I have had no response regarding the policy statements from the authors. It seems to me that many people have not really read the draft, but many may think that "encouraging in-addr is a good idea". As long as the statement is left at a vague 'in-addr is a good thing', a lot of people would agree. But the draft goes much further out of the mainstream.
The draft's approach is much like the approach being used by the "intelligent design" groups to remove the teaching of evolution in schools. If one sticks with the vague statement of "a higher being exists which created the universe", a lot of people worldwide agree. Its not until further investigation reveals that the "intelligent design" folks claim the earth is only 5000 years old, and that evolution shouldn't be taught at all that one might realize they are quite far from the mainstream. Such is the case with this draft: Investigation reveals it is quite far from the mainstream view on a number of subjects, as demonstrated by Savola's remarks, as well as a close read of the draft. I remind people that this draft started out as an attempt at making in-addr mapping maintenance a requirement. After overwhelming rejection of this notion, the draft was "toned down" a bit with more ambiguous language, leaving it with a contradictory name: The 'inaddr-required' draft that strangely didn't require in-addr, according to the proponents. But as Savola's recent comments demonstrate, many people have serious misconceptions about in-addr usage, and they expect this draft to confirm, support, or promote their misconceptions. The promulgation of misconceived notions is harmful to DNS operations. I will make some calls and faxes this week to ARIN, RIPE, and APNIC to ask them to issue a statement on the policy claims made in this draft. There are some technical representatives from the registries on the list: Detailed review and comment would be good, I think. I would argue that since the proposal has gone through a number of *frivolous iterations, that it should be dropped as a waste of time. The wrong policy statements are obviously crucial to the rest of the draft. Without them, the draft completely falls apart. I note also that in 2001, the chairs were about to discard the draft for lack of support. No progress has been made in 4 years, so I'd think its about time to make a call on this draft as a waste of time. [*Frivolous in that the iteration removed no arguments raised against the draft.] I note that almost _2_YEARS_ago, Ray Plzak noted the following about the policy statements. The policy statements _still_ have not been fixed. ---------- Forwarded message ---------- Date: Mon, 31 Mar 2003 08:34:35 -0500 From: Ray Plzak <[EMAIL PROTECTED]> To: [email protected] Subject: RE: I-D ACTION:draft-ietf-dnsop-inaddr-required-04.txt In paragraph 2 the following is stated: "ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger allocations. For smaller allocations, ARIN can provide IN-ADDR for /24 and shorter prefixes." The ARIN policy statement is: "All ISPs receiving a /16 or larger block of space (>= 256 /24s) from ARIN will be responsible for maintaining all IN-ADDR.ARPA domain records for their respective customers. For blocks smaller than /16, ARIN can maintain IN-ADDRs through the use of the SWIP template for reassignments of /24 and shorter prefixes." The policy does not require in-addr service. What it means is that if in-addr service is desired then the responsibility for allocations of /16 or shorter prefixes is that of the ISP receiving the allocation. If the prefix is longer than a /16 and shorter than a /24, then ARIN will provide the service if desired. Ray #---------------------------------------------------------------------- -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 ---------- Forwarded message ---------- Date: Tue, 22 Feb 2005 16:49:21 -0500 (EST) From: Dean Anderson <[EMAIL PROTECTED]> To: Pekka Savola <[EMAIL PROTECTED]> Cc: Daniel Senie <[EMAIL PROTECTED]>, [email protected] Subject: Re: [dnsop] Re: encouraging the use of IN-ADDR mapping I would very much like to hear the authors address their mis-statements of Registries' policies. I've brought this up against every draft so far, and it is still not addressed. ARIN's policy requires ISPs to maintain IN-ADDR for /16 or larger allocations. ARIN's policy says just the opposite. Contrary to the draft, ARIN's policy is more about what it won't do: ARIN says it won't provide DELEGATION for blocks of /16 or larger beyond the first or second octet boundary. It will not provide DELEGATION for blocks smaller than /24. In other words, ARIN won't do RFC2317 delegation. ARIN will remove delegations to lame servers. If you don't have servers to perform IN-ADDR, ARIN is not going to waste the delegation traffic. ARIN wants as little to do with IN-ADDR as possible. As does, it seems, APNIC. Also, the [ARIN] reference link in the draft is incorrect. ARIN's policy is now at http://www.arin.net/policy/index.html#seven1 I didn't check the links provided for APNIC and RIPE policies. Indeed, no registry requires an ISP to provide IN-ADDR mappings for its assigned address space. The statements in the draft are intentionally misleading. The policies simply put the responsibility for maintenance on the recipient of the allocation (usually ISPs) The Registries won't do it. That is a lot different from what the draft claims. The following is a quote from the most current draft, and shows their false assertions about requirements for IN-ADDR: As we can see, the regional registries have their own policies for recommendations and/or requirements for IN-ADDR maintenance. It should be noted, however, that many address blocks were allocated before the creation of the regional registries, and thus it is unclear whether any of the policies of the registries are binding on those who hold blocks from that era. Its hard to read this in any way except with respect to IN-ADDR MAPPING. It makes no sense with respect to IN-ADDR Delegation. Those who held blocks before the creation of the registration have delegation in the same in-addr.arpa as everyone else. The recipient has no control of the in-addr.arpa zone. Only the registries control delegations. It makes no sense to think of the policy of registries' delegation binding the recipient. That isn't possible. It could be possible to 'bind' recipients to provide MAPPING. But that isn't the case. The sentence about address blocks allocated before the creation of the regional registries claims wrongly that it is 'unclear whether policies are binding on blocks from that era'. Implicitly assuming as though IN-ADDR policy might be less binding on some blocks. There is no binding requirement for providing IN-ADDR on any block. Indeed, there is no binding requirement on the registries to delegate in-addr. As an administrator of a block from 'that era', I know a little bit about how those blocks are handled. There are a few grandfathered provisions. In-addr isn't one of them. All blocks from all era's are subject to exactly the same in-addr policies of their respective registry. All blocks are allocated from _some_ registry, whether they were originally allocated from SRI/DARPA, or not. A new registry was designated for old blocks. ARIN provides delegation records for all blocks in its allocation as described by its policies. As does RIPE, as does APNIC. There is no difference in policy or performance. In-addr performs the same whether a block was alloated in 1988 or 2005. However, the paragraph makes it seem like somehow the Registries' policies refer to MAPPING instead of DELEGATION, and that is clearly wrong. As has been said many times by now, No registry requires anyone or any block to provide in-addr mappings. No registry that I know of provides in-addr mapping for anyone but themselves. The draft seems to be a scheme to convince the registries to change their policy by misleading the IETF that this policy already exists. As well as justify the continued abuse of IN-ADDR by applications developers and system administrators. Coincidentally, on Feb 11th, I asked the maintainer of the ADNS resolver to remove code from the adnshost program that prevents it from reporting the in-addr data for any query it decides is not "consistent", according to Pekka's definition of "consistent". The -x option of the adnshost program (similar to the -x option in dig), is supposed to report the in-addr record for the IP address provided. Dig correctly reports the in-addr record. The adnshost program does not. This has little to do with our discussion, except to demonstrate the kind of abuse of in-addr that goes on. Approval of this draft would only encourage more such abuse. Instead, the DNS Operations Working Group should make clear that the operation of programs such as adnshost are incorrect, or at least discouraged. 5. Security Considerations This document has no negative impact on security. While it could be argued that lack of PTR record capabilities provides a degree of anonymity, this is really not valid. Trace routes, whois lookups and other sources will still provide methods for discovering identity. I don't know where to start on this. The concept of DNS-based security certainly has a long history of spectacularly negative impact on security. This statement just seems to deny history. The reason for abuse of in-addr by applications is the mis-placed trust in in-addr shown by Pekka, despite all the lip-service given in the draft. Specifically, though, the notion of anonymity by lack of PTR record is a valid concept held by many, despite the cavalier dismissal of it in the draft. Traceroute uses in-addr, (except in IPV6, where it uses HostInfo, in-addr is presently broken in IPV6) and whois does not give you hostnames. It is not clear what "other methods" exist to discover the hostname of an arbitrary IP address, without in-addr. If in-addr is replaced with generic, autogenerated names the ISP, then there is no point in having in-addr, since in that case it merely spends a lot of time and packets, and diskspace doing what can be done by a single whois lookup. --Dean -- Av8 Internet Prepared to pay a premium for better service? www.av8.net faster, more reliable, better service 617 344 9000 . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html . dnsop resources:_____________________________________________________ web user interface: http://darkwing.uoregon.edu/~llynch/dnsop.html mhonarc archive: http://darkwing.uoregon.edu/~llynch/dnsop/index.html
