Subject: [Softwires] Double stateless NAT64 and checksum recalculation

From: Nejc Škoberne <[email-masked]>
Date: Tue, 23 Aug 2011 16:43:37 +0100

Dear authors,

In I-D.dec-stateless-4v6-02 there is a table on page 11, which says that
IPv4 Header Checksum needs to be recalculated in stateless translation
IPv4 address sharing solutions. Does this mean that _only_ the IPv4 header
checksum should be recalculated?

This is how I see it:

Practically, the answer could maybe be yes. In each traversal of a packet through
double stateless translation, there could be just one IPv4 header recalculation,
always in the second translation process, where the IPv4 header is put back
on.

However, RFC 6145 says:

   The original IPv4 header on the
   packet is removed and replaced by an IPv6 header, and the transport
   checksum is updated as needed, if that transport is supported by the
   translator.

This means, since the I-D.dec-stateless-4v6-02 (and the same goes for
I-D.xli-behave-divi-03, of course) refers to RFC 6145, that transport-layer
checksum recalculation should also be performed. Which causes a significant
performance impact (we need to include whole packets including packets to
do checksum recalculation). So in this case, we would have 1 IPv4 checksum
recalculation and 2 TCP/UDP checksum recalculations for every packet
traversal through the mechanism.

But since we know, that these packets will be translated two times in a row,
we could just avoid the TCP/UDP recalculation, I guess? Would this work?

I guess that devices in between the CPE and AFTR then shouldn't do any
transport-layer processing, since this would probably be fatal for such
"invalid" packets. So having any IDS/IPS/stateful firewall devices in the
access network would cause issues?

However, if this is not possible, then I think that I-D.dec-stateless-4v6-02
should also state that UDP/TCP Header Checksum recalculation has to be
performed.

Thanks,
Nejc

---

From: Simon Perreault <[email-masked]>
Date: Tue, 23 Aug 2011 13:02:06 -0400

> we could just avoid the TCP/UDP recalculation, I guess? Would this work?

Yes, we've been discussing this internally among co-authors of
draft-despres-softwire-4rd-addmapping. The conclusion was that the transport
checksum does not need to be modified. A consequence is that the 4rd address
scheme does not need to care about checksum neutrality (contrary to e.g. NAT64
and NAT66).

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Nejc Škoberne <[email-masked]>
Date: Wed, 24 Aug 2011 00:00:32 +0100

Dear Simon,

> checksum does not need to be modified. 

OK. But this then means, that if there are any stateful devices like stateful
firewalls, IPS/IDS systems in between, we could have problems, right?

> A consequence is that the 4rd address

Sorry, but I don't understand this. Can you please paraphrase?

Thanks,
Nejc

---

From: Simon Perreault <[email-masked]>
Date: Tue, 23 Aug 2011 19:06:35 -0400

> firewalls, IPS/IDS systems in between, we could have problems, right?

Right. This would need to be mentioned as well.

> Sorry, but I don't understand this. Can you please paraphrase?

Please refer to:
http://tools.ietf.org/html/rfc6052#section-4.1
http://tools.ietf.org/html/rfc6296#section-2.6

Simon

---

From: Xing Li <[email-masked]>
Date: Wed, 24 Aug 2011 11:02:00 +0800

> checksum should be recalculated?

When we develop and deploy dIVI, for the 1st and 2nd IPv4/IPv6 
translators, we recalculte the transport layer checksum, as stated in 
RFC6145.

(1) In the IPv4/IPv6 translator, the transport layer checksum MUST be 
recalculated during the translation process (exception is using checksum 
neutral address) in order to generate legal IPv6 packets.
(2) The transport layer checksum calculation is acceptable even for the 
performance considerations (compare with LSN, CGN).
(3) Dual translation and single translation can be mixed in some 
deployment scenarios, so the IPv6 packets must contain the right 
transport layer checksum.

Regards,

xing

---

From: Nejc Škoberne <[email-masked]>
Date: Wed, 24 Aug 2011 10:29:34 +0100

Dear Wentao,

> If translator does not touch the TCP/UDP header, yes.
> However, if translator wants to do NAPT, which is not uncommon, then
> at least one recal. is needed (i.e. before the packet is finally
> handed to the receiver).

