Subject: [BEHAVE] Possible issue with Fragmentation text in draft-ietf-behave-v6v4-xlate-15

From: Reinaldo Penno <[email-masked]>
Date: Thu, 1 Apr 2010 14:40:48 -0400

Hello,

It is not clear from the study referenced (the 43.46%) if the IPv6 hosts
that do not comply:

* do send fragment header and reduce packet size to 1280 or
* do not send fragment header but reduce packet size to 1280 or
* include a fragmented header but continue to send whatever packet size as
before.

This leads to the following question:

Let's suppose you have three links:

IPv6-A, MTU 1400
IPv4 (B-C), MTU 1480
IPv4 (D-E), MTU 1200
IPv4 Endhost

A and B and the interfaces of a xlate in the IPv6 and IPv4 worlds
respectively.

Reading the text my interpretations is the following: If the IPv6 host does
not include a fragmented header in response to 'ICMPv6 too big' and the
packet is 1400 (as above), I should set DF=1 in the IPv4 packet and send it
out. Wouldn't that create a permanent issue (depending on the details of the
study) since the packets would never traverse D-E?

Thanks,

Reinaldo

---

From: Reinaldo Penno <[email-masked]>
Date: Thu, 1 Apr 2010 14:52:14 -0400

First sentence should read

* do not send fragment header and do not reduce packet size to 1280 or

---

From: Xing Li <[email-masked]>
Date: Fri, 02 Apr 2010 20:28:51 +0800

Hi,

>> study) since the packets would never traverse D-E?
please see the attached file. the behavior of xlate follows the current 
specification. it should be no problem.

regards,

xing, congxiao

>> Thanks,
>>
>> Reinaldo
>>
>>
>>     
>
> _______________________________________________
> Behave mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/behave
>
>
>

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 2 Apr 2010 11:20:00 -0400

Thanks for the great diagram. So, irrespective of the spec, what you are
saying is that current implementations reduce the packet size to 1280
(although might not include a fragmentation header)?

In other words, in the study clients actually reduce the packet size. That
was not clear. I would suggest putting a reference to the study in the
draft.

---

From: Xing Li <[email-masked]>
Date: Sat, 03 Apr 2010 00:15:28 +0800

Reinaldo Penno 写道:

thanks.
> (although might not include a fragmentation header)?

correct.

> was not clear. I would suggest putting a reference to the study in the

