[arin-ppml] I Oppose 2010-9: IPv6 for 6rd as written.

[Owen DeLong]

On Sep 25, 2010, at 1:46 PM, William Herrin wrote:

> On Sat, Sep 25, 2010 at 2:18 PM, Owen DeLong <owen at delong.com> wrote:
>>> After careful consideration, I OPPOSE proposal 2010-9 as written.
>>> Although I agree that 6rd use should justify an IPv6 allocation, I
>>> think this proposal should be deferred until the Spring and thoroughly
>>> rewritten.
>> 
>>> First, 2010-9 as written more or less guarantees an IPv6 /28 to ALL
>>> CURRENT IPv4 REGISTRANTS:
>> 
>> You say that like it's somehow a bad thing.
> 
> Owen,
> 
> It worries me that we've barely started to deploy IPv6 yet we keep
> finding ways to consume fractions of this 128-bit space that are
> noticeable even in the first 32 bits. Looking back with 20/20
> hindsight, early burn noticeable in the first quarter of the bits is
> widely recognized as a bad mistake with IPv4.
> 
Noticeable is, I guess open to interpretation...

In 128 bits, a /28 is much less noticeable than a /8 in IPv4...

I don't think that 0.00000037% is nearly as noticeable as you appear to
think it is.

On the other hand, 0.39% would strike me as a much more noticeable
portion of the address space. (an IPv4 /8).

Put another way, if nobody had more than a /28 of IPv4 space, we probably
wouldn't be anywhere near runout today. However, in IPv4, a /28 is nowhere
near enough space to number even so much as an early adopter's house,
let alone a significant enterprise. In IPv6, however, it's probably enough
to number all but the top 1% of organizations.

> 
>>> Third, the proposal encourages ARIN to allocate /28's in addition to
>>> the ISP's native IPv6 assignment, adding expensive consumption to the
>>> routing table. If the intent is to facilitate 6rd deployments in this
>>> fashion then the policy should explicitly encourage ISPs to accept /27
>>> allocations so that they may employ both 6rd and native IPv6 within a
>>> single contiguous allocation.
>>> 
>> In fact, I would proffer that a single /28 would allow ISPs to do both
>> 6rd _AND_ native IPv6 within the same prefix. No need to expand
>> it to a /27.
> 
> If you accept the premise that it's reasonable to map all 32 bits of
> IPv4 address space into 6rd's dynamic tunnelling and end up with a /60
> hanging off each IPv4 decapsulator then from a purely technical
> viewpoint you CAN'T use native IPv6 and 6rd in the same /28 at the
> same time. Read the RFC. Space usable for native IPv6 has to be
> entirely outside the contiguous prefix you've mapped into 6rd, so if
> you're mapping all 32 bits and delivering a /60, then 6rd consumes the
> whole /28.
> 
I have read the RFC.. However, you don't actually have to map all of
IPv4.. You just need an easy way to map all of the IPv4 that is delegated
to you. If, for example, a provider had 5/8, 10/8, 15/8, and 20/8, there is
no reason they could not be delegated 2000:db80::/28 and use it in the
following manner:

2000:db80:0000::/48 - 2000:db80:4fff::/48 - Native IPv6 assignments
2000:db80:5000::/48 - 2000:db80:5fff::/48 - Mapped 5/8 6rd space
2000:db80:6000::/48 - 2000:db80:9fff::/48 - Native IPv6 assignments
2000:db80:a000::/48 - 2000:db80:afff::/48 - Mapped 10/8 6rd space
2000:db80:b000::/48 - 2000:db80:efff::/48 - Native IPv6 assignments
2000:db80:f000::/48 - 2000:db80:ffff::/48 - Mapped 15/8 6rd space
2000:db81::/48 - 2000:db81:3fff::/48 - Native IPv6 assignments
2000:db81:4000::/48 - 2001:db81:4fff::/48 - Mapped 20/8 6rd space
2001:db81:5000::/48 - 2001:db8f:ffff::/48 - Native IPv6 assignments

Frankly, if it weren't for the routing table implications, the easy way
to do this from an IP policy perspective, would be to allocate a single
IPv6 /28 to 6rd and have all providers simply mirror their IPv4 from
that prefix. This, however, is an obviously bad idea from a routing
perspective since it would create ~300,000 unnecessary IPv6 routes.
Therefore, I think it makes much more sense to allocate a /28 to
each provider, allowing them to fill in the holes in their v4 map with
native IPv6 usage.

> Hence if you also want to do native IPv6 in the same contiguous prefix
> you have to start with a /27 or shorter from which a /28 is dedicated
> to 6rd.
> 
Not so much, no, you don't... See above.

> 
>> It's important that providers that already have partial deployments with
>> IPv6 be able to get an additional /28 for 6rd. I don't think we should be
>> giving providers that get 6rd space additional space beyond that /28.
>> I would support a proposal resolving this at a future meeting, but, again
>> for now, I think this tradeoff is acceptable vs. the cost of blocking 6rd
>> deployment between now and IANA depletion.
> 
> If 6rd deployment was blocked, I might agree with you. It isn't. As
> 6rd is designed, only the lower bits of each of the ISP's IPv4
> allocations need be programmed into 6rd, allowing it to be usefully
> employed within several fractions of the /32 allocation ISPs can
> already easily get.
> 
This is true, except for the providers serving the largest user bases
where mapping the lower bits doesn't actually do the trick.

I think that blocking 6rd for that large a portion of the population
is effectively blocking 6rd in a pretty meaningful way. To put it in
perspective, it's way more noticeable a fraction of total users than,
say 0.00000037%.

> For that matter, if this proposal was less defective I might agree
> with fixing it later. But the policy text is too poorly crafted.
> However interesting the idea, opaque and ambiguous text makes for bad
> policy.
> 
Again, as I said, it's not ideal. Some of it can probably get fixed by the
AC between the meeting and last call. (constructive suggestions for
improvement welcome). However, I still think that the policy is far
too urgent to allow it to languish past IPv4 runout. That, sir, would be
very bad policy.
> 
>>> Fourth, except for the handful of gigantic ISPs managing hundreds of
>>> IPv4 blocks, mapping IPv4 into 32 bits of IPv6 address space is
>>> disgustingly wasteful. By configuring one 6rd handler for each IPv4
>>> allocation held, nearly every ISP can easily employ 6rd within 24 bits
>>> or less. That allows it to fit entirely inside their /32 allocation,
>>> even when attaching the suggested /60 or more even more addresses to
>>> every IPv4 endpoint.
>>> 
>> Really? Who cares? As long as we set it up so that they are expected
>> to fill the "holes" with traditional IPv6 reallocations and reassignments,
>> what is the problem?
> 
> Read the RFC. Native IPv6 use in the defined 6rd block can only
> commence AFTER 6rd use stops. The technology doesn't facilitate
> "filling the holes."
> 
Technically, the only reason I see for this in the RFC is actually the need to
delay usage of those portions that might collide with future IPv4 allocations
or assignments to the organization in question. While the RFC doesn't
spell this out particularly well (speaking of opaque language), it's really
not that hard to use 6rd space in the manner I described above without
breaking either technology.

Additionally, there's enough IPv4 bogon and martian space that
could be used for your early native IPv6 portions that I regard this as largely
unnecessary, especially given the relatively short time frame to IPv4 runout.

Once an organization stops receiving new IPv4 allocations/assignments, there's
really no need to worry about the threat of future collisions.

Owen