Subject: I-D ACTION:draft-ietf-v6ops-mech-v2-03.txt (fwd)

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Jun 2004 07:56:26 +0300 (EEST)

FYI --

(co-chair hat on)

If interested in mech-v2, take a look -- this aims to address all the 
IESG evaluation comments except what we're currently discussing with 
Margaret.

(co-chair hat off)

Btw. if interested in PMTUD/packet size issues, you might also find
draft-savola-mtufrag-network-tunneling-00.txt interesting.  It's a 
more generic document describing PMTUD, fragmentation/reassembly, etc. 
issues in tunneling in the network.

---------- Forwarded message ----------
Date: Tue, 15 Jun 2004 15:45:40 -0400
From: [email-masked]
To: [email-masked]
Cc: [email-masked]
Subject: I-D ACTION:draft-ietf-v6ops-mech-v2-03.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: Basic Transition Mechanisms for IPv6 Hosts and Routers
	Author(s)	: E. Nordmark, R. Gilligan
	Filename	: draft-ietf-v6ops-mech-v2-03.txt
	Pages		: 32
	Date		: 2004-6-15
	
This document specifies IPv4 compatibility mechanisms that can be
   implemented by IPv6 hosts and routers.  Two mechanisms are specified,
   'dual stack' and configured tunneling.  Dual stack implies providing
   complete implementations of both versions of the Internet Protocol
   (IPv4 and IPv6) and configured tunneling provides a means to carry
   IPv6 packets over unmodified IPv4 routing infrastructures.

   This document obsoletes RFC 2893.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-mech-v2-03.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] with the word unsubscribe in the body of the message.  
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce 
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-v6ops-mech-v2-03.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-v6ops-mech-v2-03.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Fred Templin <[email-masked]>
Date: Thu, 17 Jun 2004 08:10:07 -0700

Pekka,

>IESG evaluation comments except what we're currently discussing with 

It seems that section 3.4 of the current mech-v2 draft includes a built-in
assumption that ICMPv4 error translation to ICMPv6 is only possible
when the ICMPv4 error messages *themselves* include more than the
minimum 8 bytes of data beyond the IPv4 header of the packet in error.

But, if the encapsulator maintains a small queue of recently-sent packets
(indexed, e.g., by the 'ip_id' field of the encapsulating IPv4 headers)
then enough state would be available for ICMPv6 error generation
in most cases even if the ICMPv4 error messages themselves only
return the minimum amount.

I suggest the following changes:

1) Section 3.4, 4th paragraph. change to:

  "The handling of other types of ICMPv4 error messages depends
   on how much information is available from the encapsulated packet
   that caused the error."

2) Section 3.4, 6th paragraph, change:

  "If the offending packet includes enough data, the encapsulator MAY"

to:

  "If the offending packet includes enough data, or if enough data is
   available in the encapulator's cache, the encapsulator MAY"

3) Section 3.4, 7th paragraph, change:

  "Also, if sufficient headers are included in the error"

to:

  "Also, if sufficient headers are available"

4) Section 3.4, 8th paragraph, change:

  "Note that when IPv4 path MTU is exceeded, and ICMPv4 errors of only 8
   bytes of payload are generated,"

to:

  "Note that when the IPv4 path MTU is exceeded, and sufficient bytes
   of payload associated with the ICMPv4 errors are not available,"

>issues in tunneling in the network.

You appear to be bird-dogging me, Pekka; I have authored a
well-publicized series of closely-related documents. See:

   http://www.geocities.com/osprey67/tunnelmtu-02.txt
   http://www.geocities.com/osprey67/tunnelmtu-03.txt
   http://www.geocities.com/osprey67/tunnelmtu-04.txt
   http://www.geocities.com/osprey67/tunnelmtu-05.txt
   http://www.geocities.com/osprey67/tunnelmtu-06.txt
   http://www.geocities.com/osprey67/isatap/iemmei-00.txt
   http://www.ietf.org/internet-drafts/draft-templin-v6ops-iemmei-01.txt

(I could dig up the e-mail announcements for these, if interested.)

Fred L. Templin
[email-masked]

---

From: Pekka Savola <[email-masked]>
Date: Wed, 23 Jun 2004 08:46:18 +0300 (EEST)

> return the minimum amount.

The current spec AFAIK doesn't have anything which would prohibit from 
doing so, so this seems like spelling out a possible different 
approach to solve the same problem (an editorial fix).

On the other hand, by introducing a new feature, we would also create
a requirement that there must be two interoperable implementations of
this feature when going for DS, and that would seem undesirable.

Do you know of such implementations?

If not, I'm thinking that all the suggestions except item 2) are 
generalizing enough not to cause any trouble, so I could adopt them.

>    http://www.ietf.org/internet-drafts/draft-templin-v6ops-iemmei-01.txt

I think the difference here is that I was more interested in only
documenting the operational problems, you went a step ahead (or took a
different step) and started figuring out the modified mechanisms.  
I'm not so interested on that work, just getting the problems on the 
table.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Fred Templin <[email-masked]>
Date: Wed, 23 Jun 2004 10:16:05 -0700

Pekka,

See below:

>Do you know of such implementations?

Well, if we are talking about actions taken by the encapsulator, it seems
like the strategy is somewhat up to the individual implementation so
long as it is consistent with normative references, e.g., RFC 1122.

The feature is asymmetric in that it is implemented in the encapsulator
and does not require corresponding modifications in the decapsulator.
So, interoperability is based on whether modified encapsulator A
still interoperates with unmodified decapsulator B, i.e., we don't
need both A and B to implement the modification - right?

>generalizing enough not to cause any trouble, so I could adopt them.

See below for alternate wording suggestion on 2).

>>   available in the encapulator's cache, the encapsulator MAY"

To be more consistent with the other suggestions, could change this to:

   "If sufficient data bytes from the offending packet are available,
    the encapsulator MAY"

Fred
[email-masked]