Subject: [BEHAVE] Comments on NAT64 draft

From: Zhen Cao <[email-masked]>
Date: Tue, 15 Sep 2009 21:30:28 +0800

Dear Authors and all,

I have some comments on the NAT64 draft, especially on Section.7 of
MTU and fragmentation. Thanks for any clarification.

1) Sec.7.1.1 talks about the PMTU in IPv6 to IPv4 translation, and it states:
           When a NAT64 translates "packet too big" messages from IPv6
to IPv4, it adjusts the advertised MTU to the minimum of the original
advertised MTU + 20, the NAT64's MTU on the IPv6 side + 20 and the
NAT64's MTU on the IPv4 side.

>From my understanding, when some IPv6 router reports a MTU 1500, the
effective MTU for IPv4 networks is actually 1480. So the "+20" should
be "-20" instead. What's more, if DF=0 in the IPv4 packet, the
effective MTU for IPv4 is 1472, considering the 8-byte place for
fragment header.

2) If the above is right, it also applies to the discussion in
Sec.7.1.2 similarly. The "-20" should be "+20" instead.

3) Sec.7.2.2 talks about the fragmentation issues from IPv6 to IPv4,
and it states:
           In the IPv6-to-IPv4 direction, there is no need to map a
fragment to the session it belongs to in order to translate the
fragment.

If there is only one ipv4 address available for ipv6-to-ipv4
translation, the above is true. However, NAT64 is a device with at
least one ipv6 interface and at least one ipv4 interface. If there are
more than one ipv4 address and the not-the-first fragment arrives
first, it does not know how to translate the packet.

Thanks again.

Best regards,
Zhen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 15 Sep 2009 16:37:26 +0200

> be "-20" instead.

Right. I think I was confusing the direction of the packet flows here.

> What's more, if DF=0 in the IPv4 packet, the

Yes, if an IPv4 host is sending packets with DF=1 that are larger than  
what can be handled on the IPv6 part of the path and then switches to  
sending packets with DF=0, it then needs to use a path MTU that is 8  
bytes smaller than was the case with DF=1. However, hosts typically  
send packets that are all DF=0, in which case we won't be sending back  
any packet too big messages, or all with DF=1, in which case the host  
should adapt to the reported path MTU so there is no need for  
fragmentation.

> Sec.7.1.2 similarly. The "-20" should be "+20" instead.

Right.

> first, it does not know how to translate the packet.

Not sure if we already discuss this in the draft, but we don't want  
the situation where a translator uses different IPv4 addresses for  
translating different sessions from the same IPv6 host because it  
breaks STUN.

Thanks for the comments,

Iljitsch

---

From: Zhen Cao <[email-masked]>
Date: Tue, 15 Sep 2009 23:38:42 +0800

On Tue, Sep 15, 2009 at 10:37 PM, Iljitsch van Beijnum
<[email-masked]> wrote:
> Yes, if an IPv4 host is sending packets with DF=1 that are larger than what
> can be handled on the IPv6 part of the path and then switches to sending
> packets with DF=0, it then needs to use a path MTU that is 8 bytes smaller
> than was the case with DF=1. However, hosts typically send packets that are
> all DF=0, in which case we won't be sending back any packet too big
> messages, or all with DF=1, in which case the host should adapt to the
> reported path MTU so there is no need for fragmentation.

Understand, thanks.

> Not sure if we already discuss this in the draft, but we don't want the
> situation where a translator uses different IPv4 addresses for translating
> different sessions from the same IPv6 host because it breaks STUN.

I am not talking about the one ipv6 mapping to multiple ipv4
addresses, and am assuming one ipv6 host maps to one ipv4 address.

If an in-the-middle fragmented packet arrives, we cannot create the
mapping entry from <Y', y> to <T, t>. Do you mean just translate it
first and wait for the first fragment to fill in the entry?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 15 Sep 2009 17:47:21 +0200

On 15 Sep 2009, at 17:38 , Zhen Cao wrote:

>> the

> addresses, and am assuming one ipv6 host maps to one ipv4 address.

Well, in that case there is no problem with the translation of  
fragments without reassembly or setting up state, right?

> first and wait for the first fragment to fill in the entry?

I assume Y' = the IPv6 source address, y = the source port, T is the  
destination address and t the destination port.

You are right that it won't be possible to map a non-first fragment to  
a session because it could match multiple sessions. However, we can  
still translate it as long as we know the IPv4 source address that we  
need to use. The IPv4 destination address can be derived from the IPv6  
destination address. The only thing we need for the translation is  
addresses and an identifier value that is the same for all fragments.

---

From: Zhen Cao <[email-masked]>
Date: Wed, 16 Sep 2009 09:46:13 +0800