actually, we have cited a reference [Stasiewicz
http://www.ietf.org/mail-archive/web/behave/current/msg08093.html ] upto
version 11 (http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-11).
It was removed in version 12 according to the review comments. The
reason is that the standard track RFC should not cite mailing-list as
references.

regards,

xing, congxiao

---

From: "Dan Wing" <[email-masked]>
Date: Fri, 2 Apr 2010 10:57:27 -0700

> -----Original Message-----
> From: [email-masked] 
> [mailto:[email-masked]] On Behalf Of Reinaldo Penno
> Sent: Friday, April 02, 2010 8:20 AM
> To: Xing Li
> Cc: [email-masked]
> Subject: Re: [BEHAVE] Possible issue with Fragmentation text 
> in draft-ietf-behave-v6v4-xlate-15
> 

Ben Stasiewicz did two studies -- one sent ICMP packet-too-big with an MTU of
1280, which was generally successful and the IPv6 hosts reduced their packets
to 1280 bytes,
http://listserver.internetnz.net.nz/pipermail/ipv6-techsig/2009-October/000708
.html.  

The other study sent ICMP packet-too-big with an MTU below 1280, which was
generally unsuccessful; it is this second study that is is cited in
draft-ietf-behave-v6v4-xlate.

> was not clear. I would suggest putting a reference to the study in the

-d

---

From: Reinaldo Penno <[email-masked]>
Date: Fri, 2 Apr 2010 15:26:51 -0400

Xing,

I had some discussions offline and would you mind if I suggest some changes
to the draft specifically in the IPv6 to IPv4 translation?

* First of all, the MTU, fragmentation discussions could use at least a
section heading of its own.
* Then the text (at least IMHO) is somewhat confusing as it tries to explain
the assumption, but if the assumptions are not right do this and then there
is this study which allows us to do that....

Maybe something crisp and to the point like:

"The IPv6 to IPv4 translation assumes the following to work properly"

* An IPv6 host when receiving an PTB with MTU < 1280 MUST adjust its packet
size to 1280
* It MAY include a fragmentation header.

If the IPv6 host does not adjust its packet size and the translator sets
DF=1 for IPv4 packets > 1280,  they might be dropped by an intermediate IPv4
link where MTU < 1280"

Thanks,

Reinaldo

---

From: Xing Li <[email-masked]>
Date: Sat, 03 Apr 2010 11:01:29 +0800

Hi, Reinaldo,

> * It MAY include a fragmentation header.

Yes, this implies that the IPv6 hosts follow the specifications defined
in [RFC2460].
> DF=1 for IPv4 packets > 1280,  they might be dropped by an intermediate IPv4
Thanks for this very important notice. We have added a configuration
options in
Section 3, which will help to solve the problem.

* From IPv4 to IPv6 direction, the translator can be configured to adjust the MTU in PTB message from a value smaller than 1280 to 1280. So there is no requirement for the IPv6 hosts to do the adjustment for a "strange" MTU in PTB.

Regards,

xing, congxiao

---

From: Reinaldo Penno <[email-masked]>
Date: Tue, 6 Apr 2010 14:56:53 -0400

Xing,

Thanks for the change but I still find this text extremely confusing...maybe
It is just me. Let me give an example:

" There are some differences between IPv6 and IPv4 in the area of
   fragmentation and the minimum link MTU that affect the translation.
   An IPv6 link has to have an MTU of 1280 bytes or greater.  The
   corresponding limit for IPv4 is 68 bytes.  Thus, unless there were
   special measures, it would not be possible to do end-to-end path MTU
   discovery when the path includes a translator, since the IPv6 node
   might receive ICMPv6 "Packet Too Big" messages originated by an IPv4
   router that report an MTU less than 1280.  However, [RFC2460] section
   5 requires that IPv6 nodes handle such an ICMPv6 "Packet Too Big"
   message by reducing the path MTU to 1280 and including an IPv6
   fragment header with each packet.  In this case, the translator
   SHOULD set DF to 0 and take the identification value from the IPv6
   fragment header when a fragmentation header with (MF=0; Offset=0) is
   present or set DF to 1 otherwise.  "

[Reinaldo] the premise of this whole text above was that the PTB message
reported a MTU below 1280. But then, the next sentence (below) says that
'this' will allow PMTU to work as long as the path in 1280 or greater...So,
the discussion and conclusion are about different scenarios.

" This allows end-to-end path MTU
   discovery across the translator as long as the path MTU is 1280 bytes
   or greater. 
"

On 4/2/10 8:01 PM, "Xing Li" <[email-masked]> wrote:

> * From IPv4 to IPv6 direction, the translator can be configured to adjust the
> MTU in PTB message from a value smaller than 1280 to 1280. So there is no
> requirement for the IPv6 hosts to do the adjustment for a "strange" MTU in
> PTB.
> 
> Regards,
> 
> xing, congxiao
> 
> 
> 
>> Thanks,
>> 
>> Reinaldo
>> 
>> 
>> 
>>

---

From: "Dan Wing" <[email-masked]>
Date: Tue, 6 Apr 2010 15:29:04 -0700

As the document has already been submitted to IESG, can you suggest specific
text so this can be turned around quickly?

-d

> Sent: Tuesday, April 06, 2010 11:57 AM
> To: Xing Li
> Cc: [email-masked]
> >>> version 11 
> (http://tools.ietf.org/html/draft-ietf-behave-v6v4-xlate-11).
> >>>>>>> * include a fragmented header but continue to send 
> whatever packet size
> >>>>>>> as
> >>>>>>> before.
> >>>>>>>     
> >>>>>>> Reading the text my interpretations is the following: 
> If the IPv6 host
> >>>>>>> does
> >>>>>>> packet is 1400 (as above), I should set DF=1 in the 
> IPv4 packet and send
> >>>>>>> it
> >>>>>>> out. Wouldn't that create a permanent issue 
> (depending on the details of
> >>>>>>> the

---

From: Xing Li <[email-masked]>
Date: Wed, 07 Apr 2010 07:36:09 +0800

Hi,

>    discovery across the translator as long as the path MTU is 1280 bytes
Actually this is the idea originally presented in RFC2460. The two
sentences you have cited are consistent. They imply that

For the packets from IPv6 to IPv4:
(1) If the minimum MTU along the path is greater than 1280, the
translation allows PMTU.
(2) If the minimum MTU along the path is equal to or smaller than 1280,
the translation cannot do PMTU.

As Dan suggested, you may suggest some text.

Regards,

xing, congxiao

---

From: WashamFan <[email-masked]>
Date: Fri, 09 Apr 2010 14:39:28 +0800

Hi,

>     present or set DF to 1 otherwise.  "

Reading from the above text and relevant text in the latest xlate doc, it
seems to me the translator would set DF=1 if the IPv6 fragment with
MF=1 and the fragment size=1280 received. In this case, it might cause
black hole if some place in IPv4 network has <1260 MTU. Am I missing 
something?

THanks,
washam