idnits 2.17.1 draft-ietf-6man-lineid-02.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 (October 31, 2011) is 4554 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 529, 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: May 3, 2012 Ericsson 6 S. Ooghe 7 Alcatel-Lucent 8 E. Nordmark 9 Cisco 10 October 31, 2011 12 The Line Identification Destination Option 13 draft-ietf-6man-lineid-02 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 May 3, 2012. 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. 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 8. Garbage collection of unused prefixes . . . . . . . . . . . . 11 82 9. Interactions with Secure Neighbor Discovery . . . . . . . . . 11 83 10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 84 11. Security Considerations . . . . . . . . . . . . . . . . . . . 12 85 12. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 13. Normative References . . . . . . . . . . . . . . . . . . . . . 12 87 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 89 1. Introduction 91 Digital Subscriber Line (DSL) is a widely deployed access technology 92 for Broadband Access for Next Generation Networks. While 93 traditionally DSL access networks were Point-to-Point Protocol (PPP) 94 [RFC1661] based some networks are migrating from the traditional PPP 95 access model into a pure IP-based Ethernet aggregated access 96 environment. Architectural and topological models of an Ethernet 97 aggregation network in context of DSL aggregation are described in 98 [TR101]. 100 +----+ +----+ +----------+ 101 |Host|---| RG |----| | 102 +----+ +----+ | | 103 | AN |\ 104 +----+ +----+ | | \ 105 |Host|---| RG |----| | \ 106 +----+ +----+ +----------+ \ +----------+ 107 \ | | 108 +-------------+ | | 109 | Aggregation | | Edge | 110 | Network |-------| Router | 111 +-------------+ | | 112 / | | 113 +----------+ / +----------+ 114 | | / 115 +----+ +----+ | | / 116 |Host|---| RG |----| AN |/ 117 +----+ +----+ | | 118 | | 119 +----------+ 121 Figure 1: Broadband Forum Network Architecture 123 One of the Ethernet and GPON aggregation models specified in this 124 document bridges sessions from multiple user ports behind a DSL 125 Access Node (AN), also referred to as a Digital subscriber line 126 access multiplexer (DSLAM), into a single VLAN in the aggregation 127 network. This is called the N:1 VLAN allocation model. 129 +----------+ 130 | | 131 | | 132 | AN |\ 133 | | \ 134 | | \ VLANx 135 +----------+ \ +----------+ 136 \ | | 137 +-------------+ | | 138 | Aggregation | VLANx | Edge | 139 | Network |-------| Router | 140 +-------------+ | | 141 / | | 142 +----------+ / +----------+ 143 | | / VLANx 144 | | / 145 | AN |/ 146 | | 147 | | 148 +----------+ 150 Figure 2: n:1 VLAN model 152 1.1. Terminology 154 1:1 VLAN It is a broadband network deployment 155 scenario where each user port is mapped to 156 a different VLAN on the Edge Router. The 157 uniqueness of the mapping is maintained in 158 the Access Node and across the Aggregation 159 Network. 160 N:1 VLAN It is a broadband network deployment 161 scenario where multiple user ports are 162 mapped to the same VLAN on the Edge Router. 163 The user ports may be located in the same 164 or different Access Nodes. 165 AN A DSL or a Gigabit Passive Optical Network 166 (GPON) Access Node. The Access Node 167 terminates the physical layer (e.g. DSL 168 termination function or GPON termination 169 function), may physically aggregate other 170 nodes implementing such functionality, or 171 may perform both functions at the same 172 time. This node contains at least one 173 standard Ethernet interface that serves as 174 its "northbound" interface into which it 175 aggregates traffic from several user ports 176 or Ethernet-based "southbound" interfaces. 178 It does not implement an IPv6 stack but 179 performs some limited inspection/ 180 modification of IPv6 packets. The IPv6 181 functions required on the Access Node are 182 described in Section 5 of [TR177]. 183 Aggregation Network The part of the network stretching from the 184 Access Nodes to the Edge Router. In the 185 context of this document the aggregation 186 network is considered to be Ethernet based, 187 providing standard Ethernet interfaces at 188 the edges, for connecting the Access Nodes 189 and Broadband Network. It is comprised of 190 ethernet switches that provide very limited 191 IP functionality (e.g. IGMP snooping, MLD 192 snooping etc.). 193 Edge Router The Edge Router, also known as the 194 Broadband Network Gateway (BNG) is the 195 first IPv6 hop for the user. In the cases 196 where the RG is bridged, the BNG acts as 197 the default router for the hosts behind the 198 RG. In cases where the RG is routed, the 199 BNG acts as the default router for the RG 200 itself. This node implements IPv6 router 201 functionality. 202 GPON Gigabit-capable Passive Optical Network is 203 an optical access network that has been 204 introduced into the Broadband Forum 205 architecture in [TR156] 206 Host A node that implements IPv6 host 207 functionality. 208 RG A residential gateway device. It can be a 209 Layer 3 (routed) device similar to one 210 specified in or a Layer 2 (bridged) device. 211 The residential gateway for Broadband Forum 212 networks is defined in [TR124] 213 End-device A node that sends Router Solicitations and 214 processes received Router Advertisements. 215 When a Layer 3 RG is used it is considered 216 an end-device in the context of this 217 document. When a Layer 2 RG is used, the 218 host behind the RG is considered to be an 219 end-device in the context of this document. 221 1.2. Conventions used in this document 223 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL","SHALL NOT", 224 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 225 document are to be interpreted as described in [RFC2119]. 227 2. Applicability Statement 229 The line identification destination option is intended to be used 230 only for the N:1 VLAN deployment model. For the other VLAN 231 deployment models line identification can be achieved differently. 233 When DHCP is used for IPv6 address assignment it has the side-effect 234 of including reliability initiated by the end-device (the end-device 235 retransmits DHCP messages until it receives a response), as well as a 236 way to detect when the end-device is not active for an extended 237 period of time (the end-device would not renew its DHCP lease). IPv6 238 Stateless address autoconfiguration was not designed to satisfy such 239 requirements. While this protocol improves the the robustness of 240 relying on Router Solicitations in lieu of DHCP, this results on some 241 limitations specified below. 243 The mechanism described in this document deals with the loss of 244 subscriber-originated Router Solicitations by initiating RSs at the 245 Access Node, which improves the robustness over solely relying on the 246 end-device's few initial retransmissions of RSs. But the AN 247 retransmissions imply that some information that was obtained by the 248 network from subscriber-originated RSs may no longer be available. 249 e.g. Since there is no L2 frame received from the subscriber in case 250 of an RS sent by an AN, the L2 address information of the host cannot 251 be determined. One piece of L2 address information currently used in 252 Broadband networks is the MAC address. For this reason, the solution 253 described in this document is NOT RECOMMENDED for networks that 254 require the MAC address of the endpoint for identification. 256 There is no indication when a subscriber is no longer active. Thus 257 this protocol can not be used to automatically reclaim resources, 258 such as prefixes, that are associated with an active subscriber. See 259 Section 8. Thus this protocol is NOT RECOMMENDED for networks that 260 require automatic notification when a subscriber is no longer active. 262 This mechanism by itself provides no protection against the loss of 263 RS induced state in access routers that would lead to loss of IPv6 264 connectivity for hosts. Given that regular IPv6 hosts do not have RS 265 retransmission behavior that would allow automatic recovery from such 266 a failure, this mechanism is considered experimental and NOT 267 RECOMMENDED for general deployments. 269 3. Issues with identifying the subscriber in an N:1 VLAN model 271 In a DSL or GPON based fixed Broadband Network, IPv6 end-devices are 272 connected to an Access Node (AN). These end-devices today will 273 typically send a Router Solicitation Message to the Edge Router, to 274 which the Edge Router responds with a Router Advertisement message. 275 The Router Advertisement typically contains a prefix that the end- 276 devices will use to automatically configure an IPv6 Address. Upon 277 sending the Router Solicitation message the node connecting the end- 278 device on the access circuit, typically an Access Node (AN), would 279 forward the RS to the Edge Router upstream over a switched network. 280 However, in such Ethernet-based aggregation networks, several 281 subscriber premises may be connected to the same interface of an edge 282 router (e.g. on the same VLAN). However, the edge router requires 283 some information to identify the end-device on the circuit the end- 284 device is connected on. To accomplish this, the AN needs to add line 285 identification information to the Router Solicitation message and 286 forward this to the Edge Router. This is analogous to the case where 287 DHCP is being used, and the line identification information is 288 inserted by a DHCP relay agent. This document proposes a method for 289 the edge router to identify the subscriber premises using the 290 contents of the received Router Solicitation messages. 292 4. Basic operation 294 This document recommends tunneling Neighbor discovery packets inside 295 another IPv6 packet that uses a destination option to convey line 296 identification information. The Neighbor discovery packets are left 297 unmodified inside the encapsulating IPv6 packet. In particular, the 298 Hop Limit field of the ND message is not decremented when the packet 299 is being tunneled. This is because ND messages whose Hop Limit is 300 not 255 will be discarded by the receiver of such messages. 302 5. Access Node Behavior 304 5.1. On receiving a Router Solicitation from the end-device 306 When an end-device sends out a Router Solicitation, it is received by 307 the access node. The AN identifies these messages by looking for 308 ICMPv6 messages (IPv6 Next Header value of 58) with ICMPv6 type 133. 309 The AN intercepts and then tunnels the received Router Solicitation 310 in a newly created IPv6 datagram with the Line Identification Option 311 (LIO). The AN forms a new IPv6 datagram whose payload is the 312 received Router Solicitation message as described in [RFC2473] except 313 that the Hop Limit field of the Router Solicitation message MUST NOT 314 be decremented. If the AN has an IPv6 address, it SHOULD use this 315 address in the Source Address field of the outer IPv6 datagram. 316 Otherwise it MUST use the unspecified address as the Source Address 317 of the outer IPv6 datagram. The destination address of the outer 318 IPv6 datagram MUST be copied from the destination address of the 319 tunneled RS. The AN MUST insert a destination options header between 320 the outer IPv6 header and the payload. It MUST insert a LIO 321 destination option and set the line identification field of the 322 option to contain the circuit identifier corresponding to the logical 323 access loop port of the Access Node from which the RS was initiated. 325 5.2. On receiving a Router Advertisement from the Edge Router 327 When the edge router sends out a tunneled router advertisement in 328 response to the RS, it is received by the access node. If there is 329 an LIO option present, the AN MUST use the line identification data 330 of the LIO option to identify the subscriber agent circuit of the 331 Access Node on which the RA should be sent. The AN MUST then remove 332 the outer IPv6 header of this tunneled RA and multicast the inner 333 packet (the original RA) on this specific subscriber circuit. 335 5.2.1. Identifying tunneled Router Advertisements 337 The Access Node can identify tunneled RAs by installing filters based 338 on the destination address (All BBF Access Nodes) of the outer 339 packets, and the presence of a destination option header with an LIO 340 destination option. 342 5.3. On detecting a subscriber circuit coming up 344 RSs initiated by end-devices as described in Section 5.1 may be lost 345 due to lack of connectivity between the access node and the end- 346 device. To ensure that the end-device will receive an RA, the AN 347 needs to trigger the sending of periodic RAs on the edge router. For 348 this purpose, the AN needs to inform the edge router that a 349 subscriber circuit has come up. When the access node detects that a 350 subscriber circuit has come up, it MUST create a Router Solicitation 351 message as described in Section 6.3.7 of [RFC4861]. It MUST use the 352 unspecified address as the source address of this RS. It MUST then 353 tunnel this RS towards the edge router as described in Section 5.1. 355 In case there are connectivity issues between the AN and the edge 356 router, the RSs initiated by the AN can be lost. The AN SHOULD 357 continue retransmitting the Router Solicitations following the 358 algorithm described in Section 5.5 for a given LIO until it receives 359 an RA for that specific LIO. 361 5.4. On detecting Edge Router failure 363 When the edge router reboots and loses state or is replaced by a new 364 edge router, the AN will detect it using connectivity check 365 mechanisms that are already in place in Broadband networks (e.g. 366 BFD). When such edge router failure is detected, the AN needs to 367 start transmitting RSs for each of its subscriber circuits that are 368 up as described in Section 5.3. 370 5.5. RS Retransmission algorithm 372 The AN SHOULD use the exponential backoff algorithm for retransmits 373 that is described in Section 14 of [RFC3315] in order to continuously 374 retransmit the Router Solicitations for a given LIO until a response 375 is received for that specific LIO. The AN SHOULD use the following 376 variables as input to the retransmission algorithm: 378 IRT 1 Second 379 MRT 30 Seconds 380 MRC 0 381 MRD 0 383 6. Edge Router Behavior 385 6.1. On receiving a Tunneled Router Solicitation from the Access Node 387 When the edge router receives a tunneled Router Solicitation 388 forwarded by the access node, it needs to check if there is an LIO 389 destination option present in the outer datagram. The edge router 390 can use the contents of the line identification field to lookup the 391 addressing information and policy that need to be applied to the line 392 from which the Router Solicitation was received. The edge router 393 MUST then process the inner RS message as specified in [RFC4861] 395 6.2. On sending a Router Advertisement towards the end-device 397 When the edge router sends out a Router Advertisement in response to 398 a tunneled RS that included an LIO option, it MUST tunnel the Router 399 Advertisement in a newly created IPv6 datagram with the Line 400 Identification Option (LIO). The edge router creates the Router 401 Advertisement message as described in Section 6.2.3 of [RFC4861]. 402 The edge router may use the contents of the LIO in the received 403 router solicitation to determine the contents of this router 404 advertisement(es. The Edge Router then forms a new IPv6 datagram, 405 whose payload is the Router Advertisement message, as described in 406 [RFC2473] except that the Hop Limit field of the Router Advertisement 407 message MUST NOT be decremented. The Edge router MUST use a link- 408 local IPv6 address on the outgoing interface in the Source Address 409 field of the outer IPv6 datagram. The destination address of the 410 outer IPv6 datagram MUST be set to the well-known link-local scope 411 All BBF Access Nodes multicast address [to be allocated]. The edge 412 router MUST insert a destination options header between the outer 413 IPv6 header and the payload. It MUST insert a LIO destination option 414 and set the line identification field of the option to contain the 415 circuit identifier corresponding to the logical access loop port of 416 the Access Node to which the RA MUST be sent. The IPv6 destination 417 address of the inner RA MUST be set to the all-nodes multicast 418 address. The link-layer destination address of the tunneled RA MUST 419 be set to the unicast link-layer address of the Access Node that sent 420 the tunneled Router Solicitation which is being responded to. 422 6.3. Sending periodic unsolicited Router Advertisements towards the 423 end-device 425 After sending a tunneled Router Advertisement as specified in 426 Section 6.2 in response to a received RS, the edge router MUST store 427 the mapping between the LIO and the prefixes contained in the Router 428 Advertisement. It should then initiate periodic sending of 429 unsolicited Router Advertisements as described in Section 6.2.3. of 430 [RFC4861] . The Router Advertisements MUST be created and tunneled 431 as described in Section 6.2. The edge router MAY stop sending Router 432 Advertisements if it receives a notification from the AN that the 433 subscriber circuit has gone down. This notification can be received 434 out-of-band using a mechanism such as ANCP. 436 7. Line Identification Destination Option (LIO) 438 The Line Identification Destination Option (LIO) is a destination 439 option that can be included in IPv6 datagrams that tunnel Router 440 Solicitation and Router Advertisement messages. Multiple Line 441 Identification destination options MUST NOT be present in the same 442 IPv6 datagram. The LIO has an alignment requirement of (none). 444 0 1 2 3 445 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 446 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 447 | Option Type | Option Length | 448 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 449 | LineIDLen | Line Identification... 450 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 452 Figure 3: Line Identification Destination Option Layout 454 Option Type 456 8-bit identifier of the type of option. The option identifier 457 for the line identification option will be allocated by the IANA. 459 Option Length 461 8-bit unsigned integer. The length of the option (excluding 462 the Option Type and Option Length fields). The value 0 is 463 considered invalid. 465 LineIDLen 467 Length of the Line Identification field in number of octets. 469 Line Identification 471 Variable length data inserted by the Access Node describing the 472 subscriber agent circuit identifier corresponding to the logical 473 access loop port of the Access Node from which the RS was 474 initiated. 476 8. Garbage collection of unused prefixes 478 Following the mechanism described in this document, the Broadband 479 network associates a prefix to a subscriber line based on the LIO. 480 Even when the subscriber line goes down temporarily, this prefix 481 stays allocated to that specific subscriber line. i.e. The prefix is 482 not returned to the unused pool. When a subscriber line no longer 483 needs a prefix, the prefix can be reclaimed by manual action 484 dissociating the prefix from the LIO in the backend systems. 486 9. Interactions with Secure Neighbor Discovery 488 Since the SEND [RFC3971] protected RS/RA packets are not modified in 489 anyway by the mechanism described in this document, there are no 490 issues with SEND verification. 492 10. Acknowledgements 494 The authors would like to thank Margaret Wasserman, Mark Townsley, 495 David Miles, John Kaippallimalil, Eric Levy-Abegnoli, Thomas Narten, 496 Olaf Bonness, Thomas Haag, Wojciech Dec, Brian Haberman, Ole Troan, 497 Hemant Singh, Jari Arkko, Joel Halpern and Bob Hinden for reviewing 498 this document and suggesting changes. 500 11. Security Considerations 502 The line identification information inserted by the access node or 503 the edge router is not protected. This means that this option may be 504 modified, inserted, or deleted without being detected. In order to 505 ensure validity of the contents of the line identification field, the 506 network between the access node and the edge router needs to be 507 trusted. 509 12. IANA Considerations 511 This document defines a new IPv6 destination option for carrying line 512 identification. IANA is requested to assign a new destination option 513 type in the Destination Options registry maintained at 515 http://www.iana.org/assignments/ipv6-parameters 517 Line Identification Option [RFCXXXX] 519 The act bits for this option need to be 10 and the chg bit needs to 520 be 0. 522 This document also requires the allocation of a well-known link-local 523 scope multicast address from the IPv6 Multicast Address Space 524 Registry located at 526 http://www.iana.org/assignments/ipv6-multicast-addresses/ 527 ipv6-multicast-addresses.xml 529 All BBF Access Nodes [RFCXXXX] 531 13. Normative References 533 [RFC1661] Simpson, W., "The Point-to-Point Protocol (PPP)", STD 51, 534 RFC 1661, July 1994. 536 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 537 Requirement Levels", BCP 14, RFC 2119, March 1997. 539 [RFC2473] Conta, A. and S. Deering, "Generic Packet Tunneling in 540 IPv6 Specification", RFC 2473, December 1998. 542 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 543 and M. Carney, "Dynamic Host Configuration Protocol for 544 IPv6 (DHCPv6)", RFC 3315, July 2003. 546 [RFC3971] Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure 547 Neighbor Discovery (SEND)", RFC 3971, March 2005. 549 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 550 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 551 September 2007. 553 [TR101] Broadband Forum, "Migration to Ethernet-based DSL 554 aggregation", . 557 [TR124] Broadband Forum, "Functional Requirements for Broadband 558 Residential Gateway Devices", . 562 [TR156] Broadband Forum, "Using GPON Access in the context of TR- 563 101", . 566 [TR177] Broadband Forum, "IPv6 in the context of TR-101", 567 . 569 Authors' Addresses 571 Suresh Krishnan 572 Ericsson 573 8400 Blvd Decarie 574 Town of Mount Royal, Quebec 575 Canada 577 Email: suresh.krishnan@ericsson.com 579 Alan Kavanagh 580 Ericsson 581 8400 Blvd Decarie 582 Town of Mount Royal, Quebec 583 Canada 585 Email: alan.kavanagh@ericsson.com 586 Balazs Varga 587 Ericsson 589 Email: balazs.a.varga@ericsson.com 591 Sven Ooghe 592 Alcatel-Lucent 593 Copernicuslaan 50 594 2018 Antwerp, 595 Belgium 597 Phone: 598 Email: sven.ooghe@alcatel-lucent.com 600 Erik Nordmark 601 Cisco 602 510 McCarthy Blvd. 603 Milpitas, CA, 95035 604 USA 606 Phone: +1 408 527 6625 607 Email: nordmark@cisco.com