[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05                                             
INTERNET-DRAFT                           Erik Nordmark, Sun Microsystems
August 7, 1998


                    Site prefixes in Neighbor Discovery

                 <draft-ietf-ipngwg-site-prefixes-02.txt>


Status of this Memo

   This document is an Internet-Draft.  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 are draft documents valid for a maximum of six months
   and may be 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.''

   To learn the current status of any Internet-Draft, please check the
   ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
   Directories on ds.internic.net (US East Coast), nic.nordu.net
   (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
   Rim).

   Distribution of this memo is unlimited.

   This Internet Draft expires February 7, 1999.



Abstract

   This document specifies extensions to IPv6 Neighbor Discovery to
   carry site prefixes.  The site prefixes are used to reduce the effect
   of site renumbering by ensuring that the communication inside a site
   uses site-local addresses.

   This protocol requires that all IPv6 implementations, even those that
   do not implement this protocol, ignore all site-local addresses that
   they retrieve from the DNS.








draft-ietf-ipngwg-site-prefixes-02.txt                          [Page 1]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


Contents

   Status of this Memo..........................................    1

   1.  INTRODUCTION AND MOTIVATION..............................    3

   2.  TERMINOLOGY..............................................    4
      2.1.  What is a site?.....................................    4
      2.2.  Requirements........................................    4

   3.  OVERVIEW.................................................    5
      3.1.  Protocol Overview...................................    5
      3.2.  Mobile IP implications..............................    6
      3.3.  Assumptions.........................................    9

   4.  UPDATED PREFIX OPTION FORMAT.............................    9

   5.  CONCEPTUAL VARIABLES.....................................   11

   6.  SENDING RULES............................................   12

   7.  RECEIVING RULES..........................................   12

   8.  USING THE SITE PREFIXES..................................   13
      8.1.  Host Name Lookups...................................   13
      8.2.  IPv6 Address Lookups................................   14

   9.  MULTIHOMED TO MULTIPLE SITES.............................   15
      9.1.  Detecting site multihoming..........................   16

   10.  SECURITY CONSIDERATIONS.................................   16

   REFERENCES...................................................   17

   AUTHOR'S ADDRESS.............................................   18

   APPENDIX A: CHANGES SINCE PREVIOUS DRAFT.....................   19














draft-ietf-ipngwg-site-prefixes-02.txt                          [Page 2]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


1.  INTRODUCTION AND MOTIVATION

   In order to maintain the aggregation of the global Internet routing
   tables it might be necessary for whole sites to renumber to use
   different prefixes for their global IPv6 addresses.  Such renumbering
   would not directly benefit the renumbered sites but instead be
   necessary for the scaling of the Internet as a whole.

   In order to increase the probability that such renumbering is viewed
   favorably by the sites themselves, which see little or no direct
   benefit, it is critical that both the effort of renumbering is kept
   at a minimum and also that the risk associated with renumbering is as
   small as possible.

   The Stateless address autoconfiguration [ADDRCONF] and support for
   router renumbering [ROUTER-RENUM] make it easier to renumber a site.
   However, these protocols do not by themselves address long-running
   TCP connections or cases where IP addresses have been stored in some
   configuration file.  Thus additional measures are needed to reduce
   the risk of renumbering.

   For many sites it is much more critical to maintain the internal
   communication than the intra-site communication over the Internet.
   Based on that observation this proposal tries to limit the effect of
   a site renumbering one or more of its global prefixes by ensuring
   that intra-site communication can use site-local addresses which
   would not be affected by the site renumbering.  With this proposal it
   is possible to maintain internal long-running TCP connections or
   otherwise store IPv6 addresses for longer time than would have been
   possible without it.

   As specified in [ADDR-TODAY] IP addresses are no longer temporally
   unique.  This implies, among other things, that applications should
   not store IPv6 addresses without a mechanisms for honoring the DNS
   time-to-live and refreshing the IPv6 address.  This protocol is not
   intended to deter from that recommendation but is merely based on the
   observation that the applications today might assume that IPv4
   addresses are temporally unique and it is likely that some
   applications might not be corrected in their behavior as they are
   moved to IPv6.  It would be unfortunate if such application
   "brokenness" would lead sites to view site renumbering as a too risky
   or a too costly operation.

   This document does not address the general issues of renumbering such
   as renumbering a single host or a subnet.  It is targeted at site
   renumbering.  The proposal does not attempt to address how long-
   running TCP connections going outside a site will survive the site
   renumbering.



draft-ietf-ipngwg-site-prefixes-02.txt                          [Page 3]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


   The author would like to acknowledge the contributions the IPNGWG
   working group and in particular Mike O'Dell who pointed out the
   importance of the problem, and Robert Elz who suggested this approach
   to solving the problem.


2.  TERMINOLOGY

   This documents uses the terminology defined in [IPv6] and
   [DISCOVERY].


2.1.  What is a site?

   This document does not attempt to define the concept of a "site", but
   it does place some assumptions on such a definition:

    - A site is an administratively controlled piece of topology that is
      well-connected.  It can be connected using tunnels including the
      special form of tunnels (using routing headers and home address
      options) defined in [MOBILE-IPv6].

    - A link can belong to zero or one site.  This implies that an
      interface can belong to at most one site.

    - A node can have interfaces belonging to different sites.  Such a
      node is said to be at the site boundary.

    - A mobile node [MOBILE-IPv6] which has been assigned one or more
      site-local addresses and moves outside the site which contains its
      home address (its "home site") is considered to have one
      interfaces which is part of the "home site".



2.2.  Requirements

   The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
   SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this












draft-ietf-ipngwg-site-prefixes-02.txt                          [Page 4]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


   document, are to be interpreted as described in [KEYWORDS].

3.  OVERVIEW

   The goal of this extension to Neighbor Discovery is to make
   communication that is local to a single site use the site-local
   addresses instead of the global addresses.  If all communication
   internal to a site uses site-local addresses then the site's global
   addresses can be renumbered without having any affect on the internal
   communication.  Thus the risk associated with site renumbering is
   lowered - applications that store IPv6 addresses and long-running TCP
   connections will, as long as the communication is local to the site,
   continue to operate across the renumbering of the site.

   A few alternative solutions have been explored.  An early proposal
   was to place the site-local addresses in the name service (e.g., the
   DNS) and make sure they are returned first in the list of addresses
   returned to an application (to make it likely that the application
   will use that address).  That proposal has the disadvantage that the
   name service must return different addresses depending on who asks
   the question; if a node inside the site asks for an address it should
   return the site-local address(es) but if a node outside the site asks
   it must not return a site-local address.  This is referred to as the
   two-faced DNS.  While some sites use a two-faced DNS today as part of
   their firewall solution it would be rather unfortunate if each and
   every site had to deploy such a solution.  See [GSE-EVAL] for more
   discussion.

   An earlier version of this proposal took a different approach. The
   name service would only contain global addresses and the routers
   would advertise the global address prefixes assigned to the site
   which the nodes would use to derive site-local addresses
   corresponding to the global addresses returned from the name service.
   That approach had the disadvantage that all nodes in a site would be
   required to respond to their automatically derived site local
   address.  For instance, it was not possible to have certain mobile
   nodes that would only be reachable using a global address.


3.1.  Protocol Overview

   This version of the document takes a middle ground.  The site-local
   addresses, as well as the global addresses, are stored in the DNS
   without requiring a "two-faced" DNS.  All nodes are required to
   ignore any site-local addresses retrieved from the DNS unless they
   can determine that they are in the same site as the peer.  This
   determination is done by verifying that the retrieved AAAA RRset for
   the peer includes one or more global addresses that match the site



draft-ietf-ipngwg-site-prefixes-02.txt                          [Page 5]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


   prefixes advertised by the routers.

   This protocol assumes that the routing infrastructure will be used to
   distribute information about which prefixes belong to the local site.
   This document only specifies how the site prefixes are distributed
   from the routers to the hosts on each link.  However, other protocols
   such as [ROUTER-RENUM] might be extended to carry the site prefixes
   to all routers in a site.  The use of the routing infrastructure to
   carry the site prefixes avoids the "two-faced" issue above - the
   routers know which part of the network is inside the site thus they
   can naturally prevent this information from being distributed outside
   the site.

   The protocol is based on each host maintaining a list of all the
   currently active site prefixes.  The site prefixes are periodically
   advertised in Neighbor Discovery Router Advertisement messages and
   each prefix has an associated lifetime.

   Once a host has a list of the prefixes that apply to its site it uses
   this information to determine if the global addresses returned by the
   name service is part of its site.  If this is the case then the host
   can use any site-local address contained in that AAAA RRset.
   Otherwise any the site-local addresses contained in that RRset must
   be ignored.  A node should prefer the site-local addresses over the
   global addresses e.g. by having the applications try the site-local
   addresses before any of the global addresses.

   The reverse lookup (from an IPv6 address to a host name) is handled
   by mapping a site-local address to the corresponding global
   addresses.  Thus, if the address being looked up is a site-local
   address the host constructs the corresponding global addresses using
   the list of site prefixes and performs a reverse lookup on those
   addresses until a match is found.

   It is expected that both the forward and reverse lookup rules can be
   hidden from applications by implementing them as part of the library
   that handles host name lookups.


3.2.  Mobile IP implications

   A mobile node which moves outside its "home site" must maintain the
   "home site-local addresses" for continued communication with nodes in
   its "home site".  This implies that such a mobile node will have one
   pseudo interface (for the traffic destined to and from its home site)
   which is assigned the home site-local addresses and other interfaces
   which might be part of the visited site.




draft-ietf-ipngwg-site-prefixes-02.txt                          [Page 6]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


   A mobile node might choose to autoconfigure site-local addresses in
   the visited site.  However, such addresses add complexity to the
   mobile node with little or no benefit.  Thus it is recommended that
   mobile nodes only autoconfigure global addresses when moving to links
   outside its home site.

   A mobile node needs to be able to detect when it has moved to a
   different site.  Thus in addition to the regular movement detection
   in [MOBILE-IPv6] it should inspect the site prefixes in the Router
   Advertisement messages to determine when it is outside its home site.

   The remainder of this section specifies the operation of Mobile IP
   when it is outside its home site.

   The mobile node needs to retain any site-local addresses it was
   assigned in its home site, but those site-local addresses should only
   be used when communicating with nodes in its home site.

   The binding updates the binding updates will have to use a global
   address as the care-of-address.

   There are no changes needed to Home Agents.  The home agent needs to
   select a proper source address when sending to a global address as is
   expected of all IPv6 implementations - it should not use a site-local
   source address when sending to a global destination address.

   The only change needed to the Correspondent Nodes using Routing
   Headers to communicate with the mobile node is to include a Home
   Address Option to carry its site-local source address so that the IP
   source address field can contain a global address when sending to the
   global destination.

   The additional use of the Home Address Option from the correspondents
   ensures that all traffic to and from the mobile node will have global
   source addresses.  Thus the site-local addresses will be "hidden" in
   1) encapsulated headers, 2) routing headers, or 3) home address
   option.


   Packets encapsulated to the mobile node will look like this:

      Outer IP header destination address:
                Registered care-of-address.  A global address.

      Outer IP header source address:
                Global address assigned to home agent

      Inner IP header destination address:



