Network Working Group Request for Comments: 4389 Category: Experimental C. Patel All Play, No Work April 2006

Transcription

1 Netwrk Wrking Grup Request fr Cmments: 4389 Categry: Experimental D. Thaler M. Talwar Micrsft C. Patel All Play, N Wrk April 2006 Status f This Mem Neighbr Discvery Prxies (ND Prxy) This mem defines an Experimental Prtcl fr the Internet cmmunity. It des nt specify an Internet standard f any kind. Discussin and suggestins fr imprvement are requested. Distributin f this mem is unlimited. Cpyright Ntice Cpyright (C) The Internet Sciety (2006). Abstract Bridging multiple links int a single entity has several peratinal advantages. A single subnet prefix is sufficient t supprt multiple physical links. There is n need t allcate subnet numbers t the different netwrks, simplifying management. Bridging sme types f media requires netwrk-layer supprt, hwever. This dcument describes these cases and specifies the IP-layer supprt that enables bridging under these circumstances. Thaler, et al. Experimental [Page 1]

2 RFC 4389 ND Prxy April 2006 Table f Cntents 1. Intrductin SCENARIO 1: Wireless Upstream SCENARIO 2: PPP Upstream Inapplicable Scenaris Terminlgy Requirements Nn-requirements Prxy Behavir Frwarding Packets Sending Packet T Big Messages Prxying Packets with Link-Layer Addresses IPv6 ND Prxying ICMPv6 Neighbr Slicitatins ICMPv6 Neighbr Advertisements ICMPv6 Ruter Advertisements ICMPv6 Redirects Originating Packets Example Lp Preventin Guidelines t Prxy Develpers IANA Cnsideratins Security Cnsideratins Acknwledgements Nrmative References Infrmative References...15 Appendix A: Cmparisn with Naive RA Prxy...16 Thaler, et al. Experimental [Page 2]

