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
_______________________________________________
openib-general mailing list
openib-general@openib.org
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
