[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.


> 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.

> 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.
>
No... We're saying that even _IF_ it were the best way to go, of which we
aren't convinced because there is no operational experience and not enough
data to make that judgment, it's at least several years away and requires
dependent implementation at both sides in order to work.  I can deploy PI
space on my side and it works generally.  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.

>> 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.

>> That model is infeasible today for a variety of human and technical
>> reasons.
>
> No, it's just that noone want's to be first.
>
No. That's one of a variety of reasons.  It's a human one.

>> 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.
>
I think you got those backwards.  VOIP is unlikely to usefully survive
convergence time in some cases (note, with BFD and fast convergence
available in some circumstances, BGP convergence is not as slow as you
think for most failures and I have seen VOIP usefully survive.).  SSH
will almost always usefully survive.  I think that the capabilities of
BFD and fast convergence will be incrementally improved over time, making
PI space more useful in this regard.  History so far has shown that I am
correct.

>> 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.

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/20041212/5918a3bf/attachment.sig>