[ppml] Comments on revised 2005-1 proposal of 2006-02-03

Fri Feb 10 09:28:55 EST 2006

    If every sane end user that depends on the internet should need to have 
PI space, then it would seem that there is a very good chance that every 
sane user of the internet today will demand PI space soon anywy. So how 
about we just given any originzation that asks for it a /48 direct from 
ARIN. After all it's going to be prohibitively painfull when they go from 
Provider IPv6 space to PI IPv6 space right? Under this likelyhood we
might as well also stop giving /32s to LIR/ISPs, because noone will
be using space from ISPs, etc...

(I hope you detected the sarcasim in that first paragraph)

   My reasoning for suggeting that only large 'end orginizations' should 
currently be elidable for PI space...  My posistion is that ARIN should 
NOT give any PI space to any originzation that has a single physical site 
at this time. Given the difficulty in renumbering is even greater if an 
orginzation could have large numbers of /48s, I belive we should make 
provisions for very large orginzations to obtain PI space at this time. 
The reason I think these large originzations should qualify and smaller 
ones should not, is simply because it's going to be much more risky for 
these large orginzations to put for the effort to go to IPv6.  So, it's my 
feeling that any originzation that can that show they would be able to 
obtain signficant numbers of /48s under current policy (by getting them 
from LIR/ISPs all over the ARIN region), should be able to go direct to 
ARIN and obtain enough space in a single contigious block, to suit all of 
their individual /48 needs.

   I'm thinking of orginizations like perhaps WalMart, Kmart/Sears, Ford, 
GM, Toyta, Honda, Starbucks, McDonalds, Wendys, Tim Hortons(for all you 
Canadians out there), etc... where if each individual location of these 
companys got a /48 from some local ISP, the company as a whole, would 
infact be eligible to obtain significant numbers of /48s under current 
policy. I beleive originzations like these that wish to move to IPv6 at 
this time, should be able to get direct PI assignments from ARIN. Part of 
the reason I think these large companys should be given a early advantage 
over small companys, is simply because if some of these big companys never 
move to IPv6 then there's a good chance that IPv6 will never get widely 
used in the ARIN region.

   Where I'm not convinced that Glenn's corner store in my hometown
USA, should be able to get any PI space at this time.

Glenn Wiltse

On Thu, 9 Feb 2006, Owen DeLong wrote:

