Re: SIP now IPv6

[Steve Deering <[e-mail]>]

> When describing issues related to TCP/IP header compression
> over SLIP you said that:
>    "Any new version of IP will have to be assigned a version number
>     less than 8..."
> That statement certainly contradicts your previous assertion
> that "the IP version number is in no danger of exhaustion".

Yakov,

I wondered if anyone would jump on that.  No, I did not contradict myself.
If you had quoted my entire sentence, you might have noticed the
qualification: "...if its packets are to survive crossing such a link."
Future versions of IP may, quite reasonably, forgo the ability to traverse
SLIP links.  Certainly, CLNP packets cannot be transmitted over SLIP links,
except by encapsulation in IP.  It might make sense for a new internet
protocol to require the upgrading of SLIP links to PPP or something else;
it will likely be desirable to specify a new header compression algorithm
for the new protocol anyway, which would entail more than just keeping the
high bit zero to merge into SLIP.  In the case of SIP, I am interested in
taking advantage of as much as possible of the existing IP link-level
infrastructure, so I prefer to get an IP version number less than 8,
but other proposals may justifiably put less weight on compatibility
with SLIP.

> In fact, ST-II uses 5, SIP is assigned 6, and IPv7 proposal
> written by Robert Ullmann uses 7 (I am not quite sure whether
> this number is officially assigned by the IANA, or Robert just used
> this number in his document). Given this, what should be the
> version number assigned to PIP, if it is to be used in
> conjunction with TCP/IP header compression over SLIP ?

0, 1, 2, and 3 are all still available in the lower half of the number space
(though I suspect that Jon would never assign version number 0, on principle).
I'm pretty sure that version 7 has not been assigned to Ullman, in which case
it too is currently available.

> >...we are under tight deadlines to demonstrate interoperability...
> >...we keep being told that time is running out !
>
> Steve,
> Who imposed the deadlines ? Under what authority ?

I understand that the IESG has set a mid-February deadline for each of the
Next-IP candidates to demonstrate interoperability of multiple implementations.
Supposedly, this was announced at the beginning of the Next-IP plenary
session at the DC IETF, but I was busy fussing with TV cameras and multicast
tunnels at the time and didn't hear it myself; I've been waiting to see a
message or a draft from the IESG, laying out the deadlines.  The SIP/IPAE
implementors are working hard to meet that deadline, under the assumption
that it is real, and one of the pieces of information they need *now* is
what bit pattern to put in the SIP version number field, so that they all
use the same pattern.

> Who told you that "time is running out" ? Where is the rationale
> for such a statement ?

The IAB told us that time was running out, when their Kobe announcement
told us that there was no time to pursue alternatives to CLNP.  The
IESG tells us, by their continuing imposition of deadlines and milestones,
that there is no time to waste if we are to get an IP replacement designed,
implemented, tested, and globally deployed before global routing collapses
or the IPv4 network number space is exhausted, *even with* the prior
deployment of CIDR.

Now, I don't myself believe that time is running out, which is why I
said "we keep being told" rather than "I believe", and I think that the
IP community and the IP protocol suite has been seriously, perhaps
fatally, wounded by those who have been shouting "the sky is falling!".
However, given that there are many who *are* panicked, I deem it necessary
to pursue SIP development and testing with considerable haste, so as to,
perhaps, alleviate some of that panic.

> There is no reason to introduce panic mode into the Internet.

It sure as hell wasn't me who introduced the panic.

>                              Given the number of proposals
> on the table, given that we are not even close to rough
> consensus, and given lack of *any* large scale operational
> experience, an assumption that in a few months the IETF will
> decide on what should be IPv7 is at best misleading, and at
> worst dangerous to the Internet community at large.

If we are ever to obtain large scale operational experience with SIP,
we need an agreed-upon value for the version field *first*, i.e., *now*.

I never said that the IETF will choose an IPv7 in a few months.  There *is*,
I believe, a demo deadline in a few months, which is *not* a contest to
decide "the winner", but just one step in the "milestones, coordinated
public presentations & demonstrations, and on-going review" that you said
was an appropriate activity of the IETF.

> >The danger of misinterpretation by the press is present, no matter
> >what we do.
> 
> However, the amount of danger depends on *what we do*. By making things
> less ambiguous we reduce the danger of misinterpretation.

Look, if the IAB/IANA/IESG/IETF/ISOC PR machinery wants to issue a press
release saying that an IP version number has been assigned to SIP
FOR TESTING PURPOSES ONLY and that this action IN NO WAY implies any
endorsement of SIP as a replacement for IPv4 by the IAB/IANA/..., blah,
blah, blah, that's fine with me.  The working groups themselves have
enough real work to do, without having to spend cycles worrying about what
readers of Comm Week might erroneously conclude from the bit pattern at the
start of a packet.

Steve