idnits 2.17.1 draft-ietf-v6ops-ipv6-cpe-router-09.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 (December 20, 2010) is 4838 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** 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) ** Obsolete normative reference: RFC 6106 (Obsoleted by RFC 8106) Summary: 6 errors (**), 0 flaws (~~), 1 warning (==), 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 23, 2011 C. Donley 6 CableLabs 7 B. Stark 8 AT&T 9 O. Troan, Ed. 10 Cisco Systems, Inc. 11 December 20, 2010 13 Basic Requirements for IPv6 Customer Edge Routers 14 draft-ietf-v6ops-ipv6-cpe-router-09 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 June 23, 2011. 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 3.2.1. Local communication . . . . . . . . . . . . . . . . . 6 64 4. Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 7 65 4.1. General Requirements . . . . . . . . . . . . . . . . . . . 7 66 4.2. WAN Side Configuration . . . . . . . . . . . . . . . . . . 7 67 4.3. LAN Side Configuration . . . . . . . . . . . . . . . . . . 10 68 4.4. Security Considerations . . . . . . . . . . . . . . . . . 13 69 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 70 6. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 14 71 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 72 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 73 8.1. Normative References . . . . . . . . . . . . . . . . . . . 14 74 8.2. Informative References . . . . . . . . . . . . . . . . . . 16 75 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 77 1. Introduction 79 This document defines basic IPv6 features for a residential or small 80 office router referred to as an IPv6 CE router. Typically these 81 routers also support IPv4. 83 Mixed environments of dual-stack hosts and IPv6-only hosts (behind 84 the CE router) can be more complex if the IPv6-only devices are using 85 a translator to access IPv4 servers [I-D.ietf-behave-v6v4-framework]. 86 Support for such mixed environments is not in scope of this document. 88 This document specifies how an IPv6 CE router automatically 89 provisions its WAN interface, acquires address space for provisioning 90 of its LAN interfaces and fetches other configuration information 91 from the service provider network. Automatic provisioning of more 92 complex topology than a single router with multiple LAN interfaces is 93 out of scope for this document. 95 See [RFC4779] for a discussion of options available for deploying 96 IPv6 in Service Provider access networks. 98 1.1. Requirements Language 100 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 101 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 102 document are to be interpreted as described in RFC 2119 [RFC2119]. 104 2. Terminology 106 End-user Network one or more links attached to the IPv6 CE 107 router that connect IPv6 hosts. 109 IPv6 Customer Edge router a node intended for home or small office 110 use which forwards IPv6 packets not 111 explicitly addressed to itself. The IPv6 112 CE router connects the end-user network to 113 a service provider network. 115 IPv6 host any device implementing an IPv6 stack 116 receiving IPv6 connectivity through the 117 IPv6 CE router 119 LAN interface an IPv6 CE router's attachment to a link in 120 the end-user network. Examples are 121 Ethernets (simple or bridged), 802.11 122 wireless or other LAN technologies. An 123 IPv6 CE router may have one or more network 124 layer LAN Interfaces. 126 Service Provider an entity that provides access to the 127 Internet. In this document, a Service 128 Provider specifically offers Internet 129 access using IPv6, and may also offer IPv4 130 Internet access. The Service Provider can 131 provide such access over a variety of 132 different transport methods such as DSL, 133 cable, wireless, and others. 135 WAN interface an IPv6 CE router's attachment to a link 136 used to provide connectivity to the Service 137 Provider network; example link technologies 138 include Ethernets (simple or bridged), PPP 139 links, Frame Relay, or ATM networks as well 140 as Internet-layer (or higher-layer) 141 "tunnels", such as tunnels over IPv4 or 142 IPv6 itself. 144 3. Architecture 146 3.1. Current IPv4 End-user Network Architecture 148 An end-user network will likely support both IPv4 and IPv6. It is 149 not expected that an end-user will change their existing network 150 topology with the introduction of IPv6. There are some differences 151 in how IPv6 works and is provisioned which has implications for the 152 network architecture. A typical IPv4 end-user network consist of a 153 "plug and play" router with NAT functionality and a single link 154 behind it, connected to the Service Provider network. 156 A typical IPv4 NAT deployment by default blocks all incoming 157 connections. Opening of ports is typically allowed using UPnP IGD 158 [UPnP-IGD] or some other firewall control protocol. 160 Another consequence of using private address space in the end-user 161 network is that it provides stable addressing, i.e. it never changes 162 even when you change Service Providers, and the addresses are always 163 there even when the WAN interface is down or the customer edge router 164 has not yet been provisioned. 166 Rewriting addresses on the edge of the network also allows for some 167 rudimentary multi-homing; even though using NATs for multi-homing 168 does not preserve connections during a fail-over event [RFC4864]. 170 Many existing routers support dynamic routing, and advanced end users 171 can build arbitrary, complex networks using manual configuration of 172 address prefixes combined with a dynamic routing protocol. 174 3.2. IPv6 End-user Network Architecture 176 The end-user network architecture for IPv6 should provide equivalent 177 or better capabilities and functionality than the current IPv4 178 architecture. 180 The end-user network is a stub network. Figure 1 illustrates the 181 model topology for the end-user network. 183 An example of a typical end-user network. 185 +-------+-------+ \ 186 | Service | \ 187 | Provider | | Service 188 | Router | | Provider 189 +-------+-------+ | network 190 | / 191 | Customer / 192 | Internet connection / 193 | 194 +------+--------+ \ 195 | IPv6 | \ 196 | Customer Edge | \ 197 | Router | / 198 +---+-------+-+-+ / 199 Network A | | Network B | End-User 200 ---+-------------+----+- --+--+-------------+--- |network(s) 201 | | | | \ 202 +----+-----+ +-----+----+ +----+-----+ +-----+----+ \ 203 |IPv6 Host | |IPv6 Host | | IPv6 Host| |IPv6 Host | / 204 | | | | | | | | / 205 +----------+ +-----+----+ +----------+ +----------+/ 207 Figure 1 209 This architecture describes the: 211 o Basic capabilities of an IPv6 CE router 213 o Provisioning of the WAN interface connecting to the Service 214 Provider 216 o Provisioning of the LAN interfaces 218 For IPv6 multicast traffic the IPv6 CE router may act as an Multicast 219 Listener Discovery (MLD) proxy [RFC4605] and may support a dynamic 220 multicast routing protocol. 222 The IPv6 CE router may be manually configured in an arbitrary 223 topology with a dynamic routing protocol. Automatic provisioning and 224 configuration is described for a single IPv6 CE router only. 226 3.2.1. Local communication 228 Link-local IPv6 addresses are used by hosts communicating on a single 229 link. Unique Local IPv6 Unicast Addresses (ULA) [RFC4193] are used 230 by hosts communicating within the End-user Network across multiple 231 links, but without requiring the application to use a globally 232 routable address. The IPv6 CE router defaults to acting as the 233 demarcation point between two networks by providing a ULA boundary, a 234 multicast zone boundary and ingress and egress traffic filters. 236 A dual-stacked host is multi-homed to IPv4 and IPv6 networks. The 237 IPv4 and IPv6 topologies may not be congruent and different addresses 238 may have different reachability, e.g. ULA addresses. A host stack 239 has to be able to quickly failover and try a different source address 240 and destination address pair if communication fails as outlined in 241 [I-D.wing-v6ops-happy-eyeballs-ipv6]. 243 At the time of writing, several hosts implementations do not handle 244 the case where they have an IPv6 address configured and no IPv6 245 connectivity. Either because the address itself has a limited 246 topological reachability (e.g. ULA) or because the IPv6 CE router is 247 not connected to the IPv6 network on its WAN interface. To support 248 host implementations that do not handle multi-homing in a multi- 249 prefix environment [I-D.ietf-v6ops-multihoming-without-nat66], the 250 IPv6 CE router should, as detailed in the below requirements, not 251 advertise itself as a default router on the LAN interface(s) when it 252 does not have IPv6 connectivity on the WAN interface or when it is 253 not provisioned with IPv6 addresses. For local IPv6 communication 254 the mechanisms specified in [RFC4191] are used. 256 ULA addressing is useful where the IPv6 CE router has multiple LAN 257 interfaces with hosts that need to communicate with each other. If 258 the IPv6 CE router has only a single LAN interface (IPv6 link) then 259 link-local addressing can be used instead. 261 In the event more than one IPv6 CE router is present on the LAN, then 262 coexistence with IPv4 requires all of them to conform to these 263 recommendations, especially requirements ULA-5 and L-4. 265 4. Requirements 267 4.1. General Requirements 269 The IPv6 CE router is responsible for implementing IPv6 routing; that 270 is, the IPv6 CE router must look up the IPv6 Destination address in 271 its routing table to decide to which interface it should send the 272 packet. 274 In this role, the IPv6 CE router is responsible for ensuring that 275 traffic using its ULA addressing does not go out the WAN interface, 276 and does not originate from the WAN interface. 278 G-1: An IPv6 CE router is an IPv6 node according to the IPv6 Node 279 Requirements [RFC4294] specification. 281 G-2: The IPv6 CE router MUST implement ICMP according to [RFC4443]. 282 In particular point to point links MUST be handled as described 283 in section 3.1 of [RFC4443]. 285 G-3: The IPv6 CE router MUST NOT forward any IPv6 traffic between 286 its LAN Interface(s) and its WAN Interface until the router has 287 successfully completed the IPv6 address acquisition process. 289 G-4: By default an IPv6 CE router that has no default router(s) on 290 its WAN interface MUST NOT advertise itself as an IPv6 default 291 router on its LAN interfaces. That is, the "Router Lifetime" 292 field is set to zero in all Router Advertisement messages it 293 originates [RFC4861]. 295 G-5: By default if the IPv6 CE router is an advertising router and 296 loses its IPv6 default router(s) on the WAN interface, it MUST 297 explicitly invalidate itself as an IPv6 default router on each 298 of its advertising interfaces by immediately transmitting one 299 or more Router Advertisement messages with the "Router 300 Lifetime" field set to zero [RFC4861]. 302 4.2. WAN Side Configuration 304 The IPv6 CE router will need to support connectivity to one or more 305 access network architectures. This document describes an IPv6 CE 306 router that is not specific to any particular architecture or Service 307 Provider, and supports all commonly used architectures. 309 IPv6 Neighbor Discovery and DHCPv6 protocols operate over any type of 310 IPv6 supported link-layer and there is no need for a link-layer 311 specific configuration protocol for IPv6 network layer configuration 312 options as in e.g. PPP IPCP for IPv4. This section makes the 313 assumption that the same mechanism will work for any link-layer, be 314 it Ethernet, DOCSIS, PPP or others. 316 WAN side requirements: 318 W-1: When the router is attached to the WAN interface link it MUST 319 act as an IPv6 host for the purposes of stateless or stateful 320 interface address assignment ([RFC4862] / [RFC3315]). 322 W-2: The IPv6 CE router MUST generate a link-local address and 323 finish Duplicate Address Detection according to [RFC4862] prior 324 to sending any Router Solicitations on the interface. The 325 source address used in the subsequent Router Solicitation MUST 326 be the link-local address on the WAN interface. 328 W-3: Absent of other routing information the IPv6 CE router MUST use 329 Router Discovery as specified in [RFC4861] to discover a 330 default router(s) and install default route(s) in its routing 331 table with the discovered router's address as the next-hop. 333 W-4: The router MUST act as a requesting router for the purposes of 334 DHCPv6 prefix delegation ([RFC3633]). 336 W-5: DHCPv6 address assignment (IA_NA) and DHCPv6 prefix delegation 337 (IA_PD) SHOULD be done as a single DHCPv6 session. 339 W-6: The IPv6 CE router MUST use a persistent DUID for DHCPv6 340 messages. The DUID MUST NOT change between network interface 341 resets or IPv6 CE router reboot. 343 Link-layer requirements: 345 WLL-1: If the WAN interface supports Ethernet encapsulation, then 346 the IPv6 CE router MUST support IPv6 over Ethernet [RFC2464]. 348 WLL-2: If the WAN interface supports PPP encapsulation the IPv6 CE 349 router MUST support IPv6 over PPP [RFC5072]. 351 WLL-3: If the WAN interface supports PPP encapsulation, in a dual- 352 stack environment with IPCP and IPV6CP running over one PPP 353 logical channel, the NCPs MUST be treated as independent of 354 each other and start and terminate independently. 356 Address assignment requirements: 358 WAA-1: The IPv6 CE router MUST support SLAAC [RFC4862]. 360 WAA-2: The IPv6 CE router MUST follow the recommendation in 361 [RFC5942]. and in particular the handling of the L-flag in 362 the Router Advertisement Prefix Information Option. 364 WAA-3: The IPv6 CE router MUST support DHCPv6 [RFC3315] client 365 behavior. 367 WAA-4: The IPv6 CE router MUST be able to support the following 368 DHCPv6 options: IA_NA, Reconfigure Accept [RFC3315], 369 DNS_SERVERS [RFC3646]. 371 WAA-5: The IPv6 CE router SHOULD support the DHCPv6 SNTP option 372 [RFC4075] and the Information Refresh Time Option [RFC4242]. 374 WAA-6: If the IPv6 CE router receives an RA message (described in 375 [RFC4861]) with the M-flag set to 1, the IPv6 CE router MUST 376 do DHCPv6 address assignment (request an IA_NA option). 378 WAA-7: If the IPv6 CE router is unable to assign address(es) through 379 SLAAC it MAY do DHCPv6 address assignment (request an IA_NA) 380 even if the M-flag is set to 0. 382 WAA-8: If the IPv6 CE router does not acquire global IPv6 383 address(es) from either SLAAC or DHCPv6, then it MUST create 384 global IPv6 address(es) from its delegated prefix(es) and 385 configure those on one of its internal virtual network 386 interfaces. 388 WAA-9: As a router the IPv6 CE router MUST follow the weak host 389 model [RFC1122]. When originating packets out an interface 390 it will use a source address from another of its interfaces 391 if the outgoing interface does not have an address of 392 suitable scope. 394 Prefix Delegation requirements: 396 WPD-1: The IPv6 CE router MUST support DHCPv6 prefix delegation 397 requesting router behavior as specified in [RFC3633] (IA_PD 398 option). 400 WPD-2: The IPv6 CE router MAY indicate as a hint to the delegating 401 router the size of the prefix it requires. If so, it MUST 402 ask for a prefix large enough to assign one /64 for each of 403 its interfaces rounded up to the nearest nibble and MUST be 404 configurable to ask for more. 406 WPD-3: The IPv6 CE router MUST be prepared to accept a delegated 407 prefix size different from what is given in the hint. If the 408 delegated prefix is too small to address all of its 409 interfaces, the IPv6 CE router SHOULD log a system management 410 error. 412 WPD-4: The IPv6 CE router MUST always initiate DHCPv6 prefix 413 delegation, regardless of the M and O-flags in a received 414 Router Advertisement message. 416 WPD-5: If the IPv6 CE Router initiates DHCPv6 before receiving a 417 Router Advertisement it MUST also request an IA_NA option in 418 DHCPv6. 420 WPD-6: If the delegated prefix(es) are aggregate route(s) of 421 multiple, more-specific routes, the IPv6 CE router MUST 422 discard packets that match the aggregate route(s), but not 423 any of the more-specific routes. In other words, the next- 424 hop for the aggregate route(s) should be the null 425 destination. This is necessary to prevent forwarding loops 426 when some addresses covered by the aggregate are not 427 reachable [RFC4632]. 429 (a) The IPv6 CE router SHOULD send an ICMPv6 Destination 430 Unreachable according to section 3.1 [RFC4443] back to 431 the source of the packet, if the packet is to be dropped 432 due to this rule. 434 WPD-7: If the IPv6 CE router requests both an IA_NA and an IA_PD in 435 DHCPv6, it MUST accept an IA_PD in DHCPv6 Advertise/Reply 436 messages, even if the message does not contain any addresses. 438 WPD-8: By default an IPv6 CE router MUST NOT initiate any dynamic 439 routing protocol on its WAN interface. 441 4.3. LAN Side Configuration 443 The IPv6 CE router distributes configuration information obtained 444 during WAN interface provisioning to IPv6 hosts and assists IPv6 445 hosts in obtaining IPv6 addresses. It also supports connectivity of 446 these devices in the absence of any working WAN interface. 448 An IPv6 CE router is expected to support an IPv6 end-user network and 449 IPv6 hosts that exhibit the following characteristics: 451 1. Link-local addresses may be insufficient for allowing IPv6 452 applications to communicate with each other in the end-user 453 network. The IPv6 CE router will need to enable this 454 communication by providing globally-scoped unicast addresses or 455 ULAs [RFC4193] whether or not WAN connectivity exists. 457 2. IPv6 hosts should be capable of using SLAAC and may be capable of 458 using DHCPv6 for acquiring their addresses. 460 3. IPv6 hosts may use DHCPv6 for other configuration information, 461 such as the DNS_SERVERS option for acquiring DNS information. 463 Unless otherwise specified, the following requirements apply to the 464 IPv6 CE router's LAN interfaces only. 466 ULA requirements: 468 ULA-1: The IPv6 CE router SHOULD be capable of generating a ULA 469 prefix [RFC4193]. 471 ULA-2: A IPv6 CE router with a ULA prefix, MUST maintain this 472 consistently across reboots. 474 ULA-3: The value of the ULA prefix SHOULD be user configurable. 476 ULA-4: By default the IPv6 CE router MUST act as a site border 477 router according to section 4.3 of [RFC4193] and filter 478 packets with Local IPv6 source or destination addresses 479 accordingly. 481 ULA-5: An IPv6 CE router MUST NOT advertise itself as a default 482 router with Router Lifetime greater than zero whenever all of 483 its configured and delegated prefixes are ULA prefixes. 485 LAN requirements: 487 L-1: The IPv6 CE router MUST support router behavior according to 488 Neighbor Discovery for IPv6 [RFC4861]. 490 L-2: The IPv6 CE router MUST assign a separate /64 from its 491 delegated prefix(es) (and ULA prefix if configured to provide 492 ULA addressing) for each of its LAN interfaces. 494 L-3: An IPv6 CE router MUST advertise itself as a router for the 495 delegated prefix(es) (and ULA prefix if configured to provide 496 ULA addressing) using the "Route Information Option" specified 497 in section 2.3 of [RFC4191]. This advertisement is 498 independent of having IPv6 connectivity on the WAN interface 499 or not. 501 L-4: An IPv6 CE router MUST NOT advertise itself as a default 502 router with a Router Lifetime [RFC4861] greater than zero if 503 it has no prefixes configured or delegated to it. 505 L-5: The IPv6 CE router MUST make each LAN interface an advertising 506 interface according to [RFC4861]. 508 L-6: In Router Advertisements messages, the Prefix Information 509 Option's A and L-flags MUST be set to 1 by default. 511 L-7: The A and L-flags setting SHOULD be user configurable. 513 L-8: The IPv6 CE router MUST support a DHCPv6 server capable of 514 IPv6 address assignment according to [RFC3315] OR a stateless 515 DHCPv6 server according to [RFC3736] on its LAN interfaces. 517 L-9: Unless the IPv6 CE router is configured to support the DHCPv6 518 IA_NA option, it SHOULD set M=0 and O=1 in its Router 519 Advertisement messages [RFC4861]. 521 L-10: The IPv6 CE router MUST support providing DNS information in 522 the DHCPv6 DNS_SERVERS and DOMAIN_LIST options [RFC3646]. 524 L-11: The IPv6 CE router SHOULD support providing DNS information in 525 Router Advertisement RDNSS and DNSSL options as specified in 526 [RFC6106]. 528 L-12: The IPv6 CE router SHOULD make available a subset of DHCPv6 529 options (as listed in section 5.3 of [RFC3736]) received from 530 the DHCPv6 client on its WAN interface to its LAN side DHCPv6 531 server. 533 L-13: If the delegated prefix changes, i.e. the current prefix is 534 replaced with a new prefix without any overlapping time 535 period, then the IPv6 CE router MUST immediately advertise the 536 old prefix with a preferred lifetime of 0 and a valid lifetime 537 of 2 hours (which must be decremented in real time) in a 538 Router Advertisement message. 540 L-14: The IPv6 CE router MUST send an ICMP Destination Unreachable 541 Message, code 5 (Source address failed ingress/egress policy) 542 for packets forwarded to it using an address from a prefix 543 which has been deprecated. 545 4.4. Security Considerations 547 It is considered a best practice to filter obviously malicious 548 traffic (e.g. spoofed packets, "martian" addresses, etc.). Thus, the 549 IPv6 CE router ought to support basic stateless egress and ingress 550 filters. The CE router is also expected to offer mechanisms to 551 filter traffic entering the customer network; however, the method by 552 which vendors implement configurable packet filtering is beyond the 553 scope of this document. 555 Security requirements: 557 S-1: The IPv6 CE router SHOULD support 558 [I-D.ietf-v6ops-cpe-simple-security]. In particular, the IPv6 559 CE router SHOULD support functionality sufficient for 560 implementing the set of recommendations in 561 [I-D.ietf-v6ops-cpe-simple-security] section 4. This document 562 takes no position on whether such functionality is enabled by 563 default or mechanisms by which users would configure it. 565 S-2: The IPv6 CE router MUST support ingress filtering in accordance 566 with [RFC2827] (BCP 38) 568 5. Acknowledgements 570 Thanks to the following people (in alphabetical order) for their 571 guidance and feedback: 573 Mikael Abrahamsson, Tore Anderson, Merete Asak, Scott Beuker, Mohamed 574 Boucadair, Rex Bullinger, Brian Carpenter, Lorenzo Colitti, Remi 575 Denis-Courmont, Gert Doering, Alain Durand, Katsunori Fukuoka, Tony 576 Hain, Thomas Herbst, Kevin Johns, Erik Kline, Stephen Kramer, Victor 577 Kuarsingh, Francois-Xavier Le Bail, David Miles, Arifumi Matsumoto, 578 Shin Miyakawa, Jean-Francois Mule, Michael Newbery, Carlos Pignataro, 579 John Pomeroy, Antonio Querubin, Teemu Savolainen, Matt Schmitt, 580 Hiroki Sato, David Thaler, Mark Townsley, Bernie Volz, James 581 Woodyatt, Dan Wing and Cor Zwart 583 This draft is based in part on CableLabs' eRouter specification. The 584 authors wish to acknowledge the additional contributors from the 585 eRouter team: 587 Ben Bekele, Amol Bhagwat, Ralph Brown, Eduardo Cardona, Margo Dolas, 588 Toerless Eckert, Doc Evans, Roger Fish, Michelle Kuska, Diego 589 Mazzola, John McQueen, Harsh Parandekar, Michael Patrick, Saifur 590 Rahman, Lakshmi Raman, Ryan Ross, Ron da Silva, Madhu Sudan, Dan 591 Torbet and Greg White 593 6. Contributors 595 The following people have participated as co-authors or provided 596 substantial contributions to this document: Ralph Droms, Kirk 597 Erichsen, Fred Baker, Jason Weil, Lee Howard, Jean-Francois Tremblay, 598 Yiu Lee, John Jason Brzozowski and Heather Kirksey. 600 7. IANA Considerations 602 This memo includes no request to IANA. 604 8. References 606 8.1. Normative References 608 [I-D.ietf-v6ops-cpe-simple-security] 609 Woodyatt, J., "Recommended Simple Security Capabilities in 610 Customer Premises Equipment for Providing Residential IPv6 611 Internet Service", draft-ietf-v6ops-cpe-simple-security-16 612 (work in progress), October 2010. 614 [RFC1122] Braden, R., "Requirements for Internet Hosts - 615 Communication Layers", STD 3, RFC 1122, October 1989. 617 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 618 Requirement Levels", BCP 14, RFC 2119, March 1997. 620 [RFC2464] Crawford, M., "Transmission of IPv6 Packets over Ethernet 621 Networks", RFC 2464, December 1998. 623 [RFC2827] Ferguson, P. and D. Senie, "Network Ingress Filtering: 624 Defeating Denial of Service Attacks which employ IP Source 625 Address Spoofing", BCP 38, RFC 2827, May 2000. 627 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 628 and M. Carney, "Dynamic Host Configuration Protocol for 629 IPv6 (DHCPv6)", RFC 3315, July 2003. 631 [RFC3633] Troan, O. and R. Droms, "IPv6 Prefix Options for Dynamic 632 Host Configuration Protocol (DHCP) version 6", RFC 3633, 633 December 2003. 635 [RFC3646] Droms, R., "DNS Configuration options for Dynamic Host 636 Configuration Protocol for IPv6 (DHCPv6)", RFC 3646, 637 December 2003. 639 [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol 640 (DHCP) Service for IPv6", RFC 3736, April 2004. 642 [RFC4075] Kalusivalingam, V., "Simple Network Time Protocol (SNTP) 643 Configuration Option for DHCPv6", RFC 4075, May 2005. 645 [RFC4191] Draves, R. and D. Thaler, "Default Router Preferences and 646 More-Specific Routes", RFC 4191, November 2005. 648 [RFC4193] Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast 649 Addresses", RFC 4193, October 2005. 651 [RFC4242] Venaas, S., Chown, T., and B. Volz, "Information Refresh 652 Time Option for Dynamic Host Configuration Protocol for 653 IPv6 (DHCPv6)", RFC 4242, November 2005. 655 [RFC4294] Loughney, J., "IPv6 Node Requirements", RFC 4294, 656 April 2006. 658 [RFC4443] Conta, A., Deering, S., and M. Gupta, "Internet Control 659 Message Protocol (ICMPv6) for the Internet Protocol 660 Version 6 (IPv6) Specification", RFC 4443, March 2006. 662 [RFC4605] Fenner, B., He, H., Haberman, B., and H. Sandick, 663 "Internet Group Management Protocol (IGMP) / Multicast 664 Listener Discovery (MLD)-Based Multicast Forwarding 665 ("IGMP/MLD Proxying")", RFC 4605, August 2006. 667 [RFC4632] Fuller, V. and T. Li, "Classless Inter-domain Routing 668 (CIDR): The Internet Address Assignment and Aggregation 669 Plan", BCP 122, RFC 4632, August 2006. 671 [RFC4779] Asadullah, S., Ahmed, A., Popoviciu, C., Savola, P., and 672 J. Palet, "ISP IPv6 Deployment Scenarios in Broadband 673 Access Networks", RFC 4779, January 2007. 675 [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, 676 "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, 677 September 2007. 679 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 680 Address Autoconfiguration", RFC 4862, September 2007. 682 [RFC4864] Van de Velde, G., Hain, T., Droms, R., Carpenter, B., and 683 E. Klein, "Local Network Protection for IPv6", RFC 4864, 684 May 2007. 686 [RFC5072] S.Varada, Haskins, D., and E. Allen, "IP Version 6 over 687 PPP", RFC 5072, September 2007. 689 [RFC5942] Singh, H., Beebee, W., and E. Nordmark, "IPv6 Subnet 690 Model: The Relationship between Links and Subnet 691 Prefixes", RFC 5942, July 2010. 693 [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, 694 "IPv6 Router Advertisement Options for DNS Configuration", 695 RFC 6106, November 2010. 697 8.2. Informative References 699 [I-D.ietf-behave-v6v4-framework] 700 Baker, F., Li, X., Bao, C., and K. Yin, "Framework for 701 IPv4/IPv6 Translation", 702 draft-ietf-behave-v6v4-framework-10 (work in progress), 703 August 2010. 705 [I-D.ietf-v6ops-multihoming-without-nat66] 706 Troan, O., Miles, D., Matsushima, S., Okimoto, T., and D. 707 Wing, "IPv6 Multihoming without Network Address 708 Translation", 709 draft-ietf-v6ops-multihoming-without-nat66-00 (work in 710 progress), December 2010. 712 [I-D.wing-v6ops-happy-eyeballs-ipv6] 713 Wing, D. and A. Yourtchenko, "Happy Eyeballs: Trending 714 Towards Success with Dual-Stack Hosts", 715 draft-wing-v6ops-happy-eyeballs-ipv6-01 (work in 716 progress), October 2010. 718 [UPnP-IGD] 719 UPnP Forum, "Universal Plug and Play (UPnP) Internet 720 Gateway Device (IGD)", November 2001, 721 . 723 Authors' Addresses 725 Hemant Singh 726 Cisco Systems, Inc. 727 1414 Massachusetts Ave. 728 Boxborough, MA 01719 729 USA 731 Phone: +1 978 936 1622 732 Email: shemant@cisco.com 733 URI: http://www.cisco.com/ 735 Wes Beebee 736 Cisco Systems, Inc. 737 1414 Massachusetts Ave. 738 Boxborough, MA 01719 739 USA 741 Phone: +1 978 936 2030 742 Email: wbeebee@cisco.com 743 URI: http://www.cisco.com/ 745 Chris Donley 746 CableLabs 747 858 Coal Creek Circle 748 Louisville, CO 80027 749 USA 751 Email: c.donley@cablelabs.com 753 Barbara Stark 754 AT&T 755 725 W Peachtree St 756 Atlanta, GA 30308 757 USA 759 Email: barbara.stark@att.com 760 Ole Troan (editor) 761 Cisco Systems, Inc. 762 Veversmauet 8 763 N-5017 BERGEN, 764 Norway 766 Email: ot@cisco.com