3 RFC 4389 ND Prxy April Intrductin In the IPv4 Internet tday, it is cmmn fr Netwrk Address Translatrs (NATs) [NAT] t be used t easily cnnect ne r mre leaf links t an existing netwrk withut requiring any crdinatin with the netwrk service prvider. Since NATs mdify IP addresses in packets, they are prblematic fr many IP applicatins. As a result, it is desirable t address the prblem (fr bth IPv4 and IPv6) withut the need fr NATs, while still maintaining the prperty that n explicit cperatin frm the ruter is needed. One cmmn slutin is IEEE 802 bridging, as specified in [BRIDGE]. It is expected that whenever pssible links will be bridged at the link layer using classic bridge technlgy [BRIDGE] as ppsed t using the mechanisms herein. Hwever, classic bridging at the datalink layer has the fllwing limitatins (amng thers): It requires the prts t supprt prmiscuus mde. It requires all prts t supprt the same type f link-layer addressing (in particular, IEEE 802 addressing). As a result, tw cmmn scenaris, described belw, are nt slved, and it is these tw scenaris we specifically target in this dcument. While the mechanism described herein may apply t ther scenaris as well, we will cncentrate ur discussin n these tw scenaris SCENARIO 1: Wireless Upstream The fllwing figure illustrates a likely example: lcal Ethernet Wireless Access A +-))) (((-+ +--> rest f netwrk hsts link Pint In this scenari, the access pint has assigned an IPv6 subnet prefix t the wireless link, and uses link-layer encryptin s that wireless clients may nt see each ther s data. Classic bridging requires the bridge (nde A in the abve diagram) t be in prmiscuus mde. In this wireless scenari, A cannt put its wireless interface int prmiscuus mde, since ne wireless nde cannt see traffic t/frm ther wireless ndes. Thaler, et al. Experimental [Page 3]

4 RFC 4389 ND Prxy April 2006 IPv4 Address Reslutin Prtcl (ARP) prxying has been used fr sme years t slve this prblem withut invlving NAT r requiring any change t the access pint r ruter. In this dcument, we describe equivalent functinality fr IPv6 t remve this incentive t deply NATs in IPv6. We als nte that Prefix Delegatin [PD] culd als be used t slve this scenari. There are, hwever, tw disadvantages t this. First, if an implementatin already supprts IPv4 ARP prxying (which is indeed the case in a number f implementatins tday), then IPv6 Prefix Delegatin wuld result in separate IPv6 subnets n either side f the device, while a single IPv4 subnet wuld span bth segments. This tplgical discrepancy can cmplicate applicatins and prtcls that use the cncept f a lcal subnet. Secnd, the extent t which Prefix Delegatin is supprted fr any particular subscriber class is up t the service prvider. Hence, there is n guarantee that Prefix Delegatin will wrk withut explicit cnfiguratin r additinal charge. Bridging, n the ther hand, allws the device t wrk with zer cnfiguratin, regardless f the service prvider s plicies, just as a NAT des. Hence bridging avids the incentive t NAT IPv6 just t avid paying fr, r requiring cnfiguratin t get, anther prefix SCENARIO 2: PPP Upstream The fllwing figure illustrates anther likely example: lcal Ethernet PPP link A Ruter +--> rest f netwrk hsts In this scenari, the ruter has assigned a /64 t the PPP link and advertises it in an IPv6 Ruter Advertisement. Classic bridging des nt supprt nn-802 media. The PPP Bridging Cntrl Prtcl [BCP] defines a mechanism fr supprting bridging ver PPP, but it requires bth ends t be cnfigured t supprt it. Hence IPv4 cnnectivity is ften slved by making the prxy (nde A in the abve diagram) be a NAT r an IPv4 ARP prxy. This dcument specifies a slutin fr IPv6 that des nt invlve NAT r require any change t the ruter. Thaler, et al. Experimental [Page 4]

5 RFC 4389 ND Prxy April Inapplicable Scenaris This dcument is nt applicable t scenaris with lps in the physical tplgy, r where ruters exist n multiple segments. These cases are detected and prxying is disabled (see Sectin 6). In additin, this dcument is nt apprpriate fr scenaris where classic bridging can be applied, r when cnfiguratin f the ruter can be dne. 2. Terminlgy The key wrds "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this dcument are t be interpreted as described in BCP 14, RFC 2119 [KEYWORDS]. The term "prxy interface" will be used t refer t an interface (which culd itself be a bridge interface) ver which netwrk-layer prxying is dne as defined herein. In this dcument, we make n distinctin between a "link" (in the classic IPv6 sense) and a "subnet". We use the term "segment" t apply t a bridged cmpnent f the link. Finally, while it is pssible that functinality equivalent t that described herein may be achieved by ndes that d nt fulfill all the requirements in [NODEREQ], in the remainder f this dcument we will describe behavir in terms f an IPv6 nde as defined in that dcument. 3. Requirements Prxy behavir is designed with the fllwing requirements in mind: Supprt cnnecting multiple segments with a single subnet prefix. Supprt media that cannt be bridged at the link layer. D nt require any changes t existing ruters. That is, ruters n the subnet may be unaware that the subnet is being bridged. Thaler, et al. Experimental [Page 5]

6 RFC 4389 ND Prxy April 2006 Prvide full cnnectivity between all ndes in the subnet. Fr example, if there are existing ndes (such as any ruters n the subnet) that have addresses in the subnet prefix, adding a prxy must allw bridged ndes t have full cnnectivity with existing ndes n the subnet. Prevent lps. Als wrk in the absence f any ruters. Supprt ndes mving between segments. Fr example, a nde shuld be able t keep its address withut seeing its address as a duplicate due t any cache maintained at the prxy. Allw dynamic additin f a prxy withut adversely disrupting the netwrk. The prxy behavir shuld nt break any existing classic bridges in use n a netwrk segment Nn-requirements The fllwing items are nt cnsidered requirements, as they are nt met by classic bridges: Shw up as a hp in a tracerute. Use the shrtest path between tw ndes n different segments. Be able t use all available interfaces simultaneusly. Instead, bridging technlgy relies n disabling redundant interfaces t prevent lps. Supprt cnnecting media n which Neighbr Discvery is nt pssible. Fr example, sme technlgies such as [6TO4] use an algrithmic mapping frm IPv6 address t the underlying link-layer (IPv4 in this case) address, and hence cannt supprt bridging arbitrary IP addresses. The fllwing additinal items are nt cnsidered requirements fr this dcument: Supprt netwrk-layer prtcls ther than IPv6. We d nt preclude such supprt, but it is nt specified in this dcument. Thaler, et al. Experimental [Page 6]

7 RFC 4389 ND Prxy April 2006 Supprt Redirects fr ff-subnet destinatins that pint t a ruter n a different segment frm the redirected hst. While this scenari may be desirable, n slutin is currently knwn that des nt have undesirable side effects utside the subnet. As a result, this scenari is utside the scpe f this dcument. 4. Prxy Behavir Netwrk-layer supprt fr prxying between multiple interfaces SHOULD be used nly when classic bridging is nt pssible. When a prxy interface cmes up, the nde puts it in "all-multicast" mde s that it will receive all multicast packets. It is cmmn fr interfaces nt t supprt full prmiscuus mde (e.g., n a wireless client), but all-multicast mde is generally still supprted. As with all ther interfaces, IPv6 maintains a neighbr cache fr each prxy interface, which will be used as described belw Frwarding Packets When a packet frm any IPv6 surce address ther than the unspecified address is received n a prxy interface, the neighbr cache f that interface SHOULD be cnsulted t find an entry fr the surce IPv6 address. If n entry exists, ne is created in the STALE state. When any IPv6 packet is received n a prxy interface, it must be parsed t see whether it is knwn t be f a type that negtiates link-layer addresses. This dcument cvers the fllwing types: Neighbr Slicitatins, Neighbr Advertisements, Ruter Advertisements, and Redirects. These packets are nes that can carry link-layer addresses, and hence must be prxied (as described belw) s that packets between ndes n different segments can be received by the prxy and have the crrect link-layer address type n each segment. When any ther IPv6 multicast packet is received n a prxy interface, in additin t any nrmal IPv6 behavir such as being delivered lcally, it is frwarded unchanged (ther than using a new link-layer header) ut all ther prxy interfaces n the same link. (As specified in [BRIDGE], the prxy may instead supprt multicast learning and filtering, but this is OPTIONAL.) In particular, the IPv6 Hp Limit is nt updated, and n ICMP errrs (except as nted in Sectin belw) are sent as a result f attempting this frwarding. Thaler, et al. Experimental [Page 7]

8 RFC 4389 ND Prxy April 2006 When any ther IPv6 unicast packet is received n a prxy interface, if it is nt lcally destined then it is frwarded unchanged (ther than using a new link-layer header) t the prxy interface fr which the next hp address appears in the neighbr cache. Again the IPv6 Hp Limit is nt updated, and n ICMP errrs (except as nted in Sectin belw) are sent as a result f attempting this frwarding. T chse a prxy interface t frward t, the neighbr cache is cnsulted, and the interface with the neighbr entry in the "best" state is used. In rder f least t mst preferred, the states (per [ND]) are INCOMPLETE, STALE, DELAY, PROBE, REACHABLE. A packet is never frwarded back ut the same interface n which it arrived; such a packet is instead silently drpped. If n cache entry exists (as may happen if the prxy has previusly evicted the cache entry r if the prxy is restarted), the prxy SHOULD queue the packet and initiate Neighbr Discvery as if the packet were being lcally generated. The prxy MAY instead silently drp the packet. In this case, the entry will eventually be recreated when the sender re-attempts Neighbr Discvery. The link-layer header and the link-layer address within the paylad fr each frwarded packet will be mdified as fllws: 1) The surce address will be the address f the utging interface. 2) The destinatin address will be the address in the neighbr entry crrespnding t the destinatin IPv6 address. 3) The link-layer address within the paylad is substituted with the address f the utging interface Sending Packet T Big Messages Whenever any IPv6 packet is t be frwarded ut an interface whse MTU is smaller than the size f the packet, the ND prxy drps the packet and sends a Packet T Big message back t the surce, as described in [ICMPv6] Prxying Packets with Link-Layer Addresses Once it is determined that the packet is either multicast r else is nt lcally destined (if unicast), the special types enumerated abve (ARP, etc.) that carry link-layer addresses are handled by generating a prxy packet that cntains the prxy s link-layer address n the utging interface instead. Such link-layer addresses ccur in the Thaler, et al. Experimental [Page 8]

