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