|
North American Network Operators Group Date Prev | Date Next | Date Index | Thread Index | Author Index | Historical Re: Allocation of IP Addresses
> On Wed, 13 Mar 1996, Jim Browning wrote: > > > A. a single allocation capable of supporting planned growth, or > > B. incremental allocations of *contiguous* blocks > > > > InterNIC's current CIDR allocation practice does not support either of > > these options. > > Here's an idea. Let new ISP's reserve large blocks (say /16's) in 65/8, > 66/8, .... but don't let them actually use these addresses on the global > Internet. Then, the ISP can run a Network Address Translation gateway and > give their customers 65/8 addresses while still using a chunk from their > provider's block. And they can switch providers without forcing their > customers to renumber. Then, after they have demonstrated that they > should be given a /16, open up the block they were given in 65/8 for use > without the NAT. > Go back and learn a little more about IP and NAT boxes! A NAT box is a fine piece of equipment, and definitely has a purpose. However, it only supports certain applications and protocols, due to problems with some application layer checksums that can be in the payload. Changing the IP address on the packet _CAN_ effect these checksums. If the NAT doesn't know the protocol, then the NAT doesn't know how to recompute the checksum/CRC/etc. As a result, some protocols break through NATs. Admittedly, these are rare, and most companies don't use them. Therefore, if you're one of those companies, it's perfectly acceptable to put one of those boxes between your interior network and the external world. However, as an ISP, you have to pass your customers traffic, and your customers determine what should or shouldn't be a desirable protocol, not you. I don't know about you, but I don't even want to think about the Technical Support ramifications of a user who doesn't know much about the Internet calling up some small providers limited technical support staff saying "How come mail, ftp, nntp, and http work, but rxyz doesn't?" Think the average tech support person is going to catch that this is the result of the NAT box? Not likely. > Of course, there is one little problem with this.... > > bash$ whois 65 > Air Force Logistics Command (ASN-LOGNET) LOGNET-AS 65 That's an Autonomous system number, not a network. > IANA (RESERVED-7) Reserved 64.0.0.0 - 95.0.0.0 IANA gets all the addresses IANA wants. IANA is the Number Assignment Authority (Internet Assigned Numbers Authority). Currently, John Postel ([email protected]). Probably these blocks are reserved so that he can do things like what you are suggesting, should that become desirable. > > bash$ whois 96 > Army Finance and Accounting Office (ASN-JTELS) JTELS-BEN1-AS 96 Again, this is an autonomous system number, not a network number. > IANA (RESERVED-8) Reserved 96.0.0.0 - 126.0.0.0 Same explanation as above. > > How did these guys get such big chunks of address space reserved? > When you're the one who assigns the numbers, it's easy to get big chunks of numbers. Owen > > The day to day implementation of policy by the InterNIC has increasingly > > critical impact on our industry, to the point of controlling who has the > > opportunity to succeed and who does not. IMHO, it is imperative that: > > > > 1. this function be performed in an understandable manner, > > 2. objective criteria be consistently applied > > 3. the criteria in use be publicly available, and > > 4. there be defined mechanisms for the 'appeal' of decisions made in the > > processing of allocation requests. > > > > Recent experience and observation leads me to conclude that these > > imperatives are perhaps not being met. Am I all wet???? > > I think that the fundamental problem here is that the Internic is > fundamentally clueless about important issues such as global routing and > *BUSINESS* issues. They are behaving a lot like a government bureaucracy > or a regulatory agency. > > I don't really see how this can be fixed with the current system of > having a US government agency writing a contract with a private US > company to provide a fundamental international infrastructure service! > > > Michael Dillon Voice: +1-604-546-8022 > Memra Software Inc. Fax: +1-604-546-3049 > http://www.memra.com E-mail: [email protected] > >
|