RE: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments

"Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se> Sun, 20 January 2002 18:11 UTC

Received: from optimus.ietf.org (ietf.org [132.151.1.19] (may be forged)) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14415 for <dhcwg-archive@odin.ietf.org>; Sun, 20 Jan 2002 13:11:40 -0500 (EST)
Received: (from daemon@localhost) by optimus.ietf.org (8.9.1a/8.9.1) id NAA23190 for dhcwg-archive@odin.ietf.org; Sun, 20 Jan 2002 13:11:43 -0500 (EST)
Received: from optimus.ietf.org (localhost [127.0.0.1]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA23056; Sun, 20 Jan 2002 13:03:12 -0500 (EST)
Received: from ietf.org (odin [132.151.1.176]) by optimus.ietf.org (8.9.1a/8.9.1) with ESMTP id NAA22985 for <dhcwg@optimus.ietf.org>; Sun, 20 Jan 2002 13:03:09 -0500 (EST)
Received: from imr1.ericy.com (imr1.ericy.com [208.237.135.240]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id NAA14324 for <dhcwg@ietf.org>; Sun, 20 Jan 2002 13:03:05 -0500 (EST)
Received: from mr6.exu.ericsson.se (mr6u3.ericy.com [208.237.135.123]) by imr1.ericy.com (8.11.3/8.11.3) with ESMTP id g0KI37h28717 for <dhcwg@ietf.org>; Sun, 20 Jan 2002 12:03:07 -0600 (CST)
Received: from eamrcnt749 (eamrcnt749.exu.ericsson.se [138.85.133.47]) by mr6.exu.ericsson.se (8.11.3/8.11.3) with SMTP id g0KI37f25773 for <dhcwg@ietf.org>; Sun, 20 Jan 2002 12:03:07 -0600 (CST)
Received: FROM eamrcnt761.exu.ericsson.se BY eamrcnt749 ; Sun Jan 20 12:03:06 2002 -0600
Received: by eamrcnt761.exu.ericsson.se with Internet Mail Service (5.5.2653.19) id <ZP0Q4PVA>; Sun, 20 Jan 2002 12:03:06 -0600
Message-ID: <66F66129A77AD411B76200508B65AC69B4CDC7@EAMBUNT705>
From: "Bernie Volz (EUD)" <Bernie.Volz@am1.ericsson.se>
To: "'Jim Bound'" <seamus@bit-net.com>, Michael Johnston <frenchy@quiet-like-a-panther.org>
Cc: dhcwg <dhcwg@ietf.org>
Subject: RE: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments
Date: Sun, 20 Jan 2002 12:03:03 -0600
MIME-Version: 1.0
X-Mailer: Internet Mail Service (5.5.2653.19)
Content-Type: multipart/alternative; boundary="----_=_NextPart_001_01C1A1DC.B4A4F0B0"
Sender: dhcwg-admin@ietf.org
Errors-To: dhcwg-admin@ietf.org
X-Mailman-Version: 1.0
Precedence: bulk
List-Id: <dhcwg.ietf.org>
X-BeenThere: dhcwg@ietf.org

What about considering a variable length field for this type and adding a 16-bit length to allow the length to be specified? That way, a vendor can use what they like. The server treats it as opaque anyway.

So, in 11.3 we could change it to be:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |       VUID length (in bits)   |     VUID (variable length)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                    VUID (variable length)                     |
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .                  domain name (variable length)                .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

VUID length is the number of bits of the VUID.

VUID is the VUID (of (VUID length + 7)/8 bytes).

- Bernie

-----Original Message-----
From: Jim Bound [mailto:seamus@bit-net.com]
Sent: Sunday, January 20, 2002 12:52 PM
To: Michael Johnston
Cc: Bernie Volz (EUD); dhcwg
Subject: Re: [dhcwg] Re: dhcpv6-22 DUID/VUID questions/comments


Infiniband spec uses 128 bit global UIDs too.  I think it makes sense to
have a 128bit option but keep the 64bit too.   If we can just add it as
another option which I think we can.  But we don't want to hold up the
spec either.


/jim


On Sun, 20 Jan 2002, Michael Johnston wrote:

> Bernie,
> 
> Intel-ish systems are what I use the most, so my information is skewed in 
> that direction. 
> 
> The UUIDs being used today are derived from the algorithm in this document:
> http://www.opengroup.org/dce/info/draft-leach-uuids-guids-01.txt 
> 
> Mechanisms for retrieving (and in many cases storing) the platform UUID from 
> (to) non-volatile storage are included in (or with) most x86PC compatible 
> laptop and desktop systems and all Intel Itanium workstations and servers. 
> 
> In order to get Microsoft WHQL or Intel WfM certification all systems with 
> network boot support must contain or generate a valid platform UUID. 
> 
> EFI (Extensible Firmware Interface) also requires a platform UUID. 
> 
> 
> %%michael 
> 
> 
> Bernie Volz (EUD) writes: 
> 
> > Hi: 
> > 
> > If there is good evidence that a 128-bit identifier makes much more sense than using the 64-bit identifier currently defined for type 2 (section 11.3), perhaps we should just use the 128-bits (a vendor that only has 64-bit identifier, could simply use 0's in the rest of the bits). 
> > 
> > Do you or does anyone else have some good information about the what new systems are using for UUIDs? 
> > 
> > - Bernie Volz 
> > 
> > -----Original Message-----
> > From: Michael Johnston [mailto:frenchy@quiet-like-a-panther.org]
> > Sent: Saturday, January 19, 2002 3:00 PM
> > To: dhcwg
> > Subject: [dhcwg] dhcpv6-22 DUID/VUID questions/comments 
> > 
> > 
> > Gentles, 
> > 
> > For the DUID contents definition (Section 11):  
> > 
> > Would you be adverse to expanding the size of the VUID to 128 bits or 
> > creating an additional type (4) for a 128 bit UUID?  
> > 
> > Reasoning:  
> > 
> > According to the dhcpv6-22 draft, "... the DUID used by a client SHOULD NOT 
> > change over time...".  From what I have seen, most new laptops, desktops & 
> > workstations (especially those that come with network installed) already 
> > contain, or have space reserved for, a 128 bit UUID that is intended to be 
> > used to manage/track the system identity.  Why have a vendor or IT assign 
> > yet another ID number to the system.  
> > 
> > Using the link-layer address is also not a unique solution.  Consider the 
> > two cases of (1) laptops connecting to docking stations that contain network 
> > adapters and (2) replacing defective or upgrading to new network adapters.  
> > 
> > 
> > %%michael  
> > 
> > _______________________________________________
> > dhcwg mailing list
> > dhcwg@ietf.org
> > https://www1.ietf.org/mailman/listinfo/dhcwg
>  
> 
> _______________________________________________
> dhcwg mailing list
> dhcwg@ietf.org
> https://www1.ietf.org/mailman/listinfo/dhcwg
>