--- 1/draft-ietf-6man-dad-proxy-04.txt 2012-09-19 14:14:01.553342170 +0200 +++ 2/draft-ietf-6man-dad-proxy-05.txt 2012-09-19 14:14:01.581343335 +0200 @@ -1,21 +1,21 @@ 6man Working Group F. Costa Internet-Draft J-M. Combes Intended status: Standards Track X. Pougnard -Expires: December 17, 2012 France Telecom Orange +Expires: March 23, 2013 France Telecom Orange H. Li Huawei Technologies - June 15, 2012 + September 19, 2012 Duplicate Address Detection Proxy - draft-ietf-6man-dad-proxy-04 + draft-ietf-6man-dad-proxy-05 Abstract The document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with "split-horizon" forwarding scheme. Based on the DAD signalling, 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 replies instead of this last one. @@ -28,21 +28,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - This Internet-Draft will expire on December 17, 2012. + This Internet-Draft will expire on March 23, 2013. Copyright Notice Copyright (c) 2012 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 @@ -51,82 +51,81 @@ 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 . . . . . . . . . . . . . . . 5 + 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. DAD-Proxy mechanism . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . 8 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6.1. Interoperability with SEND . . . . . . . . . . . . . . . . 10 6.2. IP source address spoofing protection . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11 - Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 + Appendix A. DAD Proxy state machine . . . . . . . . . . . . . . . 12 + Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 1. Introduction - This document explains why Duplicate Address Detection (DAD) - mechanism [RFC4862] cannot be used in a point-to-multipoint - architecture with "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. + 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 "split-horizon" forwarding scheme. 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 also specifies a function called DAD proxy allowing the - use of DAD by the nodes on the same point-to-multipoint domain with - "split-horizon" forwarding scheme. 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. - However, if it is necessary to cover the scenarios where this - assumption is not met, additional solutions could be defined in the - future that work in conjunction with the mechanism described here. + This document explains also why DAD mechanism [RFC4862] cannot be + used in a point-to-multipoint architecture with "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 "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) document [RFC4861] and IPv6 Stateless Address - Autoconfiguration document [RFC4862]. In addition, this section - defines additional terms related to DSL and Fiber access - architectures, which are an important case where the solution + IP version 6 (IPv6) [RFC4861] and IPv6 Stateless Address + Autoconfiguration [RFC4862]. In addition, this section defines + additional terms related to Digital Subscriber Line (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 a L2 bridge in this document. Broadband Network Gateway (BNG) @@ -169,74 +168,75 @@ 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 a same link with all CPE, but one CPE is not on a same link with any other CPE. 3.1. Duplicate Address Detection Duplicate Address Dectection (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 solicited-node multicast address of the tentative - address. This NS message is multicasted to other nodes on a 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 are received by other nodes. + 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 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 - would be forwarded by AN only to the BNG but not to any other CPE. - That said, 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 per [RFC4862] can't work properly - without an additional helper. + 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 an 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. A 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 AN, acting as a ND Proxy, receives a - ND message from a CPE, it will forward it to the BNG but none of + In DSL or Fiber networks, when the AN, acting as a ND Proxy, receives + a ND message from a CPE, it will forward it to the BNG but none of other CPEs, as only the BNG is on the same link with the CPE. Hence, - implementing ND Proxy on AN would not help a CPE acknowledge link- - local addresses used by other CPEs. + 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 [I-D.ietf-6lowpan-nd] defines an optional modification of DAD for a 6LowPAN. When a 6LoWPAN node wants to configure an IPv6 address, it - registers that address with one or more of its default router using + 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 this address cannot be configured. - A problem for this mechanism is that it requires modifications in - hosts in order to support the Address Registration option. + This mechanism requires modifications in all hosts in order to + support the Address Registration option. 3.4. IPv6 Mobility Manager According to [RFC6275], a home agent acts as a proxy for mobile nodes - when these last ones are away from the home network: the home agent - defends an mobile node's home address by replying to NS messages with - NA messages. + when they are away from the home network: the home agent defends an + 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 a 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 being deployed in DSL or Fiber access networks directly. @@ -262,28 +262,28 @@ 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. 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 - 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 depending on the information in the Binding Table. + 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 depending 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 following information: + 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 @@ -319,22 +319,21 @@ 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 another Link-layer address 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. This case could be covered in the future by - additional solutions that work in conjunction with 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 reachibility 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 considering the case as if a packet other than a solicited Neighbor Advertisement was received from IPv6-CPE1. That means that the new entry of the Neighbor Cache MUST contain the following information: @@ -489,32 +487,33 @@ [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 [I-D.ietf-6lowpan-nd] Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor Discovery Optimization for Low Power and Lossy Networks - (6LoWPAN)", draft-ietf-6lowpan-nd-18 (work in progress), - October 2011. + (6LoWPAN)", draft-ietf-6lowpan-nd-21 (work in progress), + August 2012. [I-D.ietf-savi-mix] Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI for Mixed Address Assignment Methods Scenario", draft-ietf-savi-mix-02 (work in progress), April 2012. [I-D.ietf-savi-send] Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- Address Validation Implementation", - draft-ietf-savi-send-07 (work in progress), March 2012. + draft-ietf-savi-send-08 (work in progress), + September 2012. [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. @@ -530,20 +529,78 @@ [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. +Appendix A. DAD Proxy state machine + + This appendix 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 | o 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. | | + | | o Entry for | - | Existing | + | | IPv6-CPE1 in the | | entry | + | | Binding Table. | | | + | Existing | o Link-layer-CPE2 | - | - | + | entry | bound to IPv6-CPE1 | | | + | | in the Binding | | | + | | Table. | | | + | | o Another | - | Conflict? | + | | Link-layer address, | | | + | | Link-layer-CPE1, | | | + | | bound to IPv6-CPE1 | | | + | | in the Binding | | | + | | Table. | | | + | Conflict? | o IPv6-CPE1 | - | Reachable? | + | | associated to | | | + | | Link-layer-CPE1 in | | | + | | the Neighbor Cache. | | | + | | o IPv6-CPE1 | Out of scope. | - | + | | associated to | | | + | | another Link-layer | | | + | | address than | | | + | | Link-layer-CPE1 in | | | + | | the Neighbor Cache. | | | + | | o 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? | o NUD process is | IPv6-CPE2 is | - | + | | negative. | bound to | | + | | | Link-layer-CPE2, | | + | | | instead to | | + | | | Link-layer-CPE1, | | + | | | in the Binding | | + | | | Table. | | + | | o NUD process is | A NA message is | - | + | | positive. | sent. | | + +------------+---------------------+-------------------+------------+ + Table 1 + Authors' Addresses Fabio Costa France Telecom Orange 61 rue des Archives 75141 Paris Cedex 03 France Email: fabio.costa@orange.com