9 RFC 4389 ND Prxy April 2006 link-layer header itself, as well as in the paylads f sme prtcls. As with all frwarded packets, the link-layer header is new. Sectin enumerates the currently knwn cases where link-layer addresses must be changed in paylads. Fr guidance n handling future prtcls, Sectin 7, "Guidelines t Prxy Develpers", describes the scenaris in which the link-layer address substitutin in the paylad shuld be perfrmed. Nte that any change t the length f a prxied packet, such as when the link-layer address length changes, will require a crrespnding change t the IPv6 Paylad Length field IPv6 ND Prxying When any IPv6 packet is received n a prxy interface, it must be parsed t see whether it is knwn t be ne f the fllwing types: Neighbr Slicitatin, Neighbr Advertisement, Ruter Advertisement, r Redirect ICMPv6 Neighbr Slicitatins If the received packet is an ICMPv6 Neighbr Slicitatin (NS), the NS is prcessed lcally as described in Sectin f [ND] but n NA is generated immediately. Instead the NS is prxied as described abve and the NA will be prxied when it is received. This ensures that the prxy des nt interfere with hsts mving frm ne segment t anther since it never respnds t an NS based n its wn cache ICMPv6 Neighbr Advertisements If the received packet is an ICMPv6 Neighbr Advertisement (NA), the neighbr cache n the receiving interface is first updated as if the NA were lcally destined, and then the NA is prxied as described in abve ICMPv6 Ruter Advertisements The fllwing special prcessing is dne fr IPv6 Ruter Advertisements (RAs). A new "Prxy" bit is defined in the existing Ruter Advertisement flags field as fllws: M O H Prf P Rsv Thaler, et al. Experimental [Page 9]

