Subject: Infrastructure TLDs: .ARPA should be used

From: Thomas Narten <[email-masked]>
Date: Mon, 15 May 2000 11:01:18 -0400

Dear IPng WG:

Over the last few months, the IAB has been discussing possible
complications stemming from the use of the ".INT" TLD as a location
for Internet infrastructure domains. The result of those discussions
was a recommendation to the IESG that infrastructure domains be placed
in ".ARPA" rather than in ".INT" where feasible. See
http://www.iab.org/iab/statement-on-infrastructure-domains.txt for the
full recommendation.

Earlier this year, the IPng WG discussed the implication and
feasibility of placing the new bitstring-based reverse DNS lookup (as
described in draft-ietf-ipngwg-dns-lookups-nn.txt) under ".ARPA"
instead of ".INT".  Subsequently, the IPng Chairs indicated that there
was consensus that such a change would create no technical problems
and negligible deployment or operational impact at this point in time
and that the WG was willing to change its usage of ".INT" to something
else if so requested.

This note is to formally request that the WG make such a change. That
is, based on the IAB recommendation, the IESG requests that the the
bitstring-based reverse DNS lookup tree be placed under the ".ARPA"
TLD.

For the IESG,
Thomas 
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: Steve Deering <[email-masked]>
Date: Mon, 15 May 2000 09:03:43 -0700

Just to refresh everyone's memory, the request regarding .arpa applies
only to the new, bitstring-based reverse DNS entries, *not* the nybble-
based entries that are currently in use.  There is no intent or proposal
to move the nybble-based entries out of .int.

A secondary issue that was never formally resolved was what second-level
domain to use: .ip6.arpa or .in6-addr.arpa.  From the discussion in
February, the few people who commented on that all preferred the shorter
string (.ip6.arpa), simply because it was fewer characters to type.
So I propose we go with ip6.arpa.  Any objections (speak quickly)?

Steve

---

From: Bill Manning <[email-masked]>
Date: Tue, 16 May 2000 05:08:05 -0700 (PDT)

% Earlier this year, the IPng WG discussed the implication and
% feasibility of placing the new bitstring-based reverse DNS lookup (as
% described in draft-ietf-ipngwg-dns-lookups-nn.txt) under ".ARPA"
% instead of ".INT".  Subsequently, the IPng Chairs indicated that there
% was consensus that such a change would create no technical problems
% and negligible deployment or operational impact at this point in time
% and that the WG was willing to change its usage of ".INT" to something
% else if so requested.
% 

in 1996, I raised the issue of moving the installed base from 
in-addr.arpa into the .int domain. The operational impact was that
the installed resolver base had the values -hardcoded- and so the
impact was pretty high. At that point in time, the IP6 tree was 
anchored in the IP6.INT zone and -every- resolver since then has
these two entries -hardcoded-. At last count, thats over 10 million
nodes. While it is technically possible to change, it seems 
a bit naive to claim "negligable deployment or operational impact"

-- 
--bill

---

From: Bill Manning <[email-masked]>
Date: Tue, 16 May 2000 05:10:31 -0700 (PDT)

% 
% Just to refresh everyone's memory, the request regarding .arpa applies
% only to the new, bitstring-based reverse DNS entries, *not* the nybble-
% based entries that are currently in use.  There is no intent or proposal
% to move the nybble-based entries out of .int.

	What technical reason is there to do this?
	Or is this politically motivated?

% A secondary issue that was never formally resolved was what second-level
% domain to use: .ip6.arpa or .in6-addr.arpa.  From the discussion in
% February, the few people who commented on that all preferred the shorter
% string (.ip6.arpa), simply because it was fewer characters to type.
% So I propose we go with ip6.arpa.  Any objections (speak quickly)?

	See the previous post to Thos. But, if you insist on
	fragmenting IPv6 resolution, then i guess ip6.arpa
	is the least offensive.

---

From: Olafur Gudmundsson <[email-masked]>
Date: Tue, 16 May 2000 10:40:00 -0400

>a bit naive to claim "negligable deployment or operational impact"

This is a great test case for DNAME records and exactly what they where
invented for. If these 10M+ resolvers understand DNAME then there is no 
problem. Even if the resolvers do not understand DNAME's, CNAME records 
can be used to get the resolvers to the right place.  I do not think that 
the ip6.int domain is going away any time soon, and this may cause some 
operational problems in the short run but better now than later. 

	Olafur

---

From: Steve Deering <[email-masked]>
Date: Tue, 16 May 2000 20:24:04 -0700

>a bit naive to claim "negligable deployment or operational impact"

Bill,

From the email discussion in February, we were led to believe that there
was not yet any significant deployment or use of the *bitstring-based*
reverse DNS lookup code, and therefore it would be possible to change the
hardcoded string used by that *new* code without serious deployment or
operational impact.  Was that incorrect or has it since become incorrect?

