idnits 2.17.00 (12 Aug 2021) /tmp/idnits12087/draft-thaler-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 3667, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5 on line 719. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 730. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 737. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 743. ** Found boilerplate matching RFC 3978, Section 5.4, paragraph 1 (on line 710), which is fine, but *also* found old RFC 2026, Section 10.4C, paragraph 1 text on line 37. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** 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 uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document is more than 15 pages and seems to lack a Table of Contents. == 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 648, but no explicit reference was found in the text == Unused Reference: 'DHCPv4' is defined on line 657, but no explicit reference was found in the text -- 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 3315 (ref. 'DHCPv6') (Obsoleted by RFC 8415) -- Obsolete informational reference (is this intentional?): RFC 3633 (ref. 'PD') (Obsoleted by RFC 8415) Summary: 10 errors (**), 0 flaws (~~), 5 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 IPv6 Working Group D. Thaler 2 INTERNET-DRAFT M. Talwar 3 October 22, 2003 Microsoft 4 Expires April 2005 C. Patel 5 All Play, No Work 7 Bridge-like Neighbor Discovery Proxies (ND Proxy) 8 10 Status of this Memo 12 By submitting this Internet-Draft, I certify that any applicable 13 patent or other IPR claims of which I am aware have been 14 disclosed, or will be disclosed, and any of which I become aware 15 will be disclosed, in accordance with RFC 3668. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six 23 months and may be updated, replaced, or obsoleted by other 24 documents at any time. It is inappropriate to use Internet-Drafts 25 as reference material or to cite them other than as "work in 26 progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright Notice 35 Draft ND Proxy October 2004 37 Copyright (C) The Internet Society (2004). All Rights Reserved. 39 Abstract 41 Bridging multiple links into a single entity has several 42 operational advantages. A single subnet prefix is sufficient to 43 support multiple physical links. There is no need to allocate 44 subnet numbers to the different networks, simplifying management. 45 Bridging some types of media requires network-layer support, 46 however. This document describes these cases and specifies the 47 IP-layer support that enables bridging under these circumstances. 49 1. Introduction 51 In the IPv4 Internet today, it is common for Network Address 52 Translators (NATs) [NAT] to be used to easily connect one or more 53 leaf links to an existing network without requiring any 54 coordination with the network service provider. Since NATs modify 55 IP addresses in packets, they are problematic for many IP 56 applications. As a result, it is desirable to address the problem 57 (for both IPv4 and IPv6) without the need for NATs. 59 Another common solution is IEEE 802 bridging, as specified in 60 [BRIDGE]. It is expected that whenever possible links will be 61 bridged at the link layer using classic bridge technology [BRIDGE] 62 as opposed to using the mechanisms herein. However, classic 63 bridging at the data-link layer has the following limitations 64 (among others): 66 o It requires the ports to support promiscuous mode. 68 o It requires all ports to support the same type of link-layer 69 addressing (in particular, IEEE 802 addressing). 71 As a result, two common scenarios, described below, are not 72 solved, and it is these two scenarios we specifically target in 73 this document. While the mechanism described herein may apply to 74 other scenarios as well, we will concentrate our discussion on 75 these two scenarios. 77 Draft ND Proxy October 2004 79 1.1. SCENARIO 1: Wireless upstream 81 The following figure illustrates a likely example: 83 | +-------+ +--------+ 84 local |Ethernet | | Wireless | Access | 85 +---------+ A +-))) (((-+ +--> rest of network 86 hosts | | | link | Point | 87 | +-------+ +--------+ 89 In this scenario, the access point has assigned an IPv4 and/or an 90 IPv6 subnet prefix to the wireless link, and uses link-layer 91 encryption so that wireless clients may not see each other's data. 93 Classic bridging requires the bridge (node A in the above diagram) 94 to be in promiscuous mode. In this wireless scenario, A cannot 95 put its wireless interface into promiscuous mode, since one 96 wireless node cannot see traffic to/from other wireless nodes. 97 This document describes a solution for both IPv4 and IPv6 which 98 does not involve NAT or require any change to the access point or 99 router. 101 IPv4 ARP proxying has been used for some years to solve this 102 problem, but the behavior has not been described in a 103 specification. In this document, we describe how this may be 104 implemented, and also enable equivalent functionality for IPv6 to 105 remove this incentive to deploy NATs in 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 supported 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 2004 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 believes that the other end of the 137 PPP link (node A) has a single IPv4 address, as negotiated by PPP. 138 For IPv6, it has assigned a /64 to the link and advertises it in 139 an IPv6 Router Advertisement. 141 Classic bridging does not support non-802 media, and hence IPv4 142 connectivity is solved by making the proxy (node A in the above 143 diagram) be a NAT. This document does not specify any other IPv4 144 solution for this scenario. However, this document does specify a 145 solution for IPv6 which does not involve NAT or require any change 146 to the router. 148 2. Terminology 150 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 151 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" 152 in this document are to be interpreted as described in BCP 14, RFC 153 2119 [KEYWORDS]. 155 The term "proxy interface" will be used to refer to an interface 156 (which could itself be a bridge interface) over which network 157 layer proxying is done as defined herein. 159 In this document we make no distinction between a "link" (in the 160 classic IPv6 sense) and a "subnet". We use the term "segment" to 161 apply to a bridged component of the link. 163 Finally, while it is possible that functionality equivalent to 164 that described herein may be achieved by nodes which do not 165 fulfill all the requirements in [NODEREQ], in the remainder of 166 this document we will describe behavior in terms of an IPv6 node 167 as defined in that document. 169 Draft ND Proxy October 2004 171 3. Requirements 173 Bridge-like proxy behavior is designed with the following 174 requirements in mind: 176 o Support connecting multiple segments with a single subnet 177 prefix. 179 o Support media which cannot be bridged at the link-layer. 180 Note, this document does not support bridging of non-802 181 media for IPv4. 183 o Support both IPv6 and IPv4 for 802 media. 185 o Do not require any changes to existing routers. That is, any 186 routers on the subnet should be unaware that the subnet is 187 being bridged. 189 o Provide full connectivity between all nodes in the subnet. 190 For example, if there are existing nodes (such as any routers 191 on the subnet) which have addresses in the subnet prefix, 192 adding a bridge-like proxy must allow bridged nodes to have 193 full connectivity with existing nodes on the subnet. 195 o Prevent loops. 197 o Also work in the absense of any routers. 199 o Support secure IPv6 neighbor discovery. This is discussed in 200 the Security Considerations section. 202 o Support nodes moving between segments. For example, a node 203 should be able to keep its address without seeing its address 204 as a duplicate due to any cache maintained at the proxy. 206 o Allow dynamic addition/removal of a proxy without adversely 207 disrupting the network. 209 o The proxy behavior should not break any existing classic 210 bridges in use on a network segment. 212 Draft ND Proxy October 2004 214 3.1. Non-requirements 216 The following items are not considered requirements, as they are 217 not met by classic bridges: 219 o Show up as a hop in a traceroute. 221 o Use the shortest path between two nodes on different 222 segments. 224 o Be able to use all available interfaces simultaneously. 225 Instead, bridging technology relies on disabling redundant 226 interfaces to prevent loops. 228 o Support connecting media on which Neighbor Discovery is not 229 possible. For example, some technologies such as [6TO4] use 230 an algorithmic mapping from IPv6 address to the underlying 231 link-layer (IPv4 in this case) address, and hence cannot 232 support bridging arbitrary IP addresses. 234 The following additional items are not considered requirements for 235 this document: 237 o Support network-layer protocols other than IPv4 and IPv6. We 238 do not preclude such support, but it is not specified in this 239 document. 241 o Support Neighbor Discovery, Router Discovery, or DHCPv4 242 packets using IPsec. We also note that the current methods 243 for securing these protocols do not use IPsec so this is 244 considered acceptable. 246 o Support Redirects for off-subnet destinations that point to a 247 router on a different segment from the redirected host. 248 While this scenario may be desirable, no solution is 249 currently known which does not have undesirable side effects 250 outside the subnet. As a result, this scenario is outside 251 the scope of this document. 253 4. Bridge-Like Proxy Behavior 255 Network layer support for proxying between multiple interfaces 256 SHOULD be used only when classic bridging is not possible. 258 Draft ND Proxy October 2004 260 When a proxy interface comes up, the node puts it in "all- 261 multicast" mode so that it will receive all multicast packets. It 262 is common for interfaces to not support full promiscuous mode 263 (e.g., on a wireless client), but all-multicast mode is generally 264 still supported. 266 As with all other interfaces, IPv4 and IPv6 maintain a neighbor 267 cache (aka "ARP cache") for each proxy interface, which will be 268 used as described below. For readability, we will describe the 269 neighbor cache as if both IPv4 and IPv6 neighbors use the same 270 state machine described in [ND]. 272 4.1. Receiving Packets 274 When a packet from any IP source address other than the 275 unspecified address is received on a proxy interface, the neighbor 276 cache of that interface SHOULD be consulted to find an entry for 277 the source IP address. If no entry exists, one is created in the 278 STALE state. 280 When any IP or ARP packet is received on a proxy interface, it 281 must be parsed to see whether it is known to be of a type that 282 negotiates link-layer addresses. This document covers the 283 following types: ARP, IPv6 Neighbor Discovery, IPv6 Router 284 Discovery, IPv6 Redirects, and DHCPv4. These packets are ones 285 that can carry link-layer addresses, and hence must be proxied (as 286 described below) so that packets between nodes on different 287 segments can be received by the proxy and have the correct link- 288 layer address type on each segment. 290 When any other IP broadcast or multicast packet (other than to the 291 IPv6 Link-scoped STP Multicast Group) is received on a proxy 292 interface, in addition to any normal IP behavior such as being 293 delivered locally, it is forwarded unchanged out all other proxy 294 interfaces on the same link. (As specified in [BRIDGE], the proxy 295 may instead support multicast learning and filtering but this is 296 optional.) In particular, the IPv4 TTL or IPv6 Hop Limit is not 297 updated, and no ICMP errors are sent as a result of attempting 298 this forwarding. 300 When any other IP unicast packet is received on a proxy interface, 301 if it is not locally destined then it is forwarded unchanged to 302 the proxy interface for which the next hop address appears in the 303 neighbor cache. Again the IPv4 TTL or IPv6 Hop Limit is not 304 Draft ND Proxy October 2004 306 updated, and no ICMP errors are sent as a result of attempting 307 this forwarding. To choose a proxy interface to forward to, the 308 neighbor cache is consulted, and the interface with the neighbor 309 entry in the "best" state is used. In order of least to most 310 preferred, the states (per [ND]) are INCOMPLETE, STALE, DELAY, 311 PROBE, REACHABLE. A packet is never forwarded back out the same 312 interface on which it arrived; such a packet is instead silently 313 dropped. 315 If no cache entry exists (as may happen if the proxy has 316 previously evicted the cache entry or if the proxy is restarted), 317 the proxy SHOULD queue the packet and initiate Neighbor Discovery 318 as if the packet were being locally generated. The proxy MAY 319 instead silently drop the packet. In this case, the entry will 320 eventually be recreated when the sender re-attempts neighbor 321 discovery. 323 The link layer header, and the link-layer address within the 324 payload for each forwarded packet will be modified as follows: 326 1) The source address will be the address of the outgoing 327 interface. 329 2) The destination address will be the address in the neighbor 330 entry corresponding to the destination IP address. 332 3) The link-layer address within the payload is substituted with 333 the address of the outgoing interface. 335 4.1.1. Sending Packet Too Big Messages 337 Whenever any packet is to be forwarded out an interface whose MTU 338 is smaller than the size of the packet, the ND proxy drops the 339 packet and sends a Packet Too Big message back to the source, as 340 described in [ICMPv6]. 342 4.1.2. Proxying Packets With Link-Layer Addresses 344 Once it is determined that the packet is either 345 multicast/broadcast or else is not locally destined (if unicast), 346 the special types enumerated above (ARP, etc.) that carry link- 347 layer addresses are handled by generating a proxy packet that 348 contains the proxy's link-layer address on the outgoing interface 349 Draft ND Proxy October 2004 351 instead. Section 7, "Guidelines to proxy developers", describes 352 the scenarios in which the link-layer address substitution in the 353 payload should be performed. 355 As with all forwarded packets, the link-layer header is also new. 356 Note that any change to the length of a proxied packet, such as 357 when the link-layer address length changes, will require 358 corresponding changes to fields in the IP header, namely the IPv4 359 Total Length and Header Checksum fields, or the IPv6 Payload 360 Length field. 362 4.1.3. IPv4 ARP Proxying 364 When any IPv4 or ARP packet is received on a proxy interface, it 365 must be parsed to see whether it is known to be one of the 366 following types: ARP, or DHCPv4. 368 4.1.3.1. ARP REQUEST Packets 370 If the received packet is an ARP REQUEST, the request is processed 371 locally but no ARP REPLY is generated immediately. Instead, the 372 ARP REQUEST is proxied (as described above) and the ARP REPLY will 373 be proxied when it is received. This ensures that the proxy does 374 not interfere with hosts moving from one segment to another since 375 it never responds to an ARP REQUEST based on its own cache. 377 4.1.3.2. ARP REPLY Packets 379 If the received packet is an ARP REPLY, the neighbor cache on the 380 receiving interface is first updated as if the ARP REPLY were 381 locally destined, and then the ARP REPLY is proxied as described 382 above. 384 4.1.3.3. DHCPv4 Packets 386 If the received packet is a DHCPv4 DISCOVER or REQUEST message, 387 then instead of changing the client's hardware address in the 388 payload, the BROADCAST (B) flag is set in the proxied packet. 389 This ensures that the proxy will be able to receive and proxy the 390 response since the response will be broadcast rather than unicast 391 to that hardware address. The hardware address is thus used only 392 Draft ND Proxy October 2004 394 as a unique identifier and hence need not be a link-layer address 395 on the same segment. 397 4.1.4. IPv6 ND Proxying 399 When any IPv6 packet is received on a proxy interface, it must be 400 parsed to see whether it is known to be one of the following 401 types: IPv6 Neighbor Discovery, IPv6 Router Discovery, or IPv6 402 Redirects. 404 4.1.4.1. ICMPv6 Neighbor Solicitations 406 If the received packet is an ICMPv6 Neighbor Solicitation, the NS 407 is processed locally as described in section 7.2.3 of [ND] but no 408 NA is generated immediately. Instead the NS is proxied as 409 described above and the NA will be proxied when it is received. 410 This ensures that the proxy does not interfere with hosts moving 411 from one segment to another since it never responds to an NS based 412 on its own cache. 414 4.1.4.2. ICMPv6 Neighbor Advertisements 416 If the received packet is an ICMPv6 Neighbor Advertisement, the 417 neighbor cache on the receiving interface is first updated as if 418 the NA were locally destined, and then the NA is proxied as 419 described above. 421 4.1.4.3. ICMPv6 Redirects 423 If the received packet is an ICMPv6 Redirect message, then the 424 proxied packet should be modified as follows. If the proxy has a 425 valid (i.e., not INCOMPLETE) neighbor entry for the target address 426 on the same interface as the redirected host, then the TLLA option 427 in the proxied Redirect simply contains the link-layer address of 428 the target as found in the proxy's neighbor entry, since the 429 redirected host may reach the target address directly. Otherwise, 430 if the proxy has a valid neighbor entry for the target address on 431 some other interface, then the TLLA option in the proxied packet 432 contains the link-layer address of the proxy on the sending 433 interface, since the redirected host must reach the target address 434 through the proxy. Otherwise, the proxy has no valid neighbor 435 Draft ND Proxy October 2004 437 entry for the target address, and the proxied packet contains no 438 TLLA option, which will cause the redirected host to perform 439 neighbor discovery for the target address. 441 4.2. Sending Packets 443 Locally originated packets that are sent on a proxy interface also 444 follow the same rules as packets received on a proxy interface. 445 If no neighbor entry exists when a unicast packet is to be locally 446 originated, an interface can be chosen in any implementation- 447 specific fashion. Once the neighbor is resolved, the actual 448 interface will be discovered and the packet will be sent on that 449 interface. When a multicast or broadcast packet is to be locally 450 originated, an interface can be chosen in any implementation- 451 specific fashion, and the packet will then be forwarded out other 452 proxy interfaces on the same link as described in Section 4.1 453 above. 455 5. Example 457 Consider the following topology, where A and B are nodes on 458 separate segments which are connected by a bridge-like proxy P: 460 A---|---P---|---B 461 a p1 p2 b 463 A and B have link-layer addresses a and b, respectively. P has 464 link-layer addresses p1 and p2 on the two segments. We now walk 465 through the actions that happen when A attempts to send an initial 466 IPv6 packet to B. 468 A first does a route lookup on the destination address B. This 469 matches the on-link subnet prefix, and a destination cache entry 470 is created as well as a neighbor cache entry in the INCOMPLETE 471 state. Before the packet can be sent, A needs to resolve B's 472 link-layer address and sends a Neighbor Solicitation (NS) to the 473 solicited-node multicast address for B. The SLLA option in the 474 solicitation contains A's link-layer address. 476 P receives the solicitation (since it is receiving all link-layer 477 multicast packets) and processes it as it would any multicast 478 packet by forwarding it out to other segments on the link. 479 However, before actually sending the packet, it determines if the 480 Draft ND Proxy October 2004 482 packet being sent is one which requires proxying. Since it is an 483 NS, it creates a neighbor entry for A on interface 1 and records 484 its link-layer address. It also creates a neighbor entry for B 485 (on an arbitrary proxy interface) in the INCOMPLETE state. Since 486 the packet is multicast, P then needs to proxy the NS out all 487 other proxy interfaces on the subnet. Before sending the packet 488 out interface 2, it replaces the link-layer address in the SLLA 489 option with its own link-layer address, p2. 491 B receives this NS, processing it as usual. Hence it creates a 492 neighbor entry for A mapping it to the link-layer address p2. It 493 responds with a Neighbor Advertisement (NA) sent to A containing 494 B's link-layer address b. The NA is sent using A's neighbor 495 entry, i.e. to the link-layer address p2. 497 The NA is received by P, which then processes it as it would any 498 unicast packet; i.e., it forwards this out interface 1, based on 499 the neighbor cache. However, before actually sending the packet 500 out, it inspects it to determine if the packet being sent is one 501 which requires proxying. Since it is an NA, it updates its 502 neighbor entry for B to be REACHABLE and records the link-layer 503 address b. P then replaces the link-layer address in the TLLA 504 option with its own link-layer address on the outgoing interface, 505 p1. The packet is then sent out interface 1. 507 A receives this NA, processing it as usual. Hence it creates a 508 neighbor entry for B on interface 2 in the REACHABLE state and 509 records the link-layer address p1. 511 6. Loop Prevention 513 Loop prevention can be done done by having the proxy implement the 514 Spanning Tree Algorithm and Protocol as defined in [BRIDGE] on all 515 proxy interfaces. Loop prevention is OPTIONAL, and is useful only 516 if the proxy can be deployed in an environment where physical 517 loops are possible. For example, in a cell phone which proxies 518 between a PPP dialup link and a local Ethernet interface, it is 519 typically safe to assume that physical loops are not possible and 520 hence there is no need to support the Spanning Tree Protocol 521 (STP). 523 If loop prevention is implemented, it is done as follows. IEEE 524 802 interfaces use the protocol exactly as specified in [BRIDGE]. 525 Operation of the Spanning Tree Protocol (STP) over other types of 526 Draft ND Proxy October 2004 528 link layers is done by encapsulating the STP frame in an IPv6 529 header as follows. The Next Header field is set to [TBA by IANA], 530 indicating that an STP header follows. The Destination Address 531 field is set to the Link-scoped STP Multicast Group [TBA by IANA]. 532 All proxies operating on non-IEEE 802 media join this group so 533 they will receive STP packets. STP packets are never forwarded or 534 proxied. 536 7. Guidelines to proxy developers 538 Proxy developers will have to accomodate protocols or protocol 539 options (for example, new ICMP messages) that are developed in the 540 future, or protocols that are not mentioned in this document (for 541 example, proprietary protocols). This section prescribes 542 guidelines that can be used by proxy developers to accomodate 543 protocols that are not mentioned herein. 545 1) If a link-layer address carried in the payload of the 546 protocol can be used in the link-layer header of future 547 messages, then the proxy should substitute it with its own 548 address. For example the link-layer address in NA messages is 549 used in the link-layer header for future messages, and, 550 hence, the proxy substitutes it with its own address. 552 For broadcast/multicast packets, the link-layer address 553 substituted within the payload will be different for each 554 outgoing interface. 556 2) If the link-layer address in the payload of the protocol will 557 never be used in any link-layer header, then the proxy should 558 not substitute it with its own address. No special actions 559 are required for supporting these protocols. For example, 560 [DHCPv6] is in this category. 562 8. IANA Considerations 564 To support loop prevention over non-802 media, IANA should assign: 566 1) a Protocol Number for STP, and 568 2) an IPv6 Link-Local Scope multicast address for All-STP- 569 Speakers. 571 Draft ND Proxy October 2004 573 9. Security Considerations 575 Proxies are susceptible to the same kind of security issues that 576 plague hosts using unsecured Neighbor Discovery or ARP. Even if 577 these protocols are secured, the proxies may process unsecured 578 messages, and update the neighbor cache. Malicious nodes within 579 the subnet can take advantage of this property, and hijack 580 traffic. The threats are discussed in detail in [PSREQ]. 582 As a result, securing Neighbor Discovery or ARP must take into 583 account the ability to proxy messages. This document does not 584 introduce any new requirements in this regard. 586 From an IPv6 perspective, RFC 2461 [ND] already defines the 587 ability to proxy Neighbor Advertisements. The requirements for 588 securing proxied messages are similar to those for securing Router 589 Advertisements, since the receiver must verify that the 590 advertisement came from a valid router/proxy, rather than from the 591 owner of a specific address. 593 10. Appendix A: Comparison with Naive RA Proxy 595 It has been suggested that a simple Router Advertisement (RA) 596 proxy would be sufficient, where the subnet prefix in an RA is 597 "stolen" by the proxy and applied to a downstream link instead of 598 an upstream link. Other ND messages are not proxied. 600 There are many problems with this approach. First, it requires 601 cooperation from all nodes on the upstream link. No node 602 (including the router sending the RA) can have an address in the 603 subnet or it will not have connectivity with nodes on the 604 downstream link. This is because when a node on a downstream link 605 tries to do Neighbor Discovery, and the proxy does not send the NS 606 on the upstream link, it will never discover the neighbor on the 607 upstream link. Similarly, if messages are not proxied during DAD, 608 conflicts can occur. 610 Second, if the proxy assumes that no nodes on the upstream link 611 have addresses in the prefix, such a proxy could not be safely 612 deployed without cooperation from the network administrator since 613 it introduces a requirement that the router itself not have an 614 address in the prefix. This rules out use in situations where 615 bridges and Network Address Translators (NATs) are used today, 616 which is the problem this document is directly addressing. 618 Draft ND Proxy October 2004 620 Instead, where a prefix is desired for use on one or more 621 downstream links in cooperation with the network administrator, 622 Prefix Delegation [PD] should be used instead. 624 11. Authors' Addresses 626 Dave Thaler 627 Microsoft Corporation 628 One Microsoft Way 629 Redmond, WA 98052-6399 630 Phone: +1 425 703 8835 631 EMail: dthaler@microsoft.com 633 Mohit Talwar 634 Microsoft Corporation 635 One Microsoft Way 636 Redmond, WA 98052-6399 637 Phone: +1 425 705 3131 638 EMail: mohitt@microsoft.com 640 Chirayu Patel 641 All Play, No Work 642 Bangalore, Karnataka 560038 643 Phone: +91-98452-88078 644 EMail: chirayu@chirayu.org 646 12. Normative References 648 [ARP] 649 D. Plummer, "An Ethernet Address Resolution Protocol", STD 650 37, RFC 826, November 1982. 652 [BRIDGE] 653 T. Jeffree, editor, "Media Access Control (MAC) Bridges", 654 ANSI/IEEE Std 802.1D, 1998, 655 http://standards.ieee.org/getieee802/download/802.1D-1998.pdf. 657 [DHCPv4] 658 R. Droms, "Dynamic Host Configuration Protocol", RFC 2131, 660 Draft ND Proxy October 2004 662 March 1997. 664 [ICMPv6] 665 Conta, A. and S. Deering, "Internet Control Message Protocol 666 (ICMPv6) for the Internet Protocol Version 6 (IPv6) 667 Specification", RFC 2463, December 1998. 669 [KEYWORDS] 670 S. Bradner, "Key words for use in RFCs to Indicate 671 Requirement Levels", BCP 14, RFC 2119, March, 1997. 673 [ND] Narten, T., Nordmark, E. and W. Simpson, "Neighbor Discovery 674 for IP Version 6 (IPv6)", RFC 2461, December 1998. 676 [NODEREQ] 677 J. Loughney, "IPv6 Node Requirements", Work in progress, 678 draft-ietf-ipv6-node-requirements-11.txt, August 2004. 680 13. Informative References 682 [6TO4] 683 Carpenter, B. and K. Moore, "Connection of IPv6 Domains via 684 IPv4 Clouds", RFC 3056, February 2001. 686 [DHCPv6] 687 Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins, C. 688 and M. Carney, "Dynamic Host Configuration Protocol for IPv6 689 (DHCPv6)", RFC 3315, July 2003. 691 [NAT] 692 Srisuresh, P. and K. Egevang, "Traditional IP Network Address 693 Translator (Traditional NAT)", RFC 3022, January 2001. 695 [PD] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic Host 696 Configuration Protocol (DHCP) version 6", RFC 3633, December 697 2003. 699 Draft ND Proxy October 2004 701 [PSREQ] 702 Nikander, P., Kempf, J. and E. Nordmark, "IPv6 Neighbor 703 Discovery (ND) Trust Models and Threats", RFC 3756, May 2004. 705 14. Full Copyright Statement 707 Copyright (C) The Internet Society (2004). This document is 708 subject to the rights, licenses and restrictions contained in BCP 709 78, and except as set forth therein, the authors retain all their 710 rights. 712 This document and the information contained herein are provided on 713 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 714 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND 715 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, 716 EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT 717 THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR 718 ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A 719 PARTICULAR PURPOSE. 721 15. Intellectual Property 723 The IETF takes no position regarding the validity or scope of any 724 Intellectual Property Rights or other rights that might be claimed 725 to pertain to the implementation or use of the technology 726 described in this document or the extent to which any license 727 under such rights might or might not be available; nor does it 728 represent that it has made any independent effort to identify any 729 such rights. Information on the procedures with respect to rights 730 in RFC documents can be found in BCP 78 and BCP 79. 732 Copies of IPR disclosures made to the IETF Secretariat and any 733 assurances of licenses to be made available, or the result of an 734 attempt made to obtain a general license or permission for the use 735 of such proprietary rights by implementers or users of this 736 specification can be obtained from the IETF on-line IPR repository 737 at http://www.ietf.org/ipr. 739 The IETF invites any interested party to bring to its attention 740 any copyrights, patents or patent applications, or other 741 proprietary rights that may cover technology that may be required 742 to implement this standard. Please address the information to the 743 IETF at ietf-ipr@ietf.org.