Subject: Re: [homenet] tunnels as way to disambiguate .local

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Aug 2012 08:17:32 +0100

On 01/08/2012 05:48, Curtis Villamizar wrote:
...
> fridge.sitelocal. is a FQDN with site local scope. 

And therefore intrinsically evil, just like 10.0.0.0/8 is intrinsically evil.

IMHO we shouldn't be discussing how to make it work less badly; we should
be discussing how to avoid it entirely.

    Brian

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 01 Aug 2012 10:17:06 -0400

In message <[email-masked]>
 
> be discussing how to avoid it entirely.

Brian,

Not being connected to the Internet and not having any configuration
at all might also be intrinsically evil, but that's the situation when
a consumer takes some gadget out of the box.

What we are trying to accomplish with the sitelocal is a way to name
things on a local network that have no domain name assigned through a
registry and have not had a domain name assigned as part of some
subdomain of the provider.

Even if the homenet WG was extremely thoroughthe gadget did 100% of
what we specify and implemented everything perfectly, we can't control
the user who almost never has a domain name of their own or the ISP
that can't be bothered delegating some subdomain of theirs to a
customer.  The customer then has no global domain to hang names off of
and has no choice but to not use DNS or make use of a sitelocal domain
with site local scope.

So sitelocal is inherently needed, either during a transition (until
the uplink comes up at least for the first time and a domain name is
learned) or permanently (if no domain name ever gets delegated to the
residential customer site).

Curtis

ps - Yes - it is inherently evil.  So is not delegating rDNS IMHO.
     But we can't control those MSO and ILEC residential ISPs.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 01 Aug 2012 15:26:51 +0100

Synthesise a pseudo-TLD from the ULA prefix.

    Brian

---

From: Michael Thomas <[email-masked]>
Date: Wed, 01 Aug 2012 09:42:57 -0700

> be discussing how to avoid it entirely.

I think the implications of my note is that there really isn't anything that
needs to be done here. If you want to use naming that requires that you
be in some topology-defined boundary, then tunnel back to that network
if you're not there. VPN technology is pretty well understood, after all,
and there are probably a lot of reasons you might want to do that besides
naming.

That said, my interpretation of the requirements is that we want to do
something with names such that they are quasi-global, or truly global.
I'm inclined to agree that grafting those requirement onto .local is most
likely the road to madness.

Mike

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Aug 2012 12:52:32 -0400

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
    Brian> And therefore intrinsically evil, just like 10.0.0.0/8 is
    Brian> intrinsically evil.

    Brian> IMHO we shouldn't be discussing how to make it work less
    Brian> badly; we should be discussing how to avoid it entirely.

Right, but we have installed base.
Based upon comments in Jabber yesterday, I think that the right way is
for fridge.local mDNS to return a series of SRV records in the
additional information, one of which would contain a FQDN (having a GUA)
for the fridge, if it had one.

I don't know exactly what that would look like, but it seems like the
right process: discovery gives us a name, and the name is sometimes a
FQDN.  That would also have solved Stuart's problem printing to
bluehawaii, had his laptop CUPS bookmarked bluehawaii.apple.com rather
than bluehawaii.local (nothing that bluehawaii.apple.com works just fine
when in the office)

-- 
Michael Richardson <[email-masked]>, Sandelman Software Works

---

From: Ray Hunter <[email-masked]>
Date: Wed, 01 Aug 2012 19:22:28 +0200

Isn't it possible to combine the two ideas of sitelocal. with 
pseudo-domains generated from ULA to give a usable solution?

e.g. fridge.<pseudo-ula-domain>.sitelocal.

Don't you then avoid the evilness of identifier overloading (my fridge 
versus your fridge) and potential problems with clashing TLD's?
e.g. someone registering a bunch of <pseudo-ula-domain>. TLD records as 
their company brand for manual administration.

How else are homenet devices going to know not to bother the root 
servers with fridge.<pseudo-ula-domain>. NS queries given that TLD's are 
now basically a free for all?

Wouldn't it also potentially give a unique anchor point for storing 
DNSSEC zone signing with an implicit sitelocal. trust anchor?

regards,
RayH

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 01 Aug 2012 13:25:12 -0400

In message <[email-masked]>
 
> Synthesise a pseudo-TLD from the ULA prefix.

If the whole ULA is used, then the scope is single host.  If the ULA
prefix is used, then the scope is all reachable ULA which is the same
as sitelocal but with an obscure name.

Curtis

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Aug 2012 14:09:36 -0400

>>>>> "Kerry" == Kerry Lynn <[email-masked]> writes:
    Kerry> Actually, I think the problem may be that CUPS insists on
    Kerry> re-resolving the name every time it prints, rather than
    Kerry> trying the GUA that it would have learned at initial
    Kerry> discovery.

Do we want applications caching mDNS replies into configuration files?
I think not, and I think the DNS people will shout loudly about that.

    Kerry> Nobody seems to be complaining about the need to be on-site
    Kerry> to discover the service initially.  The issues seem to be

No, in fact, it's a feature.

    Kerry> my desk, unless I connect my host to that same link.  I
    Kerry> cannot remember a time when I needed to use it remotely.

I regularly print to both my work and home printer remotely (yes, over
IPv6. The CUPS server speaks IPv6 even if my home printer speaks only
USB).  I do this will all sorts of paperwork, receipts for online
expenses, etc.   Yes, I sometimes print to the wrong printer.
I also regularly print to these printers when "offline", knowing that
CUPS will punt it out when I get "home"

I believe that Google Cloud Print is getting close to eliminating my
need to own one of these infernal mechanical devices. 

    Kerry> BTW, I agree with the earlier comment that the may be several
    Kerry> good reasons to include VPN tunnels in the homenet
    Kerry> architecture.

They exist. It would be nice if our secure setup protocol for homenet
could also be leveraged to setup remote access.

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 01 Aug 2012 14:48:31 -0400

In message <[email-masked]>
Michael Richardson writes:
 
>  
> >>>>> "Brian" =3D=3D Brian E Carpenter <[email-masked]> writes:
> Michael Richardson <[email-masked]>, Sandelman Software Works=20

It might be reasonable for mDNS or dynamic DNS to populate the FQDN
with an A and AAAA record and create a CNAME in local or sitelocal
that points to the FQDN.  Tools like host or dig would report the
CNAME, the FQDN, and the final A and/or AAAA records if sitelocal was
in the search path before the domain.

I'm not sure how that works with CUPS bookmarking.

Curtis

---

From: Evan Hunt <[email-masked]>
Date: Wed, 1 Aug 2012 19:17:27 +0000

> I think not, and I think the DNS people will shout loudly about that.

Hm... I'm a DNS people, but I'm not sure I object to this.  You'd want
some mechanism for clearing old records out after the devices had been
gone from the network for a long-enough time, but that's not intrinsically
hard.

> USB).

I'm of the opinion that "remote access from offsite" should be a service
you can configure your printer to provide, but which is not the default.

In my ideal world (please indulge me in a moment of handwaving), you plug
in your printer, and tell it what its name is (or let it pick its own
default such as "LaserPrinter-3"); it announces itself to the local network
as providing local printing, and its name is placed in the .sitelocal
domain.

*If* you check the box for "let the outside world print to me" -- which you
and I might want to do but most people wouldn't -- then it announces itself
as providing both local and remote printing, and its name is placed in
.sitelocal and then mirrored into the globally addressable domain that
you'd previously configured for your network: by preference, that would be
your private domain name, but if you don't have one of those then it could
mirror into a namespace controlled by your ISP, Apple, DynDNS or whatever.

If you were printing something, and you a found a printer via service
discovery which indicate that it could provide remote access, then you'd be
given the option to bookmark its global name and use it when you're away;
if it isn't configured for remote access then you woulnd't be given that
option.