> I thought the original argument against opening up PI was to avoid creating
> an early adopter advantage.  Why is it better to give large organizations
> first crack at an early adopter advantage and then later consider whether
> or not to treat the rest as second class citizens?  I see that as being
> even worse than the small risk of an early adopter advantage.
>
> Frankly, I think that realistically, the following are true:
>
> 1.	We need a new IDR paradigm that allows for a separation between
> 	the routing locator and the end system identifier (ASN and IP
> 	address are most likely mappings for RL and ESI in the near
> 	term, but, today, we are using IP address for both).
>
> 2.	By continuing to treat organizations below some arbitrary
> 	threshold as second class citizens on the internet, we _MAY_
> 	be able to postpone the date when the new routing paradigm
> 	mentioned in 1 is required.
>
> 3.	Even if we gave v6 PI blocks to everyone who could justify
> 	them under the most liberal of these policies, I believe it
> 	would be at least 10 years before we had to truly worry
> 	about router meltdown due to table size.  That should be
> 	more than adequate time for IETF to develop a solution.
> 	(I believe I have good beginnings of a solution.  Let me
> 	know if you are interested in more detail).
>
> 4.	I believe a solution is possible which requires:
>
> 	1.	code changes on core routers.
> 	2.	code changes on DFZ Edge routers.
> 	3.	Additional CPU on DFZ Edge routers (potentially)
> 	4.	Suggests crypto acceleration on DFZ Edge routers
> 	5.	Does not require modifications to non-DFZ routers
> 	6.	Limits the size of the global routing table to the
> 		list of viable AS Paths.
> 	7.	Allows leaf sites to multihome with a single PI block
> 		and no AS, thus not increasing the routing table
> 		slots in the DFZ.
>
> 5.	Since the above solution does not require edge router updates,
> 	and most DFZ routers see software updates more than once per
> 	year and hardware replacement usually on approx. a 3 year
> 	cycle, and, this doesn't require hardware changes (although
> 	some are recommended), 10 years gives the IETF 7 years
> 	to argue, code, test, agree, and publish and we still have
> 	plenty of time for the vendors to add it to the featureset
> 	and roll it out to end users.  I agree that expecting IETF
> 	to agree on anything in 7 years may be a bit optimistic,
> 	but, I think it can be done.
>
> Finally, we need PI space for end sites/users/organizations/whetever term
> you prefer precisely because IPv6 did not solve multihoming.  The lack
> of a multihoming solution in IPv6 makes it a non-starter for most
> organizations.  Lack of PI space will have a similar effect for other
> reasons besides multhoming.  Renumbering a /48 can be prohibitively
> painful and costly, especially when it involves ACLs and pointers
> that are maintained in foreign authority zones (customers VPN ACLs,
> etc.).  Locking businesses into a particular provider just because
> we're too lazy to fix the protocol is no longer an option.
>
> Owen
>
> Owen
>
>
> --On February 9, 2006 9:33:44 AM -0500 Glenn Wiltse <iggy at merit.edu> wrote:
>
>>    I wasn't nessasarly endorsing any 'host count' as being the
>> defining factor. However I do think the main point of contention
>> is how exactly to determin some size threshold nessasary, and what
>> to use as a unit of meassure. That's why I personaly like
>> the idea of using unique street addresss.
>>
>>    One thing I don't like, and I think many others don't like, is the
>> idea  that ARIN would hand out many /48s simply because some orginzations
>> felt  they had to have PI space and/or they are currently multi homed.
>>
>>    Maybe later, after some of the biggest end originzations have gotten
>> PI  space, and we know where we stand in terms of demand and/or needs, we
>> could possibly later relax the size limits and/or then start to give out
>> smaller block, etc...
>> 
>> Glenn Wiltse
>> 
>> On Thu, 9 Feb 2006, Dan Golding wrote:
>> 
>>> On 2/9/06 8:28 AM, "Glenn Wiltse" <iggy at merit.edu> wrote:
>>>
>>>>     In general, I like the direction Thomas is  heading in... (giving
>>>> PI to the largest sites and trying not to give out small blocks simply
>>>> because someone says they need multi homing, etc...)
>>>> 
>>>> I would change refferances to 'end site', in favor of the term 'end
>>>> orginization' (which would imply these cant' be re-assigned to other
>>>> orginizations, but little else implyed in the meaning)
>>>>
>>>>    In my mind, the only real sticky point is in deciding what exactly
>>>> defines a originization as being 'large' enough to get a PI assignment.
>>>> 
>>>> I do think that a /40 is about the smallest sized block that I would
>>>> like to see given out as IPv6 PI space at this time. Just how you
>>>> define who is large enough to justify such a assignment I do not know.
>>>>
>>>>   I personaly would rather see unique street addresses be considered
>>>> as justification for space, more so then number of employees... but
>>>> perhaps either or... or some combination of both, etc...
>>>>
>>>>    Anyway, I do really think Thomas is on the right track with his
>>>> most recent comments and/or proposal.
>>>> 
>>>> Glenn Wiltse
>>> 
>>> This is a dead end. The last 2005-1 was defeated at the last ARIN meeting
>>> specifically because of the 100k host requirement.
>>> 
>>> - Daniel Golding
>>> 
>>> 
>>> 
>>> 
>>> !DSPAM:43eb4f0186132993215505!
>>> 
>>> 
>> _______________________________________________
>> PPML mailing list
>> PPML at arin.net
>> http://lists.arin.net/mailman/listinfo/ppml
>
>
>
> -- 
> If this message was not signed with gpg key 0FE2AA3D, it's probably
> a forgery.
>