[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

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



Pekka,

Pekka Savola wrote:

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.


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,"

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



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 ftemplin@iprg.nokia.com



---------- Forwarded message ---------- Date: Tue, 15 Jun 2004 15:45:40 -0400 From: Internet-Drafts@ietf.org To: i-d-announce@ietf.org Cc: v6ops@ops.ietf.org 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 i-d-announce-request@ietf.org 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:
	mailserv@ietf.org.
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.