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

[Parminder]

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

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. 

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

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. 

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

Parminder 



> -----Original Message-----
> From: McTim [mailto:dogwallah at gmail.com]
> Sent: Saturday, March 01, 2008 12:07 PM
> To: governance at lists.cpsr.org; Parminder
> Subject: Re: [governance] RE: IPv[4,6, 4/6] was IGF delhi format
> 
> On Fri, Feb 29, 2008 at 9:05 PM, Parminder <parminder at itforchange.net>
> wrote:
> >
> >
> >  Thanks Stephane. That was helpful.
> >
> >  I know I may be testing your patience, but can I still seek some
> further
> >  clarifications.
>  I spoke of the whole working network
> >  itself as a giant application merely to understand what compatibility
> with a
> >  new system with a different protocol may mean. So, pl excuse my
> excursion.
> >  It is entirely a temporary construction to try and understand a
> phenomenon,
> >  which to me is still not understandable.
> 
> 
> It's perhaps more proper to call TCP/IP a suite of protocols (this is
> however NOT the same as an application suite like MS Office).
> It's a collection of protocols, which you can pick and choose from
> depending on your needs/wants.  For example, we monitor our network
> using SNMP. We don't have to, but if we didn't the ability to do so
> (use SNMP) would still be there.
> 
> There is a pretty picture here:
> 
> http://www.tcpipguide.com/free/t_TCPIPProtocols.htm
> 
> In fact this (http://www.tcpipguide.com) is a good place to start, it
> has seperate v4 and v6 sections.
> 
> >
> >  > > (2) What special gains were obtained in the new design v6 to make
> it
> >  > > in manner that it is not backward compatible.
> 
> The promise(s) of IPv6 are many, besides the larger address space,
> these are usually summarised as, autoconfiguration, better security,
> integrated QoS, mobility, better routing performance and services,
> newer unicast and broadcasting methods, etc.  Unfortunately for v6
> evangelists, these haven't (and won't) be fulfilled until there is a
> larger installed user base.
> 
> "Realizing the benefits of IPv6 will take time"
> http://www.gcn.com/print/25_01/37897-1.html
> 
> We all focus on the larger address space, as that is the immediate issue.
> 
> 
> >  >
> >  > Extension of the addressing space. From 2^32 (not enough to give an
> IP
> >  > address to every human being) to 2^128
> >
> >  I know the basic logic of moving to ipv6. My question was different -
> what
> >  gain was obtained in making this protocol 'in a manner that' did not
> make it
> >  seamless backward compatible. Or was that the only possibility.
> >
> 
> see above.
> 
> >
> >  > > 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.
> 
> The answers to all of your questions are freely available online, it's
> just a matter of how hard you choose to look.
> 
> >  Again, I understand the gains (or inversely, losses). Do you mean to
> say
> >  that the only way to make these gains - move to a bigger address space
> and
> >  other benefits - was to make a non-seamlessly-backward-compatible
> protocol.
> >  That is my question.
> 
> The only way?
> 
> Yes, in Panglossian terms, it is ;-)  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.
> 
> >
> >  Why there was no other proposal. Is it technically difficult or
> impossible?
> 
> You will have to read the history (IETF list archives).
> 
> >  Was it a mistake on part of the technical community doing this work?
> 
> 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).
> 
> It was clearly a trade-off made consciously, and with deliberation.
> Certainly not an engineering "mistake".
> 
>  Would
> >  they have done differently if they were politically differently
> inclined,
> >  meaning had different socio-political objectives/ values/ compulsions/
> >  constraints (I know that this is the tough question, but a very
> important
> >  one.
> 
> and one that is impossible to give any meaningful answer to.
> 
> Read http://tools.ietf.org/html/rfc1752, and tell me how these
> criteria would change if the many hundreds of people who worked on it
> had "different socio-political objectives/ values/ compulsions/".
> 
> 
> <quote>
>    A detailed review of how IPng meets the requirements set down in the
>    IPng Criteria document [Kasten94] will soon be published.  Following
>    is our feelings about the extent to which IPng is responsive to the
>    criteria.
> 
>    * complete specification - the base specifications for IPng are
>      complete but transition and address autoconfiguration do remain to
>      be finalized
>    * architectural simplicity - the protocol is simple, easy to explain
>      and uses well established paradigms
>    * scale - an address size of 128 bits easily meets the need to
>      address 10**9 networks even in the face of the inherent
>      inefficiency of address allocation for efficient routing
>    * topological flexibility - the IPng design places no constraints on
>      network topology except for the limit of 255 hops
>    * performance - the simplicity of processing, the alignment of the
>      fields in the headers, and the elimination of the header checksum
>      will allow for high performance handling of IPng data streams
>    * robust service - IPng includes no inhibitors to robust service and
>      the addition of packet-level authentication allows the securing of
>      control and routing protocols without having to have separate
>      procedures
>    * transition - the IPng transition plan is simple and realistically
>      covers the transition methods that will be present in the
>      marketplace
>    * media independence - IPng retains IPv4's media independence, it may
>      be possible to make use of IPng's Flow Label in some connection-
>      oriented media such as ATM
>    * datagram service - IPng preserves datagram service as its basic
>      operational mode, it is possible that the use of path MTU discovery
>      will complicate the use of datagrams in some cases
>    * configuration ease - IPng will have easy and flexible address
>      autoconfiguration which will support a wide variety of environments
>      from nodes on an isolated network to nodes deep in a complex
>      internet
>    * security - IPng includes specific mechanisms for authentication and
>      encryption at the internetwork layer; the security features do
> rely     on the presence of a yet to be defined key management system
>    * unique names - IPng addresses may be used as globally unique names
>      although they do have topological significance
>    * access to standards - all of the IPng standards will be published
>      as RFCs with unlimited distribution
>    * multicast support - IPng specifically includes multicast support
>    * extensibility - the use of extension headers and an expandable
>      header option feature will allow the introduction of new features
>      into IPng when needed in a way that minimizes the disruption of the
>      existing network
>    * service classes - the IPng header includes a Flow Label which may
>      be used to differentiate requested service classes
>    * mobility - the proposed IPv4 mobility functions will work with IPng
>    * control protocol - IPng includes the familiar IPv4 control protocol
>      features
>    * tunneling support - encapsulation of IPng or other protocols within
>      IPng is a basic capability described in the IPng specifications
> 
> </quote>
> 
> 
> 
> 
> 
> Connects the technical domain to the socio-political)
> >
> >  Sorry for asking so many questions. Hope I am not getting on the nerves
> of
> >  all the technical experts here. Thanks
> 
> I think that some determined research on your part would reveal the
> answers to your questions.  Google is your friend here.
> 
> --
> 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


____________________________________________________________
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