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

[Fred Templin <ftemplin@iprg.nokia.com>]

Pekka,

See below:

Pekka Savola wrote:

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

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?

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


See below for alternate wording suggestion on 2).


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

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