idnits 2.17.1 draft-wu-softwire-public4over6-deployment-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 : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet seems to have RFC 2119 boilerplate text. -- The document date (July 9, 2012) is 4308 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-08) exists of draft-ietf-softwire-dslite-deployment-03 == Outdated reference: A later version (-10) exists of draft-ietf-softwire-public-4over6-01 Summary: 1 error (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group P. Wu 3 Internet-Draft Q. Sun 4 Intended status: Informational Tsinghua University 5 Expires: January 10, 2013 July 9, 2012 7 Deployment Considerations for Public 4over6 8 draft-wu-softwire-public4over6-deployment-00 10 Abstract 12 Public 4over6 is a stateful transition mechanism which assigns public 13 IPv4 address to CPE/host and uses IPv4-in-IPv6 tunnel. It doesn't 14 involve CGN as in DS-lite and reduces the mapping scale on the 15 Concentrator to per-subscriber level. This document describers 16 deployment models for Public 4over6, and the deployment 17 considerations of the Public 4over6 architecture. 19 Status of This Memo 21 This Internet-Draft is submitted in full conformance with the 22 provisions of BCP 78 and BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF). Note that other groups may also distribute 26 working documents as Internet-Drafts. The list of current Internet- 27 Drafts is at http://datatracker.ietf.org/drafts/current/. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 This Internet-Draft will expire on January 10, 2013. 36 Copyright Notice 38 Copyright (c) 2012 IETF Trust and the persons identified as the 39 document authors. All rights reserved. 41 This document is subject to BCP 78 and the IETF Trust's Legal 42 Provisions Relating to IETF Documents 43 (http://trustee.ietf.org/license-info) in effect on the date of 44 publication of this document. Please review these documents 45 carefully, as they describe your rights and restrictions with respect 46 to this document. Code Components extracted from this document must 47 include Simplified BSD License text as described in Section 4.e of 48 the Trust Legal Provisions and are provided without warranty as 49 described in the Simplified BSD License. 51 Table of Contents 53 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 54 2. Requirements Language . . . . . . . . . . . . . . . . . . . . . 3 55 3. Concentrator Deployment Considerations . . . . . . . . . . . . 3 56 3.1. Interface Consideration . . . . . . . . . . . . . . . . . . 3 57 3.2. MTU Consideration . . . . . . . . . . . . . . . . . . . . . 3 58 3.3. Fragmentation . . . . . . . . . . . . . . . . . . . . . . . 3 59 3.4. Logging at Concentrator . . . . . . . . . . . . . . . . . . 3 60 3.5. Reliability Considerations of Concentrator . . . . . . . . 4 61 3.6. Placement of Concentrator . . . . . . . . . . . . . . . . . 4 62 3.7. Considerations for Geographically Aware Services . . . . . 4 63 4. Initiator Deployment Considerations . . . . . . . . . . . . . . 4 64 4.1. Concentrator Discovery Considerations . . . . . . . . . . . 4 65 4.2. DNS Deployment Considerations . . . . . . . . . . . . . . . 4 66 4.3. Optional NAT44 Functionality on Initiator . . . . . . . . . 5 67 5. Deployment Experience . . . . . . . . . . . . . . . . . . . . . 5 68 6. IDC Transition Usage . . . . . . . . . . . . . . . . . . . . . 5 69 7. Security Consideration . . . . . . . . . . . . . . . . . . . . 5 70 8. Acknowledgement . . . . . . . . . . . . . . . . . . . . . . . . 5 71 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 9.1. Normative References . . . . . . . . . . . . . . . . . . . 5 73 9.2. Informative References . . . . . . . . . . . . . . . . . . 6 75 1. Introduction 77 Public 4over6 [I-D.ietf-softwire-public-4over6] is a transition 78 mechanism that enables operators to assign public IPv4 addresses to 79 end users over IPv6. Public 4over6 uses IPv4-in-IPv6 softwire to 80 provide IPv4 connectivity between users in IPv6 access networks and 81 IPv4 Internet.This document discuss various Public 4over6 deployment 82 considerations for operators. 84 Terminology of this document follows the definitions and 85 abbreviations of [I-D.ietf-softwire-public-4over6] . 87 2. Requirements Language 89 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 90 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 91 document are to be interpreted as described in [RFC2119]. 93 3. Concentrator Deployment Considerations 95 Public 4over6 and DS-Lite [RFC6333] shares some deployment 96 considerations, while Concentrator and Initiator of Public 4over6 97 play a similar role to AFTR and B4 of DS-Lite. 99 3.1. Interface Consideration 101 Tunnel Concentrator is deployed at the IPv4-IPv6 network border where 102 the tunnel interface is IPv6 and the external interface is IPv4. It 103 shares the same deployment considerations with 104 [I-D.ietf-softwire-dslite-deployment]. 106 3.2. MTU Consideration 108 Same with [I-D.ietf-softwire-dslite-deployment]. 110 3.3. Fragmentation 112 Same with [I-D.ietf-softwire-dslite-deployment]. 114 3.4. Logging at Concentrator 116 Timestamped logging is essential for back tracking specific users 117 when a problem is identified with one of the assigned public IPv4 118 address. Operators only log one entry per subscriber. The log 119 should include the subscriber's IPv6 address and the public IPv4 120 address. 122 3.5. Reliability Considerations of Concentrator 123 For redundancy, the backup Concentrator should apply either of the 124 following types. One is that a dedicated DHCP server synchronizes 125 mapping entries with all Concentrators considering that the DHCP 126 server is responsible for IPv4 address allocation. Each Concentrator 127 maintain per-subscriber mapping table accordingly. Once the working 128 Concentrator is down, subscribers will switch to the backup 129 Concentrator using technologies like anycast etc. 131 The other method is that Initiators PING the Concentrator 132 periodically to check the status of the Concentrator. If the PING 133 test fails for a specific number of times, Initiators should release 134 the current public IPv4 address and require for another public IPv4 135 address from the backup Concentrator. 137 3.6. Placement of Concentrator 139 Concentrator maintains a per-subscriber mapping table, smaller than 140 the per-session binding table on DS-Lite AFTR. As a result, 141 Concentrator can be deployed closer to core of the network to cover a 142 larger region. And the amount of subscribers and the capability of 143 devices should be taken into account. 145 3.7. Considerations for Geographically Aware Services 147 Even though Public 4over6 supports the assignment of public IPv4 148 address, identification by IP address is no easier than that in DS- 149 Lite. Thus applications that assume such geographic information may 150 not work as intended. In Public 4over6, each address represents a 151 single machine, a single household, or a single small office, but 152 it's hard to identify geographic information over IPv6 access 153 networks. The considerations are similar to section 2.11 of 154 [I-D.ietf-softwire-dslite-deployment] 156 4. Initiator Deployment Considerations 158 4.1. Concentrator Discovery Considerations 160 A public 4over6 Initiator must discover the Concentrator's IPv6 161 address before starting IPv4 connections. The IPv6 address can be 162 learned through out-of-band mechanism, manual configuration or DHCPv6 163 option. If an operator uses DHCPv6 for provision the Initiator, 164 DHCPv6 option defined in [RFC6334] must be implemented in the 165 Initiator. 167 4.2. DNS Deployment Considerations 169 The Initiator can implement a proxy resolver that will proxy DNS 170 query from IPv4 transport to the DNS server in the IPv6 network. 172 Alternatively, the Initiator can tunnel IPv4 DNS query to an external 173 DNS server over IPv6 network. 175 4.3. Optional NAT44 Functionality on Initiator 177 The Initiator can be a host or a CPE device. If it's a host, the 178 host can get Public IPv4 address and does not need NAT44 function. 179 If it's a CPE, NAT44 function must be enabled for local private IPv4 180 Network. 182 5. Deployment Experience 184 Tsinghua University has deployed a Tunnel Concentrator in CERNET lab. 185 The DHCP server collocates on the same device with Tunnel 186 Concentrator. Public4over6 client software has also been released, 187 with Win7 version and Linux version. The system has provided IPv4 188 service over IPv6 access networks of universities from China. 190 The IPv4-over-IPv6 services Public 4over6 provided is transparent to 191 the upper layer applications. Even though in IPv6 networks, users 192 can also get access to IPv4 websites with no difference to native 193 IPv4. Because of assignment of public IPv4 address to Initiators, 194 users can experience P2P services. Public 4over6 is able to provide 195 qualified IPv4 services with no side impact on native IPv6. 197 6. IDC Transition Usage 199 IDC is responsible for steady service for users. And as a server, a 200 public IPv4 address does good to guarantee the IDC's QoS. Public 201 4over6 is able to provide service for IDC locating in an IPv6-only 202 network. As an Initiator, an IDC will get a public IPv4 address and 203 achieve "dual-stack" environment, which is essential for better 204 service. 206 7. Security Consideration 208 This specification raises no new security issues. 209 [I-D.ietf-softwire-public-4over6] discusses public 4over6 related 210 security issues. 212 8. Acknowledgement 214 TBD 216 9. References 218 9.1. Normative References 220 [RFC2119] Bradner, S., "Key words for 221 use in RFCs to Indicate 222 Requirement Levels", BCP 14, 223 RFC 2119, March 1997. 225 [RFC6333] Durand, A., Droms, R., 226 Woodyatt, J., and Y. Lee, 227 "Dual-Stack Lite Broadband 228 Deployments Following IPv4 229 Exhaustion", RFC 6333, 230 August 2011. 232 [RFC6334] Hankins, D. and T. Mrugalski, 233 "Dynamic Host Configuration 234 Protocol for IPv6 (DHCPv6) 235 Option for Dual-Stack Lite", 236 RFC 6334, August 2011. 238 9.2. Informative References 240 [I-D.ietf-softwire-dslite-deployment] Lee, Y., Maglione, R., 241 Williams, C., Jacquenet, C., 242 and M. Boucadair, "Deployment 243 Considerations for Dual-Stack 244 Lite", draft-ietf-softwire- 245 dslite-deployment-03 (work in 246 progress), March 2012. 248 [I-D.ietf-softwire-public-4over6] Cui, Y., Wu, J., Wu, P., Metz, 249 C., Vautrin, O., and Y. Lee, 250 "Public IPv4 over IPv6 Access 251 Network", draft-ietf-softwire- 252 public-4over6-01 (work in 253 progress), March 2012. 255 Authors' Addresses 257 Peng Wu 258 Tsinghua University 259 Department of Computer Science, Tsinghua University 260 Beijing 100084 261 P.R.China 263 Phone: +86-10-6278-5822 264 EMail: peng-wu@foxmail.com 266 Qi Sun 267 Tsinghua University 268 Department of Computer Science, Tsinghua University 269 Beijing 100084 270 P.R.China 272 Phone: +86-10-6278-5822 273 EMail: sunqi@csnet1.cs.tsinghua.edu.cn