[Docs] [txt|pdf] [Tracker] [Email] [Nits]

Versions: 00

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,<http://www.broadband-forum.org/technical/download/TR-177.pdf>

   [IEEE802.1ag] - IEEE,<http://www.ieee802.org/1/pages/802.1ag.html>












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]


Html markup produced by rfcmarkup 1.109, available from https://tools.ietf.org/tools/rfcmarkup/