Network Working Group W. Dec Internet-Draft Cisco Systems Intended status: Informational June 20, 2011 Expires: December 22, 2011 IPv6 Router Solicitation Driven Access Considered Harmful draft-dec-6man-rs-access-harmful-00 Abstract This document presents issues regarding the reliance of IPv6 Router Solicitation messages for creating or initializing router state necessary to enable IPv6 users' connectivity, particularly in situations where such users have bridged ethernet connectivity with the router. A number of alternative solution approaches are also presented and discussed. Requirements Language 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 RFC 2119 [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on December 22, 2011. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Dec Expires December 22, 2011 [Page 1] Internet-Draft rs-access-considered-harmful June 2011 (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem Overview . . . . . . . . . . . . . . . . . . . . . . . 4 2.1. RS Sending Proxy . . . . . . . . . . . . . . . . . . . . . 6 3. Discussion of possible solutions . . . . . . . . . . . . . . . 8 3.1. Modifying RFC4861 . . . . . . . . . . . . . . . . . . . . 9 3.2. Modifying RS-proxy and router behaviour . . . . . . . . . 9 3.3. Ethernet Connectivity Fault Monitoring . . . . . . . . . . 10 3.4. Access-Node based DHCPv6 Proxy Client . . . . . . . . . . 10 3.5. DHCPv6 client on end hosts . . . . . . . . . . . . . . . . 11 3.6. ANCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 3.7. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 12 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 7. Contributors and Acknowledgements . . . . . . . . . . . . . . 13 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 Dec Expires December 22, 2011 [Page 2] Internet-Draft rs-access-considered-harmful June 2011 1. Introduction Recent proposals for including subscriber line identifiers alongside host sourced Router Solicitation (RS) messages ([I-D.ietf-6man-lineid]) in an environment where the host has no direct link layer adjacency with the router (eg when using Ethernet bridging), have highlighted the intent of using these RS messages on the receiving router as a trigger for specific functions & processes. Without the execution of these processes, such as host or line authorization, the host will not receive Router Advertisements (RAs) that allow the establishment of full IPv6 connectivity. Similar RS triggered processes, although without line identifiers, are proposed in specifications concerning WiFi access and appear to share the same pitfalls. In analyzing the impact of these proposals it is useful to refer to the basics of the IPv6 Neighbour Discovery protocol as defined in [RFC4861], which defines the Router Solicitation (RS) message type. This message is intended to be used by hosts to request routers to generate Router Advertisements sooner than at their next scheduled time. The Router Solicitation mechanism is intended to be used in a very specific set of cases, or not at all, and a regular IPv6 network can work fully without any RS message ever being sent. In general, as per Section 6.3.7 of [RFC4861], Router Solicitations may be sent by a host after any of the following events: o The interface is initialized at system startup time. o The interface is reinitialized after a temporary interface failure or after being temporarily disabled by system management. o The system changes from being a router to being a host, by having its IP forwarding capability turned off by system management. o The host attaches to a link for the first time. o The host re-attaches to a link after being detached for some time. Notably in the above a host is at no stage required to periodically send RS messages, nor to send RS messages after a period of not receiving any RAs. Furthermore [RFC4861] states that once a host "receives a valid Router Advertisement with a non-zero Router Lifetime, the host MUST desist from sending additional solicitations on that interface, until the next time one of the above events occurs." This effectively signifies that following the reception of any given RA message, sent by any device, a host will not issue RS messages until it is Dec Expires December 22, 2011 [Page 3] Internet-Draft rs-access-considered-harmful June 2011 reattached or re-initialized. The following text from [RFC4861] also illustrates another aspect relating to the rule governing a host's ceasing of RS sending. "If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY seconds after sending the last solicitation, the host concludes that there are no routers on the link" Experimental evidence conducted on a number of IPv6 implementations confirms that the above behaviour is indeed currently the norm, with specific implementations differing in terms of the default timers (eg MAX_RTR_SOLICITATION_DELAY) used. One implementation has been found to send RS messages at evenly spaced 4 second intervals for up to 12 seconds after the link event. Another implementation has been found to exponentially increase the sending interval for successive messages and stopping RS sending after 90 seconds. The RS sending mechanism was thus clearly not designed nor is implemented to be periodic, nor reliable, nor expected to be sent by a host that has timed out or received an RA. Any mechanism that presupposes any of these RS sending characteristics, or requires them to work reliably, requires a thorough review. 2. Problem Overview The main intent of the [I-D.ietf-6man-lineid] proposal is to convey from an Ethernet bridging Access-Node to an upstream IPv6 router, the subscriber-line-id information indicating the origin of downstream host sourced RS messages. All this is envisaged to be done by tunneling such RS messages using IPinIP tunneling between the Access- Node and the Router, with the access node inserting the subscriber- line-id for each tunnelled RS. The reception by the router of such RS messages with the subscriber-line-id is expected to be the trigger for authorizing and allowing the subscriber's connectivity to the network. It is crucial to note that only after successful authorization will the router send RA messages that contain IPv6 Prefix Information Option (PIO) that allow the host to configure a global IPv6 address. A direct example of this usage goal can be found in Section 6.5 and Appendix A of [TR-177]. In generic terms, the principle of such mechanism is shown in Figure 1, and the goal is to create a dynamic user driven IPv6 access system that is in conductive to: Dec Expires December 22, 2011 [Page 4] Internet-Draft rs-access-considered-harmful June 2011 a. Triggering by means of subscriber sourced ND (RS) messages, processes on the IP edge router which serve to provide and setup hosts/subscribers with IPv6 connectivity. b. Deriving from the received messages host identifiers and/or information regarding where the host is connected to in the Layer 2 network (eg based on MAC address and/or subscriber line id) and using that information in performing access and/or address authorization prior to granting connectivity. c. Being used in an environment where the host/subscriber has no directly link layer adjacency with the router, but rather indirect connectivity (eg via a bridged Ethernet RG/CPE, and/or a bridging DSLAM). d. Being used in an environment where IPv6 hosts implement *only* [RFC4861] as the control protocol, and without any further host changes or client protocols (eg DHCPv6) AAA Host Bridge Router (Optional) : : : : : RS : : : :--------------->: RS : : : :(L-id optional) : AAA Req : : :---------------->: (L-id,etc) : : : : .............>: : : : : : : : AAA Resp. : : : RA : (Prefix) : : : (PIO, L-id) :<............. : : RA :<----------------: : : (PIO, etc) : : : :<---------------: . : : : : . : : : : . : : : : Periodic : : : Periodic : RAs : : : RAs :<----------------: : :<---------------: : : A number of deployment contexts that seek to realize such a system will result in the end user having no IPv6 connectivity, and being left without any automated means of recovery it, all very detrimental to the success of the IPv6 deployment. Dec Expires December 22, 2011 [Page 5] Internet-Draft rs-access-considered-harmful June 2011 One such deployment context is the residential broadband N:1 VLAN environment, as described by [I-D.ietf-6man-lineid]. This features hosts indirectly connected to the edge router over a bridged Layer 2 VLAN set-up (aka an N:1 VLAN). End subscriber hosts connect to Ethernet bridging devices, such as an RG/modem and an Access-Node/ DSLAM, which provide indirect link connectivity for the host with the router. From each end hosts perspective, its local LAN link state is as presented by the RG/modem's LAN interface, eg Ethernet or WiFi. This state is decoupled from the RG/modem's uplink interface state, or that of the DSLAM links, or that of the IP edge router interface(s). Hence, each host's interface is expected to be "up" even when no DSL WAN link synchronisation has been established, or when the WAN link is being established following a modem reboot (an event lasting 2 minutes or more is not uncommon), etc. Given this, and in consideration of the RS sending characteristics described in Section 1 , it is near certain that following a bridge/modem reload, or a DSLAM reload, any and all RS messages sent by hosts will never arrive at the intended IP edge router within the time hosts send RS messages. Since the reception of such RS messages by the edge router is required to trigger the announcement of RAs containing the chosen user address prefix option (PIO) towards the hosts, the host will be left without any addressing information and thus no IPv6 connectivity. The only recourse a user has is manual intervention on the host's interface. Note: The example of DSL is used above, but the case applies to other media, eg cable modems, that exhibit similar "modem reload" events. Moreover, the same problem appears to apply to each deployment that seeks to realize the mentioned goals and features hosts that have no direct link layer adjacency with a router, eg IEEE 802.11 WiFi architectures. It's significant to note that the [I-D.ietf-6man-lineid] mechanism implicitly assumes behaviour which by itself will result in the system failing non-deterministically. As expemplieifed by its usage described in [TR-177], "empty RAs" (ie Router-Advertisement messages that contain no addressing/prefix information) are to be multicast to all subscribers and hosts from the router, in parallel to any specific RAs containing prefix information and the line option. Again, following the cited rules of [RFC4861], should a subscriber host receive such an empty RA prior to issuing an RS, that host will never send an RS and thus never trigger the authorization process necessary to get global IPv6 addressing & connectivity. 2.1. RS Sending Proxy An update to the [I-D.ietf-6man-lineid] draft proposal has somewhat recognized the critical flaw described in Section 2. It also Dec Expires December 22, 2011 [Page 6] Internet-Draft rs-access-considered-harmful June 2011 attempted a remedy in the form of introducing an Access-Node feature, as described in Section 5.3 of [I-D.ietf-6man-lineid]. This feature, consists in the Access Node issuing RS messages towards the Router driven by subscriber link activation (and only activation) state (ie when the link is "brought up"). The term "proxy-RS sender" rather aptly describes the feature, as denoted in Figure 2 below. Bridge AAA Device (Proxy-RS Sender) Router (Optional) : : : : : Link UP : : : : ***Event*** : RS : : : :(L-id optional) : AAA Req : : :---------------->: (L-id,etc) : : : : .............>: : : : : : : : AAA Resp. : : : RA : (Prefix) : : : (PIO, L-id) :<............. : : RA :<----------------: : : (PIO, etc) : : : :<---------------: . : : : : . : : : : . : : : : Periodic : : : Periodic : RAs : : : RAs :<----------------: : :<---------------: : : [I-D.ietf-6man-lineid] indicates that a finite number of RS messages are to be sent and that sending should stop after the Access Node receives an RA with a matching subscriber line information option back from the edge router. This remedy, in the context of the overall solution, is not only insufficient, but introduces further problems, consisting of: 1. Unreliability of RS messaging: There is no assurance that the RS messages sent by the proxy will reach the edge router. Eg it is not uncommon for spanning tree protocol events take place on the Ethernet segments, or other similar events, which result in loss of connectivity with the edge router ranging from a couple of seconds to a couple of minutes - this is often the case during access-node activation. Any RS messages sent by the RS-proxy, on behalf of bridged subscribers connected to this access node, would be lost and all the relevant subscribers left without IPv6 connectivity. Dec Expires December 22, 2011 [Page 7] Internet-Draft rs-access-considered-harmful June 2011 2. Lack of subscriber host identifiers: In many of today's broadband deployments end host identifiers are required for the purpose of authorization besides intermediate identifiers such as subscriber line-id. For example, it is quite common to identify and authorize devices like WiFi smart phones or TV set-top-boxes by their unique MAC address. With the RS-proxy mechanism, these identifiers are not be available, and effectively do not meet goal b) of the system 3. No ability to clean up state/recover: Each "active" subscriber link is intended to induce IPv6 subscriber state in the router. Short of manual intervention by the operator there is no mechanism on the router to remove such state should a link ever become "inactive". In other words, there is no equivalent of a "link down" message, nor does the ND protocol provide for such extensibility, and the router and operator are likely to be burdened with a large amount of stale state, besides inefficient use of resources. 4. In ability to recover from node failures: Given that an RS-proxy eventually stops sending RSes, should the edge router loose for any reason any or all of the RS induced state, including the route to the subscriber, the system will fall into a state of unrecoverable connectivity loss for end users, even as they continue to have a valid IPv6 address. Basically, a host that received a previous RA from an Edge Router will following rfc4862 NOT send an further RS messages, while a router without the necessary state will NOT forward traffic to the subscriber. Similarly, neither will the RS-proxy send RS messages as long as the line is still "active". Given the above issues, while the introduction of the RS-sending- proxy was intended to fix a critical flaw with the original proposal, if not only left the issue in place, but it introduced further issues undermining its overall purpose and compromising the usability and scalability of the system. 3. Discussion of possible solutions Its readily apparent that any solution based on proxy functionality that is driven by link state changes cannot meet all of the system goals as presented in Section 2 (eg goals a, b and c), while satisfying the constraint of no changes to end hosts (goal e) and within the context of a bridged/indirect-link host-router set-up (goal d). At best compromises to the goals or combinations of solutions need to be adopted. The solutions below indicate such compromises: Dec Expires December 22, 2011 [Page 8] Internet-Draft rs-access-considered-harmful June 2011 3.1. Modifying RFC4861 One possible, solution, that would solve a handful of issues, would be to modify [RFC4861] in such a way as to give the protocol a semblance of reliability and persistence. For example, it could be stipulated that host RS sending behaviour needs to be periodic and continue irrespective of RA messages being received. Router behaviour would need to be modified to detect periods of RS inactivity. All this would be a substantial change to the original protocol specification, and would naturally require changes to any existing IPv6 ND implementations to be useful, falling short of goal e). Besides this, it would also significantly increase the RS processing load on any router. 3.2. Modifying RS-proxy and router behaviour Modifying the RS-proxy mechanism to issue periodic RS messages driven subscriber link state, or doing so whenever no RA is received for a given subscriber line over a certain period of time could be seen as a possible solution to some, but not all, of the problems identified. In essence this modification transforms RS/RA messaging into link- state notification messages. Unfortunately it also introduces several other flaws, besides not meeting the Section 2 goals a), b) and possibly c): o Unknown timers: For the mechanism to function, the behaviour of both the RS-proxy and the edge router need to be modified in terms of RS processing and RA sending, around a timer driven state machine, where both the Access-Node and Router share the timers. Defining for this purpose a new timer negotiation protocol appears a major ND or IPinIP protocol change, while relying on "well known" timers (ie hard set) is highly inflexibility not conductive to automated, reliable and inter operable deployments. o Increased load on AAA system: Following the intent of the system, for each RS message for which no authorization state exists on the edge router, authorization from an AAA server is to be requested. With RS messages being periodic, this will place additional burden on any AAA infrastructure, besides being analogous to issuing AAA requests for each link keepalive received. o Subscriber management: One of the main premises of an architecture that features a Layer 2 Access Node and an upstream aggregating IP Edge Router is the notion of subscriber management on the IP Edge Router. Operators deploying this architecture seek to use the IP Edge Router as the node on which subscriber related configuration and control is applied - hence the desire to perform dynamic subscriber authorization at/by the router. Introducing into this Dec Expires December 22, 2011 [Page 9] Internet-Draft rs-access-considered-harmful June 2011 architecture a mechanism where periodic RS messages sent by a proxy could lead to similarly periodic denial of authorizations at the edge router, eg for subscriber lines that are not authorized to use the service, with the only way of disabling such RS sending is by maintaining on the Access-Node subscriber configuration information, is counter to the premise of the architecture itself. o ND customization: One of the design goals for using the IPinIP tunneling mechanism was to avoid changes to the ND protocol or implementations. Unfortunately, the processing of custom tunneled RS messages as well as generation of custom tunneled RA messages, in effect requires a highly customized ND implementation, the likes of which diverges from typically ND implementations. Given the above, modifying the RS-proxy mechanism to be periodic would not only require a fairly major extension to the proposal, including the definition of timers covering message sending periodicity discovery and/or negotiation, but also result in more issues to the overall system. Above all, such a modification would in the end only mimic a link-state signalling/keepalive protocol, without actually resolving all of the identified problems, and without actually being one. 3.3. Ethernet Connectivity Fault Monitoring A core issue in the a system driven by host sourced RS, is the end hosts inability to detect when an indirect link has failed, translating into the hosts inability to re-send RS messages. On links such as PPP, which offer link state keepalives, the issue does not come up, but neither does the need of driving router authorization events via RS messages due to the link layer negotiation stage of PPP. Over Ethernet, a link state keepalive mechanisms could fill in part of that gap. The closest equivalent can be found in Ethernet Connectivity Fault Monitoring that is a component of the IEEE 802.1ag Ethernet OAM specification [802.1ag]. The implementation of such extensions on hosts and routers would allow the regular [RFC4861] RA sending rules to respond appropriately to connectivity or device failures. Unfortunately, there is no known end host implementation of 802.1ag today, which translates that this solution does not meet goal e) (no end host modifications). Nevertheless, it appears like a valid approach, whose realization however does not appear to be within the IETF's specification direct sphere of influence. 3.4. Access-Node based DHCPv6 Proxy Client An alternative solution to some of the problems identified in relation to periodic RA sending, would be to define an RS/ Dec Expires December 22, 2011 [Page 10] Internet-Draft rs-access-considered-harmful June 2011 RA-DHCPv6-proxy function, whose role would be to transform host sourced RS messages into DHCPv6 Solicit/etc messages towards the edge router. The access-node would thus be a multi DUID DHCPv6 client as seen by the rest of the operator's network. Regular mechanisms of DHCPv6 relaying by the edge router and prefix delegation would be used to assign /64 prefixes for each subscriber line. The RS/ RA-DHCPv6 proxy would also be responsible for announcing the DHCPv6 derived prefixes in regular RA messages to downstream hosts. An additional bonus of this solution is the fact that the existing DHCPv6 specification allows for the subscriber line-id to be included in the DHCPv6 messages [RFC3315], [RFC6221]. Hence, no additional RS subscriber line id or IPinIP tunnel header extensions would be required, effectively obviating all of the [I-D.ietf-6man-lineid] protocol extension requirements. Similarly, none of the upstream devices, would appear to be affected in supporting this solution. Though this solution solves the problem of error recovery, state deletion and timer discovery/negotiation, besides removing the need to define any protocol extensions to convey line-id information, in its RS triggered form it remains prone to the critical flaws described in Section 2. Hence, a more reliable version of this solution would see the DHCPv6 proxy client be invoked by line-state changes. Unfortunately, this variant again does not meet goals a), b) and possibly c). Nevertheless, with these usability caveats clearly recognized, it appears that this solution is still superior to what is currently found in [I-D.ietf-6man-lineid], and does not require protocol extensions. 3.5. DHCPv6 client on end hosts A solution that would see most of the goals realized, without the need to define any new protocol extensions, would be to rely on DHCPv6 [rfc3315] client functionality in the end host. DHCPv6 was designed to offer the degree of reliability sought for, as well as periodic retransmissions of messages, along with client identifiers. The compromise in this solution would be that it does not appear to fit goal e), at least when looked from a universal current host implementation perspective, namely that some end hosts would be required to implement a DHCPv6 client. Given the relation of the problem being addressed to the bridged connectivity model, a non technical variant of this solution at the service level is to stipulate in the user's terms and conditions it is supported only with DHCPv6 clients. This approach has been effectively assumed by the Cablelabs specifications for bridged media connectivity [MULPI], as well as put into practice by several Ethernet FTTx network operators. Dec Expires December 22, 2011 [Page 11] Internet-Draft rs-access-considered-harmful June 2011 3.6. ANCP The Access Node Control Protocol (ANCP) [I-D.ietf-ancp-protocol] defines a suite of mechanisms for conveying information pertaining to the state of a subscriber access line between a Layer 2 access node physically terminating the subscriber access line and a separate Layer 3 router. One of the key capabilities of the protocol is that to signal line state changes from the access-node to the router, as well as to apply dynamic configuration on access-lines retrieved from the router. In the combination, these two capabilities offer another alternative solution, at least in so far as a line-state driven mechanism can provide. The basic premise of the solution would see the Access-Node use existing ANCP "Port-UP" or "Port-Down" messages, which also convey line-id, to signal line state changes to the edge router. These could be considered as the trigger events to drive the edge router to send to the Access-Node either "Line Configuration" messages with IPv6 parameters, or define a new "Raw data" message type which would ferry a raw RA to be sent on the access-line. As with any of the other Access-Node line state driven solutions, meeting goals a) and b) would not be possible. Despite that, ANCP offers a robust and reliable (TCP based) line-state communication mechanism between an Access-Node and Edge Router, which does not need re-inventing. 3.7. Other The solution proposed by [I-D.ietf-6man-lineid], consisting in adding a subscriber-line-id parameter as part of an IPinIP encapsulation header, can be realized practically by various other tunneling protocols. Specifically, L2TPv3 already defines AVPs for subscriber- line-id information. As with other solutions that rely only on tunneling host sourced RAs, this will be prone to host connectivity impediments. 4. Conclusions Due to the inherent design and implementation characteristics of the ND protocol, mechanisms that gate IPv6 user connectivity based on the reception of an RS message are likely to lead to serious IPv6 connectivity failures for end users, and leave both users and operators with no automated means of recovering from the situation. The issues are particularly severe in cases when the end users do not have a direct link adjacency to the router, as is often the case in bridged Ethernet or WiFi based broadband access networks. Moreover, Dec Expires December 22, 2011 [Page 12] Internet-Draft rs-access-considered-harmful June 2011 such a mechanism appears not to meet the expected more general usage goals as presented in Section 2. As such, the definition and deployment of such mechanisms is considered to be harmful to the success of IPv6 usage, and thus should be discouraged in favour of alternative solutions. Two alternative solutions presented in Sections 3.4 and 3.6, can comprehensively meet the majority of the Section 2 goals. The solution presented in Section 3.5, which has proven to meet the requirements of many operators, indicating the imposed host constraints might not be universally applicable, remains a valid approach which requires no protocol extensions. Solution variants seek to redress the lack of direct link state adjacency by using an intermediate link state driven messaging proxy function incur a shortcoming. This consist in their inability to be able to provide the to the authorization system information such as the end host MAC address. Thus, any such solution carries usage constraints, that should be clarified. The solution variant proposed by [I-D.ietf-6man-lineid] introduces itself numerous issues of reliability and deployability, whose resolution is not trivial without major ND protocol extensions, if not other protocol work. Alternatives, as presented in Section 3.4, 3.6 and 3.7 all offer more robust and deployable mechanisms that in most cases leverage already defined protocols and mechanisms hence appear to offer a much more viable solution path. 5. IANA Considerations This document does not raise any IANA considerations. 6. Security Considerations The security of the solutions outlined needs to be evaluated in specific solution documents. 7. Contributors and Acknowledgements The author would like to thank Erik Nordmark, Ole Troan, and Sean Cavanaugh for reviewing this document. 8. References Dec Expires December 22, 2011 [Page 13] Internet-Draft rs-access-considered-harmful June 2011 8.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [I-D.ietf-6man-lineid] Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. Nordmark, "The Line Identification Destination Option", draft-ietf-6man-lineid-01 (work in progress), March 2011. [I-D.ietf-ancp-protocol] Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. Taylor, "Protocol for Access Node Control Mechanism in Broadband Networks", draft-ietf-ancp-protocol-17 (work in progress), April 2011. [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., and M. Carney, "Dynamic Host Configuration Protocol for IPv6 (DHCPv6)", RFC 3315, July 2003. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. Wadhwa, "Framework and Requirements for an Access Node Control Mechanism in Broadband Multi-Service Networks", RFC 5851, May 2010. [RFC6221] Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, May 2011. [TR-177] - Broadband Forum, [IEEE802.1ag] - IEEE, Dec Expires December 22, 2011 [Page 14] Internet-Draft rs-access-considered-harmful June 2011 Author's Address Wojciech Dec Cisco Systems Haarlerbergweg 13-19 1101 CH Amsterdam The Netherlands Email: wdec@cisco.com Dec Expires December 22, 2011 [Page 15]