A similar mental model could apply to the "fridge" and "lamp" examples
we've been kicking around as well -- you won't normally *want* them to be
globally accessible, but if you do, you should tell them so and let them
work it out with your network.  (This is the point I was trying to make at
the mic yesterday, but I'm not sure it came across.)

-- 
Evan Hunt -- [email-masked]
Internet Systems Consortium, Inc.

---

From: Michael Richardson <[email-masked]>
Date: Wed, 01 Aug 2012 18:53:57 -0400

>>>>> "Evan" == Evan Hunt <[email-masked]> writes:
    >> Do we want applications caching mDNS replies into configuration
    >> files?  I think not, and I think the DNS people will shout loudly
    >> about that.

    Evan> Hm... I'm a DNS people, but I'm not sure I object to this.
    Evan> You'd want some mechanism for clearing old records out after
    Evan> the devices had been gone from the network for a long-enough
    Evan> time, but that's not intrinsically hard.

so, after your ISP renumberers you (not a flash renumber), or if you
change routers (get a new ULA), or change ISPs, you have to discover
your printer again?

    Evan> I'm of the opinion that "remote access from offsite" should be
    Evan> a service you can configure your printer to provide, but which
    Evan> is not the default.

Uhm, so let's seperate discovery, naming, and reachability from
authorization.  (being able to reach it doesn't mean you can print...)

    Evan> In my ideal world (please indulge me in a moment of
    Evan> handwaving), you plug in your printer, and tell it what its
    Evan> name is (or let it pick its own default such as
    Evan> "LaserPrinter-3"); it announces itself to the local network as
    Evan> providing local printing, and its name is placed in the
    Evan> .sitelocal domain.

okay, so far.

    Evan> *If* you check the box for "let the outside world print to me"
    Evan> -- which you and I might want to do but most people wouldn't

I agree that this is a box.  I'd like to see some more authentication
and authorization things happen, but that's a detail for CUPS/IPP.

What's relevant here is that we have a new requirement for sitelocal
mDNS:

 we need to signal via mDNS from the printer to the holder of the FQDN
zone (probably the CPE).

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Aug 2012 11:22:38 +0100

> as sitelocal but with an obscure name.

Correct, but the name is unambiguous, which IMHO is a MUST property for
anything that looks like an FQDN. We have to live with .local but it
should be just a nasty memory like 10.0.0.0/8 fifty years from now.

I would suggest instructing IANA to reserve all TLD strings that start
with "local" and using something like .local-fd952a92a67d to name
the homenet domain. It's only a convenience to use a ULA prefix; it's
simply a unique string that the CPE needs to generate anyway, but it
has no significance beyond that.

The point is that if an FQDN or a URL including such a name escapes
from its home, it cannot be misinterpreted at another site. By contrast,
printer3.sitelocal might easily be misinterpreted elswhere.

   Brian

> .

---

From: Michael Richardson <[email-masked]>
Date: Thu, 02 Aug 2012 10:20:37 -0400

>>>>> "Brian" == Brian E Carpenter <[email-masked]> writes:
    Brian> Correct, but the name is unambiguous, which IMHO is a MUST
    Brian> property for anything that looks like an FQDN. We have to
    Brian> live with .local but it should be just a nasty memory like
    Brian> 10.0.0.0/8 fifty years from now.

    Brian> I would suggest instructing IANA to reserve all TLD strings
    Brian> that start with "local" and using something like
    Brian> .local-fd952a92a67d to name the homenet domain. It's only a
    Brian> convenience to use a ULA prefix; it's simply a unique string
    Brian> that the CPE needs to generate anyway, but it has no
    Brian> significance beyond that.

huh, you want to do it that way?
Why not fd952a92a67d.local?

I'm asking for clarification, not disagreeing.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Aug 2012 15:28:50 +0100

> Why not fd952a92a67d.local?

Yes, that would work too, as long as nobody gets cute and starts
resolving the TLD in the open Internet.

    Brian
> ------------------------------------------------------------------------
> 
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 2 Aug 2012 10:52:31 -0400

On Wed, Aug 1, 2012 at 3:17 PM, Evan Hunt <[email-masked]> wrote:

> Printing is an example, but this could apply to other apps as well (it's
just
that there are already millions of deployed mDNS printers about).  One thing
to keep in mind is that it is easier to modify the end hosts (OS providers
regularly push updates) and print servers than the printers themselves.

The idea assumes you need to be on-site to discover and add the printer
in the first place (establishing some level of "trust" in the process).  The
mDNS draft enforces this by filtering out a) multicast discovery responses
that don't have a link-local multicast destination address, or b) unicast
responses that don't have the same source prefix as the querier.

CUPS (and I presume other print systems) already cache a great deal of info
about my printer and additionally caching a GUA if it was advertised does
not
seem a reach.  Here's an example from my /etc/cups/printers.conf:

<Printer Officejet_Pro_8500_A909g>
UUID urn:uuid:dbb55a90-16ba-3534-5c4a-6da0e0d327a1
Info Officejet Pro 8500 A909g
MakeModel HP Officejet Pro 8500 A909g Series
DeviceURI
dnssd://Officejet%20Pro%208500%20A909g%20%5B4C0EA4%5D._pdl-datastream._tcp.local./?bidi
...
</Printer>

Here you see the service instance name "Officejet Pro 8500 A909g" which
appears in my print dialog, together with other unique info that prevents it
from being confused with yours, if you had one and I was visiting.

If, at service discovery time, my printer had advertised a GUA then I'm
suggesting it could have been cached as well.  In that case, the print
system
would formulate a *unicast* DNS query to that GUA for a AAAA RR named
"Officejet%20Pro%208500%20A909g%20%5B4C0EA4%5D".  If a response
is returned, that strongly implies the printer is reachable and no
resolution
is necessary (this would also solve the problem I currently have with
printing
to other LAN segments).

If that query *fails* then indicates I need to do a fresh resolution.
 Here's
where Michael's idea to advertise a FQDN binding (which can also be cached)
comes in.  But first...

** TERMINOLOGY ALERT **
I suggest we reserve the term "FQDN" to refer to names that have been
fully qualified in the global DNS namespace (as they all probably were when
the term was first coined) and use something like "LQDN" to refer to names
that are qualified in a locally-served (non-delegated) DNS zone.

...so by FQDN I mean that the original mDNS query return something like
  foo.local. CNAME foo.example.com.
(Yes, I realize we may need to invent some new RR to express the
LQDN-to-FQDN mapping).

> I think this is part and parcel of advertising the GUA and/or LQDN-to-FQDN
mapping, as above, or not, under control of the user.  Alternately, this
functionality could be deployed in a print server which just connects via
USB to the printer.  Such a server could be tightly coupled to the client
functionality and provide mutual authentication, privacy, etc.  Of course,
you get all these things if you just tunnel back to your site in the first
place ;-)

> Yep.  I'm pretty sure this could be accomplished by some form of "gateway"
(like the print server I described above).

-K-

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 2 Aug 2012 11:10:58 -0400

On Wed, Aug 1, 2012 at 1:22 PM, Ray Hunter <[email-masked]> wrote:

> e.g. fridge.<pseudo-ula-domain>.**sitelocal.
>
> Two points.  As I mentioned at the mic yesterday, this maps onto the
ULA distribution problem.  You'd either have to identify a deterministic
"root" ULA for this "zone" or guarantee that multiple such zones within
a given site all appear as being "on-site".  Second, is the unique string
part of the name or a zone of the domain?  mDNS recommends that all
host names in .local. appear as a flat namespace, but this is only a
recommendation.  We humans started using surnames some time ago
to disambiguate our identities regardless of location (although I note that
many such attempts were of the form "O'There").

> How else are homenet devices going to know not to bother the root servers
> with fridge.<pseudo-ula-domain>. NS queries given that TLD's are now
> basically a free for all?
>
> I think this is a darned good point.  It saves every resolver from having
to parse ".local-<mumble>." to decide whether it should delegate or not.

> Wouldn't it also potentially give a unique anchor point for storing DNSSEC
> zone signing with an implicit sitelocal. trust anchor?
>
> An even better point.

-K-