On Tue, Sep 15, 2009 at 11:47 PM, Iljitsch van Beijnum
<[email-masked]> wrote:
> Well, in that case there is no problem with the translation of fragments
> without reassembly or setting up state, right?
>
> You are right that it won't be possible to map a non-first fragment to a
> session because it could match multiple sessions. However, we can still
> translate it as long as we know the IPv4 source address that we need to use.
> The IPv4 destination address can be derived from the IPv6 destination
> address. The only thing we need for the translation is addresses and an
> identifier value that is the same for all fragments.
>

Let me explain my concerns further. Here, Y' = the IPv6 source
address, y = the source port; T= the translated IPv4 address on NAT64
and t the translated port on NAT64. (consistent with Sec.1.2.2
presentation). Multiple Y' may reuse the same IPv4 address T.

For example, if an ipv6 datagram has two fragments, frag1 and frag2.

a) if frag1 arrives at the NAT64 first (it includes the port number),
the NAT will choose an IPv4 address T and port t for translation and
creates an mapping entry from <Y', y> to <T, t>. When frag2 arrives
later, it  knows how to translate by querying the mapping table.

b) if frag2 arrives at the NAT64 first (it does NOT include the port
number), the NAT has not yet created the mapping entry  <Y', y> to <T,
t>.  How to translate this frag2 in this case?

Thanks,
Zhen

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Sep 2009 11:57:09 +0200

> later, it  knows how to translate by querying the mapping table.

Right. Suppose the following mapping table:

1: TCP 2001::abc/1025, 1000::10.0.0.1/80 -> 192.0.2.1/16000, 10.0.0.1/80
2: TCP 2001::abc/1026, 1000::172.16.0.255/993 -> 192.0.2.1/16001,  
172.16.0.255/993
3: TCP 2001::bdf/1025, 1000::10.0.0.1/80 -> 192.0.2.45/16002,  
10.0.0.1/80
4: TCP 2001::abc/1027, 1000::10.0.0.1/80 -> 192.0.2.1/16003, 10.0.0.1/80

If the fragment has TCP, src=2001::abc/1025, dst=1000::10.0.0.1/80 the  
mapping query will provide a hit on mapping 1, so this works.

> t>.  How to translate this frag2 in this case?

In this case the mapping lookup will be done on the addresses and  
protocol only, so a lookup for TCP, src=2001::abc, dst=1000::10.0.0.1  
will match both 1 and 4. However, this is not a problem, because the  
only information needed for the translation is the translated source  
address 192.0.2.1, which is the same for both mappings so the  
ambiguity is irrelevant.

The only problematic case is one where there is no match because this  
is the first packet (and a non-first fragment). In that case the  
fragment must be dropped, because a mapping can't be created without  
port numbers.

---

From: Zhen Cao <[email-masked]>
Date: Wed, 16 Sep 2009 21:07:54 +0800

On Wed, Sep 16, 2009 at 5:57 PM, Iljitsch van Beijnum
<[email-masked]> wrote:
> 3: TCP 2001::bdf/1025, 1000::10.0.0.1/80 -> 192.0.2.45/16002, 10.0.0.1/80
> In this case the mapping lookup will be done on the addresses and protocol
> only, so a lookup for TCP, src=2001::abc, dst=1000::10.0.0.1 will match both
> 1 and 4. However, this is not a problem, because the only information needed
> for the translation is the translated source address 192.0.2.1, which is the
> same for both mappings so the ambiguity is irrelevant.
>
> The only problematic case is one where there is no match because this is the
> first packet (and a non-first fragment). In that case the fragment must be
> dropped, because a mapping can't be created without port numbers.

Yes, that's what i meant. I forgot to mention it is the first packet
in the flow. But the NAT may wait for the first frag to arrive?
Anyway, do we need to define this behavior explicitly in the draft?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 16 Sep 2009 15:15:48 +0200

> Anyway, do we need to define this behavior explicitly in the draft?

With TCP this can't realistically happen because the initial SYN is  
small enough to fit in any reasonable MTU.

With UDP it could happen. I guess if you ALWAYS get reordering and  
ALWAYS throw away the non-initial fragment of a first packet then  
there will be trouble with protocols like the DNS that send single  
packet transactions, because those will then consistently fail.

Any ideas from implementers? Is it problematic to have to buffer and  
reassemble UDP fragments that don't match any state in the v6->v4  
direction?

