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
AbstractThe 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.
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. 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
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). RFC2119]. 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.
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 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. 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.
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. 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. 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.
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. RFC4862], it is not completely reliable, and the goal of this document is not to fix DAD.
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. 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.
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.
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. Section 4.2.1. 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).
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.
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. 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).
[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. [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.
[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>.
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. | |
| 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