2

In the IANA registery for "Protocol Numbers", there listed 2 IP protocol versions: IPv4 at #4 and IPv6 at #41. Their "protocol" column says IPv[46] Encapsulation, and "reference" column points to 2 RFCs.

The 1st one, RFC 2003 specifies method for encapsulating IPv4 using IPv4, the 2nd one, RFC 2473 specifies quote: "Generic Packet Tunneling in IPv6 Specification", and contains a minimal example of IPv6 in IPv6 for illustration.

The 2 RFCs caused much confusion for me as they seem to indicate that IPv4 can only be encapsulated in IPv4 and IPv6 in IPv6.

Questions. (Updated, merged 1 and 2, reworded 3)

  1. What do these 2 code points mean in internet protocols? Do they indicate that the immediate payload is IPv4 (#4) or IPv6 (#41) headers? Or do they have to be interpretated rigidly according to the 2 old RFCs.

  2. Is there benefit treating IPv4 and IPv6 as seperate protocols instead of different versions of the same protocol? Can any such benefit be also applicable to EtherType in Ethernet? (I'm asking this because IPv4 and IPv6 can already be identified by their leading 4 bits)

  • I'm not really sure what you mean. You have three different tunneling protocols that each do different things. The protocol numbers tell IP to which process it should send the packet payload (the same thing for an Ether Type to tell the data-link protocol to which process it should send the frame payload). – Ron Maupin Nov 25 '19 at 6:37
  • Which protocols do you mean when you ask, "Is there benefit treating them as separate protocols instead of different versions of the same protocol?" IPv4 and IPv6 are two completely separate, incompatible protocols. – Ron Maupin Nov 25 '19 at 6:38
  • @RonMaupin Updated for the 2nd comment. "The protocol numbers tell IP to which process it should send the packet payload" is almost an answer for me, the remaining part is to clarify what the role 2 old RFCs play here. – DannyNiu Nov 25 '19 at 6:51
1
  1. What do these 2 code points mean in internet protocols? Do they indicate that the immediate payload is IPv4 (#4) or IPv6 (#41) headers? Or do they have to be interpretated rigidly according to the 2 old RFCs.

The protocol number is in the Protocol field of the IPv4 packet header, and in the Next Header field of the IPv6 packet header. The protocol number tells IP (either IPv4 or IPv6) to which process it should pass the payload of the packet. If a process has not registered with the appropriate IP process, the packet is dropped, and normally an ICMP error message is sent back to the source.

  1. Is there benefit treating IPv4 and IPv6 as seperate protocols instead of different versions of the same protocol? Can any such benefit be also applicable to EtherType in Ethernet? (I'm asking this because IPv4 and IPv6 can already be identified by their leading 4 bits)

IPv4 and IPv6 are completely separate, incompatible protocols. The IPv4 process has no idea what to do with an IPv6 packet, and vice versa. Each protocol is handled by a different process, and many hosts will have one but not the other.

The Ether Type, for protocols that use such, has a similar function to the protocol number. It tells the Data-Link protocol to which process it should send the frame payload. If the Ether Type is a number not registered with the Data-Link protocol, then the frame is simply dropped. For example, a host receiving a Data-Link frame with the Ether Type 0x86DD that is not running IPv6 would simply drop the frame.


You have different tunneling protocols for different things. Your examples include tunneling IPv4 inside IPv4, IPv6 inside IPv6, and IPv6 inside IPv4. Each protocol is different because each needs to know what payload to expect so that it knows what to do with the payload. There is also GRE that has a field in its header that is the same as the IPv4 Protocol (or IPv6 Next Header) field, and that tells the GRE process to which process it should send the payload. There are many different tunnel protocols, each created by someone to fill a perceived need. Choose the one that is supported by your OS (on both ends) that does what you need it to do. Cisco created GRE to be a generic (hence the "G" in GRE) tunneling protocol.

  • As far as I remember, IPv6 is not named "IPv5" because the first 4 bits of an IP packet are the IP version (4 or 6) and the value 5 was already used for some different data type. If I interpret this statement correctly, there are some cases where the first 4 bits of the packet (and not the EtherType) are used for distinguishing between IPv4, "Type 5" and IPv6 packets. If I understand point (2) correctly, the OP also wants to know why you don't use the same EtherType value for IPv4 and v6 and distinguish IPv4 and v6 by the first 4 bits of the IP packet. – Martin Rosenau Nov 25 '19 at 20:42
  • Actually, IPv4 is really the first version of IP and IPv6 is really version 2. IPv4 was simply IP until IPNG (IPv6), and the two different versions adopted the version number in the header for the names. As I explained, the Ether Type will get the packet to the correct process. The IPv4 process does not know what to do with an IPv6 packet, and there may not even be an IPv6 process, so the data-link protocol would just drop the frame altogether, rather than sending it to a different process. – Ron Maupin Nov 25 '19 at 21:05
  • @MartinRosenau, IANA has the Version Numbers page. Versions 2, 3, and 10 to 14 are available for assignment. – Ron Maupin Nov 26 '19 at 23:52
  • You did not get my point: The IPv4 header has a "version" field while the IPX header does not have one. The IETF could have decided to define the IPv6 header without a "version" field just like IPX. In this case there would have been no reason for the "strange" version numbers "4" and "6" for the first two versions but they could have named IPv4 "IPv1" (with the "version" field set to 4) and IPv6 "IPv2" (having no "version" field at all). ... – Martin Rosenau Nov 27 '19 at 7:41
  • It only makes sense to use that field. When the IPv4 process receives a packet, the first thing it checks to see is if the version field is a 4. If it is not, then it discards the packet as damaged. If IPv6 did not have a non-4 in that field (no telling what the number could be if that position was used for something else, and could possibly end up as a 4), then the IPv4 process receiving a packet with a 4 in that field position would try to process the packet, wasting resources. Having a specific non-4 (6 in this case) in that position keeps it straight. – Ron Maupin Nov 27 '19 at 7:46

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.