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

[Leo Bicknell]

In a message written on Thu, Jun 28, 2007 at 11:32:21AM -0400, William Herrin wrote:
> 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.

My (limited) understanding of 6to4 is that devices on the IPv6 side
are supposed to treat the addresses as if they were any other IPv6
address, i.e. there is nothing special for an IPv6 host.  It's only
in the device that provides the gateway serivce from IPv6 to IPv4
(the destination of the 2002:: route) that special code is required.

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

Following on to #1, on the IPv6 side the routes are normal routes.  This
allows you to have a single 6to4 gateway and carry 2002:: across your
network to all of your sites/subnets.  I believe the intentionw as to
actually have the (single) route in the DFZ, or at least, each provider
putting its own route in its own network to a 6to4 gateway.

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

Agreed.

> 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?

I would like someone with much more familiariaty with 6to4 to comment.
It might be worth engaging some of the original authors.  Clearly we
don't want to break 6to4 as an option, however it seems to me there may
be a path to sanity here...

-- 
       Leo Bicknell - bicknell at ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/
Read TMBG List - tmbg-list-request at tmbg.org, www.tmbg.org
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 187 bytes
Desc: not available
URL: <https://lists.arin.net/pipermail/arin-ppml/attachments/20070628/a8cc6d10/attachment.sig>