INTERNET-DRAFT Erik Nordmark, Sun Microsystems July 30, 1997 Site prefixes in Neighbor Discovery 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 January 30, 1998. 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. draft-ietf-ipngwg-site-prefixes-00.txt [Page 1] INTERNET-DRAFT Site Prefixes in Neighbor Discovery July 1997 Contents Status of this Memo.......................................... 1 1. INTRODUCTION AND MOTIVATION.............................. 2 2. TERMINOLOGY.............................................. 4 2.1. Requirements........................................ 4 3. OVERVIEW................................................. 4 3.1. Assumptions......................................... 5 4. UPDATED PREFIX OPTION FORMAT............................. 5 4.1. CONCEPTUAL VARIABLES................................ 7 5. SENDING RULES............................................ 8 6. RECEIVING RULES.......................................... 8 7. USING THE SITE PREFIXES.................................. 9 7.1. Host Name Lookups................................... 9 7.2. IPv6 Address Lookups................................ 10 8. SECURITY CONSIDERATIONS.................................. 11 9. OPEN ISSUES.............................................. 12 REFERENCES................................................... 13 AUTHOR'S ADDRESS............................................. 14 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 draft-ietf-ipngwg-site-prefixes-00.txt [Page 2] INTERNET-DRAFT Site Prefixes in Neighbor Discovery July 1997 small as possible. The Stateless address autoconfiguration [ADDRCONF] and support for router renumbering [ROUTER-RENUM] make it easier to renumber a site. Also, the IPv6 routing protocols use link-local or site-local addresses to maintain their router adjacencies (as specified in [RIPNG], [OSPF] etc) so reduce the effect of site renumbering on the internal communication. 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 that are not effected 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 temporarily 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 temporarily 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. 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. draft-ietf-ipngwg-site-prefixes-00.txt [Page 3] INTERNET-DRAFT Site Prefixes in Neighbor Discovery July 1997 2. TERMINOLOGY This documents uses the terminology defined in [IPV6] and [DISCOVERY]. 2.1. Requirements The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 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. This proposal takes a different approach. The name service will only contain global addresses. 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 draft-ietf-ipngwg-site-prefixes-00.txt [Page 4] INTERNET-DRAFT Site Prefixes in Neighbor Discovery July 1997 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 the host constructs the site-local address that corresponds to the global address by replacing the site-prefix with the constant site-local prefix (fec0::0/48). This will result in one or more site-local addresses being generated. These addresses are then added to the set of addresses that will be used when communicating with the peer in such a way that the site-local addresses are tried before any of the global addresses. The host will perform the reverse operation when doing a reverse lookup (from an IPv6 address to a host name). If the address being looked up is a site-local address the host constructs the corresponding global addresses by 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 the applications by implementing them as part of the library that handles host name lookups. 3.1. 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-00.txt [Page 5] INTERNET-DRAFT Site Prefixes in Neighbor Discovery July 1997 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|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-00.txt [Page 6] INTERNET-DRAFT Site Prefixes in Neighbor Discovery July 1997 4.1. 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 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]. 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 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. draft-ietf-ipngwg-site-prefixes-00.txt [Page 7] INTERNET-DRAFT Site Prefixes in Neighbor Discovery July 1997 5. 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]. 6. 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 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 draft-ietf-ipngwg-site-prefixes-00.txt [Page 8] INTERNET-DRAFT Site Prefixes in Neighbor Discovery July 1997 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. 7. USING THE SITE PREFIXES The following rules apply when a node looks up host names and addresses in a name service such as DNS. 7.1. Host Name Lookups The goal is that when an address or multiple addresses are returned by the name server to the host that the host should, if one or more of those addresses match one of the site prefixes, prepend the corresponding site local address to the list of addresses that the application will attempt to use. It is important to prepend them to the list so that the applications try the site-local addresses before the corresponding global addresses in order to be able 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 addresses A1, A2, A3, ... An and 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 Ai compare it against all the SPj. If the first Length(SPj) bits of Ai are equal to the first Length(SPj) bits of SPj then construct the site-local address corresponding to Ai by concatenating the first Length(SPj) bits out of the site-local address (prefix) FEC0::0 and the last (128 - Length(SPj)) of Ai to form a new address. Add this address to the front of the list (i.e. before A1). 3) In some cases the above algorithm will add the same site-local address more than once to the list thus it is desirable to remove the duplicates from the resulting list. For example, if the name service returns these addresses for a draft-ietf-ipngwg-site-prefixes-00.txt [Page 9] INTERNET-DRAFT Site Prefixes in Neighbor Discovery July 1997 multihomed node: 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 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 (in order): fec0::987:X:Y:W:Z1 fec0::987:X:Y:W:Z1 (duplicate - can be removed) fec0::34:X:Y:W:Z2 fec0::34:X:Y:W:Z2 (duplicate - can be removed) 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 7.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 A and the prefixes in the Site Prefix List are SP1, SP2, ... SPm. The Site PLength of each of the prefixes is Length(SPj). 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 there is nothing more to do. 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 A to draft-ietf-ipngwg-site-prefixes-00.txt [Page 10] INTERNET-DRAFT Site Prefixes in Neighbor Discovery July 1997 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 address that should be tried in the reverse lookup are: 2837:a:b:987:X:Y:W:Z1 2000:1:2:987:X:Y:W:Z1 8. 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 all addresses (prefix 0::0/0) as a site-prefix). Such an attack would result in all nodes on the link to fail initiate any new communication with any node outside the site. Furthermore this mechanism can also be used by an attacker on the link to "redirect" an arbitrary global prefix to a node inside the site that has the same low-order part of the address as the intended recipient. Thus such an attack consists of one attacker on the link plus one cohort that has the same low order part of the address as the intended destination. 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 draft-ietf-ipngwg-site-prefixes-00.txt [Page 11] INTERNET-DRAFT Site Prefixes in Neighbor Discovery July 1997 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]. 9. OPEN ISSUES o This scheme has the assumption that the same subnet number (called Site-Local Aggregator(s) field for the global addresses) is assigned to a link and used for both site-local addresses and all global addresses that are advertised as site prefixes. Is this a reasonable assumption? o This proposal can be viewed as creating a security hole in a secure name service. The proposal tries to limit the security hole by only allowing the mapping to/from the site-local prefix i.e., it does not allow arbitrary remapping from one IPv6 address to another. When communication actually takes place after resolving a host name this hole is not any worse than the fact that any node on the link can intercept all packets sent on the link as described in [DISCOVERY]. But do we need to be concerned about the security of host name lookups and IP address lookups in the absence of any communication with the peer node? o Should the formed site-local addresses replace the global addresses in the list returned to the application? As currently specified a node might end up using a global address if it tries all of the returned addresses and for whatever reason it could not reach the node when it tried the site-local address(es).p o Do we need to specify a common API that e.g. the BIND DNS resolver can use to access the Site Prefix List? draft-ietf-ipngwg-site-prefixes-00.txt [Page 12] INTERNET-DRAFT Site Prefixes in Neighbor Discovery July 1997 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. [RIPNG] G. Malkin, R. Minnear, "RIPng for IPv6", RFC 2080, January 1997. [OSPF] R. Coltun, D. Ferguson, J. Moy, "OSPF for IPv6", Internet Draft, draft-ietf-ospf-ospfv6-04.txt. [ADDR-TODAY] B. Carpenter, J. Crowcroft, Y. Rekhter, "IPv4 Address 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-00.txt. [ROUTER-RENUM] M. Crawford, and R. Hinden, "Router Renumbering for IPv6", Internet Draft, draft-ietf-ipngwg-router-renum- 00.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. draft-ietf-ipngwg-site-prefixes-00.txt [Page 13] INTERNET-DRAFT Site Prefixes in Neighbor Discovery July 1997 AUTHOR'S ADDRESS Erik Nordmark Sun Microsystems, Inc. 901 San Antonio Road Palo Alto, CA 94303 USA phone: +1 415 786 5166 fax: +1 415 786 5896 email: nordmark@sun.com draft-ietf-ipngwg-site-prefixes-00.txt [Page 14]