INTERNET DRAFT                                            Brian        IPNGWG Working Group                                         B. Haberman
April
        Internet Draft                                           Nortel Networks
        draft-ietf-ipngwg-scoped-routing-02.txt
        November 1999                                                           IBM
                             Routing of Scoped Addresses
                      in the Internet Protocol Version 6 (IPv6)

               <draft-ietf-ipngwg-scoped-routing-01.txt>

     Status of This this Memo

        This document is an Internet-Draft and is in full conformance with all
        provisions of Section 10 of RFC 2026. RFC2026.

        Internet-Drafts are working documents of the Internet Engineering Task
        Force (IETF), its areas, and its working groups. Note that other groups
        may also distribute working documents as Internet-Drafts.

   Internet-Drafts Internet-
        Drafts are draft documents valid for a maximum of six
   months, months and may be
        updated, replaced, or obsoleted by other documents at any time. It is not appropriate
        inappropriate to use Internet-Drafts Internet- Drafts as reference material, material or to cite
        them other than as a ``working draft''
   or ``work "work in progress.'' progress."

        The list of current Internet-Drafts can be accessed at
        http://www.ietf.org/ietf/1id-abstracts.txt.

        The list of Internet-Draft Shadow Directories can be accessed at
        http://www.ietf.org/shadow.html.

     Abstract

        This document outlines a mechanism for generating routing forwarding tables
        that include scoped IPv6 addresses.  It defines a set of rules for
        routers to implement in order to forward packets addressed to scoped
        unicast and or multicast addresses regardless of the routing protocol.  It should be
   noted that these
        These rules will 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

        This document defines a set of rules for the generation of forwarding
   tables that contain
        table entries for scoped addresses.  This document describes  These rules will describe the
        handling of scoped addresses for both single site and site boundary
        routers.  Ideally, these concepts should be included in
   followup drafts of IPv6  These rules apply to all routing protocols. protocols that support IPv6
        addresses.

        The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
        "SHOULD", "SHOULD NOT", "RECOMMENDED",  "MAY", and "OPTIONAL" in this
        document are to be interpreted as described in [RFC 2119].

     2.
       Assumptions and Definitions

        This document makes several assumptions concerning sites : 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
          -  A single interface can only be in at most one site
          -  Each interface participating in a site has a site identifier
          -  In the absence of explicit configuration, all site identifiers on
             a node default to the same value

        A single site router is defined as a router configured with the same
        site identifier on all interfaces.  A site boundary router is defined
        as a router that has at least 2 distinct site identifiers configured.
   This could include a router connected to 2 distinct sites or a router
   connected to identifiers.

                                  *               *
                                  *               *
                                  *  Site ID = X  *
                                  *               *
                                +-*---|-------|---*-+
                                | * i/f 1 site and a separate global network (Figure ??).   i/f 2 * |
                                |  ***************  |
                                |                   |
                                |                   |
                                |      Router       |
                    *******************       *******************
                                |      *     *      |
                    Site ID = Y -i/f 3 *     * i/f 4- Site ID = Default
                                |      *     *      |
                    *******************       *******************
                                +-------------------+

                               Figure 1: Multi-Sited Router

     3.
       Single Site Routing

        In a single site router, a routing protocol can advertise and route all
        addresses and prefixes prefixes, except the link-local 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   *
                           *                *
                           *                *
                         +-*---|--------|---*-+
                         | * i/f 1    i/f 2 * |
                         |  ****************  |
                         |                    |
                         |                    |
                         |       Router       |
                *****************      *******************
                         |       *    *       |
           Site ID = Y   - i/f 3 *    * i/f 4 -  Site ID = Default
                         |       *    *       |
                *****************      *******************
                         +--------------------+

                      Figure 1: Multi-Sited Router

     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.

       4.1  Routing Protocols

        When a routing protocol determines that it is a site boundary router,
        it must perform additional work in order to protect inter site
        integrity and still maintain intra site connectivity.

     Haberman                                                             2
        In order to maintain connectivity, the routing protocol must be able to
        create forwarding information for the global prefixes as well as for
        all of the site prefixes for each of its attached sites.  The most straight forward
        straightforward way of doing this is to create up to (n + 1)
   routing (n+1) forwarding
        tables; one for the global prefixes, if any, and one for each of the
        (n) sites.

        To protect inter site integrity, integrity; routers must be selective in the
        forwarding information that is shared with neighboring routers.
        Routing protocols routinely transmit their routing information to its
        neighboring routers.  When a router is transmitting this routing
        information, it must not include any information about sites other than
        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 ?? 1 must advertise routing
        information on four interfaces.  The information advertised is as
   follows :
        follows:

          -  Interface 1

        *
               -  All global prefixes (3FFE:20::/64, 3FFE:40::/64,
               -  All site prefixes learned from Interfaces 1 and
           3FFE:80::/64)

        *  Site prefix FEC0:0:0:N/64

        *  Site prefix FEC0:0:0:K/64 2
          -  Interface 2

        *
               -  All global prefixes (3FFE:20::/64, 3FFE:40::/64,
               -  All site prefixes learned from Interfaces 1 and
           3FFE:80::/64)

        *  Site prefix FEC0:0:0:N/64

        *  Site prefix FEC0:0:0:K/64 2
          -  Interface 3

        *
               -  All global prefixes (3FFE:20::/64, 3FFE:40::/64, and
           3FFE:80::/64)

        *  Site prefix FEC0:0:0:M/64
               -  All site prefixes learned from Interface 3
          -  Interface 4

        *
               -  All global prefixes (3FFE:20::/64, 3FFE:40::/64, and
           3FFE:80::/64)
               -  No site prefixes

        By imposing advertisement rules, site integrity is maintained by
        keeping all site routing information contained within the site.

