idnits 2.17.00 (12 Aug 2021) /tmp/idnits23041/draft-ietf-ipv6-ndproxy-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 16. -- Found old boilerplate from RFC 3978, Section 5.5 on line 761. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 772. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 779. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 785. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 752), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 38. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year -- 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.) -- Couldn't find a document date in the document -- date freshness check skipped. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. 'BRIDGE' ** Obsolete normative reference: RFC 2463 (ref. 'ICMPv6') (Obsoleted by RFC 4443) ** Obsolete normative reference: RFC 2461 (ref. 'ND') (Obsoleted by RFC 4861) == Outdated reference: draft-ietf-ipv6-node-requirements has been published as RFC 4294 ** Downref: Normative reference to an Informational draft: draft-ietf-ipv6-node-requirements (ref. 'NODEREQ') -- Obsolete informational reference (is this intentional?): RFC 1638 (ref. 'BCP') (Obsoleted by RFC 2878) -- Obsolete informational reference (is this intentional?): RFC 3315 (ref. 'DHCPv6') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. 'PD') (Obsoleted by RFC 8415) == Outdated reference: A later version (-02) exists of draft-daley-send-spnd-prob-01 Summary: 7 errors (**), 0 flaws (~~), 4 warnings (==), 11 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 IPv6 Working Group D. Thaler 3 INTERNET-DRAFT M. Talwar 4 October 20, 2005 Microsoft 5 Expires April 2006 C. Patel 6 All Play, No Work 8 Neighbor Discovery Proxies (ND Proxy) 9 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six 24 months and may be updated, replaced, or obsoleted by other 25 documents at any time. It is inappropriate to use Internet-Drafts 26 as reference material or to cite them other than as "work in 27 progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Copyright Notice 36 Draft ND Proxy October 2005 38 Copyright (C) The Internet Society (2005). All Rights Reserved. 40 Abstract 42 Bridging multiple links into a single entity has several 43 operational advantages. A single subnet prefix is sufficient to 44 support multiple physical links. There is no need to allocate 45 subnet numbers to the different networks, simplifying management. 46 Bridging some types of media requires network-layer support, 47 however. This document describes these cases and specifies the 48 IP-layer support that enables bridging under these circumstances. 50 1. Introduction 52 In the IPv4 Internet today, it is common for Network Address 53 Translators (NATs) [NAT] to be used to easily connect one or more 54 leaf links to an existing network without requiring any 55 coordination with the network service provider. Since NATs modify 56 IP addresses in packets, they are problematic for many IP 57 applications. As a result, it is desirable to address the problem 58 (for both IPv4 and IPv6) without the need for NATs, while still 59 maintaining the property that no explicit cooperation from the 60 router is needed. 62 One common solution is IEEE 802 bridging, as specified in 63 [BRIDGE]. It is expected that whenever possible links will be 64 bridged at the link layer using classic bridge technology [BRIDGE] 65 as opposed to using the mechanisms herein. However, classic 66 bridging at the data-link layer has the following limitations 67 (among others): 69 o It requires the ports to support promiscuous mode. 71 o It requires all ports to support the same type of link-layer 72 addressing (in particular, IEEE 802 addressing). 74 As a result, two common scenarios, described below, are not 75 solved, and it is these two scenarios we specifically target in 76 this document. While the mechanism described herein may apply to 77 other scenarios as well, we will concentrate our discussion on 78 these two scenarios. 80 Draft ND Proxy October 2005 82 1.1. SCENARIO 1: Wireless upstream 84 The following figure illustrates a likely example: 86 | +-------+ +--------+ 87 local |Ethernet | | Wireless | Access | 88 +---------+ A +-))) (((-+ +--> rest of network 89 hosts | | | link | Point | 90 | +-------+ +--------+ 92 In this scenario, the access point has assigned an IPv6 subnet 93 prefix to the wireless link, and uses link-layer encryption so 94 that wireless clients may not see each other's data. 96 Classic bridging requires the bridge (node A in the above diagram) 97 to be in promiscuous mode. In this wireless scenario, A cannot 98 put its wireless interface into promiscuous mode, since one 99 wireless node cannot see traffic to/from other wireless nodes. 101 IPv4 ARP proxying has been used for some years to solve this 102 problem without involving NAT or requiring any change to the 103 access point or router. In this document, we describe equivalent 104 functionality for IPv6 to remove this incentive to deploy NATs in 105 IPv6. 107 We also note that Prefix Delegation [PD] could also be used to 108 solve this scenario. There are, however, two disadvantages to 109 this. First, if an implementation already supports IPv4 ARP 110 proxying (which is indeed the case in a number of implementations 111 today), then IPv6 Prefix Delegation would result in separate IPv6 112 subnets on either side of the device, while a single IPv4 subnet 113 would span both segments. This topological discrepancy can 114 complicate applications and protocols which use the concept of a 115 local subnet. Secondly, the extent to which Prefix Delegation is 116 supported, and supported without additional charge, is up to the 117 service provider. Hence, there is no guarantee that Prefix 118 Delegation will work without explicit configuration or additional 119 charge. Bridging, on the other hand, allows the device to work 120 with zero configuration, regardless of the service provider's 121 policies, just as a NAT does. Hence bridging avoids the incentive 122 to NAT IPv6 just to avoid paying for, or requiring configuration 123 to get, another prefix. 125 Draft ND Proxy October 2005 127 1.2. SCENARIO 2: PPP upstream 129 The following figure illustrates another likely example: 130 | +-------+ +--------+ 131 local |Ethernet | | PPP link | | 132 +---------+ A +-----------+ Router +--> rest of network 133 hosts | | | | | 134 | +-------+ +--------+ 136 In this scenario, the router has assigned a /64 to the PPP link 137 and advertises it in an IPv6 Router Advertisement. 139 Classic bridging does not support non-802 media. The PPP Bridging 140 Control Protocol [BCP] defines a mechanism for supporting bridging 141 over PPP, but it requires both ends to be configured to support 142 it. Hence IPv4 connectivity is often solved by making the proxy 143 (node A in the above diagram) be a NAT or an IPv4 ARP Proxy. This 144 document specifies a solution for IPv6 which does not involve NAT 145 or require any change to the router. 147 1.3. Inapplicable Scenarios 149 This document is not applicable to scenarios with loops in the 150 physical topology, or where routers exist on multiple segments. 151 These cases are detected and proxying is disabled (see Section 6). 153 In addition, this document is not appropriate for scenarios where 154 classic bridging can be applied, or when configuration of the 155 router can be done. 157 2. Terminology 159 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 160 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 161 in this document are to be interpreted as described in BCP 14, RFC 162 2119 [KEYWORDS]. 164 The term "proxy interface" will be used to refer to an interface 165 (which could itself be a bridge interface) over which network 166 layer proxying is done as defined herein. 168 In this document we make no distinction between a "link" (in the 169 classic IPv6 sense) and a "subnet". We use the term "segment" to 170 apply to a bridged component of the link. 172 Draft ND Proxy October 2005 174 Finally, while it is possible that functionality equivalent to 175 that described herein may be achieved by nodes which do not 176 fulfill all the requirements in [NODEREQ], in the remainder of 177 this document we will describe behavior in terms of an IPv6 node 178 as defined in that document. 180 3. Requirements 182 Proxy behavior is designed with the following requirements in 183 mind: 185 o Support connecting multiple segments with a single subnet 186 prefix. 188 o Support media which cannot be bridged at the link-layer. 190 o Do not require any changes to existing routers. That is, 191 routers on the subnet may be unaware that the subnet is being 192 bridged. 194 o Provide full connectivity between all nodes in the subnet. 195 For example, if there are existing nodes (such as any routers 196 on the subnet) which have addresses in the subnet prefix, 197 adding a proxy must allow bridged nodes to have full 198 connectivity with existing nodes on the subnet. 200 o Prevent loops. 202 o Also work in the absence of any routers. 204 o Support nodes moving between segments. For example, a node 205 should be able to keep its address without seeing its address 206 as a duplicate due to any cache maintained at the proxy. 208 o Allow dynamic addition of a proxy without adversely 209 disrupting the network. 211 o The proxy behavior should not break any existing classic 212 bridges in use on a network segment. 214 Draft ND Proxy October 2005 216 3.1. Non-requirements 218 The following items are not considered requirements, as they are 219 not met by classic bridges: 221 o Show up as a hop in a traceroute. 223 o Use the shortest path between two nodes on different 224 segments. 226 o Be able to use all available interfaces simultaneously. 227 Instead, bridging technology relies on disabling redundant 228 interfaces to prevent loops. 230 o Support connecting media on which Neighbor Discovery is not 231 possible. For example, some technologies such as [6TO4] use 232 an algorithmic mapping from IPv6 address to the underlying 233 link-layer (IPv4 in this case) address, and hence cannot 234 support bridging arbitrary IP addresses. 236 The following additional items are not considered requirements for 237 this document: 239 o Support network-layer protocols other than IPv6. We do not 240 preclude such support, but it is not specified in this 241 document. 243 o Support Redirects for off-subnet destinations that point to a 244 router on a different segment from the redirected host. 245 While this scenario may be desirable, no solution is 246 currently known which does not have undesirable side effects 247 outside the subnet. As a result, this scenario is outside 248 the scope of this document. 250 4. Proxy Behavior 252 Network layer support for proxying between multiple interfaces 253 SHOULD be used only when classic bridging is not possible. 255 When a proxy interface comes up, the node puts it in "all- 256 multicast" mode so that it will receive all multicast packets. It 257 is common for interfaces to not support full promiscuous mode 258 (e.g., on a wireless client), but all-multicast mode is generally 259 still supported. 261 Draft ND Proxy October 2005 263 As with all other interfaces, IPv6 maintains a neighbor cache for 264 each proxy interface, which will be used as described below. 266 4.1. Forwarding Packets 268 When a packet from any IPv6 source address other than the 269 unspecified address is received on a proxy interface, the neighbor 270 cache of that interface SHOULD be consulted to find an entry for 271 the source IPv6 address. If no entry exists, one is created in 272 the STALE state. 274 When any IPv6 packet is received on a proxy interface, it must be 275 parsed to see whether it is known to be of a type that negotiates 276 link-layer addresses. This document covers the following types: 277 Neighbor Solicitations, Neighbor Advertisements, Router 278 Advertisements, and Redirects. These packets are ones that can 279 carry link-layer addresses, and hence must be proxied (as 280 described below) so that packets between nodes on different 281 segments can be received by the proxy and have the correct link- 282 layer address type on each segment. 284 When any other IPv6 multicast packet is received on a proxy 285 interface, in addition to any normal IPv6 behavior such as being 286 delivered locally, it is forwarded unchanged (other than using a 287 new link-layer header) out all other proxy interfaces on the same 288 link. (As specified in [BRIDGE], the proxy may instead support 289 multicast learning and filtering but this is OPTIONAL.) In 290 particular, the IPv6 Hop Limit is not updated, and no ICMP errors 291 (except as noted in Section 4.1.1 below) are sent as a result of 292 attempting this forwarding. 294 When any other IPv6 unicast packet is received on a proxy 295 interface, if it is not locally destined then it is forwarded 296 unchanged (other than using a new link-layer header) to the proxy 297 interface for which the next hop address appears in the neighbor 298 cache. Again the IPv6 Hop Limit is not updated, and no ICMP 299 errors (except as noted in Section 4.1.1 below) are sent as a 300 result of attempting this forwarding. To choose a proxy interface 301 to forward to, the neighbor cache is consulted, and the interface 302 with the neighbor entry in the "best" state is used. In order of 303 least to most preferred, the states (per [ND]) are INCOMPLETE, 304 STALE, DELAY, PROBE, REACHABLE. A packet is never forwarded back 305 out the same interface on which it arrived; such a packet is 306 instead silently dropped. 308 Draft ND Proxy October 2005 310 If no cache entry exists (as may happen if the proxy has 311 previously evicted the cache entry or if the proxy is restarted), 312 the proxy SHOULD queue the packet and initiate Neighbor Discovery 313 as if the packet were being locally generated. The proxy MAY 314 instead silently drop the packet. In this case, the entry will 315 eventually be recreated when the sender re-attempts neighbor 316 discovery. 318 The link layer header, and the link-layer address within the 319 payload for each forwarded packet will be modified as follows: 321 1) The source address will be the address of the outgoing 322 interface. 324 2) The destination address will be the address in the neighbor 325 entry corresponding to the destination IPv6 address. 327 3) The link-layer address within the payload is substituted with 328 the address of the outgoing interface. 330 4.1.1. Sending Packet Too Big Messages 332 Whenever any IPv6 packet is to be forwarded out an interface whose 333 MTU is smaller than the size of the packet, the ND proxy drops the 334 packet and sends a Packet Too Big message back to the source, as 335 described in [ICMPv6]. 337 4.1.2. Proxying Packets With Link-Layer Addresses 339 Once it is determined that the packet is either multicast or else 340 is not locally destined (if unicast), the special types enumerated 341 above (ARP, etc.) that carry link-layer addresses are handled by 342 generating a proxy packet that contains the proxy's link-layer 343 address on the outgoing interface instead. Such link-layer 344 addresses occur in the link-layer header itself, as well as in the 345 payloads of some protocols. As with all forwarded packets, the 346 link-layer header is new. 348 Section 4.1.3 enumerates the currently known cases where link- 349 layer addresses must be changed in payloads. For guidance on 350 handling future protocols, Section 7, "Guidelines to proxy 351 developers", describes the scenarios in which the link-layer 352 address substitution in the payload should be performed. Note 353 Draft ND Proxy October 2005 355 that any change to the length of a proxied packet, such as when 356 the link-layer address length changes, will require a 357 corresponding change to the IPv6 Payload Length field. 359 4.1.3. IPv6 ND Proxying 361 When any IPv6 packet is received on a proxy interface, it must be 362 parsed to see whether it is known to be one of the following 363 types: Neighbor Solicitation, Neighbor Advertisement, Router 364 Advertisement, or Redirect. 366 4.1.3.1. ICMPv6 Neighbor Solicitations 368 If the received packet is an ICMPv6 Neighbor Solicitation (NS), 369 the NS is processed locally as described in section 7.2.3 of [ND] 370 but no NA is generated immediately. Instead the NS is proxied as 371 described above and the NA will be proxied when it is received. 372 This ensures that the proxy does not interfere with hosts moving 373 from one segment to another since it never responds to an NS based 374 on its own cache. 376 4.1.3.2. ICMPv6 Neighbor Advertisements 378 If the received packet is an ICMPv6 Neighbor Advertisement (NA), 379 the neighbor cache on the receiving interface is first updated as 380 if the NA were locally destined, and then the NA is proxied as 381 described in 4.1.2 above. 383 4.1.3.3. ICMPv6 Router Advertisements 385 The following special processing is done for IPv6 Router 386 Advertisements (RAs). 388 A new "Proxy" bit is defined in the existing Router Advertisement 389 flags field as follows: 390 +-+-+-+-+-+-+-+-+ 391 |M|O|H|Prf|P|Rsv| 392 +-+-+-+-+-+-+-+-+ 393 where "P" indicates the location of the Proxy bit, and "Rsv 394 indicates the remaining reserved bits. 396 Draft ND Proxy October 2005 398 The proxy determines an "upstream" proxy interface, typically 399 through a (zero-configuration) physical choice dictated by the 400 scenario (see Scenarios 1 and 2 above), or through manual 401 configuration. 403 When an RA with the P bit clear arrives on the upstream interface, 404 the P bit is set when the RA is proxied out all other 405 ("downstream") proxy interfaces (see section 6). 407 If an RA with the P bit set has arrived on a given interface 408 (including the upstream interface) within the last 60 minutes, 409 that interface MUST NOT be used as a proxy interface; i.e., proxy 410 functionality is disabled on that interface. 412 Furthermore, if any RA (regardless of the value of the P bit) has 413 arrived on a "downstream" proxy interface within the last 60 414 minutes, that interface MUST NOT be used as a proxy interface. 416 The RA is processed locally as well as proxied as described in 417 section 4.1.2, unless such proxying is disabled as noted above. 419 4.1.3.4. ICMPv6 Redirects 421 If the received packet is an ICMPv6 Redirect message, then the 422 proxied packet should be modified as follows. If the proxy has a 423 valid (i.e., not INCOMPLETE) neighbor entry for the target address 424 on the same interface as the redirected host, then the TLLA option 425 in the proxied Redirect simply contains the link-layer address of 426 the target as found in the proxy's neighbor entry, since the 427 redirected host may reach the target address directly. Otherwise, 428 if the proxy has a valid neighbor entry for the target address on 429 some other interface, then the TLLA option in the proxied packet 430 contains the link-layer address of the proxy on the sending 431 interface, since the redirected host must reach the target address 432 through the proxy. Otherwise, the proxy has no valid neighbor 433 entry for the target address, and the proxied packet contains no 434 TLLA option, which will cause the redirected host to perform 435 neighbor discovery for the target address. 437 4.2. Originating Packets 439 Locally originated packets that are sent on a proxy interface also 440 follow the same rules as packets received on a proxy interface. 442 Draft ND Proxy October 2005 444 If no neighbor entry exists when a unicast packet is to be locally 445 originated, an interface can be chosen in any implementation- 446 specific fashion. Once the neighbor is resolved, the actual 447 interface will be discovered and the packet will be sent on that 448 interface. When a multicast packet is to be locally originated, 449 an interface can be chosen in any implementation-specific fashion, 450 and the packet will then be forwarded out other proxy interfaces 451 on the same link as described in Section 4.1 above. 453 5. Example 455 Consider the following topology, where A and B are nodes on 456 separate segments which are connected by a proxy P: 458 A---|---P---|---B 459 a p1 p2 b 461 A and B have link-layer addresses a and b, respectively. P has 462 link-layer addresses p1 and p2 on the two segments. We now walk 463 through the actions that happen when A attempts to send an initial 464 IPv6 packet to B. 466 A first does a route lookup on the destination address B. This 467 matches the on-link subnet prefix, and a destination cache entry 468 is created as well as a neighbor cache entry in the INCOMPLETE 469 state. Before the packet can be sent, A needs to resolve B's 470 link-layer address and sends a Neighbor Solicitation (NS) to the 471 solicited-node multicast address for B. The SLLA option in the 472 solicitation contains A's link-layer address. 474 P receives the solicitation (since it is receiving all link-layer 475 multicast packets) and processes it as it would any multicast 476 packet by forwarding it out to other segments on the link. 477 However, before actually sending the packet, it determines if the 478 packet being sent is one which requires proxying. Since it is an 479 NS, it creates a neighbor entry for A on interface 1 and records 480 its link-layer address. It also creates a neighbor entry for B 481 (on an arbitrary proxy interface) in the INCOMPLETE state. Since 482 the packet is multicast, P then needs to proxy the NS out all 483 other proxy interfaces on the subnet. Before sending the packet 484 out interface 2, it replaces the link-layer address in the SLLA 485 option with its own link-layer address, p2. 487 B receives this NS, processing it as usual. Hence it creates a 488 Draft ND Proxy October 2005 490 neighbor entry for A mapping it to the link-layer address p2. It 491 responds with a Neighbor Advertisement (NA) sent to A containing 492 B's link-layer address b. The NA is sent using A's neighbor 493 entry, i.e. to the link-layer address p2. 495 The NA is received by P, which then processes it as it would any 496 unicast packet; i.e., it forwards this out interface 1, based on 497 the neighbor cache. However, before actually sending the packet 498 out, it inspects it to determine if the packet being sent is one 499 which requires proxying. Since it is an NA, it updates its 500 neighbor entry for B to be REACHABLE and records the link-layer 501 address b. P then replaces the link-layer address in the TLLA 502 option with its own link-layer address on the outgoing interface, 503 p1. The packet is then sent out interface 1. 505 A receives this NA, processing it as usual. Hence it creates a 506 neighbor entry for B on interface 2 in the REACHABLE state and 507 records the link-layer address p1. 509 6. Loop Prevention 511 An implementation MUST ensure that loops are prevented by using 512 the P bit in RA's as follows. The proxy determines an "upstream" 513 proxy interface, typically through a (zero-configuration) physical 514 choice dictated by the scenario (see Scenarios 1 and 2 above), or 515 through manual configuration. As described in Section 4.1.3.3, 516 only the upstream interface is allowed to receive RAs, and never 517 from other proxies. Proxy functionality is disabled on an 518 interface otherwise. Finally, a proxy MUST wait until it has sent 519 two P bit RAs on a given "downstream" interface before it enables 520 forwarding on that interface. 522 7. Guidelines to proxy developers 524 Proxy developers will have to accomodate protocols or protocol 525 options (for example, new ICMP messages) that are developed in the 526 future, or protocols that are not mentioned in this document (for 527 example, proprietary protocols). This section prescribes 528 guidelines that can be used by proxy developers to accomodate 529 protocols that are not mentioned herein. 531 Draft ND Proxy October 2005 533 1) If a link-layer address carried in the payload of the 534 protocol can be used in the link-layer header of future 535 messages, then the proxy should substitute it with its own 536 address. For example the link-layer address in NA messages is 537 used in the link-layer header for future messages, and, 538 hence, the proxy substitutes it with its own address. 540 For multicast packets, the link-layer address substituted 541 within the payload will be different for each outgoing 542 interface. 544 2) If the link-layer address in the payload of the protocol will 545 never be used in any link-layer header, then the proxy should 546 not substitute it with its own address. No special actions 547 are required for supporting these protocols. For example, 548 [DHCPv6] is in this category. 550 8. IANA Considerations 552 This document has no actions for IANA. 554 9. Security Considerations 556 Unsecured Neighbor Discovery has a number of security issues which 557 are discussed in detail in [PSREQ]. RFC 3971 [SEND] defines 558 security mechanisms that can protect Neighbor Discovery. 560 Proxies are susceptible to the same kind of security issues that 561 plague hosts using unsecured Neighbor Discovery. These issues 562 include hijacking traffic and denial-of-service within the subnet. 563 Malicious nodes within the subnet can take advantage of this 564 property, and hijack traffic. In addition, a Neighbor Discovery 565 proxy is essentially a legitimate man-in-the-middle, which implies 566 that there is a need to distinguish proxies from unwanted man-in- 567 the-middle attackers. 569 This document does not introduce any new mechanisms for the 570 protection of proxy neighbor discovery. That is, it does not 571 provide a mechanism from authorizing certain devices to act as 572 proxies, and it does not provide extensions to SEND to make it 573 possible to use both SEND and proxies at the same time. We note 574 that RFC 2461 [ND] already defines the ability to proxy Neighbor 575 Advertisements, and extensions to SEND are already needed to cover 576 Draft ND Proxy October 2005 578 that case, independent of this document. 580 Note also that the use of proxy Neighbor Discovery may render it 581 impossible to use SEND both on the leaf subnet and on the external 582 subnet. This because the modifications performed by the proxy 583 will invalidate the RSA Signature Option in a secured Neighbor 584 Discovery message, and cause SEND-capable nodes to either discard 585 the messages or treat them as unsecured. The latter is the 586 desired operation when SEND is used together with this 587 specification, and ensures that SEND nodes within this environment 588 can selectively downgrade themselves to unsecure Neighbor 589 Discovery when proxies are present. 591 In the following we outline some potential paths to follow when 592 defining a secure proxy mechanism. 594 It is reasonable for nodes on the leaf subnet to have a secure 595 relationship with the proxy, and accept ND packets from either the 596 owner of a specific address (normal SEND), or which it can verify 597 are from a trusted proxy (see below). 599 For nodes on the external subnet, there is a tradeoff between 600 security (where all nodes have a secure relationship with the 601 proxy) and privacy (where no nodes are aware that the proxy is a 602 proxy). In the case of a point-to-point external link (Scenario 603 2) however, SEND may not be a requirement on that link. 605 Verifying that ND packets come from a trusted proxy requires an 606 extension to the SEND protocol and is left for future work [SPND], 607 but is similar to the problem of securing Router Advertisements 608 which is supported today. For example, a rogue node can send a 609 Router Advertisement to cause a proxy to disable its proxy 610 behavior, and hence cause denial-of-service to other nodes; this 611 threat is covered in section 4.2.1 of [PSREQ]. 613 Alternative designs might involve schemes where the right for 614 representing a particular host is delegated to the proxy, or where 615 multiple nodes can make statements on behalf of one address 616 [RINGSIG]. 618 10. Appendix A: Comparison with Naive RA Proxy 620 It has been suggested that a simple Router Advertisement (RA) 621 proxy would be sufficient, where the subnet prefix in an RA is 622 Draft ND Proxy October 2005 624 "stolen" by the proxy and applied to a downstream link instead of 625 an upstream link. Other ND messages are not proxied. 627 There are many problems with this approach. First, it requires 628 cooperation from all nodes on the upstream link. No node 629 (including the router sending the RA) can have an address in the 630 subnet or it will not have connectivity with nodes on the 631 downstream link. This is because when a node on a downstream link 632 tries to do Neighbor Discovery, and the proxy does not send the NS 633 on the upstream link, it will never discover the neighbor on the 634 upstream link. Similarly, if messages are not proxied during DAD, 635 conflicts can occur. 637 Second, if the proxy assumes that no nodes on the upstream link 638 have addresses in the prefix, such a proxy could not be safely 639 deployed without cooperation from the network administrator since 640 it introduces a requirement that the router itself not have an 641 address in the prefix. This rules out use in situations where 642 bridges and Network Address Translators (NATs) are used today, 643 which is the problem this document is directly addressing. 644 Instead, where a prefix is desired for use on one or more 645 downstream links in cooperation with the network administrator, 646 Prefix Delegation [PD] should be used instead. 648 11. Acknowledgements 650 The authors wish to thank Jari Arkko for contributing portions of 651 the Security Considerations text. 653 12. Authors' Addresses 655 Dave Thaler 656 Microsoft Corporation 657 One Microsoft Way 658 Redmond, WA 98052-6399 659 Phone: +1 425 703 8835 660 EMail: dthaler@microsoft.com 662 Mohit Talwar 663 Microsoft Corporation 664 One Microsoft Way 665 Redmond, WA 98052-6399 666 Phone: +1 425 705 3131 668 Draft ND Proxy October 2005 670 EMail: mohitt@microsoft.com 672 Chirayu Patel 673 All Play, No Work 674 Bangalore, Karnataka 560038 675 Phone: +91-98452-88078 676 EMail: chirayu@chirayu.org 678 13. Normative References 680 [BRIDGE] 681 T. Jeffree, editor, "Media Access Control (MAC) Bridges", 682 ANSI/IEEE Std 802.1D, 2004, 683 http://standards.ieee.org/getieee802/download/802.1D-2004.pdf. 685 [ICMPv6] 686 Conta, A. and S. Deering, "Internet Control Message Protocol 687 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 688 Specification", RFC 2463, December 1998. 690 [KEYWORDS] 691 S. Bradner, "Key words for use in RFCs to Indicate 692 Requirement Levels", BCP 14, RFC 2119, March, 1997. 694 [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 695 for IP Version 6 (IPv6)", RFC 2461, December 1998. 697 [NODEREQ] 698 J. Loughney, "IPv6 Node Requirements", Work in progress, 699 draft-ietf-ipv6-node-requirements-11.txt, August 2004. 701 14. Informative References 703 [6TO4] 704 Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 705 IPv4 Clouds", RFC 3056, February 2001. 707 Draft ND Proxy October 2005 709 [BCP] 710 Baker, F. and R. Bowen, "PPP Bridging Control Protocol 711 (BCP)", RFC 1638, June 1994. 713 [DHCPv6] 714 Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. 715 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 716 (DHCPv6)", RFC 3315, July 2003. 718 [NAT] 719 Srisuresh, P. and K. Egevang, "Traditional IP Network Address 720 Translator (Traditional NAT)", RFC 3022, January 2001. 722 [PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 723 Configuration Protocol (DHCP) version 6", RFC 3633, December 724 2003. 726 [PSREQ] 727 Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 728 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 730 [RINGSIG] 731 Kempf, J. and C. Gentry, "Secure IPv6 Address Proxying using 732 Multi-Key Cryptographically Generated Addresses (MCGAs)", 733 Work in progress, draft-kempf-mobopts-ringsig-ndproxy-02.txt, 734 August, 2005. 736 [SEND] 737 Arkko, J., Ed., Kempf, J., Zill, B. and P. Nikander, "SEcure 738 Neighbor Discovery (SEND)", RFC 3971, March 2005. 740 [SPND] 741 Daley, G., "Securing Proxy Neighbour Discovery Problem 742 Statement", Work in progress, draft-daley-send-spnd- 743 prob-01.txt, February 2005. 745 Draft ND Proxy October 2005 747 15. Full Copyright Statement 749 Copyright (C) The Internet Society (2005). This document is 750 subject to the rights, licenses and restrictions contained in BCP 751 78, and except as set forth therein, the authors retain all their 752 rights. 754 This document and the information contained herein are provided on 755 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 756 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 757 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 758 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 759 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 760 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 761 PARTICULAR PURPOSE. 763 16. Intellectual Property 765 The IETF takes no position regarding the validity or scope of any 766 Intellectual Property Rights or other rights that might be claimed 767 to pertain to the implementation or use of the technology 768 described in this document or the extent to which any license 769 under such rights might or might not be available; nor does it 770 represent that it has made any independent effort to identify any 771 such rights. Information on the procedures with respect to rights 772 in RFC documents can be found in BCP 78 and BCP 79. 774 Copies of IPR disclosures made to the IETF Secretariat and any 775 assurances of licenses to be made available, or the result of an 776 attempt made to obtain a general license or permission for the use 777 of such proprietary rights by implementers or users of this 778 specification can be obtained from the IETF on-line IPR repository 779 at http://www.ietf.org/ipr. 781 The IETF invites any interested party to bring to its attention 782 any copyrights, patents or patent applications, or other 783 proprietary rights that may cover technology that may be required 784 to implement this standard. Please address the information to the 785 IETF at ietf-ipr@ietf.org. 787 Draft ND Proxy October 2005 789 Table of Contents 791 1: Introduction ............................................. 2 792 1.1: SCENARIO 1: Wireless upstream .......................... 3 793 1.2: SCENARIO 2: PPP upstream ............................... 4 794 1.3: Inapplicable Scenarios ................................. 4 795 2: Terminology .............................................. 4 796 3: Requirements ............................................. 5 797 3.1: Non-requirements ....................................... 6 798 4: Proxy Behavior ........................................... 6 799 4.1: Forwarding Packets ..................................... 7 800 4.1.1: Sending Packet Too Big Messages ...................... 8 801 4.1.2: Proxying Packets With Link-Layer Addresses ........... 8 802 4.1.3: IPv6 ND Proxying ..................................... 9 803 4.1.3.1: ICMPv6 Neighbor Solicitations ...................... 9 804 4.1.3.2: ICMPv6 Neighbor Advertisements ..................... 9 805 4.1.3.3: ICMPv6 Router Advertisements ....................... 9 806 4.1.3.4: ICMPv6 Redirects ................................... 10 807 4.2: Originating Packets .................................... 10 808 5: Example .................................................. 11 809 6: Loop Prevention .......................................... 12 810 7: Guidelines to proxy developers ........................... 12 811 8: IANA Considerations ...................................... 13 812 9: Security Considerations .................................. 13 813 10: Appendix A: Comparison with Naive RA Proxy .............. 14 814 11: Acknowledgements ........................................ 15 815 12: Authors' Addresses ...................................... 15 816 13: Normative References .................................... 16 817 14: Informative References .................................. 16 818 15: Full Copyright Statement ................................ 18 819 16: Intellectual Property ................................... 18