Subject: (ngtrans) Document Requested to be published as Internet Draft

From: "Arturo Azcorra" <[email-masked]>
Date: Sat, 11 Aug 2001 01:54:23 +0200

Dear Sirs:

Please find enclosed a document that I request be published as an Internet
Draft.

As I believe the document could be of interest to the Next Generation Transition
WG, and following usual recomendations, I am sending a copy of the document to
the responsibles of the group and also to the mailing list of the group for its
discussion.

In case you would like any feedback from my side, I just want to indicate that I
am leaving on vacation today, and therefore I will not be able to answer any
e-mail until end of August.

Best regards,

Prof. Dr. Arturo Azcorra
Univ. Carlos III de Madrid
Avda. de la Universidad, 30
28911 Leganes (Madrid)
Email: [email-masked]
Tel: +34 91 6248778
Fax: +34 91 6248749

---

From: Pekka Savola <[email-masked]>
Date: Sat, 11 Aug 2001 03:11:47 +0300 (EEST)

> the responsibles of the group and also to the mailing list of the group for its

(cc: list tailed down a bit)

Invent a pseudo-protocol number to make sure the transition period is even
longer than expected now?  IMO, tunnels work just fine now.

This feels like an awfully bad idea for a non-issue.  How IPv6 nodes talk
to other IPv6 nodes is not the big issue in the transition.  Why people
should use IPv6 at all, get it enabled, get apps ported etc. are.

(btw, Mr. Fleming might be interested of the name proposal).

-- 
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: Tue, 14 Aug 2001 11:46:23 -0500

I agree with Pekka. I can't see a single reason why these packets would flow
any more easily through the IPv4 network than packets with protocol type 41.
In that case, I can see no argument for the rest of the mechanism.
Encapsulation is much simpler.

By the way there is one technical error - the traffic class field is indeed
8 bits, but the diffserv code point is only 6 bits, with the other two bits
being used by ECN. The same is true of the (revised) IPv4 type of service
octet.

Also the mechanism seems to require a piece of magic, because I can't imagine
any method but magic to implement this:

  "Value 6 MUST be used when the end to end IPv6 compatibility is 
   guaranteed, either because the destination host and all routers in 
   transit are IPv6 capable, or through other compatibility mechanisms."

     Brian

---

From: "Arturo Azcorra" <[email-masked]>
Date: Thu, 16 Aug 2001 00:28:18 +0200

HI,

Thank you very much for your comments on the IPv64 proposal.

Regarding the DSCP comment sent by Brian, I agree on that the term I used was no
the correct one. I should have used "Differentiated Services Field" instead of
"Differentiated Services Code Point", and this will be fixed in the next version
of the draft (actually, the homogeneous usage of ECN by IPv4 and IPv6  is an
advantage). In any case, this issue does not affect the core of the technical
proposal containted the draft.

Another interesting comment by Brian was about the difficulties to know if there
is end-to-end IPv6 compatibility. This is clearly an important issue  that is
still under study. A very preliminar idea is to use probe packets combined with
a cache table. This could be implemented at hosts and/or edge routers and would
be transparent to the applications. In any case, this is not different from
knowing when to use tunneling vs. native IPv6.

Regarding the other comments about the usage of tunneling, I know that tunneling
works fine, but I still think that there are several advantages of using a
specific approach (IPv64) instead of a generic one (tunneling).

First, there is the reduced header overhead. In IPv64 there is a saving of 20
octets, using 40 total header octets instead of 60 being used with tunneling.
This might seem unimportant, but different Internent traffic studies show that
small  (below 40 octets in payload) pakets constitute a very large fraction of
all packets flowing in Internet (some studies show up to 40% of total packets).

Second, you have some security considerations with the widespread usage of
tunneling. The usage of IPv64 could be treated as native IPv6 traffic, as long
as the firewall is IPv6 compatible.

Third, you have implementation considerations at routers. With IPv64 it is
forbidden to use the IPv4 options field. This allows to extract the IPv64 header
fields from fixed positions, instead of extracting them from variable positions
(when using tunneling) that depend from the value of the IHL field. Therefore,
this would be a better solution if one wants that an IPv6 router be capable of
processing an IPv64 packet as IPv6 than a tunneled IPv6 packet.

Finally, there is the advantage that IPv64 packet are processed as IPv6 packets
by IPv6-capable routers in its path. With tunneling, a router should route an
IPv4 packet as such, regardless of its payload. Therefore, the advantage of
processing IPv64 packets as IPv6 at all IPv6-capable routers in the path is
lost. It can be argued that it would be possible to configure IPv6 routers to
inspect the protocol field in IPv4 packets (as is done with IPv64) and process
all the encapsulated IPv6 packets as such, but in this case you would loose the
actual tunneling functionality (i.e. to really receive the IPv6 datagram
unchanged at the destination IPv4 address), which is useful under many
situations.

