idnits 2.17.1 draft-ietf-6man-lineid-03.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 (March 2, 2012) is 4435 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 574, 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: September 3, 2012 Ericsson 6 S. Ooghe 7 Alcatel-Lucent 8 E. Nordmark 9 Cisco 10 March 2, 2012 12 The Line Identification Destination Option 13 draft-ietf-6man-lineid-03 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 September 3, 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 . . . . . . . . . . . . . 8 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 . . . . . . . . . . . . . . . . . . . . . . . 12 85 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 86 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 88 13.1. Normative References . . . . . . . . . . . . . . . . . . . 13 89 13.2. Informative References . . . . . . . . . . . . . . . . . . 14 90 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 92 1. Introduction 94 Digital Subscriber Line (DSL) is a widely deployed access technology 95 for Broadband Access for Next Generation Networks. While 96 traditionally DSL access networks were Point-to-Point Protocol (PPP) 97 [RFC1661] based some networks are migrating from the traditional PPP 98 access model into a pure IP-based Ethernet aggregated access 99 environment. Architectural and topological models of an Ethernet 100 aggregation network in context of DSL aggregation are described in 101 [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 GPON aggregation models specified in this 127 document bridges sessions from multiple user ports behind a DSL 128 Access Node (AN), also referred to as a Digital subscriber line 129 access multiplexer (DSLAM), into a single VLAN in the aggregation 130 network. This is called the N:1 VLAN 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 RG is bridged, the BNG acts as 200 the default router for the hosts behind the 201 RG. In cases where the RG is routed, the 202 BNG acts as the default router for the RG 203 itself. This node implements IPv6 router 204 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 similar to one 213 specified in or a Layer 2 (bridged) device. 214 The residential gateway for Broadband Forum 215 networks is defined in [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 DHCP is used for IPv6 address assignment it has the side-effect 237 of including reliability initiated by the end-device (the end-device 238 retransmits DHCP messages until it receives a response), as well as a 239 way to detect when the end-device is not active for an extended 240 period of time (the end-device would not renew its DHCP lease). IPv6 241 Stateless address autoconfiguration was not designed to satisfy such 242 requirements. While this protocol improves the the robustness of 243 relying on Router Solicitations in lieu of DHCP, this results on some 244 limitations specified below. 246 The mechanism described in this document deals with the loss of 247 subscriber-originated Router Solicitations by initiating RSs at the 248 Access Node, which improves the robustness over solely relying on the 249 end-device's few initial retransmissions of RSs. But the AN 250 retransmissions imply that some information that was obtained by the 251 network from subscriber-originated RSs may no longer be available. 252 e.g. Since there is no L2 frame received from the subscriber in case 253 of an RS sent by an AN, the L2 address information of the host cannot 254 be determined. One piece of L2 address information currently used in 255 Broadband networks is the MAC address. For this reason, the solution 256 described in this document is NOT RECOMMENDED for networks that 257 require the MAC address of the endpoint for identification. 259 There is no indication when a subscriber is no longer active. Thus 260 this protocol can not be used to automatically reclaim resources, 261 such as prefixes, that are associated with an active subscriber. See 262 Section 8. Thus this protocol is NOT RECOMMENDED for networks that 263 require automatic notification when a subscriber is no longer active. 265 This mechanism by itself provides no protection against the loss of 266 RS induced state in access routers that would lead to loss of IPv6 267 connectivity for hosts. Given that regular IPv6 hosts do not have RS 268 retransmission behavior that would allow automatic recovery from such 269 a failure, this mechanism is considered experimental and NOT 270 RECOMMENDED for general deployments. 272 3. Issues with identifying the subscriber in an N:1 VLAN model 274 In a DSL or GPON based fixed Broadband Network, IPv6 end-devices are 275 connected to an Access Node (AN). These end-devices today will 276 typically send a Router Solicitation Message to the Edge Router, to 277 which the Edge Router responds with a Router Advertisement message. 278 The Router Advertisement typically contains a prefix that the end- 279 devices will use to automatically configure an IPv6 Address. Upon 280 sending the Router Solicitation message the node connecting the end- 281 device on the access circuit, typically an Access Node (AN), would 282 forward the RS to the Edge Router upstream over a switched network. 283 However, in such Ethernet-based aggregation networks, several 284 subscriber premises may be connected to the same interface of an edge 285 router (e.g. on the same VLAN). However, the edge router requires 286 some information to identify the end-device on the circuit the end- 287 device is connected on. To accomplish this, the AN needs to add line 288 identification information to the Router Solicitation message and 289 forward this to the Edge Router. This is analogous to the case where 290 DHCP is being used, and the line identification information is 291 inserted by a DHCP relay agent. This document proposes a method for 292 the edge router to identify the subscriber premises using the 293 contents of the received Router Solicitation messages. 295 4. Basic operation 297 This document recommends tunneling Neighbor discovery packets inside 298 another IPv6 packet that uses a destination option to convey line 299 identification information. The Neighbor discovery packets are left 300 unmodified inside the encapsulating IPv6 packet. In particular, the 301 Hop Limit field of the ND message is not decremented when the packet 302 is being tunneled. This is because ND messages whose Hop Limit is 303 not 255 will be discarded by the receiver of such messages. 305 5. Access Node Behavior 307 5.1. On receiving a Router Solicitation from the end-device 309 When an end-device sends out a Router Solicitation, it is received by 310 the access node. The AN identifies these messages by looking for 311 ICMPv6 messages (IPv6 Next Header value of 58) with ICMPv6 type 133. 312 The AN intercepts and then tunnels the received Router Solicitation 313 in a newly created IPv6 datagram with the Line Identification Option 314 (LIO). The AN forms a new IPv6 datagram whose payload is the 315 received Router Solicitation message as described in [RFC2473] except 316 that the Hop Limit field of the Router Solicitation message MUST NOT 317 be decremented. If the AN has an IPv6 address, it SHOULD use this 318 address in the Source Address field of the outer IPv6 datagram. 319 Otherwise it MUST use the unspecified address as the Source Address 320 of the outer IPv6 datagram. The destination address of the outer 321 IPv6 datagram MUST be copied from the destination address of the 322 tunneled RS. The AN MUST insert a destination options header between 323 the outer IPv6 header and the payload. It MUST insert a LIO 324 destination option and set the line identification field of the 325 option to contain the circuit identifier corresponding to the logical 326 access loop port of the Access Node from which the RS was initiated. 328 5.2. On receiving a Router Advertisement from the Edge Router 330 When the edge router sends out a tunneled router advertisement in 331 response to the RS, it is received by the access node. If there is 332 an LIO option present, the AN MUST use the line identification data 333 of the LIO option to identify the subscriber agent circuit of the 334 Access Node on which the RA should be sent. The AN MUST then remove 335 the outer IPv6 header of this tunneled RA and multicast the inner 336 packet (the original RA) on this specific subscriber circuit. 338 5.2.1. Identifying tunneled Router Advertisements 340 The Access Node can identify tunneled RAs by installing filters based 341 on the destination address (All BBF Access Nodes) of the outer 342 packets, and the presence of a destination option header with an LIO 343 destination option. 345 5.3. On detecting a subscriber circuit coming up 347 RSs initiated by end-devices as described in Section 5.1 may be lost 348 due to lack of connectivity between the access node and the end- 349 device. To ensure that the end-device will receive an RA, the AN 350 needs to trigger the sending of periodic RAs on the edge router. For 351 this purpose, the AN needs to inform the edge router that a 352 subscriber circuit has come up. When the access node detects that a 353 subscriber circuit has come up, it MUST create a Router Solicitation 354 message as described in Section 6.3.7 of [RFC4861]. It MUST use the 355 unspecified address as the source address of this RS. It MUST then 356 tunnel this RS towards the edge router as described in Section 5.1. 358 In case there are connectivity issues between the AN and the edge 359 router, the RSs initiated by the AN can be lost. The AN SHOULD 360 continue retransmitting the Router Solicitations following the 361 algorithm described in Section 5.5 for a given LIO until it receives 362 an RA for that specific LIO. 364 5.4. On detecting Edge Router failure 366 When the edge router reboots and loses state or is replaced by a new 367 edge router, the AN will detect it using connectivity check 368 mechanisms that are already in place in Broadband networks (e.g. 369 BFD). When such edge router failure is detected, the AN needs to 370 start transmitting RSs for each of its subscriber circuits that are 371 up as described in Section 5.3. 373 5.5. RS Retransmission algorithm 375 The AN SHOULD use the exponential backoff algorithm for retransmits 376 that is described in Section 14 of [RFC3315] in order to continuously 377 retransmit the Router Solicitations for a given LIO until a response 378 is received for that specific LIO. The AN SHOULD use the following 379 variables as input to the retransmission algorithm: 381 IRT 1 Second 382 MRT 30 Seconds 383 MRC 0 384 MRD 0 386 6. Edge Router Behavior 388 6.1. On receiving a Tunneled Router Solicitation from the Access Node 390 When the edge router receives a tunneled Router Solicitation 391 forwarded by the access node, it needs to check if there is an LIO 392 destination option present in the outer datagram. The edge router 393 can use the contents of the line identification field to lookup the 394 addressing information and policy that need to be applied to the line 395 from which the Router Solicitation was received. The edge router 396 MUST then process the inner RS message as specified in [RFC4861] 398 6.2. On sending a Router Advertisement towards the end-device 400 When the edge router sends out a Router Advertisement in response to 401 a tunneled RS that included an LIO option, it MUST tunnel the Router 402 Advertisement in a newly created IPv6 datagram with the Line 403 Identification Option (LIO). The edge router creates the Router 404 Advertisement message as described in Section 6.2.3 of [RFC4861]. 405 The edge router may use the contents of the LIO in the received 406 router solicitation to determine the contents of this router 407 advertisement(es. The Edge Router then forms a new IPv6 datagram, 408 whose payload is the Router Advertisement message, as described in 409 [RFC2473] except that the Hop Limit field of the Router Advertisement 410 message MUST NOT be decremented. The Edge router MUST use a link- 411 local IPv6 address on the outgoing interface in the Source Address 412 field of the outer IPv6 datagram. The destination address of the 413 outer IPv6 datagram MUST be set to the well-known link-local scope 414 All BBF Access Nodes multicast address [to be allocated]. The edge 415 router MUST insert a destination options header between the outer 416 IPv6 header and the payload. It MUST insert a LIO destination option 417 and set the line identification field of the option to contain the 418 circuit identifier corresponding to the logical access loop port of 419 the Access Node to which the RA MUST be sent. The IPv6 destination 420 address of the inner RA MUST be set to the all-nodes multicast 421 address. The link-layer destination address of the tunneled RA MUST 422 be set to the unicast link-layer address of the Access Node that sent 423 the tunneled Router Solicitation which is being responded to. 425 6.3. Sending periodic unsolicited Router Advertisements towards the 426 end-device 428 After sending a tunneled Router Advertisement as specified in 429 Section 6.2 in response to a received RS, the edge router MUST store 430 the mapping between the LIO and the prefixes contained in the Router 431 Advertisement. It should then initiate periodic sending of 432 unsolicited Router Advertisements as described in Section 6.2.3. of 433 [RFC4861] . The Router Advertisements MUST be created and tunneled 434 as described in Section 6.2. The edge router MAY stop sending Router 435 Advertisements if it receives a notification from the AN that the 436 subscriber circuit has gone down. This notification can be received 437 out-of-band using a mechanism such as ANCP. 439 7. Line Identification Destination Option (LIO) 441 The Line Identification Destination Option (LIO) is a destination 442 option that can be included in IPv6 datagrams that tunnel Router 443 Solicitation and Router Advertisement messages. Multiple Line 444 Identification destination options MUST NOT be present in the same 445 IPv6 datagram. The LIO has an alignment requirement of (none). 447 0 1 2 3 448 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 449 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 450 | Option Type | Option Length | 451 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 | LineIDLen | Line Identification... 453 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 455 Figure 3: Line Identification Destination Option Layout 457 Option Type 459 8-bit identifier of the type of option. The option identifier 460 for the line identification option will be allocated by the IANA. 462 Option Length 464 8-bit unsigned integer. The length of the option (excluding 465 the Option Type and Option Length fields). The value 0 is 466 considered invalid. 468 LineIDLen 470 Length of the Line Identification field in number of octets. 472 Line Identification 474 Variable length data inserted by the Access Node describing the 475 subscriber agent circuit identifier corresponding to the logical 476 access loop port of the Access Node from which the RS was 477 initiated. The line idenfication should be encoded as specified 478 in Section 7.1. 480 7.1. Encoding of Line ID 482 This IPv6 Destination Option is derived from an existing widely 483 deployed DHCPv6 Option [RFC4649], which is in turn derived from a 484 widely deployed DHCPv4 Option [RFC3046]. Both of those derive from 485 and cite the basic DHCP options specification [RFC2132]. Those 486 widely deployed DHCP options use the NVT character set 487 [RFC2132][RFC0020] 489 The IPv6 Line ID option contains a description which identifies the 490 line, using only character positions (decimal 32 to decimal 126, 491 inclusive) of the US-ASCII character set [X3.4], [RFC0020]. 492 Consistent with [RFC2132], [RFC3046] and [RFC4649], the Line ID field 493 SHOULD NOT contain the US-ASCII NUL character (decimal 0). However, 494 implementations receiving this option MUST NOT fail merely because an 495 ASCII NUL character is (erroneously) present in the Line ID option's 496 data field. 498 Some existing widely deployed implementations of edge routers and 499 access nodes that support the previously mentioned DHCP option only 500 support US-ASCII, and strip the high-order bit from any 8-bit 501 characters entered by the device operator. The previously mentioned 502 DHCP options do not support 8-bit character sets either. Therefore, 503 for compatibility with the installed base and to maximise 504 interoperability, the high-order bit of each octet in this field MUST 505 be set to zero by any device inserting this option in an IPv6 packet. 507 Consistent with [RFC3046] and [RFC4649], this option always uses 508 binary comparison. Therefore, two Line IDs MUST be equal when they 509 match when compared byte-by-byte. Line-ID A and Line-ID B match 510 byte-by-byte when (1) A and B have the same number of bytes and (2) 511 for all byte indexes P in A: the value of A at index P has the same 512 binary value as the value of B at index P. 514 Two Line IDs SHOULD NOT be equal if they do not match byte-by-byte. 515 For example, an IPv6 Line ID option containing "f123" is not equal to 516 a Line ID option "F123". 518 Intermediate systems SHOULD NOT examine the contents of the Line ID. 519 Intermediate systems SHOULD NOT alter the contents of the Line ID. 521 8. Garbage collection of unused prefixes 523 Following the mechanism described in this document, the Broadband 524 network associates a prefix to a subscriber line based on the LIO. 525 Even when the subscriber line goes down temporarily, this prefix 526 stays allocated to that specific subscriber line. i.e. The prefix is 527 not returned to the unused pool. When a subscriber line no longer 528 needs a prefix, the prefix can be reclaimed by manual action 529 dissociating the prefix from the LIO in the backend systems. 531 9. Interactions with Secure Neighbor Discovery 533 Since the SEND [RFC3971] protected RS/RA packets are not modified in 534 anyway by the mechanism described in this document, there are no 535 issues with SEND verification. 537 10. Acknowledgements 539 The authors would like to thank Margaret Wasserman, Mark Townsley, 540 David Miles, John Kaippallimalil, Eric Levy-Abegnoli, Thomas Narten, 541 Olaf Bonness, Thomas Haag, Wojciech Dec, Brian Haberman, Ole Troan, 542 Hemant Singh, Jari Arkko, Joel Halpern, Bob Hinden, Ran Atkinson and 543 Glen Turner for reviewing this document and suggesting changes. 545 11. Security Considerations 547 The line identification information inserted by the access node or 548 the edge router is not protected. This means that this option may be 549 modified, inserted, or deleted without being detected. In order to 550 ensure validity of the contents of the line identification field, the 551 network between the access node and the edge router needs to be 552 trusted. 554 12. IANA Considerations 556 This document defines a new IPv6 destination option for carrying line 557 identification. IANA is requested to assign a new destination option 558 type in the Destination Options registry maintained at 560 http://www.iana.org/assignments/ipv6-parameters 562 Line Identification Option [RFCXXXX] 564 The act bits for this option need to be 10 and the chg bit needs to 565 be 0. 567 This document also requires the allocation of a well-known link-local 568 scope multicast address from the IPv6 Multicast Address Space 569 Registry located at 571 http://www.iana.org/assignments/ipv6-multicast-addresses/ 572 ipv6-multicast-addresses.xml 574 All BBF Access Nodes [RFCXXXX] 576 13. References 578 13.1. Normative References 580 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 581 RFC 1661, July 1994. 583 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 584 Requirement Levels", BCP 14, RFC 2119, March 1997. 586 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 587 IPv6 Specification", RFC 2473, December 1998. 589 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 590 and M. Carney, "Dynamic Host Configuration Protocol for 591 IPv6 (DHCPv6)", RFC 3315, July 2003. 593 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 594 Neighbor Discovery (SEND)", RFC 3971, March 2005. 596 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 597 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 598 September 2007. 600 [TR101] Broadband Forum, "Migration to Ethernet-based DSL 601 aggregation", . 604 [TR124] Broadband Forum, "Functional Requirements for Broadband 605 Residential Gateway Devices", . 609 [TR156] Broadband Forum, "Using GPON Access in the context of TR- 610 101", . 613 [TR177] Broadband Forum, "IPv6 in the context of TR-101", 614 . 616 [X3.4] American National Standards Institute, "American Standard 617 Code for Information Interchange (ASCII)", Standard X3.4 , 618 1968. 620 13.2. Informative References 622 [RFC0020] Cerf, V., "ASCII format for network interchange", RFC 20, 623 October 1969. 625 [RFC2132] Alexander, S. and R. Droms, "DHCP Options and BOOTP Vendor 626 Extensions", RFC 2132, March 1997. 628 [RFC3046] Patrick, M., "DHCP Relay Agent Information Option", 629 RFC 3046, January 2001. 631 [RFC4649] Volz, B., "Dynamic Host Configuration Protocol for IPv6 632 (DHCPv6) Relay Agent Remote-ID Option", RFC 4649, 633 August 2006. 635 Authors' Addresses 637 Suresh Krishnan 638 Ericsson 639 8400 Blvd Decarie 640 Town of Mount Royal, Quebec 641 Canada 643 Email: suresh.krishnan@ericsson.com 645 Alan Kavanagh 646 Ericsson 647 8400 Blvd Decarie 648 Town of Mount Royal, Quebec 649 Canada 651 Email: alan.kavanagh@ericsson.com 653 Balazs Varga 654 Ericsson 656 Email: balazs.a.varga@ericsson.com 658 Sven Ooghe 659 Alcatel-Lucent 660 Copernicuslaan 50 661 2018 Antwerp, 662 Belgium 664 Phone: 665 Email: sven.ooghe@alcatel-lucent.com 667 Erik Nordmark 668 Cisco 669 510 McCarthy Blvd. 670 Milpitas, CA, 95035 671 USA 673 Phone: +1 408 527 6625 674 Email: nordmark@cisco.com