(Fortunately we don't have to do this in the v4->v6 direction, where  
denial of service attacks are a bigger risk, because new sessions  
aren't set up in this direction.)

---

From: Cameron Byrne <[email-masked]>
Date: Wed, 16 Sep 2009 06:53:22 -0700

On Wed, Sep 16, 2009 at 6:15 AM, Iljitsch van Beijnum
<[email-masked]> wrote:
> With TCP this can't realistically happen because the initial SYN is small
> enough to fit in any reasonable MTU.
>
> With UDP it could happen. I guess if you ALWAYS get reordering and ALWAYS
> throw away the non-initial fragment of a first packet then there will be
> trouble with protocols like the DNS that send single packet transactions,
> because those will then consistently fail.
>
> reassemble UDP fragments that don't match any state in the v6->v4 direction?

According to RFC 4787 Requirement 14, a NAT MUST accommodate this out
of order fragment situation.

>
> (Fortunately we don't have to do this in the v4->v6 direction, where denial
> of service attacks are a bigger risk, because new sessions aren't set up in
> this direction.)
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 17 Sep 2009 16:18:18 +1200

> of order fragment situation.

This seems extreme; I wonder why it wasn't a SHOULD. However,
that's a BCP for IPv4-IPv4 NATs "as described in [RFC2663]."
We can decide independently for NAT64, but Iljitsch has asked the
right question: how big a deal is this for implementors?

    Brian

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 17 Sep 2009 20:44:25 -0400

I do not think it is a big deal. The same is done today for NAT44 and such
knowledge/experience could be easily leveraged.

I know we can decide differently for NAT64, but the box that has been doing
NAT44 will (or could) be doing NAT64 for the same network; therefore 'look
and feel' as related to the original BEHAVE RFCs should be the same as much
as possible. This would make adoption and transition easier.

Thanks,

Reinaldo

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 18 Sep 2009 13:16:30 +1200

Reinaldo,

In general terms I agree with you, but is there documented field experience?

I am concerned that even a small rate of out-of-order fragments could lead
to disproportionately high buffering requirements and a significant
performance hit, even disregarding a DOS scenario.

Regards
   Brian

---

From: Zhen Cao <[email-masked]>
Date: Fri, 18 Sep 2009 09:29:45 +0800

> right question: how big a deal is this for implementors?

It might not be a big problem for implementor, considering it only
hurts the first out-of-order fragmented packet of the flow. Also from
the statistics you provided several days before, fragmented UDP
packets counts to a very small percentage.

But changing the text in NAT64 is also not a big deal. We can analyze
this in the document a bit for the consideration of implementors. This
will do no harm and make the document as solid as possible.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Sep 2009 16:04:45 +1200

> packets counts to a very small percentage.

Correct. But if such packets consume 100 times more resource in the
NAT, they could still be a problem. That's an engineering question,
and I am still not sure of the answer.

> will do no harm and make the document as solid as possible.

Yes. But I think there is quite a big difference in this case between
a SHOULD and a MUST.

    Brian

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 25 Sep 2009 16:57:35 -0400

There is certainly the engineering issue which we could debate but it would
be good to hear service provider requirements in relation to this aspect in
the context of NAT64. In the case of NAT44 dropping fragments is not okay
(at least this is what I hear).

Thanks,

Reinaldo

---

From: Cameron Byrne <[email-masked]>
Date: Fri, 25 Sep 2009 15:12:34 -0700

> (at least this is what I hear).

As stated before, as much as i dislike making NAT64 any more
complicated than it absolutely must be, I believe it is best to have
parity with NAT44, and RFC 4787 / BCP 127 states we must support the
out of order fragments while at the same time mitigating against any
DOS attacks that may come from holding state for out-of-order
fragments.  My goal is that i can offer IPv6 only service to customers
and they cannot tell the difference from IPv4 service.   If for some
reason they send out-of-order fragments today with my current NAT44
and I support it in IPv4, i must support it in IPv6 as with NAT64 as
well.

Cameron Byrne
Principal Engineer
T-Mobile USA

---

From: Zhen Cao <[email-masked]>
Date: Sat, 26 Sep 2009 13:05:14 +0800

I thinks we should keep the NAT64 compatible with NAT44 in dealing
with out of order fragments.

Also in this case, what the implementor should do is dealing with the
first arriving out-of-order fragment. Buffering the fragment is
troublesome but it is easy to couple with some timeout scheme to avoid
consuming too much resource. So from implementation point, this does
not count much.

Thanks,
Zhen

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 27 Sep 2009 09:27:36 +1300

> consuming too much resource. So from implementation point, this does

In the 4 to 6 direction, if you have to calculate the UDP checksum, you
have to buffer all the fragments. And if the first fragment happens to arrive
last, you don't know until then whether you have to calculate the checksum.
So it seems to me that it is significantly worse than NAT44, because you
always have to buffer all UDP fragments in that case. I don't mean to say
it's impossible, but we should be very clear what we are requiring.

   Brian