draft-ietf-6man-dad-proxy-01.txt   draft-ietf-6man-dad-proxy-02.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: December 22, 2011 France Telecom Orange Expires: September 9, 2012 France Telecom Orange
H. Li H. Li
Huawei Technologies Huawei Technologies
June 20, 2011 March 8, 2012
Duplicate Address Detection Proxy Duplicate Address Detection Proxy
draft-ietf-6man-dad-proxy-01 draft-ietf-6man-dad-proxy-02
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 December 22, 2011. This Internet-Draft will expire on September 9, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2012 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
skipping to change at page 2, line 23 skipping to change at page 2, line 23
1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3
2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Background . . . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Why existing IETF solutions are not sufficient? . . . . . . . 4 3. Why existing IETF solutions are not sufficient? . . . . . . . 4
3.1. Duplicate Address Detection . . . . . . . . . . . . . . . 5 3.1. Duplicate Address Detection . . . . . . . . . . . . . . . 5
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 . . . . . . . . . . . . . . . . . . . 6 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 . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1. Interoperability with SEND . . . . . . . . . . . . . . . . 10 6.1. Interoperability with SEND . . . . . . . . . . . . . . . . 10
6.2. IP source address spoofing protection . . . . . . . . . . 11 6.2. IP source address spoofing protection . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. Open issues . . . . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
This document explains why Duplicate Address Detection (DAD) This document explains why Duplicate Address Detection (DAD)
mechanism [RFC4862] cannot be used in a point-to-multipoint mechanism [RFC4862] cannot be used in a point-to-multipoint
architecture with "split-horizon" forwarding scheme. One of the main architecture with "split-horizon" forwarding scheme. One of the main
reasons is that, because of this forwarding scheme, IPv6 nodes on the reasons is that, because of this forwarding scheme, IPv6 nodes on the
same point-to-multipoint domain cannot have direct communication: any same point-to-multipoint domain cannot have direct communication: any
communication between them must go through the first hop router of communication between them must go through the first hop router of
skipping to change at page 6, line 11 skipping to change at page 6, line 11
registers that address with one or more of its default router using registers that address with one or more of its default router using
the Address Registration option (ARO). If this address is already the Address Registration option (ARO). If this address is already
owned by another node, the router informs the 6LoWPAN node this owned by another node, the router informs the 6LoWPAN node this
address cannot be configured. address cannot be configured.
A problem for this mechanism is that it requires modifications in A problem for this mechanism is that it requires modifications in
hosts in order to support the Address Registration option. hosts in order to support the Address Registration option.
3.4. IPv6 Mobility Manager 3.4. IPv6 Mobility Manager
According to [RFC3775], a home agent acts as a proxy for mobile nodes 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 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 defends an mobile node's home address by replying to NS messages with
NA messages. NA messages.
There is a problem for this mechanism if it is applied in a DSL or 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 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 [RFC3775] 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
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 must be done per point to IPv6 addresses generated by any CPE. This must be done per point to
skipping to change at page 6, line 42 skipping to change at page 6, line 42
Binding Table MUST contain the following fields: Binding Table MUST contain the following fields:
o IPv6 Address o IPv6 Address
o Link-layer Address o Link-layer Address
For security or performances reasons, it must be possible to limit For security or performances reasons, it must be possible to limit
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
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 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
source address, in order to check if a tentative address is already 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 in use on the link. The BNG receives this message and MUST perform
actions depending on the information in the Binding Table. actions depending on the 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 43 skipping to change at page 11, line 4
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
specified in this document may break the security. Indeed, if an specified in this document may break the security. Indeed, if an
entry already exists and the BNG has to send a reply (cf. entry already exists and the BNG has to send a reply (cf.
Section 4.2.2), the BNG doesn't own the private key(s) associated Section 4.2.2), the BNG doesn't own the private key(s) associated
with to the Cryptographically Generated Addresses (CGA) [RFC3972] to with to the Cryptographically Generated Addresses (CGA) [RFC3972] to
correctly sign the proxied ND messages [RFC5909]. correctly sign the proxied ND messages [RFC5909].
To keep the same level of security, Secure Proxy ND Support for SEND To keep the same level of security, Secure Proxy ND Support for SEND
[I-D.ietf-csi-proxy-send] SHOULD be used and implemented on the BNG [RFC6496] SHOULD be used and implemented on the BNG and the CPEs.
and the CPEs.
6.2. IP source address spoofing protection 6.2. IP source address spoofing protection
To ensure a protection against IP source address spoofing in data To ensure a protection against IP source address spoofing in data
packets, this proposal may be used in combinaison with Source Address packets, this proposal MAY be used in combinaison with Source Address
Validation Improvement (SAVI) mechanisms [I-D.ietf-savi-fcfs] Validation Improvement (SAVI) mechanisms [I-D.ietf-savi-fcfs]
[I-D.ietf-savi-send]. [I-D.ietf-savi-send] [I-D.ietf-savi-mix].
7. Acknowledgments 7. Acknowledgments
TbD The authors would like to thank Alan Kavanagh, Wojciech Dec and
Suresh Krishnan for their comments. The authors would like also to
thank the IETF 6man WG members and the BBF community for their
support.
8. References 8. References
8.1. Normative References 8.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,
skipping to change at page 11, line 39 skipping to change at page 11, line 49
[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 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
(6LoWPAN)", draft-ietf-6lowpan-nd-17 (work in progress), (6LoWPAN)", draft-ietf-6lowpan-nd-18 (work in progress),
June 2011. October 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] [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 IPv6 Addresses", draft-ietf-savi-fcfs-09 Locally Assigned IPv6 Addresses", draft-ietf-savi-fcfs-14
(work in progress), April 2011. (work in progress), February 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-01 (work in progress), October 2011.
[I-D.ietf-savi-send] [I-D.ietf-savi-send]
Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- Garcia-Martinez, A. and M. Bagnulo, "SEND-based Source-
Address Validation Implementation", Address Validation Implementation",
draft-ietf-savi-send-05 (work in progress), April 2011. draft-ietf-savi-send-06 (work in progress), October 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 [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", RFC 4389, April 2006. Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing [RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing
Neighbor Discovery Proxy: Problem Statement", RFC 5909, Neighbor Discovery Proxy: Problem Statement", RFC 5909,
July 2010. July 2010.
Appendix A. Open issues [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011.
o What happens when the BNG receives a NA message with O-bit set to [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-
1 (e.g. the Link-Layer address of the CPE has changed)? Martinez, "Secure Proxy ND Support for SEcure Neighbor
Discovery (SEND)", RFC 6496, February 2012.
Authors' Addresses Authors' Addresses
Fabio Costa Fabio Costa
France Telecom Orange France Telecom Orange
38 rue du General Leclerc 61 rue des Archives
92794 Issy-les-Moulineaux Cedex 9 75141 Paris Cedex 03
France France
Email: fabio.costa@orange-ftgroup.com Email: fabio.costa@orange.com
Jean-Michel Combes Jean-Michel Combes
France Telecom Orange France Telecom Orange
38 rue du General Leclerc 38 rue du General Leclerc
92794 Issy-les-Moulineaux Cedex 9 92794 Issy-les-Moulineaux Cedex 9
France France
Email: jeanmichel.combes@orange-ftgroup.com Email: jeanmichel.combes@orange.com
Xavier Pougnard Xavier Pougnard
France Telecom Orange France Telecom Orange
2 avenue Pierre Marzin 2 avenue Pierre Marzin
22300 Lannion 22300 Lannion
France France
Email: xavier.pougnard@orange-ftgroup.com Email: xavier.pougnard@orange.com
Hongyu Li Hongyu Li
Huawei Technologies Huawei Technologies
Huawei Industrial Base Huawei Industrial Base
Shenzhen Shenzhen
China China
Email: lihy@huawei.com Email: lihy@huawei.com
 End of changes. 26 change blocks. 
37 lines changed or deleted 45 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/