Apparently GoDaddy does not support v6 glue for their customers, who does? I don't think requiring dual-stack v6 users perform v4 queries to find AAAA records is all that great.
Any input would be helpful,
-Barrett
If you deploy dual-stack, it is much easier to keep doing the DNS queries
using IPv4 transport, and there is not any practical advantage in doing so
with IPv6 transport.
Of course, is nice to have IPv6 support in as many DNS infrastructure pieces
as possible, and a good signal to the market. Many TLDs already do, and the
root servers are moving also in that direction. Hopefully then the rest of
the folks involved in DNS move on.
Regards,
Jordi
Barrett Lyon wrote:
Apparently GoDaddy does not support v6 glue for their customers, who
does? I don't think requiring dual-stack v6 users perform v4 queries to
find AAAA records is all that great.
At least eNom does.
There are a few others but it tends to be that you have to raise a
support ticket to actually get the records in, most webinterfaces don't
support it yet unfortunately.
One note here is that even though you can get glue into com/net/org
using this method, there is no IPv6 glue for the root yet, as such even
if you manage to get the IPv6 glue in, it won't accomplish much (except
sending all IPv6 capable resolvers over IPv6 transport 
as all
resolvers will still require IPv4 to reach the root. One can of course
create their own root hint zone and force bind, or other dns server, to
not fetch the hints from the real root, but that doesn't help for the
rest of the planet. (Root alternatives like orsn could fix that up but
apparently their main german box that was doing IPv6 is out of the air)
Note also that various ccTLD's are able to add glue to your zone on
request (notably .fr/.ch/.nl/.se do so already for quite some time)
Greets,
Jeroen
If you deploy dual-stack, it is much easier to keep doing the DNS queries
using IPv4 transport, and there is not any practical advantage in doing so
with IPv6 transport.
Thanks Jordi, not to sound too brash but, I'm already doing so. I am trying not to deploy a hacked v6 service which requires an incumbent legacy protocol to work.
Of course, is nice to have IPv6 support in as many DNS infrastructure pieces
as possible, and a good signal to the market. Many TLDs already do, and the
root servers are moving also in that direction. Hopefully then the rest of
the folks involved in DNS move on.
I would like to support v6 so a native v6 only user can still communicate with my network, dns and all, apparently in practice that is not easy to do, which is somewhat ironic given all of the v6 push lately. It also seems like the roots are not even fully supporting this properly?
-Barrett
One note here is that even though you can get glue into com/net/org
using this method, there is no IPv6 glue for the root yet, as such even
if you manage to get the IPv6 glue in, it won't accomplish much (except
sending all IPv6 capable resolvers over IPv6 transport
Unless I did this query wrong, you are absolutely right:
;. IN NS
A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4
B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201
C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12
D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90
E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10
F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241
G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4
H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53
I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17
J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30
K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129
L.ROOT-SERVERS.NET. 3600000 IN A 198.32.64.12
M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33
I don't see any v6 glue there... Rather than having conversations about transition to IPv6, maybe we should be sure it works natively first? It's rather ironic to think that for v6 DNS to work an incumbent legacy protocol is still required. The GTLD's appear to have somewhat better v6 services than root:
A.GTLD-SERVERS.NET. 172800 IN AAAA 2001:503:a83e::2:30
B.GTLD-SERVERS.NET. 172800 IN AAAA 2001:503:231d::2:30
I'm pretty disappointed now,
-Barrett
;. IN NS
A.ROOT-SERVERS.NET. 3600000 IN A 198.41.0.4
B.ROOT-SERVERS.NET. 3600000 IN A 192.228.79.201
C.ROOT-SERVERS.NET. 3600000 IN A 192.33.4.12
D.ROOT-SERVERS.NET. 3600000 IN A 128.8.10.90
E.ROOT-SERVERS.NET. 3600000 IN A 192.203.230.10
F.ROOT-SERVERS.NET. 3600000 IN A 192.5.5.241
G.ROOT-SERVERS.NET. 3600000 IN A 192.112.36.4
H.ROOT-SERVERS.NET. 3600000 IN A 128.63.2.53
I.ROOT-SERVERS.NET. 3600000 IN A 192.36.148.17
J.ROOT-SERVERS.NET. 3600000 IN A 192.58.128.30
K.ROOT-SERVERS.NET. 3600000 IN A 193.0.14.129
L.ROOT-SERVERS.NET. 3600000 IN A 198.32.64.12
M.ROOT-SERVERS.NET. 3600000 IN A 202.12.27.33I don't see any v6 glue there... Rather than having conversations about
transition to IPv6, maybe we should be sure it works natively first? It's
rather ironic to think that for v6 DNS to work an incumbent legacy protocol is
still required.
At least something is happening:
http://www.icann.org/committees/security/sac016.htm
http://www.icann.org/committees/security/sac017.htm
Regards,
Andras
I'm pretty disappointed now,
Searching the ICANN web site I found this:
http://www.icann.org/committees/security/sac018.pdf
Does anyone know what's been happening in the wake of that document?
Consider that Windows XP (and server 2k3) will not,
under any circumstance, send a DNS request over IPv6,
and yet they were widely considered "IPv6 compliant."
Consider also how long it took to get a working way of
telling autoconfigured hosts about which DNS servers
to use (without manually entering 128-bit addresses).
To me, the above show that the bulk of the actual
deployments were in dual-stack or tunnel environments,
and greenfield implementations were few and far
between. There's a surprising amount of unexplored
"here be dragons" territory in IPv6, given how long
some very smart people have been working on it.
-David Barak
David Barak
Need Geek Rock? Try The Franchise:
http://www.listentothefranchise.com
there are providers that have (in the US even if that matters) ipv6
connected auth servers, that could even help. I can't seem to make one of
them want to be a registrar too 
but... maybe Ultra/Neustar could do
that for you?
Given that the ARIN BoT has published a call to move to IPv6:
http://www.arin.net/media/releases/070521-v6-resolution.pdf
and that LACNIC and .MX have made these statements:
http://lacnic.net/en/anuncios/2007_agotamiento_ipv4.html
http://www.nic.mx/es/Noticias_2?NEWS=220
and ICANN has been studying the issue:
http://www.icann.org/committees/security/sac018.pdf
What possibly can be done to get the root zone "really" available on IPv6? http://www.root-servers.org/ lists a few root servers as having IPv6 addresses, so "really" means having
for i in a b c d e f g h i j k l m; do dig $i.root-servers.net aaaa +norec; done
return at least one AAAA in the answer section.
What's the hold up? What's getting worked on? Is there a dns-root-on-ipv6-deployment task force anywhere? Is there someone that can give an authoritative update on where we are on the road to being able to accomplish what is requested above? Part of my reaction is to the quip "given all of the v6 push lately" juxtaposed with NANOG 40 that barely mentioned IPv6 in the agenda.
If we can't get one application (DNS) to do IPv6 how can we expect the ISPs to just up and deploy it? I would suspect that getting the roots - or just some of them - to legitimize their IPv6 presence would be easier than getting ISPs rolling.
Well:
"Additional study and testing is encouraged to continue to assess the impact of including AAAA records in the DNS priming response."
Apparently, this can't be studied enough. This is what I wrote in my book two years ago:
"Since mid-2004, TLD registries may have IPv6 addresses included in the root zone as glue records, and some TLDs allow end users to register IPv6 nameserver addresses for their domains. Many of the root name-servers are alreadyreachable over IPv6 (see http://www.root-servers.org/). ICANN and theroot server operators are proceeding very cautiously, but addition of IPv6 glue records to the root zone is expected in the
not too distant future."
At this rate, we'll be fresh out of IPv4 space before anything happens. More study is a waste of time, we all know that all implementations from this century can handle it but a small percentage of all sites is going to have trouble anyway because they have protocol-breaking equipment installed. ICANN should bite the bullet and announce a date for this so we can start beating the firewall admins into submission.
there are providers that have (in the US even if that matters) ipv6
connected auth servers, that could even help. I can't seem to make one of
them want to be a registrar too
that for you?
Neustar/Ultra's .org gtld registration services apparently do not support v6, however, net and com do. Yet, .org does provide a v6 resolver:
b0.org.afilias-nst.org. 86400 IN AAAA 2001:500:c::1
-B
My view is that deploying only IPv6 in the LANs is the wrong approach in the
short term, unless you're sure that all your applications are ready, or you
have translation tools (that often are ugly), and you're disconnected from
the rest of the IPv4 Internet.
I'm deploying large (5000 sites) IPv6 networks for customers, and we also
decided that at a given point, if your traffic is IPv6 dominant, it made be
sensible to consider deploying IPv6-only in the access and core network. I
just explained it yesterday in another mailing list:
"The trick is to keep dual stack in the LANs (even if the LANs use net10 and
NAT), so the "old" applications that are still only available with IPv4,
keep running. In order to do that, you need an automatic tunneling protocol.
For example, softwires, and in fact this is the reason we needed it.
Softwires is basically L2TP, so you can guess we are talking simply about
VPNs "on demand".
In order to keep most of the traffic as IPv6 within the network, the access
to the rest of the Internet, for example for http, is proxied by boxes (that
also do caching functions, as in many networks is done to proxy
IPv4-to-IPv4), but in our case to IPv4-to-IPv6.
What I will never do at this stage and probably for many years, is to drop
IPv4 from the LANs, unless I have a closed network and don't want to talk
with other parties across Internet, and I'm sure all my applications already
support IPv6.
This has been presented several times in different foras such RIR meetings.
And yes ... I'm already working on an ID to explain a bit more all the
details."
Regards,
Jordi
This is one more reason, some OSs may not support IPv6 DNS transport, so you
need to keep dual stack.
Also, if roots/TLDs do not support yet IPv6, you will need to have at least
a dual stack DNS in your network.
I think in the long term we will be there, using IPv6-only in LANs, but
don't see the reason, at least not an immediate one, unless you've a very
specific scenario/business case, and then you probably need to have
translators at the edge, and then it may resolve the DNS issue also for you.
Regards,
Jordi
What I recall from the ICANN Lisbon meeting (end of March), after the SSAC
and RSSAC recommendations, is that a plan is being worked out with the root
operators in order to make sure that they have the deployment done and then
the hints file is modified.
I believe this will not take too much time (just a few months ?), if folks
are interested I can probably investigate about the concrete timing.
Today the ICANN board also approved a new resolution about IPv6, which I
just posted here:
http://www.ipv6tf.org/index.php?page=news/newsroom&id=3052
Regards,
Jordi
Apparently GoDaddy does not support v6 glue for their customers,
who does?
I know that gkg.net does.
And entering them is via the same web form as v4 addresses.
-JimC
JORDI PALET MARTINEZ wrote:
My view is that deploying only IPv6 in the LANs is the wrong approach in the
short term, unless you're sure that all your applications are ready, or you
have translation tools (that often are ugly), and you're disconnected from
the rest of the IPv4 Internet.
You're entitled to your view.
De: Barrett Lyon <blyon@blyon.com>
Responder a: <blyon@blyon.com>
CC: <nanog@merit.edu>If you deploy dual-stack, it is much easier to keep doing the DNS
queries
using IPv4 transport, and there is not any practical advantage in
doing so
with IPv6 transport.Thanks Jordi, not to sound too brash but, I'm already doing so. I am
trying not to deploy a hacked v6 service which requires an incumbent
legacy protocol to work.
As said by others, the core infrastructure really should be ready for v6-only. Why should it be so hard?
pt
Because we have designed IPv6 with the view of a smooth transition AND
co-existence, and that means dual-stack, at least in the end-sites.
Otherwise is not *smooth* anymore, and you will find troubles, it is just a
matter of time they will get resolved, of course.
Regards,
Jordi
One note here is that even though you can get glue into com/net/org
using this method, there is no IPv6 glue for the root yet, as such even
if you manage to get the IPv6 glue in, it won't accomplish much (except
sending all IPv6 capable resolvers over IPv6 transport
resolvers will still require IPv4 to reach the root. One can of course
create their own root hint zone and force bind, or other dns server, to
not fetch the hints from the real root, but that doesn't help for the
rest of the planet. (Root alternatives like orsn could fix that up but
apparently their main german box that was doing IPv6 is out of the air)
Having AAAA glue in GTLD/ccTLD's will help resolvers that first query for AAAA glue before A glue for nameservers. If you don't have AAAA glue then it's going to be an extra RTT to look up the A record for your nameservers, which makes your webpages slower to load. And everyone wants their webpages to load faster.
The fact that the root name serers don't supply AAAA glue for GTLDs/ccTLDs is a minor annoyance, people should in general only go to the root name servers once a day per GTLD/ccTLD. There are 267 TLD's and you're unlikely to talk to them all in a given day, but almost every request your name server makes is going to start with a query to a GTLD or ccTLD server.
bummer