home *** CD-ROM | disk | FTP | other *** search
/ Internet Core Protocols / Oreilly-InternetCoreProtocols.iso / RFCs / rfc2526.txt < prev    next >
Encoding:
Text File  |  1999-10-14  |  14.6 KB  |  396 lines
  1.  
  2.  
  3.  
  4.  
  5.  
  6.  
  7. Network Working Group                                         D. Johnson
  8. Request for Comments: 2526                    Carnegie Mellon University
  9. Category: Standards Track                                     S. Deering
  10.                                                      Cisco Systems, Inc.
  11.                                                               March 1999
  12.  
  13.  
  14.                  Reserved IPv6 Subnet Anycast Addresses
  15.  
  16. Status of this Memo
  17.  
  18.    This document specifies an Internet standards track protocol for the
  19.    Internet community, and requests discussion and suggestions for
  20.    improvements.  Please refer to the current edition of the "Internet
  21.    Official Protocol Standards" (STD 1) for the standardization state
  22.    and status of this protocol.  Distribution of this memo is unlimited.
  23.  
  24. Copyright Notice
  25.  
  26.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  27.  
  28. Abstract
  29.  
  30.    The IP Version 6 addressing architecture defines an "anycast" address
  31.    as an IPv6 address that is assigned to one or more network interfaces
  32.    (typically belonging to different nodes), with the property that a
  33.    packet sent to an anycast address is routed to the "nearest"
  34.    interface having that address, according to the routing protocols'
  35.    measure of distance.  This document defines a set of reserved anycast
  36.    addresses within each subnet prefix, and lists the initial allocation
  37.    of these reserved subnet anycast addresses.
  38.  
  39. 1. Introduction
  40.  
  41.    IP Version 6 (IPv6) defines a new type of address, known as an
  42.    "anycast" address, that allows a packet to be routed to one of a
  43.    number of different nodes all responding to the same address [2, 3].
  44.    The anycast address may be assigned to one or more network interfaces
  45.    (typically on different nodes), with the network delivering each
  46.    packet addressed to this address to the "nearest" interface based on
  47.    the notion of "distance" determined by the routing protocols in use.
  48.  
  49.    The uses of anycast addresses are still evolving, but such addresses
  50.    offer the potential for a number of important services [5, 6].  For
  51.    example, an anycast address may be used to allow nodes to access one
  52.    of a collection of servers providing a well-known service, without
  53.    manual configuration in each node of the list of servers; or an
  54.  
  55.  
  56.  
  57.  
  58. Johnson & Deering           Standards Track                     [Page 1]
  59.  
  60. RFC 2526         Reserved IPv6 Subnet Anycast Addresses       March 1999
  61.  
  62.  
  63.    anycast address may be used in a source route to force routing
  64.    through a specific internet service provider, without limiting
  65.    routing to a single specific router providing access to that ISP.
  66.  
  67.    IPv6 defines a required Subnet-Router anycast address [3] for all
  68.    routers within a subnet prefix, and allows additional anycast
  69.    addresses to be taken from the unicast address space.  This document
  70.    defines an additional set of reserved anycast addresses within each
  71.    subnet prefix, and lists the initial allocation of these reserved
  72.    subnet anycast addresses.
  73.  
  74.    The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
  75.    "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
  76.    document are to be interpreted as described in RFC 2119 [1].
  77.  
  78. 2. Format of Reserved Subnet Anycast Addresses
  79.  
  80.    Within each subnet, the highest 128 interface identifier values are
  81.    reserved for assignment as subnet anycast addresses.
  82.  
  83.    The construction of a reserved subnet anycast address depends on the
  84.    type of IPv6 addresses used within the subnet, as indicated by the
  85.    format prefix in the addresses.  In particular, for IPv6 address
  86.    types required to have 64-bit interface identifiers in EUI-64 format,
  87.    the universal/local bit MUST be set to 0 (local) in all reserved
  88.    subnet anycast addresses, to indicate that the interface identifier
  89.    in the address is not globally unique.  IPv6 addresses of this type
  90.    are currently specified to be those having format prefixes 001
  91.    through 111, except for Multicast Addresses (1111 1111) [3].
  92.  
  93.    Specifically, for IPv6 address types required to have to have 64-bit
  94.    interface identifiers in EUI-64 format, these reserved subnet anycast
  95.    addresses are constructed as follows:
  96.  
  97.    |              64 bits            |      57 bits     |   7 bits   |
  98.    +---------------------------------+------------------+------------+
  99.    |           subnet prefix         | 1111110111...111 | anycast ID |
  100.    +---------------------------------+------------------+------------+
  101.                                      |   interface identifier field  |
  102.  
  103.    For other IPv6 address types (that is, with format prefixes other
  104.    than those listed above), the interface identifier is not in EUI-64
  105.    format and may be other than 64 bits in length; these reserved subnet
  106.    anycast addresses for such address types are constructed as follows:
  107.  
  108.  
  109.  
  110.  
  111.  
  112.  
  113.  
  114. Johnson & Deering           Standards Track                     [Page 2]
  115.  
  116. RFC 2526         Reserved IPv6 Subnet Anycast Addresses       March 1999
  117.  
  118.  
  119.    |              n bits             |    121-n bits    |   7 bits   |
  120.    +---------------------------------+------------------+------------+
  121.    |           subnet prefix         | 1111111...111111 | anycast ID |
  122.    +---------------------------------+------------------+------------+
  123.                                      |   interface identifier field  |
  124.  
  125.    The subnet prefix here consists of all fields of the IPv6 address
  126.    except the interface identifier field.  The interface identifier
  127.    field in these reserved subnet anycast addresses is formed from a
  128.    7-bit anycast identifier ("anycast ID"), with the remaining (highest
  129.    order) bits filled with all one's; however, for interface identifiers
  130.    in EUI-64 format, the universal/local bit in the interface identifier
  131.    MUST be set to 0.  The anycast identifier identifies a particular
  132.    reserved anycast address within the subnet prefix, from the set of
  133.    reserved subnet anycast addresses.
  134.  
  135.    The motivation for reserving the highest addresses from each subnet
  136.    rather than the lowest addresses, is to avoid conflicting with some
  137.    existing official and unofficial uses of the low-numbered addresses
  138.    in a subnet.  For example, these low-numbered addresses are often
  139.    used for the ends of a point-to-point link, for tunnel endpoints, for
  140.    manually configured unicast addresses when a hardware token is not
  141.    available for the network interface, and even for manually configured
  142.    static addresses for the routers on a link.  Reserving only 128
  143.    values for anycast identifiers (rather than perhaps 256) means that
  144.    the minimum possible size of interface identifiers in an IPv6 address
  145.    is 8 bits (including room in the subnet for unicast addresses as well
  146.    as reserved subnet anycast addresses), allowing the division between
  147.    subnet prefix and interface identifier in this case to be
  148.    byte-aligned.
  149.  
  150.    As with all IPv6 anycast addresses [3], these reserved subnet anycast
  151.    addresses are allocated from the IPv6 unicast address space.  All
  152.    reserved subnet anycast addresses as defined in this document are
  153.    reserved on all links, with all subnet prefixes.  They MUST NOT be
  154.    used for unicast addresses assigned to any interface.
  155.  
  156. 3. List of Reserved Subnet Anycast Addresses
  157.  
  158.    Currently, the following anycast identifiers for these reserved
  159.    subnet anycast addresses are defined:
  160.  
  161.      Decimal   Hexadecimal     Description
  162.      -------   -----------     -----------
  163.       127         7F           Reserved
  164.       126         7E           Mobile IPv6 Home-Agents anycast [4]
  165.       0-125       00-7D        Reserved
  166.  
  167.  
  168.  
  169.  
  170. Johnson & Deering           Standards Track                     [Page 3]
  171.  
  172. RFC 2526         Reserved IPv6 Subnet Anycast Addresses       March 1999
  173.  
  174.  
  175.    Additional anycast identifiers are expected to be defined in the
  176.    future.
  177.  
  178. 4. Examples
  179.  
  180.    To illustrate the construction of reserved subnet anycast addresses,
  181.    this section details the construction of the reserved Mobile IPv6
  182.    Home-Agents subnet anycast address [4].  As noted in Section 3, the
  183.    7-bit anycast identifier for the Mobile IPv6 Home-Agents anycast
  184.    address is 126 (decimal) or 7E (hexadecimal).
  185.  
  186.    For IPv6 addresses containing a format prefix indicating that
  187.    interface identifiers are required to be 64 bits in length and are
  188.    required to be in EUI-64 format (currently format prefixes 001
  189.    through 111, except for 1111 1111 [3]), the reserved Mobile IPv6
  190.    Home-Agents subnet anycast address consists of the 64-bit subnet
  191.    prefix followed by the 64-bit interface identifier shown below:
  192.  
  193.    |0              1|1              3|3              4|4              6|
  194.    |0              5|6              1|2              7|8              3|
  195.    +----------------+----------------+----------------+----------------+
  196.    |1111110111111111|1111111111111111|1111111111111111|1111111111111110|
  197.    +----------------+----------------+----------------+----------------+
  198.           ^                                                     ^^^^^^^
  199.           +--- universal/local bit        anycast identifier ---+-----+
  200.  
  201.    For other IPv6 address types, the interface identifier may be other
  202.    than 64 bits in length and is not in EUI-64 format.  In this example,
  203.    assume that the length of the interface identifier is 64 bits, to
  204.    allow clear comparison with the example given above (although
  205.    interface identifiers of lengths other than 64 bits follow the same
  206.    general construction of the interface identifier shown here).  In
  207.    this case, the reserved Mobile IPv6 Home-Agents subnet anycast
  208.    address consists of the 64-bit subnet prefix followed by the 64-bit
  209.    interface identifier shown below:
  210.  
  211.    |0              1|1              3|3              4|4              6|
  212.    |0              5|6              1|2              7|8              3|
  213.    +----------------+----------------+----------------+----------------+
  214.    |1111111111111111|1111111111111111|1111111111111111|1111111111111110|
  215.    +----------------+----------------+----------------+----------------+
  216.                                                                 ^^^^^^^
  217.                                           anycast identifier ---+-----+
  218.  
  219.  
  220.  
  221.  
  222.  
  223.  
  224.  
  225.  
  226. Johnson & Deering           Standards Track                     [Page 4]
  227.  
  228. RFC 2526         Reserved IPv6 Subnet Anycast Addresses       March 1999
  229.  
  230.  
  231. 5. IANA Considerations
  232.  
  233.    This document defines a set of reserved subnet anycast addresses,
  234.    based on a set of anycast identifiers within each subnet prefix in
  235.    the IPv6 unicast address space.  As future needs arise, new anycast
  236.    identifiers may be defined.  Such anycast identifiers MUST be
  237.    reserved within all subnet prefixes, and so the assignment of these
  238.    anycast identifiers requires centralized administration.  New values
  239.    SHOULD be assigned in descending numerical order and are expected to
  240.    be assigned only with IESG approval.
  241.  
  242. 6. Security Considerations
  243.  
  244.    The use of any type of reserved anycast addresses poses a security
  245.    concern only in allowing potential attackers a well-known address to
  246.    attack.  By designating certain services to be located at specific
  247.    reserved anycast addresses, an attacker may more profitably focus an
  248.    attack against such a specific service.  Any such attack, however, is
  249.    best dealt with in each service that uses a reserved anycast address.
  250.  
  251.    RFC 1546, which originally proposed the idea of anycasting in IP,
  252.    also points out a number of security considerations with the use of
  253.    anycasting in general [6].
  254.  
  255. References
  256.  
  257.    [1] Bradner, S., "Key words for use in RFCs to indicate requirement
  258.        levels", BCP 14, RFC 2119, March 1997.
  259.  
  260.    [2] Deering, S. and R. Hinden, "Internet Protocol Version 6 (IPv6)
  261.        Specification", RFC 2460, December 1998.
  262.  
  263.    [3] Hinden, R. and S. Deering, "IP Version 6 Addressing
  264.        Architecture", RFC 2373, July 1998.
  265.  
  266.    [4] David B. Johnson and Charles Perkins, "Mobility Support in IPv6",
  267.        Work in Progress.
  268.  
  269.    [5] Steve King et al, "The Case for IPv6", Work in Progress.
  270.  
  271.    [6] Partridge, C., Mendez, T. and W. Milliken, "Host Anycasting
  272.        Service", RFC 1546, November 1993.
  273.  
  274.  
  275.  
  276.  
  277.  
  278.  
  279.  
  280.  
  281.  
  282. Johnson & Deering           Standards Track                     [Page 5]
  283.  
  284. RFC 2526         Reserved IPv6 Subnet Anycast Addresses       March 1999
  285.  
  286.  
  287. Authors' Addresses
  288.  
  289.    David B. Johnson
  290.    Carnegie Mellon University
  291.    Computer Science Department
  292.    5000 Forbes Avenue
  293.    Pittsburgh, PA  15213-3891
  294.    USA
  295.  
  296.    Phone:  +1 412 268-7399
  297.    Fax:    +1 412 268-5576
  298.    EMail:  dbj@cs.cmu.edu
  299.  
  300.  
  301.    Stephen E. Deering
  302.    Cisco Systems, Inc.
  303.    170 West Tasman Drive
  304.    San Jose, CA 95134-1706
  305.    USA
  306.  
  307.    Phone:  +1 408 527-8213
  308.    Fax:    +1 408 527-8254
  309.    EMail:  deering@cisco.com
  310.  
  311.  
  312.  
  313.  
  314.  
  315.  
  316.  
  317.  
  318.  
  319.  
  320.  
  321.  
  322.  
  323.  
  324.  
  325.  
  326.  
  327.  
  328.  
  329.  
  330.  
  331.  
  332.  
  333.  
  334.  
  335.  
  336.  
  337.  
  338. Johnson & Deering           Standards Track                     [Page 6]
  339.  
  340. RFC 2526         Reserved IPv6 Subnet Anycast Addresses       March 1999
  341.  
  342.  
  343. Full Copyright Statement
  344.  
  345.    Copyright (C) The Internet Society (1999).  All Rights Reserved.
  346.  
  347.    This document and translations of it may be copied and furnished to
  348.    others, and derivative works that comment on or otherwise explain it
  349.    or assist in its implementation may be prepared, copied, published
  350.    and distributed, in whole or in part, without restriction of any
  351.    kind, provided that the above copyright notice and this paragraph are
  352.    included on all such copies and derivative works.  However, this
  353.    document itself may not be modified in any way, such as by removing
  354.    the copyright notice or references to the Internet Society or other
  355.    Internet organizations, except as needed for the purpose of
  356.    developing Internet standards in which case the procedures for
  357.    copyrights defined in the Internet Standards process must be
  358.    followed, or as required to translate it into languages other than
  359.    English.
  360.  
  361.    The limited permissions granted above are perpetual and will not be
  362.    revoked by the Internet Society or its successors or assigns.
  363.  
  364.    This document and the information contained herein is provided on an
  365.    "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
  366.    TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING
  367.    BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION
  368.    HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF
  369.    MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.
  370.  
  371.  
  372.  
  373.  
  374.  
  375.  
  376.  
  377.  
  378.  
  379.  
  380.  
  381.  
  382.  
  383.  
  384.  
  385.  
  386.  
  387.  
  388.  
  389.  
  390.  
  391.  
  392.  
  393.  
  394. Johnson & Deering           Standards Track                     [Page 7]
  395.  
  396.