[P4-discuss] How to parse received IPv6 extension headers, but preserve order when sending them?

Mihai Budiu mbudiu at vmware.com
Tue Feb 21 17:06:54 EST 2017

There is no simple and efficient way to do this in either p4. We discussed header unions in p4-16, but they are not in the language yet. I think this is the most useful feature missing from the  language. You would store the options in a stack of header unions, where each union has one of all possible options, and each option is a different header. Hopefully the design committee will reach a consensus on this topic soon.


From: Andy Fingerhut<mailto:andy.fingerhut at gmail.com>
Sent: Tuesday, February 21, 2017 11:36 AM
To: p4-discuss at lists.p4.org<mailto:p4-discuss at lists.p4.org>
Subject: [P4-discuss] How to parse received IPv6 extension headers, but preserve order when sending them?

If there are code examples of this out there somewhere, I'd appreciate a pointer.

For those unfamiliar with IPv6 extension headers, basically there is a 40-byte fixed length base IPv6 header in all IPv6 packets, and inside of that base header, the 8-bit Next Header fields indicates the type of the following header, similar to the IPv4 Protocol field.

Often that Next Header will indicate TCP or UDP, but there can optionally be a sequence of 1 or more IPv6 extension headers, e.g. Destination Options, Routing, Hop-by-Hop, Fragment, Authentication, and ESP being the most common ones I know about.  The link below gives more details written by someone at Cisco, for anyone curious about it (that document doesn't have the weight of an RFC behind it -- it is simply a nice write-up of many facts):


While that link mentions that there is a recommended order that the different types of IPv6 extension headers should appear in a packet, it is reasonably common for existing router implementations to allow and pass through non-recommended orders, too.

It looks straightforward to write a P4 parser that can use the Next Header and Header Extension Length field at the beginning of each IPv6 extension header.  If one wanted to keep parsing until one reached a TCP or UDP header, for example, then stop, then that looks easy to do, at least if you don't want to do anything with the extension headers other than skip over them (which is a reasonably common use case -- to get the TCP or UDP source/dest port for ACL classification).

It even looks straightforward to do this, even if one wants to allow these IPv6 extension headers to appear in the received packets in an arbitrary order.

What is not so obvious to me is: is there a way to write in P4: Send out these parsed headers unmodified, _in the same order they were received_, even when they can be received in different orders for different packets?  Also, even if some of the header types appear more than once (e.g. even in the recommended order at the link above, Destination Options can appear twice).

For P4_14, where the deparser is either implicit, or there can be pragmas that help specify an output order, it isn't clear to me how one can specify 'send out the headers in the order they were received, even if that order is different from one received packet to the next'.

For P4_16, where the deparser is explicit, it seems possible to do, but only by somehow storing the order that these headers were received in, in some metadata field, and then using that stored order in the deparser to emit the headers (e.g. a metadata field that effectively stored a stack of 8-bit Next Header values, although you would need even more than that to handle more than one occurrence of the same Next Header value).


-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.p4.org/pipermail/p4-discuss_lists.p4.org/attachments/20170221/9fd90927/attachment-0002.html>

More information about the P4-discuss mailing list