Subject: (ngtrans) New version of IPv64 without requiring IPv6 modifications

From: "Arturo Azcorra" <[email-masked]>
Date: Wed, 12 Dec 2001 21:17:23 +0100

Hi,

Please find enclosed the last version of IPv64 draft that does not imply
modifications in the IPv6 header while keeping most of the advantages, plus a
protocol translation feature to avoid deploying IPv64 at end systems (PCs and
servers), being required only at edge-routers.

An implementation protoype has been made to proof its feasibility.

Best Regards, Arturo Azcorra

---

From: Alain Durand <[email-masked]>
Date: Wed, 12 Dec 2001 14:43:50 -0800

At 09:17 PM 12/12/2001 +0100, Arturo Azcorra wrote:
>  8. IPv64 Protocol Translation
>
>    Producing IPv64 packets would require that IPv6 end-system
>    implementations be modified according to the specification performed
>    in this document. This has the obvious disadvantage of requiring the
>    modification of the already designed IPv6 systems, and its
>    deployment.

==> This is clearly way to late in the IPv6 game.

>     To avoid this problem, a protocol translation procedure has been
>    designed to allow current native IPv6 systems to interoperate with
>    IPv64. This procedure would be provided at the router with a direct
>    delivery capacity to the IPv6 end-system. This is a current
>    restriction that might be relaxed in the future. An IPv64 router
>    with IPv6 hosts connected to one of its interfaces can be configured
>    to perform protocol translation at that interface. This means that
>    the router will convert incoming IPv6 packets from that interface to
>    IPv64 packets and IPv64 packets directed to a host on that interface
>    will be converted to native IPv6.

==> IPv6 main benefits is to restore end-to-end IP connectivity
        by removing translation devices

        As said months ago, this proposal is just too late and does not
        solve any significant problem.

         - Alain.

---

From: "Arturo Azcorra" <[email-masked]>
Date: Thu, 13 Dec 2001 19:11:38 +0100

Hello Alain,

>         by removing translation devices

This would be correct if transition had been completed and all the network be
IPv6. However, in the transition phase some mechanisms should be provided, and
all the current transition proposals perform IPv4 tunneling and/or protocol
translation, so I do not see any disadvantage in my proposal as compared with
other proposals.

>         solve any significant problem.
First problem that is solved:
Current transition approaches work well to connect IPv6 islands through an
all-IPv4 transport internet. However, I do not believe they will perform so well
in a more advanced transition phase when there is a high intermix of IPv4 and
IPv6 networks at the backbone. I do believe that the IPv64 proposal does perform
well in that near future situation.

Second problem that is solved:
Current transition approaches are mainly based on tunneling, and therefore the
advantages of IPv6 (except big address space) are lost one the IPv6 packet is
tunneled. IPv64 performs IPv6 processing at every IPv64 capable router. In this
way, IPv64 allows also a transition in  network functionality (i.e. not only in
network the conectivity) from IPv4 to IPv6.

May be the second problem is not considered significant, but I think that the
first one is significant enough to justify introducing IPv64, as it does not
imply significant technological redesigns.

Regards, Arturo

---

From: Pekka Savola <[email-masked]>
Date: Thu, 13 Dec 2001 21:30:12 +0200 (EET)

> translation, so I do not see any disadvantage in my proposal as compared with

The other mechanisms have existed for a long time and are in active use.

> well in that near future situation.

Why do you believe tunneling will not work with a high number of IPv4/IPv6 
networks?  I see no problems there.  You have about the same number of 
peers as with IPv4.

> tunneled. 

No features of IPv6 are lost in tunneling.  It's just a mechanism of 
transporting packets and restoring their original state.

Actually, IMO, tunneling in the beginning phase is a rather good thing --
it uses (usually) redundant IPv4 topology to get the best IPv6
connectivity.  If a fiber was cut where IPv6 was run, there would have to
be redundant links were it IPv6-only.  In not-quite-production networks,
where this would not be e.g. economically feasible, this is IMO
significant.

> IPv64 performs IPv6 processing at every IPv64 capable router. In this
[...]

At the same (less -- no need to wait for IPv64 etc.) expense, you can
upgrade your IPv4 routers to dual-stack and there is not even a
transitionary problem anymore.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 13 Dec 2001 21:38:47 +0100

> networks?  I see no problems there.  You have about the same number of

