[rbridge] rbridge for ipv6 ?

[Radia.Perlman@sun.com]

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?

Radia


----- 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 
> operation.> 
> > (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 
> optimizing 
> > rbridges, some can only optimize for v4, others only for v6, and 
> yet 
> > 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.
> 
> 
> Joe
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.2.4 (MingW32)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
> 
> iD8DBQFDJwoDE5f5cImnZrsRAuroAKCP0zWimIp+Z8o9wfy3r0JCRo77mACfRA6f
> 8i4sPuCpOuJE7cN33SrQ/cw=
> =L7br
> -----END PGP SIGNATURE-----
> _______________________________________________
> rbridge mailing list
> rbridge at postel.org
> http://www.postel.org/mailman/listinfo/rbridge
>