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
