On 2007-06-20 00:07, Scott Leibrand wrote:
Here's a use case for ULA-C that demonstrates its usefulness, and
demonstrates why reverse DNS for ULA-C blocks is a valuable enough
service that we shouldn't purposefully break it for the public
Internet. Let's say, for example, that I'm a very small ISP with IPv6
PA space from my upstream(s). I give out subnets of that PA space to my
customers in an automated dynamic fashion, and I don't run BGP, so I
don't need or want PI space.
However, I do have some routers with interfaces that need numbering, and
I'd rather avoid renumbering them when I change upstreams. Since ULA-C
is cheap and easy to get, I register myself a block of it, and use it to
number my router interfaces. Since I'd rather my customers saw DNS
names instead of IPv6 addresses in their traceroutes, I delegate the
reverse DNS for my ULA-C block to a nameserver on my upstream's PA
space, and set up proper PTR records for all my routers.
Now, whenever anyone does a traceroute into or out of my network,
they'll see ULA-C addresses in the traceroute. They don't need to
actually reach those addresses if they're not in my network, but they
will at least be able to resolve PTR records for them, so that the
traceroute cleanly shows whose network they're traversing.
And whenever I decide to switch upstreams, all I have to do is update my
DHCP servers, update my nameserver's A record to an IP out of my new
upstream's PA space, and we're done. I don't have to renumber a single
router, I don't have to run BGP, and I don't have to litter the DFZ with
another PI block.
Scott, what feature of existing ULAs makes them unsuitable for this
usage today? In the ridiculously unlikely event of a ULA prefix clash,
this would be detected up-front when trying to set up the reverse
delegation, and then you'd simply generate a different ULA prefix.
Brian
-Scott
[EMAIL PROTECTED] wrote:
IMHO, if reverse DNS is provided, it should be required that the
authoritative DNS servers have non-ULA addresses.
Not only that, but since the goal of ULA-C addresses is to provide
something similar to what site-local was going to be, perhaps the RIRs
should operate authoritative reverse DNS servers for the entire ULA-C
space to ensure that reverse DNS for ULA-C addresses is permanently
broken on the public Internet. Of course, anyone who wants to run their
own internal reverse DNS in their own private network, or networks,
should feel free to do so.
Is the goal of this document merely to define the ULA-C address range
well enough to throw it into the lake and see if it sinks or swims? Or
is there some requirement to provide a more workable form of site-local
addresses?
--Michael Dillon
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
