idnits 2.17.1 draft-ietf-v6ops-ipv6-cpe-router-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 == Line 108 has weird spacing: '... router a nod...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: WPD-6: An IPv6 CE router MUST not by default initiate any dynamic routing protocol on its WAN interface. -- The document date (December 18, 2009) is 5241 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2827' is defined on line 494, but no explicit reference was found in the text == Outdated reference: A later version (-12) exists of draft-ietf-6man-ipv6-subnet-model-06 == Outdated reference: A later version (-16) exists of draft-ietf-v6ops-cpe-simple-security-08 ** Obsolete normative reference: RFC 3315 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3633 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 3736 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4242 (Obsoleted by RFC 8415) ** Obsolete normative reference: RFC 4294 (Obsoleted by RFC 6434) Summary: 6 errors (**), 0 flaws (~~), 6 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force H. Singh 3 Internet-Draft W. Beebee 4 Intended status: Informational Cisco Systems, Inc. 5 Expires: June 21, 2010 C. Donley 6 CableLabs 7 B. Stark 8 AT&T 9 O. Troan, Ed. 10 Cisco Systems, Inc. 11 December 18, 2009 13 Basic Requirements for IPv6 Customer Edge Routers 14 draft-ietf-v6ops-ipv6-cpe-router-03 16 Abstract 18 This document specifies requirements for an IPv6 Customer Edge (CE) 19 router. Specifically, the current version of this document focuses 20 on the provisioning of an IPv6 CE router and the provisioning of IPv6 21 hosts attached to it. 23 Status of this Memo 25 This Internet-Draft is submitted to IETF in full conformance with the 26 provisions of BCP 78 and BCP 79. 28 Internet-Drafts are working documents of the Internet Engineering 29 Task Force (IETF), its areas, and its working groups. Note that 30 other groups may also distribute working documents as Internet- 31 Drafts. 33 Internet-Drafts are draft documents valid for a maximum of six months 34 and may be updated, replaced, or obsoleted by other documents at any 35 time. It is inappropriate to use Internet-Drafts as reference 36 material or to cite them other than as "work in progress." 38 The list of current Internet-Drafts can be accessed at 39 http://www.ietf.org/ietf/1id-abstracts.txt. 41 The list of Internet-Draft Shadow Directories can be accessed at 42 http://www.ietf.org/shadow.html. 44 This Internet-Draft will expire on June 21, 2010. 46 Copyright Notice 48 Copyright (c) 2009 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the BSD License. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 65 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 66 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 3.1. Current IPv4 end-user network architecture . . . . . . . . 4 68 3.2. IPv6 end-user network architecture . . . . . . . . . . . . 5 69 4. Use Cases and Requirements . . . . . . . . . . . . . . . . . . 6 70 4.1. WAN side configuration . . . . . . . . . . . . . . . . . . 6 71 4.2. LAN side configuration . . . . . . . . . . . . . . . . . . 8 72 4.3. General requirements . . . . . . . . . . . . . . . . . . . 9 73 4.4. Security Considerations . . . . . . . . . . . . . . . . . 10 74 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 75 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 11 76 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 77 8. Normative References . . . . . . . . . . . . . . . . . . . . . 11 78 Appendix A. Changes in revision 3 . . . . . . . . . . . . . . . . 13 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 81 1. Introduction 83 This document defines IPv6 features for a residential or small office 84 router referred to as an IPv6 CE router. Typically these routers 85 also support IPv4. 87 This document specifies how an IPv6 CE router automatically 88 provisions its WAN interface, acquires an address block for 89 provisioning of its LAN interfaces and fetches other configuration 90 information from the service provider network. Automatic 91 provisioning of more complex topology than a single router with 92 multiple LAN interfaces is out of scope for this document. 94 See [RFC4779] for a discussion of options available for deploying 95 IPv6 in service provider access networks. 97 1.1. Requirements Language 99 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 100 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 101 document are to be interpreted as described in RFC 2119 [RFC2119]. 103 2. Terminology 105 End-user Network one or more links attached to the IPv6 CE 106 router that connect IPv6 hosts. 108 IPv6 Customer Edge router a node intended for home or small office 109 use which forwards IPv6 packets not explicitly 110 addressed to itself. The IPv6 CE router 111 connects the end-user network to a service 112 provider network. 114 IPv6 host any device implementing an IPv6 stack receiving 115 IPv6 Internet connectivity through the IPv6 CE 116 router 118 LAN interface an IPv6 CE router's attachment to a link in the 119 end-user network. Examples are Ethernets 120 (simple or bridged), 802.11 wireless or other 121 LAN technologies. An IPv6 CE router may have 122 one or more network layer LAN Interfaces. 124 Service Provider a company that offers its customers access to 125 the Internet. In this document, a Service 126 Provider specifically offers Internet access 127 using IPv6, and may also offer IPv4 Internet 128 access. The Service Provider can provide such 129 access over a variety of different transport 130 methods such as DSL, cable, wireless, and 131 others. 133 WAN interface an IPv6 CE router's attachment to a link used 134 to provide connectivity to the Service Provider 135 network; example link technologies include 136 Ethernets (simple or bridged), PPP links, X.25, 137 Frame Relay, or ATM networks as well as 138 Internet-layer (or higher-layer) "tunnels", 139 such as tunnels over IPv4 or IPv6 itself. 141 3. Architecture 143 3.1. Current IPv4 end-user network architecture 145 An end-user network will likely have to support both IPv4 and IPv6. 146 It is not expected that an end-user will change their existing 147 network topology with the introduction of IPv6. There are some 148 differences in how IPv6 works and is provisioned which has 149 implications for the network architecture. A typical IPv4 end-user 150 network consist of a "plug and play" NAT box connected to the ISP. 151 The assumption is a single NAT device with a single link behind it. 152 The NAT provides stable addressing allowing for manually configured 153 addresses on the nodes in the end-user network. 155 A typical IPv4 NAT deployment by default blocks all incoming 156 connections. Opening of ports is typically allowed using UPnP or 157 some other firewall control protocol. 159 Another consequence of using private address space in the end-user 160 network is that it provides stable addressing, i.e. it never changes 161 even when you change ISPs, and the addresses are always there even 162 when the WAN interface is down or the customer edge router has not 163 yet been provisioned. 165 Rewriting addresses on the edge of the network also allows for some 166 rudimentary multi-homing; even though using NATs for multi-homing 167 does not preserve connections during fail-overs [RFC4864]. 169 Many existing routers support dynamic routing, and advanced end users 170 can build arbitrary, complex networks using manual configuration of 171 address prefixes combined with a dynamic routing protocol. 173 3.2. IPv6 end-user network architecture 175 The end-user network architecture for IPv6 should provide equivalent 176 or better capabilities and functionality than the equivalent IPv4 177 architecture. 179 The end-user network is a stub network. Figure 1 illustrates the 180 model topology for the end-user network. 182 An example of a typical end-user network. 184 +-------+-------+ \ 185 | Service | \ 186 | Provider | | ISP 187 | Router | | network 188 +-------+-------+ | 189 | / 190 | Customer / 191 | Internet connection / 192 | 193 +------+--------+ \ 194 | IPv6 | \ 195 | Customer Edge | \ 196 | Router | / 197 +---+-------+-+-+ / 198 Network A | | Network B | Customer 199 ---+-------------+----+- --+--+-------------+--- |network(s) 200 | | | | \ 201 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 202 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 203 | | | | | | | | / 204 +----------+ +-----+----+ +----------+ +----------+/ 206 Figure 1 208 This architecture describes the: 210 o Basic capabilities of an IPv6 CE router 212 o Provisioning of the WAN interface connecting to the ISP 214 o Provisioning of the LAN interfaces 216 The IPv6 CE router defaults to acting as the demarcation point 217 between two networks by providing a ULA boundary, a multicast zone 218 boundary and ingress and egress traffic filters. 220 For IPv6 multicast traffic the IPv6 CE router may act as an MLD proxy 221 [RFC4605] and may support a dynamic multicast routing protocol. 223 IPv6 CE router may be manually configured in an arbitrary topology 224 with a dynamic routing protocol. Automatic provisioning and 225 configuration is described for a single IPv6 CE router only. 227 4. Use Cases and Requirements 229 4.1. WAN side configuration 231 The IPv6 CE router will need to support connectivity to one or more 232 access network architectures. This document describes an IPv6 CE 233 router that is not specific to any particular architecture or Service 234 Provider, and supports all commonly used architectures. 236 IPv6 Neighbor Discovery and DHCP protocols operate over any type of 237 IPv6 supported link-layer and there is no need for a link-layer 238 specific configuration protocol for IPv6 network layer configuration 239 options as in PPP IPCP for IPv4. This section makes the assumption 240 that the same mechanism will work for any link-layer, be it Ethernet, 241 DOCSIS, PPP/PPPoE or others. 243 When the router is attached to the WAN interface link it must act as 244 an IPv6 host for the purposes of stateless or stateful interface 245 address assignment ([RFC4862]/[RFC3315]). The router acts as a 246 requesting router for the purposes of DHCP prefix delegation 247 ([RFC3633]). 249 DHCP address assignment (IA_NA) and DHCP prefix delegation (IA_PD) 250 should be done as a single DHCP session. 252 Link-layer requirements: 254 WLL-1: The IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]. 256 WLL-2: The IPv6 CE router MUST support IPv6 over PPP [RFC5072] and 257 PPPoE [RFC2516]. In a dual-stack environment with IPCP and 258 IPV6CP running over one PPP logical channel, the NCPs MUST be 259 treated as independent of each other and start and terminate 260 independently. 262 Address assignment requirements: 264 WAA-1: The IPv6 CE router MUST support SLAAC [RFC4862]. 266 WAA-2: The IPv6 CE router MUST follow the recommendation in 267 [I-D.ietf-6man-ipv6-subnet-model] and in particular the 268 handling of the L-bit in the Router Advertisement Prefix 269 Information Option. 271 WAA-3: The IPv6 CE router MUST support DHCP [RFC3315] client 272 behavior. It MUST be able to support the following DHCP 273 options: IA_NA, Reconfigure Accept [RFC3315], DNS_SERVERS 274 [RFC3646]. 276 WAA-4: The IPv6 CE router SHOULD support the DHCP SNTP option 277 [RFC4075] and the Information Refresh Time Option [RFC4242]. 279 WAA-5: If the IPv6 CE router receives an RA message (described in 280 [RFC4861]) with the M-bit set to 1, the IPv6 CE router MUST 281 do DHCP address assignment (request an IA_NA option). If the 282 IPv6 CE router is unable to assign an address through SLAAC 283 it MAY do DHCP address assignment (request an IA_NA) even if 284 the M-bit is set to 0. 286 WAA-6: If the IPv6 CE router does not acquire a global IPv6 address 287 from either SLAAC or DHCP, then it MUST create a global IPv6 288 address from its delegated prefix and configure that on one 289 of its internal virtual network interfaces. As a router the 290 IPv6 CE router follows the weak host model [RFC1122] and when 291 originating packets out the WAN-interface will use a suitably 292 scoped source address from one of its other interfaces. 294 Prefix Delegation requirements: 296 WPD-1: The IPv6 CE router MUST support DHCP prefix delegation 297 requesting router behavior as specified in [RFC3633] (IA_PD 298 option). The IPv6 CE router MUST ask for a prefix large 299 enough to cover all of its LAN interfaces. 301 WPD-2: The IPv6 CE router MUST always initiate DHCP prefix 302 delegation, regardless of the M and O-bits in a received 303 Router Advertisement. If the IPv6 CE Router initiates DHCP 304 before receiving a Router Advertisement it MUST also request 305 an IA_NA option in DHCP. 307 WPD-3: Absent of other routing information the IPv6 CE router MUST 308 use Router Discovery as specified in [RFC4861] to discover a 309 default router and install a default route in its routing 310 table with the discovered router's address as the next-hop. 312 WPD-4: If the delegated prefix is an aggregate route of multiple, 313 more-specific routes the IPv6 CE router MUST discard packets 314 that match the aggregate route, but not any of the more- 315 specific routes. In other words, the "next-hop" for the 316 aggregate route should be the null destination. This is 317 necessary to prevent forwarding loops when some addresses 318 covered by the aggregate are not reachable [RFC4632]. The 319 IPv6 CE Router SHOULD send an ICMPv6 Destination Unreachable 320 according to section 3.1 [RFC4443] back to the source of the 321 packet if the packet is to be dropped due to this rule. 323 WPD-5: If the IPv6 CE router requests both an IA_NA and an IA_PD in 324 DHCP, it MUST accept an IA_PD in DHCP Advertise/Reply 325 messages, even if the message does not contain any addresses 326 (IA_NA options with status code NoAddrsAvail). 328 WPD-6: An IPv6 CE router MUST not by default initiate any dynamic 329 routing protocol on its WAN interface. 331 4.2. LAN side configuration 333 The IPv6 CE router distributes configuration information obtained 334 during WAN interface provisioning to IPv6 hosts and assists IPv6 335 hosts in obtaining IPv6 addresses. It also supports connectivity of 336 these devices in the absence of any working WAN interface. 338 An IPv6 CE router will be expected to support an IPv6 end-user 339 network and IPv6 hosts that exhibit the following characteristics: 341 1. Link-local addresses are insufficient for allowing IPv6 342 applications to communicate with each other in the end-user 343 network. The IPv6 CE router will need to enable this 344 communication by providing globally-scoped unicast addresses or 345 ULAs [RFC4193] whether or not WAN connectivity exists. 347 2. IPv6 hosts will be capable of using SLAAC and may be capable of 348 using DHCP for acquiring their addresses. 350 3. IPv6 hosts will use DHCP for other configuration information, 351 such as the DNS_SERVERS option for acquiring DNS information. 353 Unless otherwise specified these requirements only apply to the IPv6 354 CE router's LAN interfaces. 356 Requirements: 358 L-1: The IPv6 CE router MUST support ULA addressing [RFC4193]. 360 L-2: The IPv6 CE router MUST have a ULA prefix that it maintains 361 consistently across reboots. The value of the ULA prefix 362 SHOULD be user configurable. 364 L-3: The IPv6 CE router by default MUST act as a site border router 365 according to section 4.3 of [RFC4193] and filter packets with 366 Local IPv6 source or destination addresses accordingly. 368 L-4: The IPv6 CE router MUST support router behavior of Neighbor 369 Discovery for IPv6 [RFC4861]. 371 L-5: The IPv6 CE router MUST assign a separate /64 from its 372 delegated prefix (and ULA prefix if configured to provide ULA 373 addressing) for each of its LAN interfaces. The IPV6 CE 374 router MUST make the interface an advertising interface 375 according to [RFC4861]. In router advertisements messages, 376 the Prefix Information Option's A/L-bits MUST be set to 1 by 377 default; the A/L bits setting SHOULD be user configurable. 379 L-6: The IPv6 CE router MUST support a DHCP server [RFC3315] on its 380 LAN interfaces. It MAY support Stateless Dynamic Host 381 Configuration Protocol (DHCP) Service for IPv6 [RFC3736]. 383 L-7: The IPv6 CE SHOULD support DHCP address assignment (IA_NA) 384 [RFC3315]. 386 L-8: Unless the IPv6 CE router is configured to support the DHCP 387 IA_NA option, it SHOULD set M=0 and O=1 in its Router 388 Advertisement messages [RFC4861]. 390 L-9: The IPv6 CE router MUST support providing DNS information in 391 the DHCP DNS_SERVERS option [RFC3646]. 393 L-10: The IPv6 CE router SHOULD pass the additional set of DHCP 394 options received from the DHCP client on its WAN interface 395 from the Service Provider to IPv6 hosts. 397 4.3. General requirements 399 The IPv6 CE router is responsible for implementing IPv6 routing; that 400 is, the IPv6 CE router must look up the IPv6 Destination address in 401 its routing table to decide to which interface it should send the 402 packet. 404 In this role, the IPv6 CE router is responsible for ensuring that 405 traffic using its ULA addressing does not go out the WAN interface, 406 and does not originate from the WAN interface. 408 An IPv6 CE router is an IPv6 node according to the IPv6 Node 409 Requirements [RFC4294] specification. 411 The IPv6 CE router MUST NOT forward any IPv6 traffic between its LAN 412 Interface(s) and its WAN Interface until the router has successfully 413 completed the IPv6 address acquisition process. 415 4.4. Security Considerations 417 It is considered a best practice to filter obviously malicious 418 traffic (e.g. spoofed packets, "martian" addresses, etc.). Thus, the 419 IPv6 CE router should support basic stateless egress and ingress 420 filters. The CE router should also offer mechanisms to filter 421 traffic entering the customer network; however, the method by which 422 vendors implement configurable packet filtering is beyond the scope 423 of this document. 425 Security requirements: 427 S-1: The IPv6 CE router SHOULD support 428 [I-D.ietf-v6ops-cpe-simple-security]. 430 S-2: The IPv6 CE router MUST support ingress filtering in accordance 431 with [RFC2827](BCP 38) 433 5. Acknowledgements 435 Thanks to the following people (in alphabetical order) for their 436 guidance and feedback: 438 Mikael Abrahamsson, Merete Asak, Scott Beuker, Rex Bullinger, Brian 439 Carpenter, Remi Denis-Courmont, Alain Durand, Katsunori Fukuoka, Tony 440 Hain, Thomas Herbst, Kevin Johns, Stephen Kramer, Victor Kuarsingh, 441 Francois-Xavier Le Bail, David Miles, Shin Miyakawa, Jean-Francois 442 Mule, Michael Newbery, Carlos Pignataro, John Pomeroy, Antonio 443 Querubin, Teemu Savolainen, Matt Schmitt, Hiroki Sato, Mark Townsley, 444 Bernie Volz, James Woodyatt, Dan Wing and Cor Zwart 446 This draft is based in part on CableLabs' eRouter specification. The 447 authors wish to acknowledge the additional contributors from the 448 eRouter team: 450 Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas, 451 Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego 452 Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur 453 Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan 454 Torbet and Greg White 456 6. Contributors 458 The following people have participated as co-authors or provided 459 substantial contributions to this document: Ralph Droms, Kirk 460 Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, 461 Yiu Lee, John Jason Brzozowski and Heather Kirksey. 463 7. IANA Considerations 465 This memo includes no request to IANA. 467 8. Normative References 469 [I-D.ietf-6man-ipv6-subnet-model] 470 Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 471 Model: the Relationship between Links and Subnet 472 Prefixes", draft-ietf-6man-ipv6-subnet-model-06 (work in 473 progress), November 2009. 475 [I-D.ietf-v6ops-cpe-simple-security] 476 Woodyatt, J., "Recommended Simple Security Capabilities in 477 Customer Premises Equipment for Providing Residential IPv6 478 Internet Service", draft-ietf-v6ops-cpe-simple-security-08 479 (work in progress), October 2009. 481 [RFC1122] Braden, R., "Requirements for Internet Hosts - 482 Communication Layers", STD 3, RFC 1122, October 1989. 484 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 485 Requirement Levels", BCP 14, RFC 2119, March 1997. 487 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 488 Networks", RFC 2464, December 1998. 490 [RFC2516] Mamakos, L., Lidl, K., Evarts, J., Carrel, D., Simone, D., 491 and R. Wheeler, "A Method for Transmitting PPP Over 492 Ethernet (PPPoE)", RFC 2516, February 1999. 494 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 495 Defeating Denial of Service Attacks which employ IP Source 496 Address Spoofing", BCP 38, RFC 2827, May 2000. 498 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 499 and M. Carney, "Dynamic Host Configuration Protocol for 500 IPv6 (DHCPv6)", RFC 3315, July 2003. 502 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 503 Host Configuration Protocol (DHCP) version 6", RFC 3633, 504 December 2003. 506 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 507 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 508 December 2003. 510 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 511 (DHCP) Service for IPv6", RFC 3736, April 2004. 513 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 514 Configuration Option for DHCPv6", RFC 4075, May 2005. 516 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 517 Addresses", RFC 4193, October 2005. 519 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 520 Time Option for Dynamic Host Configuration Protocol for 521 IPv6 (DHCPv6)", RFC 4242, November 2005. 523 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 524 April 2006. 526 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 527 Message Protocol (ICMPv6) for the Internet Protocol 528 Version 6 (IPv6) Specification", RFC 4443, March 2006. 530 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 531 "Internet Group Management Protocol (IGMP) / Multicast 532 Listener Discovery (MLD)-Based Multicast Forwarding 533 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 535 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 536 (CIDR): The Internet Address Assignment and Aggregation 537 Plan", BCP 122, RFC 4632, August 2006. 539 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 540 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 541 Access Networks", RFC 4779, January 2007. 543 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 544 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 545 September 2007. 547 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 548 Address Autoconfiguration", RFC 4862, September 2007. 550 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 551 E. Klein, "Local Network Protection for IPv6", RFC 4864, 552 May 2007. 554 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 555 PPP", RFC 5072, September 2007. 557 Appendix A. Changes in revision 3 559 o Added "the CPE Router SHOULD send an ICMPv6 Destination 560 Unreachable ([RFC4443] section 3.1) back to the source of the 561 packet if the packet is to be dropped due to aggregate null 562 route." 564 o Clarified that if IPV6CP and IPCP run over the same PPP session 565 they should be treated independently. 567 o Removed RFC2460 in the section of RFCs that SHOULD be supported. 569 o Clarified that the router acts as a host for the purposes of 570 address assignment. Not for any other ND function e.g Redirects. 572 o Improved default router selection / default route RIB insertion 573 text. 575 o Added text describing that the weak host model has to be supported 576 in the unnumbered WAN case. 578 Authors' Addresses 580 Hemant Singh 581 Cisco Systems, Inc. 582 1414 Massachusetts Ave. 583 Boxborough, MA 01719 584 USA 586 Phone: +1 978 936 1622 587 Email: shemant@cisco.com 588 URI: http://www.cisco.com/ 589 Wes Beebee 590 Cisco Systems, Inc. 591 1414 Massachusetts Ave. 592 Boxborough, MA 01719 593 USA 595 Phone: +1 978 936 2030 596 Email: wbeebee@cisco.com 597 URI: http://www.cisco.com/ 599 Chris Donley 600 CableLabs 601 858 Coal Creek Circle 602 Louisville, CO 80027 603 USA 605 Email: c.donley@cablelabs.com 607 Barbara Stark 608 AT&T 609 725 W Peachtree St 610 Atlanta, GA 30308 611 USA 613 Email: barbara.stark@att.com 615 Ole Troan (editor) 616 Cisco Systems, Inc. 617 Veversmauet 8 618 N-5017 BERGEN, 619 Norway 621 Phone: 622 Email: ot@cisco.com