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

[Parminder]

McTim

So you are saying that full compatibility was not possible with all the
features we have and we wanted. That is why it was never an objective. Fine.
We can close this dialogue if you are so eager to. But please read my emails
without eagerness to jump to conclusions. I never said IETF ever made any
conspiracy to keep good part of the Internet for themselves and leave bad
part to others. 

> "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.

I said exactly the opposite. I said that one reason why IETF did not make
ipv6 so much backward compatible could be - and here I was proposing an
mutual exploration of their possible reasons in  a very positive way - that
they were worried that if they did so, there would not be enough incentive
for all parts of the Internet to shift to ip6 and THAT WOULD lead to two
level Internet - and THEY DID NOT WANT THIS TO HAPPEN. Entirely attributing
the very best motives to them. Pl read below.

> >  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.

So your comments attributing a conspiracy theory to me are quite uncalled
for.
> 
> I'm going to assume that your conspiracy theory was concocted in
> ignorance, and just let it go.

Anyways, thanks for all the explanations. 

BTW the view you say you have on the problems of ip6 transition that " The
"problem" is not huge, it'll be
> worked out in short order (5 to 10 years)" is not shared by many others
who are quite knowledgeable. And many of them are quite worried about how it
will work out. This was and is the only reason for my interest in this
issue, and I must tell you I am not completely reassured by your statement. 

Parminder 


> -----Original Message-----
> From: McTim [mailto:dogwallah at gmail.com]
> Sent: Saturday, March 01, 2008 6:54 PM
> To: governance at lists.cpsr.org; Parminder
> Subject: Re: [governance] RE: IPv[4,6, 4/6] was IGF delhi format
> 
> 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