>>  ______________________________**_________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/**listinfo/homenet<https://www.ietf.org/mailman/listinfo/homenet>
>

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 2 Aug 2012 10:57:40 -0400

On Wed, Aug 1, 2012 at 2:09 PM, Michael Richardson <[email-masked]>wrote:

<snip>

> The VLAN service access point may be the only thing I (and perhaps many
others) would ever want to advertise in the global DNS namespace.

-K-

--

---

From: Curtis Villamizar <[email-masked]>
Date: Sat, 04 Aug 2012 16:06:02 -0400

With all due respect, any suggestion to use the ULA in a domain name
produces either a domain that is unique to one host or a domain that
is every bit as global as sitelocal, depending on whether by stating
"ULA prefix" you mean the local ULA or the well-known global ULA
prefix.

In rfc4193:

   Local IPv6 unicast addresses have the following characteristics:

      - Globally unique prefix (with high probability of uniqueness).

      - Well-known prefix to allow for easy filtering at site
        boundaries.

      [...]

If you mean the first (the local ULA prefix), then the domain is
unique to one host.  My computer could never find my fridge using the
hostname "fridge" unless it knew every ULA on the local network and
created an entry in the dns search path.  Very long entries in the dns
search path are a very bad thing (tm).

If you means the second (the assigned prefix under which all ULA fall)
then the domain is common to all hosts in the universe that generate a
ULA address.  The only difference is it is
<host>.<somethingveryobscure>.sitelocal.

Curtis

---

From: Ray Hunter <[email-masked]>
Date: Sun, 05 Aug 2012 08:58:34 +0200

I disagree. The context of my message is that there should be some 
identifier that can disambiguate the namespace per Homenet. I'm talking 
about using the ULA to generate a HomenetID for use in the namespace. 
See RFC6281.

The HomenetID and DNS subomain (or as you put it 
"<somethingveryobscure>") may be generated by one unique host (e.g. each 
Homenet border router) based on a ULA.  But that does not mean it cannot 
be discovered by all hosts and routers in the Homenet (via some bunch of 
discovery mechanisms such as automatic prefix distribution for 
router-router and DHCPv6 for router - fridge).

The HomenetID will remain constant as long as the ULA of the border 
router remains constant. If it appears to vary (because the border 
router changes) then highly mobile nodes will get some indication that 
they may not be connected to their own Homenet, and ask for user input 
to accept an update. Static nodes would only know their local HomenetID, 
and if it changed they could be set to always accept the update without 
user input. Eventually you would probably end up with a search list 
linked to the number of border routers the end node has ever 
encountered, but end nodes can automatically age out old entries.

We might also want to be able to manually override the auto-generated 
HomenetID to cover the case where border router hardware is replaced by 
the user, but that's no different to MAC address cloning on CPE's in the 
past (where ISPs used the MAC address of the CPE as an identifier in 
management systems).

Sure there's a downside in complexity of the namespace. The potential 
upside of this approach is that the same 
<somethingveryobscure>.sitelocal. zone file could also be mounted as a 
secondary on <somethingveryobscure> .<ISP DNS root> or 
<somethingveryobscure> .<employer's DNS root> if the ISP or enterprise 
wished to provide this service for global name resolution. Highly mobile 
nodes would only need two items in their DNS search list, the search 
list can be pretty much auto-generated, and they can use the same name 
resolution technology (DNS) wherever they are located. It also 
completely avoids trying to synch mDNS with DNS, which I think you'll 
agree is likely to be very difficult.

> Curtis Villamizar <mailto:[email-masked]>
> 4 August 2012 22:06

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 05 Aug 2012 08:22:44 +0100

On 05/08/2012 07:58, Ray Hunter wrote:
> identifier that can disambiguate the namespace per Homenet. 

That's what I meant too. The only point is to avoid ambiguity in the
namespace. The only reason for using a ULA prefix to create a unique
identifier string is to avoid the bother of inventing a new method of
creating a unique identifier string. The name has no relation to
addressing or routing whatever. If you prefer some other way of creating
a string with a very high probability of uniqueness, that's fine.

    Brian

> I'm talking

---

From: Michael Thomas <[email-masked]>
Date: Sun, 05 Aug 2012 08:17:36 -0700

> a string with a very high probability of uniqueness, that's fine.

So I think I understand the point of a ULA like suffix. However, that doesn't
translate into a name that anybody would use. Locally, you could just have it
as part of the DNS search list, I suppose, but that's limited to resources
that are accessed locally which .local more or less works now. So it seems a
small gain with some ugliness to boot.

What I really want though is to have resources that I can access regardless of
where I am though. I don't see how this is of any help at all for that problem.
The only thing I see is that either I make the name globally accessible -- in which
case I'd use a real DNS name, or to make myself topologically part of the .local[site]
namespace. Isn't that what this all boils down to? TANSTAAFL?

Mike

PS: the 40 bits of a ULA was constrained by v6 prefix length. if we were to do this
     for sitelocal, we'd probably want to add some bits to better cope with the birthday paradox.
     iirc, 64 bits is a lot safer.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 05 Aug 2012 19:32:24 +0100

Regards
   Brian Carpenter

> small gain with some ugliness to boot.

I don't think that elminating ambguity in scope is a small gain. The best
defence we have against ambiguous addresses is an unambiguous namespace.

> where I am though. I don't see how this is of any help at all for that problem.

At least it will *tell* you that the FQDN is meaningless where you are, if
you are out of the homenet.

> case I'd use a real DNS name, 

Absolutely - a local namespace is always second best to a genuine FQDN.

> or to make myself topologically part of the .local[site]
> namespace. 

Right - and giving it a unique name can only help in that process.

   Brian

Isn't that what this all boils down to? TANSTAAFL?

---

From: Tim Chown <[email-masked]>
Date: Sun, 5 Aug 2012 22:12:38 +0100

On 1 Aug 2012, at 05:48, Curtis Villamizar <[email-masked]> wrote:

> fridge.sitelocal. is a FQDN with site local scope.  fridge.yourdomain
> is a FQDN with global scope.

The apparent consensus in Vancouver was to use a global domain if you have one available otherwise use an "auto-generated" unique local domain.

Tim

---

From: Evan Hunt <[email-masked]>
Date: Mon, 6 Aug 2012 02:06:56 +0000

> The apparent consensus in Vancouver was to use a global domain if you
> have one available

I agree there was consensus on this point.

> otherwise use an "auto-generated" unique local domain.

...but I did not hear a clear consensus on this one. 

(For the record, though I'm open to being convinced otherwise,
my current preference is for a reserved generic namespace such
as ".local" and/or ".sitelocal", and *not* for ULA-style domains.)

---

From: Ted Lemon <[email-masked]>
Date: Sun, 5 Aug 2012 22:18:34 -0400

> as ".local" and/or ".sitelocal", and *not* for ULA-style domains.)

i wasn't able to participate in this discussion because I had other business during homenet, but I'm a bit frustrated by this conclusion.   Domains like .local seem like a good idea to geeks like us, but how many regular users ever use them?   How many have a mental model of how naming works that would allow these domains to function for them?

IMHO, we shouldn't promote bad solutions, and .local is a bad solution.   Whether we come up with some way to leverage a ULA to present things sensibly in some UI is another question, but if we are trying to come up with a solution for geeks, why not come up with a _real_ solution, instead of the .local hack?

---

From: Evan Hunt <[email-masked]>
Date: Mon, 6 Aug 2012 03:28:32 +0000

> i wasn't able to participate in this discussion because I had other
> business during homenet, but I'm a bit frustrated by this conclusion.

I was speaking for myself and I believe the issue is in flux; please
don't take it as a "conclusion". :)

> IMHO, we shouldn't promote bad solutions, and .local is a bad solution.

IMHO .<hexidecimal-gibberish> is also a bad solution.  It's, at least
potentially, a worse one: you buy a new router, and suddenly your devices
all have new names and your bookmarks don't work.  To make them work again,
you have to remember the hexidecimal-gibberish that was assigned by your
previous router and configure it to use the same one.  Ugly.

I'm not really happy with either of these choices, but I'm less unhappy
with .sitelocal.

> Whether we come up with some way to leverage a ULA to present things
> sensibly in some UI is another question, but if we are trying to come up
> with a solution for geeks, why not come up with a _real_ solution,
> instead of the .local hack?

I'd love to hear the plan.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 06 Aug 2012 10:05:29 +0100

> previous router and configure it to use the same one.  Ugly.

I do agree that expecting ordinary users to keep track of a pseudorandom
string is unreasonable. Maybe we can take a hint from mailman. When
you install a new CPE router, and it's unable to discover the current
unique string, you could be asked to enter your existing unique string,
but also be offered the option of the router creating a new one.

So the requirements seem to be

1. A discovery mechanism so that new devices on a homenet can find the
local unique string.

2. The string and the discovery mechanism need to survive a cold start
and the replacement of the CPE router (in all scenarios except a "factory
reset"). That means a distributed solution.

3. If there really is no unique string, the CPE router generates one,
unless the user prefers to type it in.

Undoubtedly .sitelocal is simpler.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Aug 2012 08:00:39 -0400

> don't take it as a "conclusion". :)

Fair enough.  :)

> IMHO .<hexidecimal-gibberish> is also a bad solution.

Yes, definitely.   If that gibberish is ever visible to the user, we've done it wrong.

> It's, at least

Even forgetting the hexadecimal gibberish, if there is any sort of local name that is based on the router, switching routers is always going to be ugly.   Ideally we want the solution to be tied to something "in the cloud" so that the replacement router can restore its brains.

> I'd love to hear the plan.

For geeks, you register a domain, or pay a small monthly fee for a subdomain of something like dyndns.org.   Maybe the brains for your router live there too, so that if you replace it, you can just punch in your domain, and it figures out the rest.   This works for geeks; everyone else uses friendly names presented in a UI.

Of course, I also think that ULAs ought to be allocated rather than guessed at, which I gather is not a popular position.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Aug 2012 10:17:34 -0400

On Aug 6, 2012, at 12:58 AM, Unindicted Coconspirator wrote:
>> Domains like .local seem like a good idea to geeks like us, but how many regular users ever use them?
> Every single user who has added a printer to OS X or Linux in the last
> several years.

No.   You think that because you're a geek like the rest of us.   Every single user who has added a printer to OS X has done so from a UI that presented a list of printers doing bonjour.   This list named the printers by brand.   The user clicked on a printer from the list, and that was the end of it.   The user certainly never saw Canon_PIXMA_900.local in any UI.   I'm fairly sure this is true of Linux as well.

> Apparently multicast DNS works even in the absence of mental models.

It works in the sense that if you know the name of the machine you are trying, and tack ".local" on the end, there is a small chance that you will get to that machine.   But usually you won't, because various network glitches will have caused the machine to rename itself to machine-04.local by the time you try to address it, even though there were never any machine.locals other than that one.   mDNS is a nice hack, but fairly useless for the particular application we are talking about.   It's pretty good for service discovery (showing a list of printers in a UI).

> A bad solution to what problem?

Well, indeed.   We are clearly talking about different problems.

> Several people spoke in favor of supporting existing solutions (a.k.a.
> running code).
> I'd like to see us gauge consensus for this point here on the list.

I'm against it, as you know.   The problem with the current running code is that namespaces overlap, and the UI has no way to detect or present this.   Settling on a half solution because we have running code is the wrong way to go.

> I tried to show in the print server example that the client
> may cache unique information about the server (GUID, unique host name, etc.) that makes
> disambiguation a non-issue.

But it's not a non-issue, because the user doesn't know the GUID, and hence doesn't know which "fridge" is the right one.   (I'm just repeating Stuart Cheshire here, from a conversation we had last week).   So the GUID doesn't give us the information we want, and indeed can produce confusing results in the UI.   A per-site naming scheme, with a nice UI on top of it, _does_ give us that.   Fridge can be fridge (home) and fridge (here) in the UI, for instance, because we know we aren't at home.

> It was agreed that name-<random>.local. is equivalent to
> name.local-<random>. from a CS standpoint.

Here you are definitely arguing about the wrong problem.   At the presentation layer, both are equivalent, and both are wrong.   What we want is not fridge-1.local and fridge-2.local, but fridge (here) and fridge (there).

> - it is relatively easy to retrofit this behavior to hosts and servers
> and difficult (or
> impossible) to reflash existing printers

You don't need to update the printers.   Just have the CPE device say where you are.   This stuff can all happen at the presentation layer—at the protocol layer, it's perfectly fine if the printer is "printer.local" as long as the CPE says what "local" means, and the UI presents it correctly.

> - using .local-<random>. based on ULA means complexity equivalent to ULA
> distribution problem.  This is a big issue when homenets are coalesced and
> can't be solved by routing alone.

In general, the homenet merge is not likely to be a homenet merge in the sense you mean, but rather a decommissioning of one of two routers, and a migration of the devices formerly connected to the one router to the network operated by the other router.   In this case, a CPE-advertised location will solve the problem in a nice, intuitive way—all the devices will appear in the UI as being connected to the local network.

> I think you're referring to a _different_ problem; resolving your
> site's resources
> while you are mobile.  Am I mistaken?

I'm claiming that this isn't a separate problem.

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 6 Aug 2012 10:40:35 -0400

On Mon, Aug 6, 2012 at 8:18 AM, Ted Lemon <[email-masked]> wrote:
> On Aug 6, 2012, at 12:58 AM, Kerry Lynn wrote:
> No.   You think that because you're a geek like the rest of us.

I think there may be two kinds of geeks on this list, those who want to take
corporate networks and scale them down for home users and those who
want to extend existing home networks and make them more functional.
These two points of view may lead to a common solution for any given
problem, but that's not yet evident.

> Every single user who has added a printer to OS X has done so from a UI that presented a list of printers doing bonjour.   This list named the printers by brand.   The user clicked on a printer from the list, and that was the end of it.   The user certainly never saw Canon_PIXMA_900.local in any UI.   I'm fairly sure this is true of Linux as well.
>
Sorry, not sure I'm getting your point.  Yes, the user is using a UI to solve
her problem.  The UI in this case is using (multicast) DNS.  DNS requires
a zone to scope the query.  That zone is ".local.".  My car probably has
15 microcontrollers and I use them when I drive to the market whether I'm
aware of it (which I don't want to be) or not.

What appears in my list is a _default_ SRV record name consisting of the
printer model plus "gibberish" (in my case "Office Jet Pro A909g [4C0EA4]").
The gibberish is the least significant 24-bits of the MAC address (printed on
the box, on a sticker near the network port, on the test page that ejects from
the printer, and from the setup menu on the printer's screen.  The user is
given the chance to change the name when the printer is added; thereafter
it is only slightly more complicated to change it.

Another advantage to adding gibberish to the SRV name (aside from those
I listed earlier) is that it reduces the probability of name conflicts.  There
can be many sources for this gibberish, but it is relatively easy to use some
intrinsic identifier.  The "hack" above is slightly worse than a five-digit zip
code, slightly better than a nine-digit zip code - the point being that users
already deal with a certain amount of gibberish in their lives.

> It works in the sense that if you know the name of the machine you are trying, and tack ".local" on the end, there is a small chance that you will get to that machine.   But usually you won't, because various network glitches will have caused the machine to rename itself to machine-04.local by the time you try to address it, even though there were never any machine.locals other than that one.

Hard for me to buy this, unless the device is hearing from itself via
tape delay.

> mDNS is a nice hack, but fairly useless for the particular application we are talking about.   It's pretty good for service discovery (showing a list of printers in a UI).
>
Yes, there are at least two problems: how to disambiguate name collisions
in locally served zones and how to access remote resources.  We agree that
these problems collapse if you outlaw locally served zones.  We disagree
on the utility and/or reliability of locally served zones.  This is why I'm
pushing back and saying the problems you raise with mDNS are solvable.

I think that in the short run it is easier to connect users to their existing
networks (e.g. through tunnels) than it is to educate them on the workings
of DNS and require them to deploy a global zone before they can connect
to any device.

> But it's not a non-issue, because the user doesn't know the GUID, and hence doesn't know which "fridge" is the right one.   (I'm just repeating Stuart Cheshire here, from a conversation we had last…
And I'm saying it can just as easily be presented as fridge(this) and
fridge(that).

While I haven't tried the experiment, I believe that if you and I both had HP
Mumble Jet printers and I was connected to your homenet and I tried to print
something then my printer would not even appear as an available option,
because under the hood the UI has determined that my printer is not on the
local network.

> Here you are definitely arguing about the wrong problem.   At the presentation layer, both are equivalent, and both are wrong.   What we want is not fridge-1.local and fridge-2.local, but fridge (h…

I thought I was discussing the problem referenced in the subject line...

> In general, the homenet merge is not likely to be a homenet merge in the sense you mean, but rather a decommissioning of one of two routers, and a migration of the devices formerly connected to the one router to the network operated by the other router.

Even though we can locally route between them just fine?  This sounds like a
new thread...

> In this case, a CPE-advertised location will solve the problem in a nice, intuitive way—all the devices will appear in the UI as being connected to the local network.
>

> I'm claiming that this isn't a separate problem.
Well, the definition of "solution" certainly depends on the problem statement.
If you define the problem as being able to access remote resources then there
are existing ways to solve this, e.g. tunnels and dyndns.  At every step in
the transition, the dominant paradigm is likely to be the one that is most
understandable and least expensive.

-K-

---

From: Michael Thomas <[email-masked]>
Date: Mon, 06 Aug 2012 09:00:00 -0700

> No.   You think that because you're a geek like the rest of us.   Every single user who has added a printer to OS X has done so from a UI that presented a list of printers doing bonjour.   This lis…

Speaking as a geek who not only remembers NBP but actually wrote
an implementation of it, I have to say that it never even occurred to
me that there is some sort of IP equivalent of NBP.  It just doesn't
fit the same mental model as fqdn's which is how I and just about
everybody else thinks of net naming.

In fact, I'm being far too generous with fqdn's. People don't even think
about them other than maybe top level brand names.com. Nowadays,
people expect to just search for whatever's relevant. If it doesn't come
up in search, it must not exist.

I have to say that part of my struggle here is just understanding the
problem(s) coming in from the cold. I see lots of hammers being applied
to things that may or may not resemble nails, but much less about the
real world aspects of this problem, cf search above.

Mike

---

From: Michael Thomas <[email-masked]>
Date: Mon, 06 Aug 2012 09:10:30 -0700

> For geeks, you register a domain, or pay a small monthly fee for a subdomain of something like dyndns.org.   Maybe the brains for your router live there too, so that if you replace it, you can just…

I think this is a similar issue with real live ULA's too: where does the
authoritative memory for site addressing ultimately reside? In real sites,
you pay people to make certain that such things are cared and tended for.
I don't know where that memory or clue comes from in a homenet.

> Of course, I also think that ULAs ought to be allocated rather than guessed at, which I gather is not a popular position.

I wonder how many fd:0:0:0:: networks are out there despite rfc 4193? If there
is any human involvement required whatsoever, I expect that the number
is very high.

Mike

---

From: Evan Hunt <[email-masked]>
Date: Mon, 6 Aug 2012 18:25:09 +0000

On Mon, Aug 06, 2012 at 10:17:34AM -0400, Ted Lemon wrote:
> Here you are definitely arguing about the wrong problem.   At the
> presentation layer, both are equivalent, and both are wrong.   What we
> want is not fridge-1.local and fridge-2.local, but fridge (here) and
> fridge (there).

If you want access to fridge (there), then fridge (there) has to have a
globally-addressable domain name.  If it doesn't have one, then there's
no way for you to reach it, and I can't think of any reason for a
well-designed UI to display it.  If "fridge.local" is available, then
it must be fridge (here).

As I see it, those who have devices that they wish to reach remotely will
have to either own their own domain names, or acquire delegated subdomains
from e.g. their ISP or their hardware vendor (I could see Apple including
one in the price of an Airport Express, for example).  If your network
is configured with such a name, and if you have a printer configured to
allow remote access, then the name it advertises and which your UI will
cache will be something like "printer-2.my-personal-domain.com" or
"printer-3.smithfamily1137.mac.com".  I think we have general consensus
in the WG that this is a good approach for remote access.

So now we're just talking about people who *don't* choose to have their
devices remotely accessible; those people's devices would use non-globally-
addressable names.

Now (as I understand it) the primary advantage to using ".<ULA>" or
".<ULA>.local" naming is the ability to cache separate lists of discovered
devices for different networks that you happen to visit.  That is, if I'm
visiting Ted's house, I'd like to see the list of devices I've previously
found on Ted's network, and if I'm at home, I'd like to see the list of
devices on mine.

But I don't see a requirement for a network name to be globally unique
if it isn't globally addressable.  I could simply *choose* a name to
disambiguate my network from Ted's, just as most of us choose our own
SSIDs.  You'd want to choose one unique enough that you wouldn't run
into duplicates very frequently, but that would be at most a
recommendation, not a requirement.

So let's say my house uses names in the "evanshouse.local" namespace.
For most visitors, this is sufficient to separate things out.  If a
visitor happens to have the same network name as I do, then my devices
and theirs could get mixed up in their lists of cached names, and that's
suboptimal and inconvenient, but not (as far as I can see) particularly
harmful.

If I buy a new router, it will ask me what network name to use, and I
will easily remember that I've been using "evanshouse".  There's no need
to look up the hexadecimal gibberish supplied by my previous router.

If I absolutely refuse to give my router a network name, then it could
choose one for me, and in that event a ULA-style name seems like a good
choice.  But I would expect it to be a rare one.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Aug 2012 14:51:48 -0400

The problem is that you are assuming (a) that only geeks will ever want remotely-addressable networks (and hence, we don't need to specify a mechanism for automatically setting that up, because they can do it manually), and (b) that no network will ever go from being locally-addressed to globally-addressed.

Both of these are self-fulfilling prophecies that I would like to prevent fulfilling themselves.

Oh, and (c) that a person with a local-only homenet will never take their laptop or cell phone to someone else's house where a naming scheme conflict happens to exist, and accidentally tweak something because of the clash.

Global naming implies state, among other things.   mDNS is sort of stateless, except of course that it's not completely stateless, and breaks badly in some cases when you treat it as if it is.   So state is, IMHO, a better solution even in the local-only situation, because you're owning the fact that you have state, and you have to go to the trouble to get it right.   And it has a clean upgrade path to the local/remote situation.  And it doesn't surprise anyone with naming clashes when visiting the neighbors' network.

---

From: Michael Richardson <[email-masked]>
Date: Mon, 06 Aug 2012 16:33:49 -0400

>> want is not fridge-1.local and fridge-2.local, but fridge (here) and

    Evan> If you want access to fridge (there), then fridge (there) has
    Evan> to have a 
    Evan> globally-addressable domain name.  If it doesn't have one,
    Evan> then there's 
    Evan> no way for you to reach it, and I can't think of any reason for a
    Evan> well-designed UI to display it.  If "fridge.local" is available, then
    Evan> it must be fridge (here).

No, the fridge must have a globally reachable address (GUA) to be reachable.

The name does not need to be globally addressable, but if it is, that
certainly helps in solving the problem.

What we are discussing, is how my (mobile) device can retrieve/discover
a pointer to a name that can be easily translated into an address.  

We want this pointer rather than just having my device cache the GUA that it
got from mDNS:  caching the GUA from mDNS works in the short term, but
fails after a renumber.  

Tunnels are okay, but to use them, but has to get the DNS search order
and the DNS server list right, and that's walled garden territory.
*If* we are going to turn each home into a walled garden, then let's be
aware that we are doing that.

---

From: Evan Hunt <[email-masked]>
Date: Mon, 6 Aug 2012 21:44:07 +0000

On Mon, Aug 06, 2012 at 02:51:48PM -0400, Ted Lemon wrote:
> The problem is that you are assuming (a) that only geeks will ever want
> remotely-addressable networks (and hence, we don't need to specify a
> mechanism for automatically setting that up, because they can do it
> manually),

Not at all -- lots of non-geeks buy domain names, and non-geeks
can also get delegated subdomains from their ISP's.  Making it easy
for them to set up is a UI problem, and not a very hard one.  You
can't use .<ULA> to reach a remote device anyway.

> and (b) that no network will ever go from being locally-addressed to
> globally-addressed.

Not really.  If you acquire a globally-resolvable domain name, then your
printer could detect the fact and start advertising the name
printername.domain.com alongside printername.myhouse.local; your
laptop could then cache the new name, note that it's a FQDN, and
begin showing it to you in a list of available printers when you're
away from home.

> Oh, and (c) that a person with a local-only homenet will never take their
> laptop or cell phone to someone else's house where a naming scheme
> conflict happens to exist, and accidentally tweak something because of
> the clash.

I think this concern is fairly minimal, and could be addressed by noting
that the router MAC address has changed and popping up a warning dialog.

> breaks badly in some cases when you treat it as if it is.   So state is,
> IMHO, a better solution even in the local-only situation, because you're
> owning the fact that you have state, and you have to go to the trouble to
> get it right.

Explain what you mean by "state" here please?  I'm not sure I'm
following you.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 6 Aug 2012 18:38:13 -0400

> can't use .<ULA> to reach a remote device anyway.

We're talking past each other.   I am not saying that .ULA is the right solution.   And as far as it being a UI problem, this is half true.   If the underlying protocol can set things up cleanly and reliably and automatically, *then* getting the UI right is a UI problem.   But if the underlying protocol doesn't allow a UI that a regular user can navigate, it doesn't matter how good the UI is.

> begin showing it to you in a list of available printers when you're

Requiring the printer and host to adapt to network conditions in the way you describe is not a homenet issue except in the sense that the homenet would have to present the information to the host or printer to allow it to do what you describe.   Which is precisely what (I thought) we were discussing.

> that the router MAC address has changed and popping up a warning dialog.

You are talking about this as if you were the programmer.   But we are the IETF, not the UI programmer.   It's not our job to get the UI right—it's to make it *possible* to get the UI right.

> Explain what you mean by "state" here please?  I'm not sure I'm

State is stuff that either your host or some server remembers between packet exchanges.   So for example, your laptop probably remembers its own name, and provides it using mDNS and DHCP.   That's state.   If the DHCP server records it in the DNS, that's also state.  No state is when nothing is recorded anywhere.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 7 Aug 2012 01:39:02 +0000

> No, the fridge must have a globally reachable address (GUA) to be reachable.

You are correct, of course, and I was being unclear; sorry about that.  
I was trying to reflect what I thought I heard in the discussion in
Vancouver, though, which was that a FQDN or the equivalent would be the
best way to handle naming of remotely accessible devices.  It seemed to
me that we had rough consensus on that point (perhaps I was mistaken),
but not on naming of devices on "island" networks.

> aware that we are doing that.

For the purposes of my mom's house, I do think "walled garden" is the
appropriate default setting, but our design should allow the default
to be overridden without great difficulty.

I think this general plan would meet those goals:

    1) All discoverable devices on all networks MUST answer
       to a locally reachable name, such as <devicename>.local,
       <devicename>.sitelocal, <devicename>.<networkname>.local,
       <devicename>.<ULA>, <devicename>-<ULA>.local, etc. (We
       haven't settled the naming convention here. I personally like
       <devicename>.<networkname>.local, with <devicename>.<ULA>.local
       as a fallback in the event of the network's owner failing to
       configure a network name);

   2) Networks configured to allow remote access to devices
      SHOULD have a globally reachable domain name, either owned
      by the user or in a vendor-managed namespace;

   3) If a device is configured for remote access and is on a
      network which has had a FQDN configured as in (2), then
      in addition to the locally reachable name described in (1),
      the device MUST also answer to "<devicename>.<FQDN>".

---

From: Evan Hunt <[email-masked]>
Date: Tue, 7 Aug 2012 02:21:18 +0000

>       the device MUST also answer to "<devicename>.<FQDN>".

And, I'm not sure these are within the scope of homenet, but to explicitly
state the design principles I'm trying to support with the previous
recommendations:

  - Applications wanting to cache information about discovered devices
    should use the most globally-reachable name available for each device.
    In other words, if it has a FQDN and a local-only name, cache the FQDN.  

  - When presenting cached information about devices, applications should
    only display local-only domain names if they were cached from the
    current local network.

  - When possible, preference should be given to the use of human-readable,
    human-memorable, and ideally human-selected names.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 07 Aug 2012 13:45:33 -0400

Ray,

I agree with the intent of RFC6281 aka Apple BTMM, although not with
many of the details of the implementation.

I agree that syncing mDNS and DNS might be difficult and I propose we
avoid using mDNS.  A compromise is if a FQDN exists in DNS, both DNS
and mDNS return a CNAME to the FQDN for local or sitelocal queries.

A bad assumption is that anything on the same subnet deserves some
level of trust just as a matter of having been connected to that
subnet.  The BTMM builds on this bad assumption by providing a means
to make it appear as if remote hosts are on the same subnet or at
least site by effectively using ULA as a host ID and tunneling the ULA
of the remote machine.

A much better way of doing things would be to use a GLA if available,
particularly for IPv6 where no NAT should ever be needed.  For
security, on the same LAN segment or not, exchange some credential,
such as a private key.  This could be done at home the way most *ix
people do it (put on USB stick and copy, exchange some insecure way
with fingerprint verification, respect key signing by a trusted
entity, etc), or for the more typical homenet customer with an
insecure transfer encrypted with a shared secret (same password typed
in two places, where one place could be the web page used to configure
the consumer oriented junk such as printer).

Delegating a sub-domain is a necessary part of any good solution that
involves remote access to the homenet.  sitelocal is different
everywhere.  <ula>.ula-based-sitelocal is unique but available only at
the site.

We (both in the IETF and in consumer product worlds) sometimes stand
on our heads trying to work around horribly insecure home and office
devices and practices that are hidden behind firewalls.  Using
firewalls has been proven time and again to be ineffective.  In the
office, one compromised PC can compromise an entire enterprise or at
least the subnet it is on if weak security is in use behind the
firewall.  Same at home if "Mom" shows up with her old windows98 PC
and an equally old PCMCIA 802.11a/b card.

How may of us have been in an office where an email from IT explained
that the current local network slowness is due to very high virus
activity (behind the firewall!) and fear not because IT is on it?

If there is a way to discover the ULA being used at a local site, then
printer3.<ula>.ula-based-sitelocal is functionally equivalent to
printer3.sitelocal - either way it is the printer that is found if you
ask for printer3 and you (or cups) don't specificy a FQDN that you
learned earlier.  If the first printer3.sitelocal was a CNAME for a
FQDN, then an application could cache the mapping of printer3 to that
FQDN or at least inform the user of the FQDN or inform the userwhen
specifying printer3 results in a different FQDN than previously.

Curtis

In message <[email-masked]>
Ray Hunter writes:

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 7 Aug 2012 14:46:39 -0400

>> aware that we are doing that.
I'm of the opinion that in a "walled garden" scenario, the tunnel endpoint may
be the only resource that needs a global name / address.  I note that dyndns
supports a wide-area DNS-SD beta (ability to populate PTR, SRV, and TXT
RRs) and I'm going to look into this approach as an alternative to BTMM.

> to be overridden without great difficulty.
I am generally supportive of this approach; certainly it would focus the
discussion between now and Atlanta.

>        configure a network name);
+1, with the caveat that ".local." has special semantics (multicast
DNS-like requests to FF02::FB, port 5353) defined by
http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns

>       by the user or in a vendor-managed namespace;
I'd like a bit more explanation re: this requirement.  In general it seems
there is no relation between a network and a domain name.  Exceptions
would include ".local." (maps to the local _link_, and therefore to the
prefix(es) assigned to that link; or domains ending in ".in-addr.arpa.".
http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd section 11 has
a method for determining the preferred registration zone(s) based on
a host's address.

>       the device MUST also answer to "<devicename>.<FQDN>".
I like to see us reserve "FQDN" for host names that are registered in
the global DNS namespace, and use "LQDN" (or some other alternative)
for host names in locally served zones.  Any support for this?

-K-

---

From: Michael Thomas <[email-masked]>
Date: Tue, 07 Aug 2012 12:11:40 -0700

On 08/07/2012 11:46 AM, Kerry Lynn wrote:
> be the only resource that needs a global name / address.

Just checking, but we all think that naming is a separate issue
from reachability, right?

Mike

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 7 Aug 2012 15:19:27 -0400

> from reachability, right?

I certainly think so.

I also think the idea that you need to "disambiguate" .local is
completely broken.  Once you need to disambiguate, you're already into
a situation where .local is the wrong answer.  MIF at least has an
excuse for needing to sort out different resolution contexts.  What's ours?

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 07 Aug 2012 15:54:39 -0400

>>>>> "Michael" == Michael Thomas <[email-masked]> writes:
    Michael> Just checking, but we all think that naming is a separate
    Michael> issue from reachability, right?

It's separate.

The question is: does the set of names you can resolve depend upon the
connectivity that you have? (the "reachability")  

I think that this is a form of security through obscurity, and I'd
rather that the various carriers who want to impose walled gardens on their
video-over-3G-to-smartphone systems (causing changes up to the
application layers) would do something different.

I overheard a snippit of conversation last week from Lorenzo about what
Android will be doing to "support" walled garden DNS.  I can't repeat
it, because I didn't hear the answer...

---

From: Jim Gettys <[email-masked]>
Date: Tue, 07 Aug 2012 16:00:18 -0400

> connectivity that you have? (the "reachability")  
Yes.

> it, because I didn't hear the answer...

Many corporations also hide internal names from the global DNS.  This
isn't just a carrier "thing".

It is possible to configure bind to "do the right thing" to query
different name servers in different part of the name space.  So it is
technically possible to set up name resolution to work when tunnels come
and go.

I take no position as to whether these corporations are sane about their
security policies, however.
                - Jim

---

From: Michael Thomas <[email-masked]>
Date: Tue, 07 Aug 2012 13:08:44 -0700

> application layers) would do something different.

As a security property was mainly what I was getting at. We're
not thinking that .local is bringing us anything on the security
front wrt reachability (privacy being a different issue). So it
seems we all hopefully agree.

Now what to with about the privacy issue... bletch. .local[site]
has similar considerations along those lines it seems to me,
though the mechanisms are different confusing the issue even
more.

Mike

---

From: Evan Hunt <[email-masked]>
Date: Tue, 7 Aug 2012 21:28:08 +0000

> from reachability, right?

Separate, but in the context of recommended configuration for home networks
under the control of non-geeks, I'd say they're related.  In that context,
we would like reachable devices to have names, and we would like devices
that are reachable remotely to have names that are resolvable remotely.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 07 Aug 2012 22:32:20 -0400

In message <[email-masked]>
Michael Richardson writes:
 
> >>>>> "Brian" =- Brian E Carpenter <[email-masked]> writes:

I'd prefer mDNS returns a mapping of printer3.local to a CNAME
printer3.fqdn and DNS returns a mapping of printer3.sitelocal (or
localsite if you prefer) to CNAME printer3.fqdn.  In both cases, if
there is a subdomain delegated by the provider, then fqdn is that
subdomain, and if no subdomain has been delegated, then the fqdn is of
the form <ula>.local (ie: fd952a92a67d.local in your example).

An application can (though none today do, cups for example could be
changed) obtain the query results using the partial domain name (ie:
printer3) and gethostbyname2 to get an address and then use
gethostbyaddr to do an rDNS lookup to get the FQDN if
printer3.sitelocal was first in the DNS search path.  If the mapping
from printer3.sitelocal were to change, the user could be given a
choice to use the new printer3.sitelocal or use the old one through
the FQDN.  Multiple mappings of printer3.sitelocal could be retained,
such that printer3 yielded a list each time a request was made to
print using this unqualified name.

Of course that would mean rDNS would have to work.

Curtis

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Aug 2012 13:03:11 +0100

> from reachability, right?

It certainly is. But see http://tools.ietf.org/html/draft-carpenter-referral-ps
especially section 4.2 "FQDNs are not sufficient".

   Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Aug 2012 10:09:36 -0400

> especially section 4.2 "FQDNs are not sufficient".

I thought one of the things we were trying to do was to address
exactly the failure modes in that section of the I-D?

Perhaps I'm being naive, but I've been working from the assumption
that, if you want to talk to something on the Internet, you need an
unambiguous way to identify it.  Historically, the best we've had for
that has been the DNS, because it provides a layer of indirection so
that you can have stable identifiers in the face of changing IP
addresses.  

Given the way the relevant markets have gone, it turns out that DNS
names are rather harder to administer and use for ordinary end users
than we might like.  But there's no reason that has to persist, and it
seems to me that if we're going to solve the problems people have
using homenet-type resources on the global Internet, then solving the
DNS piece in a user-friendly way is going to yield greater benefit
than alternatives like ginning up some trick to make mDNS names
sometimes work outside their natural context.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 08 Aug 2012 16:12:10 +0100

> exactly the failure modes in that section of the I-D?

Yes, I guess that's right. I hadn't looked at it that way.

> that you can have stable identifiers in the face of changing IP

What's actually happened (IMHO) is that people trying to solve the
reference problem have come up with additional ID spaces to solve their
particular problem - often hanging them off a trouble-free FQDN to
get the top level of uniqueness for free. But then they have to invent
things like STUN, ICE or supernodes to get connectivity to those IDs.

> sometimes work outside their natural context.

I'm inclined to agree. If we phrase it in terms of specifically
eliminating the problems in my draft, I'll even be happy about it ;-).

   Brian

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 08 Aug 2012 13:09:00 -0400

Snipped most of this message.

> for host names in locally served zones.  Any support for this?

Yes this is a good suggestion.

Examples:

  printer3 is unqualified.

  printer3.local. in mDNS is a LQDN.

  printer3.sitelocal. (or any of the <giberish>.special-tld variants,
  including any based on ULA or alignment of the stars) in DNS is a
  LQDN.

  printer3.<global-dns-domain>. is a FQDN.

Note that for both LQDN and FQDN above, a trailing dot exists.
printer3.local.<global-dns-domain>. is and always was a valid FQDN
even before mDNS existed.  local is only reserved when used as a TLD.

Curtis

---

From: Kerry Lynn <[email-masked]>
Date: Wed, 8 Aug 2012 13:38:25 -0400

> even before mDNS existed.  local is only reserved when used as a TLD.
Yes, a helpful clarification.

-K-

---

From: Andrew Sullivan <[email-masked]>
Date: Wed, 8 Aug 2012 14:22:27 -0400

>   printer3.local. in mDNS is a LQDN.

Except, of course, that it's not a "DN" at all: it's not a domain
name.  It's an mDNS name.  Different protocol on a different port.
Most notably, mDNS always uses UTF-8 and DNS often does not, and
normally when you want to look up a Unicode string in the global DNS
what you actually look up is a name made of A-labels.

This is problematic, because if you just put 

    http://café

in your browser's URL bar, you're going to get different behaviour
depending on your network, your browser, and your operating system.

I'm aware that from the user's point of view, they're all just names,
but I don't think it helps us as protocol people to gloss over the
differences among different name technologies that are all in use at
the same time.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 08 Aug 2012 14:39:12 -0400

In message <[email-masked]>

Brian,

MIF may be trying to solve the problem the wrong way.  Providing a
mapping of DNS to loopback address has long been used (by routers) to
provide a stable reachable address.  The routing cost to reach that
loopback interface (which can change many times for an active
connection) is used to determine which physical interface gets used to
reach the loopback.  For example if one interface is connected to an
ethernet which gets isolated due to a router failure, the other
interface is used because routing tells us that one of them is
unreachable.

Multihoming of course pokes holes in the routing tables and causes
some routing table bloat.  This has always been a problem and IPv6
does nothing to improve the situation that existed in IPv4 two decades
ago with a lot of small providers and large enterprises using dual
provider multihoming.

If we are concerned with hosts that have multiple interfaces both
leading to parts of the homenet, that is easily solved.  Multihomed
homenets is a whole different problem, but solvable if redundancy is
to the same provider.  A conditional static route can be advertised
within the provider, with these routes having limited scope (for
example using BGP communities).  If this practice were to become
commonplace (I doubt it, no consumer provider has that sort of
redundancy in the last mile), then the provider would have to limit
the scope of these more specific routes to a small subset of their own
topology.

I get the impression that if NAT didn't exist, then
draft-carpenter-referral-ps would server no purpose.  Is this draft
entirely motivated by problems caused by NAT?

Curtis

---

From: Evan Hunt <[email-masked]>
Date: Wed, 8 Aug 2012 18:52:07 +0000

> name.

Also not "qualified", as long as we're quibbling.  But I do think the
distinction between FQDN and <thing we're talking about> is a useful one
to have terminology for, and "LQDN" does get the job done even though it
doesn't make proper acronymic sense; I suggest we continue using it here
in the short term and plan on switching to a more precisely accurate term
by the time we start producing RFC's.

I don't have spare cycles to participate in the bikeshedding, but I'll
be happy with anything that agrees with the definition previously
proposed for "LQDN".

---

From: Curtis Villamizar <[email-masked]>
Date: Wed, 08 Aug 2012 15:49:56 -0400

In message <[email-masked]>
 
> what you actually look up is a name made of A-labels.

Good point.  I agree.  Change this to:

    printer3.local. in mDNS is not a domain name at all

Perhaps mDNS should not have used DNS in the name.  It might be
possible to tie mDNS into DNS such that a DNS resolver could return
something useful for a printer3.local query in which case
printer3.local would be a LQDN.  Without that tie in, it is not.

Curtis

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Aug 2012 08:17:22 +0100

> be happy with anything that agrees with the definition previously

As far as I can see there are still two kinds of LQDN:

ALQDN - ambiguous, or potentially ambiguous, names (like printer.local)
ULQDN - unambiguous, or almost certainly unambiguous, names (like printer.<gibberish>.sitelocal)

I will be unhappy if ALQDNs are allowed except as legacy.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 09 Aug 2012 08:33:17 +0100

> entirely motivated by problems caused by NAT?

I don't think so. There are other causes of disjoint address space,
which existed even before we had NAT or specialised firewalls -
router ACLs for example. Certainly NAT is the major cause today (and
NPTv6 will propagate the problem into IPv6). v4-only and v6-only
islands will probably arise too.

Regards
   Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Aug 2012 07:51:25 -0400

> ALQDN - ambiguous, or potentially ambiguous, names (like printer.local)

That doesn't need a new name.  We have a name for that: "relative".
See RFC 1034 section 3.1.

> ULQDN - unambiguous, or almost certainly unambiguous, names (like printer.<gibberish>.sitelocal)

That example is strictly speaking a relative name, too, since it isn't
qualified by the root label.

But my point upthread was not about bikeshedding the things we call
this, but to observe that there are different naming technologies (we
concentrated on DNS and mDNS names, but we also have NetBIOS and llmnr
names.  The latter is very similar to but not exactly the same as
mDNS.  We can only wish that NetBIOS names are all gone).  I think the
impulse to try to get these to work together from the user's
perspective is right, but for the purposes of protocol development we
need to attend to the fact that they're all just different
technologies.

> I will be unhappy if ALQDNs are allowed except as legacy.

Me too, but since they're built right into RFC 1034 (which is still
STD 13), I think we're dreaming.  We might as well wish that the world
be freed from NAT.

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Kerry Lynn <[email-masked]>
Date: Thu, 9 Aug 2012 10:17:21 -0400

>> ULQDN - unambiguous, or almost certainly unambiguous, names (like printer.<gibberish>.sitelocal)
Change the leftmost '.' to '-' and I'm with you.

> need to attend to the fact that they're all just different
We all agree we shouldn't call them FQDNs, so that's progress.

The distinction I was trying to draw was not which protocol is used
for resolution, nor the degree of ambiguity in the name, but that these
names are defined within a local scope (e.g. without recourse to
recursive DNS lookups outside the site boundary).  I feel that names
such as those in RFC 6303 would also qualify by my definition, so
maybe we should call them Locally Served DNS Names or similar.

I also want to draw attention to terminology Erik Kline used in his
discussion of http://tools.ietf.org/html/draft-kline-default-perimeter,
the notion of "inside the home" versus "The Internet".  I think this is
a very useful model to enforce with users as it can be applied
equivalently to naming, discovery, addressing, and security.

>> I will be unhappy if ALQDNs are allowed except as legacy.
That's exactly the point.  mDNS isn't going away, so let's fix the issues
and leverage it as a basic capability.

-K-

---

From: Ted Lemon <[email-masked]>
Date: Thu, 9 Aug 2012 10:24:40 -0400

> and leverage it as a basic capability.

NAT isn't going away either.   Should we fix its issues and leverage its basic capability as well?

(Seriously.   Just because something isn't going away doesn't mean we should standardize on it.)

---

From: Michael Thomas <[email-masked]>
Date: Thu, 09 Aug 2012 07:35:29 -0700

> (Seriously.   Just because something isn't going away doesn't mean we should standardize on it.)

It may not be going away, but it never had its debutante's ball either.

I just did a thoroughly scientific and completely non-anecdotal study
by conducting a rigorous and peer reviewed survey asking my friends
on facebook what they do when they want to configure their home router.

The results:

o typed in 192.168.x.x  -- 3
o uses global name from vanity domain -- 1
o suspicious that this might be a trick question -- 1
o used a name that took advantage of mdns -- 0

Mike

---

From: Don Sturek <[email-masked]>
Date: Thu, 09 Aug 2012 08:37:30 -0700

Hi Michael,

Your note below strangely proves the counterpoint (ie. "debutante ball"
for mDNS).

In your sample of 5, I am sure most (maybe all?) have some Apple product
of sometype.  If you actually had a packet sniffers in this study, you
will find these devices happily advertising and finding services using
mDNS without anyone typing in anything.

Don

---

From: Michael Thomas <[email-masked]>
Date: Thu, 09 Aug 2012 09:38:42 -0700

> mDNS without anyone typing in anything.

I don't think it's a counterpoint... i think it pretty much makes my
point that even if it's there -- which I suspect you're right about --
people don't know about it. I know for myself, it never occurred
to me that a location bar -- or worse in the case of Safari where it's
buried in a completely obscure place with an even more obscure
name (Bonjour, really??) -- might be used for something other than
global url's. The UI from a browser/web standpoint is all wrong,
and I suspect that the reasons are deeper than bizarre navigation.

Mike

---

From: Andrew Sullivan <[email-masked]>
Date: Thu, 9 Aug 2012 17:52:29 -0400

On Thu, Aug 09, 2012 at 10:17:21AM -0400, Kerry Lynn wrote:

> recursive DNS lookups outside the site boundary). 

Right, I know that, but what I'm trying to say is that merely drawing
_that_ point is not enough for our purposes.  To a user, these are all
just names.  To us when we're trying to make them work together, we
have to attend to the differences, because they don't all work the
same.

Just "doesn't use a recursive DNS outside the boundary" isn't even
enough.  For instance, what about people who are installing local
(sometimes-)recursors in order to get DNSSEC validation on their
machines?  Someone will tell them, "Install this nifty security
feature on your laptop."  But because Unbound has just inserted itself
in a place that Apple wasn't expecting it, stuff starts working funny
some of the time only in some circumstances.

(I don't think we really disagree.  I'm just very concerned to make
sure this fact about protocols doesn't get obscured, because I'm not
sure that everyone understands how many different naming
infrastructures are really involved in a small network with a lot of
ad-hocery going on.)

Best,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 12 Aug 2012 12:18:38 -0400

In message <[email-masked]>

Brian,

Without NAT there is no good reason to have an island.  If you create
an island (in IPv6) where none was needed, you get what you deserve.

NAT64 and DNS64 support v6-only islands.  The tide seems to be turning
on v4-only islands.  For example, I can fetch and build FreeBSD and
fetch all of the ports source for ports I use (>500 ports including
libraries, etc) on an IPv6 only host.  I'm confident the same would be
true of most Linux distributions.

Hosts are all dual stack.  They may end up roaming to a v4-only (or
less likely today v6-only) part of the network.  In that case a tunnel
to a DS network is needed and all is fine, performance suffering a
bit.  For example, an enterprise could go v6-only and allow either v4
or v6 tunneling (which is done today for VPN) from roaming employees
who end up in a v4 only place.  The same enterprise could do NAT64 and
DNS64 or could just set up a DS http/https proxy and mail relay at a
DS border.

I still see no purpose for draft-carpenter-referral-ps if NAT is
removed.

Curtis

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 12 Aug 2012 18:41:03 +0100

Two quick comments, and then I suggest we drop this thread here.

> an island (in IPv6) where none was needed, you get what you deserve.

Nevertheless, people do and will create islands, even very big ones,
with global-scope prefixes. Of course, if their *goal* is unreachability,
the reference problem doesn't matter.

> I still see no purpose for draft-carpenter-referral-ps if NAT is

Which isn't, unfortunately, going to happen in our lifetimes.

   Brian

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 12 Aug 2012 15:05:47 -0400

> be happy with anything that agrees with the definition previously

Even,

With your definition, an enterprise with private DNS, (with
nameservers that are not referenced by the root in any way) could also
be considered to be "not a DN".

The LQDN is a domain of local scope, tied to a a local
sitelocal. domain that does not exist or may be different outside the
site local scope.

An enterprise hidden domain is a domain of local scope tied to a local
domainname that does exists outside and is known to be different
outside of the site local scope.

So the difference is: sitelocal may not exist everywhere and if it
does it is different - an enterprise hidden domain is known to exist
everywhere and is known to be different elsewhere.

LQDN makes a distinction, separating it from FQDN.  LQDN has local
scope.  FQDN has global scope.  The distinction is useful.

BTW- If you argued that mDNS was not a form of DNS, I would agree.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Sun, 12 Aug 2012 15:26:37 -0400

In message <[email-masked]>

Brian,

My prior suggestion is that we have both types of LQDN and not just
temporarily.

  printer.{local|sitelocal} is an ALQDN
  printer.<gibberish>.ulalocal is a ULQDN
  printer.<real-domain-name> is a FQDN

For backward compatibility and to have a constant and easy to type
identifier, printer.{local|sitelocal} can be a CNAME where:

  If an FQDN for printer exists:

    ALQDN CNAME points to the FQDN
      printer.{local|sitelocal} is a CNAME for printer.<real-domain-name>
    rDNS points to the FQDN
      <in-add> points to printer.<real-domain-name>

  If an FQDN for print does not exist:

    ALQDN CNAME points to the ULQDN
      printer.{local|sitelocal} is a CNAME for printer.<gibberish>.ulalocal
    rDNS points to the ULQDN
      <in-addr> points to printer.<gibberish>.ulalocal

The application can detect that the mapping of the ALQDN has changed
in three ways.  First the CNAME mapping has changed.  Second the
address that is returned has changed.  Third the rDNS has changed.

If a domain name is later acquired, then the application can detect
this on later use of the ALQDN in two ways.  First the CNAME mapping
has changed.  Second the rDNS has changed.  Note that the final
forward mapping to an address has not changed in this case.  If a
domain name appears, but the address remains the same, the mapping to
FQDN can silently replace the mapping to ULQDN (retaining the former).

If the final address associated with a ALQDN changes, then it may be
that the site local scope has changed.  If so all ALQDN that map to
ULQDN can be retained but the user must be warned if specifying a
ALQDN.  If the ALQDN had previously mapped to a ULQDN or FQDN that
mapped to a GUA, then the user can be given the option to try it.  If
the ALQDN maps to a FQDN, the mapping can be verified.  If the ALQDN
maps to a ULQDN, then the mapping cannot be verified but can be tried.

This is what I suggested before, just reworded and using your ALQDN vs
ULQDN distinction.

Curtis