Subject: [BEHAVE] Translating ICMPv6 Parameter Problem to IPv4

From: Simon Perreault <[email-masked]>
Date: Tue, 01 Dec 2009 17:04:23 -0500

Hello again,

In section 3.2 we have the following:

      Parameter Problem (Type 4)  If the Code is 1, translate this to an
         ICMPv4 protocol unreachable (Type 3, Code 2).  Otherwise set
         the Type to 12 and the Code to zero.  The Pointer needs to be
         updated to point to the corresponding field in the translated
         inner IP header.

Question: How is that pointer updating performed? Do I have to establish
correspondences between IPv6 and IPv4 fields? If so, shouldn't this be in the text?

Thanks,
Simon
-- 
DNS64 open-source   --> http://ecdysis.viagenie.ca
STUN/TURN server    --> http://numb.viagenie.ca
vCard 4.0           --> http://www.vcarddav.org

---

From: Xing Li <[email-masked]>
Date: Sun, 06 Dec 2009 21:40:07 +0800

> correspondences between IPv6 and IPv4 fields? If so, shouldn't this be in the text?

Pointer is used to Identify the octet offset within the invoking packet 
where the error was detected. Due to the different format of the 
Parameter Problem Message
between IPv6 and IPv4, the octet offset needs to be changed in order to 
point to the same position of the error.

Regards,

xing

---

From: Simon Perreault <[email-masked]>
Date: Sun, 06 Dec 2009 10:21:22 -0500

> point to the same position of the error.

Yes but the pointer points inside an IPv6 header before translation, and 
it points inside an IPv4 header after translation. There is more to it 
than just updating the offset. It's a completely different header and 
the fields don't have 1:1 mapping.

Simon

---

From: Xing Li <[email-masked]>
Date: Mon, 07 Dec 2009 18:27:37 +0800

Simon Perreault 写道:
> Yes but the pointer points inside an IPv6 header before translation, 
> and it points inside an IPv4 header after translation. There is more 
> to it than just updating the offset. It's a completely different 
> header and the fields don't have 1:1 mapping.

In the current draft, this is discussed in ICMP Error Payload section. 
It reads, if the received ICMPv6 packet contains an ICMP Extension 
[RFC4884], the translation of the ICMPv6 packet will cause the ICMPv6 
packet to change length. For extensions not defined in RFC4884, the 
translator passes the extensions as opaque bit strings and those 
containing IPv6 address literals will not have those addresses 
translated to IPv4 address literals; this is likely to cause problems 
with processing of those ICMP extensions.

So for anything defined in RFC4884, converting the addresses, otherwise 
passing the strings. The pointer is updated based on this rule.

Regards,

xing

---

From: Simon Perreault <[email-masked]>
Date: Mon, 07 Dec 2009 07:59:58 -0500

Xing Li wrote, on 2009-12-07 05:27:
> packet to change length.

This is not what I mean. I will try again.

Suppose I have an ICMPv6 with type 4, code 0, and pointer value 3. This would
mean that there is a problem with the Flow Label field in the IPv6 header. To
translate to IPv4 I can't just offset the pointer: the Flow Label field doesn't
exist in IPv4.

Another example: suppose the pointer value is 7, which points to the Hop Limit
field. This corresponds to the TTL field in IPv4 (if this is true, it would need
to be in the text). But since the fields are not at the same place in the
header, we need to adjust the pointer by more than just an offset based on the
header length.

Third example: suppose the pointer points beyond the IP header, into the
transport header. This would be easy for TCP and UDP: just offset the pointer
based on the header length. But suppose also that the transport protocol is
ICMPv6. This is going to be translated to ICMPv4, and we have the same problems
as above because there is no 1:1 mapping between the two.

I suggest that we do not attempt to translate the pointer, for two reasons:
  - There is no 1:1 mapping between IPv4 and IPv6 parameters.
  - The error would often be of interest only to the translator, since it would
be the one having generated the erroneous parameter.

Therefore, I suggest to change the text to this:

      Parameter Problem (Type 4)  If the Code is 1, translate this to an
         ICMPv4 protocol unreachable (Type 3, Code 2).  Otherwise, silently
         drop.

And in section 2.3:

         Parameter Problem (Type 12)  Silently drop.

Simon

---

From: Xing Li <[email-masked]>
Date: Wed, 09 Dec 2009 21:27:25 +0800

>          Parameter Problem (Type 12)  Silently drop.

Got the idea, thanks. So the question for the mailing-list is:

For the ICMP/ICMPv6 error packets with the type "Parameter Problem", if 
there is a one-to-one relationship (defined in the xlate document) 
between IPv4 and IPv6 headers of the invoking packet where the error was 
detected, the translator should translate the packets from one address 
family to the other address family. Otherwise,

