Subject: [homenet] Unicast DNS within the Homenet?

From: Ray Bellis <[email-masked]>
Date: Mon, 10 Sep 2012 12:34:21 +0000

An interesting question has come up during the Arch Doc team's discussions around naming and service discovery:

"What in-home services actually require Unicast DNS lookup?" [*]

The one obvious case is in-home web servers (i.e. CPE configuration) although a prior posting suggested that most people just use an IPv4 address (e.g. 192.168.1.1) rather than a DNS name for that.  Many devices now support Bonjour for that.

If it can be shown that Unicast DNS is only need for resolution of _external_ names then much of the discussion around _internal_ naming probably becomes moot.

thanks,

Ray

[*] I'm specifically _not_ talking about normal recursive DNS for global DNS names.

---

From: Hans Liu <[email-masked]>
Date: Mon, 10 Sep 2012 12:39:39 +0000

FYI !!  All of D-Link home routers now support NetBIOS name, mDNS and LLMNR.  We removed 192.168.0.1 from device label and Quick Installation Guide already. 

Best regards,
Hans
On Sep 10, 2012, at 8:34 PM, Ray Bellis <[email-masked]>
 wrote:

thanks,

Ray

[*] I'm specifically _not_ talking about normal recursive DNS for global DNS names.
_______________________________________________
homenet mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/homenet

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Sep 2012 13:58:46 +0100

> "What in-home services actually require Unicast DNS lookup?" [*]

Well, that isn't the right question IMNSHO.

> The one obvious case is in-home web servers (i.e. CPE configuration) although a prior posting suggested that most people just use an IPv4 address (e.g. 192.168.1.1) rather than a DNS name for that.…

Using literal addresses is evil for many reasons - surely we don't need to
discuss that ancient question again?

> If it can be shown that Unicast DNS is only need for resolution of _external_ names then much of the discussion around _internal_ naming probably becomes moot.

The right question is whether DNS is the appropriate solution for converting
local devices names to addresses, or whether there is some other naming service that
should be the standard. Since DNS is the IETF standard for converting names
to addresses, there would need to be a pretty strong case for anything else.

    Brian

---

From: Ray Bellis <[email-masked]>
Date: Mon, 10 Sep 2012 13:09:11 +0000

> discuss that ancient question again?

I wasn't promoting it, just noting that this is the current position, with Bonjour et al becoming the "preferred" way.  The latter is "a good thing".

> to addresses, there would need to be a pretty strong case for anything else.

The IETF has _other_ protocols for naming services (mDNS, LLMNR) that are designed for local networks, albeit with the "wrong" multicast scope as far as we're concerned.

My question is therefore more about whether (internal) unicast DNS is actually required at all.

Ray

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Sep 2012 14:53:59 +0100

> I wasn't promoting it, just noting that this is the current position, with Bonjour et al becoming the "preferred" way.  The latter is "a good thing".

afaik Bonjour is a proprietary protocol. How can that be a good thing?

> The IETF has _other_ protocols for naming services (mDNS, LLMNR) that are designed for local networks, albeit with the "wrong" multicast scope as far as we're concerned.

And SLP, explicitly designed for locating services.

> My question is therefore more about whether (internal) unicast DNS is actually required at all.

And I'm saying that's the wrong question.

I think the right question is whether there is an *open* standard for discovering
service addresses from service names that is more suitable than DNS.

    Brian

---

From: Andrew Sullivan <[email-masked]>
Date: Mon, 10 Sep 2012 10:12:12 -0400

> to addresses, there would need to be a pretty strong case for anything else.

As Ray says, DNS is by no means the only IETF standard for this.
There's RFC 4795, for instance.  

ALso, draft-cheshire-dnsext-multicastdns-15 has been in the RFC Editor
queue for 265 days.  There is an IPR disclosure, but it's your basic
mutually-assured-patentwar-clause permissive license.  

Nevertheless, some people _do_ use real DNS -- even split-brain DNS --
in homenet-type networks.  Certainly, the many devices that include
dnsmasq (and yes, I am perfectly aware of the problems and limitations
attendant on such deployments) are using DNS inside the network some
of the time.  I'd be pretty uncomfortable deciding that all those
deployed networks are going to need reconfiguration to conform with
whatever this WG comes up with.

