Subject: [rbridge] IPvLX

From: ftemplin at iprg.nokia.com (Fred Templin)
Date: Mon Aug 23 17:31:46 2004

Hello,

With Nokia hat off, I would like to announce a proposal for IPng
called: "IPvLX - IP with virtual Link eXtension". See:

  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-00.txt

IPvLX uses IPv4 as an L2 protocol for network traversal and IPv6
as an L3 addressing protocol. It inserts an L2.5 "shim" layer between
the IPv4 header and upper layer protocol headers, and establishes
virtual links between peers using IPv6 neighbor discovery messages
for control plane signalling.

IPvLX uses a special IPv4 header construction that encodes VCI/VPI
information for virtual circuit switching in IPvLX Gateways. This
allows virtual link extension between peers located in different
enterprises/sites.

IPvLX is compatible with legacy IPv4 hosts and routers, and requires
no "flag day" changes in the Internet. It provides an adaptation layer
similar to AAL5 for efficient multiaccess segment sizing based on
path MTU.

IPvLX is a unified package combining familiar mechanisms having
various degrees of operational experience, and presents a potential
"one size fits all" alternative for IPng. Please respond on the list
with any comments/questions.

Fred L. Templin
[email-masked]

P.S. An appendix on multiprotocol support that did not make
   it in time for the I-D submission is attached below.
-------------- next part --------------
Appendix B.  IPvLX as a Layer 2.5 Shim

   Section 4 presents IPvLX as boh an IPv4 encapsulation method and an
   IPv6 header compression method that is tightly coupled with IPv6 as
   both the addressing (control plane) mechanism and data exchange (data
   plane) protocol. IPvLX could instead be decoupled from IPv6 and
   specified as a distinct Layer 2.5 "shim" between IPv4 as the L2
   protocol and any IP protocol in the IANA "Protocol Numbers" registry
   as the L3 protocol. In this model, IPv6 would serve as the control
   plane mechanism to set up virtual links between peers that can
   support data plane exchanges using any IP protocol.

   The IPvLX Flow Header (see: section 4.4.2) could be trivially
   extended to support this multiprotocol operation by adding a 1 byte
   "Protocol" field the same as for the IPv4 "Protocol" ([RFC0791],
   section 3.1) and IPv6 "Next Header" ([RFC2460], section 3) fields as
   follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|    Protocol   |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version         4-bit version number - value TBA by IANA.

   Protocol        8-bit field; indicates the IANA IP protocol number
                   exactly as for the IPv4 "Protocol" and IPv6 "Next
                   Header" fields.

   Flow Label      20-bit flow label [RFC3697].

   With this extended format, the IPvLX Flow Header becomes 4 bytes in
   length instead of just 3 and would occur immediately following the
   20-byte IPv4 header in all IPvLX packets (see: section 4.2.1) as
   follows:

                  +-------------------------------+
                  |     IPv4 Header (20 bytes)    |
                  |                               |
                  | RF = DF = 1; MF = [0|1]       |
                  | 1 <= SEGID <= 31              |
                  | 23 < Length <= (20 + SEGSIZE) |
                  |                               |
                  +-----------------------+-------+
                  |  IPvLX Flow Header (4 bytes)  |
                  +-------------------------------+
                  |                               |
                  ~ Up to (SEGSIZE - 4) PDU bytes ~
                  |                               |
                  +-------------------------------+

                    Format for all IPvLX packets

   The extended format has the disadvantage of consuming 1 extra byte
   per IPvLX packet, and reducing the maximum IPvLX PDU Payload (see:
   section 4.2) to (2^16 - (32 * 4) - 1) = 65407 bytes. These
   disadvantages are outweighed by numerous advantages, including:

       -  IPvLX gateways can process all IPvLX packets in fast-path
          since the 4-byte IPvLX Flow Header occurs in all packets.

       -  Awkward, special-case encodings that lead to slow path
          handling (e.g., the IPvLX Fragment Header - see: section
          4.4.3) are no longer needed.

       -  The 4-byte IPvLX Flow Header following the 20-byte IPv4 header
          provides a natural 8-byte alignment needed for any protocol
          headers that follow (e.g., IPv6 header extensions).

       -  The "Protocol" field allows multiprotocol operation on the
          data plane with IPv6 as the control plane mechanism for
          virtual link setup.

Date: Mon, 23 Aug 2004 17:30:50 -0700
From: Fred Templin <[email-masked]>
To: [email-masked], [email-masked], [email-masked], [email-masked]
Cc: [email-masked]
Subject: [rbridge] IPvLX
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 5080

This is a multi-part message in MIME format.
--------------090103090404090003080608
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello,

