idnits 2.17.1 draft-yhb-6man-slaac-improvement-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 a Security Considerations section. ** 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.) ** 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 15: '... the sites MUST use 64-bit prefixes....' RFC 2119 keyword, line 66: '...h and interface identifier length MUST...' RFC 2119 keyword, line 69: '...It means the prefix length MUST be 64,...' RFC 2119 keyword, line 77: '... that the sites MUST use 64-bit prefi...' RFC 2119 keyword, line 87: '... The keywords MUST, MUST NOT, REQUIR...' (10 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (August 28, 2011) is 4623 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) == Missing Reference: 'RFC2119' is mentioned on line 90, but not defined == Unused Reference: 'RFC4862' is defined on line 208, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 213, but no explicit reference was found in the text == Unused Reference: 'RFC4941' is defined on line 216, but no explicit reference was found in the text == Unused Reference: 'RFC5214' is defined on line 220, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 4941 (Obsoleted by RFC 8981) Summary: 3 errors (**), 0 flaws (~~), 6 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 6man Working Group Yu hua bing 2 Internet-Draft Ruijie Networks, China 3 Intended status: Standards Track 4 Expiration: August 28, 2011 5 February 28, 2011 7 IPv6 Stateless Address Autoconfiguration With Prefixes Longer Than 64 8 draft-yhb-6man-slaac-improvement-00 10 Abstract 12 IPv6 stateless address autoconfiguration described by RFC4862 only 13 supports 64-bit prefixes. This approach can't be deployed in the 14 sites with prefixes longer than 64. We have no right to require that 15 the sites MUST use 64-bit prefixes. This document tries to implement 16 stateless address autoconfiguration with prefixes longer than 64. 18 Status of this Memo 20 This Internet-Draft is submitted in full conformance with the 21 provisions of BCP 78 and BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF). Note that other groups may also distribute 25 working documents as Internet-Drafts. The list of current Internet- 26 Drafts is at http://datatracker.ietf.org/drafts/current/. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 Copyright Notice 35 Copyright (c) 2011 IETF Trust and the persons identified as the 36 document authors. All rights reserved. 38 This document is subject to BCP 78 and the IETF Trust's Legal 39 Provisions Relating to IETF Documents 40 (http://trustee.ietf.org/license-info) in effect on the date of 41 publication of this document. Please review these documents 42 carefully, as they describe your rights and restrictions with respect 43 to this document. Code Components extracted from this document must 44 include Simplified BSD License text as described in Section 4.e of 45 the Trust Legal Provisions and are provided without warranty as 46 described in the Simplified BSD License. 48 Table of Contents 50 1. Introduction ....................................................2 51 2. Protocol Specification ..........................................2 52 2.1. Router Advertisement Processing ............................2 53 2.2. ISATAP Tunnel ..............................................4 54 2.3. Analysis of Duplicate Address Possiblity ...................4 55 3. References ......................................................5 56 3.1. Normative References .......................................5 57 3.2. Informative References .....................................5 59 1. Introduction 61 The IPv6 stateless address autoconfiguration described by RFC4862 62 requires no manual configuration of hosts and no additional servers, 63 so it is welcomed by a lot of users. But it has a detect that some 64 users complain about: 66 The sum of the prefix length and interface identifier length MUST 67 equal 128 bits. RFC4291 specifies that for all unicast addresses, 68 except those that start with the binary value 000, Interface IDs are 69 required to be 64 bits long. It means the prefix length MUST be 64, 70 and this approach can't be deployed in the sites with prefixes longer 71 than 64. 73 A 64-bit prefix can generate at most 2^64 IPv6 addresses. In fact, 74 any LAN can't run out of so many IPv6 addresses, and only a very 75 small part of IPv6 addresses are used, so it is a serious waste. Some 76 sites do not need 64-bit prefixes. We have no right to require 77 that the sites MUST use 64-bit prefixes. 79 If the prefix of the site is longer than 64, or if the prefix is 64 80 bits long, and the site is divided into several subnets, then the 81 stateless address autoconfiguration cannot be used and the 82 convenience it will bring cannot be shared. 84 So we scream for stateless address autoconfiguration with prefixes 85 longer than 64. 87 The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD, 88 SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this 89 document, are to be interpreted as described in [RFC2119]. 91 2. Protocol Specification 93 2.1. Router Advertisement Processing 95 When a host receives a valid router advertisement, execute the 96 following steps for each Prefix-Information option in the router 97 advertisement: 99 (1) If the Autonomous flag is not set, silently ignore the Prefix 100 Information option. 102 (2) If the prefix is a link-local prefix, silently ignore the 103 Prefix Information option. 105 (3) If the preferred lifetime is greater than the valid lifetime, 106 silently ignore the Prefix Information option. A node MAY wish to 107 log a system management error in this case. 109 (4) If the prefix length is less than (128 - length of interface ID) 110 or more than 126, the Prefix Information option MUST be ignored. An 111 implementation MAY wish to log a system management error in this 112 case. 114 (5) If the prefix advertised overlaps with the prefix of an 115 address configured by stateless autoconfiguration already in the 116 list of addresses associated with the interface, and the former is 117 not equal to the latter, the Prefix Information option MUST be 118 ignored. An implementation MAY wish to log a system management error 119 in this case. 121 (6) If the receiving interface is not ISATAP tunnel interface, the 122 Valid Lifetime is not 0, host ID is configured (the host ID greater 123 than 0 and less than 2 ^ (128 - prefix length) is valid), an address 124 is formed by combining the advertised prefix with the host ID as 125 follows: 127 | N bits | 128 - N bits | 128 +---------------------------------------+------------------------+ 129 | link prefix | host ID | 130 +----------------------------------------------------------------+ 132 A host MUST allow the host ID to be configured by system management. 134 If the host ID configured on the host is invalid, an address can't 135 be formed. A node MUST log a system management error in this case. 137 (7) If the receiving interface is Ethernet, and the Valid Lifetime 138 is not 0, do with the Prefix-Information option as follows: 140 (7.1) If the prefix length is 64, an address is formed by combining 141 the advertised prefix with the interface identifier. 143 (7.2)If the prefix length is greater than 64 and is not greater than 144 80, an address is formed by combining the advertised prefix with 145 the MAC address of the interface as follows: 147 | N bits | (80 - N) bits | 48 bits | 148 +------------------------------+---------------+-----------------+ 149 | link prefix | reserved | MAC address | 150 +----------------------------------------------------------------+ 152 The middle (80 - N) bits are reserved for future use, now it MUST be 153 zero. 155 (7.3) If the prefix length is greater than 80, a random number 156 between 0 and 2 ^ (128 - prefix length) is generated, and an address 157 is formed by combining the advertised prefix with the random number 158 as follows: 160 | N bits | 128 - N bits | 161 +---------------------------------------+------------------------+ 162 | link prefix | random number | 163 +----------------------------------------------------------------+ 165 (8) If the receiving interface is not Ethernet, execute step d in 166 section 5.5.3 of RFC4862. 168 (9) If the advertised prefix is equal to the prefix of an address 169 configured by stateless autoconfiguration in the list, execute step 170 e in section 5.5.3 of RFC4862. 172 2.2. ISATAP Tunnel 174 Besides Ethernet, stateless address autoconfiguration is often used 175 on an ISATAP tunnel. But, it is a pity that the ISATAP tunnel can't 176 support stateless address autoconfiguration with prefixes longer 177 than 64 because of ISATAP interface identifier. 179 2.3. Analysis of Duplicate Address Possibility 181 On the Ethernet, if the prefix length is not less than 64 and not 182 greater than 80,use the MAC address to form the IPv6 address. The 183 possibility that the IPv6 address is duplicate is very low, because 184 the possibility that the MAC address is duplicate is very low. 186 If the prefix length is greater than 80, it is more convenient for 187 users to use the random number to form the IPv6 address, but the 188 IPv6 address is possibly duplicate. Suppose there are M hosts on the 189 link,the prefix length is N, if all hosts run stateless address 190 autoconfiguration almost at the same time, for each host, duplicate 191 address possibility P is (M-1)/(2^(128-N)-1). In order to ensure 192 each host runs stateless address autoconfiguration successfully, P 193 SHOULD be less than 1/1000. For example, there are 1000 hosts on the 194 link, if it is required that P should be less than 1/1000, N should 195 be less than 108.If stateless address autoconfiguration fails for 196 the first time, it is a good idea to try more times. 198 Another choice is that the network administrator assigns host IDs to 199 each host. The first benefit is that the IPv6 addresses can be fully 200 used, for example, on the link with 1000 hosts, the 118-bit prefix 201 is enough. The second benefit is that duplicate address possibility 202 is very low, almost zero. 204 3. References 206 3.1. Normative References 208 [RFC4862] Thomson, S., Narten, T., and T. Jinmei, "IPv6 Stateless 209 Address Autoconfiguration", RFC 4862, September 2007. 211 3.2. Informative References 213 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 214 Architecture", RFC 4291, February 2006. 216 [RFC4941] T. Narten,R. Draves and S. Krishnan, "Privacy Extensions 217 for Stateless Address Autoconfiguration in IPv6", RFC 218 4941, September 2007. 220 [RFC5214] F. Templin,T. Gleeson and D. Thaler, "Intra-Site 221 Automatic Tunnel Addressing Protocol (ISATAP)", RFC 5214, 222 March 2008. 224 Authors' Addresses 226 Yu hua bing 227 Ruijie Networks 228 Fuzhou 229 Fujian 230 China 232 Email: yhb@ruijie.com.cn