[ppml] draft-ietf-ipv6-ula-central-02.txt use cases

[Scott Leibrand]

Paul Vixie wrote:
>> Apparently people are still having a hard time visualizing use cases for
>> ULA-C, so let me try again to lay one out:
>> ...
>>     
>
> thanks.
>   

And thank you for your thoughtful and reasoned response.

>> 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.
>   

Yeah, to me that's what ULA-C should be, a block of space defined by the 
IETF, delegated by IANA to the RIRs, and administered as "unique local" 
or "private PI" space.  I don't care whether we call it ULA-C and 
allocate it out of FC00, or if we call it private PI and chose a 
different subnet.

>   
>> ...
>> 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.
>
>   
>> 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:
>   

I'm not sure which aspects of what I outline you would consider 
unnecessarily complex, but I agree that is tangential to our discussion, 
so we can follow that up offline if you like.

>   
>> 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:
>   

I'm not sure this is a digression.  What you're describing is exactly 
what I think ULA-C should be: a well-known block (that DFZ operators 
would filter announcements from) from which PI assignments can be made 
without the restrictions required on public PI space to avoid routing 
table bloat.

>   
>> 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.
>   

While I agree with this analysis in the abstract, and would not opposed 
a private PI policy based on it (as it would likely be quite robust), 
I'm not sure that we can simply see the public Internet as just another 
connectivity realm.  I believe that the history of the Internet, and the 
architecture we have built up to support it (particularly the addressing 
architecture, as defined by the IETF and delegated from IANA to the RIRs 
to ISPs and to end sites), require that we consider the public Internet 
to be a unique connectivity realm.

>   
>> 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
>   

Link-local.  Done.

> 2. most hosts also need one or more global-scoped addresses
> 3. each of those global-scoped addresses will be in some connectivity realm
>   

Agreed.

> 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
>   

Perhaps not, especially depending on your definition of "largest".  
However, any connectivity realm that approaches the public Internet in 
terms of the number and diversity of interconnected participants will 
require an addressing and routing framework to meet the various needs of 
its different participants in a mutually acceptable manner.  As long as 
we're talking about IPv6, that addressing framework will need to coexist 
with the addressing framework of the public Internet.  Given the current 
Internet addressing architecture, that means we need some way to 
partition off part of the IPv6 address space, designate it as "not to be 
routed in the DFZ", and assign pieces of that space to anyone wishing to 
internetwork in a connectivity realm other than the DFZ.

> 7. all global-scoped addresses need ongoing reliable DNS and WHOIS support
> 8. address DNS/WHOIS support is traditionally a regional, bottom-up function
>   

Agreed, which is why I advocate that ULA-C space (or whatever we end up 
calling the space that fills the needs described above) be assigned to 
Regional Internet Registries (RIRs), who can then assign it to end users 
and provide appropriate DNS and WHOIS support.  I would also support 
allowing the RIRs to allocate such non-DFZ-routed space to Local 
Internet Registries (LIRs), so that they can serve their 
members/customers by reassigning such space and providing DNS and/or 
WHOIS services in a method (and possibly a connectivity realm) not 
served by the RIRs directly.

> if we can get agreement on those, then the resulting conclusions are easy.
>   

Given our slightly differing opinions on the special significance of the 
"public Internet" connectivity realm, I would love to hear what 
conclusions you draw based on the above points.  I would draw the 
following conclusions:

    * There is a need to allocate and assign IPv6 address space, in a
      non-restrictive manner, to entities wishing to internetwork
      outside of the public Internet's DFZ.
    * There is a need to provide reliable DNS and WHOIS support for
      these addresses.  The methods of providing such DNS support should
      include, but should not be limited to, allowing registrants to
      delegate DNS authority to servers reachable from the public
      Internet.  Other methods for providing reliable DNS support for
      these addresses should be explored, but no method should be
      allowed which imposes an undue burden on Internet DNS infrastructure.

-Scott