On 06-Feb-22 07:21, Bob Hinden wrote:
Reducing the cc: a little and trimming the response.
On Feb 4, 2022, at 9:49 AM, Gorry Fairhurst <gorry@xxxxxxxxxxxxxx> wrote:
On 04/02/2022 16:08, Templin (US), Fred L wrote:
Gorry, thanks and see also below:
Fred
If it helps, we could add text saying a host wishing to use a MTU larger
than 64KB must not use this HBH option, although that might be obvious.
I think what is being asked is very simple and not hard at all to implement. It
is just a simple test of the option length - if the length is 4 the option is in
"short form", and if the length is 8 the option is in "long form".
But, the overriding consideration is that there is an impending use of Jumbos
that we believe will begin to emerge in the near term called: "IP Parcels". If
you have not heard about them yet, I strongly suggest you have a quick look:
https://datatracker.ietf.org/doc/draft-templin-intarea-parcels/
IP Parcels should become an early adopter of your MTU option, but they can
be larger than 64K (up to 4M) and would very soon want to begin using
the
long form. Plus, the MTU option would only be used on path qualification
messages and not on every single packet so using the long form would not
introduce any unnecessary inefficiencies.
So yes - please include both long and short forms of the MTU option in the
first publication - because it is very likely going to cast the option in stone
for the forseeable future.
Thanks - Fred
Gorry
I did read the draft you pointed to thanks, because I anticipated that
your query might be linked to this topic - my thought is that if your work was to proceed in future at the IETF, then you might be able to take advantage of the HBH option proposed in the draft for traversing standard links (i.e. with KB of MTU).
If your thought was to use packets and frames larger than 64 KB, then there would be many issues to consider. There are various possibilities including a new header that might be the best way forward for those paths that wish to support this approach - I'd expect you'd need new functionality anyway at routers to handle this change in architecture. This was not
what was considered in draft-ietf-6man-mtu-option.
The HBH option is designed to work with the IPv6 header’s header length, not with Jumbograms (RFC 2675). I agree with Gorry that if it is helpful, we could say that in the draft.
I also agree with Gorry that making packets larger than 64K work on the
internet is a big undertaking, that will touch many areas. We have had RFC2675 Jumbograms since 1999, it doesn’t appear to be any uptaked.
https://mailarchive.ietf.org/arch/msg/ipv6/MeVE88345dPY7AcvYI8pN5mU8A0/
To me, the current state of “IP Parcels” is at a very early stage, that is, an individual draft in the INT area. I don’t think it warrants changing <draft-ietf-6man-mtu-option> to accommodate it.
Bob
p.s. I can think of a few ways that this option could accommodate Jumbograms without changing the format, but won’t go into that here.
Don't bother. Jumbograms were always intended to be used in what we'd now
call "limited domain" deployments with well understood operational constraints, so PMTUD simply isn't needed.
Brian
--
last-call mailing list
last-call@xxxxxxxx
https://www.ietf.org/mailman/listinfo/last-call
