[openib-general] Re: IB Address Translation service

[Hal Rosenstock]

On Wed, 2005-04-06 at 03:19, Michael S. Tsirkin wrote:
> > So I don't think that the above 2 cases require an invariant QPN.
> > 
> > 3. The third case is multihomed interfaces on the same IPoIB subnet. I
> > don't think this is currently supported by IPoIB (but may someday). That
> > would either not be supported by RARP or some way to have invariant QPNs
> > would be needed. I'm not sure how important this case is.
> > 
> > Is the above correct ? Are there other cases ? 
> > 
> > -- Hal
> > 
> 
> Some DHCP servers (dhcpd) let you configure a fixed IP per hardware address.
> It seems to me that making this work requires an invariant QP, right?

I believe that DHCP servers require work in order to do this for IPoIB
as they do not understand an IPoIB hardware address. So if they do
support client identifier mapping to IP address, then I think the answer
is maybe (rather than a definitive yes). The reason I say this is that
the DHCP draft appears to allow any unique client identifier per IP
subnet to be used. In that case, as long there is a scheme to make each
identifier unique per IP subnet, DHCP is fine. 

    The "client-identifier" option includes a type and identifier pair.
    The identifier included in the "client-identifier" option may
    consist of a hardware address or any other unique value such as the
    DNS name of the client. When a hardware address is used, the type
    field should be one of the ARP hardware types listed in [ARPPARAM].

The most common (simple to implement) client identifier from the the
DHCP client perspective is the IPoIB hardware address.

http://www.ietf.org/internet-drafts/draft-ietf-dhc-3315id-for-v4-04.txt
states:

Client identities are ephemeral

   RFC2132 recommends that client identifiers be generated by using
   the permanent link-layer address of the network interface that the
   client is trying to configure. 

Requirements

   In order to address the problems stated in section 2, DHCPv4 client
   identifiers must have the following characteristics:

   - They must be persistent, in the sense that a particular host's
     client identifier must not change simply because a piece of
     network hardware is added or removed.

...

   - DHCPv4 client identifiers used by dual-stack hosts that also use
     DHCPv6 must use the same host identification string for both
     DHCPv4 and DHCPv6 - for example, a DHCPv4 server that uses the
     client's identity to update the DNS on behalf of a DHCPv4 client
     must register the same client identity in the DNS that would be
     registered by the DHCPv6 server on behalf of the DHCPv6 client
     running on that host, and vice versa.

   In order to satisfy all but the last of these requirements, we need
   to construct a DHCPv4 client identifier out of two parts.  One part
   must be unique to the host on which the client is running.  The
   other must be unique to the network identity being presented.  The
   DHCP Unique Identifier (DUID) and Identity Association Identifier
   (IAID) specified in RFC3315 satisfy these requirements. 

DHCPv4 Client behavior

   DHCPv4 clients conforming to this specification MUST use stable
   DHCPv4 node identifiers in the dhcp-client-identifier option.
   DHCPv4 clients MUST NOT use client identifiers based solely on
   layer two addresses that are hard-wired to the layer two device
   (e.g., the ethernet MAC address) as suggested in RFC2131, except as
   allowed in section 9.2 of RFC3315.  DHCPv4 clients MUST send a
   'client identifier' option containing an Identity Association
   Unique Identifier, as defined in section 10 of RFC3315, and a DHCP
   Unique Identifier, as defined in section 9 of RFC3315.  These
   together constitute an RFC3315-style binding identifier.

   The general format of the DHCPv4 'client identifier' option is
   defined in section 9.14 of RFC2132.

   To send an RFC3315-style binding identifiier in a DHCPv4 'client
   identifier' option, the type of the 'client identifier' option is
   set to 255.  The type field is immediately followed by the IAID,
   which is an opaque 32-bit quantity.  The IAID is immediately
   followed by the DUID, which consumes the remaining contents of the
   'client identifier' option.  The format of the 'client identifier'
   option is as follows:

      Code  Len  Type  IAID                DUID
      +----+----+-----+----+----+----+----+----+----+---
      | 61 | n  | 255 | i1 | i2 | i3 | i4 | d1 | d2 |...
      +----+----+-----+----+----+----+----+----+----+---

   Any DHCPv4 or DHCPv6 client that conforms to this specification
   SHOULD provide a means by which an operator can learn what DUID the
   client has chosen.  Such clients SHOULD also provide a means by
   which the operator can configure the DUID.  A device that is
   normally configured with both a DHCPv4 and DHCPv6 client SHOULD
   automatically use the same DUID for DHCPv4 and DHCPv6 without any
   operator intervention.

   DHCPv4 clients that support more than one network interface SHOULD
   use the same DUID on every interface.  DHCPv4 clients that support
   more than one network interface SHOULD use a different IAID on
   each interface.

>From RFC 3315, there are multiple DUID types: DUID-LLT (link link address
plus time), DUIT_EN (assigned by vendor based on enterprise number), DUID-LL
(based on link layer address), 

Identity Association

   An "identity-association" (IA) is a construct through which a server
   and a client can identify, group, and manage a set of related IPv6
   addresses.  Each IA consists of an IAID and associated configuration
   information.

   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.

   The IAID uniquely identifies the IA and must be chosen to be unique
   among the IAIDs on the client.  The IAID is chosen by the client.
   For any given use of an IA by the client, the IAID for that IA MUST
   be consistent across restarts of the DHCP client.  The client may
   maintain consistency either by storing the IAID in non-volatile
   storage or by using an algorithm that will consistently produce the
   same IAID as long as the configuration of the client has not changed.
   There may be no way for a client to maintain consistency of the IAIDs
   if it does not have non-volatile storage and the client's hardware
   configuration changes.

Using a scheme along these lines, precludes the requirement for a nonvolatile
QPN for DHCP.

-- Hal