Vlad,
Not at all. The zone IDs are not included in the route
advertisement messages. That simplifies things a great deal since
you don't have to coordinate the zone IDs across a site. The zone
IDs only have meaning on the node in which they are used.
Brian
Vladislav Yasevich wrote:
>
> 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]
--------------------------------------------------------------------
