Brian Wouldn't the Zone ID for a given site on all routers in that same site have to be same for this to work?
-vlad Brian Haberman wrote: > 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-arch-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] > -------------------------------------------------------------------- > > -- +++++++++++++++++++++++++++++++++++++++++++++++++++++++++++++ Vladislav Yasevich Tru64 UNIX - IPv6 Project Lead Hewlett Packard Tel: (603) 884-1079 Nashua, NH 03062 ZKO3-3/T07 -------------------------------------------------------------------- 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] --------------------------------------------------------------------
