draft-ietf-ipngwg-scoped-routing-01.txt   draft-ietf-ipngwg-scoped-routing-02.txt 
IPNGWG Working Group B. Haberman
INTERNET DRAFT Brian Haberman Internet Draft Nortel Networks
April 1999 IBM draft-ietf-ipngwg-scoped-routing-02.txt
November 1999
Routing of Scoped Addresses Routing of Scoped Addresses
in the Internet Protocol Version 6 (IPv6) in the Internet Protocol Version 6 (IPv6)
<draft-ietf-ipngwg-scoped-routing-01.txt> Status of this Memo
Status of This Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC 2026.
Internet-Drafts are working documents of the Internet Engineering This document is an Internet-Draft and is in full conformance with all
Task Force (IETF), its areas, and its working provisions of Section 10 of RFC2026.
groups. Note that other groups may also distribute working documents
as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six Internet-Drafts are working documents of the Internet Engineering Task
months, and may be updated, replaced, or obsoleted by other documents Force (IETF), its areas, and its working groups. Note that other groups
at any time. It is not appropriate to use Internet-Drafts as may also distribute working documents as Internet-Drafts. Internet-
reference material, or to cite them other than as a ``working draft'' Drafts are draft documents valid for a maximum of six months and may be
or ``work in progress.'' updated, replaced, or obsoleted by other documents at any time. It is
inappropriate to use Internet- Drafts as reference material or to cite
them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
Abstract Abstract
This document outlines a mechanism for generating routing tables that This document outlines a mechanism for generating forwarding tables
include scoped IPv6 addresses. It defines a set of that include scoped IPv6 addresses. It defines a set of rules for
rules for routers to implement in order to forward scoped unicast and routers to implement in order to forward packets addressed to scoped
multicast addresses regardless of the routing protocol. It should be unicast or multicast addresses regardless of the routing protocol.
noted that these rules will apply to all scoped addresses. These rules apply to all scoped addresses.
Contents
1. Introduction 1
2. Assumptions and Definitions 1
3. Single Site Routing 1
4. Site Boundary Unicast Routing 2
4.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 2
4.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 4
5. Scoped Multicast Routing 5
5.1. Routing Protocols . . . . . . . . . . . . . . . . . . . . 5
5.2. Packet Forwarding . . . . . . . . . . . . . . . . . . . . 5
6. Protocol Impact 6
1. Introduction 1.
Introduction
This document defines a set of rules for the generation of forwarding This document defines a set of rules for the generation of forwarding
tables that contain scoped addresses. This document describes the table entries for scoped addresses. These rules will describe the
handling of scoped addresses for both single site and handling of scoped addresses for both single site and site boundary
site boundary routers. Ideally, these concepts should be included in routers. These rules apply to all routing protocols that support IPv6
followup drafts of IPv6 routing protocols. addresses.
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
this document are to be interpreted as described in [RFC 2119]. document are to be interpreted as described in [RFC 2119].
2. Assumptions and Definitions 2.
Assumptions and Definitions
This document makes several assumptions concerning sites : This document makes several assumptions concerning sites :
- Site boundaries cut through nodes - Links belong to at most one site
- Interfaces belong to the site of the attached link, if any
Haberman 1
- Nodes are a part of all sites which their interfaces belong to,
and no other sites
- Site boundaries are identical for unicast and multicast traffic - Site boundaries are identical for unicast and multicast traffic
- A single interface can be in at most one site
- A single interface can only be in one site
- Each interface participating in a site has a site identifier - Each interface participating in a site has a site identifier
- In the absence of explicit configuration, all site identifiers on - In the absence of explicit configuration, all site identifiers on
a node default to the same value a node default to the same value
A single site router is defined as a router configured with the same A single site router is defined as a router configured with the same
site identifier on all interfaces. A site boundary router is defined site identifier on all interfaces. A site boundary router is defined
as a router that has at least 2 distinct site identifiers configured. as a router that has at least 2 distinct site identifiers.
This could include a router connected to 2 distinct sites or a router
connected to 1 site and a separate global network (Figure ??).
3. Single Site Routing
In a single site router, a routing protocol
can advertise and route all addresses and prefixes on all interfaces.
This configuration does not require any special handling for site
local addresses. The reception and transmission of site local
addresses is handled in the same manner as globally scoped addresses.
This applies to both unicast and multicast routing protocols.
* * * *
* * * *
* Site ID = X * * Site ID = X *
* * * *
* * +-*---|-------|---*-+
+-*---|--------|---*-+
| * i/f 1 i/f 2 * | | * i/f 1 i/f 2 * |
| **************** | | *************** |
| | | |
| | | |
| Router | | Router |
***************** ******************* ******************* *******************
| * * | | * * |
Site ID = Y - i/f 3 * * i/f 4 - Site ID = Default Site ID = Y - i/f 3 * * i/f 4 - Site ID = Default
| * * | | * * |
***************** ******************* ******************* *******************
+--------------------+ +-------------------+
Figure 1: Multi-Sited Router Figure 1: Multi-Sited Router
4. Site Boundary Unicast Routing 3.
Single Site Routing
With respect to site boundaries, In a single site router, a routing protocol can advertise and route all
routers must consider which interfaces a packet can be transmitted on addresses and prefixes, except the link-local prefixes, on all
as well as control the propagation of routing information specific to interfaces. This configuration does not require any special handling
the site. This includes controlling which prefixes can be advertised for site local addresses. The reception and transmission of site local
on an interface. addresses is handled in the same manner as globally scoped addresses.
This applies to both unicast and multicast routing protocols.
4.1. Routing Protocols 4.
Site Boundary Unicast Routing
With respect to site boundaries, routers must consider which interfaces
a packet can be transmitted on as well as control the propagation of
routing information specific to the site. This includes controlling
which prefixes can be advertised on an interface.
4.1 Routing Protocols
When a routing protocol determines that it is a site boundary router, When a routing protocol determines that it is a site boundary router,
it must perform additional work in order to protect inter site it must perform additional work in order to protect inter site
integrity and still maintain intra site connectivity. integrity and still maintain intra site connectivity.
In order to maintain connectivity, the routing protocol must be Haberman 2
able to create forwarding information for the global prefixes as well In order to maintain connectivity, the routing protocol must be able to
as for all of the site prefixes for each of its attached sites. The create forwarding information for the global prefixes as well as for
most straight forward way of doing this is to create up to (n + 1) all of the site prefixes for each of its attached sites. The most
routing tables; one for the global prefixes, if any, and one for each straightforward way of doing this is to create up to (n+1) forwarding
of the (n) sites. tables; one for the global prefixes, if any, and one for each of the
(n) sites.
To protect inter site integrity, routers must be selective in the To protect inter site integrity; routers must be selective in the
forwarding information that is shared with neighboring routers. forwarding information that is shared with neighboring routers.
Routing protocols routinely transmit their routing information to Routing protocols routinely transmit their routing information to its
neighboring routers. When a router is transmitting this routing neighboring routers. When a router is transmitting this routing
information, it must not include any information about sites other information, it must not include any information about sites other than
than the site defined on the interface used to reach a neighbor. the site defined on the interface used to reach a neighbor.
* *
* *
* Site ID = X *
* *
* *
+-*---|--------|---*-+
| * i/f 1 i/f 2 * |
| **************** |
| |
| |
| Router |
***************** *******************
| * * |
Site ID = Y - i/f 3 * * i/f 4 - Site ID = Default
| * * |
***************** *******************
+--------------------+
i/f 1 : global prefix = 3FFE:20::/64
site prefix = FEC0:0:0:N/64
i/f 2 : no global prefix
site prefix = FEC0:0:0:K/64
i/f 3 : global prefix = 3FFE:40::/64
site prefix = FEC0:0:0:M/64
i/f 4 : global prefix = 3FFE:80::/64
no site prefix
Figure 2: Routing Information Exchange
As an example, the router in Figure ?? must advertise routing As an example, the router in Figure 1 must advertise routing
information on four interfaces. The information advertised is as information on four interfaces. The information advertised is as
follows : follows :
- Interface 1 - Interface 1
- All global prefixes
* All global prefixes (3FFE:20::/64, 3FFE:40::/64, and - All site prefixes learned from Interfaces 1 and 2
3FFE:80::/64)
* Site prefix FEC0:0:0:N/64
* Site prefix FEC0:0:0:K/64
- Interface 2 - Interface 2
- All global prefixes
* All global prefixes (3FFE:20::/64, 3FFE:40::/64, and - All site prefixes learned from Interfaces 1 and 2
3FFE:80::/64)
* Site prefix FEC0:0:0:N/64
* Site prefix FEC0:0:0:K/64
- Interface 3 - Interface 3
- All global prefixes
* All global prefixes (3FFE:20::/64, 3FFE:40::/64, and - All site prefixes learned from Interface 3
3FFE:80::/64)
* Site prefix FEC0:0:0:M/64
- Interface 4 - Interface 4
- All global prefixes
* All global prefixes (3FFE:20::/64, 3FFE:40::/64, and - No site prefixes
3FFE:80::/64)
By imposing advertisement rules, site integrity is maintained by By imposing advertisement rules, site integrity is maintained by
keeping all site routing information contained within the site. keeping all site routing information contained within the site.
4.2. Packet Forwarding 4.2 Packet Forwarding
In addition to the extra cost of generating additional In addition to the extra cost of generating additional forwarding
forwarding information for each site, site boundary routers must also information for each site, site boundary routers must also do some
do some additional checking when forwarding packets that contain site additional checking when forwarding packets that contain site local
local addresses. addresses.
If a packet being forwarded contains a If a packet being forwarded contains a site local destination address,
site local destination address, regardless of the scope of the source regardless of the scope of the source address, the router must perform
address, the router must perform the following : the following:
- Lookup incoming interface's site identifier - Lookup incoming interface's site identifier
- Perform route lookup for destination address in arrival - Perform route lookup for destination address in arrival
interfaces site scoped routing table interface's site scoped routing table
If a packet being forwarded contains a site local source If a packet being forwarded contains a site local source address and a
address and a globally scoped destination address, the following must global scoped destination address, the following must be performed:
be performed :
- Lookup outgoing interface's site identifier - Lookup outgoing interface's site identifier
- Compare inbound and outbound interfaces' site identifiers - Compare inbound and outbound interfaces' site identifiers
If the site identifiers match, the If the site identifiers match, the packet can be forwarded. If they do
packet can be forwarded. If they do not match, an ICMPv6 destination not match, an ICMPv6 destination unreachable message must be sent to
unreachable message must be sent to the sender with a new code value,
code = 5 (Scope Mismatch).
This ICMPv6 message will indicate that the destination address is not
reachable with the specified source address.
5. Scoped Multicast Routing
With IPv6 multicast, there are multiple scopes Haberman 3
supported. Multicast routers must be able to control the propagation the sender with a code value, code = 2 (beyond scope of source
of scoped packets based on administratively configured boundaries. address).
5.1. Routing Protocols 5.
Scoped Multicast Routing
Multicast routing protocols must follow the same rules as the unicast With IPv6 multicast, there are multiple scopes supported. Multicast
protocols. They will be required to maintain information about routers must be able to control the propagation of scoped packets based
global prefixes as well as information about all scope boundaries on administratively configured boundaries.
that pass through the router. Multicast protocols that rely on
underlying unicast protocols (i.e. PIM) will not suffer as much of a
performance impact since the unicast protocol will handle the
forwarding table generation. They must be able to handle the
additional scope boundaries used in multicast addresses. Multicast
protocols that generate and
maintain their own routing tables will have to perform the additional
route calculations for scope. All multicast protocols will be forced
to handle 14 additional scoping identifiers above the site
identifiers supported in IPv6 unicast addresses.
5.2. Packet Forwarding 5.1 Routing Protocols
The forwarding rules for multicast can be described by the following Multicast routing protocols must follow the same rules as the unicast
combinations : protocols. They will be required to maintain information about global
prefixes as well as information about all scope boundaries that exist
on the router.
- Global multicast destination address / Global unicast source Multicast protocols that rely on underlying unicast protocols for route
address exchange (i.e. PIM, MOSPF) will not suffer as much of a performance
impact since the unicast protocol will handle the forwarding table
generation. They must be able to handle the additional scope
boundaries used in multicast addresses.
- Global multicast destination address / Site local unicast source Multicast protocols that generate and maintain their own routing tables
address will have to perform the additional route calculations for scope
boundaries. All multicast protocols will be forced to handle fourteen
additional scooping identifiers above the site identifiers supported in
IPv6 unicast addresses.
- Scoped multicast destination address / Global unicast source 5.2 Packet Forwarding
address
- Scoped multicast destination address / Site local unicast source The following combinations describe the forwarding rules for multicast:
address
The first combination requires no special - Global multicast destination / Global unicast source
processing over what is currently in place for global IPv6 multicast. - Global multicast destination / Site local unicast source
Combinations 2,3, and 4 should result in the router performing the - Scoped multicast destination / Global unicast source
same identifiers check as outlined for site local unicast addresses. - Scoped multicast destination / Site local unicast source
Since IPv6 supports fifteen unique multicast scopes, it is assumed
that scopes 0x1 through 0x4 are strictly less than
the unicast site scope, scope 0x5 (site) is equal to the unicast site
scope, scopes 0x6 through 0xd are strictly greater than the unicast
site scope and strictly less than the unicast global scope, and scope
0xe is equal to the unicast global scope.
6. Protocol Impact The first combination requires no special processing over what is
currently in place for global IPv6 multicast. The remaining
combinations should result in the router performing the same
identifiers check as outlined for the site local unicast addresses.
Since IPv6 multicast supports fifteen unique multicast scopes, it is
assumed that scopes 0x1 through 0x4 are strictly less than the unicast
site scope, scope 0x5 (site) is equal to the unicast site scope, scopes
0x6 through 0xd are strictly greater than the unicast site scope and
strictly less than the unicast global scope, and scope 0xe is equal to
the unicast global scope.
The performance impact on routing protocols is obvious. 6.
Routers implementing scoped address support will be forced to perform Protocol Impact
an additional check in the main forwarding path to
determine if the source address is scoped. This will add overhead to
the processing of every packet flowing through the router. In
addition, there will be some storage overhead for
the scope identifiers. If scoped addresses are going to be realized,
this performance impact may be acceptable.
References The performance impact on routing protocols is obvious. Routers
implementing scoped address support will be forced to perform an
additional check in the main forwarding path to determine if the source
address is a site-local address. This will add overhead to the
processing of every packet flowing through the router. In addition,
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate Haberman 4
Requirement Levels", RFC 2119, BCP14, March 1997. there will be some storage overhead for the scope identifiers. If
scoped addresses are going to be realized, this performance impact may
be acceptable.
7.
Security Considerations Security Considerations
This document specifies a set of guidelines that allow routers to This document specifies a set of guidelines that allow routers to
prevent site prevent site-specific information from leaking out of each site. If
specific information from leaking out of each site. If site boundary site boundary routers allow site routing information to be forwarded
routers allow site routing information to be forwarded outside of the outside of the site, the integrity of the site could be compromised.
site, the integrity of the site could be compromised.
8.
References
[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
Requirement Levels", RFC 2119, BCP14, March 1999.
Acknowledgements Acknowledgements
I would like to thank Thomas Narten, Steve Deering, and Erik Nordmark The author would like to thank Thomas Narten, Steve Deering, Erik
for their comments and reviews of this document. Nordmark, and Matt Crawford for their comments and reviews of this
document.
Haberman 5
Author's Address Author's Address
Brian Haberman Brian Haberman
IBM Corporation Nortel Networks
800 Park Office Drive 4309 Emperor Blvd.
Research Triangle Park, NC 27709 Suite 200
USA Durham, NC 27703
+1-919-254-2673 1-919-992-4439
haberman@raleigh.ibm.com Email : haberman@nortelnetworks.com
Haberman 6
 End of changes. 56 change blocks. 
226 lines changed or deleted 156 lines changed or added

This html diff was produced by rfcdiff 1.33. The latest version is available from http://tools.ietf.org/tools/rfcdiff/