[arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition

Mark Andrews marka at isc.org
Tue Feb 8 21:44:31 EST 2011

In message <4D51FA04.8080401 at brightok.net>, Jack Bates writes:
> On 2/8/2011 7:46 PM, Lee Howard wrote:
> > Jason tried to refocus the thread.
> > Forget the past fifteen years.  It is past.
> >
> > John, Tony, you are saying, "There is no way to avoid extensive deployment 
> of
> > large-scale NAT44 in ISP networks"?
> >
> > I have a hard time accepting that, since nobody wants it.  It runs contrary
>  to
> > everyone's interest.  It is a temporary solution at best, so companies have
>  to
> > deal with both LSN and IPv6, instead of just IPv6.  Is everyone really resi
> gned
> > to this?
> There are already very large mobile networks (and I'm sure wireline) 
> that already deploy LSN. If they hadn't, anyone want to guess how much 
> sooner we'd have run out? LSN deployment is already past tense. It just 
> hasn't hit critical deployment yet.
> But since LSN breaks 6to4 direct communications, let me subject you all 
> to complete evil (because it was a fun thought exercise).
> DNS recursive servers relabel all 2002:: responses as ULA  /16 (random 
> 8bit). This forces the client 6to4 to send the packets to the anycast 
> relay (you have 1 internal to each LSN area), the inbound 6to4 does 
> NPTv6 to convert the source 2002:: to your prefix and passes the packet 
> towards the public 6to4 relay (sits outside the LSN for talking to 
> remote 2002:: networks). The ULA /16 is converted back to 2002::/16 via 
> NPTv6 destined outbound.
> so....
> AAAA  2002: becomes fd8f:
> client sends 2002: to 6to4 anycast to reach fd8f:
> internal 6to4 anycast relay converts it to 2600:0000:0202:: trying to 
> reach 2002: (nat source and destination appropriately)
> It routes to your public anycast relay and on to the destination. Coming 
> back, it will have to find a remote relay and come back IPv6 to reach 
> your internal relay, where it passes back through NAT to change the 
> source and destination again.
> ULA was chosen for remotes as it's possible to use a /16 to handle a 1:1 
> for the entire Internet. That's not necessary on the inside LSN 
> addressing as we know the addressing ourselves and can hard code 
> appropriately.
> Jack (finding new ways to have broken 6to4 in broken IPv4 LSN environments)

Is it worth trying to deploy RFC 5969?  That would be cleaner.

> _______________________________________________
> You are receiving this message because you are subscribed to
> the ARIN Public Policy Mailing List (ARIN-PPML at arin.net).
> Unsubscribe or manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/arin-ppml
> Please contact info at arin.net if you experience any issues.
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: marka at isc.org

More information about the ARIN-PPML mailing list