Subject: IPv6 Scoped Addresses and Routing Protocols

From: Margaret Wasserman <[email-masked]>
Date: Fri, 24 May 2002 12:17:04 -0400

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

_______________________________________________
routing-discussion mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/routing-discussion

---

From: Jeff Parker <[email-masked]>
Date: Fri, 24 May 2002 21:29:52 -0400

At 12:17 PM -0400 5/24/02, Margaret Wasserman wrote:
>addressing and our current IPv6 routing protocol specifications
>...
>(4) IS-IS-IPv6:
>

Margaret -
	I don't know anymore about site-local than what I've read 
above, but perhaps I can help with how you might use ISIS.
	ISIS is used today is as an interior routing protocol.  The 
boarder routers run ISIS on the 'inside' ('in site', in your 
terminology?) and use BGP to peer with the rest of the world.   In 
this scheme, BGP could filter out the site addresses when 
communicating with the outside.
	Neither IS-IS nor OSPF scales past a certain size, somewhere 
in the 100 to 1000 router range.  But both have the notion of an 
area, and it should be possible to connect multiple sites (areas) 
together using the ISIS Level 2 notion, or OSPFs Area 0.  There would 
have to be provision to filter site address announcements from 
leaking into Level 2 (Area 0) if you tied multiple sites together 
with the IGP.

- jeff parker

---

From: Francis Dupont <[email-masked]>
Date: Sat, 25 May 2002 18:48:50 +0200

In your previous mail you wrote:

   Sites boundaries run through routers, so a single router (called a
   site border router (SBR)) can have interfaces in more than one site.

=> a SBR is a nightmare... It needs a scoped routing table in the kernel
and separate IGPs for each site. I don't want to imagine how we can
support site reconfiguration on a running SBR.

   SBRs will need to enforce site boundaries

=> this part is easy: a very small number of lines of code in the forwarding
routine.

   not mixing site-local routing information

=> this is called a scoped routing table (zoned should be a better term
but unfortunately it is too late to fix RFC 2553 or even 2553bis...)

   and not forwarding packets outside of a given site.

=> this is "enforcing site boundaries", isn't this?

   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.
   
=> in fact usually a zone ID is added to addresses for the same result.

   None of our IPv6 routing protocol documents deal with site-local
   boundaries or SBR behaviour explicitly.
   
=> one can expect a site is a routing domain and an internal gateway protocol
should be run in the site. As routing protocols carry raw addresses (i.e.,
in a case of a scoped address, the address without its zone indication)
this is the only reasonable way.

=> two remarks:
 - usually BGP is used as an inter-domain routing protocol so is supposed
   to manage routes for global prefixes.
 - the issue is partially addressed in the section 2 (partially == not
   fully solved).
In fact, the multi-protocol feature of BGP 4+ provides some ways to carry
extra information in a NLRI. For instance, we can reuse a VPN-like
(cf RFC 2547) way to manage site-local addresses with site identifiers.

   RIPng for IPv6
   
=> its poor scalability makes RIPng a bad candidate for multi-sited stuff.

   (2) BGP-IPv6:
   
   Would it ever be reasonable for BGP to propagate site-local routing
   information?

=> I've already answered this should be possible in the hard (== multi-sited)
case. Personally I believe site-local addresses should be reserved to the
not-connected organizations: the "non-link-local" argument applies.
(PS: here not-connected is at the network layer)

   Why, under what circumstances?

=> very large not-connected organizations?

   Would it be reasonable to assume that an Inter-Domain Routing protocol
   shouldn't propagate site-local information at all?
   
=> I'd like to say site-local information should not cross site boundaries.

   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?

=> I am not an expert of RFC 2547 but site-local addressing fulfills
the 1.3 requirement about overlapping address spaces so a similar
tagging of site-local addresses (RFC 2547 adds a "Route Distinguisher"
which identifies a VPN, we can use the same concept for identifications
of sites) should work.

   Is this really just an issue of configuring the router properly, as
   BGP-IPv6 implies?

=> not for the multi-sited case because a router is not supposed to run
more than one BGP-IPv6 process. But in other cases I agree with the
suggession of BGP-IPv6 (i.e., I still believe BGP-IPv6 doesn't need
to be updated).

   (3) OSPF-IPV6:
   
=> OSPF-IPv6 has the new (over OSPFv2) property that one is allowed to
run more than one OSPF-IPv6 process per router. So with a dangerous but
possible configuration the multi-sited case can be handled.

   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").
   
=> results are 5 and 80 pages (totally unfair comparison :-)!

   Or to assume that an OSPF AS will always be completely contained
   within one site -- which is what the current draft seems to assume?
   
=> I agree but this is not a limitation because one may run multiple
OSPF-IPv6 processes per router, i.e. put a router in multiple ASs.

   (4) IS-IS-IPv6:
   
   Any thoughts?

=> I believe IS-IS-IPv6 assumes an AS is completely contained in one site
but there is no multiple process capability (my argument is the CLNS
addressing is per node, not per interface. A well-known consequence is
IS-IS can not run as an external gateway protocol). But this applies
to the original IS-IS lightly modified to carry IPv4 addresses (as decribed
in the reference).
   
   (5) RIP-IPv6:
   
   The RIP-IPv6 document explicitly states that there is a single IPv6
   routing table.

=> so RIP-IPv6 has explicitly no provision for the multi-sited case.
   
   (6) Will the MIBs for any of these routing tables be capable of
   representing multiple independent, possibly overlapping sets of
   site-local routing information?

=> in the case of BGP 4 (the only one I know because MIBs are the reason
the RFC 2553 is not yet a Draft Standard :-) all references in
draft-ietf-idr-bgp4-mibv2-02.txt point to RFC 3291 which defines ipv6z
addresses: "A non-global IPv6 address including a zone index as
defined by the InetAddressIPv6z textual convention"!

   (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?

=> no because we shan't easily get a consensus (there are two strong
opposite opinions about the use of sites).

   (8) Should we mention link-local addresses anywhere in these specifications?

=> not in specifications when they are enough clear but in applicability
documents.

   We certainly would not want to propagate routing information for
   link-local addresses.
   
=> perhaps this is the opportunity to solve a very old issue raised by
Jean-Luc Richier many years ago: a topology discovery tool using SNMP
to dump routing tables can not go beyond directly connected routers
because it gets useless link-local addresses of next routers...

Thanks

[email-masked]