Re: [IPv6] sendmsg() for HBH ? Re: Removing extension headers from packets (revisited)

[JINMEI Tatuya / 神明達哉 <[e-mail]>]

> But I am not sure about TCP because the packetization is done by the kernel.

If it's about RFC3542, it clarifies that ancillary data can't be used
on a TCP socket:

   It is not possible to use ancillary data to transmit the above
   options for TCP since there is not a one-to-one mapping between send
   operations and the TCP segments being transmitted.  Instead an
   application can use setsockopt to specify them as sticky options.
   When the application uses setsockopt to specify the above options it
   is expected that TCP will start using the new information when
   sending segments.  However, TCP may or may not use the new
   information when retransmitting segments that were originally sent
   when the old sticky options were in effect.

As for requiring the privilege, RFC3542 didn't intend to necessarily
require it for the general case
(it explicitly states so if a special privilege is required for some
specific part of API), but it notes
that the use of certain HbH options might require it:

   Finally, we note that use of some Hop-by-Hop options or some
   Destination options, might require special privilege.  That is,
   normal applications (without special privilege) might be forbidden
   from setting certain options in outgoing packets, and might never see
   certain options in received packets.

Of course, it's not surprising if an implementation doesn't fully
follow what the RFC says.

--
jinmei

On Mon, Aug 21, 2023 at 12:55 AM Shihang(Vincent)
<shihang9=[e-mail]> wrote:
>
> Hi Tom,
>
> I wonder if the sendmsg() can set the EH header on a per-packet basis, with different extension headers for each packet? My understanding is that it is doable for UDP since the packetization is done at user space.  The ancillary data can be associated to each datagram. But I am not sure about TCP because the packetization is done by the kernel.
>
>
>
> Thanks,
>
> Hang
>
>
>
> From: ipv6 <[e-mail]> On Behalf Of Tom Herbert
> Sent: Friday, August 18, 2023 10:14 PM
> To: Toerless Eckert <[e-mail]>
> Cc: 6MAN <[e-mail]>
> Subject: Re: [IPv6] sendmsg() for HBH ? Re: Removing extension headers from packets (revisited)
>
>
>
>
>
> On Fri, Aug 18, 2023, 12:42 AM Toerless Eckert <[e-mail]> wrote:
>
> Btw:
>
> Does anybody here know, what the current state of affairs is re.
> OS-level unprivileged host applications using UDP or TCP (OS) sockets to be able
> to insert HBH headers vis sendmsg() (particles) ?
>
> I think to remember that a couple of years back, when i know some
> folks looked last, not all the OSs (linux, android, windows, iOS/macos)
> did support insertion of extension headers via sendmsg() for
> UDP or TCP socket - unless the process had admin privileges.
>
>
>
> Hi Toerless,
>
>
>
> Yes, admin privileges are need to set EH in Linux. I have patches to fix that and am planning to push them at some point.
>
>
>
>
> Not too difficult to fix IMHO, but if this problem still exists,
> then i think it would help quite a bit if there was an IETF RFC
> that clearly stated that HBH headers are meant to be something that
> MUST be allowed for user (non-privileged) applications in support
> of application-to-network signaling. Otherwise we may be dragged into
> ongoing discussion of fear of risk with OS developers.
>
> And of course, we have to persuade ourselves, that such a statement
> would be appropriate - and write such an RFC.
>
> Of course, this discussion is orthogonal to whether or not we want to
> remove HBH headers along the path, but i for once think that any effort
> to do cool future stuff with HBH is predicated on first agreeing that we want
> OS-level unprivileged applications to unsert them. Otherwise we're just
> again building some useless corner solution that will never get widely deployed.
>
>
>
> Yes, fortunately OS support doesn't require and standards action.
>
>
>
> Tom
>
>
>
>
> Cheers
>     Toerless
>
> On Mon, Aug 14, 2023 at 01:12:40PM -0700, Tom Herbert wrote:
> > Hi 6man,
> >
> > I know this topic of removing extension headers has been brought up
> > before, but I think in light of some emerging use cases it might be
> > worth revisiting.
> >
> > draft-herbert-fast and draft-media-hdr-wireless describe host to
> > network signaling. Both of these use Hop-by-Hop extension headers
> > (draft-media-hdr-wireless currently specifies using UDP options, but
> > could be HBH). A common attribute of these is that the information in
> > Hop-by-Hop options is only relevant in the local network of the
> > source. More specifically, it might only be relevant to the first hop
> > router in a provider network to process the options. After processing
> > by that router, the Hop-by-Hop option just along for the ride, no
> > other nodes in the path care about it and the end node probably
> > doesn't care either.
> >
> > Segment routing has a similar property. Once the final segment is set
> > in the Destination Address, the segment routing header contains no
> > useful information to downstream nodes.
> >
> > In both these cases, as long as the destination is in the same domain
> > as the sender, we expect things to work. For EH it's a statement of
> > practicality because of perceived drop rates on the Internet, for
> > segment routing it's inherent in the design for segment routing
> > domains. So this raises the question, what happens if a sender sends
> > to a destination out of its local domain and still wants services
> > applied to packets while they're in the local domain, or what if
> > segment routing is used to route a packet to an egress point in the
> > segment routing domain that then traverses the Internet.
> >
> > Could it be acceptable for routers to remove HBH EH or routing header
> > EH when a packet exits a limited domain? I realize this is contrary to
> > RFC8200 and might be considered an architectural abomination, but on
> > the other hand this might be a practical way to improve the
> > deployability of extension headers without any material adverse side
> > effects (other than packets being dropped which might happen anyway if
> > packets with EH escaped the limited domain).
> >
> > Comments?
> >
> > Thanks,
> > Tom
> >
> > --------------------------------------------------------------------
> > IETF IPv6 working group mailing list
> > [e-mail]
> > Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> > --------------------------------------------------------------------
>
> --
> ---
> [e-mail]
>
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [e-mail]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------