idnits 2.17.1 draft-ietf-6man-lineid-06.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 14, 2012) is 4272 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 616, 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 15, 2013 Ericsson 6 S. Ooghe 7 Alcatel-Lucent 8 E. Nordmark 9 Cisco 10 August 14, 2012 12 The Line Identification Destination Option 13 draft-ietf-6man-lineid-06 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 15, 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 . . . . . . . . . . . . . . . . . . . . . . . . . 7 67 5.1. On initialization . . . . . . . . . . . . . . . . . . . . 7 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 . . . . . . . . . . . . . . . . . . . . . . . . . . 8 71 5.3.1. Identifying tunneled Router Advertisements . . . . . . 8 72 5.4. On detecting a subscriber circuit coming up . . . . . . . 8 73 5.5. On detecting Edge Router failure . . . . . . . . . . . . . 9 74 5.6. RS Retransmission algorithm . . . . . . . . . . . . . . . 9 75 6. Edge Router Behavior . . . . . . . . . . . . . . . . . . . . . 9 76 6.1. On receiving a Tunneled Router Solicitation from the AN . 9 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 . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . 13 85 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 86 11. Security Considerations . . . . . . . . . . . . . . . . . . . 14 87 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 88 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 89 13.1. Normative References . . . . . . . . . . . . . . . . . . . 14 90 13.2. Informative References . . . . . . . . . . . . . . . . . . 15 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. While this option improves 248 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 is considered experimental and 278 SHOULD only be used in 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. 303 4. Basic operation 305 This document uses a mechanism that tunnels Neighbor discovery 306 packets inside another IPv6 packet that uses a destination option to 307 convey line identification information. The Neighbor discovery 308 packets are left unmodified inside the encapsulating IPv6 packet. In 309 particular, the Hop Limit field of the Neighbor Discovery (ND) 310 message is not decremented when the packet is being tunneled. This 311 is because ND messages whose Hop Limit is not 255 will be discarded 312 by the receiver of such messages, as described in Sections 6.1.1 and 313 6.1.2 of [RFC4861]. 315 5. AN Behavior 317 5.1. On initialization 319 On initialization, the AN MUST join the All-BBF-Access-Nodes 320 multicast group on all its upstream interfaces towards the Edge 321 Router. 323 5.2. On receiving a Router Solicitation from the end-device 325 When an end-device sends out a Router Solicitation, it is received by 326 the AN. The AN identifies these messages by looking for ICMPv6 327 messages (IPv6 Next Header value of 58) with ICMPv6 type 133. The AN 328 intercepts and then tunnels the received Router Solicitation in a 329 newly created IPv6 datagram with the Line Identification Option 330 (LIO). The AN forms a new IPv6 datagram whose payload is the 331 received Router Solicitation message as described in [RFC2473] except 332 that the Hop Limit field of the Router Solicitation message MUST NOT 333 be decremented. If the AN has an IPv6 address, it MUST use this 334 address in the Source Address field of the outer IPv6 datagram. 335 Otherwise, the AN MUST copy the source address from the received 336 Router Solicitation into the Source Address field of the outer IPv6 337 datagram. The destination address of the outer IPv6 datagram MUST be 338 copied from the destination address of the tunneled RS. The AN MUST 339 include a destination options header between the outer IPv6 header 340 and the payload. It MUST insert a LIO destination option and set the 341 line identification field of the option to contain the circuit 342 identifier corresponding to the logical access loop port of the AN 343 from which the RS was initiated. 345 5.3. On receiving a Router Advertisement from the Edge Router 347 When the edge router sends out a tunneled Router Advertisement in 348 response to the RS, it is received by the AN. If there is an LIO 349 option present, the AN MUST use the line identification data of the 350 LIO option to identify the subscriber agent circuit of the AN on 351 which the RA should be sent. The AN MUST then remove the outer IPv6 352 header of this tunneled RA and multicast the inner packet (the 353 original RA) on this specific subscriber circuit. 355 5.3.1. Identifying tunneled Router Advertisements 357 The AN can identify tunneled RAs by installing filters based on the 358 destination address (All-BBF-Access-Nodes which is reserved link- 359 local scoped multicast address) of the outer packets, and the 360 presence of a destination option header with an LIO destination 361 option. 363 5.4. On detecting a subscriber circuit coming up 365 RSes initiated by end-devices as described in Section 5.2 may be lost 366 due to lack of connectivity between the AN and the end-device. To 367 ensure that the end-device will receive an RA, the AN needs to 368 trigger the sending of periodic RAs on the edge router. For this 369 purpose, the AN needs to inform the edge router that a subscriber 370 circuit has come up. Each time the AN detects that a subscriber 371 circuit has come up, it MUST create a Router Solicitation message as 372 described in Section 6.3.7 of [RFC4861]. It MUST use the unspecified 373 address as the source address of this RS. It MUST then tunnel this 374 RS towards the edge router as described in Section 5.2. 376 In case there are connectivity issues between the AN and the edge 377 router, the RSes initiated by the AN can be lost. The AN SHOULD 378 continue retransmitting the Router Solicitations following the 379 algorithm described in Section 5.6 for a given LIO until it receives 380 an RA for that specific LIO. 382 5.5. On detecting Edge Router failure 384 When the edge router reboots and loses state or is replaced by a new 385 edge router, the AN will detect it using connectivity check 386 mechanisms that are already in place in Broadband networks (e.g. 387 BFD). When such edge router failure is detected, the AN needs to 388 start transmitting RSes for each of its subscriber circuits that are 389 up as described in Section 5.4. 391 5.6. RS Retransmission algorithm 393 The AN SHOULD use the exponential backoff algorithm for retransmits 394 that is described in Section 14 of [RFC3315] in order to continuously 395 retransmit the Router Solicitations for a given LIO until a response 396 is received for that specific LIO. The AN SHOULD use the following 397 variables as input to the retransmission algorithm: 399 IRT 1 Second 400 MRT 30 Seconds 401 MRC 0 402 MRD 0 404 6. Edge Router Behavior 406 6.1. On receiving a Tunneled Router Solicitation from the AN 408 When the edge router receives a tunneled Router Solicitation 409 forwarded by the AN, it needs to check if there is an LIO destination 410 option present in the outer datagram. The edge router can use the 411 contents of the line identification field to lookup the addressing 412 information and policy that need to be applied to the line from which 413 the Router Solicitation was received. The edge router MUST then 414 process the inner RS message as specified in [RFC4861]. 416 6.2. On sending a Router Advertisement towards the end-device 418 When the edge router sends out a Router Advertisement in response to 419 a tunneled RS that included an LIO option, it MUST tunnel the Router 420 Advertisement in a newly created IPv6 datagram with the Line 421 Identification Option (LIO) as described below. First, The edge 422 router creates the Router Advertisement message as described in 423 Section 6.2.3 of [RFC4861]. The edge router MUST include a Prefix 424 Information Option in this RA that contains the prefix that 425 corresponds to the received LIO (The LIO from the received tunneled 426 RS is usually passed on from the edge router to some form of 427 provisioning system that returns the prefix to be included in the RA. 428 It could e,g, be based on RADIUS.). Then, the Edge Router forms the 429 new IPv6 datagram, whose payload is the Router Advertisement message, 430 as described in [RFC2473] except that the Hop Limit field of the 431 Router Advertisement message MUST NOT be decremented. The Edge 432 router MUST use a link-local IPv6 address on the outgoing interface 433 in the Source Address field of the outer IPv6 datagram. The edge 434 router MUST include a destination options header between the outer 435 IPv6 header and the payload. It MUST insert a LIO destination option 436 and set the line identification field of the option to contain the 437 same value as that of the Line ID option in the received RS. The 438 IPv6 destination address of the inner RA MUST be set to the all-nodes 439 multicast address. 441 If the Source Address field of the received IPv6 datagram was not the 442 unspecified address, the edge router MUST copy this address into the 443 Destination Address field of the outer IPv6 datagram sent back 444 towards the AN. The link-layer destination address of the outer IPv6 445 datagram containing the tunneled RA MUST be resolved using regular 446 Neighbour Discovery procedures. 448 If the Source Address field of the received IPv6 datagram was the 449 unspecified address, the destination address of the outer IPv6 450 datagram MUST be set to the well-known link-local scope All-BBF- 451 Access-Nodes multicast address [to be allocated]. The link-layer 452 destination address of the tunneled RA MUST be set to the unicast 453 link-layer address of the AN that sent the tunneled Router 454 Solicitation which is being responded to. 456 6.3. Sending periodic unsolicited Router Advertisements towards the 457 end-device 459 After sending a tunneled Router Advertisement as specified in 460 Section 6.2 in response to a received RS, the edge router MUST store 461 the mapping between the LIO and the prefixes contained in the Router 462 Advertisement. It should then initiate periodic sending of 463 unsolicited Router Advertisements as described in Section 6.2.3. of 465 [RFC4861] . The Router Advertisements MUST be created and tunneled 466 as described in Section 6.2. The edge router MAY stop sending Router 467 Advertisements if it receives a notification from the AN that the 468 subscriber circuit has gone down. This notification can be received 469 out-of-band using a mechanism such as ANCP. Please consult Section 8 470 for more details. 472 7. Line Identification Destination Option (LIO) 474 The Line Identification Destination Option (LIO) is a destination 475 option that can be included in IPv6 datagrams that tunnel Router 476 Solicitation and Router Advertisement messages. The use of the Line 477 ID option in any other IPv6 datagrams is not defined by this 478 document. Multiple Line Identification destination options MUST NOT 479 be present in the same IPv6 datagram. The LIO has no alignment 480 requirement. 482 0 1 2 3 483 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 484 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 485 | Option Type | Option Length | 486 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 487 | LineIDLen | Line Identification... 488 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 490 Figure 3: Line Identification Destination Option Layout 492 Option Type 494 8-bit identifier of the type of option. The option identifier 495 for the line identification option will be allocated by the IANA. 497 Option Length 499 8-bit unsigned integer. The length of the option (excluding 500 the Option Type and Option Length fields). The value MUST be 501 greater than 0. 503 LineIDLen 505 8-bit unsigned integer. The length of the Line Identification 506 field in number of octets. 508 Line Identification 510 Variable length data inserted by the AN describing the 511 subscriber agent circuit identifier corresponding to the logical 512 access loop port of the AN from which the RS was 513 initiated. The line identification MUST be unique across all the 514 ANs that share a link to the edge router. e.g. One such line 515 identification scheme is described in Section 3.9 of [TR101]. 516 The line idenfication should be encoded as specified in 517 Section 7.1. 519 7.1. Encoding of Line ID 521 This IPv6 Destination Option is derived from an existing widely 522 deployed DHCPv6 Option [RFC4649], which is in turn derived from a 523 widely deployed DHCPv4 Option [RFC3046]. Both of those derive from 524 and cite the basic DHCP options specification [RFC2132]. Those 525 widely deployed DHCP options use the NVT character set 526 [RFC2132][RFC0020]. Since the data carried in the Line ID option is 527 used in the same manner by the provisioning systems as the DHCP 528 options, it is beneficial for it to maintain the same encoding as the 529 DHCP options. 531 The IPv6 Line ID option contains a description which identifies the 532 line, using only character positions (decimal 32 to decimal 126, 533 inclusive) of the US-ASCII character set [X3.4], [RFC0020]. 534 Consistent with [RFC2132], [RFC3046] and [RFC4649], the Line ID field 535 SHOULD NOT contain the US-ASCII NUL character (decimal 0). However, 536 implementations receiving this option MUST NOT fail merely because an 537 ASCII NUL character is (erroneously) present in the Line ID option's 538 data field. 540 Some existing widely deployed implementations of edge routers and ANs 541 that support the previously mentioned DHCP option only support US- 542 ASCII, and strip the high-order bit from any 8-bit characters entered 543 by the device operator. The previously mentioned DHCP options do not 544 support 8-bit character sets either. Therefore, for compatibility 545 with the installed base and to maximise interoperability, the high- 546 order bit of each octet in this field MUST be set to zero by any 547 device inserting this option in an IPv6 packet. 549 Consistent with [RFC3046] and [RFC4649], this option always uses 550 binary comparison. Therefore, two Line IDs MUST be equal when they 551 match when compared byte-by-byte. Line-ID A and Line-ID B match 552 byte-by-byte when (1) A and B have the same number of bytes and (2) 553 for all byte indexes P in A: the value of A at index P has the same 554 binary value as the value of B at index P. 556 Two Line IDs MUST NOT be equal if they do not match byte-by-byte. 557 For example, an IPv6 Line ID option containing "f123" is not equal to 558 a Line ID option "F123". 560 Intermediate systems MUST NOT alter the contents of the Line ID. 562 8. Garbage collection of unused prefixes 564 Following the mechanism described in this document, the Broadband 565 network associates a prefix to a subscriber line based on the LIO. 566 Even when the subscriber line goes down temporarily, this prefix 567 stays allocated to that specific subscriber line. i.e. The prefix is 568 not returned to the unused pool. When a subscriber line no longer 569 needs a prefix, the prefix can be reclaimed by manual action 570 dissociating the prefix from the LIO in the backend systems. 572 9. Interactions with Secure Neighbor Discovery 574 Since the SEND [RFC3971] protected RS/RA packets are not modified in 575 anyway by the mechanism described in this document, there are no 576 issues with SEND verification. 578 10. Acknowledgements 580 The authors would like to thank Margaret Wasserman, Mark Townsley, 581 David Miles, John Kaippallimalil, Eric Levy-Abegnoli, Thomas Narten, 582 Olaf Bonness, Thomas Haag, Wojciech Dec, Brian Haberman, Ole Troan, 583 Hemant Singh, Jari Arkko, Joel Halpern, Bob Hinden, Ran Atkinson, 584 Glen Turner, Kathleen Moriarty, David Sinicrope, Dan Harkins, Stephen 585 Farrell, Barry Leiba, Sean Turner and Ralph Droms for reviewing this 586 document and suggesting changes. 588 11. Security Considerations 590 The line identification information inserted by the AN or the edge 591 router is not protected. This means that this option may be 592 modified, inserted, or deleted without being detected. In order to 593 ensure validity of the contents of the line identification field, the 594 network between the AN and the edge router needs to be trusted. 596 12. IANA Considerations 598 This document defines a new IPv6 destination option for carrying line 599 identification. IANA is requested to assign a new destination option 600 type in the Destination Options registry maintained at 602 http://www.iana.org/assignments/ipv6-parameters 604 Line Identification Option [RFCXXXX] 606 The act bits for this option need to be 10 and the chg bit needs to 607 be 0. 609 This document also requires the allocation of a well-known link-local 610 scope multicast address from the IPv6 Multicast Address Space 611 Registry located at 613 http://www.iana.org/assignments/ipv6-multicast-addresses/ 614 ipv6-multicast-addresses.xml 616 All-BBF-Access-Nodes [RFCXXXX] 618 13. References 620 13.1. Normative References 622 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 623 RFC 1661, July 1994. 625 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 626 Requirement Levels", BCP 14, RFC 2119, March 1997. 628 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 629 IPv6 Specification", RFC 2473, December 1998. 631 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 632 and M. Carney, "Dynamic Host Configuration Protocol for 633 IPv6 (DHCPv6)", RFC 3315, July 2003. 635 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 636 Neighbor Discovery (SEND)", RFC 3971, March 2005. 638 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 639 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 640 September 2007. 642 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 643 Address Autoconfiguration", RFC 4862, September 2007. 645 [TR101] Broadband Forum, "Migration to Ethernet-based DSL 646 aggregation", . 649 [TR124] Broadband Forum, "Functional Requirements for Broadband 650 Residential Gateway Devices", . 654 [TR156] Broadband Forum, "Using GPON Access in the context of TR- 655 101", . 658 [TR177] Broadband Forum, "IPv6 in the context of TR-101", 659 . 661 [X3.4] American National Standards Institute, "American Standard 662 Code for Information Interchange (ASCII)", Standard X3.4 , 663 1968. 665 13.2. Informative References 667 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 668 October 1969. 670 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 671 Extensions", RFC 2132, March 1997. 673 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 674 RFC 3046, January 2001. 676 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 677 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 678 August 2006. 680 Authors' Addresses 682 Suresh Krishnan 683 Ericsson 684 8400 Blvd Decarie 685 Town of Mount Royal, Quebec 686 Canada 688 Email: suresh.krishnan@ericsson.com 690 Alan Kavanagh 691 Ericsson 692 8400 Blvd Decarie 693 Town of Mount Royal, Quebec 694 Canada 696 Email: alan.kavanagh@ericsson.com 698 Balazs Varga 699 Ericsson 700 Konyves Kalman krt. 11. B. 701 1097 Budapest 702 Hungary 704 Email: balazs.a.varga@ericsson.com 706 Sven Ooghe 707 Alcatel-Lucent 708 Copernicuslaan 50 709 2018 Antwerp, 710 Belgium 712 Phone: 713 Email: sven.ooghe@alcatel-lucent.com 715 Erik Nordmark 716 Cisco 717 510 McCarthy Blvd. 718 Milpitas, CA, 95035 719 USA 721 Phone: +1 408 527 6625 722 Email: nordmark@cisco.com