Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem

[神明達哉 <[e-mail]>]

At Tue, 29 Oct 2013 14:13:39 +0900,
Lorenzo Colitti <[e-mail]> wrote:

> > 7) Programming: UDP vs. ICMP
> >
> > For a random programmer today, coding a server to receive the data on a
> > UDP socket is a more familiar exercise than working with ICMP. Disclaimer:
> > the value of "random" was chosen to be "me" for arbitrary reasons. This
> > point is more of a rathole and a personal preference, probably. I think I
> > remember Dave Thaler saying one of the mechanisms in Windows was way easier
> > to extend than the other, but I do not remember which.
>
> ICMP is harder than UDP to implement; it often requires raw sockets or
> kernel collaboration (e.g., on Linux RDNSS information can be read using
> netlink. UDP is much simpler). On the other hand, I think stateful DHCPv6
> is a more complicated protocol to implement than RAs, with more message
> types and so on.

I don't know why Linux uses a non portable API, but I believe
writing programs handling RA options like RDNSS is no harder than
writing DHCPv6 client in terms of socket API.  As long as the system
supports RFC3542 you should be able to write a portable RA "client"
pretty easily (meaning as easy/hard as writing some UDP client
program).  For example, FreeBSD's rtsold supports RDNSS and (AFAIK)
only relies on the RFC3542 APIs.  Also, since DHCP is trickier than
other UDP applications in some points (it's more sensitive to which
interface to use, and in some cases you need to make sure the source
address is link-local, etc), it's quite likely that you'll need
something like unusual APIs like RFC3542 or some non-portable system
dependent interface to write a standard-compliant DHCP(v6) client.

So, overall, I'd say the programming difficulty regarding UDP (DHCP)
vs ICMP (RS/RA) is marginal.

As I'm writing a response, I'll also make a comment on another, more
minor point:

At Tue, 29 Oct 2013 14:13:39 +0900,
Lorenzo Colitti <[e-mail]> wrote:

> But you can't authenticate in DHCPv6 either, right? Whether you get an
> unsolicited "here's some config parameters" RA or a unicast "thank you for
> your request, here's some config parameters" DHCPv6 reply, the problem is
> the same: is the source trustworthy? AIUI we don't have any solution for
> this except DHCPv6 guard and RA guard, which are effectively the same
> solution. I mean - we do have SEND and DHCPv6 authentication, but does
> anyone implement those?

If you mean the Delayed Authentication Protocol by DHCPv6
authentication, the WIDE DHCPv6 supports it:
http://sourceforge.net/projects/wide-dhcpv6/
although I myself have only used it in testing.  I heard some other
vendors implemented it, too.

(And, for that matter, it also supports the Information Refresh Time
option (RFC4242)).

--
jinmei