Subject: [homenet] how to bookmark .lan,/.home,/.my-homenet when not home

From: Michael Richardson <[email-masked]>
Date: Mon, 30 Jul 2012 19:06:30 -0400

while reading drafts on the airplane, I have come to think that picking
any specific name a la ".local" for the homenet name service is fraught
with RFC1918-like confusion.  For the actual printer and refridgerator
(which does not move, but needs to talk to the TV) it's not a big deal,
but for mobile devices, I think it's gonna lead to confusion. 

When I'm at your house, and I visit "fridge.local", do I get your
fridge, or mine?  Assuming I want mine, if I've discovered it when I was
at home, how would I bookmark and remember it, assuming it had a GUA?

I therefore propose adding a level of indirection (because that solves
every problem....), which (mobile) hosts will ideally become aware of.  

I think of this as a layer above the current LLMNR/mDNS/Bonjour++ layer.

My idea is that the .homenet/.local discovery protocol would, in
addition to the AAAA ULA or GUA record, would provide a reference a
unique name which might not be globally resolvable from the DNS root,
but can be resolved by arrangement.  This would be not unlike
split-horizon DNS, but given IPv6 reachability, no VPN necessary.

For sites where mglt-name-delegation works, great, use that!
For those where this doesn't work,  we need a new well known name.
Perhaps it can find a "logical" place in arpa.   Let's say it's based
upon the ULA, and the home with prefix A:B:C:D gets
D.C.B.A.homenet.arpa.  (add this to DNS search path...)

When an application resolves fridge.local,  if the fridge has a GUA
which it has provided to the CPE's DNS server,  then it also returns a
pointer to the "long-term name" (probably in a new RR) like
"fridge.D.C.B.A.homenet.arpa". Any bookmarks and the like would contain
that address (HTTP/HTML has existing mechanisms to deal with this),
other applications might see this as the canonical name. (getaddrinfo(3)
already has a canonname)

My idea is that given IPv6 reachability for the HOME's CPE(s), that a
mobile recursive (secure) DNS resolver can learn to make queries for 
D.C.B.A.homenet.arpa. directly to the home CPE, even when the mobile
device is not "at home".  

