Index: [Article Count Order] [Thread]

Date: Wed, 28 Dec 2005 14:35:42 -0500
From: "Bernie Volz \(volz\)" <volz@cisco.com>
Subject: [dhcptest:00080] S_RFC3315_BasicConfirmRepWithStatusCodeOP.seq & S_RFC3315_BasicRebindRep.seq  - Test is sending Server Identifier Option when it MUST NOT
To: <dhcptest@tahi.org>
Message-Id: <8E296595B6471A4689555D5D725EBB2101099B92@xmb-rtp-20a.amer.cisco.com>
X-Mail-Count: 00080

This also applies to S_RFC3315_BasicConfirmRepWithStatusCodeOP.seq
(again the CONFIRM includes the server-identifier option).

And, S_RFC3315_BasicRebindRep.seq also fails because a server-identifier
option is included. Again, from RFC 3315:

15.7. Rebind Message

   Clients MUST discard any received Rebind messages.

   Servers MUST discard any received Rebind messages that do not include
   a Client Identifier option or that do include a Server Identifier
                                 ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
   option.
   ^^^^^^

- Bernie

> -----Original Message-----
> From: Bernie Volz (volz) 
> Sent: Wednesday, December 28, 2005 2:30 PM
> To: dhcptest@tahi.org
> Subject: [dhcptest:00079] S_RFC3315_BasicConfirmRep.seq - 
> Test is sending Server Identifier Option when it MUST NOT
> 
> I'm using the DHCPv6_Self_Test_0-2 tests against a DHCPv6 
> server and it
> is failing the S_RFC3315_BasicConfirmRep test.
> 
> The reason for the failure is that the server is dropping the CONFIRM
> message because it contains a Server-Identifier option.
> 
> The server logs:
> 
> R18: ----- RECEIVED -- R18 -----  
> R18: -> received 84 bytes from fe80::200:ff:fe00:a2a2, port 1031  
> R18: -> +- Start of CONFIRM (4) message (84 bytes)  
> R18: -> |  transaction-id 105  
> R18: -> |  client-identifier (1) option (14 bytes)  
> R18: -> |    00:01:00:01:00:04:93:e0:00:00:00:00:a2:a2  
> R18: -> |  server-identifier (2) option (14 bytes)  
> R18: -> |    00:01:00:01:43:b2:b2:e5:00:03:ba:6c:9f:b9  
> R18: -> |  ia-na (3) option (40 bytes)  
> R18: -> |    (iaid 101010, t1 0, t2 0)  
> R18: -> |    iaaddr (5) option (24 bytes)  
> R18: -> |      (address 3333::2c80:c051:6f40:673a,  
> R18: -> |       preferred-lifetime 0,  
> R18: -> |       valid-lifetime 0)  
> R18: -> +- End of CONFIRM message  
> R18: ----- END OF RECEIVED -- R18 -----  
> 
> Received DHCPv6 CONFIRM packet R18 with a Server Identifier 
> option when
> it MUST NOT have one. Packet dropped.
> 
> Note that per RFC 3315:
> 
> 15.5. Confirm Message
> 
>    Clients MUST discard any received Confirm messages.
> 
>    Servers MUST discard any received Confirm messages that do not
>    include a Client Identifier option or that do include a Server
>                                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    Identifier option.
>    ^^^^^^^^^^^^^^^^^
> 
> Sorry if this problem has already been reported by someone else.
> 
> - Bernie Volz
>