Subject: [homenet] homenet "no host changes" assumption and DNS

From: "STARK, BARBARA H" <[email-masked]>
Date: Fri, 18 Aug 2017 13:21:06 +0000

No hat.
I'm proposing something radical here. Let the tomatoes fly.
I'd like to question whether we really need to maintain the "no changes to the host" assumption when it comes to architecting homenet DNS.
Currently, there is no host that expects to use .home.arpa (or any other domain) inside the premises. There is no host that expects a general-purpose in-home domain name system to work or be present. The widest use of in-home domains is the way ISPs use domains like ".home". To the best of my knowledge, they use those for access to the ISP-supplied router's HTTP-served content. Nothing else. The "no host changes" tenet was primarily about not breaking existing host functionality. A fully functional in-home domain name system is not something any legacy host has expectations or functionality for. As long as we don't break usage of Internet DNS, there should not be any requirement or mandate that we have to make in-home DNS work for legacy hosts.

If we got rid of the "no changes to host" tenet (for hosts that can make use of the home naming architecture), that would give us much more freedom to create an in-home DNS architecture without a dependency on homenet routers implementing the DNS Proxy kludge. Or any other kludge. It would let us create an architecture that would finally start to move us away from DNS Proxy and other methods that intercept DNS queries to make supposedly "intelligent" decisions on behalf of stupid hosts. And we would not be further entrenching use of these DNS intercept functions.

I would like to require the hosts that want to make use of the new homenet naming architecture responsible for understanding the different provisioning domains and simultaneously launching queries to the advertised (or internally configured) DNS servers for each provisioning domain. 

The host that gets multiple DNS responses needs to be responsible for making the decision that's right for it. In the case of multiple Internet connections: if the application needs high bandwidth and low loss but latency isn't important (e.g., streaming video), then maybe it picks the high bandwidth high latency low loss connection. If it needs low latency but not much bandwidth (e.g., VoIP), then maybe it picks the low bandwidth low latency connection. The CE router should not be making this decision (which DNS response to supply to the host) on behalf of apps it knows nothing about.

Make the home domain a different provisioning domain, and insist that hosts wanting to make use of domain names in the home domain must understand provisioning domains and how to use and interact with them. The home domain DNS server can be advertised by mDNS or other means.

I truly believe we need to start moving towards providing hosts with the info they need to make their own decisions. DNS Proxy mandates (or other DNS intercept mechanisms) are antithetical to this. 
Barbara

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Aug 2017 09:26:42 -0400

I think that what you are proposing here is great, except that I don't think we actually _need_ to go out of charter on this.   I think that what Toke has been advocating can be worked into the framework you are describing, so that you and I! get what we want, and Toke gets what he wants.

> El 18 ag 2017, a les 9:21, STARK, BARBARA H <[email-masked]> va escriure:
> 
> No hat.
> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet

---

From: Andrew Sullivan <[email-masked]>
Date: Fri, 18 Aug 2017 10:50:59 -0400

Hi,

On Fri, Aug 18, 2017 at 01:21:06PM +0000, STARK, BARBARA H wrote:

> Currently, there is no host that expects to use .home.arpa (or any other domain) inside the premises.

I don't think the "or any other domain" claim is true.  At the very
least, _lots_ of hosts are already using local. in homenets -- indeed,
that's how we got to this pass.

> There is no host that expects a general-purpose in-home domain name system to work or be present.

That's because there is no host that "expects an in-home domain name
system" at all.  I think your position is starting from a position
with which I disagree pretty strongly.  In my view, what we did many
years ago was hook up individual machines to an ISP's network.  When
broadband home access came along, we continued to pretend that the
link in the CPE was just a node in an ISP's network, and pretended
that the home network was not a first-class network that was
internetworked together with other networks to make the Internet.  We
ended up with multiple classes of network, some of which are only
kinda part of the Internet.

The reason that homenet is being worked on in the IETF as opposed to,
say, the Broadband Forum, is exactly that we are trying to provide
internetworking services for these surprisingly sophisticated,
unmanaged networks.  So to say that there's no "general-purpose
in-home domain name system" misses the point: it's _the_ domain name
system, and the homenet is part of that global DNS just as surely as
com. is, and participates in the global name space just as surely as
onion. and local. do.

