[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: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
More information about the ARIN-PPML
mailing list