idnits 2.17.1 draft-wbeebee-v6ops-ipv6-cpe-router-bis-04.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 (October 25, 2010) is 4931 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.vyncke-advanced-ipv6-security' is defined on line 521, but no explicit reference was found in the text == Unused Reference: 'RFC1122' is defined on line 526, but no explicit reference was found in the text == Unused Reference: 'RFC2080' is defined on line 529, but no explicit reference was found in the text == Unused Reference: 'RFC2464' is defined on line 535, but no explicit reference was found in the text == Unused Reference: 'RFC2827' is defined on line 543, but no explicit reference was found in the text == Unused Reference: 'RFC3315' is defined on line 547, but no explicit reference was found in the text == Unused Reference: 'RFC3633' is defined on line 551, but no explicit reference was found in the text == Unused Reference: 'RFC3646' is defined on line 555, but no explicit reference was found in the text == Unused Reference: 'RFC3736' is defined on line 559, but no explicit reference was found in the text == Unused Reference: 'RFC4075' is defined on line 565, but no explicit reference was found in the text == Unused Reference: 'RFC4193' is defined on line 568, but no explicit reference was found in the text == Unused Reference: 'RFC4242' is defined on line 571, but no explicit reference was found in the text == Unused Reference: 'RFC4294' is defined on line 575, but no explicit reference was found in the text == Unused Reference: 'RFC4443' is defined on line 578, but no explicit reference was found in the text == Unused Reference: 'RFC4541' is defined on line 582, but no explicit reference was found in the text == Unused Reference: 'RFC4632' is defined on line 592, but no explicit reference was found in the text == Unused Reference: 'RFC4779' is defined on line 596, but no explicit reference was found in the text == Unused Reference: 'RFC4862' is defined on line 604, but no explicit reference was found in the text == Unused Reference: 'RFC4864' is defined on line 607, but no explicit reference was found in the text == Unused Reference: 'RFC5072' is defined on line 611, but no explicit reference was found in the text == Unused Reference: 'RFC5571' is defined on line 614, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-behave-v6v4-framework' is defined on line 625, but no explicit reference was found in the text == Unused Reference: 'UPnP-IGD' is defined on line 631, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-softwire-ds-lite-tunnel-option-05 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-06 == Outdated reference: A later version (-09) exists of draft-ietf-v6ops-ipv6-cpe-router-07 == Outdated reference: A later version (-03) exists of draft-vyncke-advanced-ipv6-security-01 ** 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: 5 errors (**), 0 flaws (~~), 28 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: April 28, 2011 C. Donley 6 CableLabs 7 B. Stark 8 AT&T 9 O. Troan, Ed. 10 Cisco Systems, Inc. 11 October 25, 2010 13 Advanced Requirements for IPv6 Customer Edge Routers 14 draft-wbeebee-v6ops-ipv6-cpe-router-bis-04 16 Abstract 18 This document continues the work undertaken by the IPv6 CE Router 19 Phase I work in the IETF v6ops Working Group. Advanced requirements 20 or Phase II work is covered in this document. 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on April 28, 2011. 39 Copyright Notice 41 Copyright (c) 2010 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Table of Contents 56 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 57 1.1. Requirements Language . . . . . . . . . . . . . . . . . . 3 58 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 3. Conceptual Configuration Variables . . . . . . . . . . . . . . 4 60 4. Architecture . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 5. Advanced Features and Feature Requirements . . . . . . . . . . 6 62 5.1. DNS . . . . . . . . . . . . . . . . . . . . . . . . . . . 6 63 5.2. Multicast Behavior . . . . . . . . . . . . . . . . . . . . 6 64 5.3. ND Proxy . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 5.4. Prefix Delegation on LAN interface(s) (More details 66 are TBD) . . . . . . . . . . . . . . . . . . . . . . . . . 8 67 5.5. Routed network behavior(General Cases TBD) . . . . . . . . 8 68 5.6. Transition Technologies Support . . . . . . . . . . . . . 9 69 5.6.1. Dual-Stack(DS)-Lite . . . . . . . . . . . . . . . . . 9 70 5.6.2. 6rd . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5.6.3. Transition Technologies Coexistence . . . . . . . . . 10 72 5.7. Quality Of Service . . . . . . . . . . . . . . . . . . . . 11 73 5.8. Unicast Data Forwarding . . . . . . . . . . . . . . . . . 11 74 5.9. ZeroConf . . . . . . . . . . . . . . . . . . . . . . . . . 11 75 6. Security Considerations . . . . . . . . . . . . . . . . . . . 11 76 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 11 77 8. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 12 78 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 79 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 80 10.1. Normative References . . . . . . . . . . . . . . . . . . . 12 81 10.2. Informative References . . . . . . . . . . . . . . . . . . 15 82 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15 84 1. Introduction 86 This document defines Advanced IPv6 features for a residential or 87 small office router referred to as an IPv6 CE router. Typically 88 these routers also support IPv4. The IPv6 End-user Network 89 Architecture for such a router is described in 90 [I-D.ietf-v6ops-ipv6-cpe-router]. This version of the document 91 includes the requirements for Advanced features. 93 1.1. Requirements Language 95 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 96 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 97 document are to be interpreted as described in RFC 2119 [RFC2119]. 99 2. Terminology 101 End-user Network one or more links attached to the IPv6 CE 102 router that connect IPv6 hosts. 104 IPv6 Customer Edge router a node intended for home or small office 105 use which forwards IPv6 packets not 106 explicitly addressed to itself. The IPv6 107 CE router connects the end-user network to 108 a service provider network. 110 IPv6 host any device implementing an IPv6 stack 111 receiving IPv6 connectivity through the 112 IPv6 CE router 114 LAN interface an IPv6 CE router's attachment to a link in 115 the end-user network. Examples are 116 Ethernets (simple or bridged), 802.11 117 wireless or other LAN technologies. An 118 IPv6 CE router may have one or more network 119 layer LAN Interfaces. 121 Service Provider an entity that provides access to the 122 Internet. In this document, a Service 123 Provider specifically offers Internet 124 access using IPv6, and may also offer IPv4 125 Internet access. The Service Provider can 126 provide such access over a variety of 127 different transport methods such as DSL, 128 cable, wireless, and others. 130 WAN interface an IPv6 CE router's attachment to a link 131 used to provide connectivity to the Service 132 Provider network; example link technologies 133 include Ethernets (simple or bridged), PPP 134 links, Frame Relay, or ATM networks as well 135 as Internet-layer (or higher-layer) 136 "tunnels", such as tunnels over IPv4 or 137 IPv6 itself. 139 3. Conceptual Configuration Variables 141 The CE Router maintains such a list of conceptual optional 142 configuration variables. 144 1. Enable an IGP on the LAN. 146 4. Architecture 148 This document extends the architecture described in 149 [I-D.ietf-v6ops-ipv6-cpe-router] to cover a strictly larger set of 150 operational scenarios. In particular, QoS, multicast, DNS, routed 151 network in the home, transition technologies, and conceptual 152 configuration variables. This document also extends the model 153 described in [I-D.ietf-v6ops-ipv6-cpe-router] to a two router 154 topology where the two routers are connected back-to-back (the LAN of 155 one router is connected to the WAN of the other router). This 156 topology is depicted below: 158 +-------+-------+ \ 159 | Service | \ 160 | Provider | | Service 161 | Router | | Provider 162 +-------+-------+ | network 163 | / 164 | Customer / 165 | Internet connection / 166 | 167 +------+--------+ \ 168 | IPv6 | \ 169 | Customer Edge | \ 170 | Router | | 171 +----+-+-----+--+ | 172 Network A | | | Network B | 173 ----+-------------+----+ | --+--+-------------+--- | 174 | | | | | | | 175 +----+-----+ +-----+----+ | +----+-----+ +-----+----+ | 176 |IPv6 Host | |IPv6 Host | | | IPv6 Host| |IPv6 Host | | 177 | | | | | | | | | | 178 +----------+ +-----+----+ | +----------+ +----------+ | 179 | | 180 +------+--------+ | End-User 181 | IPv6 | | networks 182 | Interior | | 183 | Router | | 184 +---+-------+-+-+ | 185 Network C | | Network D | 186 ----+-------------+---+- --+---+-------------+--- | 187 | | | | | 188 +----+-----+ +-----+----+ +----+-----+ +-----+----+ | 189 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | | 190 | | | | | | | | / 191 +----------+ +-----+----+ +----------+ +----------+/ 193 Figure 1. 195 For DNS, the operational expectation is that the end-user would be 196 able to access home hosts from the home using DNS names instead of 197 more cumbersome IPv6 addresses. Note that this is distinct from the 198 requirement to access home hosts from outside the home. 200 End-users are expected to be able to receive multicast video in the 201 home without requiring the CE router to include the cost of 202 supporting full multicast routing protocols. 204 5. Advanced Features and Feature Requirements 206 The IPv6 CE router will need to support connectivity to one or more 207 access network architectures. This document describes an IPv6 CE 208 router that is not specific to any particular architecture or Service 209 Provider, and supports all commonly used architectures. 211 5.1. DNS 213 D-1: For local DNS queries for configuration, the CE Router may 214 include a DNS server to handle local queries. Non-local 215 queries can be forwarded unchanged to a DNS server specified in 216 the DNS server DHCPv6 option. The CE Router may also include 217 DNS64 functionality which is specified in 218 [I-D.bagnulo-behave-dns64]. 220 D-2: The local DNS server MAY also handle renumbering from the 221 Service Provider provided prefix for local names used 222 exclusively inside the home (the local AAAA and PTR records are 223 updated). This capability provides connectivity using local 224 DNS names in the home after a Service Provider renumbering. A 225 CE Router MAY add local DNS entries based on dynamic requests 226 from the LAN segment(s). The protocol to carry such requests 227 from hosts to the CE Router is yet to be described. 229 5.2. Multicast Behavior 231 This section is only applicable to a CE Router with at least one LAN 232 interface. A host in the home is expected to receive multicast 233 video. Note the CE Router resides at edge of the home and the 234 Service Provider, and the CE Router has at least one WAN connection 235 for multiple LAN connections. In such a multiple LAN to a WAN 236 toplogy at the CE Router edge, it is not necessary to run a multicast 237 routing protocol and thus MLD Proxy as specified in [RFC4605] can be 238 used. The CE Router discovers the hosts via a MLDv2 Router 239 implementation on a LAN interface. A WAN interface of the CE Router 240 interacts with the Service Provider router by sending MLD Reports and 241 replying to MLD queries for multicast Group memberships for hosts in 242 the home. 244 The CE router SHOULD implement MLD Proxy as specified in [RFC4605]. 245 For the routed topology shown in Figure 1, each router implements a 246 MLD Proxy. If the CE router implements MLD Proxy, the requirements 247 on the CE Router for MLD Proxy are listed below. 249 WAN requirements, MLD Proxy: 251 WMLD-1: Consistent with [RFC4605], the CE router MUST NOT implement 252 the router portion of MLDv2 for the WAN interface. 254 LAN requirements, MLD Proxy: 256 LMMLD-1: The CPE Router MUST follow the model described for MLD 257 Proxy in [RFC4605] to implement multicast. 259 LMMLD-2: Consistent with [RFC4605], the LAN interfaces on the CPE 260 router MUST NOT implement an MLDv2 Multicast Listener. 262 LAN requirements: 264 LM-1: If the CE Router has bridging configured between the LAN 265 interfaces, then the LAN interfaces MUST support snooping of 266 MLD [RFC3810] messages. 268 5.3. ND Proxy 270 LAN requirements: 272 LNDP-1: If the CE Router has only one /64 prefix to be used across 273 multiple LAN interfaces and the CE Router supports any two 274 LAN interfaces that cannot bridge data between them because 275 the two interfaces have disparate MAC layers, then the CE 276 Router MUST support Proxying Neighbor Advertisements as 277 specified in Section 7.2.8 of [RFC4861]. If any two LAN 278 interfaces support bridging between the interfaces, then 279 Proxying Neighbor Advertisements is not necessary between 280 the two interfaces. Legacy 3GPP networks have the following 281 requirements: 283 1. No DHCPv6 prefix is delegated to the CE Router. 285 2. Only one /64 is available on the WAN link. 287 3. The link types between the WAN interface and LAN 288 interface(s) are disparate and, therefore, can't be 289 bridged. 291 4. No NAT66 is to be used. 293 5. Each LAN interface needs global connectivity. 295 6. Uses SLAAC to configure LAN interface addresses. 297 For these legacy 3GPP networks, the CPE Router MUST support 298 ND Proxy between the WAN and LAN interface(s). If a CE 299 Router will never be deployed in an environment with these 300 characteristics, then ND Proxy is not necessary. 302 5.4. Prefix Delegation on LAN interface(s) (More details are TBD) 304 This section is only applicable to a CE Router with at least one LAN 305 interface. The LAN interface(s) are delegated prefixes subnetted 306 from the delegated prefix acquired by the WAN interface and the ULA 307 prefix. After the CE router has assigned prefixes for all of its 308 internally defined needs (its interfaces and any other purposes 309 defined in its internal logic), any leftover prefixes are available 310 for delegation. Any automated prefix delegation mechanism is TBD. 312 5.5. Routed network behavior(General Cases TBD) 314 CPE Router Behavior in a routed network: 316 R-1: One example of the CPE Router use in the home is shown below. 317 The home has a broadband modem combined with a CPE Router, all 318 in one device. The LAN interface of the device is connected to 319 another standalone CPE Router that supports a wireless access 320 point. To support such a network, this document recommends 321 using prefix delegation of the prefix obtained either via IA_PD 322 from WAN interface or a ULA from the LAN interface . The 323 network interface of the downstream router may obtain an IA_PD 324 via stateful DHCPv6. If the CPE router supports the routed 325 network through automatic prefix delegation, the CPE router 326 MUST support a DHCPv6 server or DHCPv6 relay agent. Further, 327 if an IA_PD is used, the Service Provider or user MUST allocate 328 an IA_PD or ULA prefix short enough to be delegated and 329 subsequently used for SLAAC. Therefore, a prefix length 330 shorter than /64 is needed. The CPE Router MAY support and IGP 331 in the home network. 333 /-------+------------\ /------------+-----\ 334 SP <--+ Modem | CPE Router +--+ CPE Router | WAP + --> PC 335 \-------+------------/ \------------+-----/ 337 WAP = Wireless Access Point 339 Figure 2. 341 5.6. Transition Technologies Support 343 5.6.1. Dual-Stack(DS)-Lite 345 Even as users migrate from IPv4 to IPv6 addressing, a significant 346 percentage of Internet resources and content will remain accessible 347 only through IPv4. Also, many end-user devices will only support 348 IPv4. As a consequence, Service Providers require mechanisms to 349 allow customers to continue to access content and resources using 350 IPv4 even after the last IPv4 allocations have been fully depleted. 351 One technology that can be used for IPv4 address extension is DS- 352 Lite. 354 DS-Lite enables a Service Provider to share IPv4 addresses among 355 multiple customers by combining two well-known technologies: IP in IP 356 (IPv4-in-IPv6) tunneling and Carrier Grade NAT. More specifically, 357 Dual-Stack-Lite encapsulates IPv4 traffic inside an IPv6 tunnel at 358 the IPv6 CE Router and sends it to a Service Provider Address Family 359 Translation Router (AFTR). Configuration of the IPv6 CE Router to 360 support IPv4 LAN traffic is outside the scope of this document. 362 The IPv6 CE Router SHOULD implement DS-Lite functionality as 363 specified in [I-D.ietf-softwire-dual-stack-lite]. 365 WAN requirements: 367 DLW-1: To facilitate IPv4 extension over an IPv6 network, if the CE 368 Router supports DS-Lite functionality, the CE Router WAN 369 interface MUST implement a B4 Interface as specified in 370 [I-D.ietf-softwire-dual-stack-lite]. 372 DLW-2: If the IPv6 CE Router implements DS-Lite functionality, the 373 CE Router MUST support using a DS-Lite DHCPv6 option 374 [I-D.ietf-softwire-ds-lite-tunnel-option] to configure the 375 DS-Lite tunnel. The IPv6 CE Router MAY use other mechanisms 376 to configure DS-Lite parameters. Such mechanisms are outside 377 the scope of this document. 379 DLW-3: IPv6 CE Router MUST NOT perform IPv4 Network Address 380 Translation (NAT) on IPv4 traffic encapsulated using DS-Lite. 382 DLW-4: If the IPv6 CE Router is configured with an non-RFC1918 IPv4 383 address on its WAN interface, the IPv6 CE Router MUST disable 384 the DS-Lite B4 element. 386 DLW-5: If DS-Lite is operational on the IPv6 CE Router, multicast 387 data MUST NOT be sent on any DS-Lite tunnel. 389 5.6.2. 6rd 391 The IPv6 CE Router can be used to offer IPv6 service to a LAN, even 392 when the WAN access network only supports IPv4. One technology that 393 supports IPv6 service over an IPv4 network is IPv6 Rapid Deployment 394 (6rd). 6rd encapsulates IPv6 traffic from the end user LAN inside 395 IPv4 at the IPv6 CE Router and sends it to a Service Provider Border 396 Relay (BR). The IPv6 CE Router calculates a 6rd delegated IPv6 397 prefix during 6rd configuration, and sub-delegates the 6rd delegated 398 prefix to devices in the LAN. 400 The IPv6 CE Router SHOULD implement 6rd functionality as specified in 401 [RFC5969]. 403 6rd requirements: 405 6RD-1: If the IPv6 CE Router implements 6rd functionality, the CE 406 Router WAN interface MUST support at least one 6rd Virtual 407 Interface and 6rd CE functionality as specified in [RFC5969]. 409 6RD-2: If the IPv6 CE Router implements 6rd CE functionality, it 410 MUST support using the 6rd DHCPv4 Option (212) for 6rd 411 configuration. The IPv6 CE Router MAY use other mechanisms 412 to configure 6rd parameters. Such mechanisms are outside the 413 scope of this document. 415 6RD-3: If 6rd is operational on the IPv6 CE Router, multicast data 416 MUST NOT be sent on any 6rd tunnel. 418 5.6.3. Transition Technologies Coexistence 420 Run the following four in parallel to provision CPE router 421 connectivity to the Service Provider: 423 1. Initiate IPv4 address acquisition. 425 2. Initiate IPv6 address acquisition as specified by 426 [I-D.ietf-v6ops-ipv6-cpe-router]. 428 3. If 6rd is provisioned, initiate 6rd. 430 4. If DS-Lite is provisioned, initiate DS-Lite. 432 The default route for IPv6 through the native physical interface 433 should have preference over the 6rd tunnel interface. The default 434 route for IPv4 through the native physical interface should have 435 preference over the DS-Lite tunnel interface. 437 5.7. Quality Of Service 439 Q-1: The CPE router MAY support differentiated services [RFC2474]. 441 5.8. Unicast Data Forwarding 443 The null route introduced by the WPD-6 requirement in 444 [I-D.ietf-v6ops-ipv6-cpe-router] has lower precedence than other 445 routes except for the default route. 447 5.9. ZeroConf 449 The CE Router MAY support manual configuration via the web using a 450 URL string like http://router.local as per multicast DNS (mDNS). 451 Zero-configuration is vendor-dependent. 453 6. Security Considerations 455 None. 457 7. Acknowledgements 459 Thanks to the following people (in alphabetical order) for their 460 guidance and feedback: 462 Mikael Abrahamsson, Merete Asak, Scott Beuker, Mohamed Boucadair, Rex 463 Bullinger, Brian Carpenter, Remi Denis-Courmont, Gert Doering, Alain 464 Durand, Katsunori Fukuoka, Tony Hain, Thomas Herbst, Kevin Johns, 465 Stephen Kramer, Victor Kuarsingh, Francois-Xavier Le Bail, David 466 Miles, Shin Miyakawa, Jean-Francois Mule, Michael Newbery, Carlos 467 Pignataro, John Pomeroy, Antonio Querubin, Teemu Savolainen, Matt 468 Schmitt, Hiroki Sato, Mark Townsley, Bernie Volz, James Woodyatt, Dan 469 Wing and Cor Zwart 471 This draft is based in part on CableLabs' eRouter specification. The 472 authors wish to acknowledge the additional contributors from the 473 eRouter team: 475 Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas, 476 Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego 477 Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur 478 Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan 479 Torbet and Greg White. 481 8. Contributors 483 The following people have participated as co-authors or provided 484 substantial contributions to this document: Ralph Droms, Kirk 485 Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, 486 Yiu Lee, John Jason Brzozowski and Heather Kirksey. 488 9. IANA Considerations 490 This memo includes no request to IANA. 492 10. References 494 10.1. Normative References 496 [I-D.bagnulo-behave-dns64] 497 Bagnulo, M., Sullivan, A., Matthews, P., Beijnum, I., and 498 M. Endo, "DNS64: DNS extensions for Network Address 499 Translation from IPv6 Clients to IPv4 Servers", 500 draft-bagnulo-behave-dns64-02 (work in progress), 501 March 2009. 503 [I-D.ietf-softwire-ds-lite-tunnel-option] 504 Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 505 Protocol for IPv6 (DHCPv6) Option for Dual- Stack Lite", 506 draft-ietf-softwire-ds-lite-tunnel-option-05 (work in 507 progress), September 2010. 509 [I-D.ietf-softwire-dual-stack-lite] 510 Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 511 Stack Lite Broadband Deployments Following IPv4 512 Exhaustion", draft-ietf-softwire-dual-stack-lite-06 (work 513 in progress), August 2010. 515 [I-D.ietf-v6ops-ipv6-cpe-router] 516 Singh, H., Beebee, W., Donley, C., Stark, B., and O. 517 Troan, "Basic Requirements for IPv6 Customer Edge 518 Routers", draft-ietf-v6ops-ipv6-cpe-router-07 (work in 519 progress), August 2010. 521 [I-D.vyncke-advanced-ipv6-security] 522 Vyncke, E. and M. Townsley, "Advanced Security for IPv6 523 CPE", draft-vyncke-advanced-ipv6-security-01 (work in 524 progress), March 2010. 526 [RFC1122] Braden, R., "Requirements for Internet Hosts - 527 Communication Layers", STD 3, RFC 1122, October 1989. 529 [RFC2080] Malkin, G. and R. Minnear, "RIPng for IPv6", RFC 2080, 530 January 1997. 532 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 533 Requirement Levels", BCP 14, RFC 2119, March 1997. 535 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 536 Networks", RFC 2464, December 1998. 538 [RFC2474] Nichols, K., Blake, S., Baker, F., and D. Black, 539 "Definition of the Differentiated Services Field (DS 540 Field) in the IPv4 and IPv6 Headers", RFC 2474, 541 December 1998. 543 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 544 Defeating Denial of Service Attacks which employ IP Source 545 Address Spoofing", BCP 38, RFC 2827, May 2000. 547 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 548 and M. Carney, "Dynamic Host Configuration Protocol for 549 IPv6 (DHCPv6)", RFC 3315, July 2003. 551 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 552 Host Configuration Protocol (DHCP) version 6", RFC 3633, 553 December 2003. 555 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 556 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 557 December 2003. 559 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 560 (DHCP) Service for IPv6", RFC 3736, April 2004. 562 [RFC3810] Vida, R. and L. Costa, "Multicast Listener Discovery 563 Version 2 (MLDv2) for IPv6", RFC 3810, June 2004. 565 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 566 Configuration Option for DHCPv6", RFC 4075, May 2005. 568 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 569 Addresses", RFC 4193, October 2005. 571 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 572 Time Option for Dynamic Host Configuration Protocol for 573 IPv6 (DHCPv6)", RFC 4242, November 2005. 575 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 576 April 2006. 578 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 579 Message Protocol (ICMPv6) for the Internet Protocol 580 Version 6 (IPv6) Specification", RFC 4443, March 2006. 582 [RFC4541] Christensen, M., Kimball, K., and F. Solensky, 583 "Considerations for Internet Group Management Protocol 584 (IGMP) and Multicast Listener Discovery (MLD) Snooping 585 Switches", RFC 4541, May 2006. 587 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 588 "Internet Group Management Protocol (IGMP) / Multicast 589 Listener Discovery (MLD)-Based Multicast Forwarding 590 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 592 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 593 (CIDR): The Internet Address Assignment and Aggregation 594 Plan", BCP 122, RFC 4632, August 2006. 596 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 597 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 598 Access Networks", RFC 4779, January 2007. 600 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 601 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 602 September 2007. 604 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 605 Address Autoconfiguration", RFC 4862, September 2007. 607 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 608 E. Klein, "Local Network Protection for IPv6", RFC 4864, 609 May 2007. 611 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 612 PPP", RFC 5072, September 2007. 614 [RFC5571] Storer, B., Pignataro, C., Dos Santos, M., Stevant, B., 615 Toutain, L., and J. Tremblay, "Softwire Hub and Spoke 616 Deployment Framework with Layer Two Tunneling Protocol 617 Version 2 (L2TPv2)", RFC 5571, June 2009. 619 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 620 Infrastructures (6rd) -- Protocol Specification", 621 RFC 5969, August 2010. 623 10.2. Informative References 625 [I-D.ietf-behave-v6v4-framework] 626 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 627 IPv4/IPv6 Translation", 628 draft-ietf-behave-v6v4-framework-10 (work in progress), 629 August 2010. 631 [UPnP-IGD] 632 UPnP Forum, "Universal Plug and Play (UPnP) Internet 633 Gateway Device (IGD)", November 2001, 634 . 636 Authors' Addresses 638 Hemant Singh 639 Cisco Systems, Inc. 640 1414 Massachusetts Ave. 641 Boxborough, MA 01719 642 USA 644 Phone: +1 978 936 1622 645 Email: shemant@cisco.com 646 URI: http://www.cisco.com/ 648 Wes Beebee 649 Cisco Systems, Inc. 650 1414 Massachusetts Ave. 651 Boxborough, MA 01719 652 USA 654 Phone: +1 978 936 2030 655 Email: wbeebee@cisco.com 656 URI: http://www.cisco.com/ 658 Chris Donley 659 CableLabs 660 858 Coal Creek Circle 661 Louisville, CO 80027 662 USA 664 Email: c.donley@cablelabs.com 665 Barbara Stark 666 AT&T 667 725 W Peachtree St 668 Atlanta, GA 30308 669 USA 671 Email: barbara.stark@att.com 673 Ole Troan (editor) 674 Cisco Systems, Inc. 675 Veversmauet 8 676 N-5017 BERGEN, 677 Norway 679 Email: ot@cisco.com