So, the reason we can't expect host changes for naming is because any
plan for internetworking that starts, "First, upgrade all the hosts,"
is doomed.  That hasn't worked since 1983.

> If we got rid of the "no changes to host" tenet (for hosts that can make use of the home naming architecture), that would give us much more freedom to create an in-home DNS architecture without a d…

I don't understand how you can claim the above: the plain fact of the
matter is that we have multiple domain-name-using protocols in action
here: at the very least, mDNS, DNS, and LLMNR, and maybe Tor
resolution and some other stuff.  If what you're saying instead is
that hosts are supposed to know which networking context they're
living in, then perhaps we need a radical rethinking of what we're
working on.  It _might_ be the case that end to end is the wrong model
given the kinds of things we turn out to be attaching to the Internet
(this was part of what got discussed in the IAB's technical plenary
last November).  But if that's what we're doing, I think this WG needs
at the very least to go through a round of rechartering so that the
rest of the IETF understands that we are proposing a really
significant break with the nominal Internet architecture.  I'm not
convinced that the WG has the patience to do such an effort, BTW.  But
I think this is a pretty fundamental change you're proposing, and I
think it would not be wrong for the IETF to push back pretty hard
against such a change should the WG come out with documents that embed
such an assumption.

> I would like to require the hosts that want to make use of the new homenet naming architecture responsible for understanding the different provisioning domains and simultaneously launching queries…

DNS doesn't work that way, is the problem.  It doesn't have a mode
bit.  What you are proposing is homenet-DNS; it's a new protocol.
Maybe that's the right answer, but I'm far from convinced that this is
the place to create DNSbis.

Best regards,

A
-- 
Andrew Sullivan
[email-masked]

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Fri, 18 Aug 2017 17:38:53 +0200

Ted Lemon <[email-masked]> writes:

> I think that what you are proposing here is great, except that I don't
> think we actually _need_ to go out of charter on this.   I think that
> what Toke has been advocating can be worked into the framework you are
> describing, so that you and I! get what we want, and Toke gets what he
> wants.

Yeah, I think so too. I.e., we can create a framework that will work for
existing hosts and still provide the information for more capable hosts
to do their thing.

Whether these more capable hosts will actually end up performing better
is another matter; but I guess we'll see about that... ;)

-Toke

---

From: "STARK, BARBARA H" <[email-masked]>
Date: Sun, 20 Aug 2017 17:41:06 +0000

> I don't think the "or any other domain" claim is true.  At the very least, _lots_
> of hosts are already using local. in homenets -- indeed, that's how we got to
> this pass.

Yes. I should have been clearer. I meant this in the context of DNS. Though mDNS uses the same protocol semantics and Record structure as DNS, I see mDNS as a rather distinct architecture from that of DNS. Maybe I'm mistaken in looking at it that way.  I'm not aware of widespread use by hosts of local. for DNS queries. Implementations for processing (when to send, how to respond, what to do with the info) of mDNS and DNS tend to be distinct.
 
> system" at all.  I think your position is starting from a position with which I
> disagree pretty strongly.  

My primary position is that homenet solutions must do no harm. They must not cause people to have a worse or more  frustrating experience and must not impose cost on anyone who does not benefit from them (cause other people's experience to be worse by making one person's experience better).
My secondary position is they should create an improved user experience. And the improvement should be desirable by average people, perceived by these people to be worth the cost, and easy for these people to get.
In the context of homenet naming architecture, my position is that a solution must meet these "do no harm" and "create an improved experience" positions.

> In my view, what we did many years ago was hook
> up individual machines to an ISP's network.  When broadband home access
> came along, we continued to pretend that the link in the CPE was just a node
> in an ISP's network, and pretended that the home network was not a first-
> class network that was internetworked together with other networks to
> make the Internet.  We ended up with multiple classes of network, some of
> which are only kinda part of the Internet.

I don't understand this concept of first and second class networks. I do see a distinction between my home network and networks that participate as part of the "public" Internet (including access ISP networks). My home network is mine. I don't care whether it uses the same architectural elements as in the "public" Internet as long as it does what I want. I recently participated in writing a paper with a number of other technology people from various companies, and one thing we determined was we could not decide on a definition of "the Internet". So I don't know what definition you use. I do know that by my definition, my home network is not part of "the Internet", and I don't ever want it to be part of "the Internet". I do not want it to be assimilated. This doesn't make my home network a lower class network, IMO. It makes it a distinct and different network. I agree we have ended up with multiple networks. I disagree they are of different classes. They are, simply, different.

