idnits 2.17.1 draft-ietf-6man-lineid-05.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 (June 4, 2012) is 4344 days in the past. Is this intentional? Checking references for intended status: Experimental ---------------------------------------------------------------------------- == Missing Reference: 'RFCXXXX' is mentioned on line 587, but not defined ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) Summary: 1 error (**), 0 flaws (~~), 3 warnings (==), 1 comment (--). 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: Experimental B. Varga 5 Expires: December 6, 2012 Ericsson 6 S. Ooghe 7 Alcatel-Lucent 8 E. Nordmark 9 Cisco 10 June 4, 2012 12 The Line Identification Destination Option 13 draft-ietf-6man-lineid-05 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 December 6, 2012. 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 in an N:1 VLAN model . 6 64 4. Basic operation . . . . . . . . . . . . . . . . . . . . . . . 7 65 5. Access Node Behavior . . . . . . . . . . . . . . . . . . . . . 7 66 5.1. On receiving a Router Solicitation from the end-device . . 7 67 5.2. On receiving a Router Advertisement from the Edge 68 Router . . . . . . . . . . . . . . . . . . . . . . . . . . 8 69 5.2.1. Identifying tunneled Router Advertisements . . . . . . 8 70 5.3. On detecting a subscriber circuit coming up . . . . . . . 8 71 5.4. On detecting Edge Router failure . . . . . . . . . . . . . 9 72 5.5. RS Retransmission algorithm . . . . . . . . . . . . . . . 9 73 6. Edge Router Behavior . . . . . . . . . . . . . . . . . . . . . 9 74 6.1. On receiving a Tunneled Router Solicitation from the 75 Access Node . . . . . . . . . . . . . . . . . . . . . . . 9 76 6.2. On sending a Router Advertisement towards the 77 end-device . . . . . . . . . . . . . . . . . . . . . . . . 9 78 6.3. Sending periodic unsolicited Router Advertisements 79 towards the end-device . . . . . . . . . . . . . . . . . . 10 80 7. Line Identification Destination Option (LIO) . . . . . . . . . 10 81 7.1. Encoding of Line ID . . . . . . . . . . . . . . . . . . . 11 82 8. Garbage collection of unused prefixes . . . . . . . . . . . . 12 83 9. Interactions with Secure Neighbor Discovery . . . . . . . . . 12 84 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 13 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 89 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 92 1. Introduction 94 Digital Subscriber Line (DSL) is a widely deployed access technology 95 for Broadband Access for Next Generation Networks. While traditional 96 DSL access networks were Point-to-Point Protocol (PPP) [RFC1661] 97 based, some networks are migrating from the traditional PPP access 98 model into a pure IP-based Ethernet aggregated access environment. 99 Architectural and topological models of an Ethernet aggregation 100 network in the context of DSL aggregation are described in [TR101]. 102 +----+ +----+ +----------+ 103 |Host|---| RG |----| | 104 +----+ +----+ | | 105 | AN |\ 106 +----+ +----+ | | \ 107 |Host|---| RG |----| | \ 108 +----+ +----+ +----------+ \ +----------+ 109 \ | | 110 +-------------+ | | 111 | Aggregation | | Edge | 112 | Network |-------| Router | 113 +-------------+ | | 114 / | | 115 +----------+ / +----------+ 116 | | / 117 +----+ +----+ | | / 118 |Host|---| RG |----| AN |/ 119 +----+ +----+ | | 120 | | 121 +----------+ 123 Figure 1: Broadband Forum Network Architecture 125 One of the Ethernet and Gigabit Passive Optical Network (GPON) 126 aggregation models specified in this document bridges sessions from 127 multiple user ports behind a DSL Access Node (AN), also referred to 128 as a Digital subscriber line access multiplexer (DSLAM), into a 129 single VLAN in the aggregation network. This is called the N:1 VLAN 130 allocation model. 132 +----------+ 133 | | 134 | | 135 | AN |\ 136 | | \ 137 | | \ VLANx 138 +----------+ \ +----------+ 139 \ | | 140 +-------------+ | | 141 | Aggregation | VLANx | Edge | 142 | Network |-------| Router | 143 +-------------+ | | 144 / | | 145 +----------+ / +----------+ 146 | | / VLANx 147 | | / 148 | AN |/ 149 | | 150 | | 151 +----------+ 153 Figure 2: n:1 VLAN model 155 1.1. Terminology 157 1:1 VLAN It is a broadband network deployment 158 scenario where each user port is mapped to 159 a different VLAN on the Edge Router. The 160 uniqueness of the mapping is maintained in 161 the Access Node and across the Aggregation 162 Network. 163 N:1 VLAN It is a broadband network deployment 164 scenario where multiple user ports are 165 mapped to the same VLAN on the Edge Router. 166 The user ports may be located in the same 167 or different Access Nodes. 168 AN A DSL or a Gigabit Passive Optical Network 169 (GPON) Access Node. The Access Node 170 terminates the physical layer (e.g. DSL 171 termination function or GPON termination 172 function), may physically aggregate other 173 nodes implementing such functionality, or 174 may perform both functions at the same 175 time. This node contains at least one 176 standard Ethernet interface that serves as 177 its "northbound" interface into which it 178 aggregates traffic from several user ports 179 or Ethernet-based "southbound" interfaces. 181 It does not implement an IPv6 stack but 182 performs some limited inspection/ 183 modification of IPv6 packets. The IPv6 184 functions required on the Access Node are 185 described in Section 5 of [TR177]. 186 Aggregation Network The part of the network stretching from the 187 Access Nodes to the Edge Router. In the 188 context of this document the aggregation 189 network is considered to be Ethernet based, 190 providing standard Ethernet interfaces at 191 the edges, for connecting the Access Nodes 192 and Broadband Network. It is comprised of 193 ethernet switches that provide very limited 194 IP functionality (e.g. IGMP snooping, MLD 195 snooping etc.). 196 Edge Router The Edge Router, also known as the 197 Broadband Network Gateway (BNG) is the 198 first IPv6 hop for the user. In the cases 199 where the Residential Gateway (RG) is 200 bridged, the BNG acts as the default router 201 for the hosts behind the RG. In cases 202 where the RG is routed, the BNG acts as the 203 default router for the RG itself. This 204 node implements IPv6 router functionality. 205 GPON Gigabit-capable Passive Optical Network is 206 an optical access network that has been 207 introduced into the Broadband Forum 208 architecture in [TR156] 209 Host A node that implements IPv6 host 210 functionality. 211 RG A residential gateway device. It can be a 212 Layer 3 (routed) device or a Layer 2 213 (bridged) device. The residential gateway 214 for Broadband Forum networks is defined in 215 [TR124] 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. 236 When the Dynamic Host Configuration Protocol (DHCP) [RFC3315] is used 237 for IPv6 address assignment it has the side-effect of including 238 reliability initiated by the end-device (the end-device retransmits 239 DHCP messages until it receives a response), as well as a way to 240 detect when the end-device is not active for an extended period of 241 time (the end-device would not renew its DHCP lease). The IPv6 242 Stateless address autoconfiguration protocol [RFC4862] was not 243 designed to satisfy such requirements. While this protocol improves 244 the the robustness of relying on Router Solicitations in lieu of 245 DHCP, this results on some limitations specified below. 247 The mechanism described in this document deals with the loss of 248 subscriber-originated Router Solicitations (RSes) by initiating RSes 249 at the Access Node, which improves the robustness over solely relying 250 on the end-device's few initial retransmissions of RSes. But the AN 251 retransmissions imply that some information (e.g. the subscriber's 252 MAC address) that was obtained by the edge router from subscriber- 253 originated RSes may no longer be available. e.g. Since there is no 254 L2 frame received from the subscriber in case of an RS sent by an AN, 255 the L2 address information of the host cannot be determined. One 256 piece of L2 address information currently used in Broadband networks 257 is the MAC address. For this reason, the solution described in this 258 document is NOT RECOMMENDED for networks that require the MAC address 259 of the endpoint for identification. 261 There is no indication when a subscriber is no longer active. Thus 262 this protocol can not be used to automatically reclaim resources, 263 such as prefixes, that are associated with an active subscriber. See 264 Section 8. Thus this protocol is NOT RECOMMENDED for networks that 265 require automatic notification when a subscriber is no longer active. 267 This mechanism by itself provides no protection against the loss of 268 RS induced state in access routers that would lead to loss of IPv6 269 connectivity for hosts. Given that regular IPv6 hosts do not have RS 270 retransmission behavior that would allow automatic recovery from such 271 a failure, this mechanism is considered experimental and SHOULD only 272 be used in deployments employing N:1 VLANs. 274 3. Issues with identifying the subscriber in an N:1 VLAN model 276 In a DSL or GPON based fixed Broadband Network, IPv6 end-devices are 277 connected to an Access Node (AN). These end-devices today will 278 typically send a Router Solicitation Message to the Edge Router, to 279 which the Edge Router responds with a Router Advertisement message. 280 The Router Advertisement typically contains a prefix that the end- 281 devices will use to automatically configure an IPv6 Address. Upon 282 sending the Router Solicitation message the node connecting the end- 283 device on the access circuit, typically an Access Node (AN), would 284 forward the RS to the Edge Router upstream over a switched network. 285 However, in such Ethernet-based aggregation networks, several 286 subscriber premises may be connected to the same interface of an edge 287 router (e.g. on the same VLAN). However, the edge router requires 288 some information to identify the end-device on the circuit. To 289 accomplish this, the AN needs to add line identification information 290 to the Router Solicitation message and forward this to the Edge 291 Router. This is analogous to the case where DHCP is being used, and 292 the line identification information is inserted by a DHCP relay agent 293 [RFC3315]. This document proposes a method for the edge router to 294 identify the subscriber premises using the contents of the received 295 Router Solicitation messages. 297 4. Basic operation 299 This document recommends tunneling Neighbor discovery packets inside 300 another IPv6 packet that uses a destination option to convey line 301 identification information. The Neighbor discovery packets are left 302 unmodified inside the encapsulating IPv6 packet. In particular, the 303 Hop Limit field of the Neighbor Discovery (ND) message is not 304 decremented when the packet is being tunneled. This is because ND 305 messages whose Hop Limit is not 255 will be discarded by the receiver 306 of such messages. 308 5. Access Node Behavior 310 5.1. On receiving a Router Solicitation from the end-device 312 When an end-device sends out a Router Solicitation, it is received by 313 the access node. The AN identifies these messages by looking for 314 ICMPv6 messages (IPv6 Next Header value of 58) with ICMPv6 type 133. 315 The AN intercepts and then tunnels the received Router Solicitation 316 in a newly created IPv6 datagram with the Line Identification Option 317 (LIO). The AN forms a new IPv6 datagram whose payload is the 318 received Router Solicitation message as described in [RFC2473] except 319 that the Hop Limit field of the Router Solicitation message MUST NOT 320 be decremented.If the AN has an IPv6 address, it MUST use this 321 address in the Source Address field of the outer IPv6 datagram. 322 Otherwise, when the end-device sends out a Router Solicitation and 323 uses a link-local address in the Source Address field, the AN MUST 324 copy this address into the Source Address field of the outer IPv6 325 datagram. In all other cases, the AN MUST use the unspecified 326 address as the Source Address of the outer IPv6 datagram. The 327 destination address of the outer IPv6 datagram MUST be copied from 328 the destination address of the tunneled RS. The AN MUST include a 329 destination options header between the outer IPv6 header and the 330 payload. It MUST insert a LIO destination option and set the line 331 identification field of the option to contain the circuit identifier 332 corresponding to the logical access loop port of the Access Node from 333 which the RS was initiated. 335 5.2. On receiving a Router Advertisement from the Edge Router 337 When the edge router sends out a tunneled Router Advertisement in 338 response to the RS, it is received by the access node. If there is 339 an LIO option present, the AN MUST use the line identification data 340 of the LIO option to identify the subscriber agent circuit of the 341 Access Node on which the RA should be sent. The AN MUST then remove 342 the outer IPv6 header of this tunneled RA and multicast the inner 343 packet (the original RA) on this specific subscriber circuit. 345 5.2.1. Identifying tunneled Router Advertisements 347 The Access Node can identify tunneled RAs by installing filters based 348 on the destination address (All BBF Access Nodes) of the outer 349 packets, and the presence of a destination option header with an LIO 350 destination option. 352 5.3. On detecting a subscriber circuit coming up 354 RSes initiated by end-devices as described in Section 5.1 may be lost 355 due to lack of connectivity between the access node and the end- 356 device. To ensure that the end-device will receive an RA, the AN 357 needs to trigger the sending of periodic RAs on the edge router. For 358 this purpose, the AN needs to inform the edge router that a 359 subscriber circuit has come up. When the access node detects that a 360 subscriber circuit has come up, it MUST create a Router Solicitation 361 message as described in Section 6.3.7 of [RFC4861]. It MUST use the 362 unspecified address as the source address of this RS. It MUST then 363 tunnel this RS towards the edge router as described in Section 5.1. 365 In case there are connectivity issues between the AN and the edge 366 router, the RSes initiated by the AN can be lost. The AN SHOULD 367 continue retransmitting the Router Solicitations following the 368 algorithm described in Section 5.5 for a given LIO until it receives 369 an RA for that specific LIO. 371 5.4. On detecting Edge Router failure 373 When the edge router reboots and loses state or is replaced by a new 374 edge router, the AN will detect it using connectivity check 375 mechanisms that are already in place in Broadband networks (e.g. 376 BFD). When such edge router failure is detected, the AN needs to 377 start transmitting RSes for each of its subscriber circuits that are 378 up as described in Section 5.3. 380 5.5. RS Retransmission algorithm 382 The AN SHOULD use the exponential backoff algorithm for retransmits 383 that is described in Section 14 of [RFC3315] in order to continuously 384 retransmit the Router Solicitations for a given LIO until a response 385 is received for that specific LIO. The AN SHOULD use the following 386 variables as input to the retransmission algorithm: 388 IRT 1 Second 389 MRT 30 Seconds 390 MRC 0 391 MRD 0 393 6. Edge Router Behavior 395 6.1. On receiving a Tunneled Router Solicitation from the Access Node 397 When the edge router receives a tunneled Router Solicitation 398 forwarded by the access node, it needs to check if there is an LIO 399 destination option present in the outer datagram. The edge router 400 can use the contents of the line identification field to lookup the 401 addressing information and policy that need to be applied to the line 402 from which the Router Solicitation was received. The edge router 403 MUST then process the inner RS message as specified in [RFC4861]. 405 6.2. On sending a Router Advertisement towards the end-device 407 When the edge router sends out a Router Advertisement in response to 408 a tunneled RS that included an LIO option, it MUST tunnel the Router 409 Advertisement in a newly created IPv6 datagram with the Line 410 Identification Option (LIO). The edge router creates the Router 411 Advertisement message as described in Section 6.2.3 of [RFC4861]. 412 The edge router MUST include a Prefix Information Option in this RA 413 that contains the prefix that corresponds to the received LIO. The 414 edge router may use the contents of the LIO in the received router 415 solicitation to determine the contents of this Router Advertisement. 416 The Edge Router then forms a new IPv6 datagram, whose payload is the 417 Router Advertisement message, as described in [RFC2473] except that 418 the Hop Limit field of the Router Advertisement message MUST NOT be 419 decremented. The Edge router MUST use a link-local IPv6 address on 420 the outgoing interface in the Source Address field of the outer IPv6 421 datagram. If the Source Address field of the received IPv6 datagram 422 was not the unspecified address, the Edge router MUST copy this 423 address into the Destination Address field of the outer IPv6 datagram 424 sent back towards the Access Node. The link-layer destination 425 address of the tunneled RA MUST be resolved using regular Neighbour 426 Discovery procedures. Otherwise, the destination address of the 427 outer IPv6 datagram MUST be set to the well-known link-local scope 428 All-BBF-Access-Nodes multicast address [to be allocated]. The edge 429 router MUST include a destination options header between the outer 430 IPv6 header and the payload. It MUST insert a LIO destination option 431 and set the line identification field of the option to contain the 432 circuit identifier corresponding to the logical access loop port of 433 the Access Node to which the RA MUST be sent. The IPv6 destination 434 address of the inner RA MUST be set to the all-nodes multicast 435 address. The link-layer destination address of the tunneled RA MUST 436 be set to the unicast link-layer address of the Access Node that sent 437 the tunneled Router Solicitation which is being responded to. 439 6.3. Sending periodic unsolicited Router Advertisements towards the 440 end-device 442 After sending a tunneled Router Advertisement as specified in 443 Section 6.2 in response to a received RS, the edge router MUST store 444 the mapping between the LIO and the prefixes contained in the Router 445 Advertisement. It should then initiate periodic sending of 446 unsolicited Router Advertisements as described in Section 6.2.3. of 447 [RFC4861] . The Router Advertisements MUST be created and tunneled 448 as described in Section 6.2. The edge router MAY stop sending Router 449 Advertisements if it receives a notification from the AN that the 450 subscriber circuit has gone down. This notification can be received 451 out-of-band using a mechanism such as ANCP. 453 7. Line Identification Destination Option (LIO) 455 The Line Identification Destination Option (LIO) is a destination 456 option that can be included in IPv6 datagrams that tunnel Router 457 Solicitation and Router Advertisement messages. Multiple Line 458 Identification destination options MUST NOT be present in the same 459 IPv6 datagram. The LIO has no alignment requirement. 461 0 1 2 3 462 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 463 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 464 | Option Type | Option Length | 465 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 466 | LineIDLen | Line Identification... 467 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 469 Figure 3: Line Identification Destination Option Layout 471 Option Type 473 8-bit identifier of the type of option. The option identifier 474 for the line identification option will be allocated by the IANA. 476 Option Length 478 8-bit unsigned integer. The length of the option (excluding 479 the Option Type and Option Length fields). The value MUST be 480 greater than 0. 482 LineIDLen 484 Length of the Line Identification field in number of octets. 486 Line Identification 488 Variable length data inserted by the Access Node describing the 489 subscriber agent circuit identifier corresponding to the logical 490 access loop port of the Access Node from which the RS was 491 initiated. The line idenfication should be encoded as specified 492 in Section 7.1. 494 7.1. Encoding of Line ID 496 This IPv6 Destination Option is derived from an existing widely 497 deployed DHCPv6 Option [RFC4649], which is in turn derived from a 498 widely deployed DHCPv4 Option [RFC3046]. Both of those derive from 499 and cite the basic DHCP options specification [RFC2132]. Those 500 widely deployed DHCP options use the NVT character set 501 [RFC2132][RFC0020]. 503 The IPv6 Line ID option contains a description which identifies the 504 line, using only character positions (decimal 32 to decimal 126, 505 inclusive) of the US-ASCII character set [X3.4], [RFC0020]. 506 Consistent with [RFC2132], [RFC3046] and [RFC4649], the Line ID field 507 SHOULD NOT contain the US-ASCII NUL character (decimal 0). However, 508 implementations receiving this option MUST NOT fail merely because an 509 ASCII NUL character is (erroneously) present in the Line ID option's 510 data field. 512 Some existing widely deployed implementations of edge routers and 513 access nodes that support the previously mentioned DHCP option only 514 support US-ASCII, and strip the high-order bit from any 8-bit 515 characters entered by the device operator. The previously mentioned 516 DHCP options do not support 8-bit character sets either. Therefore, 517 for compatibility with the installed base and to maximise 518 interoperability, the high-order bit of each octet in this field MUST 519 be set to zero by any device inserting this option in an IPv6 packet. 521 Consistent with [RFC3046] and [RFC4649], this option always uses 522 binary comparison. Therefore, two Line IDs MUST be equal when they 523 match when compared byte-by-byte. Line-ID A and Line-ID B match 524 byte-by-byte when (1) A and B have the same number of bytes and (2) 525 for all byte indexes P in A: the value of A at index P has the same 526 binary value as the value of B at index P. 528 Two Line IDs MUST NOT be equal if they do not match byte-by-byte. 529 For example, an IPv6 Line ID option containing "f123" is not equal to 530 a Line ID option "F123". 532 Intermediate systems MUST NOT alter the contents of the Line ID. 534 8. Garbage collection of unused prefixes 536 Following the mechanism described in this document, the Broadband 537 network associates a prefix to a subscriber line based on the LIO. 538 Even when the subscriber line goes down temporarily, this prefix 539 stays allocated to that specific subscriber line. i.e. The prefix is 540 not returned to the unused pool. When a subscriber line no longer 541 needs a prefix, the prefix can be reclaimed by manual action 542 dissociating the prefix from the LIO in the backend systems. 544 9. Interactions with Secure Neighbor Discovery 546 Since the SEND [RFC3971] protected RS/RA packets are not modified in 547 anyway by the mechanism described in this document, there are no 548 issues with SEND verification. 550 10. Acknowledgements 552 The authors would like to thank Margaret Wasserman, Mark Townsley, 553 David Miles, John Kaippallimalil, Eric Levy-Abegnoli, Thomas Narten, 554 Olaf Bonness, Thomas Haag, Wojciech Dec, Brian Haberman, Ole Troan, 555 Hemant Singh, Jari Arkko, Joel Halpern, Bob Hinden, Ran Atkinson and 556 Glen Turner for reviewing this document and suggesting changes. 558 11. Security Considerations 560 The line identification information inserted by the access node or 561 the edge router is not protected. This means that this option may be 562 modified, inserted, or deleted without being detected. In order to 563 ensure validity of the contents of the line identification field, the 564 network between the access node and the edge router needs to be 565 trusted. 567 12. IANA Considerations 569 This document defines a new IPv6 destination option for carrying line 570 identification. IANA is requested to assign a new destination option 571 type in the Destination Options registry maintained at 573 http://www.iana.org/assignments/ipv6-parameters 575 Line Identification Option [RFCXXXX] 577 The act bits for this option need to be 10 and the chg bit needs to 578 be 0. 580 This document also requires the allocation of a well-known link-local 581 scope multicast address from the IPv6 Multicast Address Space 582 Registry located at 584 http://www.iana.org/assignments/ipv6-multicast-addresses/ 585 ipv6-multicast-addresses.xml 587 All BBF Access Nodes [RFCXXXX] 589 13. References 591 13.1. Normative References 593 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 594 RFC 1661, July 1994. 596 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 597 Requirement Levels", BCP 14, RFC 2119, March 1997. 599 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 600 IPv6 Specification", RFC 2473, December 1998. 602 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 603 and M. Carney, "Dynamic Host Configuration Protocol for 604 IPv6 (DHCPv6)", RFC 3315, July 2003. 606 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 607 Neighbor Discovery (SEND)", RFC 3971, March 2005. 609 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 610 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 611 September 2007. 613 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 614 Address Autoconfiguration", RFC 4862, September 2007. 616 [TR101] Broadband Forum, "Migration to Ethernet-based DSL 617 aggregation", . 620 [TR124] Broadband Forum, "Functional Requirements for Broadband 621 Residential Gateway Devices", . 625 [TR156] Broadband Forum, "Using GPON Access in the context of TR- 626 101", . 629 [TR177] Broadband Forum, "IPv6 in the context of TR-101", 630 . 632 [X3.4] American National Standards Institute, "American Standard 633 Code for Information Interchange (ASCII)", Standard X3.4 , 634 1968. 636 13.2. Informative References 638 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 639 October 1969. 641 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 642 Extensions", RFC 2132, March 1997. 644 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 645 RFC 3046, January 2001. 647 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 648 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 649 August 2006. 651 Authors' Addresses 653 Suresh Krishnan 654 Ericsson 655 8400 Blvd Decarie 656 Town of Mount Royal, Quebec 657 Canada 659 Email: suresh.krishnan@ericsson.com 661 Alan Kavanagh 662 Ericsson 663 8400 Blvd Decarie 664 Town of Mount Royal, Quebec 665 Canada 667 Email: alan.kavanagh@ericsson.com 669 Balazs Varga 670 Ericsson 671 Konyves Kalman krt. 11. B. 672 1097 Budapest 673 Hungary 675 Email: balazs.a.varga@ericsson.com 677 Sven Ooghe 678 Alcatel-Lucent 679 Copernicuslaan 50 680 2018 Antwerp, 681 Belgium 683 Phone: 684 Email: sven.ooghe@alcatel-lucent.com 685 Erik Nordmark 686 Cisco 687 510 McCarthy Blvd. 688 Milpitas, CA, 95035 689 USA 691 Phone: +1 408 527 6625 692 Email: nordmark@cisco.com