In addition, it seems to me that there are going to be split-brain
overloaded-name conditions that are more easily solved with DNS than
with anything else.  (Certainly, the desire expressed several times in
Vancouver for a single identifier simply to work no matter what
network one is in suggests that things like llmnr and mdns are not
going to be winners here.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Michael Thomas <[email-masked]>
Date: Mon, 10 Sep 2012 07:13:40 -0700

> to addresses, there would need to be a pretty strong case for anything else.

Maybe a thought experiment might help all of this along. In the
very near future, I will probably be able to buy components and
services like a display, an amp, anam/fm radio receiver, a cable/sat
decoder, a jukebox-like disk server, speakers, lighting controls,
internet based content services, and a popcorn popper. All IP
enabled all wireless most likely.

I want control these all from my phone, tablet or laptop where
there the app brings all of these things together and wirelessly
"wires" them all up much like banana plugs did before. I may
want to have many different profiles of what constitutes a
"theater" depending on whether I'm in the kitchen, on my
lard-o-matic, or in a fully vegetative state on the couch.

I need to be able to incrementally add components because
I'm not rich, and I might want to add ad hoc components because
my friends bring over some new gadget, or have content they'd
like to source, etc. And I need to be able to have multiple different
control points including possibly even allowing my friends to take
control of the system as a whole.

I generally want my app to control everything, but I am resigned
to the fact that every once in a while I'm going to need to go to
my speaker's web server and adjust things that are proprietary or
can't be controlled due to version skew.

So this is complicated, but naming is obviously a big  part of
assembling this. Discovery plays a part, especially in the
beginning, but repository based naming is also needed because I
want to bind more intuitive names like "Bose-sw-corner-livingroom"
to my components such that if I blow out one speaker, I can replace
it and not have the name I chose get thrown into the trash with
the old speaker.

This isn't really all that far off, or far out.

Mike

---

From: Don Sturek <[email-masked]>
Date: Mon, 10 Sep 2012 07:17:04 -0700

Bonjour is based on mDNS
(http://datatracker.ietf.org/doc/draft-cheshire-dnsext-multicastdns/) and
DNS-SD (http://datatracker.ietf.org/doc/draft-cheshire-dnsext-dns-sd/),
both currently in the RFC editors queue.....

Don

On 9/10/12 6:53 AM, "Brian E Carpenter" <[email-masked]>
wrote:

>> I wasn't promoting it, just noting that this is the current position,
>>with Bonjour et al becoming the "preferred" way.  The latter is "a good
>>thing".
>
>> The IETF has _other_ protocols for naming services (mDNS, LLMNR) that
>>are designed for local networks, albeit with the "wrong" multicast scope
>>as far as we're concerned.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 10 Sep 2012 16:48:38 +0100

Don,

Yes, based on, and it will be good to see those RFCs out.

What I'm basically worried about here is ending up with one
toolset for homenets and a different toolset for small enterprise
networks, which seem much more likely to go the DNS way than anything
else. In practice there's no hard and fast boundary between home and
small business.

  Brian

---

From: Don Sturek <[email-masked]>
Date: Mon, 10 Sep 2012 08:57:14 -0700

Hi Brian,

Totally agree with you.  In fact, I think Ray asked about the use case for
unicast DNS within Homenet.  I think locating service names in a small
business, dormitory, etc. is that use case where mDNS does not scale well
and where a globally unique name is maybe not necessary.......

Don

On 9/10/12 8:48 AM, "Brian E Carpenter" <[email-masked]>
wrote:

>>>>> to addresses, there would need to be a pretty strong case for
>>>>>anything
>>>>> else.

---

From: Ray Hunter <[email-masked]>
Date: Mon, 10 Sep 2012 18:14:04 +0200

Ahem, who says Bonjour is becoming the "preferred" way?

Last time I checked, I had to download and install additional 
(proprietary) software to use Bonjour, and it didn't work across a router.

Multicast DNS has significant implications for power consumption for 
nodes that wish to sleep, and mandatory support for site-wide multicast 
would also make demands on Homenet routers e.g. PIM? MLD?

Anyone claiming this is the preferred way should also have a good answer 
to those issues.

regards
RayH

Ray Bellis wrote:
> On 10 Sep 2012, at 13:58, Brian E Carpenter<[email-masked]>  wrote:
>

---

From: Kerry Lynn <[email-masked]>
Date: Mon, 10 Sep 2012 12:17:28 -0400

What I'm concerned about is using one protocol for internal name resolution
and another for external.

Bonjour, mDNS and multicast DNS are synonymous.  mDNS is based
on DNS-SD, which is a conventional use of *existing* DNS RR types for
service discovery.  mDNS uses DNS-like messages.  I'm OK with calling
it "DNS-like" but to say that it is unrelated to DNS or a closed standard
is just confusing the issues IMO.

The Hamming distance between mDNS and DNS is virtually nil compared
to other alternatives mentioned so far for internal name resolution (SLP,
LLMNR, etc.)  What this means in practice is that any resolver that deals
with mDNS can also resolve global DNS names.

I think that DNS and DNS-like protocols should be where we focus our
limited time and energy for homenet naming use cases until someone
comes up with a scenario that, by rough consensus, shows DNS to be
unsuitable for homenet naming.

Now back to Ray's original question, I can see a use for unicast mDNS
resolution in homenet insofar as a previously cached binding might be
validated with a unicast message.  If that binding proves to be invalid,
then the client could initiate a new discovery (using scoped multicast
or some as yet TBD proxying scheme.)

-K-

---

From: Curtis Villamizar <[email-masked]>
Date: Mon, 10 Sep 2012 19:15:18 -0400

In message <[email-masked]>
Ray Bellis writes:
 
> An interesting question has come up during the Arch Doc team's
> discussions around naming and service discovery:
>  
> The one obvious case is in-home web servers (i.e. CPE configuration)
> although a prior posting suggested that most people just use an IPv4
> address (e.g. 192.168.1.1) rather than a DNS name for that.  Many
> devices now support Bonjour for that.
>  
> If it can be shown that Unicast DNS is only need for resolution of
> _external_ names then much of the discussion around _internal_ naming
> probably becomes moot.
>  
> thanks,
>  
> Ray
>  

Ray,

I've read the thread so far and I'm replying to the original message.

The app that needs DNS is anything from outside or from a mobile
device that requires access to the home without going through a cloud
intermediary (usually not free).

PC to PC SIP is one example, optionally with video.  The most common
intermediary is skype.  There are also numerous SIP providers that
essentially broker the initial connection for free (handle the SIP
part, not the RTP part) and only charge if you connect to the PSTN
where they are usually a SIP back to back UI connection and incur a
fee from the PSTN.  There is no reason why SIP URLs could not be used
with IPv6.  Admittedly, not a popular idea with the phone companies.

For IPv4 today the cloud intermediary is a necessary evil due to both
side being behind a NAT and having no means to get a DNS name for
themselves.  With IPv6 this can be solved.  With IPv6 if we get it
right you won't need to go through a third party to change your
thermostat because you just found out that you are coming home early -
you can directly address your thermostat by name (hopefully with
reasonable authentication).

At issue is whether the homenet WG is going to continue with PC world
business as usual, which is lame discovery protocols that work only
when there is only one subnet and are useless otherwise.

One argument for multiple subnets is that bridging the GbE segment to
the WiFi segment can swamp the WiFi segment.  By routing between the
two, active queue management (QoS) is easier and all of the segment
broadcast and multicast on the GbE segment need not appear on the
wireless.

There are other motivations such as having an open guest wireless
channel vs having a secure wireless channel, plus a wired segment.
WiFi home routers able to support two channels are not uncommon today,
though they are on the high end of home stuff (available on the
shelves of you consumer and office supply places).  It is better not
to bridge the guest and secure segments together but rather to route
between them.

With IPv6 and the prospect of GUA for everything, the practice of
hiding horribly insecure devices and protocols behind a firewall needs
to disappear.  It has proven unsafe over and over in enterprise of any
size, where one compromise exposes the entire private side.

If it is not DNS, it has to meet some requirements:

  1.  work over multiple subnets
  2.  tie into DNS if devices are to be accessed from elsewhere

If it is DNS, it has to meet some requirement that DNS as practiced
isn't very good at right now.

  1.  there needs to be a means of creating a namespace without going
      to a registry first (entirely local, but provider delegation
      would be better)
  2.  a usable interface is needed to assign names to devices (dyndns
      is almost adequate, setting host name on each device, but better
      would be to assign names centrally - configured dhcp entries)

In either case where multiple routers are encountered, some means to
resolve who is in charge of the name space is needed.

Or we can continue with yet another lame half-baked solution de-jour
for a single subnet home carrying forward the thinking of NATed PI
addresses behind a firewall and have a different set of solutions for
soho, small business, and up.

Regarding some of the other comments.

... I see the point about the home with wireless audio and video
components.  There is only so much that can be done in a dorm or other
high density housing (apartments) where having many WiFi APs crowd the
channel space.  Even where I live, where lots are 1.5-2.5 acres, I saw
today 6 APs, three on channel 6, when I looked at my wife's laptop to
see why it was having a bad day.  This is why many dorms have wired
Ethernet, and that tried to go all wireless and switched back.  The
campus library, the dorm lounges, etc still have wireless.  Due to
virus and worm problems MAC addresses need to be registered with
campus IT before a student device is granted access.  Only very public
places like lounges and library have open wireless and are somewhat
isolated (untrusted guest treatment).  Of course students can still
bring in wireless routers and NAT and make a mess of things (and do).

... Brian, I agree that two namespaces is evil (or whatever you called
it).  I also agree that if it is not DNS there needs to be a very good
reason.

Curtis

---

From: james woodyatt <[email-masked]>
Date: Mon, 10 Sep 2012 18:41:49 -0700

> "What in-home services actually require Unicast DNS lookup?" [*]

Really?  How has the architecture team managed to overlook the obvious problem that homenets with interior routing domains comprising multiple networks cannot use either mDNS or LLMNR, which are confined to link-local multicast scope, without requiring name service proxies?

As Brian notes, you could try to resurrect SLP, but-- really?  I don't see that happening.  Name service proxies also sound like a major undertaking compared to ordinary unicast DNS.  What an exciting distributed database scheme with which consider securing its integrity... I can't wait.

Alternatively, you could try to extend mDNS and/or LLMNR to support a wider multicast scope, then require routed homenets to implement some kind of multicast routing protocol.  That sounds like a big specification effort and I'm not sanguine about the chances for adoption there.

Finally, we could punt on the homenet routing problem, and just use mDNS+DNS-SD exclusively-- I'm sure I can think of at least one major player in the home networking space that would be quite happy to see such an outcome turn out to be the status quo, but last I checked, this working group didn't like that idea very much.

So, um-- I guess the answer to the Arch Doc team's question should be, "NAME ALL THE THINGS IN DNS!!"  What am I missing?

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: joel jaeggli <[email-masked]>
Date: Mon, 10 Sep 2012 20:58:03 -0700

> So, um-- I guess the answer to the Arch Doc team's question should be, "NAME ALL THE THINGS IN DNS!!"  What am I missing?
I tend to agree that you can't just  punt on the DNS for the same reason 
you can't just punt on routing in the absence of either you're left 
needing some topological abomination to knit together the home-nets.

---

From: Ray Bellis <[email-masked]>
Date: Tue, 11 Sep 2012 07:04:43 +0000

On 11 Sep 2012, at 05:25, Benjamin Kerensa <[email-masked]<mailto:[email-masked]>>
 wrote:

Correct. 192.168.1.1 is also the most common default router IPv4 address.

Many devices now support Bonjour for that

...

What about "localhost"

I've never yet seen a system that couldn't resolve localhost all by itself.

Ray

---

From: Ray Bellis <[email-masked]>
Date: Tue, 11 Sep 2012 07:19:46 +0000

> As Brian notes, you could try to resurrect SLP, but-- really?  I don't see that happening.  Name service proxies also sound like a major undertaking compared to ordinary unicast DNS.  What an excit…

I'm informed that mDNS proxying is already understood and present in several devices.

> Alternatively, you could try to extend mDNS and/or LLMNR to support a wider multicast scope, then require routed homenets to implement some kind of multicast routing protocol.  That sounds like a b…

Either of the two above is assumed, with the arch team tending towards proxying rather than extending multicast.  The final recommendation would be part of a "solutions-draft", and not in the "architecture".

> So, um-- I guess the answer to the Arch Doc team's question should be, "NAME ALL THE THINGS IN DNS!!"  What am I missing?

I shall attempt to clarify.

Iff all "in-home" services can be reached (whilst in-home) by mDNS-like protocols then we do not need an "in-home" unicast DNS zone.

To reach those same services from _outside_ the home does of course need them to exist in the global DNS, as pointed out by Curtis.

To do that we need (I think) only two things:

1.  the ability for the device (or the network on its behalf) to register a FQDN for that device.

2.  the ability for clients of that device to learn that FQDN when it's bookmarked so that they can reach it from outside.

In the absence of an internal Unicast DNS zone all of the discussion of what that zone should be is irrelevant.  No need for "ULA prefix-based" LQDNs, for example.

So the point of the original email was to test that first assumption - i.e. what services don't (or can't) work in-home without a local unicast DNS zone.

Ray

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2012 10:17:15 +0100

On 11/09/2012 08:19, Ray Bellis wrote:
...
> So the point of the original email was to test that first assumption - i.e. what services don't (or can't) work in-home without a local unicast DNS zone.

Excuse my ignorance, but if a LAN has both mDNS and DNS available,
what happens when an app calls getnameinfo() ?

   Brian

---

From: Simon Perreault <[email-masked]>
Date: Tue, 11 Sep 2012 09:11:18 -0400

> what happens when an app calls getnameinfo() ?

Current situation is: "implementation-dependant".

In fact, getnameinfo() is not defined in terms of DNS. It can use any 
underlying naming service, or even multiple ones. On Linux this is 
configured with /etc/nsswitch.conf.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2012 14:45:12 +0100

> configured with /etc/nsswitch.conf.

Thanks. Then it seems to me that a recommendation about the desirable behaviour
of getnameinfo() and getaddrinfo() needs to be made, consistent with the final
recommendation for mDNS vs DNS. At least we should describe a consistent
deployment scenario.

    Brian

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Sep 2012 06:52:16 -0700

> So the point of the original email was to test that first assumption - i.e. what services don't (or can't) work in-home without a local unicast DNS zone.

