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

[William Herrin]

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.


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

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.


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

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.


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

Regards,
Bill Herrin




-- 
William D. Herrin ................ herrin at dirtside.com  bill at herrin.us
3005 Crane Dr. ...................... Web: <http://bill.herrin.us/>
Falls Church, VA 22042-3004