[arin-ppml] is NAT an inevitabile part of IPv4 / IPv6 transition
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
> > large-scale NAT44 in ISP networks"?
> > I have a hard time accepting that, since nobody wants it. It runs contrary
> > everyone's interest. It is a temporary solution at best, so companies have
> > deal with both LSN and IPv6, instead of just IPv6. Is everyone really resi
> > 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.
> AAAA 2002:184.108.40.206:: becomes fd8f:220.127.116.11::
> client sends 2002:18.104.22.168:: to 6to4 anycast to reach fd8f:22.214.171.124::
> internal 6to4 anycast relay converts it to 2600:0000:0202:: trying to
> reach 2002:126.96.36.199:: (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
> 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:
> 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