10 RFC 4389 ND Prxy April 2006 where "P" indicates the lcatin f the Prxy bit, and "Rsv" indicates the remaining reserved bits. The prxy determines an "upstream" prxy interface, typically thrugh a (zer-cnfiguratin) physical chice dictated by the scenari (see Scenaris 1 and 2 abve), r thrugh manual cnfiguratin. When an RA with the P bit clear arrives n the upstream interface, the P bit is set when the RA is prxied ut all ther ("dwnstream") prxy interfaces (see Sectin 6). If an RA with the P bit set has arrived n a given interface (including the upstream interface) within the last 60 minutes, that interface MUST NOT be used as a prxy interface; i.e., prxy functinality is disabled n that interface. Furthermre, if any RA (regardless f the value f the P bit) has arrived n a "dwnstream" prxy interface within the last 60 minutes, that interface MUST NOT be used as a prxy interface. The RA is prcessed lcally as well as prxied as described in Sectin 4.1.2, unless such prxying is disabled as nted abve ICMPv6 Redirects If the received packet is an ICMPv6 Redirect message, then the prxied packet shuld be mdified as fllws. If the prxy has a valid (i.e., nt INCOMPLETE) neighbr entry fr the target address n the same interface as the redirected hst, then the Target Link-Layer Address (TLLA) ptin in the prxied Redirect simply cntains the link-layer address f the target as fund in the prxy s neighbr entry, since the redirected hst may reach the target address directly. Otherwise, if the prxy has a valid neighbr entry fr the target address n sme ther interface, then the TLLA ptin in the prxied packet cntains the link-layer address f the prxy n the sending interface, since the redirected hst must reach the target address thrugh the prxy. Otherwise, the prxy has n valid neighbr entry fr the target address, and the prxied packet cntains n TLLA ptin, which will cause the redirected hst t perfrm Neighbr Discvery fr the target address Originating Packets Lcally riginated packets that are sent n a prxy interface als fllw the same rules as packets received n a prxy interface. If n neighbr entry exists when a unicast packet is t be lcally riginated, an interface can be chsen in any implementatin-specific fashin. Once the neighbr is reslved, the actual interface will be Thaler, et al. Experimental [Page 10]

