Subject: Re: [homenet] NPTv6-only home networks

From: Teemu Savolainen <[email-masked]>
Date: Sat, 23 Feb 2013 19:56:16 +0200

And this works with hosts that use IPv6 privacy addresses and not have IIDs derived from MAC?

-----Original Message-----
From: "Simon Kelley" <[email-masked]>
Sent: ‎22.‎2.‎2013 17:54
To: "Ted Lemon" <[email-masked]>
Cc: "[email-masked]" <[email-masked]>; "David Lamparter" <[email-masked]>
Subject: Re: [homenet] NPTv6-only home networks

On 22/02/13 14:50, Ted Lemon wrote:
> On Feb 22, 2013, at 8:24 AM, Simon Kelley <[email-masked]> wrote:
>> It works as well for clients which do DHCPv4 and SLAAC. IPv6-only hosts
>> would have to do stateful DHCPv6, but the DHCPv4 and SLAAC model covers
>> an awful lot of currently-deployed clients.
> 
> So dnsmasq is noticing that the IPv4 and IPv6 hosts are the same host using the MAC address or something, and then coordinating the DNS registration?
> 
> 
As the DHCPv4 state machine moves to "lease complete" it spits a (MAC
address, hostname, broadcast domain) tuple over to the IPv6 side.
The broadcast domain plus configuration yields a list of prefixes, and
the MAC address gets turned into a SLAAC host-identifier. The two make a
set of putative addresses. The state machine then sends an ICMP6 echo
request to each putative address and if it responds then that address is
added as an AAAA record with the hostname.

There are some implementation details involving timeouts and retries and
sending speculative router advertisements to ensure that a
new-on-the-network host is ready to reply to the pings.

The practice is that it always works, even a smartphone moving slowly
into a dodgy Wifi network. If the client can get a DHPCv4 lease, the
IPv6 SLAAC address gets a name too.

Simon.

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

---

From: Simon Kelley <[email-masked]>
Date: Sat, 23 Feb 2013 18:02:04 +0000

> And this works with hosts that use IPv6 privacy addresses and not have

If they have only privacy addresses, it doesn't work. If they have both 
a SLAAC address and a privacy address, and use the privacy address when 
initiating connections (for privacy), but accept connections to the 
SLAAC address, then it still works.

Simon.

> ------------------------------------------------------------------------
> From: Simon Kelley <mailto:[email-masked]>
> Sent: ‎22.‎2.‎2013 17:54
> To: Ted Lemon <mailto:[email-masked]>
> Cc: [email-masked] <mailto:[email-masked]>; David Lamparter
> <mailto:[email-masked]>
>  > So dnsmasq is noticing that the IPv4 and IPv6 hosts are the same host
> using the MAC address or something, and then coordinating the DNS
> registration?
>  >
>  >

---

From: Ted Lemon <[email-masked]>
Date: Sat, 23 Feb 2013 13:14:54 -0500

On Feb 23, 2013, at 1:02 PM, Simon Kelley <[email-masked]> wrote:
> If they have only privacy addresses, it doesn't work. If they have both a SLAAC address and a privacy address, and use the privacy address when initiating connections (for privacy), but accept connections to the SLAAC address, then it still works.

I would argue that if they have only privacy addresses, it _does_ work, because privacy addresses ought not to be published in the DNS.

---

From: Teemu Savolainen <[email-masked]>
Date: Sat, 23 Feb 2013 20:39:55 +0200

Good points, those clarify. Might be good idea to write I-D about:)

Thank you.
 On Feb 23, 2013 8:14 PM, "Ted Lemon" <[email-masked]> wrote:

> initiating connections (for privacy), but accept connections to the SLAAC
> address, then it still works.
>
> I would argue that if they have only privacy addresses, it _does_ work,
> because privacy addresses ought not to be published in the DNS.
>
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 23 Feb 2013 13:46:03 -0500

> Good points, those clarify. Might be good idea to write I-D about:)

You offering?   :)

---

From: Teemu Savolainen <[email-masked]>
Date: Sat, 23 Feb 2013 22:12:55 +0200

I'll leave it for those whose idea this was:-)

(And it lacks the IPv6-only aspect)

---

From: Ted Lemon <[email-masked]>
Date: Sat, 23 Feb 2013 18:26:41 -0500

> I'll leave it for those whose idea this was:-)

If you insist.   However, that assumes that they will write a document, which isn't always a safe assumption.

---

From: Dave Taht <[email-masked]>
Date: Sat, 23 Feb 2013 15:38:56 -0800

> which isn't always a safe assumption.

I am a big believer in running code and rough consensus.

We seem to have both at the moment...

As one of the inventors of the dhcpv4 to SLAAC naming technique (with evan
hunt), I'm glad to hear this.

However, someone else had come up with it independently and published it a
few months prior to us, and we'd have to track that person down in order to
write an ID.

