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.
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 protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------