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

[Mark Andrews]

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:1.1.1.1:: becomes fd8f:1.1.1.1::
> 
> client sends 2002:2.2.2.2:: to 6to4 anycast to reach fd8f:1.1.1.1::
> 
> internal 6to4 anycast relay converts it to 2600:0000:0202:: trying to 
> reach 2002:1.1.1.1:: (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.

> _______________________________________________
> PPML
> 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