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

[Pekka Savola <pekkas@netcore.fi>]

On Thu, 17 Jun 2004, Fred Templin wrote:
> 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.

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.

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