GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc6788

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]

/data/webs/external/dokuwiki/data/pages/rfc/rfc6788.txt · Last modified: 2012/11/19 20:07 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki