Subject: [homenet] RFC: dhcpv4 to slaac DNS naming scheme

From: Dave Taht <[email-masked]>
Date: Fri, 14 Feb 2014 15:12:18 -0800

I had intended to submit this to the homenet wg, but appear to have goofed
in some way in getting it to the right place.

presently at:

http://datatracker.ietf.org/doc/draft-taht-kelley-hunt-dhcpv4-to-slaac-naming/

Abstract

   This memo presents a technique for using the hostname acquired from a
   DHCPv4 client request to publish AAAA records on that domain name for
   public IPv6 addresses acquired by the same dual-stack host using
   SLAAC.

   On dual-stack networks, there is a need to automatically publish
   entries in the DNS for the public IPv6 addresses of an IPv6 host when
   it does not use DHCPv6.  IPv6 hosts can acquire IPv6 addresses using
   SLAAC, but there is no mechanism allowing them to register a name in
   the DNS database other than a DNS update, which would create a very
   difficult key management problem.  By combining the DHCPv4 hostname
   or client FQDN option with information acquired using ICMPv6, a
   lightweight DHCPv4 server on a home gateway or SOHO gateway can
   automatically publish AAAA records for such hosts.

-- 
Dave Täht

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 15 Feb 2014 11:18:55 +0900

>    public IPv6 addresses acquired by the same dual-stack host using

Dave,

Good to see some work being done on this problem. A few comments:

1. Assuming that hosts generate IPv6 interface IDs per RFC 4291 will soon
be mostly obsolete. As you point out, Windows already doesn't do it, and I
believe Mac OS and iOS have recently stopped doing it too. So that's a
large chunk of the client population already. For the rest, see
http://tools.ietf.org/html/draft-gont-6man-deprecate-eui64-based-addresses-00,
which is likely going to be adopted by 6man. It likely won't deprecate
EUI-64-based IPv6 addresses, but it will almost certainly discourage them.
As you also point out, the proposed mechanism also doesn't work for privacy
addresses, which is what virtually all hosts are going to be using for
outgoing connections anyway. So I don't think that the proposed scheme is a
solution to the problem.

2. Since you propose getting this information using MAC addresses, you're
doing layering violations and protocol violations already. So why not go a
step further and look into the neighbour cache? In principle, you could
have the reverse DNS lookup cause a lookup into the IPv6 neighbour cache to
find the address that you would then look up in the DHCP lease database.
That's expensive, but you could cache the result, and you could also snoop
DAD probes to populate the cache when hosts join the network. That would
work in a lot more cases than the proposed scheme.

3. If we're going to do work on this, it would be useful to have a
mechanism that works even without IPv4. The draft says that relying on
dynamic DNS updates "creates a very difficult key management problem", but
I don't understand that statement. Can we not simply use unauthenticated
DNS updates, and agree to accept them only if they come from the local
link? After all, in the proposed scheme the DHCPv4 request that provides
the hostname is also unauthenticated, but the router is perfectly happy to
accept it. What is the additional security difficulty here? Is is something
that could be worked out in a different way? Assuming client support, could
the hostname be provided by other types of packets such as ICMPv6 node
information replies?

Regards,
Lorenzo

---

From: Simon Kelley <[email-masked]>
Date: Sat, 15 Feb 2014 09:23:52 +0000

On 15/02/14 02:18, Lorenzo Colitti wrote:
> On Sat, Feb 15, 2014 at 8:12 AM, Dave Taht <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> 1. Assuming that hosts generate IPv6 interface IDs per RFC 4291 will
> soon be mostly obsolete. As you point out, Windows already doesn't do
> it, and I believe Mac OS and iOS have recently stopped doing it too. So
> that's a large chunk of the client population already. For the rest, see
> http://tools.ietf.org/html/draft-gont-6man-deprecate-eui64-based-addresses-00
> , which is likely going to be adopted by 6man. It likely won't deprecate
> EUI-64-based IPv6 addresses, but it will almost certainly discourage
> them. As you also point out, the proposed mechanism also doesn't work
> for privacy addresses, which is what virtually all hosts are going to be
> using for outgoing connections anyway. So I don't think that the
> proposed scheme is a solution to the problem.

