[ppml] Proposed Policy: PI assignments for V6

[Kurt Erik Lindqvist]

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


On 2004-12-12, at 19.53, Owen DeLong wrote:

>> So the PI proposal will only address the renumbering pain?
>>
> No.  it also addresses transition pain, choose your own destiny rather 
> than
> be at the mercy of an ISP pain, multihoming pain, and, a host of other 
> problems
> that we have been living with to some extent or other in the v4 world.

Well, if you have, why didn't you get PI space in v4?

>> I think people use NAT as an abstraction layer. It's just that they
>> never had to realise it as there was no option.
>>
> There's probably some truth to this.  However, the abstraction layer 
> does
> come at some cost, and, I know of a number of organizations that would 
> really
> rather not use NAT.  They've accepted it in a v4 world because they 
> didn't
> see any alternative.  They will not accept it in a v6 world.

I think they are very few. Extremely few actually.

>  For multi6, not only do I have
> to support its requirements, but, it has to be implemented at virtually
> every site I'm trying to talk to as well.

In order for you to take full advantage - yes. But not for it to work 
in general.

>>> 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".
>>
> That's a tautology.  You're saying you don't want to issue PI space in 
> v6
> because you don't want a swamp, but, you say the only way to believe 
> that
> a swamp can be prevented is to see PI space issued and reclaimed 
> without
> creating a swamp.  So, I will take your statement "Seeing is 
> believing" as
> an endorsement for at least conducting the experiment.

You are arguing that ULAs can't be traced if they are leaked, but that 
we could reclaim PI space. I think you can trace ULAs, I am not as 
convinced we can reclaim PI space. But I really hope I would be wrong 
on that one.

>> 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.
>>
> I think you got those backwards.

I did, sorry.

>>> 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.
>>
> And this counters the above statement how?  Technically, I could run a 
> DFZ
> with two routes if I really wanted to.
> 	0.0.0.0/1	-> ISP
> 	128.0.0.0/1	-> ISP
>
> Heavy filtering indeed.  However, MOST of the real DFZs aren't 
> filtering that
> heavily.  The ones that do probably can't reach a variety of sites on 
> the
> internet or aren't as effectively default free as they think.
>
> Over time, any site which filters more aggressively than the RIR MAU 
> boundary
> will be able to reach fewer and fewer sites.  I don't think this small 
> minority
> of sites justifies preserving a larger boundary.

In v4 they have seen more and more scenic routing, not less 
reachability. My point was that we have no effective control over the 
filtering polices with ISPs. And the larger the ISP, the less 
influence.

- - kurtis -

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

iQA/AwUBQb3s5qarNKXTPFCVEQJyMwCg9f/mJVG00KYAYIu4wEm1Uw/L7eAAoMEO
pel7hbiKLiQY3UBr5BFxMcFN
=1dqJ
-----END PGP SIGNATURE-----