is there any operational considerations before putting both A and AAAA records on a name used glue? or, should one use separate names for v4 and v6 transport? e.g.: example.com. NS ns1.example.com. NS ns2.example.com. ns1.example.com. A 192.0.2.1 AAAA dead:beef::1 ns2.example.com. A 192.0.2.2 AAAA dead:beef::2 vs example.com. NS ns1.example.com. NS ns1.ipv6.example.com. NS ns2.example.com. NS ns2.ipv6.example.com. ns1.example.com. A 192.0.2.1 ns1.ipv6.example.com. AAAA dead:beef::1 ns2.example.com. A 192.0.2.2 ns2.ipv6.example.com. AAAA dead:beef::2 yours, jakob
On 5 sep 2003, at 10.12, Jakob Schlyter wrote:
is there any operational considerations before putting both A and AAAA records on a name used glue? or, should one use separate names for v4 and v6 transport?
I personally would put A and AAAA for the same name. Otherwise I guess there is a risk the resolver using only IPv4 will query for A RR for ns1.ipv6.example.com, which of course will not exist. A and AAAA should use the same namespace. I think the same is true for any service which uses domain names when addressing services. One use in the example below ns1.example.com as the domain name for the nameserver for example.com, and that is true regardless of what transport you use. Similar rules should be true for HTTP, SMTP etc. paf
e.g.:
example.com. NS ns1.example.com. NS ns2.example.com. ns1.example.com. A 192.0.2.1 AAAA dead:beef::1 ns2.example.com. A 192.0.2.2 AAAA dead:beef::2 vs example.com. NS ns1.example.com. NS ns1.ipv6.example.com. NS ns2.example.com. NS ns2.ipv6.example.com. ns1.example.com. A 192.0.2.1 ns1.ipv6.example.com. AAAA dead:beef::1 ns2.example.com. A 192.0.2.2 ns2.ipv6.example.com. AAAA dead:beef::2
yours,
jakob
paf wrote:
A and AAAA should use the same namespace.
apart from this more general statement, which I agree with, separating namespaces would cost more precious octets in the packet. -Peter
"Peter" == Peter Koch <pk@TechFak.Uni-Bielefeld.DE> writes:
>> A and AAAA should use the same namespace. Peter> apart from this more general statement, which I agree with, Peter> separating namespaces would cost more precious octets in Peter> the packet. I wonder if saving the odd octet here and there to squeeze stuff into a 512 byte payload is really the best approach. It is wise to apply the constraints of 1980's DNS to the world of IPv6 in the 21st century? This seems to be storing up trouble for the future and could make it awkward to get reasonable amounts of IPv6 glue deployed. How feasible would it be to mandate or recommend that IPv6-aware DNS clients use EDNS0 to get bigger payloads and complete glue RRsets? Could we just say "use EDNS0" and be done with it?
Jim Reid said:
century? This seems to be storing up trouble for the future and could make it awkward to get reasonable amounts of IPv6 glue deployed. How feasible would it be to mandate or recommend that IPv6-aware DNS clients use EDNS0 to get bigger payloads and complete glue RRsets?
that might be useful but will not solve the problem.
Could we just say "use EDNS0" and be done with it?
Legacy, i.e. EDNS-unaware, clients will continue to use the 512 byte limit, so the servers - unless they call for more load - should be conservative and the zone administrators should be as well. Related to this, IPv6 already has an impact on server load. On our system we already see large amounts of AAAA and A6 type queries (each roughly 85% of the type A count), so I'd really favor a conservative approach. -Peter
How many old clients and servers do _NOT_ handle a 1400 byte packet? When was the last time you saw one? (The pix blocks it in some configuration modes I can add before you all say _T_H_E__P_I_X_...) paf On 5 sep 2003, at 19.49, Peter Koch wrote:
Jim Reid said:
century? This seems to be storing up trouble for the future and could make it awkward to get reasonable amounts of IPv6 glue deployed. How feasible would it be to mandate or recommend that IPv6-aware DNS clients use EDNS0 to get bigger payloads and complete glue RRsets?
that might be useful but will not solve the problem.
Could we just say "use EDNS0" and be done with it?
Legacy, i.e. EDNS-unaware, clients will continue to use the 512 byte limit, so the servers - unless they call for more load - should be conservative and the zone administrators should be as well.
Related to this, IPv6 already has an impact on server load. On our system we already see large amounts of AAAA and A6 type queries (each roughly 85% of the type A count), so I'd really favor a conservative approach.
-Peter
"Peter" == Peter Koch <pk@TechFak.Uni-Bielefeld.DE> writes:
>> Could we just say "use EDNS0" and be done with it? Peter> Legacy, i.e. EDNS-unaware, clients will continue to use the Peter> 512 byte limit, so the servers - unless they call for more Peter> load - should be conservative and the zone administrators Peter> should be as well. Indeed. However I wonder how much legacy IPv6 stuff exists and whether we're allowing that to unduly influence things. Suppose an EDNS0 header bit was set aside for a resolver to say "give me all the AAAA or A6 records you have for this query". And of course, the resolver would provide a buffer large enough to receive the reply. Meanwhile, legacy stuff would continue with 512 byte payloads. It would see the largely IPv4 internet just as they do right now, unless those clients explicitly queried for (say) a AAAA record. There's some hand-waving going on here. An RFC would be needed to document server behaviour along the lines of "don't throw in IPv6 glue unless you *know* the client (a) said they wanted it; (b) provided a buffer big enough for the extra data without causing truncation. I think this should work without breaking anything. New resolvers could use this hypothetical EDNS0 bit if they care about IPv6. Legacy stuff would be unchanged. However legacy IPv6 stuff would be no better off than it is at present. That deployed base might not be large enough to worry about anyway. IMO it won't be big enough to justify protocol tweaks or changes in operational practice. What I'm really saying is fix this for the millions of IPv6 hosts that will be joining the internet and not get too obsessed with backwards compatibility for the probably small installed base of existing IPv6 devices with resolvers that can't or won't be upgraded. Peter> Related to this, IPv6 already has an impact on server Peter> load. On our system we already see large amounts of AAAA Peter> and A6 type queries (each roughly 85% of the type A count), Peter> so I'd really favor a conservative approach. Aha! Interesting numbers. Do you have any idea what it is that's generating these AAAA and A6 queries? 85% of the A query count seems very high. I wonder if there are some idiot clients out there in a tight loop who just keep asking for AAAA or A6 even when they are told there aren't any? Maybe it's something like that which accounts for the high AAAA and A6 query rate you're seeing.
Jim Reid wrote:
Indeed. However I wonder how much legacy IPv6 stuff exists and whether
there's no "legacy IPv6" but a lot of EDNS0-unaware ("legacy") mostly IPv4 based clients, which have to deal with what fits into 512 bytes.
legacy stuff would continue with 512 byte payloads. It would see the largely IPv4 internet just as they do right now, unless those clients explicitly queried for (say) a AAAA record.
1886bis, currently in "AUTH48" state, instead modified all additional section processing from "add A" to "add A and AAAA".
compatibility for the probably small installed base of existing IPv6 devices with resolvers that can't or won't be upgraded.
I agree that the currently installed base of IPv6 hosts could be required to change, but I'm not concerned about those anyway.
there aren't any? Maybe it's something like that which accounts for the high AAAA and A6 query rate you're seeing.
Exactly. Most of these queries are for a single nameserver's name, which only has A but no AAAA and even less A6. -Peter
% Jim Reid wrote: % % > Indeed. However I wonder how much legacy IPv6 stuff exists and whether % there's no "legacy IPv6" but a lot of EDNS0-unaware ("legacy") mostly % IPv4 based clients, which have to deal with what fits into 512 bytes. To some degree, the 512 byte limit is part of the DNS protocol. RFC 1034 is reasonably clear on this. % > legacy stuff would continue with 512 byte payloads. It would see the % > largely IPv4 internet just as they do right now, unless those clients % > explicitly queried for (say) a AAAA record. % % 1886bis, currently in "AUTH48" state, instead modified all additional % section processing from "add A" to "add A and AAAA". It would perhaps be useful to review the respsize draft that is circulating in the DNSOPS w/g. And I am informed that the 8.4.1 and the 9.2.3 code attempt to "shuffle" the data in the additional section processing step to first send out glue of the type that the request came in on. e.g. query over v4, get A's first, query over v6, AAAAs first. % > compatibility for the probably small installed base of existing IPv6 % > devices with resolvers that can't or won't be upgraded. % % I agree that the currently installed base of IPv6 hosts could be required % to change, but I'm not concerned about those anyway. pretty much any resolver code shipped since 1998 understands IPv6 rrs. Not sure O'dells law still holds. --bill Opinions expressed may not even be mine by the time you read them, and certainly don't reflect those of any other entity (legal or otherwise).
"Peter" == Peter Koch <pk@TechFak.Uni-Bielefeld.DE> writes:
Peter> there's no "legacy IPv6" but a lot of EDNS0-unaware Peter> ("legacy") mostly IPv4 based clients, which have to deal Peter> with what fits into 512 bytes. Indeed. This stuff mostly doesn't know or care about IPv6, so let's try to ensure they never see AAAA records or get into problems caused by truncation isses as IPv6 glue comes along. >> legacy stuff would continue with 512 byte payloads. It would >> see the largely IPv4 internet just as they do right now, unless >> those clients explicitly queried for (say) a AAAA record. Peter> 1886bis, currently in "AUTH48" state, instead modified all Peter> additional section processing from "add A" to "add A and Peter> AAAA". I'd not read this draft. It seems to be what I've been suggesting. Thanks for the tip Peter.
-----BEGIN PGP SIGNED MESSAGE----- Peter Koch wrote:
Related to this, IPv6 already has an impact on server load. On our system we already see large amounts of AAAA and A6 type queries (each roughly 85% of the type A count), so I'd really favor a conservative approach.
We could make a rather stupid assumption that 85% of the queriers you see request AAAA and then the A record. Thus that the installed base supporting IPv6 is really growing. Sounds like a good thing. Patrik Fältström [paf@cisco.com] wrote:
(The pix blocks it in some configuration modes I can add before you all say _T_H_E__P_I_X_...)
Haha, hmm people where indeed complaining about PIX's at RIPE46 :) Btw, when is a PIX going to do IPv6, I once heared "March 2003" but I queried a university where they wanted to do IPv6 but due to policy stuff were not allowed as their PIX didn't filter IPv6 that it still did not support it :( Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP1m9dCmqKFIzPnwjEQIi9ACcCwDWE8q37sVknGKx+HLbploQnw4An2bk V2aGclP12SzfxOA/dJQewPPF =xTjY -----END PGP SIGNATURE-----
I'm not sure about the actual status, but Cisco demonstrated it at the last US Summit. See http://newsroom.cisco.com/dlls/prod_062403c.html. May be is still not commercial, but sure you can get a release from the Cisco people, just to try ? Regards, Jordi ----- Original Message ----- From: "Jeroen Massar" <jeroen@unfix.org> To: "'Peter Koch'" <pk@TechFak.Uni-Bielefeld.DE>; <dns-wg@ripe.net> Cc: "'Patrik Fältström'" <paf@cisco.com> Sent: Saturday, September 06, 2003 12:56 PM Subject: RE: [dns-wg] v6 ns/glue naming bcp -----BEGIN PGP SIGNED MESSAGE----- Peter Koch wrote:
Related to this, IPv6 already has an impact on server load. On our system we already see large amounts of AAAA and A6 type queries (each roughly 85% of the type A count), so I'd really favor a conservative approach.
We could make a rather stupid assumption that 85% of the queriers you see request AAAA and then the A record. Thus that the installed base supporting IPv6 is really growing. Sounds like a good thing. Patrik Fältström [paf@cisco.com] wrote:
(The pix blocks it in some configuration modes I can add before you all say _T_H_E__P_I_X_...)
Haha, hmm people where indeed complaining about PIX's at RIPE46 :) Btw, when is a PIX going to do IPv6, I once heared "March 2003" but I queried a university where they wanted to do IPv6 but due to policy stuff were not allowed as their PIX didn't filter IPv6 that it still did not support it :( Greets, Jeroen -----BEGIN PGP SIGNATURE----- Version: Unfix PGP for Outlook Alpha 13 Int. Comment: Jeroen Massar / jeroen@unfix.org / http://unfix.org/~jeroen/ iQA/AwUBP1m9dCmqKFIzPnwjEQIi9ACcCwDWE8q37sVknGKx+HLbploQnw4An2bk V2aGclP12SzfxOA/dJQewPPF =xTjY -----END PGP SIGNATURE----- ********************************** Madrid 2003 Global IPv6 Summit Presentations and videos on line at: http://www.ipv6-es.com 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 6 sep 2003, at 12.56, Jeroen Massar wrote:
(The pix blocks it in some configuration modes I can add before you all say _T_H_E__P_I_X_...)
Haha, hmm people where indeed complaining about PIX's at RIPE46 :) Btw, when is a PIX going to do IPv6, I once heared "March 2003" but I queried a university where they wanted to do IPv6 but due to policy stuff were not allowed as their PIX didn't filter IPv6 that it still did not support it :(
The pix is like all "firewall software" there to "protect" stupid things behind it. So, to some degree it should only allow the minimal possible things (512 byte DNS packets, no extensions to SMTP etc). But, the problem _I_ see with the pix is that one only have the choice of being so rigid regarding the standards, OR to open the port(s) completely. As you understand, this is something I am trying to change, but it is hard, because firewall people are extremely conservative. paf
At 12:56 PM +0200 2003/09/06, Jeroen Massar wrote:
Haha, hmm people where indeed complaining about PIX's at RIPE46 :) Btw, when is a PIX going to do IPv6, I once heared "March 2003" but I queried a university where they wanted to do IPv6 but due to policy stuff were not allowed as their PIX didn't filter IPv6 that it still did not support it :(
I think there are some changes coming soon. I was contacted by one of the PIX project managers in response to some negative things I had to say about it in the past, and they were offering to let me test the new version. Problem is, I don't really have a network available to me to do that, but they did confirm that there are some changes coming. Now, whether those changes include IPv6, I couldn't say. But I could ask, if anyone is interested. -- Brad Knowles, <brad.knowles@skynet.be> "They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety." -Benjamin Franklin, Historical Review of Pennsylvania. GCS/IT d+(-) s:+(++)>: a C++(+++)$ UMBSHI++++$ P+>++ L+ !E-(---) W+++(--) N+ !w--- O- M++ V PS++(+++) PE- Y+(++) PGP>+++ t+(+++) 5++(+++) X++(+++) R+(+++) tv+(+++) b+(++++) DI+(++++) D+(++) G+(++++) e++>++++ h--- r---(+++)* z(+++)
On Fri, 5 Sep 2003, Patrik Fältström wrote:
I personally would put A and AAAA for the same name. Otherwise I guess there is a risk the resolver using only IPv4 will query for A RR for ns1.ipv6.example.com, which of course will not exist.
A and AAAA should use the same namespace.
wasn't there an issue with bind8 marking names, instead of addresses, as bad/stale/unreachable ? so if a host has local v6 connectivity (e.g. link-local) but cannot reach the global v6 Internet, all A/AAAA nameservers would be considered bad since their v6 addresses wouldn't be reachable. I really hope I got this wrong, but I want find out before I put all my NSes on v6 and suddenly find my self unresolvable. jakob
participants (8)
-
Bill Manning -
Brad Knowles -
Jakob Schlyter -
Jeroen Massar -
Jim Reid -
JORDI PALET MARTINEZ -
Patrik Fältström -
Peter Koch