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

神明達哉 <jinmei@wide.ad.jp> Tue, 29 October 2013 19:59 UTC

Return-Path: <jinmei.tatuya@gmail.com>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id B6D7D11E827E for <v6ops@ietfa.amsl.com>; Tue, 29 Oct 2013 12:59:56 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 1.222
X-Spam-Level: *
X-Spam-Status: No, score=1.222 tagged_above=-999 required=5 tests=[BAYES_00=-2.599, CHARSET_FARAWAY_HEADER=3.2, FM_FORGED_GMAIL=0.622, NO_RELAYS=-0.001]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id NTgVq9hfKpBu for <v6ops@ietfa.amsl.com>; Tue, 29 Oct 2013 12:59:56 -0700 (PDT)
Received: from mail-wg0-x233.google.com (mail-wg0-x233.google.com [IPv6:2a00:1450:400c:c00::233]) by ietfa.amsl.com (Postfix) with ESMTP id F30F111E8255 for <v6ops@ietf.org>; Tue, 29 Oct 2013 12:59:55 -0700 (PDT)
Received: by mail-wg0-f51.google.com with SMTP id l18so367402wgh.30 for <v6ops@ietf.org>; Tue, 29 Oct 2013 12:59:54 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:sender:in-reply-to:references:date:message-id:subject :from:to:cc:content-type; bh=y+vEcsaW1jdrxH3xeZdSCTwFTNdMeaXC9GKQPsHogAY=; b=txhQWvgmh/DM/q1GcRLdL3nJFfUVU9TcZG8MGUo00VasJpFnkqMPJiXqXpTKsrUG/X RCmCoaz8CjkCdFAPrrD8J8t66DEkZbd4wtSe/HK6yYdgzE7puW+HrVB6UIS2LAUYAL1f HT6ydpmVQP349Wa/zQp1eorEkvdLWaAWtIewFkYZzLws0K/hmgZmHUlSZNVgnEVG62cX 72xEZTQ/J5wauRe8CoB+xwzEJwCDMRywwPEwtA1pLhI1AYM4nUmUxq+CNJEtbP4XrIr/ UXygS3sBOzLXz9AVHsDO1qdQuIpF3KV+ZgXufv75cOnze/RyXLfA6+Twuk51EojdGXef qzZw==
MIME-Version: 1.0
X-Received: by 10.180.76.69 with SMTP id i5mr14517766wiw.34.1383076794702; Tue, 29 Oct 2013 12:59:54 -0700 (PDT)
Sender: jinmei.tatuya@gmail.com
Received: by 10.194.120.167 with HTTP; Tue, 29 Oct 2013 12:59:54 -0700 (PDT)
In-Reply-To: <CAKD1Yr3ivNEzMFOCkxe2EcLYr=x2x1ThdB9AqYsyU96ZZ9UGqg@mail.gmail.com>
References: <CE8E8EC3.59F3A%victor@jvknet.com> <06601039-CAFD-49B0-918B-A8ACD51B978D@fugue.com> <alpine.OSX.2.00.1310281905440.11422@ayourtch-mac> <CAKD1Yr3ivNEzMFOCkxe2EcLYr=x2x1ThdB9AqYsyU96ZZ9UGqg@mail.gmail.com>
Date: Tue, 29 Oct 2013 12:59:54 -0700
X-Google-Sender-Auth: x7oJy0PBoh3aS2r-t0g5vW_X4Pk
Message-ID: <CAJE_bqc8Cqj=myrXGpUrCP1q4FSfaKZUbp_zcAorBmPSx1+S9A@mail.gmail.com>
From: =?ISO-2022-JP?B?GyRCP0BMQEMjOkgbKEI=?= <jinmei@wide.ad.jp>
To: Lorenzo Colitti <lorenzo@google.com>
Content-Type: text/plain; charset=ISO-8859-1
Cc: "v6ops@ietf.org" <v6ops@ietf.org>, Ted Lemon <mellon@fugue.com>, "Ole Troan \(otroan\)" <otroan@cisco.com>, Dave Thaler <dthaler@microsoft.com>, "draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org" <draft-liu-bonica-v6ops-dhcpv6-slaac-problem@tools.ietf.org>
Subject: Re: [v6ops] DHCPv6/SLAAC Make Hosts Confusing-//RE: new draft: draft-liu-bonica-v6ops-dhcpv6-slaac-problem
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 29 Oct 2013 19:59:57 -0000

At Tue, 29 Oct 2013 14:13:39 +0900,
Lorenzo Colitti <lorenzo@google.com> 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 <lorenzo@google.com> 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