draft-ietf-ipngwg-site-prefixes-02.txt                          [Page 7]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


                One of the mobile node's home addresses.  Likely to be a
                site-local address.

      Inner IP header source address:
                Sender of original packet.  Likely to be a site-local
                address.


   Packets sent to the mobile node using routing headers:

      IP header destination address:
                Registered care-of-address.  A global address.

      IP header source address:
                A global address needed to match the scope of the
                destination address.  (This requirement is added by the
                specification.)

      Routing header:
                The mobile node's home address which has been used for
                this communication e.g. which identifies the TCP
                connection.  Likely to be a site-local address.

      Home address option (This requirement is added by the
                specification.):
                The correspondent node's address which has been used for
                this communication e.g. which identifies the TCP
                connection.  Likely to be a site-local address.


   Packets sent from the mobile node to a site-local correspondent
   address:

      IP header destination address:
                The correspondent node's global address.  If this is not
                known then the packet must be instead be encapsulated
                and sent to the (global address of) the home agent which
                can deliver the packet to the site-local destination
                address.

      IP header source address:
                Mobile node's care-of-address.  A global address.

      Routing header:
                The correspondent node's address which has been used for
                this communication e.g. which identifies the TCP
                connection.  Likely to be a site-local address.




draft-ietf-ipngwg-site-prefixes-02.txt                          [Page 8]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


      Home address option:
                The mobile node's address which has been used for this
                communication e.g. which identifies the TCP connection.
                Likely to be a site-local address.


   Packets sent from the mobile node to a global correspondent:

      IP header destination address:
                The correspondent node's global address.

      IP header source address:
                Mobile node's care-of-address.  A global address.

      Home address option:
                The mobile node's address which has been used for this
                communication e.g. which identifies the TCP connection.
                Likely to be a site-local address.