Simon Kelly took what we had in cerowrt, and improved it substantially,
however there is still some stuff that is less than desirable, notably, the
DNS TTL is presently set to 0 in the dnsmasq implementation, and I tend to
think it should reflect the available lease time, or some larger number
than 0, in order to do more effective caching.

dnsmasq is now a full fledged replacement for radvd, and as it as insight
into the lease time now, coming up with either a suggested minimum TTL or
one based on the least seems like a good idea. Suggestions?

Secondly, what ietf group would shepard the document?

-- 
Dave Täht

Fixing bufferbloat with cerowrt:
http://www.teklibre.com/cerowrt/subscribe.html

---

From: Dave Taht <[email-masked]>
Date: Sat, 23 Feb 2013 15:41:13 -0800

> one based on the least seems like a good idea. Suggestions?

Grumble. Remind me not to try to write important stuff on my phone.

dnsmasq is now a full fledged replacement for radvd, and as it nas insight
into the lease time now, coming up with either a suggested minimum TTL or
one based on the current value of the lease seems like a good idea.
Suggestions?

-- 
Dave Täht

---

From: Ted Lemon <[email-masked]>
Date: Sat, 23 Feb 2013 19:18:01 -0500

On Feb 23, 2013, at 6:41 PM, Dave Taht <[email-masked]> wrote:
> dnsmasq is now a full fledged replacement for radvd, and as it nas insight into the lease time now, coming up with either a suggested minimum TTL or one based on the current value of the lease seems like a good idea. Suggestions?

The lease time is something configured on the gateway.   It's not really related to the TTL, since the expectation is that the device will renew over and over, even if the lease time is short.   And if the device moves to a different location, it probably won't be able to register the same name, so a stale record won't be a major problem.

Personally I'd use a value of 3600; it doesn't give you a ton of caching, but that doesn't matter for a name that is almost never looked up by anyone.   Caching google.com is really important.   Caching washing-machine.brattlegrad.fugue.com, not so much.

As for the document, if it's worth documenting, it's worth someone writing the document.   If you want the person who first suggested it to you to get credit, mention them in the acknowledges and wax poetic about the greatness of their contribution.   If you want to make sure that the work gets documented, write the document if they won't.

---

From: Simon Kelley <[email-masked]>
Date: Sun, 24 Feb 2013 09:48:24 +0000

On 23/02/13 23:38, Dave Taht wrote:

> however there is still some stuff that is less than desirable, notably,
> the DNS TTL is presently set to 0 in the dnsmasq implementation

This isn't quite accurate. Replies with cached data from forwarded 
queries of course get the TTL from upstream, reduced by the time the 
data has been cached. Replies with 0 TTL are answers to queries from 
internal hosts (ie from hosts on the local net) where the data in also 
local (ie stuff from /etc/hosts, other configuration or DHCP leases). 
The rationale is that re-doing the query is very cheap for these hosts, 
and there is no other good value for TTL.

DHCP lease time is not a good value. My laptop can have a DHCP lease 
with days left to run on my wireless subnet: if I plug in the wired 
network port, the name will be transfered to the new lease on the wired 
subnet, and I don't want to wait for days for all the hosts on the net 
to catch up with the new address.

For queries _not_ from the internal hosts (i.e. the new auth 
functionality) the TTL in the replies currently defaults to 600, and is 
configurable. These replies are only ever local data, dnsmasq will never 
forward-upstream queries from the wider net, to avoid DNS amplification 
attacks.

Simon.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2013 03:14:51 -0300

Hi, Simon,

> SLAAC address, then it still works.

But.. if you're learning the IPv6 addresses based on the assumption that
they are the traditional SLAAC addresses (that embed IEEE identifiers),
you'd be missing IPv6 addresses of Windows nodes (which do not generate
IIDs according to traditional SLAAC), any nodes using CGAs, etc.

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Simon Kelley <[email-masked]>
Date: Tue, 26 Feb 2013 07:43:30 +0000

> IIDs according to traditional SLAAC), any nodes using CGAs, etc.

On my network, the Windows nodes use stateful DHCPv6. I don't see this 
technique as a universal panacea or something to necessarily rely on 
going forward, but it does make naming work 
_for_existing_deployed_systems. It works, for instance, with hundreds of 
millions of existing Android phones and tablets, 99.99% of which will 
never be upgraded.

Simon.

---

From: Fernando Gont <[email-masked]>
Date: Tue, 26 Feb 2013 05:03:12 -0300

> millions of existing Android phones and tablets, 99.99% of which will

Agreed. I was mostly thinking about the IPv6-only case, and also about a
more general technique that would still work with SLAAC when hte IIDs do
not include MAC addresses.

Thanks,
-- 
Fernando Gont
SI6 Networks
e-mail: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492