I'm sorry but this formulation is just plain wrong on almost every level.
Zeroconf-ish like solutions are when you *can't* do anything better. DNS
is better when you can. If I take the time to (re-)name something, I want
that to end up in a repository whose destiny is not tied to the particular
device. I very often want that name/device to be accessible outside of
my home too.

So no, let's not start from an assumption that it's an mDNS world in the
home. I'd say let's start from the opposite assumption that it's a normal
DNS world inside the home where mDNS is a way to auto-populate a
DNS repository in lieu of anything better.

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Sep 2012 10:00:11 -0400

> DNS repository in lieu of anything better.

+1.

I've begun to feel as if the discussion going on here is leading to a product I don't want, so I haven't felt like it was worth weighing in on this subject, but this pretty much represents my feelings about it as well.

---

From: Andrew Sullivan <[email-masked]>
Date: Tue, 11 Sep 2012 10:59:29 -0400

> recommendation for mDNS vs DNS. At least we should describe a consistent

But you can't _make_ such a recommendation, because different
scenarios -- network-topologically indistinguishable from one another
-- require very different conclusions.  

This is exactly the same problem MIF faced with the DNS server
selection logic.  You naturally want to use the DNS server that you
believe is going to provide you with the right answers.  But when you
move networks (say, into the coffeeshop which is using Stupid DNS
Tricks to authenticate you as a customer first), you actually need the
_least good_ answer sometimes, in order to move you from your
expensive mobile radio onto your cheap wifi.

The same problem crops up here.  Inside your house, mDNS is perhaps
the right answer.  But for bookmarking on your laptop that you carry
on the road but want to use with your home network then, it's exactly
the wrong answer.  So this once again comes down to use cases, and
trading userland functionality against complications that make the
specification complex, and implementations tricky and therefore buggy.

To moan just a little bit, this is why many of us think that the
mutliple namespace approaches (seen in mDNS, llmnr, before those
NetBIOS, and so on) are harmful.  Inevitably, these systems get hooked
up to the wider Internet, and the inconsistencies thereby revealed
make people confused.  (This isn't to say there is an obvious better
answer, given the facts of the world about DNS name registration and
resolution.)

Best,

A

-- 
Andrew Sullivan
[email-masked]

---

From: Kerry Lynn <[email-masked]>
Date: Tue, 11 Sep 2012 11:17:04 -0400

> I've begun to feel as if the discussion going on here is leading to a product I don't want, so I haven't felt like it was worth weighing in on this subject, but this pretty much represents my feeli…
Can we explore how this auto-population might occur?  It seems that to
glean bindings from mDNS or LLMNR there would have to be at least
(or exactly?) one "agent" per subnet.  The natural place for the agent to
reside is on the router.  Presumably each agent learns the address of
the DNS server via stateless DHCPv6.  The DNS server would need to
be configured with a TSIG for each agent.  The agent hears multicast
responses to lookups on its local link, then periodically updates the
DNS server.

I assume an alternative would be to auto-configure via stateful DHCPv6.
Would that more or less of a configuration burden than the sketch above?
Would work with existing devices?

Thanks, -K-

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Sep 2012 12:01:53 -0400

> Would work with existing devices?

There are a couple of options being pursued in the DHC working group; the DHCP address registration process would be an obvious mechanism for leveraging DHCP to populate the DNS.   The idea here is that you do RA+SLAAC, or RA+CGA, and then you contact the DHCP server to tell it what address you allocated and what name you want associated with it, and to get any local network configuration information you might need.

