On Tue, Jun 19, 2007 at 04:54:36PM +0100, Jeroen Massar wrote:
> When the prefix is 'local' why would that need to be rooted into the global
> Internet? I get the point about having unique addresses out of the same
> namespace, but I don't get why reverses then have to be supplied too.
1) by putting it in the global space, every single recursive dns server
in an organization doesn't have to special case (read: slave or conditional
forwarding) ULA reverse zones to get accurate PTR records.
2) two (or more) different organizations who agree to use ULA-C space
(e.g. as part of a partnership) don't have to do even funkier dns tricks
than #1 to have accurate PTR records for both sides.
best of all: by delegating, we avoid the AS112 problem as well.
additionally, there is a draft going through the dnsops WG speaking to
the advantages and pitfalls of reverse dns. wherever possible we should
encourage PTR records to be accurate as possible for as many people as
possible. delegating ULA-C allocations to globally reachable nameservers
hurts no-one and can only potentially be useful information.
> What is the point of that? How can a ULA address reach a global unicast
> address or for that matter, how is such a ULA address, which is most likely
> going to be the sole user of those reverse servers going to contact any of
> the root servers, .arpa servers, RIR servers etc to actually find out where
> that server is located in the first place?
devices on ULA addresses could contact recursive nameservers that have
a global unicast address and can resolve on their behalf. some machines
may even have both a ULA-C address AND a global address.
> Are those people going to do NAT from their ULA space? Then please directly
> kill this whole ULA proposal completely. If NAT is involved in anyway it
> should never see daylight.
this has nothing to do with NAT, but thanks for bringing out the boogeyman.
> Also, registered the DNS servers in the global DNS thus means that those
> machines will be Internet connected, then what is the point of ULA again?
the delegation should be to global unicast space, not to ULA-C space.
you'll have to find another reason to ask "what's the point?", i guess.
> reverse tree, then there will also be ULA AAAA's in the forward tree, oh boy
> we are going to have a nice mess there...
people put RFC1918 addresses in A records today and the internet hasn't
imploded as a result yet. if you're a partner of mine, lookup an RFC1918
address i have in the global dns, and you can reach that address through
a prefix i give you as part of our partnership: that RFC1918 record in
the global DNS is useful to you. what's the difference between that and
ULA-C, besides the fact that i don't have to worry about which company's
network addressing tomorrow's merger/acquisition/partnership/etc uses..
like i do with RFC1918.
if you have no relationship with me (or my potential ULA-C space) then
what does it matter to you if i put ULA-C addresses in my forward zones
or have my reverse ULA-C space delegated to a globally reachable server.
i have a great counter-argument: since routing slots are oh so valuable
and are driving policy decisions (e.g. minimum allocation size in ARIN)
and engineering efforts (e.g. SOMEONE MIGHT LEAK ULA-C!), perhaps malloc()
slots in your DNS servers are so important that you might inadvertantly
cache one of my records that points to space you can't reach. in the
interest of the memory footprint DNS servers everywhere we can't allow
ULA[-C] addresses to ever be in the global dns space!
--
- bill fumerola / [EMAIL PROTECTED]
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
