draft-ietf-6man-dad-proxy-00.txt   draft-ietf-6man-dad-proxy-01.txt 
6man Working Group F. Costa 6man Working Group F. Costa
Internet-Draft J-M. Combes Internet-Draft J-M. Combes
Intended status: Standards Track X. Pougnard Intended status: Standards Track X. Pougnard
Expires: July 14, 2011 France Telecom Orange Expires: December 22, 2011 France Telecom Orange
H. Li H. Li
Huawei Technologies Huawei Technologies
January 10, 2011 June 20, 2011
Duplicate Address Detection Proxy Duplicate Address Detection Proxy
draft-ietf-6man-dad-proxy-00 draft-ietf-6man-dad-proxy-01
Abstract Abstract
The document describes a mechanism allowing the use of Duplicate The document describes a mechanism allowing the use of Duplicate
Address Detection (DAD) by IPv6 nodes in a point-to-multipoint Address Detection (DAD) by IPv6 nodes in a point-to-multipoint
architecture with "split-horizon" forwarding scheme. Based on the architecture with "split-horizon" forwarding scheme. Based on the
DAD signalling, the first hop router stores in a Binding Table all DAD signalling, the first hop router stores in a Binding Table all
known IPv6 addresses used on a point-to-multipoint domain (e.g. known IPv6 addresses used on a point-to-multipoint domain (e.g.
VLAN). When a node performs DAD for an address already used by VLAN). When a node performs DAD for an address already used by
another node, the first hop router replies instead of this last one. another node, the first hop router replies instead of this last one.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." 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 Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 7, line 49 skipping to change at page 7, line 49
IPv6 address is in the entry is still connected. In the following, 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- 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 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 the Link-layer address of the CPE which is performing DAD, which is
different from Link-layer-CPE1. different from Link-layer-CPE1.
The BNG MUST check if the potential address conflict is real. In The BNG MUST check if the potential address conflict is real. In
particular: particular:
o If IPv6-CPE1 is in the Neighbor Cache and it is associated with 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. as explained in Section 4.2.3.
o If IPv6-CPE1 is in the Neighbor Cache, but it is associated with 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 another Link-layer address than Link-layer-CPE1, that means that
there is possibly a conflict with another CPE, but that CPE did there is possibly a conflict with another CPE, but that CPE did
not perform DAD. This situation is out of the scope of this not perform DAD. This situation is out of the scope of this
document, since one assumption made above is that all the nodes of document, since one assumption made above is that all the nodes of
a point-to-multipoint domain (except the DAD proxy itself) perform a point-to-multipoint domain (except the DAD proxy itself) perform
DAD. This case could be covered in the future by additional DAD. This case could be covered in the future by additional
solutions that work in conjunction with the DAD proxy. solutions that work in conjunction with the DAD proxy.
skipping to change at page 10, line 29 skipping to change at page 10, line 29
(a) CPE1 generated a tentative address (a) CPE1 generated a tentative address
(b) CPE1 performs DAD for this one (b) CPE1 performs DAD for this one
(c) BNG updates its Binding Table (c) BNG updates its Binding Table
(d) CPE2 generates a same tentative address (d) CPE2 generates a same tentative address
(e) CPE2 performs DAD for this one (e) CPE2 performs DAD for this one
(f) BNG informs CPE2 that DAD fails (f) BNG informs CPE2 that DAD fails
Figure 2 Figure 2
The BNG and the CPE MUST support the Unicast Transmission on Link- The BNG and the CPE MUST support the Unicast Transmission on Link-
layer of IPv6 Multicast Messages [I-D.gundavelli-v6ops-l2-unicast], layer of IPv6 Multicast Messages [RFC6085], to be able, respectively,
to be able, respectively, to generate and to process such a packet to generate and to process such a packet format.
format.
5. IANA Considerations 5. IANA Considerations
No new options or messages are defined in this document. No new options or messages are defined in this document.
6. Security Considerations 6. Security Considerations
6.1. Interoperability with SEND 6.1. Interoperability with SEND
If SEcure Neighbor Discovery (SEND) [RFC3971] is used, the mechanism If SEcure Neighbor Discovery (SEND) [RFC3971] is used, the mechanism
skipping to change at page 11, line 20 skipping to change at page 11, line 20
[I-D.ietf-savi-send]. [I-D.ietf-savi-send].
7. Acknowledgments 7. Acknowledgments
TbD TbD
8. References 8. References
8.1. Normative 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 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
"Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
September 2007. September 2007.
[RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
Address Autoconfiguration", RFC 4862, September 2007. 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 8.2. Informative References
[I-D.ietf-6lowpan-nd] [I-D.ietf-6lowpan-nd]
Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
Discovery Optimization for Low-power and Lossy Networks", Discovery Optimization for Low Power and Lossy Networks
draft-ietf-6lowpan-nd-15 (work in progress), (6LoWPAN)", draft-ietf-6lowpan-nd-17 (work in progress),
September 2010. June 2011.
[I-D.ietf-csi-proxy-send] [I-D.ietf-csi-proxy-send]
Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-
Martinez, "Secure Proxy ND Support for SEND", Martinez, "Secure Proxy ND Support for SEND",
draft-ietf-csi-proxy-send-05 (work in progress), May 2010. draft-ietf-csi-proxy-send-05 (work in progress), May 2010.
[I-D.ietf-savi-fcfs] [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 SAVI: First-Come First-Serve Source-Address Validation for
Locally Assigned Addresses", draft-ietf-savi-fcfs-05 (work Locally Assigned IPv6 Addresses", draft-ietf-savi-fcfs-09
in progress), July 2010. (work in progress), April 2011.
[I-D.ietf-savi-send] [I-D.ietf-savi-send]
Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source-
Address Validation Implementation", 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 [RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", June 2004. in IPv6", June 2004.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005. Neighbor Discovery (SEND)", RFC 3971, March 2005.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
RFC 3972, March 2005. RFC 3972, March 2005.
 End of changes. 12 change blocks. 
21 lines changed or deleted 18 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/