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

[McTim]

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