Brian, It would not be significant to rip the site stuff out of the code as I see it.
/jim > -----Original Message----- > From: Brian Haberman [mailto:[EMAIL PROTECTED]] > Sent: Sunday, June 09, 2002 10:33 AM > To: Margaret Wasserman > Cc: [EMAIL PROTECTED] > Subject: Re: Fwd: IPv6 Scoped Addresses and Routing Protocols > > > Hi Margaret, > I suppose that I should admit to being remiss in this area. I > have done a fair amount of work in this area and just haven't had the > time to document routing protocol behavior changes to support site > local prefixes (even though I recall telling you I was going > to do it). > > Anyway, I will start by saying that I have modified RIPng to > correctly handle the advertisement of site-locals. In order to make > this efficient, I maintained the concept of a single instance of RIPng > running in the router. In order to understand the changes to the > routing protocol, you also have to understand the changes to the > RIB for site locals. So, how did I make it work? > > 1. The RIB now contains an additional field, the zone ID. I > have done this in two different ways. The first is to add > the zone ID as a separate field. The second is to embed > the zone ID in the "unused" portion of the site local > prefix. > > 2. RIPng was changed to build its route advertisement messages > on a per zone ID basis. That is, it starts with adding all > global prefixes to the message. It then adds site local > prefixes that are in the same zone ID as the interface that > the advertisement will be transmitted. It determines this > by extracting the zone ID from the outgoing interface and > using this find all site locals in the RIB with a matching > zone ID. > > 3. When RIPng receives a route advertisement from a peer, it > takes the zone ID from the receiving interface and using > that to add the site local prefixes to the RIB. > > That, in a nutshell, allows a single instance of RIPng to control > the advertising of site local unicast prefixes. Though I haven't > done the work, I would see OSPF as acting in a similar manner. > > If someone wants me to describe the actual forwarding, just let me > know. > > Regards, > Brian > > Margaret Wasserman wrote: > > > > I sent the attached message to the routing area discussion > list. I thought that people on > > the IPv6 list might be interested in this discussion, so I > will forward a message containing > > the responses after this one. I suppose I just should have > cc:ed the IPv6 group in the > > first place... > > > > Margaret > > > > >Date: Fri, 24 May 2002 12:17:04 -0400 > > >To: [EMAIL PROTECTED] > > From: Margaret Wasserman <[EMAIL PROTECTED]> > > >Subject: IPv6 Scoped Addresses and Routing Protocols > > > > > > > > > > > >Hi All, > > > > > >I raised some questions with Bill Fenner in Minneapolis > regarding IPv6 scoped > > >addressing and our current IPv6 routing protocol > specifications, and Bill suggested > > >that I should send my questions to this list for > discussion. So, here they are. > > > > > >First, some background... > > > > > >As many of you probably know, IPv6 includes the concept of > scoped unicast > > >addressing -- a unicast address can have link-local scope, > site-local scope > > >or global scope. The address scopes are defined in the > IPv6 Addressing > > >Architecture: > > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-ar > ch-v3-07.txt > > > > > >Additional information can be found in the IPv6 Scoped Address > > >Architecture: > > > > > > >http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-scoping > -arch-03.txt > > > > > >I would suggest that all of you read the IPv6 Scoped > Address Architecture > > >document, if you haven't already, as it contains > information regarding > > >the expected configuration and forwarding behaviour of > IPv6 routers. > > >It also defines the concept of an IPv6 site, which is > important to understanding > > >the questions that I am about to raise. > > > > > >In IPv6, there is a concept of site-local addressing that > is quite different > > >from the concept of "net 10" addresses in IPv4. Sites are > administratively > > >defined entities that must be "convex" (i.e. the best > route between two nodes > > >in the site must, at all scopes, fall completely within > the site). Sites boundaries > > >run through routers, so a single router (called a site > border router (SBR)) can > > >have interfaces in more than one site. And, IPv6 > site-local addresses can be > > >used for site-constrained communication, even when a site > is globally > > >connected and global addresses are available. > > > > > >Because all site-local addresses use the same well-known > site-local prefix, the > > >only way to tell that a particular site-local address > belongs to a particular > > >site is to know which site originated the address. SBRs will need > > >to enforce site boundaries, not mixing site-local routing > information, and not > > >forwarding packets outside of a given site. To do this, > it is expected that > > >SBRs will need to maintain multiple "conceptual routing > tables", including one > > >site-local routing table for each attached site, and one > global routing table. > > > > > >Unfortunately, I can't find any indication that these > concepts have been reflected > > >in the current IPv6 routing protocols. None of our IPv6 > routing protocol documents > > >deal with site-local boundaries or SBR behaviour explicitly. > > > > > >There are currently four standards for how IPv6 routes > will be handled in BGP, OSPF, > > >IS-IS and RIP. I will refer to these documents as > BGP-IPv6, OSPF-IPv6 and IS-IS-IPv6, > > >and RIP-IPv6 respectively: > > > > > >Use of BGP-4 Multiprotocol Extensions for IPv6 > Inter-Domain Routing: > > >http://www.ietf.org/rfc/rfc2545.txt > > > > > >OSPF for IPv6 > > >http://www.ietf.org/rfc/rfc2740.txt > > > > > >Routing IPv6 with IS-IS: > > >http://www.ietf.org/internet-drafts/draft-ietf-isis-ipv6-02.txt > > > > > >RIPng for IPv6 > > >http://www.ietf.org/rfc/rfc2080.txt > > > > > >So here are my actual questions: > > > > > >(1) Are the statements regarding the routing system in the > IPv6 Scoped Addressing Architecture > > >draft valid? Will they work in real life? Please read > it, and comment to the IPv6 WG if you think that > > >there are any issues with what it says. > > > > > >(2) BGP-IPv6: > > > > > >BGP-IPv6 states: "As this document makes no assumption on > the characteristics of a particular > > >routing realm where BGP-4 is used, it makes no distinction > between global and site-local addresses > > >and refers to both as "global" or "non-link-local"." > > > > > >Would it ever be reasonable for BGP to propagate > site-local routing information? Why, under > > >what circumstances? Would it be reasonable to assume that > an Inter-Domain Routing protocol > > >shouldn't propagate site-local information at all? > > > > > >If BGP should be capable of propagating site-local > information, will it be possible, using existing > > >BGP standards for a BGP SBR router with four interfaces > (A, B, C & D), in two sites (A & B in S1, > > >and C & D in S2) to maintain two separate sets of > information for prefix FEC0::/10, one that applies > > >to S1 (interfaces A & B) and one that applies to S2 > (interfaces C & D), and to propagate that information > > >accordingly? Is this really just an issue of configuring > the router properly, as BGP-IPv6 implies? > > > > > >(3) OSPF-IPV6: > > > > > >In this specification, no distinction is made between > site-local and global addresses. Unlike the > > >previous specification (BGP-IPv6), this assumption is not > stated up-front. Instead, everywhere in > > >the draft where either site-local or global addresses are > mentioned they are both mentioned (i.e. > > >"site-local or global IPv6 addresses"). > > > > > >Again this specification makes no provision for separate > sets of site local information. There is > > >also no mention of a boundary for site-local route > propagation, and no mention of multiple conceptual > > >sets of site-local routing information. Would it make > sense to tie the concept of an IPv6 site to > > >one of the existing propagation boundaries in OSPF, such > as an OSPF area? Or to assume that > > >an OSPF AS will always be completely contained within one > site -- which is what the current draft > > >seems to assume? > > > > > >(4) IS-IS-IPv6: > > > > > >IS-IS-IPv6 makes no mention of site-local or scoped > addressing at all. Is this appropriate? How will IS-IS > > >SBRs know not to propagate site-local routing information > between two attached sites? I don't yet > > >know enough about IS-IS to understand how site-local > routing information would best be handled > > >in IS-IS. Any thoughts? > > > > > >(5) RIP-IPv6: > > > > > >The RIP-IPv6 document explicitly states that there is a > single IPv6 routing table, and it makes no > > >mention of sites. I think it would be fine to constrain > RIP to operating within a single IPv6 > > >site, but that should be explicitly stated somewhere. > > > > > >(6) Will the MIBs for any of these routing tables be > capable of representing multiple independent, > > >possibly overlapping sets of site-local routing > information? I looked them over quickly, and it > > >wasn't immediately obvious to me how they could do this. > > > > > >(7) Do you think that there would be some utility to > defining the actual routing architecture (as > > >opposed to just the addressing architecture) for IPv6? If > so, what would be the best way to do > > >that? > > > > > >(8) Should we mention link-local addresses anywhere in > these specifications? We certainly would > > >not want to propagate routing information for link-local addresses. > > > > > >If there is some work that needs to be done here, I am > very happy to provide some IPv6 expertise > > >to that effort. > > > > > >Margaret > > > > > > > > > > > > > -------------------------------------------------------------------- > > IETF IPng Working Group Mailing List > > IPng Home Page: http://playground.sun.com/ipng > > FTP archive: ftp://playground.sun.com/pub/ipng > > Direct all administrative requests to [EMAIL PROTECTED] > > -------------------------------------------------------------------- > -------------------------------------------------------------------- > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > -------------------------------------------------------------------- > -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
