Subject: [BEHAVE] AD evaluation of draft-ietf-behave-v6v4-xlate-11

From: Magnus Westerlund <[email-masked]>
Date: Sat, 20 Mar 2010 08:05:50 -0700

Authors and WG,

As one of my last acts as AD I have performed an AD review of the
translator documents. As you have seen David is also reviewing the
documents in parallel as preparations for taking over the handling of
these documents. I am very pleased that the WG has managed to progress
these documents without to much delay.

See below my AD comments and questions from this review. As usual please
discuss things with me as it is as likely that I have misunderstood as
there are issues with the document. I also have to state that I have
failed to keep abreast on all the postings on the mailing list.

I do hope that these comments can be addressed quickly and if anyone
needs more discussion that we can identified that prior the IETF week is
over and take it in the BEHAVE session. However, please submit a new
draft as soon as you are able to. It is possible to submit new versions
from Monday of the IETF week.

1. Section 1,
It is directly derivative from
   Erik Nordmark's [RFC2765], which provides stateless translation
   between IPv4 [RFC0791] and IPv6 [RFC2460], and between ICMPv4
   [RFC0792] and ICMPv6 [RFC4443].

Can you please include the title of RFC 2765 after Nordmark's?

2. section 1.3,
In the stateful mode, a specific IPv6 address range will represent
   IPv4 systems (IPv4-converted addresses), but the IPv6 systems may use
   any [RFC4291] addresses except in that range.

Shouldn't there be an IPv6 before the RFC 4291 reference?

3. Section 3,

I wonder if the motivation for the required fragmentation in v4->v6
direction of packet larger 1280 that doesn't have the DF bit set should
be motivated. To my understanding it is because we can't make any thing
smarter that will work without needing to keep track of per flow
destination state.

4. Section 3.5:
If the address translation algorithm is not checksum neutral, the
   recalculation and updating of the transport-layer headers MUST be
   performed.

The above assumes that there is a pseudo header included in the
checksum. For SCTP that isn't true.

5. Section 4:
Since the ICMPv6 [RFC4443], TCP [RFC0793], and UDP [RFC0768] headers
   contain checksums that cover the IP header, if the address mapping
   algorithm is not checksum-neutral, the ICMP and transport-layer
   headers MUST be updated.

Could we include DCCP in the list above?

6. Question related to section 3. Is it assumed that the IPv4 header
checksum is checked upon reception of a IPv4 packet to be translated?
Does this assumption need to be stated explicitly?

7. Section 4.1:
   Identification:  If the packet size is equal to or smaller than 1280
      bytes, generate the identification value.  If the packet size is
      greater than 1280 bytes, set Identification All zeros.

First, is it really smart to set the ID field to all 0? It will have
impact on for example header compression. Especially as the translator
will need to have functionality to generate IDs anyway.

Secondly, do we need to make recommendations on generation of IDs? It
appears that a single counter for all outgoing IPv4 flows from the
translator are likely to wrap very quickly. Thus this might actually
require to have destination specific state.

I think we at least should make one change to the above sentence.
If the packet size is
      greater than 1280 bytes, may set Identification All zeros.

That way it becomes at least an implementation choice if to set it to 0
or not.

8. Section 4.1, Next header field:
I think this spec needs to be clearer on that you need to extract the
right next header field part of the chain. If I look at IPv6 spec it has
the following order.

           IPv6 header
           Hop-by-Hop Options header
           Destination Options header (note 1)
           Routing header
           Fragment header
           Authentication header (note 2)
           Encapsulating Security Payload header (note 2)
           Destination Options header (note 3)
           upper-layer header

Which prevents it from being as simple as saying as the first which
isn't a IPv6 extension header. So process chain until ESP is found is
clearly one rule. However, what will happen at the destination if there
is a Destination Options header inside the ESP?

Can someone that knows this better try to find some text that makes this
clearer?

9. Section 4.1, fragmentation header part, protocol:
Also here I think there needs to be some adjustment of the text on how
to fill in the protocol header.

10. Section 4.5:
I wonder if AH should be included in this section in the previous
section when extension headers are disacussed. But I think making it
clear there that if AH is included one should do X.

11. Section 8, figure 8. Is it intentional that the lines inside the
network boxes and outside doesn't align?

12. Section 8.2, bullet 3:
   3.  The packet is routed to the IPv6 interface of the XLATE (since
       IPv6 routing is configured that way)

