Dean Anderson (dean) writes:
> A number of the points you raise have already been addressed.
Hi Dean,
Where ?
> The IPV6 Reverse resolution question has been discussed at length in
> DNSEXT previously. In fact, it was proposed to remove reverse resolution
> entirely from IPV6 for just the reason Dr. Huang notes.
Which one ? There's still nothing showing that there effectively
is going to be a bottleneck of traffic to the root. Some curve,
some data points, anything, we could use to extrapolate future
problems from current trends, or even a *simulation* of load
based on guesstimages/projections of network host population would
come in handy.
> A 128 bit IPV6
> address is 16 octets. To perform reverse resolution requires traversing
> 16 levels of DNS tree.
How is that better than 32 steps for the proposed implementation ?
(from the draft, §2.3)
> The Total address space of IPv6 is huge. But, only the Reserve Domain Name
> Servers managing used IP addresses will join the Virtual Hierarchical
> Overlay Network for DNS. And the worst maxium query steps are 32.
> With route cache the query steps will be less than 32. Therefore,
> this strategy for Reverse Resolution is feasible.
Note: I may very well have gotten lost in the logic, and if
there's something I missed, please point it out...
> Even the delegations impose significantly larger
> trees on the registries. It is recognized that this isn't going to be
> very scalable, or even possible.
Again, where ? The references you point to below are somewhat old,
and of course it doesn't make them any less relevant (after all,
IPv6 is only going to be get used more and more), but still, I fail
to see any kind of model that really does show that it will be a
problem.
C. Huitema's argument that the "... operational implications are
daunting",
I can easily identify with -- autoconfiguration, if it does get used,
will mean that everything has to be automatized and most likely dynamic.
Alain Durand does point out that due to the size of ipv6 space,
reverse information for large ranges of IP addresses will have to be
dynamically generated, use wildcard, only record some, or drop.
But it still doesn't say how this is going to be a problem, that
Mr. (not a Dr. it seems) is arguing his draft is the solution to.
> IPV6 proposes to use ICMP Node Identification query instead.
You mean ICMP Node Information ? (RFC4620)
Yes, it definitely looks like an interesting solution. It has issues,
though, for example, the fact that it assumes that every node on
the internet will be reachable so that they can be queries:
(from RFC4620, §8. Security Considerations)
> This protocol has the potential of revealing information useful to a
> would-be attacker. An implementation of this protocol MUST have a
> default configuration that refuses to answer queries from global-
> scope [3] addresses.
... and the protocol doesn't propose implementing a collector/
local aggregator which could handle/reverse proxy such queries at the
edge router or firewall level, so I guess if you've got a firewall,
you haven't got reverse anyway.
> At present, there is an IPV6 reverse
> tree, but it is not guarenteed it will stay. It is for transition--so
> that gethostbyaddr() still works on IPv6 during transition.
That's not the impression I got. Decisions to phase out ip6.int and
use ip6.arpa look to me like ip6.arpa is here to stay. HOW we populate
it -- or rather: how do we make that namespace return something useful,
using gethostbyaddr(), is part of the challenge -- for the reasons
stated by the sources you site.
But I don't see either of these issues in anyway related to the
"the overload of traffic in tree structure" that Mr. Huang says
should be avoided.
> See for example the discussions here:
>
> http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg00931.html
> http://ops.ietf.org/lists/namedroppers/namedroppers.2002/msg01828.html
Cheers,
Phil
_______________________________________________
DNSOP mailing list
DNSOP@ietf.org
https://www.ietf.org/mailman/listinfo/dnsop