With Nokia hat off, I would like to announce a proposal for IPng
called: "IPvLX - IP with virtual Link eXtension". See:

  http://www.ietf.org/internet-drafts/draft-templin-ipvlx-00.txt

IPvLX uses IPv4 as an L2 protocol for network traversal and IPv6
as an L3 addressing protocol. It inserts an L2.5 "shim" layer between
the IPv4 header and upper layer protocol headers, and establishes
virtual links between peers using IPv6 neighbor discovery messages
for control plane signalling.

IPvLX uses a special IPv4 header construction that encodes VCI/VPI
information for virtual circuit switching in IPvLX Gateways. This
allows virtual link extension between peers located in different
enterprises/sites.

IPvLX is compatible with legacy IPv4 hosts and routers, and requires
no "flag day" changes in the Internet. It provides an adaptation layer
similar to AAL5 for efficient multiaccess segment sizing based on
path MTU.

IPvLX is a unified package combining familiar mechanisms having
various degrees of operational experience, and presents a potential
"one size fits all" alternative for IPng. Please respond on the list
with any comments/questions.

Fred L. Templin
[email-masked]

P.S. An appendix on multiprotocol support that did not make
   it in time for the I-D submission is attached below.

--------------090103090404090003080608
Content-Type: text/plain;
 name="appb"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
 filename="appb"

Appendix B.  IPvLX as a Layer 2.5 Shim

   Section 4 presents IPvLX as boh an IPv4 encapsulation method and an
   IPv6 header compression method that is tightly coupled with IPv6 as
   both the addressing (control plane) mechanism and data exchange (data
   plane) protocol. IPvLX could instead be decoupled from IPv6 and
   specified as a distinct Layer 2.5 "shim" between IPv4 as the L2
   protocol and any IP protocol in the IANA "Protocol Numbers" registry
   as the L3 protocol. In this model, IPv6 would serve as the control
   plane mechanism to set up virtual links between peers that can
   support data plane exchanges using any IP protocol.

   The IPvLX Flow Header (see: section 4.4.2) could be trivially
   extended to support this multiprotocol operation by adding a 1 byte
   "Protocol" field the same as for the IPv4 "Protocol" ([RFC0791],
   section 3.1) and IPv6 "Next Header" ([RFC2460], section 3) fields as
   follows:

   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version|    Protocol   |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Version         4-bit version number - value TBA by IANA.

   Protocol        8-bit field; indicates the IANA IP protocol number
                   exactly as for the IPv4 "Protocol" and IPv6 "Next
                   Header" fields.

   Flow Label      20-bit flow label [RFC3697].

   With this extended format, the IPvLX Flow Header becomes 4 bytes in
   length instead of just 3 and would occur immediately following the
   20-byte IPv4 header in all IPvLX packets (see: section 4.2.1) as
   follows:

                  +-------------------------------+
                  |     IPv4 Header (20 bytes)    |
                  |                               |
                  | RF = DF = 1; MF = [0|1]       |
                  | 1 <= SEGID <= 31              |
                  | 23 < Length <= (20 + SEGSIZE) |
                  |                               |
                  +-----------------------+-------+
                  |  IPvLX Flow Header (4 bytes)  |
                  +-------------------------------+
                  |                               |
                  ~ Up to (SEGSIZE - 4) PDU bytes ~
                  |                               |
                  +-------------------------------+

                    Format for all IPvLX packets

   The extended format has the disadvantage of consuming 1 extra byte
   per IPvLX packet, and reducing the maximum IPvLX PDU Payload (see:
   section 4.2) to (2^16 - (32 * 4) - 1) = 65407 bytes. These
   disadvantages are outweighed by numerous advantages, including:

       -  IPvLX gateways can process all IPvLX packets in fast-path
          since the 4-byte IPvLX Flow Header occurs in all packets.

       -  Awkward, special-case encodings that lead to slow path
          handling (e.g., the IPvLX Fragment Header - see: section
          4.4.3) are no longer needed.

       -  The 4-byte IPvLX Flow Header following the 20-byte IPv4 header
          provides a natural 8-byte alignment needed for any protocol
          headers that follow (e.g., IPv6 header extensions).

       -  The "Protocol" field allows multiprotocol operation on the
          data plane with IPv6 as the control plane mechanism for
          virtual link setup.

--------------090103090404090003080608--

Date: Wed, 4 Aug 2004 10:18:16 -0700 (PDT)
From: Erik Nordmark <[email-masked]>
Subject: RE: [rbridge] IPVLX Agenda
To: "Ghanwani, Anoop" <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Erik Nordmark <[email-masked]>
Reply-To: Erik Nordmark <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 186

