Thank you for your report.
We have been realizing these problems.
We will fix these problem in the next release or in new DHCPv6 Logo
Program ct.
Thanks again,
Best regards,
...Hideshi
> -----Original Message-----
> From: Seth Jennings [mailto:sjennings@us.ibm.com]
> Sent: Saturday, March 10, 2007 4:08 AM
> To: dhcptest@tahi.org
> Cc: Patrick T Vo; Denise Genty
> Subject: [dhcptest:00153] Test cases per RFC?
>
> In the DHCPv6 test (version 1.0), I found two test cases that
> I don't think are per RFC 3315.
>
> 1. In test case 63 (Creation and Transmission of Relay-reply
> Messages include Advertise Message) the packet sent by the
> test is below:
>
> Frame_Ether (length:130)
> | Hdr_Ether (length:14)
> | | DestinationAddress = 33:33:00:01:00:03
> | | SourceAddress = 00:00:00:00:a4:a4
> | | Type = 34525
> | Packet_IPv6 (length:116)
> | | Hdr_IPv6 (length:40)
> | | | Version = 6
> | | | TrafficClass = 0
> | | | FlowLabel = 0
> | | | PayloadLength = 76
> | | | NextHeader = 17
> | | | HopLimit = 32
> | | | SourceAddress =
> 3ffe:501:ffff:100:200:ff:fe00:a4a4
> | | | DestinationAddress = ff05::1:3
> | | Upp_UDP (length:76)
> | | | Hdr_UDP (length:8)
> | | | | SourcePort = 547
> | | | | DestinationPort = 547
> | | | | Length = 76
> | | | | Checksum = 15198 calc(15198)
> | | | Udp_DHCPv6_RelayForward (length:68)
> | | | | Type = 12
> | | | | HopCount = 0
> | | | | LinkAddr =
> 3ffe:501:ffff:101:200:ff:fe00:a5a5
> | | | | PeerAddr = fe80::200:ff:fe00:a2a2
> | | | | Opt_DHCPv6_RelayMessage (length:34)
> | | | | | Code = 9
> | | | | | Length = 30
> | | | | | Udp_DHCPv6_Solicit (length:30)
> | | | | | | Type = 1
> | | | | | | Identifier = 100
> | | | | | | Opt_DHCPv6_CID (length:18)
> | | | | | | | Code = 1
> | | | | | | | Length = 14
> | | | | | | | DHCPv6_DUID_LLT_Ether (length:14)
> | | | | | | | | Type = 1
> | | | | | | | | HardwareType = 1
> | | | | | | | | Time = 300000
> | | | | | | | | LinkLayerAddress = 00:00:00:00:a2:a2
> | | | | | | Opt_DHCPv6_IID (length:8)
> | | | | | | | Code = 18
> | | | | | | | Length = 4
> | | | | | | | Identifier = 01010101
>
> You can see that the Interface Id option is inside the
> SOLICIT message. In RFC 3315 section 22.18, the Interface Id
> option "MUST NOT appear in any message except a Relay-Forward
> or Relay-Reply message". If the Length field of the Relay
> Message option was changed from 30 to 22, this would make the
> Interface Id option part of the Relay-Forward message and per RFC.
>
> 2. In test case 95 (The format of Relay-reply Message when it
> passes through multi relay agent) the packet sent by the test
> is below:
>
> Frame_Ether (length:184)
> | Hdr_Ether (length:14)
> | | DestinationAddress = 00:04:ac:e4:b3:55
> | | SourceAddress = 00:00:00:00:a7:a7
> | | Type = 34525
> | Packet_IPv6 (length:170)
> | | Hdr_IPv6 (length:40)
> | | | Version = 6
> | | | TrafficClass = 0
> | | | FlowLabel = 0
> | | | PayloadLength = 130
> | | | NextHeader = 17
> | | | HopLimit = 64
> | | | SourceAddress =
> 3ffe:501:ffff:100:200:ff:fe00:a4a4
> | | | DestinationAddress = ff05::1:3
> | | Upp_UDP (length:130)
> | | | Hdr_UDP (length:8)
> | | | | SourcePort = 547
> | | | | DestinationPort = 547
> | | | | Length = 130
> | | | | Checksum = 36631 calc(36631)
> | | | Udp_DHCPv6_RelayForward (length:122)
> | | | | Type = 12
> | | | | HopCount = 0
> | | | | LinkAddr = ::
> | | | | PeerAddr =
> 3ffe:501:ffff:101:200:ff:fe00:a7a7
> | | | | Opt_DHCPv6_RelayMessage (length:88)
> | | | | | Code = 9
> | | | | | Length = 84
> | | | | | Udp_DHCPv6_RelayForward (length:84)
> | | | | | | Type = 12
> | | | | | | HopCount = 0
> | | | | | | LinkAddr =
> 3ffe:501:ffff:101:200:ff:fe00:a8a8
> | | | | | | PeerAddr = fe80::200:ff:fe00:a2a2
> | | | | | | Opt_DHCPv6_RelayMessage (length:42)
> | | | | | | | Code = 9
> | | | | | | | Length = 38
> | | | | | | | Udp_DHCPv6_Solicit (length:38)
> | | | | | | | | Type = 1
> | | | | | | | | Identifier = 100
> | | | | | | | | Opt_DHCPv6_CID (length:18)
> | | | | | | | | | Code = 1
> | | | | | | | | | Length = 14
> | | | | | | | | | DHCPv6_DUID_LLT_Ether (length:14)
> | | | | | | | | | | Type = 1
> | | | | | | | | | | HardwareType = 1
> | | | | | | | | | | Time = 300000
> | | | | | | | | | | LinkLayerAddress =
> 00:00:00:00:a2:a2
> | | | | | | | | Opt_DHCPv6_IA_NA (length:16)
> | | | | | | | | | Code = 3
> | | | | | | | | | Length = 12
> | | | | | | | | | Identifier = 101010
> | | | | | | | | | Time1 = 4000
> | | | | | | | | | Time2 = 5000
> | | | | | | Opt_DHCPv6_IID (length:8)
> | | | | | | | Code = 18
> | | | | | | | Length = 4
> | | | | | | | Identifier = 01010101
>
> You can see that the hop-count is 0 for both Relay-Forward
> messages. In RFC 3315 section 20.1.2 :
>
> "The relay agent copies the source address from the IP datagram in
> which the message was received from the client into the
> peer-address
> field in the Relay-forward message and sets the hop-count field to
> the value of the hop-count field in the received message
> incremented
> by 1."
>
> The first (outermost) RELAY-FORW message should have a hop-count of 1.
>
>
> Thanks,
>
> Seth Jennings
> sjennings@us.ibm.com
> TCP/IP Development
> (512) 838-4072
>
>