Subject: [DNSOP] fresh comments on dnsop-reve...-01.txt

From: Edward Lewis <[email-masked]>
Date: Tue, 13 Feb 2007 19:03:33 -0500

Referring to:
http://tools.ietf.org/id/draft-ietf-dnsop-reverse-mapping-considerations-01.txt

#3.3  Differences in IPv4 and IPv6 operations
#
#   RIRs allocate address blocks on CIDR [RFC4632] boundaries.

That's not completely true, the RIR's allocate on ranges of numbers, 
and a range can be expressed in CIDR notation.

There are cases of incorrectly allocated ranges in years past 
(possibly even before the RIRs came into being) that might allocate 
say 323.231.223.1-256.  (Instead of 0-255.)  There are allocations on 
the books like that, the CIDR is quite complicated.

Perhaps you want to say "RIRs allocate addresses ranges that are not 
easily expressed in the rigid classful representation of the IN-ADDR 
portion of DNS."

#   Unfortunately, the IN-ADDR zones are based on classful allocations.
#   Guidelines [RFC2317] for delegating on non-octet-aligned boundaries
#   exist, but are not always implemented.  There is not a similar
#   concern for IP6.ARPA.

The truth is that this is a concern in IPv6, but instead of having a 
granularity of 256 addresses, it is now just 16 addresses.

...

#   depends.  It may be supposed that IPv6 will make this "reachover
#   problem" worse, because of the likelihood of longer delegation chains
#   in IPv6.

I don't think there will be more delegations in IPv6.  A v6 address 
will go through the same leveles as v4 - IANA/RIR to ISP to consumer. 
Maybe there will be more delegations but I would say "likely". 
Unless you are referring to the number of labels in each delegation.

#4.1 Delegation considerations
#
#   It is desirable that Regional Registries and any Local Registries to
#   whom they delegate encourage reverse mappings.

This is too loose.

Does this mean we want them (RIRs) to offer RFC 2137 (classless) 
delegations?  I'm not sure what form is the best for the IETF to 
"tell" the RIRs what to do - the RIR's are "member driven" and 
policies concerning this would be best made through their vetting 
practices.  I am not sure what to recommend to put here, what is 
needed is a statement that an RIR policy proposer can point to and 
say "let's follow this IETF recommendation."

# block

I think the best word is "range" and not "block."  The connotation of 
the latter is that there's an inherent relationship of addresses at a 
certain "bitmap" depth, i.e., all /24's have similar properties.  The 
truth is that in some networks, the /24 is important, in others it is 
just half of a /23 or quarter of /22.  It's not like all the numbers 
under +1-312-555-wxyz have something in common (modulo number 
porting).

#4.3  Usage and deployment considerations
#
#   Site administrators are encouraged to think carefully before adopting
#   any test of reverse delegation, particularly when that test is
#   intended to improve security.  The use of reverse mapping does not
#   usually improve security, and should not be a default policy.  In

I would change the last complete sentence in the passage quoted to:

The use of reverse mapping as a security tool is debatable and making 
serious judgements based on it is discouraged as there are many ways 
a determined malicious element can falsify the data.

...or something like that.  What I'm getting around is that some get 
"warm fuzzies" from checking the reverse map and there's no denying 
that it is nice to see all the ends tie up.  Yes, I know that "warm 
fuzzies" is not macho security talk.

-- 
-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-
Edward Lewis                                                +1-571-434-5468
NeuStar

"Two years ago you said we had 5-7 years, now you are saying 3-5.  What I
need from you is a consistent story..."

_______________________________________________
DNSOP mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dnsop