summaryrefslogtreecommitdiff
path: root/doc/rfc/rfc6957.txt
diff options
context:
space:
mode:
Diffstat (limited to 'doc/rfc/rfc6957.txt')
-rw-r--r--doc/rfc/rfc6957.txt899
1 files changed, 899 insertions, 0 deletions
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, <http://www.broadband-forum.org/technical/download/
+ TR-101_Issue-2.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+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]
+