draft-ietf-6man-lineid-06.txt   draft-ietf-6man-lineid-07.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: February 15, 2013 Ericsson Expires: February 16, 2013 Ericsson
S. Ooghe S. Ooghe
Alcatel-Lucent Alcatel-Lucent
E. Nordmark E. Nordmark
Cisco Cisco
August 14, 2012 August 15, 2012
The Line Identification Destination Option The Line Identification Destination Option
draft-ietf-6man-lineid-06 draft-ietf-6man-lineid-07
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 February 15, 2013. This Internet-Draft will expire on February 16, 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 21 skipping to change at page 2, line 21
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Conventions used in this document . . . . . . . . . . . . 5 1.2. Conventions used in this document . . . . . . . . . . . . 5
2. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 6
3. Issues with identifying the subscriber premises in an N:1 3. Issues with identifying the subscriber premises in an N:1
VLAN model . . . . . . . . . . . . . . . . . . . . . . . . . . 7 VLAN model . . . . . . . . . . . . . . . . . . . . . . . . . . 7
4. Basic operation . . . . . . . . . . . . . . . . . . . . . . . 7 4. Basic operation . . . . . . . . . . . . . . . . . . . . . . . 7
5. AN Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. AN Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 8
5.1. On initialization . . . . . . . . . . . . . . . . . . . . 7 5.1. On initialization . . . . . . . . . . . . . . . . . . . . 8
5.2. On receiving a Router Solicitation from the end-device . . 8 5.2. On receiving a Router Solicitation from the end-device . . 8
5.3. On receiving a Router Advertisement from the Edge 5.3. On receiving a Router Advertisement from the Edge
Router . . . . . . . . . . . . . . . . . . . . . . . . . . 8 Router . . . . . . . . . . . . . . . . . . . . . . . . . . 9
5.3.1. Identifying tunneled Router Advertisements . . . . . . 8 5.3.1. Identifying tunneled Router Advertisements . . . . . . 9
5.4. On detecting a subscriber circuit coming up . . . . . . . 8 5.4. On detecting a subscriber circuit coming up . . . . . . . 9
5.5. On detecting Edge Router failure . . . . . . . . . . . . . 9 5.5. On detecting Edge Router failure . . . . . . . . . . . . . 9
5.6. RS Retransmission algorithm . . . . . . . . . . . . . . . 9 5.6. RS Retransmission algorithm . . . . . . . . . . . . . . . 10
6. Edge Router Behavior . . . . . . . . . . . . . . . . . . . . . 9 6. Edge Router Behavior . . . . . . . . . . . . . . . . . . . . . 10
6.1. On receiving a Tunneled Router Solicitation from the AN . 9 6.1. On receiving a Tunneled Router Solicitation from the AN . 10
6.2. On sending a Router Advertisement towards the 6.2. On sending a Router Advertisement towards the
end-device . . . . . . . . . . . . . . . . . . . . . . . . 10 end-device . . . . . . . . . . . . . . . . . . . . . . . . 10
6.3. Sending periodic unsolicited Router Advertisements 6.3. Sending periodic unsolicited Router Advertisements
towards the end-device . . . . . . . . . . . . . . . . . . 10 towards the end-device . . . . . . . . . . . . . . . . . . 11
7. Line Identification Destination Option (LIO) . . . . . . . . . 11 7. Line Identification Destination Option (LIO) . . . . . . . . . 11
7.1. Encoding of Line ID . . . . . . . . . . . . . . . . . . . 12 7.1. Encoding of Line ID . . . . . . . . . . . . . . . . . . . 12
8. Garbage collection of unused prefixes . . . . . . . . . . . . 13 8. Garbage collection of unused prefixes . . . . . . . . . . . . 13
9. Interactions with Secure Neighbor Discovery . . . . . . . . . 13 9. Interactions with Secure Neighbor Discovery . . . . . . . . . 14
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14
11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14
12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14
13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15
13.2. Informative References . . . . . . . . . . . . . . . . . . 15 13.2. Informative References . . . . . . . . . . . . . . . . . . 16
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16
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 traditional for Broadband Access for Next Generation Networks. While traditional
DSL access networks were Point-to-Point Protocol (PPP) [RFC1661] DSL access networks were Point-to-Point Protocol (PPP) [RFC1661]
based, some networks are migrating from the traditional PPP access based, some networks are migrating from the traditional PPP access
model into a pure IP-based Ethernet aggregated access environment. model into a pure IP-based Ethernet aggregated access environment.
Architectural and topological models of an Ethernet aggregation Architectural and topological models of an Ethernet aggregation
skipping to change at page 6, line 22 skipping to change at page 6, line 22
configuration to attach to networks that use the N:1 VLAN deployment configuration to attach to networks that use the N:1 VLAN deployment
model. model.
When the Dynamic Host Configuration Protocol (DHCP) [RFC3315] is used When the Dynamic Host Configuration Protocol (DHCP) [RFC3315] is used
for IPv6 address assignment it has the side-effect of including for IPv6 address assignment it has the side-effect of including
reliability initiated by the end-device (the end-device retransmits reliability initiated by the end-device (the end-device retransmits
DHCP messages until it receives a response), as well as a way to DHCP messages until it receives a response), as well as a way to
detect when the end-device is not active for an extended period of detect when the end-device is not active for an extended period of
time (the end-device would not renew its DHCP lease). The IPv6 time (the end-device would not renew its DHCP lease). The IPv6
Stateless address autoconfiguration protocol [RFC4862] was not Stateless address autoconfiguration protocol [RFC4862] was not
designed to satisfy such requirements. While this option improves designed to satisfy such requirements [RSDA]. While this option
the reliability of operation in deployments that use Router improves the reliability of operation in deployments that use Router
Solicitations rather than DHCP, there are some limitations as Solicitations rather than DHCP, there are some limitations as
specified below. specified below.
The mechanism described in this document deals with the loss of The mechanism described in this document deals with the loss of
subscriber-originated Router Solicitations (RSes) by initiating RSes subscriber-originated Router Solicitations (RSes) by initiating RSes
at the AN, which improves the robustness over solely relying on the at the AN, which improves the robustness over solely relying on the
end-device's few initial retransmissions of RSes. end-device's few initial retransmissions of RSes.
But the AN retransmissions imply that some information (e.g. the But the AN retransmissions imply that some information (e.g. the
subscriber's MAC address) that was obtained by the edge router from subscriber's MAC address) that was obtained by the edge router from
skipping to change at page 6, line 52 skipping to change at page 6, line 52
There is no indication when a subscriber is no longer active. Thus There is no indication when a subscriber is no longer active. Thus
this protocol can not be used to automatically reclaim resources, this protocol can not be used to automatically reclaim resources,
such as prefixes, that are associated with an active subscriber. See such as prefixes, that are associated with an active subscriber. See
Section 8. Thus this protocol is NOT RECOMMENDED for networks that Section 8. Thus this protocol is NOT RECOMMENDED for networks that
require automatic notification when a subscriber is no longer active. require automatic notification when a subscriber is no longer active.
This mechanism by itself provides no protection against the loss of This mechanism by itself provides no protection against the loss of
RS induced state in access routers that would lead to loss of IPv6 RS induced state in access routers that would lead to loss of IPv6
connectivity for end-devices. Given that regular IPv6 hosts do not connectivity for end-devices. Given that regular IPv6 hosts do not
have RS retransmission behavior that would allow automatic recovery have RS retransmission behavior that would allow automatic recovery
from such a failure, this mechanism is considered experimental and from such a failure, this mechanism SHOULD only be used in
SHOULD only be used in deployments employing N:1 VLANs. deployments employing N:1 VLANs.
3. Issues with identifying the subscriber premises in an N:1 VLAN model 3. Issues with identifying the subscriber premises in an N:1 VLAN model
In a DSL or GPON based fixed Broadband Network, IPv6 end-devices are In a DSL or GPON based fixed Broadband Network, IPv6 end-devices are
connected to an AN. These end-devices today will typically send a connected to an AN. These end-devices today will typically send a
Router Solicitation Message to the Edge Router, to which the Edge Router Solicitation Message to the Edge Router, to which the Edge
Router responds with a Router Advertisement message. The Router Router responds with a Router Advertisement message. The Router
Advertisement typically contains a prefix that the end-devices will Advertisement typically contains a prefix that the end-devices will
use to automatically configure an IPv6 Address. Upon sending the use to automatically configure an IPv6 Address. Upon sending the
Router Solicitation message the node connecting the end-device on the Router Solicitation message the node connecting the end-device on the
skipping to change at page 7, line 27 skipping to change at page 7, line 27
based aggregation networks, several subscriber premises may be based aggregation networks, several subscriber premises may be
connected to the same interface of an edge router (e.g. on the same connected to the same interface of an edge router (e.g. on the same
VLAN). However, the edge router requires some information to VLAN). However, the edge router requires some information to
identify the end-device on the circuit. To accomplish this, the AN identify the end-device on the circuit. To accomplish this, the AN
needs to add line identification information to the Router needs to add line identification information to the Router
Solicitation message and forward this to the Edge Router. This is Solicitation message and forward this to the Edge Router. This is
analogous to the case where DHCP is being used, and the line analogous to the case where DHCP is being used, and the line
identification information is inserted by a DHCP relay agent identification information is inserted by a DHCP relay agent
[RFC3315]. This document proposes a method for the edge router to [RFC3315]. This document proposes a method for the edge router to
identify the subscriber premises using the contents of the received identify the subscriber premises using the contents of the received
Router Solicitation messages. Router Solicitation messages. Note that there might be several end-
devices that are located on the same subscriber premises.
4. Basic operation 4. Basic operation
This document uses a mechanism that tunnels Neighbor discovery This document uses a mechanism that tunnels Neighbor discovery
packets inside another IPv6 packet that uses a destination option to packets inside another IPv6 packet that uses a destination option to
convey line identification information. The Neighbor discovery convey line identification information as depicted in Figure 3. The
packets are left unmodified inside the encapsulating IPv6 packet. In Neighbor discovery packets are left unmodified inside the
particular, the Hop Limit field of the Neighbor Discovery (ND) encapsulating IPv6 packet. In particular, the Hop Limit field of the
message is not decremented when the packet is being tunneled. This Neighbor Discovery (ND) message is not decremented when the packet is
is because ND messages whose Hop Limit is not 255 will be discarded being tunneled. This is because ND messages whose Hop Limit is not
by the receiver of such messages, as described in Sections 6.1.1 and 255 will be discarded by the receiver of such messages, as described
6.1.2 of [RFC4861]. in Sections 6.1.1 and 6.1.2 of [RFC4861].
+----+ +----+ +-----------+
|Host| | AN | |Edge Router|
+----+ +----+ +-----------+
| RS | |
|---------->| |
| | |
| |Tunneled RS(LIO)|
| |--------------->|
| | |
| |Tunneled RA(LIO)|
| |<---------------|
| RA | |
|<----------| |
| | |
Figure 3: Basic message flow
5. AN Behavior 5. AN Behavior
5.1. On initialization 5.1. On initialization
On initialization, the AN MUST join the All-BBF-Access-Nodes On initialization, the AN MUST join the All-BBF-Access-Nodes
multicast group on all its upstream interfaces towards the Edge multicast group on all its upstream interfaces towards the Edge
Router. Router.
5.2. On receiving a Router Solicitation from the end-device 5.2. On receiving a Router Solicitation from the end-device
skipping to change at page 10, line 45 skipping to change at page 11, line 22
Neighbour Discovery procedures. Neighbour Discovery procedures.
If the Source Address field of the received IPv6 datagram was the If the Source Address field of the received IPv6 datagram was the
unspecified address, the destination address of the outer IPv6 unspecified address, the destination address of the outer IPv6
datagram MUST be set to the well-known link-local scope All-BBF- datagram MUST be set to the well-known link-local scope All-BBF-
Access-Nodes multicast address [to be allocated]. The link-layer Access-Nodes multicast address [to be allocated]. The link-layer
destination address of the tunneled RA MUST be set to the unicast destination address of the tunneled RA MUST be set to the unicast
link-layer address of the AN that sent the tunneled Router link-layer address of the AN that sent the tunneled Router
Solicitation which is being responded to. Solicitation which is being responded to.
The edge router MUST ensure that it does not transmit tunneled RAs
whose size is larger than the MTU of the link between the edge router
and the AN. i.e. The outer IPv6 datagram would require
fragmentation. This is required because the AN may not be capable of
handling the reassembly of such fragmented datagrams.
6.3. Sending periodic unsolicited Router Advertisements towards the 6.3. Sending periodic unsolicited Router Advertisements towards the
end-device end-device
After sending a tunneled Router Advertisement as specified in After sending a tunneled Router Advertisement as specified in
Section 6.2 in response to a received RS, the edge router MUST store Section 6.2 in response to a received RS, the edge router MUST store
the mapping between the LIO and the prefixes contained in the Router the mapping between the LIO and the prefixes contained in the Router
Advertisement. It should then initiate periodic sending of Advertisement. It should then initiate periodic sending of
unsolicited Router Advertisements as described in Section 6.2.3. of unsolicited Router Advertisements as described in Section 6.2.3. of
[RFC4861] . The Router Advertisements MUST be created and tunneled [RFC4861] . The Router Advertisements MUST be created and tunneled
as described in Section 6.2. The edge router MAY stop sending Router as described in Section 6.2. The edge router MAY stop sending Router
Advertisements if it receives a notification from the AN that the Advertisements if it receives a notification from the AN that the
subscriber circuit has gone down. This notification can be received subscriber circuit has gone down. This notification can be received
out-of-band using a mechanism such as ANCP. Please consult Section 8 out-of-band using a mechanism such as ANCP. Please consult Section 8
for more details. for more details.
7. Line Identification Destination Option (LIO) 7. Line Identification Destination Option (LIO)
The Line Identification Destination Option (LIO) is a destination The Line Identification Destination Option (LIO) is a destination
skipping to change at page 11, line 30 skipping to change at page 12, line 14
requirement. requirement.
0 1 2 3 0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Option Type | Option Length | | Option Type | Option Length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LineIDLen | Line Identification... | LineIDLen | Line Identification...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: Line Identification Destination Option Layout Figure 4: Line Identification Destination Option Layout
Option Type Option Type
8-bit identifier of the type of option. The option identifier 8-bit identifier of the type of option. The option identifier
for the line identification option will be allocated by the IANA. for the line identification option will be allocated by the IANA.
Option Length Option Length
8-bit unsigned integer. The length of the option (excluding 8-bit unsigned integer. The length of the option (excluding
the Option Type and Option Length fields). The value MUST be the Option Type and Option Length fields). The value MUST be
skipping to change at page 14, line 4 skipping to change at page 14, line 18
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, Bob Hinden, Ran Atkinson, Hemant Singh, Jari Arkko, Joel Halpern, Bob Hinden, Ran Atkinson,
Glen Turner, Kathleen Moriarty, David Sinicrope, Dan Harkins, Stephen Glen Turner, Kathleen Moriarty, David Sinicrope, Dan Harkins, Stephen
Farrell, Barry Leiba, Sean Turner and Ralph Droms for reviewing this Farrell, Barry Leiba, Sean Turner, Ralph Droms, and Mohammed
document and suggesting changes. Boucadair for reviewing this document and suggesting changes.
11. Security Considerations 11. Security Considerations
The line identification information inserted by the AN or the edge The line identification information inserted by the AN or the edge
router is not protected. This means that this option may be 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 AN and the edge router needs to be trusted. network between the AN and the edge router needs to be trusted.
12. IANA Considerations 12. IANA Considerations
skipping to change at page 16, line 5 skipping to change at page 16, line 20
[RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, March 1997. Extensions", RFC 2132, March 1997.
[RFC3046] Patrick, M., "DHCP Relay Agent Information Option", [RFC3046] Patrick, M., "DHCP Relay Agent Information Option",
RFC 3046, January 2001. RFC 3046, January 2001.
[RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6
(DHCPv6) Relay Agent Remote-ID Option", RFC 4649, (DHCPv6) Relay Agent Remote-ID Option", RFC 4649,
August 2006. August 2006.
[RSDA] Dec, W., "IPv6 Router Solicitation Driven Access
Considered Harmful", draft-dec-6man-rs-access-harmful-00
(work in progress), June 2011.
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. 19 change blocks. 
34 lines changed or deleted 61 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/