ICANN registrar supporting v6 glue?
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
De: Barrett Lyon <blyon@blyon.com> Responder a: <owner-nanog@merit.edu> Fecha: Fri, 29 Jun 2007 08:54:03 -0700 Para: <nanog@merit.edu> Asunto: ICANN registrar supporting v6 glue?
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
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
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
On Fri, 29 Jun 2007, Barrett Lyon wrote:
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?
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?
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?
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
On Fri, 29 Jun 2007, Barrett Lyon wrote:
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?
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
bummer :(
On Fri, Jun 29, 2007 at 01:57:04PM -0700, Barrett Lyon wrote:
Neustar/Ultra's .org gtld registration services apparently do not
As a point of clarification, Neustar Ultra Services has exactly nothing to do with registration of .ORG domain names. That's a function of Public Interest Registry, who contracts the technical operations of the registry to Afilias (my employer). Neustar Ultra is one of the providers of DNS services for .org, but they have nothing to do with the registration side. I'm not in a position to state when PIR is planning to accept IPv6 records in the zone, although I am aware that there are plans to do it in the near future (you'd have to take it up with PIR, because they make the registry policies). I will note that .info (which Afilias operates) accepts IPv6 addresses today, but as far as I can tell registrars just don't care. If this is something you want, you need to talk to the registrars. Also,
Yet, .org does provide a v6 resolver:
b0.org.afilias-nst.org. 86400 IN AAAA 2001:500:c::1
that happens not to be a Neustar Ultra Services operated nameserver. There are some servers operated by NUS, authoritative for .org, that _do_ speak IPv6, however. A -- Andrew Sullivan 204-4141 Yonge Street Afilias Canada Toronto, Ontario Canada <andrew@ca.afilias.info> M2P 2A8 jabber: ajsaf@jabber.org +1 416 646 3304 x4110
At 9:23 -0700 6/29/07, Barrett Lyon wrote:
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?
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. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused.
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
De: Edward Lewis <Ed.Lewis@neustar.biz> Responder a: <owner-nanog@merit.edu> Fecha: Fri, 29 Jun 2007 15:43:45 -0400 Para: <nanog@merit.edu> CC: <ed.lewis@neustar.biz> Asunto: Re: ICANN registrar supporting v6 glue?
At 9:23 -0700 6/29/07, Barrett Lyon wrote:
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?
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. -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar
Think glocally. Act confused.
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
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
De: Barrett Lyon <blyon@blyon.com> Responder a: <blyon@blyon.com> Fecha: Fri, 29 Jun 2007 09:23:59 -0700 Para: <jordi.palet@consulintel.es> CC: <nanog@merit.edu> Asunto: Re: ICANN registrar supporting v6 glue?
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
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
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
De: Pete Templin <petelists@templin.org> Responder a: <petelists@templin.org> Fecha: Fri, 29 Jun 2007 19:14:30 -0500 Para: <jordi.palet@consulintel.es> CC: <nanog@nanog.org> Asunto: Re: ICANN registrar supporting v6 glue?
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
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
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
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
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.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.
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? -- -=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=- Edward Lewis +1-571-434-5468 NeuStar Think glocally. Act confused.
On 29-jun-2007, at 19:06, Edward Lewis wrote:
I'm pretty disappointed now,
Searching the ICANN web site I found this:
Does anyone know what's been happening in the wake of that document?
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.
--- Barrett Lyon <blyon@blyon.com> wrote:
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.
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 ____________________________________________________________________________________ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC
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
De: David Barak <thegameiam@yahoo.com> Responder a: <owner-nanog@merit.edu> Fecha: Fri, 29 Jun 2007 10:19:05 -0700 (PDT) Para: <nanog@merit.edu> Asunto: IPv6 & DNS
--- Barrett Lyon <blyon@blyon.com> wrote:
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.
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
______________________________________________________________________________ ______ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
On Fri, Jun 29, 2007 at 06:57:30PM -0400, JORDI PALET MARTINEZ wrote:
This is one more reason, some OSs may not support IPv6 DNS transport, so you need to keep dual stack.
The OS, IPv6, udp/tcp and DNS are all at different layers of the protocol stack.. we are supposed to be able to seamlessly switch out lower layers without the upper layers needing to be aware. This seems to be proving difficult.
Also, if roots/TLDs do not support yet IPv6, you will need to have at least a dual stack DNS in your network.
No, I just wont bother with v6! If this thing doesnt 'just work' why am I going to spend time and effort trying to use it for negative gain?
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.
Why would I need it in a LAN? I can use RFC1918 if I want to be an island and then I dont have to put in kludges or talk my users through why their apps arent working, that will also resolve the DNS issue :) Steve
De: David Barak <thegameiam@yahoo.com> Responder a: <owner-nanog@merit.edu> Fecha: Fri, 29 Jun 2007 10:19:05 -0700 (PDT) Para: <nanog@merit.edu> Asunto: IPv6 & DNS
--- Barrett Lyon <blyon@blyon.com> wrote:
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.
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
______________________________________________________________________________ ______ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC
********************************************** The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
Below, in-line. Regards, Jordi
De: Stephen Wilcox <steve.wilcox@packetrade.com> Responder a: <owner-nanog@merit.edu> Fecha: Sat, 30 Jun 2007 14:23:37 +0100 Para: JORDI PALET MARTINEZ <jordi.palet@consulintel.es> CC: <nanog@nanog.org> Asunto: Re: IPv6 & DNS
On Fri, Jun 29, 2007 at 06:57:30PM -0400, JORDI PALET MARTINEZ wrote:
This is one more reason, some OSs may not support IPv6 DNS transport, so you need to keep dual stack.
The OS, IPv6, udp/tcp and DNS are all at different layers of the protocol stack.. we are supposed to be able to seamlessly switch out lower layers without the upper layers needing to be aware. This seems to be proving difficult.
Because in fact, most of the IPv6 implementations today are not really "dual-stack" but hybrid-stack, in the sense that 80% of the stack is the same. You can definitively "turn-off" IPv4 by not setting up a DHCP server neither manual configuration, the effect is the same. Hybrid stacks are very important because then the "dual-stack" takes 120% of the code instead of 200%, which in a PC is not relevant, but it is in a cellular phone, PDA, sensor, etc. But as said, IPv6 was designed having in mind a smooth transition including dual-stack. Nothing is wrong when IPv6 "alone" doesn't work today. Is like trying to use only gas in an engine that requires a mix of gas and oil. It is something wrong ? No, it is the way you try to use the engine, because was not designed that way !
Also, if roots/TLDs do not support yet IPv6, you will need to have at least a dual stack DNS in your network.
No, I just wont bother with v6! If this thing doesnt 'just work' why am I going to spend time and effort trying to use it for negative gain?
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.
Why would I need it in a LAN? I can use RFC1918 if I want to be an island and then I dont have to put in kludges or talk my users through why their apps arent working, that will also resolve the DNS issue :)
In fact, I have not talked about public IPv4 addresses at all ! As explained in another message, we are doing large IPv6-only deployments (5.000 sites). The "only" applies to the core and access network, but we keep net10+NAT+IPv6 in the LANs.
Steve
De: David Barak <thegameiam@yahoo.com> Responder a: <owner-nanog@merit.edu> Fecha: Fri, 29 Jun 2007 10:19:05 -0700 (PDT) Para: <nanog@merit.edu> Asunto: IPv6 & DNS
--- Barrett Lyon <blyon@blyon.com> wrote:
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.
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
____________________________________________________________________________ __ ______ Take the Internet to Go: Yahoo!Go puts the Internet in your pocket: mail, news, photos & more. http://mobile.yahoo.com/go?refer=1GNXIC
********************************************** The IPv6 Portal: http://www.ipv6tf.org
Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org
This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
********************************************** The IPv6 Portal: http://www.ipv6tf.org Bye 6Bone. Hi, IPv6 ! http://www.ipv6day.org This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.
--- JORDI PALET MARTINEZ <jordi.palet@consulintel.es> wrote:
But as said, IPv6 was designed having in mind a smooth transition including dual-stack. Nothing is wrong when IPv6 "alone" doesn't work today. Is like trying to use only gas in an engine that requires a mix of gas and oil. It is something wrong ? No, it is the way you try to use the engine, because was not designed that way !
The problem is that turning on v6, while requiring that v4 continue to work means accepting the limitations and security risks of both protocols. This is not a "transition" - this is another level of indirection (c.f. RFC 1925). A "transition" has an end-state which is clearly defined, and we are only just starting to ferret out the end-state with regard to v6.
In fact, I have not talked about public IPv4 addresses at all ! As explained in another message, we are doing large IPv6-only deployments (5.000 sites). The "only" applies to the core and access network, but we keep net10+NAT+IPv6 in the LANs.
That's what you mean by "IPv6-only"? When I talk about IPv6-only, what I mean is "no other layer-3 protocols running: no IPv4, no Appletalk, no IPX, etc." I get that there is rough consensus. I'm waiting for the running code. -David Barak David Barak Need Geek Rock? Try The Franchise: http://www.listentothefranchise.com ____________________________________________________________________________________ Looking for earth-friendly autos? Browse Top Cars by "Green Rating" at Yahoo! Autos' Green Center. http://autos.yahoo.com/green_center/
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)
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.
Barrett Lyon wrote:
=20 Apparently GoDaddy does not support v6 glue for their customers, who does? I don't think requiring dual-stack v6 users perform v4 queries t= o 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)
You don't change the hints you just provide zones that override B.ROOT-SERVERS.NET, F.ROOT-SERVERS.NET, H.ROOT-SERVERS.NET, K.ROOT-SERVERS.NET and M.ROOT-SERVERS.NET or just use your own ROOT-SERVERS.NET zone with the AAAAs added in. In the few couple of years I've only seen two outages with the IPv6 root instances. In both cases they were fixed soon after reporting the outage. Mark B.ROOT-SERVERS.NET. 3600 IN A 192.228.79.201 B.ROOT-SERVERS.NET. 3600 IN AAAA 2001:478:65::53 F.ROOT-SERVERS.NET. 3600 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600 IN AAAA 2001:500::1035 H.ROOT-SERVERS.NET. 3600 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600 IN AAAA 2001:500:1::803f:235 K.ROOT-SERVERS.NET. 3600 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 3600 IN AAAA 2001:7fd::1 M.ROOT-SERVERS.NET. 3600 IN A 202.12.27.33 M.ROOT-SERVERS.NET. 3600 IN AAAA 2001:dc3::35
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
--------------enig28DE1EA6E1A720C65610D130 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/
iHUEARECADUFAkaFMZMuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58Ixw1AKC8ycHIGT3Nzs296Xf4XeeDvq+m agCeM0cnyTZxnh0QbnuQXVwhw2kil1o= =UGVO -----END PGP SIGNATURE-----
--------------enig28DE1EA6E1A720C65610D130--
On Sat, Jun 30, 2007 at 11:16:40PM +1000, Mark Andrews wrote:
Barrett Lyon wrote:
=20 Apparently GoDaddy does not support v6 glue for their customers, who does? I don't think requiring dual-stack v6 users perform v4 queries t= o 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)
You don't change the hints you just provide zones that override B.ROOT-SERVERS.NET, F.ROOT-SERVERS.NET, H.ROOT-SERVERS.NET, K.ROOT-SERVERS.NET and M.ROOT-SERVERS.NET or just use your own ROOT-SERVERS.NET zone with the AAAAs added in.
I've read your email twice and I dont follow. Either you are telling me a) Provide my own hints with AAAA included (you specifically say thats not what you mean tho) or b) Serve my own root zone. From a root operator, surely thats not right either (I hope!)?
In the few couple of years I've only seen two outages with the IPv6 root instances. In both cases they were fixed soon after reporting the outage.
So there are v6 roots out there? Where are they hiding and why arent they being provided in the hints file or NS queries on . ? Steve
B.ROOT-SERVERS.NET. 3600 IN A 192.228.79.201 B.ROOT-SERVERS.NET. 3600 IN AAAA 2001:478:65::53 F.ROOT-SERVERS.NET. 3600 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600 IN AAAA 2001:500::1035 H.ROOT-SERVERS.NET. 3600 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600 IN AAAA 2001:500:1::803f:235 K.ROOT-SERVERS.NET. 3600 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 3600 IN AAAA 2001:7fd::1 M.ROOT-SERVERS.NET. 3600 IN A 202.12.27.33 M.ROOT-SERVERS.NET. 3600 IN AAAA 2001:dc3::35
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
--------------enig28DE1EA6E1A720C65610D130 Content-Type: application/pgp-signature; name="signature.asc" Content-Description: OpenPGP digital signature Content-Disposition: attachment; filename="signature.asc"
-----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.7 (MingW32) Comment: Jeroen Massar / http://unfix.org/~jeroen/
iHUEARECADUFAkaFMZMuFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy b2VuQHVuZml4Lm9yZwAKCRApqihSMz58Ixw1AKC8ycHIGT3Nzs296Xf4XeeDvq+m agCeM0cnyTZxnh0QbnuQXVwhw2kil1o= =UGVO -----END PGP SIGNATURE-----
--------------enig28DE1EA6E1A720C65610D130--
Stephen Wilcox wrote:
On Sat, Jun 30, 2007 at 11:16:40PM +1000, Mark Andrews wrote: [..]
You don't change the hints you just provide zones that override B.ROOT-SERVERS.NET, F.ROOT-SERVERS.NET, H.ROOT-SERVERS.NET, K.ROOT-SERVERS.NET and M.ROOT-SERVERS.NET or just use your own ROOT-SERVERS.NET zone with the AAAAs added in.
I've read your email twice and I dont follow.
Either you are telling me
You want option c: c) Serve your own version of "root-servers.net" containing AAAA's This never occurred to me but it indeed is the best way to do it. All the root-servers have names in root-servers.net, as such just make your own master zone containing: B.ROOT-SERVERS.NET. 3600 IN A 192.228.79.201 B.ROOT-SERVERS.NET. 3600 IN AAAA 2001:478:65::53 F.ROOT-SERVERS.NET. 3600 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600 IN AAAA 2001:500::1035 H.ROOT-SERVERS.NET. 3600 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600 IN AAAA 2001:500:1::803f:235 K.ROOT-SERVERS.NET. 3600 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 3600 IN AAAA 2001:7fd::1 M.ROOT-SERVERS.NET. 3600 IN A 202.12.27.33 M.ROOT-SERVERS.NET. 3600 IN AAAA 2001:dc3::35 + optionally the other roots-servers as found on www.root-servers.org And presto. You don't even have to turn of glue fetch etc, as the above zone will override the glue then anyway. Good one Mark, thanks. Greets, Jeroen
In article <20070630133219.GF18222@MrServer.telecomplete.net> you write:
I've read your email twice and I dont follow.
Either you are telling me
a) Provide my own hints with AAAA included (you specifically say thats not what you mean tho)
or
b) Serve my own root zone. From a root operator, surely thats not right either (I hope!)?
You don't want to override the NS records. You want to augment the address records. You can do it on a per host basis (which is what I do at home) or you can do it by augmenting the contents of root-servers.net. You will note that I have choosen not to leak the addresses to anyone other than myself. zone "b.root-servers.net" { type master; file "master/b.root-servers.net"; notify no; allow-query { localhost; }; }; zone "f.root-servers.net" { type master; file "master/f.root-servers.net"; notify no; allow-query { localhost; }; }; zone "h.root-servers.net" { type master; file "master/h.root-servers.net"; notify no; allow-query { localhost; }; }; zone "k.root-servers.net" { type master; file "master/k.root-servers.net"; notify no; allow-query { localhost; }; }; zone "m.root-servers.net" { type master; file "master/m.root-servers.net"; notify no; allow-query { localhost; }; }; or zone "root-servers.net" { type master; file "master/root-servers.net"; notify no; allow-query { localhost; }; }
In the few couple of years I've only seen two outages with the IPv6 root instances. In both cases they were fixed soon after reporting the outage.
So there are v6 roots out there?
I'm using the IPv6 addresses published by the root server operators on http://www.root-servers.org/. They are the addresses that will be added to root-servers.net zone once there is agreement to add them.
Where are they hiding and why arent they being provided in the hints file or NS queries on . ?
They arn't hiding. They were published years ago. It's just a long process to get them added to the root-servers.net zone. I added them to my config on Feb 18 2005 and they had been published for a long time when I did that. -rw-r--r-- 1 root wheel 160 Feb 18 2005 /var/named/master/b.root-servers.net -rw-r--r-- 1 root wheel 156 Feb 18 2005 /var/named/master/f.root-servers.net -rw-r--r-- 1 root wheel 162 Feb 18 2005 /var/named/master/h.root-servers.net -rw-r--r-- 1 root wheel 154 Feb 18 2005 /var/named/master/k.root-servers.net -rw-r--r-- 1 root wheel 155 Feb 18 2005 /var/named/master/m.root-servers.net Mark
Steve
B.ROOT-SERVERS.NET. 3600 IN A 192.228.79.201 B.ROOT-SERVERS.NET. 3600 IN AAAA 2001:478:65::53 F.ROOT-SERVERS.NET. 3600 IN A 192.5.5.241 F.ROOT-SERVERS.NET. 3600 IN AAAA 2001:500::1035 H.ROOT-SERVERS.NET. 3600 IN A 128.63.2.53 H.ROOT-SERVERS.NET. 3600 IN AAAA 2001:500:1::803f:235 K.ROOT-SERVERS.NET. 3600 IN A 193.0.14.129 K.ROOT-SERVERS.NET. 3600 IN AAAA 2001:7fd::1 M.ROOT-SERVERS.NET. 3600 IN A 202.12.27.33 M.ROOT-SERVERS.NET. 3600 IN AAAA 2001:dc3::35
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
"Barrett" == Barrett Lyon <blyon@blyon.com> writes:
Barrett> Apparently GoDaddy does not support v6 glue for their customers, Barrett> who does? I know that gkg.net does. And entering them is via the same web form as v4 addresses. -JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
Hi, here is my experience 3 weeks ago ; I contacted 20 gTLD host masters and only a few host master replied me with negative answer; they have no plan to involve IPv6 for their name servers and coordination of their registrars. (a lot of registrars provide web form to their customers but have no field for AAAA) ICANN advised me that it would be better to propose IPv6 support at RIRs community meeting(s). It is needed to add v6 support to their policy book. Is there someone in this mailing list to propose at there with me, please contact me directly. Regards, On 2007/06/30, at 8:19, James Cloos wrote:
"Barrett" == Barrett Lyon <blyon@blyon.com> writes:
Barrett> Apparently GoDaddy does not support v6 glue for their customers, Barrett> who does?
I know that gkg.net does.
And entering them is via the same web form as v4 addresses.
-JimC -- James Cloos <cloos@jhcloos.com> OpenPGP: 1024D/ED7DAEA6
------------------------------- Ruri Hiromi ruri@bugest.net
participants (15)
-
Andrew Sullivan -
Barrett Lyon -
Chris L. Morrow -
David Barak -
Edward Lewis -
Iljitsch van Beijnum -
JAKO Andras -
James Cloos -
Jeroen Massar -
JORDI PALET MARTINEZ -
Mark Andrews -
Perry Lorier -
Pete Templin -
Ruri Hiromi -
Stephen Wilcox