From pjaenke at adelphia.net  Mon Jan 24 17:02:52 2000
From: pjaenke at adelphia.net (Phillip Jaenke)
Date: Mon, 24 Jan 2000 17:02:52 -0500
Subject: Call for Comments on IPv6 Allocations
Message-ID: <388CCC0C.63540A6F@adelphia.net>

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




From richardj at arin.net  Mon Jan 31 08:04:29 2000
From: richardj at arin.net (Richard Jimmerson)
Date: Mon, 31 Jan 2000 08:04:29 -0500
Subject: Call for Comments on IPv6 Allocations
In-Reply-To: <388CCC0C.63540A6F@adelphia.net>
Message-ID: <000701bf6beb$b6366d10$bdfc95c0@ARINNET>

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