Subject: [Ipoverib] BOOTP/DHCP chaddr field

From: "Larsen, Roy K" <[email-masked]>
Date: Mon, 11 Mar 2002 13:45:15 -0800

Some OS network stacks use fixed-length arrays to store hardware address
(arrrrg).  Increasing the size of the array is not always possible due to
backward binary compatibility.  So I've been looking at what an
implementation might need to do to re-write frames to tokenize the hardware
address as it travels in and out of a network stack.  At first, I thought
this would be a personal problem of the implementation but then I realized
that some IP protocol frames contain hardware addresses that have their own
fixed length address constraints.  In particular, BOOTP and DHCP which have
a maximum of 16 bytes for hardware address (chaddr).

How should IPoIB deal with chaddr?  We can't use the 20 byte IPoIB
"hardware" address.  Do we need a common mapping function?  If we have a
mapping function, should/must it be applied consistently to ARP/ND?

Does anyone know of others?  Thoughts?

Roy

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

---

From: Vivek Kashyap <[email-masked]>
Date: Mon, 11 Mar 2002 18:55:05 -0800 (PST)

> Does anyone know of others?  Thoughts?
Roy,

        The internal size issue will have to be resolved by the
        individual implementations in their own way.

	Some thoughts on DHCP over IB:

        We could always have the DHCP server broadcast a reply always
        - use the GID from the link-layer address in chaddr to occupy
        all 16 bytes. The client receives the broadcast reply and
        picks the one containing its GID. The broadcast option is
        frowned on generally.

        A better alternative is along the following lines :

-----------------------------------------------------------------------

                           DHCP for InfiniBand networks

1. Issues related to IPoIB link addresses

        In Etherenet/IEEE802 The DHCP server can use the 'chaddr'
        field to reply directly to the requester. This is not the case
        with IPoIB. There are a few reasons for this:

	(i) The IPoIB link-layer address is 20 bytes long. 
	
	The chaddr field is 16-bytes in length

	(ii) The QPN component of the link address may change per boot

        This value cannot be included in the hardware unique channel
        address. The client cannot reply to ARP/ND to resolve the QPN
        since it doesn't know its IP address yet.

2. Discovery of DHCP server

        The DHCP server is discovered when a reply to DHCPDISCOVER
        message is received. The DHCPDISCOVER message is broadcast on
        the IP subnet. The same needs to happen in an IPoIB network.

        IPoIB_MCAST describes the broadcast MGID. This MGID is derived
        by including the P_Key of the subnet. Thus the P_Key must be
        known to the client before it can broadcast. The P_Key is a
        configuration parameter.

3. Usage of DHCP message fields

        Following rules should be used when a DHCP client is run over
        an IPoIB network:

	'htype' (hardware address type) MUST be 32 

	'hlen' (hardware address length) MUST be 16

****	OR, we could just zero this out and only use the client identifier.

        The 'chaddr' (client hardware address) field is set to the GID
        associated with the IP interface. This GID is the same as the
        one that is used in the link-layer address.

        'client identifier' option MUST be used in DHCP messages from
        the client to the server due to the chaddr not being
        sufficient for a reply back to the client. 'client identifier'
        option will consist of the link-layer address as defined in
        IPoIB_ENCAP. 

    Code  Len   Type  Client-Identifier
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+
   |  61 |  20 | 32  |        link-layer address (GID + QPN)         |
   +-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+-----+

        Note: the client-identifier can include FQDN as the identifier
        but a new option (81) has been proposed for that purpose. If
        FQDN is used with this option (61) then the broadcast bit must
        be set to cause the server to broadcast.

Vivek
-- 
Vivek Kashyap
Linux Technology Center, IBM
[email-masked] 
[email-masked] 
503 578 3422 (o)

---

From: [email-masked]
Date: Tue, 12 Mar 2002 15:20:47 +0900

Roy, Vivek,

>From: Vivek Kashyap <[email-masked]>
>Subject: Re: [Ipoverib] BOOTP/DHCP chaddr field
>Date: Mon, 11 Mar 2002 18:55:05 -0800 (PST)
>> 

Right.
ARP(rfc 826) and RARP(rfc 903) can handle any bytes upto 255 bytes, but
DHCP(rfc 2131) and BOOTP(rfc 951) can not handle longer link-layer address
than 16 bytes.

>> "hardware" address.
>>  Do we need a common mapping function?  If we have a

That's good if multiple interfaces are not defined per HCA port.

>        A better alternative is along the following lines :

Yes. MGID's P_key is also a good (i.e. non-transient) identifier, I also think.
It can be an additional identifier onto port's GID (GID prefix + GUID index 0).

>	'hlen' (hardware address length) MUST be 16

If RFC2131(DHCP) is not extended, that's right,
of course, DHCP implementations must be current RFC2131 compliant
 (i.e. compliant to variable "chaddr length").

>    Code  Len   Type  Client-Identifier

I don't agree with including QPN into DHCP link-layer address.
If such a transient value,like QPN, is included as link-layer address, 
it makes it difficult to set up the DHCP server information.
i.e. administrators have no chance to know clients' QPNs (link-layer addresses)
 generally.

Thanks,
Akihiko

---

From: Vivek Kashyap <[email-masked]>
Date: Wed, 13 Mar 2002 01:07:04 -0800 (PST)

> That's good if multiple interfaces are not defined per HCA port.

        In this such a case the client identifier option must be used
        with a value unique to the interface. A GUID is unique to the port 
        but a per interface GID, or per interface FQDN, or even a
        GID+QPN (if the interface always uses that value) 
        or a unique whatever can be used. Note that the same unique
        identifier across boots can also be derived by including the
        GUID+timestamp of first use+local-unique value. This
        identifier can be written to local permanent storage for
        consistent use across boots/leases.

	The basic issue is : 
		
		(i) a unique identifier

		(ii) the client must receive the reply

                the client can receive the reply as a broadcast and
                then sift through to pick the one that applies to it -
                (say) using its own GID. Otherwise the DHCP server
                must be told the 'MAC'/link-layer address to unicast
                the reply to.

	Therefore simplest solution is:

                'chaddr' is used to include the GID. The Broadcast
                flag is always set.

                or 
		
		a slightly different solution but still using the
                broadcast flag is to use the client-identifier option
                for the unique identifier.

        The alternative is to have the replies unicast back to the
        client. For this the DHCP server needs to know the
        link-address and therefore the QPN.

        In the earlier mail I added this in the client-identifier but
        that will not work - I re-read the RFC and it makes the
        client-identifier an opaque value. The chaddr is the
        hardware/MAC address. So, the addressing information must be
        included in the chaddr field and not in the client identifier
        field. The client identifier field can be the unique value for
        the DHCP database lookup at the server. 

        A solution can be to include the QPN and the lower 64-bits of
        the GID(the GID prefix is known to all) or the LID itself.
        However such a solution can work in a single IB subnet only.
        If the IPoIB subnet spans IB subnets then this information is
        not enough - one needs the GID prefix too.

        So, when IPoIB subnet spans IB subnets the broadcast flag
        needs to be used.  

> It can be an additional identifier onto port's GID (GID prefix + GUID index 0).

Not sure of that. I was saying that the P_Key is already known to the
sender. Hence it need not be included. The receiving DHCP server host
will accept the packet only if it is on the same broadcast MGID or a
relay agent is on the same broadcast MGID. So, in my view P_Key
doesn't enter the picture.

>  (i.e. compliant to variable "chaddr length").

I am not sure what you mean by 'compliant to variable chaddr length'.
DHCPv6 may take larger values but DHCP-2131 keeps it at 16.

Vivek