DNS64 & nslookup
booloo at ucsc.edu
Thu Apr 12 16:22:02 UTC 2018
I know this is the wrong list for this
discussion, but I wanted to reply on
general principles. I lurk on the v6ops
list so know you think about this stuff
> Secondly, I would look at other mechanisms than DNS64/NAT64 to provide
> IPv4 as-a-service. It really has a lot of issues which the other
> mechanisms don’t.
As near as I can tell, the primary issues that one
needs to contend with relate to embedded IPv4
literals, a few problematic apps (e.g. FTP), and
apps built with APIs that lack support for IPv6.
In our environment, we also have to deal with the
odd assorted devices that lack IPv6 support altogether
as well. The theory is that we can run 464XLAT
in order to provide a bump-in-the-wire CLAT to
help with these cases. It does mean we still have
to hand out IPv4 addresses, but we don't have to
route any of the v4 traffic on our backbone by
virtue of placing the CLAT box on the same
subnet as the hosts.
We've been running a DNS64/NAT64 without CLAT
net for a while without much trouble, but with a pretty
limited clientele. The CLAT piece comes soon, and
access will expand. If you really think this is asking
for trouble, I'd be interested in anything you can tell
me about said trouble.
> Thirdly, I wouldn’t rush to running IPv6-only. It does have its
> but they come with serious drawbacks. At this stage IPv6-only is still
> niche only.
IPv6-only offers some operational benefit - you are
moving in the direction of supporting one protocol, reducing
complexity, and security is simpler. We could run dual-stack,
but it does nothing to relieve the pressure on our IPv4 space.
Considering the aforementioned strategy, if you think serious
drawbacks are inevitable, I'm all ears. I do have to be able
to support this as a production service - and I'm still trying to
convince myself that's possible.
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the bind-users