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

["Shihang(Vincent)" <[e-mail]>]

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]<mailto:[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]<mailto:[e-mail]>
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

--
---
[e-mail]<mailto:[e-mail]>