Re: [v6ops] Operational Implications of IPv6 Packets with Extension Headers - Load Balancer

[Tom Herbert <[e-mail]>]

On Tue, Jul 28, 2020 at 11:14 PM Fernando Gont <[e-mail]> wrote:
>
> Hi, Brian,
>
> On 29/7/20 01:03, Brian E Carpenter wrote:
> [....]
> >> It seems evident that the IPv6 packet structure makes a cost-effective
> >> implementation rather difficult. Since engineering does not only have to
> >> do with science, but also with economics, it follows that:
> >>
> >> * Folks (group #1) will not be willing to pay for features that their
> >> clients do not explicitly require.
> >>
> >> * Vendors (group #2) will not spend cycles on something which will not
> >> get them money in return.
> >>
> >> * Other set of folks (group #3) will not actively try to leverage
> >> features with a high failure rate, since they would also need to
> >> implement workarounds -- and if the workarounds already solve the
> >> problem, with a much higher success rate, there's not much of a point in
> >> spending time (and ultimately $$) in the feature that usually fails.
> >>
> >> * Users (group #4) use whatever solves their problem.
> >>
> >>
> >> We may be unhappy with the above fact. But unless we're willing to pay
> >> the bill :-), I'm not sure to what extent embarking into a Crusade would
> >> solve the "problem".
> >
> > Not what I meant, really.
>
> FWIW, I do agree with you. My comment was a response to Tom where he was
> objecting to folks that, for one reason or another, happen to drop
> packets. (in this particular case the advice given by JOel in his
> presentation)
>
> And what I meant is that rather that being mad about them, one should
> try to find the reasons for which they are resorting to that (which is
> what this document is meant to), and then figure out and do what we can
> from a protocol engineering perspective.
>
Fernando,

I agree with that and I do appreciate that section 3 of the draft
describes several of the mitigations to make EH processing more
palatable like the provision of RFC8200 that allows nodes to ignore
HBH and the limits in RFC8504. It might be helpful in the draft to
mention the relevant mitigations when discussing specific reasons for
drops. For instance, if DOS is being discussed then RFC8504 should be
mentioned in reference since the one purpose of limits on number of
options is to mitigate DOS attacks (i.e. without limits an attacker
could fill an MTU with 100s of unknown HBH options that an
implementation, SW or HW, will choke on it).

Another area that should be elaborated here, or maybe necessitates a
separate document, is the parsing buffer problem described in section
5.1.1 by "If an IPv6 header chain is sufficiently long that its header
exceeds the packet look-up capacity of the router, then it may be
dropped due to hardware inability to determine how it should be
handled.". I believe this is a real problem, but it's never been
quantified. For instance, when a host creates a packet how can it
possibly guess than some router in the path will drop the packet
because the header chain is too long (not just IPv6 header chain by
the way, but really all headers a node needs to process which can
include transport or even transport payload). The draft for sending
ICMP errors when packets are dropped is in the RFC editor queue, but I
believe we can provide some sort of guidance that intermediate nodes
are expected to be able to process at least X bytes of headers. This
probably needs to broken down by what headers nodes process: a
forwarding node might just look at IPv6 header and HBH options, an
intermediate destination needs to look at routing header, a stateful
firewall needs to get transport header, and application layer firewall
needs to go even farther, etc.

Tom


>
>
> > All we can do here is write documents. So if
> > the consensus is still what the standards track documents say, including
> > Node Requirements, we have actually done our duty.
>
> That's in part correct. However, for cases where standards track
> documents implementation become unfeasible or cost-ineffective, one may
> need to consider being more flexible and reconsider the spec.
>
> A good example was the IPsec requirement in an early revision of Node
> Reqs: it was words on paper that would never be complied with - so the
> spec was changed to reflect that.
>
> I'm not necessarily saying that this is the case here, but rather that
> that's an option that should be on the table.
>
>
>
> > And we have, in RFC8504:
> > "All nodes SHOULD support the setting and use of the IPv6 Flow Label
> > field as defined in the IPv6 Flow Label specification [RFC6437].
> > Forwarding nodes such as routers and load distributors MUST NOT
> > depend only on Flow Label values being uniformly distributed.
>
> I retrospective, if it cannot depend on the FL (which I agree), is there
> much of a point in using it?
>
> Thanks,
> --
> Fernando Gont
> SI6 Networks
> e-mail: [e-mail]
> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492
>
>
>
>