idnits 2.17.1 draft-ietf-ipngwg-site-prefixes-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 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. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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 3 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 (November 21, 1997) is 9646 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 598, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 604, but no explicit reference was found in the text ** Obsolete normative reference: RFC 1883 (ref. 'IPv6') (Obsoleted by RFC 2460) ** Obsolete normative reference: RFC 1884 (ref. 'ADDR-ARCH') (Obsoleted by RFC 2373) ** Obsolete normative reference: RFC 1970 (ref. 'DISCOVERY') (Obsoleted by RFC 2461) ** 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-00 -- Possible downref: Normative reference to a draft: ref. 'GSE-EVAL' == Outdated reference: A later version (-10) exists of draft-ietf-ipngwg-router-renum-00 ** Obsolete normative reference: RFC 1971 (ref. 'ADDRCONF') (Obsoleted by RFC 2462) ** Obsolete normative reference: RFC 1825 (ref. 'IPv6-SA') (Obsoleted by RFC 2401) ** Obsolete normative reference: RFC 1826 (ref. 'IPv6-AUTH') (Obsoleted by RFC 2402) ** Obsolete normative reference: RFC 1827 (ref. 'IPv6-ESP') (Obsoleted by RFC 2406) ** Obsolete normative reference: RFC 2065 (ref. 'DNSsec') (Obsoleted by RFC 2535) Summary: 18 errors (**), 0 flaws (~~), 7 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 INTERNET-DRAFT Erik Nordmark, Sun Microsystems 3 November 21, 1997 5 Site prefixes in Neighbor Discovery 7 9 Status of this Memo 11 This document is an Internet-Draft. Internet-Drafts are working 12 documents of the Internet Engineering Task Force (IETF), its areas, 13 and its working groups. Note that other groups may also distribute 14 working documents as Internet-Drafts. 16 Internet-Drafts are draft documents valid for a maximum of six months 17 and may be updated, replaced, or obsoleted by other documents at any 18 time. It is inappropriate to use Internet-Drafts as reference 19 material or to cite them other than as ``work in progress.'' 21 To learn the current status of any Internet-Draft, please check the 22 ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow 23 Directories on ds.internic.net (US East Coast), nic.nordu.net 24 (Europe), ftp.isi.edu (US West Coast), or munnari.oz.au (Pacific 25 Rim). 27 Distribution of this memo is unlimited. 29 This Internet Draft expires May 21, 1998. 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 Contents 40 Status of this Memo.......................................... 1 42 1. INTRODUCTION AND MOTIVATION.............................. 3 44 2. TERMINOLOGY.............................................. 4 45 2.1. Requirements........................................ 4 47 3. OVERVIEW................................................. 4 48 3.1. Assumptions......................................... 5 50 4. UPDATED PREFIX OPTION FORMAT............................. 6 51 4.1. CONCEPTUAL VARIABLES................................ 7 53 5. SENDING RULES............................................ 8 55 6. RECEIVING RULES.......................................... 8 57 7. USING THE SITE PREFIXES.................................. 9 58 7.1. Host Name Lookups................................... 9 59 7.2. IPv6 Address Lookups................................ 10 61 8. MULTIHOMED TO MULTIPLE SITES............................. 11 62 8.1. Detecting site multihoming.......................... 11 64 9. SECURITY CONSIDERATIONS.................................. 12 66 10. OPEN ISSUES............................................. 13 68 REFERENCES................................................... 14 70 AUTHOR'S ADDRESS............................................. 15 72 APPENDIX A: CHANGES SINCE PREVIOUS DRAFT..................... 15 74 1. INTRODUCTION AND MOTIVATION 76 In order to maintain the aggregation of the global Internet routing 77 tables it might be necessary for whole sites to renumber to use 78 different prefixes for their global IPv6 addresses. Such renumbering 79 would not directly benefit the renumbered sites but instead be 80 necessary for the scaling of the Internet as a whole. 82 In order to increase the probability that such renumbering is viewed 83 favorably by the sites themselves, which see little or no direct 84 benefit, it is critical that both the effort of renumbering is kept 85 at a minimum and also that the risk associated with renumbering is as 86 small as possible. 88 The Stateless address autoconfiguration [ADDRCONF] and support for 89 router renumbering [ROUTER-RENUM] make it easier to renumber a site. 90 However, these protocols do not by themselves address long-running 91 TCP connections or cases where IP addresses have been stored in some 92 configuration file. Thus additional measures are needed to reduce 93 the risk of renumbering. 95 For many sites it is much more critical to maintain the internal 96 communication than the intra-site communication over the Internet. 97 Based on that observation this proposal tries to limit the effect of 98 a site renumbering one or more of its global prefixes by ensuring 99 that intra-site communication can use site-local addresses that are 100 not effected by the site renumbering. With this proposal it is 101 possible to maintain internal long-running TCP connections or 102 otherwise store IPv6 addresses for longer time than would have been 103 possible without it. 105 As specified in [ADDR-TODAY] IP addresses are no longer temporarily 106 unique. This implies, among other things, that applications should 107 not store IPv6 addresses without a mechanisms for honoring the DNS 108 time-to-live and refreshing the IPv6 address. This protocol is not 109 intended to deter from that recommendation but is merely based on the 110 observation that the applications today might assume that IPv4 111 addresses are temporarily unique and it is likely that some 112 applications might not be corrected in their behavior as they are 113 moved to IPv6. It would be unfortunate if such application 114 "brokenness" would lead sites to view site renumbering as a too risky 115 or a too costly operation. 117 This document does not address the general issues of renumbering such 118 as renumbering a single host or a subnet. It is targeted at site 119 renumbering. The proposal does not attempt to address how long- 120 running TCP connections going outside a site will survive the site 121 renumbering. 123 The author would like to acknowledge the contributions the IPNGWG 124 working group and in particular Mike O'Dell who pointed out the 125 importance of the problem, and Robert Elz who suggested this approach 126 to solving the problem. 128 2. TERMINOLOGY 130 This documents uses the terminology defined in [IPv6] and 131 [DISCOVERY]. 133 2.1. Requirements 135 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 136 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 137 document, are to be interpreted as described in [KEYWORDS]. 139 3. OVERVIEW 141 The goal of this extension to Neighbor Discovery is to make 142 communication that is local to a single site use the site-local 143 addresses instead of the global addresses. If all communication 144 internal to a site uses site-local addresses then the site's global 145 addresses can be renumbered without having any affect on the internal 146 communication. Thus the risk associated with site renumbering is 147 lowered - applications that store IPv6 addresses and long-running TCP 148 connections will, as long as the communication is local to the site, 149 continue to operate across the renumbering of the site. 151 A few alternative solutions have been explored. An early proposal 152 was to place the site-local addresses in the name service (e.g., the 153 DNS) and make sure they are returned first in the list of addresses 154 returned to an application (to make it likely that the application 155 will use that address). That proposal has the disadvantage that the 156 name service must return different addresses depending on who asks 157 the question; if a node inside the site asks for an address it should 158 return the site-local address(es) but if a node outside the site asks 159 it must not return a site-local address. This is referred to as the 160 two-faced DNS. While some sites use a two-faced DNS today as part of 161 their firewall solution it would be rather unfortunate if each and 162 every site had to deploy such a solution. See [GSE-EVAL] for more 163 discussion. 165 This proposal takes a different approach. The name service will only 166 contain global addresses. The routing infrastructure will be used to 167 distribute information about which prefixes belong to the local site. 168 This document only specifies how the site prefixes are distributed 169 from the routers to the hosts on each link. However, other protocols 170 such as [ROUTER-RENUM] might be extended to carry the site prefixes 171 to all routers in a site. The use of the routing infrastructure to 172 carry the site prefixes avoids the "two-faced" issue above - the 173 routers know which part of the network is inside the site thus they 174 can naturally prevent this information from being distributed outside 175 the site. 177 The protocol is based on each host maintaining a list of all the 178 currently active site prefixes. The site prefixes are periodically 179 advertised in Neighbor Discovery Router Advertisement messages and 180 each prefix has an associated lifetime. 182 Once a host has a list of the prefixes that apply to its site it uses 183 this information to determine if the global addresses returned by the 184 name service is part of its site. If this is the case the host 185 constructs the site-local address that corresponds to the global 186 address by replacing the site prefix with the constant site-local 187 prefix (fec0::0/48). This will result in one or more site-local 188 addresses being generated. These addresses are then added to the set 189 of addresses that will be used when communicating with the peer in 190 such a way that the site-local addresses are tried before any of the 191 global addresses. 193 The host will perform the reverse operation when doing a reverse 194 lookup (from an IPv6 address to a host name). If the address being 195 looked up is a site-local address the host constructs the 196 corresponding global addresses by using the list of site prefixes and 197 performs a reverse lookup on those addresses until a match is found. 199 It is expected that both the forward and reverse lookup rules can be 200 hidden from the applications by implementing them as part of the 201 library that handles host name lookups. 203 3.1. Assumptions 205 The protocol assumes that the site uses a consistent subnet numbering 206 scheme across all its global addresses and its site-local addresses. 208 Thus, for every subnet in the site, the 16-bit subnet ID field 209 [ADDR-ARCH] for the site-local address must have the same value as 210 the Site-Local Aggregator(s) field in the global addresses. 212 4. UPDATED PREFIX OPTION FORMAT 214 The protocol adds two new fields using previously reserved parts of 215 the Prefix Information Option defined in [DISCOVERY]. 217 0 1 2 3 218 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 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Type | Length | Prefix Length |L|A|S| Resvd1 | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Valid Lifetime | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Preferred Lifetime | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | Site PLength | Reserved2 | 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 | | 229 + + 230 | | 231 + Prefix + 232 | | 233 + + 234 | | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 New fields: 239 S 1-bit site prefix flag. When set indicates that 240 this prefix, in addition to what might be specified 241 by the L and A flags, should be used to create 242 site-local addresses when an address matches the 243 first Site PLength part of the prefix. 245 Site PLength 8-bit unsigned integer. This Site Prefix Length is 246 only valid when the S flag is set. The number of 247 leading bits in the Prefix that are valid. The 248 value ranges from 0 to 128. 250 The defined format above allows a single Prefix Information option to 251 carry a subnet prefix used for on-link and/or stateless address 252 autoconfiguration [ADDRCONF] together with a site prefix since the 253 site prefix(es) are normally sub-prefixes of the subnet prefixes. 255 For example, if the subnet prefix is 256 2000:1:2:653a::0/64 257 and the site prefix is: 258 2000:1:2::0/48 259 this can be encoded in a single Prefix Information option with Prefix 260 Length being 64, Site PLength being 48 and the Prefix being 261 2000:1:2:653a::0. 263 4.1. CONCEPTUAL VARIABLES 265 This document makes use of internal conceptual variables to describe 266 protocol behavior and external variables that an implementation must 267 allow system administrators to change. The specific variable names, 268 how their values change, and how their settings influence protocol 269 behavior are provided to demonstrate protocol behavior. An 270 implementation is not required to have them in the exact form 271 described here, so long as its external behavior is consistent with 272 that described in this document. 274 Hosts will need to maintain the following pieces of information. 275 Unlike the information specific in [DISCOVERY] this information is 276 not per interface but, for the bulk of this document, viewed as being 277 for the host as a whole. 279 Site Prefix List 281 A list of the site prefixes that have been received 282 in Router Advertisement messages that have not yet 283 timed out. Each entry has an associated 284 invalidation timer value (extracted from the 285 advertisement) used to expire site prefixes when 286 they become invalid. A special "infinity" timer 287 value specifies that a prefix remains valid 288 forever, unless a new (finite) value is received in 289 a subsequent advertisement. 291 Note that the Site Prefix List is separate from the 292 list of on-link prefixes called Prefix List in 293 [DISCOVERY]. 295 For normal operation the Site Prefix List is per node. However, in 296 order to discover that the node is multihomed to multiple sites the 297 site prefixes have to be tracked for each interface. 299 The conceptual Router variable called AdvPrefixList in [DISCOVERY] is 300 extended to also contain site prefixes. Conceptually this can be 301 done by having each prefix both contain a AdvSubnetPrefixLength and a 302 AdvSitePrefixLength field. If one of the length fields is zero the 303 prefix is not used as a on-link and/or addrconf prefix or a site 304 prefix, respectively. The same lifetime values will apply to both 305 the subnet and site prefix aspects of a prefix in the AdvPrefixList. 307 The above are conceptual variables; Implementations are free to 308 implement the router variables as a separate list for the site 309 prefixes and the existing Neighbor Discovery AdvPrefixList for subnet 310 prefixes. However, it is desirable that such implementations still 311 use a single Prefix Information option to encode both a site and a 312 subnet prefix when the site prefix is just a sub-prefix of the subnet 313 prefix. 315 5. SENDING RULES 317 When a router is sending Prefix options as part of sending Router 318 Advertisement messages in addition to the rules in [DISCOVERY] is 319 performs the following operations: 321 o If the AdvSitePrefixLength field in the AdvPrefixList entry is 322 non-zero set the S flag in the Prefix option to one and set the 323 Site PLength to the AdvSitePrefixLength. 325 o Only if the AdvSubnetPrefixLength field is non-zero should the L- 326 bit and the A-bit be set from the AdvOnLinkFlag and the 327 AdvAutonomousFlag fields, respectively. 329 o The Prefix field and the lifetime fields are set is specified in 330 [DISCOVERY]. 332 6. RECEIVING RULES 334 The host receiving a valid Router Advertisement follows the rules as 335 specified in [DISCOVERY] with the following additions when parsing 336 each received Prefix Information option. For each prefix that has 337 the S-flag set: 339 o If the Site PLength is zero ignore the prefix. 341 o If the prefix is the link-local or the site-local prefix ignore 342 the prefix. 344 o If the prefix is a multicast address ignore the prefix. 346 o If the prefix is not already present in the Site Prefix List and 347 the Valid Lifetime is zero, ignore the prefix. 349 o If the prefix is not already present in the Site Prefix List and 350 the Valid Lifetime is non-zero, create a new entry for the prefix 351 in the Site Prefix List and initialize its invalidation timer to 352 the Valid Lifetime value in the Prefix Information option. 354 o If the prefix is already present in the host's Site Prefix List as 355 the result of a previously-received advertisement, reset its 356 invalidation timer to the Valid Lifetime value in the Prefix 357 Information option. If the new Lifetime value is zero, 358 immediately remove the prefix from the Site Prefix List. 360 The bits in the Prefix after the first Site PLength bits MUST be 361 ignored when the prefix is entered in the Site Prefix List and/or 362 when it is compared against other site prefixes. These bits might be 363 non-zero when the Prefix option carries a subnet prefix in addition 364 to a site prefix. 366 Timing out a site prefix from the Site Prefix List SHOULD NOT affect 367 any existing communication. New communication will use the updated 368 Site Prefix List after performing a host name lookup. 370 7. USING THE SITE PREFIXES 372 The following rules apply when a node looks up host names and 373 addresses in a name service such as DNS. 375 7.1. Host Name Lookups 377 The goal is that when an address or multiple addresses are returned 378 by the name server to the host that the host should, if one or more 379 of those addresses match one of the site prefixes, prepend the 380 corresponding site local address to the list of addresses that the 381 application will attempt to use and remove the global address from 382 the list. 384 It is important to prepend them to the list so that the applications 385 try the site-local addresses before any global address. Also, the 386 matched global addresses are removed from the list in order to 387 prevent the applications from using global addresses for 388 communication that is local to the site. 390 A possible algorithm for doing these comparisons is as follows: 392 1) Assume the name service returns the addresses A1, A2, A3, ... 393 An and the prefixes in the Site Prefix List are SP1, SP2, ... 394 SPm. The Site PLength of each of the prefixes is Length(SPj). 396 2) For each Ai compare it against all the SPj. If the first 397 Length(SPj) bits of Ai are equal to the first Length(SPj) bits 398 of SPj then construct the site-local address corresponding to 399 Ai by concatenating the first Length(SPj) bits out of the 400 site-local address (prefix) FEC0::0 and the last (128 - 401 Length(SPj)) of Ai to form a new address. Add this address to 402 the front of the list (i.e. before A1) and remove Ai from the 403 list. 405 3) In some cases the above algorithm will create the same site- 406 local address more than once thus it is desirable to remove the 407 duplicates from the resulting list. 409 For example, if the name service returns these addresses for a 410 multihomed node: 411 2837:a:b:987:X:Y:W:Z1 412 2000:1:2:987:X:Y:W:Z1 413 2837:a:b:34:X:Y:W:Z2 414 2000:1:2:34:X:Y:W:Z2 415 2abc:77:66:23:X:Y:W:Z3 417 and the prefixes in the Site Prefix List are: 418 2837:a:b::0/48 419 2000:1:2::0/48 421 The resulting list that the application should use should be (in 422 order): 423 fec0::987:X:Y:W:Z1 424 fec0::987:X:Y:W:Z1 (duplicate - can be removed) 425 fec0::34:X:Y:W:Z2 426 fec0::34:X:Y:W:Z2 (duplicate - can be removed) 427 2abc:77:66:23:X:Y:W:Z3 429 7.2. IPv6 Address Lookups 431 It is not sufficient to handle the forward lookup. For instance, the 432 node that receives packets and/or connections from a site-local 433 address might have the desire to perform a reverse lookup to get a 434 host name. Thus these rules allow such a reverse lookup to succeed 435 as long as the Site Prefix List contains all the prefixes that apply 436 to the site. 438 A possible algorithm for doing this is as follows: 440 1) Assume the site-local address is A and the prefixes in the Site 441 Prefix List are SP1, SP2, ... SPm. The Site PLength of each of 442 the prefixes is Length(SPj). 444 2) First perform a regular reverse lookup of the IPv6 address. If 445 the lookup succeeds or the lookup fails and the IPv6 address is 446 not a site-local address there is nothing more to do. 448 3) When the reverse lookup of a site-local address fails use the 449 Site Prefix List to construct global addresses corresponding to 450 the site-local address. This is done by taking each entry in 451 the Site Prefix List and using it to construct a global 452 address. For each of the SPj concatenate the first Length(SPj) 453 bits from SPj and the last (128 - Length(SPj)) bits from A to 454 form a new address. Look up each of the resulting addresses 455 until a match is found. 457 For example, if the site-local address is: 458 fec0::987:X:Y:W:Z1 460 and the prefixes in the Site Prefix List are: 461 2837:a:b::0/48 462 2000:1:2::0/48 464 The addresses that should be tried in the reverse lookup are: 465 2837:a:b:987:X:Y:W:Z1 466 2000:1:2:987:X:Y:W:Z1 468 8. MULTIHOMED TO MULTIPLE SITES 470 If a node is multihomed to multiple sites the above scheme can not be 471 used unless all applications always associate an interface with each 472 IP address. 474 The algorithm outline below is able to detect when a node is site 475 multihomed so that the modifications in the host name lookup can be 476 disabled. However, this can be avoided if the site boundaries are 477 configured to be between nodes as opposed to "inside" a node. This 478 would make each node belong to at most one site with some interfaces 479 on the node belonging to a "DMZ" between the sites. 481 8.1. Detecting site multihoming 483 A possible algorithm for doing this is as follows: 485 1) Ignore all the interfaces for which there are no site prefixes. 487 2) For the remainder of interfaces group the interfaces which 488 share at least one site prefix together. 490 3) If the result is more than one grouping of interfaces the node 491 is considered to be multihomed to more than one site. 493 9. SECURITY CONSIDERATIONS 495 Router Advertisements are not required to be authenticated and even 496 if they are authenticated it is unclear whether or not there would be 497 a mechanisms to verify the authority of a particular node to send 498 Router Advertisements. 500 Neighbor Discovery uses the rule of HopCount 255 (set to 255 on 501 transmit and verified to be 255 on reception) to drop any Neighbor 502 Discovery packets that are sent non-neighboring nodes. This limits 503 any attack using ND to the neighbors. 505 Without authentication and authorization this new mechanisms 506 introduces a new type of denial of service attack. A node on the 507 link can send a router advertisement listing site prefixes that are 508 in fact not part of the site. For instance, it could advertise all 509 addresses (prefix 0::0/0) as a site prefix). Such an attack would 510 result in all nodes on the link to fail initiate any new 511 communication with any node outside the site. 513 Furthermore this mechanism can also be used by an attacker on the 514 link to "redirect" an arbitrary global prefix to a node inside the 515 site that has the same low-order part of the address as the intended 516 recipient. Thus such an attack consists of one attacker on the link 517 plus one cohort that has the same low order part of the address as 518 the intended destination. 520 This could be viewed as allowing some form of indirect spoofing of 521 the addresses returned by the DNS independent whether or not the DNS 522 itself is secure. Thus introducing a secure DNS [DNSsec] would not 523 remove this form of "address spoofing". However, it seems like this 524 threat is no worse than the other threats in [DISCOVERY] where any 525 node on the link can intercept all packets sent on the link. 527 The packets used to discover site prefixes, just like all other 528 Neighbor Discovery protocol packet exchanges, can be authenticated 529 using the IP Authentication Header [IPv6-AUTH]. A node SHOULD 530 include an Authentication Header when sending Neighbor Discovery 531 packets if a security association for use with the IP Authentication 532 Header exists for the destination address. The security associations 533 may have been created through manual configuration or through the 534 operation of some key management protocol. 536 Received Authentication Headers in these packets, just like all 537 Neighbor Discovery packets, MUST be verified for correctness and 538 packets with incorrect authentication MUST be ignored. 540 Confidentiality issues are addressed by the IP Security Architecture 541 and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6- 542 ESP]. 544 10. OPEN ISSUES 546 o This scheme has the assumption that the same subnet number (called 547 Site-Local Aggregator(s) field for the global addresses) is 548 assigned to a link and used for both site-local addresses and all 549 global addresses that are advertised as site prefixes. Is this a 550 reasonable assumption? 552 o This proposal can be viewed as creating a security hole in a 553 secure name service such as DNSsec. The proposal tries to limit 554 the security hole by only allowing the mapping to/from the site- 555 local prefix i.e., it does not allow arbitrary remapping from one 556 IPv6 address to another. When communication actually takes place 557 after resolving a host name this hole is not any worse than the 558 fact that any node on the link can intercept all packets sent on 559 the link as described in [DISCOVERY]. But do we need to be 560 concerned about the security of host name lookups and IP address 561 lookups in the absence of any communication with the peer node? 563 o Do we need to specify a common API that e.g. the BIND DNS resolver 564 can use to access the Site Prefix List? 566 o How should this handle a mobile node, which is communicating using 567 site-local addresses, when it moves outside the site? How would a 568 mobile node detect that it has moved outside a site? 570 REFERENCES 572 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 573 Requirement Levels", RFC 2119, March 1997. 575 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 576 6 (IPv6) Specification", RFC 1883, January 1996. 578 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 579 Addressing Architecture", RFC 1884, January 1996. 581 [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor 582 Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996. 584 [ADDR-TODAY] B. Carpenter, J. Crowcroft, Y. Rekhter, "IPv4 Address 585 Behavior Today", RFC 2101, February 1997. 587 [GSE-EVAL] M. Crawford, A. Mankin, T. Narten, J. Stewart, L. Zhang, 588 "IPng Analysis of the GSE Proposal", Internet Draft, 589 draft-ietf-ipngwg-esd-analysis-00.txt. 591 [ROUTER-RENUM] M. Crawford, and R. Hinden, "Router Renumbering for 592 IPv6", Internet Draft, draft-ietf-ipngwg-router-renum- 593 00.txt. 595 [ADDRCONF] S. Thomson, T. Narten, "IPv6 Address Autoconfiguration", 596 RFC 1971, August 1996. 598 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 599 Protocol". RFC 1825, August 1995. 601 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 1826, 602 August 1995. 604 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 605 RFC 1827, August 1995. 607 [DNSsec] D. Eastlake, C. Kaufman, "Domain Name System Security 608 Extensions", RFC 2065, January 1997. 610 AUTHOR'S ADDRESS 612 Erik Nordmark 613 Sun Microsystems, Inc. 614 901 San Antonio Road 615 Palo Alto, CA 94303 616 USA 618 phone: +1 650 786 5166 619 fax: +1 650 786 5896 620 email: nordmark@sun.com 622 APPENDIX A: CHANGES SINCE PREVIOUS DRAFT 624 The following changes have been made since version 00 of the draft. 626 o Removed mention of routing protocols. 628 o Made the formed site-local addresses replace the global addresses 629 in the list returned to the application. This change prevents the 630 "accidental" use of a global address when the application 631 tries all of the returned 632 addresses and for whatever reason it could not reach the node when 633 it tried the site-local address(es). 635 o Added describing how to the mechanism is automatically disabled on 636 nodes which are Multihomed to multiple sites. 638 o Updated list of open issues.