[ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address Space

[John Paul Morrison]

There are some valid concerns, and I think it would be good to discuss 
them, since they can be fixed.

Quickly: 

1. RFC 3056 describes three things: an IPv6 allocation (2002::/16), an 
IPv4 protocol for tunneling, and specifies some things for routing 
2002:: on the IPv6 Internet.
This is a lot, and while the first two items are simple, the merits of 
the last point could certainly be discussed.

2. 6to4 tunelling describes an IPv4 protocol, not an IPv6 one. It's used 
for IPv6 to traverse IPv4 networks. Only the 6to4 gateway needs to 
understand
how to encapsulate/de-encapsulate the traffic. Any IPv6 stack should 
work with a 2002: 6to4 address

3. I agree that there are some limitations like DNS delegation, whether 
it's permanent, 6to4 prefixes on the native IPv6 Internet.
These last points are not built into IPv6 and are a matter of policy or 
current practice. It would be worthwhile to address in terms of policy 
or revising the RFC.

More detailed verbiage:

I emailed the RFC author's and a big concern was "importing the IPv4 
swamp" into the IPv6 routing tables. It's a nice idea, but I'm not sure 
it's the best place to mandate this.
Since ISPs typically filter IPv4 prefixes longer than /24, it doesn't 
seem necessary to stipulate this at all in the RFC. The equivalent would 
be to filter on /40 prefixes for routes imported via 6to4. The only real 
caveat is that 2002::/16 (and only that one) is a kind of default route 
(it's really the IPv4 0.0.0.0 route) - so that prefix needs special 
treatment.
Somehow I don't think the IPv4 swamp is going to evaporate - maybe IPv6 
with PA addresses will do a great job of cleaning up the routing tables, 
but I think that's expecting a lot. If everyone goes out and gets new PI 
address space for v6, then you may just end doubling  the routing table 
size.

It seems like a fairly straightforward transition to IPv6 on the 
Internet backbone by running a single IPv6 routing table, with the 
existing IPv4 prefixes simply
being imported/converted to IPv6 prefixes by prepending 2002::




William Herrin wrote:
> On 6/27/07, John Paul Morrison <jmorrison at bogomips.com> wrote:
>> I do not support this proposal as it essentially duplicates the IPv6
>> address space already allocated to IPv4 users, documented in RFC 3056
>> (6to4).
>
> John,
>
>  First, thank you for privately discussing 6to4's functionality with
> me. You were very helpful and informative.
>
>  You are not alone in suggesting that 6to4 might suitably replace the
> Migration Incentive Space proposal, however 6to4 has several issues
> which would need to be addressed before it could be considered a valid
> alternative. I'd like to find if there is a consensus on ppml as to
> whether those issues should be addressed in 6to4. If they should, I'll
> start working on such a proposal with the intent that it replace the
> Migration Incentive Space proposal. If they should not, then I would
> ask that 6to4 be considered irrelevant to and dropped from the
> discussion.
>
> 6to4 Problem #1: Implementation of 6to4 is an optional component of
> the IPv6 protocol. Devices confronted with a 2002:: address may but
> need not recognize that packets to such a destination should be
> encapsulated in an IPv4 packet. The Migration Incentive Space proposal
> is intended to rely on only those components of IPv6 which are
> mandatory.
>
> 6to4 Problem #2: Its unclear whether the authors of RFC 3056 intended
> that it be possilble for prefixes within 2002:: to be announced into
> the global IPv6 BGP table so that all native IPv6 networks could reach
> such hosts without IPv4 encapsulation. Indeed, some parts of the
> document suggest that an available IPv6 route should NOT take priority
> over encapsulation. For 6to4 to reasonably replace the Migration
> Incentive Space, it would need to be clarified that ARIN encourages
> IPv4 holders to announce an appropriately selected 2002:: route, that
> remote IPv6 systems should give native IPv6 routes to 2002::
> destinations priorirty over the encalsulated IPv4 route, and that ARIN
> intends such blocks within 2002:: to have the same validity as any
> other IPv6 block they assign or allocate.
>
> 6to4 Problem #3: Its unclear whether the authors of RFC 3056 intended
> that prefixes within 2002:: continue to exist in IPv4's
> post-exhaustion phase when IPv6 has become the dominant protocol. The
> Migration Incentive Space is intended to be a permanant solution whose
> addresses continue to see use after IPv4's end of life.
>
> 6to4 Problem #4: ARIN does not control the reverse DNS for 6to4
> prefixes associated with the IPv4 blocks which ARIN manages. It is
> presently managed by the NRO, an organization in which ARIN
> participates (see https://6to4.nro.net/). The documentation for 6to4
> reverse dns states that, "This password is not mandatory when the site
> is accessed from inside your 6to4 source address. It is intended to
> prevent an arbitrary access from locking out the domain if the address
> is not static. (It is recognized that this places far less trust than
> normal in the correctness of a 6to4 delegation)." For 6to4 to work as
> a replacement for the Migration Incentive Space, reverse DNS for the
> blocks under ARIN's authority would need to be operated with a degree
> of security and access comperable to what ARIN applies to its normal
> delegation of reverse DNS.
>
> So, the question I put to you and to the others who have suggested
> 6to4 is this: Do we seek changes and clarifications to address these
> four problems or do we drop 6to4 from consideration as an alternative
> to the Migration Incentive Space proposal?
>
> Regards,
> Bill Herrin
>