bgp4r 0.0.15 → 0.0.16

metadata

@@ -1,15 +1,14 @@
 --- !ruby/object:Gem::Specification
 name: bgp4r
 version: !ruby/object:Gem::Version
-  version: 0.0.15
-  prerelease: 
+  version: 0.0.16
 platform: ruby
 authors:
 - Jean-Michel Esnault
 autorequire: 
 bindir: bin
 cert_chain: []
-date: 2012-02-13 00:00:00.000000000 Z
+date: 2014-05-07 00:00:00.000000000 Z
 dependencies: []
 description: BGP4R is a BGP-4 ruby library to create,  send, and receive  BGP messages
   in an  object oriented manner
@@ -47,6 +46,7 @@ files:
 - bgp/nlris/prefix.rb
 - bgp/nlris/rd.rb
 - bgp/nlris/vpn.rb
+- bgp/nlris/mapped_ipv4.rb
 - bgp/optional_parameters/add_path.rb
 - bgp/optional_parameters/as4.rb
 - bgp/optional_parameters/capabilities.rb
@@ -87,6 +87,7 @@ files:
 - examples/unit-testing/no_export_test.rb
 - examples/unit-testing/prepend_aspath_test.rb
 - examples/unit-testing/unknown_transitive_attr_test.rb
+- examples/bgp-vyatta-ipv6.rb
 - test/functional/add_path_test.rb
 - test/functional/live_feed_test.rb
 - test/helpers/server.rb
@@ -111,6 +112,7 @@ files:
 - test/unit/nlris/prefix_test.rb
 - test/unit/nlris/rd_test.rb
 - test/unit/nlris/vpn_test.rb
+- test/unit/nlris/mapped_ipv4_test.rb
 - test/unit/optional_parameters/add_path_test.rb
 - test/unit/optional_parameters/as4_test.rb
 - test/unit/optional_parameters/capability_test.rb
@@ -138,29 +140,26 @@ files:
 - test/unit/path_attributes/origin_test.rb
 - test/unit/path_attributes/originator_id_test.rb
 - test/unit/path_attributes/path_attribute_test.rb
-- test/unit/path_attributes/tunnel_encapsulation_test (Jean-Michel's Laptop's conflicted
-  copy 2011-11-02).rb
 homepage: http://github.com/jesnault/bgp4r/tree/master
 licenses: []
+metadata: {}
 post_install_message: 
 rdoc_options: []
 require_paths:
 - .
 required_ruby_version: !ruby/object:Gem::Requirement
-  none: false
   requirements:
   - - ! '>='
     - !ruby/object:Gem::Version
       version: 1.8.6
 required_rubygems_version: !ruby/object:Gem::Requirement
-  none: false
   requirements:
   - - ! '>='
     - !ruby/object:Gem::Version
       version: '0'
 requirements: []
 rubyforge_project: bgp4r
-rubygems_version: 1.8.11
+rubygems_version: 2.0.3
 signing_key: 
 specification_version: 3
 summary: A BGP-4 Ruby Library
@@ -216,5 +215,3 @@ test_files:
 - test/unit/path_attributes/origin_test.rb
 - test/unit/path_attributes/originator_id_test.rb
 - test/unit/path_attributes/path_attribute_test.rb
-- test/unit/path_attributes/tunnel_encapsulation_test (Jean-Michel's Laptop's conflicted
-  copy 2011-11-02).rb

data/test/unit/path_attributes/tunnel_encapsulation_test (Jean-Michel's Laptop's conflicted copy 2011-11-02).rb

