Re: End-to-end (was Re: Non-Last Small IPv6 Fragments)

[Tom Herbert <[e-mail]>]

On Wed, Jan 16, 2019 at 8:36 AM Fernando Gont <[e-mail]> wrote:
>
> On 16/1/19 12:41, Tom Herbert wrote:
> > On Tue, Jan 15, 2019 at 11:52 PM Fernando Gont <[e-mail]> wrote:
> >>
> >> On 15/1/19 19:42, Tom Herbert wrote:
> >> [....]
> >>> packets. This uses a modifiable HBH options and is completely
> >>> idependent of the transport layer.
> >>
> >> You cannot use HBH in the public Internet. Well, you can... but there
> >> high chances your packets will be dropped.
> >>
> > Fernando,
> >
> > By that same thinking we can't use any extension headers at all,
>
> Indeed.
>
>
>
> > any
> > transport protocol other then TCP (and maybe UDP), ICMP, the TCP
> > authentication option, TCP fast open, UDP options, or even IPv6 on the
> > Internet.
>
> I assume that such options focus on specific scenarios (e.g. TCP-AO for
> BGP), or they have fall-back options (e.g. traditional open for TCP-FO).
> Otherwise they are doomed to fail.
>
>
>
> > As for HBH, RFC8200 relaxed the requirement that intermediate nodes
> > need to process them. If a node just wants to get to the transport
> > layer it can skip over the EH very with a few simple operations. I see
> > no excuse for new devices being deployed to systematically drop HBH or
> > destination options EHs. If they are  doing that then their
> > implementation does not comply with the IPv6 standard and we shouldn't
> > have any compunction about publically calling them out on that.
>
> See https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops
>
> The folks running the networks have work to do. And will certainly not
> pay extra money for functionality that somehow is currently not
> required. Vendors will not invest extra to sell devices at the same price.
>
I'm not sure what you mean by "functionality that somehow is currently
not required.". Who determines what is required?

> We can call them out. Vendors for selling boxes that perform very badly
> for packets that contain EHs, and operators for "looking into packets in
> the middle of the network, breaking the sacred e2e principle (or some
> interpretation of it)".
>
> Then I guess *we* will be called out to pretend doing engineering, while
> doing stuff that doesn't work in practice.
>
There is engineering happening. The requirement that every node needs
to process HBH options where there could be hundreds of options in a
single packet was, in retrospect, completely impractical to expect to
be supported. So, RFC8200 relaxed the nodes must process requirement,
and we can define some reasonable limits as to how many options can be
processed. These are examples of updating standards that make
engineering feasible.

> We burying our heads into sand doesn't help the situation, either...
>

Agreed. If someone were to *prove* conclusively that it is impossible
to support even the minimum requirement that allows device to skip
over HBH options, then I would agree that it may make sense to give up
and deprecate them. But until we have that proof in hand, the problem
is real and needs to be dealt with.

Tom

> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>