idnits 2.17.1 draft-donley-v6ops-ce-router-design-00.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 (March 29, 2012) is 4411 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-06) exists of draft-donley-nat444-impacts-03 == Outdated reference: A later version (-12) exists of draft-ietf-v6ops-6204bis-07 -- Obsolete informational reference (is this intentional?): RFC 3315 (Obsoleted by RFC 8415) Summary: 0 errors (**), 0 flaws (~~), 3 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group C. Donley 3 Internet-Draft CableLabs 4 Intended status: Informational J. Brzozowski 5 Expires: September 30, 2012 Comcast 6 H. Liu 7 D-Link 8 V. Kuarsingh 9 Rogers Communications 10 J. Weil 11 Time Warner Cable 12 March 29, 2012 14 Design Considerations for an IPv6 CE Router 15 draft-donley-v6ops-ce-router-design-00 17 Abstract 19 This document describes design considerations for IPv6 CE routers. 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six months 32 and may be updated, replaced, or obsoleted by other documents at any 33 time. It is inappropriate to use Internet-Drafts as reference 34 material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on September 30, 2012. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with respect 48 to this document. Code Components extracted from this document must 49 include Simplified BSD License text as described in Section 4.e of 50 the Trust Legal Provisions and are provided without warranty as 51 described in the Simplified BSD License. 53 Table of Contents 55 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 56 2. Design Considerations . . . . . . . . . . . . . . . . . . . . . 3 57 2.1. Address acquisition . . . . . . . . . . . . . . . . . . . . 3 58 2.2. Transition technologies . . . . . . . . . . . . . . . . . . 4 59 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 60 4. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 61 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 4 62 6. Informative References . . . . . . . . . . . . . . . . . . . . 5 63 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 65 1. Introduction 67 This document descrbes design considerations for IPv6 customer edge 68 (CE) routers designed for residential/small business use 69 [I-D.ietf-v6ops-6204bis]. These routers may also support IPv4 and 70 potentially one/more transition technologies. These design 71 considerations are crafted to ensure a safe and orderly transition to 72 IPv6 while maintaining a quality IP connection to the customer 73 premise. 75 2. Design Considerations 77 There are two overriding goals for CE routers: 79 o Offer customers the best possible quality of experience. 81 o Do not unnecessarily overwhelm ISP resources. 83 2.1. Address acquisition 85 The IPv6 CE router needs to support connectivity to one or more 86 access network architectures. There are generally three IPv6 address 87 acquisition mechanisms in widespread use today: 89 o stateful DHCPv6 [RFC3315] 91 o Stateless Address Autoconfiguraton (SLAAC)[RFC4862] 93 o unnumbered 95 Design considerations for address acquisition: 97 1. IPv6 CE routers should support one or more of the above address 98 acquisition mechanisms. 100 2. Only one address acquisition mechanism should be used for a given 101 protocol (e.g. native IPv4/IPv6) at a given time. 103 3. Not all access architectures support all address acquisition 104 mechanisms. When attached to access networks that do not support 105 certain address acquisition mechanisms, the CE router should not 106 attempt to use unsupported addressing mechanisms, if it is 107 possible to identify such a limitation. 109 4. The CE router should attempt address acquisition gracefully. It 110 should not overwhelm service provider provisioning servers. 112 5. If a Service Provider sends a hint to the CE router as to which 113 addressing mechanism to use, the CE router should honor the hint. 115 2.2. Transition technologies 117 CE routers should support technologies for providing ipv4 access over 118 IPv6 networks and IPv6 access over IPv4 networks. While the IETF has 119 defined a large number of such protocols, the CE router need not 120 implement all of them. In particular, it should implement those 121 technologies required by ISPs. At the time of this writing, such 122 technologies include: 124 o Native Dual-Stack 126 o IPv6 Rapid Deployment (6RD) [RFC5969] 128 o Dual-Stack Lite (DS-Lite)[RFC6333] 130 Design considerations for transition technologies: 132 1. Native IPv4/IPv6 service should be preferred over tunneled 133 service. 135 2. Avoid NAT, when possible. [I-D.donley-nat444-impacts] 137 3. While multihoming (supporting both native/tunneled service for a 138 given protocol) may be a valid approach, it need not be 139 supported. Singlehoming should also be considered a valid 140 approach. 142 3. IANA Considerations 144 This document makes no request of IANA. 146 Note to RFC Editor: this section may be removed on publication as an 147 RFC. 149 4. Security Considerations 151 TBD 153 5. Acknowledgements 154 6. Informative References 156 [I-D.donley-nat444-impacts] 157 Donley, C., Howard, L., Colorado, U., and V. Kuarsingh, 158 "Assessing the Impact of Carrier-Grade NAT on Network 159 Applications", draft-donley-nat444-impacts-03 (work in 160 progress), November 2011. 162 [I-D.ietf-v6ops-6204bis] 163 Singh, H., Beebee, W., Donley, C., Stark, B., and O. 164 Troan, "Basic Requirements for IPv6 Customer Edge 165 Routers", draft-ietf-v6ops-6204bis-07 (work in progress), 166 March 2012. 168 [RFC3315] Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C., 169 and M. Carney, "Dynamic Host Configuration Protocol for 170 IPv6 (DHCPv6)", RFC 3315, July 2003. 172 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 173 Address Autoconfiguration", RFC 4862, September 2007. 175 [RFC5969] Townsley, W. and O. Troan, "IPv6 Rapid Deployment on IPv4 176 Infrastructures (6rd) -- Protocol Specification", 177 RFC 5969, August 2010. 179 [RFC6333] Durand, A., Droms, R., Woodyatt, J., and Y. Lee, "Dual- 180 Stack Lite Broadband Deployments Following IPv4 181 Exhaustion", RFC 6333, August 2011. 183 Authors' Addresses 185 Chris Donley 186 CableLabs 188 Email: c.donley@cablelabs.com 190 John Brzozowski 191 Comcast 193 Hans Liu 194 D-Link 195 Victor Kuarsingh 196 Rogers Communications 198 Jason Weil 199 Time Warner Cable