The mobile device needs to be "pair"ed with the CPE such that it agrees
to do this side-ways lookup.   It's pretty much identical to a windows
desktop joining an AD (but I can't speak to the "home edition" being
able to do that... don't do windows).  

This process is, I admit, a form of walled garden DNS, something I've
argued against as being unnecessary.  I'd rather that the ISPs provided
a name, but I feel that ISPs won't be very fast to offer this, and for
the home user with no native IPv6 (using a managed tunnel, for
instance), that a protocol such as I am suggesting, would provide a
clear value (something people would brag about to their friends...)
without requiring people to "wait" for their ISP.

This does not replace "fridge.local" referring to the fridge on the
network that you are on, but it does provide a way to easily discover
and then bookmark "my fridge".

(written offline using xemacs on android)

---

From: Erik Kline <[email-masked]>
Date: Tue, 31 Jul 2012 08:13:27 +0900

> D.C.B.A.homenet.arpa.  (add this to DNS search path...)

Whenever the home prefix is renumbered (which has happened to me already),
do all the names have to change then?

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 31 Jul 2012 11:59:47 -0400

> but for mobile devices, I think it's gonna lead to confusion.
Michael,

For those of us familiar with
http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns
the continued use of ".local." in these threads is leading to some
confusion, as we
synonymize this with using Multicast DNS (mDNS) instead of Unicast DNS.

As was noted in a previous thread, "Special-Use Domain Names" has been
approved as a Proposed Standard:
http://www.ietf.org/mail-archive/web/ietf-announce/current/msg10435.html
The mDNS draft places ".local" in this category and specifies:

   that the DNS top-level domain ".local." is a
   special domain with special semantics, namely that any fully-
   qualified name ending in ".local." is link-local, and names within
   this domain are meaningful only on the link where they originate.

> fridge, or mine?

Mine, by definition.  Given that I'm not sure how you mean ".homenet"
to work by comparison, I'm not sure I completely understand the rest
of the discussion.

> Assuming I want mine, if I've discovered it when I was

If you are remotely accessing resources in your home, you are probably
more advanced than 99% of all home network users.  Why wouldn't the
solution you use on the road apply equally well at your neighbor's house?
(I'm thinking here of services like dyndns.)  You simply put the domain
in which your fridge is registered earlier than ".local." in your DNS search
path, no?  If all else fails, put it in /etc/hosts?

> D.C.B.A.homenet.arpa.  (add this to DNS search path...)
I think defining new "zones" under .arpa. may have merit in the following
respect: ICANN is now in the business of selling dotless domain names.
Despite the fact that there are many grandfathered special domain names
(including .local.) nobody that I know of has yet attempted to allocate a
new one.  Defining new special use names under .arpa. may be a way of
allocating them within IETF's authority, without approval from ICANN.

Note also that http://tools.ietf.org/html/rfc6303 defines a registry that is
apparently similar to special-names (at least there appears to be some
overlap):
http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xml

Regards, -K-

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

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Jul 2012 13:42:46 -0400

>>>>> "Kerry" == Kerry Lynn <[email-masked]> writes:

    Kerry> Mine, by definition.  Given that I'm not sure how you mean ".homenet"
    Kerry> to work by comparison, I'm not sure I completely understand the rest
    Kerry> of the discussion.

Yes, I agree that when I lookup "fridge.local", I'll get yours.
*unless* the mapping to a GUA is still in my browser's cache... 

(I deleted a realistic situation for my smartphone talking to my stove
to find out when the roast is done)

So what I'm after is a way for the fridge to say, when I lookup
"fridge.local" that it's GUA is 2001::F001 (mDNS can already do this),
but also that it's unicast DNS name is fridge.kerlyn.com.

    Kerry> If you are remotely accessing resources in your home, you are probably
    Kerry> more advanced than 99% of all home network users.  Why wouldn't the
    Kerry> solution you use on the road apply equally well at your
    Kerry> neighbor's house?

Kerry, the point of end-to-end connectivity into the home is to permit
the things that us "1%" do, to be doable by everyone... Right?

So, yes, dyndns is *a* solution, but I don't know how to automate it in
a scalable way.  I'm concerned that for the homenet protocols to be
incrementally deployable ("create value") that we can not rely too much
on the ISPs doing the right thing for forward DNS delegation.

    Kerry> I think defining new "zones" under .arpa. may have merit in the following
    Kerry> respect: ICANN is now in the business of selling dotless
    Kerry> domain names.

Just to be clear: my idea isn't that IETF run a dyndns under arpa, but
that we have a WKN under arpa which is treated specially.

I understand that my idea is hard to evaluate without a document.
Should I write one then?

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

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Jul 2012 13:49:02 -0400

In message <CABOxzu1xoH9YbStyULeqpqQ8jdNFD0f0RgfbRjSPBEOvEt80=[email-masked]>
Kerry Lynn writes:
 
> http://tools.ietf.org/html/draft-cheshire-dnsext-multicastdns the
> continued use of ".local." in these threads is leading to some
> confusion, as we synonymize this with using Multicast DNS (mDNS)
> instead of Unicast DNS.
>  

I am not a fan of mDNS but avoiding conflict with mDNS is a good thing
and since this is decided one course of action is to define a
sitelocal.

The intent here is to allow routing within a site, not just bridging.

With ULA the problem that link local addresses are not supposed to be
routed is solved.  ULA avoids the issue of site boundaries that made
IPv6 site local addresses get depricated (a good thing IMHO).

It then becomes necessary only to coordinate the sitelocal domain
among router on the site and avoid leaking among sites.  This is
easily accomplished if the provider router offers a global routable
prefix and refusing to become part of or recognize the DNS site.

The issue is what happens when *my* fridge is not on the same home
subnet as *my* home computer.  (Sustituting a more realistic example,
like thermostats, water heater, alarm system, etc, where temp/time
profiles might be altered, but we'll stick with the fridge example).

> path, no?  If all else fails, put it in /etc/hosts?

A separate issue is how to address the fridge from a computer at work
or a mobile phone where clearly neither are on the same site.  Here a
domain name has to be assigned and most likely something of the form
<subdomain>.<provider-fqdn> if there is not going to be a registration
fee.  The subdomain might be the same as the email address provided by
most home providers or <email>.site.<provider-fqdn>.  At worst the
mobile phone would need to have <email>.site.<provider-fqdn> in the
DNS search path so "fridge" can be resolved.

The sitelocal name then only serves a purpose when the site is not
connected to the provider and doesn't know its domain name.

> http://www.iana.org/assignments/locally-served-dns-zones/locally-served-dns-zones.xml

A local router which provides DHCP can offer itself as a DNS resolver
and effectively become primary for the /128 of any inaddr for any ULA
within the site, returning the <hostname>.sitelocal address or the
<hostname>.<domain> address depending on whether a domain for the site
is unknown or known (either configured or learned).

If the provider offers a routeable address and a domain, then the
provider should also delegate both the forward domain and rDNS.  Of
course it would be real nice if the provider also offered a DNS
secondary and updated the NS record if it was accepted.  The site
router would then have to allow zone transfers to that secondary.
This is a fair amount of code that isn't written, but requires very
little more than 1) some extensions to DHCP and 2) a BCP to say that
this is a good idea and 3) the blessing to use sitelocal in this way
if no domain is configured (since local is defined to be linklocal).

