draft-ietf-6man-dad-proxy-06.txt   draft-ietf-6man-dad-proxy-07.txt 
6man Working Group F. Costa 6man Working Group F. Costa
Internet-Draft J-M. Combes, Ed. Internet-Draft J-M. Combes, Ed.
Intended status: Standards Track X. Pougnard Intended status: Standards Track X. Pougnard
Expires: August 29, 2013 France Telecom Orange Expires: October 11, 2013 France Telecom Orange
H. Li H. Li
Huawei Technologies Huawei Technologies
February 25, 2013 April 9, 2013
Duplicate Address Detection Proxy Duplicate Address Detection Proxy
draft-ietf-6man-dad-proxy-06 draft-ietf-6man-dad-proxy-07
Abstract Abstract
The document describes a proxy based mechanism allowing the use of The document describes a proxy based mechanism allowing the use of
Duplicate Address Detection (DAD) by IPv6 nodes in a point-to- Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-
multipoint architecture with "split-horizon" forwarding scheme, multipoint architecture with "split-horizon" forwarding scheme,
primarily deployed for Digital Subscriber Line (DSL) and Fiber access primarily deployed for Digital Subscriber Line (DSL) and Fiber access
architectures. Based on the DAD signalling, the first hop router architectures. Based on the DAD signalling, the first hop router
stores in a Binding Table all known IPv6 addresses used on a point- 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 to-multipoint domain (e.g. VLAN). When a node performs DAD for an
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 August 29, 2013. This Internet-Draft will expire on October 11, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 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 2, line 29 skipping to change at page 2, line 29
3.2. Neighbor Discovery Proxy . . . . . . . . . . . . . . . . . 5 3.2. Neighbor Discovery Proxy . . . . . . . . . . . . . . . . . 5
3.3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . 5 3.3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . 5
3.4. IPv6 Mobility Manager . . . . . . . . . . . . . . . . . . 6 3.4. IPv6 Mobility Manager . . . . . . . . . . . . . . . . . . 6
4. Duplicate Address Detection Proxy (DAD-Proxy) 4. Duplicate Address Detection Proxy (DAD-Proxy)
specifications . . . . . . . . . . . . . . . . . . . . . . . . 6 specifications . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. DAD-Proxy Data structure . . . . . . . . . . . . . . . . . 6 4.1. DAD-Proxy Data structure . . . . . . . . . . . . . . . . . 6
4.2. DAD-Proxy mechanism . . . . . . . . . . . . . . . . . . . 7 4.2. DAD-Proxy mechanism . . . . . . . . . . . . . . . . . . . 7
4.2.1. No entry exists for the tentative address . . . . . . 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.2. An entry already exists for the tentative address . . 7
4.2.3. Confirmation of reachability to check the validity 4.2.3. Confirmation of reachability to check the validity
of the conflict . . . . . . . . . . . . . . . . . . . 8 of the conflict . . . . . . . . . . . . . . . . . . . 9
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. Manageability Considerations . . . . . . . . . . . . . . . . . 11
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11
6.1. Interoperability with SEND . . . . . . . . . . . . . . . . 10 7. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6.2. IP source address spoofing protection . . . . . . . . . . 11 7.1. Interoperability with SEND . . . . . . . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. IP source address spoofing protection . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 9.1. Normative References . . . . . . . . . . . . . . . . . . . 12
Appendix A. DAD Proxy state machine . . . . . . . . . . . . . . . 12 9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Appendix A. DAD Proxy state machine . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15
1. Introduction 1. Introduction
This document specifies a function called Duplicate Address Detection This document specifies a function called Duplicate Address Detection
(DAD) proxy allowing the use of DAD by the nodes on the same point- (DAD) proxy allowing the use of DAD by the nodes on the same point-
to-multipoint domain with "split-horizon" forwarding scheme, to-multipoint domain with "split-horizon" forwarding scheme,
primarily deployed for Digital Subscriber Line (DSL) and Fiber access primarily deployed for Digital Subscriber Line (DSL) and Fiber access
architectures. It only impacts the first hop router and it doesn't architectures. It only impacts the first hop router and it doesn't
need modifications on the other IPv6 nodes. This mechanism is fully need modifications on the other IPv6 nodes. This mechanism is fully
effective if all the nodes of a point-to-multipoint domain (except effective if all the nodes of a point-to-multipoint domain (except
skipping to change at page 6, line 28 skipping to change at page 6, line 28
Fiber public access network. Operators of such networks require a NA Fiber public access network. Operators of such networks require a NA
message is only received by the sender of the corresponding NS message is only received by the sender of the corresponding NS
message, for security and scalability reasons. However, the home message, for security and scalability reasons. However, the home
agent per [RFC6275] multicasts NA messages on the home link and all agent per [RFC6275] multicasts NA messages on the home link and all
nodes on this link will receive these NA messages. This shortcoming nodes on this link will receive these NA messages. This shortcoming
prevents this mechanism being deployed in DSL or Fiber access prevents this mechanism being deployed in DSL or Fiber access
networks directly. networks directly.
4. Duplicate Address Detection Proxy (DAD-Proxy) specifications 4. Duplicate Address Detection Proxy (DAD-Proxy) specifications
At 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 4.1. DAD-Proxy Data structure
A BNG needs to store in a Binding Table information related to the A BNG needs to store in a Binding Table information related to the
IPv6 addresses generated by any CPE. This Binding Table can be IPv6 addresses generated by any CPE. This Binding Table can be
distinct from the Neighbor Cache. This must be done per point to distinct from the Neighbor Cache. This must be done per point to
multipoint domain (e.g. per Ethernet VLAN). Each entry in this multipoint domain (e.g. per Ethernet VLAN). Each entry in this
Binding Table MUST contain the following fields: Binding Table MUST contain the following fields:
o IPv6 Address o IPv6 Address
skipping to change at page 7, line 5 skipping to change at page 7, line 8
the number of IPv6 Addresses per Link-layer Address (possibly, but the number of IPv6 Addresses per Link-layer Address (possibly, but
not necessarily, to 1). not necessarily, to 1).
On the reception of an unsolicited NA (e.g., when a CPE wishes to 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 inform its neighbors of a new link-layer address) for an IPv6 address
already recorded in the Binding Table, each entry associated to this already recorded in the Binding Table, each entry associated to this
IPv6 address MUST be updated consequently: the current Link-layer IPv6 address MUST be updated consequently: the current Link-layer
Address is replaced by the one included in the unsolicited NA Address is replaced by the one included in the unsolicited NA
message. 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 have at least the same
size as this last one. Implementations MUST either state the fixed
size of 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 enquire 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 4.2. DAD-Proxy mechanism
When a CPE performs DAD, as specified in [RFC4862], it sends a When a CPE performs DAD, as specified in [RFC4862], it sends a
Neighbor Solicitation (NS) message, with the unspecified address as Neighbor Solicitation (NS) message, with the unspecified address as
the source address, in order to check if a tentative address is 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 already in use on the link. The BNG receives this message and MUST
perform actions specified in the following sections based on the perform actions specified in the following sections based on the
information in the Binding Table. information in the Binding Table.
4.2.1. No entry exists for the tentative address 4.2.1. No entry exists for the tentative address
skipping to change at page 10, line 29 skipping to change at page 11, line 4
| | | | | |
| |<=========|(f) | |<=========|(f)
| | | | | |
(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 [RFC6085], to be able, respectively, layer of IPv6 Multicast Messages [RFC6085], to be able, respectively,
to generate and to process such a packet format. to generate and to process such a packet format.
5. IANA Considerations 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. 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 7. Security Considerations
6.1. Interoperability with SEND 7.1. Interoperability with SEND
The mechanism described in this document will not interoperate with The mechanism described in this document will not interoperate with
SEcure Neighbor Discovery (SEND) [RFC3971]. This is due to the BNG SEcure Neighbor Discovery (SEND) [RFC3971]. This is due to the BNG
not owning the private key associated with the Cryptographically not owning the private key associated with the Cryptographically
Generated Address (CGA) [RFC3972] needed to correctly sign the Generated Address (CGA) [RFC3972] needed to correctly sign the
proxied ND messages [RFC5909]. proxied ND messages [RFC5909].
Secure Proxy ND Support for SEND [RFC6496] has been specified to Secure Proxy ND Support for SEND [RFC6496] has been specified to
address this limitation, and SHOULD be implemented and used on the address this limitation, and SHOULD be implemented and used on the
BNG and the CPEs. BNG and the CPEs.
6.2. IP source address spoofing protection 7.2. IP source address spoofing protection
To ensure protection against IP source address spoofing in data To ensure protection against IP source address spoofing in data
packets, this proposal can be used in combinaison with Source Address packets, this proposal can be used in combinaison with Source Address
Validation Improvement (SAVI) mechanisms [RFC6620] Validation Improvement (SAVI) mechanisms [RFC6620]
[I-D.ietf-savi-send] [I-D.ietf-savi-mix]. [I-D.ietf-savi-send] [I-D.ietf-savi-mix].
If so, the SAVI device is the BNG and the Binding Anchor for a CPE is If so, 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. its MAC address, which is assumed to be unique in this document (cf.
Section 1). Section 1).
7. Acknowledgments 8. Acknowledgments
The authors would like to thank Alan Kavanagh, Wojciech Dec, Suresh The authors would like to thank Alan Kavanagh, Wojciech Dec, Suresh
Krishnan and Tassos Chatzithomaoglou for their comments. The authors Krishnan and Tassos Chatzithomaoglou for their comments. The authors
would like also to thank the IETF 6man WG members and the BBF would like also to thank the IETF 6man WG members and the BBF
community for their support. community for their support.
8. References 9. References
8.1. Normative References 9.1. Normative References
[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, [RFC6085] Gundavelli, S., Townsley, M., Troan, O., and W. Dec,
"Address Mapping of IPv6 Multicast Packets on Ethernet", "Address Mapping of IPv6 Multicast Packets on Ethernet",
RFC 6085, January 2011. RFC 6085, January 2011.
8.2. Informative References 9.2. Informative References
[I-D.ietf-savi-mix] [I-D.ietf-savi-mix]
Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI
for Mixed Address Assignment Methods Scenario", for Mixed Address Assignment Methods Scenario",
draft-ietf-savi-mix-03 (work in progress), November 2012. draft-ietf-savi-mix-03 (work in progress), November 2012.
[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-08 (work in progress), draft-ietf-savi-send-09 (work in progress), April 2013.
September 2012.
[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.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Proxies (ND Proxy)", RFC 4389, April 2006. Proxies (ND Proxy)", RFC 4389, April 2006.
 End of changes. 17 change blocks. 
26 lines changed or deleted 54 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/