Re: [v6ops] I-D Action: draft-vasilenko-v6ops-ipv6-oversized-analysis-01.txt

> Abstract
> 
>    The IETF has some initiatives relying on IPv6 Extension Headers
>    added in transit: SRv6, iOAM.

No it doesn't, since this is forbidden by RFC8200.

Does it mean that some mechanisms require IPv6-in-IPv6 encapsulation? If so, the fact that this makes packets bigger is hardly new; it's the original reason for the 1280 byte minimum MTU, so that encapsulated packets will usually fit inside a 1500 byte physical MTU.

1500-1280 = 220, allowing for several levels of encapsulation. As Steve Deering wrote on 13 Nov 1997: "e.g., enough for two layers of secure tunneling including both ESP and AUTH headers."

Obviously, any node that encapsulates an IPv6 packet and sends it on may need to fragment it, as part of the normal sending process (also see RFC4213). There seems to be absolutely nothing new here. At one point the draft says:

   Some standards do propose IPv6 fragmentation (primarily for packets
   1280B and below), but fragmentation is recommended after
   encapsulation.

It isn't "recommended"; it's necessary if, and only if, the PMTU is too small for the packet. But a PMTU below 1280 is not allowed; if the physical MTU is below 1280, an adaptation layer must hide it. 

The draft also says:

   Many standards discussed below ([MPLS Encapsulation], [L2TPv3],
   [VxLAN], [NVO3]) forgot to mention that packets 1280 and below
   should be fragmented.

Firstly, packets of 1280 bytes do not need to be fragmented, because they fit into 1280 bytes.

Secondly, this text confuses the IPv6 sending layer (which fragments per RFC8200 according to the known or assumed PMTU) and the adaptation layer (which fragments and reassembles *at the link layer*, below IPv6, if needed). General IPv6 standards don't mention adaptation layer fragmentation because they don't even see it. IPv6-over-foo documents may need to mention it, if and only if they handle a lower layer whose MTU is less than 1280. A good example is RFC7668 (IPv6 over Bluetooth LE).

Why mention [MPLS Encapsulation] (RFC4023)? It's about MPLS encapsulated in IP, not IP in MPLS. Similarly, [L2TPv3] (RFC3931) and [VxLAN] (RFC7348) are about generic L2 encapsulated in IP, not the other way round. [NVO3] (RFC8926) is different because it mainly concerns IP-in-IP, but it discusses fragmentation in section 4.4.1, specifically stating:

   When determining the MTU size of a tunnel link, the
   maximum length of options MUST be assumed as options may vary on a
   per-packet basis.

(It doesn't need to mention 1280 specifically and in any case, in an NVO3 environment the physical MTU will usually exceed 1500.)

The draft concludes:

   One should upgrade all links to a bigger MTU, if
   possible.

I think most people would agree. We got 1280 because in 1997, 1500 was a hard physical limit on every Ethernet interface. But we are never going to get rid of low-end IoT links with much smaller physical MTUs, needing an adaptation layer to achieve the 1280 byte minimum.

Regards
   Brian

On 18-Sep-21 21:39, internet-drafts@ietf.org wrote:
> 
> A New Internet-Draft is available from the on-line Internet-Drafts directories.
> 
> 
>         Title           : IPv6 Oversized Packets Analysis
>         Authors         : Eduard Vasilenko
>                           Xiao Xipeng
>                           Dmitriy Khaustov
> 	Filename        : draft-vasilenko-v6ops-ipv6-oversized-analysis-01.txt
> 	Pages           : 19
> 	Date            : 2021-09-18
> 
> Abstract:
>    The IETF has some initiatives relying on IPv6 Extension Headers
>    added in transit: SRv6, iOAM. Additionally, some recent developments
>    are overlays (SRv6, VxLAN, NVO3, L2TPv3, and LISP). It could create
>    oversized packets that need to be dealt with. This document analyzes
>    available standards for the resolution of oversized packet drops.
> 
> 
> The IETF datatracker status page for this draft is:
> https://datatracker.ietf.org/doc/draft-vasilenko-v6ops-ipv6-oversized-analysis/
> 
> There is also an htmlized version available at:
> https://datatracker.ietf.org/doc/html/draft-vasilenko-v6ops-ipv6-oversized-analysis-01
> 
> A diff from the previous version is available at:
> https://www.ietf.org/rfcdiff?url2=draft-vasilenko-v6ops-ipv6-oversized-analysis-01
> 
> 
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
> 
> 
> _______________________________________________
> I-D-Announce mailing list
> I-D-Announce@ietf.org
> https://www.ietf.org/mailman/listinfo/i-d-announce
> Internet-Draft directories: http://www.ietf.org/shadow.html
> or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
> 