draft-ietf-6man-dad-proxy-07.txt   rfc6957.txt 
6man Working Group F. Costa Internet Engineering Task Force (IETF) F. Costa
Internet-Draft J-M. Combes, Ed. Request for Comments: 6957 J-M. Combes, Ed.
Intended status: Standards Track X. Pougnard Category: Standards Track X. Pougnard
Expires: October 11, 2013 France Telecom Orange ISSN: 2070-1721 France Telecom Orange
H. Li H. Li
Huawei Technologies Huawei Technologies
April 9, 2013 June 2013
Duplicate Address Detection Proxy Duplicate Address Detection Proxy
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 a "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 signaling, 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
address already used by another node, the first hop router replies address already used by another node, the first-hop router defends
instead of this last one. the address rather than the device using the address.
Status of this Memo
This Internet-Draft is submitted in full conformance with the Status of This Memo
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering This is an Internet Standards Track document.
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 This document is a product of the Internet Engineering Task Force
and may be updated, replaced, or obsoleted by other documents at any (IETF). It represents the consensus of the IETF community. It has
time. It is inappropriate to use Internet-Drafts as reference received public review and has been approved for publication by the
material or to cite them other than as "work in progress." Internet Engineering Steering Group (IESG). Further information on
Internet Standards is available in Section 2 of RFC 5741.
This Internet-Draft will expire on October 11, 2013. Information about the current status of this document, any errata,
and how to provide feedback on it may be obtained at
http://www.rfc-editor.org/info/rfc6957.
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
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
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
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 . . . . . . . . . . . . . . . 4
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 of
4.2.3. Confirmation of reachability to check the validity the Conflict . . . . . . . . . . . . . . . . . . . . 9
of the conflict . . . . . . . . . . . . . . . . . . . 9 5. Manageability Considerations . . . . . . . . . . . . . . . . 11
5. Manageability Considerations . . . . . . . . . . . . . . . . . 11 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 6.1. Interoperability with SEND . . . . . . . . . . . . . . . 11
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6.2. Protection against IP Source Address Spoofing . . . . . . 11
7.1. Interoperability with SEND . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
7.2. IP source address spoofing protection . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . 12
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . 12
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . 12
9.1. Normative References . . . . . . . . . . . . . . . . . . . 12 Appendix A. DAD-Proxy State Machine . . . . . . . . . . . . . . 14
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
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 a "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 [TR-101]. It only impacts the first-hop router and it
need modifications on the other IPv6 nodes. This mechanism is fully doesn't need modifications on the other IPv6 nodes. This mechanism
effective if all the nodes of a point-to-multipoint domain (except is fully effective if all the nodes of a point-to-multipoint domain
the DAD proxy itself) perform DAD. (except the DAD proxy itself) perform DAD.
This document explains also why DAD mechanism [RFC4862] without a This document explains also why the DAD mechanism [RFC4862] without a
proxy cannot be used in a point-to-multipoint architecture with proxy cannot be used in a point-to-multipoint architecture with a
"split-horizon" forwarding scheme (IPv6 over PPP [RFC5072] is not "split-horizon" forwarding scheme (IPv6 over PPP [RFC5072] is not
affected). One of the main reasons is that, because of this affected). One of the main reasons is that, because of this
forwarding scheme, IPv6 nodes on the same point-to-multipoint domain forwarding scheme, IPv6 nodes on the same point-to-multipoint domain
cannot have direct communication: any communication between them must cannot have direct communication: any communication between them must
go through the first hop router of the same domain. go through the first-hop router of the same domain.
It is assumed in this document that Link-layer addresses on a point- It is assumed in this document that link-layer addresses on a point-
to-multipoint domain are unique from the first hop router's point of to-multipoint domain are unique from the first-hop router's point of
view (e.g. in an untrusted Ethernet architecture this assumption can view (e.g., in an untrusted Ethernet architecture, this assumption
be guaranteed thanks to mechanisms such as "MAC Address Translation" can be guaranteed thanks to mechanisms such as Media Access Control
performed by an aggregation device between IPv6 nodes and the first (MAC) address translation performed by an aggregation device between
hop router). IPv6 nodes and the first-hop router).
1.1. Requirements Language 1.1. Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
2. Background 2. Background
Terminology in this document follows that in Neighbor Discovery for Terminology in this document follows that in "Neighbor Discovery for
IP version 6 (IPv6) [RFC4861] and IPv6 Stateless Address IP version 6 (IPv6)" [RFC4861] and "IPv6 Stateless Address
Autoconfiguration [RFC4862]. In addition, this section defines Autoconfiguration" [RFC4862]. In addition, this section defines
additional terms related to Digital Subscriber Line (DSL) and Fiber additional terms related to DSL and Fiber access architectures, which
access architectures, which are an important case where the solution are an important case where the solution described in this document
described in this document can be used: can be used:
Customer Premises Equipment (CPE) Customer Premises Equipment (CPE)
The first IPv6 node in a customer's network. The first IPv6 node in a customer's network.
Access Node (AN) Access Node (AN)
The first aggregation point in the public access network. It The first aggregation point in the public access network. It
is considered as a L2 bridge in this document. is considered as an L2 bridge in this document.
Broadband Network Gateway (BNG) Broadband Network Gateway (BNG)
The first hop router from the CPE's point of view. The first-hop router from the CPE's point of view.
VLAN N:1 architecture VLAN N:1 architecture
A point-to-multipoint architecture where many CPEs are A point-to-multipoint architecture where many CPEs are
connected to the same VLAN. The CPEs may be connected on the connected to the same VLAN. The CPEs may be connected on the
same or different Access Nodes. same or different Access Nodes.
split-horizon model split-horizon model
A forwarding scheme where CPEs cannot have direct layer 2 A forwarding scheme where CPEs cannot have direct layer 2
communications between them (i.e. IP flows must be forwarded communications between them (i.e., IP flows must be forwarded
through the BNG via routing). through the BNG via routing).
The following figure shows where are the different entities defined The following figure shows where the different entities are, as
above. defined above.
+------+ +----+ +------+ +----+
| CPE3 |---------| AN | | CPE3 |---------| AN |
+------+ +----+ +------+ +----+
| |
| |
+------+ +----+ +------+ +----+
| CPE2 |---------| AN |---+ | CPE2 |---------| AN |---+
+------+ +----+ | +------+ +----+ |
+------+ | | +------+ | |
| CPE1 |------------+ | | CPE1 |------------+ |
+------+ +-----+ +------+ +-----+
| BNG |--- Internet | BNG |--- Internet
+-----+ +-----+
Figure 1: DSL and Fiber access Architecture Figure 1: DSL and Fiber Access Architecture
3. Why existing IETF solutions are not sufficient? 3. Why Existing IETF Solutions Are Not Sufficient
In a DSL or Fiber access architecture depicted in Figure 1, CPE1,2,3 In a DSL or Fiber access architecture depicted in Figure 1, CPE1,
and the BNG are IPv6 nodes, while AN is a L2 bridge providing CPE2, CPE3, and the BNG are IPv6 nodes, while AN is an L2 bridge
connectivity between the BNG and each CPE. The AN enforces a split- providing connectivity between the BNG and each CPE. The AN enforces
horizon model so that CPEs can only send and receive frames (e.g. a split-horizon model so that CPEs can only send and receive frames
Ethernet frames) to and from the BNG but not to each other. That (e.g., Ethernet frames) to and from the BNG but not to each other.
said, the BNG is on a same link with all CPE, but one CPE is not on a That said, the BNG is on the same link with all CPEs, but a given CPE
same link with any other CPE. is not on the same link with any other CPE.
3.1. Duplicate Address Detection 3.1. Duplicate Address Detection
Duplicate Address Detection (DAD) [RFC4862] is performed when an IPv6 Duplicate Address Detection (DAD) [RFC4862] is performed when an IPv6
node verifies the uniqueness of a tentative IPv6 address. This node node verifies the uniqueness of a tentative IPv6 address. This node
sends a Neighbor Solicitation (NS) message with the IP destination sends a Neighbor Solicitation (NS) message with the IP destination
set to the solicited-node multicast address of the tentative address. set to the solicited-node multicast address of the tentative address.
This NS message is multicasted to other nodes on the same link. When This NS message is multicasted to other nodes on the same link. When
the tentative address is already used on the link by another node, the tentative address is already used on the link by another node,
this last one replies with a Neighbor Advertisement (NA) message to this last one replies with a Neighbor Advertisement (NA) message to
inform the first node. So when performing DAD, a node expects the NS inform the first node. So, when performing DAD, a node expects the
messages to be received by any node currently using the tentative NS messages to be received by any node currently using the tentative
address. address.
However, in a point-to-multipoint network with split-horizon However, in a point-to-multipoint network with a split-horizon
forwarding scheme implemented in the AN, the CPEs are prevented from forwarding scheme implemented in the AN, the CPEs are prevented from
talking to each other directly. All packets sent out from a CPE are talking to each other directly. All packets sent out from a CPE are
forwarded by the AN only to the BNG but not to any other CPE. NS forwarded by the AN only to the BNG but not to any other CPE. NS
messages sent by a certain CPE will be received only by the BNG and messages sent by a certain CPE will be received only by the BNG and
will not reach other CPEs. So, other CPEs have no idea that a will not reach other CPEs. So, other CPEs have no idea that a
certain IPv6 address is used by another CPE. That means, in a certain IPv6 address is used by another CPE. That means, in a
network with split-horizon, DAD, as defined in [RFC4862], can't work network with split-horizon, DAD, as defined in [RFC4862], can't work
properly without an additional help. properly without additional help.
3.2. Neighbor Discovery Proxy 3.2. Neighbor Discovery Proxy
Neighbor Discovery (ND) Proxy [RFC4389] is designed for forwarding ND Neighbor Discovery (ND) Proxy [RFC4389] is designed for forwarding ND
messages between different IP links where the subnet prefix is the messages between different IP links where the subnet prefix is the
same. A ND Proxy function on a bridge ensures that packets between same. An ND Proxy function on a bridge ensures that packets between
nodes on different segments can be received by this function and have nodes on different segments can be received by this function and have
the correct link-layer address type on each segment. When the ND the correct link-layer address type on each segment. When the ND
proxy receives a multicast ND message, it forwards it to all other Proxy receives a multicast ND message, it forwards it to all other
interfaces on a same link. interfaces on a same link.
In DSL or Fiber networks, when the AN, acting as a ND Proxy, receives In DSL or Fiber networks, when the AN, acting as an ND Proxy,
a ND message from a CPE, it will forward it to the BNG but none of receives an ND message from a CPE, it will forward it to the BNG but
other CPEs, as only the BNG is on the same link with the CPE. Hence, none of the other CPEs, as only the BNG is on the same link with the
implementing ND Proxy on the AN would not help a CPE acknowledge CPE. Hence, implementing ND Proxy on the AN would not help a CPE
link-local addresses used by other CPEs. acknowledge link-local addresses used by other CPEs.
As the BNG must not forward link-local scoped messages sent from a As the BNG must not forward link-local scoped messages sent from a
CPE to other CPEs, ND Proxy cannot be implemented in the BNG. CPE to other CPEs, ND Proxy cannot be implemented in the BNG.
3.3. 6LoWPAN Neighbor Discovery 3.3. 6LoWPAN Neighbor Discovery
[RFC6775] defines an optional modification of DAD for a 6LowPAN. [RFC6775] defines an optional modification of DAD for IPv6 over Low-
When a 6LoWPAN node wants to configure an IPv6 address, it registers Power Wireless Personal Area Networks (6LoWPAN). When a 6LoWPAN node
that address with one or more of its default routers using the wants to configure an IPv6 address, it registers that address with
Address Registration option (ARO). If this address is already owned one or more of its default routers using the Address Registration
by another node, the router informs the 6LoWPAN node this address Option (ARO). If this address is already owned by another node, the
cannot be configured. router informs the 6LoWPAN node that this address cannot be
configured.
This mechanism requires modifications in all hosts in order to This mechanism requires modifications in all hosts in order to
support the Address Registration option. support the ARO.
3.4. IPv6 Mobility Manager 3.4. IPv6 Mobility Manager
According to [RFC6275], a home agent acts as a proxy for mobile nodes According to [RFC6275], a home agent acts as a proxy for mobile nodes
when they are away from the home network: the home agent defends an when they are away from the home network: the home agent defends a
mobile node's home address by replying to NS messages with NA mobile node's home address by replying to NS messages with NA
messages. 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 that
message is only received by the sender of the corresponding NS an NA 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 from 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 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 based on DAD [RFC4862], it is not completely reliable, and the goal
this document is not to fix DAD. 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
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 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 For security or performances reasons, the Binding Table MUST be large
enough for the deployment in which it is used: if the Binding Table 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 is distinct from the Neighbor Cache, it MUST be at least the same
size as this last one. Implementations MUST either state the fixed size as this last one. Implementations MUST either state the fixed
size of Binding Table that they support or make the size size of the Binding Table that they support or make the size
configurable. In the latter case, implementations MUST state the configurable. In the latter case, implementations MUST state the
largest Binding Table size that they support. Additionally, largest Binding Table size that they support. Additionally,
implementations SHOULD allow an operator to enquire the current implementations SHOULD allow an operator to inquire about the current
occupancy level of the Binding Table to determine if it is about to occupancy level of the Binding Table to determine if it is about to
become full. Implementations encountering a full Binding Table will become full. Implementations encountering a full Binding Table will
likely handle it in a way similar to NS message loss. likely handle it in a way similar to NS message loss.
It is recommended to apply technical solutions to minimize the risk It is recommended to apply technical solutions to minimize the risk
that the Binding Table becomes full. These solutions are out of the that the Binding Table becomes full. These solutions are out of the
scope of this document. 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
When there is no entry for the tentative address, the BNG MUST create When there is no entry for the tentative address, the BNG MUST create
one with the following information: one with the following information:
o IPv6 Address Field set to the tentative address in the NS message. o IPv6 Address field set to the tentative address in the NS message.
o Link-layer Address Field set to the Link-layer source address in o Link-layer Address field set to the link-layer source address in
the Link-layer Header of the NS message. the link-layer header of the NS message.
The BNG MUST NOT reply to the CPE or forward the NS message. The BNG MUST NOT reply to the CPE or forward the NS message.
4.2.2. An entry already exists for the tentative address 4.2.2. An Entry Already Exists for the Tentative Address
When there is an entry for the tentative address, the BNG MUST check When there is an entry for the tentative address, the BNG MUST check
the following conditions: the following conditions:
o The address in the Target Address Field in the NS message is equal o The address in the Target Address field in the NS message is equal
to the address in the IPv6 Address Field in the entry. to the address in the IPv6 Address field in the entry.
o The source address of the IPv6 Header in the NS message is equal o The source address of the IPv6 Header in the NS message is equal
to the unspecified address. to the unspecified address.
When these conditions are met and the source address of the Link- When these conditions are met and the source address of the link-
Layer Header in the NS message is equal to the address in the Link- layer header in the NS message is equal to the address in the Link-
Layer Address Field in the entry, that means the CPE is still layer Address field in the entry, that means the CPE is still
performing DAD for this address. The BNG MUST NOT reply to the CPE performing DAD for this address. The BNG MUST NOT reply to the CPE
or forward the NS message. or forward the NS message.
When these conditions are met and the source address of the Link- When these conditions are met and the source address of the link-
Layer Header in the NS message is not equal to the address in the layer header in the NS message is not equal to the address in the
Link-Layer Address Field in the entry, that means possibly another Link-layer Address field in the entry, that means possibly another
CPE performs DAD for an already owned address. The BNG then has to CPE is performing DAD for an already owned address. The BNG then has
verify whether there is a real conflict by checking if the CPE whose to verify whether there is a real conflict by checking if the CPE
IPv6 address is in the entry is still connected. In the following, whose IPv6 address is in the entry is still connected. In the
we will call IPv6-CPE1 the IPv6 address of the existing entry in the following text, we will call IPv6-CPE1 the IPv6 address of the
Binding Table, Link-layer-CPE1 the Link-layer address of that entry existing entry in the Binding Table, Link-layer-CPE1 the link-layer
and Link-layer-CPE2 the Link-layer address of the CPE which is address of that entry, and Link-layer-CPE2 the link-layer address of
performing DAD, which is different from Link-layer-CPE1. the CPE that is performing DAD, which is 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-layer-CPE1, the reachability 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 in this cache it is o If IPv6-CPE1 is in the Neighbor Cache, but in this cache it is
associated with another Link-layer address than Link-layer-CPE1, associated with a link-layer address other than Link-layer-CPE1,
that means that there is possibly a conflict with another CPE, but 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 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 of this document, since one assumption made above is that all the
nodes of a point-to-multipoint domain (except the DAD proxy nodes of a point-to-multipoint domain (except the DAD proxy
itself) perform DAD. itself) perform DAD.
o If IPv6-CPE1 is not in the Neighbor Cache, then the BNG MUST o If IPv6-CPE1 is not in the Neighbor Cache, then the BNG MUST
create a new entry based on the information of the entry in the create a new entry based on the information of the entry in the
Binding Table. This step is necessary in order to trigger the Binding Table. This step is necessary in order to trigger the
reachibility check as explained in Section 4.2.3. The entry in reachability check as explained in Section 4.2.3. The entry in
the Neighbor Cache MUST be created based on the algorithm defined the Neighbor Cache MUST be created based on the algorithm defined
in section 7.3.3 of [RFC4861], in particular by considering the in Section 7.3.3 of [RFC4861], in particular by treating this case
case as if a packet other than a solicited Neighbor Advertisement as though a packet other than a solicited Neighbor Advertisement
was received from IPv6-CPE1. That means that the new entry of the were received from IPv6-CPE1. Thus, the new entry of the Neighbor
Neighbor Cache MUST contain the following information: Cache MUST contain the following information:
* IPv6 address: IPv6-CPE1 * IPv6 address: IPv6-CPE1
* Link-layer address: Link-layer-CPE1 * Link-layer address: Link-layer-CPE1
* State: STALE * State: STALE
Then the reachability of IPv6-CPE1 MUST be confirmed as soon as The reachability of IPv6-CPE1 MUST be confirmed as soon as
possible following the procedure explained in section 4.2.3. possible following the procedure explained in Section 4.2.3.
4.2.3. Confirmation of reachability to check the validity of the 4.2.3. Confirmation of Reachability to Check the Validity of the
conflict Conflict
Given that the IPv6-CPE1 is in an entry of the Neighbor Cache, the Given that the IPv6-CPE1 is in an entry of the Neighbor Cache, the
reachability of IPv6-CPE1 is checked by using the NUD (Neighbor reachability of IPv6-CPE1 is checked by using the Neighbor
Unreachibility Detection) mechanism described in section 7.3.1 of Unreachability Detection (NUD) mechanism described in Section 7.3.1
[RFC4861]. This mechanism MUST be triggered as if a packet has to be of [RFC4861]. This mechanism MUST be triggered as though a packet
sent to IPv6-CPE1. Note that in some cases this mechanism does not had to be sent to IPv6-CPE1. Note that in some cases this mechanism
do anything, for instance if the state of the entry is REACHABLE and does not do anything. For instance, if the state of the entry is
a positive confirmation was received recently that the forward path REACHABLE and a positive confirmation was received recently that the
to the IPv6-CPE1 was functioning properly (see RFC 4861 for more forward path to the IPv6-CPE1 was functioning properly (see RFC 4861
details). for more details), this mechanism does not do anything.
Next, the behavior of the BNG depends on the result of the NUD Next, the behavior of the BNG depends on the result of the NUD
process, as explained in the following sections. process, as explained in the following sections.
4.2.3.1. The result of the NUD process is negative 4.2.3.1. The Result of the NUD Process is Negative
If the result of the NUD process is negative (i.e. if this process If the result of the NUD process is negative (i.e., if this process
removes IPv6-CPE1 from the Neighbor Cache), that means that the removes IPv6-CPE1 from the Neighbor Cache), that means that the
potential conflict is not real. potential conflict is not real.
The conflicting entry in the Binding Table (Link-layer-CPE1) is The conflicting entry in the Binding Table (Link-layer-CPE1) is
deleted and it is replaced by a new entry with the same IPv6 address, deleted and it is replaced by a new entry with the same IPv6 address,
but the Link-layer address of the CPE which is performing DAD (Link- but the link-layer address of the CPE is performing DAD (Link-layer-
layer-CPE2), as explained in Section 4.2.1. CPE2), as explained in Section 4.2.1.
4.2.3.2. The result of the NUD process is positive 4.2.3.2. The Result of the NUD Process is Positive
If the result of the NUD process is positive (i.e. if after this If the result of the NUD process is positive (i.e., if after this
process the state of IPv6-CPE1 is REACHABLE), that means that the process the state of IPv6-CPE1 is REACHABLE), that means that the
potential conflict is real. potential conflict is real.
As shown in Figure 2, the BNG MUST reply to CPE that is performing As shown in Figure 2, the BNG MUST reply to the CPE that is
DAD (CPE2 in Figure 1) with a NA message which has the following performing DAD (CPE2 in Figure 1) with an NA message that has the
format: following format:
Layer 2 Header Fields: Layer 2 Header Fields:
Source Address Source Address
The Link-layer address of the interface on which the BNG The link-layer address of the interface on which the BNG
received the NS message. received the NS message.
Destination Address Destination Address
The source address in the Layer 2 Header of the NS The source address in the Layer 2 Header of the NS
message received by the BNG (i.e. Link-layer-CPE2) message received by the BNG (i.e., Link-layer-CPE2).
IPv6 Header Fields: IPv6 Header Fields:
Source Address Source Address
An address assigned to the interface from which the An address assigned to the interface from which the
advertisement is sent. advertisement is sent.
Destination Address Destination Address
The all-nodes multicast address. The all-nodes multicast address.
ICMPv6 Fields: ICMPv6 Fields:
Target Address Target Address
The tentative address already used (i.e. IPv6-CPE1). The tentative address already used (i.e., IPv6-CPE1).
Target Link-layer address Target Link-layer Address
The Link-layer address of the interface on which the BNG The link-layer address of the interface on which the BNG
received the NS message. received the NS message.
CPE1 CPE2 BNG CPE1 CPE2 BNG
| | | | | |
(a)| | | (a)| | |
| | | | | |
(b)|===================>| (b)|===================>|
| | |(c) | | |(c)
| | | | | |
| (d)| | | (d)| |
| | | | | |
| (e)|=========>| | (e)|=========>|
| | | | | |
| |<=========|(f) | |<=========|(f)
| | | | | |
(a) CPE1 generated a tentative address (a) CPE1 generates 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
The BNG and the CPE MUST support the Unicast Transmission on Link- Figure 2: DAD Failure
layer of IPv6 Multicast Messages [RFC6085], to be able, respectively,
The BNG and the CPE MUST support the unicast transmission on the link
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. Manageability Considerations 5. Manageability Considerations
The BNG SHOULD support a mechanism to log and emit alarms whenever a The BNG SHOULD support a mechanism to log and emit alarms whenever a
duplication of IPv6 addresses is detected by the DAD-Proxy function. duplication of IPv6 addresses is detected by the DAD-Proxy function.
Moreover, the BNG SHOULD implement a function to allow an operator to 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 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 management of access rights to get this information is out of the
scope of this document. scope of this document.
6. IANA Considerations 6. Security Considerations
No new options or messages are defined in this document.
7. Security Considerations
7.1. Interoperability with SEND 6.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 it SHOULD be implemented and used on the
BNG and the CPEs. BNG and the CPEs.
7.2. IP source address spoofing protection 6.2. Protection against IP Source Address Spoofing
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 combination with Source Address
Validation Improvement (SAVI) mechanisms [RFC6620] Validation Improvement (SAVI) mechanisms [RFC6620] [SAVI-SEND]
[I-D.ietf-savi-send] [I-D.ietf-savi-mix]. [SAVI-MIX].
If so, the SAVI device is the BNG and the Binding Anchor for a CPE is If SAVI mechanisms are used, the SAVI device is the BNG, and the
its MAC address, which is assumed to be unique in this document (cf. Binding Anchor for a CPE is its MAC address, which is assumed to be
Section 1). unique in this document (cf. Section 1).
8. Acknowledgments 7. 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
would like also to thank the IETF 6man WG members and the BBF authors would like also to thank the IETF 6man WG members and the BBF
community for their support. community for their support.
9. References 8. References
9.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,
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.
9.2. Informative References 8.2. Informative References
[I-D.ietf-savi-mix] [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, "SAVI Neighbor Discovery (SEND)", RFC 3971, March 2005.
for Mixed Address Assignment Methods Scenario",
draft-ietf-savi-mix-03 (work in progress), November 2012.
[I-D.ietf-savi-send] [RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)",
Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source- RFC 3972, March 2005.
Address Validation Implementation",
draft-ietf-savi-send-09 (work in progress), April 2013.
[RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure [RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery
Neighbor Discovery (SEND)", RFC 3971, March 2005. Proxies (ND Proxy)", RFC 4389, April 2006.
[RFC3972] Aura, T., "Cryptographically Generated Addresses (CGA)", [RFC5072] Varada, S., Ed., Haskins, D., and E. Allen, "IP Version 6
RFC 3972, March 2005. over PPP", RFC 5072, September 2007.
[RFC4389] Thaler, D., Talwar, M., and C. Patel, "Neighbor Discovery [RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing
Proxies (ND Proxy)", RFC 4389, April 2006. Neighbor Discovery Proxy: Problem Statement", RFC 5909,
July 2010.
[RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over [RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support
PPP", RFC 5072, September 2007. in IPv6", RFC 6275, July 2011.
[RFC5909] Combes, J-M., Krishnan, S., and G. Daley, "Securing [RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia-
Neighbor Discovery Proxy: Problem Statement", RFC 5909, Martinez, "Secure Proxy ND Support for SEcure Neighbor
July 2010. Discovery (SEND)", RFC 6496, February 2012.
[RFC6275] Perkins, C., Johnson, D., and J. Arkko, "Mobility Support [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
in IPv6", RFC 6275, July 2011. SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", RFC
6620, May 2012.
[RFC6496] Krishnan, S., Laganier, J., Bonola, M., and A. Garcia- [RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C.
Martinez, "Secure Proxy ND Support for SEcure Neighbor Bormann, "Neighbor Discovery Optimization for IPv6 over
Discovery (SEND)", RFC 6496, February 2012. Low-Power Wireless Personal Area Networks (6LoWPANs)",
RFC 6775, November 2012.
[RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS [SAVI-MIX] Bi, J., Yao, G., Halpern, J., and E. Levy-Abegnoli, Ed.,
SAVI: First-Come, First-Served Source Address Validation "SAVI for Mixed Address Assignment Methods Scenario",
Improvement for Locally Assigned IPv6 Addresses", Work in Progress, May 2013.
RFC 6620, May 2012.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann, [SAVI-SEND] Bagnulo, M. and A. Garcia-Martinez, "SEND-based Source-
"Neighbor Discovery Optimization for IPv6 over Low-Power Address Validation Implementation", Work in Progress,
Wireless Personal Area Networks (6LoWPANs)", RFC 6775, April 2013.
November 2012.
Appendix A. DAD Proxy state machine [TR-101] The Broadband Forum, "Migration to Ethernet-Based DSL
Aggregation", Issue 2, Technical Report TR-101, July
2011, <http://www.broadband-forum.org/technical/download/
TR-101_Issue-2.pdf>.
This appendix, informative, contains a summary (cf. Table 1) of the Appendix A. DAD-Proxy State Machine
actions done by the BNG when it receives a DAD based NS (DAD-NS)
message. The tentative address in this message is IPv6-CPE1 and the
associated Link-layer address is Link-layer-CPE2. The actions are
precisely specified in Section 4.2.
+------------+---------------------+-------------------+------------+ This appendix, which is informative, contains a summary (cf. Table 1)
| Event | Check | Action | New event | of the actions done by the BNG when it receives a DAD-based NS
+------------+---------------------+-------------------+------------+ (DAD-NS) message. The tentative address in this message is IPv6-CPE1
| DAD-NS | o No entry for | Create an entry | - | and the associated link-layer address is Link-layer-CPE2. The
| message | IPv6-CPE1 in the | for IPv6-CPE1 | | actions are precisely specified in Section 4.2.
| reception. | Binding Table. | bound to | |
| | | Link-layer-CPE2 | | +------------+--------------------+--------------------+------------+
| | | in the Binding | | | Event | Check | Action | New event |
| | | Table. | | +------------+--------------------+--------------------+------------+
| | o Entry for | - | Existing | | DAD-NS | * No entry for | Create an entry | - |
| | IPv6-CPE1 in the | | entry | | message | IPv6-CPE1 in the | for IPv6-CPE1 | |
| | Binding Table. | | | | reception. | Binding Table. | bound to Link- | |
| Existing | o Link-layer-CPE2 | - | - | | | | layer-CPE2 in the | |
| entry | bound to IPv6-CPE1 | | | | | | Binding Table. | |
| | in the Binding | | | | | * Entry for | - | Existing |
| | Table. | | | | | IPv6-CPE1 in the | | entry. |
| | o Another | - | Conflict? | | | Binding Table. | | |
| | Link-layer address, | | | | | | | |
| | Link-layer-CPE1, | | | | Existing | * Link-layer-CPE2 | - | - |
| | bound to IPv6-CPE1 | | | | entry. | bound to IPv6-CPE1 | | |
| | in the Binding | | | | | in the Binding | | |
| | Table. | | | | | Table. | | |
| Conflict? | o IPv6-CPE1 | - | Reachable? | | | * Another link- | - | Conflict? |
| | associated to | | | | | layer address, | | |
| | Link-layer-CPE1 in | | | | | Link-layer-CPE1, | | |
| | the Neighbor Cache. | | | | | bound to IPv6-CPE1 | | |
| | o IPv6-CPE1 | Out of scope. | - | | | in the Binding | | |
| | associated to | | | | | Table. | | |
| | another Link-layer | | | | | | | |
| | address than | | | | Conflict? | * IPv6-CPE1 | - | Reachable? |
| | Link-layer-CPE1 in | | | | | associated to | | |
| | the Neighbor Cache. | | | | | Link-layer-CPE1 in | | |
| | o IPv6-CPE1 is not | Create an entry | Reachable? | | | the Neighbor | | |
| | in the Neighbor | for IPv6-CPE1 | | | | Cache. | | |
| | Cache. | associated to | | | | * IPv6-CPE1 | Out of scope. | - |
| | | Link-layer-CPE1 | | | | associated to | | |
| | | in the Neighbor | | | | another link-layer | | |
| | | Cache. | | | | address than Link- | | |
| Reachable? | o NUD process is | IPv6-CPE2 is | - | | | layer-CPE1 in the | | |
| | negative. | bound to | | | | Neighbor Cache. | | |
| | | Link-layer-CPE2, | | | | * IPv6-CPE1 is not | Create an entry | Reachable? |
| | | instead to | | | | in the Neighbor | for IPv6-CPE1 | |
| | | Link-layer-CPE1, | | | | Cache. | associated to | |
| | | in the Binding | | | | | Link-layer-CPE1 in | |
| | | Table. | | | | | the Neighbor | |
| | o NUD process is | A NA message is | - | | | | Cache. | |
| | positive. | sent. | | | Reachable? | * NUD process is | IPv6-CPE2 is bound | - |
+------------+---------------------+-------------------+------------+ | | negative. | to Link-layer- | |
Table 1 | | | CPE2, instead to | |
| | | Link-layer-CPE1, | |
| | | in the Binding | |
| | | Table. | |
| | * NUD process is | A NA message is | - |
| | positive. | sent. | |
+------------+--------------------+--------------------+------------+
Table 1: DAD-Proxy State Machine
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 (editor) Jean-Michel Combes (editor)
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
2 avenue Pierre Marzin 2 avenue Pierre Marzin
22300 Lannion 22300 Lannion
France France
Email: xavier.pougnard@orange.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. 107 change blocks. 
298 lines changed or deleted 297 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/