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

Fri Jun 29 10:02:20 EDT 2007

I'm a frequent user of 6to4, every time I don't have native connectivity and
I've a public IPv4 address. Some times it even works with a private IPv4
address if the NAT box is able to do "proto-41-forwarding" (for more info
about this look at 
http://www.euro6ix.org/documentation/euro6ix_co_upm-consulintel_wp4_ipv6_tun
nels_nat_v1_6.pdf and
http://www.consulintel.euro6ix.org/ietf/draft-palet-v6ops-proto41-nat-03.txt
).

So definitively it is not broken, and the number of 6to4 relays keeps
increasing.

In fact, I've started a thread at the afripv6-discuss mailing list in order
to help to setup 6to4 relay, which become even more important there where
the bandwidth is more expensive, because it avoids traffic going thru
upstream links. The first message on this is here:
https://lists.afrinic.net/pipermail/afripv6-discuss/2007/000061.html

More information about 6to4 also available at:
http://www.ipv6tf.org/index.php?page=using/connectivity/6to4

Regards,
Jordi

> De: Scott Leibrand <sleibrand at internap.com>
> Responder a: <ppml-bounces at arin.net>
> Fecha: Thu, 28 Jun 2007 17:34:37 -0700
> Para: John Paul Morrison <jmorrison at bogomips.com>
> CC: <ppml at arin.net>, William Herrin <arin-contact at dirtside.com>
> Asunto: Re: [ppml] Solicing comments: IPv4 to IPv6 Migration Incentive Address
> Space
> 
> 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
>>   
> _______________________________________________
> 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

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.