However, of course this is new technology that isn't even standardized yet.   I'd like it if homenet recommended implementing this, but I think another way of populating the DNS is through mDNS—when a host publishes its name in mDNS, it's assumed to be valid as long as no conflicting registration has been made locally.   I don't particularly love this method because mDNS doesn't have the same duplicate detection features that DHCP does through the DUID, but it wouldn't be _worse_ than plain mDNS, and would allow the DNS resolver to query a consistent FQDN tree for local names, so that it would work whether you were attached to the local wire or not.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 11 Sep 2012 17:16:38 +0100

> -- require very different conclusions.  

Surely we can recommend, or at least suggest, that the library which
provides getnameinfo() tries both mDNS and DNS and returns the results in
a configurable order.

And if we can't do that, surely we can describe scenarios and their
consequences.

As Fred, I think, said the app is going to have to do something
happy-eyeballs like but we can help it along the way.

   Brian

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Sep 2012 09:24:39 -0700

> There are a couple of options being pursued in the DHC working group; the DHCP address registration process would be an obvious mechanism for leveraging DHCP to populate the DNS.   The idea here is…

Maybe somebody can educated me, but isn't it a bit dangerous to use
an auto-configured address as a way to contact a host? If I change out my
ethernet hardware, for example, my auto-conf address would normally
change too, right?

> However, of course this is new technology that isn't even standardized yet.   I'd like it if homenet recommended implementing this, but I think another way of populating the DNS is through mDNS—whe…

DHCP may be a solution but it ought not be the only solution, right? What if
there's no relationship between my dns repository and the DHCP server? That
is, suppose that Google hosted my DNS and thus wasn't actually on my home
network. I suppose that a home router could work in concert by either working
with its DHCP or listening to mdns chatter and then doing IXFR's to a name
server. Is that what's being talked about?

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Sep 2012 12:37:30 -0400

> ethernet hardware, for example, my auto-conf address would normally

No.   Things change.   All that's required to deal with this is that the underlying protocol support it.   The DHCP DUID identification system does support this kind of change, as long as the actual device doesn't change.   If the device changes, then when the registration expires, the name can be reclaimed.

> server. Is that what's being talked about?

If there is no relationship between the home gateway, which is the DHCP server in the case I'm describing, and the DNS server, then this can't work whether the protocol used for getting names is mDNS or DHCP or some third protocol we haven't talked about yet.

---

From: Evan Hunt <[email-masked]>
Date: Tue, 11 Sep 2012 17:44:51 +0000

> DNS repository in lieu of anything better.

Another +1.

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

---

From: Evan Hunt <[email-masked]>
Date: Tue, 11 Sep 2012 18:07:43 +0000

On Tue, Sep 11, 2012 at 12:37:30PM -0400, Ted Lemon wrote:
> No.   Things change.   All that's required to deal with this is that the
> underlying protocol support it.   The DHCP DUID identification system
> does support this kind of change, as long as the actual device doesn't
> change.   If the device changes, then when the registration expires, the
> name can be reclaimed.

This does raise a point, though:  Dynamic DNS doesn't have an expiration
mechanism.  Populating the DNS using mDNS is a good idea, I think, but it
might be nice if we had some method of signaling the intended future
disposation of a name.

I'm thinking along the lines of a new rrtype, or maybe just a TXT record,
that can indicate things like "after time T, it's okay to delete this
rrset", or "if this name already exists with a different address, it's
okay to replace the old one instead of adding to it".

My home zone is cluttered up with the names of a couple of dozen laptops
and ipods belonging to neighbors and visitors over the past year.  It's
probably my own fault for misconfiguring DHCP (I don't think it's doing
the right thing in the "on expiry" block, and it hasn't been a high
priority for me to fix it).  But if we're going to be supplying DNS
data from multiple sources -- DHCP, mDNS, maybe others -- then it might
be a good idea to manage time limits on the demand side.

---

From: james woodyatt <[email-masked]>
Date: Tue, 11 Sep 2012 11:29:48 -0700

On Sep 11, 2012, at 11:07 , Evan Hunt <[email-masked]> wrote:
> 
> This does raise a point, though:  Dynamic DNS doesn't have an expiration mechanism.  [...] My home zone is cluttered up with the names of a couple of dozen laptops and ipods belonging to neighbors and visitors over the past year.  [...]

I recommend reading section 5 of "Understanding Apple's Back-to-My-Mac Service" [RFC 6281], which gives a brief summary of how this problem is effectively and reliably managed in that system.  There you will find references to the following truly under-loved technical specifications:

  <http://tools.ietf.org/html/draft-sekar-dns-ul>
  <http://tools.ietf.org/html/draft-sekar-dns-llq>

Maybe HOMENET could push for these to be taken up as IETF work items?

---

From: Evan Hunt <[email-masked]>
Date: Tue, 11 Sep 2012 18:46:44 +0000

> I recommend reading section 5 of "Understanding Apple's Back-to-My-Mac Service" [RFC
> 6281], which gives a brief summary of how this problem is effectively and reliably
> managed in that system.  There you will find references to the following truly
> under-loved technical specifications:
> 

Thanks for the pointer.  I'm not sure about long lived queries, but update
leases is clearly useful, and I would support resurrecting it.

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Sep 2012 13:07:39 -0700

On 09/11/2012 11:07 AM, Evan Hunt wrote:
> My home zone is cluttered up with the names of a couple of dozen laptops and ipods belonging to neighbors and visitors over the past year. It's probably my own fault for misconfiguring DHCP (I don't think it's doing the right thing in the "on expiry" block, and it hasn't been a high priority for me to fix it). But if we're going to be supplying DNS data from multiple sources -- DHCP, mDNS, maybe others -- then it might be a good idea to manage time limits on the demand side. 

A more fundamental question is enrollment. Security considerations are usually
the sworn enemy of zeroconf like solutions. How we make those tradeoffs will
most likely be a difficult conversation. What gives something on my home network
the right to announce itself, offer services, change state in some repository, etc,
etc?

If we're using the property that they need to have access to my home wifi
as proof the device is "mine" rather than "somebody else's", then lets stop
right  now with the posture that what we're doing is "zeroconf" because
configuring a wifi password is most certainly not "zeroconf".

Which brings me to: we shouldn't be hung up with "zeroconf", we should
be shooting for "littleconf".

Mike

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Sep 2012 16:26:07 -0400

> be shooting for "littleconf".

Yup.

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 11 Sep 2012 16:57:08 -0400

In message <[email-masked]>
 
> answer, given the facts of the world about DNS name registration and

Andrew,

+1

I agree that multiple namespaces are harful, and multiple additional
namespaces of mDNS, llmnr, NetBIOS even more harmful.

So the question is what motivated these rather than use DNS.  For mDNS
and I think the others it was the absense of a need to provide and
pick a DHCP/dynDNS server and just multicast the identities, plus
simple service discovery (though admitedly confined to a single
subnet).  So lets solve this for DHCP/dynDNS.

I'll start with the simplest cases and move to more involved.

In the case where there is nothing but a computer and printer, either
the computer needs to volunteer to be DHCP server and dynDNS
nameserver or addresses and names don't exist.  With IPv4 and mDNS
and no DHCP server there are still no addresses (unless things default
to 192.168.0.1 or similar).  With IPv6 there are ULA that can be used
and then its just a matter of naming.

