idnits 2.17.1 draft-ietf-6man-lineid-01.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 14, 2011) is 4792 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 461, but not defined -- 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: 0 errors (**), 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 15, 2011 Ericsson 6 S. Ooghe 7 Alcatel-Lucent 8 E. Nordmark 9 Cisco 10 March 14, 2011 12 The Line Identification Destination Option 13 draft-ietf-6man-lineid-01 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 15, 2011. 42 Copyright Notice 44 Copyright (c) 2011 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. Issues with identifying the subscriber in an N:1 VLAN model . 6 63 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4. Basic operation . . . . . . . . . . . . . . . . . . . . . . . 6 65 5. Access Node Behavior . . . . . . . . . . . . . . . . . . . . . 6 66 5.1. On receiving a Router Solicitation from the end-device . . 6 67 5.2. On receiving a Router Advertisement from the Edge 68 Router . . . . . . . . . . . . . . . . . . . . . . . . . . 7 69 5.2.1. Identifying tunneled Router Advertisements . . . . . . 7 70 5.3. On detecting a subscriber circuit coming up . . . . . . . 7 71 6. Edge Router Behavior . . . . . . . . . . . . . . . . . . . . . 8 72 6.1. On receiving a Tunneled Router Solicitation from the 73 Access Node . . . . . . . . . . . . . . . . . . . . . . . 8 74 6.2. On sending a Router Advertisement towards the 75 end-device . . . . . . . . . . . . . . . . . . . . . . . . 8 76 6.3. Sending periodic unsolicited Router Advertisements 77 towards the end-device . . . . . . . . . . . . . . . . . . 9 78 7. Line Identification Destination Option (LIO) . . . . . . . . . 9 79 8. Interactions with Secure Neighbor Discovery . . . . . . . . . 10 80 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 81 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 82 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 83 12. Normative References . . . . . . . . . . . . . . . . . . . . . 11 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 86 1. Introduction 88 Digital Subscriber Line (DSL) is a widely deployed access technology 89 for Broadband Access for Next Generation Networks. While 90 traditionally DSL access networks were Point-to-Point Protocol (PPP) 91 [RFC1661] based some networks are migrating from the traditional PPP 92 access model into a pure IP-based Ethernet aggregated access 93 environment. Architectural and topological models of an Ethernet 94 aggregation network in context of DSL aggregation are described in 95 [TR101]. 97 +----+ +----+ +----------+ 98 |Host|---| RG |----| | 99 +----+ +----+ | | 100 | AN |\ 101 +----+ +----+ | | \ 102 |Host|---| RG |----| | \ 103 +----+ +----+ +----------+ \ +----------+ 104 \ | | 105 +-------------+ | | 106 | Aggregation | | Edge | 107 | Network |-------| Router | 108 +-------------+ | | 109 / | | 110 +----------+ / +----------+ 111 | | / 112 +----+ +----+ | | / 113 |Host|---| RG |----| AN |/ 114 +----+ +----+ | | 115 | | 116 +----------+ 118 Figure 1: Broadband Forum Network Architecture 120 One of the Ethernet and GPON aggregation models specified in this 121 document bridges sessions from multiple user ports behind a DSL 122 Access Node (AN), also referred to as a Digital subscriber line 123 access multiplexer (DSLAM), into a single VLAN in the aggregation 124 network. This is called the N:1 VLAN allocation model. 126 +----------+ 127 | | 128 | | 129 | AN |\ 130 | | \ 131 | | \ VLANx 132 +----------+ \ +----------+ 133 \ | | 134 +-------------+ | | 135 | Aggregation | VLANx | Edge | 136 | Network |-------| Router | 137 +-------------+ | | 138 / | | 139 +----------+ / +----------+ 140 | | / VLANx 141 | | / 142 | AN |/ 143 | | 144 | | 145 +----------+ 147 Figure 2: n:1 VLAN model 149 1.1. Terminology 151 1:1 VLAN It is a broadband network deployment 152 scenario where each user port is mapped to 153 a different VLAN on the Edge Router. The 154 uniqueness of the mapping is maintained in 155 the Access Node and across the Aggregation 156 Network. 157 N:1 VLAN It is a broadband network deployment 158 scenario where multiple user ports are 159 mapped to the same VLAN on the Edge Router. 160 The user ports may be located in the same 161 or different Access Nodes. 162 AN A DSL or a Gigabit Passive Optical Network 163 (GPON) Access Node. The Access Node 164 terminates the physical layer (e.g. DSL 165 termination function or GPON termination 166 function), may physically aggregate other 167 nodes implementing such functionality, or 168 may perform both functions at the same 169 time. This node contains at least one 170 standard Ethernet interface that serves as 171 its "northbound" interface into which it 172 aggregates traffic from several user ports 173 or Ethernet-based "southbound" interfaces. 175 It does not implement an IPv6 stack but 176 performs some limited inspection/ 177 modification of IPv6 packets. The IPv6 178 functions required on the Access Node are 179 described in Section 5 of [TR177]. 180 Aggregation Network The part of the network stretching from the 181 Access Nodes to the Edge Router. In the 182 context of this document the aggregation 183 network is considered to be Ethernet based, 184 providing standard Ethernet interfaces at 185 the edges, for connecting the Access Nodes 186 and Broadband Network. It is comprised of 187 ethernet switches that provide very limited 188 IP functionality (e.g. IGMP snooping, MLD 189 snooping etc.). 190 Edge Router The Edge Router, also known as the 191 Broadband Network Gateway (BNG) is the 192 first IPv6 hop for the user. In the cases 193 where the RG is bridged, the BNG acts as 194 the default router for the hosts behind the 195 RG. In cases where the RG is routed, the 196 BNG acts as the default router for the RG 197 itself. This node implements IPv6 router 198 functionality. 199 GPON Gigabit-capable Passive Optical Network is 200 an optical access network that has been 201 introduced into the Broadband Forum 202 architecture in [TR156] 203 Host A node that implements IPv6 host 204 functionality. 205 RG A residential gateway device. It can be a 206 Layer 3 (routed) device similar to one 207 specified in or a Layer 2 (bridged) device. 208 The residential gateway for Broadband Forum 209 networks is defined in [TR124] 210 End-device A node that sends Router Solicitations and 211 processes received Router Advertisements. 212 When a Layer 3 RG is used it is considered 213 an end-device in the context of this 214 document. When a Layer 2 RG is used, the 215 host behind the RG is considered to be an 216 end-device in the context of this document. 218 1.2. Conventions used in this document 220 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 221 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 222 document are to be interpreted as described in [RFC2119]. 224 2. Issues with identifying the subscriber in an N:1 VLAN model 226 In a DSL or GPON based fixed Broadband Network, IPv6 end-devices are 227 connected to an Access Node (AN). These end-devices today will 228 typically send a Router Solicitation Message to the Edge Router, to 229 which the Edge Router responds with a Router Advertisement message. 230 The Router Advertisement typically contains a prefix that the end- 231 devices will use to automatically configure an IPv6 Address. Upon 232 sending the Router Solicitation message the node connecting the end- 233 device on the access circuit, typically an Access Node (AN), would 234 forward the RS to the Edge Router upstream over a switched network. 235 However, in such Ethernet-based aggregation networks, several 236 subscriber premises may be connected to the same interface of an edge 237 router (e.g. on the same VLAN). However, the edge router requires 238 some information to identify the end-device on the circuit the end- 239 device is connected on. To accomplish this, the AN needs to add line 240 identification information to the Router Solicitation message and 241 forward this to the Edge Router. This is analogous to the case where 242 DHCP is being used, and the line identification information is 243 inserted by a DHCP relay agent. This document proposes a method for 244 the edge router to identify the subscriber premises using the 245 contents of the received Router Solicitation messages. 247 3. Applicability 249 The line identification destination option is intended to be used 250 only for the N:1 VLAN deployment model. For the other VLAN 251 deployment models line identification can be achieved differently. 253 4. Basic operation 255 This document recommends tunneling Neighbor discovery packets inside 256 another IPv6 packet that uses a destination option to convey line 257 identification information. The Neighbor discovery packets are left 258 unmodified inside the encapsulating IPv6 packet. In particular, the 259 Hop Limit field of the ND message is not decremented when the packet 260 is being tunneled. This is because ND messages whose Hop Limit is 261 not 255 will be discarded by the receiver of such messages. 263 5. Access Node Behavior 265 5.1. On receiving a Router Solicitation from the end-device 267 When an end-device sends out a Router Solicitation, it is received by 268 the access node. The AN identifies these messages by looking for 269 ICMPv6 messages (IPv6 Next Header value of 58) with ICMPv6 type 133. 270 The AN intercepts and then tunnels the received Router Solicitation 271 in a newly created IPv6 datagram with the Line Identification Option 272 (LIO). The AN forms a new IPv6 datagram whose payload is the 273 received Router Solicitation message as described in [RFC2473] except 274 that the Hop Limit field of the Router Solicitation message MUST NOT 275 be decremented. If the AN has an IPv6 address, it SHOULD use this 276 address in the Source Address field of the outer IPv6 datagram. 277 Otherwise it MUST use the unspecified address as the Source Address 278 of the outer IPv6 datagram. The destination address of the outer 279 IPv6 datagram MUST be copied from the destination address of the 280 tunneled RS. The AN MUST insert a destination options header between 281 the outer IPv6 header and the payload. It MUST insert a LIO 282 destination option and set the line identification field of the 283 option to contain the circuit identifier corresponding to the logical 284 access loop port of the Access Node from which the RS was initiated. 286 5.2. On receiving a Router Advertisement from the Edge Router 288 When the edge router sends out a tunneled router advertisement in 289 response to the RS, it is received by the access node. If there is 290 an LIO option present, the AN MUST use the line identification data 291 of the LIO option to identify the subscriber agent circuit of the 292 Access Node on which the RA should be sent. The AN MUST then remove 293 the outer IPv6 header of this tunneled RA and multicast the inner 294 packet (the original RA) on this specific subscriber circuit. 296 5.2.1. Identifying tunneled Router Advertisements 298 The Access Node can identify tunneled RAs by installing filters based 299 on the destination address (All BBF Access Nodes) of the outer 300 packets, and the presence of a destination option header with an LIO 301 destination option. 303 5.3. On detecting a subscriber circuit coming up 305 RSs initiated by end-devices as described in Section 5.1 may be lost 306 due to lack of connectivity between the access node and the end- 307 device. To ensure that the end-device will receive an RA, the AN 308 needs to trigger the sending of periodic RAs on the edge router. For 309 this purpose, the AN needs to inform the edge router that a 310 subscriber circuit has come up. When the access node detects that a 311 subscriber circuit has come up, it MUST create a Router Solicitation 312 message as described in Section 6.3.7 of [RFC4861]. It MUST use the 313 unspecified address as the source address of this RS. It MUST then 314 tunnel this RS towards the edge router as described in Section 5.1. 316 In case there are connectivity issues between the AN and the edge 317 router, the RSes initiated by the AN can be lost. The AN MAY 318 continue retransmitting the Router Solicitations for a given LIO 319 until it receives an RA for that specific LIO. 321 Alternately, the AN can send this notification about the subscriber 322 circuit coming up using a out-of-band mechanism with acknowledgements 323 like ANCP, if such mechanism is available. 325 6. Edge Router Behavior 327 6.1. On receiving a Tunneled Router Solicitation from the Access Node 329 When the edge router receives a tunneled Router Solicitation 330 forwarded by the access node, it needs to check if there is an LIO 331 destination option present in the outer datagram. The edge router 332 can use the contents of the line identification field to lookup the 333 addressing information and policy that need to be applied to the line 334 from which the Router Solicitation was received. The edge router 335 MUST then process the inner RS message as specified in [RFC4861] 337 6.2. On sending a Router Advertisement towards the end-device 339 When the edge router sends out a Router Advertisement in response to 340 a tunneled RS that included an LIO option, it MUST tunnel the Router 341 Advertisement in a newly created IPv6 datagram with the Line 342 Identification Option (LIO). The edge router creates the Router 343 Advertisement message as described in Section 6.2.3 of [RFC4861]. 344 The edge router may use the contents of the LIO in the received 345 router solicitation to determine the contents of this router 346 advertisement(es. The Edge Router then forms a new IPv6 datagram, 347 whose payload is the Router Advertisement message, as described in 348 [RFC2473] except that the Hop Limit field of the Router Advertisement 349 message MUST NOT be decremented. The Edge router MUST use a link- 350 local IPv6 address on the outgoing interface in the Source Address 351 field of the outer IPv6 datagram. The destination address of the 352 outer IPv6 datagram MUST be set to the well-known link-local scope 353 All BBF Access Nodes multicast address [to be allocated]. The edge 354 router MUST insert a destination options header between the outer 355 IPv6 header and the payload. It MUST insert a LIO destination option 356 and set the line identification field of the option to contain the 357 circuit identifier corresponding to the logical access loop port of 358 the Access Node to which the RA MUST be sent. The IPv6 destination 359 address of the inner RA MUST be set to the all-nodes multicast 360 address. The link-layer destination address of the tunneled RA MUST 361 be set to the unicast link-layer address of the Access Node that sent 362 the tunneled Router Solicitation which is being responded to. 364 6.3. Sending periodic unsolicited Router Advertisements towards the 365 end-device 367 After sending a tunneled Router Advertisement as specified in 368 Section 6.2 in response to a received RS, the edge router MUST store 369 the mapping between the LIO and the prefixes contained in the Router 370 Advertisement. It should then initiate periodic sending of 371 unsolicited Router Advertisements as described in Section 6.2.3. of 372 [RFC4861] . The Router Advertisements MUST be created and tunneled 373 as described in Section 6.2. The edge router MAY stop sending Router 374 Advertisements if it receives a notification from the AN that the 375 subscriber circuit has gone down. This notification can be received 376 out-of-band using a mechanism such as ANCP. 378 7. Line Identification Destination Option (LIO) 380 The Line Identification Destination Option (LIO) is a destination 381 option that can be included in IPv6 datagrams that tunnel Router 382 Solicitation and Router Advertisement messages. Multiple Line 383 Identification destination options MUST NOT be present in the same 384 IPv6 datagram. The LIO has an alignment requirement of (none). 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 | Option Type | Option Length | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | Line Identification... 392 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 394 Figure 3: Line Identification Destination Option Layout 396 Option Type 398 8-bit identifier of the type of option. The option identifier 399 for the line identification option will be allocated by the IANA. 401 Option Length 403 8-bit unsigned integer. The length of the option (excluding 404 the Option Type and Option Length fields). The value 0 is 405 considered invalid. 407 LineIDLen 409 Length of the Line Identification field in number of octets. 411 Line Identification 413 Variable length data inserted by the Access Node describing the 414 subscriber agent circuit identifier corresponding to the logical 415 access loop port of the Access Node from which the RS was 416 initiated. 418 8. Interactions with Secure Neighbor Discovery 420 Since the SEND [RFC3971] protected RS/RA packets are not modified in 421 anyway by the mechanism described in this document, there are no 422 issues with SEND verification. 424 9. Acknowledgements 426 The authors would like to thank Margaret Wasserman, Mark Townsley, 427 David Miles, John Kaippallimalil, Eric Levy-Abegnoli, Thomas Narten, 428 Olaf Bonness, Thomas Haag, Wojciech Dec, Brian Haberman, Ole Troan, 429 Hemant Singh, Jari Arkko and Joel Halpern for reviewing this document 430 and suggesting changes. 432 10. Security Considerations 434 The line identification information inserted by the access node or 435 the edge router is not protected. This means that this option may be 436 modified, inserted, or deleted without being detected. In order to 437 ensure validity of the contents of the line identification field, the 438 network between the access node and the edge router needs to be 439 trusted. 441 11. IANA Considerations 443 This document defines a new IPv6 destination option for carrying line 444 identification. IANA is requested to assign a new destination option 445 type in the Destination Options registry maintained at 447 http://www.iana.org/assignments/ipv6-parameters 449 Line Identification Option [RFCXXXX] 451 The act bits for this option need to be 10 and the chg bit needs to 452 be 0. 454 This document also requires the allocation of a well-known link-local 455 scope multicast address from the IPv6 Multicast Address Space 456 Registry located at 458 http://www.iana.org/assignments/ipv6-multicast-addresses/ 459 ipv6-multicast-addresses.xml 461 All BBF Access Nodes [RFCXXXX] 463 12. Normative References 465 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 466 RFC 1661, July 1994. 468 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 469 Requirement Levels", BCP 14, RFC 2119, March 1997. 471 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 472 IPv6 Specification", RFC 2473, December 1998. 474 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 475 Neighbor Discovery (SEND)", RFC 3971, March 2005. 477 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 478 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 479 September 2007. 481 [TR101] Broadband Forum, "Migration to Ethernet-based DSL 482 aggregation", . 485 [TR124] Broadband Forum, "Functional Requirements for Broadband 486 Residential Gateway Devices", . 490 [TR156] Broadband Forum, "Using GPON Access in the context of TR- 491 101", . 494 [TR177] Broadband Forum, "IPv6 in the context of TR-101", 495 . 497 Authors' Addresses 499 Suresh Krishnan 500 Ericsson 501 8400 Blvd Decarie 502 Town of Mount Royal, Quebec 503 Canada 505 Email: suresh.krishnan@ericsson.com 507 Alan Kavanagh 508 Ericsson 509 8400 Blvd Decarie 510 Town of Mount Royal, Quebec 511 Canada 513 Email: alan.kavanagh@ericsson.com 515 Balazs Varga 516 Ericsson 518 Email: balazs.a.varga@ericsson.com 520 Sven Ooghe 521 Alcatel-Lucent 522 Copernicuslaan 50 523 2018 Antwerp, 524 Belgium 526 Phone: 527 Email: sven.ooghe@alcatel-lucent.com 528 Erik Nordmark 529 Cisco 531 Email: nordmark@acm.org