3.3.  Assumptions

   The protocol assumes that the site uses a consistent subnet numbering
   scheme across all its global addresses and its site-local addresses.

   Thus, for every subnet in the site, the 16-bit subnet ID field
   [ADDR-ARCH] for the site-local address must have the same value as
   the Site-Local Aggregator(s) field in the global addresses.


4.  UPDATED PREFIX OPTION FORMAT

   The protocol adds two new fields using previously reserved parts of
   the Prefix Information Option defined in [DISCOVERY].
















draft-ietf-ipngwg-site-prefixes-02.txt                          [Page 9]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


         0                   1                   2                   3
         0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |     Type      |    Length     | Prefix Length |L|A|R|S|Resvd1 |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                         Valid Lifetime                        |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                       Preferred Lifetime                      |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        | Site PLength  |           Reserved2                           |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
        |                                                               |
        +                                                               +
        |                                                               |
        +                            Prefix                             +
        |                                                               |
        +                                                               +
        |                                                               |
        +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   New fields:

      S              1-bit site prefix flag.  When set indicates that
                     this prefix, in addition to what might be specified
                     by the L and A flags, should be used to create
                     site-local addresses when an address matches the
                     first Site PLength part of the prefix.

      Site PLength   8-bit unsigned integer.  This Site Prefix Length is
                     only valid when the S flag is set.  The number of
                     leading bits in the Prefix that are valid.  The
                     value ranges from 0 to 128.

   The defined format above allows a single Prefix Information option to
   carry a subnet prefix used for on-link and/or stateless address
   autoconfiguration [ADDRCONF] together with a site prefix since the
   site prefix(es) are normally sub-prefixes of the subnet prefixes.

   For example, if the subnet prefix is
           2000:1:2:653a::0/64
   and the site prefix is:
           2000:1:2::0/48
   this can be encoded in a single Prefix Information option with Prefix
   Length being 64, Site PLength being 48 and the Prefix being
   2000:1:2:653a::0.