11 RFC 4389 ND Prxy April 2006 discvered and the packet will be sent n that interface. When a multicast packet is t be lcally riginated, an interface can be chsen in any implementatin-specific fashin, and the packet will then be frwarded ut ther prxy interfaces n the same link as described in Sectin 4.1 abve. 5. Example Cnsider the fllwing tplgy, where A and B are ndes n separate segments which are cnnected by a prxy P: A P B a p1 p2 b A and B have link-layer addresses a and b, respectively. P has link-layer addresses p1 and p2 n the tw segments. We nw walk thrugh the actins that happen when A attempts t send an initial IPv6 packet t B. A first des a rute lkup n the destinatin address B. This matches the n-link subnet prefix, and a destinatin cache entry is created as well as a neighbr cache entry in the INCOMPLETE state. Befre the packet can be sent, A needs t reslve B s link-layer address and sends a Neighbr Slicitatin (NS) t the slicited-nde multicast address fr B. The Surce Link-Layer Address (SLLA) ptin in the slicitatin cntains A s link-layer address. P receives the slicitatin (since it is receiving all link-layer multicast packets) and prcesses it as it wuld any multicast packet by frwarding it ut t ther segments n the link. Hwever, befre actually sending the packet, it determines if the packet being sent is ne that requires prxying. Since it is an NS, it creates a neighbr entry fr A n interface 1 and recrds its link-layer address. It als creates a neighbr entry fr B (n an arbitrary prxy interface) in the INCOMPLETE state. Since the packet is multicast, P then needs t prxy the NS ut all ther prxy interfaces n the subnet. Befre sending the packet ut interface 2, it replaces the link-layer address in the SLLA ptin with its wn link-layer address, p2. B receives this NS, prcessing it as usual. Hence it creates a neighbr entry fr A mapping it t the link-layer address p2. It respnds with a Neighbr Advertisement (NA) sent t A cntaining B s link-layer address b. The NA is sent using A s neighbr entry, i.e., t the link-layer address p2. Thaler, et al. Experimental [Page 11]

12 RFC 4389 ND Prxy April 2006 The NA is received by P, which then prcesses it as it wuld any unicast packet; i.e., it frwards this ut interface 1, based n the neighbr cache. Hwever, befre actually sending the packet ut, it inspects it t determine if the packet being sent is ne that requires prxying. Since it is an NA, it updates its neighbr entry fr B t be REACHABLE and recrds the link-layer address b. P then replaces the link-layer address in the TLLA ptin with its wn link-layer address n the utging interface, p1. The packet is then sent ut interface 1. A receives this NA, prcessing it as usual. Hence it creates a neighbr entry fr B n interface 2 in the REACHABLE state and recrds the link-layer address p1. 6. Lp Preventin An implementatin MUST ensure that lps are prevented by using the P bit in RAs as fllws. The prxy determines an "upstream" prxy interface, typically thrugh a (zer-cnfiguratin) physical chice dictated by the scenari (see Scenaris 1 and 2 abve), r thrugh manual cnfiguratin. As described in Sectin , nly the upstream interface is allwed t receive RAs, and never frm ther prxies. Prxy functinality is disabled n an interface therwise. Finally, a prxy MUST wait until it has sent tw P bit RAs n a given "dwnstream" interface befre it enables frwarding n that interface. 7. Guidelines t Prxy Develpers Prxy develpers will have t accmmdate prtcls r prtcl ptins (fr example, new ICMP messages) that are develped in the future, r prtcls that are nt mentined in this dcument (fr example, prprietary prtcls). This sectin prescribes guidelines that can be used by prxy develpers t accmmdate prtcls that are nt mentined herein. 1) If a link-layer address carried in the paylad f the prtcl can be used in the link-layer header f future messages, then the prxy shuld substitute it with its wn address. Fr example, the link-layer address in NA messages is used in the link-layer header fr future messages, and, hence, the prxy substitutes it with its wn address. Fr multicast packets, the link-layer address substituted within the paylad will be different fr each utging interface. Thaler, et al. Experimental [Page 12]

