[ppml] Proposed Policy: PI assignments for V6

[Owen DeLong]

>>> 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 did, but, many other organizations did not.  It basically depended on when
you got into v4 as to whether you could or not.  This is starting to become
more reasonable again in v4 (2002-3, 2003-15).  However, in v6, it is still
problematic.  As such, the current policy proposal is an attempt to bring
similar sanity and capabilities to the v6 addressing policy.

>>> 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.
>
Then we can agree to disagree here.  Unfortunately, you may be right, 
afterall,
lots of enterprises have accepted an Operating system so thoroughly insecure
that CPU manufacturers are now advertising on-chip virus protection as if
it were a feature.

>>  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.
>
I guess that depends on your definition of work.  As near as I could tell,
for any of the flow survivability features to work, it required 
implementation
at both ends.

>>>> 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.
>
I didn't argue they couldn't be traced.  I argued that it would be difficult
to impossible to identify ownership on non-registered ULA.  I argued that
registered ULA would be de facto PI.  I stand by both of these statements.
I believe if there were community consensus around reclaiming v6 PI
allocations under this policy, it could easily be done.  Perhaps not as
quickly as you would like, but, it can be done.

>> 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.
>
Agreed... Nothing in my proposal claims otherwise or attempts to address 
this
in any way.  Orgs that are concerned about ISPs filtering more aggressively
than the RIR MAU are welcome to use PA space and accept all the headaches
that implies.  Orgs that are less concerned should be able to use this
policy to get PI space.  It's all about giving the Org the choice about
what best meets their need.

Owen

-- 
If it wasn't crypto-signed, it probably didn't come from me.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20041214/417c37ed/attachment.sig>