If DNS is used in the above scenario, then something has to come up as
the DHCP/DNS server and do dynDNS, in this case just collecting the
name/ULA mapping.  If a router comes up and has a GUA prefix, there
needs to be a way for the computer to transfer control to the router.
With DHCP server preference set appropriately, with FORCERENEW and
Forcerenew Nonce Authentication, this is acheivable and reasonably
secure.

A multicast "I'm a DHCP server and just came up" would trigger
anything acting as a DHCP server to take notice.  For IPv6 this could
be sent to the All_DHCP_Relay_Agents_and_Servers multicast address.
AFAIK DHCP relays and servers and configured and there is no mechanism
available for servers to dynamically discover other DHCP servers and
coordinate as peers.

The above would require very little change to DHCP or DNS.  Other than
that it is just usage and therefore an Information RFC or BCP is all
that is needed.

The case where a router comes up but has no GUA prefix and sits on two
subnets also has to be handled.  In that case the router may have
priority over computers offering DHCP/dynDNS and the same can occur,
with the router providing names and routes to ULA on each subnet.
Again, no change to DHCP or DNS, just usage.

If more than one router comes up and none have a GUA prefix, then they
must make names available.  Collecting name/ULA mappings is the same
there is no means to coordinate the DNS namespace so that Router-A can
announce name/ULA mappings for devices connected only to Router-B.
Here an extension is needed.  One possibility is that each subnet
becomes a DNS zone and exactly one router connected to that subnet is
selected to do DHCP/dynDNS for that subnet.  The other routers must
discover each other and exchange names.

Reasonable default names is also an issue.  Two routers named
"linksys" doesn't help, just as two printers named "printer1" doesn't
help.  I'm not sure how (or if) mDNS solves the latter problem.  I
suspect it doesn't.  What might be needed is a means for a DHCP server
to assign a host name based on what the client sent with a digit (or
two if needed) appended to the conflicting name.  A similar technique
could be applied to routers coming up with the same name.

In past postings I have suggested that a router without a GUA prefix
snd a DHCP request as a client first and try to obtain a GUA prefix,
and absent of that try to negociate with other DHCP servers over what
address to use and how to divide up the sitelocal name space.

Another case is where a router comes up and has a GUA prefix or has
discovered one (service provider link came up, one got configured,
etc).  A lot of FORCERENEW exchanges would occur and hosts would get
GUA addresses.  Subdividing the GUA prefix would be based on number of
hosts reported per subnet and margins for growth to avoid additional
FORCERENEW as new hosts came up on an existing subnet.

Another case for address allocation is more than one router coming up
with different GUA prefixes.  Each would subdivide, and hosts could
now be offerred more than one address (if DHCP supported it) or a tie
breaker is need (shortest route, plus other tie breaker) to pick a
GUA.  The former is better so a change in route costs does not require
a FORCERENEW.

The last case for address allocation is more than one router with the
same GUA prefix.  One has to be picked to subdivide the GUA prefix.
Otherwise not much changes.

A second dimension is the root of the namespace.  If the initial root
is .sitelocal and a router comes up with (or somehow discovers) a DNS
domain for which it is authoritative (ie: primary), then FORCERENEW is
needed to change the domain name and likely also the DNS nameserver
list, though other routers could be granted secondary.  The dynamic
namespace can then be subdivided among subnets creating zones in the
DNS namespace rooted at "." rather than at ".sitelocal".

btw- Using DNSSEC with ".sitelocal" requires manual key exchange and
may not be practical.

If two (or more) routers come up with different namespaces rooted at
".", then the addresses space can be in both forward lookups.  If
there are also two (or more) GUA (highly likely) then the rDNS for the
GUA provided by each router can point to the zone provided by that
router if it is also authoritative for a GUA prefix.

The only other motivation for mDNS and friends is service discovery.
LL scope multicast work on a subnet.  Site local multicast is now
depricated but prior proposals for service discovery anycast have
suggested gradually increasing TTL on a globally scoped multicast.
The semantics here are different from mDNS and friends.  In mDNS a LL
multicast says "I am a <service>" where in anycast the host says "are
there any <service> out there" and can therefore find services off
subnet by increasing TTL until <service> is found.  (ie: printer).

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 11 Sep 2012 17:14:11 -0400

In message <[email-masked]>
Michael Thomas writes:
 
> > There are a couple of options being pursued in the DHC working
> > group; the DHCP address registration process would be an obvious
> > mechanism for leveraging DHCP to populate the DNS.  The idea here is
> > that you do RA+SLAAC, or RA+CGA, and then you contact the DHCP
> > server to tell it what address you allocated and what name you want
> > associated with it, and to get any local network configuration
> > information you might need.
>  
> Maybe somebody can educated me, but isn't it a bit dangerous to use an
> auto-configured address as a way to contact a host? If I change out my
> > However, of course this is new technology that isn't even
> > standardized yet.  I'd like it if homenet recommended implementing
> > this, but I think another way of populating the DNS is through mDNS—w
> > hen a host publishes its name in mDNS, it's assumed to be valid as
> > long as no conflicting registration has been made locally.  I don't
> > particularly love this method because mDNS doesn't have the same
> > duplicate detection features that DHCP does through the DUID, but it
> > wouldn't be _worse_ than plain mDNS, and would allow the DNS
> > resolver to query a consistent FQDN tree for local names, so that it
> > would work whether you were attached to the local wire or not.
>  
> DHCP may be a solution but it ought not be the only solution, right?
> What if there's no relationship between my dns repository and the DHCP
> server? That is, suppose that Google hosted my DNS and thus wasn't
> actually on my home network. I suppose that a home router could work
> in concert by either working with its DHCP or listening to mdns
> chatter and then doing IXFR's to a name server. Is that what's being
> talked about?
>  
> Mike

Mike,

> suppose that Google hosted my DNS

Create a zone names <myhome>.<mydomain-at-google-ns> and then you can
have a zone for which dyn-DNS is authoritative.  At that point the
dynDNS server and DHCP server need not be the same host, just both
under your control and able to use the dynDNS protocol to populate the
dynDNS domain (the <myhome> subdomain in the prior example).

Unless of course you can convince Google to honor dynDNS from your
DHCP server (hint: no chance, create a subdomain if you want dynDNS).

If Google is a secondary, not primary, then problem solved.

Personally I have stayed away from mDNS, compiling out avahi (mDNS) or
bonjour or anything similar in any port that offerred it.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 11 Sep 2012 18:16:00 -0400

> be a good idea to manage time limits on the demand side.

Even,

I've avoided that problem with the opposite approach.  I have both
fixed DNS and DHCP fixed entries for the laptops in my home.  Anything
else gets an address from the pool and no name except in the DHCP
leases file.  The only "anything else" is grandpa's laptop when he
visits and my kids laptops when they are home, or other guests.

I also get a stupid name based on serial number from one appliance
that doesn't allow the name to be changed and also don't allow a fixed
address to be configured.  At least I know what it is and I can define
a meaningful DNS name for it even if it won't take one.

If my wife or I take a laptop elsewhere, to the library for example
(or to IETF), then DHCP gives me a different address.  No big deal but
also no reconfig to go elsewhere.  A bit deal for my wife, but then
again she leaves her laptop at home all the time.