draft-ietf-ipngwg-site-prefixes-02.txt                         [Page 10]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


5.  CONCEPTUAL VARIABLES

   This document makes use of internal conceptual variables to describe
   protocol behavior and external variables that an implementation must
   allow system administrators to change.  The specific variable names,
   how their values change, and how their settings influence protocol
   behavior are provided to demonstrate protocol behavior.  An
   implementation is not required to have them in the exact form
   described here, so long as its external behavior is consistent with
   that described in this document.

   Hosts will need to maintain the following pieces of information.
   Unlike the information specific in [DISCOVERY] this information is
   not per interface but, for the bulk of this document, viewed as being
   for the host as a whole.

      Site Prefix List

                     A list of the site prefixes that have been received
                     in Router Advertisement messages that have not yet
                     timed out.  Each entry has an associated
                     invalidation timer value (extracted from the
                     advertisement) used to expire site prefixes when
                     they become invalid.  A special "infinity" timer
                     value specifies that a prefix remains valid
                     forever, unless a new (finite) value is received in
                     a subsequent advertisement.

                     Note that the Site Prefix List is separate from the
                     list of on-link prefixes called Prefix List in
                     [DISCOVERY].

   For normal operation the Site Prefix List is per node.  However, in
   order to discover that the node is multihomed to multiple sites the
   site prefixes have to be tracked for each interface.

   The conceptual Router variable called AdvPrefixList in [DISCOVERY] is
   extended to also contain site prefixes.  Conceptually this can be
   done by having each prefix both contain a AdvSubnetPrefixLength and a
   AdvSitePrefixLength field.  If one of the length fields is zero the
   prefix is not used as a on-link and/or addrconf prefix or a site
   prefix, respectively.  The same lifetime values will apply to both
   the subnet and site prefix aspects of a prefix in the AdvPrefixList.

   The above are conceptual variables; Implementations are free to
   implement the router variables as a separate list for the site
   prefixes and the existing Neighbor Discovery AdvPrefixList for subnet
   prefixes.  However, it is desirable that such implementations still



