Re: New Version Notification for draft-tsou-6man-hbh-header-update-00.txt

[RJ Atkinson <[e-mail]>]

On 08  Mar 2012, at 23:53 , sreenatha wrote:
> So here what is the advantage we will get by
> inserting the header and immediately processing the header?

Correct IPv6 protocol behaviour in *all* cases, 
instead of being correct only in some cases.

> In draft we just saying that source node which is
> inserting the HopByHop header no need to process it again.

That can lead to incorrect IPv6 protocol behaviour 
in some cases, as others have explained already.

Note well that the existing IPv6 specifications do NOT place 
constraints on the internal implementation details of a 
particular IPv6 implementation, but instead the IPv6 
specifications place constraints on the externally visible 
IPv6 packet processing behaviour that the particular IPv6 
implementation provides/demonstrates. 

By contrast, this draft actually proposes to change the 
requirements on the *externally visible* packet processing 
behaviour, and the proposal will cause incorrect IPv6 operation 
in several identified real-world cases. 

IF (and this is a critical important IF) one's implementation
provides the correct packet processing behaviour in *all*
cases, and one's implementation is fully interoperable in *all*
cases, then no one else cares how one's implementation internals
are organised or executed.  

So if the authors' concern was flexibility in implementation strategy, 
and provided the chosen implementation strategy provides the correct 
IPv6 packet processing behaviours in *all* cases, then there is
no need for this draft to exist at all.

[Credit where due: most or all of those cases that would be
harmed by this I-D were originally identified by folks other than me.]

I continue to object to this draft on grounds that it will
create interoperability problems and will allow incorrect
IPv6 packet processing behaviours in several identified
real-world situations.

(begin new topic)

More generally, the IPv6 WG appears to be receiving too many 
proposals to make IPv6 specification changes.  In broad terms, 
those proposals HARM and DELAY the current deployment of IPv6.  

One of the most serious criticisms about IPv6 from users and 
network operators (e.g. educational, research, commercial, 
governmental, residential, home, or other network operators) 
is that *the IPv6 specifications keep changing* without there
being an absolute need to change the specifications.

IPv6 needs specification stability, ideally zero changes and
at most bug-fixes for well-documented, current, real-world, 
operational issues, if IPv6 is going to be deployed globally 
in time.

Yours,

Ran