idnits 2.17.1 draft-shirasaki-isp-shared-addr-07.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 seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (January 4, 2012) is 4488 days in the past. Is this intentional? Checking references for intended status: Best Current Practice ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'PROP58' is defined on line 177, but no explicit reference was found in the text == Outdated reference: A later version (-10) exists of draft-ietf-behave-lsn-requirements-05 == Outdated reference: A later version (-08) exists of draft-shirasaki-nat444-isp-shared-addr-06 == Outdated reference: A later version (-06) exists of draft-shirasaki-nat444-04 Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force I. Yamagata 3 Internet-Draft S. Miyakawa 4 Intended status: BCP NTT Communications 5 Expires: July 7, 2012 A. Nakagawa 6 Japan Internet Exchange (JPIX) 7 J. Yamaguchi 8 IIJ 9 H. Ashida 10 IS Consulting G.K. 11 January 4, 2012 13 ISP Shared Address 14 draft-shirasaki-isp-shared-addr-07 16 Abstract 18 This document defines IPv4 ISP Shared Address to be jointly used 19 among Internet Service Providers (ISPs). This space is intended to 20 be used in NAT444 model which is used during the transition period to 21 IPv6. 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 July 7, 2012. 40 Copyright Notice 42 Copyright (c) 2012 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 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. ISP Shared Address . . . . . . . . . . . . . . . . . . . . . . 4 71 2.1. Definition . . . . . . . . . . . . . . . . . . . . . . . . 4 72 2.2. Details . . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 3. Size of Address Space . . . . . . . . . . . . . . . . . . . . . 5 74 4. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 5 75 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 5 76 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 5 77 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 5 78 7.1. Normative References . . . . . . . . . . . . . . . . . . . 5 79 7.2. Informative References . . . . . . . . . . . . . . . . . . 5 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 6 82 1. Introduction 84 The only permanent solution of the IPv4 address exhaustion is to 85 deploy IPv6. Now, just before the exhaustion, it's time to make a 86 transition to IPv6. 88 NAT444 model [I-D.shirasaki-nat444] is one of the solutions for 89 transition to IPv6. 91 This document defines ISP Shared Address to be used in NAT444 model 92 [I-D.shirasaki-nat444-isp-shared-addr]. It is supposed to be used 93 between Customer Premises Equipment (CPE) and Carrier Grade NAT (CGN) 94 [I-D.ietf-behave-lsn-requirements]. 96 ISP Shared Address is needed until the IPv4 Internet fades out. 98 2. ISP Shared Address 100 2.1. Definition 102 ISP Shared Address is intended to be assigned between CPE and CGN in 103 a NAT444. 105 2.2. Details 107 - Each ISP can use ISP Shared Address without any coordination with 108 IANA or Internet registries. 110 - ISP Shared Address can be used by many ISPs. 112 - ISP has to install CGN to use ISP Shared Address. 114 - ISP Shared Address must not be used at customers' site or Internet 115 Exchanges. 117 - Routing information of ISP Shared Address must not be advertised to 118 the Internet. 120 - Reverse DNS queries for this address space must not be sent to root 121 DNS servers. 123 - Packets with this space as source address and/or destination 124 address must be filtered out at the border of each ISP. 126 - Addresses within this address space should be unique within the 127 ISP, or the set of ISPs which choose to cooperate over this space so 128 they may directly communicate with each other in their networks. 130 3. Size of Address Space 132 Because the aggregation size of Tokyo area POP is around /10 in 133 Japan, /10 should be the hard limit of minimum size ISP Shared 134 Address. We understand this can be determined by further 135 discussions. 137 4. Acknowledgements 139 Thanks for the input and review by Shirou Niinobe, Takeshi Tomochika, 140 Tomohiro Fujisaki, Dai Nishino, JP address community members, AP 141 address community members and JPNIC members. 143 5. IANA Considerations 145 IANA is to record the allocation of the IPv4 global unicast address 146 as ISP Shared Address in the IPv4 address registry. 148 6. Security Considerations 150 ISP Shared Address is supposed to be used with CGN. The Global IPv4 151 address that is assigned outside CGN may be used as source address of 152 'Denial of Service' attack. 154 7. References 156 7.1. Normative References 158 [I-D.ietf-behave-lsn-requirements] 159 Perreault, S., Yamagata, I., Miyakawa, S., Nakagawa, A., 160 and H. Ashida, "Common requirements for Carrier Grade NATs 161 (CGNs)", draft-ietf-behave-lsn-requirements-05 (work in 162 progress), November 2011. 164 7.2. Informative References 166 [I-D.shirasaki-nat444-isp-shared-addr] 167 Yamaguchi, J., Shirasaki, Y., Miyakawa, S., Nakagawa, A., 168 and H. Ashida, "NAT444 addressing models", 169 draft-shirasaki-nat444-isp-shared-addr-06 (work in 170 progress), July 2011. 172 [I-D.shirasaki-nat444] 173 Yamagata, I., Shirasaki, Y., Nakagawa, A., Yamaguchi, J., 174 and H. Ashida, "NAT444", draft-shirasaki-nat444-04 (work 175 in progress), July 2011. 177 [PROP58] Niinobe, S., Tomochika, T., Yamaguchi, J., Nishino, D., 178 Ashida, H., Nakagawa, A., and T. Hosaka, "Proposal to 179 create IPv4 shared use address space among LIRs", 2008, 180 . 183 Authors' Addresses 185 Ikuhei Yamagata 186 NTT Communications Corporation 187 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 188 Tokyo 108-8118 189 Japan 191 Phone: +81 3 6700 8530 192 Email: ikuhei@nttv6.jp 194 Shin Miyakawa 195 NTT Communications Corporation 196 Gran Park Tower 17F, 3-4-1 Shibaura, Minato-ku 197 Tokyo 108-8118 198 Japan 200 Phone: +81 50 3812 4695 201 Email: miyakawa@nttv6.jp 203 Akira Nakagawa 204 Japan Internet Exchange Co., Ltd. (JPIX) 205 Otemachi Building 21F, 1-8-1 Otemachi, Chiyoda-ku 206 Tokyo 100-0004 207 Japan 209 Phone: +81 90 9242 2717 210 Email: a-nakagawa@jpix.ad.jp 211 Jiro Yamaguchi 212 Internet Initiative Japan Inc. 213 Jinbocho Mitsui Bldg., 1-105 Kanda Jinbo-cho, Chiyoda-ku 214 Tokyo 101-0051 215 Japan 217 Phone: +81 3 5205 6500 218 Email: jiro-y@iij.ad.jp 220 Hiroyuki Ashida 221 IS Consulting G.K. 222 12-17 Odenma-cho, Nihonbashi, Chuo-ku 223 Tokyo 103-0011 224 Japan 226 Email: assie@hir.jp