This technique is useful for all the _existing_ systems that only do 
EUI64 SLAAC, I don't think it's something we should do going forward. It 
might be worth pointing out that deprecate-eui64-based-addresses goes 
backwards in this respect, and deprecate-eui64-based-addresses-and 
use-dhcpv6-instead would be better, or define a hostname option in the 
Router Solicit packet.
>
> 2. Since you propose getting this information using MAC addresses,
> you're doing layering violations and protocol violations already. So why
> not go a step further and look into the neighbour cache? In principle,
> you could have the reverse DNS lookup cause a lookup into the IPv6
> neighbour cache to find the address that you would then look up in the
> DHCP lease database. That's expensive, but you could cache the result,
> and you could also snoop DAD probes to populate the cache when hosts
> join the network. That would work in a lot more cases than the proposed
> scheme.
>

Two reasons.

1) Using ICMP6 works even when the client is not a neighbour of the 
server, ie when it's on a remote network segment and DHCPv4 relay is in use.

2) Implementation. There'a a well defined, stable and universal API to 
send and recieve ICMP6 packets. The same code runs everywhere. Snooping 
the ND takes code that's platform specific and rather more complex.

Cheers,

Simon.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 15 Feb 2014 19:35:39 +0900

On Sat, Feb 15, 2014 at 6:23 PM, Simon Kelley <[email-masked]>wrote:

> This technique is useful for all the _existing_ systems that only do EUI64
> SLAAC, I don't think it's something we should do going forward.
>

Which ones are those, though? I mean - we can certainly write this up as
is, but if it doesn't work on Windows, Mac OS, or iOS, then... how much use
will it be in the real world? Given that homenet device implementation
resources are not unlimited, perhaps we should try to define things that
have more impact on devices that people use.

---

From: Simon Kelley <[email-masked]>
Date: Sat, 15 Feb 2014 10:44:55 +0000

On 15/02/14 10:35, Lorenzo Colitti wrote:
> On Sat, Feb 15, 2014 at 6:23 PM, Simon Kelley <[email-masked]
> <mailto:[email-masked]>> wrote:
>
>     EUI64 SLAAC, I don't think it's something we should do going forward.
>
>
> is, but if it doesn't work on Windows, Mac OS, or iOS, then... how much
> use will it be in the real world?

The obvious answer is Android, which is what it was originally 
implemented for. I think the three platforms you mention have have 
DHCPv6 support, Android doesn't, or at least didn't: I'm not sure about 
the latest releases.

---

From: Sander Steffann <[email-masked]>
Date: Sat, 15 Feb 2014 12:19:31 +0100

Op 15 feb. 2014, om 11:35 heeft Lorenzo Colitti <[email-masked]> het volgende geschreven:

> Which ones are those, though? I mean - we can certainly write this up as is, but if it doesn't work on Windows, Mac OS, or iOS, then... how much use will it be in the real world? Given that homenet device implementation resources are not unlimited, perhaps we should try to define things that have more impact on devices that people use.

+1
Sander

---

From: Sander Steffann <[email-masked]>
Date: Sat, 15 Feb 2014 12:44:50 +0100

Hi,

Op 15 feb. 2014, om 11:44 heeft Simon Kelley <[email-masked]> het volgende geschreven:
> The obvious answer is Android, which is what it was originally implemented for. I think the three platforms you mention have have DHCPv6 support, Android doesn't, or at least didn't: I'm not sure about the latest releases.

If Android is the only OS that benefits from this mechanism then I don't think this belongs in Homenet... Or in the IETF. We should develop interoperable solutions here. Sorry if I sound a bit harsh. This might have been an interesting solution many years ago, but not today. I think today this needs to be further integrated with maybe ND / DAD monitoring to make it work with non-EUI64 addresses.

Cheers,
Sander

---

From: Evan Hunt <[email-masked]>
Date: Sat, 15 Feb 2014 16:44:38 +0000

On Sat, Feb 15, 2014 at 07:35:39PM +0900, Lorenzo Colitti wrote:
> is, but if it doesn't work on Windows, Mac OS, or iOS, then...

