idnits 2.17.1 draft-krishnan-6man-rs-mark-08.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 seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 20, 2010) is 4965 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 440, 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' 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: March 24, 2011 Ericsson 6 S. Ooghe 7 Alcatel-Lucent 8 E. Nordmark 9 Oracle 10 September 20, 2010 12 Line identification in IPv6 Router Solicitation messages 13 draft-krishnan-6man-rs-mark-08 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 the N:1 VLAN 22 allocation model. 24 Status of this Memo 26 This Internet-Draft is submitted in full conformance with the 27 provisions of BCP 78 and BCP 79. 29 Internet-Drafts are working documents of the Internet Engineering 30 Task Force (IETF). Note that other groups may also distribute 31 working documents as Internet-Drafts. The list of current Internet- 32 Drafts is at http://datatracker.ietf.org/drafts/current/. 34 Internet-Drafts are draft documents valid for a maximum of six months 35 and may be updated, replaced, or obsoleted by other documents at any 36 time. It is inappropriate to use Internet-Drafts as reference 37 material or to cite them other than as "work in progress." 39 This Internet-Draft will expire on March 24, 2011. 41 Copyright Notice 43 Copyright (c) 2010 IETF Trust and the persons identified as the 44 document authors. All rights reserved. 46 This document is subject to BCP 78 and the IETF Trust's Legal 47 Provisions Relating to IETF Documents 48 (http://trustee.ietf.org/license-info) in effect on the date of 49 publication of this document. Please review these documents 50 carefully, as they describe your rights and restrictions with respect 51 to this document. Code Components extracted from this document must 52 include Simplified BSD License text as described in Section 4.e of 53 the Trust Legal Provisions and are provided without warranty as 54 described in the Simplified BSD License. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 60 1.2. Conventions used in this document . . . . . . . . . . . . 5 61 2. Issues with identifying the subscriber in an N:1 VLAN model . 6 62 3. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 6 63 4. Basic operation . . . . . . . . . . . . . . . . . . . . . . . 6 64 5. Access Node Behavior . . . . . . . . . . . . . . . . . . . . . 6 65 5.1. On receiving a Router Solicitation from the end-device . . 6 66 5.2. On receiving a Router Advertisement from the Edge 67 Router . . . . . . . . . . . . . . . . . . . . . . . . . . 7 68 5.2.1. Identifying tunneled Router Advertisements . . . . . . 7 69 5.3. On detecting a subscriber circuit coming up . . . . . . . 7 70 6. Edge Router Behavior . . . . . . . . . . . . . . . . . . . . . 8 71 6.1. On receiving a Tunneled Router Solicitation from the 72 Access Node . . . . . . . . . . . . . . . . . . . . . . . 8 73 6.2. On sending a Router Advertisement towards the 74 end-device . . . . . . . . . . . . . . . . . . . . . . . . 8 75 6.3. Sending periodic unsolicited Router Advertisements 76 towards the end-device . . . . . . . . . . . . . . . . . . 8 77 7. Line Identification Destination Option (LIO) . . . . . . . . . 9 78 8. Interactions with Secure Neighbor Discovery . . . . . . . . . 10 79 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 80 10. Security Considerations . . . . . . . . . . . . . . . . . . . 10 81 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 82 12. Normative References . . . . . . . . . . . . . . . . . . . . . 11 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 85 1. Introduction 87 DSL is a widely deployed access technology for Broadband Access for 88 Next Generation Networks. While traditionally DSL access networks 89 were PPP based some networks are migrating from the traditional PPP 90 access model into a pure IP-based Ethernet aggregated access 91 environment. Architectural and topological models of an Ethernet 92 aggregation network in context of DSL aggregation are described in 93 [TR101]. 95 +----+ +----+ +----------+ 96 |Host|---| RG |----| | 97 +----+ +----+ | | 98 | AN |\ 99 +----+ +----+ | | \ 100 |Host|---| RG |----| | \ 101 +----+ +----+ +----------+ \ +----------+ 102 \ | | 103 +-------------+ | | 104 | Aggregation | | Edge | 105 | Network |-------| Router | 106 +-------------+ | | 107 / | | 108 +----------+ / +----------+ 109 | | / 110 +----+ +----+ | | / 111 |Host|---| RG |----| AN |/ 112 +----+ +----+ | | 113 | | 114 +----------+ 116 Figure 1: Broadband Forum Network Architecture 118 One of the Ethernet and GPON aggregation models specified in this 119 document bridges sessions from multiple user ports behind a DSL 120 Access Node (AN), also referred to as a DSLAM, into a single VLAN in 121 the aggregation network. This is called the N:1 VLAN allocation 122 model. 124 +----------+ 125 | | 126 | | 127 | AN |\ 128 | | \ 129 | | \ VLANx 130 +----------+ \ +----------+ 131 \ | | 132 +-------------+ | | 133 | Aggregation | VLANx | Edge | 134 | Network |-------| Router | 135 +-------------+ | | 136 / | | 137 +----------+ / +----------+ 138 | | / VLANx 139 | | / 140 | AN |/ 141 | | 142 | | 143 +----------+ 145 Figure 2: n:1 VLAN model 147 1.1. Terminology 149 1:1 VLAN It is a broadband network deployment 150 scenario where each user port is mapped to 151 a different VLAN on the Edge Router. The 152 uniqueness of the mapping is maintained in 153 the Access Node and across the Aggregation 154 Network. 155 N:1 VLAN It is a broadband network deployment 156 scenario where multiple user ports are 157 mapped to the same VLAN on the Edge Router. 158 The user ports may be located in the same 159 or different Access Nodes. 160 AN A DSL or GPON Access Node. The Access Node 161 terminates the phyiscal layer (e.g. DSL 162 termination function or GPON termination 163 function), may physically aggregate other 164 nodes implementing such functionality, or 165 may perform both functions at the same 166 time. This node contains at least one 167 standard Ethernet interface that serves as 168 its "northbound" interface into which it 169 aggregates traffic from several user ports 170 or Ethernet-based "southbound" interfaces. 171 It does not implement an IPv6 stack but 172 performs some limited inspection/ 173 modification of IPv6 packets. 174 Aggregation Network The part of the network stretching from the 175 Access Nodes to the Edge Router. In the 176 context of this document the aggregation 177 network is considered to be Ethernet based, 178 providing standard Ethernet interfaces at 179 the edges, for connecting the Access Nodes 180 and Broadband Network. It is comprised of 181 ethernet switches that provide very limited 182 IP functionality (e.g. IGMP snooping, MLD 183 snooping etc.). 184 Edge Router The Edge Router, also known as the 185 Broadband Network Gateway (BNG) is the 186 first IPv6 hop for the user. In the cases 187 where the RG is bridged, the BNG acts as 188 the default router for the hosts behind the 189 RG. In cases where the RG is routed, the 190 BNG acts as the default router for the RG 191 itself. This node implements IPv6 router 192 functionality. 193 GPON Gigabit-capable Passive Optical Network is 194 an optical access network that has been 195 introduced into the Broadband Forum 196 architecture in [TR156] 197 Host A node that implements IPv6 host 198 functionality. 199 RG A residential gateway device. It can be a 200 Layer 3 (routed) device similar to one 201 specified in or a Layer 2 (bridged) device. 202 The residential gateway for Broadband Forum 203 networks is defined in [TR124] 204 End-device A node that sends Router Solicitations and 205 processes received Router Advertisements. 206 When a Layer 3 RG is used it is considered 207 an end-device in the context of this 208 document. When a Layer 2 RG is used, the 209 host behind the RG is considered to be an 210 end-device in the context of this document. 212 1.2. Conventions used in this document 214 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 215 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 216 document are to be interpreted as described in [RFC2119]. 218 2. Issues with identifying the subscriber in an N:1 VLAN model 220 In a DSL or GPON based fixed Broadband Network, IPv6 end-devices are 221 connected to an Access Node (AN). These end-devices today will 222 typically send a Router Solicitation Message to the Edge Router, to 223 which the Edge Router responds with a Router Advertisement message. 224 The Router Advertisement typically contains a prefix that the end- 225 devices will use to automatically configure an IPv6 Address. Upon 226 sending the Router Solicitation message the node connecting the end- 227 device on the access circuit, typically an Access Node (AN), would 228 forward the RS to the Edge Router upstream over a switched network. 229 However, in such Ethernet-based aggregation networks, several 230 subscriber premises may be connected to the same interface of an edge 231 router (e.g. on the same VLAN). However, the edge router requires 232 some information to identify the end-device on the circuit the end- 233 device is connected on. To accomplish this, the AN needs to add line 234 identification information to the Router Solicitation message and 235 forward this to the Edge Router. This is analogous to the case where 236 DHCP is being used, and the line identification information is 237 inserted by a DHCP relay agent. This document proposes a method for 238 the edge router to identify the subscriber premises using the 239 contents of the received Router Solicitation messages. 241 3. Applicability 243 The line identification destination option is intended to be used 244 only for the N:1 VLAN deployment model. For the other VLAN 245 deployment models line identification can be achieved differently. 247 4. Basic operation 249 This document recommends tunneling Neighbor discovery packets inside 250 another IPv6 packet that uses a destination option to convey line 251 identification information. The Neighbor discovery packets are left 252 unmodified inside the encapsulating IPv6 packet. In particular, the 253 Hop Limit field of the ND message is not decremented when the packet 254 is being tunneled. This is because ND messages whose Hop Limit is 255 not 255 will be discarded by the receiver of such messages. 257 5. Access Node Behavior 259 5.1. On receiving a Router Solicitation from the end-device 261 When an end-device sends out a Router Solicitation, it is received by 262 the access node. The AN then tunnels the received Router 263 Solicitation in a newly created IPv6 datagram with the Line 264 Identification Option (LIO). The AN forms a new IPv6 datagram whose 265 payload is the received Router Solicitation message as described in 266 [RFC2473] except that the Hop Limit field of the Router Solicitation 267 message MUST NOT be decremented. If the AN has an IPv6 address, it 268 SHOULD use this address in the Source Address field of the outer IPv6 269 datagram. Otherwise it MUST use the unspecified address as the 270 Source Address of the outer IPv6 datagram. The destination address 271 of the outer IPv6 datagram MUST be copied from the destination 272 address of the tunneled RS. The AN MUST insert a destination options 273 header between the outer IPv6 header and the payload. It MUST insert 274 a LIO destination option and set the line identification field of the 275 option to contain the circuit identifier corresponding to the logical 276 access loop port of the Access Node from which the RS was initiated. 278 5.2. On receiving a Router Advertisement from the Edge Router 280 When the edge router sends out a tunneled router advertisement in 281 response to the RS, it is received by the access node. If there is 282 an LIO option present, the AN MUST use the line identification data 283 of the LIO option to identify the subscriber agent circuit of the 284 Access Node on which the RA should be sent. The AN MUST then remove 285 the outer IPv6 header of this tunneled RA and multicast the inner 286 packet (the original RA) on this specific subscriber circuit. 288 5.2.1. Identifying tunneled Router Advertisements 290 The Access Node can identify tunneled RAs by installing filters based 291 on the destination address of the outer packets, and the presence of 292 a destination option header with an LIO destination option. 294 5.3. On detecting a subscriber circuit coming up 296 RSs initiated by end-devices as described in Section 5.1 may be lost 297 due to lack of connectivity between the access node and the end- 298 device. To ensure that the end-device will receive an RA, the AN 299 needs to trigger the sending of periodic RAs on the edge router. For 300 this purpose, the AN needs to inform the edge router that a 301 subscriber circuit has come up. When the access node detects that a 302 subscriber circuit has come up, it MUST create a Router Solicitation 303 message as described in Section 6.3.7 of [RFC4861]. It MUST use the 304 unspecified address as the source address of this RS. It MUST then 305 tunnel this RS towards the edge router as described in Section 5.1. 307 In case there are connectivity issues between the AN and the edge 308 router, the RSes initiated by the AN can be lost. The AN MAY 309 continue retransmitting the Router Solicitations for a given LIO 310 until it receives an RA for that specific LIO. 312 Alternately, the AN can send this notification about the subscriber 313 circuit coming up using a out-of-band mechanism with acknowledgements 314 like ANCP, if such mechanism is available. 316 6. Edge Router Behavior 318 6.1. On receiving a Tunneled Router Solicitation from the Access Node 320 When the edge router receives a tunneled Router Solicitation 321 forwarded by the access node, it needs to check if there is an LIO 322 destination option present in the outer datagram. The edge router 323 can use the contents of the line identification field to lookup the 324 addressing information and policy that need to be applied to the line 325 from which the Router Solicitation was received. The edge router 326 MUST then process the inner RS message as specified in [RFC4861] 328 6.2. On sending a Router Advertisement towards the end-device 330 When the edge router sends out a Router Advertisement in response to 331 a tunneled RS that included an LIO option, it MUST tunnel the Router 332 Advertisement in a newly created IPv6 datagram with the Line 333 Identification Option (LIO). The edge router creates the Router 334 Advertisement message as described in Section 6.2.3 of [RFC4861]. 335 The edge router may use the contents of the LIO in the received 336 router solicitation to determine the contents of this router 337 advertisement(es. The Edge Router then forms a new IPv6 datagram, 338 whose payload is the Router Advertisement message, as described in 339 [RFC2473] except that the Hop Limit field of the Router Advertisement 340 message MUST NOT be decremented. The Edge router MUST use a link- 341 local IPv6 address on the outgoing interface in the Source Address 342 field of the outer IPv6 datagram. The destination address of the 343 outer IPv6 datagram MUST be set to [KNOWN_VALUE_X, say fe80::0] . 344 The edge router MUST insert a destination options header between the 345 outer IPv6 header and the payload. It MUST insert a LIO destination 346 option and set the line identification field of the option to contain 347 the circuit identifier corresponding to the logical access loop port 348 of the Access Node to which the RA MUST be sent. The IPv6 349 destination address of the inner RA MUST be set to the all-nodes 350 multicast address. The link-layer destination address of the 351 tunneled RA MUST be set to the unicast link-layer address of the 352 Access Node that sent the tunneled Router Solicitation which is being 353 responded to. 355 6.3. Sending periodic unsolicited Router Advertisements towards the 356 end-device 358 After sending a tunneled Router Advertisement as specified in 359 Section 6.2 in response to a received RS, the edge router MUST store 360 the mapping between the LIO and the prefixes contained in the Router 361 Advertisement. It should then initiate periodic sending of 362 unsolicited Router Advertisements as described in Section 6.2.3. of 363 [RFC4861] . The Router Advertisements MUST be created and tunneled 364 as described in Section 6.2. The edge router MAY stop sending Router 365 Advertisements if it receives a notification from the AN that the 366 subscriber circuit has gone down. This notification can be received 367 out-of-band using a mechanism such as ANCP. 369 7. Line Identification Destination Option (LIO) 371 The Line Identification Destination Option (LIO) is a destination 372 option that can be included in IPv6 datagrams that tunnel Router 373 Solicitation and Router Advertisement messages. Multiple Line 374 Identification destination options MUST NOT be present in the same 375 IPv6 datagram. The LIO has an alignment requirement of (none). 377 0 1 2 3 378 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 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 380 | Option Type | Option Length | 381 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 382 | Line Identification... 383 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 385 Figure 3: Line Identification Destination Option Layout 387 Option Type 389 8-bit identifier of the type of option. The option identifier 390 for the line identification option will be allocated by the IANA. 392 Option Length 394 8-bit unsigned integer. The length of the option (excluding 395 the Option Type and Option Length fields). The value 0 is 396 considered invalid. 398 LineIDLen 400 Length of the Line Identification field in number of octets. 402 Line Identification 404 Variable length data inserted by the Access Node describing the 405 subscriber agent circuit identifier corresponding to the logical 406 access loop port of the Access Node from which the RS was 407 initiated. 409 8. Interactions with Secure Neighbor Discovery 411 Since the SEND [RFC3971] protected RS/RA packets are not modified in 412 anyway by the mechanism described in this document, there are no 413 issues with SEND verification. 415 9. Acknowledgements 417 The authors would like to thank Margaret Wasserman, Mark Townsley, 418 David Miles, John Kaippallimalil, Eric Levy-Abegnoli, Thomas Narten, 419 Olaf Bonness, Thomas Haag, Wojciech Dec, Brian Haberman, Ole Troan, 420 Hemant Singh, Jari Arkko and Joel Halpern for reviewing this document 421 and suggesting changes. 423 10. Security Considerations 425 The line identification information inserted by the access node or 426 the edge router is not protected. This means that this option may be 427 modified, inserted, or deleted without being detected. In order to 428 ensure validity of the contents of the line identification field, the 429 network between the access node and the edge router needs to be 430 trusted. 432 11. IANA Considerations 434 This document defines a new IPv6 destination option for carrying line 435 identification. IANA is requested to assign a new destination option 436 type in the Destination Options registry maintained at 438 http://www.iana.org/assignments/ipv6-parameters 440 Line Identification Option [RFCXXXX] 442 The act bits for this option need to be 10 and the chg bit needs to 443 be 0. 445 12. Normative References 447 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 448 Requirement Levels", BCP 14, RFC 2119, March 1997. 450 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 451 IPv6 Specification", RFC 2473, December 1998. 453 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 454 Neighbor Discovery (SEND)", RFC 3971, March 2005. 456 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 457 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 458 September 2007. 460 [TR101] Broadband Forum, "Migration to Ethernet-based DSL 461 aggregation", . 464 [TR124] Broadband Forum, "Functional Requirements for Broadband 465 Residential Gateway Devices", . 469 [TR156] Broadband Forum, "Using GPON Access in the context of TR- 470 101", . 473 Authors' Addresses 475 Suresh Krishnan 476 Ericsson 477 8400 Blvd Decarie 478 Town of Mount Royal, Quebec 479 Canada 481 Email: suresh.krishnan@ericsson.com 483 Alan Kavanagh 484 Ericsson 485 8400 Blvd Decarie 486 Town of Mount Royal, Quebec 487 Canada 489 Email: alan.kavanagh@ericsson.com 491 Balazs Varga 492 Ericsson 494 Email: balazs.a.varga@ericsson.com 496 Sven Ooghe 497 Alcatel-Lucent 498 Copernicuslaan 50 499 2018 Antwerp, 500 Belgium 502 Phone: 503 Email: sven.ooghe@alcatel-lucent.com 505 Erik Nordmark 506 Oracle 507 17 Network Circle 508 Menlo Park, CA 94025 509 USA 511 Email: erik.nordmark@oracle.com