Option 1:
The translator passes the invoking packet where the error was detected 
as opaque bit strings; this is likely to cause problems with processing 
of those ICMPv6/ICMP Error messages.

Option 2:
The translator silently drops the ICMP/ICMPv6 Error messages.

Which option should we choose? Please comment.

Regards,

xing, congxiao

---

From: Simon Perreault <[email-masked]>
Date: Wed, 09 Dec 2009 08:58:58 -0500

> there is a one-to-one relationship (defined in the xlate document)

Do you mean that it is already defined, or that it will eventually be defined?

Because I don't see it in the draft right now.

> Which option should we choose? Please comment.

My opinion: Option 2. Doing otherwise would be useless.

Simon

---

From: Xing Li <[email-masked]>
Date: Mon, 14 Dec 2009 22:29:56 +0800

> Because I don't see it in the draft right now.

We mean:

For the ICMP/ICMPv6 error packets with the type "Parameter Problem", if 
there is a one-to-one relationship (defined in the sections 2.1 and 3.1 
in the xlate document) between IPv4 and IPv6 headers of the invoking 
packet where the error was detected, the translator should translate the 
packets from one address family to the other address family.

> My opinion: Option 2. Doing otherwise would be useless.

Got the idea.

xing

---

From: Kentaro Ebisawa <[email-masked]>
Date: Wed, 16 Dec 2009 02:30:28 +0900

Hi,

> packets from one address family to the other address family.

I basically agree on above, but I think there are some cases which
translated pointer value is identical from the type/code of the original
message. Also, there are some cases which we can drop the packet before
trying to translate the pointer.

I think above cases would be better to be clearly defined in the xlate
document to minimize ambiguity.

Here are the 6 cases which pointer field needs to be updated for both
[ICMPv4 -> ICMPv6] and [ICMPv6 -> ICMPv4] cases.

[ICMPv4 -> ICMPv6]

1. protocol unreachable (3,2)
 | Translate to Type 4, Code 1 (ICMPv6 Parameter Problem) and
 | make the Pointer to point to the IPv6 Next Header field
This is clearly defined. Keep it as is.

For ICMPv4 Parameter Problem, Code is not defined as I mentioned in
another thread.
 | Parameter Problem (Type 12)  Set the Type field to 4.  The
 |   Pointer needs to be updated to point to the corresponding
 |   field in the translated include IP header.

So I think we can translate each code like below.

2. Pointer indicates the error (12,0)
We can translate to ICMPv6 Type 4 Code 0 (Erroneous header field
encountered) and update the pointer as defined in sections 2.1
and 3.1 in the xlate document.

3. Missing a Required Option (12,1)
Do we have ICMPv6 Type Code corresponding to this ?
If not, and if the case mentioned in RFC1108 2.8.1. is the only case
this message is used, then I think we can drop this since we can not
translate the "Option" anyway and thus don't have pointer value to
be translated.

Or should we leave this open to implementers ??

4. Bad Length (12,2)
I'm assuming the "Length" is "Total Length" and not IHL since we will
have either malformed Options or payload if IHL was incorrect. In that
case, I think we can translate this to Type 4, Code 0 and set pointer
to 4 (IPv6 Payload Length) which corresponds to text like below :

 >  Translate to Type 4, Code 1 (ICMPv6 Parameter Problem) and
 >  make the Pointer to point to the IPv6 Payload Length field

[ICMPv6 -> ICMPv4]
Parameter Problem (Type 4), code 0,2 is the only case we need to
update pointer for ICMPv6 to ICMPv4 translation.
 | Parameter Problem (Type 4)  If the Code is 1, translate this to an
 |    ICMPv4 protocol unreachable (Type 3, Code 2).  Otherwise set
 |    the Type to 12 and the Code to zero.  The Pointer needs to be
 |    updated to point to the corresponding field in the translated
 |    inner IP header.

5. Erroneous header field encountered (4,0)
I think we can translate to ICMPv4 Type 12, Code 0 and update the
pointer as defined in sections 2.1 and 3.1 in the xlate document,
as in the original text.

6. Unrecognized IPv6 option encountered (4,2)
Since it is "Unrecognized" IPv6 option, I don't think we can translate
the option to IPv4 and thus we can not translate the pointer value.
If we are going to drop packets whoes pointer value could not be
translated, then we would be always dropping this packet.

So if I'm not missing something, I think we should replace the text
to drop the packet.

Regards,
-- 
Kentaro Ebisawa <[email-masked]>

On Mon, 14 Dec 2009 22:29:56 +0800
Xing Li <[email-masked]> wrote:

> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave

---

From: Xing Li <[email-masked]>
Date: Wed, 16 Dec 2009 15:40:51 +0800

Kentaro Ebisawa 写道:

Thanks. Will ask the group for the consensus. xing