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

[Vasilenko Eduard <[e-mail]>]

Tom, "anything" means anything.
1) or 2) from your list and all other choices too.
What is the problem to test everything properly and activate it now for one domain where the business case exists?
Such admin would probably filter everything out at borders. Exactly as it is recommended by SRH spec (and many others).
Ed/
-----Original Message-----
From: Tom Herbert [mailto:[e-mail]] 
Sent: Friday, June 11, 2021 9:55 PM
To: Vasilenko Eduard <[e-mail]>
Cc: [e-mail]
Subject: Re: New Version Notification for draft-hinden-6man-hbh-processing-01.txt

On Fri, Jun 11, 2021 at 11:29 AM Vasilenko Eduard <[e-mail]> wrote:
>
> Hi Tom,
> I was probably not clear.
> I do not propose to develop something special for "closed domains". The spec should be unified.
> I am just doubtful that it makes sense to look at what is going on the public Internet. It does not matter.
> It makes sense to look for advanced functionality to closed domains only.
> One Carrier could be a valid use case too.
> PS: I do not see any trouble now for 1 carrier to activate anything from EHs (including HbH). After Carrier would pay the price.

Eduard.

It really depends on what you mean by "activate anything from EHs".
There are at least two possible interpretations: 1) Process the EHs like HBH 2) Forward packets containing EHs without doing anything with them. For the viability of EHs, including future use cases, we mostly care about interpretation #2. This really just means we want nodes to ignore packets with extension headers instead of dropping them.
According to the data in RFC7872 that mostly is already happening (e.g. 90% of packets with Destination Options we're being successfully delivered at least five years ago). RFC8200 has already relaxed the requirement that all nodes in the path need to process HBH, so so aside from an explicit policy, the biggest impediment is in implementation for those intermediate nodes that need to access the transport layer and if the necessary headers don't fit in the parsing buffer they may drop the packet. The solution to that, I believe, is to set a requirement specifying the maximum length IP header chain (e.g. 104 bytes including IPv6 header) that nodes must support if they are accessing the transport layer.

Tom

> Eduard
> -----Original Message-----
> From: Tom Herbert [mailto:[e-mail]]
> Sent: Friday, June 11, 2021 5:50 PM
> To: Vasilenko Eduard <[e-mail]>
> Cc: [e-mail]
> Subject: Re: New Version Notification for 
> draft-hinden-6man-hbh-processing-01.txt
>
> 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
> > --------------------------------------------------------------------