idnits 2.17.1 draft-mlevy-v6ops-auto-v6-allocation-per-asn-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 abstract seems to contain references ([RFC2460], [RFC4271], [BARBER2011]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** 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 126: '... allocation MUST NOT advertise a mor...' RFC 2119 keyword, line 127: '...IPv6 network operators MUST filter out...' RFC 2119 keyword, line 181: '... as private ASNs MUST NOT use this sch...' RFC 2119 keyword, line 182: '...16-bit ASN 23456 MUST NOT use this sch...' Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (January 24, 2013) is 4109 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- ** Obsolete normative reference: RFC 2460 (Obsoleted by RFC 8200) ** Obsolete normative reference: RFC 3068 (Obsoleted by RFC 7526) ** Obsolete normative reference: RFC 4893 (Obsoleted by RFC 6793) Summary: 5 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group M. Levy 3 Internet-Draft Hurricane Electric 4 Intended status: Informational M. Pounsett 5 Expires: July 28, 2013 Afilias 6 January 24, 2013 8 A mechanism to allocate IPv6 blocks for BGP networks based on the 9 networks AS Number 10 draft-mlevy-v6ops-auto-v6-allocation-per-asn-00.txt 12 Abstract 14 This document provides a methodology for automatically allocating 15 IPv6 [RFC2460] address blocks for networks that run BGP [RFC4271] and 16 are either single-homed or multi-homed [BARBER2011]. The automatic 17 allocation is taken from a specific /16 block assigned by IANA for 18 this purpose. 20 Networks that require more than this single /48 can still request 21 additional allocations via the existing RIR process. Networks are 22 not forced to use this allocation and can ignore this completely. 23 Availability of the /48 assignment via this mechanism does not change 24 existing mechanisms for obtaining IPv6 assignments through the 25 existing RIR (Regional Internet Registry) or LIR (Local Internet 26 Registry) mechanisms. 28 There is an implicit assumption that it's a good thing to promote 29 networks to enable IPv6 with a near-zero effort. 31 Status of this Memo 33 This Internet-Draft is submitted in full conformance with the 34 provisions of BCP 78 and BCP 79. 36 Internet-Drafts are working documents of the Internet Engineering 37 Task Force (IETF). Note that other groups may also distribute 38 working documents as Internet-Drafts. The list of current Internet- 39 Drafts is at http://datatracker.ietf.org/drafts/current/. 41 Internet-Drafts are draft documents valid for a maximum of six months 42 and may be updated, replaced, or obsoleted by other documents at any 43 time. It is inappropriate to use Internet-Drafts as reference 44 material or to cite them other than as "work in progress." 46 This Internet-Draft will expire on July 28, 2013. 48 Copyright Notice 49 Copyright (c) 2013 IETF Trust and the persons identified as the 50 document authors. All rights reserved. 52 This document is subject to BCP 78 and the IETF Trust's Legal 53 Provisions Relating to IETF Documents 54 (http://trustee.ietf.org/license-info) in effect on the date of 55 publication of this document. Please review these documents 56 carefully, as they describe your rights and restrictions with respect 57 to this document. Code Components extracted from this document must 58 include Simplified BSD License text as described in Section 4.e of 59 the Trust Legal Provisions and are provided without warranty as 60 described in the Simplified BSD License. 62 Table of Contents 64 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 65 2. Defining the /48 address . . . . . . . . . . . . . . . . . . . 3 66 3. IANA allocated /16 . . . . . . . . . . . . . . . . . . . . . . 4 67 4. ASN bit length . . . . . . . . . . . . . . . . . . . . . . . . 4 68 5. ASN allocation . . . . . . . . . . . . . . . . . . . . . . . . 5 69 6. BGP Filtering and Validation . . . . . . . . . . . . . . . . . 5 70 7. Whois . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 8. RIR support . . . . . . . . . . . . . . . . . . . . . . . . . . 5 72 9. Reverse DNS . . . . . . . . . . . . . . . . . . . . . . . . . . 5 73 10. Routing Table Impact . . . . . . . . . . . . . . . . . . . . . 6 74 11. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 75 12. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 76 13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 6 77 14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 6 78 14.1. Normative References . . . . . . . . . . . . . . . . . . . 6 79 14.2. Informative References . . . . . . . . . . . . . . . . . . 7 80 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 7 82 1. Introduction 84 IPv6's massive address space provides a wonderful opportunity to 85 radically change the process of IP address allocation. Presently 86 IPv6 allocation is the same process as used by the IPv4 world. The 87 RIRs allocate IPv6 address blocks based on member requests and their 88 space requirements. A minimum allocation of a /48 is believed to be 89 sufficient to start any enterprise in the world of IPv6. 91 Described below is a method to automatically define an IPv6 /48 block 92 that can be used in the global routing tables for any ASN. 94 2. Defining the /48 address 96 The /48 address is allocated using a fixed pattern. 98 ASN-based address assignment 99 +----------+--------------------+-----------------/ /------------+ 100 | IANA /16 | 32 bit ASN | 80 bits for IPv6 /48 space | 101 +----------+--------------------+-----------------/ /------------+ 103 The sum of the bits in the IANA allocated /16 prefix plus the 32 bits 104 of the ASN plus the /48 of user defined usage adds up to 128 bits. 106 +------+----------------------+ 107 | Bits | Usage | 108 +------+----------------------+ 109 | 16 | IANA provided prefix | 110 | 32 | ASN | 111 | 80 | User defined | 112 | 128 | TOTAL | 113 +------+----------------------+ 115 Table 1: Address space math 117 The end network can allocate out of the assigned /48 as needed. It 118 is assumed that the end network will use this allocation for global 119 routing; however the network may choose to not announce this 120 allocation. 122 If any route is announced from this allocation, any prefixes more 123 specific than the allocated /48 must not be propagated in to the 124 global IPv6 routing table. This is to prevent the IPv6 routing table 125 from becoming too large. Therefore, a site which uses this 126 allocation MUST NOT advertise a more specific than the allocated /48 127 routing prefix. All native IPv6 network operators MUST filter out 128 and discard any routing prefix advertisements longer than /48 from 129 within this /16 allocation. 131 3. IANA allocated /16 133 IANA is to allocate a /16 in a similar manner to the 2002::/16 134 allocation for 6to4 [RFC3068] which is used by the 6to4 135 protocol[RFC3056].. No IPv4 allocation by IANA is required. 137 4. ASN bit length 139 ASNs are now defined as 32 bits[RFC4893] long. If a network operates 140 a smaller 16 bit ASN (for example an earlier allocation) then there 141 are 16 bits of zeros prepending the ASN number. No provision is 142 provided within this allocation methodology to provide 16 bit ASNs 143 with an advantage as this could cause an overlapping allocation. 145 No special treatment is provided an operator of a 16 bit ASN; All 146 ASNs are considered to use 32 bits. 148 16 bit ASNs (shown at binary) 149 +------+------+------+------+------+------+------+------+ 150 | 0000 | 0000 | 0000 | 0000 | #### | #### | #### | #### | 151 +------+------+------+------+------+------+------+------+ 153 32 bit ASNs (shown at binary) 154 +------+------+------+------+------+------+------+------+ 155 | #### | #### | #### | #### | #### | #### | #### | #### | 156 +------+------+------+------+------+------+------+------+ 158 ASNs are normally expressed as human-readable decimal numbers; yet 159 for this allocation the number should be converted into a hexadecimal 160 notation. All IPv6 addresses are written in hexadecimal. (NNNN 161 represents the /16 allocation by IANA) 163 +----------------+--------------------+---------------------+ 164 | ASN in decemal | ASN in hexadecimal | Sample IP block | 165 +----------------+--------------------+---------------------+ 166 | AS1 | 1 | NNNN:0000:0001::/48 | 167 | AS6939 | 1B1B | NNNN:0000:1B1B::/48 | 168 | AS29001 | 7149 | NNNN:0000:0001::/48 | 169 | AS393220 | 60004 | NNNN:0006:0004::/48 | 170 +----------------+--------------------+---------------------+ 172 Table 2: ASN examples 174 A network is assigned an ASN via the existing RIR process. Only 175 valid ASN holders can use this ASN-based prefix. 177 5. ASN allocation 179 ASNs are allocated by RIRs and this RFC does not handle that arena. 181 ASNs defined as private ASNs MUST NOT use this scheme. The special 182 16-bit ASN 23456 MUST NOT use this scheme. 184 6. BGP Filtering and Validation 186 Filtering would be a simple case of mapping the final ASN in a path 187 to the prefix in an exact bit-order match. 189 For example; the prefix NNNN:0000:1B1B::/48 should only be seen as 190 announced from AS6939 (6939 equals 0x1B1B in hex). Networks would 191 have their upstream transit providers add this /48 prefix to their 192 existing inbound BGP route filters. 194 7. Whois 196 In order for the IPv6 /48 to have valid whois information RIRs will 197 have to map it from their existing ASN whois data. The whois data 198 for the /48 should be the same as the ASN whois data. 200 8. RIR support 202 It is suggested that RIRs, via their Internet Registry services, 203 support these automatic assignments (including but not limited to 204 whois and reverse DNS). The RIRs should provide these services in 205 addition to the services already provided for the associated AS 206 number. 208 9. Reverse DNS 210 Reverse DNS is vital to the operation of the global Internet. Any 211 block allocated via this mechanism should include the ability to have 212 the network operator provide reverse DNS entries. 214 It is proposed that the first /64 from the allocated /48 have the 215 rDNS services hard coded into the ::1 and ::2 addresses. This allows 216 reverse DNS to operate without intervention or RIR involvement. 218 Nameserver 1: NNNN:####:####:0000::1 219 Naneserver 2: NNNN:####:####:0000::2 221 10. Routing Table Impact 223 This mechanism is not expected to have any impact to the global 224 Internet routing table since existing policies in the RIR system 225 already readily provide for the allocation of provider-independent 226 IPv6 prefixes. Additionally, AS number holders are likely to be 227 multihomed entities which were going to be independently routed in 228 any case. Service Providers are, as always, not obligated to route 229 these IPv6 assignments and/or may establish conditions of service 230 which offset any additional routing cost. 232 11. IANA Considerations 234 This memo includes a request to IANA to allocate a /16 from the 235 available IPv6 address space. 237 12. Security Considerations 239 There is clearly a need for RPKI ROAs for all allocated ASNs within 240 an RIR. The mapping would be 1:1 from ASN to /48 prefix. Hence an 241 RIR allocating an ASN should also allow the holder of that ASN to 242 manage this IPv6 prefix via their RIR portal. 244 There is nothing different in with a prefix from this space than from 245 a prefix allocated by an RIR. 247 13. Acknowledgements 249 We would like to thank the following people. ???? 251 We would also like to also thank the contributions from people in the 252 industry that have promoted IPv6 and multihoming: Bill Manning (as 253 himself) and Randy Bush (IIJ). 255 14. References 257 14.1. Normative References 259 [RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6 260 (IPv6) Specification", RFC 2460, December 1998. 262 [RFC3056] Carpenter, B. and K. Moore, "Connection of IPv6 Domains 263 via IPv4 Clouds", RFC 3056, February 2001. 265 [RFC3068] Huitema, C., "An Anycast Prefix for 6to4 Relay Routers", 266 RFC 3068, June 2001. 268 [RFC4271] Rekhter, Y., Li, T., and S. Hares, "A Border Gateway 269 Protocol 4 (BGP-4)", RFC 4271, January 2006. 271 [RFC4893] Vohra, Q. and E. Chen, "BGP Support for Four-octet AS 272 Number Space", RFC 4893, May 2007. 274 14.2. Informative References 276 [BARBER2011] 277 Barber, S., "IPv6 in the Real World: Practical 278 Multihoming", February 2011, . 281 Authors' Addresses 283 Martin J. Levy 284 Hurricane Electric 285 760 Mission Court 286 Fremont, CA 94359 287 US 289 Phone: +1 510 580-4100 290 Email: martin@he.net 291 URI: http://he.net/ 293 Matthew Pounsett 294 Afilias 295 4141 Yonge St., Suite 204 296 Toronto, Ontario M2P 2A8 297 CA 299 Phone: +1 416 646-3304 300 Email: mpounsett@afilias.info 301 URI: http://www.afilias.info/