Hi, all,
Spoiler alert if you don’t want to read the whole post:
- draft-vasilenko makes erroneous claims as to the content in
draft-tunnels
- draft-tunnels and draft-vasilenko are consistent (once the latter is
corrected) in their mutual conclusions
- draft-tunnels on the need for fragmentation over finite MTU
paths
- draft-vasilenko in encouraging increases in those finite MTUs
Joe
---
First, draft-ietf-intarea-tunnels is discussed on the int-area list; after
review of the information below, if you still believe there are issues to be
addressed in that doc, you should post them there.
The technical errors in RFC2473 have been indicated in that document since
draft-ietf-intarea-tunnels-01, posted in July 2015. They remain accurate, IMO.
Note that I ceased performing in-place updates of that document because of
*lack of active discussion* and because in-place updates are a waste of my time.
I am glad to see someone in IPv6 interested now, and would be glad to update my
draft as needed.
FWIW, having read your doc, here are its errors in misstating the content of my
draft:
- your doc mistakenly assumes that mine requires IPv6 hosts to send 1500B
packets if they can, even if tunnels are on the path
as with any IPv6 path, the source should send fragments no larger than
the entire path can transit, whose reassembled size is no larger than the
receiver can reassemble
those original fragments are what enter the on-path tunnels, so they
should be no larger than the tunnel egress can fragment
and those original fragments would be encapsulated and then source
fragmented by the tunnel according to the same (recursive) policy
- nothing in draft-tunnels assumes ICMP PTB cannot adjust these sizes or that
the tunnel cannot use PLPMTUD
see sec 4.3.1 of v10
- draft-tunnels does not “introduce” a new variable called tunnel MTU; I
introduced the terminology, but the concept is as old as tunnels
I coined that term to refer to the MTU across the tunnel with
reassembly at egress (which already exists), as different from the MTU between
ingress and egress (which I call tunnel MAP)
sec 4.2.3 of v10 doesn’t claim this value cannot be set; in explains
that PMTUD has no role in discovering its value:
Note, however, that PMTUD never discovers
EMTU_R that is larger than the required minimum; that information is
available to some upper layer protocols, such as TCP [RFC1122
<https://tools.ietf.org/html/rfc1122>], but
cannot be determined at the IP layer.
I never said it cannot be discovered
it should be (e.g., by a tunnel configuration protocol)
note that there are no current protocols that do this, even
without tunnels (i.e., discover larger EMTU_R)
I can add that point as clarification
- draft-tunnels does not increase IPv6 fragmentation
please indicate why you believe it would (notably here "a considerable
increase in fragmentation is proposed for the reasons of academic purity”)
- draft-tunnels does not claim fragmentation is the only solution to oversize
packets
it addresses how and where to handle tunnels in the presence of packet
limits, of which path MTU is only one
- ICMP PTB is not a solution out to the origin source
that would potentially drop the IPv6 path MTU below 1280, given enough
tunnel overhead (or layers thereof), a violation of IPv6
so yes, in that case, the ONLY solution that preserves IPv6 in the
presence of tunnels with that much overhead would be ingress source
fragmentation
- sec 3.3 of my doc DOES allow ICMPs to be relayed back to the source
it merely states that they should be generated when a packet too large
to ingress arrives,
NOT when an internal tunnel ICMP is received by the ingress
the point is that the origin source sees the ingress as a router on the
path,
so it should get ICMPs from that router only when packets arrive at
that router, not when its tunnel fails downstream
this makes ICMP relay *easier* and more reliable to implement; the
ingress gets tunnel ICMPs to learn the tunnel’s effective link MTU,
then uses that link MTU to send ICMPs back
yes, this is to allow the tunnel to act as the link *that it is*, but
it does not prohibit ICMP info from flowing back to the source
And finally:
- nobody is claiming we shouldn’t increase link MTU
draft-tunnels would still be relevant, no matter how large the MTU is,
for the reasons I state in that doc
One other observation:
- your statistics for fragment drops apply only when the fragment is visible to
the IP layer
there are intermediate layers that hide fragmentation for exactly this
reason, e.g., UDP tunnels, GRE, etc.
---
> On Mar 21, 2021, at 1:59 AM, Vasilenko Eduard <[email protected]>
> wrote:
>
> Dear Experts,
> I have seen many recent activities in IETF related to MTU problems. Well,
> maybe not so active as some others, but active anyway. Many other active
> drafts are evaluated in this draft.
> I had an idea what is the right way to solve problems in this area, but after
> the research, it has been found that foundations were discussed in RFC 2473
> (Dec 1998). Just people have forgotten about it.
> We have discussed it with co-authors and we have decided that it make sense
> to publish the research because it looks at the problem in a systematic
> approach.
>
> The one thing that is alarming in this research: draft-ietf-intarea-tunnels
> is pushing for much more fragmentation for pure Academic reasons. This draft
> is already referenced by many other documents.
> I believe that not many people have spent enough time to understand it's
> complexity to reveal the truth: the majority of the IPv6 traffic would be
> fragmented if it would follow draft-ietf-intarea-tunnels.
>
> Thanks to everybody who would spend enough time to produce comments.
> Eduard
> -----Original Message-----
> From: [email protected] [mailto:[email protected]]
> Sent: Friday, March 19, 2021 11:07 PM
> To: Dmitriy Khaustov <[email protected]>; Vasilenko Eduard
> <[email protected]>; Vasilenko Eduard
> <[email protected]>; Xipengxiao <[email protected]>; Xipengxiao
> <[email protected]>
> Subject: New Version Notification for
> draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt
>
>
> A new version of I-D, draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt
> has been successfully submitted by Eduard Vasilenko and posted to the IETF
> repository.
>
> Name: draft-vasilenko-v6ops-ipv6-oversized-analysis
> Revision: 00
> Title: IPv6 Oversized Packets Analysis
> Document date: 2021-03-19
> Group: Individual Submission
> Pages: 19
> URL:
> https://www.ietf.org/archive/id/draft-vasilenko-v6ops-ipv6-oversized-analysis-00.txt
> Status:
> https://datatracker.ietf.org/doc/draft-vasilenko-v6ops-ipv6-oversized-analysis/
> Htmlized:
> https://datatracker.ietf.org/doc/html/draft-vasilenko-v6ops-ipv6-oversized-analysis
> Htmlized:
> https://tools.ietf.org/html/draft-vasilenko-v6ops-ipv6-oversized-analysis-00
>
>
> Abstract:
> The IETF has many new initiatives relying on IPv6 Enhanced Headers
> added in transit: SRv6, SFC, BIERv6, iOAM. Additionally, some recent
> developments are overlays (SRv6, VxLAN) over IPv6. It could create
> oversized packets that need to be dealt with. This document analyzes
> available standards for the resolution of oversized packet drops.
>
>
>
>
> 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.
>
> The IETF Secretariat
>
>
> _______________________________________________
> v6ops mailing list
> [email protected]
> https://www.ietf.org/mailman/listinfo/v6ops
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
