Subject: Re: [dnsop] Re: encouraging the use of IN-ADDR mapping (fwd)

From: Dean Anderson <[email-masked]>
Date: Mon, 28 Feb 2005 18:57:31 -0500 (EST)

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-masked]>
To: [email-masked]
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-masked]>
To: Pekka Savola <[email-masked]>
Cc: Daniel Senie <[email-masked]>, [email-masked]
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