@@ -1,388 +0,0 @@
-require "test/unit"
-require "bgp/path_attributes/tunnel_encapsulation"
-require 'bgp4r'
-require 'test/helpers/server'
-
-
-class TestTunnelEncapsulation < Test::Unit::TestCase
-  include BGP
-  
-  class TestColor < Test::Unit::TestCase
-    include BGP
-    def test_case_name
-      color = Tunnel_encapsulation::Color.new(10)
-      assert_equal('0408030b00000000000a',color.to_shex)
-      assert_equal(4, color.stlv_type)
-    end
-  end
-
-  class TestProtocolTYpe < Test::Unit::TestCase
-    include BGP
-    def test_case_name
-      protocol_type = Tunnel_encapsulation::Protocol_type.new :ipv4
-      assert_equal('02020800', protocol_type.to_shex)
-      assert_equal(2, protocol_type.stlv_type)
-      assert_equal('020286dd', Tunnel_encapsulation::Protocol_type.new(:ipv6).to_shex)
-      assert_equal('02028847', Tunnel_encapsulation::Protocol_type.new(:mpls).to_shex)
-    end
-  end
-  
-  class TestEncapsulationGre < Test::Unit::TestCase
-    include BGP
-    def test_case_name
-      encap = Tunnel_encapsulation::Encap_gre.new(0x12345678)
-      assert_equal('010412345678', encap.to_shex)
-    end
-  end
-
-  class TestEncapsulationL2tpv3 < Test::Unit::TestCase
-    include BGP
-    def test_case_name
-      encap = Tunnel_encapsulation::Encap_l2tpv3.new(0x1234, '1234567890123456789')
-      assert_equal('010e0000123412345678901234567890', encap.to_shex)
-    end
-  end
-
-  class TestTunnel < Test::Unit::TestCase
-    include BGP
-    def test_case_name
-      tlv = Tunnel_encapsulation::Tunnel.new(:tunnel_type=> :l2tpv3, :session_id=> 1, :cookie=> 'ffddeeaabb11ee3344', :proto_type=> :ipv4, :color=> 1234)
-      assert_equal('0001001d010d00000001ffddeeaabb11ee3344020208000408030b0000000004d2', tlv.to_shex)
-    end
-  end
-
-  
-  def test_case_name
-    tunnel_encap = Tunnel_encapsulation.new
-    assert_equal('c01700', tunnel_encap.to_shex)
-    tunnel_encap.add :tunnel_type=> :l2tpv3, :session_id=> 1, :coockie=> 0x1234, :proto_type=> :ipv4, :color=> 1234
-    assert_equal('c01718 0001 0014 01 04 00000001 02 02 0800 04 08 030b0000000004d2'.split.join, tunnel_encap.to_shex)
-    tunnel_encap.add :tunnel_type=> :l2tpv3, :session_id=> 2, :coockie=> 0x1234, :proto_type=> :ipv6, :color=> 1234
-    assert_equal('c0173000010014010400000001020208000408030b0000000004d200010014010400000002020286dd0408030b0000000004d2'.split.join, tunnel_encap.to_shex)
-    tunnel_encap.add :tunnel_type=> :l2tpv3, :session_id=> 3, :coockie=> 0x1234, :proto_type=> :mpls, :color=> 1234
-    assert_equal('c0174800010014010400000001020208000408030b0000000004d200010014010400000002020286dd0408030b0000000004d200010014010400000003020288470408030b0000000004d2'.split.join, tunnel_encap.to_shex)
-    tunnel_encap.add :tunnel_type=> :gre, :key=> 0x12345678
-    assert_equal('c0175200010014010400000001020208000408030b0000000004d200010014010400000002020286dd0408030b0000000004d200010014010400000003020288470408030b0000000004d200020006010412345678', tunnel_encap.to_shex)
-  end
-  include BGP::TestHelpers
-  
-  # def teardown
-  #   stop_server
-  # end
-  
-  # def test_send_update_with_tunnel_encap_attribute
-  # 
-  #   start_server(179)
-  #   
-  #   @c = Neighbor.new(4, 100, 180, '0.0.0.2', '127.0.0.1', '127.0.0.1')
-  #   @c.start :port=> 179
-  #   assert_equal('Established', @c.state)
-  #   assert_equal('Established', @s.state)
-  # 
-  #   tunnel_encap = Tunnel_encapsulation.new
-  #   tunnel_encap.add :tunnel_type=> :l2tpv3, :session_id=> 1, :coockie=> 0x1234, :proto_type=> :ipv4, :color=> 1234
-  #   tunnel_encap.add :tunnel_type=> :l2tpv3, :session_id=> 2, :coockie=> 0x1234, :proto_type=> :ipv6, :color=> 1234
-  #   tunnel_encap.add :tunnel_type=> :l2tpv3, :session_id=> 3, :coockie=> 0x1234, :proto_type=> :mpls, :color=> 1234
-  #   tunnel_encap.add :tunnel_type=> :gre, :key=> 0x12345678
-  #   
-  #   u = Update.new
-  #   u << tunnel_encap
-  #   
-  #   @c.send_message u
-  #   @c.send_message u
-  #   @c.send_message u
-  #   @c.send_message u
-  #   @c.send_message u
-  #   sleep 2
-  #       
-  # end
-  
-  
-  
-end
-
-
-__END__
-
-tunnels=[]
-
-
-
-
-Tunnel Type
-L2TPV3 =1
-GRE = 2
-IPIP = 7
-
-
-tunnel_encap attr:
-
-  tlv type 1: 
-    value: 
-      stlv-type 1 : session_id + coockie
-      stlv-proto-type 2 : ipv4  0x0800
-      stlv-color 4 : 0x1234
-    
-  
-  tlv type 1:
-    value:
-      stlv-type 1: session_id + coockie
-      stlv-proto-type 2 : ipv6 0x86dd
-      stlv-color 4 : 0x1234
-  
-  tlv type 1:
-    value:
-      stlv-type 1: session_id + coockie
-      stlv-proto-type 2 : mpls  0x8847
-      stlv-color 4 : 0x1234
-      
-   
-
-  tlv type 2:  (gre)
-    value: 
-      stlv-type 1: gre key (4)
-
-
-
-
-  
-
-  sub-tlv: session_id + coockie
-
-
-For example, if we want to use three L2TPv3 sessions, one carrying
-IPv4 packets, one carrying IPv6 packets, and one carrying MPLS
-packets, the egress router will include three TLVs of L2TPv3
-encapsulation type, each specifying a different Session ID and a
-different payload type.  The protocol type sub-TLV for these will be
-IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and
-MPLS (protocol type = 0x8847), respectively.  This informs the
-ingress routers of the appropriate encapsulation information to use
-with each of the given protocol types.  Insertion of the specified
-Session ID at the ingress routers allows the egress to process the
-incoming packets correctly, according to their protocol type.
-
-
-
-TLVs
-
-L2TPv3  type = 1
-GRE = 2
-IP in IP = 7
-
-Sub-TLVs
-
-- Encapsulation: sub-TLV type = 1
-
-  encap_l2tpv3 : session_id(4) + coockie(v)
-  encap_gre: key(4)
-
-- Protocol type: sub-TLV tye =2
-
-  ethertype(2)
-
-  For example, if we want to use three L2TPv3 sessions, one carrying
-  IPv4 packets, one carrying IPv6 packets, and one carrying MPLS
-  packets, the egress router will include three TLVs of L2TPv3
-  encapsulation type, each specifying a different Session ID and a
-  different payload type.  The protocol type sub-TLV for these will be
-  IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and
-  MPLS (protocol type = 0x8847), respectively.  This informs the
-  ingress routers of the appropriate encapsulation information to use
-  with each of the given protocol types.  Insertion of the specified
-  Session ID at the ingress routers allows the egress to process the
-  incoming packets correctly, according to their protocol type.
-
-  Inclusion of this sub-TLV depends on the tunnel type.  It MUST be
-  encoded for L2TPv3 tunnel type.  On the other hand, the protocol type
-  sub-TLV is not required for IP in IP or GRE tunnels.
-
-
-- Protocol type: sub-TLV type = 2
-- Color: sub-TLV type = 4
-
-
-
-4.  Tunnel Encapsulation Attribute
-
-   The Tunnel Encapsulation attribute is an optional transitive
-   attribute that is composed of a set of Type-Length-Value (TLV)
-   encodings.  The type code of the attribute is 23.  Each TLV contains
-   information corresponding to a particular tunnel technology.  The TLV
-   is structured as follows:
-
-       0                   1                   2                   3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |    Tunnel Type (2 Octets)     |        Length (2 Octets)      |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                                                               |
-      |                             Value                             |
-      |                                                               |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   * Tunnel Type (2 octets): identifies the type of tunneling technology
-     being signaled.  This document defines the following types:
-
-     - L2TPv3 over IP [RFC3931]: Tunnel Type = 1
-     - GRE [RFC2784]: Tunnel Type = 2
-     - IP in IP [RFC2003] [RFC4213]: Tunnel Type = 7
-
-     Unknown types are to be ignored and skipped upon receipt.
-
-   * Length (2 octets): the total number of octets of the value field.
-
-   * Value (variable): comprised of multiple sub-TLVs.  Each sub-TLV
-     consists of three fields: a 1-octet type, 1-octet length, and zero
-     or more octets of value.  The sub-TLV is structured as follows:
-
-
-
-
-Mohapatra & Rosen           Standards Track                     [Page 5]
- 
-RFC 5512    BGP Encapsulation SAFI and Tunnel Encapsulation   April 2009
-
-
-                     +-----------------------------------+
-                     |      Sub-TLV Type (1 Octet)       |
-                     +-----------------------------------+
-                     |     Sub-TLV Length (1 Octet)      |
-                     +-----------------------------------+
-                     |     Sub-TLV Value (Variable)      |
-                     |                                   |
-                     +-----------------------------------+
-
-   * Sub-TLV Type (1 octet): each sub-TLV type defines a certain
-     property about the tunnel TLV that contains this sub-TLV.  The
-     following are the types defined in this document:
-
-     - Encapsulation: sub-TLV type = 1
-     - Protocol type: sub-TLV type = 2
-     - Color: sub-TLV type = 4
-
-     When the TLV is being processed by a BGP speaker that will be
-     performing encapsulation, any unknown sub-TLVs MUST be ignored and
-     skipped.  However, if the TLV is understood, the entire TLV MUST
-     NOT be ignored just because it contains an unknown sub-TLV.
-
-   * Sub-TLV Length (1 octet): the total number of octets of the sub-TLV
-     value field.
-
-   * Sub-TLV Value (variable): encodings of the value field depend on
-     the sub-TLV type as enumerated above.  The following sub-sections
-     define the encoding in detail.
-
-4.1.  Encapsulation Sub-TLV
-
-   The syntax and semantics of the encapsulation sub-TLV is determined
-   by the tunnel type of the TLV that contains this sub-TLV.
-
-   When the tunnel type of the TLV is L2TPv3 over IP, the following is
-   the structure of the value field of the encapsulation sub-TLV:
-
-       0                   1                   2                   3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                      Session ID (4 octets)                    |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                                                               |
-      |                        Cookie (Variable)                      |
-      |                                                               |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-
-
-
-
-Mohapatra & Rosen           Standards Track                     [Page 6]
- 
-RFC 5512    BGP Encapsulation SAFI and Tunnel Encapsulation   April 2009
-
-
-   * Session ID: a non-zero 4-octet value locally assigned by the
-     advertising router that serves as a lookup key in the incoming
-     packet's context.
-
-   * Cookie: an optional, variable length (encoded in octets -- 0 to 8
-     octets) value used by L2TPv3 to check the association of a received
-     data message with the session identified by the Session ID.
-     Generation and usage of the cookie value is as specified in
-     [RFC3931].
-
-     The length of the cookie is not encoded explicitly, but can be
-     calculated as (sub-TLV length - 4).
-
-   When the tunnel type of the TLV is GRE, the following is the
-   structure of the value field of the encapsulation sub-TLV:
-
-       0                   1                   2                   3
-       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-      |                      GRE Key (4 octets)                       |
-      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   * GRE Key: 4-octet field [RFC2890] that is generated by the
-     advertising router.  The actual method by which the key is obtained
-     is beyond the scope of this document.  The key is inserted into the
-     GRE encapsulation header of the payload packets sent by ingress
-     routers to the advertising router.  It is intended to be used for
-     identifying extra context information about the received payload.
-
-     Note that the key is optional.  Unless a key value is being
-     advertised, the GRE encapsulation sub-TLV MUST NOT be present.
-
-4.2.  Protocol Type Sub-TLV
-
-   The protocol type sub-TLV MAY be encoded to indicate the type of the
-   payload packets that will be encapsulated with the tunnel parameters
-   that are being signaled in the TLV.  The value field of the sub-TLV
-   contains a 2-octet protocol type that is one of the types defined in
-   [IANA-AF] as ETHER TYPEs.
-
-   For example, if we want to use three L2TPv3 sessions, one carrying
-   IPv4 packets, one carrying IPv6 packets, and one carrying MPLS
-   packets, the egress router will include three TLVs of L2TPv3
-   encapsulation type, each specifying a different Session ID and a
-   different payload type.  The protocol type sub-TLV for these will be
-   IPv4 (protocol type = 0x0800), IPv6 (protocol type = 0x86dd), and
-   MPLS (protocol type = 0x8847), respectively.  This informs the
-   ingress routers of the appropriate encapsulation information to use
-   with each of the given protocol types.  Insertion of the specified
-   Session ID at the ingress routers allows the egress to process the
-   incoming packets correctly, according to their protocol type.
-
-   Inclusion of this sub-TLV depends on the tunnel type.  It MUST be
-   encoded for L2TPv3 tunnel type.  On the other hand, the protocol type
-   sub-TLV is not required for IP in IP or GRE tunnels.
-
-4.3.  Color Sub-TLV
-
-   The color sub-TLV MAY be encoded as a way to color the corresponding
-   tunnel TLV.  The value field of the sub-TLV contains an extended
-   community that is defined as follows:
-
-4.3.1.  Color Extended Community
-
-   The Color Extended Community is an opaque extended community
-   [RFC4360] with the following encoding:
-
-           0                   1                   2                   3
-           0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
-          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-          |       0x03    |     0x0b      |           Reserved            |
-          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-          |                          Color Value                          |
-          +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
-
-   The value of the high-order octet of the extended type field is 0x03,
-   which indicates it is transitive.  The value of the low-order octet
-   of the extended type field for this community is 0x0b.  The color
-   value is user defined and configured locally on the routers.  The
-   same Color Extended Community can then be attached to the UPDATE
-   messages that contain payload prefixes.  This way, the BGP speaker
-   can express the fact that it expects the packets corresponding to
-   these payload prefixes to be received with a particular tunnel
-   encapsulation header.
-
-