To be completely honest, this mechanism was invented as a hack to work
around the idiosyncrasies of my personal home network. It was Dave who
recognized its potential applicability in other environments and documented
it (kindly giving me coauthorship credit that I'm not sure I deserve). 
*I* thought we were just duct-taping together a one-off solution to
the sort of problem only IETF people would ever have.

That said, I do have three years of real-world operational experience
with it, and I observe that it *is* working with all current versions
of macos, iOS, android and linux.

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

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 16 Feb 2014 09:11:52 +1300

Hi,

draft-taht-kelley-hunt-dhcpv4-to-slaac-naming-00 says:

>    IPv6 hosts can acquire IPv6 addresses using
>    the DNS database other than a DNS update, which creates a very
>    difficult key management problem. 

Can you explain that? I understood that Secure Dynamic DNS Update
was quite widely deployed. If it can't be readily deployed in homenets,
somebody needs to fix that.

>    The server MUST discard any IPv6 prefixes whose length is not 64,
>    since hosts cannot assign addresses in these prefixes using SLAAC.

SLAAC itself is carefully not limited to /64. IIDs are limited to /64
by RFC 4291 as updated by RFC 7136.

See draft-carpenter-6man-why64 for more discussion of this subtlety.
I hope we'll be discussing this in 6man in London.

>    The server MUST discard link-local prefixes.  It MAY be configured to
>    discard site-local prefixes.  This would be appropriate of the host
>    records were being inserted into the global DNS, but not if they were
>    being inserted into a local DNS view only available within the site.
> 
>    Having determined the set of possible IPv6 prefixes (as above) the
>    implementation then determines a possible interface identifier.  It
>    uses the client's link-layer address contained in the CHADDR field of
>    the DHCPv4 [RFC2131] packet, or encoded in the client-id as in
>    FIREWIRE [RFC3146] and applies the procedure given in [RFC4291] para
>    2.5.1 to calculate the SLAAC interface identifier.

RFC 7136 makes it clear that this is not a reversible transformation
(unless you know with absolute certainty that RFC 4291 Appendix A
has been applied, which is increasingly rare and likely to be
deprecated). So I really don't see how this draft could be
standardised; I could see it being published as Informational
("here's something that works in special circumstances").

    Brian

---

From: Evan Hunt <[email-masked]>
Date: Sat, 15 Feb 2014 20:57:18 +0000

> somebody needs to fix that.

It can be, and is.  However, if the *host* is registering a name in the
DNS, then it must be configured in advance with a suitable key.  If the
*router* manages everything, then it needs to know all the pieces of the
puzzle -- hostname, v4 address(es), v6 address(es) -- and that's not always
straightforward with architectures in which the v4 and v6 address spaces
are managed by different software, possibly running on different servers.

The slaac mechanism allows a dhcpv4 daemon to make an educated guess at a
usable v6 address for a host, confirm it, and act on it, either by sending
a suitable DNS update or (for something like dnsmasq, which acts as both
DHCP and DNS server) updating its own internal state.

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Feb 2014 17:23:32 -0500

It's probably worth pointing out that this is essentially an ops document, not a protocol spec.   From an ops perspective, it's perfectly reasonable.   I offered Dave the same criticism about ND that Lorenzo did when he asked me to look at it, and I still think looking in the neighbor table makes more sense than sending ICMP messages.   But fundamentally I think this is a useful hack, and worth writing an ops document about.   I don't know that homenet needs to be where the doc is published, but that's a separate issue.

---

From: "Townsley.net" <[email-masked]>
Date: Sat, 15 Feb 2014 23:31:51 +0100

I think the subtlety here is whether or not homenet recommends doing this by default in one form or another - as Homenets really don't have the luxury of users deciding to do these types of things or not. In that sense, what may look "operational" in a traditional network with traditional operators, becomes part and parcel of what a "Homenet" is or is not. 

- Mark

(Thumbtyped)

On Feb 15, 2014, at 11:23 PM, Ted Lemon <[email-masked]> wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Sat, 15 Feb 2014 17:46:58 -0500

> I think the subtlety here is whether or not homenet recommends doing this by default in one form or another - as Homenets really don't have the luxury of users deciding to do these types of things…

I think what you're talking about is still an ops doc—it's just a document that describes how operations are done automatically.   Because I really don't think it's a protocol spec, but I agree with you that it still needs to be written and makes sense as output of homenet.

---

From: "Townsley.net" <[email-masked]>
Date: Sun, 16 Feb 2014 08:34:30 +0100

Good we agree on the substance, if not the semantics. On the semantics, I could probably be swayed over a longer conversation.... with beer. 

- Mark

(Thumbtyped)