Re: Public DNS64

[Ca By <cb.list6 () gmail com>]

On Monday, May 30, 2016, Ca By <cb.list6 () gmail com> wrote:

> On Monday, May 30, 2016, Baldur Norddahl <baldur.norddahl () gmail com
> <javascript:_e(%7B%7D,'cvml','baldur.norddahl () gmail com');>> wrote:
>
> > > Like HE is doing?
> > >
> > > swmike@uplift:~$ dig +short AAAA ipv4.swm.pp.se @nat64.he.net
> > > 2001:470:64:ffff::d4f7:c88f
> > > swmike@uplift:~$ ping6 2001:470:64:ffff::d4f7:c88f
> > > PING 2001:470:64:ffff::d4f7:c88f(2001:470:64:ffff::d4f7:c88f) 56 data
> > bytes
> > > 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=1 ttl=42 time=316 ms
> > > 64 bytes from 2001:470:64:ffff::d4f7:c88f: icmp_seq=2 ttl=42 time=315 ms
> > >
> > > Now, pinging myself via DNS64/NAT64 service and getting 315ms RTT means
> > > the NAT64 isn't very local to me... :P
> >
> >
> >
> > It goes to the USA and back again. They would need NAT64 servers in every
> > region and then let the DNS64 service decide which one is close to you by
> > encoding the region information in the returned IPv6 address. Such as
> > 2001:470:64:[region number]::/96.
> >
> > An anycast solution would need a distributed NAT64 implementation, such
> > that the NAT64 servers could somehow synchronize state. A more simple
> > solution is just to have the DNS64 be anycast and have a DNS64 at each
> > NAT64 location with the DNS64 returning pointers to the local NAT64.
> >
> > Now, can we have a public MAP server? That might scale. The geo blockers
> > will hate it. What is not to like?
> MAP scale. I know folks think it is theoretically nice but....
>
>
> Just curious, has anyone yet deployed MAP at scale? I know of several
> production and large scale nat64s (usually mobile 464xlat related), and a
> few large ds-lite, but never MAP in production at scale.  Maybe i am
> missing something.
>
> CB
Tore's email reminded me that we got  no answers about a production large
scale MAP deployment.  I guess it is yet to be deployed.

Since it came up 2x in this thread, not only is MAP apparently not deployed
anywhere at scale and therefore unproven in the real world, it would not
fit this public usecase. MAP requires dhcpv6 and that dhcpv6 server must
statefully / tight-coordination assign the addresses and ports to the end
user.  This complexity and requirement, along with the unsavoriness of yet
another tunnel made MAP a deal breaker for my network. It also statically
assigns s fixed number of scarce ipv4 ports to users, this is inefficient
and not flexible.

I suppose some party could launch a public dhpv6 server. But the 2nd hop
routing would not work without several hacks

CB


> Regards,
> > Baldur