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