One document matched: draft-ietf-6man-dad-proxy-04.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY RFC2119 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
<!ENTITY RFC3971 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3971.xml">
<!ENTITY RFC3972 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.3972.xml">
<!ENTITY RFC4389 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4389.xml">
<!ENTITY RFC4861 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4861.xml">
<!ENTITY RFC4862 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.4862.xml">
<!ENTITY RFC5072 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5072.xml">
<!ENTITY RFC5909 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5909.xml">
<!ENTITY RFC6085 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6085.xml">
<!ENTITY RFC6275 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6275.xml">
<!ENTITY RFC6496 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6496.xml">
<!ENTITY RFC6620 PUBLIC "" "http://xml.resource.org/public/rfc/bibxml/reference.RFC.6620.xml">
<!ENTITY lowpan-nd PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-6lowpan-nd.xml">
<!ENTITY savi-send PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-savi-send.xml">
<!ENTITY savi-mix PUBLIC "" "http://xml.resource.org/public/rfc/bibxml3/reference.I-D.ietf-savi-mix.xml">
]>
<?rfc strict="yes" ?>
<?rfc toc="yes" ?>
<?rfc tocompact="yes" ?>
<?rfc compact="yes" ?>
<?rfc subcompact="no" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes" ?>
<rfc category="std" docName="draft-ietf-6man-dad-proxy-04" ipr="trust200902">
<front>
<title abbrev="DAD-Proxy">Duplicate Address Detection Proxy</title>
<!-- AUTHORS -->
<!--?rfc include="author-daley.xml" ?-->
<author fullname="Fabio Costa" initials="F." surname="Costa">
<organization>France Telecom Orange</organization>
<address>
<postal>
<street>61 rue des Archives</street>
<city>75141 Paris Cedex 03</city>
<country>France</country>
</postal>
<email>fabio.costa@orange.com</email>
</address>
</author>
<author fullname="Jean-Michel Combes" initials="J-M." surname="Combes">
<organization>France Telecom Orange</organization>
<address>
<postal>
<street>38 rue du General Leclerc</street>
<city>92794 Issy-les-Moulineaux Cedex 9</city>
<country>France</country>
</postal>
<email>jeanmichel.combes@orange.com</email>
</address>
</author>
<author fullname="Xavier Pougnard" initials="X." surname="Pougnard">
<organization>France Telecom Orange</organization>
<address>
<postal>
<street>2 avenue Pierre Marzin</street>
<city>22300 Lannion</city>
<country>France</country>
</postal>
<email>xavier.pougnard@orange.com</email>
</address>
</author>
<author fullname="Hongyu Li" initials="H." surname="Li">
<organization>Huawei Technologies</organization>
<address>
<postal>
<street>Huawei Industrial Base</street>
<city>Shenzhen</city>
<country>China</country>
</postal>
<email>lihy@huawei.com</email>
</address>
</author>
<date month="June" year="2012" />
<area>Internet</area>
<workgroup>6man Working Group</workgroup>
<abstract>
<t>The document describes a mechanism allowing the use of Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-multipoint architecture with "split-horizon" forwarding scheme. Based on the DAD signalling, the first hop router 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 address already used by another node, the first hop router replies instead of this last one.</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>This document explains why Duplicate Address Detection (DAD) mechanism <xref target="RFC4862"></xref> cannot be used in a point-to-multipoint architecture with "split-horizon" forwarding scheme (IPv6 over PPP <xref target="RFC5072"></xref> is not affected). One of the main reasons is that, because of this forwarding scheme, IPv6 nodes on the same point-to-multipoint domain cannot have direct communication: any communication between them must go through the first hop router of the same domain.</t>
<t>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 "split-horizon" forwarding scheme. It only impacts the first hop 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-multipoint domain (except the DAD proxy itself) perform DAD. However, if it is necessary to cover the scenarios where this assumption is not met, additional solutions could be defined in the future that work in conjunction with the mechanism described here.</t>
<t>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 view (e.g. in an untrusted Ethernet architecture this assumption can be guaranteed thanks to mechanisms such as "MAC Address Translation" performed by an aggregation device between IPv6 nodes and the first hop router).</t>
<section title="Requirements Language">
<t>The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in <xref target="RFC2119">RFC 2119</xref>.</t>
</section>
</section>
<section title="Background">
<t>Terminology in this document follows that in Neighbor Discovery for IP version 6 (IPv6) document <xref target="RFC4861"></xref> and IPv6 Stateless Address Autoconfiguration document <xref target="RFC4862"></xref>. In addition, this section defines additional terms related to DSL and Fiber access architectures, which are an important case where the solution described in this document can be used:</t>
<t><list hangIndent="6" style="hanging">
<t hangText="Customer Premises Equipment (CPE)"><vspace />
The first IPv6 node in a customer's network.</t>
<t hangText="Access Node (AN)"><vspace />
The first aggregation point in the public access network. It is considered as a L2 bridge in this document.</t>
<t hangText="Broadband Network Gateway (BNG)"><vspace />
The first hop router from the CPE's point of view.</t>
<t hangText="VLAN N:1 architecture"><vspace />
A point-to-multipoint architecture where many CPEs are connected to the same VLAN. The CPEs may be connected on the same or different Access Nodes.</t>
<t hangText="split-horizon model"><vspace />
A forwarding scheme where CPEs cannot have direct layer 2 communications between them (i.e. IP flows must be forwarded through the BNG via routing).</t>
</list></t>
<t>The following figure shows where are the different entities defined
above.</t>
<figure anchor="Fig_Architecture" title="DSL and Fiber access Architecture">
<artwork xml:space="preserve"><![CDATA[
+------+ +----+
| CPE3 |---------| AN |
+------+ +----+
|
|
+------+ +----+
| CPE2 |---------| AN |---+
+------+ +----+ |
+------+ | |
| CPE1 |------------+ |
+------+ +-----+
| BNG |--- Internet
+-----+
]]></artwork>
</figure>
</section>
<section title="Why existing IETF solutions are not sufficient?">
<t>In a DSL or Fiber access architecture depicted in <xref target="Fig_Architecture"></xref>, CPE1,2,3 and the BNG are IPv6 nodes, while AN is a L2 bridge providing connectivity between the BNG and each CPE. The AN enforces a split-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 said, the BNG is on a same link with all CPE, but one CPE is not on a same link with any other CPE.</t>
<section title="Duplicate Address Detection">
<t>Duplicate Address Dectection (DAD) <xref target="RFC4862"></xref> is performed when an IPv6 node verifies the uniqueness of a tentative IPv6 address. This node sends a Neighbor Solicitation (NS) message with the IP destination set to solicited-node multicast address of the tentative address. This NS message is multicasted to other nodes on a same link. When the tentative address is already used on the link by another node, this last one replies with a Neighbor Advertisement (NA) message to inform the first node. So when performing DAD, a node expects the NS messages are received by other nodes.</t>
<t>However, in a point-to-multipoint network with split-horizon forwarding scheme implemented in the AN, the CPEs are prevented from talking to each other directly. All packets sent out from a CPE would be forwarded by AN only to the BNG but not to any other CPE. That said, NS 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 certain IPv6 address is used by another CPE. That means, in a network with split-horizon, DAD per <xref target="RFC4862"></xref> can't work properly without an additional helper.</t>
</section>
<section title="Neighbor Discovery Proxy">
<t>Neighbor Discovery (ND) Proxy <xref target="RFC4389"></xref> is designed for forwarding ND messages between different IP links where the subnet prefix is the same. A ND Proxy function on a bridge ensures that packets between nodes on different segments can be received by this function and have the correct link-layer address type on each segment. When the ND proxy receives a multicast ND message, it forwards it to all other interfaces on a same link.</t>
<t>In DSL or Fiber networks, when AN, acting as a ND Proxy, receives 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, implementing ND Proxy on AN would not help a CPE acknowledge link-local addresses used by other CPEs.</t>
<t>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.</t>
</section>
<section title="6LoWPAN Neighbor Discovery">
<t><xref target="I-D.ietf-6lowpan-nd"></xref> defines an optional modification of DAD for a 6LowPAN. When a 6LoWPAN node wants to configure an IPv6 address, it registers that address with one or more of its default router using the Address Registration option (ARO). If this address is already owned by another node, the router informs the 6LoWPAN node this address cannot be configured.</t>
<t>A problem for this mechanism is that it requires modifications in hosts in order to support the Address Registration option.</t>
</section>
<section title="IPv6 Mobility Manager">
<t>According to <xref target="RFC6275"></xref>, a home agent acts as a proxy for mobile nodes when these last ones are away from the home network: the home agent defends an mobile node's home address by replying to NS messages with NA messages.</t>
<t>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 message is only received by the sender of the corresponding NS message, for security and scalability reasons. However, the home agent per <xref target="RFC6275"></xref> multicasts NA messages on the home link and all nodes on this link will receive these NA messages. This shortcoming prevents this mechanism being deployed in DSL or Fiber access networks directly.</t>
</section>
</section>
<section title="Duplicate Address Detection Proxy (DAD-Proxy) specifications">
<section title="DAD-Proxy Data structure">
<t>A BNG needs to store in a Binding Table information related to the 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 Binding Table MUST contain the following fields: <list style="symbols">
<t>IPv6 Address</t>
<t>Link-layer Address</t>
</list></t>
<t>For security or performances reasons, it must be possible to limit the number of IPv6 Addresses per Link-layer Address (possibly, but not necessarily, to 1).</t>
<t>On the reception of an unsolicited NA (e.g., when a CPE wishes to inform its neighbors of a new link-layer address) for an IPv6 address already recorded in the Binding Table, each entry associated to this IPv6 address MUST be updated consequently: the current Link-layer Address is replaced by the one included in the unsolicited NA message.</t>
</section>
<section title="DAD-Proxy mechanism">
<t>When a CPE performs DAD, as specified in <xref target="RFC4862"></xref>, it sends a Neighbor Solicitation (NS) message, with the unspecified address as source address, in order to check if a tentative address is already in use on the link. The BNG receives this message and MUST perform actions depending on the information in the Binding Table.</t>
<section anchor="NoEntry" title="No entry exists for the tentative address">
<t>When there is no entry for the tentative address, the BNG MUST create one with following information: <list style="symbols">
<t>IPv6 Address Field set to the tentative address in the NS message.</t>
<t>Link-layer Address Field set to the Link-layer source address in the Link-layer Header of the NS message.</t>
</list></t>
<t>The BNG MUST NOT reply to the CPE or forward the NS message.</t>
</section>
<section anchor="Entry" title="An entry already exists for the tentative address">
<t>When there is an entry for the tentative address, the BNG MUST check the following conditions: <list style="symbols">
<t>The address in the Target Address Field in the NS message is equal to the address in the IPv6 Address Field in the entry.</t>
<t>The source address of the IPv6 Header in the NS message is equal to the unspecified address.</t>
</list></t>
<t>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 Address Field in the entry, that means the CPE is still performing DAD for this address. The BNG MUST NOT reply to the CPE or forward the NS message.</t>
<t>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 Link-Layer Address Field in the entry, that means possibly another CPE performs DAD for an already owned address. The BNG then has to verify whether there is a real conflict by checking if the CPE whose IPv6 address is in the entry is still connected. In the following, we will call IPv6-CPE1 the IPv6 address of the existing entry in the Binding Table, Link-layer-CPE1 the Link-layer address of that entry and Link-layer-CPE2 the Link-layer address of the CPE which is performing DAD, which is different from Link-layer-CPE1.</t>
<t>The BNG MUST check if the potential address conflict is real. In particular: <list style="symbols">
<t>If IPv6-CPE1 is in the Neighbor Cache and it is associated with Link-layer-CPE1, the reachability of IPv6-CPE1 MUST be confirmed as explained in <xref target="Confirmation"/>.</t>
<t>If IPv6-CPE1 is in the Neighbor Cache, but in this cache it is associated with another Link-layer address than Link-layer-CPE1, 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 of this document, since one assumption made above is that all the nodes of a point-to-multipoint domain (except the DAD proxy itself) perform DAD. This case could be covered in the future by additional solutions that work in conjunction with the DAD proxy.</t>
<t>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 Binding Table. This step is necessary in order to trigger the reachibility check as explained in <xref target="Confirmation"/>. The entry in the Neighbor Cache MUST be created based on the algorithm defined in section 7.3.3 of <xref target="RFC4861"></xref>, in particular by considering the case as if a packet other than a solicited Neighbor Advertisement was received from IPv6-CPE1. That means that the new entry of the Neighbor Cache MUST contain the following information:
<list style="symbols">
<t>IPv6 address: IPv6-CPE1</t>
<t>Link-layer address: Link-layer-CPE1</t>
<t>State: STALE</t>
</list>
Then the reachability of IPv6-CPE1 MUST be confirmed as soon as possible following the procedure explained in section 4.2.3.
</t>
</list></t>
</section>
<section anchor="Confirmation" title="Confirmation of reachability to check the validity of the conflict">
<t>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 Unreachibility Detection) mechanism described in section 7.3.1 of <xref target="RFC4861"></xref>. This mechanism MUST be triggered as if a packet has to be sent to IPv6-CPE1. Note that in some cases this mechanism does not do anything, for instance if the state of the entry is REACHABLE and a positive confirmation was received recently that the forward path to the IPv6-CPE1 was functioning properly (see RFC 4861 for more details).</t>
<t>Next, the behavior of the BNG depends on the result of the NUD process, as explained in the following sections.</t>
<section title="The result of the NUD process is negative">
<t>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 potential conflict is not real.</t>
<t>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, but the Link-layer address of the CPE which is performing DAD (Link-layer-CPE2), as explained in <xref target="NoEntry"/>.</t>
</section>
<section title="The result of the NUD process is positive">
<t>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 potential conflict is real.</t>
<t>As shown in <xref target="Fig_valid_status"></xref>, the BNG MUST reply to CPE that is performing DAD (CPE2 in <xref target="Fig_Architecture"></xref>) with a NA message which has the following format: <list hangIndent="6" style="hanging">
<t hangText="Layer 2 Header Fields:"><list hangIndent="6"
style="hanging">
<t hangText="Source Address"><vspace />
The Link-layer address of the interface on which the BNG received the NS message.</t>
<t hangText="Destination Address"><vspace />
The source address in the Layer 2 Header of the NS message received by the BNG (i.e. Link-layer-CPE2)</t>
</list></t>
<t hangText="IPv6 Header Fields:"><list hangIndent="6"
style="hanging">
<t hangText="Source Address"><vspace />
An address assigned to the interface from which the advertisement is sent.</t>
<t hangText="Destination Address"><vspace />
The all-nodes multicast address.</t>
</list></t>
<t hangText="ICMPv6 Fields:"><list hangIndent="6"
style="hanging">
<t hangText="Target Address"><vspace />
The tentative address already used (i.e. IPv6-CPE1).</t>
<t hangText="Target Link-layer address"><vspace />
The Link-layer address of the interface on which the BNG received the NS message.</t>
</list></t>
</list></t>
<figure anchor="Fig_valid_status">
<artwork xml:space="preserve"><![CDATA[
CPE1 CPE2 BNG
| | |
(a)| | |
| | |
(b)|===================>|
| | |(c)
| | |
| (d)| |
| | |
| (e)|=========>|
| | |
| |<=========|(f)
| | |
(a) CPE1 generated a tentative address
(b) CPE1 performs DAD for this one
(c) BNG updates its Binding Table
(d) CPE2 generates a same tentative address
(e) CPE2 performs DAD for this one
(f) BNG informs CPE2 that DAD fails
]]></artwork>
</figure>
<t>The BNG and the CPE MUST support the Unicast Transmission on Link-layer of IPv6 Multicast Messages <xref target="RFC6085"></xref>, to be able, respectively, to generate and to process such a packet format.</t>
</section>
</section>
</section>
</section>
<section title="IANA Considerations">
<t>No new options or messages are defined in this document.</t>
</section>
<section title="Security Considerations">
<section title="Interoperability with SEND">
<t>If SEcure Neighbor Discovery (SEND) <xref target="RFC3971"></xref> is used, the mechanism specified in this document may break the security. Indeed, if an entry already exists and the BNG has to send a reply (cf. <xref target="Entry"></xref>), the BNG doesn't own the private key(s) associated with to the Cryptographically Generated Addresses (CGA) <xref target="RFC3972"></xref> to correctly sign the proxied ND messages <xref target="RFC5909"></xref>.</t>
<t>To keep the same level of security, Secure Proxy ND Support for SEND <xref target="RFC6496"></xref> SHOULD be used and implemented on the BNG and the CPEs.</t>
</section>
<section title="IP source address spoofing protection">
<t>To ensure a protection against IP source address spoofing in data packets, this proposal MAY be used in combinaison with Source Address Validation Improvement (SAVI) mechanisms <xref target="RFC6620"></xref> <xref target="I-D.ietf-savi-send"></xref> <xref target="I-D.ietf-savi-mix"></xref>.</t>
</section>
</section>
<section title="Acknowledgments">
<t>The authors would like to thank Alan Kavanagh, Wojciech Dec, Suresh Krishnan and Tassos Chatzithomaoglou for their comments. The authors would like also to thank the IETF 6man WG members and the BBF community for their support.</t>
</section>
<!-- Acknowledgments -->
</middle>
<back>
<references title="Normative References">
&RFC2119;
<!-- Neighbor Discovery for IP version 6 (IPv6) -->
&RFC4861;
<!-- IPv6 Stateless Address Autoconfiguration -->
&RFC4862;
<!-- Address Mapping of IPv6 Multicast Packets on Ethernet -->
&RFC6085;
</references>
<references title='Informative References' >
<!-- IP Version 6 over PPP -->
&RFC5072;
<!-- SEcure Neighbor Discovery (SEND) -->
&RFC3971;
<!-- Cryptographically Generated Addresses (CGA) -->
&RFC3972;
<!-- Mobility Support in IPv6 -->
&RFC6275;
<!-- Neighbor Discovery Proxies -->
&RFC4389;
<!-- Securing Neighbor Discovery Proxy: Problem Statement -->
&RFC5909;
<!-- Neighbor Discovery Optimization for Low Power and Lossy Networks (6LoWPAN) -->
&lowpan-nd;
<!-- Secure Proxy ND Support for SEND -->
&RFC6496;
<!-- FCFS SAVI: First-Come First-Serve Source-Address Validation for Locally Assigned IPv6 Addresses -->
&RFC6620;
<!-- SEND-based Source-Address Validation Implementation -->
&savi-send;
<!-- SAVI for Mixed Address Assignment Methods Scenario -->
&savi-mix;
</references>
<!--
<section anchor="Open_Issues_TODO_List" title="Open issues">
<t><list style="symbols">
<t>What happens when the BNG receives a NA message with O-bit set to 1 (e.g. the Link-Layer address of the CPE has changed)?</t>
</list></t>
</section>
-->
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:19:14 |