> Were minutes taken at the BoF?  Are they publicly accessible?

I need to merge to sets of minutes together and then I'll send them out to
the list and ask for corrections.

   Erik

Content-class: urn:content-classes:message
Subject: RE: [rbridge] IPVLX Agenda
Date: Wed, 4 Aug 2004 10:14:09 -0700
From: "Ghanwani, Anoop" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Cc: 
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3283

Hi Erik,

Were minutes taken at the BoF?  Are they publicly accessible?

Thanks,
Anoop
--
Anoop Ghanwani | Procurve Networking | 916.785.1760 | [email-masked]

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Erik Nordmark
> Sent: Friday, July 30, 2004 3:49 PM
> To: [email-masked]
> Subject: [rbridge] IPVLX Agenda
> 
> 
> 
> Sorry for the lateness - I've been on vacation for the last two weeks.
> Agenda comments welcome now or during agenda bashing on Monday.
> 
> ---
> 
> Agenda for IP Virtual Link eXtension BOF (IPVLX)
> 	Monday 1300-1500 in Harbor I
> 
> Welcome Administrivia, and	Erik Nordmark		5 minutes
> Agenda Bashing
> 
> Problem Statement		Erik Nordmark		15 minutes
> 
> Exploring possible solutions to understand
> the problem and solution space better with 2 presentations:
> 
> Automatic Prefix Assignment	Hilarie Orman		15 minutes
> 
> L2 Bridges and		 	Radia Perlman		
> 30 minutes
> Rbridges 
> <draft-perlman-rbridge-01.txt>
> 
> How do the 3 above approaches   Erik Nordmark		10 minutes
> match the problem statement?
> 
> Discussion off problem		All			
> 30 minutes
> statement and how to proceed
> 
> 
> Reading list:
> Problem statement (included below)
> draft-perlman-rbridge-01.txt
> draft-williams-ipvlx-ipbridging-01.txt
> 
> ---
> 
> Problem Statement:
> 
> Organizations with large local networks may wish to administer
> them without the complications of internal IP address assignments.
> Layer 2 addresses provide the unique names, but the most common 
> layer 2 interconnection method (dynamically created spanning tree
> formation using bridges) is not as flexible as layer 3 routing.
> The BoF will explore hybrid solutions that retain the simplicity of 
> administration while taking full advantage of complex topologies.
> 
> Bridges with spanning tree algorithms have obvious 
> disadvantages: routing
> is confined to a spanning tree (precluding pair-wise shortest paths),
> ARP and Neighbor Discovery packets must be carried across all 
> the links,
> the header on which the spanning tree forwards has no hop count,
> spanning tree forwarding in the presence of temporary loops spawns
> exponential copies of packets, nodes can have only a single point of
> attachment, the spanning tree, in order to avoid temporary loops,
> is slow to start forwarding on new ports, and it is not 
> possible to take
> advantage of the rich physical topology for capacity since 
> the packet flows
> are restricted to following the spanning tree.
> 
> Routers avoid those disadvantages but have their own problems:
> IP addresses are link specific so a host that moves must change 
> its IP address, the routers must be configured with unique 
> link prefixes
> for each of the attached links, and the block of IP address 
> space can not be
> fully utilized because it must be partitioned across the 
> different links.
> 
> The BoF will explore combining benefits of bridges and 
> routers in a way 
> that will co-exist with existing hosts, IP routers and bridges.  The 
> design should support both IPv4 and IPv6.
> 
> ---
> 
> 
> 
> _______________________________________________
> rbridge mailing list
> [email-masked]
> http://www.postel.org/mailman/listinfo/rbridge
> 

From: Bill Sommerfeld <[email-masked]>
To: Radia Perlman <[email-masked]>
Date: Tue, 03 Aug 2004 13:57:31 -0400
Sender: [email-masked]
Subject: Re: [rbridge] duplicate-arp equivalence.
Cc: [email-masked]
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 960

   Ah. This is an interesting issue. First let me ask...you are
   describing the case where there are two IP nodes with different MAC
   addresses but the same L3 address, right?
 
   Is this because you genuinely want a node to have multiple interfaces
   and have the same layer 3 address on multiple interfaces (with
   different layer 2 addresses on each interface)? Or is this
   misconfiguration?

My first note was specifically worrying about the misconfiguration
case from a "first, do no harm" perspective.

   But it would help to know if this is an error case you're worried about 
   detecting or something you'd like to work for path splitting.

But in the long run I'm also interested in the multihoming case..

