Hi:
Thank you for working to correct these issues! I'm sorry I won't be at
the Interop Test Event next week, but Ralph Droms will be there.
I haven't yet tried the additional patched files
(S_RFC3315_15.4_InvalidREquestMsgWoCltID.seq and
S_RFC3315_15_DiscardRequestwithInvalidOP.seq). Our server is still
failing the Invalid Option tests (where the test node, client, sends in
a Preference Option to the server), but that will continue to be the
case as we don't plan to add checks for these options (as they do no
"harm" -- the server ignores them).
> I still have some points which are not clear about
> Status code option,
> would you like to confirm them for me?
> 1) If the message exchange is successful, the Status Code option
> "Success" isn't a "Must be in" option, isn't right?
Except for a successful REPLY to a CONFIRM, RELEASE, and DECLINE
message, I believe you are correct in that a Status Code Option with
Success is not required.
In section 22.13 of RFC 3315 it is stated "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."
>
> 2)When we received a Reply message with the "NotOnLink" status
> code option(or NotBinding), it maybe have 3 kinds of
> location. (showed in the
> following list) Can we think about all of them is acceptable?
>
> Type1: at the root of the message
> Message main
> | |
> IA_* NotOnLink
>
> Type2: in the root of the IA_* optiones
> Message main
> |
> IA_*
> |
> NotOnLink
>
> Type3: in the root of the IA_Address optiones
> Message main
> |
> IA_*
> |
> IA_Address
> |
> NotOnLink
While technically all of these are possible, I interpret RFC 3315 to
mean only type 2 (for Reply to a REQUEST) and type 1 (for REPLY to a
CONFIRM) are used.
Section 18.2.1 (REQUEST) says:
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.
Section 18.2.2 (CONFIRM) says:
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. 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. If the server is unable to perform
this test (for example, the server does not have information about
prefixes on the link to which the client is connected), or there were
no addresses in any of the IAs sent by the client, the server MUST
NOT send a reply to the client.
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.
>
> 3)If the Relay message with the "NotAddrAvail" status
> code option is received, It maybe have 2 kinds of location.
> How about them?
>
> Type1: in the root of the IA_* options
> Message main
> |
> IA_*
> |
> NotAddrAvail
>
> Type2: in the root of the IA_Address options
> Message main
> |
> IA_*
> |
> IA_Address
> |
> NotAddrAvail
> ...
No, I think these can only appear in the main message (1) or
encapsulated within an IA_* option (2).
The first type (1) [in the main message] is sent in an Advertise (see
RFC 3315, section 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 and a status message for the user, a Server
Identifier option with the server's DUID, and a Client Identifier
option with the client's DUID.
The second type (2) [encapsulated within an IA_* option] is sent in a
REPLY to a REQUEST (see RFC 3315, section 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.
Note that for the NoPrefixAvail, RFC 3633 has slightly different
behavior and it only uses the second type (2) [encapsulated within an
IA_PD option] encoding! RFC 3633, Section 11 states:
If the delegating router will not assign any prefixes to any IA_PDs
in a subsequent Request from the requesting router, the delegating
router MUST send an Advertise message to the requesting router that
includes the IA_PD with no prefixes in the IA_PD and a Status Code
option in the IA_PD containing status code NoPrefixAvail and a status
message for the user, a Server Identifier option with the delegating
router's DUID and a Client Identifier option with the requesting
router's DUID.
And, then in 12.1:
Handling of Status Codes options in received Reply messages is
described in section 18.1.8, "Receipt of Reply Messages" of RFC 3315.
The NoPrefixAvail Status Code is handled in the same manner as the
NoAddrsAvail Status Code.
>
> 4)If the count of IA_* option and IA_Address option are all
> gearter than 1,
> I think maybe the right structure should be like this?
> Is it right?
> Message main
> -------------------------------------------
> | |
> IA_* IA_*
> ------------------- ----------------------
> | | | |
> IA_Address IA_Address IA_Address IA_Address
> | | | |
> Status1 Status2 Status3 Status4
Yes, this is potentially a correct structure although I don't believe we
have any case that could return this at present? (I guess this goes back
to question 1 above, in that there may not be a StatusN option, but the
implicit "Success" status code is assumed?)
- Bernie
> -----Original Message-----
> From: haoda [mailto:haoda@64translator.com]
> Sent: Monday, January 16, 2006 3:03 AM
> To: dhcptest@tahi.org
> Subject: [dhcptest:00101] Re: Release-0.3 TAHI DHCPv6 conformance test
>
> Hi,Mr. Volz,
>
> Thank you very much!
> The informations from you are not only its location and log,
> but also including the description of them & RFC.
> They are very helpful to me.
>
> I have read your mail carefully and begun fixing the problem
> which have been found. Please wait for the next release.
> It will be done recently.
>
> > Regarding Test 26
> > (S_RFC3315_15.4_InvalidRequestMsgWoCltID.seq), it still fails
> &
> > Regarding Test 27
> Sorry I forget to add the files which have been modified in
> last patch.
> Please change them to the new files.
> By the way, I think the Test 25 is different from 27 because
> the goal of
> Test 25 is to check whether the result is failed if the SID
> opiton is not
> consitent in the exchangement of messages.
>
>
> > Regarding Test 47 (./S_RFC3315_15.10_ClientIDOPMatch.seq),
> > Regarding Test 48
> > Regarding Test 51
> > Regarding Test 52 (./S_RFC3315_15.14_InvalidRelayReplyMsg.seq
> > Regarding Test 72
> > Regarding Test 75 (./S_RFC3315_18.2.2_ReceiptConfirmMsg.seq)
> > Regarding Test 78 (
> > Regarding Test 81
> > Regarding Test 83
> > Regarding Test 86
> > Regarding Test 93 (./S_RFC3315_18.2.7_ReceiptDeclineMsg.seq),
> > Regarding Test 107
> > Regarding Test 108 (./S_RFC3315_22.13_StatusCodeOP.seq),
> > Regarding Test 123 (./S_RFC3633_10_MultiIAPDPreOP.seq), this
> > Regarding Test 128 (./S_RFC3633_12.2_ClientInitPDRebind.seq),
> > Regarding Test 130
> They are now fixing, please waitting.
> Almost all of them have relation to the Status Code option.
> I still have some points which are not clear about
> Status code option,
> would you like to confirm them for me?
> 1) If the message exchange is successful, the Status Code option
> "Success" isn't a "Must be in" option, isn't right?
>
> 2)When we received a Reply message with the "NotOnLink" status
> code option(or NotBinding), it maybe have 3 kinds of
> location. (showed in the
> following list) Can we think about all of them is acceptable?
>
> Type1: at the root of the message
> Message main
> | |
> IA_* NotOnLink
>
> Type2: in the root of the IA_* optiones
> Message main
> |
> IA_*
> |
> NotOnLink
>
> Type3: in the root of the IA_Address optiones
> Message main
> |
> IA_*
> |
> IA_Address
> |
> NotOnLink
>
> 3)If the Relay message with the "NotAddrAvail" status
> code option is received, It maybe have 2 kinds of location.
> How about them?
>
> Type1: in the root of the IA_* optiones
> Message main
> |
> IA_*
> |
> NotBinding or Not
>
> Type2: in the root of the IA_Address optiones
> Message main
> |
> IA_*
> |
> IA_Address
> |
> NotOnLink
>
>
> 4)If the count of IA_* option and IA_Address option are all
> gearter than 1,
> I think maybe the right structure should be like this?
> Is it right?
> Message main
> ----------------------------------------------
> | |
> IA_* IA_*
> --------------------- -------------------------
> | | | |
> IA_Address IA_Address IA_Address IA_Address
> | | |
> |
> Staus1 Status2 Status3 Status4
>
> And please keep giving me informations of DHCPv6 test tool.
> Thank you!
>
> Sincerely yours,
> Haoda
>