idnits 2.17.1 draft-ietf-ipngwg-site-prefixes-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 17 instances of too long lines in the document, the longest one being 1 character in excess of 72. == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. == There are 4 instances of lines with non-RFC3849-compliant IPv6 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 24, 1999) is 9074 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'IPv6-SA' is defined on line 843, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 849, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2460 (ref. 'IPv6') (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 2373 (ref. 'ADDR-ARCH') (Obsoleted by RFC 3513) ** Obsolete normative reference: RFC 2461 (ref. 'DISCOVERY') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 2101 (ref. 'ADDR-TODAY') == Outdated reference: A later version (-05) exists of draft-ietf-ipngwg-esd-analysis-04 -- Possible downref: Normative reference to a draft: ref. 'GSE-EVAL' == Outdated reference: A later version (-10) exists of draft-ietf-ipngwg-router-renum-08 ** Obsolete normative reference: RFC 2462 (ref. 'ADDRCONF') (Obsoleted by RFC 4862) ** Obsolete normative reference: RFC 2401 (ref. 'IPv6-SA') (Obsoleted by RFC 4301) ** Obsolete normative reference: RFC 2402 (ref. 'IPv6-AUTH') (Obsoleted by RFC 4302, RFC 4305) ** Obsolete normative reference: RFC 2406 (ref. 'IPv6-ESP') (Obsoleted by RFC 4303, RFC 4305) ** Obsolete normative reference: RFC 2535 (ref. 'DNSsec') (Obsoleted by RFC 4033, RFC 4034, RFC 4035) == Outdated reference: A later version (-24) exists of draft-ietf-mobileip-ipv6-07 ** Obsolete normative reference: RFC 2553 (ref. 'BSD-API') (Obsoleted by RFC 3493) Summary: 15 errors (**), 0 flaws (~~), 9 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 INTERNET-DRAFT Erik Nordmark, Sun Microsystems 2 June 24, 1999 4 Site prefixes in Neighbor Discovery 6 8 Status of this Memo 10 This document is an Internet-Draft and is in full conformance with 11 all provisions of Section 10 of RFC2026. 13 Internet-Drafts are working documents of the Internet Engineering 14 Task Force (IETF), its areas, and its working groups. Note that 15 other groups may also distribute working documents as Internet- 16 Drafts. 18 Internet-Drafts are draft documents valid for a maximum of six months 19 and may be updated, replaced, or obsoleted by other documents at any 20 time. It is inappropriate to use Internet-Drafts as reference 21 material or to cite them other than as "work in progress." 23 The list of current Internet-Drafts can be accessed at 24 http://www.ietf.org/ietf/1id-abstracts.txt 26 The list of Internet-Draft Shadow Directories can be accessed at 27 http://www.ietf.org/shadow.html. 29 This Internet Draft expires December 24, 1999. 31 Abstract 33 This document specifies extensions to IPv6 Neighbor Discovery to 34 carry site prefixes. The site prefixes are used to reduce the effect 35 of site renumbering by ensuring that the communication inside a site 36 uses site-local addresses. 38 This protocol requires that all IPv6 implementations, even those that 39 do not implement this protocol, ignore all site-local addresses that 40 they retrieve from the DNS when the AAAA or A6 RRset contain both 41 global and site-local addresses. If the RRset contains only site- 42 local addresses those addresses can be used. 44 Contents 46 Status of this Memo.......................................... 1 48 1. INTRODUCTION AND MOTIVATION.............................. 3 50 2. TERMINOLOGY.............................................. 4 51 2.1. What is a Site?..................................... 4 52 2.2. Requirements........................................ 4 54 3. OVERVIEW................................................. 5 55 3.1. Protocol Overview................................... 5 56 3.2. Mobile IP Implications.............................. 7 57 3.3. Assumptions......................................... 9 59 4. UPDATED PREFIX OPTION FORMAT............................. 10 61 5. CONCEPTUAL VARIABLES..................................... 11 63 6. SENDING RULES............................................ 12 65 7. RECEIVING RULES.......................................... 12 67 8. USING THE SITE PREFIXES.................................. 13 68 8.1. Host Name Lookups................................... 13 69 8.2. IPv6 Address Lookups................................ 15 71 9. MULTI-SITED NODES........................................ 16 72 9.1. Detecting that a Node is Multi-sited................ 16 73 9.2. Address Records for Multi-sited Nodes............... 17 74 9.3. Distinguishing Between Different Sites.............. 17 76 10. SECURITY CONSIDERATIONS................................. 18 78 REFERENCES................................................... 19 80 AUTHOR'S ADDRESS............................................. 20 82 APPENDIX A: CHANGES SINCE PREVIOUS DRAFT..................... 20 84 1. INTRODUCTION AND MOTIVATION 86 In order to maintain the aggregation of the global Internet routing 87 tables it might be necessary for whole sites to renumber to use 88 different prefixes for their global IPv6 addresses. Such renumbering 89 would not directly benefit the renumbered sites but instead be 90 necessary for the scaling of the Internet as a whole. 92 In order to increase the probability that such renumbering is viewed 93 favorably by the sites themselves, which see little or no direct 94 benefit, it is critical that both the effort of renumbering is kept 95 at a minimum and also that the risk associated with renumbering is as 96 small as possible. 98 The Stateless address autoconfiguration [ADDRCONF] and support for 99 router renumbering [ROUTER-RENUM] make it easier to renumber a site. 100 However, these protocols do not by themselves address long-running 101 TCP connections or cases where IP addresses have been stored in some 102 configuration file. Thus additional measures are needed to reduce 103 the cost of renumbering. 105 For many sites it is much more critical to maintain the internal 106 communication than the inter-site communication over the Internet. 107 Based on that observation this proposal tries to limit the effect of 108 a site renumbering one or more of its global prefixes by ensuring 109 that intra-site communication can use site-local addresses which 110 would not be affected by the site renumbering. With this proposal it 111 is possible to maintain internal long-running TCP connections or 112 otherwise store IPv6 addresses for longer time than would have been 113 possible without it. 115 As specified in [ADDR-TODAY] IP addresses are no longer temporally 116 unique. This implies, among other things, that applications should 117 not store IPv6 addresses without a mechanism for honoring the DNS 118 time-to-live and refreshing the IPv6 address. This protocol is not 119 intended to deter from that recommendation but is merely based on the 120 observation that the applications today might assume that IPv4 121 addresses are temporally unique and it is likely that some 122 applications might not be corrected in their behavior as they are 123 moved to IPv6. It would be unfortunate if such application 124 "brokenness" would lead sites to view site renumbering as a too risky 125 or a too costly operation. 127 This document does not address the general issues of renumbering such 128 as renumbering a single host or a subnet. It is targeted at site 129 renumbering. The proposal does not attempt to address how long- 130 running TCP connections going outside a site will survive the site 131 renumbering. 133 The author would like to acknowledge the contributions the IPNGWG 134 working group and in particular Mike O'Dell who pointed out the 135 importance of the problem, and Robert Elz who suggested this approach 136 to solving the problem. 138 2. TERMINOLOGY 140 This documents uses the terminology defined in [IPv6] and [DISCOVERY] 141 and in addition: 143 Multi-sited node 144 A node that has interfaces in multiple sites. 146 2.1. What is a Site? 148 This document does not attempt to define the concept of a "site", but 149 it does place some assumptions on such a definition: 151 - A site is an administratively controlled piece of topology that is 152 well-connected. It can be connected using tunnels including the 153 special form of tunnels (using routing headers and home address 154 options) defined in [MOBILE-IPv6]. 156 - A link can belong to zero or one site. This implies that an 157 interface can belong to at most one site. 159 - A node can have interfaces belonging to different sites. Such a 160 node is said to be multi-sited. 162 - A mobile node [MOBILE-IPv6] which has been assigned one or more 163 site-local addresses and moves outside the site which contains its 164 home address (its "home site") is considered to have one 165 interfaces which is part of the "home site". 167 2.2. Requirements 169 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 170 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 171 document, are to be interpreted as described in [KEYWORDS]. 173 3. OVERVIEW 175 The goal of this extension to Neighbor Discovery is to make 176 communication that is local to a single site use the site-local 177 addresses instead of the global addresses. If all communication 178 internal to a site uses site-local addresses then the site's global 179 addresses can be renumbered without having any affect on the internal 180 communication. Thus the risk associated with site renumbering is 181 lowered - applications that store IPv6 addresses and long-running TCP 182 connections will, as long as the communication is local to the site, 183 continue to operate across the renumbering of the site. 185 A few alternative solutions have been explored. An early proposal 186 was to place the site-local addresses in the name service (e.g., the 187 DNS) and make sure they are returned first in the list of addresses 188 returned to an application (to make it likely that the application 189 will use that address). That proposal has the disadvantage that the 190 name service must return different addresses depending on who asks 191 the question; if a node inside the site asks for an address it should 192 return the site-local address(es) but if a node outside the site asks 193 it must not return a site-local address. This is referred to as the 194 two-faced DNS. While some sites use a two-faced DNS today as part of 195 their firewall solution it would be rather unfortunate if each and 196 every site had to deploy such a solution. See [GSE-EVAL] for more 197 discussion. 199 An earlier version of this proposal took a different approach. The 200 name service would only contain global addresses and the routers 201 would advertise the global address prefixes assigned to the site 202 which the nodes would use to derive site-local addresses 203 corresponding to the global addresses returned from the name service. 204 That approach had the disadvantage that all nodes in a site would be 205 required to respond to their automatically derived site local 206 address. For instance, it was not possible to have certain mobile 207 nodes that would only be reachable using global addresses. 209 3.1. Protocol Overview 211 This version of the document takes a middle ground. The site-local 212 addresses, as well as the global addresses, are stored in the DNS 213 without requiring a "two-faced" DNS. All nodes are required to 214 ignore any site-local addresses retrieved from the DNS unless: 216 1) the DNS returned only site-local addresses (used in sites that 217 are not connected to the Internet i.e. where all the addresses 218 are site-local), or 220 2) they can determine that they are in the same site as the peer. 221 This determination is done by verifying that the retrieved 222 AAAA/A6 RRset for the peer includes one or more global addresses 223 that match the site prefixes advertised by the routers. 225 This protocol assumes that the routing infrastructure will be used to 226 distribute information about which prefixes belong to the local site. 227 This document only specifies how the site prefixes are distributed 228 from the routers to the hosts on each link. However, other protocols 229 such as [ROUTER-RENUM] might be extended to carry the site prefixes 230 to all routers in a site. The use of the routing infrastructure to 231 carry the site prefixes avoids the "two-faced" issue above - the 232 routers know which part of the network is inside the site thus they 233 can naturally prevent this information from being distributed outside 234 the site. 236 The protocol is based on each host maintaining a list of all the 237 currently active site prefixes. The site prefixes are periodically 238 advertised in Neighbor Discovery Router Advertisement messages and 239 each prefix has an associated lifetime. 241 Once a host has a list of prefixes that apply to its site it uses 242 this information to determine if the global addresses contained in a 243 AAAA/A6 RRset is part of its site. If this is the case then the host 244 can use any site-local addresses contained in that AAAA/A6 RRset. 245 Otherwise any site-local addresses contained in that RRset must be 246 ignored. A node should prefer the site-local addresses over the 247 global addresses e.g. by having the applications try the site-local 248 addresses before or instead of the global addresses. 250 The reverse lookup (from an IPv6 address to a host name) is handled 251 by mapping a site-local address to the corresponding global addresses 252 as a fallback. Thus, if the address being looked up is a site-local 253 address and the reverse lookup for that address fails the host 254 constructs the corresponding global addresses using the list of site 255 prefixes and performs a reverse lookup on those addresses until a 256 match is found. 258 It is expected that both the forward and reverse lookup rules can be 259 hidden from applications by implementing them as part of the library 260 that handles host name lookups. 262 3.2. Mobile IP Implications 264 A mobile node which moves outside its "home site" must maintain the 265 "home site-local addresses" for continued communication with nodes in 266 its "home site". This implies that such a mobile node conceptually 267 will have one interface (for the traffic destined to and from its 268 home site) which is assigned the home site-local addresses in 269 addition to its other interfaces which might be part of the visited 270 site. 272 A mobile node may choose to autoconfigure site-local addresses in the 273 visited site. However, such addresses add complexity to the mobile 274 node with little or no benefit. Thus it is recommended that mobile 275 nodes only autoconfigure global addresses when moving to links 276 outside its home site. 278 A mobile node needs to be able to detect when it has moved to a 279 different site. Thus in addition to the regular movement detection 280 in [MOBILE-IPv6] it should inspect the site prefixes in the Router 281 Advertisement messages to determine when it is outside its home site. 283 The remainder of this section specifies the operation of Mobile IP 284 when the mobile node is outside its home site. 286 The mobile node needs to retain any site-local addresses it was 287 assigned in its home site, but those site-local addresses should only 288 be used when communicating with nodes in its home site. 290 The binding updates must use a global address as the care-of-address. 292 There are no changes needed to Home Agents. The home agent needs to 293 select a proper source address when sending to a global address as is 294 expected of all IPv6 implementations - it should not use a site-local 295 source address when sending to a global destination address. 297 The only change needed to the Correspondent Nodes is to not use a 298 site-local source address when sending to a global destination: When 299 using a Routing Header to communicate with a mobile node that has a 300 global Care-of-Address the correspondent needs to include a Home 301 Address Option to carry its site-local source address and set the IP 302 source address field to one of its global addresses. 304 This additional use of the Home Address Option from the 305 correspondents ensures that all traffic to and from the mobile node 306 will have global source addresses. Thus the site-local addresses 307 will be "hidden" in 1) encapsulated headers, 2) routing headers, or 308 3) home address option. 310 Packets encapsulated to the mobile node will look like this: 312 Outer IP header destination address: 313 Registered care-of-address. A global address. 315 Outer IP header source address: 316 Global address assigned to home agent 318 Inner IP header destination address: 319 One of the mobile node's home addresses. Likely to be a 320 site-local address. 322 Inner IP header source address: 323 Sender of original packet. Likely to be a site-local 324 address. 326 Packets sent to the mobile node using routing headers: 328 IP header destination address: 329 Registered care-of-address. A global address. 331 IP header source address: 332 A global address is needed to match the scope of the 333 destination address. (This requirement is added by this 334 specification.) 336 Routing header: 337 The mobile node's home address which has been used for 338 this communication e.g. which identifies the TCP 339 connection. Likely to be a site-local address. 341 Home address option (This requirement is added by the 342 specification.): 343 The correspondent node's address which has been used for 344 this communication e.g. which identifies the TCP 345 connection. Likely to be a site-local address. 347 Packets sent from the mobile node to a site-local correspondent 348 address: 350 IP header destination address: 351 The correspondent node's global address. If this is not 352 known then the packet must be instead be encapsulated 353 and sent to the (global address of) the home agent which 354 can deliver the packet to the site-local destination 355 address. 357 IP header source address: 358 Mobile node's care-of-address. A global address. 360 Routing header: 361 The correspondent node's address which has been used for 362 this communication e.g. which identifies the TCP 363 connection. Likely to be a site-local address. 365 Home address option: 366 The mobile node's address which has been used for this 367 communication e.g. which identifies the TCP connection. 368 Likely to be a site-local address. 370 Packets sent from the mobile node to a global correspondent: 372 IP header destination address: 373 The correspondent node's global address. 375 IP header source address: 376 Mobile node's care-of-address. A global address. 378 Home address option: 379 The mobile node's address which has been used for this 380 communication e.g. which identifies the TCP connection. 381 Likely to be a site-local address. 383 3.3. Assumptions 385 The protocol assumes that the site uses a consistent subnet numbering 386 scheme across all its global addresses and its site-local addresses. 388 Thus, for every subnet in the site that uses both global and site- 389 local addresses, the 16-bit subnet ID field [ADDR-ARCH] for the 390 site-local address must have the same value as the Site-Local 391 Aggregator(s) field in the global addresses. However, it is possible 392 that some hosts (or whole subnets) only be configured with site-local 393 addresses in which case they will only be reachable from nodes within 394 the site. Is it also possible that some hosts (or subnets) only be 395 configured with global addresses in which case they will not benefit 396 from use of site locals. 398 4. UPDATED PREFIX OPTION FORMAT 400 The protocol adds two new fields using previously reserved parts of 401 the Prefix Information Option defined in [DISCOVERY]. 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 | Type | Length | Prefix Length |L|A|R|S|Resvd1 | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | Valid Lifetime | 409 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 410 | Preferred Lifetime | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Reserved2 | Site PLength | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | | 415 + + 416 | | 417 + Prefix + 418 | | 419 + + 420 | | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 423 New fields: 425 S 1-bit site prefix flag. When set indicates that 426 this prefix, in addition to what might be specified 427 by the L and A flags, should be used to create 428 site-local addresses when an address matches the 429 first Site PLength part of the prefix. 431 Site PLength 8-bit unsigned integer. This Site Prefix Length is 432 only valid when the S flag is set. The number of 433 leading bits in the Prefix that are valid. The 434 value ranges from 0 to 128. 436 The defined format above allows a single Prefix Information option to 437 carry a subnet prefix used for on-link and/or stateless address 438 autoconfiguration [ADDRCONF] together with a site prefix since the 439 site prefix(es) are normally sub-prefixes of the subnet prefixes. 441 For example, if the subnet prefix is 442 2000:1:2:653a::0/64 443 and the site prefix is: 444 2000:1:2::0/48 445 this can be encoded in a single Prefix Information option with Prefix 446 Length being 64, Site PLength being 48, the Prefix being 447 2000:1:2:653a::0, and the S flag being set. 449 5. CONCEPTUAL VARIABLES 451 This document makes use of internal conceptual variables to describe 452 protocol behavior and external variables that an implementation must 453 allow system administrators to change. The specific variable names, 454 how their values change, and how their settings influence protocol 455 behavior are provided to demonstrate protocol behavior. An 456 implementation is not required to have them in the exact form 457 described here, so long as its external behavior is consistent with 458 that described in this document. 460 Hosts will need to maintain the following pieces of information. 461 Like the prefix related information specified in [DISCOVERY] this 462 information recorded per interface but, except for multi-sited nodes, 463 used as a global list being the union of the information over all 464 interfaces. Multi-sited nodes need to use the information separately 465 for each site i.e. form the union over all interfaces that are 466 attached to a particular site. See Section 9 how multi-sited nodes 467 operate. 469 Site Prefix List 471 A list of the site prefixes that have been received 472 in Router Advertisement messages that have not yet 473 timed out. Each entry has an associated 474 invalidation timer value (extracted from the 475 advertisement) used to expire site prefixes when 476 they become invalid. A special "infinity" timer 477 value specifies that a prefix remains valid 478 forever, unless a new (finite) value is received in 479 a subsequent advertisement. 481 Note that the Site Prefix List is separate from the 482 list of on-link prefixes called Prefix List in 483 [DISCOVERY]. 485 The conceptual Router variable called AdvPrefixList in [DISCOVERY] is 486 extended to also contain site prefixes. Conceptually this can be 487 done by having each prefix both contain a AdvSubnetPrefixLength (the 488 length of the AdvPrefix as specified in [DISCOVERY]) and a 489 AdvSitePrefixLength field. If one of the length fields is zero the 490 prefix is not used as a on-link and/or addrconf prefix or a site 491 prefix, respectively. The same lifetime values will apply to both 492 the subnet and site prefix aspects of a prefix in the AdvPrefixList. 494 The above are conceptual variables; Implementations are free to 495 implement the router variables as a separate list for the site 496 prefixes and the existing Neighbor Discovery AdvPrefixList for subnet 497 prefixes. However, it is desirable that such implementations still 498 use a single Prefix Information option to encode both a site and a 499 subnet prefix when the site prefix is just a sub-prefix of the subnet 500 prefix (unless the lifetimes need to be different for the subnet and 501 site prefixes). 503 6. SENDING RULES 505 When a router is sending Prefix options as part of sending Router 506 Advertisement messages, in addition to the rules in [DISCOVERY], the 507 router performs the following operations: 509 o If the AdvSitePrefixLength field in the AdvPrefixList entry is 510 non-zero set the S flag in the Prefix option to one and set the 511 Site PLength to the AdvSitePrefixLength. 513 o Only if the AdvSubnetPrefixLength field is non-zero should the L- 514 bit and the A-bit be set from the AdvOnLinkFlag and the 515 AdvAutonomousFlag fields, respectively. 517 o The Prefix field and the lifetime fields are set is specified in 518 [DISCOVERY]. 520 7. RECEIVING RULES 522 The host receiving a valid Router Advertisement follows the rules as 523 specified in [DISCOVERY] with the following additions when processing 524 each received Prefix Information option. For each prefix that has 525 the S-flag set: 527 o If the Site PLength is zero then do nothing further. 529 o If the prefix is a link-local or a site-local prefix then do 530 nothing further. 532 o If the prefix is a multicast address then do nothing further. 534 o If the prefix is not already present in the Site Prefix List and 535 the Valid Lifetime is zero, then do nothing further. 537 o If the prefix is not already present in the Site Prefix List and 538 the Valid Lifetime is non-zero, then create a new entry for the 539 prefix in the Site Prefix List and initialize its invalidation 540 timer to the Valid Lifetime value in the Prefix Information 541 option. 543 o If the prefix is already present in the host's Site Prefix List as 544 the result of a previously-received advertisement, then reset its 545 invalidation timer to the Valid Lifetime value in the Prefix 546 Information option. If the new Lifetime value is zero, then 547 immediately remove the prefix from the Site Prefix List. 549 The bits in the Prefix after the first Site PLength bits MUST be 550 ignored when the prefix is entered in the Site Prefix List and/or 551 when it is compared against other site prefixes. These bits might be 552 non-zero when the Prefix option carries a subnet prefix in addition 553 to a site prefix. 555 Timing out a site prefix from the Site Prefix List SHOULD NOT affect 556 any existing communication. New communication will use the updated 557 Site Prefix List after performing a host name lookup. 559 8. USING THE SITE PREFIXES 561 The following rules apply when a node looks up host names and 562 addresses in a name service such as DNS. 564 8.1. Host Name Lookups 566 The node will inspect the AAAA/A6 RRset returned from DNS to check if 567 one or more of the global addresses belong to the same site as 568 itself. This is done by comparing all the global addresses against 569 all the prefixes in the Site Prefix List. If there are no matches 570 then the site-local addresses in the RRset must not be used. If 571 there are one or more matches then the node should prefer using the 572 site-local address(es) over the global addresses. This can be done 573 by sorting the addresses before they are returned to the application 574 and excluding the addresses that are subsumed by the site-local 575 addresses. 577 It is important that the site-local addresses are first in the sorted 578 list so that the applications try the site-local addresses before any 579 global address. Also, the matched global addresses are removed from 580 the list in order to prevent the applications from using global 581 addresses for communication that is local to the site. 583 A possible algorithm for doing these comparisons is as follows: 585 1) Assume the name service returns the global addresses G1, G2, 586 G3, ... Gn and the site-local addresses SL1, SL2, ... SLk. 587 Assume the prefixes in the Site Prefix List are SP1, SP2, ... 588 SPm. The Site PLength of each of the prefixes is Length(SPj). 590 2) If n is zero (i.e. no global addresses were returned) just hand 591 all the site local addresses SL1, .. SLk to the application. 593 3) Otherwise; for each Gi compare it against all the SPj. If the 594 first Length(SPj) bits of Gi are equal to the first Length(SPj) 595 bits of SPj then we have a match. If there is a match then 596 suppress Gi (do not hand it to the application). 598 3a) If there is one or more matches then give the application the 599 site-local addresses SL1, SL2, ... SLk inserted before the Gi 600 addresses that were not suppressed by rule 2) 602 3b) If there is no match the result is that the application only 603 gets the global addresses G1, ... Gn. 605 For example, if the name service returns these addresses for a 606 multihomed node: 607 2837:a:b:987:X:Y:W:Z1 608 2000:1:2:987:X:Y:W:Z1 609 fec0::987:X:Y:W:Z1 610 2837:a:b:34:X:Y:W:Z2 611 2000:1:2:34:X:Y:W:Z2 612 fec0::34:X:Y:W:Z2 613 2abc:77:66:23:X:Y:W:Z3 615 and the prefixes in the Site Prefix List are: 616 2837:a:b::0/48 617 2000:1:2::0/48 619 The resulting list that the application should use should be: 620 fec0::987:X:Y:W:Z1 621 fec0::34:X:Y:W:Z2 622 2abc:77:66:23:X:Y:W:Z3 624 If there is no match (e.g., the Site Prefix List is empty) the 625 resulting list that the application should use should be: 626 2837:a:b:987:X:Y:W:Z1 627 2000:1:2:987:X:Y:W:Z1 628 2837:a:b:34:X:Y:W:Z2 629 2000:1:2:34:X:Y:W:Z2 630 2abc:77:66:23:X:Y:W:Z3 632 8.2. IPv6 Address Lookups 634 It is not sufficient to handle the forward lookup. For instance, the 635 node that receives packets and/or connections from a site-local 636 address might have the desire to perform a reverse lookup to get a 637 host name. Thus these rules allow such a reverse lookup to succeed 638 as long as the Site Prefix List contains all the prefixes that apply 639 to the site. 641 A possible algorithm for doing this is as follows: 643 1) Assume the site-local address is SL and the prefixes in the 644 Site Prefix List are SP1, SP2, ... SPm. The Site PLength of 645 each of the prefixes is Length(SPj). 647 2) First perform a regular reverse lookup of the IPv6 address. If 648 the lookup succeeds return success to the application. If the 649 lookup fails and the IPv6 address is not a site-local address 650 report the failure to the application. 652 3) When the reverse lookup of a site-local address fails use the 653 Site Prefix List to construct global addresses corresponding to 654 the site-local address. This is done by taking each entry in 655 the Site Prefix List and using it to construct a global 656 address. For each of the SPj concatenate the first Length(SPj) 657 bits from SPj and the last (128 - Length(SPj)) bits from SL to 658 form a new address. Look up each of the resulting addresses 659 until a match is found. 661 For example, if the site-local address is: 662 fec0::987:X:Y:W:Z1 664 and the prefixes in the Site Prefix List are: 665 2837:a:b::0/48 666 2000:1:2::0/48 668 The addresses that should be tried in the reverse lookup are: 669 fec0::987:X:Y:W:Z1 670 2837:a:b:987:X:Y:W:Z1 671 2000:1:2:987:X:Y:W:Z1 673 9. MULTI-SITED NODES 675 A node potentially connected to multiple sites needs to be able to 677 o Detect that is it multi-sited. 679 o Be configured with the appropriate AAAA/A6 records in the DNS. 681 o Be able to distinguish between the different sites when 682 originating applications. 684 An alternative to multi-sited nodes is to not use any site-local 685 addresses for the node "close" to the site boundary (i.e. and not 686 list any site-local addresses in the DNS for that node). This will 687 force all traffic to and from that node to use global addresses 688 (except those few cases where link-local addresses are used). 690 9.1. Detecting that a Node is Multi-sited 692 A possible algorithm for detecting when a node is multi-sited is as 693 follows: 695 1) Inspect the Site Prefix List for all interfaces. 697 2) If an interface has no Site Prefix List entry ignore that 698 interface. 700 3) If two or more interfaces have one or more common Site Prefix 701 List entries group those interfaces together. 703 4) If the result is more than one group of interfaces the node is 704 considered to be multi-sited. 706 If the node detects that it is multi-sited and does not contain 707 support for site-local addresses in this environment it must at a 708 minimum log an event. It may also attempt to remove any site-local 709 addresses assigned to it from the DNS to avoid communication failure 710 should other nodes attempt to communicate with it using site-local 711 addresses. 713 9.2. Address Records for Multi-sited Nodes 715 A given AAAA/A6 RRset can only contain site-local addresses for one 716 site, since the site is implicit in the association between the 717 global and site-local addresses contained in the same RRset. 719 This implies that a multi-sited node that have a single domain name 720 with AAAA/A6 records for interfaces in multiple sites can not have 721 site-local addresses in that RRset. 723 The multi-sited node can have a different domain name for each site 724 to which it is connected, in order to enter site-local AAAA/A6 725 records in the DNS. 727 For example, a multi-sited node connected to two sites: 728 Site1: 729 Address 2000:1:2:987:X:Y:W:Z1 (A1) 730 Address fec0::987:X:Y:W:Z1 (A2) 731 Address 2000:1:2:34:X:Y:W:Z2 (A3) 732 Address fec0::34:X:Y:W:Z2 (A4) 733 Site prefix 2000:1:2::0/48 734 Site2: 735 Address 4444:a:b:34:X1:Y1:W1:Z3 (A5) 736 Address fec0:::34:X1:Y1:W1:Z3 (A6) 737 Site prefix 4444:a:b::0/48 738 This node could have 3 different host names: 739 foo.bar.site1.tla which list the AAAA/A6 records A1 through A4 741 foo.site2.tla which list the AAAA/A6 records A5 through A6 743 foo.net which list the global AAAA/A6 records A1, A3 and A5. 745 9.3. Distinguishing Between Different Sites 747 A multi-sited node needs to take additional care in applications and 748 in the protocol stack to qualify any site-local addresses with the 749 site unless all applications always associate an interface with each 750 IP address. (For instance, the use of getaddrinfo() as specified in 751 [BSD-API] allows the transparent passing of a site-id to the TCP/IP 752 stack in the sin6_scope_id without modifying the applications.) It 753 is recommended (but not required) that implementations which operate 754 at site boundaries have such support. 756 If the implementation does not have such support it must not pass any 757 site-local addresses to the applications since it will not be 758 possible for the IP layer to determine which site (i.e., the set of 759 interfaces attached to a site) to originate the packet on. 761 10. SECURITY CONSIDERATIONS 763 Router Advertisements are not required to be authenticated and even 764 if they are authenticated it is unclear whether or not there would be 765 a mechanisms to verify the authority of a particular node to send 766 Router Advertisements. 768 Neighbor Discovery uses the rule of HopCount 255 (set to 255 on 769 transmit and verified to be 255 on reception) to drop any Neighbor 770 Discovery packets that are sent non-neighboring nodes. This limits 771 any attack using ND to the neighbors. 773 Without authentication and authorization this new mechanisms 774 introduces a new type of denial of service attack. A node on the 775 link can send a router advertisement listing site prefixes that are 776 in fact not part of the site. For instance, it could advertise some 777 other sites prefix as a site prefix. Such an attack would result in 778 all nodes on the link to fail initiate any new communication with any 779 node in that site since they would accept the site-local AAAA/A6 780 records. 782 Also there is the possibility to return incorrect information for the 783 reverse lookup of IPv6 addresses. A node on the link can send a 784 router advertisement listing site prefixes that are in fact not part 785 of the site. For instance, it could advertise an incorrect site 786 prefix (e.g. a:b::0/48) which would make the reverse lookup of the 787 site local address fec0::X lookup a:b::X. 789 This could be viewed as allowing some form of indirect spoofing of 790 the addresses returned by the DNS independent whether or not the DNS 791 itself is secure. Thus introducing a secure DNS [DNSsec] would not 792 remove this form of "address spoofing". However, it seems like this 793 threat is no worse than the other threats in [DISCOVERY] where any 794 node on the link can intercept all packets sent on the link. 796 The packets used to discover site prefixes, just like all other 797 Neighbor Discovery protocol packet exchanges, can be authenticated 798 using the IP Authentication Header [IPv6-AUTH]. A node SHOULD 799 include an Authentication Header when sending Neighbor Discovery 800 packets if a security association for use with the IP Authentication 801 Header exists for the destination address. The security associations 802 may have been created through manual configuration or through the 803 operation of some key management protocol. 805 Received Authentication Headers in these packets, just like all 806 Neighbor Discovery packets, MUST be verified for correctness and 807 packets with incorrect authentication MUST be ignored. 809 Confidentiality issues are addressed by the IP Security Architecture 810 and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6- 811 ESP]. 813 REFERENCES 815 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 816 Requirement Levels", RFC 2119, March 1997. 818 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 819 6 (IPv6) Specification", RFC 2460, December 1998. 821 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 822 Addressing Architecture", RFC 2373, July 1998. 824 [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor 825 Discovery for IP Version 6 (IPv6)", RFC 2461, December 826 1998. 828 [ADDR-TODAY] B. Carpenter, J. Crowcroft, Y. Rekhter, "IPv4 Address 829 Behavior Today", RFC 2101, February 1997. 831 [GSE-EVAL] M. Crawford, A. Mankin, T. Narten, J. Stewart, L. Zhang, 832 "Separating Identifiers and Locators in Addresses: An 833 Analysis of the GSE Proposal for IPv6", Internet Draft, 834 draft-ietf-ipngwg-esd-analysis-04.txt. 836 [ROUTER-RENUM] M. Crawford, and R. Hinden, "Router Renumbering for 837 IPv6", Internet Draft, draft-ietf-ipngwg-router-renum- 838 08.txt. 840 [ADDRCONF] S. Thomson, T. Narten, "IPv6 Address Autoconfiguration", 841 RFC 2462, December 1998. 843 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 844 Protocol". RFC 2401, November 1998. 846 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, 847 November 1998. 849 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 850 RFC 2406, November 1998. 852 [DNSsec] D. Eastlake, C. Kaufman, "Domain Name System Security 853 Extensions", RFC 2535, March 1999. 855 [MOBILE-IPv6] D.B. Johnson, C. Perkins, "Mobility Support in IPv6", 856 Internet Draft, draft-ietf-mobileip-ipv6-07.txt, March 857 1999. 859 [BSD-API] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic 860 Socket Interface Extensions for IPv6", RFC 2553, March 861 19999. 863 AUTHOR'S ADDRESS 865 Erik Nordmark 866 Sun Microsystems, Inc. 867 901 San Antonio Road 868 Palo Alto, CA 94303 869 USA 871 phone: +1 650 786 5166 872 fax: +1 650 786 5896 873 email: nordmark@sun.com 875 APPENDIX A: CHANGES SINCE PREVIOUS DRAFT 877 The following changes have been made since version 02 of the draft. 879 o Moved the Site PLength field in the option format to make it 880 easier for [ROUTER-RENUM] to include the field in its option 881 format. 882 o Changed the rules about suppressing global addresses to only 883 suppress the ones that match the site prefixes. 884 o Refined the rules and text to handle case when site not connected 885 to the Internet i.e. when the DNS returns only site-local 886 addresses. 887 o Specified that a multi-sited node that have a single domain name 888 can use site-local addresses on at most one site. This is to 889 ensure that one AAAA/A6 RRset contains site-local addresses for at 890 most one site. The multihomed node must have a different domain 891 name for each site in it wants to use site-local addresses in all 892 its sites. 893 o Defined "multi-sited node" 894 o Clarified that a multi-sited node can, instead of ignoring all 895 site-locals, pass the full AAAA/A6 RRset (include the site-local 896 addresses) for nodes in directly attached sites *IF* the 897 applications and protocol stack can ensure that the communication 898 will use the proper site. (For instance, using mechanisms like 899 getaddrinfo() and the sin6_scope_id to pass the local site 900 identifier to the protocol stack transparent to the application.) 901 o Changed references from AAAA to AAAA/A6. 903 The following changes have been made since version 01 of the draft. 905 o Stated the assumptions on what a "site" is and how it is 906 configured. 908 o Changed the document to store site-local addresses in the DNS and 909 use filtering do ignore site-local addresses unless the sender and 910 receiver can be determined to belong to the same site. 912 o Added text describing interaction with mobile IP. 914 o Added rules for ignoring site-local entries from the DNS 916 o Make "turn off at site boundary" implementation dependent. 918 o Changed 'S' bit in prefix option not to conflict with [MOBILE- 919 IPv6]. 921 The following changes have been made since version 00 of the draft. 923 o Removed mention of routing protocols. 925 o Made the formed site-local addresses replace the global addresses 926 in the list returned to the application. This change prevents the 927 "accidental" use of a global address when the application tries 928 all of the returned addresses and for whatever reason it could not 929 reach the node when it tried the site-local address(es). 931 o Added text describing how to the mechanism is automatically 932 disabled on nodes which are Multihomed to multiple sites. 934 o Updated list of open issues.