Regards, Arturo

Prof. Dr. Arturo Azcorra

> -----Mensaje original-----
> De: [email-masked]
> [mailto:[email-masked]]En nombre de Brian E Carpenter
> Enviado el: martes, 14 de agosto de 2001 18:46
> Para: Pekka Savola
> CC: Arturo Azcorra; [email-masked]
> Asunto: Re: (ngtrans) Document Requested to be published as Internet
> Draft
>
>

---

From: Pekka Savola <[email-masked]>
Date: Thu, 16 Aug 2001 19:48:08 +0300 (EEST)

> all packets flowing in Internet (some studies show up to 40% of total packets).

I don't think that's much of an issue for most people who live in the
dual-stack world (ipv6 mobiles and like are ipv6-only and this is of no
consequence to them).

A crucial question, I think, is: "Do we need a mechanism to transport
IPv6 over IPv4 so that Path MTU does not change, and how badly?".

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 23 Aug 2001 08:54:08 -0700

Arturo,

Thank you for contributing to the idea pool for IPv6. Since your 
proposal would make substantial changes to the basic IPv6 header it 
is out of scope for the NGtrans WG, so I am adding the IPv6 chairs 
to this message. 

While your proposal would appear to expedite delivery of packets in a predominantly IPv4 routed network, it raises more concerns than it addresses. To start with your base premise:
   "It is considered that time is a critical variable, and unless the 
   next version of a protocol is adopted before a certain time, the 
   protocol will change to incorporate "functional improvements."
is self-referential by attempting a fundamental change of this scale 
at this point. Changing all the existing implementations would require
at least 2 years after all the details get worked out.

The assumption that the version number is set based on the end-to-end
capability of the network ignores the fact that the source can't 
possibly know what the infrastructure is capable of at any point in
time as routes change. 

Having fields in the address that are mutable by IPv4 routers ensures 
that the only field useful for return path identification is the IPv4
source, which is as likely to be a private use address as not. Unless
both nodes exist in the same IPv4 address realm, there is no way for 
the receiving node to return to the source.

Defining an extension header to carry the real IPv6 source means all 
the fields that would be in the existing IPv6 over IPv4 tunnel 
mechanisms are still in front of the data. Essentially this proposal 
would be defining an environment specific tunneling mechanism with 
the additional complication that all nodes would have to have full 
topology state to make it work.

The restriction of disallowing IPv4 options is inconsistent with the 
initial statement that the IPv4 stack would be unmodified. 

In short this proposal is significantly late in the process, and its
attempt to be more efficient than tunnels actually breaks more existing
mechanism than it helps.

Tony

-----Original Message-----
From: Arturo Azcorra [mailto:[email-masked]]
Sent: Friday, August 10, 2001 4:54 PM
To: [email-masked]
Cc: [email-masked]; Tony; [email-masked]; [email-masked]; [email-masked]; [email-masked]
Subject: Document Requested to be published as Internet Draft

Dear Sirs:

Best regards,

Prof. Dr. Arturo Azcorra

---

From: "Arturo Azcorra" <[email-masked]>
Date: Tue, 28 Aug 2001 02:44:33 +0200

Tony,

Many thanks for the comments and the attention you have paid to the
internet-draft.

I agree with all your statements, but the only one that I consider a true
technical barrier is the decission by the source of what format to use, that was
previously pointed out by Brian. I am still working on this problem (which is
similar to the current problem of when to use tunneling or native IPv6), and
hopefully will come out with a reasonable solution.

The other fundamental issue which you are completely right in pointing out is
that my proposal is most likely late in the process. The impact of changing the
existing IPv6 implementations. This is an economic-bussiness issue in which the
cost and delay of changing the existing IPv6 should be balanced over the
advantages of the approach I propose. The most likely answer is to leave IPv6 as
it is now.

However, to put some more weight on the side of my proposal, I have introduced a
new function in IPv64. This function would allow that an IPv4-only host receive
and correctly process IPv64 packets, with the advantages of native in-transit
IPv6 processing when sending packets to an IPv4-only host, without requiring
tunneling and protocol conversion.

Please, find enclosed the next version of the internet-draft in which the above
function is described.

Best regards, Arturo

Prof. Dr. Arturo Azcorra
Tel: +34 91 6249993
Fax: +34 91 6248749
Mob: +34 609 147242

> De: Tony Hain [mailto:[email-masked]]
> Enviado el: jueves, 23 de agosto de 2001 17:54
> Para: [email-masked]; [email-masked]
> CC: [email-masked]; [email-masked]; [email-masked];
> [email-masked]; [email-masked]; Steve Deering; Bob Hinden
> Asunto: RE: Document Requested to be published as Internet Draft
>
>
> Arturo,
>
> While your proposal would appear to expedite delivery of packets in a
> predominantly IPv4 routed network, it raises more concerns than it
> addresses. To start with your base premise: