Re: Turning routers into hosts (Re: Death by extension header (was:RE: New Version Notification for draft-li-6man-hbh-fwd-hdr-00.txt))

On Mon, Jul 13, 2020 at 8:15 PM Brian E Carpenter <
brian.e.carpenter@gmail.com> wrote:

> On 14-Jul-20 09:23, Mark Smith wrote:
> > On Tue, 14 Jul 2020 at 06:02, Toerless Eckert <tte@cs.fau.de> wrote:
> >>
> >> On Mon, Jul 13, 2020 at 03:00:44PM -0300, Fernando Gont wrote:
> >>> On 10/7/20 15:32, Toerless Eckert wrote:
> >>>> IMHO: See my email earlier in the thread about punting stuff to
> slow-path, especially when/before
> >>>> you figure out that you should have just ignored something at
> linerarte.
> >>>>
> >>>> Aka: not sufficiently prescriptive RFCs + bad implementations ==
> extension header based features killed in deployments.
> >>>
> >>> Indeed. And add to that that the EH structure itself seems to be rather
> >>> unfriendly with some popular hardware architectures. (unless with "not
> >>> sufficiently prescriptive RFCs" you are meaning to set the maximum
> EH-header
> >>> chain length to some sane value that folks might agree to comply with).
> >>
> >> I think we might want to start with a draft collecting what we think to
> >> kow about the problem and figure out if we can structure it accordingl
> >> to make sense out of it to make progress that is not just incrementally
> fixing
> >> one single bit.
> >>
> >
> > I think one of the first sections needs to be titled:
> >
> > "Turning Routers into Hosts"
>
> Are you sure you don't mean "Turning Routers into Packet Manglers"?

... are you sure you don't mean "Turning Routers into Smoking Holes in the
Ground"

Regards,
  An operator of a device that tried to punt packets to the slow path.

>
> Regards,
>    An author of RFC3234

> >
> > because in-flight processing of packets' EHs, payloads etc, rather
> > than just dumb, fast and simple forwarding them, is host processing of
> > packets.
> >
> > How to tell it's host processing?
> >
> > - processing of packets requires going past the IPv6 fixed header
> >
> > - in-flight processing would fail if everything but the fixed header
> > was encrypted
> >
> > - processing beyond the fixed (forwarding) header is occuring at a
> > node that *doesn't* hold the packet's destination address:
> >
> >
> > RFC8200:
> >
> > router       a node that forwards IPv6 packets not explicitly
> >                 addressed to itself.  (See Note below.)
> >
> >    host         any node that is not a router.  (See Note below.)
> >
> > (Note is about a node's interfaces being forwarding or not)
> >
> >
> > In this discussion and similar, people are really discussing paths
> > between a packet's original source and a final destination constructed
> > of a set of packet host processing hops.
> >
> >
> > Regards,
> > Mark.
> >
> >
> >
> >> Cheers
> >>     Toerless
> >>
> >> --------------------------------------------------------------------
> >> IETF IPv6 working group mailing list
> >> ipv6@ietf.org
> >> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> >> --------------------------------------------------------------------
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > ipv6@ietf.org
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
> >
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------
>

-- 
I don't think the execution is relevant when it was obviously a bad idea in
the first place.
This is like putting rabid weasels in your pants, and later expressing
regret at having chosen those particular rabid weasels and that pair of
pants.
   ---maf