draft-ietf-6man-dad-proxy-05.txt   draft-ietf-6man-dad-proxy-06.txt 
6man Working Group F. Costa 6man Working Group F. Costa
Internet-Draft J-M. Combes Internet-Draft J-M. Combes, Ed.
Intended status: Standards Track X. Pougnard Intended status: Standards Track X. Pougnard
Expires: March 23, 2013 France Telecom Orange Expires: August 29, 2013 France Telecom Orange
H. Li H. Li
Huawei Technologies Huawei Technologies
September 19, 2012 February 25, 2013
Duplicate Address Detection Proxy Duplicate Address Detection Proxy
draft-ietf-6man-dad-proxy-05 draft-ietf-6man-dad-proxy-06
Abstract Abstract
The document describes a mechanism allowing the use of Duplicate The document describes a proxy based mechanism allowing the use of
Address Detection (DAD) by IPv6 nodes in a point-to-multipoint Duplicate Address Detection (DAD) by IPv6 nodes in a point-to-
architecture with "split-horizon" forwarding scheme. Based on the multipoint architecture with "split-horizon" forwarding scheme,
DAD signalling, the first hop router stores in a Binding Table all primarily deployed for Digital Subscriber Line (DSL) and Fiber access
known IPv6 addresses used on a point-to-multipoint domain (e.g. architectures. Based on the DAD signalling, the first hop router
VLAN). When a node performs DAD for an address already used by stores in a Binding Table all known IPv6 addresses used on a point-
another node, the first hop router replies instead of this last one. 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.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
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 March 23, 2013. This Internet-Draft will expire on August 29, 2013.
Copyright Notice Copyright Notice
Copyright (c) 2012 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 . . . . . . . . . . . . . . . 4 3.1. Duplicate Address Detection . . . . . . . . . . . . . . . 5
3.2. Neighbor Discovery Proxy . . . . . . . . . . . . . . . . . 5 3.2. Neighbor Discovery Proxy . . . . . . . . . . . . . . . . . 5
3.3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . 5 3.3. 6LoWPAN Neighbor Discovery . . . . . . . . . . . . . . . . 5
3.4. IPv6 Mobility Manager . . . . . . . . . . . . . . . . . . 6 3.4. IPv6 Mobility Manager . . . . . . . . . . . . . . . . . . 6
4. Duplicate Address Detection Proxy (DAD-Proxy) 4. Duplicate Address Detection Proxy (DAD-Proxy)
specifications . . . . . . . . . . . . . . . . . . . . . . . . 6 specifications . . . . . . . . . . . . . . . . . . . . . . . . 6
4.1. DAD-Proxy Data structure . . . . . . . . . . . . . . . . . 6 4.1. DAD-Proxy Data structure . . . . . . . . . . . . . . . . . 6
4.2. DAD-Proxy mechanism . . . . . . . . . . . . . . . . . . . 6 4.2. DAD-Proxy mechanism . . . . . . . . . . . . . . . . . . . 7
4.2.1. No entry exists for the tentative address . . . . . . 7 4.2.1. No entry exists for the tentative address . . . . . . 7
4.2.2. An entry already exists for the tentative address . . 7 4.2.2. An entry already exists for the tentative address . . 7
4.2.3. Confirmation of reachability to check the validity 4.2.3. Confirmation of reachability to check the validity
of the conflict . . . . . . . . . . . . . . . . . . . 8 of the conflict . . . . . . . . . . . . . . . . . . . 8
5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10
6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10
6.1. Interoperability with SEND . . . . . . . . . . . . . . . . 10 6.1. Interoperability with SEND . . . . . . . . . . . . . . . . 10
6.2. IP source address spoofing protection . . . . . . . . . . 11 6.2. IP source address spoofing protection . . . . . . . . . . 11
7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11
8.1. Normative References . . . . . . . . . . . . . . . . . . . 11 8.1. Normative References . . . . . . . . . . . . . . . . . . . 11
8.2. Informative References . . . . . . . . . . . . . . . . . . 11 8.2. Informative References . . . . . . . . . . . . . . . . . . 11
Appendix A. DAD Proxy state machine . . . . . . . . . . . . . . . 12 Appendix A. DAD Proxy state machine . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
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. It only to-multipoint domain with "split-horizon" forwarding scheme,
impacts the first hop router and it doesn't need modifications on the primarily deployed for Digital Subscriber Line (DSL) and Fiber access
other IPv6 nodes. This mechanism is fully effective if all the nodes architectures. It only impacts the first hop router and it doesn't
of a point-to-multipoint domain (except the DAD proxy itself) perform need modifications on the other IPv6 nodes. This mechanism is fully
DAD. effective if all the nodes of a point-to-multipoint domain (except
the DAD proxy itself) perform DAD.
This document explains also why DAD mechanism [RFC4862] cannot be This document explains also why DAD mechanism [RFC4862] without a
used in a point-to-multipoint architecture with "split-horizon" proxy cannot be used in a point-to-multipoint architecture with
forwarding scheme (IPv6 over PPP [RFC5072] is not affected). One of "split-horizon" forwarding scheme (IPv6 over PPP [RFC5072] is not
the main reasons is that, because of this forwarding scheme, IPv6 affected). One of the main reasons is that, because of this
nodes on the same point-to-multipoint domain cannot have direct forwarding scheme, IPv6 nodes on the same point-to-multipoint domain
communication: any communication between them must go through the cannot have direct communication: any communication between them must
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 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
skipping to change at page 4, line 49 skipping to change at page 5, line 7
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,2,3
and the BNG are IPv6 nodes, while AN is a L2 bridge providing 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- 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. 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 Detection (DAD) [RFC4862] is performed when an IPv6
IPv6 node verifies the uniqueness of a tentative IPv6 address. This node verifies the uniqueness of a tentative IPv6 address. This node
node sends a Neighbor Solicitation (NS) message with the IP sends a Neighbor Solicitation (NS) message with the IP destination
destination set to the solicited-node multicast address of the set to the solicited-node multicast address of the tentative address.
tentative address. This NS message is multicasted to other nodes on This NS message is multicasted to other nodes on the same link. When
the same link. When the tentative address is already used on the the tentative address is already used on the link by another node,
link by another node, this last one replies with a Neighbor this last one replies with a Neighbor Advertisement (NA) message to
Advertisement (NA) message to inform the first node. So when inform the first node. So when performing DAD, a node expects the NS
performing DAD, a node expects the NS messages to be received by any messages to be received by any node currently using the tentative
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 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 an additional help.
skipping to change at page 5, line 43 skipping to change at page 5, line 49
a 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 the AN would not help a CPE acknowledge implementing ND Proxy on the AN would not help a CPE acknowledge
link-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 [RFC6775] defines an optional modification of DAD for a 6LowPAN.
6LowPAN. When a 6LoWPAN node wants to configure an IPv6 address, it When a 6LoWPAN node wants to configure an IPv6 address, it registers
registers that address with one or more of its default routers using that address with one or more of its default routers using the
the Address Registration option (ARO). If this address is already Address Registration option (ARO). If this address is already owned
owned by another node, the router informs the 6LoWPAN node this by another node, the router informs the 6LoWPAN node this address
address cannot be configured. 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 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 they are away from the home network: the home agent defends an when they are away from the home network: the home agent defends an
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.
skipping to change at page 6, line 26 skipping to change at page 6, line 31
agent per [RFC6275] multicasts NA messages on the home link and all agent per [RFC6275] multicasts NA messages on the home link and all
nodes on this link will receive these NA messages. This shortcoming nodes on this link will receive these NA messages. This shortcoming
prevents this mechanism being deployed in DSL or Fiber access prevents this mechanism being deployed in DSL or Fiber access
networks directly. networks directly.
4. Duplicate Address Detection Proxy (DAD-Proxy) specifications 4. Duplicate Address Detection Proxy (DAD-Proxy) specifications
4.1. DAD-Proxy Data structure 4.1. DAD-Proxy Data structure
A BNG needs to store in a Binding Table information related to the A BNG needs to store in a Binding Table information related to the
IPv6 addresses generated by any CPE. This Binding Table MAY 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
skipping to change at page 7, line 4 skipping to change at page 7, line 11
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
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 depending on the information in the Binding Table. perform actions specified in the following sections based 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 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.
skipping to change at page 10, line 40 skipping to change at page 10, line 44
to generate and to process such a packet format. to generate and to process such a packet format.
5. IANA Considerations 5. IANA Considerations
No new options or messages are defined in this document. No new options or messages are defined in this document.
6. Security Considerations 6. Security Considerations
6.1. Interoperability with SEND 6.1. Interoperability with SEND
If SEcure Neighbor Discovery (SEND) [RFC3971] is used, the mechanism The mechanism described in this document will not interoperate with
specified in this document may break the security. Indeed, if an SEcure Neighbor Discovery (SEND) [RFC3971]. This is due to the BNG
entry already exists and the BNG has to send a reply (cf. not owning the private key associated with the Cryptographically
Section 4.2.2), the BNG doesn't own the private key(s) associated Generated Address (CGA) [RFC3972] needed to correctly sign the
with to the Cryptographically Generated Addresses (CGA) [RFC3972] to proxied ND messages [RFC5909].
correctly sign the proxied ND messages [RFC5909].
To keep the same level of security, Secure Proxy ND Support for SEND Secure Proxy ND Support for SEND [RFC6496] has been specified to
[RFC6496] SHOULD be used and implemented on the BNG and the CPEs. address this limitation, and SHOULD be implemented and used on the
BNG and the CPEs.
6.2. IP source address spoofing protection 6.2. IP source address spoofing protection
To ensure a protection against IP source address spoofing in data To ensure protection against IP source address spoofing in data
packets, this proposal MAY be used in combinaison with Source Address packets, this proposal can be used in combinaison with Source Address
Validation Improvement (SAVI) mechanisms [RFC6620] Validation Improvement (SAVI) mechanisms [RFC6620]
[I-D.ietf-savi-send] [I-D.ietf-savi-mix]. [I-D.ietf-savi-send] [I-D.ietf-savi-mix].
If so, the SAVI device is the BNG and the Binding Anchor for a CPE is
its MAC address, which is assumed to be unique in this document (cf.
Section 1).
7. 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 authors
would like also to thank the IETF 6man WG members and the BBF would like also to thank the IETF 6man WG members and the BBF
community for their support. community for their support.
8. References 8. References
8.1. Normative References 8.1. Normative References
skipping to change at page 11, line 39 skipping to change at page 11, line 47
[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.
8.2. Informative References 8.2. Informative References
[I-D.ietf-6lowpan-nd]
Shelby, Z., Chakrabarti, S., and E. Nordmark, "Neighbor
Discovery Optimization for Low Power and Lossy Networks
(6LoWPAN)", draft-ietf-6lowpan-nd-21 (work in progress),
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-03 (work in progress), November 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-08 (work in progress), draft-ietf-savi-send-08 (work in progress),
September 2012. 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.
skipping to change at page 12, line 37 skipping to change at page 12, line 39
[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.
[RFC6775] Shelby, Z., Chakrabarti, S., Nordmark, E., and C. Bormann,
"Neighbor Discovery Optimization for IPv6 over Low-Power
Wireless Personal Area Networks (6LoWPANs)", RFC 6775,
November 2012.
Appendix A. DAD Proxy state machine Appendix A. DAD Proxy state machine
This appendix contains a summary (cf. Table 1) of the actions done by This appendix, informative, contains a summary (cf. Table 1) of the
the BNG when it receives a DAD based NS (DAD-NS) message. The actions done by the BNG when it receives a DAD based NS (DAD-NS)
tentative address in this message is IPv6-CPE1 and the associated message. The tentative address in this message is IPv6-CPE1 and the
Link-layer address is Link-layer-CPE2. The actions are precisely associated Link-layer address is Link-layer-CPE2. The actions are
specified in Section 4.2. precisely specified in Section 4.2.
+------------+---------------------+-------------------+------------+ +------------+---------------------+-------------------+------------+
| Event | Check | Action | New event | | Event | Check | Action | New event |
+------------+---------------------+-------------------+------------+ +------------+---------------------+-------------------+------------+
| DAD-NS | o No entry for | Create an entry | - | | DAD-NS | o No entry for | Create an entry | - |
| message | IPv6-CPE1 in the | for IPv6-CPE1 | | | message | IPv6-CPE1 in the | for IPv6-CPE1 | |
| reception. | Binding Table. | bound to | | | reception. | Binding Table. | bound to | |
| | | Link-layer-CPE2 | | | | | Link-layer-CPE2 | |
| | | in the Binding | | | | | in the Binding | |
| | | Table. | | | | | Table. | |
skipping to change at page 14, line 16 skipping to change at page 14, line 16
Authors' Addresses Authors' Addresses
Fabio Costa Fabio Costa
France Telecom Orange France Telecom Orange
61 rue des Archives 61 rue des Archives
75141 Paris Cedex 03 75141 Paris Cedex 03
France France
Email: fabio.costa@orange.com Email: fabio.costa@orange.com
Jean-Michel Combes Jean-Michel Combes (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
 End of changes. 24 change blocks. 
68 lines changed or deleted 75 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/