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 protected]
https://www1.ietf.org/mailman/listinfo/dnsop
