
---------- From: Jim Fleming[SMTP:JimFleming] Sent: Monday, April 20, 1998 2:15 PM To: 'arin-council at arin.net'; 'ARIN list' Cc: 'BBURR at ntia.doc.gov'; 'ietf at ns.ietf.org'; 'Ira_C._Magaziner at oa.eop.gov' Subject: Structuring the Root Structuring the Root for the IPv4 Internet can be as simple as assigning each of the TLD authorities a section of the IPv4 address space to "manage" (not route). The IN-ADDR.ARPA zone file could be cleaned up once delegations are made in a more distributed manner. It is important to note that this methodology does not "use" all of the IPv4 addresses, it just distributes them fairly for management purposes. Based on the contents of the Root Zone file from the legacy Root Name Server Cluster operated by the U.S. Government, the following TLDs appear to be recognized: (only .ARPA is out of alpha order) 0 ARPA 1 AC 2 AD 3 AE 4 AF 5 AG 6 AI 7 AL 8 AM 9 AN 10 AO 11 AQ 12 AR 13 AS 14 AT 15 AU 16 AW 17 AZ 18 BA 19 BB 20 BE 21 BF 22 BG 23 BH 24 BI 25 BJ 26 BM 27 BN 28 BO 29 BR 30 BS 31 BT 32 BV 33 BW 34 BY 35 BZ 36 CA 37 CC 38 CD 39 CF 40 CG 41 CH 42 CI 43 CK 44 CL 45 CM 46 CN 47 CO 48 COM <------ See example below 49 CR 50 CU 51 CV 52 CX 53 CY 54 CZ 55 DE 56 DJ 57 DK 58 DM 59 DO 60 DZ 61 EC 62 EDU 63 EE 64 EG 65 ER 66 ES 67 ET 68 FI 69 FJ 70 FK 71 FM 72 FO 73 FR 74 GA 75 GB 76 GD 77 GE 78 GF 79 GG 80 GH 81 GI 82 GL 83 GM 84 GN 85 GOV 86 GP 87 GQ 88 GR 89 GS 90 GT 91 GU 92 GW 93 GY 94 HK 95 HM 96 HN 97 HR 98 HT 99 HU 100 ID 101 IE 102 IL 103 IM 104 IN 105 INT 106 IO 107 IQ 108 IR 109 IS 110 IT 111 JE 112 JM 113 JO 114 JP 115 KE 116 KG 117 KH 118 KI 119 KN 120 KR 121 KW 122 KY 123 KZ 124 LA 125 LB 126 LC 127 LI 128 LK 129 LR 130 LS 131 LT 132 LU 133 LV 134 LY 135 MA 136 MC 137 MD 138 MG 139 MH 140 MIL 141 MK 142 ML 143 MM 144 MN 145 MO 146 MP 147 MQ 148 MR 149 MS 150 MT 151 MU 152 MV 153 MW 154 MX 155 MY 156 MZ 157 NA 158 NC 159 NE 160 NET 161 NF 162 NG 163 NI 164 NL 165 NO 166 NP 167 NR 168 NU 169 NZ 170 OM 171 ORG 172 PA 173 PE 174 PF 175 PG 176 PH 177 PK 178 PL 179 PM 180 PN 181 PR 182 PT 183 PW 184 PY 185 QA 186 RE 187 RO 188 RU 189 RW 190 SA 191 SB 192 SC 193 SD 194 SE 195 SG 196 SH 197 SI 198 SJ 199 SK 200 SL 201 SM 202 SN 203 SO 204 SR 205 ST 206 SU 207 SV 208 SY 209 SZ 210 TC 211 TD 212 TF 213 TG 214 TH 215 TJ 216 TK 217 TM 218 TN 219 TO 220 TP 221 TR 222 TT 223 TV 224 TW 225 TZ 226 UA 227 UG 228 UK 229 UM 230 US 231 UY 232 UZ 233 VA 234 VC 235 VE 236 VG 237 VI 238 VN 239 VU 240 WF 241 WS 242 YE 243 YT 244 YU 245 ZA 246 ZM 247 ZR 248 ZW 249 <AVAILABLE> 250 <AVAILABLE> 251 <AVAILABLE> 252 <AVAILABLE> 253 <AVAILABLE> 254 <AVAILABLE> 255 <AVAILABLE> The last 7 slots could be used to add new TLDs as part of the transition described in the Department of Commerce's Green Paper. Once all 256 slots are filled the number on the left can be used to identify sections of the IPv4 Address Space that can be delegated to the various TLD authorities for "management" (and stewardship). A simple way to do this is to use the number above to specify the value for bits in the fields labeled here as TTT.TTTTT. aaaaaTTT.TTTTTbbb.bbbbbbbb.bbbbbbbb If the value of aaaaa is allowed to range from 0 to 31 for EACH of the values of TTT.TTTTT then prefixes can be identified for each of the TLD authorities to manage. This approach distributes the entire IPv4 address space to responsible parties for management and stewardship purposes. Using the value of 48 for the .COM TLD illustrates that the following IPv4 blocks would be placed in the hands of the InterNIC (NSF/NSI) for management. Since the NSF and NSI have delegated IPv4 numbering to ARIN, these 32 /13 blocks would be managed by ARIN. This would be all ARIN manages for revenue producing activities. The rest of the IPv4 space would be distributed to other TLD authorities to more fairly distribute the assets that produce revenue. 1.128-135.0.0 9.128-135.0.0 17.128-135.0.0 25.128-135.0.0 33.128-135.0.0 41.128-135.0.0 49.128-135.0.0 57.128-135.0.0 65.128-135.0.0 73.128-135.0.0 81.128-135.0.0 89.128-135.0.0 97.128-135.0.0 105.128-135.0.0 113.128-135.0.0 121.128-135.0.0 129.128-135.0.0 137.128-135.0.0 145.128-135.0.0 153.128-135.0.0 161.128-135.0.0 169.128-135.0.0 177.128-135.0.0 185.128-135.0.0 193.128-135.0.0 201.128-135.0.0 209.128-135.0.0 217.128-135.0.0 225.128-135.0.0 233.128-135.0.0 241.128-135.0.0 249.128-135.0.0 The following C program can be used to determine other ranges of blocks given a TLD index as shown above. /* * * gs n * * Generates a gs number based an 8 bit value * */ main(argc,argv) int argc; char *argv[]; { int i; int k; int n; k = ((atoi(argv[1]) << 19) & 0x07f80000); for(i=0; i<32; i++){ n = (i<<27) + k; printf("%d.%d-%d.%d.%d\n", (n>>24)&0xff, (n>>16)&0xff, ((n>>16)+7)&0xff, (n>>8)&0xff, n&0xff); } } ===== -------- Logged at Mon Apr 20 23:49:02 MET DST 1998 ---------