I also have two mystery devices with a uid and no client-hostname.
Not pingable.  Hmm.  :-(

I would think that the dynDNS name would go away if the DHCP lease
expired.  Apparently not.  I'd call that a bug.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 11 Sep 2012 18:21:52 -0400

In message <[email-masked]>
james woodyatt writes:
 
> I recommend reading section 5 of "Understanding Apple's Back-to-My-Mac
> Service" [RFC 6281], which gives a brief summary of how this problem
> is effectively and reliably managed in that system.  There you will
> find references to the following truly under-loved technical
> specifications:
>  

Or maybe not.

The situation right now is multiple name and service discovery
protocols for Window PC, multiple name and service discovery protocols
for Apple, and multiple name and service discovery protocols for Linux
and very limited intersection between them, plus they all only work on
a single subnet and therefore are useless in anything but homes and
the most tiny soho or enterprise.

If dynDNS doesn't delete with the lease expire, that just a bug.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 11 Sep 2012 19:53:37 -0400

In message <[email-masked]>
Michael Thomas writes:
 
> > My home zone is cluttered up with the names of a couple of dozen
> > laptops and ipods belonging to neighbors and visitors over the past
> > year. It's probably my own fault for misconfiguring DHCP (I don't
> > think it's doing the right thing in the "on expiry" block, and it
> > hasn't been a high priority for me to fix it). But if we're going to
> > be supplying DNS data from multiple sources -- DHCP, mDNS, maybe
> > others -- then it might be a good idea to manage time limits on the
> > demand side.
>  
> A more fundamental question is enrollment. Security considerations are
> usually the sworn enemy of zeroconf like solutions. How we make those
> tradeoffs will most likely be a difficult conversation. What gives
> something on my home network the right to announce itself, offer
> services, change state in some repository, etc, etc?
>  
> If we're using the property that they need to have access to my home
> wifi as proof the device is "mine" rather than "somebody else's", then
> lets stop right now with the posture that what we're doing is
> "zeroconf" because configuring a wifi password is most certainly not
> "zeroconf".

We had a similar discussion before and I pointed out that for security
some form of exchange of keys or certificates was needed.

Having a factory configured root DNSSEC certificate gets one form of
trust anchor.  The browser certificates provide another, possibly very
flawed forn of trust anchor.

A means to create a local certificate and manually distribute this
could be the basis of a local trust anchor for local addresses and
names.

For specific services it may be best to have certificates or keys
exchanged between client and server.

> be shooting for "littleconf".

Agree.  Insecure with zeroconf.  Secure with littleconf.  And insecure
is bad.  Very bad with GUA.

Curtis

---

From: Michael Thomas <[email-masked]>
Date: Tue, 11 Sep 2012 18:14:18 -0700

> some form of exchange of keys or certificates was needed.

Here is usually where IETF usually wraps around the axle. I'm not
saying that "has my wifi password, therefore is allowed" is bad, I'm
just saying that it's not zeroconf. We need to be extremely careful
that the best is the enemy of the good. At the point that we're talking
about certs we've almost certainly wandered into something well
beyond "littleconf". If we can get by with "has my wifi password"
or similar, we're still probably on track. Or maybe ssh-like leap of
faith kinds of bare public key enrollment is ok.

In any case, my larger point is that "littleconf" might also involve having
to give a name to some of my devices so that I don't have to remember
that megacorp-light-switch-1279385xxc7 is the front room mood lighting
in addition to giving it my wifi password for the home automation SSID.

Mike

---

From: Curtis Villamizar <[email-masked]>
Date: Tue, 11 Sep 2012 22:36:42 -0400

In message <[email-masked]>
 
> faith kinds of bare public key enrollment is ok.

"keys or certificates" would include public/private key pairs like the
rsa or dsa keys that ssh uses.

> in addition to giving it my wifi password for the home automation SSID.

And my SIP phone has a serial number for a host name.  One problem is
that some clueless programmers have allowed any characters to be
entered into the host name string, so DHCP can return a hostname that
has more than just DNS allowed characters.  I'm not sure %20 and other
substitutes legal in URLs are legal in hostnames.  I don't think so.

Its OK to have "Bill's Laptop" in the leases file, but you can't put
that into a DNS hostname and "Bill T. Cat's Laptop" would be worse
because of the dot.  But you might get this from DHCP.

Maybe a good start for homenet is recommendations on what should be
setable on any home device and constraints (hostnames within valid DNS
character set being one example).  Allowing a fixed address is another
(my SIP phone DNS client is a bit broken and doesn't always renew
before the lease expires and then locks up if the address changes).
Supporting IPv6 is yet another.

Curtis

---

From: Ted Lemon <[email-masked]>
Date: Tue, 11 Sep 2012 22:57:20 -0400

> If dynDNS doesn't delete with the lease expire, that just a bug.

At least the ISC and Nominum DHCP servers automatically delete the dynamic name when the lease expires.   I assume Cisco's does as well.  Your point about widespread protocol support is a good one—I have a lot of trouble getting consistent behavior out of mDNS.   I have no problem getting consistent behavior out of DNS.

---

From: Ray Hunter <[email-masked]>
Date: Wed, 12 Sep 2012 08:41:11 +0200

Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server 
anyway in Homenet, why don't we go for the classic enterprise set up 
that has run for years for IPv4, rather than trying to shoe horn locally 
assigned SLAAC addresses into global DNS?

It's not as though you can buy any piece of domestic networking 
equipment today that does not support DHCPv4, so why not DHCPv6?

So we'd have:
Homenet router <-> ISP = DHCP-PD to learn prefixes [existing]
in Homenet prefix allocation & distribution [work in progress]
DHCPv6 from the Homenet router to the ISP could be extended to 
communicate any ISP DNS domain settings to the Homenet [gap]
elect/configure a unicast DNS server for Homenet [gap]
run standard unicast DNS [existing]
elect/configure a DHCPv6 server for use within Homenet [gap]
The routers that are acting as clients for DHCP-PD would seem good 
candidates.
run standard DHCPv6 server on local Homenet router[existing]
configure DHCPv6 relay per Homenet router to point to Homenet DHCPv6 
server[existing standard, although autoconfig is a gap for the election 
process]
use DHCPv6 server to update DNS content using RFC 2316 Dynamic DNS 
update on behalf of end clients [existing]
client -> Homenet router RFC 3315 DHCPv6 based address configuration, 
and standard unicast DNS [existing]

Then the client only needs to do stuff that is already incorporated in 
any operating system used in business.

Or is this stateless /stateful war still too fresh in the collective 
IETF memory?

Ted Lemon wrote:
> On Sep 11, 2012, at 11:17 AM, Kerry Lynn<[email-masked]>  wrote:

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Sep 2012 08:36:54 -0400

On Sep 12, 2012, at 2:41 AM, Ray Hunter <[email-masked]> wrote:
> Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server anyway in Homenet, why don't we go for the classic enterprise set up that has run for years for IPv4, rather than trying to shoe horn locally assigned SLAAC addresses into global DNS?

Two reasons.   First, there's strong opposition to this, and so it will never happen, whether it is the right idea or not (I don't think it's particularly the right idea, although I'm not vehemently opposed to it either).   Secondly, it precludes the use of CGA by hosts.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Sep 2012 11:02:01 +1000

