[arin-ppml] Opposed to 2010-9 and 2010-12

[Owen DeLong]

On Oct 8, 2010, at 11:32 AM, Joel Jaeggli wrote:

> On 10/7/10 3:50 PM, Owen DeLong wrote:
>> On Oct 7, 2010, at 12:45 PM, Christopher Morrow wrote:
>>>> 1.      If it becomes a permanent deployment, it will seriously degrade end user
>>>>       capabilities and stifle innovation and place unnecessary limits on future
>>> 
>>> more than not having ipv6 will? more than nat/nat/nat will? I'm not a
>>> particularly large fan of 6rd either, but... it does give the
>>> capability to get v6 to end users (in a decent quality) and today.
>>> 
>> Less than those, but, more than native IPv6.
> 
> in either the native case or the 6rd case you're jacking up the cpe so
> the difference is in the access network.
> 
I'm not sure I understand that statement. With 6rd, it's utterly impractical to give
out large enough blocks for end users to get /48s. We're stuck with giving out
huge blocks (/24s) just to enable end customers to get /56s. That's horrible,
but, livable on a temporary basis.

With native, a /32 will support 65,500+ /48 customers and you should be able
to get more if you need. Unless you're one of the 5 or so largest ISPs in the
world, you should be able to get by with a /20 or less. Most ISPs other than
the smallest of the small probably should get /28s.

(Yes, I realize current policy is defective in this regard and I am working on
a proposal to correct that).

>>> Talking to Mark some, and Lorenzo, and looked at ietf work ongoing to
>>> bring operations tools/capabilities they need to deploy v6 in a
>>> congruent manner as v4.... waiting for this will take quite a long
>>> while (2-3 years at best for the standards work to finish, never mind
>>> implementations).
>>> 
>> Hence my suggestion that we provide for 6rd, but, require that it be
>> something we can deprecate later.
>> 
>>> To be clear, I'd support neither -9 nor -12, but a fix for -12 that
>>> removed all of the 'transition technology' wording and focused on
>>> 'subsequent allocation' alone.
>>> 
>> Yeah, I can't support that without safeguards to make sure that we
>> can deprecate 6rd.
> 
> if something gets cooked into the network for perhaps a decade it's not
> coming out easily. the ability to deprecate it is tied either to it's
> nature as a short-term bandaid, which I'm not sure I buy or it's failure
> in the marketplace. I see no reason to presuppose the latter.
> 
The ability to deprecate it is tied to having it in a prefix that providers who
agree it should be deprecated can start filtering later. If it stops working
for a large enough portion of the network, then, it gets deprecated.
If it doesn't, then, it remains permanent.

Sure, having it in a separate prefix doesn't guarantee deprecation, but,
failing to put it in a separate prefix guarantees deprecation is impossible.

Owen