Potentially both, but path-splitting/multipathing/redundancy is a
harder nut to crack; in addition, if you're multihoming for (local)
performance, a multihomed leaf node would also want some way to learn
the topology..

						- Bill

Date: Wed, 04 Aug 2004 03:20:34 +1000
From: Aidan Williams <[email-masked]>
To: "Developing a hybrid router/bridge." <[email-masked]>
Subject: [rbridge] Scalability vs robustness/efficiency
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 452

Hi all,

During the BoF there were various people at the microphone
who saw rbridge as a way of scaling the size of bridged
networks beyond what one can achieve today.
Whilst increased scalability may result from using rbridges
I think that is not the primary motivation.

Rather the motivation is that rbridging offers increased
robustness and efficiency over bridged networks
at whatever scale bridged lans are used today.

regards
	aidan
____
:wq!

Date: Tue, 03 Aug 2004 10:06:53 -0700
From: Radia Perlman <[email-masked]>
Subject: Re: [rbridge] duplicate-arp equivalence.
To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Cc: 
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 3656

Ah. This is an interesting issue. First let me ask...you are describing 
the case where
there are two IP nodes with different MAC addresses but the same L3 
address, right?

Is this because you genuinely want a node to have multiple interfaces 
and have the
same layer 3 address on multiple interfaces (with different layer 2 
addresses on
each interface)? Or is this misonfiguration?

The way the RBridge design is now, you may or may not like
its behavior. Let me explain what happens.

Suppose IPa is looking for IPx, and nobody has looked for IPx yet. IPa will
do an ARP. There will be a flooded ARP request. Some designated RBridge R1,
will be locally connected to the target, and hear the ARP reply (IPx, MACy).

R1 will flood (IPx, MACy) in its link state information. Now when anyone is
looking for IPx, their local RBridge will respond "MACy". There will not
be a conflict detected because the ARP is answered locally.

However, if the "other" IPx does an ARP reply (a gratuitous
ARP reply), then RBridges would be able to
detect the conflict.

This behavior will be very efficient in the usual case, however, I can 
imagine someone
being unhappy about not detecting this. So there are a couple of 
alternatives off the
top of my head:

a) learn (IPx, MACy) from received data traffic (like a bridge learns 
MACy from received
data, an RBridge could proactively learn from both the layer 3 and layer 
2 header). This
way they would detect if the same IP address is in multiple locations, 
with different layer
2 addresses. If (IPx, MACy) is in your link state information, and a 
designated RBridge R2
receives an unencapsulated packet from IPx with MACz, then R2 could 
either also advertise
(IPx, MACz) in its link state information so that all RBridges will know 
there are two
answers for IPx (either MACy or MACz), or R1 (who heard MACy) and R2 could
each do a gratuitous ARP reply to alert their local node of the 
existence of the other
node. (i.e., is this a failure case to be noticed, or a path splitting 
case to be handled?)

b) periodically have all RBridges do ARP queries for all (l3, l2) info 
in the link state database
to make sure there are no conflicts (I don't like this solution).

c) when I started this list I thought I had other ideas, but can't think 
of them now.  But
it would help to know if this is an error case you're worried about 
detecting or something
you'd like to work for path splitting.

Radia

Bill Sommerfeld wrote:

>I've looked at rbridges a little bit from the perspective of a host
>implementor..
>
>A very desirable property of an rbridge ARP proxy would replicate the
>existing arp conflict detection behavior you see on a broadcast
>network -- both nodes see both arp replies, and a common response is
>to generate a log message along the lines of:
>
>	WARNING: IP: Hardware address '00:90:96:xx:yy:zz' trying to be
>	our address 130.129.a.b!
>
>(quoted from a log entry from earlier today on my laptop; edited to
>protect the guilty from embarassment).
>
>A collection of rbridges would have to do something special in this
>case to notice the address collision -- so, in addition to generating
>the duplicate arp replies it could also generate a log message/audit
>event/management trap indicating that something odd is going on.
>
>In addition, an rbridge could be in a position to "resolve" the clash
>by enforcing its own policy.
>
>(I'd appreciate it if section 7 of the draft could be enhanced to
>mention this case..)
>
>						- Bill
>
>
>
>_______________________________________________
>rbridge mailing list
>[email-masked]
>http://www.postel.org/mailman/listinfo/rbridge
>  
>

From: Bill Sommerfeld <[email-masked]>
To: [email-masked]
Date: Mon, 02 Aug 2004 23:40:57 -0400
Sender: [email-masked]
Subject: [rbridge] duplicate-arp equivalence.
Reply-To: [email-masked], "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 1009

I've looked at rbridges a little bit from the perspective of a host
implementor..

