RE: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

["Pascal Thubert (pthubert)" <[e-mail]>]

Hello Fernando

How that that so different from the PMTUD problem? When the route changes, the end-to-end MTU may change too.

Similarities:

- there are places were you won't even try to guess; 6LoWPAN decided to use an MTU of 1280 and will not try PMTUD; for HbH, as Brian suggests, it might be that the Internet at large is the wrong place to try it.

- there are flows and use cases that can really benefit from it, so keeping the lowest common denominator in all circumstances seems utterly wasteful.

- the concept of domain that Brian mentioned is intuitively the thing we're after. But the domain scope is not always very clear. So exploration can help.

Note that adding a HbH OH in an existing PMTUD / MSS exploration does not require a change in the intermediate routers and middle boxes. We do not need an RFC for that, anyone can try it already. 

draft-ietf-6man-mtu-option seems to serve the purpose as a side effect, though clarifying that other options can be placed in the HbH OH to experiment whether those options are also supported along the path seems like a good idea, e.g., for options with the leftmost bit set to 1 (act = 0b1O or act = 0b11).    

Keep safe;

Pascal

> -----Original Message-----
> From: Fernando Gont <fernando.gont=[e-mail]>
> Sent: vendredi 11 juin 2021 7:21
> To: Pascal Thubert (pthubert) <[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail];
> [e-mail]; [e-mail]
> Subject: Re: New Version Notification for draft-hinden-6man-hbh-processing-
> 01.txt
> 
> Hi, Pascal,
> 
> On Fri, 2021-06-11 at 05:00 +0000, Pascal Thubert (pthubert) wrote:
> > This might need a solution be similar to the MTU problem; e.g., during
> > PMTUD a node might add the HbH Options that it needs to check that the
> > options make it through…
> 
> Aside from a bunch of other evil details:
> 
> WHat if, say, you employ this solution at, say, connection- establishment
> time, find that EHs actually "work" towards your destination, but them,
> sometime later, the path to your destinationchanges, and you find out that
> EHs no longer work?
> 
>      Abort the transaction/connections?
>      "Migrate" from EH-based mechansim to the fall back mechanism?
>      Anything else?
> 
> What about the impact on e.g. RTT for connection-establishment? What about
> the complexity of the mechanism? How many bugs/vulns before every
> implementation gets it right?
> 
> Truth #3 of https://datatracker.ietf.org/doc/html/rfc1925 comes to mind...
> 
> Thanks!
> 
> Regards,
> --
> Fernando Gont
> Director of Information Security
> EdgeUno, Inc.
> PGP Fingerprint: DFBD 63E3 B248 AE79 C598 AF23 EBAE DA03 0644 1531
> 
> 
>