Adding a Custom Header between the UDP Header and the Payload

P4 Dev
1

Hello everyone,

I was wondering if it is possible to add a custom header for INT in between a UDP header and the payload after that and then parse that header in some subsequent destination. If yes, how would you do it? Cause, to parse it later, wouldn’t it be required to store some upcoming protocol identifier in the UDP header? But as far as I know, there are only four fields in the UDP header: source port, destination port, UDP length, and the UDP checksum. There are no protocol identifiers in UDP. So, how can one pull this off, if it’s even possible? How would you go about writing the code?

What I was thinking is that there is an ID field (Identification) in the IPv4 header preceding the UDP header, which I haven’t found to be very useful yet for most day-to-day purposes. I was thinking I could store a custom value in that ID field of IPv4 to parse the custom header after the UDP header. What do you think about it? I am open to any other suggestions as well.

header ipv4_t {
    bit<4>   version;  // Version (4 for IPv4)
    bit<4>   hdr_len;  // Header length in 32b words
    bit<8>   tos;      // Type of Service
    bit<16>  length;   // Packet length in 32b words
    bit<16>  id;       // Identification
    bit<3>   flags;    // Flags
    bit<13>  offset;   // Fragment offset
    bit<8>   ttl;      // Time to live
    bit<8>   protocol; // Next protocol
    bit<16>  hdr_chk;  // Header checksum
    IPv4Addr src;      // Source address
    IPv4Addr dst;      // Destination address
}

Hoping to hear from you soon. Thanks in advance.

Regards,

2

Ports are „used“ on the host side to identify the application layer protocol. Therefore you could use an officially unused - aka unassigned by Iana - UDP port to indicate that an int header follows. Of course, your int header requires to store the old port s.t. you can restore the original UDP header when you remove the int header.

Chances are small that you get a clash with your custom UDP port if selected wisely.

If you would change the identification field you might mess up Ip fragmentation.

3

Could you please kindly elaborate? I don’t think I understood what exactly you wanted to convey.

4

It is fairly common to use the UDP destination port field as a “next protocol id”, e.g. there are reserved values of UDP destination port to indicate that the header that follows is one of:

  • VXLAN (dest port=4789 decimal)
  • RoCEv2 (dest port=4791 decimal)

and several others. See List of TCP and UDP port numbers - Wikipedia for many of those values.

Those headers following the UDP header often contain a field that identifies what the header after that one is – that can vary depending upon that next header.

Whether a downstream device can parse your resulting packet is up to that downstream device. If it is one that you program yourself and has lots of flexibility in how it parses packet headers, then you should be good to go. If it is not a device that you have that kind of control over, then you’ll need to see whether the vendor supports the header sequence you create, or not.