[ppml] Soliciting comments: IPv4 to IPv6 fast migration

[William Herrin]

On 7/25/07, Owen DeLong <owen at delong.com> wrote:
> 1.      It is very unnecessarily complex.

Hi Owen,

It is complex. I'm open to constuctive suggestions on how to reduce
that complexity.


> 2.      Do you really think that the required 6to4 functionality can be
>         widely enough deployed in less than 4 months?

A minimalist implementation involves removing what little filtering of
2002:: prefixes exists from routers used by some 800 organizations. I
believe it could be accomplished in 4 weeks, let alone 4 months. All
the same, this is a fair question for the network operators. I'll
refer it to the folks on nanog when I ask them.

Beyond the minimalist implementation, orgs are free to filter and
encapsulate or not, whatever meets their local goals. As no avalanche
of 6to4 users will suddenly appear on 1/1/2008, they have ample time
to choose, plan, test and implement.


> 3.      This would make the 6to4 address range a permanent encampment
>         of legacy v4 holders and preserve all of the issues related to the
>         swamp.

The first issue with the swamp is the scattered, discontiguous blocks.
This proposal addresses that issue by permitting each org only one
block.

The second issue with the swamp is ARIN's ambiguous authority to do
anything about it like asking folks to renumber. This proposal
addresses that issue by requiring the blocks to fall under the RSA.

This proposal does create a permanent encampment of v4 holders. But
they're not legacy holders: they'll all have signed an RSA, subjecting
themselves to then-current IPv4 and IPv6 policies moving forward.


> 4.      This proposal (and 6to4 in general) appear to ignore what happens
>         when sites have IPv4 addresses, native IPv6 connectivity, but, no
>         longer have native IPv4 connectivity.

Phase 3 of the proposal entitled "Native phase: Following the decline
of IPv4," addresses your question.

6to4 does not address the question because absent a policy like this
one the question is moot.

A more general sketch of what happens is this: the backbones drop
native IPv4 and start tunnelling it before the end-user sites do. The
end user with 6to4 space certainly isn't going to drop IPv4
connectivity. As the beckbones drop IPv4, they start routing 2002::
natively as required in the updated RFC. As a result, a steadily lower
percentage of the incoming v6 traffic at the end-user site is
encapsulated. By the time any of this becomes more than a mild
annoyance, ARIN makes its periodic assessment (last item in phase 2)
and announces the move to phase 3 in which folks are asked to
propagate the 2002:: routes so that normal routing takes precendence
over the 2002::/16 route to the encapsulator while those who are not
part of the IPv6 DFZ are asked to remove any 6to4 encapsulators.

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