[arin-ppml] v4 to v6 obstacles

[Lee Howard]

----- Original Message ----
> From: Joe Maimon <jmaimon at chl.com>
> To: RudOlph Daniel <rudi.daniel at gmail.com>
> Cc: arin-ppml at arin.net
> Sent: Tue, October 27, 2009 7:15:33 AM
> Subject: Re: [arin-ppml] v4 to v6 obstacles
> 
> 
> 
> RudOlph Daniel wrote:
> > Hi Roger
> > Your suggestion is that NAT-PT is not going to be a worker, which was also the 
> suggestion of RFC4966. So what alternatives do we have for 100% v6 access to v4 
> and how can we live with less than 100% if the solution is as you suggest not 
> yet available?
> > 
> I was under the impression that complaints about ipv6-ipv4 interoperability 
> generally refer to the idealogical reasons that did their best to sink nat-pt, 
> even while grudgingly acknowledging
> 
> "
>    However, it is clear that in some circumstances an IPv6-IPv4 protocol
>    translation solution may be a useful transitional solution,
> "
> 
> Due to this style of idealogical design, the best that seems to be standardized 
> now is dual stack with rfc1918 and nat on the ipv4 side.
> 
> We now have a plethora of obsoleted, standardized, non standardized and not yet 
> standardized interoperability schemes, which is kind of irritating this late in 
> the game.
> 
> NAT arrived late to IPv4 and it appears to be arriving late to IPv6 as well.

Different issues.  I don't see a need for NAT66.  But Address Family Translation
(AFT, or NAT46 and NAT64) would be useful.
NAPT-PT, being deprecated, is poorly supported.  Seems like people are holding
their breath for NAT64, and maybe someday somebody will submit a draft for 
NAT46.  Which is too late to get gear fielded.  And doesn't solve most of the
issues identified in RFC4966.

Is it possible to "reprecrate" something that has been deprecated?  Can we 
obsolete RFC4966?  Anyone have a pointer to the right list for that?

Lee