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

[Vasilenko Eduard <[e-mail]>]

Hi Brian,
Thanks a lot that you have read the draft. Answers are in-line.
Eduard
-----Original Message-----
From: v6ops [mailto:[e-mail]] On Behalf Of Brian E Carpenter
Sent: Sunday, September 19, 2021 2:29 AM
To: [e-mail]
Subject: 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.
[EV] I did want to point the root cause here: EH were needed for some new functionality.
The fact is secondary that EH is possible to add only together with additional IPv6 basic header. If this additional tax is mandatory then nothing could be done.
What if this tax would be released in the future?
It is potentially possible to add: "Additional extension headers is possible to add in transit only together with a basic IPv6 header by the requirement of [IPv6]."
Is it mandatory to bloat "Abstract" with secondary facts? Could we move this detail deeper in the document?
Thanks that you have pointed it to me previous time - I did clean 1 paragraph inside this draft.

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."
[EV] Well, not always. Because some tunnels may be imposed for additional functionality that is represented by big EH. One SRH could be bigger than 220B (SPRING is talking about 16 SIDs). The metadata of iOAM could be bigger too.  220B is not a panacea.
Huston statistics is shown later in the draft: 220B is not available in many cases.

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. 
[EV] Well, again it is obviously not for many people. See section 3.3 for many excerpts from different tunnel RFCs (MPLS, L2TPv3, VxLAN, NVO3, GRE).
Unfortunately, there is a mess in standards. People developing all these standards did not read carefully RFC 2473.
L2TPv3, VxLAN, NVO3 forgotten to investigate the situation for what to do if the source already send the smallest packet (1280) and it is not possible to decrease it by ICMP PTB.
draft-ietf-intarea-tunnels is trying to impose fragmentation even for the case when it is possible to signal smaller PMTU to the source.

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.
[EV] The point was different. Probably the text should be changed to:
   Many standards discussed below ([MPLS Encapsulation], [L2TPv3],
   [VxLAN], [NVO3]) forgot to mention that packets 1280 and below
   should be fragmented if they are too big for the tunnel.

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).
[EV] Fragmentation below IP (at L2, like BLE) is probably not related to the discussion.
Is the addition of "if they are too big for the tunnel" (see above) enough to clear the confusion that I have created?

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. 
[EV] Section 3.3 is about fragmentation at the tunnel ends. Hence, tunneling technologies are considered.
It does not matter that the tunnel is L2 (like VxLAN was initially) - it should still be capable to:
1. Detect tunnel MTU by PMTUD inside the tunnel
2. Inform the source by ICMP PTB to decrease PMTU
3. Fragment packet if the packet is already 1280B or smaller but still too big for the tunnel.
Funny enough, but only the oldest RFC 2473 discuss properly 3 points from above.
4. Even more, RFC 2473 has an "ICMP PTB proxy" that informs the source in one round trip time.
All these points are spread between sections 3.3 and 3.4.
Because if 1-3 are not implemented then only drop or fragmentation is the choice.

In regards to "normal MPLS" (MPLS over L2): I do not know what to do. It is a challenge to deal at L3 with technology that is defined as the shim layer between L2 and L3.
Probably, "Service label" should not be related to PMTUD or fragmentation because service should not be path-dependent.
"Transport label" (or 2nd layer transport label like BGP-LU) may be related to fragmentation and has its own PMTUD but it is not over IP - it is directly over L2.
Preliminary conclusion: Normal MPLS looks like "transport technology" that is not related to IP because it is below IP. Hence, put out of the scope. Maybe wrong.

[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.)
[EV] IMHO: the more interesting excerpt from NVO3 is section 4.4.4:
"It is strongly RECOMMENDED that Path MTU Discovery ([PMTUD]) be used to prevent or minimize fragmentation."
And the fact that NVO3 does not discuss what to do if the packet is already 1280B of smaller - ICMP PTB would not help.

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.
[EV] Yes, by Jen's request, I have investigated and presented statistics for support of > 1280B in IoT OSes. Not good.

Regards
   Brian

On 18-Sep-21 21:39, [e-mail] 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-overs
> ized-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
> [e-mail]
> 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
> 

_______________________________________________
v6ops mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/v6ops