Re: [homenet] Unicast DNS within the Homenet?

[Ted Lemon]

On Sep 14, 2012, at 11:00 AM, Ted Lemon  wrote:
> 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/

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ted Lemon]

On Sep 14, 2012, at 12:28 AM, Curtis Villamizar  wrote:
> You can do things like direct
> SIP to a laptop with this and SIP URLs rather than (the far more
> common) B2BUA.

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

> 
>> There's a draft in the DHC working group for setting up the reverse
>> zone...
> 
> Did you mean:
> 
>  draft-lemon-dhc-dns-pd-01
>  Populating the DNS Reverse Tree for DHCP Delegated Prefixes

Yes.

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

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/

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ted Lemon]

On Sep 13, 2012, at 11:43 PM, Curtis Villamizar  wrote:
> 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).

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Brian E Carpenter]

On 13/09/2012 21:15, David R Oran wrote:
> On Sep 13, 2012, at 1:12 PM, Michael Thomas  wrote:
> 
>> On 09/12/2012 06:57 PM, Ted Lemon wrote:
>>> On Sep 12, 2012, at 9:02 PM, Mark Andrews  wrote:
 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.
>>> 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.
>>>
>> 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?
>>
> 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.

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 gr...@ietf.org list. It's been hard
to get that conversation going, though.

  Brian


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Mark Baugher]

On Sep 11, 2012, at 4:53 PM, Curtis Villamizar wrote:

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

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Curtis Villamizar]

In message <20120913022841.a98d624f6...@drugs.dv.isc.org>
Mark Andrews writes:

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

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

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Curtis Villamizar]

In message <7e23e81a-9daa-45ac-a577-3b0574e1d...@fugue.com>
Ted Lemon writes:
 
> On Sep 12, 2012, at 9:02 PM, Mark Andrews  wrote:
> > 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.
>  
> 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
> zone...

Did you mean:

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

Earlier in this thread you said:

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

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Curtis Villamizar]

In message 
Ted Lemon writes:
 
> On Sep 12, 2012, at 2:41 AM, Ray Hunter  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.


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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[David R Oran]

On Sep 13, 2012, at 1:12 PM, Michael Thomas  wrote:

> On 09/12/2012 06:57 PM, Ted Lemon wrote:
>> On Sep 12, 2012, at 9:02 PM, Mark Andrews  wrote:
>>> 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.
>> 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.
>> 
> 
> 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?
> 
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 
> Mike
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Michael Thomas]

On 09/12/2012 06:57 PM, Ted Lemon wrote:

On Sep 12, 2012, at 9:02 PM, Mark Andrews  wrote:

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.

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.



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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ray Hunter]

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 
13 September 2012 18:27
On 9/12/12 10:35 PM, Ray Hunter wrote:
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 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.


[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 
13 September 2012 03:02

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.


 



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet



Ray Hunter 
13 September 2012 07:35
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 
13 September 2012 03:02

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.

Ted Lemon 
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 
12 September 2012 08:41
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 coll

Re: [homenet] Unicast DNS within the Homenet?

[joel jaeggli]

On 9/12/12 10:35 PM, Ray Hunter wrote:
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 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.


[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 
13 September 2012 03:02

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.





___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ted Lemon]

On Sep 12, 2012, at 11:54 PM, Mark Andrews  wrote:
> MacOS already supports this so clearly someone at Apple thinks
> "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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ray Hunter]

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 
13 September 2012 03:02

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.





___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Mark Andrews]

In message <279cabeb-4dee-45c7-8cf2-8c34eac3c...@fugue.com>, Ted Lemon writes:
> On Sep 12, 2012, at 10:28 PM, Mark Andrews  wrote:
> > 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.
> 
> 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
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ted Lemon]

On Sep 12, 2012, at 10:28 PM, Mark Andrews  wrote:
> 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.

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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Mark Andrews]

In message <7e23e81a-9daa-45ac-a577-3b0574e1d...@fugue.com>, Ted Lemon writes:
> On Sep 12, 2012, at 9:02 PM, Mark Andrews  wrote:
> > 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.
> 
> 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.

> There's a draft in the DHC working group for setting up the reverse zone...
> 
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ted Lemon]

On Sep 12, 2012, at 9:02 PM, Mark Andrews  wrote:
> 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.

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Mark Andrews]

In message , Ted Lemon writes:
> On Sep 12, 2012, at 2:41 AM, Ray Hunter  wrote:
> > 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: ma...@isc.org
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ted Lemon]

On Sep 12, 2012, at 2:41 AM, Ray Hunter  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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ray Hunter]

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

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?


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.



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ted Lemon]