A very desirable property of an rbridge ARP proxy would replicate the
existing arp conflict detection behavior you see on a broadcast
network -- both nodes see both arp replies, and a common response is
to generate a log message along the lines of:

	WARNING: IP: Hardware address '00:90:96:xx:yy:zz' trying to be
	our address 130.129.a.b!

(quoted from a log entry from earlier today on my laptop; edited to
protect the guilty from embarassment).

A collection of rbridges would have to do something special in this
case to notice the address collision -- so, in addition to generating
the duplicate arp replies it could also generate a log message/audit
event/management trap indicating that something odd is going on.

In addition, an rbridge could be in a position to "resolve" the clash
by enforcing its own policy.

(I'd appreciate it if section 7 of the draft could be enhanced to
mention this case..)

						- Bill

Date: Mon, 2 Aug 2004 23:29:28 +0300 (EEST)
From: Pekka Savola <[email-masked]>
To: [email-masked]
Subject: [rbridge] rbridge-01 comments
Reply-To: "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 2924

[?re-sending from Sunday -- this probably got stuck in the approval
queue as I wasn't subscribed ]

A couple of high-level comments:

 - is IS-IS trivial enough to implement?  in future, even some stereos or
home equipment might function as rbridges...

 - designated bridge IP protocol support: (this is not just designated
bridges, of course..) -- it seems this approach assumes that all the
rbridges (or at least designated rbridges) support all the IP versions
supported within the site?   Or at least if e.g. v4-only rbridge would be
elected, v6 could fall to the slower path?  What if elsewhere in the site a
v6 rbridge would be elected?

 - it would be very, very desirable (obviously) if there was some trick that
IP MTU could stay at 1500 bytes.  Actually, I guess due to MPLS or
VLANs-in-VLANs lots of Ethernet hardware at least support larger framing --
I just don't know whether that could be leveraged here. (a really
half-baked idea: try to do special marking using VLAN frames -- I just can't
quickly remember how they look like or whether they would be abusable :-)

 - the rbridge design is lucrative especially for smaller campuses
("home networks", which are unmanaged -- if it's managed, it should
have sufficient knowledge to set up routing infrastructure!).  
However, a few things which haven't bene spelled out scare me, as an
operator:

   * larger (campus-wide?) subnets means that spoofing inside a subnet is
also easier, and ingress filtering granularity ("in-prefix spoofing") is
more coarse -- leading to more difficult user tracking.

   * manageability in general is reduced.

   * if you have a single IPv4 pool for campus, or just a couple of them, it
begs the question how you configure the v4 subnet mask, and how you change
it when increasing/decreasing the size?  Maybe trivial with DHCP, but more
challenging than with smaller subnets if you have to use manual
configuration on hosts. (remember that the subnet mask needs to be changed
de-facto immediately everywhere, unless proxy-arp hacks are used, else
in-site communication suffers.)

   * larger subnets do not mean good for firewalling between segments.  Do
you do this at rbridges using MAC's then? :)  I.e., modern enterprises
*have* to include firewalling between different departments, or different
classes of networks.  The rbridge model appears to increase openness (which
is good), but this will likely hamper the effects to keep the users separate
and from harming each other.  (consider e.g., virus/worm propagation inside
a single rbridged subnet.)

Some minor observations:

 - does IS-IS have an "area address" -- wasn't that an OSPF concept?

 - the draft uses quite ipv4-specific terminology in most places (ARP, IGMP)

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

Date: Sun, 1 Aug 2004 15:57:37 -0700 (PDT)
From: Erik Nordmark <[email-masked]>
To: [email-masked]
Cc: 
Subject: [rbridge] Need minute taker and jabber scribe
Reply-To: Erik Nordmark <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 58

Any volunteers for this for tomorrow's meeting?

  Erik

Date: Sun, 1 Aug 2004 15:56:54 -0700 (PDT)
From: Erik Nordmark <[email-masked]>
Subject: Re: [rbridge] IPVLX Agenda
To: Fred Templin <[email-masked]>
Cc: "Developing a hybrid router/bridge." <[email-masked]>, Erik Nordmark <[email-masked]>
Reply-To: Erik Nordmark <[email-masked]>, "Developing a hybrid router/bridge." <[email-masked]>
Status: RO
Content-Length: 422

> I have a new document with some possible relevance for
> ipvlx. Any chance to have this one added to the reading list:
> 
>   http://www.geocities.com/osprey67/v6v4inet-01a.txt

It isn't obvious to me how this draft relates to understanding the IPVLX
problem statement and the possible ways it can be approached.
Did anybody on the list already read it that can help the rest of us
understand the relationship?

  Erik