idnits 2.17.1 draft-ietf-ipv6-ndproxy-03.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 787. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 807. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 813. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 778), 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. ** The document seems to lack an RFC 3979 Section 5, para. 1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? 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) == Unused Reference: 'ARP' is defined on line 708, but no explicit reference was found in the text == Unused Reference: 'DHCPv4' is defined on line 723, but no explicit reference was found in the text ** Downref: Normative reference to an Unknown state RFC: RFC 925 (ref. 'ARPPROXY') -- 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) ** Downref: Normative reference to an Informational draft: draft-ietf-ipv6-node-requirements (ref. 'NODEREQ') -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. 'PD') (Obsoleted by RFC 8415) Summary: 9 errors (**), 0 flaws (~~), 4 warnings (==), 8 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 July 14, 2005 Microsoft 5 Expires January 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 July 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 The behavior of one common type of IPv4 ARP Proxy deployed today 51 is documented herein for informational purposes, but this document 52 concentrates on describing similar behavior for IPv6. 54 1. Introduction 56 In the IPv4 Internet today, it is common for Network Address 57 Translators (NATs) [NAT] to be used to easily connect one or more 58 leaf links to an existing network without requiring any 59 coordination with the network service provider. Since NATs modify 60 IP addresses in packets, they are problematic for many IP 61 applications. As a result, it is desirable to address the problem 62 (for both IPv4 and IPv6) without the need for NATs, while still 63 maintaining the property that no explicit cooperation from the 64 router is needed. 66 Another common solution is IEEE 802 bridging, as specified in 67 [BRIDGE]. It is expected that whenever possible links will be 68 bridged at the link layer using classic bridge technology [BRIDGE] 69 as opposed to using the mechanisms herein. However, classic 70 bridging at the data-link layer has the following limitations 71 (among others): 73 o It requires the ports to support promiscuous mode. 75 o It requires all ports to support the same type of link-layer 76 addressing (in particular, IEEE 802 addressing). 78 As a result, two common scenarios, described below, are not 79 solved, and it is these two scenarios we specifically target in 80 this document. While the mechanism described herein may apply to 81 other scenarios as well, we will concentrate our discussion on 82 Draft ND Proxy July 2005 84 these two scenarios. 86 1.1. SCENARIO 1: Wireless upstream 88 The following figure illustrates a likely example: 90 | +-------+ +--------+ 91 local |Ethernet | | Wireless | Access | 92 +---------+ A +-))) (((-+ +--> rest of network 93 hosts | | | link | Point | 94 | +-------+ +--------+ 96 In this scenario, the access point has assigned an IPv4 and/or an 97 IPv6 subnet prefix to the wireless link, and uses link-layer 98 encryption so that wireless clients may not see each other's data. 100 Classic bridging requires the bridge (node A in the above diagram) 101 to be in promiscuous mode. In this wireless scenario, A cannot 102 put its wireless interface into promiscuous mode, since one 103 wireless node cannot see traffic to/from other wireless nodes. 104 This document describes a solution for both IPv4 and IPv6 which 105 does not involve NAT or require any change to the access point or 106 router. 108 Multiple variants of IPv4 ARP proxying have been used for some 109 years to solve this problem. ARP-based bridges were first 110 described in [ARPPROXY], but that variant decrements the TTL, does 111 not forward all-ones broadcasts, and requires proxies to keep per- 112 packet state on recent subnet broadcasts. The first two 113 characteristics can cause problems with applications and protocols 114 which assume that nodes in the subnet prefix can be reached with 115 TTL 1 (or with TTL 255, with TTL 255 verified on receipt) and/or 116 with a subnet broadcast. The third characteristic results in 117 scalability issues in proxy implementations. As a result, 118 multiple variants have emerged in different implementations over 119 time. In this document, we describe one such variant, and enable 120 equivalent functionality for IPv6 to remove this incentive to 121 deploy NATs in IPv6. 123 We also note that Prefix Delegation [PD] could also be used to 124 solve this scenario. There are, however, two disadvantages to 125 this. First, if an implementation already supports IPv4 ARP 126 proxying (which is indeed supported in a number of implementations 127 today), then IPv6 Prefix Delegation would result in separate IPv6 128 Draft ND Proxy July 2005 130 subnets on either side of the device, while a single IPv4 subnet 131 would span both segments. This topological discrepancy can 132 complicate applications and protocols which use the concept of a 133 local subnet. Secondly, the extent to which Prefix Delegation is 134 supported, and supported without additional charge, is up to the 135 service provider. Hence, there is no guarantee that Prefix 136 Delegation will work without explicit configuration or additional 137 charge. Bridging, on the other hand, allows the device to work 138 with zero configuration, regardless of the service provider's 139 policies, just as a NAT does. Hence bridging avoids the incentive 140 to NAT IPv6 just to avoid paying for, or requiring configuration 141 to get, another prefix. 143 1.2. SCENARIO 2: PPP upstream 145 The following figure illustrates another likely example: 146 | +-------+ +--------+ 147 local |Ethernet | | PPP link | | 148 +---------+ A +-----------+ Router +--> rest of network 149 hosts | | | | | 150 | +-------+ +--------+ 152 In this scenario, the router believes that the other end of the 153 PPP link (node A) has a single IPv4 address, as negotiated by PPP. 154 For IPv6, it has assigned a /64 to the link and advertises it in 155 an IPv6 Router Advertisement. 157 Classic bridging does not support non-802 media, and hence IPv4 158 connectivity is solved by making the proxy (node A in the above 159 diagram) be a NAT. This document does not specify any other IPv4 160 solution for this scenario. However, this document does specify a 161 solution for IPv6 which does not involve NAT or require any change 162 to the router. 164 2. Terminology 166 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 167 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 168 in this document are to be interpreted as described in BCP 14, RFC 169 2119 [KEYWORDS]. 171 The term "proxy interface" will be used to refer to an interface 172 (which could itself be a bridge interface) over which network 173 layer proxying is done as defined herein. 175 Draft ND Proxy July 2005 177 In this document we make no distinction between a "link" (in the 178 classic IPv6 sense) and a "subnet". We use the term "segment" to 179 apply to a bridged component of the link. 181 Finally, while it is possible that functionality equivalent to 182 that described herein may be achieved by nodes which do not 183 fulfill all the requirements in [NODEREQ], in the remainder of 184 this document we will describe behavior in terms of an IPv6 node 185 as defined in that document. 187 3. Requirements 189 Proxy behavior is designed with the following requirements in 190 mind: 192 o Support connecting multiple segments with a single subnet 193 prefix. 195 o Support media which cannot be bridged at the link-layer. 196 Note, this document does not support bridging of non-802 197 media for IPv4. 199 o Support both IPv6 and IPv4 for 802 media. 201 o Do not require any changes to existing routers. That is, any 202 routers on the subnet should be unaware that the subnet is 203 being bridged. 205 o Provide full connectivity between all nodes in the subnet. 206 For example, if there are existing nodes (such as any routers 207 on the subnet) which have addresses in the subnet prefix, 208 adding a proxy must allow bridged nodes to have full 209 connectivity with existing nodes on the subnet. 211 o Prevent loops. 213 o Also work in the absence of any routers. 215 o Support nodes moving between segments. For example, a node 216 should be able to keep its address without seeing its address 217 as a duplicate due to any cache maintained at the proxy. 219 o Allow dynamic addition of a proxy without adversely 220 disrupting the network. 222 Draft ND Proxy July 2005 224 o The proxy behavior should not break any existing classic 225 bridges in use on a network segment. 227 3.1. Non-requirements 229 The following items are not considered requirements, as they are 230 not met by classic bridges: 232 o Show up as a hop in a traceroute. 234 o Use the shortest path between two nodes on different 235 segments. 237 o Be able to use all available interfaces simultaneously. 238 Instead, bridging technology relies on disabling redundant 239 interfaces to prevent loops. 241 o Support connecting media on which Neighbor Discovery is not 242 possible. For example, some technologies such as [6TO4] use 243 an algorithmic mapping from IPv6 address to the underlying 244 link-layer (IPv4 in this case) address, and hence cannot 245 support bridging arbitrary IP addresses. 247 The following additional items are not considered requirements for 248 this document: 250 o Support network-layer protocols other than IPv4 and IPv6. We 251 do not preclude such support, but it is not specified in this 252 document. 254 o Support Neighbor Discovery, Router Discovery, or DHCPv4 255 packets using IPsec. We also note that the current methods 256 for securing these protocols do not use IPsec so this is 257 considered acceptable. 259 o Support Redirects for off-subnet destinations that point to a 260 router on a different segment from the redirected host. 261 While this scenario may be desirable, no solution is 262 currently known which does not have undesirable side effects 263 outside the subnet. As a result, this scenario is outside 264 the scope of this document. 266 Draft ND Proxy July 2005 268 4. Proxy Behavior 270 Network layer support for proxying between multiple interfaces 271 SHOULD be used only when classic bridging is not possible. 273 When a proxy interface comes up, the node puts it in "all- 274 multicast" mode so that it will receive all multicast packets. It 275 is common for interfaces to not support full promiscuous mode 276 (e.g., on a wireless client), but all-multicast mode is generally 277 still supported. 279 As with all other interfaces, IPv4 and IPv6 maintain a neighbor 280 cache (aka "ARP cache") for each proxy interface, which will be 281 used as described below. For readability, we will describe the 282 neighbor cache as if both IPv4 and IPv6 neighbors use the same 283 state machine described in [ND]. 285 4.1. Forwarding Packets 287 When a packet from any IP source address other than the 288 unspecified address is received on a proxy interface, the neighbor 289 cache of that interface SHOULD be consulted to find an entry for 290 the source IP address. If no entry exists, one is created in the 291 STALE state. 293 When any IP or ARP packet is received on a proxy interface, it 294 must be parsed to see whether it is known to be of a type that 295 negotiates link-layer addresses. This document covers the 296 following types: ARP, IPv6 Neighbor Discovery, IPv6 Router 297 Discovery, IPv6 Redirects, and DHCPv4. These packets are ones 298 that can carry link-layer addresses, and hence must be proxied (as 299 described below) so that packets between nodes on different 300 segments can be received by the proxy and have the correct link- 301 layer address type on each segment. 303 When any other IP broadcast or multicast packet is received on a 304 proxy interface, in addition to any normal IP behavior such as 305 being delivered locally, it is forwarded unchanged (other than 306 using a new link-layer header) out all other proxy interfaces on 307 the same link. (As specified in [BRIDGE], the proxy may instead 308 support multicast learning and filtering but this is OPTIONAL.) 309 In particular, the IPv4 TTL or IPv6 Hop Limit is not updated, and 310 no ICMP errors (except as noted in Section 4.1.1 below) are sent 311 as a result of attempting this forwarding. 313 Draft ND Proxy July 2005 315 When any other IP unicast packet is received on a proxy interface, 316 if it is not locally destined then it is forwarded unchanged 317 (other than using a new link-layer header) to the proxy interface 318 for which the next hop address appears in the neighbor cache. 319 Again the IPv4 TTL or IPv6 Hop Limit is not updated, and no ICMP 320 errors (except as noted in Section 4.1.1 below) are sent as a 321 result of attempting this forwarding. To choose a proxy interface 322 to forward to, the neighbor cache is consulted, and the interface 323 with the neighbor entry in the "best" state is used. In order of 324 least to most preferred, the states (per [ND]) are INCOMPLETE, 325 STALE, DELAY, PROBE, REACHABLE. A packet is never forwarded back 326 out the same interface on which it arrived; such a packet is 327 instead silently dropped. 329 If no cache entry exists (as may happen if the proxy has 330 previously evicted the cache entry or if the proxy is restarted), 331 the proxy SHOULD queue the packet and initiate Neighbor Discovery 332 as if the packet were being locally generated. The proxy MAY 333 instead silently drop the packet. In this case, the entry will 334 eventually be recreated when the sender re-attempts neighbor 335 discovery. 337 The link layer header, and the link-layer address within the 338 payload for each forwarded packet will be modified as follows: 340 1) The source address will be the address of the outgoing 341 interface. 343 2) The destination address will be the address in the neighbor 344 entry corresponding to the destination IP address. 346 3) The link-layer address within the payload is substituted with 347 the address of the outgoing interface. 349 4.1.1. Sending Packet Too Big Messages 351 Whenever any IPv4 packet is to be forwarded out an interface whose 352 MTU is smaller than the size of the packet, and the Dont Fragment 353 bit is set, the ARP proxy drops the packet and sends a 354 Fragmentation Needed message back to the source. 356 Similarly, whenever any IPv6 packet is to be forwarded out an 357 interface whose MTU is smaller than the size of the packet, the ND 358 proxy drops the packet and sends a Packet Too Big message back to 359 Draft ND Proxy July 2005 361 the source, as described in [ICMPv6]. 363 4.1.2. Proxying Packets With Link-Layer Addresses 365 Once it is determined that the packet is either 366 multicast/broadcast or else is not locally destined (if unicast), 367 the special types enumerated above (ARP, etc.) that carry link- 368 layer addresses are handled by generating a proxy packet that 369 contains the proxy's link-layer address on the outgoing interface 370 instead. Section 7, "Guidelines to proxy developers", describes 371 the scenarios in which the link-layer address substitution in the 372 payload should be performed. 374 As with all forwarded packets, the link-layer header is also new. 375 Note that any change to the length of a proxied packet, such as 376 when the link-layer address length changes, will require 377 corresponding changes to fields in the IP header, namely the IPv4 378 Total Length and Header Checksum fields, or the IPv6 Payload 379 Length field. 381 4.1.3. IPv4 ARP Proxying 383 When any IPv4 or ARP packet is received on a proxy interface, it 384 must be parsed to see whether it is known to be one of the 385 following types: ARP, or DHCPv4. 387 4.1.3.1. ARP REQUEST Packets 389 If the received packet is an ARP REQUEST, the request is processed 390 locally but no ARP REPLY is generated immediately. Instead, the 391 ARP REQUEST is proxied (as described above) and the ARP REPLY will 392 be proxied when it is received. This ensures that the proxy does 393 not interfere with hosts moving from one segment to another since 394 it never responds to an ARP REQUEST based on its own cache. 396 4.1.3.2. ARP REPLY Packets 398 If the received packet is an ARP REPLY, the neighbor cache on the 399 receiving interface is first updated as if the ARP REPLY were 400 locally destined, and then the ARP REPLY is proxied as described 401 above. 403 Draft ND Proxy July 2005 405 4.1.3.3. DHCPv4 Packets 407 If the received packet is a DHCPv4 DISCOVER or REQUEST message, 408 then instead of changing the client's hardware address in the 409 payload, the BROADCAST (B) flag is set in the proxied packet. 410 This ensures that the proxy will be able to receive and proxy the 411 response since the response will be broadcast rather than unicast 412 to that hardware address. The hardware address is thus used only 413 as a unique identifier and hence need not be a link-layer address 414 on the same segment. 416 One limitation of this rule is that if the authentication protocol 417 for DHCPv4 described in [DHCPAUTH] is used, only clients that set 418 the BROADCAST flag themselves will be able to use DHCPv4 through 419 the proxy. If [DHCPAUTH] is not used, a DHCPv4 client might still 420 detect, with previously undefined behavior, that the broadcast bit 421 has been changed from the setting in the message originally set by 422 the client. However, the point of this rule is not to solve this 423 problem, but rather to document existing practice. 425 4.1.4. IPv6 ND Proxying 427 When any IPv6 packet is received on a proxy interface, it must be 428 parsed to see whether it is known to be one of the following 429 types: IPv6 Neighbor Discovery, IPv6 Router Discovery, or IPv6 430 Redirects. 432 4.1.4.1. ICMPv6 Neighbor Solicitations 434 If the received packet is an ICMPv6 Neighbor Solicitation, the NS 435 is processed locally as described in section 7.2.3 of [ND] but no 436 NA is generated immediately. Instead the NS is proxied as 437 described above and the NA will be proxied when it is received. 438 This ensures that the proxy does not interfere with hosts moving 439 from one segment to another since it never responds to an NS based 440 on its own cache. 442 4.1.4.2. ICMPv6 Neighbor Advertisements 444 If the received packet is an ICMPv6 Neighbor Advertisement, the 445 neighbor cache on the receiving interface is first updated as if 446 the NA were locally destined, and then the NA is proxied as 447 Draft ND Proxy July 2005 449 described above. 451 4.1.4.3. ICMPv6 Router Advertisements 453 The following special processing is done for IPv6 Router 454 Advertisements (RAs). 456 A new "Proxy" bit is defined in the existing Router Advertisement 457 flags field as follows: 458 +-+-+-+-+-+-+-+-+ 459 |M|O|H|Prf|P|Rsv| 460 +-+-+-+-+-+-+-+-+ 461 where "P" indicates the location of the Proxy bit, and "Rsv 462 indicates the remaining reserved bits. 464 The proxy determines an "upstream" proxy interface, typically 465 through a physical choice dictated by the scenario (see Scenarios 466 1 and 2 above), or through manual configuration. 468 When an RA with the P bit clear arrives on the upstream interface, 469 the P bit is set when the RA is proxied out all other 470 ("downstream") proxy interfaces (see secion 6). 472 If an RA with the P bit set has arrived on a given interface 473 (including the upstream interface) within the last 60 minutes, 474 that interface MUST NOT be used as a proxy interface; i.e., proxy 475 functionality is disabled on that interface. 477 Furthermore, if any RA (regardless of the value of the P bit) has 478 arrived on a "downstream" proxy interface within the last 60 479 minutes, that interface MUST NOT be used as a proxy interface. 481 4.1.4.4. ICMPv6 Redirects 483 If the received packet is an ICMPv6 Redirect message, then the 484 proxied packet should be modified as follows. If the proxy has a 485 valid (i.e., not INCOMPLETE) neighbor entry for the target address 486 on the same interface as the redirected host, then the TLLA option 487 in the proxied Redirect simply contains the link-layer address of 488 the target as found in the proxy's neighbor entry, since the 489 redirected host may reach the target address directly. Otherwise, 490 if the proxy has a valid neighbor entry for the target address on 491 some other interface, then the TLLA option in the proxied packet 492 Draft ND Proxy July 2005 494 contains the link-layer address of the proxy on the sending 495 interface, since the redirected host must reach the target address 496 through the proxy. Otherwise, the proxy has no valid neighbor 497 entry for the target address, and the proxied packet contains no 498 TLLA option, which will cause the redirected host to perform 499 neighbor discovery for the target address. 501 4.2. Originating Packets 503 Locally originated packets that are sent on a proxy interface also 504 follow the same rules as packets received on a proxy interface. 505 If no neighbor entry exists when a unicast packet is to be locally 506 originated, an interface can be chosen in any implementation- 507 specific fashion. Once the neighbor is resolved, the actual 508 interface will be discovered and the packet will be sent on that 509 interface. When a multicast or broadcast packet is to be locally 510 originated, an interface can be chosen in any implementation- 511 specific fashion, and the packet will then be forwarded out other 512 proxy interfaces on the same link as described in Section 4.1 513 above. 515 5. Example 517 Consider the following topology, where A and B are nodes on 518 separate segments which are connected by a proxy P: 520 A---|---P---|---B 521 a p1 p2 b 523 A and B have link-layer addresses a and b, respectively. P has 524 link-layer addresses p1 and p2 on the two segments. We now walk 525 through the actions that happen when A attempts to send an initial 526 IPv6 packet to B. 528 A first does a route lookup on the destination address B. This 529 matches the on-link subnet prefix, and a destination cache entry 530 is created as well as a neighbor cache entry in the INCOMPLETE 531 state. Before the packet can be sent, A needs to resolve B's 532 link-layer address and sends a Neighbor Solicitation (NS) to the 533 solicited-node multicast address for B. The SLLA option in the 534 solicitation contains A's link-layer address. 536 P receives the solicitation (since it is receiving all link-layer 537 Draft ND Proxy July 2005 539 multicast packets) and processes it as it would any multicast 540 packet by forwarding it out to other segments on the link. 541 However, before actually sending the packet, it determines if the 542 packet being sent is one which requires proxying. Since it is an 543 NS, it creates a neighbor entry for A on interface 1 and records 544 its link-layer address. It also creates a neighbor entry for B 545 (on an arbitrary proxy interface) in the INCOMPLETE state. Since 546 the packet is multicast, P then needs to proxy the NS out all 547 other proxy interfaces on the subnet. Before sending the packet 548 out interface 2, it replaces the link-layer address in the SLLA 549 option with its own link-layer address, p2. 551 B receives this NS, processing it as usual. Hence it creates a 552 neighbor entry for A mapping it to the link-layer address p2. It 553 responds with a Neighbor Advertisement (NA) sent to A containing 554 B's link-layer address b. The NA is sent using A's neighbor 555 entry, i.e. to the link-layer address p2. 557 The NA is received by P, which then processes it as it would any 558 unicast packet; i.e., it forwards this out interface 1, based on 559 the neighbor cache. However, before actually sending the packet 560 out, it inspects it to determine if the packet being sent is one 561 which requires proxying. Since it is an NA, it updates its 562 neighbor entry for B to be REACHABLE and records the link-layer 563 address b. P then replaces the link-layer address in the TLLA 564 option with its own link-layer address on the outgoing interface, 565 p1. The packet is then sent out interface 1. 567 A receives this NA, processing it as usual. Hence it creates a 568 neighbor entry for B on interface 2 in the REACHABLE state and 569 records the link-layer address p1. 571 6. Loop Prevention 573 An implementation MUST ensure that loops are prevented by using 574 the P bit in RA's as follows. The proxy determines an "upstream" 575 proxy interface, typically through a physical choice dictated by 576 the scenario (see Scenarios 1 and 2 above), or through manual 577 configuration. As described in Section 4.1.3.3, only the upstream 578 interface is allowed to receive RAs, and never from other proxies. 579 Proxy functionality is disabled on an interface otherwise. 580 Finally, a proxy MUST wait until it has sent two P bit RAs on a 581 given "downstream" interface before it enables forwarding on that 582 interface. 584 Draft ND Proxy July 2005 586 7. Guidelines to proxy developers 588 Proxy developers will have to accomodate protocols or protocol 589 options (for example, new ICMP messages) that are developed in the 590 future, or protocols that are not mentioned in this document (for 591 example, proprietary protocols). This section prescribes 592 guidelines that can be used by proxy developers to accomodate 593 protocols that are not mentioned herein. 595 1) If a link-layer address carried in the payload of the 596 protocol can be used in the link-layer header of future 597 messages, then the proxy should substitute it with its own 598 address. For example the link-layer address in NA messages is 599 used in the link-layer header for future messages, and, 600 hence, the proxy substitutes it with its own address. 602 For broadcast/multicast packets, the link-layer address 603 substituted within the payload will be different for each 604 outgoing interface. 606 2) If the link-layer address in the payload of the protocol will 607 never be used in any link-layer header, then the proxy should 608 not substitute it with its own address. No special actions 609 are required for supporting these protocols. For example, 610 [DHCPv6] is in this category. 612 8. IANA Considerations 614 This document has no actions for IANA. 616 9. Security Considerations 618 Proxies are susceptible to the same kind of security issues that 619 plague hosts using unsecured Neighbor Discovery or ARP. Even if 620 these protocols are secured, the proxies may process unsecured 621 messages, and update the neighbor cache. Malicious nodes within 622 the subnet can take advantage of this property, and hijack 623 traffic. The threats are discussed in detail in [PSREQ]. 625 As a result, securing Neighbor Discovery or ARP must take into 626 account the ability to proxy messages. This document does not 627 introduce any new requirements in this regard. 629 Draft ND Proxy July 2005 631 From an IPv6 perspective, RFC 2461 [ND] already defines the 632 ability to proxy Neighbor Advertisements. Since the ND packets 633 must be modified whenever the link-layer address formats are 634 different (as with PPP) or promiscuous reception is not possible 635 (as with 802.11), securing any solution in this space requires 636 that hosts have a secure relationship with the proxy. 638 It is reasonable for nodes on the leaf subnet to have a secure 639 relationship with the proxy, and accept ND packets from either the 640 owner of a specific address (normal SEND), or which it can verify 641 are from a trusted proxy (see below). 643 For nodes on the external subnet, there is a tradeoff between 644 security (where all nodes have a secure relationship with the 645 proxy) and privacy (where no nodes are aware that the proxy is a 646 proxy). In the case of a point-to-point external link (Scenario 647 2) however, SEND may not be a requirement on that link. 649 Verifying that ND packets come from a trusted proxy requires an 650 extension to the SEND protocol and is left for future work, but is 651 similar to the problem of securing Router Advertisements which is 652 supported today. 654 10. Appendix A: Comparison with Naive RA Proxy 656 It has been suggested that a simple Router Advertisement (RA) 657 proxy would be sufficient, where the subnet prefix in an RA is 658 "stolen" by the proxy and applied to a downstream link instead of 659 an upstream link. Other ND messages are not proxied. 661 There are many problems with this approach. First, it requires 662 cooperation from all nodes on the upstream link. No node 663 (including the router sending the RA) can have an address in the 664 subnet or it will not have connectivity with nodes on the 665 downstream link. This is because when a node on a downstream link 666 tries to do Neighbor Discovery, and the proxy does not send the NS 667 on the upstream link, it will never discover the neighbor on the 668 upstream link. Similarly, if messages are not proxied during DAD, 669 conflicts can occur. 671 Second, if the proxy assumes that no nodes on the upstream link 672 have addresses in the prefix, such a proxy could not be safely 673 deployed without cooperation from the network administrator since 674 it introduces a requirement that the router itself not have an 675 Draft ND Proxy July 2005 677 address in the prefix. This rules out use in situations where 678 bridges and Network Address Translators (NATs) are used today, 679 which is the problem this document is directly addressing. 680 Instead, where a prefix is desired for use on one or more 681 downstream links in cooperation with the network administrator, 682 Prefix Delegation [PD] should be used instead. 684 11. Authors' Addresses 686 Dave Thaler 687 Microsoft Corporation 688 One Microsoft Way 689 Redmond, WA 98052-6399 690 Phone: +1 425 703 8835 691 EMail: dthaler@microsoft.com 693 Mohit Talwar 694 Microsoft Corporation 695 One Microsoft Way 696 Redmond, WA 98052-6399 697 Phone: +1 425 705 3131 698 EMail: mohitt@microsoft.com 700 Chirayu Patel 701 All Play, No Work 702 Bangalore, Karnataka 560038 703 Phone: +91-98452-88078 704 EMail: chirayu@chirayu.org 706 12. Normative References 708 [ARP] 709 D. Plummer, "An Ethernet Address Resolution Protocol", STD 710 37, RFC 826, November 1982. 712 [ARPPROXY] 713 J. Postel, "Multi-LAN address resolution", RFC 925, October 714 1984. 716 Draft ND Proxy July 2005 718 [BRIDGE] 719 T. Jeffree, editor, "Media Access Control (MAC) Bridges", 720 ANSI/IEEE Std 802.1D, 2004, 721 http://standards.ieee.org/getieee802/download/802.1D-2004.pdf. 723 [DHCPv4] 724 R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 725 March 1997. 727 [ICMPv6] 728 Conta, A. and S. Deering, "Internet Control Message Protocol 729 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 730 Specification", RFC 2463, December 1998. 732 [KEYWORDS] 733 S. Bradner, "Key words for use in RFCs to Indicate 734 Requirement Levels", BCP 14, RFC 2119, March, 1997. 736 [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 737 for IP Version 6 (IPv6)", RFC 2461, December 1998. 739 [NODEREQ] 740 J. Loughney, "IPv6 Node Requirements", Work in progress, 741 draft-ietf-ipv6-node-requirements-11.txt, August 2004. 743 13. Informative References 745 [6TO4] 746 Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 747 IPv4 Clouds", RFC 3056, February 2001. 749 [DHCPAUTH] 750 Droms, R. and W. Arbaugh, Eds., "Autentication for DHCP 751 Messages", RFC 3118, June 2001. 753 [DHCPv6] 754 Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. 756 Draft ND Proxy July 2005 758 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 759 (DHCPv6)", RFC 3315, July 2003. 761 [NAT] 762 Srisuresh, P. and K. Egevang, "Traditional IP Network Address 763 Translator (Traditional NAT)", RFC 3022, January 2001. 765 [PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 766 Configuration Protocol (DHCP) version 6", RFC 3633, December 767 2003. 769 [PSREQ] 770 Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 771 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 773 14. Full Copyright Statement 775 Copyright (C) The Internet Society (2005). This document is 776 subject to the rights, licenses and restrictions contained in BCP 777 78, and except as set forth therein, the authors retain all their 778 rights. 780 This document and the information contained herein are provided on 781 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 782 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 783 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 784 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 785 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 786 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 787 PARTICULAR PURPOSE. 789 15. Intellectual Property 791 The IETF takes no position regarding the validity or scope of any 792 Intellectual Property Rights or other rights that might be claimed 793 to pertain to the implementation or use of the technology 794 described in this document or the extent to which any license 795 under such rights might or might not be available; nor does it 796 represent that it has made any independent effort to identify any 797 such rights. Information on the procedures with respect to rights 798 Draft ND Proxy July 2005 800 in RFC documents can be found in BCP 78 and BCP 79. 802 Copies of IPR disclosures made to the IETF Secretariat and any 803 assurances of licenses to be made available, or the result of an 804 attempt made to obtain a general license or permission for the use 805 of such proprietary rights by implementers or users of this 806 specification can be obtained from the IETF on-line IPR repository 807 at http://www.ietf.org/ipr. 809 The IETF invites any interested party to bring to its attention 810 any copyrights, patents or patent applications, or other 811 proprietary rights that may cover technology that may be required 812 to implement this standard. Please address the information to the 813 IETF at ietf-ipr@ietf.org. 815 Draft ND Proxy July 2005 817 Table of Contents 819 1: Introduction ............................................. 2 820 1.1: SCENARIO 1: Wireless upstream .......................... 3 821 1.2: SCENARIO 2: PPP upstream ............................... 4 822 2: Terminology .............................................. 4 823 3: Requirements ............................................. 5 824 3.1: Non-requirements ....................................... 6 825 4: Proxy Behavior ........................................... 7 826 4.1: Forwarding Packets ..................................... 7 827 4.1.1: Sending Packet Too Big Messages ...................... 8 828 4.1.2: Proxying Packets With Link-Layer Addresses ........... 9 829 4.1.3: IPv4 ARP Proxying .................................... 9 830 4.1.3.1: ARP REQUEST Packets ................................ 9 831 4.1.3.2: ARP REPLY Packets .................................. 9 832 4.1.3.3: DHCPv4 Packets ..................................... 10 833 4.1.4: IPv6 ND Proxying ..................................... 10 834 4.1.4.1: ICMPv6 Neighbor Solicitations ...................... 10 835 4.1.4.2: ICMPv6 Neighbor Advertisements ..................... 10 836 4.1.4.3: ICMPv6 Router Advertisements ....................... 11 837 4.1.4.4: ICMPv6 Redirects ................................... 11 838 4.2: Originating Packets .................................... 12 839 5: Example .................................................. 12 840 6: Loop Prevention .......................................... 13 841 7: Guidelines to proxy developers ........................... 14 842 8: IANA Considerations ...................................... 14 843 9: Security Considerations .................................. 14 844 10: Appendix A: Comparison with Naive RA Proxy .............. 15 845 11: Authors' Addresses ...................................... 16 846 12: Normative References .................................... 16 847 13: Informative References .................................. 17 848 14: Full Copyright Statement ................................ 18 849 15: Intellectual Property ................................... 18