13 RFC 4389 ND Prxy April ) If the link-layer address in the paylad f the prtcl will never be used in any link-layer header, then the prxy shuld nt substitute it with its wn address. N special actins are required fr supprting these prtcls. Fr example, [DHCPv6] is in this categry. 8. IANA Cnsideratins This dcument defines a new bit in the RA flags (the P bit). There is currently n registratin prcedure fr such bits, s IANA shuld nt take any actin. 9. Security Cnsideratins Unsecured Neighbr Discvery has a number f security issues, which are discussed in detail in [PSREQ]. RFC 3971 [SEND] defines security mechanisms that can prtect Neighbr Discvery. Prxies are susceptible t the same kind f security issues that plague hsts using unsecured Neighbr Discvery. These issues include hijacking traffic and denial-f-service within the subnet. Malicius ndes within the subnet can take advantage f this prperty, and hijack traffic. In additin, a Neighbr Discvery prxy is essentially a legitimate man-in-the-middle, which implies that there is a need t distinguish prxies frm unwanted man-inthe-middle attackers. This dcument des nt intrduce any new mechanisms fr the prtectin f prxy Neighbr Discvery. That is, it des nt prvide a mechanism frm authrizing certain devices t act as prxies, and it des nt prvide extensins t SEND t make it pssible t use bth SEND and prxies at the same time. We nte that RFC 2461 [ND] already defines the ability t prxy Neighbr Advertisements, and extensins t SEND are already needed t cver that case, independent f this dcument. Nte als that the use f prxy Neighbr Discvery may render it impssible t use SEND bth n the leaf subnet and n the external subnet. This is because the mdificatins perfrmed by the prxy will invalidate the RSA Signature Optin in a secured Neighbr Discvery message, and cause SEND-capable ndes t either discard the messages r treat them as unsecured. The latter is the desired peratin when SEND is used tgether with this specificatin, and it ensures that SEND ndes within this envirnment can selectively dwngrade themselves t unsecure Neighbr Discvery when prxies are present. Thaler, et al. Experimental [Page 13]

14 RFC 4389 ND Prxy April 2006 In the fllwing, we utline sme ptential paths t fllw when defining a secure prxy mechanism. It is reasnable fr ndes n the leaf subnet t have a secure relatinship with the prxy and t accept ND packets either frm the wner f a specific address (nrmal SEND) r frm a trusted prxy that it can verify (see belw). Fr ndes n the external subnet, there is a trade-ff between security (where all ndes have a secure relatinship with the prxy) and privacy (where n ndes are aware that the prxy is a prxy). In the case f a pint-t-pint external link (Scenari 2), hwever, SEND may nt be a requirement n that link. Verifying that ND packets cme frm a trusted prxy requires an extensin t the SEND prtcl and is left fr future wrk [SPND], but is similar t the prblem f securing Ruter Advertisements that is supprted tday. Fr example, a rgue nde can send a Ruter Advertisement t cause a prxy t disable its prxy behavir, and hence cause denial-f-service t ther ndes; this threat is cvered in Sectin f [PSREQ]. Alternative designs might invlve schemes where the right fr representing a particular hst is delegated t the prxy, r where multiple ndes can make statements n behalf f ne address [RINGSIG]. 10. Acknwledgements The authrs wish t thank Jari Arkk fr cntributing prtins f the Security Cnsideratins text. 11. Nrmative References [BRIDGE] [ICMPv6] T. Jeffree, editr, "Media Access Cntrl (MAC) Bridges", ANSI/IEEE Std 802.1D, 2004, getieee802/dwnlad/802.1d-2004.pdf. Cnta, A. and S. Deering, "Internet Cntrl Message Prtcl (ICMPv6) fr the Internet Prtcl Versin 6 (IPv6) Specificatin", RFC 2463, December [KEYWORDS] Bradner, S., "Key wrds fr use in RFCs t Indicate Requirement Levels", BCP 14, RFC 2119, March [ND] Narten, T., Nrdmark, E., and W. Simpsn, "Neighbr Discvery fr IP Versin 6 (IPv6)", RFC 2461, December Thaler, et al. Experimental [Page 14]

