draft-ietf-6man-dad-proxy-02.txt   draft-ietf-6man-dad-proxy-03.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: September 9, 2012 France Telecom Orange Expires: December 14, 2012 France Telecom Orange
H. Li H. Li
Huawei Technologies Huawei Technologies
March 8, 2012 June 12, 2012
Duplicate Address Detection Proxy Duplicate Address Detection Proxy
draft-ietf-6man-dad-proxy-02 draft-ietf-6man-dad-proxy-03
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 September 9, 2012. This Internet-Draft will expire on December 14, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2012 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
skipping to change at page 3, line 9 skipping to change at page 3, line 9
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
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 (IPv6 over PPP
reasons is that, because of this forwarding scheme, IPv6 nodes on the [RFC5072] is not affected). One of the main reasons is that, because
same point-to-multipoint domain cannot have direct communication: any of this forwarding scheme, IPv6 nodes on the same point-to-multipoint
communication between them must go through the first hop router of domain cannot have direct communication: any communication between
the same domain. them must go through the first hop router of the same domain.
This document also specifies a function called DAD proxy allowing the 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 use of DAD by the nodes on the same point-to-multipoint domain with
"split-horizon" forwarding scheme. It only impacts the first hop "split-horizon" forwarding scheme. It only impacts the first hop
router and it doesn't need modifications on the other IPv6 nodes. 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- This mechanism is fully effective if all the nodes of a point-to-
multipoint domain (except the DAD proxy itself) perform DAD. multipoint domain (except the DAD proxy itself) perform DAD.
However, if it is necessary to cover the scenarios where this However, if it is necessary to cover the scenarios where this
assumption is not met, additional solutions could be defined in the assumption is not met, additional solutions could be defined in the
future that work in conjunction with the mechanism described here. future that work in conjunction with the mechanism described here.
skipping to change at page 6, line 30 skipping to change at page 6, line 30
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
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 Binding Table MAY be
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
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).
skipping to change at page 11, line 16 skipping to change at page 11, line 16
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
[RFC6496] SHOULD be used and implemented on the BNG and the CPEs. [RFC6496] SHOULD be used and implemented on the BNG 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 [RFC6620]
[I-D.ietf-savi-send] [I-D.ietf-savi-mix]. [I-D.ietf-savi-send] [I-D.ietf-savi-mix].
7. Acknowledgments 7. Acknowledgments
The authors would like to thank Alan Kavanagh, Wojciech Dec and The authors would like to thank Alan Kavanagh, Wojciech Dec, Suresh
Suresh Krishnan for their comments. The authors would like also to Krishnan and Tassos Chatzithomaoglou for their comments. The authors
thank the IETF 6man WG members and the BBF community for their would like also to thank the IETF 6man WG members and the BBF
support. 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 12, line 5 skipping to change at page 12, line 5
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-18 (work in progress), (6LoWPAN)", draft-ietf-6lowpan-nd-18 (work in progress),
October 2011. October 2011.
[I-D.ietf-savi-fcfs]
Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come First-Serve Source-Address Validation for
Locally Assigned IPv6 Addresses", draft-ietf-savi-fcfs-14
(work in progress), February 2012.
[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-01 (work in progress), October 2011. draft-ietf-savi-mix-02 (work in progress), April 2012.
[I-D.ietf-savi-send] [I-D.ietf-savi-send]
Garcia-Martinez, A. and M. Bagnulo, "SEND-based Source- Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source-
Address Validation Implementation", Address Validation Implementation",
draft-ietf-savi-send-06 (work in progress), October 2011. draft-ietf-savi-send-07 (work in progress), March 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.
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over
PPP", RFC 5072, September 2007.
[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.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
in IPv6", RFC 6275, July 2011. in IPv6", RFC 6275, July 2011.
[RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-
Martinez, "Secure Proxy ND Support for SEcure Neighbor Martinez, "Secure Proxy ND Support for SEcure Neighbor
Discovery (SEND)", RFC 6496, February 2012. 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.
Authors' Addresses Authors' Addresses
Fabio Costa Fabio Costa
France Telecom Orange France Telecom Orange
61 rue des Archives 61 rue des Archives
75141 Paris Cedex 03 75141 Paris Cedex 03
France France
Email: fabio.costa@orange.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.com Email: jeanmichel.combes@orange.com
Xavier Pougnard Xavier Pougnard
France Telecom Orange France Telecom Orange
 End of changes. 15 change blocks. 
24 lines changed or deleted 28 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/