idnits 2.17.1 draft-ietf-ipngwg-site-prefixes-05.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: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. == 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 (Februari 7, 2001) is 8542 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 870, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 876, 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) == Outdated reference: A later version (-04) exists of draft-ietf-ipngwg-scoping-arch-01 -- Possible downref: Normative reference to a draft: ref. 'SCOPE-ARCH' ** Obsolete normative reference: RFC 2461 (ref. 'DISCOVERY') (Obsoleted by RFC 4861) ** Downref: Normative reference to an Informational RFC: RFC 2101 (ref. 'ADDR-TODAY') -- Unexpected draft version: The latest known version of draft-ietf-ipngwg-esd-analysis is -05, but you're referring to -06. -- Possible downref: Normative reference to a draft: ref. 'GSE-EVAL' ** 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 (~~), 8 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark, Sun Microsystems 3 Februari 7, 2001 5 Site prefixes in Neighbor Discovery 7 9 Status of this Memo 11 This document is an Internet-Draft and is in full conformance with 12 all provisions of Section 10 of RFC2026. sp Internet-Drafts are 13 working documents of the Internet Engineering Task Force (IETF), its 14 areas, and its working groups. Note that other groups may also 15 distribute working documents as Internet-Drafts. 17 Internet-Drafts are draft documents valid for a maximum of six months 18 and may be updated, replaced, or obsoleted by other documents at any 19 time. It is inappropriate to use Internet-Drafts as reference 20 material or to cite them other than as "work in progress." 22 The list of current Internet-Drafts can be accessed at 23 http://www.ietf.org/ietf/1id-abstracts.txt 25 The list of Internet-Draft Shadow Directories can be accessed at 26 http://www.ietf.org/shadow.html. 28 This Internet Draft expires August 7, 2001. 30 Abstract 32 This document specifies extensions to IPv6 Neighbor Discovery to 33 carry site prefixes. The site prefixes are used to reduce the effect 34 of site renumbering by ensuring that the communication inside a site 35 uses site-local addresses. 37 This protocol requires that all IPv6 implementations, even those that 38 do not implement this protocol, ignore all site-local addresses that 39 they retrieve from the DNS when the AAAA or A6 RRset contain both 40 global and site-local addresses. If the RRset contains only site- 41 local addresses those addresses can be used. 43 Contents 45 Status of this Memo.......................................... 1 47 1. INTRODUCTION AND MOTIVATION.............................. 3 49 2. TERMINOLOGY.............................................. 4 50 2.1. What is a Site?..................................... 4 51 2.2. Requirements........................................ 5 53 3. OVERVIEW................................................. 5 54 3.1. Protocol Overview................................... 5 55 3.2. Mobile IP Implications.............................. 7 56 3.3. Assumptions......................................... 9 58 4. UPDATED PREFIX OPTION FORMAT............................. 10 60 5. CONCEPTUAL VARIABLES..................................... 11 62 6. SENDING RULES............................................ 12 64 7. RECEIVING RULES.......................................... 12 66 8. USING THE SITE PREFIXES.................................. 13 67 8.1. Host Name Lookups................................... 13 68 8.2. IPv6 Address Lookups................................ 15 70 9. MULTI-SITED NODES........................................ 16 71 9.1. Detecting that a Node is Multi-sited................ 16 72 9.2. Address Records for Multi-sited Nodes............... 17 73 9.3. Distinguishing Between Different Sites.............. 18 75 10. SECURITY CONSIDERATIONS................................. 18 77 REFERENCES................................................... 19 79 AUTHOR'S ADDRESS............................................. 20 81 APPENDIX A: CHANGES SINCE PREVIOUS DRAFT..................... 21 83 1. INTRODUCTION AND MOTIVATION 85 In order to maintain the aggregation of the global Internet routing 86 tables it might be necessary for whole sites to renumber to use 87 different prefixes for their global IPv6 addresses. Such renumbering 88 would not directly benefit the renumbered sites but instead be 89 necessary for the scaling of the Internet as a whole. 91 In order to increase the probability that such renumbering is viewed 92 favorably by the sites themselves, which see little or no direct 93 benefit, it is critical that both the effort of renumbering is kept 94 at a minimum and also that the risk associated with renumbering is as 95 small as possible. 97 The Stateless address autoconfiguration [ADDRCONF] and support for 98 router renumbering [ROUTER-RENUM] make it easier to renumber a site. 99 However, these protocols do not by themselves address long-running 100 TCP connections or cases where IP addresses have been stored in some 101 configuration file. Thus additional measures are needed to reduce 102 the cost of renumbering. 104 For many sites it is much more critical to maintain the internal 105 communication than the inter-site communication over the Internet. 106 Based on that observation this proposal tries to limit the effect of 107 a site renumbering one or more of its global prefixes by ensuring 108 that intra-site communication can use site-local addresses which 109 would not be affected by the site renumbering. With this proposal it 110 is possible to maintain internal long-running TCP connections or 111 otherwise store IPv6 addresses for longer time than would have been 112 possible without it. 114 As specified in [ADDR-TODAY] IP addresses are no longer temporally 115 unique. This implies, among other things, that applications should 116 not store IPv6 addresses without a mechanism for honoring the DNS 117 time-to-live and refreshing the IPv6 address. This protocol is not 118 intended to deter from that recommendation but is merely based on the 119 observation that the applications today might assume that IPv4 120 addresses are temporally unique and it is likely that some 121 applications might not be corrected in their behavior as they are 122 moved to IPv6. It would be unfortunate if such application 123 "brokenness" would lead sites to view site renumbering as a too risky 124 or a too costly operation. 126 This document does not address the general issues of renumbering such 127 as renumbering a single host or a subnet. It is targeted at site 128 renumbering. The proposal does not attempt to address how long- 129 running TCP connections going outside a site will survive the site 130 renumbering. 132 Note that using literal site-local addresses would survive a site 133 renumbering event but it would not survive other forms of renumbering 134 e.g. subnet or host renumbering. Thus nodes should use host names 135 instead of literal addresses for the same reasons as specified in 136 [ADDR-TODAY]. 138 The author would like to acknowledge the contributions the IPNGWG 139 working group and in particular Mike O'Dell who pointed out the 140 importance of the problem, and Robert Elz who suggested this approach 141 to solving the problem. 143 2. TERMINOLOGY 145 This documents uses the terminology defined in [IPv6] and [DISCOVERY] 146 and in addition: 148 Multi-sited node 149 A node that has interfaces in multiple sites. 151 2.1. What is a Site? 153 This document does not attempt to define the concept of a "site", but 154 it does place some assumptions on such a definition. These 155 assumptions are consistent with [SCOPE-ARCH]: 157 - A site is an administratively controlled piece of topology that is 158 well-connected. It can be connected using tunnels including the 159 special form of tunnels (using routing headers and home address 160 options) defined in [MOBILE-IPv6]. 162 - A link can belong to zero or one site. This implies that an 163 interface can belong to at most one site. 165 - A node can have interfaces belonging to different sites. Such a 166 node is said to be multi-sited. 168 - A mobile node [MOBILE-IPv6] which has been assigned one or more 169 site-local addresses and moves outside the site which contains its 170 home address (its "home site") is considered to have one 171 interfaces which is part of the "home site". 173 2.2. Requirements 175 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 176 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 177 document, are to be interpreted as described in [KEYWORDS]. 179 3. OVERVIEW 181 The goal of this extension to Neighbor Discovery is to make 182 communication that is local to a single site use the site-local 183 addresses instead of the global addresses. If all communication 184 internal to a site uses site-local addresses then the site's global 185 addresses can be renumbered without having any affect on the internal 186 communication. Thus the risk associated with site renumbering is 187 lowered - applications that store IPv6 addresses and long-running TCP 188 connections will, as long as the communication is local to the site, 189 continue to operate across the renumbering of the site. 191 A few alternative solutions have been explored. An early proposal 192 was to place the site-local addresses in the name service (e.g., the 193 DNS) and make sure they are returned first in the list of addresses 194 returned to an application (to make it likely that the application 195 will use that address). That proposal has the disadvantage that the 196 name service must return different addresses depending on who asks 197 the question; if a node inside the site asks for an address it should 198 return the site-local address(es) but if a node outside the site asks 199 it must not return a site-local address. This is referred to as the 200 two-faced DNS. While some sites use a two-faced DNS today as part of 201 their firewall solution it would be rather unfortunate if each and 202 every site had to deploy such a solution. See [GSE-EVAL] for more 203 discussion. 205 An earlier version of this proposal took a different approach. The 206 name service would only contain global addresses and the routers 207 would advertise the global address prefixes assigned to the site 208 which the nodes would use to derive site-local addresses 209 corresponding to the global addresses returned from the name service. 210 That approach had the disadvantage that all nodes in a site would be 211 required to respond to their automatically derived site local 212 address. For instance, it was not possible to have certain mobile 213 nodes that would only be reachable using global addresses. 215 3.1. Protocol Overview 217 This version of the document takes a middle ground. The site-local 218 addresses, as well as the global addresses, are stored in the DNS 219 without requiring a "two-faced" DNS. All nodes are required to 220 ignore any site-local addresses retrieved from the DNS unless: 222 1) the DNS returned only site-local addresses (used in sites that 223 are not connected to the Internet i.e. where all the addresses 224 are site-local), or 226 2) they can determine that they are in the same site as the peer. 227 This determination is done by verifying that the retrieved 228 AAAA/A6 RRset for the peer includes one or more global addresses 229 that match the site prefixes advertised by the routers. 231 This protocol assumes that the routing infrastructure will be used to 232 distribute information about which prefixes belong to the local site. 233 This document only specifies how the site prefixes are distributed 234 from the routers to the hosts on each link. However, other protocols 235 such as [ROUTER-RENUM] might be extended to carry the site prefixes 236 to all routers in a site. The use of the routing infrastructure to 237 carry the site prefixes avoids the "two-faced" issue above - the 238 routers know which part of the network is inside the site thus they 239 can naturally prevent this information from being distributed outside 240 the site. 242 The protocol is based on each host maintaining a list of all the 243 currently active site prefixes. The site prefixes are periodically 244 advertised in Neighbor Discovery Router Advertisement messages and 245 each prefix has an associated lifetime. 247 Once a host has a list of prefixes that apply to its site it uses 248 this information to determine if the global addresses contained in a 249 AAAA/A6 RRset is part of its site. If this is the case then the host 250 can use any site-local addresses contained in that AAAA/A6 RRset. 251 Otherwise any site-local addresses contained in that RRset must be 252 ignored. A node should prefer the site-local addresses over the 253 global addresses e.g. by having the applications try the site-local 254 addresses before or instead of the global addresses. 256 The reverse lookup (from an IPv6 address to a host name) is handled 257 by mapping a site-local address to the corresponding global addresses 258 as a fallback. Thus, if the address being looked up is a site-local 259 address and the reverse lookup for that address fails the host 260 constructs the corresponding global addresses using the list of site 261 prefixes and performs a reverse lookup on those addresses until a 262 match is found. 264 It is expected that both the forward and reverse lookup rules can be 265 hidden from applications by implementing them as part of the library 266 that handles host name lookups. 268 3.2. Mobile IP Implications 270 A mobile node which moves outside its "home site" must maintain the 271 "home site-local addresses" for continued communication with nodes in 272 its "home site". This implies that such a mobile node conceptually 273 will have one interface (for the traffic destined to and from its 274 home site) which is assigned the home site-local addresses in 275 addition to its other interfaces which might be part of the visited 276 site. 278 A mobile node may choose to autoconfigure site-local addresses in the 279 visited site. However, such addresses add complexity to the mobile 280 node with little or no benefit. Thus it is recommended that mobile 281 nodes only autoconfigure global addresses when moving to links 282 outside its home site. 284 A mobile node needs to be able to detect when it has moved to a 285 different site. Thus in addition to the regular movement detection 286 in [MOBILE-IPv6] it should inspect the site prefixes in the Router 287 Advertisement messages to determine when it is outside its home site. 289 The remainder of this section specifies the operation of Mobile IP 290 when the mobile node is outside its home site. 292 The mobile node needs to retain any site-local addresses it was 293 assigned in its home site, but those site-local addresses should only 294 be used when communicating with nodes in its home site. 296 The binding updates must use a global address as the care-of-address. 298 There are no changes needed to Home Agents. The home agent needs to 299 select a proper source address when sending to a global address as is 300 expected of all IPv6 implementations - it should not use a site-local 301 source address when sending to a global destination address. 303 The only change needed to the Correspondent Nodes is to not use a 304 site-local source address when sending to a global destination: When 305 using a Routing Header to communicate with a mobile node that has a 306 global Care-of-Address the correspondent needs to include a Home 307 Address Option to carry its site-local source address and set the IP 308 source address field to one of its global addresses. 310 This additional use of the Home Address Option from the 311 correspondents ensures that all traffic to and from the mobile node 312 will have global source addresses. Thus the site-local addresses 313 will be "hidden" in 1) encapsulated headers, 2) routing headers, or 314 3) home address option. 316 Packets encapsulated to the mobile node will look like this: 318 Outer IP header destination address: 319 Registered care-of-address. A global address. 321 Outer IP header source address: 322 Global address assigned to home agent 324 Inner IP header destination address: 325 One of the mobile node's home addresses. Likely to be a 326 site-local address. 328 Inner IP header source address: 329 Sender of original packet. Likely to be a site-local 330 address. 332 Packets sent to the mobile node using routing headers: 334 IP header destination address: 335 Registered care-of-address. A global address. 337 IP header source address: 338 A global address is needed to match the scope of the 339 destination address. (This requirement is added by this 340 specification.) 342 Routing header: 343 The mobile node's home 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 Home address option (This requirement is added by the 348 specification.): 349 The correspondent node's address which has been used for 350 this communication e.g. which identifies the TCP 351 connection. Likely to be a site-local address. 353 Packets sent from the mobile node to a site-local correspondent 354 address: 356 IP header destination address: 357 The correspondent node's global address. If this is not 358 known then the packet must be instead be encapsulated 359 and sent to the (global address of) the home agent which 360 can deliver the packet to the site-local destination 361 address. 363 IP header source address: 364 Mobile node's care-of-address. A global address. 366 Routing header: 367 The correspondent node's address which has been used for 368 this communication e.g. which identifies the TCP 369 connection. Likely to be a site-local address. 371 Home address option: 372 The mobile node's address which has been used for this 373 communication e.g. which identifies the TCP connection. 374 Likely to be a site-local address. 376 Packets sent from the mobile node to a global correspondent: 378 IP header destination address: 379 The correspondent node's global address. 381 IP header source address: 382 Mobile node's care-of-address. A global address. 384 Home address option: 385 The mobile node's address which has been used for this 386 communication e.g. which identifies the TCP connection. 387 Likely to be a site-local address. 389 3.3. Assumptions 391 The protocol assumes that the site uses a consistent subnet numbering 392 scheme across all its global addresses and its site-local addresses. 394 Thus, for every subnet in the site that uses both global and site- 395 local addresses, the 16-bit subnet ID field [ADDR-ARCH] for the 396 site-local address must have the same value as the Site-Local 397 Aggregator(s) field in the global addresses. However, it is possible 398 that some hosts (or whole subnets) only be configured with site-local 399 addresses in which case they will only be reachable from nodes within 400 the site. Is it also possible that some hosts (or subnets) only be 401 configured with global addresses in which case they will not benefit 402 from use of site locals. 404 4. UPDATED PREFIX OPTION FORMAT 406 The protocol adds two new fields using previously reserved parts of 407 the Prefix Information Option defined in [DISCOVERY]. 409 0 1 2 3 410 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 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 412 | Type | Length | Prefix Length |L|A|R|S|Resvd1 | 413 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 414 | Valid Lifetime | 415 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 416 | Preferred Lifetime | 417 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 418 | Reserved2 | Site PLength | 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 | | 421 + + 422 | | 423 + Prefix + 424 | | 425 + + 426 | | 427 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 429 New fields: 431 S 1-bit site prefix flag. When set indicates that 432 this prefix, in addition to what might be specified 433 by the L and A flags, should be used as specified 434 in this document (to accept and prefer site-local 435 addresses) when an address matches the first Site 436 PLength bits of the prefix. 438 Site PLength 8-bit unsigned integer. This Site Prefix Length is 439 only valid when the S flag is set. The number of 440 leading bits in the Prefix that are valid. The 441 value ranges from 0 to 128. Note that bits in the 442 Prefix past Site PLength bits can be non-zero and 443 MUST be ignored when comparing against the site 444 prefix. 446 The defined format above allows a single Prefix Information option to 447 carry a subnet prefix used for on-link and/or stateless address 448 autoconfiguration [ADDRCONF] together with a site prefix since the 449 site prefix(es) are normally sub-prefixes of the subnet prefixes. 451 For example, if the subnet prefix is 452 2000:1:2:653a::0/64 453 and the site prefix is: 454 2000:1:2::0/48 455 this can be encoded in a single Prefix Information option with Prefix 456 Length being 64, Site PLength being 48, the Prefix being 457 2000:1:2:653a::0, and the S flag being set. 459 5. CONCEPTUAL VARIABLES 461 This document makes use of internal conceptual variables to describe 462 protocol behavior and external variables that an implementation must 463 allow system administrators to change. The specific variable names, 464 how their values change, and how their settings influence protocol 465 behavior are provided to demonstrate protocol behavior. An 466 implementation is not required to have them in the exact form 467 described here, so long as its external behavior is consistent with 468 that described in this document. 470 Hosts will need to maintain the following pieces of information. 471 Like the prefix related information specified in [DISCOVERY] this 472 information recorded per interface but, except for multi-sited nodes, 473 used as a global list being the union of the information over all 474 interfaces. Multi-sited nodes need to use the information separately 475 for each site i.e. form the union over all interfaces that are 476 attached to a particular site. See Section 9 how multi-sited nodes 477 operate. 479 Site Prefix List 481 A list of the site prefixes that have been received 482 in Router Advertisement messages that have not yet 483 timed out. Each entry has an associated 484 invalidation timer value (extracted from the 485 advertisement) used to expire site prefixes when 486 they become invalid. A special "infinity" timer 487 value specifies that a prefix remains valid 488 forever, unless a new (finite) value is received in 489 a subsequent advertisement. 491 Note that the Site Prefix List is separate from the 492 list of on-link prefixes called Prefix List in 493 [DISCOVERY]. 495 The conceptual Router variable called AdvPrefixList in [DISCOVERY] is 496 extended to also contain site prefixes. Conceptually this can be 497 done by having each prefix both contain a AdvSubnetPrefixLength (the 498 length of the AdvPrefix as specified in [DISCOVERY]) and a 499 AdvSitePrefixLength field. If one of the length fields is zero the 500 prefix is not used as a on-link and/or addrconf prefix or a site 501 prefix, respectively. The same lifetime values will apply to both 502 the subnet and site prefix aspects of a prefix in the AdvPrefixList. 504 The above are conceptual variables; Implementations are free to 505 implement the router variables as a separate list for the site 506 prefixes and the existing Neighbor Discovery AdvPrefixList for subnet 507 prefixes. However, it is desirable that such implementations still 508 use a single Prefix Information option to encode both a site and a 509 subnet prefix when the site prefix is just a sub-prefix of the subnet 510 prefix (unless the lifetimes need to be different for the subnet and 511 site prefixes). 513 6. SENDING RULES 515 When a router is sending Prefix options as part of sending Router 516 Advertisement messages, in addition to the rules in [DISCOVERY], the 517 router performs the following operations: 519 o If the AdvSitePrefixLength field in the AdvPrefixList entry is 520 non-zero set the S flag in the Prefix option to one and set the 521 Site PLength to the AdvSitePrefixLength. 523 o Only if the AdvSubnetPrefixLength field is non-zero should the L- 524 bit and the A-bit be set from the AdvOnLinkFlag and the 525 AdvAutonomousFlag fields, respectively. 527 o The Prefix field and the lifetime fields are set is specified in 528 [DISCOVERY]. 530 7. RECEIVING RULES 532 The host receiving a valid Router Advertisement follows the rules as 533 specified in [DISCOVERY] with the following additions when processing 534 each received Prefix Information option. For each prefix that has 535 the S-flag set: 537 o If the Site PLength is zero then do nothing further. 539 o If the prefix is a link-local or a site-local prefix then do 540 nothing further. 542 o If the prefix is a multicast address then do nothing further. 544 o If the prefix is not already present in the Site Prefix List and 545 the Valid Lifetime is zero, then do nothing further. 547 o If the prefix is not already present in the Site Prefix List and 548 the Valid Lifetime is non-zero, then create a new entry for the 549 prefix in the Site Prefix List and initialize its invalidation 550 timer to the Valid Lifetime value in the Prefix Information 551 option. 553 o If the prefix is already present in the host's Site Prefix List as 554 the result of a previously-received advertisement, then reset its 555 invalidation timer to the Valid Lifetime value in the Prefix 556 Information option. If the new Lifetime value is zero, then 557 immediately remove the prefix from the Site Prefix List. 559 The bits in the Prefix after the first Site PLength bits MUST be 560 ignored when the prefix is entered in the Site Prefix List and/or 561 when it is compared against other site prefixes. These bits might be 562 non-zero when the Prefix option carries a subnet prefix in addition 563 to a site prefix. 565 Timing out a site prefix from the Site Prefix List SHOULD NOT affect 566 any existing communication. New communication will use the updated 567 Site Prefix List after performing a host name lookup. 569 8. USING THE SITE PREFIXES 571 The following rules apply when a node looks up host names and 572 addresses in a name service such as DNS. 574 8.1. Host Name Lookups 576 The node will inspect the AAAA/A6 RRset returned from DNS to check if 577 one or more of the global addresses belong to the same site as 578 itself. This is done by comparing all the global addresses against 579 all the prefixes in the Site Prefix List. If there are no matches 580 then the site-local addresses in the RRset must not be used. If 581 there are one or more matches then the node should prefer using the 582 site-local address(es) over the global addresses. This can be done 583 by sorting the addresses before they are returned to the application 584 and excluding the addresses that are subsumed by the site-local 585 addresses. 587 It is important that the site-local addresses are first in the sorted 588 list so that the applications try the site-local addresses before any 589 global address. Also, the matched global addresses are removed from 590 the list in order to prevent the applications from using global 591 addresses for communication that is local to the site. An 592 alternative would be to keep both global and site-local addresses in 593 the list and order the list so that site-local addresses appear first 594 i.e. will be tried first by the application. The disadvantage of 595 doing that approach is that ot doesn't guarantee site-local 596 communication uses site-local addresses. For instance if a router is 597 broken when the application tries to connect the application might 598 fail to connect using the site-local address. When it tries to 599 connect using the global address the router might be back up. 601 A possible algorithm for doing these comparisons is as follows: 603 1) Assume the name service returns the global addresses G1, G2, 604 G3, ... Gn and the site-local addresses SL1, SL2, ... SLk. 605 Assume the prefixes in the Site Prefix List are SP1, SP2, ... 606 SPm. The Site PLength of each of the prefixes is Length(SPj). 608 2) If n is zero (i.e. no global addresses were returned) just hand 609 all the site local addresses SL1, .. SLk to the application. 611 3) Otherwise; for each Gi compare it against all the SPj. If the 612 first Length(SPj) bits of Gi are equal to the first Length(SPj) 613 bits of SPj then we have a match. If there is a match then 614 suppress Gi (do not hand it to the application). 616 3a) If there is one or more matches then give the application the 617 site-local addresses SL1, SL2, ... SLk inserted before the Gi 618 addresses that were not suppressed by rule 2) 620 3b) If there is no match the result is that the application only 621 gets the global addresses G1, ... Gn. 623 For example, if the name service returns these addresses for a 624 multihomed node: 625 2837:a:b:987:X:Y:W:Z1 626 2000:1:2:987:X:Y:W:Z1 627 fec0::987:X:Y:W:Z1 628 2837:a:b:34:X:Y:W:Z2 629 2000:1:2:34:X:Y:W:Z2 630 fec0::34:X:Y:W:Z2 631 2abc:77:66:23:X:Y:W:Z3 633 and the prefixes in the Site Prefix List are: 634 2837:a:b::0/48 635 2000:1:2::0/48 637 The resulting list that the application should use should be: 638 fec0::987:X:Y:W:Z1 639 fec0::34:X:Y:W:Z2 640 2abc:77:66:23:X:Y:W:Z3 642 If there is no match (e.g., the Site Prefix List is empty) the 643 resulting list that the application should use should be: 644 2837:a:b:987:X:Y:W:Z1 645 2000:1:2:987:X:Y:W:Z1 646 2837:a:b:34:X:Y:W:Z2 647 2000:1:2:34:X:Y:W:Z2 648 2abc:77:66:23:X:Y:W:Z3 650 Note that a minimal implementation can avoid these rules, and not see 651 the benefits of the mechanism. Such implementations MUST ignore 652 site-local addresses in the RRset unless the RRset contains no global 653 addresses. Thus they would only use site-local addresses in the case 654 when the site is not connected to the Internet. 656 8.2. IPv6 Address Lookups 658 It is not sufficient to handle the forward lookup. For instance, the 659 node that receives packets and/or connections from a site-local 660 address might have the desire to perform a reverse lookup to get a 661 host name. Thus these rules allow such a reverse lookup to succeed 662 as long as the Site Prefix List contains all the prefixes that apply 663 to the site. 665 A possible algorithm for doing this is as follows: 667 1) Assume the site-local address is SL and the prefixes in the 668 Site Prefix List are SP1, SP2, ... SPm. The Site PLength of 669 each of the prefixes is Length(SPj). 671 2) First perform a regular reverse lookup of the IPv6 address. If 672 the lookup succeeds return success to the application. If the 673 lookup fails and the IPv6 address is not a site-local address 674 report the failure to the application. 676 3) When the reverse lookup of a site-local address fails use the 677 Site Prefix List to construct global addresses corresponding to 678 the site-local address. This is done by taking each entry in 679 the Site Prefix List and using it to construct a global 680 address. For each of the SPj concatenate the first Length(SPj) 681 bits from SPj and the last (128 - Length(SPj)) bits from SL to 682 form a new address. Look up each of the resulting addresses 683 until a match is found. 685 For example, if the site-local address is: 686 fec0::987:X:Y:W:Z1 688 and the prefixes in the Site Prefix List are: 689 2837:a:b::0/48 690 2000:1:2::0/48 692 The addresses that should be tried in the reverse lookup are: 693 fec0::987:X:Y:W:Z1 694 2837:a:b:987:X:Y:W:Z1 695 2000:1:2:987:X:Y:W:Z1 697 9. MULTI-SITED NODES 699 A node potentially connected to multiple sites needs to be able to 701 o Detect that is it multi-sited. 703 o Be configured with the appropriate AAAA/A6 records in the DNS. 705 o Be able to distinguish between the different sites when 706 originating applications. 708 An alternative to multi-sited nodes is to not use any site-local 709 addresses for the node "close" to the site boundary (i.e. and not 710 list any site-local addresses in the DNS for that node). This will 711 force all traffic to and from that node to use global addresses 712 (except those few cases where link-local addresses are used). 714 9.1. Detecting that a Node is Multi-sited 716 A possible algorithm for detecting when a node is multi-sited is as 717 follows: 719 1) Inspect the Site Prefix List for all interfaces. 721 2) If an interface has no Site Prefix List entry ignore that 722 interface. 724 3) If two or more interfaces have one or more common Site Prefix 725 List entries group those interfaces together. 727 4) If the result is more than one group of interfaces the node is 728 considered to be multi-sited. 730 If the node detects that it is multi-sited and does not contain 731 support for site-local addresses in this environment it must at a 732 minimum log an event. It may also attempt to remove any site-local 733 addresses assigned to it from the DNS to avoid communication failure 734 should other nodes attempt to communicate with it using site-local 735 addresses. 737 9.2. Address Records for Multi-sited Nodes 739 A given AAAA/A6 RRset can only contain site-local addresses for one 740 site, since the site is implicit in the association between the 741 global and site-local addresses contained in the same RRset. 743 This implies that a multi-sited node that have a single domain name 744 with AAAA/A6 records for interfaces in multiple sites can not have 745 site-local addresses in that RRset. 747 The multi-sited node can have a different domain name for each site 748 to which it is connected, in order to enter site-local AAAA/A6 749 records in the DNS. 751 For example, a multi-sited node connected to two sites: 752 Site1: 753 Address 2000:1:2:987:X:Y:W:Z1 (A1) 754 Address fec0::987:X:Y:W:Z1 (A2) 755 Address 2000:1:2:34:X:Y:W:Z2 (A3) 756 Address fec0::34:X:Y:W:Z2 (A4) 757 Site prefix 2000:1:2::0/48 758 Site2: 759 Address 4444:a:b:34:X1:Y1:W1:Z3 (A5) 760 Address fec0:::34:X1:Y1:W1:Z3 (A6) 761 Site prefix 4444:a:b::0/48 762 This node could have 3 different host names: 763 foo.bar.site1.tla which list the AAAA/A6 records A1 through A4 765 foo.site2.tla which list the AAAA/A6 records A5 through A6 767 foo.net which list the global AAAA/A6 records A1, A3 and A5. 769 9.3. Distinguishing Between Different Sites 771 A multi-sited node needs to take additional care in applications and 772 in the protocol stack to qualify any site-local addresses with the 773 site unless all applications always associate an interface with each 774 IP address. (For instance, the use of getaddrinfo() as specified in 775 [BSD-API] allows the transparent passing of a site-id to the TCP/IP 776 stack in the sin6_scope_id without modifying the applications.) It 777 is recommended (but not required) that implementations which operate 778 at site boundaries have such support. 780 If the implementation does not have such support it must not pass any 781 site-local addresses to the applications since it will not be 782 possible for the IP layer to determine which site (i.e., the set of 783 interfaces attached to a site) to originate the packet on. 785 10. SECURITY CONSIDERATIONS 787 Router Advertisements are not required to be authenticated and even 788 if they are authenticated it is unclear whether or not there would be 789 a mechanisms to verify the authority of a particular node to send 790 Router Advertisements. 792 Neighbor Discovery uses the rule of HopCount 255 (set to 255 on 793 transmit and verified to be 255 on reception) to drop any Neighbor 794 Discovery packets that are sent non-neighboring nodes. This limits 795 any attack using ND to the neighbors. 797 Without authentication and authorization this new mechanisms 798 introduces a new type of denial of service attack. A node on the 799 link can send a router advertisement listing site prefixes that are 800 in fact not part of the site. For instance, it could advertise some 801 other sites prefix as a site prefix. Such an attack would result in 802 all nodes on the link to fail initiate any new communication with any 803 node in that site since they would accept the site-local AAAA/A6 804 records. 806 Also there is the possibility to return incorrect information for the 807 reverse lookup of IPv6 addresses. A node on the link can send a 808 router advertisement listing site prefixes that are in fact not part 809 of the site. For instance, it could advertise an incorrect site 810 prefix (e.g. a:b::0/48) which would make the reverse lookup of the 811 site local address fec0::X lookup a:b::X. 813 This could be viewed as allowing some form of indirect spoofing of 814 the addresses returned by the DNS independent whether or not the DNS 815 itself is secure. Thus introducing a secure DNS [DNSsec] would not 816 remove this form of "address spoofing". However, it seems like this 817 threat is no worse than the other threats in [DISCOVERY] where any 818 node on the link can intercept all packets sent on the link. 820 The packets used to discover site prefixes, just like all other 821 Neighbor Discovery protocol packet exchanges, can be authenticated 822 using the IP Authentication Header [IPv6-AUTH]. A node SHOULD 823 include an Authentication Header when sending Neighbor Discovery 824 packets if a security association for use with the IP Authentication 825 Header exists for the destination address. The security associations 826 may have been created through manual configuration or through the 827 operation of some key management protocol. 829 Received Authentication Headers in these packets, just like all 830 Neighbor Discovery packets, MUST be verified for correctness and 831 packets with incorrect authentication MUST be ignored. 833 Confidentiality issues are addressed by the IP Security Architecture 834 and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6- 835 ESP]. 837 REFERENCES 839 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 840 Requirement Levels", RFC 2119, March 1997. 842 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 843 6 (IPv6) Specification", RFC 2460, December 1998. 845 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 846 Addressing Architecture", RFC 2373, July 1998. 848 [SCOPE-ARCH] S. Deering, B.Haberman, B.Zill, "IP Version 6 Scoped 849 Address Architecture", draft-ietf-ipngwg-scoping-arch- 850 01.txt, July 2000. 852 [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor 853 Discovery for IP Version 6 (IPv6)", RFC 2461, December 854 1998. 856 [ADDR-TODAY] B. Carpenter, J. Crowcroft, Y. Rekhter, "IPv4 Address 857 Behavior Today", RFC 2101, February 1997. 859 [GSE-EVAL] M. Crawford, A. Mankin, T. Narten, J. Stewart, L. Zhang, 860 "Separating Identifiers and Locators in Addresses: An 861 Analysis of the GSE Proposal for IPv6", Internet Draft, 862 draft-ietf-ipngwg-esd-analysis-06.txt, July 2000. 864 [ROUTER-RENUM] M. Crawford, and R. Hinden, "Router Renumbering for 865 IPv6", RFC 2894, August 2000. 867 [ADDRCONF] S. Thomson, T. Narten, "IPv6 Address Autoconfiguration", 868 RFC 2462, December 1998. 870 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 871 Protocol". RFC 2401, November 1998. 873 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 2402, 874 November 1998. 876 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 877 RFC 2406, November 1998. 879 [DNSsec] D. Eastlake, C. Kaufman, "Domain Name System Security 880 Extensions", RFC 2535, March 1999. 882 [MOBILE-IPv6] D.B. Johnson, C. Perkins, "Mobility Support in IPv6", 883 Internet Draft, draft-ietf-mobileip-ipv6-07.txt, March 884 1999. 886 [BSD-API] R. Gilligan, S. Thomson, J. Bound, W. Stevens, "Basic 887 Socket Interface Extensions for IPv6", RFC 2553, March 888 19999. 890 AUTHOR'S ADDRESS 892 Erik Nordmark 893 Sun Microsystems Laboratories 894 29, Chemin du Viuex Chene 895 38240 Meylan, France 897 phone: +33 (0)4 76 18 88 03 898 fax: +33 (0)4 76 18 88 88 899 email: nordmark@sun.com 901 APPENDIX A: CHANGES SINCE PREVIOUS DRAFT 903 The following changes have been made since version 04 of the draft. 905 o Changed author's address. 907 The following changes have been made since version 03 of the draft. 909 o Removed remaining use of "create site-local" to make it clear that 910 site-local addresses are stored in the DNS and "filtered" by the 911 nodes. 913 The following changes have been made since version 02 of the draft. 915 o Moved the Site PLength field in the option format to make it 916 easier for [ROUTER-RENUM] to include the field in its option 917 format. 918 o Changed the rules about suppressing global addresses to only 919 suppress the ones that match the site prefixes. 920 o Refined the rules and text to handle case when site not connected 921 to the Internet i.e. when the DNS returns only site-local 922 addresses. 923 o Specified that a multi-sited node that have a single domain name 924 can use site-local addresses on at most one site. This is to 925 ensure that one AAAA/A6 RRset contains site-local addresses for at 926 most one site. The multihomed node must have a different domain 927 name for each site in it wants to use site-local addresses in all 928 its sites. 929 o Defined "multi-sited node" 930 o Clarified that a multi-sited node can, instead of ignoring all 931 site-locals, pass the full AAAA/A6 RRset (include the site-local 932 addresses) for nodes in directly attached sites *IF* the 933 applications and protocol stack can ensure that the communication 934 will use the proper site. (For instance, using mechanisms like 935 getaddrinfo() and the sin6_scope_id to pass the local site 936 identifier to the protocol stack transparent to the application.) 937 o Changed references from AAAA to AAAA/A6. 939 The following changes have been made since version 01 of the draft. 941 o Stated the assumptions on what a "site" is and how it is 942 configured. 944 o Changed the document to store site-local addresses in the DNS and 945 use filtering do ignore site-local addresses unless the sender and 946 receiver can be determined to belong to the same site. 948 o Added text describing interaction with mobile IP. 950 o Added rules for ignoring site-local entries from the DNS 952 o Make "turn off at site boundary" implementation dependent. 954 o Changed 'S' bit in prefix option not to conflict with [MOBILE- 955 IPv6]. 957 The following changes have been made since version 00 of the draft. 959 o Removed mention of routing protocols. 961 o Made the formed site-local addresses replace the global addresses 962 in the list returned to the application. This change prevents the 963 "accidental" use of a global address when the application tries 964 all of the returned addresses and for whatever reason it could not 965 reach the node when it tried the site-local address(es). 967 o Added text describing how to the mechanism is automatically 968 disabled on nodes which are Multihomed to multiple sites. 970 o Updated list of open issues.