Re: [dhcwg] DUID+IAID

"A. Gregory Rabil" <greg.rabil@jagornet.com> Thu, 29 March 2012 17:06 UTC

Return-Path: <greg.rabil@jagornet.com>
X-Original-To: dhcwg@ietfa.amsl.com
Delivered-To: dhcwg@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 0523D21E80F6 for <dhcwg@ietfa.amsl.com>; Thu, 29 Mar 2012 10:06:22 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -2.236
X-Spam-Level:
X-Spam-Status: No, score=-2.236 tagged_above=-999 required=5 tests=[AWL=0.140, BAYES_00=-2.599, FM_FORGED_GMAIL=0.622, HTML_MESSAGE=0.001, J_CHICKENPOX_44=0.6, RCVD_IN_DNSWL_LOW=-1]
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 kIoscoYMvafH for <dhcwg@ietfa.amsl.com>; Thu, 29 Mar 2012 10:06:21 -0700 (PDT)
Received: from mail-bk0-f44.google.com (mail-bk0-f44.google.com [209.85.214.44]) by ietfa.amsl.com (Postfix) with ESMTP id 8917921E80F0 for <dhcwg@ietf.org>; Thu, 29 Mar 2012 10:06:20 -0700 (PDT)
Received: by bkuw5 with SMTP id w5so2419924bku.31 for <dhcwg@ietf.org>; Thu, 29 Mar 2012 10:06:19 -0700 (PDT)
X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=google.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :content-type:x-gm-message-state; bh=r/xtTwp01tINv02l2dZsyN8V95kZ2OftLrTqhwM4jSM=; b=lSKNk1dpEQPlYOsG/VNSWI8CF6tmBnAmxXoDM1tZAfvQ1W3y26o2pY94usGU6gkJ7m kkzcoHvB1y0eS9Bb5pBGFL2Fgu4unzS9ddDVKnnF63XL+jpaSCxbH9gi/I82WRAHDTcL 0RP2+mqnRQfQTXlKrml65qB7oCSenmIQXclmm4luVeWm0Qzkj3tsanY4FxR5UTx7ay1/ FopdjDwnjk+2QR15GRG7Jq0NffVBCM599ubTk9KAgd+r8nwde88gZVBVoyuoolPAcfU8 XPtZ0O3UMr9Kuch41cLRHMaRY1bsheDhWm+rESFkUnZbH++veQWC0SNljJ5Exi/ref4a uhqQ==
MIME-Version: 1.0
Received: by 10.204.154.202 with SMTP id p10mr13741605bkw.79.1333040779327; Thu, 29 Mar 2012 10:06:19 -0700 (PDT)
Received: by 10.204.98.198 with HTTP; Thu, 29 Mar 2012 10:06:19 -0700 (PDT)
In-Reply-To: <8D23D4052ABE7A4490E77B1A012B6307472D4438@mbx-01.win.nominum.com>
References: <CAAed6vtfuig6Y1Zqqxd=rQc7MarO7vfkYVDG0HbzeaQrx7GcYw@mail.gmail.com> <8D23D4052ABE7A4490E77B1A012B6307472D4438@mbx-01.win.nominum.com>
Date: Thu, 29 Mar 2012 13:06:19 -0400
Message-ID: <CAAed6vsga7nimW-uA00nStj-sEJ2g9kUbT1=eR1qgxBesczOow@mail.gmail.com>
From: "A. Gregory Rabil" <greg.rabil@jagornet.com>
To: "dhcwg@ietf.org" <dhcwg@ietf.org>
Content-Type: multipart/alternative; boundary="0015175d07bc1f7b9f04bc64bea2"
X-Gm-Message-State: ALoCoQnMA8F0ghmCaYB9GMUTj0B/Q/Uxg9S53DEcc3pxVd0QJoE0ypMKi+tDSqrofsE8qyURxcF9
Subject: Re: [dhcwg] DUID+IAID
X-BeenThere: dhcwg@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: <dhcwg.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/dhcwg>
List-Post: <mailto:dhcwg@ietf.org>
List-Help: <mailto:dhcwg-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/dhcwg>, <mailto:dhcwg-request@ietf.org?subject=subscribe>
X-List-Received-Date: Thu, 29 Mar 2012 17:06:22 -0000