draft-ietf-ipngwg-site-prefixes-02.txt                         [Page 11]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


   use a single Prefix Information option to encode both a site and a
   subnet prefix when the site prefix is just a sub-prefix of the subnet
   prefix.


6.  SENDING RULES

   When a router is sending Prefix options as part of sending Router
   Advertisement messages in addition to the rules in [DISCOVERY] is
   performs the following operations:

    o If the AdvSitePrefixLength field in the AdvPrefixList entry is
      non-zero set the S flag in the Prefix option to one and set the
      Site PLength to the AdvSitePrefixLength.

    o Only if the AdvSubnetPrefixLength field is non-zero should the L-
      bit and the A-bit be set from the AdvOnLinkFlag and the
      AdvAutonomousFlag fields, respectively.

    o The Prefix field and the lifetime fields are set is specified in
      [DISCOVERY].


7.  RECEIVING RULES

   The host receiving a valid Router Advertisement follows the rules as
   specified in [DISCOVERY] with the following additions when parsing
   each received Prefix Information option.  For each prefix that has
   the S-flag set:

    o If the Site PLength is zero ignore the prefix.

    o If the prefix is the link-local or the site-local prefix ignore
      the prefix.

    o If the prefix is a multicast address ignore the prefix.

    o If the prefix is not already present in the Site Prefix List and
      the Valid Lifetime is zero, ignore the prefix.

    o If the prefix is not already present in the Site Prefix List and
      the Valid Lifetime is non-zero, create a new entry for the prefix
      in the Site Prefix List and initialize its invalidation timer to
      the Valid Lifetime value in the Prefix Information option.

    o If the prefix is already present in the host's Site Prefix List as
      the result of a previously-received advertisement, reset its
      invalidation timer to the Valid Lifetime value in the Prefix



draft-ietf-ipngwg-site-prefixes-02.txt                         [Page 12]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


      Information option.  If the new Lifetime value is zero,
      immediately remove the prefix from the Site Prefix List.

   The bits in the Prefix after the first Site PLength bits MUST be
   ignored when the prefix is entered in the Site Prefix List and/or
   when it is compared against other site prefixes.  These bits might be
   non-zero when the Prefix option carries a subnet prefix in addition
   to a site prefix.

   Timing out a site prefix from the Site Prefix List SHOULD NOT affect
   any existing communication.  New communication will use the updated
   Site Prefix List after performing a host name lookup.