draft-lemon-dhc-dns-pd-01.txt covers a lot of 1) above (some
extensions to DHCP).  It does not provide a means for the provider to
offer to be DNS secondary and that might be a usefule addition.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Jul 2012 14:02:11 -0400

In message <[email-masked]>
 
> I think of this as a layer above the current LLMNR/mDNS/Bonjour++ layer.

If you have your own domain, whether by default you get your fridge or
the one at the site that you are at depends on whther your domain is
ahead or or after sitelocal in your DNS search path.  This affect only
how a short name like fridge gets expanded into a FQDN.  You can still
access either fridge.

Printer might be a good example.  Use the one at home or have a copy
printed where you are now.  I've printed things from remotely a few
times for my wife to pick up at home and sign.  And I've also wanted a
local copy at times.

> split-horizon DNS, but given IPv6 reachability, no VPN necessary.

If I'm at your house I don't want to have to configure your router so
I can talk to my printer.

Also, not local can mean on a mobile device including a mobile phone
or at a WiFi hotspot.  I don't think the barista is going to allow you
to configure their router to share with you local DNS.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Jul 2012 14:19:05 -0400

>>>>> "Curtis" == Curtis Villamizar <[email-masked]> writes:
    Curtis> The issue is what happens when *my* fridge is not on the same home
    Curtis> subnet as *my* home computer.  (Sustituting a more realistic example,
    Curtis> like thermostats, water heater, alarm system, etc, where temp/time
    Curtis> profiles might be altered, but we'll stick with the fridge
    Curtis> example).

this is an issue, and we have some proposals to solve this.

It's not the issue that I'm talking about.  I'm saying that I want to
leverage the sitelocal host discovery protocol to also discover a global
name for the host.  I'm suggeting that an application (e.g. browser,
cups, etc.) on a mobile device should never (by default) actually
bookmark "fridge.local", because it's not globally meaningful.

    Curtis> A separate issue is how to address the fridge from a computer at work
    Curtis> or a mobile phone where clearly neither are on the same site.  Here a
    Curtis> domain name has to be assigned and most likely something of the form
    Curtis> <subdomain>.<provider-fqdn> if there is not going to be a registration
    Curtis> fee.  The subdomain might be the same as the email address provided by
    Curtis> most home providers or <email>.site.<provider-fqdn>.  At worst the
    Curtis> mobile phone would need to have <email>.site.<provider-fqdn> in the
    Curtis> DNS search path so "fridge" can be resolved.

    Curtis> The sitelocal name then only serves a purpose when the site is not
    Curtis> connected to the provider and doesn't know its domain name.

It's not a hard problem, technically (layer 1-7)
It's a hard layer 8/9 problem, and I'm suggesting that maybe we need to
think about whether there are layer-5/6/7 things that we can do as we
are specifying the sitelocal discovery process to ease the layer 8/9
problem.

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 31 Jul 2012 15:38:27 -0400

>  *unless* the mapping to a GUA is still in my browser's cache...
I haven't tried the scenario you mention, and since I'm not home it will be a
while until I can...

> but also that it's unicast DNS name is fridge.kerlyn.com.
Now I am starting to get what you mean.  If you have a unicast DNS
service deployed in your home you can populate it with specially named
PTR records to indicate preferred registration zones (see section 11 of
http://tools.ietf.org/html/draft-cheshire-dnsext-dns-sd).  I guess in theory
these names could also be discovered via mDNS.

> the things that us "1%" do, to be doable by everyone... Right?
Sure, but we shouldn't break things that already work, nor require additional
configuration hassles for ALL users.  It should be made relatively painless to
introduce new functionality.

What I'm trying to figure out is whether most people in these conversations
are envisioning a unicast DNS service in the home that has a "locally
defined" zone, as opposed to mDNS which *distributes* the name service.

One way in which the latter may be deployed may be to have some "agent"
that listens to mDNS announcements and then enters RRs into a unicast
DNS.  This still doesn't buy us FQDNs, however, unless the DNS has a
delegated zone.

> on the ISPs doing the right thing for forward DNS delegation.
So you want to remotely access hosts in your residence, but without
configuration of any sort?

> that we have a WKN under arpa which is treated specially.
Right.  And even though, in theory, we are able to request new TLDs from
ICANN that warrant special semantics, this hasn't yet been attempted to my
knowledge.

> I understand that my idea is hard to evaluate without a document.
I'd support seeing more about naming/service discovery in homenet drafts as
opposed to the mailing list.

-K-

---

From: Michael Richardson <[email-masked]>
Date: Tue, 31 Jul 2012 16:40:18 -0400

(cutting to get to the point)

>>>>> "Kerry" == Kerry Lynn <[email-masked]> writes:
    Kerry> What I'm trying to figure out is whether most people in these conversations
    Kerry> are envisioning a unicast DNS service in the home that has a "locally
    Kerry> defined" zone, as opposed to mDNS which *distributes* the name service.

We want to make this possible, but not required.
And when possible, make it easy.  The easiest way I can think of is;

    Kerry> One way in which the latter may be deployed may be to have some "agent"
    Kerry> that listens to mDNS announcements and then enters RRs into a unicast
    Kerry> DNS.  This still doesn't buy us FQDNs, however, unless the DNS has a
    Kerry> delegated zone.

1) the listener populates the reverse zone, which we have proposals on
how to delegate via DHCPv6.

2) the listener could populate a forward zone, if one existed.

I'm talking about #2. 
a) if said forward zone existed, it would be nice if mDNS would permit
the "canonical" FQDN for a host to be discoverable (and therefore
bookmarkable).

b) if said forward zone existed, should nodes be able to indicate their
desire to be in it (or not in it) via mDNS?  or DHCP? Or ???

Finally, I was wondering if we can through some to-be-defined-magic, get
a new FQDN-ish thing which can be used without pre-arrangement in the
home.  Before I propose a solution (my first email hinted at one), I
would like to know if it's a problem worth solving.

    Kerry> So you want to remotely access hosts in your residence, but without
    Kerry> configuration of any sort?

Yes.  I want to discover things in my home, and then remember how to
talk to them.  

    Kerry> I'd support seeing more about naming/service discovery in homenet drafts as
    Kerry> opposed to the mailing list.

okay.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Jul 2012 22:23:37 -0400

In message <[email-masked]>
Michael Richardson writes:
 
>     Kerry> Mine, by definition.  Given that I'm not sure how you mean
>     Kerry> ".homenet" 
>     Kerry> to work by comparison, I'm not sure I completely understand
>     Kerry> the rest 