On Sep 11, 2012, at 6:21 PM, Curtis Villamizar  wrote:
> 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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Curtis Villamizar]

In message <504fe1ea.90...@mtcc.com>
Michael Thomas writes:
 
> On 09/11/2012 04:53 PM, Curtis Villamizar wrote:
> > In message <504f9a0b.1080...@mtcc.com>
> > Michael Thomas writes:
> >   
> > 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.
>  
> 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.

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

> 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

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Michael Thomas]

On 09/11/2012 04:53 PM, Curtis Villamizar wrote:

In message <504f9a0b.1080...@mtcc.com>
Michael Thomas writes:
  
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.


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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Curtis Villamizar]

In message <504f9a0b.1080...@mtcc.com>
Michael Thomas writes:
 
> 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".

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.

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

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

> Mike

Curtis
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Curtis Villamizar]

In message 
james woodyatt writes:
 
> On Sep 11, 2012, at 11:07 , Evan Hunt  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:
>  
>   
>   
>  
> Maybe HOMENET could push for these to be taken up as IETF work items?
> --
> james woodyatt 
> member of technical staff, core os networking


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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Curtis Villamizar]

In message <20120911180743.gd15...@isc.org>
Evan Hunt writes:
 
> 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.
>  
> -- 
> Evan Hunt -- e...@isc.org
> Internet Systems Consortium, Inc.


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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Curtis Villamizar]

In message <504f65c7.4010...@mtcc.com>
Michael Thomas writes:
 
> On 09/11/2012 09:01 AM, Ted Lemon wrote:
>  
> > 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
> 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—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 . 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  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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Curtis Villamizar]

In message <20120911145928.gc20...@mx1.yitter.info>
Andrew Sullivan writes:
 
> On Tue, Sep 11, 2012 at 02:45:12PM +0100, Brian E Carpenter wrote:
> > 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.
>  
> 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
> a...@anvilwalrusden.com


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 c

Re: [homenet] Unicast DNS within the Homenet?

[Ted Lemon]

On Sep 11, 2012, at 4:07 PM, Michael Thomas  wrote:
> Which brings me to: we shouldn't be hung up with "zeroconf", we should
> be shooting for "littleconf".

Yup.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Michael Thomas]

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Evan Hunt]

> 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:
> 
>   
>   
> 
> Maybe HOMENET could push for these to be taken up as IETF work items?

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

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[james woodyatt]

On Sep 11, 2012, at 11:07 , Evan Hunt  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:

  
  

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


--
james woodyatt 
member of technical staff, core os networking



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Evan Hunt]

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.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Evan Hunt]

On Tue, Sep 11, 2012 at 06:52:16AM -0700, Michael Thomas wrote:
> 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.

Another +1.

-- 
Evan Hunt -- e...@isc.org
Internet Systems Consortium, Inc.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ted Lemon]

On Sep 11, 2012, at 12:24 PM, Michael Thomas  wrote:
> 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?

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.

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

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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Michael Thomas]

On 09/11/2012 09:01 AM, Ted Lemon wrote:

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



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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Brian E Carpenter]

On 11/09/2012 15:59, Andrew Sullivan wrote:
> On Tue, Sep 11, 2012 at 02:45:12PM +0100, Brian E Carpenter wrote:
>> 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.
> 
> But you can't _make_ such a recommendation, because different
> scenarios -- network-topologically indistinguishable from one another
> -- 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

> 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
> 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ted Lemon]

On Sep 11, 2012, at 11:17 AM, Kerry Lynn  wrote:
> 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?

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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Kerry Lynn]

On Tue, Sep 11, 2012 at 10:00 AM, Ted Lemon  wrote:
> On Sep 11, 2012, at 9:52 AM, Michael Thomas  wrote:
>> 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.
>
> +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.
>
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-

> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Andrew Sullivan]

On Tue, Sep 11, 2012 at 02:45:12PM +0100, Brian E Carpenter wrote:
> 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.

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
a...@anvilwalrusden.com
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ted Lemon]

On Sep 11, 2012, at 9:52 AM, Michael Thomas  wrote:
> 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.

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Michael Thomas]

On 09/11/2012 12:19 AM, Ray Bellis wrote:

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.



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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Brian E Carpenter]

On 11/09/2012 14:11, Simon Perreault wrote:
> Le 2012-09-11 05:17, Brian E Carpenter a écrit :
>> Excuse my ignorance, but if a LAN has both mDNS and DNS available,
>> 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.

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Simon Perreault]

Le 2012-09-11 05:17, Brian E Carpenter a écrit :

Excuse my ignorance, but if a LAN has both mDNS and DNS available,
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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Brian E Carpenter]

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
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ray Bellis]

