RE: [Ipsec] Interpretation of ICMP Type and Code

["Michael Roe" <mroe@microsoft.com>]

I had interpreted the text as meaning (b),
tstart*256+cstart <= t*256+c <= tend*256+cend
But as you say, it's not entirely clear.

I think it doesn't matter very much - either option would be OK.
Ideally, we ought to specify which it is, or we'll have
interoperability problems.

On the other hand, we really need to get IKEv2 finished soon, so I'm
not too keen on the idea of IKEv2 being delayed by this issue! 

The architecture document might be the right place for this. Not just
because I'd like to avoid delaying IKEv2, but also because this issue is
really about which selectors match which packets - and that seems to
belong in 2401bis.

Mike

> From: ipsec-admin@ietf.org [mailto:ipsec-admin@ietf.org] On 
> Behalf Of Charles Lynn
> Sent: 19 April 2004 16:25
> To: ipsec@ietf.org
>       For the
>       ICMP protocol, the two one octet fields Type and Code are
>       treated as a single 16 bit integer (with Type in the most
>       significant eight bits and Code in the least significant
>       eight bits) port number for the purposes of filtering based
>       on this field.
> 
> How are Type and Code to be treated by an implementation?
> I have not found a clear specification of the semantics.
> 
> Given a start Type of tstart and an end Type of tend,
>       a start Code of cstart and an end Code of cend, and
>       an ICMP packet with Type t and Code c:
> 
> Is the test that an implementation MUST make:
> 
> a)	(tstart <= t <= tend) AND (cstart <= c <= cend),
>  or
> b)	tstart*256+cstart <= t*256+c <= tend*256+cend
> 
> I think that either 2401bis or IKEv2 should state one of the above to
> make sure that all implementations interpret things the same way.

_______________________________________________
Ipsec mailing list
Ipsec@ietf.org
https://www1.ietf.org/mailman/listinfo/ipsec