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

[William Herrin]

On Fri, Sep 24, 2010 at 11:59 AM, ARIN <info at arin.net> wrote:
> Draft Policy 2010-9
> IPv6 for 6rd
>
> Version/Date: 24 September 2010
>
> Policy statement:
>
> 6rd is an incremental method for Service Providers to deploy IPv6,
> defined in the IETF Standards Track RFC 5969. If you have IPv4 addresses
> then you automatically qualify for IPv6 space for 6rd.  Upon receipt of
> a 6rd request, an appropriate  additional IPv6 allocation will be made
> that supports 6rd to be counted as a separate & parallel deployment to
> IPv4 and native IPv6. There is no requirement to segregate address space
> requested under this policy from regular IPv6 Allocation Supernets.
> From a management perspective  this address space is to be treated as
> regular IPv6 address space.
>
> While it is possible for an operator to transition to native IPv6 within
> the same address space used by 6rd, some operators may wish to keep
> native IPv6 users separate from 6rd users to permit optimization of
> aggregation. If an operator chooses to renumber users to an address
> space outside the 6rd aggregate when transitioning them to native IPv6,
> the 6rd allocation may be returned to ARIN when it is no longer in use.
> It is suggested that contiguous allocations be made to any prior
> existing ones in the event justification for more IPv6 address space
> exists when the organization transitions 6rd out of their network.
>
> Justification for use of IPv6 for 6rd will be reviewed after the first 3
> years and reclaimed if it is not in use. After the first 3 years, any
> additional reviews will follow regular IPv6 policy. Requester will be
> exempt from returning all or a portion of the address space when 6rd is
> no longer  used if they can show justification for need of the 6rd
> address space for other existing IPv6 addressing requirements be it
> native IPv6 or some other IPv6 network technology.


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

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.

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.

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.

Finally, noting 6rd's use of the 6to4 protocol and addresses announced
via BGP, I want to take a moment to say, "I told you so:"
http://lists.arin.net/pipermail/arin-ppml/2007-July/007965.html

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