Hello,
He forgot to advise about this affair.
I think that it had become consensus to use 135. Testing with many
vendors in the past, 135 is used. Although it was an old test event
fairly, the stack which was using 2 was not connected with others, and
it had corrected to 135.
However, I cannot show this basis. I hear that in practice, it is 135.
Specification will be corrected to 135 when RFC is updated.
Best Regards
--
Kiyoaki Kawaguchi
""Leino, Tammy" <tammy_leino@mentor.com>" wrote:
> Kiyoaki,
>
> I have found the checksum issue.
>
> Although RFC 3775 states to use 2 as the Next Header value in the
> pseudoheader, TAHI expects this value to be 135.
>
> The pseudo-header contains IPv6 header fields, as specified in
> Section 8.1 of RFC 2460 [11]. The Next Header value used in the
> pseudo-header is 2. The addresses used in the pseudo-header are
> the addresses that appear in the Source and Destination Address
> fields in the IPv6 packet carrying the Mobility Header.
>
> I found some threads on-line discussing this issue. Most people believe
> the IETF will change RFC 3775 to operate the way TAHI expects. Can you
> comment on this if you have time?
>
> Best Regards,
> Tammy
>
>
> -----Original Message-----
> From: K.Kawaguchi [mailto:kawaguti@ysknet.co.jp]
> Sent: Thursday, June 05, 2008 9:27 PM
> To: Leino, Tammy
> Cc: users@tahi.org
> Subject: Re: [users:00748] Re: MIPv6 Conformance Test Suite CN-1-1
>
>
> Hello Tammy,
>
> As you expected first, the checksum fields differ. It is the bottom of
> the log stuck on below.
>
> This tool is already used for many users. Probably, calculation of the
> checksum of this tool will be right.
>
> The checksum calculation of MIPv6 message is described by
> "6.1.1. Format" in RFC3775". Please check processing.
>
> 1.html#vRecvPKT3 in log file
> The logic structure of BE message and the log of the check by the
> tool.
> -----------------------------------------------
> Recv at 16:10:52
> Frame_Ether (length:78)
> | Hdr_Ether (length:14)
> | | DestinationAddress = 00:00:00:00:00:01
> | | SourceAddress = 00:a0:7d:08:00:00
> | | Type = 34525
> | Packet_IPv6 (length:64)
> | | Hdr_IPv6 (length:40)
> | | | Version = 6
> | | | TrafficClass = 0
> | | | FlowLabel = 0
> | | | PayloadLength = 24
> | | | NextHeader = 135
> | | | HopLimit = 255
> | | | SourceAddress =
> 3ffe:501:ffff:100:2a0:7dff:fe08:0
> | | | DestinationAddress = 3ffe:501:ffff:101::2
> | | Hdr_MH_BE (length:24)
> | | | NextHeader = 59
> | | | HeaderExtLength = 2
> | | | Type = 7
> | | | Reserved1 = 0
> | | | Checksum = 27700 calc(27567)
> | | | Status = 1 (Unknown binding for Home
> Address destination option)
> | | | Reserved2 = 0
> | | | Address = 3ffe:501:ffff:104::2
> | | Upp_NoNext (length:0)
> | | | data =
> ===Ns_Cn_R0_G_G_G================================= <<<< The internal
> packet definition name for evaluation.
> A message
> may be able to be guessed from a name.
> ICMPv6
> Neighbor solicitation message.
>
> (snip)
>
> ===BeAny================================= <<<< MIPv6 Binding
> Error message.
> ng compare ext_BE_any.Checksum received:27700 = 27567 <<<< The field
> with difference value.
> They are
> those with difference to the value of a checksum.
> -----------------------------------------------
>
>
> Best Regards
> --
> Kiyoaki Kawaguchi
>
>
>
> ""Leino, Tammy" <tammy_leino@mentor.com>" wrote:
>
> > This is a multi-part message in MIME format.
> >
> >
> > Hello Kiyoaki,
> >
> > I greatly appreciate your advice and offer to lend assistance. I have
> > scrutinized the log and output, but I cannot find any error in my BE
> > packet.
> >
> > I have attached the output results of the first test in CN-1-1.
> Please
> > refer to the BE packet that is being rejected.
> >
> > Thank you again for your offer to assist.
> >
> > Best Regards,
> > Tammy Leino
> >
> >
> > -----Original Message-----
> > From: K.Kawaguchi [mailto:kawaguti@ysknet.co.jp]
> > Sent: Thursday, June 05, 2008 4:08 AM
> > To: users@tahi.org; Leino, Tammy
> > Subject: Re: [users:00742] MIPv6 Conformance Test Suite CN-1-1
> >
> >
> > Hello,
> >
> > It seems that there is a some difference compared with BE
> > message which the tester expected so that you may guess.
> >
> > Please see log of the test result in a test tool. A difference
> > may be able to be found in the part which shows outputted BE
> > packet with logic structure.
> > Please send log file to me, if the view of log is not known.
> >
> >
> > Best Regards
> > --
> > Kiyoaki Kawaguchi
> >
> >
> >
> > ""Leino, Tammy" <tammy_leino@mentor.com>" wrote:
> >
> > > This is a multi-part message in MIME format.
> > >
> > >
> > > Hello,
> > >
> > > I am executing the correspondent node test #1; CN-1-1. I have IPsec
>
> > disabled. My tn.def, nut.def and config.txt files are configured
> > properly.
> > When TN sends the echo request with a Home Address option (action #3
> in
> > the
> > test procedure), my NUT responds with a BE message matching the three
> > criteria
> > outlined in the JUDGEMENT for *2 of the test:
> > >
> > > (*2) MN receives Binding Error.
> > > - The Destination Address is set to the Source Address of ICMP
> Echo
> > Request (MN care-of address).
> > > - The Status field is set to 1.
> > > - The Home Address field is set to the value in the Home Address
> > option in
> > the ICMP Echo Request (MN home address).
> > >
> > > However, TAHI reports the following error and aborts the test:
> > >
> > > CNT_SendAndRecv Status =UnKnown
> > > UnKnown Pkt=>HASH(0x82b75c8)
> > > BE - Receive Unexpented Packet
> > > -> FAIL
> > >
> > > I cannot tell what is wrong with my BE message. I viewed it in
> > Wireshark,
> > and it is formed properly. Wireshark is able to parse it and
> recognizes
> > it as
> > a BE, and I verified that all the requirements of JUDGEMENT *2 are
> met.
> > >
> > > Can anyone shed light on this error? Perhaps a checksum error?
> This
> > same
> > error occurs for all tests that require a BE to be transmitted to the
> > TN.
> > >
> > > Thank you for any assistance you can lend.
> > >
> > > Best Regards,
> > > Tammy Leino
> > >
> > >
> > >
> > >
> > >
> >
> >
> >
> >
>
>
>
>