Subject: [BEHAVE] Translating pointer in Parameter Problem (draft-ietf-behave-v6v4-xlate)

From: Kentaro Ebisawa <[email-masked]>
Date: Thu, 17 Dec 2009 12:00:23 +0900

Hi,

In the yesterday's interim conf call, there was comment that we should
add more guidance to how to translate the pointer. I've classified to
5 classes (A~E) when translating a pointer so it would be eaiser to
think through.

# Summarized list of pointer value and classes are at the tail of this e-mail.

BTW, my assumption is we will drop if the pointer is pointing to Options
(IPv4:20+) or Extention headers(IPv6:40+) since we are not going to
translate them and thus no way to translate the pointer.0 (For Fragment
Header, I explicitly classified this to case E since it has field in
IPv4 header.)

/// Classification and my comments to how to handle them ///

A. There is one-to-one mapping and can be translated with no ambiguity.
B. The translated field is spread among multiple octets.
   We can translate but need to define which octet to use.
C. Multiple fiels are included in the octet original pointer is pointing
   to, and can not distinguish which field it's pointing to.
   We can NOT translate unless we are aware of which value normally used
   in current (and future) implementations.
D. There is no corresponding filed in the translated protocol(IPv4/IPv6)
E. Pointer is pointing to fragment related header (IPv4) or Fragment
   Extention Header(IPv6).

For A and D, it's simple. We can translate(A) or drop(D) based on the
chart below.

For B, only IPv4->IPv6 Type Of Service->Traffic Class is classified to
this. We can either drop it, or decide to use 0 or 1.
Maybe we can use 0 since if we have any problem in version field, we
wouldn't have sent the packet triggering this ICMP message anyway.

For C, there are 3 cases. 1 for IPv4->IPv6 and 2 for IPv6->IPv4.
 C-1. v4->v6 : pointer=0, Version/IHL
 C-2. v6->v4 : pointer=0, Version/Traffic Class
 C-3. v6->v4 : pointer=1, Traffic Class/Flow Label

 For C-1, I think we can drop this. We wouldn't have sent the packet
 triggering this ICMP message if the version field had problem, and
 there is no corresponding field for IHL in v6.

 For C-2, we can either drop this or translate to 1 (Type of Service),
 assuming we won't send original packet with incorrect Version.
 But I would preffer dropping this to avoid sending fales alert.

 For C-3, I think we should drop it since there are no way to distinguish
 if the sender wanted to point to Traffic Class or Flow lable.

For E, we can add Fragment Header and point to it (v4->v6). Also, we
can parse the Extention header and if it was Fragment header, we can
point to corresponding Fragment related field (v6->v4).
But if we try to translate, we will need to think about the case don't
fragment bit is set since we can not insert Fragment Header in such
case.
So perfer simply dropping this but would like to hear more comments.

/// Summarized list of pointer value and classes ///
* Translating from IPv4 to IPv6:

 |   Original IPv4 Pointer     |   | Translated IPv6 Pointer Vaule  |
 +-----------------------------+   +--------------------------------+
 |  0  | Version/IHL           | C |  0  | Version/Traffic Class    |
 |  1  | Type Of Service       | B | 0or1| Traffic Class/Flow Label |
 | 2,3 | Total Length          | A | 4,5 | Payload Length           |
 | 4,5 | Identification        | E |  -  |                          |
 |  6  | Flags/Fragment Offset | E |  -  |                          |
 |  7  | Fragment Offset       | E |  -  |                          |
 |  8  | Time to Live          | A |  7  | Hop Limit                |
 |  9  | Protocol              | A |  6  | Next Header              |
 |10,11| Header Checksum       | D |  -  |                          |
 |12-15| Source Address        | A | 8-23| Source Address           |
 |16-19| Destination Address   | A |24-39| Destination Address      |
 +-----------------------------+   +--------------------------------+

* Translating from IPv6 to IPv4:

 |   Original IPv6 Pointer        |   | Translated IPv4 Pointer Vaule |
 +--------------------------------+   +-------------------------------+
 |  0  | Version/Traffic Class    | C | 0or1| Version/IHL, Type Of Ser|
 |  1  | Traffic Class/Flow Label | C |  1  | Type Of Service         |
 | 2,3 | Flow Label               | D |  -  |                         |
 | 4,5 | Payload Length           | A | 2,3 | Total Length            |
 |  6  | Next Header              | A |  9  | Protocol                |
 |  7  | Hop Limit                | A |  8  | Time to Live            |
 | 8-23| Source Address           | A |12-15| Source Address          |
 |24-39| Destination Address      | A |16-19| Destination Address     |
 +--------------------------------+   +-------------------------------+

/// FYI: pointer value and header field included in the octet ///

 |        IPv4 Pointer         |  |     IPv6 Pointer               |
 +-----------------------------+  +--------------------------------+
 |  0  | Version/IHL           |  |  0  | Version/Traffic Class    |
 |  1  | Type Of Service       |  |  1  | Traffic Class/Flow Label |
 |     |                       |  | 2,3 | Flow Label               |
 | 2,3 | Total Length          |  | 4,5 | Payload Length           |
 | 4,5 | Identification        |  |  -  |                          |
 |  6  | Flags/Fragment Offset |  |  -  |                          |
 |  7  | Fragment Offset       |  |  -  |                          |
 |  8  | Time to Live          |  |  7  | Hop Limit                |
 |  9  | Protocol              |  |  6  | Next Header              |
 |10,11| Header Checksum       |  |  -  |                          |
 |12-15| Source Address        |  | 8-23| Source Address           |
 |16-19| Destination Address   |  |24-39| Destination Address      |
 | 20+ | Options               |  | 40+ | extension header         |
 +-----------------------------+  +--------------------------------+

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