I've spent many years focused on understanding and meeting the needs of consumers and their home networks. I believe my view of my home network is consistent with how most people think of their home network. If you ask an average person whether their home network is part of the Internet, I believe they will say "no".
 
> The reason that homenet is being worked on in the IETF as opposed to, say,
> the Broadband Forum, is exactly that we are trying to provide
> internetworking services for these surprisingly sophisticated, unmanaged
> networks.  So to say that there's no "general-purpose in-home domain name
> system" misses the point: it's _the_ domain name system, and the homenet
> is part of that global DNS just as surely as com. is, and participates in the
> global name space just as surely as onion. and local. do.

I'm not quite sure what you mean by "global DNS" or what conclusions I should draw from this statement. AFAIK, local. is only used with mDNS (which, as I mentioned above, I consider to be distinct from DNS, in spite of using the same protocol semantics and record structures). I do know, absolutely, that I don't ever want my home network names exposed to the public Internet or resolvable by everyone "out there". I also know that I don't care how similar or dissimilar my home network naming architecture is to "global DNS", as long as it works and meets my needs. And I'm quite sure this sentiment is very much shared by regular consumers -- the target homenet deployers. 
 
> So, the reason we can't expect host changes for naming is because any plan
> for internetworking that starts, "First, upgrade all the hosts,"