Regular DNS can do that too.  :-)  [btw - this wasn't dyndns]

  host fridge
  fridge.ipv6.occnc.com has IPv6 address 2001:470:1f07:1545::4:f00d

That only works because ipv6.occnc.com is in my search path.  In the
prior example I gave if sitelocal was in my search path and there was
no DNS name given to my zone, then I'd get fridge.sitelocal.

If OTOH a provider gave me curtis.site.myprovider.evil then I'd get
fridge.curtis.site.myprovider.evil in response to a "host fridge"
command.  That is because the provider would put
curtis.site.myprovider.evil in the domain and search response in DHCP
and the router would pass it along.  [btw- I don't have a ISP provided
email (that I know of) and I doubt "curtis" is not taken, however the
contact email for them is [email-masked].]

>     Kerry> If you are remotely accessing resources in your home, you
>     Kerry> are probably

Exactly.

> on the ISPs doing the right thing for forward DNS delegation.

The dyndns would be localized to the site.  The provider just
delegates a name to use that is a subdomain of their own, or as I
suggested in an earlier email, perhaps of the form
<customer-email>.site.<provider-fqdn>.  That would be completely
static and set up at customer service setup and never changed.  At
worst, the customer could opt not to use it or have equipment that
can't make use of it.

A provider run DNS secondary would similarly just be statically
configured.

Today the customer is given a dynamic address (unless explicitly
asking for and paying for a single static address).  That is because
IPv4 addresses are in short supply.  IPv6 /64 prefixes are not is
short supply, therefore a provider supporting IPv6 native (or tunnels)
could easily offer a static /64 reserved when the customer service is
initially setup and never changed until the customer leaves.

This is two things configured on the provider side when the customer
is setup and never touched until the customer leaves.  That is not a
large burden on the provider dns ops staff.

>     Kerry> I think defining new "zones" under .arpa. may have merit in
>     Kerry> the following

The homenet.arpa subdomain adds nothing IMHO.  If the provider is
completely non-cooperative in all ways except basic IPv6 connectivity
and granting a /64 via DHCP or statically configured on provider owned
CPE, then the customer simply gets fridge.sitelocal and can't access
his own fridge from the neighbor's house.

> I understand that my idea is hard to evaluate without a document.

Could you summarize in an outline what you would put in that document?

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 31 Jul 2012 22:48:09 -0400

In message <[email-masked]>
Michael Richardson writes:
 
>     Curtis> The issue is what happens when *my* fridge is not on the same h> ome
>     Curtis> subnet as *my* home computer.  (Sustituting a more realistic ex> ample,
>     Curtis> like thermostats, water heater, alarm system, etc, where temp/t> ime
>     Curtis> A separate issue is how to address the fridge from a computer a> t work
>     Curtis> or a mobile phone where clearly neither are on the same site.  > Here a
>     Curtis> domain name has to be assigned and most likely something of the>  form
>     Curtis> <subdomain>.<provider-fqdn> if there is not going to be a regis> tration
>     Curtis> fee.  The subdomain might be the same as the email address prov> ided by
>     Curtis> most home providers or <email>.site.<provider-fqdn>.  At worst > the
>     Curtis> mobile phone would need to have <email>.site.<provider-fqdn> in>  the
>     Curtis> The sitelocal name then only serves a purpose when the site is > not

Getting sitelocal allocated should be no more difficult than getting
local allocated.  It is a TLD that does not resolve globally but does
resolve differently at each site.  It can be used in the absense of a
DNS domain.

It can also be used in the absense of IETF action and in the absense
of provider cooperation because no one can stop you.  :-)
But I'm not advocating doing that.

  host fridge.sitelocal
  fridge.sitelocal is an alias for fridge.ipv6.occnc.com.
  fridge.ipv6.occnc.com has IPv6 address 2001:470:1f07:1545::4:f00d

[ :-) no cooperation from IETF or from my provider required and no
harm done.  I could have made it an AAAA record rather than a CNAME.
To see this you need to direct queries at my name server.
fridge.sitelocal is entirely local.  fridge.ipv6.occnc.com is in the
global DNS.  Please don't try to ping6 my fridge.  It won't answer.  ]

Curtis