8.  USING THE SITE PREFIXES

   The following rules apply when a node looks up host names and
   addresses in a name service such as DNS.



8.1.  Host Name Lookups

   The node will inspect the AAAA RRset returned from DNS to check if
   one or more of the global addresses belong to the same site as
   itself.  This is done by comparing all the global addresses against
   all the prefixes in the Site Prefix List.  If there are no matches
   then the site-local addresses in the RRset must not be used.  If
   there are one or more matches then the node should prefer using the
   site-local address(es) over the global addresses.  This can be done
   by sorting the addresses before they are returned to the application.

   It is important that the site-local addresses are first in the sorted
   list so that the applications try the site-local addresses before any
   global address.  Also, the matched global addresses are removed from
   the list in order to prevent the applications from using global
   addresses for communication that is local to the site.

   A possible algorithm for doing these comparisons is as follows:

      1) Assume the name service returns the global addresses G1, G2,
         G3, ... Gn and the site-local addresses SL1, SL2, ... SLk.
         Assume the prefixes in the Site Prefix List are SP1, SP2, ...
         SPm.  The Site PLength of each of the prefixes is Length(SPj).

      2) For each Gi compare it against all the SPj.  If the first
         Length(SPj) bits of Gi are equal to the first Length(SPj) bits
         of SPj then we have a match.



draft-ietf-ipngwg-site-prefixes-02.txt                         [Page 13]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


      3) If there is one or more matches and k > 0 then only give the
         application the site-local addresses SL1, SL2, ... SLk.

      4) Otherwise give only give the application the global addresses
         G1, ... Gn.

   For example, if the name service returns these addresses for a
   multihomed node:
           2837:a:b:987:X:Y:W:Z1
           2000:1:2:987:X:Y:W:Z1
           fec0::987:X:Y:W:Z1
           2837:a:b:34:X:Y:W:Z2
           2000:1:2:34:X:Y:W:Z2
           fec0::34:X:Y:W:Z2
           2abc:77:66:23:X:Y:W:Z3

   and the prefixes in the Site Prefix List are:
           2837:a:b::0/48
           2000:1:2::0/48

   The resulting list that the application should use should be:
           fec0::987:X:Y:W:Z1
           fec0::34:X:Y:W:Z2

   If there is no match (e.g., the Site Prefix List is empty) the
   resulting list that the application should use should be:
           2837:a:b:987:X:Y:W:Z1
           2000:1:2:987:X:Y:W:Z1
           2837:a:b:34:X:Y:W:Z2
           2000:1:2:34:X:Y:W:Z2
           2abc:77:66:23:X:Y:W:Z3



8.2.  IPv6 Address Lookups

   It is not sufficient to handle the forward lookup.  For instance, the
   node that receives packets and/or connections from a site-local
   address might have the desire to perform a reverse lookup to get a
   host name.  Thus these rules allow such a reverse lookup to succeed
   as long as the Site Prefix List contains all the prefixes that apply
   to the site.

   A possible algorithm for doing this is as follows:

      1) Assume the site-local address is SL and the prefixes in the
         Site Prefix List are SP1, SP2, ... SPm.  The Site PLength of
         each of the prefixes is Length(SPj).



