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]
--------------------------------------------------------------------

Reply via email to