[openib-general] Re: IB Address Translation service

[Michael S. Tsirkin]

Quoting r. Hal Rosenstock <halr at voltaire.com>:
> Subject: Re: IB Address Translation service
> 
> 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.

Are we talking about IPoIB hardware address size issues?

> 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.

So a client could, for example, mask the QP number and use the
remaining non-volatile portion as the identifier?

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

Do you know whether dhcp clients / servers support this?
dhcpd man page seems to talk only about hardware address.

-- 
MST - Michael S. Tsirkin