Some additional feedback:
1. S_RFC3315_18.2.2_ReceiptConfirmMsg.seq,
S_RFC3315_18.2.2_ReceiptConfirmMsgWithNotOnLink.seq, and
S_RFC3315_18.2.2_AbnormalReplyReceiptConfirmMsg.seq also include a
Server Identifier option when it must not. (There are other cases --
looks like most REBIND messages include the Server Identifier.)
2. For S_RFC3315_15_DiscardSolicitwithInvalidOP.seq,
S_RFC3315_15_DiscardRenewwithInvalidOP.seq, and
S_RFC3315_15_DiscardDeclinewithInvalidOP.seq,
S_RFC3315_15_DiscardReleasewithInvalidOP.seq,
S_RFC3315_15.10_ClientIDOPMatch.seq, I see nothing in RFC 3315 that
would require a server to do anything to check for the existance of the
Preference Option from a client and drop the packet. While the
Preference Option is only used in server messages to clients, there is
no real harm in a client including it and a properly implemented server
would IGNORE unknown options.
Note that this is different from the Server Identifier Option I
mentioned for other tests cases - the Solicit, Confirm, and Rebind
messages are specially designed to be sent to *ALL* servers, not just
one. Hence, there are valid reasons why a server that receives one of
these messages should detect the inclusion of this option and consider
the message invalid. Also, section 15 of RFC 3315 specifically indicates
these checks.
3. I fail to see what is invalid about the RENEW message in
S_RFC3315_18.2.3_DiscardReceiptRenewMsg.seq?
4. For the S_RFC3315_18.2.3_ReplyNoBidingStutusCodeReceiptRenewMsg.seq
test case, it looks like the test expects the Status Code option to be
in the main part of the Reply. However, the server I'm testing against
is putting it in the IA_NA option itself. RFC 3315 isn't clear about
this and does appear to favor your interpretation but that causes issues
if there are multiple IAs in the RENEW (since it may be the server just
doesn't know about one, not all).
18.2.3. Receipt of Renew Messages
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, a Server Identifier
option containing the server's DUID, the Client Identifier option
from the client message, and no other options.
When the server receives a Renew 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 the server
returns the IA containing no addresses with a Status Code option set
to NoBinding in the Reply message.
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
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.
If the server finds the addresses in the IA for the client then the
^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
server sends back the IA to the client with new lifetimes and T1/T2
times. The server may choose to change the list of addresses and the
lifetimes of addresses in IAs that are returned to the client.
It seems to me that we need to claify RFC 3315 about exactly where this
Status Code option should go. During the drafting, I recall that the
discussion was to put it in the IA_* option.
5. In S_RFC3315_22.13_StatusCodeOP.seq, the following message is sent
and the expected response is a Reply with a Status Code option? Why?
What's wrong with this request? Is the absense of an IAADDR option in
the IA_NA option supposed to generate an error? If so, this is mistaken
as I don't see that an IAADDR option is required.
Or, is there something I missed in this test sequence
(SOLICIT/ADVERTISE/REQUEST/REPLY)?
R10: ----- RECEIVED -- R10 -----
R10: -> received 56 bytes from fe80::200:ff:fe00:a2a2, port 1027
R10: -> +- Start of REQUEST (3) message (56 bytes)
R10: -> | transaction-id 101
R10: -> | client-identifier (1) option (14 bytes)
R10: -> | 00:01:00:01:00:04:93:e0:00:00:00:00:a2:a2
R10: -> | server-identifier (2) option (14 bytes)
R10: -> | 00:01:00:01:43:b2:b2:e5:00:03:ba:6c:9f:b9
R10: -> | ia-na (3) option (12 bytes)
R10: -> | (iaid 101010, t1 1h6m40s, t2 1h23m20s)
R10: -> +- End of REQUEST message
R10: ----- END OF RECEIVED -- R10 -----
6. None of the relay tests appear to be working for me.
I notice that the client requests are coming from and being sent to
fe80::200:ff:fe00:a2a2, which works fine. However, the relay requests
are coming from fe80::200:ff:fe00:a4a4 and this does not work (ie,
replies aren't received). I am running on FreeBSD 6.0? Perhaps I missed
up something in the setup?
This is unlikely an issue with the DHCPv6 server under test since it has
been used successfully with other relay agents such as Dibbler and
commercially available routers. And, the DHCPv6 server is receiving the
packets; the Tahi TN is not receiving the packets.
7. In S_RFC3633_12.2_ClientInitPDRenew.seq, the server-identifier option
that was sent in the
The server responded with a server-identifier option of
00:01:00:01:43:b2:b2:e5:00:03:ba:6c:9f:b9, yet the TN sent
00:ff:00:00:00:00:00:00:00:00.
Reply Message
DHCPv6 OptionValues
Opt_DHCPv6_ServerUnicastAddress= 2001:420:3800:4801:203:baff:fe6c:9fb8
Opt_DHCPv6_SIDDUID-LLT HardwareType = 1
DUID-LLT MAC = 00:03:ba:6c:9f:b9 <---- Server ID
returned
DUID-LLT TIME = 1135784677
IdentifierIdentifier = 101
Opt_DHCPv6_CIDDUID-LLT HardwareType = 1
DUID-LLT MAC = 00:00:00:00:a2:a2
DUID-LLT TIME = 300000
Opt_DHCPv6_IA_PDIdentifier= 303030
T1= 5397
T2= 8636
#IA_Prefix Option 1
Prefix= 3ffe:ffff:102::
Prefix Length= 48
PreferredLifetime= 10795
ValidLifetime= 21595
Opt_DHCPv6_PreferencePreference = 10
Can not found DUID in this message <----- Huh?
Send DHCPv6 Renew Message: CLIENT1 --> all DHCPv6 Servers
Renew Message
DHCPv6 OptionValues
Opt_DHCPv6_SIDDUID (unknown)
IdentifierIdentifier = 106
Opt_DHCPv6_CIDDUID-LLT HardwareType = 1
DUID-LLT MAC = 00:00:00:00:a2:a2
DUID-LLT TIME = 300000
Opt_DHCPv6_IA_PDIdentifier= 303030
T1= 500
T2= 1000
#IA_Prefix Option 1
Prefix= 3ffe:ffff:1000::
Prefix Length= 48
PreferredLifetime= 1000
ValidLifetime= 2000
Could not get Reply Message <--- server dropped it since
server-identifier was incorrect!
NG: Can't receive the reply message
DHCPv6 Server stop
- Bernie