doc: Add RFC documents

1 files changed, 955 insertions, 0 deletions

diff --git a/doc/rfc/rfc6788.txt b/doc/rfc/rfc6788.txt
new file mode 100644
index 0000000..c1b670d
--- /dev/null
+++ b/doc/rfc/rfc6788.txt
@@ -0,0 +1,955 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                       S. Krishnan
+Request for Comments: 6788                                   A. Kavanagh
+Category: Standards Track                                       B. Varga
+ISSN: 2070-1721                                                 Ericsson
+                                                                S. Ooghe
+                                                          Alcatel-Lucent
+                                                             E. Nordmark
+                                                                   Cisco
+                                                           November 2012
+
+
+                     The Line-Identification Option
+
+Abstract
+
+   In Ethernet-based aggregation networks, several subscriber premises
+   may be logically connected to the same interface of an Edge Router.
+   This document proposes a method for the Edge Router to identify the
+   subscriber premises using the contents of the received Router
+   Solicitation messages.  The applicability is limited to broadband
+   network deployment scenarios in which multiple user ports are mapped
+   to the same virtual interface on the Edge Router.
+
+Status of This Memo
+
+   This is an Internet Standards Track document.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Further information on
+   Internet Standards is available in Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6788.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krishnan, et al.             Standards Track                    [Page 1]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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
+   (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
+      1.1. Terminology ................................................4
+      1.2. Conventions Used in This Document ..........................6
+   2. Applicability Statement .........................................6
+   3. Issues with Identifying the Subscriber Premises in an
+      N:1 VLAN Model ..................................................7
+   4. Basic Operation .................................................7
+   5. AN Behavior .....................................................8
+      5.1. On Initialization ..........................................8
+      5.2. On Receiving a Router Solicitation from the End-Device .....8
+      5.3. On Receiving a Router Advertisement from the Edge Router ...9
+           5.3.1. Identifying Tunneled Router Advertisements ..........9
+      5.4. On Detecting a Subscriber Circuit Coming Up ................9
+      5.5. On Detecting Edge Router Failure ..........................10
+      5.6. RS Retransmission Algorithm ...............................10
+   6. Edge Router Behavior ...........................................10
+      6.1. On Receiving a Tunneled Router Solicitation from the AN ...10
+      6.2. On Sending a Router Advertisement Towards the End-Device ..10
+      6.3. Sending Periodic Unsolicited Router Advertisements
+           Towards the End-Device ....................................11
+   7. Line-Identification Option (LIO) ...............................12
+      7.1. Encoding of Line ID .......................................13
+   8. Garbage Collection of Unused Prefixes ..........................14
+   9. Interactions with Secure Neighbor Discovery ....................14
+   10. Acknowledgements ..............................................14
+   11. Security Considerations .......................................14
+   12. IANA Considerations ...........................................14
+   13. References ....................................................15
+      13.1. Normative References .....................................15
+      13.2. Informative References ...................................16
+
+
+
+
+Krishnan, et al.             Standards Track                    [Page 2]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+1.  Introduction
+
+   Digital Subscriber Line (DSL) is a widely deployed access technology
+   for Broadband Access for Next Generation Networks.  While traditional
+   DSL access networks were Point-to-Point Protocol (PPP) [RFC1661]
+   based, some networks are migrating from the traditional PPP access
+   model into a pure IP-based Ethernet aggregated access environment.
+   Architectural and topological models of an Ethernet aggregation
+   network in the context of DSL aggregation are described in [TR101].
+
+   +----+   +----+    +----------+
+   |Host|---| RG |----|          |
+   +----+   +----+    |          |
+                      |    AN    |\
+   +----+   +----+    |          | \
+   |Host|---| RG |----|          |  \
+   +----+   +----+    +----------+   \                    +----------+
+                                      \                   |          |
+                                    +-------------+       |          |
+                                    | Aggregation |       |  Edge    |
+                                    |   Network   |-------|  Router  |
+                                    +-------------+       |          |
+                                      /                   |          |
+                      +----------+   /                    +----------+
+                      |          |  /
+   +----+   +----+    |          | /
+   |Host|---| RG |----|    AN    |/
+   +----+   +----+    |          |
+                      |          |
+                      +----------+
+
+              Figure 1: Broadband Forum Network Architecture
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krishnan, et al.             Standards Track                    [Page 3]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+   One of the Ethernet and Gigabit-capable Passive Optical Network
+   (GPON) aggregation models specified in this document bridges sessions
+   from multiple user ports behind a DSL Access Node (AN), also referred
+   to as a Digital Subscriber Line Access Multiplexer (DSLAM), into a
+   single VLAN in the aggregation network.  This is called the N:1 VLAN
+   allocation model.
+
+      +----------+
+      |          |
+      |          |
+      |    AN    |\
+      |          | \
+      |          |  \ VLANx
+      +----------+   \                    +----------+
+                      \                   |          |
+                    +-------------+       |          |
+                    | Aggregation | VLANx |  Edge    |
+                    |   Network   |-------|  Router  |
+                    +-------------+       |          |
+                      /                   |          |
+      +----------+   /                    +----------+
+      |          |  / VLANx
+      |          | /
+      |    AN    |/
+      |          |
+      |          |
+      +----------+
+
+                         Figure 2: n:1 VLAN model
+
+1.1.  Terminology
+
+   1:1 VLAN               A broadband network deployment scenario in
+                          which each user port is mapped to a different
+                          VLAN on the Edge Router.  The uniqueness of
+                          the mapping is maintained in the Access Node
+                          and across the aggregation network.
+
+   N:1 VLAN               A broadband network deployment scenario in
+                          which multiple user ports are mapped to the
+                          same VLAN on the Edge Router.  The user ports
+                          may be located in the same or different Access
+                          Nodes.
+
+   GPON                   Gigabit-capable Passive Optical Network is an
+                          optical access network that has been
+                          introduced into the Broadband Forum
+                          architecture in [TR156].
+
+
+
+Krishnan, et al.             Standards Track                    [Page 4]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+   AN                     A DSL or a GPON Access Node.  The Access Node
+                          terminates the physical layer (e.g., DSL
+                          termination function or GPON termination
+                          function), may physically aggregate other
+                          nodes implementing such functionality, or may
+                          perform both functions at the same time.  This
+                          node contains at least one standard Ethernet
+                          interface that serves as its "northbound"
+                          interface into which it aggregates traffic
+                          from several user ports or Ethernet-based
+                          "southbound" interfaces.  It does not
+                          implement an IPv6 stack but performs some
+                          limited inspection/modification of IPv6
+                          packets.  The IPv6 functions required on the
+                          Access Node are described in Section 5 of
+                          [TR177].
+
+   Aggregation Network    The part of the network stretching from the
+                          Access Nodes to the Edge Router.  In the
+                          context of this document, the aggregation
+                          network is considered to be Ethernet based,
+                          providing standard Ethernet interfaces at the
+                          edges, for connecting the Access Nodes and the
+                          broadband network.  It is comprised of
+                          Ethernet switches that provide very limited IP
+                          functionality (e.g., IGMP snooping, Multicast
+                          Listener Discovery (MLD) snooping, etc.).
+
+   RG                     A residential gateway device.  It can be a
+                          Layer-3 (routed) device or a Layer-2 (bridged)
+                          device.  The residential gateway for Broadband
+                          Forum networks is defined in [TR124].
+
+   Edge Router            The Edge Router, also known as the Broadband
+                          Network Gateway (BNG), is the first IPv6 hop
+                          for the user.  In cases where the RG is
+                          bridged, the BNG acts as the default router
+                          for the hosts behind the RG.  In cases where
+                          the RG is routed, the BNG acts as the default
+                          router for the RG itself.  This node
+                          implements IPv6 router functionality.
+
+   Host                   A node that implements IPv6 host
+                          functionality.
+
+
+
+
+
+
+
+Krishnan, et al.             Standards Track                    [Page 5]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+   End-Device             A node that sends Router Solicitations and
+                          processes received Router Advertisements.
+                          When a Layer-3 (L3) RG is used, it is
+                          considered an end-device in the context of
+                          this document.  When a Layer-2 (L2) RG is
+                          used, the host behind the RG is considered to
+                          be an end-device in the context of this
+                          document.
+
+1.2.  Conventions Used in This Document
+
+   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 [RFC2119].
+
+2.  Applicability Statement
+
+   The Line-Identification Option (LIO) is intended to be used only for
+   the N:1 VLAN deployment model.  For the other VLAN deployment models,
+   line identification can be achieved differently.  The mechanism
+   described in this document allows the connection of hosts that only
+   support IPv6 stateless address auto-configuration to attach to
+   networks that use the N:1 VLAN deployment model.
+
+   When the Dynamic Host Configuration Protocol (DHCP) [RFC3315] is used
+   for IPv6 address assignment, it has the side-effect of providing end-
+   device-initiated reliability as well as inactivity detection.  The
+   reliability is provided by the end-device continuing to retransmit
+   DHCP messages until it receives a response), and inactivity is
+   detected by the end-device not renewing its DHCP lease.  The "IPv6
+   Stateless Address Autoconfiguration" protocol [RFC4862] was not
+   designed to satisfy such requirements [RSDA].  While this option
+   improves the reliability of operation in deployments that use Router
+   Solicitations rather than DHCP, there are some limitations as
+   specified below.
+
+   The mechanism described in this document deals with the loss of
+   subscriber-originated Router Solicitations (RSes) by initiating RSes
+   at the AN, which improves robustness over solely relying on the
+   end-device's few initial retransmissions of RSes.
+
+   However, the AN retransmissions imply that some information (e.g.,
+   the subscriber's MAC address) that was obtained by the Edge Router
+   from subscriber-originated RSes may no longer be available.  For
+   example, since there is no L2 frame received from the subscriber in
+   case of an RS sent by an AN, the L2-address information of the
+   end-device cannot be determined.  One piece of L2-address information
+   currently used in some broadband networks is the MAC address.  For
+
+
+
+Krishnan, et al.             Standards Track                    [Page 6]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+   this reason, the solution described in this document is NOT
+   RECOMMENDED for networks that require the MAC address of the endpoint
+   for identification.
+
+   There is no indication when a subscriber is no longer active.  Thus,
+   this protocol cannot be used to automatically reclaim resources, such
+   as prefixes, that are associated with an active subscriber.  See
+   Section 8.  Thus, this protocol is NOT RECOMMENDED for networks that
+   require automatic notification when a subscriber is no longer active.
+
+   This mechanism by itself provides no protection against the loss of
+   RS-induced state in access routers that would lead to loss of IPv6
+   connectivity for end-devices.  Given that regular IPv6 hosts do not
+   have RS retransmission behavior that would allow automatic recovery
+   from such a failure, this mechanism SHOULD only be used in
+   deployments employing N:1 VLANs.
+
+3.  Issues with Identifying the Subscriber Premises in an N:1 VLAN Model
+
+   In a DSL- or GPON-based fixed broadband network, IPv6 end-devices are
+   connected to an AN.  Today, these end-devices will typically send a
+   Router Solicitation message to the Edge Router, to which the Edge
+   Router responds with a Router Advertisement message.  The Router
+   Advertisement typically contains a prefix that the end-devices will
+   use to automatically configure an IPv6 address.  Upon sending the
+   Router Solicitation message, the node connecting the end-device on
+   the access circuit, typically an AN, forwards the RS to the Edge
+   Router upstream over a switched network.  In such Ethernet-based
+   aggregation networks, several subscriber premises may be connected to
+   the same interface of an Edge Router (e.g., on the same VLAN).
+   However, the Edge Router requires some information to identify the
+   end-device on the circuit.  To accomplish this, the AN needs to add
+   line-identification information to the Router Solicitation message
+   and forward this to the Edge Router.  This is analogous to the case
+   where DHCP is being used, and the line-identification information is
+   inserted by a DHCP relay agent [RFC3315].  This document proposes a
+   method for the Edge Router to identify the subscriber premises using
+   the contents of the received Router Solicitation messages.  Note that
+   there might be several end-devices located on the same subscriber
+   premises.
+
+4.  Basic Operation
+
+   This document uses a mechanism that tunnels Neighbor Discovery (ND)
+   packets inside another IPv6 packet that uses a destination option
+   (Line-ID option) to convey line-identification information as
+   depicted in Figure 3.  The use of the Line-ID option in any other
+   IPv6 datagrams, including untunneled RS and RA messages, is not
+
+
+
+Krishnan, et al.             Standards Track                    [Page 7]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+   defined by this document.  The ND packets are left unmodified inside
+   the encapsulating IPv6 packet.  In particular, the Hop Limit field of
+   the ND message is not decremented when the packet is being tunneled.
+   This is because an ND message whose Hop Limit is not 255 will be
+   discarded by the receiver of such messages, as described in Sections
+   6.1.1 and 6.1.2 of [RFC4861].
+
+      +----+     +----+       +-----------+
+      |Host|     | AN |       |Edge Router|
+      +----+     +----+       +-----------+
+        |    RS     |                |
+        |---------->|                |
+        |           |                |
+        |           |Tunneled RS(LIO)|
+        |           |--------------->|
+        |           |                |
+        |           |Tunneled RA(LIO)|
+        |           |<---------------|
+        |    RA     |                |
+        |<----------|                |
+        |           |                |
+
+
+                       Figure 3: Basic Message Flow
+
+5.  AN Behavior
+
+5.1.  On Initialization
+
+   On initialization, the AN MUST join the All-BBF-Access-Nodes
+   multicast group on all its upstream interfaces towards the Edge
+   Router.
+
+5.2.  On Receiving a Router Solicitation from the End-Device
+
+   When an end-device sends out a Router Solicitation, it is received by
+   the AN.  The AN identifies these messages by looking for ICMPv6
+   messages (IPv6 Next Header value of 58) with ICMPv6 type 133.  The AN
+   intercepts and then tunnels the received Router Solicitation in a
+   newly created IPv6 datagram with the Line-Identification Option
+   (LIO).  The AN forms a new IPv6 datagram whose payload is the
+   received Router Solicitation message as described in [RFC2473],
+   except that the Hop Limit field of the Router Solicitation message
+   MUST NOT be decremented.  If the AN has an IPv6 address, it MUST use
+   this address in the Source Address field of the outer IPv6 datagram.
+   Otherwise, the AN MUST copy the source address from the received
+   Router Solicitation into the Source Address field of the outer IPv6
+   datagram.  The destination address of the outer IPv6 datagram MUST be
+
+
+
+Krishnan, et al.             Standards Track                    [Page 8]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+   copied from the destination address of the tunneled RS.  The AN MUST
+   include a destination options header between the outer IPv6 header
+   and the payload.  It MUST insert an LIO destination option and set
+   the Line ID field of the option to contain the circuit identifier
+   corresponding to the logical access loop port of the AN from which
+   the RS was initiated.
+
+5.3.  On Receiving a Router Advertisement from the Edge Router
+
+   When the Edge Router sends out a tunneled Router Advertisement in
+   response to the RS, it is received by the AN.  If there is an LIO
+   present, the AN MUST use the line-identification data of the LIO to
+   identify the subscriber agent circuit of the AN on which the RA
+   should be sent.  The AN MUST then remove the outer IPv6 header of
+   this tunneled RA and multicast the inner packet (the original RA) on
+   this specific subscriber circuit.
+
+5.3.1.  Identifying Tunneled Router Advertisements
+
+   The AN can identify tunneled RAs by installing filters based on the
+   destination address (All-BBF-Access-Nodes, which is a reserved
+   link-local scoped multicast address) of the outer packets and the
+   presence of a destination option header with an LIO destination
+   option.
+
+5.4.  On Detecting a Subscriber Circuit Coming Up
+
+   RSes initiated by end-devices as described in Section 5.2 may be lost
+   due to lack of connectivity between the AN and the end-device.  To
+   ensure that the end-device will receive an RA, the AN needs to
+   trigger the sending of periodic RAs on the Edge Router.  For this
+   purpose, the AN needs to inform the Edge Router that a subscriber
+   circuit has come up.  Each time the AN detects that a subscriber
+   circuit has come up, it MUST create a Router Solicitation message as
+   described in Section 6.3.7 of [RFC4861].  It MUST use the unspecified
+   address as the source address of this RS.  It MUST then tunnel this
+   RS towards the Edge Router as described in Section 5.2.
+
+   In case there are connectivity issues between the AN and the Edge
+   Router, the RSes initiated by the AN can be lost.  The AN SHOULD
+   continue retransmitting the Router Solicitations following the
+   algorithm described in Section 5.6 for a given LIO until it receives
+   an RA for that specific LIO.
+
+
+
+
+
+
+
+
+Krishnan, et al.             Standards Track                    [Page 9]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+5.5.  On Detecting Edge Router Failure
+
+   When the Edge Router reboots and loses state or is replaced by a new
+   Edge Router, the AN will detect it using connectivity check
+   mechanisms that are already in place in broadband networks (e.g.,
+   Bidirectional Forwarding Detection).  When such Edge Router failure
+   is detected, the AN needs to start transmitting RSes for each of its
+   subscriber circuits that have come up, as described in Section 5.4.
+
+5.6.  RS Retransmission Algorithm
+
+   The AN SHOULD use the exponential backoff algorithm for retransmits
+   that is described in Section 14 of [RFC3315] in order to continuously
+   retransmit the Router Solicitations for a given LIO until a response
+   is received for that specific LIO.  The AN SHOULD use the following
+   variables as input to the retransmission algorithm:
+
+     Initial retransmission time (IRT)      1 Second
+     Maximum retransmission time (MRT)     30 Seconds
+     Maximum retransmission count (MRC)     0
+     Maximum retransmission duration (MRD)  0
+
+6.  Edge Router Behavior
+
+6.1.  On Receiving a Tunneled Router Solicitation from the AN
+
+   When the Edge Router receives a tunneled Router Solicitation
+   forwarded by the AN, it needs to check if there is an LIO destination
+   option present in the outer datagram.  The Edge Router can use the
+   contents of the Line ID field to lookup the addressing information
+   and policy that need to be applied to the line from which the Router
+   Solicitation was received.  The Edge Router MUST then process the
+   inner RS message as specified in [RFC4861].
+
+6.2.  On Sending a Router Advertisement Towards the End-Device
+
+   When the Edge Router sends out a Router Advertisement in response to
+   a tunneled RS that included an LIO, it MUST tunnel the Router
+   Advertisement in a newly created IPv6 datagram with the LIO as
+   described below.  First, the Edge Router creates the Router
+   Advertisement message as described in Section 6.2.3 of [RFC4861].
+   The Edge Router MUST include a Prefix Information option in this RA
+   that contains the prefix that corresponds to the received LIO.  (The
+   LIO from the received tunneled RS is usually passed on from the Edge
+   Router to some form of provisioning system that returns the prefix to
+   be included in the RA.  It could e,g., be based on RADIUS.)  Then,
+   the Edge Router forms the new IPv6 datagram whose payload is the
+   Router Advertisement message, as described in [RFC2473], except that
+
+
+
+Krishnan, et al.             Standards Track                   [Page 10]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+   the Hop Limit field of the Router Advertisement message MUST NOT be
+   decremented.  The Edge router MUST use a link-local IPv6 address on
+   the outgoing interface in the Source Address field of the outer IPv6
+   datagram.  The Edge Router MUST include a destination options header
+   between the outer IPv6 header and the payload.  It MUST insert an LIO
+   and set the Line ID field of the option to contain the same value as
+   that of the Line-ID option in the received RS.  The IPv6 destination
+   address of the inner RA MUST be set to the all-nodes multicast
+   address.
+
+   If the Source Address field of the received IPv6 datagram was not the
+   unspecified address, the Edge Router MUST copy this address into the
+   Destination Address field of the outer IPv6 datagram sent back
+   towards the AN.  The link-layer destination address of the outer IPv6
+   datagram containing the outer IPv6 datagram MUST be resolved using
+   regular Neighbor Discovery procedures.
+
+   If the Source Address field of the received IPv6 datagram was the
+   unspecified address, the destination address of the outer IPv6
+   datagram MUST be set to the well-known link-local scope
+   All-BBF-Access-Nodes multicast address (ff02::10).  The link-layer
+   destination address of the tunneled RA MUST be set to the unicast
+   link-layer address of the AN that sent the tunneled Router
+   Solicitation that is being responded to.
+
+   The Edge Router MUST ensure that it does not transmit tunneled RAs
+   whose size is larger than the MTU of the link between the Edge Router
+   and the AN, which would require that the outer IPv6 datagram undergo
+   fragmentation.  This limitation is imposed because the AN may not be
+   capable of handling the reassembly of such fragmented datagrams.
+
+6.3.  Sending Periodic Unsolicited Router Advertisements Towards the
+      End-Device
+
+   After sending a tunneled Router Advertisement as specified in Section
+   6.2 in response to a received RS, the Edge Router MUST store the
+   mapping between the LIO and the prefixes contained in the Router
+   Advertisement.  It should then initiate periodic sending of
+   unsolicited Router Advertisements as described in Section 6.2.3. of
+   [RFC4861] .  The Router Advertisements MUST be created and tunneled
+   as described in Section 6.2.  The Edge Router MAY stop sending Router
+   Advertisements if it receives a notification from the AN that the
+   subscriber circuit has gone down.  This notification can be received
+   out-of-band using a mechanism such as the Access Node Control
+   Protocol (ANCP).  Please consult Section 8 for more details.
+
+
+
+
+
+
+Krishnan, et al.             Standards Track                   [Page 11]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+7.  Line-Identification Option (LIO)
+
+   The Line-Identification Option (LIO) is a destination option that can
+   be included in IPv6 datagrams that tunnel Router Solicitation and
+   Router Advertisement messages.  The use of the Line-ID option in any
+   other IPv6 datagrams is not defined by this document.  Multiple Line-
+   ID destination options MUST NOT be present in the same IPv6 datagram.
+   The LIO has no alignment requirement.
+
+    0                   1                   2                   3
+    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+                                   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+                                   |  Option Type  | Option Length |
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+   | LineIDLen     |     Line ID...
+   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
+
+                Figure 4: Line-Identification Option Layout
+
+    Option Type
+
+       8-bit identifier of the type of option.  The option identifier
+       for the Line-Identification Option (0x8C) has been allocated by
+       the IANA.
+
+    Option Length
+
+       8-bit unsigned integer.  The length of the option (excluding the
+       Option Type and Option Length fields).  The value MUST be greater
+       than 0.
+
+    LineIDLen
+
+       8-bit unsigned integer.  The length of the Line ID field in
+       number of octets.
+
+    Line ID
+
+       Variable-length data inserted by the AN describing the
+       subscriber-agent circuit identifier corresponding to the logical
+       access loop port of the AN from which the RS was initiated.  The
+       line identification MUST be unique across all the ANs that share
+       a link to the Edge Router, e.g., one such line- identification
+       scheme is described in Section 3.9 of [TR101].  The line
+       identification should be encoded as specified in Section 7.1.
+
+
+
+
+
+
+Krishnan, et al.             Standards Track                   [Page 12]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+7.1.  Encoding of the Line ID Field Content
+
+   This IPv6 Destination option is derived from an existing widely
+   deployed DHCPv6 option [RFC4649], which is in turn derived from a
+   widely deployed DHCPv4 option [RFC3046].  These options derive from
+   and cite the basic DHCP options specification [RFC2132].  These
+   widely deployed DHCP options use the Network Virtual Terminal (NVT)
+   character set [RFC2132] [RFC0020].  Since the data carried in the
+   Line-ID option is used in the same manner by the provisioning systems
+   as the DHCP options, it is beneficial for it to maintain the same
+   encoding as the DHCP options.
+
+   The IPv6 Line ID option contains a description that identifies the
+   line using only character positions (decimal 32 to decimal 126,
+   inclusive) of the US-ASCII character set [X3.4] [RFC0020].
+   Consistent with [RFC2132], [RFC3046], and [RFC4649], the Line ID
+   field SHOULD NOT contain the US-ASCII NUL character (decimal 0).
+   However, implementations receiving this option MUST NOT fail merely
+   because an ASCII NUL character is (erroneously) present in the Line
+   ID field.
+
+   Some existing widely deployed implementations of Edge Routers and ANs
+   that support the previously mentioned DHCP option only support
+   US-ASCII and strip the high-order bit from any 8-bit characters
+   entered by the device operator.  The previously mentioned DHCP
+   options do not support 8-bit character sets either.  Therefore, for
+   compatibility with the installed base and to maximize
+   interoperability, the high-order bit of each octet in this field MUST
+   be set to zero by any device inserting this option in an IPv6 packet.
+
+   Consistent with [RFC3046] and [RFC4649], this option always uses
+   binary comparison.  Therefore, two Line IDs MUST be equal when they
+   match when compared byte-by-byte.  Line-ID A and Line-ID B match
+   byte-by-byte when (1) A and B have the same number of bytes, and (2)
+   for all byte indexes P in A: the value of A at index P has the same
+   binary value as the value of B at index P.
+
+   Two Line IDs MUST NOT be equal if they do not match byte-by-byte.
+   For example, an IPv6 Line-ID option containing "f123" is not equal to
+   a Line-ID option "F123".
+
+   Intermediate systems MUST NOT alter the contents of the Line ID.
+
+
+
+
+
+
+
+
+
+Krishnan, et al.             Standards Track                   [Page 13]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+8.  Garbage Collection of Unused Prefixes
+
+   Following the mechanism described in this document, the broadband
+   network associates a prefix to a subscriber line based on the LIO.
+   Even when the subscriber line goes down temporarily, this prefix
+   stays allocated to that specific subscriber line, i.e., the prefix is
+   not returned to the unused pool.  When a subscriber line no longer
+   needs a prefix, the prefix can be reclaimed by manual action
+   dissociating the prefix from the LIO in the backend systems.
+
+9.  Interactions with Secure Neighbor Discovery
+
+   Since the RS/RA packets that are protected by the "SEcure Neighbor
+   Discovery (SEND)" [RFC3971] are not modified in any way by the
+   mechanism described in this document, there are no issues with SEND
+   verification.
+
+10.  Acknowledgements
+
+   The authors would like to thank Margaret Wasserman, Mark Townsley,
+   David Miles, John Kaippallimalil, Eric Levy-Abegnoli, Thomas Narten,
+   Olaf Bonness, Thomas Haag, Wojciech Dec, Brian Haberman, Ole Troan,
+   Hemant Singh, Jari Arkko, Joel Halpern, Bob Hinden, Ran Atkinson,
+   Glen Turner, Kathleen Moriarty, David Sinicrope, Dan Harkins, Stephen
+   Farrell, Barry Leiba, Sean Turner, Ralph Droms, and Mohammed
+   Boucadair for reviewing this document and suggesting changes.
+
+11.  Security Considerations
+
+   The line identification information inserted by the AN or the Edge
+   Router is not protected.  This means that this option may be
+   modified, inserted, or deleted without being detected.  In order to
+   ensure validity of the contents of the Line ID field, the network
+   between the AN and the Edge Router needs to be trusted.
+
+12.  IANA Considerations
+
+   This document defines a new IPv6 destination option for carrying line
+   identification.  IANA has assigned the following new destination
+   option type in the "Destination Options and Hop-by-Hop Options"
+   registry maintained at
+   <http://www.iana.org/assignments/ipv6-parameters>:
+
+      0x8C  Line-Identification Option  [RFC6788]
+
+   The act bits for this option are 10 and the chg bit is 0.
+
+
+
+
+
+Krishnan, et al.             Standards Track                   [Page 14]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+   Per this document, IANA has also allocated the following well-known
+   link-local scope multicast address from the "IPv6 Multicast Address
+   Space Registry" located at
+   <http://www.iana.org/assignments/ipv6-multicast-addresses/>:
+
+      FF02:0:0:0:0:0:0:10  All-BBF-Access-Nodes  [RFC6788]
+
+13.  References
+
+13.1.  Normative References
+
+   [RFC1661]  Simpson, W., Ed., "The Point-to-Point Protocol (PPP)", STD
+              51, RFC 1661, July 1994.
+
+   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
+              Requirement Levels", BCP 14, RFC 2119, March 1997.
+
+   [RFC2473]  Conta, A. and S. Deering, "Generic Packet Tunneling in
+              IPv6 Specification", RFC 2473, December 1998.
+
+   [RFC3315]  Droms, R., Ed., Bound, J., Volz, B., Lemon, T., Perkins,
+              C., and M. Carney, "Dynamic Host Configuration Protocol
+              for IPv6 (DHCPv6)", RFC 3315, July 2003.
+
+   [RFC3971]  Arkko, J., Ed., Kempf, J., Zill, B., and P. Nikander,
+              "SEcure Neighbor Discovery (SEND)", RFC 3971, March 2005.
+
+   [RFC4861]  Narten, T., Nordmark, E., Simpson, W., and H. Soliman,
+              "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861,
+              September 2007.
+
+   [RFC4862]  Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless
+              Address Autoconfiguration", RFC 4862, September 2007.
+
+   [TR101]    Broadband Forum, "Migration to Ethernet-based DSL
+              aggregation", <http://www.broadband-forum.org/
+              technical/download/TR-101.pdf>.
+
+   [TR124]    Broadband Forum, "Functional Requirements for Broadband
+              Residential Gateway Devices",
+              <http://www.broadband-forum.org/technical/
+              download/TR-124_Issue-2.pdf>.
+
+   [TR156]    Broadband Forum, "Using GPON Access in the context of
+              TR-101", <http://www.broadband-forum.org/
+              technical/download/TR-156.pdf>.
+
+
+
+
+
+Krishnan, et al.             Standards Track                   [Page 15]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+   [TR177]    Broadband Forum, "IPv6 in the context of TR-101",
+              <www.broadband-forum.org/technical/download/TR-177.pdf>.
+
+   [X3.4]     American National Standards Institute, "American Standard
+              Code for Information Interchange (ASCII)", Standard X3.4,
+              1968.
+
+13.2.  Informative References
+
+   [RFC0020]  Cerf, V., "ASCII format for network interchange", RFC 20,
+              October 1969.
+
+   [RFC2132]  Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor
+              Extensions", RFC 2132, March 1997.
+
+   [RFC3046]  Patrick, M., "DHCP Relay Agent Information Option", RFC
+              3046, January 2001.
+
+   [RFC4649]  Volz, B., "Dynamic Host Configuration Protocol for IPv6
+              (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, August
+              2006.
+
+   [RSDA]     Dec, W., "IPv6 Router Solicitation Driven Access
+              Considered Harmful", Work in Progress, June 2011.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Krishnan, et al.             Standards Track                   [Page 16]
+
+RFC 6788                     Line-ID Option                November 2012
+
+
+Authors' Addresses
+
+   Suresh Krishnan
+   Ericsson
+   8400 Blvd Decarie
+   Town of Mount Royal, Quebec
+   Canada
+
+   EMail: suresh.krishnan@ericsson.com
+
+
+   Alan Kavanagh
+   Ericsson
+   8400 Blvd Decarie
+   Town of Mount Royal, Quebec
+   Canada
+
+   EMail: alan.kavanagh@ericsson.com
+
+
+   Balazs Varga
+   Ericsson
+   Konyves Kalman krt. 11. B.
+   1097 Budapest
+   Hungary
+
+   EMail: balazs.a.varga@ericsson.com
+
+
+   Sven Ooghe
+   Alcatel-Lucent
+   Copernicuslaan 50
+   2018 Antwerp,
+   Belgium
+
+   Phone:
+   EMail: sven.ooghe@alcatel-lucent.com
+
+
+   Erik Nordmark
+   Cisco
+   510 McCarthy Blvd.
+   Milpitas, CA, 95035
+   USA
+
+   Phone: +1 408 527 6625
+   EMail: nordmark@cisco.com
+
+
+
+
+Krishnan, et al.             Standards Track                   [Page 17]
+