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

[Scott Leibrand]

John and William,

I don't have a lot of experience with it myself, but I recall reading 
awhile back that a lot of the 2002::/16 "default" routes on the IPv6 
Internet today are broken in one way or another, such than 6to4 service 
is quite unreliable.  Perhaps others on the list can elaborate on that...

-Scott


John Paul Morrison wrote:
> 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
>>
>>     
>
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> (PPML at arin.net).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
>