home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_ietf_i / draft-ietf-ipngwg-site-prefixes-00.txt < prev    next >
Text File  |  1997-07-30  |  30KB  |  788 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. INTERNET-DRAFT                           Erik Nordmark, Sun Microsystems
  8. July 30, 1997
  9.  
  10.  
  11.                     Site prefixes in Neighbor Discovery
  12.  
  13.                  <draft-ietf-ipngwg-site-prefixes-00.txt>
  14.  
  15.  
  16. Status of this Memo
  17.  
  18.    This document is an Internet-Draft.  Internet-Drafts are working
  19.    documents of the Internet Engineering Task Force (IETF), its areas,
  20.    and its working groups.  Note that other groups may also distribute
  21.    working documents as Internet-Drafts.
  22.  
  23.    Internet-Drafts are draft documents valid for a maximum of six months
  24.    and may be updated, replaced, or obsoleted by other documents at any
  25.    time.  It is inappropriate to use Internet-Drafts as reference
  26.    material or to cite them other than as ``work in progress.''
  27.  
  28.    To learn the current status of any Internet-Draft, please check the
  29.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  30.    Directories on ds.internic.net (US East Coast), nic.nordu.net
  31.    (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific
  32.    Rim).
  33.  
  34.    Distribution of this memo is unlimited.
  35.  
  36.    This Internet Draft expires January 30, 1998.
  37.  
  38.  
  39.  
  40. Abstract
  41.  
  42.    This document specifies extensions to IPv6 Neighbor Discovery to
  43.    carry site-prefixes.  The site prefixes are used to reduce the effect
  44.    of site renumbering by ensuring that the communication inside a site
  45.    uses site-local addresses.
  46.  
  47.  
  48.  
  49.  
  50.  
  51.  
  52.  
  53.  
  54.  
  55.  
  56.  
  57.  
  58. draft-ietf-ipngwg-site-prefixes-00.txt                          [Page 1]
  59.  
  60. INTERNET-DRAFT    Site Prefixes in Neighbor Discovery          July 1997
  61.  
  62.  
  63. Contents
  64.  
  65.    Status of this Memo..........................................    1
  66.  
  67.    1.  INTRODUCTION AND MOTIVATION..............................    2
  68.  
  69.    2.  TERMINOLOGY..............................................    4
  70.       2.1.  Requirements........................................    4
  71.  
  72.    3.  OVERVIEW.................................................    4
  73.       3.1.  Assumptions.........................................    5
  74.  
  75.    4.  UPDATED PREFIX OPTION FORMAT.............................    5
  76.       4.1.  CONCEPTUAL VARIABLES................................    7
  77.  
  78.    5.  SENDING RULES............................................    8
  79.  
  80.    6.  RECEIVING RULES..........................................    8
  81.  
  82.    7.  USING THE SITE PREFIXES..................................    9
  83.       7.1.  Host Name Lookups...................................    9
  84.       7.2.  IPv6 Address Lookups................................   10
  85.  
  86.    8.  SECURITY CONSIDERATIONS..................................   11
  87.  
  88.    9.  OPEN ISSUES..............................................   12
  89.  
  90.    REFERENCES...................................................   13
  91.  
  92.    AUTHOR'S ADDRESS.............................................   14
  93.  
  94.  
  95.  
  96.  
  97.  
  98.  
  99. 1.  INTRODUCTION AND MOTIVATION
  100.  
  101.    In order to maintain the aggregation of the global Internet routing
  102.    tables it might be necessary for whole sites to renumber to use
  103.    different prefixes for their global IPv6 addresses.  Such renumbering
  104.    would not directly benefit the renumbered sites but instead be
  105.    necessary for the scaling of the Internet as a whole.
  106.  
  107.    In order to increase the probability that such renumbering is viewed
  108.    favorably by the sites themselves, which see little or no direct
  109.    benefit, it is critical that both the effort of renumbering is kept
  110.    at a minimum and also that the risk associated with renumbering is as
  111.  
  112.  
  113.  
  114. draft-ietf-ipngwg-site-prefixes-00.txt                          [Page 2]
  115.  
  116. INTERNET-DRAFT    Site Prefixes in Neighbor Discovery          July 1997
  117.  
  118.  
  119.    small as possible.
  120.  
  121.    The Stateless address autoconfiguration [ADDRCONF] and support for
  122.    router renumbering [ROUTER-RENUM] make it easier to renumber a site.
  123.    Also, the IPv6 routing protocols use link-local or site-local
  124.    addresses to maintain their router adjacencies (as specified in
  125.    [RIPNG], [OSPF] etc) so reduce the effect of site renumbering on the
  126.    internal communication.  However, these protocols do not by
  127.    themselves address long-running TCP connections or cases where IP
  128.    addresses have been stored in some configuration file.  Thus
  129.    additional measures are needed to reduce the risk of renumbering.
  130.  
  131.    For many sites it is much more critical to maintain the internal
  132.    communication than the intra-site communication over the Internet.
  133.    Based on that observation this proposal tries to limit the effect of
  134.    a site renumbering one or more of its global prefixes by ensuring
  135.    that intra-site communication can use site-local addresses that are
  136.    not effected by the site renumbering.  With this proposal it is
  137.    possible to maintain internal long-running TCP connections or
  138.    otherwise store IPv6 addresses for longer time than would have been
  139.    possible without it.
  140.  
  141.    As specified in [ADDR-TODAY] IP addresses are no longer temporarily
  142.    unique.  This implies, among other things, that applications should
  143.    not store IPv6 addresses without a mechanisms for honoring the DNS
  144.    time-to-live and refreshing the IPv6 address.  This protocol is not
  145.    intended to deter from that recommendation but is merely based on the
  146.    observation that the applications today might assume that IPv4
  147.    addresses are temporarily unique and it is likely that some
  148.    applications might not be corrected in their behavior as they are
  149.    moved to IPv6.  It would be unfortunate if such application
  150.    "brokenness" would lead sites to view site renumbering as a too risky
  151.    or a too costly operation.
  152.  
  153.    This document does not address the general issues of renumbering such
  154.    as renumbering a single host or a subnet.  It is targeted at site
  155.    renumbering.  The proposal does not attempt to address how long-
  156.    running TCP connections going outside a site will survive the site
  157.    renumbering.
  158.  
  159.    The author would like to acknowledge the contributions the IPNGWG
  160.    working group and in particular Mike O'Dell who pointed out the
  161.    importance of the problem, and Robert Elz who suggested this approach
  162.    to solving the problem.
  163.  
  164.  
  165.  
  166.  
  167.  
  168.  
  169.  
  170. draft-ietf-ipngwg-site-prefixes-00.txt                          [Page 3]
  171.  
  172. INTERNET-DRAFT    Site Prefixes in Neighbor Discovery          July 1997
  173.  
  174.  
  175. 2.  TERMINOLOGY
  176.  
  177.    This documents uses the terminology defined in [IPV6] and
  178.    [DISCOVERY].
  179.  
  180.  
  181. 2.1.  Requirements
  182.  
  183.    The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
  184.    SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
  185.    document, are to be interpreted as described in [KEYWORDS].
  186.  
  187. 3.  OVERVIEW
  188.  
  189.    The goal of this extension to Neighbor Discovery is to make
  190.    communication that is local to a single site use the site-local
  191.    addresses instead of the global addresses.  If all communication
  192.    internal to a site uses site-local addresses then the site's global
  193.    addresses can be renumbered without having any affect on the internal
  194.    communication.  Thus the risk associated with site renumbering is
  195.    lowered - applications that store IPv6 addresses and long-running TCP
  196.    connections will, as long as the communication is local to the site,
  197.    continue to operate across the renumbering of the site.
  198.  
  199.    A few alternative solutions have been explored.  An early proposal
  200.    was to place the site-local addresses in the name service (e.g., the
  201.    DNS) and make sure they are returned first in the list of addresses
  202.    returned to an application (to make it likely that the application
  203.    will use that address).  That proposal has the disadvantage that the
  204.    name service must return different addresses depending on who asks
  205.    the question; if a node inside the site asks for an address it should
  206.    return the site-local address(es) but if a node outside the site asks
  207.    it must not return a site-local address.  This is referred to as the
  208.    two-faced DNS.  While some sites use a two-faced DNS today as part of
  209.    their firewall solution it would be rather unfortunate if each and
  210.    every site had to deploy such a solution.  See [GSE-EVAL] for more
  211.    discussion.
  212.  
  213.    This proposal takes a different approach.  The name service will only
  214.    contain global addresses.  The routing infrastructure will be used to
  215.    distribute information about which prefixes belong to the local site.
  216.    This document only specifies how the site-prefixes are distributed
  217.    from the routers to the hosts on each link.  However, other protocols
  218.    such as [ROUTER-RENUM] might be extended to carry the site-prefixes
  219.    to all routers in a site.  The use of the routing infrastructure to
  220.    carry the site-prefixes avoids the "two-faced" issue above - the
  221.    routers know which part of the network is inside the site thus they
  222.    can naturally prevent this information from being distributed outside
  223.  
  224.  
  225.  
  226. draft-ietf-ipngwg-site-prefixes-00.txt                          [Page 4]
  227.  
  228. INTERNET-DRAFT    Site Prefixes in Neighbor Discovery          July 1997
  229.  
  230.  
  231.    the site.
  232.  
  233.    The protocol is based on each host maintaining a list of all the
  234.    currently active site prefixes.  The site prefixes are periodically
  235.    advertised in Neighbor Discovery Router Advertisement messages and
  236.    each prefix has an associated lifetime.
  237.  
  238.    Once a host has a list of the prefixes that apply to its site it uses
  239.    this information to determine if the global addresses returned by the
  240.    name service is part of its site.  If this is the case the host
  241.    constructs the site-local address that corresponds to the global
  242.    address by replacing the site-prefix with the constant site-local
  243.    prefix (fec0::0/48).  This will result in one or more site-local
  244.    addresses being generated.  These addresses are then added to the set
  245.    of addresses that will be used when communicating with the peer in
  246.    such a way that the site-local addresses are tried before any of the
  247.    global addresses.
  248.  
  249.    The host will perform the reverse operation when doing a reverse
  250.    lookup (from an IPv6 address to a host name).  If the address being
  251.    looked up is a site-local address the host constructs the
  252.    corresponding global addresses by using the list of site prefixes and
  253.    performs a reverse lookup on those addresses until a match is found.
  254.  
  255.    It is expected that both the forward and reverse lookup rules can be
  256.    hidden from the applications by implementing them as part of the
  257.    library that handles host name lookups.
  258.  
  259.  
  260. 3.1.  Assumptions
  261.  
  262.    The protocol assumes that the site uses a consistent subnet numbering
  263.    scheme across all its global addresses and its site-local addresses.
  264.  
  265.    Thus, for every subnet in the site, the 16-bit subnet ID field
  266.    [ADDR-ARCH] for the site-local address must have the same value as
  267.    the Site-Local Aggregator(s) field in the global addresses.
  268.  
  269.  
  270. 4.  UPDATED PREFIX OPTION FORMAT
  271.  
  272.    The protocol adds two new fields using previously reserved parts of
  273.    the Prefix Information Option defined in [DISCOVERY].
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. draft-ietf-ipngwg-site-prefixes-00.txt                          [Page 5]
  283.  
  284. INTERNET-DRAFT    Site Prefixes in Neighbor Discovery          July 1997
  285.  
  286.  
  287.          0                   1                   2                   3
  288.          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
  289.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  290.         |     Type      |    Length     | Prefix Length |L|A|S| Resvd1  |
  291.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  292.         |                         Valid Lifetime                        |
  293.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  294.         |                       Preferred Lifetime                      |
  295.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  296.         | Site PLength  |           Reserved2                           |
  297.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  298.         |                                                               |
  299.         +                                                               +
  300.         |                                                               |
  301.         +                            Prefix                             +
  302.         |                                                               |
  303.         +                                                               +
  304.         |                                                               |
  305.         +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  306.  
  307.    New fields:
  308.  
  309.       S              1-bit site prefix flag.  When set indicates that
  310.                      this prefix, in addition to what might be specified
  311.                      by the L and A flags, should be used to create
  312.                      site-local addresses when an address matches the
  313.                      first Site PLength part of the prefix.
  314.  
  315.       Site PLength   8-bit unsigned integer.  This Site Prefix Length is
  316.                      only valid when the S flag is set.  The number of
  317.                      leading bits in the Prefix that are valid.  The
  318.                      value ranges from 0 to 128.
  319.  
  320.    The defined format above allows a single Prefix Information option to
  321.    carry a subnet prefix used for on-link and/or stateless address
  322.    autoconfiguration [ADDRCONF] together with a site prefix since the
  323.    site prefix(es) are normally sub-prefixes of the subnet prefixes.
  324.  
  325.    For example, if the subnet prefix is
  326.            2000:1:2:653a::0/64
  327.    and the site prefix is:
  328.            2000:1:2::0/48
  329.    this can be encoded in a single Prefix Information option with Prefix
  330.    Length being 64, Site PLength being 48 and the Prefix being
  331.    2000:1:2:653a::0.
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. draft-ietf-ipngwg-site-prefixes-00.txt                          [Page 6]
  339.  
  340. INTERNET-DRAFT    Site Prefixes in Neighbor Discovery          July 1997
  341.  
  342.  
  343. 4.1.  CONCEPTUAL VARIABLES
  344.  
  345.    This document makes use of internal conceptual variables to describe
  346.    protocol behavior and external variables that an implementation must
  347.    allow system administrators to change.  The specific variable names,
  348.    how their values change, and how their settings influence protocol
  349.    behavior are provided to demonstrate protocol behavior.  An
  350.    implementation is not required to have them in the exact form
  351.    described here, so long as its external behavior is consistent with
  352.    that described in this document.
  353.  
  354.    Hosts will need to maintain the following pieces of information.
  355.    Unlike the information specific in [DISCOVERY] this information is
  356.    not per interface but for the host as a whole.
  357.  
  358.       Site Prefix List  - A list of the site prefixes that have been
  359.                      received in Router Advertisement messages that have
  360.                      not yet timed out.  Each entry has an associated
  361.                      invalidation timer value (extracted from the
  362.                      advertisement) used to expire site prefixes when
  363.                      they become invalid.  A special "infinity" timer
  364.                      value specifies that a prefix remains valid
  365.                      forever, unless a new (finite) value is received in
  366.                      a subsequent advertisement.
  367.  
  368.                      Note that the Site Prefix List is separate from the
  369.                      list of on-link prefixes called Prefix List in
  370.                      [DISCOVERY].
  371.  
  372.    The conceptual Router variable called AdvPrefixList in [DISCOVERY] is
  373.    extended to also contain site prefixes.  Conceptually this can be
  374.    done by having each prefix both contain a AdvSubnetPrefixLength and a
  375.    AdvSitePrefixLength field.  If one of the length fields is zero the
  376.    prefix is not used as a on-link and/or addrconf prefix or a site
  377.    prefix, respectively.  The same lifetime values will apply to both
  378.    the subnet and site prefix aspects of a prefix in the AdvPrefixList.
  379.  
  380.    The above are conceptual variables; Implementations are free to
  381.    implement the router variables as a separate list for the site
  382.    prefixes and the existing Neighbor Discovery AdvPrefixList for subnet
  383.    prefixes.  However, it is desirable that such implementations still
  384.    use a single Prefix Information option to encode both a site and a
  385.    subnet prefix when the site prefix is just a sub-prefix of the subnet
  386.    prefix.
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. draft-ietf-ipngwg-site-prefixes-00.txt                          [Page 7]
  395.  
  396. INTERNET-DRAFT    Site Prefixes in Neighbor Discovery          July 1997
  397.  
  398.  
  399. 5.  SENDING RULES
  400.  
  401.    When a router is sending Prefix options as part of sending Router
  402.    Advertisement messages in addition to the rules in [DISCOVERY] is
  403.    performs the following operations:
  404.  
  405.     o If the AdvSitePrefixLength field in the AdvPrefixList entry is
  406.       non-zero set the S flag in the Prefix option to one and set the
  407.       Site PLength to the AdvSitePrefixLength.
  408.  
  409.     o Only if the AdvSubnetPrefixLength field is non-zero should the L-
  410.       bit and the A-bit be set from the AdvOnLinkFlag and the
  411.       AdvAutonomousFlag fields, respectively.
  412.  
  413.     o The Prefix field and the lifetime fields are set is specified in
  414.       [DISCOVERY].
  415.  
  416.  
  417. 6.  RECEIVING RULES
  418.  
  419.    The host receiving a valid Router Advertisement follows the rules as
  420.    specified in [DISCOVERY] with the following additions when parsing
  421.    each received Prefix Information option.  For each prefix that has
  422.    the S-flag set:
  423.  
  424.     o If the Site PLength is zero ignore the prefix.
  425.  
  426.     o If the prefix is the link-local or the site-local prefix ignore
  427.       the prefix.
  428.  
  429.     o If the prefix is a multicast address ignore the prefix.
  430.  
  431.     o If the prefix is not already present in the Site Prefix List and
  432.       the Valid Lifetime is zero, ignore the prefix.
  433.  
  434.     o If the prefix is not already present in the Site Prefix List and
  435.       the Valid Lifetime is non-zero, create a new entry for the prefix
  436.       in the Site Prefix List and initialize its invalidation timer to
  437.       the Valid Lifetime value in the Prefix Information option.
  438.  
  439.     o If the prefix is already present in the host's Site Prefix List as
  440.       the result of a previously-received advertisement, reset its
  441.       invalidation timer to the Valid Lifetime value in the Prefix
  442.       Information option.  If the new Lifetime value is zero,
  443.       immediately remove the prefix from the Site Prefix List.
  444.  
  445.    The bits in the Prefix after the first Site PLength bits MUST be
  446.    ignored when the prefix is entered in the Site Prefix List and/or
  447.  
  448.  
  449.  
  450. draft-ietf-ipngwg-site-prefixes-00.txt                          [Page 8]
  451.  
  452. INTERNET-DRAFT    Site Prefixes in Neighbor Discovery          July 1997
  453.  
  454.  
  455.    when it is compared against other site prefixes.  These bits might be
  456.    non-zero when the Prefix option carries a subnet prefix in addition
  457.    to a site prefix.
  458.  
  459.    Timing out a site prefix from the Site Prefix List SHOULD NOT affect
  460.    any existing communication.  New communication will use the updated
  461.    Site Prefix List after performing a host name lookup.
  462.  
  463.  
  464. 7.  USING THE SITE PREFIXES
  465.  
  466.    The following rules apply when a node looks up host names and
  467.    addresses in a name service such as DNS.
  468.  
  469.  
  470.  
  471. 7.1.  Host Name Lookups
  472.  
  473.    The goal is that when an address or multiple addresses are returned
  474.    by the name server to the host that the host should, if one or more
  475.    of those addresses match one of the site prefixes, prepend the
  476.    corresponding site local address to the list of addresses that the
  477.    application will attempt to use.
  478.  
  479.    It is important to prepend them to the list so that the applications
  480.    try the site-local addresses before the corresponding global
  481.    addresses in order to be able to prevent the applications from using
  482.    global addresses for communication that is local to the site.
  483.  
  484.    A possible algorithm for doing these comparisons is as follows:
  485.  
  486.       1) Assume the name service returns the addresses A1, A2, A3, ...
  487.          An and the prefixes in the Site Prefix List are SP1, SP2, ...
  488.          SPm.  The Site PLength of each of the prefixes is Length(SPj).
  489.  
  490.       2) For each Ai compare it against all the SPj.  If the first
  491.          Length(SPj) bits of Ai are equal to the first Length(SPj) bits
  492.          of SPj then construct the site-local address corresponding to
  493.          Ai by concatenating the first Length(SPj) bits out of the
  494.          site-local address (prefix) FEC0::0 and the last (128 -
  495.          Length(SPj)) of Ai to form a new address.  Add this address to
  496.          the front of the list (i.e. before A1).
  497.  
  498.       3) In some cases the above algorithm will add the same site-local
  499.          address more than once to the list thus it is desirable to
  500.          remove the duplicates from the resulting list.
  501.  
  502.    For example, if the name service returns these addresses for a
  503.  
  504.  
  505.  
  506. draft-ietf-ipngwg-site-prefixes-00.txt                          [Page 9]
  507.  
  508. INTERNET-DRAFT    Site Prefixes in Neighbor Discovery          July 1997
  509.  
  510.  
  511.    multihomed node:
  512.            2837:a:b:987:X:Y:W:Z1
  513.            2000:1:2:987:X:Y:W:Z1
  514.            2837:a:b:34:X:Y:W:Z2
  515.            2000:1:2:34:X:Y:W:Z2
  516.            2abc:77:66:23:X:Y:W:Z3
  517.    and the prefixes in the Site Prefix List are:
  518.            2837:a:b::0/48
  519.            2000:1:2::0/48
  520.    The resulting list that the application should use should be (in
  521.    order):
  522.            fec0::987:X:Y:W:Z1
  523.            fec0::987:X:Y:W:Z1      (duplicate - can be removed)
  524.            fec0::34:X:Y:W:Z2
  525.            fec0::34:X:Y:W:Z2       (duplicate - can be removed)
  526.            2837:a:b:987:X:Y:W:Z1
  527.            2000:1:2:987:X:Y:W:Z1
  528.            2837:a:b:34:X:Y:W:Z2
  529.            2000:1:2:34:X:Y:W:Z2
  530.            2abc:77:66:23:X:Y:W:Z3
  531.  
  532.  
  533.  
  534. 7.2.  IPv6 Address Lookups
  535.  
  536.    It is not sufficient to handle the forward lookup.  For instance, the
  537.    node that receives packets and/or connections from a site-local
  538.    address might have the desire to perform a reverse lookup to get a
  539.    host name.  Thus these rules allow such a reverse lookup to succeed
  540.    as long as the Site Prefix List contains all the prefixes that apply
  541.    to the site.
  542.  
  543.    A possible algorithm for doing this is as follows:
  544.  
  545.       1) Assume the site-local address is A and the prefixes in the Site
  546.          Prefix List are SP1, SP2, ... SPm.  The Site PLength of each of
  547.          the prefixes is Length(SPj).
  548.  
  549.       2) First perform a regular reverse lookup of the IPv6 address.  If
  550.          the lookup succeeds or the lookup fails and the IPv6 address is
  551.          not a site-local address there is nothing more to do.
  552.  
  553.       3) When the reverse lookup of a site-local address fails use the
  554.          Site Prefix List to construct global addresses corresponding to
  555.          the site-local address.  This is done by taking each entry in
  556.          the Site Prefix List and using it to construct a global
  557.          address.  For each of the SPj concatenate the first Length(SPj)
  558.          bits from SPj and the last (128 - Length(SPj)) bits from A to
  559.  
  560.  
  561.  
  562. draft-ietf-ipngwg-site-prefixes-00.txt                         [Page 10]
  563.  
  564. INTERNET-DRAFT    Site Prefixes in Neighbor Discovery          July 1997
  565.  
  566.  
  567.          form a new address.  Look up each of the resulting addresses
  568.          until a match is found.
  569.  
  570.    For example, if the site-local address is:
  571.            fec0::987:X:Y:W:Z1
  572.    and the prefixes in the Site Prefix List are:
  573.            2837:a:b::0/48
  574.            2000:1:2::0/48
  575.    The address that should be tried in the reverse lookup are:
  576.            2837:a:b:987:X:Y:W:Z1
  577.            2000:1:2:987:X:Y:W:Z1
  578.  
  579.  
  580. 8.  SECURITY CONSIDERATIONS
  581.  
  582.    Router Advertisements are not required to be authenticated and even
  583.    if they are authenticated it is unclear whether or not there would be
  584.    a mechanisms to verify the authority of a particular node to send
  585.    Router Advertisements.
  586.  
  587.    Neighbor Discovery uses the rule of HopCount 255 (set to 255 on
  588.    transmit and verified to be 255 on reception) to drop any Neighbor
  589.    Discovery packets that are sent non-neighboring nodes.  This limits
  590.    any attack using ND to the neighbors.
  591.  
  592.    Without authentication and authorization this new mechanisms
  593.    introduces a new type of denial of service attack.  A node on the
  594.    link can send a router advertisement listing site-prefixes that are
  595.    in fact not part of the site.  For instance, it could advertise all
  596.    addresses (prefix 0::0/0) as a site-prefix).  Such an attack would
  597.    result in all nodes on the link to fail initiate any new
  598.    communication with any node outside the site.
  599.  
  600.    Furthermore this mechanism can also be used by an attacker on the
  601.    link to "redirect" an arbitrary global prefix to a node inside the
  602.    site that has the same low-order part of the address as the intended
  603.    recipient.  Thus such an attack consists of one attacker on the link
  604.    plus one cohort that has the same low order part of the address as
  605.    the intended destination.
  606.  
  607.    This could be viewed as allowing some form of indirect spoofing of
  608.    the addresses returned by the DNS independent whether or not the DNS
  609.    itself is secure.  Thus introducing a secure DNS [DNSsec] would not
  610.    remove this form of "address spoofing".  However, it seems like this
  611.    threat is no worse than the other threats in [DISCOVERY] where any
  612.    node on the link can intercept all packets sent on the link.
  613.  
  614.    The packets used to discover site prefixes, just like all other
  615.  
  616.  
  617.  
  618. draft-ietf-ipngwg-site-prefixes-00.txt                         [Page 11]
  619.  
  620. INTERNET-DRAFT    Site Prefixes in Neighbor Discovery          July 1997
  621.  
  622.  
  623.    Neighbor Discovery protocol packet exchanges, can be authenticated
  624.    using the IP Authentication Header [IPv6-AUTH].  A node SHOULD
  625.    include an Authentication Header when sending Neighbor Discovery
  626.    packets if a security association for use with the IP Authentication
  627.    Header exists for the destination address.  The security associations
  628.    may have been created through manual configuration or through the
  629.    operation of some key management protocol.
  630.  
  631.    Received Authentication Headers in these packets, just like all
  632.    Neighbor Discovery packets, MUST be verified for correctness and
  633.    packets with incorrect authentication MUST be ignored.
  634.  
  635.    Confidentiality issues are addressed by the IP Security Architecture
  636.    and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6-
  637.    ESP].
  638.  
  639.  
  640.  
  641. 9.  OPEN ISSUES
  642.  
  643.  
  644.     o This scheme has the assumption that the same subnet number (called
  645.       Site-Local Aggregator(s) field for the global addresses) is
  646.       assigned to a link and used for both site-local addresses and all
  647.       global addresses that are advertised as site prefixes.  Is this a
  648.       reasonable assumption?
  649.  
  650.     o This proposal can be viewed as creating a security hole in a
  651.       secure name service.  The proposal tries to limit the security
  652.       hole by only allowing the mapping to/from the site-local prefix
  653.       i.e., it does not allow arbitrary remapping from one IPv6 address
  654.       to another.  When communication actually takes place after
  655.       resolving a host name this hole is not any worse than the fact
  656.       that any node on the link can intercept all packets sent on the
  657.       link as described in [DISCOVERY].  But do we need to be concerned
  658.       about the security of host name lookups and IP address lookups in
  659.       the absence of any communication with the peer node?
  660.  
  661.     o Should the formed site-local addresses replace the global
  662.       addresses in the list returned to the application?  As currently
  663.       specified a node might end up using a global address if it tries
  664.       all of the returned addresses and for whatever reason it could not
  665.       reach the node when it tried the site-local address(es).p
  666.  
  667.     o Do we need to specify a common API that e.g. the BIND DNS resolver
  668.       can use to access the Site Prefix List?
  669.  
  670.  
  671.  
  672.  
  673.  
  674. draft-ietf-ipngwg-site-prefixes-00.txt                         [Page 12]
  675.  
  676. INTERNET-DRAFT    Site Prefixes in Neighbor Discovery          July 1997
  677.  
  678.  
  679. REFERENCES
  680.  
  681.  
  682.      [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate
  683.              Requirement Levels", RFC 2119, March 1997.
  684.  
  685.      [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version
  686.              6 (IPv6) Specification", RFC 1883, January 1996.
  687.  
  688.      [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6
  689.              Addressing Architecture", RFC 1884, January 1996.
  690.  
  691.      [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor
  692.              Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996.
  693.  
  694.      [RIPNG] G. Malkin, R. Minnear, "RIPng for IPv6", RFC 2080, January
  695.              1997.
  696.  
  697.      [OSPF] R. Coltun, D. Ferguson, J. Moy, "OSPF for IPv6", Internet
  698.              Draft, draft-ietf-ospf-ospfv6-04.txt.
  699.  
  700.      [ADDR-TODAY] B. Carpenter, J. Crowcroft, Y. Rekhter, "IPv4 Address
  701.              Behavior Today", RFC 2101, February 1997.
  702.  
  703.      [GSE-EVAL] M. Crawford, A. Mankin, T. Narten, J. Stewart, L. Zhang,
  704.              "IPng Analysis of the GSE Proposal", Internet Draft,
  705.              draft-ietf-ipngwg-esd-analysis-00.txt.
  706.  
  707.      [ROUTER-RENUM] M. Crawford, and R. Hinden, "Router Renumbering for
  708.              IPv6", Internet Draft, draft-ietf-ipngwg-router-renum-
  709.              00.txt.
  710.  
  711.      [ADDRCONF] S. Thomson, T. Narten, "IPv6 Address Autoconfiguration",
  712.              RFC 1971, August 1996.
  713.  
  714.      [IPv6-SA] R. Atkinson.  "Security Architecture for the Internet
  715.              Protocol".  RFC 1825, August 1995.
  716.  
  717.      [IPv6-AUTH] R. Atkinson.  "IP Authentication Header", RFC 1826,
  718.              August 1995.
  719.  
  720.      [IPv6-ESP] R. Atkinson.  "IP Encapsulating Security Payload (ESP)",
  721.              RFC 1827, August 1995.
  722.  
  723.      [DNSsec] D. Eastlake, C. Kaufman, "Domain Name System Security
  724.              Extensions", RFC 2065, January 1997.
  725.  
  726.  
  727.  
  728.  
  729.  
  730. draft-ietf-ipngwg-site-prefixes-00.txt                         [Page 13]
  731.  
  732. INTERNET-DRAFT    Site Prefixes in Neighbor Discovery          July 1997
  733.  
  734.  
  735. AUTHOR'S ADDRESS
  736.  
  737.         Erik Nordmark
  738.         Sun Microsystems, Inc.
  739.         901 San Antonio Road
  740.         Palo Alto, CA 94303
  741.         USA
  742.  
  743.         phone: +1 415 786 5166
  744.         fax:   +1 415 786 5896
  745.         email: nordmark@sun.com
  746.  
  747.  
  748.  
  749.  
  750.  
  751.  
  752.  
  753.  
  754.  
  755.  
  756.  
  757.  
  758.  
  759.  
  760.  
  761.  
  762.  
  763.  
  764.  
  765.  
  766.  
  767.  
  768.  
  769.  
  770.  
  771.  
  772.  
  773.  
  774.  
  775.  
  776.  
  777.  
  778.  
  779.  
  780.  
  781.  
  782.  
  783.  
  784.  
  785.  
  786. draft-ietf-ipngwg-site-prefixes-00.txt                         [Page 14]
  787.  
  788.