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

[Owen DeLong]

> 
> 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.
> 
> My reasons are:
> 
> First, 2010-9 as written more or less guarantees an IPv6 /28 to ALL
> CURRENT IPv4 REGISTRANTS:
> 
> "If you have IPv4 addresses then you automatically qualify for IPv6
> space for 6rd. [...] A /28 allows the operator to delegate prefixes
> shorter than /64, allowing multiple /64 subnets within the home."
> 
You say that like it's somehow a bad thing.

In the first /12 per region, there's more than enough space to give every
single active ASN two /28s. Even if the uptake on this proposal was
100% and every ASN currently in the global table (world wide) took one
from ARIN, it would only consume 1/2 of that first /12.

I'm simply not seeing a problem with using /28s this way?

> Second, the proposal needs major wordsmithing. The language is too
> opaque, making it difficult to tease out how ARIN is supposed to
> evaluate IPv6 applications justified by an intent to use 6rd. It
> should be rewritten with phrases like "ARIN shall," using far fewer
> words per paragraph and with the addition of short headings for
> clarity.
> 
I can't disagree with this, and, I would support future policy to improve
the situation. However, I think the language here is adequate to at least
start meeting the needs of providers that want to deploy 6rd and I think
it is more important that ARIN not pose an impediment to this process,
especially between now and IANA depletion than to have ideal
wording.

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

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.

> 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? As I stated, this would still constitute such a
small consumption of address space that I just don't see the benefit
to making it  an issue.


Owen