I have no expectation of updating *all* hosts. But I do think it may be reasonable to expect "if a host wants to participate in the brand new homenet naming architecture, it must be updated". There's a difference between *all* hosts and a conditional set of hosts. I'm aware of many home network consumer electronics devices (TVs, Blu-ray players, etc.) that were shipped with no DNS or mDNS support at all. I'm quite sure no-one is expecting to support these devices in a homenet naming architecture. If you agree our solution doesn't have to handle hosts with neither DNS nor mDNS, then we agree the set of hosts we need to consider is conditional. We are disagreeing on what the condition is that defines the set. I predicate my conditional expectations on "must do no harm and should improve the user experience". BTW, I'm pretty sure that any HTML browser from 1983 would provide an excruciatingly bad user experience in today's Internet. I don't even think there are many browsers in use today that don't do HTML5. If the upgrade is easy, and people care (because they don't like the un-upgraded experience or because they like what the upgrade provides), then it will happen. If the feature is something people care absolutely nothing about, no-one will be incented to implement or apply the upgrade. If the feature is something people like and want, the incentive will exist on all sides. If we think no-one will care, then we shouldn't be doing this.

> > If we got rid of the "no changes to host" tenet (for hosts that can make use
> of the home naming architecture), that would give us much more freedom to
> create an in-home DNS architecture without a dependency on homenet
> routers implementing the DNS Proxy kludge. Or any other kludge. It would
> let us create an architecture that would finally start to move us away from
> DNS Proxy and other methods that intercept DNS queries to make
> supposedly "intelligent" decisions on behalf of stupid hosts. And we would
> not be further entrenching use of these DNS intercept functions.
> >
> 
> I don't understand how you can claim the above: the plain fact of the matter
> is that we have multiple domain-name-using protocols in action
> here: at the very least, mDNS, DNS, and LLMNR, and maybe Tor resolution
> and some other stuff.  If what you're saying instead is that hosts are
> supposed to know which networking context they're living in, then perhaps
> we need a radical rethinking of what we're working on.  It _might_ be the
> case that end to end is the wrong model given the kinds of things we turn
> out to be attaching to the Internet (this was part of what got discussed in the
> IAB's technical plenary last November).  But if that's what we're doing, I think
> this WG needs at the very least to go through a round of rechartering so that
> the rest of the IETF understands that we are proposing a really significant
> break with the nominal Internet architecture.  I'm not convinced that the WG
> has the patience to do such an effort, BTW.  But I think this is a pretty
> fundamental change you're proposing, and I think it would not be wrong for
> the IETF to push back pretty hard against such a change should the WG come
> out with documents that embed such an assumption.

As chair: OK. I hear you. But I'll need to understand this better.
 
> > I would like to require the hosts that want to make use of the new
> homenet naming architecture responsible for understanding the different
> provisioning domains and simultaneously launching queries to the advertised
> (or internally configured) DNS servers for each provisioning domain.
> >
> 
> DNS doesn't work that way, is the problem.  It doesn't have a mode bit.
> What you are proposing is homenet-DNS; it's a new protocol.
> Maybe that's the right answer, but I'm far from convinced that this is the
> place to create DNSbis.

I'm not proposing any changes to the DNS (or mDNS) protocol or DNS record structure. But I think what I am proposing I should put into a different email so I can describe it in more detail.
Barbara

---

From: Andrew Sullivan <[email-masked]>
Date: Sun, 20 Aug 2017 23:15:06 -0400

On Sun, Aug 20, 2017 at 05:41:06PM +0000, STARK, BARBARA H wrote:

>  Yes. I should have been clearer. I meant this in the context of
> DNS. Though mDNS uses the same protocol semantics and Record
> structure as DNS, I see mDNS as a rather distinct architecture from
> that of DNS. Maybe I'm mistaken in looking at it that way.  I'm not
> aware of widespread use by hosts of local. for DNS
> queries. Implementations for processing (when to send, how to
> respond, what to do with the info) of mDNS and DNS tend to be
> distinct.

What you say there is both true and not true.  The reason mDNS (and
LLMNR, for that matter) use domain names and not some other naming
scheme is because every application in the world knows what to do with
a domain name: pass it down to the resolution library.  Therefore,
what domain-name-using protocols that depend on a special magic
"protocol switch" label do is rely on the resolution libraries to
catch the "special" name, and send that name down the alternative
resolution path.  This is what mDNS does with local. and it's what Tor
does with onion. and so on.  It therefore _can't_ be true that it uses
a really distinct architecture, because it's stuck with labels and the
whole rest of the decisions made for us in the early 1980s by the
makers of DNS.  But it is a distinct architecture in that, once you
are sure that you have someone playing in the new rules, you can make
different decisions.

> My primary position is that homenet solutions must do no harm. They must not cause people to have a worse or more  frustrating experience and must not impose cost on anyone who does not benefit fro…

I think you're going to be disappointed, then.  Lookups for
local. leak to the global DNS all the time, and I think we should
expect the same for home.arpa.  All we can do is warn people.

> My secondary position is they should create an improved user experience. And the improvement should be desirable by average people, perceived by these people to be worth the cost, and easy for thes…

Which people are you talking about?  If the goal here is people who
have the faintest idea that there _is_ a naming system involved, then
I suggest we already have the answer: literally anyone who knows that
is in a position today to run some sort of split-brain DNS and make
everything work.  What we were supposed to be working on, I thought,
was a situation where nobody thought it was "worth the cost" because
they had no idea that there was anything to trade.  That's what mDNS,
when working correctly, mostly does.  I think that is what we're
supposed to be aiming for, without the restriction to the local link.  

>  I do see a distinction between my home network and networks that participate as part of the "public" Internet (including access ISP networks).

Of course you do.  You do networks for a living.  Even some people who
work in the office I used to go to, who were supposed to be involved
in selling Internetty things, did not seem to understand the kind of
local net/office net/Internet kinds of distinctions that you are
making.  I have never had the slightest luck in explaining these
distinctions to my parents, even though my father was, before he
retired, an actual rocket scientist; and even though I was in an
earlier career able to explain to undergraduates why "If you don't eat
your peas, you can't have dessert" did not mean that if you ate your
peas you got dessert.  Distinctions among networks are, I suspect,
nowhere near as clear to others as to us.  I believe that's precisely
part of the reason the group got chartered: network operators at
universities -- the people you'd most expect to understand network
distinctions -- wanted various link-local stuff to work on the
"campus" or "site local" scope.  

>we could not decide on a definition of "the Internet". So I don't know what definition you use.

A network of other networks linked together by the common underlying
Internet Protocol, ostensively definable by the relationship "can send
a packet to".  At least in the most general sense.  This is of course
automatically problematic because of v4 and v6, which necessarily
means that we are working on two different internets today.  I think
that's probably correct.

> I believe my view of my home network is consistent with how most people think of their home network. If you ask an average person whether their home network is part of the Internet, I believe they will say "no".
>

I believe that if you ask an average person that question, they will
say, "What?"  I don't think that people think in the terms you mean.
They simply want their things to be accessible when they want them
where they want them, ad they want others not to be able to do that,
and this is why everything has moved into the "cloud" even though that
is inefficient in many cases.  

> I'm not quite sure what you mean by "global DNS"

The global DNS is the domain name system used by the Internet.  

>AFAIK, local. is only used with mDNS

At least theoretically (though as I noted it leaks).  But it's a
domain name that is, because of an IANA registry, reserved from
allocation in the global DNS.  

> I do know, absolutely, that I don't ever want my home network names exposed to the public Internet or resolvable by everyone "out there".
>

That's nice, but that is not in fact what the architecture document
this WG produced suggested.  There are definitely use cases we have
that involve exposing things "in the homenet" to "the public
Internet".  The most obvious one is the file server in my house, which
is useful to me if I happen to be on the road.  Stuart has mentioned
the printer in his house, because apparently he sometimes prints
things at home when he is on the road.  The idea that people at home
might need access from outside the homenet to things _in_ the homenet
doesn't seem silly to me, and so I don't think we get to rule it out
of scope unless we just decide that we won't solve that problem.

> I have no expectation of updating *all* hosts. But I do think it may be reasonable to expect "if a host wants to participate in the brand new homenet naming architecture, it must be updated".

I guess I just don't know which hosts these are supposed to be.  The
idea, as I understood it, was that we were not going to require
ordinary users, who are not managing these networks now, to make the
kinds of decisions you seem to be assuming.

Best regards,

A

-- 
Andrew Sullivan
[email-masked]

---

From: james woodyatt <[email-masked]>
Date: Mon, 21 Aug 2017 11:52:57 -0700

On Aug 18, 2017, at 07:50, Andrew Sullivan <[email-masked]> wrote:
> 
> Maybe that's the right answer, but I'm far from convinced that this is the place to create DNSbis.

p1. I’m far from convinced that yet another incremental refinement of DNS can be sufficient or even necessary.

p2. I'm quite certain that HOMENET is the wrong place to attempt it.

--james woodyatt <[email-masked] <mailto:[email-masked]>>

---

From: Michael Richardson <[email-masked]>
Date: Mon, 21 Aug 2017 19:20:29 -0400

STARK, BARBARA H <[email-masked]> wrote:
    > number of other technology people from various companies, and one thing
    > we determined was we could not decide on a definition of "the
    > Internet". So I don't know what definition you use. I do know that by
    > my definition, my home network is not part of "the Internet", and I

My definition for capital-Internet:
   The set of networks which are directly reachable ("icmp ping") and are
   enumerated in the "public" BGP4 tables.

So, in traditional v4 land, only your edge router was part of The Internet by
this definition.  IPv6, Teredo, and PCP/UPnP changed this to include more
and more hosts that are behind the router.

Of course, your router might have a policy preventing internal hosts being
directly reachable.  (RFC6408 suggests that policy I think)
For instance, one might require some kind VPN to be established in order to
reach, in which case it is not "directly"

    > don't ever want it to be part of "the Internet". I do not want it to be
    > assimilated. This doesn't make my home network a lower class network,
    > IMO. It makes it a distinct and different network. I agree we have
    > ended up with multiple networks. I disagree they are of different
    > classes. They are, simply, differen!  t.

I think that a lot of people in this group want to make sure that your
network (whether or not you think of it as part of the "Internet"), remains
your network, and does not become an extension of the ISPs network.

    > I've spent many years focused on understanding and meeting the needs of
    > consumers and their home networks. I believe my view of my home network
    > is consistent with how most people think of their home network. If you
    > ask an average person whether their home network is part of the
    > Internet, I believe they will say "no".

I think that it depends a lot on how they use it, and what kind of education
they have had.  Most of my older relatives think in terms of computers,
and Internet.  The Internet connects their computers, they don't have a home
network.   That's a result of ISP "propaganda", in my opinion.

    > I have no expectation of updating *all* hosts. But I do think it may be
    > reasonable to expect "if a host wants to participate in the brand new
    > homenet naming architecture, it must be updated". There's a difference
    > between *all* hosts and a conditional set of hosts. I'm aware of many

+1

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [