Quoting r. Hal Rosenstock <[EMAIL PROTECTED]>: > 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 _______________________________________________ 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