4.2.

       4.2  Packet Forwarding

        In addition to the extra cost of generating additional forwarding
        information for each site, site boundary routers must also do some
        additional checking when forwarding packets that contain site local
        addresses.

        If a packet being forwarded contains a site local destination address,
        regardless of the scope of the source address, the router must perform
        the following : following:

          -  Lookup incoming interface's site identifier
          -  Perform route lookup for destination address in arrival
       interfaces
             interface's site scoped routing table

        If a packet being forwarded contains a site local source address and a globally
        global scoped destination address, the following must be performed : performed:

          -  Lookup outgoing interface's site identifier
          -  Compare inbound and outbound interfaces' site identifiers

        If the site identifiers match, the packet can be forwarded.  If they do
        not match, an ICMPv6 destination unreachable message must be sent to

     Haberman                                                             3
        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 2 (beyond scope of source address.
        address).

     5.
       Scoped Multicast Routing

        With IPv6 multicast, there are multiple scopes supported.  Multicast
        routers must be able to control the propagation of scoped packets based
        on administratively configured boundaries.

5.1.

       5.1  Routing Protocols

        Multicast routing protocols must follow the same rules as the unicast
        protocols.  They will be required to maintain information about global
        prefixes as well as information about all scope boundaries that pass through exist
        on the router.

        Multicast protocols that rely on underlying unicast protocols for route
        exchange (i.e.  PIM) 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.

        Multicast protocols that generate and maintain their own routing tables
        will have to perform the additional route calculations for scope. scope
        boundaries.  All multicast protocols will be forced to handle 14 fourteen
        additional scoping scooping identifiers above the site identifiers supported in
        IPv6 unicast addresses.

5.2.

       5.2  Packet Forwarding

        The following combinations describe the forwarding rules for multicast can be described by the following
   combinations : multicast:

          -  Global multicast destination address / Global unicast source
       address
          -  Global multicast destination address / Site local unicast source
       address
          -  Scoped multicast destination address / Global unicast source
       address
          -  Scoped multicast destination address / Site local unicast source
       address

        The first combination requires no special processing over what is
        currently in place for global IPv6 multicast.
   Combinations 2,3, and 4  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.

     6.
       Protocol Impact

        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 scoped. a site-local address.  This will add overhead to the
        processing of every packet flowing through the router.  In addition,

     Haberman                                                             4
        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

[RFC 2119] S. Bradner, "Key words for use in RFCs to Indicate
           Requirement Levels", RFC 2119, BCP14, March 1997.

     7.
       Security Considerations

        This document specifies a set of guidelines that allow routers to
        prevent site
   specific site-specific information from leaking out of each site.  If
        site boundary routers allow site routing information to be forwarded
        outside of the 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

   I

     The author would like to thank Thomas Narten, Steve Deering, and Erik Nordmark
     Nordmark, and Matt Crawford for their comments and reviews of this
     document.

     Haberman                                                             5
     Author's Address

        Brian Haberman
        IBM Corporation
        800 Park Office Drive
        Research Triangle Park,
        Nortel Networks
        4309 Emperor Blvd.
        Suite 200
        Durham, NC 27709
        USA
        +1-919-254-2673
        haberman@raleigh.ibm.com  27703
        1-919-992-4439
        Email : haberman@nortelnetworks.com

     Haberman                                                             6