idnits 2.17.1 draft-ietf-ipngwg-site-prefixes-00.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 2 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 (July 30, 1997) is 9760 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) == Missing Reference: 'IPV6' is mentioned on line 128, but not defined == Unused Reference: 'IPv6' is defined on line 540, but no explicit reference was found in the text == Unused Reference: 'IPv6-SA' is defined on line 569, but no explicit reference was found in the text == Unused Reference: 'IPv6-ESP' is defined on line 575, 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) == Outdated reference: A later version (-08) exists of draft-ietf-ospf-ospfv6-04 ** 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 (~~), 10 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 July 30, 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 January 30, 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.............................. 2 44 2. TERMINOLOGY.............................................. 4 45 2.1. Requirements........................................ 4 47 3. OVERVIEW................................................. 4 48 3.1. Assumptions......................................... 5 50 4. UPDATED PREFIX OPTION FORMAT............................. 5 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. SECURITY CONSIDERATIONS.................................. 11 63 9. OPEN ISSUES.............................................. 12 65 REFERENCES................................................... 13 67 AUTHOR'S ADDRESS............................................. 14 69 1. INTRODUCTION AND MOTIVATION 71 In order to maintain the aggregation of the global Internet routing 72 tables it might be necessary for whole sites to renumber to use 73 different prefixes for their global IPv6 addresses. Such renumbering 74 would not directly benefit the renumbered sites but instead be 75 necessary for the scaling of the Internet as a whole. 77 In order to increase the probability that such renumbering is viewed 78 favorably by the sites themselves, which see little or no direct 79 benefit, it is critical that both the effort of renumbering is kept 80 at a minimum and also that the risk associated with renumbering is as 81 small as possible. 83 The Stateless address autoconfiguration [ADDRCONF] and support for 84 router renumbering [ROUTER-RENUM] make it easier to renumber a site. 85 Also, the IPv6 routing protocols use link-local or site-local 86 addresses to maintain their router adjacencies (as specified in 87 [RIPNG], [OSPF] etc) so reduce the effect of site renumbering on the 88 internal communication. However, these protocols do not by 89 themselves address long-running TCP connections or cases where IP 90 addresses have been stored in some configuration file. Thus 91 additional measures are needed to reduce the risk of renumbering. 93 For many sites it is much more critical to maintain the internal 94 communication than the intra-site communication over the Internet. 95 Based on that observation this proposal tries to limit the effect of 96 a site renumbering one or more of its global prefixes by ensuring 97 that intra-site communication can use site-local addresses that are 98 not effected by the site renumbering. With this proposal it is 99 possible to maintain internal long-running TCP connections or 100 otherwise store IPv6 addresses for longer time than would have been 101 possible without it. 103 As specified in [ADDR-TODAY] IP addresses are no longer temporarily 104 unique. This implies, among other things, that applications should 105 not store IPv6 addresses without a mechanisms for honoring the DNS 106 time-to-live and refreshing the IPv6 address. This protocol is not 107 intended to deter from that recommendation but is merely based on the 108 observation that the applications today might assume that IPv4 109 addresses are temporarily unique and it is likely that some 110 applications might not be corrected in their behavior as they are 111 moved to IPv6. It would be unfortunate if such application 112 "brokenness" would lead sites to view site renumbering as a too risky 113 or a too costly operation. 115 This document does not address the general issues of renumbering such 116 as renumbering a single host or a subnet. It is targeted at site 117 renumbering. The proposal does not attempt to address how long- 118 running TCP connections going outside a site will survive the site 119 renumbering. 121 The author would like to acknowledge the contributions the IPNGWG 122 working group and in particular Mike O'Dell who pointed out the 123 importance of the problem, and Robert Elz who suggested this approach 124 to solving the problem. 126 2. TERMINOLOGY 128 This documents uses the terminology defined in [IPV6] and 129 [DISCOVERY]. 131 2.1. Requirements 133 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 134 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 135 document, are to be interpreted as described in [KEYWORDS]. 137 3. OVERVIEW 139 The goal of this extension to Neighbor Discovery is to make 140 communication that is local to a single site use the site-local 141 addresses instead of the global addresses. If all communication 142 internal to a site uses site-local addresses then the site's global 143 addresses can be renumbered without having any affect on the internal 144 communication. Thus the risk associated with site renumbering is 145 lowered - applications that store IPv6 addresses and long-running TCP 146 connections will, as long as the communication is local to the site, 147 continue to operate across the renumbering of the site. 149 A few alternative solutions have been explored. An early proposal 150 was to place the site-local addresses in the name service (e.g., the 151 DNS) and make sure they are returned first in the list of addresses 152 returned to an application (to make it likely that the application 153 will use that address). That proposal has the disadvantage that the 154 name service must return different addresses depending on who asks 155 the question; if a node inside the site asks for an address it should 156 return the site-local address(es) but if a node outside the site asks 157 it must not return a site-local address. This is referred to as the 158 two-faced DNS. While some sites use a two-faced DNS today as part of 159 their firewall solution it would be rather unfortunate if each and 160 every site had to deploy such a solution. See [GSE-EVAL] for more 161 discussion. 163 This proposal takes a different approach. The name service will only 164 contain global addresses. The routing infrastructure will be used to 165 distribute information about which prefixes belong to the local site. 166 This document only specifies how the site-prefixes are distributed 167 from the routers to the hosts on each link. However, other protocols 168 such as [ROUTER-RENUM] might be extended to carry the site-prefixes 169 to all routers in a site. The use of the routing infrastructure to 170 carry the site-prefixes avoids the "two-faced" issue above - the 171 routers know which part of the network is inside the site thus they 172 can naturally prevent this information from being distributed outside 173 the site. 175 The protocol is based on each host maintaining a list of all the 176 currently active site prefixes. The site prefixes are periodically 177 advertised in Neighbor Discovery Router Advertisement messages and 178 each prefix has an associated lifetime. 180 Once a host has a list of the prefixes that apply to its site it uses 181 this information to determine if the global addresses returned by the 182 name service is part of its site. If this is the case the host 183 constructs the site-local address that corresponds to the global 184 address by replacing the site-prefix with the constant site-local 185 prefix (fec0::0/48). This will result in one or more site-local 186 addresses being generated. These addresses are then added to the set 187 of addresses that will be used when communicating with the peer in 188 such a way that the site-local addresses are tried before any of the 189 global addresses. 191 The host will perform the reverse operation when doing a reverse 192 lookup (from an IPv6 address to a host name). If the address being 193 looked up is a site-local address the host constructs the 194 corresponding global addresses by using the list of site prefixes and 195 performs a reverse lookup on those addresses until a match is found. 197 It is expected that both the forward and reverse lookup rules can be 198 hidden from the applications by implementing them as part of the 199 library that handles host name lookups. 201 3.1. Assumptions 203 The protocol assumes that the site uses a consistent subnet numbering 204 scheme across all its global addresses and its site-local addresses. 206 Thus, for every subnet in the site, the 16-bit subnet ID field 207 [ADDR-ARCH] for the site-local address must have the same value as 208 the Site-Local Aggregator(s) field in the global addresses. 210 4. UPDATED PREFIX OPTION FORMAT 212 The protocol adds two new fields using previously reserved parts of 213 the Prefix Information Option defined in [DISCOVERY]. 215 0 1 2 3 216 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 217 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 218 | Type | Length | Prefix Length |L|A|S| Resvd1 | 219 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 220 | Valid Lifetime | 221 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 222 | Preferred Lifetime | 223 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 224 | Site PLength | Reserved2 | 225 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 226 | | 227 + + 228 | | 229 + Prefix + 230 | | 231 + + 232 | | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 235 New fields: 237 S 1-bit site prefix flag. When set indicates that 238 this prefix, in addition to what might be specified 239 by the L and A flags, should be used to create 240 site-local addresses when an address matches the 241 first Site PLength part of the prefix. 243 Site PLength 8-bit unsigned integer. This Site Prefix Length is 244 only valid when the S flag is set. The number of 245 leading bits in the Prefix that are valid. The 246 value ranges from 0 to 128. 248 The defined format above allows a single Prefix Information option to 249 carry a subnet prefix used for on-link and/or stateless address 250 autoconfiguration [ADDRCONF] together with a site prefix since the 251 site prefix(es) are normally sub-prefixes of the subnet prefixes. 253 For example, if the subnet prefix is 254 2000:1:2:653a::0/64 255 and the site prefix is: 256 2000:1:2::0/48 257 this can be encoded in a single Prefix Information option with Prefix 258 Length being 64, Site PLength being 48 and the Prefix being 259 2000:1:2:653a::0. 261 4.1. CONCEPTUAL VARIABLES 263 This document makes use of internal conceptual variables to describe 264 protocol behavior and external variables that an implementation must 265 allow system administrators to change. The specific variable names, 266 how their values change, and how their settings influence protocol 267 behavior are provided to demonstrate protocol behavior. An 268 implementation is not required to have them in the exact form 269 described here, so long as its external behavior is consistent with 270 that described in this document. 272 Hosts will need to maintain the following pieces of information. 273 Unlike the information specific in [DISCOVERY] this information is 274 not per interface but for the host as a whole. 276 Site Prefix List - A list of the site prefixes that have been 277 received in Router Advertisement messages that have 278 not yet timed out. Each entry has an associated 279 invalidation timer value (extracted from the 280 advertisement) used to expire site prefixes when 281 they become invalid. A special "infinity" timer 282 value specifies that a prefix remains valid 283 forever, unless a new (finite) value is received in 284 a subsequent advertisement. 286 Note that the Site Prefix List is separate from the 287 list of on-link prefixes called Prefix List in 288 [DISCOVERY]. 290 The conceptual Router variable called AdvPrefixList in [DISCOVERY] is 291 extended to also contain site prefixes. Conceptually this can be 292 done by having each prefix both contain a AdvSubnetPrefixLength and a 293 AdvSitePrefixLength field. If one of the length fields is zero the 294 prefix is not used as a on-link and/or addrconf prefix or a site 295 prefix, respectively. The same lifetime values will apply to both 296 the subnet and site prefix aspects of a prefix in the AdvPrefixList. 298 The above are conceptual variables; Implementations are free to 299 implement the router variables as a separate list for the site 300 prefixes and the existing Neighbor Discovery AdvPrefixList for subnet 301 prefixes. However, it is desirable that such implementations still 302 use a single Prefix Information option to encode both a site and a 303 subnet prefix when the site prefix is just a sub-prefix of the subnet 304 prefix. 306 5. SENDING RULES 308 When a router is sending Prefix options as part of sending Router 309 Advertisement messages in addition to the rules in [DISCOVERY] is 310 performs the following operations: 312 o If the AdvSitePrefixLength field in the AdvPrefixList entry is 313 non-zero set the S flag in the Prefix option to one and set the 314 Site PLength to the AdvSitePrefixLength. 316 o Only if the AdvSubnetPrefixLength field is non-zero should the L- 317 bit and the A-bit be set from the AdvOnLinkFlag and the 318 AdvAutonomousFlag fields, respectively. 320 o The Prefix field and the lifetime fields are set is specified in 321 [DISCOVERY]. 323 6. RECEIVING RULES 325 The host receiving a valid Router Advertisement follows the rules as 326 specified in [DISCOVERY] with the following additions when parsing 327 each received Prefix Information option. For each prefix that has 328 the S-flag set: 330 o If the Site PLength is zero ignore the prefix. 332 o If the prefix is the link-local or the site-local prefix ignore 333 the prefix. 335 o If the prefix is a multicast address ignore the prefix. 337 o If the prefix is not already present in the Site Prefix List and 338 the Valid Lifetime is zero, ignore the prefix. 340 o If the prefix is not already present in the Site Prefix List and 341 the Valid Lifetime is non-zero, create a new entry for the prefix 342 in the Site Prefix List and initialize its invalidation timer to 343 the Valid Lifetime value in the Prefix Information option. 345 o If the prefix is already present in the host's Site Prefix List as 346 the result of a previously-received advertisement, reset its 347 invalidation timer to the Valid Lifetime value in the Prefix 348 Information option. If the new Lifetime value is zero, 349 immediately remove the prefix from the Site Prefix List. 351 The bits in the Prefix after the first Site PLength bits MUST be 352 ignored when the prefix is entered in the Site Prefix List and/or 353 when it is compared against other site prefixes. These bits might be 354 non-zero when the Prefix option carries a subnet prefix in addition 355 to a site prefix. 357 Timing out a site prefix from the Site Prefix List SHOULD NOT affect 358 any existing communication. New communication will use the updated 359 Site Prefix List after performing a host name lookup. 361 7. USING THE SITE PREFIXES 363 The following rules apply when a node looks up host names and 364 addresses in a name service such as DNS. 366 7.1. Host Name Lookups 368 The goal is that when an address or multiple addresses are returned 369 by the name server to the host that the host should, if one or more 370 of those addresses match one of the site prefixes, prepend the 371 corresponding site local address to the list of addresses that the 372 application will attempt to use. 374 It is important to prepend them to the list so that the applications 375 try the site-local addresses before the corresponding global 376 addresses in order to be able to prevent the applications from using 377 global addresses for communication that is local to the site. 379 A possible algorithm for doing these comparisons is as follows: 381 1) Assume the name service returns the addresses A1, A2, A3, ... 382 An and the prefixes in the Site Prefix List are SP1, SP2, ... 383 SPm. The Site PLength of each of the prefixes is Length(SPj). 385 2) For each Ai compare it against all the SPj. If the first 386 Length(SPj) bits of Ai are equal to the first Length(SPj) bits 387 of SPj then construct the site-local address corresponding to 388 Ai by concatenating the first Length(SPj) bits out of the 389 site-local address (prefix) FEC0::0 and the last (128 - 390 Length(SPj)) of Ai to form a new address. Add this address to 391 the front of the list (i.e. before A1). 393 3) In some cases the above algorithm will add the same site-local 394 address more than once to the list thus it is desirable to 395 remove the duplicates from the resulting list. 397 For example, if the name service returns these addresses for a 398 multihomed node: 399 2837:a:b:987:X:Y:W:Z1 400 2000:1:2:987:X:Y:W:Z1 401 2837:a:b:34:X:Y:W:Z2 402 2000:1:2:34:X:Y:W:Z2 403 2abc:77:66:23:X:Y:W:Z3 404 and the prefixes in the Site Prefix List are: 405 2837:a:b::0/48 406 2000:1:2::0/48 407 The resulting list that the application should use should be (in 408 order): 409 fec0::987:X:Y:W:Z1 410 fec0::987:X:Y:W:Z1 (duplicate - can be removed) 411 fec0::34:X:Y:W:Z2 412 fec0::34:X:Y:W:Z2 (duplicate - can be removed) 413 2837:a:b:987:X:Y:W:Z1 414 2000:1:2:987:X:Y:W:Z1 415 2837:a:b:34:X:Y:W:Z2 416 2000:1:2:34:X:Y:W:Z2 417 2abc:77:66:23:X:Y:W:Z3 419 7.2. IPv6 Address Lookups 421 It is not sufficient to handle the forward lookup. For instance, the 422 node that receives packets and/or connections from a site-local 423 address might have the desire to perform a reverse lookup to get a 424 host name. Thus these rules allow such a reverse lookup to succeed 425 as long as the Site Prefix List contains all the prefixes that apply 426 to the site. 428 A possible algorithm for doing this is as follows: 430 1) Assume the site-local address is A and the prefixes in the Site 431 Prefix List are SP1, SP2, ... SPm. The Site PLength of each of 432 the prefixes is Length(SPj). 434 2) First perform a regular reverse lookup of the IPv6 address. If 435 the lookup succeeds or the lookup fails and the IPv6 address is 436 not a site-local address there is nothing more to do. 438 3) When the reverse lookup of a site-local address fails use the 439 Site Prefix List to construct global addresses corresponding to 440 the site-local address. This is done by taking each entry in 441 the Site Prefix List and using it to construct a global 442 address. For each of the SPj concatenate the first Length(SPj) 443 bits from SPj and the last (128 - Length(SPj)) bits from A to 444 form a new address. Look up each of the resulting addresses 445 until a match is found. 447 For example, if the site-local address is: 448 fec0::987:X:Y:W:Z1 449 and the prefixes in the Site Prefix List are: 450 2837:a:b::0/48 451 2000:1:2::0/48 452 The address that should be tried in the reverse lookup are: 453 2837:a:b:987:X:Y:W:Z1 454 2000:1:2:987:X:Y:W:Z1 456 8. SECURITY CONSIDERATIONS 458 Router Advertisements are not required to be authenticated and even 459 if they are authenticated it is unclear whether or not there would be 460 a mechanisms to verify the authority of a particular node to send 461 Router Advertisements. 463 Neighbor Discovery uses the rule of HopCount 255 (set to 255 on 464 transmit and verified to be 255 on reception) to drop any Neighbor 465 Discovery packets that are sent non-neighboring nodes. This limits 466 any attack using ND to the neighbors. 468 Without authentication and authorization this new mechanisms 469 introduces a new type of denial of service attack. A node on the 470 link can send a router advertisement listing site-prefixes that are 471 in fact not part of the site. For instance, it could advertise all 472 addresses (prefix 0::0/0) as a site-prefix). Such an attack would 473 result in all nodes on the link to fail initiate any new 474 communication with any node outside the site. 476 Furthermore this mechanism can also be used by an attacker on the 477 link to "redirect" an arbitrary global prefix to a node inside the 478 site that has the same low-order part of the address as the intended 479 recipient. Thus such an attack consists of one attacker on the link 480 plus one cohort that has the same low order part of the address as 481 the intended destination. 483 This could be viewed as allowing some form of indirect spoofing of 484 the addresses returned by the DNS independent whether or not the DNS 485 itself is secure. Thus introducing a secure DNS [DNSsec] would not 486 remove this form of "address spoofing". However, it seems like this 487 threat is no worse than the other threats in [DISCOVERY] where any 488 node on the link can intercept all packets sent on the link. 490 The packets used to discover site prefixes, just like all other 491 Neighbor Discovery protocol packet exchanges, can be authenticated 492 using the IP Authentication Header [IPv6-AUTH]. A node SHOULD 493 include an Authentication Header when sending Neighbor Discovery 494 packets if a security association for use with the IP Authentication 495 Header exists for the destination address. The security associations 496 may have been created through manual configuration or through the 497 operation of some key management protocol. 499 Received Authentication Headers in these packets, just like all 500 Neighbor Discovery packets, MUST be verified for correctness and 501 packets with incorrect authentication MUST be ignored. 503 Confidentiality issues are addressed by the IP Security Architecture 504 and the IP Encapsulating Security Payload documents [IPv6-SA, IPv6- 505 ESP]. 507 9. OPEN ISSUES 509 o This scheme has the assumption that the same subnet number (called 510 Site-Local Aggregator(s) field for the global addresses) is 511 assigned to a link and used for both site-local addresses and all 512 global addresses that are advertised as site prefixes. Is this a 513 reasonable assumption? 515 o This proposal can be viewed as creating a security hole in a 516 secure name service. The proposal tries to limit the security 517 hole by only allowing the mapping to/from the site-local prefix 518 i.e., it does not allow arbitrary remapping from one IPv6 address 519 to another. When communication actually takes place after 520 resolving a host name this hole is not any worse than the fact 521 that any node on the link can intercept all packets sent on the 522 link as described in [DISCOVERY]. But do we need to be concerned 523 about the security of host name lookups and IP address lookups in 524 the absence of any communication with the peer node? 526 o Should the formed site-local addresses replace the global 527 addresses in the list returned to the application? As currently 528 specified a node might end up using a global address if it tries 529 all of the returned addresses and for whatever reason it could not 530 reach the node when it tried the site-local address(es).p 532 o Do we need to specify a common API that e.g. the BIND DNS resolver 533 can use to access the Site Prefix List? 535 REFERENCES 537 [KEYWORDS] S. Bradner, "Key words for use in RFCs to Indicate 538 Requirement Levels", RFC 2119, March 1997. 540 [IPv6] S. Deering, R. Hinden, Editors, "Internet Protocol, Version 541 6 (IPv6) Specification", RFC 1883, January 1996. 543 [ADDR-ARCH] S. Deering, R. Hinden, Editors, "IP Version 6 544 Addressing Architecture", RFC 1884, January 1996. 546 [DISCOVERY] T. Narten, E. Nordmark, and W. Simpson, "Neighbor 547 Discovery for IP Version 6 (IPv6)", RFC 1970, August 1996. 549 [RIPNG] G. Malkin, R. Minnear, "RIPng for IPv6", RFC 2080, January 550 1997. 552 [OSPF] R. Coltun, D. Ferguson, J. Moy, "OSPF for IPv6", Internet 553 Draft, draft-ietf-ospf-ospfv6-04.txt. 555 [ADDR-TODAY] B. Carpenter, J. Crowcroft, Y. Rekhter, "IPv4 Address 556 Behavior Today", RFC 2101, February 1997. 558 [GSE-EVAL] M. Crawford, A. Mankin, T. Narten, J. Stewart, L. Zhang, 559 "IPng Analysis of the GSE Proposal", Internet Draft, 560 draft-ietf-ipngwg-esd-analysis-00.txt. 562 [ROUTER-RENUM] M. Crawford, and R. Hinden, "Router Renumbering for 563 IPv6", Internet Draft, draft-ietf-ipngwg-router-renum- 564 00.txt. 566 [ADDRCONF] S. Thomson, T. Narten, "IPv6 Address Autoconfiguration", 567 RFC 1971, August 1996. 569 [IPv6-SA] R. Atkinson. "Security Architecture for the Internet 570 Protocol". RFC 1825, August 1995. 572 [IPv6-AUTH] R. Atkinson. "IP Authentication Header", RFC 1826, 573 August 1995. 575 [IPv6-ESP] R. Atkinson. "IP Encapsulating Security Payload (ESP)", 576 RFC 1827, August 1995. 578 [DNSsec] D. Eastlake, C. Kaufman, "Domain Name System Security 579 Extensions", RFC 2065, January 1997. 581 AUTHOR'S ADDRESS 583 Erik Nordmark 584 Sun Microsystems, Inc. 585 901 San Antonio Road 586 Palo Alto, CA 94303 587 USA 589 phone: +1 415 786 5166 590 fax: +1 415 786 5896 591 email: nordmark@sun.com