Changes between Version 4 and Version 5 of tests_v6


Ignore:
Timestamp:
May 27, 2013, 11:09:24 AM (4 years ago)
Author:
wlodekwencel
Comment:

--

Legend:

Unmodified
Added
Removed
Modified
  • tests_v6

    v4 v5  
    1616|| 14 || 15.14. || Servers must discard any received Relay-reply messages. || ||
    1717|| 15 || 17.2. || A server sends an Advertise message in response to valid Solicit messages it receives. || ||
    18 || 16 || 17.2.1. || If the server is not permitted to respond to the client, the server discards the Solicit message. || ||
    19 || 17 || 17.2.2. || The server sets the "msg-type" field to ADVERTISE and copies the contents of the transaction-id field from the Solicit message received from the client to the Advertise message. || ||
    20 || 18 || 17.2.2. || The server preference value must default to zero unless otherwise configured by the server administrator. || ||
    21 || 19 || 17.2.2. || If the client has included an Option Request option in the Solicit message, the server includes options in the Advertise message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. || ||
    22 || 20 || 17.2.2. || If the Solicit message from the client included one or more IA options, the server must include IA options in the Advertise message containing any addresses that would be assigned to IAs contained in the Solicit message from the client. || ||
    23 || 21 || 17.2.2. || If the client has included addresses in the IAs in the Solicit message, the server uses those addresses as hints about the addresses the client would like to receive. || ||
    24 || 22 || 17.2.2. || If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server must send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail || ||
    25 || 23 || 17.2.2. || If the Solicit message was received directly by the server, the server unicasts the Advertise message directly to the client using the address in the source address field from the IP datagram in which the Solicit message was received. The Advertise message must be unicast on the link from which the Solicit message was received. || ||
    26 || 24 || 17.2.2. || If the Solicit message was received in a Relay-forward message, the server constructs a Relay-reply message with the Advertise message in the payload of a "relay-message" option. The server unicasts the Relay-reply message directly to the relay agent using the address in the source address field from the IP datagram in which the Relay-forward message was received. || ||
    27 || 25 || 18.1.3. || The server determines new lifetimes for the addresses in the IA according to the administrative configuration of the server. || ||
    28 || 26 || 18.2. || This Reply message must always contain the Server Identifier option containing the server's DUID and the Client Identifier option from the client message if one was present. || ||
     18|| 16 || 17.2.1. || If the client has included a Rapid Commit option in the Solicit message and the server has been configured to respond with committed address assignments and other resources, the server responds to the Solicit with a Reply message as described in section 17.2.3. || ||
     19|| 17 || 17.2.1. || If the client has included a Rapid Commit option in the Solicit message and the server has been configured to respond [..] Otherwise, the server ignores the Rapid Commit option and processes the remainder of the message as if no Rapid Commit option were present. || ||
     20|| 18 || 17.2.2. || The server sets the "msg-type" field to ADVERTISE and copies the contents of the transaction-id field from the Solicit message received from the client to the Advertise message. || ||
     21|| 19 || 17.2.2. || The server preference value must default to zero unless otherwise configured by the server administrator. || ||
     22|| 20 || 17.2.2. || If the client has included an Option Request option in the Solicit message, the server includes options in the Advertise message containing configuration parameters for all of the options identified in the Option Request option that the server has been configured to return to the client. || ||
     23|| 21 || 17.2.2. || If the Solicit message from the client included one or more IA options, the server must include IA options in the Advertise message containing any addresses that would be assigned to IAs contained in the Solicit message from the client. || ||
     24|| 22 || 17.2.2. || If the client has included addresses in the IAs in the Solicit message, the server uses those addresses as hints about the addresses the client would like to receive. || ||
     25|| 23 || 17.2.2. || If the server will not assign any addresses to any IAs in a subsequent Request from the client, the server must send an Advertise message to the client that includes only a Status Code option with code NoAddrsAvail || ||
     26|| 24 || 17.2.2. || If the Solicit message was received directly by the server, the server unicasts the Advertise message directly to the client using the address in the source address field from the IP datagram in which the Solicit message was received. The Advertise message must be unicast on the link from which the Solicit message was received. || ||
     27|| 25 || 17.2.2. || If the Solicit message was received in a Relay-forward message, the server constructs a Relay-reply message with the Advertise message in the payload of a "relay-message" option. The server unicasts the Relay-reply message directly to the relay agent using the address in the source address field from the IP datagram in which the Relay-forward message was received. || Relay test ||
     28|| 26 || 18.2. || Reply message must always contain the Server Identifier option containing the server's DUID and the Client Identifier option from the client message if one was present. || ||
    2929|| 27 || 18.2.1. || When the server receives a Request message via unicast from a client to which the server has not sent a unicast option, the server discards the Request message and responds with a Reply message containing a Status Code option with the value UseMulticast || ||
    3030|| 28 || 18.2.1. || The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Request message into the transaction-id field.[[BR]] The server must include a Server Identifier option containing the server's DUID and the Client Identifier option from the Request message in the Reply message. || ||
    3131|| 29 || 18.2.1. || If the server finds that the prefix on one or more IP addresses in any IA in the message from the client is not appropriate for the link to which the client is connected, the server must return the IA to the client with a Status Code option with the value NotOnLink. || ||
    3232|| 30 || 18.2.1. || If the server cannot assign any addresses to an IA in the message from the client, the server must include the IA in the Reply message with no addresses in the IA and a Status Code option in the IA containing status code NoAddrsAvail. || ||
    33 || 31 || 18.2.2. || When the server receives a Confirm message, the server determines whether the addresses in the Confirm message are appropriate for the link to which the client is attached.[[BR]] If all of the addresses in the Confirm message pass this test, the server returns a status of Success. If any of the addresses do not pass this test, the server returns a status of NotOnLink. [[BR]]If the server is unable to perform this test, or there were no addresses in any of the IAs sent by the client, the server must NOT send a reply to the client. || ||
    34 || 32 || 18.2.2. || The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Confirm message into the transaction-id field. The server must include a Server Identifier option containing the server's DUID and the Client Identifier option from the Confirm message in the Reply message.  The server includes a Status Code option indicating the status of the Confirm message. || ||
    35 || 33 || 18.2.3. || When the server receives a Renew message via unicast from a client to which the server has not sent a unicast option, the server discards the Renew message and responds with a Reply message containing a Status Code option with the value UseMulticast || ||
    36 || 34 || 18.2.3. || If the server cannot find a client entry for the IA the server returns the IA containing no addresses with a Status Code option set to NoBinding in the Reply message. || ||
    37 || 35 || 18.2.3. || If the server finds that any of the addresses are not appropriate for the link to which the client is attached, the server returns the address to the client with lifetimes of 0. || ||
    38 || 36 || 18.2.3. || The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Renew message into the transaction-id field. The server must include a Server Identifier option containing the server's DUID and the Client Identifier option from the Renew message in the Reply message. || ||
    39 || 37 || 18.2.4. || When the server receives a Rebind message that contains an IA option from a client, it locates the client's binding and verifies that the information in the IA from the client matches the information stored for that client. If the server cannot find a client entry for the IA and the server determines that the addresses in the IA are not appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server MAY send a Reply message to the client containing the client's IA, with the lifetimes for the addresses in the IA set to zero. || ||
    40 || 38 || 18.2.4. || When the server receives a Rebind message that contains an IA option from a client, If the server finds that any of the addresses are no longer appropriate for the link to which the client is attached, the server returns the address to the client with lifetimes of 0. || ||
    41 || 39 || 18.2.4. || When the server receives a Rebind message that contains an IA option from a client, If the server finds the addresses in the IA for the client then the server should send back the IA to the client with new lifetimes and T1/T2 times. || ||
    42 || 40 || 18.2.4. || The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Rebind message into the transaction-id field. The server must include a Server Identifier option containing the server's DUID and the Client Identifier option from the Rebind message in the Reply message. || ||
    43 || 41 || 18.2.5. || When the server receives an Information-request message, the client is requesting configuration information that does not include the assignment of any addresses.  The server determines all configuration parameters appropriate to the client, based on the server configuration policies known to the server. || ||
    44 || 42 || 18.2.5. || The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Information-request message into the transaction-id field. The server must include a Server Identifier option containing the server's DUID in the Reply message.  If the client included a Client Identification option in the Information-request message, the server copies that option to the Reply message || ||
    45 || 43 || 18.2.5. || If the Information-request message received from the client did not include a Client Identifier option, the server should respond with a Reply message containing any configuration parameters that are not determined by the client's identity. || ||
    46 || 44 || 18.2.6. || When the server receives a Release message via unicast from a client to which the server has not sent a unicast option, the server discards the Release message and responds with a Reply message containing a Status Code option with value UseMulticast || ||
    47 || 45 || 18.2.6. || Upon the receipt of a valid Release message,  If the IAs in the message are in a binding for the client, and the addresses in the IAs have been assigned by the server to those IAs, the server deletes the addresses from the IAs and makes the addresses available || ||
    48 || 46 || 18.2.6. || Upon the receipt of a valid Release message, After all the addresses have been processed, the server generates a Reply message and includes a Status Code option with value Success, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID || ||
    49 || 47 || 18.2.7. || When the server receives a Decline message via unicast from a client to which the server has not sent a unicast option, the server discards the Decline message and responds with a Reply message containing a Status Code option with the value UseMulticast || ||
    50 || 48 || 18.2.7. || When the server receives a Decline message After all the addresses have been processed, the server generates a Reply message and includes a Status Code option with the value Success || ||
    51 || 49 || 18.2.7. || For each IA in the Decline message for which the server has no binding information, the server adds an IA option using the IAID from the Release message and includes a Status Code option with the value NoBinding in the IA option || ||
     33|| 31 || 18.2.1. || The server includes a Reconfigure Accept option if the server wants to require that the client accept Reconfigure messages. || ||
     34|| 32 || 18.2.2. || When the server receives a Confirm message, the server determines whether the addresses in the Confirm message are appropriate for the link to which the client is attached.[[BR]] If all of the addresses in the Confirm message pass this test, the server returns a status of Success. If any of the addresses do not pass this test, the server returns a status of NotOnLink. [[BR]]If the server is unable to perform this test, or there were no addresses in any of the IAs sent by the client, the server must NOT send a reply to the client. || ||
     35|| 33 || 18.2.2. || The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Confirm message into the transaction-id field. The server must include a Server Identifier option containing the server's DUID and the Client Identifier option from the Confirm message in the Reply message.  The server includes a Status Code option indicating the status of the Confirm message. || ||
     36|| 34 || 18.2.3. || When the server receives a Renew message via unicast from a client to which the server has not sent a unicast option, the server discards the Renew message and responds with a Reply message containing a Status Code option with the value UseMulticast || ||
     37|| 35 || 18.2.3. || If the server cannot find a client entry for the IA the server returns the IA containing no addresses with a Status Code option set to NoBinding in the Reply message. || ||
     38|| 36 || 18.2.3. || If the server finds that any of the addresses are not appropriate for the link to which the client is attached, the server returns the address to the client with lifetimes of 0. || ||
     39|| 37 || 18.2.3. || The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Renew message into the transaction-id field. The server must include a Server Identifier option containing the server's DUID and the Client Identifier option from the Renew message in the Reply message. || ||
     40|| 38 || 18.2.4. || When the server receives a Rebind message that contains an IA option from a client, it locates the client's binding and verifies that the information in the IA from the client matches the information stored for that client. If the server cannot find a client entry for the IA and the server determines that the addresses in the IA are not appropriate for the link to which the client's interface is attached according to the server's explicit configuration information, the server MAY send a Reply message to the client containing the client's IA, with the lifetimes for the addresses in the IA set to zero. || ||
     41|| 39 || 18.2.4. || When the server receives a Rebind message that contains an IA option from a client, If the server finds that any of the addresses are no longer appropriate for the link to which the client is attached, the server returns the address to the client with lifetimes of 0. || ||
     42|| 40 || 18.2.4. || When the server receives a Rebind message that contains an IA option from a client, If the server finds the addresses in the IA for the client then the server should send back the IA to the client with new lifetimes and T1/T2 times. || ||
     43|| 41 || 18.2.4. || The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Rebind message into the transaction-id field. The server must include a Server Identifier option containing the server's DUID and the Client Identifier option from the Rebind message in the Reply message. || ||
     44|| 42 || 18.2.5. || When the server receives an Information-request message, the client is requesting configuration information that does not include the assignment of any addresses.  The server determines all configuration parameters appropriate to the client, based on the server configuration policies known to the server. || ||
     45|| 43 || 18.2.5. || The server constructs a Reply message by setting the "msg-type" field to REPLY, and copying the transaction ID from the Information-request message into the transaction-id field. The server must include a Server Identifier option containing the server's DUID in the Reply message.  If the client included a Client Identification option in the Information-request message, the server copies that option to the Reply message || ||
     46|| 44 || 18.2.5. || If the Information-request message received from the client did not include a Client Identifier option, the server should respond with a Reply message containing any configuration parameters that are not determined by the client's identity. || ||
     47|| 45 || 18.2.6. || When the server receives a Release message via unicast from a client to which the server has not sent a unicast option, the server discards the Release message and responds with a Reply message containing a Status Code option with value UseMulticast || ||
     48|| 46 || 18.2.6. || Upon the receipt of a valid Release message,  If the IAs in the message are in a binding for the client, and the addresses in the IAs have been assigned by the server to those IAs, the server deletes the addresses from the IAs and makes the addresses available || ||
     49|| 47 || 18.2.6. || Upon the receipt of a valid Release message, After all the addresses have been processed, the server generates a Reply message and includes a Status Code option with value Success, a Server Identifier option with the server's DUID, and a Client Identifier option with the client's DUID || ||
     50|| 48 || 18.2.7. || When the server receives a Decline message via unicast from a client to which the server has not sent a unicast option, the server discards the Decline message and responds with a Reply message containing a Status Code option with the value UseMulticast || ||
     51|| 49 || 18.2.7. || When the server receives a Decline message After all the addresses have been processed, the server generates a Reply message and includes a Status Code option with the value Success || ||
     52|| 50 || 18.2.7. || For each IA in the Decline message for which the server has no binding information, the server adds an IA option using the IAID from the Release message and includes a Status Code option with the value NoBinding in the IA option || ||
     53|| 51 || 18.2.8. || The Reply message MUST be unicast through the interface on which the original message was received. || ||
     54|| 52 || 18.2.8. || If the original message was received in a Relay-forward message, the server constructs a Relay-reply message with the Reply message in the payload of a Relay Message option. The server unicasts the Relay-reply message directly to the relay agent using the address in the source address field from the IP datagram in which the Relay-forward message was received. || relay ||
     55|| 53 || 19. || DHCP Server-Initiated Configuration Exchange - temporary unsupported ||  ||
     56|| 54 || 20.1. || The relay agent copies the source address from the header of the IP datagram in which the message was received to the peer-address field of the Relay-forward message. The relay agent copies the received DHCP message (excluding any IP or UDP headers) into a Relay Message option in the new message. || relay ||
     57|| 55 || 20.1.1. || If the relay agent cannot use the address in the link-address field to identify the interface through which the response to the client will be relayed, the relay agent MUST include an Interface-id option in the Relay-forward message. The server will include the Interface-id option in its Relay-reply message. || relay ||
     58|| 56 || 20.1.2. || If the message received by the relay agent is a Relay-forward message and the hop-count in the message is greater than or equal to HOP_COUNT_LIMIT, the relay agent discards the received message. || relay ||
     59|| 57 || 21. ||Authentication of DHCP Messages - temporary unsupported ||  ||
     60|| 58 || 22. || Unless otherwise noted, each option may appear only in the options area of a DHCP message and may appear only once. || ||
     61|| 59 || 22.1. || The format of DHCP options is: option-code, option-len, option-data || ||
     62|| 60 || 22.2. || The Client Identifier option is used to carry a DUID identifying a client between a client and a server. || ||
     63|| 61 || 22.3. || The Server Identifier option is used to carry a DUID identifying a server between a client and a server. || ||
     64|| 62 || 22.4. || The Identity Association for Non-temporary Addresses option (IA_NA option) is used to carry an IA_NA. || ||
     65|| 63 || 22.4. || The IA_NA-options field encapsulates those options that are specific to this IA_NA. An IA_NA option may only appear in the options area of a DHCP message.  A DHCP message may contain multiple IA_NA options. || ||
     66|| 64 || 22.4. || If a server receives an IA_NA with T1 greater than T2, and both T1 and T2 are greater than 0, the server ignores the invalid values of T1 and T2 and processes the IA_NA as though the client had set T1 and T2 to 0. || ||
     67|| 65 || 22.5. || The Identity Association for the Temporary Addresses (IA_TA) option is used to carry an IA_TA, the parameters associated with the IA_TA and the addresses associated with the IA_TA. || ||
     68|| 66 || 22.5. || The IA_TA-Options field encapsulates those options that are specific to this IA_TA. || ||
     69|| 67 || 22.6. || The IA Address option is used to specify IPv6 addresses associated with an IA_NA or an IA_TA. The IA Address option must be encapsulated in the Options field of an IA_NA or IA_TA option. More than one IA Address Option can appear in an IA_NA option or an IA_TA option. || ||
     70|| 68 || 22.7. || The Option Request option is used to identify a list of options in a message between a client and a server. A client MAY include an Option Request option in a Solicit, Request, Renew, Rebind, Confirm or Information-request message to inform the server about options the client wants the server to send to the client. || ||
     71|| 69 || 22.8. || The Preference option is sent by a server to a client to affect the selection of a server by the client. || ||
     72|| 70 || 22.10. || The Relay Message option carries a DHCP message in a Relay-forward or Relay-reply message. || unsupported ||
     73|| 71 || 22.11. || The Authentication option carries authentication information to authenticate the identity and contents of DHCP messages. The use of the Authentication option is described in section 21 || unsuporrted ||
     74|| 72 || 22.12. || The server sends this option to a client to indicate to the client that it is allowed to unicast messages to the server. The server specifies the IPv6 address to which the client is to send unicast messages in the server-address field. || ||
     75|| 73 || 22.13. || This option returns a status indication related to the DHCP message or option in which it appears. If the Status Code option does not appear in a message in which the option could appear, the status of the message is assumed to be Success. || ||
     76|| 74 || 22.14. || The Rapid Commit option is used to signal the use of the two message exchange for address assignment. A server MUST include this option in a Reply message sent in response to a Solicit message when completing the Solicit-Reply message exchange. || ||
     77|| 75 || 22.15. || The User Class option is used by a client to identify the type or category of user or applications it represents. A server selects configuration information for the client based on the classes identified in this option. || ||
     78|| 76 || 22.16. || This option is used by a client to identify the vendor that manufactured the hardware on which the client is running. || ||
     79|| 77 || 22.17. || This option is used by clients and servers to exchange vendor-specific information.Multiple instances of the Vendor-specific Information option may appear in a DHCP message. || ||
     80|| 78 || 22.18. || The relay agent MAY send the Interface-id option to identify the interface on which the client message was received.  If a relay agent receives a Relay-reply message with an Interface-id option, the relay agent relays the message to the client through the interface identified by the option. || relay - unsupported ||
     81|| 79 || 22.18. || The server MUST copy the Interface-Id option from the Relay-Forward message into the Relay-Reply message the server sends to the relay agent in response to the Relay-Forward message. || ||
     82|| 80 || 22.18. || This option (the Interface-Id option) MUST NOT appear in any message except a Relay-Forward or Relay-Reply message. || ||
     83|| 81 || 22.19. || The Reconfigure Message option can only appear in a Reconfigure message. || ||
     84|| 82 || 22.20. || A client uses the Reconfigure Accept option to announce to the server whether the client is willing to accept Reconfigure messages. The default behavior, in the absence of this option, means unwillingness to accept Reconfigure messages. || ||