Subject: Ethernet as a shared (not broadcast) network?

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 4 Apr 2006 17:30:27 -0500

In perusing old RFCs, I think I've come across a rather odd possibility that 
doesn't seem to be explicitly prohibited but is probably accidental: using 
multiple Ethernets operating as a single "shared" network instead of as 
multiple "broadcast" networks, to use RFC 2461 section 2.2 terms.

To understand the possible use of this, consider a site where there are 
multiple Ethernet VLANs in use, perhaps dozens, but the administrator wishes 
to use a single /64 for all of them without bridging them together.  This is 
conceptually similar to OSI's concept of "area" addressing.

Obviously, the routers would need to allow assigning the same prefix to 
multiple interfaces, and the L bit in the ICMPv6 RA's Prefix Information 
option would need to be clear (0).  When L=0, all hosts on any of the VLANs 
would forward packets to new destinations to a router.  If the destination 
were on the same VLAN the router would send a Redirect message; if not, the 
packet would be forwarded as normal.  This looks fairly useful in some 
scenarios.

A few obvious problems come to mind:

1. Any router connected to one VLAN in the "area" must be connected to all 
such VLANs.  If not, routing protocol modifications would be required so 
that routers would be able to forward to destinations not on an attached 
link.
2. Multicast semantics are not obvious.  Should a multicast packet of link 
scope be forwarded to the other VLANs?  ICMP RA/RS/ND gets ugly if you do 
that.  I think multicast packets of greater scope will work correctly, but I 
get lost in all the corner cases.
3. Hosts may not expect L=0 on Ethernets and behave incorrectly.

Solutions?  Other problems?  Doubts about my mental health?

S

Stephen Sprunk        "Stupid people surround themselves with smart
CCIE #3723           people.  Smart people surround themselves with
K5SSS         smart people who disagree with them."  --Aaron Sorkin
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Tue, 4 Apr 2006 15:38:48 -0700

Let me ask: would this be any different than putting an Ethernet  
switch in front of a router port?

I believe that there will be a market for this in the home.

On Apr 4, 2006, at 3:30 PM, Stephen Sprunk wrote:

> In perusing old RFCs, I think I've come across a rather odd  
> possibility that doesn't seem to be explicitly prohibited but is  
> probably accidental: using multiple Ethernets operating as a single  
> "shared" network instead of as multiple "broadcast" networks, to  
> use RFC 2461 section 2.2 terms.
>
> To understand the possible use of this, consider a site where there  
> are multiple Ethernet VLANs in use, perhaps dozens, but the  
> administrator wishes to use a single /64 for all of them without  
> bridging them together.  This is conceptually similar to OSI's  
> concept of "area" addressing.
>
> Obviously, the routers would need to allow assigning the same  
> prefix to multiple interfaces, and the L bit in the ICMPv6 RA's  
> Prefix Information option would need to be clear (0).  When L=0,  
> all hosts on any of the VLANs would forward packets to new  
> destinations to a router.  If the destination were on the same VLAN  
> the router would send a Redirect message; if not, the packet would  
> be forwarded as normal.  This looks fairly useful in some scenarios.
>
> 1. Any router connected to one VLAN in the "area" must be connected  
> to all such VLANs.  If not, routing protocol modifications would be  
> required so that routers would be able to forward to destinations  
> not on an attached link.
> 2. Multicast semantics are not obvious.  Should a multicast packet  
> of link scope be forwarded to the other VLANs?  ICMP RA/RS/ND gets  
> ugly if you do that.  I think multicast packets of greater scope  
> will work correctly, but I get lost in all the corner cases.

---

From: Bob Hinden <[email-masked]>
Date: Tue, 4 Apr 2006 16:26:32 -0700

Stephen,

I think you have reinvented what has been called multilink subnets.   
This has been discussed at some length in the IPv6 working group and  
the conclusion was to not go there in the general case.  We did  
produce a very simple version called "ND Proxy".  See: http:// 
www.ietf.org/internet-drafts/draft-ietf-ipv6-ndproxy-04.txt.  This is  
currently in RFC-Editor queue.

Dave Thaler also wrote a draft on the general topic that was  
presented at the internet area meeting in Dallas:

   Issues With Protocols Proposing Multilink Subnets

   http://www.ietf.org/internet-drafts/draft-thaler-intarea-multilink- 
subnet-issues-00.txt

Bob

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 5 Apr 2006 00:33:06 -0500

Thus spake "Bob Hinden" <[email-masked]>
> I think you have reinvented what has been called multilink subnets.   This 
> has been discussed at some length in the IPv6 working group and  the 
> conclusion was to not go there in the general case.  We did  produce a 
> very simple version called "ND Proxy".  See: http:// 

Interesting, but it's sufficiently different from what I envisioned I didn't 
see a connection.  It shows me the value of creating specific protocols to 
cover a specific set of use cases, though, rather than one that tries to 
cover them all.

> Dave Thaler also wrote a draft on the general topic that was  presented at 
> the internet area meeting in Dallas:
>

Very good reading; thanks for the pointer.

It seems the main issue is multicast propogation, which is one I'd come up 
with but didn't see the full ramifications of.  In fact, limiting 
multicast/broadcast traffic is one of my main reasons for wanting multilink 
subnets (the other being STP scaling problems).  I'll have to think about 
if/how the listed problems apply to what I had in mind; they might be 
considered features in some environments, not bugs.

S

---

From: Bob Hinden <[email-masked]>
Date: Wed, 5 Apr 2006 13:23:47 -0700

Stephen,

On Apr 4, 2006, at 10:33 PM, Stephen Sprunk wrote:

>> I think you have reinvented what has been called multilink  
>> subnets.   This has been discussed at some length in the IPv6  
>> working group and  the conclusion was to not go there in the  
>> general case.  We did  produce a very simple version called "ND  
>> Proxy".  See: http:// www.ietf.org/internet-drafts/draft-ietf-ipv6- 
>> ndproxy-04.txt.  This is currently in RFC-Editor queue.
>
> Interesting, but it's sufficiently different from what I envisioned  
> I didn't see a connection.  It shows me the value of creating  
> specific protocols to cover a specific set of use cases, though,  
> rather than one that tries to cover them all.

Do a search and read the earlier versions of the draft (w.g. and  
individual).  The original intent was broader :-)

Bob

>>   http://www.ietf.org/internet-drafts/draft-thaler-intarea- 
>> multilink- subnet-issues-00.txt
>
> It seems the main issue is multicast propogation, which is one I'd  
> come up with but didn't see the full ramifications of.  In fact,  
> limiting multicast/broadcast traffic is one of my main reasons for  
> wanting multilink subnets (the other being STP scaling problems).   
> I'll have to think about if/how the listed problems apply to what I  
> had in mind; they might be considered features in some  
> environments, not bugs.
>
> S
>