In any case I think the problem statememt is false. Why would we get such a patchwork
topology? We have a fully connected IPv4 backbone; with dual stack routers we will
slowly get a fully connected IPv6 backbone. I don't expect a scenario in which the
IPv4 backbone is fragmented before the IPv6 backbone is complete; that would be
crazy behaviour by the ISPs. 

> transporting packets and restoring their original state.

Indeed. The cases where we lose features are those involving SIIT, NAT-PT, BIS, and BIA. 
> > network the conectivity) from IPv4 to IPv6.

So does installing dual stack routers and tunnels.

> transitionary problem anymore.
Exactly
   Brian

---

From: "Arturo Azcorra" <[email-masked]>
Date: Wed, 19 Dec 2001 19:28:07 +0100

Hi,

> The other mechanisms have existed for a long time and are in active use.
I am aware of what you say, but the same applies to IPv4 (and to DQDB, 100VG any
lan, .. some time ago), yet we all are trying to replace it by IPv6.  In any
case, the transition mechanism I propose is not intended to be a substitute fo
the current transition mechanims, but a complement to the existing ones that
brings some advantages for expected situation in the near future. I would then
focus the discussion on wether IPv64 brings enough advantages to make it
convenient to be used in same cases.

> networks?  I see no problems there.  You have about the same number of
I am not saying that it does not work, I am saying that IPv64 is a better
technical solution.

> transporting packets and restoring their original state.
You are wrong on this. In-transit (i.e. all along the tunnel) you loose:
* The feature of the flow label
* The feature of the IPv6 extension headers
* Finally, and most important, you loose the improvements brought by forwarding
based on the IPv6 address, instead of on IPv4 address.
These features are lost even in the presence of dual stack IPv6/IPv4 routers in
the path, because the IPv6 packets are tunneled through all the transit networks
to the destination enterprise network.

> where this would not be e.g. economically feasible, this is IMO
I fully agree here. Tunneling in the beginning phase is a very good thing, but
it is not the best solution for  the mid phase.

> transitionary problem anymore.
I guess you are kidding here. This is obviously not correct. If what you mean is
to upgrade ALL routers, that is completely unfeasible. If what you mean is that
some dual-stack routers imply automatically a solved transition, this is not the
case as native IPv6 datagrams would not cross the legacy IPv4 networks.

Regards, Arturo

---

From: Pekka Savola <[email-masked]>
Date: Wed, 19 Dec 2001 20:55:59 +0200 (EET)

On Wed, 19 Dec 2001, Arturo Azcorra wrote:
> [...].  I would then

Yes.  So far I haven't seen concrete advantages.

> based on the IPv6 address, instead of on IPv4 address.

This depends on the definition of "IPv6 features lost in the tunneling".

So far that has always been interpreted as "the original IPv6 datagram is 
restored when the packet is decapsulated".  This is what is done.

You seemed to interpret this in such a way that IPv4 nodes transporting
these packets would somehow be able to use some IPv6 features, e.g. flow
label.

> to the destination enterprise network.

This is true, if you consider mechanisms like 6to4. But these have always
been "last-resort" mechanisms.

For native IPv6, configured tunnels should be established to nearest
dual-stacks.

> case as native IPv6 datagrams would not cross the legacy IPv4 networks.

[note, please don't make this MPLS/anti-MPLS flamewar, I'm using it only 
to try to make the point :-)]

No, I wasn't joking.

I'm not sure what kind of topology you have in mind.

Perhaps you consider the tunneling to be like MPLS: at edge, every site's
IPv6 router puts IPv6 packets in "MPLS" (=IPv4) and they only get popped
out at the destination site.  This is obviously less than perfect
solution, where some "IPv64" like solution might be useful.

This is close to what happens with 6to4.

Proper IPv6 network, however, is built so that the size of "MPLS" cloud is
always minimized.  The moment the upstream router supports IPv6, one can
push "MPLS" out of downstream router and make "MPLS" cloud even smaller.
IPv4 tunneling is used as a last-resort mechanism, a part (hopefully
minor) of end-to-end IPv6 connectivity.

---

From: Alain Durand <[email-masked]>
Date: Wed, 19 Dec 2001 22:43:48 -0800

At 07:28 PM 12/19/2001 +0100, Arturo Azcorra wrote:
>In any

I think you already got several times the answer to this question from 
different
members of this working group. It is no.

         - Alain.