Subject: [MEXT] [RFC3775 changes] MH checksum calculation

From: Vijay Devarapalli <[email-masked]>
Date: Thu, 20 Mar 2008 10:26:46 -0700

Hello,

There is a bug in the checksum calculation for the mobility header.
The "Next Header" value in the pseudo-header should say '135' since
the mobility header protocol number is '135'. It says '2' instead.
This needs to be fixed.

OLD:

       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.

NEW:

       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 135.  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.

Vijay

_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Suresh Krishnan <[email-masked]>
Date: Mon, 24 Mar 2008 17:42:26 -0400

Hi Vijay,
   I really don't think this needs fixing at all. Everything works fine 
with any number in the next header (including 2 :-)) as long as the 
sender and receiver use the same number. If we fix this, an upgraded 
receiver will fail to verify a packet from a legacy sender and vice 
versa. Do you agree?

Cheers
Suresh

---

From: Hesham Soliman <[email-masked]>
Date: Tue, 25 Mar 2008 08:44:45 +1100

I agree, this is one of those bugs that need to stay in order to  
maintain backward compatibility.

Hesham

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 24 Mar 2008 14:54:38 -0700

Many implementations (the ones I know at least) already use '135',
since it was considered a bug. Folks had posted emails on this to
the mailing list in the past and it was clarified that it should
have been 135. We also told them this would be fixed when 3775 is
revised. :)

Vijay

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Mar 2008 10:36:55 +0100

Suresh, Hesham, let me bite: are you guys kidding?  I hope so :-)

Alex

>>>       fields in the IPv6 packet carrying the Mobility Header.

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 25 Mar 2008 10:39:26 +0100

Suresh Krishnan wrote:
> Hi Vijay, I really don't think this needs fixing at all. Everything
> works fine with any number in the next header (including 2 :-)) as
> long as the sender and receiver use the same number. If we fix this,
> an upgraded receiver will fail to verify a packet from a legacy
> sender and vice versa. Do you agree?

Implementations I'm aware of already use 135 instead of 2.  When rfc3775
came out the bug was very quickly pointed (a matter of days).

A question can be made on whether this could go in an Errata rather than
in a 3775bis.  Errata is much quicker to do.

I agree changing it to 135.

Alex

> Cheers Suresh
>>  The "Next Header" value in the pseudo-header should say '135'
>> since the mobility header protocol number is '135'. It says '2'
>> instead. This needs to be fixed.
>> 
>> OLD:
>> 
>> _______________________________________________ MEXT mailing list 
>> [email-masked] https://www.ietf.org/mailman/listinfo/mext
> 
> _______________________________________________ MEXT mailing list 
> [email-masked] https://www.ietf.org/mailman/listinfo/mext
>

---

From: Suresh Krishnan <[email-masked]>
Date: Tue, 25 Mar 2008 11:10:11 -0400

Hi Alex,
   Unfortunately not :-(. I have a #define in my implementation that 
defines this number. I have it set to 135 (Note that I did not 
automatically set it to IPPROTO_MH) since mipl does so. I think more 
implementers should speak up. If nobody uses 2, it should be OK to change?

Cheers
Suresh

---

From: Tsuyoshi MOMOSE <[email-masked]>
Date: Wed, 26 Mar 2008 07:01:31 -1000

Hi Suresh,

For SHISA implementation as part of kame, it of course uses 135.  
Thorough several interoperability events I joined in the past, there  
are no problems regarding checksum issues with the value 135. The  
value must be changed to 135. Keeping the value as 2 may confuse new  
MIP6 implementors.

Thanks.

---
Tsuyoshi Momose

On 2008/03/25, at 5:10, Suresh Krishnan wrote:
>>>>> since