idnits 2.17.1 draft-ietf-6man-lineid-08.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords -- however, there's a paragraph with a matching beginning. Boilerplate error? (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- The document date (August 17, 2012) is 4263 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCXXXX' is mentioned on line 643, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) -- Possible downref: Non-RFC (?) normative reference: ref. 'TR101' -- Possible downref: Non-RFC (?) normative reference: ref. 'TR124' -- Possible downref: Non-RFC (?) normative reference: ref. 'TR156' -- Possible downref: Non-RFC (?) normative reference: ref. 'TR177' Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 5 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 6man Working Group S. Krishnan 3 Internet-Draft A. Kavanagh 4 Intended status: Standards Track B. Varga 5 Expires: February 18, 2013 Ericsson 6 S. Ooghe 7 Alcatel-Lucent 8 E. Nordmark 9 Cisco 10 August 17, 2012 12 The Line Identification Destination Option 13 draft-ietf-6man-lineid-08 15 Abstract 17 In Ethernet based aggregation networks, several subscriber premises 18 may be logically connected to the same interface of an edge router. 19 This document proposes a method for the edge router to identify the 20 subscriber premises using the contents of the received Router 21 Solicitation messages. The applicability is limited to broadband 22 network deployment scenarios where multiple user ports are mapped to 23 the same virtual interface on the edge router. 25 Status of this Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at http://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on February 18, 2013. 42 Copyright Notice 44 Copyright (c) 2012 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (http://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 61 1.2. Conventions used in this document . . . . . . . . . . . . 5 62 2. Applicability Statement . . . . . . . . . . . . . . . . . . . 6 63 3. Issues with identifying the subscriber premises in an N:1 64 VLAN model . . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4. Basic operation . . . . . . . . . . . . . . . . . . . . . . . 7 66 5. AN Behavior . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.1. On initialization . . . . . . . . . . . . . . . . . . . . 8 68 5.2. On receiving a Router Solicitation from the end-device . . 8 69 5.3. On receiving a Router Advertisement from the Edge 70 Router . . . . . . . . . . . . . . . . . . . . . . . . . . 9 71 5.3.1. Identifying tunneled Router Advertisements . . . . . . 9 72 5.4. On detecting a subscriber circuit coming up . . . . . . . 9 73 5.5. On detecting Edge Router failure . . . . . . . . . . . . . 9 74 5.6. RS Retransmission algorithm . . . . . . . . . . . . . . . 10 75 6. Edge Router Behavior . . . . . . . . . . . . . . . . . . . . . 10 76 6.1. On receiving a Tunneled Router Solicitation from the AN . 10 77 6.2. On sending a Router Advertisement towards the 78 end-device . . . . . . . . . . . . . . . . . . . . . . . . 10 79 6.3. Sending periodic unsolicited Router Advertisements 80 towards the end-device . . . . . . . . . . . . . . . . . . 11 81 7. Line Identification Destination Option (LIO) . . . . . . . . . 11 82 7.1. Encoding of Line ID . . . . . . . . . . . . . . . . . . . 12 83 8. Garbage collection of unused prefixes . . . . . . . . . . . . 13 84 9. Interactions with Secure Neighbor Discovery . . . . . . . . . 14 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 89 13.1. Normative References . . . . . . . . . . . . . . . . . . . 15 90 13.2. Informative References . . . . . . . . . . . . . . . . . . 16 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 93 1. Introduction 95 Digital Subscriber Line (DSL) is a widely deployed access technology 96 for Broadband Access for Next Generation Networks. While traditional 97 DSL access networks were Point-to-Point Protocol (PPP) [RFC1661] 98 based, some networks are migrating from the traditional PPP access 99 model into a pure IP-based Ethernet aggregated access environment. 100 Architectural and topological models of an Ethernet aggregation 101 network in the context of DSL aggregation are described in [TR101]. 103 +----+ +----+ +----------+ 104 |Host|---| RG |----| | 105 +----+ +----+ | | 106 | AN |\ 107 +----+ +----+ | | \ 108 |Host|---| RG |----| | \ 109 +----+ +----+ +----------+ \ +----------+ 110 \ | | 111 +-------------+ | | 112 | Aggregation | | Edge | 113 | Network |-------| Router | 114 +-------------+ | | 115 / | | 116 +----------+ / +----------+ 117 | | / 118 +----+ +----+ | | / 119 |Host|---| RG |----| AN |/ 120 +----+ +----+ | | 121 | | 122 +----------+ 124 Figure 1: Broadband Forum Network Architecture 126 One of the Ethernet and Gigabit Passive Optical Network (GPON) 127 aggregation models specified in this document bridges sessions from 128 multiple user ports behind a DSL Access Node (AN), also referred to 129 as a Digital subscriber line access multiplexer (DSLAM), into a 130 single VLAN in the aggregation network. This is called the N:1 VLAN 131 allocation model. 133 +----------+ 134 | | 135 | | 136 | AN |\ 137 | | \ 138 | | \ VLANx 139 +----------+ \ +----------+ 140 \ | | 141 +-------------+ | | 142 | Aggregation | VLANx | Edge | 143 | Network |-------| Router | 144 +-------------+ | | 145 / | | 146 +----------+ / +----------+ 147 | | / VLANx 148 | | / 149 | AN |/ 150 | | 151 | | 152 +----------+ 154 Figure 2: n:1 VLAN model 156 1.1. Terminology 158 1:1 VLAN It is a broadband network deployment 159 scenario where each user port is mapped to 160 a different VLAN on the Edge Router. The 161 uniqueness of the mapping is maintained in 162 the Access Node and across the Aggregation 163 Network. 164 N:1 VLAN It is a broadband network deployment 165 scenario where multiple user ports are 166 mapped to the same VLAN on the Edge Router. 167 The user ports may be located in the same 168 or different Access Nodes. 169 GPON Gigabit-capable Passive Optical Network is 170 an optical access network that has been 171 introduced into the Broadband Forum 172 architecture in [TR156] 173 AN A DSL or a GPON Access Node. The Access 174 Node terminates the physical layer (e.g. 175 DSL termination function or GPON 176 termination function), may physically 177 aggregate other nodes implementing such 178 functionality, or may perform both 179 functions at the same time. This node 180 contains at least one standard Ethernet 181 interface that serves as its "northbound" 182 interface into which it aggregates traffic 183 from several user ports or Ethernet-based 184 "southbound" interfaces. It does not 185 implement an IPv6 stack but performs some 186 limited inspection/modification of IPv6 187 packets. The IPv6 functions required on 188 the Access Node are described in Section 5 189 of [TR177]. 190 Aggregation Network The part of the network stretching from the 191 Access Nodes to the Edge Router. In the 192 context of this document the aggregation 193 network is considered to be Ethernet based, 194 providing standard Ethernet interfaces at 195 the edges, for connecting the Access Nodes 196 and Broadband Network. It is comprised of 197 ethernet switches that provide very limited 198 IP functionality (e.g. IGMP snooping, MLD 199 snooping etc.). 200 RG A residential gateway device. It can be a 201 Layer 3 (routed) device or a Layer 2 202 (bridged) device. The residential gateway 203 for Broadband Forum networks is defined in 204 [TR124] 205 Edge Router The Edge Router, also known as the 206 Broadband Network Gateway (BNG) is the 207 first IPv6 hop for the user. In the cases 208 where the Residential Gateway (RG) is 209 bridged, the BNG acts as the default router 210 for the hosts behind the RG. In cases 211 where the RG is routed, the BNG acts as the 212 default router for the RG itself. This 213 node implements IPv6 router functionality. 214 Host A node that implements IPv6 host 215 functionality. 216 End-device A node that sends Router Solicitations and 217 processes received Router Advertisements. 218 When a Layer 3 RG is used it is considered 219 an end-device in the context of this 220 document. When a Layer 2 RG is used, the 221 host behind the RG is considered to be an 222 end-device in the context of this document. 224 1.2. Conventions used in this document 226 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 227 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 228 document are to be interpreted as described in [RFC2119]. 230 2. Applicability Statement 232 The line identification destination option is intended to be used 233 only for the N:1 VLAN deployment model. For the other VLAN 234 deployment models, line identification can be achieved differently. 235 The mechanism described in the document is useful for allowing the 236 connection of hosts that only support IPv6 stateless address auto- 237 configuration to attach to networks that use the N:1 VLAN deployment 238 model. 240 When the Dynamic Host Configuration Protocol (DHCP) [RFC3315] is used 241 for IPv6 address assignment it has the side-effect of including 242 reliability initiated by the end-device (the end-device retransmits 243 DHCP messages until it receives a response), as well as a way to 244 detect when the end-device is not active for an extended period of 245 time (the end-device would not renew its DHCP lease). The IPv6 246 Stateless address autoconfiguration protocol [RFC4862] was not 247 designed to satisfy such requirements [RSDA]. While this option 248 improves the reliability of operation in deployments that use Router 249 Solicitations rather than DHCP, there are some limitations as 250 specified below. 252 The mechanism described in this document deals with the loss of 253 subscriber-originated Router Solicitations (RSes) by initiating RSes 254 at the AN, which improves the robustness over solely relying on the 255 end-device's few initial retransmissions of RSes. 257 But the AN retransmissions imply that some information (e.g. the 258 subscriber's MAC address) that was obtained by the edge router from 259 subscriber-originated RSes may no longer be available. e.g. Since 260 there is no L2 frame received from the subscriber in case of an RS 261 sent by an AN, the L2 address information of the end-device cannot be 262 determined. One piece of L2 address information currently used in 263 some Broadband networks is the MAC address. For this reason, the 264 solution described in this document is NOT RECOMMENDED for networks 265 that require the MAC address of the endpoint for identification. 267 There is no indication when a subscriber is no longer active. Thus 268 this protocol can not be used to automatically reclaim resources, 269 such as prefixes, that are associated with an active subscriber. See 270 Section 8. Thus this protocol is NOT RECOMMENDED for networks that 271 require automatic notification when a subscriber is no longer active. 273 This mechanism by itself provides no protection against the loss of 274 RS induced state in access routers that would lead to loss of IPv6 275 connectivity for end-devices. Given that regular IPv6 hosts do not 276 have RS retransmission behavior that would allow automatic recovery 277 from such a failure, this mechanism SHOULD only be used in 278 deployments employing N:1 VLANs. 280 3. Issues with identifying the subscriber premises in an N:1 VLAN model 282 In a DSL or GPON based fixed Broadband Network, IPv6 end-devices are 283 connected to an AN. These end-devices today will typically send a 284 Router Solicitation Message to the Edge Router, to which the Edge 285 Router responds with a Router Advertisement message. The Router 286 Advertisement typically contains a prefix that the end-devices will 287 use to automatically configure an IPv6 Address. Upon sending the 288 Router Solicitation message the node connecting the end-device on the 289 access circuit, typically an AN, would forward the RS to the Edge 290 Router upstream over a switched network. However, in such Ethernet- 291 based aggregation networks, several subscriber premises may be 292 connected to the same interface of an edge router (e.g. on the same 293 VLAN). However, the edge router requires some information to 294 identify the end-device on the circuit. To accomplish this, the AN 295 needs to add line identification information to the Router 296 Solicitation message and forward this to the Edge Router. This is 297 analogous to the case where DHCP is being used, and the line 298 identification information is inserted by a DHCP relay agent 299 [RFC3315]. This document proposes a method for the edge router to 300 identify the subscriber premises using the contents of the received 301 Router Solicitation messages. Note that there might be several end- 302 devices that are located on the same subscriber premises. 304 4. Basic operation 306 This document uses a mechanism that tunnels Neighbor discovery 307 packets inside another IPv6 packet that uses a destination option 308 (Line ID option) to convey line identification information as 309 depicted in Figure 3. The use of the Line ID option in any other 310 IPv6 datagrams, including untunneled RS and RA messages, is not 311 defined by this document. The Neighbor discovery packets are left 312 unmodified inside the encapsulating IPv6 packet. In particular, the 313 Hop Limit field of the Neighbor Discovery (ND) message is not 314 decremented when the packet is being tunneled. This is because ND 315 messages whose Hop Limit is not 255 will be discarded by the receiver 316 of such messages, as described in Sections 6.1.1 and 6.1.2 of 317 [RFC4861]. 319 +----+ +----+ +-----------+ 320 |Host| | AN | |Edge Router| 321 +----+ +----+ +-----------+ 322 | RS | | 323 |---------->| | 324 | | | 325 | |Tunneled RS(LIO)| 326 | |--------------->| 327 | | | 328 | |Tunneled RA(LIO)| 329 | |<---------------| 330 | RA | | 331 |<----------| | 332 | | | 334 Figure 3: Basic message flow 336 5. AN Behavior 338 5.1. On initialization 340 On initialization, the AN MUST join the All-BBF-Access-Nodes 341 multicast group on all its upstream interfaces towards the Edge 342 Router. 344 5.2. On receiving a Router Solicitation from the end-device 346 When an end-device sends out a Router Solicitation, it is received by 347 the AN. The AN identifies these messages by looking for ICMPv6 348 messages (IPv6 Next Header value of 58) with ICMPv6 type 133. The AN 349 intercepts and then tunnels the received Router Solicitation in a 350 newly created IPv6 datagram with the Line Identification Option 351 (LIO). The AN forms a new IPv6 datagram whose payload is the 352 received Router Solicitation message as described in [RFC2473] except 353 that the Hop Limit field of the Router Solicitation message MUST NOT 354 be decremented. If the AN has an IPv6 address, it MUST use this 355 address in the Source Address field of the outer IPv6 datagram. 356 Otherwise, the AN MUST copy the source address from the received 357 Router Solicitation into the Source Address field of the outer IPv6 358 datagram. The destination address of the outer IPv6 datagram MUST be 359 copied from the destination address of the tunneled RS. The AN MUST 360 include a destination options header between the outer IPv6 header 361 and the payload. It MUST insert a LIO destination option and set the 362 line identification field of the option to contain the circuit 363 identifier corresponding to the logical access loop port of the AN 364 from which the RS was initiated. 366 5.3. On receiving a Router Advertisement from the Edge Router 368 When the edge router sends out a tunneled Router Advertisement in 369 response to the RS, it is received by the AN. If there is an LIO 370 option present, the AN MUST use the line identification data of the 371 LIO option to identify the subscriber agent circuit of the AN on 372 which the RA should be sent. The AN MUST then remove the outer IPv6 373 header of this tunneled RA and multicast the inner packet (the 374 original RA) on this specific subscriber circuit. 376 5.3.1. Identifying tunneled Router Advertisements 378 The AN can identify tunneled RAs by installing filters based on the 379 destination address (All-BBF-Access-Nodes which is reserved link- 380 local scoped multicast address) of the outer packets, and the 381 presence of a destination option header with an LIO destination 382 option. 384 5.4. On detecting a subscriber circuit coming up 386 RSes initiated by end-devices as described in Section 5.2 may be lost 387 due to lack of connectivity between the AN and the end-device. To 388 ensure that the end-device will receive an RA, the AN needs to 389 trigger the sending of periodic RAs on the edge router. For this 390 purpose, the AN needs to inform the edge router that a subscriber 391 circuit has come up. Each time the AN detects that a subscriber 392 circuit has come up, it MUST create a Router Solicitation message as 393 described in Section 6.3.7 of [RFC4861]. It MUST use the unspecified 394 address as the source address of this RS. It MUST then tunnel this 395 RS towards the edge router as described in Section 5.2. 397 In case there are connectivity issues between the AN and the edge 398 router, the RSes initiated by the AN can be lost. The AN SHOULD 399 continue retransmitting the Router Solicitations following the 400 algorithm described in Section 5.6 for a given LIO until it receives 401 an RA for that specific LIO. 403 5.5. On detecting Edge Router failure 405 When the edge router reboots and loses state or is replaced by a new 406 edge router, the AN will detect it using connectivity check 407 mechanisms that are already in place in Broadband networks (e.g. 408 BFD). When such edge router failure is detected, the AN needs to 409 start transmitting RSes for each of its subscriber circuits that are 410 up as described in Section 5.4. 412 5.6. RS Retransmission algorithm 414 The AN SHOULD use the exponential backoff algorithm for retransmits 415 that is described in Section 14 of [RFC3315] in order to continuously 416 retransmit the Router Solicitations for a given LIO until a response 417 is received for that specific LIO. The AN SHOULD use the following 418 variables as input to the retransmission algorithm: 420 IRT 1 Second 421 MRT 30 Seconds 422 MRC 0 423 MRD 0 425 6. Edge Router Behavior 427 6.1. On receiving a Tunneled Router Solicitation from the AN 429 When the edge router receives a tunneled Router Solicitation 430 forwarded by the AN, it needs to check if there is an LIO destination 431 option present in the outer datagram. The edge router can use the 432 contents of the line identification field to lookup the addressing 433 information and policy that need to be applied to the line from which 434 the Router Solicitation was received. The edge router MUST then 435 process the inner RS message as specified in [RFC4861]. 437 6.2. On sending a Router Advertisement towards the end-device 439 When the edge router sends out a Router Advertisement in response to 440 a tunneled RS that included an LIO option, it MUST tunnel the Router 441 Advertisement in a newly created IPv6 datagram with the Line 442 Identification Option (LIO) as described below. First, The edge 443 router creates the Router Advertisement message as described in 444 Section 6.2.3 of [RFC4861]. The edge router MUST include a Prefix 445 Information Option in this RA that contains the prefix that 446 corresponds to the received LIO (The LIO from the received tunneled 447 RS is usually passed on from the edge router to some form of 448 provisioning system that returns the prefix to be included in the RA. 449 It could e,g, be based on RADIUS.). Then, the Edge Router forms the 450 new IPv6 datagram, whose payload is the Router Advertisement message, 451 as described in [RFC2473] except that the Hop Limit field of the 452 Router Advertisement message MUST NOT be decremented. The Edge 453 router MUST use a link-local IPv6 address on the outgoing interface 454 in the Source Address field of the outer IPv6 datagram. The edge 455 router MUST include a destination options header between the outer 456 IPv6 header and the payload. It MUST insert a LIO destination option 457 and set the line identification field of the option to contain the 458 same value as that of the Line ID option in the received RS. The 459 IPv6 destination address of the inner RA MUST be set to the all-nodes 460 multicast address. 462 If the Source Address field of the received IPv6 datagram was not the 463 unspecified address, the edge router MUST copy this address into the 464 Destination Address field of the outer IPv6 datagram sent back 465 towards the AN. The link-layer destination address of the outer IPv6 466 datagram containing the outer IPv6 datagram MUST be resolved using 467 regular Neighbour Discovery procedures. 469 If the Source Address field of the received IPv6 datagram was the 470 unspecified address, the destination address of the outer IPv6 471 datagram MUST be set to the well-known link-local scope All-BBF- 472 Access-Nodes multicast address [to be allocated]. The link-layer 473 destination address of the tunneled RA MUST be set to the unicast 474 link-layer address of the AN that sent the tunneled Router 475 Solicitation which is being responded to. 477 The edge router MUST ensure that it does not transmit tunneled RAs 478 whose size is larger than the MTU of the link between the edge router 479 and the AN, which would require that the outer IPv6 datagram undergo 480 fragmentation. This limitation is imposed because the AN may not be 481 capable of handling the reassembly of such fragmented datagrams. 483 6.3. Sending periodic unsolicited Router Advertisements towards the 484 end-device 486 After sending a tunneled Router Advertisement as specified in 487 Section 6.2 in response to a received RS, the edge router MUST store 488 the mapping between the LIO and the prefixes contained in the Router 489 Advertisement. It should then initiate periodic sending of 490 unsolicited Router Advertisements as described in Section 6.2.3. of 491 [RFC4861] . The Router Advertisements MUST be created and tunneled 492 as described in Section 6.2. The edge router MAY stop sending Router 493 Advertisements if it receives a notification from the AN that the 494 subscriber circuit has gone down. This notification can be received 495 out-of-band using a mechanism such as ANCP. Please consult Section 8 496 for more details. 498 7. Line Identification Destination Option (LIO) 500 The Line Identification Destination Option (LIO) is a destination 501 option that can be included in IPv6 datagrams that tunnel Router 502 Solicitation and Router Advertisement messages. The use of the Line 503 ID option in any other IPv6 datagrams is not defined by this 504 document. Multiple Line Identification destination options MUST NOT 505 be present in the same IPv6 datagram. The LIO has no alignment 506 requirement. 508 0 1 2 3 509 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 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Option Type | Option Length | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 513 | LineIDLen | Line Identification... 514 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 516 Figure 4: Line Identification Destination Option Layout 518 Option Type 520 8-bit identifier of the type of option. The option identifier 521 for the line identification option will be allocated by the IANA. 523 Option Length 525 8-bit unsigned integer. The length of the option (excluding 526 the Option Type and Option Length fields). The value MUST be 527 greater than 0. 529 LineIDLen 531 8-bit unsigned integer. The length of the Line Identification 532 field in number of octets. 534 Line Identification 536 Variable length data inserted by the AN describing the 537 subscriber agent circuit identifier corresponding to the logical 538 access loop port of the AN from which the RS was 539 initiated. The line identification MUST be unique across all the 540 ANs that share a link to the edge router. e.g. One such line 541 identification scheme is described in Section 3.9 of [TR101]. 542 The line idenfication should be encoded as specified in 543 Section 7.1. 545 7.1. Encoding of Line ID 547 This IPv6 Destination Option is derived from an existing widely 548 deployed DHCPv6 Option [RFC4649], which is in turn derived from a 549 widely deployed DHCPv4 Option [RFC3046]. Both of those derive from 550 and cite the basic DHCP options specification [RFC2132]. Those 551 widely deployed DHCP options use the NVT character set 553 [RFC2132][RFC0020]. Since the data carried in the Line ID option is 554 used in the same manner by the provisioning systems as the DHCP 555 options, it is beneficial for it to maintain the same encoding as the 556 DHCP options. 558 The IPv6 Line ID option contains a description which identifies the 559 line, using only character positions (decimal 32 to decimal 126, 560 inclusive) of the US-ASCII character set [X3.4], [RFC0020]. 561 Consistent with [RFC2132], [RFC3046] and [RFC4649], the Line ID field 562 SHOULD NOT contain the US-ASCII NUL character (decimal 0). However, 563 implementations receiving this option MUST NOT fail merely because an 564 ASCII NUL character is (erroneously) present in the Line ID option's 565 data field. 567 Some existing widely deployed implementations of edge routers and ANs 568 that support the previously mentioned DHCP option only support US- 569 ASCII, and strip the high-order bit from any 8-bit characters entered 570 by the device operator. The previously mentioned DHCP options do not 571 support 8-bit character sets either. Therefore, for compatibility 572 with the installed base and to maximise interoperability, the high- 573 order bit of each octet in this field MUST be set to zero by any 574 device inserting this option in an IPv6 packet. 576 Consistent with [RFC3046] and [RFC4649], this option always uses 577 binary comparison. Therefore, two Line IDs MUST be equal when they 578 match when compared byte-by-byte. Line-ID A and Line-ID B match 579 byte-by-byte when (1) A and B have the same number of bytes and (2) 580 for all byte indexes P in A: the value of A at index P has the same 581 binary value as the value of B at index P. 583 Two Line IDs MUST NOT be equal if they do not match byte-by-byte. 584 For example, an IPv6 Line ID option containing "f123" is not equal to 585 a Line ID option "F123". 587 Intermediate systems MUST NOT alter the contents of the Line ID. 589 8. Garbage collection of unused prefixes 591 Following the mechanism described in this document, the Broadband 592 network associates a prefix to a subscriber line based on the LIO. 593 Even when the subscriber line goes down temporarily, this prefix 594 stays allocated to that specific subscriber line. i.e. The prefix is 595 not returned to the unused pool. When a subscriber line no longer 596 needs a prefix, the prefix can be reclaimed by manual action 597 dissociating the prefix from the LIO in the backend systems. 599 9. Interactions with Secure Neighbor Discovery 601 Since the SEND [RFC3971] protected RS/RA packets are not modified in 602 anyway by the mechanism described in this document, there are no 603 issues with SEND verification. 605 10. Acknowledgements 607 The authors would like to thank Margaret Wasserman, Mark Townsley, 608 David Miles, John Kaippallimalil, Eric Levy-Abegnoli, Thomas Narten, 609 Olaf Bonness, Thomas Haag, Wojciech Dec, Brian Haberman, Ole Troan, 610 Hemant Singh, Jari Arkko, Joel Halpern, Bob Hinden, Ran Atkinson, 611 Glen Turner, Kathleen Moriarty, David Sinicrope, Dan Harkins, Stephen 612 Farrell, Barry Leiba, Sean Turner, Ralph Droms, and Mohammed 613 Boucadair for reviewing this document and suggesting changes. 615 11. Security Considerations 617 The line identification information inserted by the AN or the edge 618 router is not protected. This means that this option may be 619 modified, inserted, or deleted without being detected. In order to 620 ensure validity of the contents of the line identification field, the 621 network between the AN and the edge router needs to be trusted. 623 12. IANA Considerations 625 This document defines a new IPv6 destination option for carrying line 626 identification. IANA is requested to assign a new destination option 627 type in the Destination Options registry maintained at 629 http://www.iana.org/assignments/ipv6-parameters 631 Line Identification Option [RFCXXXX] 633 The act bits for this option need to be 10 and the chg bit needs to 634 be 0. 636 This document also requires the allocation of a well-known link-local 637 scope multicast address from the IPv6 Multicast Address Space 638 Registry located at 640 http://www.iana.org/assignments/ipv6-multicast-addresses/ 641 ipv6-multicast-addresses.xml 643 All-BBF-Access-Nodes [RFCXXXX] 645 13. References 647 13.1. Normative References 649 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 650 RFC 1661, July 1994. 652 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 653 Requirement Levels", BCP 14, RFC 2119, March 1997. 655 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 656 IPv6 Specification", RFC 2473, December 1998. 658 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 659 and M. Carney, "Dynamic Host Configuration Protocol for 660 IPv6 (DHCPv6)", RFC 3315, July 2003. 662 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 663 Neighbor Discovery (SEND)", RFC 3971, March 2005. 665 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 666 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 667 September 2007. 669 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 670 Address Autoconfiguration", RFC 4862, September 2007. 672 [TR101] Broadband Forum, "Migration to Ethernet-based DSL 673 aggregation", . 676 [TR124] Broadband Forum, "Functional Requirements for Broadband 677 Residential Gateway Devices", . 681 [TR156] Broadband Forum, "Using GPON Access in the context of TR- 682 101", . 685 [TR177] Broadband Forum, "IPv6 in the context of TR-101", 686 . 688 [X3.4] American National Standards Institute, "American Standard 689 Code for Information Interchange (ASCII)", Standard X3.4 , 690 1968. 692 13.2. Informative References 694 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 695 October 1969. 697 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 698 Extensions", RFC 2132, March 1997. 700 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 701 RFC 3046, January 2001. 703 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 704 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 705 August 2006. 707 [RSDA] Dec, W., "IPv6 Router Solicitation Driven Access 708 Considered Harmful", draft-dec-6man-rs-access-harmful-00 709 (work in progress), June 2011. 711 Authors' Addresses 713 Suresh Krishnan 714 Ericsson 715 8400 Blvd Decarie 716 Town of Mount Royal, Quebec 717 Canada 719 Email: suresh.krishnan@ericsson.com 721 Alan Kavanagh 722 Ericsson 723 8400 Blvd Decarie 724 Town of Mount Royal, Quebec 725 Canada 727 Email: alan.kavanagh@ericsson.com 729 Balazs Varga 730 Ericsson 731 Konyves Kalman krt. 11. B. 732 1097 Budapest 733 Hungary 735 Email: balazs.a.varga@ericsson.com 736 Sven Ooghe 737 Alcatel-Lucent 738 Copernicuslaan 50 739 2018 Antwerp, 740 Belgium 742 Phone: 743 Email: sven.ooghe@alcatel-lucent.com 745 Erik Nordmark 746 Cisco 747 510 McCarthy Blvd. 748 Milpitas, CA, 95035 749 USA 751 Phone: +1 408 527 6625 752 Email: nordmark@cisco.com