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

[Tom Herbert <[e-mail]>]

On Fri, Jun 11, 2021 at 4:13 AM Vasilenko Eduard
<[e-mail]> wrote:
>
> Hi all,
> I was silent reading this discussion because it is pretty much a useless exercise.
> 95% of Telco traffic is the Best Effort (nobody pays a penny for additional services).
> Additional headers processing has the cost:
> - develop a new feature
> - test a new feature
> - implement a new feature
> - support a new feature
> And accept the responsibility for additional different risks (security, performance, interoperability).
>
> Never-ever EH would work on the Internet till the Telco business model would change. Dump pipe does not need it.
> It is true for half of the latest development in the IETF (especially for anything QoS-related).
>
> Hence, fancy IPv6 functionality should be convenient only for closed domains.
> It is primarily Enterprises where business case calculation for everything activated is not so strict.
> Enterprises have much more traffic that is considered important for many reasons.
>
> IMHO:
> HbH in its current specification is perfectly fine for a closed domain.

> If you would change it in any way that was discussed here - it would be still fine for a closed domain.
> Of course, I could be wrong here because IPv6 popularity in the Enterprise is still close to 0%.
> Hence, we do not know what Enterprise would need when they move to IPv6.
> Unfortunately, such discussion is not popular here. It is primarily here about how to fix what is not possible to fix.
>
Eduard,

The only thing we can possibly fix in this forum are the protocol
specifications for IPv6. To that end, there's only one specification
for IPv6 which applies to all use cases of the protocol in that the
protocol does not distinguish between teco network, home networks,
enterprise networks, the Internet as a whole, or closed networks
(bifurcating the standard specifications between limited domains and
the open Internet has thus far been rejected). Given this context of
the WG, it is reasonable to try to update the protocols to address the
apparent gap wrt to extension headers between the protocol standards
and what is widely deployed. This is precisely what this draft and
this discussion is attempting to do.

Tom

> PS: it makes sense to drop testing "best effort pipe" for fancy services for not to disappoint ourselves.
> Eduard
> -----Original Message-----
> From: ipv6 [mailto:[e-mail]] On Behalf Of Pascal Thubert (pthubert)
> Sent: Friday, June 11, 2021 9:59 AM
> To: Fernando Gont <fernando.gont=[e-mail]>
> Cc: [e-mail]; [e-mail]; [e-mail]
> Subject: RE: New Version Notification for draft-hinden-6man-hbh-processing-01.txt
>
> 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
> >
> >
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------