Hello Fred,
Please find my reply.
>>The thing is, applications that want to use steady-state fragmentation will
>>not want to
>>receive RF ICMP messages. And so, there should be some way for the sender to
>>indicate
>>to the receiver that an RF ICMP is desired. I think the way I proposed doing
>>that was for
>>the sender to set the evil bit in the IPv4 header and re-purpose that bit as
>>the "RF bit".
>>But, another way could be to include an indication at connection setup time
>>at a layer
>>above IPv4 (e.g., a TCP option).”
If an application does not want to receive the ICMP reply then it can drop the
message.
All ICMP message replies are unconditional and sender does not set any
condition
to receive them. Sender Application of the packet either drop ICMP reply or
rate-limit them.
Setting RF bit in IPV4 header is a complex task and needs changes at sender end.
So far none of the ICMP reply/error message sets a bit in the packet while
sending a packet
to indicate receivers to send ICMP reply.
Hopefully I was able to explain...
Regards
Manoj Nayak
Message: 2
Date: Tue, 29 Oct 2019 19:41:18 +0000
From: "Templin (US), Fred L" <[email protected]>
To: Ron Bonica <[email protected]>,
"[email protected]" <[email protected]>
Subject: Re: [Int-area] New Version Notification for
draft-bonica-intarea-lossless-pmtud-00.txt
Message-ID: <[email protected]>
Content-Type: text/plain; charset="us-ascii"
Ron, I proposed something like this a long time ago and called it "Report
Fragmentation (RF)".
I think that concept and name were also proposed an even longer time ago in
the days of
the pmtud wg back when RFCs 1063 and 1191 were under development in the
late 1980's.
The thing is, applications that want to use steady-state fragmentation will
not want to
receive RF ICMP messages. And so, there should be some way for the sender
to indicate
to the receiver that an RF ICMP is desired. I think the way I proposed
doing that was for
the sender to set the evil bit in the IPv4 header and re-purpose that bit
as the "RF bit".
But, another way could be to include an indication at connection setup time
at a layer
above IPv4 (e.g., a TCP option).
In any event, this idea has been kicked down the road before by myself and
the earlier
pmtud researchers. There are a number of details to concern yourself with
including
assumptions of the receiver's reassembly buffer size. I have quite a large
stack of
expired drafts on pmtud that you are welcome to examine to see what ground
has
already been covered.
Fred
> -----Original Message-----
> From: Int-area [mailto:[email protected]] On Behalf Of Ron Bonica
> Sent: Tuesday, October 29, 2019 9:53 AM
> To: [email protected]
> Subject: [Int-area] FW: New Version Notification for
draft-bonica-intarea-lossless-pmtud-00.txt
>
> Folks,
>
> Please review and comment.
>
> Ron
>
>
>
> Juniper Business Use Only
>
> -----Original Message-----
> From: [email protected] <[email protected]>
> Sent: Tuesday, October 29, 2019 11:48 AM
> To: Ron Bonica <[email protected]>; Hakan Alpan <[email protected]>; Radon
Rosborough <[email protected]>; Bradely
> Newton <[email protected]>; Miles President <[email protected]>; Manoj
Nayak <[email protected]>
> Subject: New Version Notification for
draft-bonica-intarea-lossless-pmtud-00.txt
>
>
> A new version of I-D, draft-bonica-intarea-lossless-pmtud-00.txt
> has been successfully submitted by Ron Bonica and posted to the IETF
repository.
>
> Name: draft-bonica-intarea-lossless-pmtud
> Revision: 00
> Title: Lossless Path MTU Discovery (PMTUD)
> Document date: 2019-10-29
> Group: Individual Submission
> Pages: 8
> URL:
https://urldefense.com/v3/__https://tools.ietf.org/html/draft-bonica-intarea-lossless-pmtud-00__;!8WoA6RjC81c!XifH7EcqHRKXHyGSwB3ojXm6YmKn_vYWCjgM-VDTPTEzP-khJGlb9MqM8x-YTELKJ64$
>
>
>
> Abstract:
> This document describes alternative IPv4 PMTUD procedures that do not
> prevent IP fragmentation and do no rely on the network's ability to
> deliver ICMP Destination Unreachable messages to the source node.
> This document also defines a new ICMP message. IPv4 nodes emit this
> new message when they reassemble a fragmented packet.
>
>
>
>
> 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
> _______________________________________________
> Int-area mailing list
> [email protected]
>
https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!8WoA6RjC81c!XifH7EcqHRKXHyGSwB3ojXm6YmKn_vYWCjgM-VDTPTEzP-khJGlb9MqM8x-YOVqXLNE$
_______________________________________________
Int-area mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/int-area
