draft-ietf-dhc-dhcpv6-28.txt

DHCPv6协议在Linux操作系统下的一个客户端实现。

   This method of DUID generation is recommended for all general purpose
   computing devices such as desktop computers and laptop computers, and
   also for devices such as printers, routers, and so on, that contain
   some form of writable non-volatile storage.

   Despite our best efforts, it is possible that this algorithm for
   generating a DUID could result in a client identifier collision.
   A DHCP client that generates a DUID-LLT using this mechanism MUST
   provide an administrative interface that replaces the existing DUID
   with a newly-generated DUID-LLT.


9.3. DUID Assigned by Vendor Based on Enterprise Number [DUID-EN]

   This form of DUID is assigned by the vendor to the device.  It
   consists of the vendor's registered Private Enterprise Number as
   maintained by IANA [10] followed by a unique identifier assigned by
   the vendor.  The following diagram summarizes the structure of a
   DUID-EN:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               2               |       enterprise-number       |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |   enterprise-number (contd)   |                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
   .                           identifier                          .
   .                       (variable length)                       .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The source of the identifier is left up to the vendor defining it,
   but each identifier part of each DUID-EN MUST be unique to the device
   that is using it, and MUST be assigned to the device at the time of



Droms (ed.), et al.            Expires 30 Apr 2003             [Page 15]

Internet Draft              DHCP for IPv6 (-28)               2 Nov 2002


   manufacture and stored in some form of non-volatile storage.  The
   generated DUID SHOULD be recorded in non-erasable storage.  The
   enterprise-number is the vendor's registered Private Enterprise
   Number as maintained by IANA [10].  The enterprise-number is stored
   as an unsigned 32 bit number.

   An example DUID of this type might look like this:

   +---+---+---+---+---+---+---+---+
   | 0 | 2 | 0 | 0 | 0 |  9| 12|192|
   +---+---+---+---+---+---+---+---+
   |132|221| 3 | 0 | 9 | 18|
   +---+---+---+---+---+---+


   This example includes the two-octet type of 2, the Enterprise
   Number (9), followed by eight octets of identifier data
   (0x0CC084D303000912).


9.4. DUID Based on Link-layer Address [DUID-LL]

   This type of DUID consists of two octets containing the DUID type 3,
   a two octet network hardware type code, followed by the link-layer
   address of any one network interface that is permanently connected to
   the client or server device.  For example, a host that has a network
   interface implemented in a chip that is unlikely to be removed and
   used elsewhere could use a DUID-LL. The hardware type MUST be a valid
   hardware type assigned by the IANA as described in RFC826 [18].
   The hardware type is stored in network byte order.  The link-layer
   address is stored in canonical form, as described in RFC2464 [4].
   The following diagram illustrates the format of a DUID-LL:

    0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |               3               |    hardware type (16 bits)    |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   .                                                               .
   .             link-layer address (variable length)              .
   .                                                               .
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+


   The choice of network interface can be completely arbitrary, as
   long as that interface provides a unique link-layer address and is
   permanently attached to the device on which the DUID-LL is being
   generated.  The same DUID-LL SHOULD be used in configuring all
   network interfaces connected to the device, regardless of which
   interface's link-layer address was used to generate the DUID.

   DUID-LL is recommended for devices that have a permanently-connected
   network interface with a link-layer address and do not have



Droms (ed.), et al.            Expires 30 Apr 2003             [Page 16]

Internet Draft              DHCP for IPv6 (-28)               2 Nov 2002


   nonvolatile, writable stable storage.  DUID-LL MUST NOT be used by
   DHCP clients or servers that cannot tell whether or not a network
   interface is permanently attached to the device on which the DHCP
   client is running.


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

   The configuration information in an IA consists of one or more IPv6
   addresses along with the times T1 and T2 for the IA. See section 22.4
   for the representation of an IA in a DHCP message.

   Each address in an IA has a preferred lifetime and a valid lifetime,
   as defined in RFC2462 [21].  The lifetimes are transmitted from the
   DHCP server to the client in the IA option.  The lifetimes apply to
   the use of IPv6 addresses as described in section 5.5.4 of RFC2462.


