Subject: RE: [Ipoverib] IPoIB/DHCP

From: "Larsen, Roy K" <[email-masked]>
Date: Mon, 3 Feb 2003 16:05:46 -0800

Yaron,

Are you suggesting putting the value you describe in the chaddr field?  That
won't work.  The DHCP server must be instructed to reply with a broadcast
and since we can't use the chaddr field, we must use the client ID field.
Once we use the client ID field, any unique and persistent value/character
string (like the one you outline below) should work just fine since it is
opaque to the DHCP server.

Roy

-----Original Message-----
From: Yaron Haviv [mailto:[email-masked]]
Sent: Monday, February 03, 2003 3:28 PM
To: [email-masked]; 'Larsen, Roy K'
Cc: [email-masked]; [email-masked]
Subject: RE: [Ipoverib] IPoIB/DHCP

One observation on the DHCP issues,

If we eventually don't use the real IPoIB MAC address (GID+QP) why not to
just settle for
Uniqe Value (4) + GUID (8) = 12 < 16
This way we will have a unique address, which also enable determining the
node (Base GID = Subnet Prefix + GUID)
And avoid all the hassle of dealing with long 20 byte addresses

This way we don't need to change DHCP at all
Also we see many other implementation issues that prevent using the 20 Byte
address without messing with the OS code
In some OS's it is even not practical

Not to mention that some network monitoring and diagnostic tools fail to
work in such an environment (20 bytes)

Yaron

-----Original Message-----
From: [email-masked] [mailto:[email-masked]]On Behalf Of
Kanoj Sarcar
Sent: Monday, February 03, 2003 10:26 PM
To: Larsen, Roy K
Cc: [email-masked]; [email-masked]
Subject: Re: [Ipoverib] IPoIB/DHCP

"Larsen, Roy K" wrote:
>
> Kanoj,
>
> I tend to agree.  The client-id issues was thrashed on the list and it
> basically devolved to what was stated in the last paragraph of 2.1
>
> "This document does not preclude the use of other 'client identifier'
type,
> such as fully qualified domain name(FQDN) or the EUI-64 value associated
> with the interface."
>

Roy,

> However, the QPN+GID *IS* the IPoIB MAC address so it technically fits the

The client identifier format suggested in the document does not use the QPN,
rather a "Unique-value(4 octets)"; thus the 20 bytes does not represent the
MAC address, thus the type should not be 32, but should be 0.

I do agree that if an implementation does use the QPN as the 4 octets, it
should set the type to 32.

I think something like this would be more appropriate:

    Code  Len   Type  Client-Identifier
   +-----+-----+-----+-----+-----+-----+-----+-------------------....----+
   |  61 | 21  |  0  | Unique-value(4 octets) |   GID (16 octets)          |
   +-----+-----+-----+-----+-----+-----+-----+-------------------....----+

"If an implementation uses the QPN of the interface as the 4 octet
Unique-value,
alongwith the 16 octet GID to create a 20 octet client-identifier, then it
should set the Type value to 32 [ARPPARAM]"

Thanks.

Kanoj

> bill.  However, for the reasons you state, we do not plan on using in our
> implementation.
>
> Roy
>
> -----Original Message-----
> From: Kanoj Sarcar [mailto:[email-masked]]
> Sent: Friday, January 31, 2003 9:07 PM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [Ipoverib] IPoIB/DHCP
>
> Hi,
>
> I have an issue with section 2.1 of
> draft-ietf-ipoib-dhcp-over-infiniband-04.txt.
> I think it should be reworded to allow the following two formats for the
> client-id:
>
>      Code  Len   Type  Client-Identifier
>    +-----+-----+-----+-----+-----+-----+-----+-------------------....----+
>    |  61 | 21  |  0  | Unique-value(4 octets) |   GID (16 octets)
|
>    +-----+-----+-----+-----+-----+-----+-----+-------------------....----+
>
>     Code  Len   Type  Client-Identifier
>    +-----+-----+-----+-----+-----+-----+-----+-------------------....----+
>    |  61 | 21  |  32 | QPN  (4 octets) |   GID (16 octets)          |
>    +-----+-----+-----+-----+-----+-----+-----+-------------------....----+
>
> Note that if the 20 byte client identifier does not represent the MAC
> address
> of the interface, the type should be 0. The type can be 32 only if the mac
> address is being used as the identifier.
>
> In fact, I doubt the neccesity of specifying the second format, since it
> represents
> an unstable address (QPN), which is likely to change whenever a port is
> rebooted.
>
> For the rationale, please see section 9.14 of RFC 2132:
> "A hardware type of 0 (zero) should be used when the value field
> contains an identifier other than a hardware address (e.g. a fully
> qualified domain name)."
>
> Thanks.
>
> Kanoj
> _______________________________________________
> IPoverIB mailing list
> [email-masked]
> https://www1.ietf.org/mailman/listinfo/ipoverib
_______________________________________________
IPoverIB mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ipoverib

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