15 RFC 4389 ND Prxy April 2006 [NODEREQ] Lughney, J., Ed., "IPv6 Nde Requirements", RFC 4294, April Infrmative References [6TO4] [BCP] [DHCPv6] [NAT] [PD] [PSREQ] [RINGSIG] [SEND] [SPND] Carpenter, B. and K. Mre, "Cnnectin f IPv6 Dmains via IPv4 Cluds", RFC 3056, February Higashiyama, M., Baker, F., and T. Lia, "Pint-t-Pint Prtcl (PPP) Bridging Cntrl Prtcl (BCP)", RFC 3518, April Drms, R., Ed., Bund, J., Vlz, B., Lemn, T., Perkins, C., and M. Carney, "Dynamic Hst Cnfiguratin Prtcl fr IPv6 (DHCPv6)", RFC 3315, July Srisuresh, P. and K. Egevang, "Traditinal IP Netwrk Address Translatr (Traditinal NAT)", RFC 3022, January Tran, O. and R. Drms, "IPv6 Prefix Optins fr Dynamic Hst Cnfiguratin Prtcl (DHCP) versin 6", RFC 3633, December Nikander, P., Kempf, J., and E. Nrdmark, "IPv6 Neighbr Discvery (ND) Trust Mdels and Threats", RFC 3756, May Kempf, J. and C. Gentry, "Secure IPv6 Address Prxying using Multi-Key Cryptgraphically Generated Addresses (MCGAs)", Wrk in Prgress, August Arkk, J., Ed., Kempf, J., Zill, B., and P. Nikander, "SEcure Neighbr Discvery (SEND)", RFC 3971, March Daley, G., "Securing Prxy Neighbur Discvery Prblem Statement", Wrk in Prgress, February Thaler, et al. Experimental [Page 15]

16 RFC 4389 ND Prxy April 2006 Appendix A: Cmparisn with Naive RA Prxy It has been suggested that a simple Ruter Advertisement (RA) prxy wuld be sufficient, where the subnet prefix in an RA is "stlen" by the prxy and applied t a dwnstream link instead f an upstream link. Other ND messages are nt prxied. There are many prblems with this apprach. First, it requires cperatin frm all ndes n the upstream link. N nde (including the ruter sending the RA) can have an address in the subnet r it will nt have cnnectivity with ndes n the dwnstream link. This is because when a nde n a dwnstream link tries t d Neighbr Discvery, and the prxy des nt send the NS n the upstream link, it will never discver the neighbr n the upstream link. Similarly, if messages are nt prxied during Duplicate Address Detectin (DAD), cnflicts can ccur. Secnd, if the prxy assumes that n ndes n the upstream link have addresses in the prefix, such a prxy culd nt be safely deplyed withut cperatin frm the netwrk administratr since it intrduces a requirement that the ruter itself nt have an address in the prefix. This rules ut use in situatins where bridges and Netwrk Address Translatrs (NATs) are used tday, which is the prblem this dcument is directly addressing. Instead, where a prefix is desired fr use n ne r mre dwnstream links in cperatin with the netwrk administratr, Prefix Delegatin [PD] shuld be used instead. Thaler, et al. Experimental [Page 16]

17 RFC 4389 ND Prxy April 2006 Authrs Addresses Dave Thaler Micrsft Crpratin One Micrsft Way Redmnd, WA Phne: Mhit Talwar Micrsft Crpratin One Micrsft Way Redmnd, WA Phne: Chirayu Patel All Play, N Wrk Bangalre, Karnataka Phne: chirayu@chirayu.rg Thaler, et al. Experimental [Page 17]

18 RFC 4389 ND Prxy April 2006 Full Cpyright Statement Cpyright (C) The Internet Sciety (2006). This dcument is subject t the rights, licenses and restrictins cntained in BCP 78, and except as set frth therein, the authrs retain all their rights. This dcument and the infrmatin cntained herein are prvided n an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Prperty The IETF takes n psitin regarding the validity r scpe f any Intellectual Prperty Rights r ther rights that might be claimed t pertain t the implementatin r use f the technlgy described in this dcument r the extent t which any license under such rights might r might nt be available; nr des it represent that it has made any independent effrt t identify any such rights. Infrmatin n the prcedures with respect t rights in RFC dcuments can be fund in BCP 78 and BCP 79. Cpies f IPR disclsures made t the IETF Secretariat and any assurances f licenses t be made available, r the result f an attempt made t btain a general license r permissin fr the use f such prprietary rights by implementers r users f this specificatin can be btained frm the IETF n-line IPR repsitry at The IETF invites any interested party t bring t its attentin any cpyrights, patents r patent applicatins, r ther prprietary rights that may cver technlgy that may be required t implement this standard. Please address the infrmatin t the IETF at ietf-ipr@ietf.rg. Acknwledgement Funding fr the RFC Editr functin is prvided by the IETF Administrative Supprt Activity (IASA). Thaler, et al. Experimental [Page 18]