idnits 2.17.1 draft-dec-6man-rs-access-harmful-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 197 has weird spacing: '... :(L-id optio...' == Line 278 has weird spacing: '... :(L-id optio...' -- The document date (June 20, 2011) is 4695 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'MULPI' is mentioned on line 502, but not defined == Unused Reference: 'RFC5851' is defined on line 621, but no explicit reference was found in the text == Unused Reference: 'IEEE802.1ag' is defined on line 633, but no explicit reference was found in the text == Outdated reference: A later version (-08) exists of draft-ietf-6man-lineid-01 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 7 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group W. Dec 3 Internet-Draft Cisco Systems 4 Intended status: Informational June 20, 2011 5 Expires: December 22, 2011 7 IPv6 Router Solicitation Driven Access Considered Harmful 8 draft-dec-6man-rs-access-harmful-00 10 Abstract 12 This document presents issues regarding the reliance of IPv6 Router 13 Solicitation messages for creating or initializing router state 14 necessary to enable IPv6 users' connectivity, particularly in 15 situations where such users have bridged ethernet connectivity with 16 the router. A number of alternative solution approaches are also 17 presented and discussed. 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on December 22, 2011. 42 Copyright Notice 44 Copyright (c) 2011 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 2. Problem Overview . . . . . . . . . . . . . . . . . . . . . . . 4 61 2.1. RS Sending Proxy . . . . . . . . . . . . . . . . . . . . . 6 62 3. Discussion of possible solutions . . . . . . . . . . . . . . . 8 63 3.1. Modifying RFC4861 . . . . . . . . . . . . . . . . . . . . 9 64 3.2. Modifying RS-proxy and router behaviour . . . . . . . . . 9 65 3.3. Ethernet Connectivity Fault Monitoring . . . . . . . . . . 10 66 3.4. Access-Node based DHCPv6 Proxy Client . . . . . . . . . . 10 67 3.5. DHCPv6 client on end hosts . . . . . . . . . . . . . . . . 11 68 3.6. ANCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 12 69 3.7. Other . . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 4. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . 12 71 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 72 6. Security Considerations . . . . . . . . . . . . . . . . . . . 13 73 7. Contributors and Acknowledgements . . . . . . . . . . . . . . 13 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 77 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 14 79 1. Introduction 81 Recent proposals for including subscriber line identifiers alongside 82 host sourced Router Solicitation (RS) messages 83 ([I-D.ietf-6man-lineid]) in an environment where the host has no 84 direct link layer adjacency with the router (eg when using Ethernet 85 bridging), have highlighted the intent of using these RS messages on 86 the receiving router as a trigger for specific functions & processes. 87 Without the execution of these processes, such as host or line 88 authorization, the host will not receive Router Advertisements (RAs) 89 that allow the establishment of full IPv6 connectivity. Similar RS 90 triggered processes, although without line identifiers, are proposed 91 in specifications concerning WiFi access and appear to share the same 92 pitfalls. 94 In analyzing the impact of these proposals it is useful to refer to 95 the basics of the IPv6 Neighbour Discovery protocol as defined in 96 [RFC4861], which defines the Router Solicitation (RS) message type. 97 This message is intended to be used by hosts to request routers to 98 generate Router Advertisements sooner than at their next scheduled 99 time. The Router Solicitation mechanism is intended to be used in a 100 very specific set of cases, or not at all, and a regular IPv6 network 101 can work fully without any RS message ever being sent. In general, 102 as per Section 6.3.7 of [RFC4861], Router Solicitations may be sent 103 by a host after any of the following events: 105 o The interface is initialized at system startup time. 107 o The interface is reinitialized after a temporary interface failure 108 or after being temporarily disabled by system management. 110 o The system changes from being a router to being a host, by having 111 its IP forwarding capability turned off by system management. 113 o The host attaches to a link for the first time. 115 o The host re-attaches to a link after being detached for some time. 117 Notably in the above a host is at no stage required to periodically 118 send RS messages, nor to send RS messages after a period of not 119 receiving any RAs. 121 Furthermore [RFC4861] states that once a host "receives a valid 122 Router Advertisement with a non-zero Router Lifetime, the host MUST 123 desist from sending additional solicitations on that interface, until 124 the next time one of the above events occurs." This effectively 125 signifies that following the reception of any given RA message, sent 126 by any device, a host will not issue RS messages until it is 127 reattached or re-initialized. 129 The following text from [RFC4861] also illustrates another aspect 130 relating to the rule governing a host's ceasing of RS sending. 132 "If a host sends MAX_RTR_SOLICITATIONS solicitations, and receives no 133 Router Advertisements after having waited MAX_RTR_SOLICITATION_DELAY 134 seconds after sending the last solicitation, the host concludes that 135 there are no routers on the link" 137 Experimental evidence conducted on a number of IPv6 implementations 138 confirms that the above behaviour is indeed currently the norm, with 139 specific implementations differing in terms of the default timers (eg 140 MAX_RTR_SOLICITATION_DELAY) used. One implementation has been found 141 to send RS messages at evenly spaced 4 second intervals for up to 12 142 seconds after the link event. Another implementation has been found 143 to exponentially increase the sending interval for successive 144 messages and stopping RS sending after 90 seconds. 146 The RS sending mechanism was thus clearly not designed nor is 147 implemented to be periodic, nor reliable, nor expected to be sent by 148 a host that has timed out or received an RA. Any mechanism that 149 presupposes any of these RS sending characteristics, or requires them 150 to work reliably, requires a thorough review. 152 2. Problem Overview 154 The main intent of the [I-D.ietf-6man-lineid] proposal is to convey 155 from an Ethernet bridging Access-Node to an upstream IPv6 router, the 156 subscriber-line-id information indicating the origin of downstream 157 host sourced RS messages. All this is envisaged to be done by 158 tunneling such RS messages using IPinIP tunneling between the Access- 159 Node and the Router, with the access node inserting the subscriber- 160 line-id for each tunnelled RS. The reception by the router of such 161 RS messages with the subscriber-line-id is expected to be the trigger 162 for authorizing and allowing the subscriber's connectivity to the 163 network. It is crucial to note that only after successful 164 authorization will the router send RA messages that contain IPv6 165 Prefix Information Option (PIO) that allow the host to configure a 166 global IPv6 address. A direct example of this usage goal can be 167 found in Section 6.5 and Appendix A of [TR-177]. 169 In generic terms, the principle of such mechanism is shown in Figure 170 1, and the goal is to create a dynamic user driven IPv6 access system 171 that is in conductive to: 173 a. Triggering by means of subscriber sourced ND (RS) messages, 174 processes on the IP edge router which serve to provide and setup 175 hosts/subscribers with IPv6 connectivity. 177 b. Deriving from the received messages host identifiers and/or 178 information regarding where the host is connected to in the Layer 179 2 network (eg based on MAC address and/or subscriber line id) and 180 using that information in performing access and/or address 181 authorization prior to granting connectivity. 183 c. Being used in an environment where the host/subscriber has no 184 directly link layer adjacency with the router, but rather 185 indirect connectivity (eg via a bridged Ethernet RG/CPE, and/or a 186 bridging DSLAM). 188 d. Being used in an environment where IPv6 hosts implement *only* 189 [RFC4861] as the control protocol, and without any further host 190 changes or client protocols (eg DHCPv6) 192 AAA 193 Host Bridge Router (Optional) 194 : : : : 195 : RS : : : 196 :--------------->: RS : : 197 : :(L-id optional) : AAA Req : 198 : :---------------->: (L-id,etc) : 199 : : : .............>: 200 : : : : 201 : : : AAA Resp. : 202 : : RA : (Prefix) : 203 : : (PIO, L-id) :<............. : 204 : RA :<----------------: : 205 : (PIO, etc) : : : 206 :<---------------: . : : 207 : : . : : 208 : : . : : 209 : : Periodic : : 210 : Periodic : RAs : : 211 : RAs :<----------------: : 212 :<---------------: : : 214 A number of deployment contexts that seek to realize such a system 215 will result in the end user having no IPv6 connectivity, and being 216 left without any automated means of recovery it, all very detrimental 217 to the success of the IPv6 deployment. 219 One such deployment context is the residential broadband N:1 VLAN 220 environment, as described by [I-D.ietf-6man-lineid]. This features 221 hosts indirectly connected to the edge router over a bridged Layer 2 222 VLAN set-up (aka an N:1 VLAN). End subscriber hosts connect to 223 Ethernet bridging devices, such as an RG/modem and an Access-Node/ 224 DSLAM, which provide indirect link connectivity for the host with the 225 router. From each end hosts perspective, its local LAN link state is 226 as presented by the RG/modem's LAN interface, eg Ethernet or WiFi. 227 This state is decoupled from the RG/modem's uplink interface state, 228 or that of the DSLAM links, or that of the IP edge router 229 interface(s). Hence, each host's interface is expected to be "up" 230 even when no DSL WAN link synchronisation has been established, or 231 when the WAN link is being established following a modem reboot (an 232 event lasting 2 minutes or more is not uncommon), etc. Given this, 233 and in consideration of the RS sending characteristics described in 234 Section 1 , it is near certain that following a bridge/modem reload, 235 or a DSLAM reload, any and all RS messages sent by hosts will never 236 arrive at the intended IP edge router within the time hosts send RS 237 messages. Since the reception of such RS messages by the edge router 238 is required to trigger the announcement of RAs containing the chosen 239 user address prefix option (PIO) towards the hosts, the host will be 240 left without any addressing information and thus no IPv6 241 connectivity. The only recourse a user has is manual intervention on 242 the host's interface. 244 Note: The example of DSL is used above, but the case applies to other 245 media, eg cable modems, that exhibit similar "modem reload" events. 246 Moreover, the same problem appears to apply to each deployment that 247 seeks to realize the mentioned goals and features hosts that have no 248 direct link layer adjacency with a router, eg IEEE 802.11 WiFi 249 architectures. 251 It's significant to note that the [I-D.ietf-6man-lineid] mechanism 252 implicitly assumes behaviour which by itself will result in the 253 system failing non-deterministically. As expemplieifed by its usage 254 described in [TR-177], "empty RAs" (ie Router-Advertisement messages 255 that contain no addressing/prefix information) are to be multicast to 256 all subscribers and hosts from the router, in parallel to any 257 specific RAs containing prefix information and the line option. 258 Again, following the cited rules of [RFC4861], should a subscriber 259 host receive such an empty RA prior to issuing an RS, that host will 260 never send an RS and thus never trigger the authorization process 261 necessary to get global IPv6 addressing & connectivity. 263 2.1. RS Sending Proxy 265 An update to the [I-D.ietf-6man-lineid] draft proposal has somewhat 266 recognized the critical flaw described in Section 2. It also 267 attempted a remedy in the form of introducing an Access-Node feature, 268 as described in Section 5.3 of [I-D.ietf-6man-lineid]. This feature, 269 consists in the Access Node issuing RS messages towards the Router 270 driven by subscriber link activation (and only activation) state (ie 271 when the link is "brought up"). The term "proxy-RS sender" rather 272 aptly describes the feature, as denoted in Figure 2 below. 273 Bridge AAA 274 Device (Proxy-RS Sender) Router (Optional) 275 : : : : 276 : Link UP : : : 277 : ***Event*** : RS : : 278 : :(L-id optional) : AAA Req : 279 : :---------------->: (L-id,etc) : 280 : : : .............>: 281 : : : : 282 : : : AAA Resp. : 283 : : RA : (Prefix) : 284 : : (PIO, L-id) :<............. : 285 : RA :<----------------: : 286 : (PIO, etc) : : : 287 :<---------------: . : : 288 : : . : : 289 : : . : : 290 : : Periodic : : 291 : Periodic : RAs : : 292 : RAs :<----------------: : 293 :<---------------: : : 295 [I-D.ietf-6man-lineid] indicates that a finite number of RS messages 296 are to be sent and that sending should stop after the Access Node 297 receives an RA with a matching subscriber line information option 298 back from the edge router. This remedy, in the context of the 299 overall solution, is not only insufficient, but introduces further 300 problems, consisting of: 302 1. Unreliability of RS messaging: There is no assurance that the RS 303 messages sent by the proxy will reach the edge router. Eg it is 304 not uncommon for spanning tree protocol events take place on the 305 Ethernet segments, or other similar events, which result in loss 306 of connectivity with the edge router ranging from a couple of 307 seconds to a couple of minutes - this is often the case during 308 access-node activation. Any RS messages sent by the RS-proxy, on 309 behalf of bridged subscribers connected to this access node, 310 would be lost and all the relevant subscribers left without IPv6 311 connectivity. 313 2. Lack of subscriber host identifiers: In many of today's broadband 314 deployments end host identifiers are required for the purpose of 315 authorization besides intermediate identifiers such as subscriber 316 line-id. For example, it is quite common to identify and 317 authorize devices like WiFi smart phones or TV set-top-boxes by 318 their unique MAC address. With the RS-proxy mechanism, these 319 identifiers are not be available, and effectively do not meet 320 goal b) of the system 322 3. No ability to clean up state/recover: Each "active" subscriber 323 link is intended to induce IPv6 subscriber state in the router. 324 Short of manual intervention by the operator there is no 325 mechanism on the router to remove such state should a link ever 326 become "inactive". In other words, there is no equivalent of a 327 "link down" message, nor does the ND protocol provide for such 328 extensibility, and the router and operator are likely to be 329 burdened with a large amount of stale state, besides inefficient 330 use of resources. 332 4. In ability to recover from node failures: Given that an RS-proxy 333 eventually stops sending RSes, should the edge router loose for 334 any reason any or all of the RS induced state, including the 335 route to the subscriber, the system will fall into a state of 336 unrecoverable connectivity loss for end users, even as they 337 continue to have a valid IPv6 address. Basically, a host that 338 received a previous RA from an Edge Router will following rfc4862 339 NOT send an further RS messages, while a router without the 340 necessary state will NOT forward traffic to the subscriber. 341 Similarly, neither will the RS-proxy send RS messages as long as 342 the line is still "active". 344 Given the above issues, while the introduction of the RS-sending- 345 proxy was intended to fix a critical flaw with the original proposal, 346 if not only left the issue in place, but it introduced further issues 347 undermining its overall purpose and compromising the usability and 348 scalability of the system. 350 3. Discussion of possible solutions 352 Its readily apparent that any solution based on proxy functionality 353 that is driven by link state changes cannot meet all of the system 354 goals as presented in Section 2 (eg goals a, b and c), while 355 satisfying the constraint of no changes to end hosts (goal e) and 356 within the context of a bridged/indirect-link host-router set-up 357 (goal d). At best compromises to the goals or combinations of 358 solutions need to be adopted. The solutions below indicate such 359 compromises: 361 3.1. Modifying RFC4861 363 One possible, solution, that would solve a handful of issues, would 364 be to modify [RFC4861] in such a way as to give the protocol a 365 semblance of reliability and persistence. For example, it could be 366 stipulated that host RS sending behaviour needs to be periodic and 367 continue irrespective of RA messages being received. Router 368 behaviour would need to be modified to detect periods of RS 369 inactivity. All this would be a substantial change to the original 370 protocol specification, and would naturally require changes to any 371 existing IPv6 ND implementations to be useful, falling short of goal 372 e). Besides this, it would also significantly increase the RS 373 processing load on any router. 375 3.2. Modifying RS-proxy and router behaviour 377 Modifying the RS-proxy mechanism to issue periodic RS messages driven 378 subscriber link state, or doing so whenever no RA is received for a 379 given subscriber line over a certain period of time could be seen as 380 a possible solution to some, but not all, of the problems identified. 381 In essence this modification transforms RS/RA messaging into link- 382 state notification messages. Unfortunately it also introduces 383 several other flaws, besides not meeting the Section 2 goals a), b) 384 and possibly c): 386 o Unknown timers: For the mechanism to function, the behaviour of 387 both the RS-proxy and the edge router need to be modified in terms 388 of RS processing and RA sending, around a timer driven state 389 machine, where both the Access-Node and Router share the timers. 390 Defining for this purpose a new timer negotiation protocol appears 391 a major ND or IPinIP protocol change, while relying on "well 392 known" timers (ie hard set) is highly inflexibility not conductive 393 to automated, reliable and inter operable deployments. 395 o Increased load on AAA system: Following the intent of the system, 396 for each RS message for which no authorization state exists on the 397 edge router, authorization from an AAA server is to be requested. 398 With RS messages being periodic, this will place additional burden 399 on any AAA infrastructure, besides being analogous to issuing AAA 400 requests for each link keepalive received. 402 o Subscriber management: One of the main premises of an architecture 403 that features a Layer 2 Access Node and an upstream aggregating IP 404 Edge Router is the notion of subscriber management on the IP Edge 405 Router. Operators deploying this architecture seek to use the IP 406 Edge Router as the node on which subscriber related configuration 407 and control is applied - hence the desire to perform dynamic 408 subscriber authorization at/by the router. Introducing into this 409 architecture a mechanism where periodic RS messages sent by a 410 proxy could lead to similarly periodic denial of authorizations at 411 the edge router, eg for subscriber lines that are not authorized 412 to use the service, with the only way of disabling such RS sending 413 is by maintaining on the Access-Node subscriber configuration 414 information, is counter to the premise of the architecture itself. 416 o ND customization: One of the design goals for using the IPinIP 417 tunneling mechanism was to avoid changes to the ND protocol or 418 implementations. Unfortunately, the processing of custom tunneled 419 RS messages as well as generation of custom tunneled RA messages, 420 in effect requires a highly customized ND implementation, the 421 likes of which diverges from typically ND implementations. 423 Given the above, modifying the RS-proxy mechanism to be periodic 424 would not only require a fairly major extension to the proposal, 425 including the definition of timers covering message sending 426 periodicity discovery and/or negotiation, but also result in more 427 issues to the overall system. Above all, such a modification would 428 in the end only mimic a link-state signalling/keepalive protocol, 429 without actually resolving all of the identified problems, and 430 without actually being one. 432 3.3. Ethernet Connectivity Fault Monitoring 434 A core issue in the a system driven by host sourced RS, is the end 435 hosts inability to detect when an indirect link has failed, 436 translating into the hosts inability to re-send RS messages. On 437 links such as PPP, which offer link state keepalives, the issue does 438 not come up, but neither does the need of driving router 439 authorization events via RS messages due to the link layer 440 negotiation stage of PPP. Over Ethernet, a link state keepalive 441 mechanisms could fill in part of that gap. The closest equivalent 442 can be found in Ethernet Connectivity Fault Monitoring that is a 443 component of the IEEE 802.1ag Ethernet OAM specification [802.1ag]. 444 The implementation of such extensions on hosts and routers would 445 allow the regular [RFC4861] RA sending rules to respond appropriately 446 to connectivity or device failures. Unfortunately, there is no known 447 end host implementation of 802.1ag today, which translates that this 448 solution does not meet goal e) (no end host modifications). 449 Nevertheless, it appears like a valid approach, whose realization 450 however does not appear to be within the IETF's specification direct 451 sphere of influence. 453 3.4. Access-Node based DHCPv6 Proxy Client 455 An alternative solution to some of the problems identified in 456 relation to periodic RA sending, would be to define an RS/ 457 RA-DHCPv6-proxy function, whose role would be to transform host 458 sourced RS messages into DHCPv6 Solicit/etc messages towards the edge 459 router. The access-node would thus be a multi DUID DHCPv6 client as 460 seen by the rest of the operator's network. Regular mechanisms of 461 DHCPv6 relaying by the edge router and prefix delegation would be 462 used to assign /64 prefixes for each subscriber line. The RS/ 463 RA-DHCPv6 proxy would also be responsible for announcing the DHCPv6 464 derived prefixes in regular RA messages to downstream hosts. An 465 additional bonus of this solution is the fact that the existing 466 DHCPv6 specification allows for the subscriber line-id to be included 467 in the DHCPv6 messages [RFC3315], [RFC6221]. Hence, no additional RS 468 subscriber line id or IPinIP tunnel header extensions would be 469 required, effectively obviating all of the [I-D.ietf-6man-lineid] 470 protocol extension requirements. Similarly, none of the upstream 471 devices, would appear to be affected in supporting this solution. 473 Though this solution solves the problem of error recovery, state 474 deletion and timer discovery/negotiation, besides removing the need 475 to define any protocol extensions to convey line-id information, in 476 its RS triggered form it remains prone to the critical flaws 477 described in Section 2. Hence, a more reliable version of this 478 solution would see the DHCPv6 proxy client be invoked by line-state 479 changes. Unfortunately, this variant again does not meet goals a), 480 b) and possibly c). Nevertheless, with these usability caveats 481 clearly recognized, it appears that this solution is still superior 482 to what is currently found in [I-D.ietf-6man-lineid], and does not 483 require protocol extensions. 485 3.5. DHCPv6 client on end hosts 487 A solution that would see most of the goals realized, without the 488 need to define any new protocol extensions, would be to rely on 489 DHCPv6 [rfc3315] client functionality in the end host. DHCPv6 was 490 designed to offer the degree of reliability sought for, as well as 491 periodic retransmissions of messages, along with client identifiers. 492 The compromise in this solution would be that it does not appear to 493 fit goal e), at least when looked from a universal current host 494 implementation perspective, namely that some end hosts would be 495 required to implement a DHCPv6 client. 497 Given the relation of the problem being addressed to the bridged 498 connectivity model, a non technical variant of this solution at the 499 service level is to stipulate in the user's terms and conditions it 500 is supported only with DHCPv6 clients. This approach has been 501 effectively assumed by the Cablelabs specifications for bridged media 502 connectivity [MULPI], as well as put into practice by several 503 Ethernet FTTx network operators. 505 3.6. ANCP 507 The Access Node Control Protocol (ANCP) [I-D.ietf-ancp-protocol] 508 defines a suite of mechanisms for conveying information pertaining to 509 the state of a subscriber access line between a Layer 2 access node 510 physically terminating the subscriber access line and a separate 511 Layer 3 router. One of the key capabilities of the protocol is that 512 to signal line state changes from the access-node to the router, as 513 well as to apply dynamic configuration on access-lines retrieved from 514 the router. In the combination, these two capabilities offer another 515 alternative solution, at least in so far as a line-state driven 516 mechanism can provide. 518 The basic premise of the solution would see the Access-Node use 519 existing ANCP "Port-UP" or "Port-Down" messages, which also convey 520 line-id, to signal line state changes to the edge router. These 521 could be considered as the trigger events to drive the edge router to 522 send to the Access-Node either "Line Configuration" messages with 523 IPv6 parameters, or define a new "Raw data" message type which would 524 ferry a raw RA to be sent on the access-line. 526 As with any of the other Access-Node line state driven solutions, 527 meeting goals a) and b) would not be possible. Despite that, ANCP 528 offers a robust and reliable (TCP based) line-state communication 529 mechanism between an Access-Node and Edge Router, which does not need 530 re-inventing. 532 3.7. Other 534 The solution proposed by [I-D.ietf-6man-lineid], consisting in adding 535 a subscriber-line-id parameter as part of an IPinIP encapsulation 536 header, can be realized practically by various other tunneling 537 protocols. Specifically, L2TPv3 already defines AVPs for subscriber- 538 line-id information. As with other solutions that rely only on 539 tunneling host sourced RAs, this will be prone to host connectivity 540 impediments. 542 4. Conclusions 544 Due to the inherent design and implementation characteristics of the 545 ND protocol, mechanisms that gate IPv6 user connectivity based on the 546 reception of an RS message are likely to lead to serious IPv6 547 connectivity failures for end users, and leave both users and 548 operators with no automated means of recovering from the situation. 549 The issues are particularly severe in cases when the end users do not 550 have a direct link adjacency to the router, as is often the case in 551 bridged Ethernet or WiFi based broadband access networks. Moreover, 552 such a mechanism appears not to meet the expected more general usage 553 goals as presented in Section 2. As such, the definition and 554 deployment of such mechanisms is considered to be harmful to the 555 success of IPv6 usage, and thus should be discouraged in favour of 556 alternative solutions. 558 Two alternative solutions presented in Sections 3.4 and 3.6, can 559 comprehensively meet the majority of the Section 2 goals. The 560 solution presented in Section 3.5, which has proven to meet the 561 requirements of many operators, indicating the imposed host 562 constraints might not be universally applicable, remains a valid 563 approach which requires no protocol extensions. 565 Solution variants seek to redress the lack of direct link state 566 adjacency by using an intermediate link state driven messaging proxy 567 function incur a shortcoming. This consist in their inability to be 568 able to provide the to the authorization system information such as 569 the end host MAC address. Thus, any such solution carries usage 570 constraints, that should be clarified. 572 The solution variant proposed by [I-D.ietf-6man-lineid] introduces 573 itself numerous issues of reliability and deployability, whose 574 resolution is not trivial without major ND protocol extensions, if 575 not other protocol work. Alternatives, as presented in Section 3.4, 576 3.6 and 3.7 all offer more robust and deployable mechanisms that in 577 most cases leverage already defined protocols and mechanisms hence 578 appear to offer a much more viable solution path. 580 5. IANA Considerations 582 This document does not raise any IANA considerations. 584 6. Security Considerations 586 The security of the solutions outlined needs to be evaluated in 587 specific solution documents. 589 7. Contributors and Acknowledgements 591 The author would like to thank Erik Nordmark, Ole Troan, and Sean 592 Cavanaugh for reviewing this document. 594 8. References 595 8.1. Normative References 597 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 598 Requirement Levels", BCP 14, RFC 2119, March 1997. 600 8.2. Informative References 602 [I-D.ietf-6man-lineid] 603 Krishnan, S., Kavanagh, A., Varga, B., Ooghe, S., and E. 604 Nordmark, "The Line Identification Destination Option", 605 draft-ietf-6man-lineid-01 (work in progress), March 2011. 607 [I-D.ietf-ancp-protocol] 608 Wadhwa, S., Moisand, J., Haag, T., Voigt, N., and T. 609 Taylor, "Protocol for Access Node Control Mechanism in 610 Broadband Networks", draft-ietf-ancp-protocol-17 (work in 611 progress), April 2011. 613 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 614 and M. Carney, "Dynamic Host Configuration Protocol for 615 IPv6 (DHCPv6)", RFC 3315, July 2003. 617 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 618 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 619 September 2007. 621 [RFC5851] Ooghe, S., Voigt, N., Platnic, M., Haag, T., and S. 622 Wadhwa, "Framework and Requirements for an Access Node 623 Control Mechanism in Broadband Multi-Service Networks", 624 RFC 5851, May 2010. 626 [RFC6221] Miles, D., Ooghe, S., Dec, W., Krishnan, S., and A. 627 Kavanagh, "Lightweight DHCPv6 Relay Agent", RFC 6221, 628 May 2011. 630 [TR-177] - Broadband 631 Forum, 633 [IEEE802.1ag] - IEEE, 635 Author's Address 637 Wojciech Dec 638 Cisco Systems 639 Haarlerbergweg 13-19 640 1101 CH Amsterdam 641 The Netherlands 643 Email: wdec@cisco.com