idnits 2.17.1 draft-miyakawa-1plus64s-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 15. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 181. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 192. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 199. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 205. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (June 30, 2008) is 5780 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) ** Downref: Normative reference to an Informational RFC: RFC 4241 Summary: 2 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Internet Engineering Task Force S. Miyakawa 3 Internet-Draft Y. Shirasaki 4 Expires: January 1, 2009 NTT Communications 5 June 30, 2008 7 1 + /64s as IPv6 Standard Access Model 8 draft-miyakawa-1plus64s-00 10 Status of this Memo 12 By submitting this Internet-Draft, each author represents that any 13 applicable patent or other IPR claims of which he or she is aware 14 have been or will be disclosed, and any of which he or she becomes 15 aware will be disclosed, in accordance with Section 6 of BCP 79. 17 Internet-Drafts are working documents of the Internet Engineering 18 Task Force (IETF), its areas, and its working groups. Note that 19 other groups may also distribute working documents as Internet- 20 Drafts. 22 Internet-Drafts are draft documents valid for a maximum of six months 23 and may be updated, replaced, or obsoleted by other documents at any 24 time. It is inappropriate to use Internet-Drafts as reference 25 material or to cite them other than as "work in progress." 27 The list of current Internet-Drafts can be accessed at 28 http://www.ietf.org/ietf/1id-abstracts.txt. 30 The list of Internet-Draft Shadow Directories can be accessed at 31 http://www.ietf.org/shadow.html. 33 This Internet-Draft will expire on January 1, 2009. 35 Copyright Notice 37 Copyright (C) The IETF Trust (2008). 39 Abstract 41 This document proposes the "standard" address assignment scheme for 42 IPv6 access network which uses RA or DHCPv6 to assign an global IPv6 43 address to the WAN interface of the CPE and DHCPv6 PD on the upstream 44 link of CPE to delegate one or more /64 prefixes to the CPE. 46 Table of Contents 48 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 49 2. General Considerations . . . . . . . . . . . . . . . . . . . . 3 50 3. 1+/64s scheme . . . . . . . . . . . . . . . . . . . . . . . . . 3 51 4. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 4 52 5. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 4 53 6. Security Considerations . . . . . . . . . . . . . . . . . . . . 4 54 7. Normative References . . . . . . . . . . . . . . . . . . . . . 4 55 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 5 56 Intellectual Property and Copyright Statements . . . . . . . . . . 6 58 1. Introduction 60 This document describes about the "standard" address assignment 61 scheme for IPv6 access network for especially residential or SOHO 62 service. 64 2. General Considerations 66 In IPv4 environment, there is a de-fact standard method to subscribe 67 ISP service. Usually, PPP (Point to Point Protocol) is used as an 68 abstraction of the user subscription in IPv4 only environment. A PPP 69 connection connects an access concentrator and a customer premises 70 equipment (CPE). One single global IPv4 address is assigned to the 71 WAN interface of the CPE. If CPE is a router, typically, CPE does 72 "network address translation (NAT)" and gives [RFC1918] based private 73 addresses to the hosts behind the CPE such as an personal computer 74 (PC) and so on. Even if the CPE is a bridging device, a PC beyond 75 CPE terminates PPP (PPPoE maybe) by itself and receives a global IPv4 76 address to be used. In each cases, from an access concentrator point 77 of view, there is no difference. The model is quite simple. It 78 gives to the "customer" one global IPv4 address. That's all. 80 On the other hand, if we think about IPv6 ISP, this model does not 81 work well, because there is no NAT in IPv6. Simply, we cannot use 82 "One global IPv6 address" model to assign global IPv6 addresses to 83 all machines behind the CPE router. We have to rely on some 84 different model. 86 3. 1+/64s scheme 88 +-----+ +-- PC 89 +---------------------+ | | | 90 Internet <---+ access concentrator +--- uplink ---+ CPE +---+ 91 +---------------------+ (WAN) | | | 92 +-----+ LAN 94 Figure 1: Network Model 96 "1+/64s" is quite simple scheme. 98 (A) Use RA or DHCPv6 to assign an global IPv6 address to the WAN 99 interface of the CPE. Do not leave the link between the access 100 concentrator and the CPE (the upstream link) link-local address 101 only. 103 (B) Use DHCPv6 PD the upstream link to delegate one or more /64 104 prefixes to the CPE so that it can use those prefixes to 105 configure LANs behind it. 107 4. Discussion 109 The reason why the condition (A) is needed is that there are "strong 110 model" implementations of the Internet Protocol. When we wrote 111 [RFC4241] ("A Model of IPv6/IPv4 Dual Stack Internet Access Service" 112 an Informational RFC describing NTT Communications' native IPv4/v6 113 dual stack ADSL service specification), we believed that there is no 114 need to use any global IPv6 address for the uplink. But, at the year 115 2007, when Microsoft Vista was released to the market, we found that 116 that operating system employs the strong host model shown in 117 [RFC1122]. 119 In this case, if the WAN interface of the CPE has only link-local 120 address, any application on the CPE cannot use the global ip address 121 even if this CPE has delegated prefix for LAN interface but chose the 122 link-local address as its source address towards any destination on 123 the Internet. So, we need to assign a global IPv6 address to the WAN 124 interface on the CPE. 126 5. IANA Considerations 128 There are no IANA considerations. 130 6. Security Considerations 132 TBD 134 7. Normative References 136 [RFC1122] Braden, R., "Requirements for Internet Hosts - 137 Communication Layers", STD 3, RFC 1122, October 1989. 139 [RFC1918] Rekhter, Y., Moskowitz, R., Karrenberg, D., Groot, G., and 140 E. Lear, "Address Allocation for Private Internets", 141 BCP 5, RFC 1918, February 1996. 143 [RFC4241] Shirasaki, Y., Miyakawa, S., Yamasaki, T., and A. 144 Takenouchi, "A Model of IPv6/IPv4 Dual Stack Internet 145 Access Service", RFC 4241, December 2005. 147 Authors' Addresses 149 Shin Miyakawa 150 NTT Communications Corporation 151 Tokyo Opera City Tower 21F, 3-20-2 Nishi-Shinjuku, Shinjuku-ku 152 Tokyo 163-1421 153 Japan 155 Phone: +81 3 6800 3262 156 Email: miyakawa@nttv6.jp 158 Yasuhiro Shirasaki 159 NTT Communications Corporation 160 NTT Hibiya Bldg. 7F, 1-1-6 Uchisaiwai-cho, Chiyoda-ku 161 Tokyo 100-8019 162 Japan 164 Phone: +81 3 6700 8530 165 Email: yasuhiro@nttv6.jp 167 Full Copyright Statement 169 Copyright (C) The IETF Trust (2008). 171 This document is subject to the rights, licenses and restrictions 172 contained in BCP 78, and except as set forth therein, the authors 173 retain all their rights. 175 This document and the information contained herein are provided on an 176 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 177 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 178 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 179 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 180 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 181 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 183 Intellectual Property 185 The IETF takes no position regarding the validity or scope of any 186 Intellectual Property Rights or other rights that might be claimed to 187 pertain to the implementation or use of the technology described in 188 this document or the extent to which any license under such rights 189 might or might not be available; nor does it represent that it has 190 made any independent effort to identify any such rights. Information 191 on the procedures with respect to rights in RFC documents can be 192 found in BCP 78 and BCP 79. 194 Copies of IPR disclosures made to the IETF Secretariat and any 195 assurances of licenses to be made available, or the result of an 196 attempt made to obtain a general license or permission for the use of 197 such proprietary rights by implementers or users of this 198 specification can be obtained from the IETF on-line IPR repository at 199 http://www.ietf.org/ipr. 201 The IETF invites any interested party to bring to its attention any 202 copyrights, patents or patent applications, or other proprietary 203 rights that may cover technology that may be required to implement 204 this standard. Please address the information to the IETF at 205 ietf-ipr@ietf.org. 207 Acknowledgment 209 Funding for the RFC Editor function is provided by the IETF 210 Administrative Support Activity (IASA).