Subject: (ngtrans) IPv6 is happening the code cannot keep breaking

From: Jim Bound IPv6 Technical Leader UNIX Engineering Internet Group <[email-masked]>
Date: Thu, 17 Sep 1998 12:04:17 -0400

WARNING!!! WARNING!!! Danger Danger Will Robbinson be careful now when
you fiddle with that computer we got to get back to planet earth or we
will be lost in space forever!!!!

This note is to probe a discussion in ngtrans or elsewhere regarding some 
statement from this WG as to the state of IPv6 implementations and the pain 
of changing essential ingredients without regard to the existing
implementations and near term users of IPv6.

Let me firtst say that I would think all vendors have seen what I have
seen as a vendor in the market.

 1.  IPv6 is showing up on customers requests for proposals when
     procuruing networking software as to the vendors intent to
     support IPv6.

 2.  Early Adopter customers (not just university and research labs)
     are asking how and when they can begin deployment of IPv6 test
     beds in isolated departments or LANs.   

 3.  Network Architects at customers will ask first how do we transition
     to IPv6 and interoperate with IPv4.

 4.  ISVs are asking how can they support IPv6 but ship IPv4 binaries
     too.  What do we need to do to our (ISV) middleware APIs?

 5.  How do I get an IPv6 address?

 6.  Do you have a guide on how what steps I take to deploy IPv6?
     In simple terms and the basics?  

These and other questions point to a market need and a market
requirement, which is the result of our work on IPv6 for the past 4
years, and the core specs reaching Draft Standard at this time.  In
addition to some vendors adding IPv6 to their marketing and
differentiating factors for networking software within their product
directions.

It is time we in the IETF accept the fact that we MUST stop changing
basic parts of IPv6 that BREAK existing code, WITHOUT consideration for
a transition state and binary compatibility.  This does not mean IPv6 is
done or that we don't have a lot of work to do, but rather in vendor
terms treat enhancements to IPv6 as a "shipping product" not a research
effort where code can be tossed aside or worse yet the entire
architecture.  

We just saw this with the new DNS A6 record type and I believe we will
fix that in NGTRANS.  We also saw it by changing the socket structure
for the Basic IPv6 API which will break binary compatibility for all
vendors who have shipped IPv6 stacks to ISVs, OEMs, and System
Integrators building embedded systems.

I highly recommend at this time that "running code" for IPv6 be given a
high priority in WGs working on IPv6 parts and services, and if a result
will break IPv6 implementations, then an ensuing transition strategy should
be part of any draft that has that end result.

For example the next iteration of the IPv6 Basic API will be completed
shortly and most vendors I have talked to will not break IPv6 binaries
again because of this API.  Neither will the The Open Group Network
Group as they standardize that API as an update to Info RFC 2133.

It is time to keep this in the back of our minds as we continue to work
on IPv6.

I think we need some statement from NGTRANS to the IETF regarding this
issue as it affects the operability to get IPv6 deployed.

Ideally it would be good to get such a "call" from the IAB eventually
but I think first NGTRANS agreeing on this would be a first step.

/jim