--- 1/draft-ietf-6man-dad-proxy-00.txt 2011-06-20 16:15:43.000000000 +0200 +++ 2/draft-ietf-6man-dad-proxy-01.txt 2011-06-20 16:15:43.000000000 +0200 @@ -1,21 +1,21 @@ 6man Working Group F. Costa Internet-Draft J-M. Combes Intended status: Standards Track X. Pougnard -Expires: July 14, 2011 France Telecom Orange +Expires: December 22, 2011 France Telecom Orange H. Li Huawei Technologies - January 10, 2011 + June 20, 2011 Duplicate Address Detection Proxy - draft-ietf-6man-dad-proxy-00 + draft-ietf-6man-dad-proxy-01 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 July 14, 2011. + This Internet-Draft will expire on December 22, 2011. Copyright Notice Copyright (c) 2011 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 @@ -303,21 +303,21 @@ IPv6 address is in the entry is still connected. In the following, we will call IPv6-CPE1 the IPv6 address of the existing entry, Link- layer-CPE1 the Link-layer address of that entry and Link-layer-CPE2 the Link-layer address of the CPE which 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-local-CPE1, the reachibility of IPv6-CPE1 MUST be confirmed + 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 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. @@ -423,23 +423,22 @@ (a) CPE1 generated 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 The BNG and the CPE MUST support the Unicast Transmission on Link- - layer of IPv6 Multicast Messages [I-D.gundavelli-v6ops-l2-unicast], - to be able, respectively, to generate and to process such a packet - format. + layer of IPv6 Multicast Messages [RFC6085], to be able, respectively, + to generate and to process such a packet format. 5. IANA Considerations No new options or messages are defined in this document. 6. Security Considerations 6.1. Interoperability with SEND If SEcure Neighbor Discovery (SEND) [RFC3971] is used, the mechanism @@ -461,59 +460,57 @@ [I-D.ietf-savi-send]. 7. Acknowledgments TbD 8. References 8.1. Normative References - [I-D.gundavelli-v6ops-l2-unicast] - Gundavelli, S., Townsley, M., Troan, O., and W. Dec, - "Unicast Transmission of IPv6 Multicast Messages on Link- - layer", draft-gundavelli-v6ops-l2-unicast-06 (work in - progress), August 2010. - [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 [I-D.ietf-6lowpan-nd] Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor - Discovery Optimization for Low-power and Lossy Networks", - draft-ietf-6lowpan-nd-15 (work in progress), - September 2010. + Discovery Optimization for Low Power and Lossy Networks + (6LoWPAN)", draft-ietf-6lowpan-nd-17 (work in progress), + June 2011. [I-D.ietf-csi-proxy-send] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- Martinez, "Secure Proxy ND Support for SEND", draft-ietf-csi-proxy-send-05 (work in progress), May 2010. [I-D.ietf-savi-fcfs] - Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS- + Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS SAVI: First-Come First-Serve Source-Address Validation for - Locally Assigned Addresses", draft-ietf-savi-fcfs-05 (work - in progress), July 2010. + Locally Assigned IPv6 Addresses", draft-ietf-savi-fcfs-09 + (work in progress), April 2011. [I-D.ietf-savi-send] Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- Address Validation Implementation", - draft-ietf-savi-send-04 (work in progress), May 2010. + draft-ietf-savi-send-05 (work in progress), April 2011. [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in IPv6", June 2004. [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.