draft-ietf-ipngwg-site-prefixes-02.txt                         [Page 14]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


      2) First perform a regular reverse lookup of the IPv6 address.  If
         the lookup succeeds, or the lookup fails and the IPv6 address
         is not a site-local address, report the failure to the
         application.

      3) When the reverse lookup of a site-local address fails use the
         Site Prefix List to construct global addresses corresponding to
         the site-local address.  This is done by taking each entry in
         the Site Prefix List and using it to construct a global
         address.  For each of the SPj concatenate the first Length(SPj)
         bits from SPj and the last (128 - Length(SPj)) bits from SL to
         form a new address.  Look up each of the resulting addresses
         until a match is found.

   For example, if the site-local address is:
           fec0::987:X:Y:W:Z1

   and the prefixes in the Site Prefix List are:
           2837:a:b::0/48
           2000:1:2::0/48

   The addresses that should be tried in the reverse lookup are:
           fec0::987:X:Y:W:Z1
           2837:a:b:987:X:Y:W:Z1
           2000:1:2:987:X:Y:W:Z1



9.  MULTIHOMED TO MULTIPLE SITES

   If a node is multihomed to multiple sites the above scheme can not be
   used unless all applications always associate an interface with each
   IP address.  It is recommended (but not required) that
   implementations which operate at site boundaries have such support.

   An alternative is to turn off all use of site-local addresses (and
   not include them in the name service) on a node that sits at a site
   boundary.  This will force all traffic to and from that node to use
   global addresses (except on those few cases where link-local
   addresses are used).

   Another alternative would be to configure the site boundaries using
   two nodes and an intervening link where the link is not part of any
   site.  Thus a node at the boundary would have one or more interfaces
   that are not part of any site - those interfaces would be connected
   to nodes which are part of other sites.  Other interfaces on the node
   would be part of one site.  This would allow the "boundary" node to
   use site-local addresses when communicating to one site.



draft-ietf-ipngwg-site-prefixes-02.txt                         [Page 15]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


   The algorithm outlined below is able to detect when a node is site
   multihomed which can be used to ignore all site-local addresses in
   the host name lookup algorithm.



9.1.  Detecting site multihoming

   A possible algorithm for doing this is as follows:

      1) Inspect the Site Prefix List for all interfaces.

      2) If an interface has no Site Prefix List entry ignore that
         interface.

      3) If two or more interfaces have one or more common Site Prefix
         List entries group those interfaces together.

      4) If the result is more than one group of interfaces the node is
         considered to be multihomed to more than one site.



10.  SECURITY CONSIDERATIONS

   Router Advertisements are not required to be authenticated and even
   if they are authenticated it is unclear whether or not there would be
   a mechanisms to verify the authority of a particular node to send
   Router Advertisements.

   Neighbor Discovery uses the rule of HopCount 255 (set to 255 on
   transmit and verified to be 255 on reception) to drop any Neighbor
   Discovery packets that are sent non-neighboring nodes.  This limits
   any attack using ND to the neighbors.

   Without authentication and authorization this new mechanisms
   introduces a new type of denial of service attack.  A node on the
   link can send a router advertisement listing site prefixes that are
   in fact not part of the site.  For instance, it could advertise some
   other sites prefix as a site prefix.  Such an attack would result in
   all nodes on the link to fail initiate any new communication with any
   node in that site since they would accept the site-local AAAA
   records.

   Also there is the possibility to return incorrect information for the
   reverse lookup of IPv6 addresses.  A node on the link can send a
   router advertisement listing site prefixes that are in fact not part
   of the site.  For instance, it could advertise an incorrect site



draft-ietf-ipngwg-site-prefixes-02.txt                         [Page 16]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


   prefix (e.g. a:b::0/48) which would make the reverse lookup of the
   site local address fec0::X lookup a:b::X.

   This could be viewed as allowing some form of indirect spoofing of
   the addresses returned by the DNS independent whether or not the DNS
   itself is secure.  Thus introducing a secure DNS [DNSsec] would not
   remove this form of "address spoofing".  However, it seems like this
   threat is no worse than the other threats in [DISCOVERY] where any
   node on the link can intercept all packets sent on the link.

   The packets used to discover site prefixes, just like all other
   Neighbor Discovery protocol packet exchanges, can be authenticated
   using the IP Authentication Header [IPv6-AUTH].  A node SHOULD
   include an Authentication Header when sending Neighbor Discovery
   packets if a security association for use with the IP Authentication
   Header exists for the destination address.  The security associations
   may have been created through manual configuration or through the
   operation of some key management protocol.

   Received Authentication Headers in these packets, just like all
   Neighbor Discovery packets, MUST be verified for correctness and
   packets with incorrect authentication MUST be ignored.

   Confidentiality issues are addressed by the IP Security Architecture
   and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6-
   ESP].






