This actually threw me off. I was trying to understand how getaddrinfo() works, and just parsing different fields like ai_protocols when I came across this:

async-scratch-c master  ? ❯ ./build/test google.com nfs
flags  canon   family  inet6  type  stream  protocol  TCP
	host: google.com
flags  canon   family  inet6  type  datagram  protocol  UDP
	host: -
flags  canon   family  inet6  type  stream  protocol  unkown (132)
	host: -
flags  canon   family  inet6  type  seqpacket  protocol  unkown (132)
	host: -
flags  canon   family  inet  type  stream  protocol  TCP
	host: - address 142.250.206.78 port 2049
flags  canon   family  inet  type  datagram  protocol  UDP
	host: - address 142.250.206.78 port 2049
flags  canon   family  inet  type  stream  protocol  unkown (132)
	host: - address 142.250.206.78 port 2049
flags  canon   family  inet  type  seqpacket  protocol  unkown (132)
	host: - address 142.250.206.78 port 2049

now, based on the guide I was following, I had switch cases to parse stuff like so:

void print_protocol(struct addrinfo *aip) {
  printf("  protocol  ");
  switch (aip->ai_protocol) {
  case 0:
    printf("default");
    break;
  case IPPROTO_TCP:
    printf("TCP");
    break;
  case IPPROTO_UDP:
    printf("UDP");
    break;
  case IPPROTO_RAW:
    printf("raw");
    break;
  default:
    printf("unkown (%d)", aip->ai_protocol);
  }
}

So, what does the 132 stand for?

well, after digging a bit and finally finding the man page man protocols it pointed me to the right file: /etc/protocols, which tells me what that protocol is:

async-scratch-c master  ? ❯ cat /etc/protocols | grep 132
sctp         132 SCTP

great! but, looking a bit closer I see

rsvp-e2e-ignore 134 RSVP-E2E-IGNORE
udplite      136 UDPLite
mpls-in-ip   137 MPLS-in-IP
manet        138 manet
hip          139 HIP
shim6        140 Shim6
wesp         141 WESP
rohc         142 ROHC
ethernet     143 Ethernet
aggfrag      144 AGGFRAG
nsh          145 NSH
homa         146 Homa
bit-emu      147 BIT-EMU
reserved     255 Reserved

Why would 143 Ethernet be listed as a protocol? it’s a L2 protocol, not L4 like some of the other choices in this file.

Which led me to rfc 3378. What stands out to me is this section:

EtherIP may be used to enable communications between stations that
   implement Ethernet or IEEE 802.3 with a layer three protocol other
   than IP.  For example, two stations connected to different Ethernet
   LANs using the Xerox Network Systems Internetwork Datagram Protocol
   (IDP) [XNS] could employ EtherIP to enable communications across the
   Internet.

which is kind of wild. Now, the following is my lack of knowledge on the topic, but the best I can understand / theorize about this is that, there are times when it’s needed to hide L2 packets within L4 (Well, hide is the incorrect term, more like wrap), and when the kernel while stripping away layers finds this header, will start taking a different action than just keep going up the TCP/IP stack.