Subject: Re: [v6ops] new draft: draft-sunq-v6ops-contents-transition-00.txt

From: Qiong <[email-masked]>
Date: Sun, 8 May 2011 14:25:05 +0800

Dear Erik,

In this deployment, packet fragmentation and reassembly might take place due
to the IPv4/IPv6 packet-length mismatch and MTU-mismatch. So, a fragmented
IPv4/IPv6 packet should be firstly reassembled to an integrated packet, and
then the NAT64 box will do IPv4/IPv6 packet translation, MTU discovery, and
packet fragmentation if necessary.

Is it  enough for your question?

Best wishes

Qiong SUN

From: Erik Kline <[email-masked]>
To: [email-masked]
Date: Sat, 7 May 2011 20:08:31 +0200
Subject: Re: [v6ops] new draft: draft-sunq-v6ops-contents-transition-00.txt
Can there be some discussion of MTU-mismatch and implications?

On 7 May 2011 15:55,  <[email-masked]> wrote:
>
> A new draft has been posted, at
http://tools.ietf.org/html/draft-sunq-v6ops-contents-transition. Please take
a look at it and comment.
> ______________________________
_________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Randy Bush <[email-masked]>
Date: Sun, 08 May 2011 11:03:56 +0200

> In this deployment, packet fragmentation and reassembly might take
> place due to the IPv4/IPv6 packet-length mismatch and MTU-mismatch.
> So, a fragmented IPv4/IPv6 packet should be firstly reassembled to an
> integrated packet, and then the NAT64 box will do IPv4/IPv6 packet
> translation, MTU discovery, and packet fragmentation if necessary.

i think erik meant in the document, please

randy

---

From: Fred Baker <[email-masked]>
Date: Sun, 8 May 2011 06:51:31 -0700

On May 7, 2011, at 11:25 PM, Qiong wrote:

> In this deployment, packet fragmentation and reassembly might take place due to the IPv4/IPv6 packet-length mismatch and MTU-mismatch. So, a fragmented IPv4/IPv6 packet should be firstly reassembled to an integrated packet, and then the NAT64 box will do IPv4/IPv6 packet translation, MTU discovery, and packet fragmentation if necessary. 

Per RFC 6145            

1.4.  Path MTU Discovery and Fragmentation

   Due to the different sizes of the IPv4 and IPv6 header, which are 20+
   octets and 40 octets respectively, handling the maximum packet size
   is critical for the operation of the IPv4/IPv6 translator.  There are
   three mechanisms to handle this issue: path MTU discovery (PMTUD),
   fragmentation, and transport-layer negotiation such as the TCP
   Maximum Segment Size (MSS) option [RFC0879].  Note that the
   translator MUST behave as a router, i.e., the translator MUST send a
   Packet Too Big error message or fragment the packet when the packet
   size exceeds the MTU of the next-hop interface.

   Don't Fragment, ICMP Packet Too Big, and packet fragmentation are
   discussed in Sections 4 and 5 of this document.  The reassembling of
   fragmented packets in the stateful translator is discussed in
   [RFC6146], since it requires state maintenance in the translator.

Path MTU is mandatory in IPv6, so in the IPv6->IPv4 direction that should be sufficient for any fragmentation issues. In the IPv4->IPv6 direction, Path MTU addresses any case in which IPv4 DF is set. If DF is zero (the end system is expecting the network to fragment), I would expect you would look to section 4 for guidance. The section is too long to quote, but in essence the datagram is fragmented as an IPv4 datagram and then the fragments are translated into IPv6 datagrams containing the fragment header.

The reason to not reassemble and then re-fragment is that datagrams can be load-shared - they might not all go through the same translator.

---

From: Jacni Qin <[email-masked]>
Date: Mon, 9 May 2011 16:54:40 +0800

Hi Randy and Erik,

This is a first version to start the work. We'll take it into account in the
next revision.
Thanks a lot for your comments!

Cheers,
Jacni

On Sun, May 8, 2011 at 5:03 PM, Randy Bush <[email-masked]> wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]

---

From: Jacni Qin <[email-masked]>
Date: Mon, 9 May 2011 16:57:45 +0800

Hi Fred,

Thanks for the reply.

On Sun, May 8, 2011 at 9:51 PM, Fred Baker <[email-masked]> wrote:

> > In this deployment, packet fragmentation and reassembly might take place
> due to the IPv4/IPv6 packet-length mismatch and MTU-mismatch. So, a
> fragmented IPv4/IPv6 packet should be firstly reassembled to an integrated
> packet, and then the NAT64 box will do IPv4/IPv6 packet translation, MTU
> discovery, and packet fragmentation if necessary.
>
>
> Per RFC 6145
>
> Path MTU is mandatory in IPv6, so in the IPv6->IPv4 direction that should
> be sufficient for any fragmentation issues. In the IPv4->IPv6 direction,
> Path MTU addresses any case in which IPv4 DF is set. If DF is zero (the end
> system is expecting the network to fragment), I would expect you would look
> to section 4 for guidance. The section is too long to quote, but in essence
> the datagram is fragmented as an IPv4 datagram and then the fragments are
> translated into IPv6 datagrams containing the fragment header.
>

Jacni>:Thanks, maybe we can add a reference and some text.

>
> The reason to not reassemble and then re-fragment is that datagrams can be
> load-shared - they might not all go through the same translator.
>

Jacni>: Yes, load sharing is a good case.
And there is another special one mentioned in RFC6146, the "Incoming IPv4
UDP packets with a zero checksum" which must be reassembled.

Cheers,
Jacni

---

From: Erik Kline <[email-masked]>
Date: Wed, 11 May 2011 18:34:54 +0900

> The reason to not reassemble and then re-fragment is that datagrams can be load-shared - they might not all go through the same translator.

Absolutely understood.  But there's lots of $VENDOR gear that does not
process IPv6 Fragment headers, or doesn't keep state to know which
ACLs to apply to fragments as they arrive.  Usually this means they
get dropped.  Thus, fragmenting toward IPv6 hosts has always seemed
risky to me.  We've seen this in real life.

In practice, I think this would only affect a UDP application running
on an IPv6 client where the IPv4 side sent the largest possible UDP
datagrams that it could.  It would have to get fragmented going toward
the IPv6 destination (after pathmtu discovery, of course), and then
that's when the packet is at the mercy of anything inspecting packets
and not supporting fragments.

Yes, this is certainly broken, but it's most definitely out there.

Now, if it turns out that was /not/ a concern in the authors'
experience, i.e. for all of their normal operations they never noticed
such a problem, then that's cool.  In which I think "To the best of
our knowledge we encountered no trouble with IPv4/IPv6 MTU mismatch."
is a perfectly worthy note to add to the experiences gained from the
deployment.

That's all I meant.