In message <[email-masked]>, Ted Lemon writes:
> > Ted, respect your DHCP/DNS knowledge, but if we need a DHCP server anyway i
> n Homenet, why don't we go for the classic enterprise set up that has run for
>  years for IPv4, rather than trying to shoe horn locally assigned SLAAC addre
> sses into global DNS?
> 
> Two reasons.   First, there's strong opposition to this, and so it will never
>  happen, whether it is the right idea or not (I don't think it's particularly
>  the right idea, although I'm not vehemently opposed to it either).   Secondl
> y, it precludes the use of CGA by hosts.

Note updating DNS involves both FORWARD and REVERSE entries and the
solutions can be different.

My machines have names.  Those names don't change as I move around
the world.  Random DHCP servers at coffee shops DO NOT have the
ability to update the DNS entries for those names.  They do have the
authority to update the PTR records in in-addr.arpa and ip6.arpa
namespaces.

Machines start off with mDNS to avoid bootstrap problems.  They
then have the ability to get a TSIG using TKEY signed with a
administrators TSIG (think Username/Password pair) for the forward
zone.  This will be stored in non-volitile storage on the master
nameserver and on the client.  Once the client has the TSIG key it
uses that to update its own forward entries.

Machines register PTR records in the reverse zones using TCP as the
authenticator in the reverse zone unless there is a DHCP option
that says to use the DHCP server to relay the PTR record update.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Sep 2012 21:57:09 -0400

> authority to update the PTR records in in-addr.arpa and ip6.arpa

We're not talking about mobile IP here—we''re talking about naming in the homenet.   The technology has existed for over a decade to do what you describe with DHCP and DDNS in IPv4, but AFAIK nobody uses it, for two reasons: one, I don't think it actually serves a real need, and two, it requires geek skills to set up, which most people don't have.   But the second point is really a footnote to the first.

There's a draft in the DHC working group for setting up the reverse zone...

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Sep 2012 12:28:40 +1000

In message <[email-masked]>, Ted Lemon writes:
> We're not talking about mobile IP here=97we''re talking about naming in the=
>  homenet.   The technology has existed for over a decade to do what you des=
> cribe with DHCP and DDNS in IPv4, but AFAIK nobody uses it, for two reasons=
> : one, I don't think it actually serves a real need,

More because no one looked at the whole picture and tried to get a
comprehensive solution.  It has multiple moving parts from multiple
vendors.

> and two, it requires g=
> eek skills to set up, which most people don't have.

Which is a UI / product support problem.  The Mac has DNS registration
under Sharing.  It requires manual entry of the TSIG key which
currently has to be entered into the nameserver for each device.
It could be made as simple as BlueTooth associations are.

>   But the second point =
> is really a footnote to the first.

I have laptops that connect to the home net and then go walkabout.
I suspect a large percentage of homes have some equipment that moves
about.  Those laptops still want to do things to the home net
occasionally.  Devices on the home network want to push stuff to
those laptops occasionally.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 12 Sep 2012 23:06:29 -0400

> It could be made as simple as BlueTooth associations are.

It's probably true that a homenet router could be set up to allow for DNS updates from remote locations using a TSIG or SIG(0) signature.   It might be nice to list this as a feature if we feel it can be specified cleanly.   But as you say, it would be necessary for third party devices to implement this, and in order for them to do that they have to perceive a need.   It could happen; I just don't think it's going to be valued enough to motivate people do make the effort required to set it up.   I think there are a lot of steps between where we are now and an environment where people see the need for this.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 13 Sep 2012 13:54:07 +1000

In message <[email-masked]>, Ted Lemon writes:
> It's probably true that a homenet router could be set up to allow for =
> DNS updates from remote locations using a TSIG or SIG(0) signature.   It =
> might be nice to list this as a feature if we feel it can be specified =
> cleanly.   But as you say, it would be necessary for third party devices =
> to implement this, and in order for them to do that they have to =
> perceive a need.   It could happen; I just don't think it's going to be =
> valued enough to motivate people do make the effort required to set it =
> up.   I think there are a lot of steps between where we are now and an =
> environment where people see the need for this.

MacOS already supports this so clearly someone at Apple thinks
"there is a need".  You turn on Active Directory in Windows and
your machines will try to register themselves when on the road.

This working group is looking at a paradigm shift in how home
networking is done.  We now have directly addressable machines on
the home network.  Publishing addresses to the world now makes sense
for lots of reasons including we are now reachable.

The "nobody is doing now" argument doesn't cut it here.  Are we
about enabling future development or styfling it?  The world is
slowly heading away from asymetric home links (cable/adls) to
symetric home links (fibre) with enough bi-directional bandwidth
for the home user to host whatever services that want to.

We need to forward thinking enough to put in the infrastructure to
support that.  That means more than addresses being added to the
DNS which is basically where integrated DNS/DHCP solutions stop.

Mark

---

From: Ray Hunter <[email-masked]>
Date: Thu, 13 Sep 2012 07:35:51 +0200

Fair counter point to my suggestion. Enterprises don't generally put 
laptops in public viewable DNS.

Isn't your requirement to support highly mobile devices a good reason to 
avoid mDNS wherever possible?

[mDNS being link local specific, and any extensions/gateways from mDNS 
to unicast DNS will also be local network specific, so your favourite 
coffee shop network may not support them]

regards,
RayH
> Mark Andrews <mailto:[email-masked]>
> 13 September 2012 03:02
>
> ------------------------------------------------------------------------
<snip>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Sep 2012 08:54:35 -0400

On Sep 12, 2012, at 11:54 PM, Mark Andrews <[email-masked]> wrote:
> "there is a need". 

No, MacOS doesn't support this.   MacOS supports DynDNS-like functionality, not roaming via DNS.   And it supports it in the sense that geeks can make it work, not in the sense that regular end users can make it work.   The necessary enabling work to make this usable is far beyond what Apple is doing.   Also beyond what Microsoft is doing.

It's not hard, and if there's demand, I'm sure the work will get done.   As I said earlier, I don't oppose putting support for it into a spec, if it can be done cleanly.   But I don't think we'll see widespread implementation anytime soon.

---

From: joel jaeggli <[email-masked]>
Date: Thu, 13 Sep 2012 09:27:08 -0700

On 9/12/12 10:35 PM, Ray Hunter wrote:
> Isn't your requirement to support highly mobile devices a good reason 
> to avoid mDNS wherever possible?
MDNS has a purpose, which is to locate on-link resources. particularly 
if a network is adhoc or ephemeral it seems like the appropriate tool 
for that. two devices forming an adjacency may have no other network.

---

From: Ray Hunter <[email-masked]>
Date: Thu, 13 Sep 2012 18:49:42 +0200

Sure, but the scope of this discussion is name resolution in Homenet, 
where there is always at least 1 router present.
So these two devices could always use unicast to reach a rendezvous point.

What devices do on other ephemeral ad hoc networks is out of scope.
> joel jaeggli <mailto:[email-masked]>
> 13 September 2012 18:27
>> [mDNS being link local specific, and any extensions/gateways from 
>> mDNS to unicast DNS will also be local network specific, so your 
>> favourite coffee shop network may not support them]
>>
>> regards,
>> RayH
> Ray Hunter <mailto:[email-masked]>
> 13 September 2012 07:35
> Ted Lemon <mailto:[email-masked]>
> 12 September 2012 14:36
>
> Two reasons. First, there's strong opposition to this, and so it will 
> never happen, whether it is the right idea or not (I don't think it's 
> particularly the right idea, although I'm not vehemently opposed to it 
> either). Secondly, it precludes the use of CGA by hosts.
>
> Ray Hunter <mailto:[email-masked]>
> 12 September 2012 08:41
> that has run for years for IPv4, rather than trying to shoe horn 
> locally assigned SLAAC addresses into global DNS?
>
> server[existing standard, although autoconfig is a gap for the 
> election process]

---

From: Michael Thomas <[email-masked]>
Date: Thu, 13 Sep 2012 10:12:25 -0700

> We're not talking about mobile IP here—we''re talking about naming in the homenet.   The technology has existed for over a decade to do what you describe with DHCP and DDNS in IPv4, but AFAIK nobod…

Suppose the real need would be to have a viable way to get rid of
putting raw IP addresses in upper level protocols? Ie, SDP, etc?

Mike

---

From: David R Oran <[email-masked]>
Date: Thu, 13 Sep 2012 16:15:27 -0400

> putting raw IP addresses in upper level protocols? Ie, SDP, etc?
That is a much broader architectural discussion than just DNS versus other naming systems. The whole question of how and whether A can tell B in an application protocol that he ought to talk to X in an independent communication and whether the expectation is that X=A can be made better, worse or just different when X is a name versus an address.

I suggest we not talk about it - we risk ultimate regression to Godwin's Law.

The

---

From: Curtis Villamizar <[email-masked]>
Date: Thu, 13 Sep 2012 23:43:14 -0400

> either).  Secondly, it precludes the use of CGA by hosts.