On 11 Sep 2012, at 02:41, james woodyatt  wrote:

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

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 big specification effort and 
> I'm not sanguine about the chances for adoption there.

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

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

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ray Bellis]

On 11 Sep 2012, at 05:25, Benjamin Kerensa 
mailto:bkere...@gmail.com>>
 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


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[joel jaeggli]

On 9/10/12 6:41 PM, james woodyatt wrote:

On Sep 10, 2012, at 05:34 , Ray Bellis  wrote:

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?" [*]

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?

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.

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[james woodyatt]

On Sep 10, 2012, at 05:34 , Ray Bellis  wrote:
> 
> 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?" [*]

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 
member of technical staff, core os networking



___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Curtis Villamizar]

In message <47437c06-fb3d-41ab-adb9-01a409164...@nominet.org.uk>
Ray Bellis writes:
 
> 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.


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 wirel

Re: [homenet] Unicast DNS within the Homenet?

[Kerry Lynn]

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-


On Mon, Sep 10, 2012 at 11:48 AM, Brian E Carpenter
 wrote:
> 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
>
>
> On 10/09/2012 15:17, Don Sturek wrote:
>> 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" 
>> wrote:
>>
>>> On 10/09/2012 14:09, Ray Bellis wrote:
 On 10 Sep 2012, at 13:58, Brian E Carpenter
  wrote:

> Using literal addresses is evil for many reasons - surely we don't
> need to
> 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".
>>> afaik Bonjour is a proprietary protocol. How can that be a good thing?
>>>
> 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.
 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
>>>
>>>
>>> ___
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>>
>>
>>
> ___
> homenet mailing list
> homenet@ietf.org
> https://www.ietf.org/mailman/listinfo/homenet
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ray Hunter]

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


Using literal addresses is evil for many reasons - surely we don't need to
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".


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.


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




___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Don Sturek]

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

>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
>
>
>On 10/09/2012 15:17, Don Sturek wrote:
>> 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" 
>> wrote:
>> 
>>> On 10/09/2012 14:09, Ray Bellis wrote:
 On 10 Sep 2012, at 13:58, Brian E Carpenter
  wrote:

> Using literal addresses is evil for many reasons - surely we don't
> need to
> 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".
>>> afaik Bonjour is a proprietary protocol. How can that be a good thing?
>>>
> 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.
 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
>>>
>>>
>>> ___
>>> homenet mailing list
>>> homenet@ietf.org
>>> https://www.ietf.org/mailman/listinfo/homenet
>> 
>> 
>> 


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Brian E Carpenter]

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


On 10/09/2012 15:17, Don Sturek wrote:
> 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" 
> wrote:
> 
>> On 10/09/2012 14:09, Ray Bellis wrote:
>>> On 10 Sep 2012, at 13:58, Brian E Carpenter
>>>  wrote:
>>>
 Using literal addresses is evil for many reasons - surely we don't
 need to
 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".
>> afaik Bonjour is a proprietary protocol. How can that be a good thing?
>>
 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.
>>> 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
>>
>>
>> ___
>> homenet mailing list
>> homenet@ietf.org
>> https://www.ietf.org/mailman/listinfo/homenet
> 
> 
> 
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Don Sturek]

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

>On 10/09/2012 14:09, Ray Bellis wrote:
>> On 10 Sep 2012, at 13:58, Brian E Carpenter
>> wrote:
>> 
>>> Using literal addresses is evil for many reasons - surely we don't
>>>need to
>>> 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".
>
>afaik Bonjour is a proprietary protocol. How can that be a good thing?
>
>>> 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.
>> 
>> 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
>
>
>___
>homenet mailing list
>homenet@ietf.org
>https://www.ietf.org/mailman/listinfo/homenet


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Andrew Sullivan]

On Mon, Sep 10, 2012 at 01:58:46PM +0100, Brian E Carpenter wrote:
> 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.

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
a...@anvilwalrusden.com
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Brian E Carpenter]

On 10/09/2012 14:09, Ray Bellis wrote:
> On 10 Sep 2012, at 13:58, Brian E Carpenter  
> wrote:
> 
>> Using literal addresses is evil for many reasons - surely we don't need to
>> 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".

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

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


___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Ray Bellis]

On 10 Sep 2012, at 13:58, Brian E Carpenter  wrote:

> Using literal addresses is evil for many reasons - surely we don't need to
> 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".

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

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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Brian E Carpenter]

On 10/09/2012 13:34, Ray Bellis wrote:
> 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?" [*]

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.  Many devices now support 
> Bonjour 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

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

Re: [homenet] Unicast DNS within the Homenet?

[Hans Liu]

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

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.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet

___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet