> Apparently people are still having a hard time visualizing use cases for
> ULA-C, so let me try again to lay one out:
> ...
thanks.
> So, again, I see that ULA-C is a very simple solution to fill a very useful
> function that cannot be filled by local ULAs alone (at least without adding
> additional complexity to DNS). Importantly, this functionality does not
> depend on ULA-C providing an additional assurance of uniqueness, but on the
> fact that my block (and its authoritative DNS servers) can be registered,
> and others can query the registered data.
if you want registration, then you want a new kind of RIR PI space, since it
has to be unique, and the registration data has to be made and kept accurate.
> ...
> Now let's say I am thinking a little bit bigger than just my neighborhood,
> and would also like my network to connect to neighboring mesh networks.
i like this vision, it matches my own.
> (This could fairly easily evolve into an arbitrarily large internetwork
> enabling disaster-resistant connectivity across neighborhoods, cities, or
> entire regions.)
yes.
> In order to facilitate troubleshooting, I elect to use ULA-C space for my
> network infrastructure, including router interfaces, (and either rewrite
> source addresses of any packets (presumably ICMP) my routers send out to the
> Internet, or also assign PA space to each interface with something like
> DHCP-PD, so that the router can use IPv6 address selection to use a public
> address for packets destined for public Internet addresses).
i was almost going to snort beer out my nose at how funny that was, until the
millisecond when i realized that you didn't know it was funny to say "in order
to facilitate troubleshooting" and then follow with that description of rube
goldbergesque complexity. why did you leave out the part where the anvil that
had been launched a few moments earlier finally, inevitably, lands on the
coyote's midriff?
but we (both) digress from the real point:
> In a situation like this, I need to be able to resolve PTRs for hosts using
> my neighboring networks' ULA space without any prior knowledge about the
> neighboring wireless network.
which wouldn't be nec'y if both of these networks were in some new kind of PI
space that was allocated out of a prefix designated by IANA for non-DFZ use.
(i keep bringing the discussion back to that point because asking IANA to
designate such a prefix ought to be the IETF's reaction to the ULA-C draft.)
but i still digress, let's get to the meat of it:
> If both networks are numbered out of ULA-C space, this is easy: I send my
> PTR queries to my regular DNS resolver, which has a PA address and Internet
> connectivity, and can resolve the PTR from the DNS server authoritative for
> my neighboring wireless network's ULA-C block.
here you're equating, dangerously in my opinion, three unrelated concepts:
1. "public internet"
2. "PA address"
3. "internet connectivity"
please re-think this in terms of "connectivity realms", of which the DFZ is
one, and the american automotive exchange is another, and every fortune-2000
internal network is another, and every ad-hoc wireless mesh is another. in
these terms, you'd have successfully pointed out that a given host may be in
more than one connectivity realm, and that it's impossible to know in advance
whether a network peer you reach in realm A can reach the same realm B that
you can reach. now take it one step further -- stop according the DFZ any
special status, treat it as just another connectivity realm to which any
given network peer of yours may or may not have access.
> As IPv6 adoption takes hold and dynamic wireless networking becomes cheaper
> and more widespread, I would see this kind of use case, and its many
> permutations, becoming more and more common.
me too.
> Can you describe a way to use existing address types available to small
> networks (PA and ULA-L) and existing DNS technologies to support the
> requirements listed above? If not, I would argue that we should complete
> the process of ULA-C standardization, as it represents the simplest
> available solution to the problem.
i see ULA-C as a giant rubber band and some rocket powered roller skates
which will finally, really, we mean it this time, allow the coyote to catch
that darn roadrunner.
the simpler solution is to recognize the following primary facts of reality:
1. every host needs a lan-scoped address
2. most hosts also need one or more global-scoped addresses
3. each of those global-scoped addresses will be in some connectivity realm
4. many of those connectivity realms will transitively, invisibly, overlap
5. the DFZ or "public internet" isn't special, it's just a connectivity realm
6. of all connectivity realms, the DFZ may not always be the largest one
7. all global-scoped addresses need ongoing reliable DNS and WHOIS support
8. address DNS/WHOIS support is traditionally a regional, bottom-up function
if we can get agreement on those, then the resulting conclusions are easy.
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
