Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt

2019-10-31 Thread Joe Touch


> On Oct 31, 2019, at 5:07 PM, Erik Kline  wrote:
> 
> It may be folly to try to modify IPv4 implementations at this point.   I have 
> no objections if you wish to try pushing this big rock up hill, but I doubt 
> you will be successful.
> 
> BTW, what *actually* prevents a middlebox from doing IPv6 fragmentation? 

Expecting it to work. That middlebox has no idea what packets are going through 
other middleboxes from the same endpoint. There’s no way it can pick IDs to 
avoid collision, the way the origin can. That’s why both IPv4 and IPv6 rely on 
the origin creating those IDs.

The result would either be significantly increased reassembly errors, sort of 
like accidental poisoning of the receiver’s cache, or potentially resulting in 
incorrect packets (the latter could be more likely in some cases, e.g., when 
the fragment happens to have a zero IP checksum).

Joe

___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt

2019-10-31 Thread Erik Kline
>
> It may be folly to try to modify IPv4 implementations at this point.   I
> have no objections if you wish to try pushing this big rock up hill, but I
> doubt you will be successful.
>

BTW, what *actually* prevents a middlebox from doing IPv6 fragmentation?
In other words, if some box "decided to be helpful" and do IPv6
fragmentation in the middle, would anything really break (*other* than the
obvious existing problem with fragment extension headers not being
forwarded to their destination)?

I'm wondering about whether this work might be applicable to v6 as well,
even if just for parity.
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


[Int-area] FW: New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt

2019-10-31 Thread Ron Bonica


Updated draft


Juniper Business Use Only

-Original Message-
From: internet-dra...@ietf.org  
Sent: Thursday, October 31, 2019 3:15 PM
To: Ron Bonica ; Hakan Alpan ; Radon 
Rosborough ; Bradely Newton ; Bradley 
Newton ; Miles President ; Manoj Nayak 

Subject: New Version Notification for draft-bonica-intarea-lossless-pmtud-01.txt


A new version of I-D, draft-bonica-intarea-lossless-pmtud-01.txt
has been successfully submitted by Ron Bonica and posted to the IETF repository.

Name:   draft-bonica-intarea-lossless-pmtud
Revision:   01
Title:  Lossless Path MTU Discovery (PMTUD)
Document date:  2019-10-31
Group:  Individual Submission
Pages:  7
URL 
https://tools.ietf.org/html/draft-bonica-intarea-lossless-pmtud-01
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
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area


Re: [Int-area] New Version Notification for draft-bonica-intarea-lossless-pmtud-00.txt

2019-10-31 Thread Ron Bonica
Joe,

You have a point that this solution may never be widely deployed. So, I have 
cranked the intended status back to EXPERIMENTAL and removed the IANA request. 
(We can work with experimental code points.)

We will do the experiment and report on results.

 Ron


Juniper Business Use Only

-Original Message-
From: Joe Touch  
Sent: Wednesday, October 30, 2019 12:44 AM
To: Ron Bonica 
Cc: int-area@ietf.org
Subject: Re: [Int-area] New Version Notification for 
draft-bonica-intarea-lossless-pmtud-00.txt

Hi, Ron,

A few things come to mind. The first one, IMO, renders the rest somewhat less 
important.

Joe

-

- this approach applies only to IPv4; not sure it’s worth trying to optimize 
for only that case
(it requires on-path fragmentation permitted)

- this approach relies on ICMPs, so it’s as robust (or, more to the point, not) 
as PMTUD
if ICMPs can find the reverse path from the dest, why wouldn’t the 
routers?
i.e., isn’t the problem with ICMPs not just routers not sending them 
but firewalls BLOCKING them?
(i.e., if ICMPs would work here, PMTU would have worked, rendering this 
unnecessary)

- why does this doc assume the max ICMP is 576?
we’re still talking IPv4 here; it’s still 68 (that’s why only 64 bits 
of the orig payload are guaranteed)
(yes, your note in the end of sec 1 is relevant, but given v4-in-v4 
tunneling, it’s possible that paths might be smaller than the 576 assumption)

- why would this approach find the largest fragment through a system?
rfc1812 talks about various strategies, one of which is “equal sized”, 
which might never find the max the way you propose 


> On Oct 29, 2019, at 9:53 AM, Ron Bonica 
>  wrote:
> 
> Folks,
> 
> Please review and comment.
> 
>Ron
> 
> 
> 
> Juniper Business Use Only
> 
> -Original Message-
> From: internet-dra...@ietf.org  
> Sent: Tuesday, October 29, 2019 11:48 AM
> To: Ron Bonica ; Hakan Alpan ; Radon 
> Rosborough ; Bradely Newton ; Miles 
> President ; Manoj Nayak 
> 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!SaG54qXv3mOmFFinOp93hDtn-j4u5ZzUbomMfaHAujluBDj7pJq_RtQMALmTf6K4$
>  
> 
> 
> 
> 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
> Int-area@ietf.org
> https://urldefense.com/v3/__https://www.ietf.org/mailman/listinfo/int-area__;!8WoA6RjC81c!SaG54qXv3mOmFFinOp93hDtn-j4u5ZzUbomMfaHAujluBDj7pJq_RtQMAGjVmADJ$
>  
___
Int-area mailing list
Int-area@ietf.org
https://www.ietf.org/mailman/listinfo/int-area