[ppml] Proposed Policy: PI assignments for V6

Kurt Erik Lindqvist kurtis at kurtis.pp.se
Fri Dec 10 09:53:50 EST 2004


-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


On 2004-12-09, at 01.15, Stephen Sprunk wrote:

> No, but having PI space makes the process less painful.  Only the 
> border routers need to be updated, and it can be done as quickly as 
> BGP convergence can be completed (twice).
>
> A PA site would add a second PA prefix to all of their routers/hosts, 
> wait a few days, switch all the addresses in DNS, wait another few 
> days, then remove the first PA prefix.  This kills any active 
> connections during the last step, but that's arguably minor.  
> Depending on the number of routers/hosts, this does require extensive 
> effort on the admins' part.

So the PI proposal will only address the renumbering pain?

>> Do we? How much of these problems are really just covered up with 
>> NAT? And how many enterprises that you argue would like your 
>> PI+multihoming capability would much rather that their NAT boxes 
>> worked with v6 so they didn't have to learn about that comples 
>> routing stuff?
>
> It's not the "comples [sic] routing stuff" that sites are avoiding -- 
> it's the renumbering of routers/hosts.  Some also consider NAT to be a 
> security feature because individual hosts or general topology can't be 
> determined if there's a single IP visible externally; there is a 
> strong belief that security by obscurity is necessary even if the 
> people involved _know_ that it doesn't provide real security.

I think people use NAT as an abstraction layer. It's just that they 
never had to realise it as there was no option.

>> Marcelo already pointed this out but I think you really ought to 
>> catch up with the work in multi6.
>
> Consensus is that multi6's proposals are not viable today nor will 
> they be in the near future.  The possibility of progress a decade from 
> now should not hold up people trying to deploy real networks today.

So you are saying that the proposal out of multi6 really would be the 
best way to go, but as someone somewhere has reached consensus that 
this will take 10 years to deploy we are going to do PI space anyway? 
What interests me is that I haven't actually seen anyone discuss the 
multi6 proposals, I've just seen people saying that they haven't 
studied it.

>> I have no problem with the v4 swamp that is not advertised and no 
>> longer in use. I have a problem with the v4 swamp that IS advertised 
>> and IS being used....
>
> This is also a considerable portion of the v4 swamp that is being used 
> but not advertised globally.
>
> However, none of that is relevant to the proposal at hand, since ARIN 
> can revoke or reclaim any IPv6 assignments in the future if necessary.

"Seeing is believing".

>>> I don't think your proposed solution is better for the community or 
>>> for
>>> any of the individuals it claims to serve.  I think it is an inferior
>>> solution that does not provide important elements that are available
>>> with PI space.  It's only better for the ISPs.
>>
>> I think PI for v6 is fine coupled with smd's old suggestion of 
>> transit providers charging per announced prefix. That is AFAIk the 
>> only model with give away PI that works. And PI+ASN = give away PI 
>> today.
>
> That model is infeasible today for a variety of human and technical 
> reasons.

No, it's just that noone want's to be first.


>> That said. There are a few things I think is being forgotten in this 
>> discussion, and I really, really didn't want to point this out, but I 
>> guess I have to. PI space have the property that you can take it with 
>> you when you change providers, and really only solves renumbering. It 
>> does not give you anything wrt provider independence you do not 
>> already have. Why? Because you can today already either get multiple 
>> PAs, which won't help the problem with surviving TCP flows, but 
>> honestly, PI won't help you with that either.
>
> Please explain how connections using PI addresses do not survive when 
> a site's link to the respective provider goes down, either 
> intentionally or otherwise.

It will depend on the TCP session being fault tolerant for a BGP 
timeout+BGP convergence. A VoIP session most likely will be useful. A 
SSH might not. Survive and being useful are two very different things. 
YMMV.

> If there is a PI block with a minimum assignment/allocation of /48, 
> then presumably providers will relax their filters for that block.  
> This has been the case when RIRs have changed allocation policies for 
> IPv4.  There is strong historical record to show that most will NOT 
> accept a route longer than the minimum allocation size in a particular 
> block.

I know people that have 80k routes less in their DFZ that most people 
do. Filtering vary a lot.

- - kurtis -

-----BEGIN PGP SIGNATURE-----
Version: PGP 8.1

iQA/AwUBQbm4g6arNKXTPFCVEQIRGQCg0Mk93FQdjXsok+dwnGjXCICFavUAoOei
XiYdUbudKUSxfYbJ77dY1K2k
=I4R7
-----END PGP SIGNATURE-----




More information about the ARIN-PPML mailing list