Subject: [Int-area] I-D Action: draft-ietf-intarea-frag-fragile-03.txt

From: [email-masked]
Date: Wed, 21 Nov 2018 06:27:39 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Internet Area Working Group WG of the IETF.

        Title           : IP Fragmentation Considered Fragile
        Authors         : Ron Bonica
                          Fred Baker
                          Geoff Huston
                          Robert M. Hinden
                          Ole Troan
                          Fernando Gont
	Filename        : draft-ietf-intarea-frag-fragile-03.txt
	Pages           : 24
	Date            : 2018-11-21

Abstract:
   This document describes IP fragmentation and explains how it reduces
   the reliability of Internet communication.

   This document also proposes alternatives to IP fragmentation and
   provides recommendations for developers and network operators.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-intarea-frag-fragile/

There are also htmlized versions available at:
https://tools.ietf.org/html/draft-ietf-intarea-frag-fragile-03
https://datatracker.ietf.org/doc/html/draft-ietf-intarea-frag-fragile-03

A diff from the previous version is available at:
https://www.ietf.org/rfcdiff?url2=draft-ietf-intarea-frag-fragile-03

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 22 Nov 2018 08:41:29 +1300

Hi,

> 7.1.  For Application Developers
> 
>    Protocol developers SHOULD NOT develop new protocols that rely on IP
>    fragmentation.  However, they MAY develop new protocols that rely on
>    IP fragmentation when no viable alternative exists.
> 
>    Legacy protocols that depend upon IP fragmentation SHOULD be updated
>    to break that dependency.  However, in some cases, there may be no
>    viable alternative to IP fragmentation (e.g., IPSEC tunnel mode, IP-
>    in-IP encapsulation).  In these cases, the protocol will continue to
>    rely on IP fragmentation

It occurs to me that another case where there is no viable alternative
is IPv6-to-IPv4 translation, if the translated IPv6 packet exceeds the
next hop IPv4 MTU. The last paragraph of section 5.1.1 of RFC7915 says:

>    If an IPv6 packet that is smaller than or equal to 1280 bytes results
>    (after translation) in an IPv4 packet that is larger than the MTU of
>    the next-hop interface, then the translator MUST perform IPv4
>    fragmentation on that packet such that it can be transferred over the
>    constricting link.

There are related but different issues for IPv4 to IPv6 translation,
covered in section 4 of RFC7915:

>    However, when the IPv4 sender does not set the DF bit, the translator
>    MUST ensure that the packet does not exceed the path MTU on the IPv6
>    side.  This is done by fragmenting the IPv4 packet (with Fragment
>    Headers) so that it fits in 1280-byte IPv6 packets, since that is the
>    minimum IPv6 MTU.

This topic might be worth mentioning, for example in the section
"For Middle Box Developers" since NAT64/NAT46 are middleboxes.

Regards
   Brian

On 2018-11-22 03:27, [email-masked] wrote:
> _______________________________________________
> Int-area mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/int-area
>