I believe the IPv6 in the above sentences are supposed to be IPv4.

13. Section 9.2:

I think the following references are actually normative ones:
   [I-D.ietf-behave-address-format]
   [I-D.ietf-behave-v6v4-xlate-stateful]

14. Section 9.2:
RFC 3171 has been obsoleted by RFC 5771

Cheers

Magnus Westerlund

IETF Transport Area Director
----------------------------------------------------------------------
Multimedia Technologies, Ericsson Research EAB/TVM
----------------------------------------------------------------------
Ericsson AB                | Phone  +46 10 7148287
Färögatan 6                | Mobile +46 73 0949079
SE-164 80 Stockholm, Sweden| mailto: [email-masked]
----------------------------------------------------------------------

---

From: Magnus Westerlund <[email-masked]>
Date: Tue, 23 Mar 2010 09:54:41 -0700

Hi,

Thanks for the updated document. It resolves most of the issues.
However, there are a few things I would like to discuss a bit more.

> That way it becomes at least an implementation choice if to set it to 0

Thanks for making it clear that you don't must set it to 0. However, I
would like to get some feedback on the above question regarding
recommendations for generating the IP ID field.

> Can someone that knows this better try to find some text that makes this

I think the update was a step in the right direction. However, I still
feel a bit uncomfortable that we don't consider ESP specifically.
Because with the updated text you could interpret this as you should dig
into the ESP payload which clearly is impossible.

> clear there that if AH is included one should do X.

Sorry, I don't understand how Section 4.1 resolves this. Can you please
clarify that?

Cheers

Magnus Westerlund

---

From: Xing Li <[email-masked]>
Date: Thu, 25 Mar 2010 01:58:49 +0800

Hi, Magnus,

> However, there are a few things I would like to discuss a bit more.

Thank you very much! The answers and discussions are inline.
> recommendations for generating the IP ID field.

Agree. We can get comments from the experts in the mailing list.
> into the ESP payload which clearly is impossible.

Agree. How about we explicitly say it in

1.2.  Applicability and Limitations

   As with [RFC2765], the translating function specified in this
   document does not translate any IPv4 options and it does not
   translate IPv6 routing headers, hop-by-hop extension headers,
   destination options headers, source routing headers, 
   authentication header (AH) and 
   encapsulating security payload (ESP) headers. For  
   IPv6 packets contains ESP header, they MUST be dropped by the 
   translator, since it is impossible to dig into the ESP 
   payloads to get transport layer parameters.

> Sorry, I don't understand how Section 4.1 resolves this. Can you please

Oh, in the previous reply, we mean skip the Authentication Header and 
then there will be no
additional functions required in Section 4.5. However, we may add some 
discussion in
Section 4.5 concerning AH. The question is that do we really need to map 
AH field from IPv6
packets to IPv4 packets in the IPv4/IPv6 translator?

We will wait for your comments and upload a new version of xlate 
reflecting these issues.

Regards,

xing, congxiao

---

From: Magnus Westerlund <[email-masked]>
Date: Wed, 24 Mar 2010 17:25:15 -0700

> Agree. We can get comments from the experts in the mailing list.

Yes I definitely would like to get feedback on this question from the
participants in the WG.

>    payloads to get transport layer parameters.

For the stateless mode it would be good if ESP continued to work. Thus I
would be hesitant to simply drop ESP. As I see it there could be some
surprise for a v4 client if it receives a destination header inside the
ESP payload. However, I think the usage of destination headers are not
that common. Thus I am actually quite hesitant to simply drop ESP and
rather surprise the v4 side in case there is a v6 destination header.

I think the text regarding the next header field need to become clearer.
The current is:

Protocol:  For ICMPv6 (58) changed to ICMPv4 (1), otherwise skip
      extension headers, Next Header field copied from the last IPv6
      header.

"last IPv6 header" appears to be either ESP or the Upper layer protocol.

> packets to IPv4 packets in the IPv4/IPv6 translator?

After thinking on it I don't think Section 4.5 is the right place to
specify that if an AH header is found, the translation is stopped and
the packet discarded. But I think it needs to be specified somewhere.
Currently the document only talks about these in the security section.

As I think this applies to both directions I am not certain where it
should be created. Do the authors have a suggestion?

Cheers

Magnus Westerlund