[ih] [ipv6] IP versions explained

[Steve Deering]

> On Nov 7, 2009, at 9:54 AM, Steve Wilcox wrote:
>> ... I think what happened in the 90s and before is not well  
>> recorded.. perhaps time to write it up? :-)

Regarding the '90s and IP version numbers greater than 4...

Version 5 was assigned to the Stream Protocol, ST (see RFC 1190).  ST  
was designed not as a successor to IP, but rather as a companion  
protocol to IP, providing a stream- or circuit-oriented internet-layer  
service.   It used the same ether-type as IP, and relied on the IP  
version number (first 4 bits of the header) to distinguish ST from  
IP.  There were multiple implementations of ST, and it was used in the  
'80s and '90s to support experiments (and perhaps production use?) in  
"real-time" applications such as teleconferencing.

The protocol now know as IPv6 was primarily derived from my proposed  
IPv4 successor called SIP (Simple Internet Protocol).  Originally, SIP  
did not include an IP version number field and used a separate ether- 
type.  Several prototype implementations of SIP were undertaken, and  
the requirement to use a new ether-type created an obstacle for at  
least one of those implementations (probably on some early version of  
Windows), so I changed the specification of SIP to include an IP  
version number field and to use the same ether-type as IPv4.

I therefore applied to IANA for an IP version number to use in SIP  
prototypes, and was assigned number 6, because that was the next  
available value.  In order not to be seen as "blessing" SIP as the  
next version of IP,  Jon at the same time assigned IP version numbers  
to all the other IPng candidates then under consideration in the IETF,  
even though their headers didn't have or require an IP version number  
field.  The assignments were as follows:

   6 - SIP
   7 - TP/IX
   8 - PIP
   9 - TUBA

About a year later, we in the SIP (later SIPP) Working Group received  
reports of a problem arising in the deployment of ST.   Apparently,
ST had been failing in some environments because of intermediate  
devices -- not routers, but rather things like layer-2 switches or  
security devices -- that were snooping in IP headers and taking some  
action (such as discarding packets) based on what they found.   
Unfortunately, those devices were identifying IP packets simply by  
ether-type, and were failing to verify the IP version number before  
proceeding to parse other parts of the IP header.  Despite the fact  
that those devices were clearly "in the wrong", we decided to go back  
to using the separate ether-type for SIP so that we wouldn't risk  
encountering the same deployment problem as ST.  So that's how IPv6  
ended up with the redundancy of both an IP version number field and  
its own ether-type.

Steve