draft-ietf-6man-dad-proxy-04.txt   draft-ietf-6man-dad-proxy-05.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 17, 2012 France Telecom Orange Expires: March 23, 2013 France Telecom Orange
H. Li H. Li
Huawei Technologies Huawei Technologies
June 15, 2012 September 19, 2012
Duplicate Address Detection Proxy Duplicate Address Detection Proxy
draft-ietf-6man-dad-proxy-04 draft-ietf-6man-dad-proxy-05
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 17, 2012. This Internet-Draft will expire on March 23, 2013.
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 2, line 16 skipping to change at page 2, line 16
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 . . . . . . . . . . . . . . . . . . . 6
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
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. DAD Proxy state machine . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
This document explains why Duplicate Address Detection (DAD) This document specifies a function called Duplicate Address Detection
mechanism [RFC4862] cannot be used in a point-to-multipoint (DAD) proxy allowing the use of DAD by the nodes on the same point-
architecture with "split-horizon" forwarding scheme (IPv6 over PPP to-multipoint domain with "split-horizon" forwarding scheme. It only
[RFC5072] is not affected). One of the main reasons is that, because impacts the first hop router and it doesn't need modifications on the
of this forwarding scheme, IPv6 nodes on the same point-to-multipoint other IPv6 nodes. This mechanism is fully effective if all the nodes
domain cannot have direct communication: any communication between of a point-to-multipoint domain (except the DAD proxy itself) perform
them must go through the first hop router of the same domain. DAD.
This document also specifies a function called DAD proxy allowing the This document explains also why DAD mechanism [RFC4862] cannot be
use of DAD by the nodes on the same point-to-multipoint domain with used in a point-to-multipoint architecture with "split-horizon"
"split-horizon" forwarding scheme. It only impacts the first hop forwarding scheme (IPv6 over PPP [RFC5072] is not affected). One of
router and it doesn't need modifications on the other IPv6 nodes. the main reasons is that, because of this forwarding scheme, IPv6
This mechanism is fully effective if all the nodes of a point-to- nodes on the same point-to-multipoint domain cannot have direct
multipoint domain (except the DAD proxy itself) perform DAD. communication: any communication between them must go through the
However, if it is necessary to cover the scenarios where this first hop router of the same domain.
assumption is not met, additional solutions could be defined in the
future that work in conjunction with the mechanism described here.
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 can
be guaranteed thanks to mechanisms such as "MAC Address Translation" be guaranteed thanks to mechanisms such as "MAC Address Translation"
performed by an aggregation device between IPv6 nodes and the first performed by an aggregation device between IPv6 nodes and the first
hop router). 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) document [RFC4861] and IPv6 Stateless Address IP version 6 (IPv6) [RFC4861] and IPv6 Stateless Address
Autoconfiguration document [RFC4862]. In addition, this section Autoconfiguration [RFC4862]. In addition, this section defines
defines additional terms related to DSL and Fiber access additional terms related to Digital Subscriber Line (DSL) and Fiber
architectures, which are an important case where the solution access architectures, which are an important case where the solution
described in this document can be used: described in this document 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 a L2 bridge in this document.
Broadband Network Gateway (BNG) Broadband Network Gateway (BNG)
skipping to change at page 5, line 10 skipping to change at page 5, line 4
horizon model so that CPEs can only send and receive frames (e.g. horizon model so that CPEs can only send and receive frames (e.g.
Ethernet frames) to and from the BNG but not to each other. That Ethernet frames) to and from the BNG but not to each other. That
said, the BNG is on a same link with all CPE, but one CPE is not on a said, the BNG is on a same link with all CPE, but one CPE is not on a
same link with any other CPE. same link with any other CPE.
3.1. Duplicate Address Detection 3.1. Duplicate Address Detection
Duplicate Address Dectection (DAD) [RFC4862] is performed when an Duplicate Address Dectection (DAD) [RFC4862] is performed when an
IPv6 node verifies the uniqueness of a tentative IPv6 address. This IPv6 node verifies the uniqueness of a tentative IPv6 address. This
node sends a Neighbor Solicitation (NS) message with the IP node sends a Neighbor Solicitation (NS) message with the IP
destination set to solicited-node multicast address of the tentative destination set to the solicited-node multicast address of the
address. This NS message is multicasted to other nodes on a same tentative address. This NS message is multicasted to other nodes on
link. When the tentative address is already used on the link by the same link. When the tentative address is already used on the
another node, this last one replies with a Neighbor Advertisement link by another node, this last one replies with a Neighbor
(NA) message to inform the first node. So when performing DAD, a Advertisement (NA) message to inform the first node. So when
node expects the NS messages are received by other nodes. performing DAD, a node expects the NS messages to be received by any
node currently using the tentative address.
However, in a point-to-multipoint network with split-horizon However, in a point-to-multipoint network with 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 talking to each other directly. All packets sent out from a CPE are
would be forwarded by AN only to the BNG but not to any other CPE. forwarded by the AN only to the BNG but not to any other CPE. NS
That said, NS messages sent by a certain CPE will be received only by messages sent by a certain CPE will be received only by the BNG and
the BNG and will not reach other CPEs. So, other CPEs have no idea will not reach other CPEs. So, other CPEs have no idea that a
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 per [RFC4862] can't work properly network with split-horizon, DAD, as defined in [RFC4862], can't work
without an additional helper. properly without an 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. A 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 AN, acting as a ND Proxy, receives a In DSL or Fiber networks, when the AN, acting as a ND Proxy, receives
ND message from a CPE, it will forward it to the BNG but none of a ND message from a CPE, it will forward it to the BNG but none of
other CPEs, as only the BNG is on the same link with the CPE. Hence, other CPEs, as only the BNG is on the same link with the CPE. Hence,
implementing ND Proxy on AN would not help a CPE acknowledge link- implementing ND Proxy on the AN would not help a CPE acknowledge
local addresses used by other CPEs. 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
[I-D.ietf-6lowpan-nd] defines an optional modification of DAD for a [I-D.ietf-6lowpan-nd] defines an optional modification of DAD for a
6LowPAN. When a 6LoWPAN node wants to configure an IPv6 address, it 6LowPAN. When a 6LoWPAN node wants to configure an IPv6 address, it
registers that address with one or more of its default router using registers that address with one or more of its default routers 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 This mechanism requires modifications in all hosts in order to
hosts in order to support the Address Registration option. support the Address Registration option.
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 these last ones are away from the home network: the home agent when they are away from the home network: the home agent defends an
defends an mobile node's home address by replying to NS messages with mobile node's home address by replying to NS messages with NA
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 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.
skipping to change at page 7, line 9 skipping to change at page 6, line 50
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.
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 the source address, in order to check if a tentative address is
in use on the link. The BNG receives this message and MUST perform already in use on the link. The BNG receives this message and MUST
actions depending on the information in the Binding Table. perform 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
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 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
skipping to change at page 8, line 18 skipping to change at page 8, line 11
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 another Link-layer address 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. This case could be covered in the future by itself) perform DAD.
additional solutions that work in conjunction with the DAD proxy.
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 reachibility 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 considering the
case as if a packet other than a solicited Neighbor Advertisement case as if a packet other than a solicited Neighbor Advertisement
was received from IPv6-CPE1. That means that the new entry of the was received from IPv6-CPE1. That means that the new entry of the
Neighbor Cache MUST contain the following information: Neighbor Cache MUST contain the following information:
skipping to change at page 11, line 49 skipping to change at page 11, line 42
[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-18 (work in progress), (6LoWPAN)", draft-ietf-6lowpan-nd-21 (work in progress),
October 2011. August 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-02 (work in progress), April 2012. draft-ietf-savi-mix-02 (work in progress), April 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-07 (work in progress), March 2012. draft-ietf-savi-send-08 (work in progress),
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.
skipping to change at page 13, line 5 skipping to change at page 12, line 37
[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 [RFC6620] Nordmark, E., Bagnulo, M., and E. Levy-Abegnoli, "FCFS
SAVI: First-Come, First-Served Source Address Validation SAVI: First-Come, First-Served Source Address Validation
Improvement for Locally Assigned IPv6 Addresses", Improvement for Locally Assigned IPv6 Addresses",
RFC 6620, May 2012. RFC 6620, May 2012.
Appendix A. DAD Proxy state machine
This appendix contains a summary (cf. Table 1) 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 and the associated
Link-layer address is Link-layer-CPE2. The actions are precisely
specified in Section 4.2.
+------------+---------------------+-------------------+------------+
| Event | Check | Action | New event |
+------------+---------------------+-------------------+------------+
| DAD-NS | o No entry for | Create an entry | - |
| message | IPv6-CPE1 in the | for IPv6-CPE1 | |
| reception. | Binding Table. | bound to | |
| | | Link-layer-CPE2 | |
| | | in the Binding | |
| | | Table. | |
| | o Entry for | - | Existing |
| | IPv6-CPE1 in the | | entry |
| | Binding Table. | | |
| Existing | o Link-layer-CPE2 | - | - |
| entry | bound to IPv6-CPE1 | | |
| | in the Binding | | |
| | Table. | | |
| | o Another | - | Conflict? |
| | Link-layer address, | | |
| | Link-layer-CPE1, | | |
| | bound to IPv6-CPE1 | | |
| | in the Binding | | |
| | Table. | | |
| Conflict? | o IPv6-CPE1 | - | Reachable? |
| | associated to | | |
| | Link-layer-CPE1 in | | |
| | the Neighbor Cache. | | |
| | o IPv6-CPE1 | Out of scope. | - |
| | associated to | | |
| | another Link-layer | | |
| | address than | | |
| | Link-layer-CPE1 in | | |
| | the Neighbor Cache. | | |
| | o IPv6-CPE1 is not | Create an entry | Reachable? |
| | in the Neighbor | for IPv6-CPE1 | |
| | Cache. | associated to | |
| | | Link-layer-CPE1 | |
| | | in the Neighbor | |
| | | Cache. | |
| Reachable? | o NUD process is | IPv6-CPE2 is | - |
| | negative. | bound to | |
| | | Link-layer-CPE2, | |
| | | instead to | |
| | | Link-layer-CPE1, | |
| | | in the Binding | |
| | | Table. | |
| | o NUD process is | A NA message is | - |
| | positive. | sent. | |
+------------+---------------------+-------------------+------------+
Table 1
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
 End of changes. 23 change blocks. 
59 lines changed or deleted 117 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/