The idea is, that the NAPT44 is done before the first stateless NAT64
process, so this is a completely separate issue. Of course, recalculation
is mandatory in the NAPT44 part. I am just discussing the stateless
NAT64 part.

> Agree. I think transmitting packets with invalid TCP checksum field is
> dangerous.
> Stateful NAT is ubiquitous nowadays.

Simon? How was the conclusion, "that the transport checksum does not 
need to be modified", reached?

> Besides, the purpose of checksum is to do error checking. So sending
> packets with wrong checksum does not make sense. (How could the
> translator itself checks the integrity of the packet, if it wants to?)

Good point. Anyone?

Thanks,
Nejc

---

From: Nejc Škoberne <[email-masked]>
Date: Wed, 24 Aug 2011 11:21:58 +0100

Dear Simon,

> http://tools.ietf.org/html/rfc6296#section-2.6

Please correct me if I am wrong:

- The RFC 6145-compliant stateless NAT64 solutions do not have to 
  recalculate transport-layer checksums if and only if the Well-Known
  Prefix or a checksum-neutral Network-Specific Prefix is used and
  if the suffix is 0.

- All double stateless NAT64 solutions (dIVI, 4via6-T), since they
  can not have checksum-neutral IPv6 addresses (because they also
  encode port-set ID) MUST recalculate transport-layer checksums or
  else they are not RFC 6145-compliant.

So are you saying, that it is OK if we choose to not recalculate
checksums (and therefore violate RFC 6145) in
case we are sure, that there will be no transport-layer processing
between the CPE and AFTR in double stateless NAT64 scenarios?

Thanks,
Nejc

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Aug 2011 08:37:33 -0400

> need to be modified", reached?

Look, this is a deployment issue. It is simple.

X ----> NAT64 --------> NAT46 ----> Y

(Assume NAT46 is the exact reverse of NAT64.)

There are two cases:

- If there is no layer 4 processing (stateful firewall, DPI, etc.)
taking place between NT64 and NAT46, then there is no need to update the
layer 4 checksum at NAT64 and NAT46.

- Otherwise, then the layer 4 checksum needs updating.

Is there anything worth arguing about this?

>> translator itself checks the integrity of the packet, if it wants to?)

The translator does not check the layer 4 checksum. Doing so would be
very wrong. It would also imply statefulness because the translator
would need to reassemble fragments. Layer 4 checksum validation is done
end-to-end, not hop-by-hop. Compare this with layer 3 checksum
validation which is done hop-by-hop (and was eliminated with IPv6
because end-to-end checksum is sufficient).

See RFC 6145 for the details for the translation algorithm. There is no
layer 4 checksum validation nor fragment reassembly. Fragment reassembly
is described for the stateful translation algorithm, in RFC 6146. The
translation algorithm we're considering for 4rd is of course stateless
and corresponds to RFC 6145.

Simon

---

From: Nejc Škoberne <[email-masked]>
Date: Wed, 24 Aug 2011 13:43:37 +0100

Dear Simon,

> Is there anything worth arguing about this?

No, if violating RFC 6145 in such conditions is acceptable, there is
nothing worth arguing about this. I am new here, so I just don't know.

Thanks for your clarifications, it's just that I would like to understand
all these details in order to make as thorough as possible a comparison
of all these mechanisms.

Nejc

---

From: Simon Perreault <[email-masked]>
Date: Wed, 24 Aug 2011 08:59:54 -0400

>   Prefix or a checksum-neutral Network-Specific Prefix is used and

Right.

>   else they are not RFC 6145-compliant.

First, I think it would be feasible to change the 4rd address scheme so
that the IPv6 prefix is checksum-neutral, even with encoding the port
set ID. But it would be super complex, so I'm not pursuing this idea
further.

Second, I don't like the term "RFC 6145-compliant". In the 4rd-T draft
one could specify that the RFC6145 algorithm is used with the exception
that the transport checksum is not updated. There is no "compliance"
involved. We're free to specify that if it makes sense.

> between the CPE and AFTR in double stateless NAT64 scenarios?

Once again, I dislike the "violate" term. If the exception is written in
a hypothetic 4rd-T RFC, then we're fine and nobody's violating anything.

Beyond that remark, yes, that's exactly what I'm saying.

Simon