Not using SLAAC does not preclude the use of CGA (RFC3971).  The host
can pick its own address with DHCP and use INFORM.  It won't stop the
host from using CGA or SEND (secure ND, RFC3972).

Not that I think very highly of CGA as a security measure to start
with but it could save a TCP RST on a TCP session running a protocol
secured at the application layer and is lighter weight than IPSEC.

That CGA was proposed in the first place is further proof that 128
bits in IPv6 addresses was pure folly.  Unfortunately that decision
dates all the way back to around 1995 and the huge addresses has been
one reason IPv6 has been so slow to catch on.  CGA tells us that the
bottom 64 bits serves no purpose so we might as well use it for
something else.  The Flow ID field is another useless wart.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 14 Sep 2012 00:28:38 -0400

In message <[email-masked]>
Ted Lemon writes:
 
> We're not talking about mobile IP here—we''re talking about naming in
> the homenet.  The technology has existed for over a decade to do what
> you describe with DHCP and DDNS in IPv4, but AFAIK nobody uses it, for
> two reasons: one, I don't think it actually serves a real need, and
> two, it requires geek skills to set up, which most people don't have.
> But the second point is really a footnote to the first.

DHCP and DDNS is used in enterprise and not for mobility, except to
some extent mobility within the enterprise (laptops wandering to
conference rooms).  For anything that offers a service, meaning
anything useful to connect to, DDNS is used so that if IT rearranges
the wired ethernet, the server automagically has the same name but
shows up somewhere else.  In a past life IT tried to get me to do this
with a CVS/SVN server but their DDNS didn't work enough times that I
got them to go back to static entries.  You can do things like direct
SIP to a laptop with this and SIP URLs rather than (the far more
common) B2BUA.

> There's a draft in the DHC working group for setting up the reverse

Did you mean:

  draft-lemon-dhc-dns-pd-01
  Populating the DNS Reverse Tree for DHCP Delegated Prefixes

Earlier in this thread you said:

> > locally assigned SLAAC addresses i nto global DNS?
>

There is also

  draft-ietf-dhc-cga-config-dhcpv6-02
  Configuring Cryptographically Generated Addresses (CGA) using DHCPv6

which is where I wondered why you said that CGA could not be used and
maybe I missed something.  In your opinion CGA cannot be used if
... SLAAC is not used?  ... DHCPv6 is used?  ... something else?
Since you made that statement, exactly what did you means.

Curtis

---

From: Curtis Villamizar <[email-masked]>
Date: Fri, 14 Sep 2012 00:59:41 -0400

In message <[email-masked]>
Mark Andrews writes:

[... trim ... net related to point below ...]

> those laptops occasionally.

First thing is as soon as you walk from one AP to another, your
channel changes and at least with Linux/BSD, nothing much happens.
What should happen is wpa_supplicant should notify dhclient to try to
renew the lease.  If the APs are bridged, nothing need happen (but
there will be more broadcast/multicast than need be).  If you stepped
into another subnet, then you'll need a new DHCP lease.

I haven't tried this with a MAC.  PCs don't seem to work unless you
close the lid and suspend and then unsuspend.

I don't think that with any OS right now (maybe android) you could
walk down the street with an open laptop and switch from one business
wifi to another (different subnets) and just have it work.  OTOH -
open wifi may not be common enough to try it on Main Street.

OTOH if you shut down at home, go to the library or coffee shop, and
start up, all is fine with any OS.  Either the suspend/resume (when it
doesn't hang the laptop) or shutdown/startup will trigger requesting a
rebind and getting refused and getting a new lease.

I've also run into the situation where a channel has a great signal
but there is no DHCP server to be found.

So my point is that

  1) changing wireless channels should force an attempt to rebind, and

  2) not getting any DHCP response or not getting all the required
     DHCP parameters should temporarily eliminate a channel from
     consideration and force roaming to another.

I think homenet could recommend these actions in some document, though
I don't see an existing document where it fits in.

Curtis

---

From: Mark Baugher <[email-masked]>
Date: Tue, 11 Sep 2012 18:14:49 -0700

> exchanged between client and server.

In an unmanaged environment, some form of a ceremony is needed
(http://eprint.iacr.org/2007/399.pdf), such as to prove locality
and control.  

Mark

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 15 Sep 2012 14:12:58 +0100

> I suggest we not talk about it - we risk ultimate regression to Godwin's Law.

People who want to talk about it can still do so in the context of
http://tools.ietf.org/html/draft-carpenter-referral-ps (Problem
Statement for Referral) on the [email-masked] list. It's been hard
to get that conversation going, though.

  Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 13 Sep 2012 23:51:58 -0400

> host from using CGA or SEND (secure ND, RFC3972).

Curtis, go read the RFCs you're pontificating about and then get back to us.   Please?

---

From: Ted Lemon <[email-masked]>
Date: Fri, 14 Sep 2012 11:00:20 -0400

On Sep 14, 2012, at 12:28 AM, Curtis Villamizar <[email-masked]> wrote:
> You can do things like direct

I would really like to see this happen, but we are so far from being able to do this at the moment...

>  Populating the DNS Reverse Tree for DHCP Delegated Prefixes

Yes.

> Since you made that statement, exactly what did you means.

If your address is assigned by the DHCP server, it can't be a CGA address, because the private key isn't private.  The DHC working group is working on a draft to allow addresses generated using SLAAC or CGA to be registered to the DHCP server in a way that allows DHCP updates to the DNS, either the forward and reverse zones, or just the reverse zone.   But this is new work, and hasn't been published as an RFC yet.    The relevant draft is here: http://datatracker.ietf.org/doc/draft-ietf-dhc-addr-registration/

---

From: Ted Lemon <[email-masked]>
Date: Wed, 19 Sep 2012 16:48:41 -0400

> If your address is assigned by the DHCP server, it can't be a CGA address, because the private key isn't private.  The DHC working group is working on a draft to allow addresses generated using SLA…

Sorry for the late barrage of messages in this discussion—my mail program was jammed up for some reason.