[rbridge] rbridge for ipv6 ?
Radia.Perlman at sun.com
Tue Sep 13 12:56:58 PDT 2005
I agree with Joe. I don't see any problem with supporting IPv6. The IS-IS routing that we'll use
will be layer 3 agnostic. The first step is having all the RBridges exchanging their system IDs (MAC addresses)
and connectivity to other RBridges' system IDs. IS-IS does not send over IP. It has its own Ethertype. So
I don't see any problem with IPv6 for the basic RBridge-RBridge topology building piece.
Then there would be TLVs for announcing
. VLAN membership
. MAC addresses of attached nodes
. (L3,L2) information for supporting proxy ARP/proxy ND
I'd think only the last would be layer 3 aware. And yes, I agree we should support IPv6 as well as
IPv4. I think it's just a matter of having two different TLVs, one for announcing (IPv4, MAC) and
one for announcing (IPv6, MAC).
Are there other issues?
----- Original Message -----
From: Joe Touch <touch at ISI.EDU>
Date: Tuesday, September 13, 2005 10:18 am
Subject: Re: [rbridge] rbridge for ipv6 ?
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> Pekka Savola wrote:
> > On Tue, 13 Sep 2005, Joe Touch wrote:
> >>Rbridge is an L2 device; at the ingress, it should be capable of
> peeking>>into various packets for optimization like other L2
> systems, e.g., for
> >>multicast. This includes IPv4 and IPv6, but these are just
> optimizations>>- if not implemented, it should not affect correct
> > (This should be obvious, but I'll state it explicitly in any
> case), it
> > should still work if some parts of the site implement v4/v6
> > rbridges, some can only optimize for v4, others only for v6, and
> > another set not at all.
> Agreed. Also, how much the optimization helps may depend on how
> widespread support for the optimization is.
> > Maybe that requires each rbridge adversiting its optimizing
> > capabilities in IS-IS or something, which may or may not be trivial.
> We can have everyone participate in supporting multiple routing
> 'trees'(they're not trees anymore, but you get the idea), where
> only egresses
> that support v4 or v4 peek will be able to utilize. I don't think this
> requires advertizing the capabilities per se, but it will probably
> require the use of separate forwarding tables. those that support such
> will use them; others will support only a single merged table as well.
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> -----END PGP SIGNATURE-----
> rbridge mailing list
> rbridge at postel.org
More information about the rbridge