idnits 2.17.1 draft-ietf-v6ops-ipv6-cpe-router-05.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 date (May 11, 2010) is 5092 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2827' is defined on line 557, but no explicit reference was found in the text == Outdated reference: A later version (-11) exists of draft-ietf-6man-node-req-bis-04 == Outdated reference: A later version (-16) exists of draft-ietf-v6ops-cpe-simple-security-11 ** 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) == Outdated reference: A later version (-10) exists of draft-ietf-behave-v6v4-framework-08 Summary: 4 errors (**), 0 flaws (~~), 5 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: November 12, 2010 C. Donley 6 CableLabs 7 B. Stark 8 AT&T 9 O. Troan, Ed. 10 Cisco Systems, Inc. 11 May 11, 2010 13 Basic Requirements for IPv6 Customer Edge Routers 14 draft-ietf-v6ops-ipv6-cpe-router-05 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 basic provisioning of an IPv6 CE router and the provisioning 21 of IPv6 hosts attached to it. 23 Status of this Memo 25 This Internet-Draft is submitted 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). Note that other groups may also distribute 30 working documents as Internet-Drafts. The list of current Internet- 31 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on November 12, 2010. 40 Copyright Notice 42 Copyright (c) 2010 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents 47 (http://trustee.ietf.org/license-info) in effect on the date of 48 publication of this document. Please review these documents 49 carefully, as they describe your rights and restrictions with respect 50 to this document. Code Components extracted from this document must 51 include Simplified BSD License text as described in Section 4.e of 52 the Trust Legal Provisions and are provided without warranty as 53 described in the Simplified BSD License. 55 Table of Contents 57 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 58 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 59 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 60 3. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3.1. Current IPv4 End-user Network Architecture . . . . . . . . 4 62 3.2. IPv6 End-user Network Architecture . . . . . . . . . . . . 5 63 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 6 65 4.2. WAN Side Configuration . . . . . . . . . . . . . . . . . . 6 66 4.3. LAN Side Configuration . . . . . . . . . . . . . . . . . . 9 67 4.4. Security Considerations . . . . . . . . . . . . . . . . . 11 68 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 69 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 70 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 71 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 72 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 73 8.2. Informative References . . . . . . . . . . . . . . . . . . 14 74 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 76 1. Introduction 78 This document defines basic IPv6 features for a residential or small 79 office router referred to as an IPv6 CE router. Typically these 80 routers also support IPv4. 82 Mixed environments of dual-stack hosts and IPv6-only hosts (behind 83 the CE router) can be more complex if the IPv6-only devices are using 84 a translator to access IPv4 servers [I-D.ietf-behave-v6v4-framework]. 85 Support for such mixed environments is not in scope of this document. 87 This document specifies how an IPv6 CE router automatically 88 provisions its WAN interface, acquires address space for provisioning 89 of its LAN interfaces and fetches other configuration information 90 from the service provider network. Automatic provisioning of more 91 complex topology than a single router with multiple LAN interfaces is 92 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 110 explicitly addressed to itself. The IPv6 111 CE router connects the end-user network to 112 a service provider network. 114 IPv6 host any device implementing an IPv6 stack 115 receiving IPv6 connectivity through the 116 IPv6 CE router 118 LAN interface an IPv6 CE router's attachment to a link in 119 the end-user network. Examples are 120 Ethernets (simple or bridged), 802.11 121 wireless or other LAN technologies. An 122 IPv6 CE router may have one or more network 123 layer LAN Interfaces. 125 Service Provider an entity that provides access to the 126 Internet. In this document, a Service 127 Provider specifically offers Internet 128 access using IPv6, and may also offer IPv4 129 Internet access. The Service Provider can 130 provide such access over a variety of 131 different transport methods such as DSL, 132 cable, wireless, and others. 134 WAN interface an IPv6 CE router's attachment to a link 135 used to provide connectivity to the Service 136 Provider network; example link technologies 137 include Ethernets (simple or bridged), PPP 138 links, Frame Relay, or ATM networks as well 139 as Internet-layer (or higher-layer) 140 "tunnels", such as tunnels over IPv4 or 141 IPv6 itself. 143 3. Architecture 145 3.1. Current IPv4 End-user Network Architecture 147 An end-user network will likely support both IPv4 and IPv6. It is 148 not expected that an end-user will change their existing network 149 topology with the introduction of IPv6. There are some differences 150 in how IPv6 works and is provisioned which has implications for the 151 network architecture. A typical IPv4 end-user network consist of a 152 "plug and play" router with NAT functionality and a single link 153 behind it, connected to the Service Provider network. 155 A typical IPv4 NAT deployment by default blocks all incoming 156 connections. Opening of ports is typically allowed using UPnP IGD 157 [UPnP-IGD] or 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 Service Providers, and the addresses are always 162 there even when the WAN interface is down or the customer edge router 163 has not 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 a fail-over event [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 current 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 | | Service 187 | Router | | Provider 188 +-------+-------+ | network 189 | / 190 | Customer / 191 | Internet connection / 192 | 193 +------+--------+ \ 194 | IPv6 | \ 195 | Customer Edge | \ 196 | Router | / 197 +---+-------+-+-+ / 198 Network A | | Network B | End-User 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 Service 213 Provider 215 o Provisioning of the LAN interfaces 217 Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] are used by hosts 218 communicating within the End-user Network; this is functionally 219 similar to RFC1918 addresses used within an IPv4 End-user Network. 220 The IPv6 CE router defaults to acting as the demarcation point 221 between two networks by providing a ULA boundary, a multicast zone 222 boundary and ingress and egress traffic filters. 224 For IPv6 multicast traffic the IPv6 CE router may act as an MLD proxy 225 [RFC4605] and may support a dynamic multicast routing protocol. 227 The IPv6 CE router may be manually configured in an arbitrary 228 topology with a dynamic routing protocol. Automatic provisioning and 229 configuration is described for a single IPv6 CE router only. 231 4. Requirements 233 4.1. General Requirements 235 The IPv6 CE router is responsible for implementing IPv6 routing; that 236 is, the IPv6 CE router must look up the IPv6 Destination address in 237 its routing table to decide to which interface it should send the 238 packet. 240 In this role, the IPv6 CE router is responsible for ensuring that 241 traffic using its ULA addressing does not go out the WAN interface, 242 and does not originate from the WAN interface. 244 G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node 245 Requirements [I-D.ietf-6man-node-req-bis] specification. 247 G-2: The IPv6 CE router MUST implement ICMP according to [RFC4443]. 248 In particular point to point links MUST be handled as described 249 in section 3.1 of [RFC4443]. 251 G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between 252 its LAN Interface(s) and its WAN Interface until the router has 253 successfully completed the IPv6 address acquisition process. 255 4.2. WAN Side Configuration 257 The IPv6 CE router will need to support connectivity to one or more 258 access network architectures. This document describes an IPv6 CE 259 router that is not specific to any particular architecture or Service 260 Provider, and supports all commonly used architectures. 262 IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of 263 IPv6 supported link-layer and there is no need for a link-layer 264 specific configuration protocol for IPv6 network layer configuration 265 options as in e.g. PPP IPCP for IPv4. This section makes the 266 assumption that the same mechanism will work for any link-layer, be 267 it Ethernet, DOCSIS, PPP or others. 269 WAN side requirements: 271 W-1: When the router is attached to the WAN interface link it MUST 272 act as an IPv6 host for the purposes of stateless or stateful 273 interface address assignment ([RFC4862]/[RFC3315]). 275 W-2: The IPv6 CE router MUST generate a link-local address and 276 finish Duplicate Address Detection according to [RFC4862] prior 277 to sending any Router Solicitations on the interface. The 278 source address used in the subsequent Router Solicitation MUST 279 be the link-local address on the WAN interface. 281 W-3: Absent of other routing information the IPv6 CE router MUST use 282 Router Discovery as specified in [RFC4861] to discover a 283 default router(s) and install default route(s) in its routing 284 table with the discovered router's address as the next-hop. 286 W-4: The router MUST act as a requesting router for the purposes of 287 DHCPv6 prefix delegation ([RFC3633]). 289 W-5: DHCPv6 address assignment (IA_NA) and DHCPv6 prefix delegation 290 (IA_PD) SHOULD be done as a single DHCPv6 session. 292 Link-layer requirements: 294 WLL-1: If the WAN interface supports Ethernet encapsulation, then 295 the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]. 297 WLL-2: If the WAN interface supports PPP encapsulation the IPv6 CE 298 router MUST support IPv6 over PPP [RFC5072]. 300 WLL-3: If the WAN interface supports PPP encapsulation, in a dual- 301 stack environment with IPCP and IPV6CP running over one PPP 302 logical channel, the NCPs MUST be treated as independent of 303 each other and start and terminate independently. 305 Address assignment requirements: 307 WAA-1: The IPv6 CE router MUST support SLAAC [RFC4862]. 309 WAA-2: The IPv6 CE router MUST follow the recommendation in 310 [I-D.ietf-6man-ipv6-subnet-model] and in particular the 311 handling of the L-flag in the Router Advertisement Prefix 312 Information Option. 314 WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client 315 behavior. 317 WAA-4: The IPv6 CE router MUST be able to support the following 318 DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], 319 DNS_SERVERS [RFC3646]. 321 WAA-5: The IPv6 CE router SHOULD support the DHCPv6 SNTP option 322 [RFC4075] and the Information Refresh Time Option [RFC4242]. 324 WAA-6: If the IPv6 CE router receives an RA message (described in 325 [RFC4861]) with the M-flag set to 1, the IPv6 CE router MUST 326 do DHCPv6 address assignment (request an IA_NA option). 328 WAA-7: If the IPv6 CE router is unable to assign address(es) through 329 SLAAC it MAY do DHCPv6 address assignment (request an IA_NA) 330 even if the M-flag is set to 0. 332 WAA-8: If the IPv6 CE router does not acquire global IPv6 333 address(es) from either SLAAC or DHCPv6, then it MUST create 334 global IPv6 address(es) from its delegated prefix(es) and 335 configure those on one of its internal virtual network 336 interfaces. 338 WAA-9: As a router the IPv6 CE router MUST follow the weak host 339 model [RFC1122]. When originating packets out an interface 340 it will use a source address from another of its interfaces 341 if the outgoing interface does not have an address of 342 suitable scope. 344 Prefix Delegation requirements: 346 WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation 347 requesting router behavior as specified in [RFC3633] (IA_PD 348 option). 350 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating 351 router the size of the prefix it requires. If so, it MUST 352 ask for a prefix large enough to assign one /64 for each of 353 its interfaces rounded up to the nearest nibble and MUST be 354 configurable to ask for more. 356 WPD-3: The IPv6 CE router MUST be prepared to accept a delegated 357 prefix size different from what is given in the hint. If the 358 delegated prefix is too small to address all of its 359 interfaces, the IPv6 CE router SHOULD log a system management 360 error. 362 WPD-4: The IPv6 CE router MUST always initiate DHCPv6 prefix 363 delegation, regardless of the M and O-flags in a received 364 Router Advertisement message. 366 WPD-5: If the IPv6 CE Router initiates DHCPv6 before receiving a 367 Router Advertisement it MUST also request an IA_NA option in 368 DHCPv6. 370 WPD-6: If the delegated prefix(es) are aggregate route(s) of 371 multiple, more-specific routes, the IPv6 CE router MUST 372 discard packets that match the aggregate route(s), but not 373 any of the more-specific routes. In other words, the next- 374 hop for the aggregate route(s) should be the null 375 destination. This is necessary to prevent forwarding loops 376 when some addresses covered by the aggregate are not 377 reachable [RFC4632]. 379 (a) The IPv6 CE router SHOULD send an ICMPv6 Destination 380 Unreachable according to section 3.1 [RFC4443] back to 381 the source of the packet, if the packet is to be dropped 382 due to this rule. 384 WPD-7: If the IPv6 CE router requests both an IA_NA and an IA_PD in 385 DHCPv6, it MUST accept an IA_PD in DHCPv6 Advertise/Reply 386 messages, even if the message does not contain any addresses 387 (IA_NA options with status code equal to NoAddrsAvail). 389 WPD-8: By default an IPv6 CE router MUST NOT initiate any dynamic 390 routing protocol on its WAN interface. 392 4.3. LAN Side Configuration 394 The IPv6 CE router distributes configuration information obtained 395 during WAN interface provisioning to IPv6 hosts and assists IPv6 396 hosts in obtaining IPv6 addresses. It also supports connectivity of 397 these devices in the absence of any working WAN interface. 399 An IPv6 CE router is expected to support an IPv6 end-user network and 400 IPv6 hosts that exhibit the following characteristics: 402 1. Link-local addresses are insufficient for allowing IPv6 403 applications to communicate with each other in the end-user 404 network. The IPv6 CE router will need to enable this 405 communication by providing globally-scoped unicast addresses or 406 ULAs [RFC4193] whether or not WAN connectivity exists. 408 2. IPv6 hosts should be capable of using SLAAC and may be capable of 409 using DHCPv6 for acquiring their addresses. 411 3. IPv6 hosts may use DHCPv6 for other configuration information, 412 such as the DNS_SERVERS option for acquiring DNS information. 414 Unless otherwise specified, the following requirements apply to the 415 IPv6 CE router's LAN interfaces only. 417 Requirements: 419 L-1: The IPv6 CE router MUST support ULA addressing [RFC4193]. 421 L-2: The IPv6 CE router MUST have a ULA prefix that it maintains 422 consistently across reboots. 424 L-3: The value of the ULA prefix SHOULD be user configurable. 426 L-4: By default the IPv6 CE router MUST act as a site border router 427 according to section 4.3 of [RFC4193] and filter packets with 428 Local IPv6 source or destination addresses accordingly. 430 L-5: The IPv6 CE router MUST support router behavior according to 431 Neighbor Discovery for IPv6 [RFC4861]. 433 L-6: The IPv6 CE router MUST assign a separate /64 from its 434 delegated prefix(es) (and ULA prefix if configured to provide 435 ULA addressing) for each of its LAN interfaces. 437 L-7: The IPv6 CE router MUST make each LAN interface an advertising 438 interface according to [RFC4861]. 440 L-8: In Router Advertisements messages, the Prefix Information 441 Option's A and L-flags MUST be set to 1 by default. 443 L-9: The A and L-flags setting SHOULD be user configurable. 445 L-10: The IPv6 CE router MUST support a DHCPv6 server capable of 446 IPv6 address assignment according to [RFC3315] OR a stateless 447 DHCPv6 server according to [RFC3736] on its LAN interfaces. 449 L-11: Unless the IPv6 CE router is configured to support the DHCPv6 450 IA_NA option, it SHOULD set M=0 and O=1 in its Router 451 Advertisement messages [RFC4861]. 453 L-12: The IPv6 CE router MUST support providing DNS information in 454 the DHCPv6 DNS_SERVERS option [RFC3646]. 456 L-13: The IPv6 CE router SHOULD make available a subset of DHCPv6 457 options (as listed in section 5.3 of [RFC3736]) received from 458 the DHCPv6 client on its WAN interface to its LAN side DHCPv6 459 server. 461 L-14: If the delegated prefix changes, i.e. the current prefix is 462 replaced with a new prefix without any overlapping time 463 period, then the IPv6 CE router MUST immediately advertise the 464 old prefix with a preferred lifetime of 0 and a valid lifetime 465 of 2 hours (which must be decremented in real time) in a 466 Router Advertisement message. 468 L-15: The IPv6 CE router MUST send an ICMP Destination Unreachable 469 Message, code 5 (Source address failed ingress/egress policy) 470 for packets forwarded to it using an address from a prefix 471 which has been deprecated. 473 4.4. Security Considerations 475 It is considered a best practice to filter obviously malicious 476 traffic (e.g. spoofed packets, "martian" addresses, etc.). Thus, the 477 IPv6 CE router should support basic stateless egress and ingress 478 filters. The CE router should also offer mechanisms to filter 479 traffic entering the customer network; however, the method by which 480 vendors implement configurable packet filtering is beyond the scope 481 of this document. 483 Security requirements: 485 S-1: The IPv6 CE router SHOULD support 486 [I-D.ietf-v6ops-cpe-simple-security]. 488 S-2: The IPv6 CE router MUST support ingress filtering in accordance 489 with [RFC2827](BCP 38) 491 5. Acknowledgements 493 Thanks to the following people (in alphabetical order) for their 494 guidance and feedback: 496 Mikael Abrahamsson, Merete Asak, Scott Beuker, Mohamed Boucadair, Rex 497 Bullinger, Brian Carpenter, Remi Denis-Courmont, Gert Doering, Alain 498 Durand, Katsunori Fukuoka, Tony Hain, Thomas Herbst, Kevin Johns, 499 Stephen Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, David 500 Miles, Shin Miyakawa, Jean-Francois Mule, Michael Newbery, Carlos 501 Pignataro, John Pomeroy, Antonio Querubin, Teemu Savolainen, Matt 502 Schmitt, Hiroki Sato, Mark Townsley, Bernie Volz, James Woodyatt, Dan 503 Wing and Cor Zwart 505 This draft is based in part on CableLabs' eRouter specification. The 506 authors wish to acknowledge the additional contributors from the 507 eRouter team: 509 Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas, 510 Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego 511 Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur 512 Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan 513 Torbet and Greg White 515 6. Contributors 517 The following people have participated as co-authors or provided 518 substantial contributions to this document: Ralph Droms, Kirk 519 Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, 520 Yiu Lee, John Jason Brzozowski and Heather Kirksey. 522 7. IANA Considerations 524 This memo includes no request to IANA. 526 8. References 528 8.1. Normative References 530 [I-D.ietf-6man-ipv6-subnet-model] 531 Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 532 Model: the Relationship between Links and Subnet 533 Prefixes", draft-ietf-6man-ipv6-subnet-model-12 (work in 534 progress), April 2010. 536 [I-D.ietf-6man-node-req-bis] 537 Jankiewicz, E., Loughney, J., and T. Narten, "IPv6 Node 538 Requirements RFC 4294-bis", 539 draft-ietf-6man-node-req-bis-04 (work in progress), 540 March 2010. 542 [I-D.ietf-v6ops-cpe-simple-security] 543 Woodyatt, J., "Recommended Simple Security Capabilities in 544 Customer Premises Equipment for Providing Residential IPv6 545 Internet Service", draft-ietf-v6ops-cpe-simple-security-11 546 (work in progress), April 2010. 548 [RFC1122] Braden, R., "Requirements for Internet Hosts - 549 Communication Layers", STD 3, RFC 1122, October 1989. 551 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 552 Requirement Levels", BCP 14, RFC 2119, March 1997. 554 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 555 Networks", RFC 2464, December 1998. 557 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 558 Defeating Denial of Service Attacks which employ IP Source 559 Address Spoofing", BCP 38, RFC 2827, May 2000. 561 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 562 and M. Carney, "Dynamic Host Configuration Protocol for 563 IPv6 (DHCPv6)", RFC 3315, July 2003. 565 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 566 Host Configuration Protocol (DHCP) version 6", RFC 3633, 567 December 2003. 569 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 570 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 571 December 2003. 573 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 574 (DHCP) Service for IPv6", RFC 3736, April 2004. 576 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 577 Configuration Option for DHCPv6", RFC 4075, May 2005. 579 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 580 Addresses", RFC 4193, October 2005. 582 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 583 Time Option for Dynamic Host Configuration Protocol for 584 IPv6 (DHCPv6)", RFC 4242, November 2005. 586 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 587 Message Protocol (ICMPv6) for the Internet Protocol 588 Version 6 (IPv6) Specification", RFC 4443, March 2006. 590 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 591 "Internet Group Management Protocol (IGMP) / Multicast 592 Listener Discovery (MLD)-Based Multicast Forwarding 593 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 595 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 596 (CIDR): The Internet Address Assignment and Aggregation 597 Plan", BCP 122, RFC 4632, August 2006. 599 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 600 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 601 Access Networks", RFC 4779, January 2007. 603 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 604 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 605 September 2007. 607 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 608 Address Autoconfiguration", RFC 4862, September 2007. 610 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 611 E. Klein, "Local Network Protection for IPv6", RFC 4864, 612 May 2007. 614 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 615 PPP", RFC 5072, September 2007. 617 8.2. Informative References 619 [I-D.ietf-behave-v6v4-framework] 620 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 621 IPv4/IPv6 Translation", 622 draft-ietf-behave-v6v4-framework-08 (work in progress), 623 March 2010. 625 [UPnP-IGD] 626 UPnP Forum, "Universal Plug and Play (UPnP) Internet 627 Gateway Device (IGD)", November 2001, 628 . 630 Authors' Addresses 632 Hemant Singh 633 Cisco Systems, Inc. 634 1414 Massachusetts Ave. 635 Boxborough, MA 01719 636 USA 638 Phone: +1 978 936 1622 639 Email: shemant@cisco.com 640 URI: http://www.cisco.com/ 642 Wes Beebee 643 Cisco Systems, Inc. 644 1414 Massachusetts Ave. 645 Boxborough, MA 01719 646 USA 648 Phone: +1 978 936 2030 649 Email: wbeebee@cisco.com 650 URI: http://www.cisco.com/ 652 Chris Donley 653 CableLabs 654 858 Coal Creek Circle 655 Louisville, CO 80027 656 USA 658 Email: c.donley@cablelabs.com 660 Barbara Stark 661 AT&T 662 725 W Peachtree St 663 Atlanta, GA 30308 664 USA 666 Email: barbara.stark@att.com 667 Ole Troan (editor) 668 Cisco Systems, Inc. 669 Veversmauet 8 670 N-5017 BERGEN, 671 Norway 673 Email: ot@cisco.com