Transport vs Carrier vs Passenger Protocols
When thinking about tunnelling, which is encapsulating one protocol with another and then transporting that encapsulated packet across a network, you’ll soon see yourself seeing terminology such as Transport, Carrier and Passenger protocols. So what is what?
The passenger protocol is the protocol you want to carry over a network that does not understand it (or you do not want the network to see it). For example, you may want to tunnel IPv6 packets over an IPv4-only network. Thus, the IPv6 would become the passenger protocol here.
The carrier protocol is the one that is used to encapsulate the passenger’s protocol packets as its own payload. In my example, tunneling IPv6 packets over IPv4 network would require that each IPv6 packet is inserted into an IPv4 packet and the resulting IPv4 packet is transported through the IPv4 network. Thus, the IPv4 becomes the carrier protocol.
Anytime we say “X-over-Y” if related to tunneling, the “X” is the passenger protocol and the “Y” is the carrier protocol, as packets of the type X are carried inside packets of the type Y. Common examples include IPv6-over-IPv4, CLNS-over-IPv4, even IPv4-over-IPv4 and so on.
The transport protocol in this case, or better said, a tunneling protocol is an additional protocol used to facilitate this tunneling. For example, putting IPv6 packets into IPv4 packets is easy and straightforward, but you may require various additional functions for this tunnel:
Multiple passenger protocols over a single tunnel. You somehow need to identify the type of the passenger protocol, and the IP Protocol header field may not have enough values to express all possible existing protocols you could tunnel over IP.
Sequencing. The IP is actually unable to make sure that tunnelled packets arrive in their original order, and it may be your requirement that the individual tunnelled packets must be processed in their original order.
Authentication. You may require that the tunnel is authenticated before transferring data over it.
Keepalives. You may require an active test whether the tunnel is indeed capable of transporting data end-to-end. The IP as a best-effort connection less protocol does not have any means to provide you with this test.https://community.cisco.com/t5/switching/routing-protocol-type/m-p/1516618/highlight/true#M149305
Dynamic session establishment and tear down, differentiating multiple sessions within a single tunnel.
If you need any of these functions then you have to use the additional tunnelling protocol. Nowadays, the most popular tunnelling protocols are GRE (Generic Routing Encapsulation) and L2TP (Layer 2 Tunnelling Protocol), not counting the MPLS Pseudowires (they are rather special and I don’t want to cover them here).
If the GRE is used then the GRE header is placed into the carrier protocol payload just before the passenger protocol datagram comes in. If you create an IPv6-over-IP tunnel using the GRE tunnelling protocol, the resulting packet would look like: