Call for Comments on IPv6 Allocations

[Phillip Jaenke]

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