[governance] RE: IPv[4,6, 4/6] was IGF delhi format

[McTim]

On Sat, Mar 1, 2008 at 12:15 PM, Parminder <parminder at itforchange.net> wrote:
>
>  McTim
>
>
>  > It's a solution to a number of problems/issues with IPv4.
>  >
>  > Solving these problems required a different packet design. This meant
>  > that a v6 packet would not be able to be read by a v4 host natively
>  > (and vice versa).
>
>
> Well, that the answer to my question. So, you do say that, within plausible
>  limits, there was no possible design for a v6 packet that could do all it
>  does now and still be read by v4 host and vice versa. Fine.
>
>  Though there is a connected issue (which was also my question) that if we
>  had kept this condition - that v6 packet JUST SHOULD BE ABLE to be read by
>  v4 host and vice versa - as an important, and lets say for argument's sake,
>  an incontrovertible condition, what all functionality of a v6 system will be
>  lost to us.

If I understand you correctly, and you make the packet headers the
same (compatible) then you lose pretty much everything.

Address translation is trivial, so as Suresh said, this is a non-issue.

If we knew this, then we can seek to do a political trade off
>  between the seamless-compatibility objective and these other objectives
>  which were simply not possible if we insisted on seamless compatibility.
>

Well that trade off was done years ago.  Seamless compatibility was
NEVER an objective!

>  I am sure this above formulation is no more complex than all the technical
>  specification formulations that you forward to me and I read them all, and
>  am not complaining :).
>
>  When you say
>
>  >>
>
> >>  Why there was no other proposal. Is it technically difficult or
>  impossible?
>
>  >You will have to read the history (IETF list archives).
>
>  And also
>
>
>  >>  > > Were these gains evaluated against the losses of
>  > > non-compatibility,  > > or non-seamless-compatibility.
>
>  >Probably, you will have to read the history of IETFs IPng (later renamed
>  >IPv6) WG, as I wasn't on that list when those choices were made.
>
>
> You are pointing to me to the IETFs history docs on the crucial aspect of my
>  questions. But do we, (and you) as someone interested in tech governance
>  have no views at all on whether the v6 transition problem we are faced with,
>  which by all estimates is huge, could have been avoided by an alternative
>  design. Can we afford to not give any thought to this, and not have any view
>  on this.... Did you never think of investigating, and forming a view on
>  this.
>

I do have a view, it's this:  The "problem" is not huge, it'll be
worked out in short order (5 to 10 years). There are many transition
mechanisms folk can employ, and have done.  The tools are there, it's
just that folk aren't deploying them at the speed that was
anticipated.  I have no interest in re-fighting protocol wars that
have already been fought.

>
> The swarm wisdom of the IETF
>  > produced IPv6 long ago.  The spec is done, the WG is closed.  Their is
>  > an installed base, it can't/won't be changed.
>
>
> That's not a sufficient response. We may not be able to change it. But we
>  need to understand under what conditions crucial decisions that impact all
>  of us are taken, and see how we can improve those conditions and processes.

Then join the process that makes the decisions.

>  That's all what constitutes discussing IG, and thats what we are here on
>  this list doing, as I understand it.
>
>  And about the 'IPng Criteria document [Kasten94]' that you have quoted, why
>  couldn't there be a specific criterion there that 'v6 packet should be able
>  to be read by v4 host and vice versa'.... it isn't there, any good reasons??

Because then you couldn't do many if not most of the other things listed!

Let me make an analogous thought experiment and see if it helps you.

Let's say that the predominate vehicle engine in the world is the
internal combustion engine (the Internet). let's also say that most
engines run on fossil fuels (IPv4).  So when folks
(IETF/IAB/IESG/RIRs/IANA/others) saw that we would run out of fuel
some day, they tried conserving (CIDR), this worked quite well but it
was not a permanent solution.  They realised a longer term fuel
solution was needed (128 bits of address space).

They reckoned that if they were going to need a new kind of fuel, then
maybe they could do a redesign of the engine (IP stack) at the same
time, so it could, inter alia, use both older and newer cars/fuel
during the transition.  In addition, maybe this new engine could do
things the old one couldn't, like fly your car into the air or go
underwater or go into space someday, (i.e., IPv6 extensible packet
headers).  so after many years work in isolation (because very few
others knew or cared that we would run out of fuel) they finalised the
specs for the new engine and fuel (IPv6).

So a few people started building the new engine into their vehicles,
(Linux, Mac and Vista have it by default, XP has it but you have to
manually turn it on), realising that they could use the old fuel, but
had to use a mix of old and new at the same time in different
combustion chambers (dual stack) OR tunnel the fuel line of one fuel
thru the fuel line of the other (tunneling) OR convert the old fuel
into the new and vice versa (NAT-PT).

What's more, the new fuel is dirt cheap relative to the old, and
seemingly infinite. w00t!

A decade later some people are panicking because they don't understand
that most modern vehicles can use both fuels if tweaked by a mechanic.
 There are usually no parts to buy, just some labor involved.  Older
vehicles can use the new fuel as well (NAT), but it may not work as
well as the new fuel works on the newer engines (dual stack).

So what you are asking is;

"Why can't the old engine use the new fuel in it's original combustion
chamber and why can't the new engine use the old fuel without
converting it?"

Because then it couldn't do the things the new engine can do, only the
things the old one can do.

and

"Wasn't that a mistake by these so-called far sighted engineers?"

The answer is clearly, no.

and

"We should second guess them because I don't understand what they have
built, plus I suspect they want the best engine and fuel for
themselves, and leave the rest of us to use the old engines and fuel,
which is in short supply"

which is net-kookery, really.

>
>  And when they put done this criterion
>
> >    * transition - the IPng transition plan is simple and realistically
>  >      covers the transition methods that will be present in the
>  >      marketplace
>
>
> From what we know around us today, they obviously did not get it right.

It is simple, you can, inter alia: dual stack (available in the
marketplace today), Tunnel (available in the marketplace today) or do
address/protocol translation (NAT-PT) (available in the marketplace
today).


>  I can think of one possible reason why they did not put in a
>  seamless-compatibility criterion (not saying that was their reason, but just
>  exploring the possible reasons bec I think we need to understand the
>  circumstance under which such an imp decision was taken). It could be that
>  if two protocols were perfectly compatible, there would not be enough
>  incentive among most users to shift to the new protocol. It will create two
>  layers of the Internet - those who can enjoy all the functionalities of the
>  much more superior v6 protocol and those who are struck with v4. Well, that
>  at its face would be a very good reason for IETF for doing what they did.

I'm going to assume that your conspiracy theory was concocted in
ignorance, and just let it go.


>  But this imperative needed to be discussed more widely, among circles
>  outside the IETF, and evaluated against the problems that a non-compatible
>  protocols based transition will cause and such....thats the kind of
>  tech-policy interface issue that, rightly, takes up most of our energies on
>  this list.
>
>  So, while I thank you for all the links you have sent (you have been as
>  engaging and through as ever) and I will use google as well, but as my email
>  describes above, the issue is not about a set of facts which have a clear
>  answer out there. If there were some such clear answer, someone on this list
>  would have told me that. And I havent got that answer.

Hopefully, the above should clear it up for you, if not, I can't help you.

-- 
Cheers,

McTim
$ whois -h whois.afrinic.net mctim
____________________________________________________________
You received this message as a subscriber on the list:
     governance at lists.cpsr.org
To be removed from the list, send any message to:
     governance-unsubscribe at lists.cpsr.org

For all list information and functions, see:
     http://lists.cpsr.org/lists/info/governance