Call for Comments on IPv6 Allocations

Richard Jimmerson richardj at arin.net
Mon Jan 31 08:04:29 EST 2000


Hello Phillip,

Thanks for your comments, I'll pass them on.

Best Regards,  

Richard Jimmerson
American Registry for Internet Numbers (ARIN)


| -----Original Message-----
| From: policy-request at arin.net 
| [mailto:policy-request at arin.net]On Behalf
| Of Phillip Jaenke
| Sent: Monday, January 24, 2000 5:03 PM
| To: policy at arin.net
| Subject: Re: Call for Comments on IPv6 Allocations
| 
| 
| Hi there. I've not done a CfC with ARIN before, nor am I the 
| person here
| responsible for requesting/maintaining IP space (just the DNS end of
| it;), but I figured it might be of some help if I chirped up, as it
| were, in dictating the policies for IPv6 allocation.
| 
| First off, I'd like to offer a definition of transport provider. 
| 
| I would define a 'transport provider' as a provider doing 
| IPv6 over IPv4
| during the transitional period, providing customers with IPv6 space as
| opposed to IPv4. The transport provider also would not provide
| necessarily hosting services, but only an indirect network connection.
| Ie; Customer A has a T1 to Transport Provider A. Customer A 
| has a block
| of IPv6 addresses that route to Transport Provider A's 
| router, which has
| a block of IPv4 addresses (or IPv6 addresses). Transport 
| Provider A then
| provides a  connection to Backbone Provider A, ie; UUnet, SprintLink,
| etc. 
| 
| This provider does not necessarily provide hosted services, 
| such as web
| hosting, colocation, etcetera, but does provide a form of connection,
| either a leased-line such as a T1 or DS3, or even dial-up service. 
| 
| This definition, of course, can be shifted upwards, in a sense, to
| define a Transport Provider as a backbone provider, such as UUnet or
| SprintLink, who does not necessarily provide dial-up service, but does
| provide leased-line services and routing services, either 
| via/with IPv4
| or IPv6.
| 
| Secondly, the email I recieved (forwarded from Richard Jimmerson
| (richardj at arin.net)) noted a desire for input on sections 4.2.3.2
| (Multihomed Sites), 2.1.4 (NLA Registries), 2.1.5 (End-sites), 4.2.8
| (Allocation to NLA Registries), and 4.3.1 (Assignments to End-users).
| Unfortunately, I do not have the skill nor knowledge to comment on all
| of these, but I would like to offer some input on 4.2.3.2 (Multihomed
| Sites) and 4.4 (Reclamation Methods/Conditions) assuming that 
| these are
| not set in stone, yet. 
| 
| Reguarding section 4.2.3.2;
| 
| I won't try to write it all, but rather, offer insights, opinions, and
| input. I believe that the current definitions for multihomed under ASN
| allocation would suffice for IPv6, with the exception for the 
| allowance
| of Internet2. Ie; University C has a connection to Provider A's public
| Internet connection, and a connection to Provider A (who is 
| an Internet2
| sponsor) for Internet2 only. This could be considered multihomed as
| University C therefore has two seperate connections to two seperate
| networks - the Internet and Internet2. 
| 
| Reguarding section 4.4 and section 2.2.3;
| 
| Due to the explosion of broadband technologies and the sheer amount of
| IPv6 space, it may be possible that broadband providers, such as
| Excite at Home and others, will move from reserved IP ranges 
| into public IP
| ranges, due to the requirement of 2 IPs per cablemodem. As 
| I'm sure some
| have noticed, broadband providers are simply *devouring* the 
| 24.0.0.0/8
| as it is handed out, and requesting more as soon as they are able. I
| have already begun to see addresses from the 25.0.0.0/8 
| handed out, and
| some providers are renumbering infrastructure equipment, such as
| servers, in other IP space, such as the 64.0.0.0/8 or net blocks
| allocated by their upstream providers in smaller blocks, ie; Classless
| /28's or Classless /24's. 
| 
| It is my opinion that providers utilizing the maximum routable space
| should be subject to a review of all allocations and assignments, as
| well as routing tables. It is very easy for a provider to 
| simply 'fake'
| IP usage by assigning multiple IPs to a single system. Therefore, any
| provider that has reached the current maximum should be subject to a
| voluntary audit of their allocation. During this audit, as opposed to
| simply allocationg more addresses, or giving a yay or nay vote for
| revoking 'wasted' address space, suggestions should be made by the
| reviewers as to how the provider can reclaim allocated space within
| their own network, such as using reserved address space for certain
| tasks, or increasing contiguous blocks. (ie; under IPv4, taking two
| classless /25's assigned to a terminal server, and combining 
| them into a
| single classless /24.)
| 
| Unfortunately, there are many providers who do not know how to
| effeciently or effectively allocate address space, and it 
| would work to
| the better of the Internet as a whole were these providers given some
| form of assistance, perhaps in the form of a mailing list, or 
| a paid for
| audit of their allocations by ARIN, rather than simply turned 
| down when
| requesting additional address space.
| 
| Thank you for your time, and I hope that you find this feedback
| valuable.
| 
| -- 
| -Phillip R. Jaenke, Unix Technician
|  pjaenke at adelphia.net





More information about the Policy mailing list