Subject: RE: [dhcwg] [Question] Question about length of link-layer address inDUID

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Wed, 26 Oct 2005 08:30:20 -0400

> Is my understanding correct or not?

Yes, it is correct.

- Bernie 

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> On Behalf Of Hideshi Enokihara
> Sent: Wednesday, October 26, 2005 3:37 AM
> To: [email-masked]
> Subject: [dhcwg] [Question] Question about length of 
> link-layer address inDUID
> 
> Hi all,
> 
> I have a question about DUID-LLT and DUID-LL.
> 
> The format of DUID-LLT and DUID-LL is as follows. 
> 
> DUID-LLT
> 
>      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
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |               1               |    hardware type (16 bits)    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |                        time (32 bits)                         |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     .                                                               .
>     .             link-layer address (variable length)              .
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> DUID-LL
> 
>      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
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     |               3               |    hardware type (16 bits)    |
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>     .                                                               .
>     .             link-layer address (variable length)              .
>     .                                                               .
>     +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> And RFC3315 says,
> 
>                         The hardware type MUST be a valid 
> hardware type
>    assigned by the IANA as described in RFC 826 [14].  Both 
> the time and
>    the hardware type are stored in network byte order.  The link-layer
>    address is stored in canonical form, as described in RFC 2464 [2].
> 
> 
> In both DUID, I think that length of link-layer address field 
> changes depending
> on the hardware type.
> If hardware type is Ethernet(1), length of link-layer address 
> field should be
> 48 bits(link-layer address/MAC address), I think.
> 
> So, if DHCPv6 client that uses Ethernet  sends Solicit message, 
> length of link-layer address field in this message should be 48 bits.
> 
> Is my understanding correct or not?
> 
> Best Regards,
> -- 
> *************************************
> Hideshi Enokihara
> IPv6 Business
> Network & Software Development Dept.
> Yokogawa Electric Corporation
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/dhcwg
> 

_______________________________________________
dhcwg mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/dhcwg

---

From: Hideshi Enokihara <[email-masked]>
Date: Fri, 28 Oct 2005 20:14:56 +0900

Hi all, 

Thank you for your quick response.
Now I'm clear.

So, I have one more question regarding DUID.

RFC3315 says,
-----------------------------------------------------------
17.2.2. Creation and Transmission of Advertise Messages

   The server sets the "msg-type" field to ADVERTISE and copies the
   contents of the transaction-id field from the Solicit message
   received from the client to the Advertise message.  The server
   includes its server identifier in a Server Identifier option and
   copies the Client Identifier from the Solicit message into the
   Advertise message.
-----------------------------------------------------------
I want to forcs on follwing sentence,
"The server includes its server identifier in a Server Identifier
option and copies the Client Identifier from the Solicit message
into the Advertise message."

This sentence means that DHCPv6 Server JUST copies the Client ID 
form Solicit message without checking whether Client ID is valid or not, right?

I have seen the DHCP client that doesn't use Mac address(48bit) as link-layer address field.
(That DHCP client had used DUID-LL/DUID-TTL with hardware type=1). 
That DHCP client had used link-local address or longer than 48bit number as link-layer address field.

Because the DHCP server just copies DUID as described in the above-mentioned, 
it seems no problem in interoperability that the client behave like this, seemingly.

However, I think that there is a possibility that this causes the problem because DUID that the client used here is not globally unique. 

How do you think?
Are there a lot of DHCPv6 clients of such behavior?

Best Regards,

On Wed, 26 Oct 2005 08:30:20 -0400

---

From: Ted Lemon <[email-masked]>
Date: Fri, 28 Oct 2005 09:11:31 -0700

On Friday 28 October 2005 04:14, Hideshi Enokihara wrote:
> However, I think that there is a possibility that this causes the problem
> because DUID that the client used here is not globally unique.

This is a problem with the client, which the server can't really solve.   So 
yes, the server just copies the DUID without trying to ensure that it 
conforms to any standards other than that the length field is okay.   For 
example, it's perfectly permissible to write a new RFC describing a new DUID 
format and implement this in a client, and then have that client communicate 
with a server that doesn't understand the new format; they should 
interoperate correctly.

The reason for describing the format of the DUID in RFC3315 is to explain to 
client implementors how to generate unique identifiers - it's not so a server 
implementation can somehow validate the contents of a DUID.   If the DUID is 
not globally unique, you may run into problems; this is why it's good for 
client vendors to actually follow the instructions in the RFC.   :'}