From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc6957.txt | 899 ++++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 899 insertions(+) create mode 100644 doc/rfc/rfc6957.txt (limited to 'doc/rfc/rfc6957.txt') diff --git a/doc/rfc/rfc6957.txt b/doc/rfc/rfc6957.txt new file mode 100644 index 0000000..26ead10 --- /dev/null +++ b/doc/rfc/rfc6957.txt @@ -0,0 +1,899 @@ + + + + + + +Internet Engineering Task Force (IETF) F. Costa +Request for Comments: 6957 J-M. Combes, Ed. +Category: Standards Track X. Pougnard +ISSN: 2070-1721 France Telecom Orange + H. Li + Huawei Technologies + June 2013 + + + Duplicate Address Detection Proxy + +Abstract + + The document describes a proxy-based mechanism allowing the use of + Duplicate Address Detection (DAD) by IPv6 nodes in a point-to- + multipoint architecture with a "split-horizon" forwarding scheme, + primarily deployed for Digital Subscriber Line (DSL) and Fiber access + architectures. Based on the DAD signaling, the first-hop router + stores in a Binding Table all known IPv6 addresses used on a point- + to-multipoint domain (e.g., VLAN). When a node performs DAD for an + address already used by another node, the first-hop router defends + the address rather than the device using the address. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 5741. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc6957. + + + + + + + + + + + + + + + +Costa, et al. Standards Track [Page 1] + +RFC 6957 DAD-Proxy June 2013 + + +Copyright Notice + + Copyright (c) 2013 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + +Table of Contents + + 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 + 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 + 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . 3 + 3. Why Existing IETF Solutions Are Not Sufficient . . . . . . . 4 + 3.1. Duplicate Address Detection . . . . . . . . . . . . . . . 4 + 3.2. Neighbor Discovery Proxy . . . . . . . . . . . . . . . . 5 + 3.3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . 5 + 3.4. IPv6 Mobility Manager . . . . . . . . . . . . . . . . . . 6 + 4. Duplicate Address Detection Proxy (DAD-Proxy) Specifications 6 + 4.1. DAD-Proxy Data Structure . . . . . . . . . . . . . . . . 6 + 4.2. DAD-Proxy Mechanism . . . . . . . . . . . . . . . . . . . 7 + 4.2.1. No Entry Exists for the Tentative Address . . . . . . 7 + 4.2.2. An Entry Already Exists for the Tentative Address . . 7 + 4.2.3. Confirmation of Reachability to Check the Validity of + the Conflict . . . . . . . . . . . . . . . . . . . . 9 + 5. Manageability Considerations . . . . . . . . . . . . . . . . 11 + 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 + 6.1. Interoperability with SEND . . . . . . . . . . . . . . . 11 + 6.2. Protection against IP Source Address Spoofing . . . . . . 11 + 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 + 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12 + 8.1. Normative References . . . . . . . . . . . . . . . . . . 12 + 8.2. Informative References . . . . . . . . . . . . . . . . . 12 + Appendix A. DAD-Proxy State Machine . . . . . . . . . . . . . . 14 + + + + + + + + + + +Costa, et al. Standards Track [Page 2] + +RFC 6957 DAD-Proxy June 2013 + + +1. Introduction + + This document specifies a function called Duplicate Address Detection + (DAD) proxy allowing the use of DAD by the nodes on the same point- + to-multipoint domain with a "split-horizon" forwarding scheme, + primarily deployed for Digital Subscriber Line (DSL) and Fiber access + architectures [TR-101]. It only impacts the first-hop router and it + doesn't need modifications on the other IPv6 nodes. This mechanism + is fully effective if all the nodes of a point-to-multipoint domain + (except the DAD proxy itself) perform DAD. + + This document explains also why the DAD mechanism [RFC4862] without a + proxy cannot be used in a point-to-multipoint architecture with a + "split-horizon" forwarding scheme (IPv6 over PPP [RFC5072] is not + affected). One of the main reasons is that, because of this + forwarding scheme, IPv6 nodes on the same point-to-multipoint domain + cannot have direct communication: any communication between them must + go through the first-hop router of the same domain. + + It is assumed in this document that link-layer addresses on a point- + to-multipoint domain are unique from the first-hop router's point of + view (e.g., in an untrusted Ethernet architecture, this assumption + can be guaranteed thanks to mechanisms such as Media Access Control + (MAC) address translation performed by an aggregation device between + IPv6 nodes and the first-hop router). + +1.1. Requirements Language + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in RFC 2119 [RFC2119]. + +2. Background + + Terminology in this document follows that in "Neighbor Discovery for + IP version 6 (IPv6)" [RFC4861] and "IPv6 Stateless Address + Autoconfiguration" [RFC4862]. In addition, this section defines + additional terms related to DSL and Fiber access architectures, which + are an important case where the solution described in this document + can be used: + + Customer Premises Equipment (CPE) + The first IPv6 node in a customer's network. + + Access Node (AN) + The first aggregation point in the public access network. It + is considered as an L2 bridge in this document. + + + + +Costa, et al. Standards Track [Page 3] + +RFC 6957 DAD-Proxy June 2013 + + + Broadband Network Gateway (BNG) + The first-hop router from the CPE's point of view. + + VLAN N:1 architecture + A point-to-multipoint architecture where many CPEs are + connected to the same VLAN. The CPEs may be connected on the + same or different Access Nodes. + + split-horizon model + A forwarding scheme where CPEs cannot have direct layer 2 + communications between them (i.e., IP flows must be forwarded + through the BNG via routing). + + The following figure shows where the different entities are, as + defined above. + + +------+ +----+ + | CPE3 |---------| AN | + +------+ +----+ + | + | + +------+ +----+ + | CPE2 |---------| AN |---+ + +------+ +----+ | + +------+ | | + | CPE1 |------------+ | + +------+ +-----+ + | BNG |--- Internet + +-----+ + + Figure 1: DSL and Fiber Access Architecture + +3. Why Existing IETF Solutions Are Not Sufficient + + In a DSL or Fiber access architecture depicted in Figure 1, CPE1, + CPE2, CPE3, and the BNG are IPv6 nodes, while AN is an L2 bridge + providing connectivity between the BNG and each CPE. The AN enforces + a split-horizon model so that CPEs can only send and receive frames + (e.g., Ethernet frames) to and from the BNG but not to each other. + That said, the BNG is on the same link with all CPEs, but a given CPE + is not on the same link with any other CPE. + +3.1. Duplicate Address Detection + + Duplicate Address Detection (DAD) [RFC4862] is performed when an IPv6 + node verifies the uniqueness of a tentative IPv6 address. This node + sends a Neighbor Solicitation (NS) message with the IP destination + set to the solicited-node multicast address of the tentative address. + + + +Costa, et al. Standards Track [Page 4] + +RFC 6957 DAD-Proxy June 2013 + + + This NS message is multicasted to other nodes on the same link. When + the tentative address is already used on the link by another node, + this last one replies with a Neighbor Advertisement (NA) message to + inform the first node. So, when performing DAD, a node expects the + NS messages to be received by any node currently using the tentative + address. + + However, in a point-to-multipoint network with a split-horizon + forwarding scheme implemented in the AN, the CPEs are prevented from + talking to each other directly. All packets sent out from a CPE are + forwarded by the AN only to the BNG but not to any other CPE. NS + messages sent by a certain CPE will be received only by the BNG and + will not reach other CPEs. So, other CPEs have no idea that a + certain IPv6 address is used by another CPE. That means, in a + network with split-horizon, DAD, as defined in [RFC4862], can't work + properly without additional help. + +3.2. Neighbor Discovery Proxy + + Neighbor Discovery (ND) Proxy [RFC4389] is designed for forwarding ND + messages between different IP links where the subnet prefix is the + same. An ND Proxy function on a bridge ensures that packets between + nodes on different segments can be received by this function and have + the correct link-layer address type on each segment. When the ND + Proxy receives a multicast ND message, it forwards it to all other + interfaces on a same link. + + In DSL or Fiber networks, when the AN, acting as an ND Proxy, + receives an ND message from a CPE, it will forward it to the BNG but + none of the other CPEs, as only the BNG is on the same link with the + CPE. Hence, implementing ND Proxy on the AN would not help a CPE + acknowledge link-local addresses used by other CPEs. + + As the BNG must not forward link-local scoped messages sent from a + CPE to other CPEs, ND Proxy cannot be implemented in the BNG. + +3.3. 6LoWPAN Neighbor Discovery + + [RFC6775] defines an optional modification of DAD for IPv6 over Low- + Power Wireless Personal Area Networks (6LoWPAN). When a 6LoWPAN node + wants to configure an IPv6 address, it registers that address with + one or more of its default routers using the Address Registration + Option (ARO). If this address is already owned by another node, the + router informs the 6LoWPAN node that this address cannot be + configured. + + This mechanism requires modifications in all hosts in order to + support the ARO. + + + +Costa, et al. Standards Track [Page 5] + +RFC 6957 DAD-Proxy June 2013 + + +3.4. IPv6 Mobility Manager + + According to [RFC6275], a home agent acts as a proxy for mobile nodes + when they are away from the home network: the home agent defends a + mobile node's home address by replying to NS messages with NA + messages. + + There is a problem for this mechanism if it is applied in a DSL or + Fiber public access network. Operators of such networks require that + an NA message is only received by the sender of the corresponding NS + message, for security and scalability reasons. However, the home + agent per [RFC6275] multicasts NA messages on the home link and all + nodes on this link will receive these NA messages. This shortcoming + prevents this mechanism from being deployed in DSL or Fiber access + networks directly. + +4. Duplicate Address Detection Proxy (DAD-Proxy) Specifications + + First, it is important to note that, as this mechanism is strongly + based on DAD [RFC4862], it is not completely reliable, and the goal + of this document is not to fix DAD. + +4.1. DAD-Proxy Data Structure + + A BNG needs to store in a Binding Table information related to the + IPv6 addresses generated by any CPE. This Binding Table can be + distinct from the Neighbor Cache. This must be done per point-to- + multipoint domain (e.g., per Ethernet VLAN). Each entry in this + Binding Table MUST contain the following fields: + + o IPv6 Address + + o Link-layer Address + + For security or performances reasons, it must be possible to limit + the number of IPv6 addresses per link-layer address (possibly, but + not necessarily, to 1). + + On the reception of an unsolicited NA (e.g., when a CPE wishes to + inform its neighbors of a new link-layer address) for an IPv6 address + already recorded in the Binding Table, each entry associated to this + IPv6 address MUST be updated consequently: the current link-layer + address is replaced by the one included in the unsolicited NA + message. + + For security or performances reasons, the Binding Table MUST be large + enough for the deployment in which it is used: if the Binding Table + is distinct from the Neighbor Cache, it MUST be at least the same + + + +Costa, et al. Standards Track [Page 6] + +RFC 6957 DAD-Proxy June 2013 + + + size as this last one. Implementations MUST either state the fixed + size of the Binding Table that they support or make the size + configurable. In the latter case, implementations MUST state the + largest Binding Table size that they support. Additionally, + implementations SHOULD allow an operator to inquire about the current + occupancy level of the Binding Table to determine if it is about to + become full. Implementations encountering a full Binding Table will + likely handle it in a way similar to NS message loss. + + It is recommended to apply technical solutions to minimize the risk + that the Binding Table becomes full. These solutions are out of the + scope of this document. + +4.2. DAD-Proxy Mechanism + + When a CPE performs DAD, as specified in [RFC4862], it sends a + Neighbor Solicitation (NS) message, with the unspecified address as + the source address, in order to check if a tentative address is + already in use on the link. The BNG receives this message and MUST + perform actions specified in the following sections based on the + information in the Binding Table. + +4.2.1. No Entry Exists for the Tentative Address + + When there is no entry for the tentative address, the BNG MUST create + one with the following information: + + o IPv6 Address field set to the tentative address in the NS message. + + o Link-layer Address field set to the link-layer source address in + the link-layer header of the NS message. + + The BNG MUST NOT reply to the CPE or forward the NS message. + +4.2.2. An Entry Already Exists for the Tentative Address + + When there is an entry for the tentative address, the BNG MUST check + the following conditions: + + o The address in the Target Address field in the NS message is equal + to the address in the IPv6 Address field in the entry. + + o The source address of the IPv6 Header in the NS message is equal + to the unspecified address. + + When these conditions are met and the source address of the link- + layer header in the NS message is equal to the address in the Link- + layer Address field in the entry, that means the CPE is still + + + +Costa, et al. Standards Track [Page 7] + +RFC 6957 DAD-Proxy June 2013 + + + performing DAD for this address. The BNG MUST NOT reply to the CPE + or forward the NS message. + + When these conditions are met and the source address of the link- + layer header in the NS message is not equal to the address in the + Link-layer Address field in the entry, that means possibly another + CPE is performing DAD for an already owned address. The BNG then has + to verify whether there is a real conflict by checking if the CPE + whose IPv6 address is in the entry is still connected. In the + following text, we will call IPv6-CPE1 the IPv6 address of the + existing entry in the Binding Table, Link-layer-CPE1 the link-layer + address of that entry, and Link-layer-CPE2 the link-layer address of + the CPE that is performing DAD, which is different from Link-layer- + CPE1. + + The BNG MUST check if the potential address conflict is real. In + particular: + + o If IPv6-CPE1 is in the Neighbor Cache and it is associated with + Link-layer-CPE1, the reachability of IPv6-CPE1 MUST be confirmed + as explained in Section 4.2.3. + + o If IPv6-CPE1 is in the Neighbor Cache, but in this cache it is + associated with a link-layer address other than Link-layer-CPE1, + that means that there is possibly a conflict with another CPE, but + that CPE did not perform DAD. This situation is out of the scope + of this document, since one assumption made above is that all the + nodes of a point-to-multipoint domain (except the DAD proxy + itself) perform DAD. + + o If IPv6-CPE1 is not in the Neighbor Cache, then the BNG MUST + create a new entry based on the information of the entry in the + Binding Table. This step is necessary in order to trigger the + reachability check as explained in Section 4.2.3. The entry in + the Neighbor Cache MUST be created based on the algorithm defined + in Section 7.3.3 of [RFC4861], in particular by treating this case + as though a packet other than a solicited Neighbor Advertisement + were received from IPv6-CPE1. Thus, the new entry of the Neighbor + Cache MUST contain the following information: + + * IPv6 address: IPv6-CPE1 + + * Link-layer address: Link-layer-CPE1 + + * State: STALE + + The reachability of IPv6-CPE1 MUST be confirmed as soon as + possible following the procedure explained in Section 4.2.3. + + + +Costa, et al. Standards Track [Page 8] + +RFC 6957 DAD-Proxy June 2013 + + +4.2.3. Confirmation of Reachability to Check the Validity of the + Conflict + + Given that the IPv6-CPE1 is in an entry of the Neighbor Cache, the + reachability of IPv6-CPE1 is checked by using the Neighbor + Unreachability Detection (NUD) mechanism described in Section 7.3.1 + of [RFC4861]. This mechanism MUST be triggered as though a packet + had to be sent to IPv6-CPE1. Note that in some cases this mechanism + does not do anything. For instance, if the state of the entry is + REACHABLE and a positive confirmation was received recently that the + forward path to the IPv6-CPE1 was functioning properly (see RFC 4861 + for more details), this mechanism does not do anything. + + Next, the behavior of the BNG depends on the result of the NUD + process, as explained in the following sections. + +4.2.3.1. The Result of the NUD Process is Negative + + If the result of the NUD process is negative (i.e., if this process + removes IPv6-CPE1 from the Neighbor Cache), that means that the + potential conflict is not real. + + The conflicting entry in the Binding Table (Link-layer-CPE1) is + deleted and it is replaced by a new entry with the same IPv6 address, + but the link-layer address of the CPE is performing DAD (Link-layer- + CPE2), as explained in Section 4.2.1. + +4.2.3.2. The Result of the NUD Process is Positive + + If the result of the NUD process is positive (i.e., if after this + process the state of IPv6-CPE1 is REACHABLE), that means that the + potential conflict is real. + + As shown in Figure 2, the BNG MUST reply to the CPE that is + performing DAD (CPE2 in Figure 1) with an NA message that has the + following format: + + Layer 2 Header Fields: + + Source Address + The link-layer address of the interface on which the BNG + received the NS message. + + Destination Address + The source address in the Layer 2 Header of the NS + message received by the BNG (i.e., Link-layer-CPE2). + + + + + +Costa, et al. Standards Track [Page 9] + +RFC 6957 DAD-Proxy June 2013 + + + IPv6 Header Fields: + + Source Address + An address assigned to the interface from which the + advertisement is sent. + + Destination Address + The all-nodes multicast address. + + ICMPv6 Fields: + + Target Address + The tentative address already used (i.e., IPv6-CPE1). + + Target Link-layer Address + The link-layer address of the interface on which the BNG + received the NS message. + + CPE1 CPE2 BNG + | | | + (a)| | | + | | | + (b)|===================>| + | | |(c) + | | | + | (d)| | + | | | + | (e)|=========>| + | | | + | |<=========|(f) + | | | + + (a) CPE1 generates a tentative address + (b) CPE1 performs DAD for this one + (c) BNG updates its Binding Table + (d) CPE2 generates a same tentative address + (e) CPE2 performs DAD for this one + (f) BNG informs CPE2 that DAD fails + + Figure 2: DAD Failure + + The BNG and the CPE MUST support the unicast transmission on the link + layer of IPv6 multicast messages [RFC6085], to be able, respectively, + to generate and to process such a packet format. + + + + + + + +Costa, et al. Standards Track [Page 10] + +RFC 6957 DAD-Proxy June 2013 + + +5. Manageability Considerations + + The BNG SHOULD support a mechanism to log and emit alarms whenever a + duplication of IPv6 addresses is detected by the DAD-Proxy function. + Moreover, the BNG SHOULD implement a function to allow an operator to + access logs and to see the current entries in the Binding Table. The + management of access rights to get this information is out of the + scope of this document. + +6. Security Considerations + +6.1. Interoperability with SEND + + The mechanism described in this document will not interoperate with + SEcure Neighbor Discovery (SEND) [RFC3971]. This is due to the BNG + not owning the private key associated with the Cryptographically + Generated Address (CGA) [RFC3972] needed to correctly sign the + proxied ND messages [RFC5909]. + + Secure Proxy ND Support for SEND [RFC6496] has been specified to + address this limitation, and it SHOULD be implemented and used on the + BNG and the CPEs. + +6.2. Protection against IP Source Address Spoofing + + To ensure protection against IP source address spoofing in data + packets, this proposal can be used in combination with Source Address + Validation Improvement (SAVI) mechanisms [RFC6620] [SAVI-SEND] + [SAVI-MIX]. + + If SAVI mechanisms are used, the SAVI device is the BNG, and the + Binding Anchor for a CPE is its MAC address, which is assumed to be + unique in this document (cf. Section 1). + +7. Acknowledgments + + The authors would like to thank Alan Kavanagh, Wojciech Dec, Suresh + Krishnan, and Tassos Chatzithomaoglou for their comments. The + authors would like also to thank the IETF 6man WG members and the BBF + community for their support. + + + + + + + + + + + +Costa, et al. Standards Track [Page 11] + +RFC 6957 DAD-Proxy June 2013 + + +8. References + +8.1. Normative References + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, March 1997. + + [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, + "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, + September 2007. + + [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless + Address Autoconfiguration", RFC 4862, September 2007. + + [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec, + "Address Mapping of IPv6 Multicast Packets on Ethernet", + RFC 6085, January 2011. + +8.2. Informative References + + [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure + Neighbor Discovery (SEND)", RFC 3971, March 2005. + + [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", + RFC 3972, March 2005. + + [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery + Proxies (ND Proxy)", RFC 4389, April 2006. + + [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6 + over PPP", RFC 5072, September 2007. + + [RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing + Neighbor Discovery Proxy: Problem Statement", RFC 5909, + July 2010. + + [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support + in IPv6", RFC 6275, July 2011. + + [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- + Martinez, "Secure Proxy ND Support for SEcure Neighbor + Discovery (SEND)", RFC 6496, February 2012. + + [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS + SAVI: First-Come, First-Served Source Address Validation + Improvement for Locally Assigned IPv6 Addresses", RFC + 6620, May 2012. + + + + +Costa, et al. Standards Track [Page 12] + +RFC 6957 DAD-Proxy June 2013 + + + [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. + Bormann, "Neighbor Discovery Optimization for IPv6 over + Low-Power Wireless Personal Area Networks (6LoWPANs)", + RFC 6775, November 2012. + + [SAVI-MIX] Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, Ed., + "SAVI for Mixed Address Assignment Methods Scenario", + Work in Progress, May 2013. + + [SAVI-SEND] Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- + Address Validation Implementation", Work in Progress, + April 2013. + + [TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL + Aggregation", Issue 2, Technical Report TR-101, July + 2011, . + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Costa, et al. Standards Track [Page 13] + +RFC 6957 DAD-Proxy June 2013 + + +Appendix A. DAD-Proxy State Machine + + This appendix, which is informative, contains a summary (cf. Table 1) + of the actions done by the BNG when it receives a DAD-based NS + (DAD-NS) message. The tentative address in this message is IPv6-CPE1 + and the associated link-layer address is Link-layer-CPE2. The + actions are precisely specified in Section 4.2. + + +------------+--------------------+--------------------+------------+ + | Event | Check | Action | New event | + +------------+--------------------+--------------------+------------+ + | DAD-NS | * No entry for | Create an entry | - | + | message | IPv6-CPE1 in the | for IPv6-CPE1 | | + | reception. | Binding Table. | bound to Link- | | + | | | layer-CPE2 in the | | + | | | Binding Table. | | + | | * Entry for | - | Existing | + | | IPv6-CPE1 in the | | entry. | + | | Binding Table. | | | + | | | | | + | Existing | * Link-layer-CPE2 | - | - | + | entry. | bound to IPv6-CPE1 | | | + | | in the Binding | | | + | | Table. | | | + | | * Another link- | - | Conflict? | + | | layer address, | | | + | | Link-layer-CPE1, | | | + | | bound to IPv6-CPE1 | | | + | | in the Binding | | | + | | Table. | | | + | | | | | + | Conflict? | * IPv6-CPE1 | - | Reachable? | + | | associated to | | | + | | Link-layer-CPE1 in | | | + | | the Neighbor | | | + | | Cache. | | | + | | * IPv6-CPE1 | Out of scope. | - | + | | associated to | | | + | | another link-layer | | | + | | address than Link- | | | + | | layer-CPE1 in the | | | + | | Neighbor Cache. | | | + | | * IPv6-CPE1 is not | Create an entry | Reachable? | + | | in the Neighbor | for IPv6-CPE1 | | + | | Cache. | associated to | | + | | | Link-layer-CPE1 in | | + | | | the Neighbor | | + | | | Cache. | | + + + +Costa, et al. Standards Track [Page 14] + +RFC 6957 DAD-Proxy June 2013 + + + | Reachable? | * NUD process is | IPv6-CPE2 is bound | - | + | | negative. | to Link-layer- | | + | | | CPE2, instead to | | + | | | Link-layer-CPE1, | | + | | | in the Binding | | + | | | Table. | | + | | * NUD process is | A NA message is | - | + | | positive. | sent. | | + +------------+--------------------+--------------------+------------+ + + Table 1: DAD-Proxy State Machine + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Costa, et al. Standards Track [Page 15] + +RFC 6957 DAD-Proxy June 2013 + + +Authors' Addresses + + Fabio Costa + France Telecom Orange + 61 rue des Archives + 75141 Paris Cedex 03 + France + + EMail: fabio.costa@orange.com + + + Jean-Michel Combes (editor) + France Telecom Orange + 38 rue du General Leclerc + 92794 Issy-les-Moulineaux Cedex 9 + France + + EMail: jeanmichel.combes@orange.com + + + Xavier Pougnard + France Telecom Orange + 2 avenue Pierre Marzin + 22300 Lannion + France + + EMail: xavier.pougnard@orange.com + + + Hongyu Li + Huawei Technologies + Huawei Industrial Base + Shenzhen + China + + EMail: lihy@huawei.com + + + + + + + + + + + + + + + +Costa, et al. Standards Track [Page 16] + -- cgit v1.2.3