11. Selecting Addresses for Assignment to an IA

   A server selects addresses to be assigned to an IA according to the
   address assignment policies determined by the server administrator
   and the specific information the server determines about the client
   from some combination of the following sources:

    -  The link to which the client is attached.  The server determines
       the link as follows:

        *  If the server receives the message directly from the client
           and the source address in the IP datagram in which the
           message was received is a link-local address, then the client



Droms (ed.), et al.            Expires 30 Apr 2003             [Page 17]

Internet Draft              DHCP for IPv6 (-28)               2 Nov 2002


           is on the same link to which the interface over which the
           message was received is attached

        *  If the server receives the message from a forwarding relay
           agent, then the client is on the same link as the one to
           which the interface identified by the link-address field in
           the message from the relay agent is attached

        *  If the server receives the message directly from the client
           and the source address in the IP datagram in which the
           message was received is not a link-local address, then the
           client is on the link identified by the source address in the
           IP datagram (note that this situation can occur only if the
           server has enabled the use of unicast message delivery by the
           client and the client has sent a message for which unicast
           delivery is allowed)

    -  The DUID supplied by the client

    -  Other information in options supplied by the client

    -  Other information in options supplied by the relay agent

   Any address assigned by a server that is based on an EUI-64
   identifier MUST include an interface identifier with the "u"
   (universal/local) and "g" (individual/group) bits of the interface
   identifier set appropriately, as indicated in section 2.5.1 of RFC
   2373 [9].

   A server MUST NOT assign an address that is otherwise reserved for
   some other purpose.  For example, a server MUST NOT assign reserved
   anycast addresses, as defined in RFC2526, from any subnet.


12. Management of Temporary Addresses

   A client may request the assignment of temporary addresses (see
   RFC 3041 [16] for the definition of temporary addresses).  DHCPv6
   handling of address assignment is no different for temporary
   addresses.  DHCPv6 says nothing about details of temporary addresses
   like lifetimes, how clients use temporary addresses, rules for
   generating successive temporary addresses, etc.

   Clients ask for temporary addresses and servers assign them.
   Temporary addresses are carried in the Identity Association for
   Temporary Addresses (IA_TA) option (see section 22.5).  Each IA_TA
   option contains at most one temporary address for each of the
   prefixes on the link to which the client is attached.

   The IAID number space for the IA_TA option IAID number space is
   separate from the IA_NA option IAID number space.





Droms (ed.), et al.            Expires 30 Apr 2003             [Page 18]

Internet Draft              DHCP for IPv6 (-28)               2 Nov 2002


   The server MAY update the DNS for a temporary address as described in
   section 4 of RFC3041.


13. Transmission of Messages by a Client

   Unless otherwise specified in this document or in a document that
   describes how IPv6 is carried over a specific type of link (for link
   types that do not support multicast), a client sends DHCP messages to
   the All_DHCP_Relay_Agents_and_Servers.

   A client uses multicast to reach all servers or an individual server.
   An individual server is indicated by specifying that server's DUID in
   a Server Identifier option (see section 22.3) in the client's message
   (all servers will receive this message but only the indicated server
   will respond).  All servers are indicated by not supplying this
   option.

   A client may send some messages directly to a server using unicast,
   as described in section 22.12.


14. Reliability of Client Initiated Message Exchanges

   DHCP clients are responsible for reliable delivery of messages in the
   client-initiated message exchanges described in sections 17 and 18.
   If a DHCP client fails to receive an expected response from a server,
   the client must retransmit its message.  This section describes the
   retransmission strategy to be used by clients in client-initiated
   message exchanges.

   Note that the procedure described in this section is slightly
   modified when used with the Solicit message.  The modified procedure
   is described in section 17.1.2.

   The client begins the message exchange by transmitting a message to
   the server.  The message exchange terminates when either the client
   successfully receives the appropriate response or responses from a
   server or servers, or when the message exchange is considered to have
   failed according to the retransmission mechanism described below.

   The client retransmission behavior is controlled and described by the
   following variables:

      RT     Retransmission timeout

      IRT    Initial retransmission time

      MRC    Maximum retransmission count

      MRT    Maximum retransmission time

      MRD    Maximum retransmission duration



Droms (ed.), et al.            Expires 30 Apr 2003             [Page 19]

Internet Draft              DHCP for IPv6 (-28)               2 Nov 2002


      RAND   Randomization factor

   With each message transmission or retransmission, the client sets RT
   according to the rules given below.  If RT expires before the message
   exchang