draft-ietf-6man-lineid-02.txt   draft-ietf-6man-lineid-03.txt 
6man Working Group S. Krishnan 6man Working Group S. Krishnan
Internet-Draft A. Kavanagh Internet-Draft A. Kavanagh
Intended status: Standards Track B. Varga Intended status: Standards Track B. Varga
Expires: May 3, 2012 Ericsson Expires: September 3, 2012 Ericsson
S. Ooghe S. Ooghe
Alcatel-Lucent Alcatel-Lucent
E. Nordmark E. Nordmark
Cisco Cisco
October 31, 2011 March 2, 2012
The Line Identification Destination Option The Line Identification Destination Option
draft-ietf-6man-lineid-02 draft-ietf-6man-lineid-03
Abstract Abstract
In Ethernet based aggregation networks, several subscriber premises In Ethernet based aggregation networks, several subscriber premises
may be logically connected to the same interface of an edge router. may be logically connected to the same interface of an edge router.
This document proposes a method for the edge router to identify the This document proposes a method for the edge router to identify the
subscriber premises using the contents of the received Router subscriber premises using the contents of the received Router
Solicitation messages. The applicability is limited to broadband Solicitation messages. The applicability is limited to broadband
network deployment scenarios where multiple user ports are mapped to network deployment scenarios where multiple user ports are mapped to
the same virtual interface on the Edge Router. the same virtual interface on the Edge Router.
skipping to change at page 1, line 41 skipping to change at page 1, line 41
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 May 3, 2012. This Internet-Draft will expire on September 3, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 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
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
skipping to change at page 2, line 36 skipping to change at page 2, line 36
5.4. On detecting Edge Router failure . . . . . . . . . . . . . 8 5.4. On detecting Edge Router failure . . . . . . . . . . . . . 8
5.5. RS Retransmission algorithm . . . . . . . . . . . . . . . 9 5.5. RS Retransmission algorithm . . . . . . . . . . . . . . . 9
6. Edge Router Behavior . . . . . . . . . . . . . . . . . . . . . 9 6. Edge Router Behavior . . . . . . . . . . . . . . . . . . . . . 9
6.1. On receiving a Tunneled Router Solicitation from the 6.1. On receiving a Tunneled Router Solicitation from the
Access Node . . . . . . . . . . . . . . . . . . . . . . . 9 Access Node . . . . . . . . . . . . . . . . . . . . . . . 9
6.2. On sending a Router Advertisement towards the 6.2. On sending a Router Advertisement towards the
end-device . . . . . . . . . . . . . . . . . . . . . . . . 9 end-device . . . . . . . . . . . . . . . . . . . . . . . . 9
6.3. Sending periodic unsolicited Router Advertisements 6.3. Sending periodic unsolicited Router Advertisements
towards the end-device . . . . . . . . . . . . . . . . . . 10 towards the end-device . . . . . . . . . . . . . . . . . . 10
7. Line Identification Destination Option (LIO) . . . . . . . . . 10 7. Line Identification Destination Option (LIO) . . . . . . . . . 10
8. Garbage collection of unused prefixes . . . . . . . . . . . . 11 7.1. Encoding of Line ID . . . . . . . . . . . . . . . . . . . 11
9. Interactions with Secure Neighbor Discovery . . . . . . . . . 11 8. Garbage collection of unused prefixes . . . . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 9. Interactions with Secure Neighbor Discovery . . . . . . . . . 12
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13
13. Normative References . . . . . . . . . . . . . . . . . . . . . 12 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13
13.2. Informative References . . . . . . . . . . . . . . . . . . 14
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14
1. Introduction 1. Introduction
Digital Subscriber Line (DSL) is a widely deployed access technology Digital Subscriber Line (DSL) is a widely deployed access technology
for Broadband Access for Next Generation Networks. While for Broadband Access for Next Generation Networks. While
traditionally DSL access networks were Point-to-Point Protocol (PPP) traditionally DSL access networks were Point-to-Point Protocol (PPP)
[RFC1661] based some networks are migrating from the traditional PPP [RFC1661] based some networks are migrating from the traditional PPP
access model into a pure IP-based Ethernet aggregated access access model into a pure IP-based Ethernet aggregated access
environment. Architectural and topological models of an Ethernet environment. Architectural and topological models of an Ethernet
aggregation network in context of DSL aggregation are described in aggregation network in context of DSL aggregation are described in
skipping to change at page 11, line 25 skipping to change at page 11, line 25
LineIDLen LineIDLen
Length of the Line Identification field in number of octets. Length of the Line Identification field in number of octets.
Line Identification Line Identification
Variable length data inserted by the Access Node describing the Variable length data inserted by the Access Node describing the
subscriber agent circuit identifier corresponding to the logical subscriber agent circuit identifier corresponding to the logical
access loop port of the Access Node from which the RS was access loop port of the Access Node from which the RS was
initiated. initiated. The line idenfication should be encoded as specified
in Section 7.1.
7.1. Encoding of Line ID
This IPv6 Destination Option is derived from an existing widely
deployed DHCPv6 Option [RFC4649], which is in turn derived from a
widely deployed DHCPv4 Option [RFC3046]. Both of those derive from
and cite the basic DHCP options specification [RFC2132]. Those
widely deployed DHCP options use the NVT character set
[RFC2132][RFC0020]
The IPv6 Line ID option contains a description which identifies the
line, using only character positions (decimal 32 to decimal 126,
inclusive) of the US-ASCII character set [X3.4], [RFC0020].
Consistent with [RFC2132], [RFC3046] and [RFC4649], the Line ID field
SHOULD NOT contain the US-ASCII NUL character (decimal 0). However,
implementations receiving this option MUST NOT fail merely because an
ASCII NUL character is (erroneously) present in the Line ID option's
data field.
Some existing widely deployed implementations of edge routers and
access nodes that support the previously mentioned DHCP option only
support US-ASCII, and strip the high-order bit from any 8-bit
characters entered by the device operator. The previously mentioned
DHCP options do not support 8-bit character sets either. Therefore,
for compatibility with the installed base and to maximise
interoperability, the high-order bit of each octet in this field MUST
be set to zero by any device inserting this option in an IPv6 packet.
Consistent with [RFC3046] and [RFC4649], this option always uses
binary comparison. Therefore, two Line IDs MUST be equal when they
match when compared byte-by-byte. Line-ID A and Line-ID B match
byte-by-byte when (1) A and B have the same number of bytes and (2)
for all byte indexes P in A: the value of A at index P has the same
binary value as the value of B at index P.
Two Line IDs SHOULD NOT be equal if they do not match byte-by-byte.
For example, an IPv6 Line ID option containing "f123" is not equal to
a Line ID option "F123".
Intermediate systems SHOULD NOT examine the contents of the Line ID.
Intermediate systems SHOULD NOT alter the contents of the Line ID.
8. Garbage collection of unused prefixes 8. Garbage collection of unused prefixes
Following the mechanism described in this document, the Broadband Following the mechanism described in this document, the Broadband
network associates a prefix to a subscriber line based on the LIO. network associates a prefix to a subscriber line based on the LIO.
Even when the subscriber line goes down temporarily, this prefix Even when the subscriber line goes down temporarily, this prefix
stays allocated to that specific subscriber line. i.e. The prefix is stays allocated to that specific subscriber line. i.e. The prefix is
not returned to the unused pool. When a subscriber line no longer not returned to the unused pool. When a subscriber line no longer
needs a prefix, the prefix can be reclaimed by manual action needs a prefix, the prefix can be reclaimed by manual action
dissociating the prefix from the LIO in the backend systems. dissociating the prefix from the LIO in the backend systems.
skipping to change at page 11, line 48 skipping to change at page 12, line 42
Since the SEND [RFC3971] protected RS/RA packets are not modified in Since the SEND [RFC3971] protected RS/RA packets are not modified in
anyway by the mechanism described in this document, there are no anyway by the mechanism described in this document, there are no
issues with SEND verification. issues with SEND verification.
10. Acknowledgements 10. Acknowledgements
The authors would like to thank Margaret Wasserman, Mark Townsley, The authors would like to thank Margaret Wasserman, Mark Townsley,
David Miles, John Kaippallimalil, Eric Levy-Abegnoli, Thomas Narten, David Miles, John Kaippallimalil, Eric Levy-Abegnoli, Thomas Narten,
Olaf Bonness, Thomas Haag, Wojciech Dec, Brian Haberman, Ole Troan, Olaf Bonness, Thomas Haag, Wojciech Dec, Brian Haberman, Ole Troan,
Hemant Singh, Jari Arkko, Joel Halpern and Bob Hinden for reviewing Hemant Singh, Jari Arkko, Joel Halpern, Bob Hinden, Ran Atkinson and
this document and suggesting changes. Glen Turner for reviewing this document and suggesting changes.
11. Security Considerations 11. Security Considerations
The line identification information inserted by the access node or The line identification information inserted by the access node or
the edge router is not protected. This means that this option may be the edge router is not protected. This means that this option may be
modified, inserted, or deleted without being detected. In order to modified, inserted, or deleted without being detected. In order to
ensure validity of the contents of the line identification field, the ensure validity of the contents of the line identification field, the
network between the access node and the edge router needs to be network between the access node and the edge router needs to be
trusted. trusted.
skipping to change at page 12, line 37 skipping to change at page 13, line 32
This document also requires the allocation of a well-known link-local This document also requires the allocation of a well-known link-local
scope multicast address from the IPv6 Multicast Address Space scope multicast address from the IPv6 Multicast Address Space
Registry located at Registry located at
http://www.iana.org/assignments/ipv6-multicast-addresses/ http://www.iana.org/assignments/ipv6-multicast-addresses/
ipv6-multicast-addresses.xml ipv6-multicast-addresses.xml
<TBA2> All BBF Access Nodes [RFCXXXX] <TBA2> All BBF Access Nodes [RFCXXXX]
13. Normative References 13. References
13.1. Normative References
[RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51,
RFC 1661, July 1994. RFC 1661, July 1994.
[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.
[RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in
IPv6 Specification", RFC 2473, December 1998. IPv6 Specification", RFC 2473, December 1998.
skipping to change at page 13, line 30 skipping to change at page 14, line 26
www.broadband-forum.org/technical/download/ www.broadband-forum.org/technical/download/
TR-124_Issue-2.pdf>. TR-124_Issue-2.pdf>.
[TR156] Broadband Forum, "Using GPON Access in the context of TR- [TR156] Broadband Forum, "Using GPON Access in the context of TR-
101", <http://www.broadband-forum.org/technical/download/ 101", <http://www.broadband-forum.org/technical/download/
TR-156.pdf>. TR-156.pdf>.
[TR177] Broadband Forum, "IPv6 in the context of TR-101", [TR177] Broadband Forum, "IPv6 in the context of TR-101",
<www.broadband-forum.org/technical/download/TR-177.pdf>. <www.broadband-forum.org/technical/download/TR-177.pdf>.
[X3.4] American National Standards Institute, "American Standard
Code for Information Interchange (ASCII)", Standard X3.4 ,
1968.
13.2. Informative References
[RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20,
October 1969.
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
August 2006.
Authors' Addresses Authors' Addresses
Suresh Krishnan Suresh Krishnan
Ericsson Ericsson
8400 Blvd Decarie 8400 Blvd Decarie
Town of Mount Royal, Quebec Town of Mount Royal, Quebec
Canada Canada
Email: suresh.krishnan@ericsson.com Email: suresh.krishnan@ericsson.com
 End of changes. 11 change blocks. 
15 lines changed or deleted 81 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/