>Or is this politically motivated?

See the IAB statement cited by Thomas and Scott for the reasons.

Steve

---

From: Bill Manning <[email-masked]>
Date: Wed, 17 May 100 02:22:38 -0700 (PDT)

% >a bit naive to claim "negligable deployment or operational impact"
% 
% Bill,
% 
% >From the email discussion in February, we were led to believe that there
% was not yet any significant deployment or use of the *bitstring-based*
% reverse DNS lookup code, and therefore it would be possible to change the
% hardcoded string used by that *new* code without serious deployment or
% operational impact.  Was that incorrect or has it since become incorrect?

	I beleive that there is limited deployment of the *bitstring-based*
DNS code. None the less, the impact is in splitting the lookup. Operationally
this will lead to substantial confusion since it will be unclear in which
tree the lable is anchored, ip6.int or ip6.arpa.  I expect that there will
be a call to try and syncronize these two trees, which will fail.
The confusion will impact the deployment of IP6. 

% >What technical reason is there to do this?
% >Or is this politically motivated?
% See the IAB statement cited by Thomas and Scott for the reasons.

	Ah... ok. no real technical reason for the requested change.
% Steve
% 
%

---

From: "Matt Crawford" <[email-masked]>
Date: Wed, 17 May 2000 08:45:17 -0500

> The confusion will impact the deployment of IP6. 

Even I think you're overestimating the potential for confusion.  But
no matter -- every implementation that understands bitstring labels
will understand the DNAME record, and 16 DNAME records just under
ip6.arpa will make the confusion you fear moot.

0.ip6.arpa.	999999	IN	DNAME	0.ip6.int.
; etc ...

This, as you know, won't interfere with any data under \[b0].ip6.arpa.

				Matt

---

From: Bill Manning <[email-masked]>
Date: Wed, 17 May 2000 07:57:22 -0700 (PDT)

% 
% > 	I beleive that there is limited deployment of the *bitstring-based*
% > DNS code. None the less, the impact is in splitting the lookup. Operationally
% > this will lead to substantial confusion since it will be unclear in which
% > tree the lable is anchored, ip6.int or ip6.arpa.  I expect that there will
% > be a call to try and syncronize these two trees, which will fail.
% > The confusion will impact the deployment of IP6. 
% 
% Even I think you're overestimating the potential for confusion.  But
% no matter -- every implementation that understands bitstring labels
% will understand the DNAME record, and 16 DNAME records just under
% ip6.arpa will make the confusion you fear moot.
% 
% 0.ip6.arpa.	999999	IN	DNAME	0.ip6.int.
% ; etc ...
% 
% This, as you know, won't interfere with any data under \[b0].ip6.arpa.
% 
% 				Matt

	I hope you are right. I remain unconvinced.  Deployment of
	new code is not all that quick.  nearly 20% of the installed
	base is still running pre 4.9 code... :(  And since the remaining
	80% are running code that supports useful IP6 RR types, it will be
	operationally interesting to tell thousands of operators that
	due to a marginal political -potential- disagreement, they must
	upgrade to support new RR types. Or if your statement is that 
	they won't know or care since only the ip6.arpa server has to know,
	that is only marginally palateable, since the many thousands
	of trees and much education over the past five years has gone into
	training people where the IP6 tree is anchored.  Rooting this out
	is not a negligable thing from an operational perspective.

	May I direct all queries for clarification on this issue over
	the next five years to these in favor of this change?  Surely
	if it has the characteristics imputed to it, this should not
	be an onurus request.  :)
--bill
	
--bill

---

From: "Vitali A. Chipitsyn" <[email-masked]>
Date: Wed, 17 May 2000 10:43:31 -0400

> ip6.arpa will make the confusion you fear moot.

I agree with Matt that there is not much of a confusion if DNAME is used. However, I have 
run into the problem of reaching the 512 bytes limit on DNS UDP packets very quickly. We 
have 3 hierarchical levels within our site's IPv6 address space and use a fake ip6.int 
domain which means that *no* public topology hierarchical levels are defined. Therefore, 
adding another level of indirection brings us closer to the 512 bytes limit. I know that 
there have been attempts to solve this limit, but I am outdated on their status.

Also, existence of this 512 bytes limit is another argument to using ip6.arpa as opposed to
in6-addr.arpa.

--vc

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 17 May 2000 15:32:27 -0700 (PDT)

> be a call to try and syncronize these two trees, which will fail. The
> confusion will impact the deployment of IP6. 

I think similar issues of consistency would be present just because
the binary labels are different than the nibble-at-a-time text labels,
even if we had kept the binary labels in ip6.int.

I don't see how using ip6.arpa for binary labels and ip6.int for
the nibble text labels makes maintaining consistency
any harder.

   Erik