Thanks Ted.

> The intent was that there might well be more than one IAID per interface.

> In practice, I would expect an IA_NA and an IA_TA to use different IAIDs,
for instance.   Similarly for IA_PD.

RFC 3315 states this:

   The IAID number space for the IA_TA option IAID number space is
   separate from the IA_NA option IAID number space.

Based on that statement, I was thinking that a typical implementation might
use the index of an interface as the IAID.  For example, eth0=IAID1.  Then,
if an IA_NA, IA_TA, or IA_PD sent on eth0, would all use IAID=1, and are
distinguished by IA_TYPE as described in the text above.  However, that
obviously would not work if there are more than one IA of the same type on
that interface, as you described:

> It was also intended that the client could ask for more than one set of
IA_NA addresses per interface if it wanted to present more than one
identity to the network.

Yes, and I believe this is further clarified in RFC 3315 with this text:

   A client must associate at least one distinct IA with each of its
   network interfaces for which it is to request the assignment of IPv6
   addresses from a DHCP server.  The client uses the IAs assigned to an
   interface to obtain configuration information from a server for that
   interface.  Each IA must be associated with exactly one interface.


So, each IA is associated with exactly one interface, but not necessarily
the other way around.

> Even if what I'd said weren't an oversimplification, it wouldn't work to
use the MAC address as the IAID, because it's unnecessarily big.   I expect
it to be rare that a single DHCP request will require 2^48 IAs.

Yes, from a implementation standpoint, there is obviously no need for the
whole MAC address to uniquely identify the request.  My point was simply
that since the IAID, at least in some cases (the oversimplified one), may
actually map to an interface, then it would be more useful to know which
interface it maps to.

With that said, I have some questions regarding the
proposed draft-halwasia-dhc-dhcpv6-hardware-addr-opt-01.

RFC 3315 mentions this:

   When a client sends a DHCP message to the
   All_DHCP_Relay_Agents_and_Servers address, it SHOULD send the message
   through the interface for which configuration information is being
   requested.  However, the client MAY send the message through another
   interface attached to the same link

So, would the hardware-addr-option (or link-layer option) identify the MAC
of the interface on which the request was sent, or the MAC of the interface
"for which configuration information is being requested"?

Also, I recall a thread on the mailing list that discussed CPE routers
which may request an address for the WAN-side interface via an IA_NA option
along with an IA_PD request for the LAN-side interface.  I believe the
discussion was focused on the renew behavior.  However, IIRC, some
implementations may send the IA_NA and IA_PD in the same or separate
requests.  Regardless of one or two requests, the packets would
(presumably) be sent over the WAN-side interface.  In the situation where
the client sends the IA_NA and IA_PD in the same request packet, the
proposed link-layer address option would be the MAC of which interface -
WAN or LAN?  In the case of separate requests, would you then expect two
different MACs?  I think were I'm heading with this is that perhaps the
link-layer option needs to be "inside" the IA option, not at the outermost
message level of the packet.

Greg

On Thu, Mar 29, 2012 at 10:41 AM, Ted Lemon <Ted.Lemon@nominum.com> wrote:

> > Ted (don't mean to call you out here, but it is prevalent to my
> question) wrote this on the ISC DHCP list:
> >>DUID+IAID uniquely identifies the interface; DUID uniquely identifies
> the host.
> > My question is can this be guaranteed?
>
> No, I was oversimplifying.   The intent was that there might well be more
> than one IAID per interface.   In practice, I would expect an IA_NA and an
> IA_TA to use different IAIDs, for instance.   Similarly for IA_PD.   It was
> also intended that the client could ask for more than one set of IA_NA
> addresses per interface if it wanted to present more than one identity to
> the network.
>
> Even if what I'd said weren't an oversimplification, it wouldn't work to
> use the MAC address as the IAID, because it's unnecessarily big.   I expect
> it to be rare that a single DHCP request will require 2^48 IAs.
>