idnits 2.17.1 draft-arifumi-softwire-dslite-global-addr-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Sep 2009 rather than the newer Notice from 28 Dec 2009. (See https://trustee.ietf.org/license-info/) 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 a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 129: '...4 Address Option MUST NOT appear more ...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 2, 2010) is 5167 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Outdated reference: A later version (-10) exists of draft-ietf-softwire-ds-lite-tunnel-option-01 == Outdated reference: A later version (-11) exists of draft-ietf-softwire-dual-stack-lite-03 Summary: 2 errors (**), 0 flaws (~~), 4 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Softwires Working Group A. Matsumoto 3 Internet-Draft T. Fujisaki 4 Intended status: Standards Track NTT 5 Expires: September 3, 2010 March 2, 2010 7 Global IPv4 Address Configuration Option for DS-Lite 8 draft-arifumi-softwire-dslite-global-addr-00.txt 10 Abstract 12 When an ISP tries to deploy IPv6 and take an action for IPv4 address 13 depletion, DS-Lite is reasonable approach for solving both of the 14 problems. However, it is troublesome for an ISP to have the existing 15 IPv4 service facilities and DS-Lite facilities at the same time for 16 not a short period of time. This document proposes a mechanism to 17 assign an IPv4 global address in DS-Lite framework, which makes every 18 customer to move to DS-Lite based network, and enables an ISP to 19 maintain single facility of the service network. 21 Status of this Memo 23 This Internet-Draft is submitted to IETF 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), its areas, and its working groups. Note that 28 other groups may also distribute working documents as Internet- 29 Drafts. 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 The list of current Internet-Drafts can be accessed at 37 http://www.ietf.org/ietf/1id-abstracts.txt. 39 The list of Internet-Draft Shadow Directories can be accessed at 40 http://www.ietf.org/shadow.html. 42 This Internet-Draft will expire on September 3, 2010. 44 Copyright Notice 46 Copyright (c) 2010 IETF Trust and the persons identified as the 47 document authors. All rights reserved. 49 This document is subject to BCP 78 and the IETF Trust's Legal 50 Provisions Relating to IETF Documents 51 (http://trustee.ietf.org/license-info) in effect on the date of 52 publication of this document. Please review these documents 53 carefully, as they describe your rights and restrictions with respect 54 to this document. Code Components extracted from this document must 55 include Simplified BSD License text as described in Section 4.e of 56 the Trust Legal Provisions and are provided without warranty as 57 described in the BSD License. 59 This document may contain material from IETF Documents or IETF 60 Contributions published or made publicly available before November 61 10, 2008. The person(s) controlling the copyright in some of this 62 material may not have granted the IETF Trust the right to allow 63 modifications of such material outside the IETF Standards Process. 64 Without obtaining an adequate license from the person(s) controlling 65 the copyright in such materials, this document may not be modified 66 outside the IETF Standards Process, and derivative works of it may 67 not be created outside the IETF Standards Process, except to format 68 it for publication as an RFC or to translate it into languages other 69 than English. 71 Table of Contents 73 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Global IPv4 Address Assignment for B4 . . . . . . . . . . . . . 4 75 3. DS-Lite Global IPv4 Address Option for DHCPv4 . . . . . . . . . 5 76 4. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 77 5. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 78 6. Normative References . . . . . . . . . . . . . . . . . . . . . 5 79 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 81 1. Introduction 83 When an ISP tries to deploy IPv6 and take an action for IPv4 address 84 depletion, DS-Lite [I-D.ietf-softwire-dual-stack-lite] is reasonable 85 approach for solving both of the problems. 87 In the existing IPv4 service, an ISP usually provides an IPv4 global 88 address for each customer. IPv4 address depletion does not mean that 89 ISP will lose already acquired IPv4 global address blocks, so they 90 will continue to provide the IPv4 global address service to a part of 91 the existing customers regardless of whether IPv6 connectivity 92 service is provided to the customers or not. 94 However, it will be troublesome for an ISP to have and maintain the 95 existing IPv4 service facilities and DS-Lite facilities at the same 96 time and for not a short period of time. 98 This document proposes a mechanism to assign an IPv4 global address 99 in DS-Lite framework, which makes every customer to move to DS-Lite 100 based network, and enables an ISP to maintain single facility of the 101 service network. 103 2. Global IPv4 Address Assignment for B4 105 A new DHCPv4 option is proposed here to assign an IPv4 global address 106 for a customer. This option is used in combination with the option 107 to notify DS-Lite tunnel endpoint address defined in this draft 108 [I-D.ietf-softwire-ds-lite-tunnel-option]. 110 When a DS-Lite capable router receives both of these options, that 111 means the router should behave in DS-Lite with IPv4 global address 112 manner. When it receives just a tunnel endpoint option, that means 113 the router should behave in normal DS-Lite manner. 115 B4 should use the received IPv4 global address as the inner address 116 of its DS-Lite tunnel interface. 118 AFTR has to have IPv4 routing information, which is which DS-Lite 119 tunnel should be used for forwarding IPv4 packet, for each IPv4 gobal 120 address assigned customer. AFTR just acts as a router and tunnel 121 endpoint, not as a NAT device for this type of customers. In order 122 to tell whether do NATing or not, AFTR should have a list of IPv4 123 global address blocks for NATing, or non-NATing, or both. And, AFTR 124 has to look at the list, when it receives a packet from tunnel 125 interface and also from up-stream interface. 127 3. DS-Lite Global IPv4 Address Option for DHCPv4 129 The DS-Lite Global IPv4 Address Option MUST NOT appear more than once 130 in a message. 132 The format of the DS-Lite Global IPv4 Address Option is shown in the 133 following figure: 135 0 1 2 3 136 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 137 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 138 | option-code | option-len | IPv4 address | 139 +-------------------------------+-------------------------------+ 140 | IPv4 address (cont.) | 141 +-------------------------------+ 143 DS-Lite Global IPv4 Address DHCPv4 Option format. 145 4. IANA Considerations 147 IANA is requested to allocate two DHCPv4 Option code referencing this 148 document. 150 5. Security Considerations 152 TBD 154 6. Normative References 156 [I-D.ietf-softwire-ds-lite-tunnel-option] 157 Hankins, D. and T. Mrugalski, "Dynamic Host Configuration 158 Protocol for IPv6 (DHCPv6) Options for Dual- Stack Lite", 159 draft-ietf-softwire-ds-lite-tunnel-option-01 (work in 160 progress), January 2010. 162 [I-D.ietf-softwire-dual-stack-lite] 163 Durand, A., Droms, R., Haberman, B., Woodyatt, J., Lee, 164 Y., and R. Bush, "Dual-stack lite broadband deployments 165 post IPv4 exhaustion", 166 draft-ietf-softwire-dual-stack-lite-03 (work in progress), 167 February 2010. 169 Authors' Addresses 171 Arifumi Matsumoto 172 NTT PF Lab 173 Midori-Cho 3-9-11 174 Musashino-shi, Tokyo 180-8585 175 Japan 177 Phone: +81 422 59 3334 178 Email: arifumi@nttv6.net 180 Tomohiro Fujisaki 181 NTT PF Lab 182 Midori-Cho 3-9-11 183 Musashino-shi, Tokyo 180-8585 184 Japan 186 Phone: +81 422 59 7351 187 Email: fujisaki@syce.net