[ih] Why a new etype of IPv6

[Steve Deering]

On Sep 22, 2010, at 2:34 PM, John Kristoff wrote:

> While on the subject of IPv6, I don't recall seeing any of the
> official, or even unofficial for that matter, reasoning for
> assigning a unique ethertype value (0x86dd versus 0x0800) for
> the use of IPv6 over Ethernet / 802.3.  I would guess it amounts
> to a "why not", but perhaps it is more involved than that.  Maybe
> some specific performance or data link-specific reasoning?  Any
> insight to satisfy my curiosity would be appreciated.

John,

I answered that in a posting to the internet-history list last  
November.  My answer yesterday, to your question about v9 for TUBA,  
was an extract from that November posting; here it is again in full:

> From: Steve Deering <deering at brunzel.org>
> Date: November 7, 2009 1:36:50 PM PST (CA)
> To: internet history <internet-history at postel.org>
> Cc: Steve Wilcox <stevewilcox at google.com>, ipv6 <ipv6 at google.com>,  
> Michael Shields <mshields at google.com>, Vint Cerf <vint at google.com>
> Subject: Re: [ih] [ipv6] IP versions explained
>
>> 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 known 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
>