Subject: Re: [Mip4] FMIPv4

From: Rajeev Koodli <[email-masked]>
Date: Mon, 05 Feb 2007 11:32:21 -0800

Hi Alex,

>> > 5.3. Router Solicitation for Proxy Advertisement (RtSolPr)
> 
> Is this an RS carried as ICMP (RFC1256) or as ICMPv6.  Encoding is
> different.  Remark that existing implementations of ICMPv4 RS could be
> re-used for minimal modifications, or otherwise ICMPv6 could be re-used.
>   It's a choice.  But in a FMIPv4 deployment one wouldn't assume
> availability of ICMPv6... or maybe yes (?).  Also it's strange to use
> Checksum field as computed from rfc1256 but the format from ICMPv6.
> 
> Same for Proxy Router Advertisement.
> 
> 
> Rajeev:> I am coming back to this issue.
> 
> The RS in 1256 has the format (hope it shows up right, but you get the idea):
> 
> 0                          1                          2
> 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |     Type         |     Code         |             Checksum              |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> |                           Reserved
> |
> +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
> 
> 
> 
> There is no room for options as such. ICMPv6 format is almost similar, but the
> Reserved field is replaced by the Message Body field which allows room for
> options. 
> 
> The RtSolPr/PrRtAdv messages need to have options.
> 
> So, we need to use the base ICMPv6 format adapted for our purpose here (as was
> done in FMIPv6).
> So, the format looks like in Section 5.3.
> 
>    0                          1                          2
> 3
>    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |     Type         |     Code         |             Checksum              |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |   Subtype      |   Reserved     |          Identifier                   |
>   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>   |   Options ...
>   +-+-+-+-+-+-+-+-+-+-+-+-
> 
> 
> Now, the checksum calculation:
> For ICMPv4,
> 
> The  16-bit one's complement of the one's complement sum of the ICMP message,
> starting with the ICMP Type.  For computing the checksum, the Checksum field
> is set to 0.
> 
> For ICMPv6,
> 
> The checksum is the 16-bit one's complement of the one's complement
>    sum of the entire ICMPv6 message starting with the ICMPv6 message
>    type field, prepended with a "pseudo-header" of IPv6 header fields,
>    as specified in [IPv6, section 8.1].  The Next Header value used in
>    the pseudo-header is 58.  (NOTE: the inclusion of a pseudo-header in
>    the ICMPv6 checksum is a change from IPv4; see [IPv6] for the
>    rationale for this change.)
> 
> Except for the inclusion of the pseudo-header, the calculation is identical.
> 
> In our case, we have IPv4 header. Hence, the fmipv4 spec refers to 1256 for
> checksum calculation.
> 
> In summary, we need to use the expanded ICMPv6 format (which also allows
> re-use of FMIPv6 software), but use ICMPv4 checksum because we use IPv4
> headers for the RtsolPr/PrRtAdv messages.
> 
> Does this clarify?
> 
> -Rajeev
> 
> 
> 
> 

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 20:57:18 +0100

Rajeev Koodli wrote:
>     There is no room for options as such. ICMPv6 format is almost
>     similar, but the Reserved field is replaced by the Message Body
>     field which allows room for options.
> 
>     So, we need to use the base ICMPv6 format adapted for our purpose
>     here (as was done in FMIPv6).
>     The  16-bit one's complement of the one's complement sum of the ICMP
>     message, starting with the ICMP Type.  For computing the checksum,
>     the Checksum field is set to 0.
> 
>     For ICMPv6,
> 
>     In our case, we have IPv4 header. Hence, the fmipv4 spec refers to
>     1256 for checksum calculation.
> 
>     In summary, we need to use the expanded ICMPv6 format (which also
>     allows re-use of FMIPv6 software), but use ICMPv4 checksum because
>     we use IPv4 headers for the RtsolPr/PrRtAdv messages.
> 
>     Does this clarify?

Thanks for clarification on the motivation, I understand now why.

Do you basically propose an expansion to the existing ICMPv4 RA format? 
  Or a plain new ICMPv4 type message?

You've put Type to be assigned by IANA for PrRtAdv.  So I believe you 
propose a new ICMPv4 message. (otherwise you'd have put Type '9' RA)(?).

The Checksum computation you refer to rfc1256 is designed only for Type 
9 ICMPv4 messages, because they specify how the Checksum is computed at 
every RS, RA, etc.

So I guess it makes sense to request a IANA number for a new ICMPv4 
message and then put text in this draft that is exactly how to compute 
the checksum for this message.

What do you think?

Alex

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 05 Feb 2007 12:03:52 -0800

> propose a new ICMPv4 message. (otherwise you'd have put Type '9' RA)(?).

Yes, it is a new Type.

> the checksum for this message.

Sounds good. The checksum calculation is identical, except for the new Type.
So, if we put in text saying that calculation is the same as in rfc1256, but
with the new Type number, would that suffice for us here?

Thanks,

-Rajeev

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 05 Feb 2007 21:17:44 +0100

>> propose a new ICMPv4 message. (otherwise you'd have put Type '9' RA)(?).

So one may suggest explicitely to IANA that the type is to be assigned 
from the ICMPv4 Type space, and not from ICMPv6 Type space, which are 
different.  In the IANA Considerations section.

> with the new Type number, would that suffice for us here?

Yes.  When you say calculation is 'same as in rfc1256' then one may 
wonder 'which message of rfc1256 because each defines a checksum 
calculation'.  One may go finer grain and say that the Reserved field is 
set to 0 for checksum calculation (1256 doesn't say so).  That's why I 
was saying complete checksum text copypasting would be good.

Otherwise it's fine, thanks,

Alex