---

From: Simon Perreault <[email-masked]>
Date: Thu, 17 Dec 2009 08:45:19 -0500

First, thank you for this excellent analysis. This is exactly what I had
in mind. If this text is adopted it will fulfill all my needs.

> wouldn't have sent the packet triggering this ICMP message anyway.

I think it should be 1, for two reasons:

- The fact that it would be the same as IPv4 would make it a little bit
more likely that it would also be interpreted in the same way.

- If there was a problem with the flow label the value would be 3 instead.

>  there is no corresponding field for IHL in v6.

Agreed.

>  But I would preffer dropping this to avoid sending fales alert.

Agreed.

>  if the sender wanted to point to Traffic Class or Flow lable.

Disagree. I think 1 clearly means traffic class. (Who/what is the
authority on this?)

> So perfer simply dropping this but would like to hear more comments.

Well, the point is that the fragmentation parameters on each side are
likely to be very different. So an ICMP received on either side wouldn't
really apply on the other. Therefore, I would also like to drop this.

There are two other cases which I think also need to be considered:

F. The pointer points inside the payload to a parameter which the
translator changes (e.g. UDP source port).

G. The pointer points inside the payload to something the translator
doesn't change (e.g. UDP data).

In F, the ICMP is of interest to the translator, not the originator of
the packet. So besides using the information usefully if it can, the
translator should drop the packet.

In G, we can forward after offsetting the pointer so that it points at
the same data after translation.

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

---

From: Kentaro Ebisawa <[email-masked]>
Date: Fri, 18 Dec 2009 15:17:39 +0900

Hi,

Thanks for the comments.
I agree with your comments on additional cases, F and G.

> - If there was a problem with the flow label the value would be 3 instead.

Here are the first 4 octets of IPv6 Header From RFC2460 "3.IPv6 Header Format".

    0               1               2               3
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |Version| Traffic Class |           Flow Label                  |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

In octet "1", the latter 4 bits of Traffic Class and the first 4 bits
of Flow Lable is included.  The definition of the pointer per RFC792
is  "identifies the octet where an error was detected." and doesn't
mention it MUST or SHOULD be an octet including first bit nor last
bit of the field.

Thus, unless documented in other RFC etc. which I missed, it's
implementer's choice to use 1, 2 or 3 for the Flow Label.

Do you know how current implementations actually select pointer value ?
I briefly looked into Linux code but could not find a code where
it's sending Parameter problem for Header field. (I could only find
for options field)

> >  C-3. v6->v4 : pointer=1, Traffic Class/Flow Label
...
> Disagree. I think 1 clearly means traffic class. (Who/what is the

As said above, I am not aware of any documents discussing or defining
about relationship between pointer value and header field, and thus
thinking it was not defined anywhere and it's up to implementers to
select 0 or 1 for IPv6 Traffic Class.

I'm also wondering who/what is the authority on this. So would be very
helpfull if anyone can let us know pointer to any documents or discussions.

Thanks,

On Thu, 17 Dec 2009 08:45:19 -0500

---

From: Xing Li <[email-masked]>
Date: Sat, 19 Dec 2009 08:56:17 +0800

Hi, Kentaro,

Thank you very much for the analysis concerning the ICMP Pointer. We 
have add them in the new version (05) of the xlate draft. Please see the 
document at
http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-05 and the diff 
at http://tools.ietf.org/rfcdiff?url2=draft-ietf-behave-v6v4-xlate-05.txt

Please check if they are reflecting your comments.

Regards,

xing

---

From: Xing Li <[email-masked]>
Date: Sat, 19 Dec 2009 09:06:20 +0800

Hi, Kentaro and Simon,

Thanks for the discussion. Since the xlate draft is in WGLC, we cannot 
update it during this time slot. Let's wait for the working group's 
comments, so we can update the appendix later.

     |   Original IPv4 Pointer        | Translated IPv6 Pointer Vaule  |
     +--------------------------------+--------------------------------+
     |  0  | Version/IHL              |  0  | Version/Traffic Class    |
     |  1  | Type Of Service          | 0or1| Traffic Class/Flow Label |
     | 2,3 | Total Length             | 4,5 | Payload Length           |
     | 4,5 | Identification           |  -  |                          |
     |  6  | Flags/Fragment Offset    |  -  |                          |
     |  7  | Fragment Offset          |  -  |                          |
     |  8  | Time to Live             |  7  | Hop Limit                |
     |  9  | Protocol                 |  6  | Next Header              |
     |10,11| Header Checksum          |  -  |                          |
     |12-15| Source Address           | 8-23| Source Address           |
     |16-19| Destination Address      |24-39| Destination Address      |
     +--------------------------------+--------------------------------+

     |   Original IPv6 Pointer        | Translated IPv4 Pointer Vaule  |
     +--------------------------------+--------------------------------+
     |  0  | Version/Traffic Class    | 0or1| Version/IHL, Type Of Ser |
     |  1  | Traffic Class/Flow Label |  1  | Type Of Service          |
     | 2,3 | Flow Label               |  -  |                          |
     | 4,5 | Payload Length           | 2,3 | Total Length             |
     |  6  | Next Header              |  9  | Protocol                 |
     |  7  | Hop Limit                |  8  | Time to Live             |
     | 8-23| Source Address           |12-15| Source Address           |
     |24-39| Destination Address      |16-19| Destination Address      |
     +--------------------------------+--------------------------------+

                                 Figure 6

regards,

xing