REFERENCES


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

     [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version
             6 (IPv6) Specification", RFC 1883, January 1996.

     [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6
             Addressing Architecture", RFC 1884, January 1996.

     [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor
             Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996.

     [ADDR-TODAY] B. Carpenter, J. Crowcroft, Y. Rekhter, "IPv4 Address



draft-ietf-ipngwg-site-prefixes-02.txt                         [Page 17]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


             Behavior Today", RFC 2101, February 1997.

     [GSE-EVAL] M. Crawford, A. Mankin, T. Narten, J. Stewart, L. Zhang,
             "IPng Analysis of the GSE Proposal", Internet Draft,
             draft-ietf-ipngwg-esd-analysis-02.txt.

     [ROUTER-RENUM] M. Crawford, and R. Hinden, "Router Renumbering for
             IPv6", Internet Draft, draft-ietf-ipngwg-router-renum-
             03.txt.

     [ADDRCONF] S. Thomson, T. Narten, "IPv6 Address Autoconfiguration",
             RFC 1971, August 1996.

     [IPv6-SA] R. Atkinson.  "Security Architecture for the Internet
             Protocol".  RFC 1825, August 1995.

     [IPv6-AUTH] R. Atkinson.  "IP Authentication Header", RFC 1826,
             August 1995.

     [IPv6-ESP] R. Atkinson.  "IP Encapsulating Security Payload (ESP)",
             RFC 1827, August 1995.

     [DNSsec] D. Eastlake, C. Kaufman, "Domain Name System Security
             Extensions", RFC 2065, January 1997.

     [MOBILE-IPv6] D.B. Johnson, C. Perkins, "Mobility Support in IPv6",
             Internet Draft, draft-ietf-mobileip-ipv6-06.txt, August
             1998.



AUTHOR'S ADDRESS

        Erik Nordmark
        Sun Microsystems, Inc.
        901 San Antonio Road
        Palo Alto, CA 94303
        USA

        phone: +1 650 786 5166
        fax:   +1 650 786 5896
        email: nordmark@sun.com









draft-ietf-ipngwg-site-prefixes-02.txt                         [Page 18]


INTERNET-DRAFT    Site Prefixes in Neighbor Discovery        August 1998


APPENDIX A: CHANGES SINCE PREVIOUS DRAFT


   The following changes have been made since version 01 of the draft.

    o Stated the assumptions on what a "site" is and how it is configured.

    o Changed the document to store site-local addresses in the DNS and use
      filtering do ignore site-local addresses unless the sender and receiver
      can be determined to belong to the same site.

    o Added text describing interaction with mobile IP.

    o Added rules for ignoring site-local entries from the DNS

    o Make "turn off at site boundary" implementation dependent.

    o Changed 'S' bit in prefix option not to conflict with [MOBILE-IPv6].


   The following changes have been made since version 00 of the draft.

    o Removed mention of routing protocols.

    o Made the formed site-local addresses replace the global addresses
      in the list returned to the application.  This change prevents the
      "accidental" use of a global address when the application
      tries all of the returned
      addresses and for whatever reason it could not reach the node when
      it tried the site-local address(es).

    o Added describing how to the mechanism is automatically disabled on
      nodes which are  Multihomed to multiple sites.

    o Updated list of open issues.
















draft-ietf-ipngwg-site-prefixes-02.txt                         [Page 19]