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

From: sreenatha <[email-masked]>
Date: Fri, 09 Mar 2012 10:23:36 +0530

Hi Ran,

   I went through the RFC's which Brian mentioned. For Quick Start option,
while inserting the option only they can do whatever processing need to be
done.(Decrementing TTL value in the option. If Application is inserting the
Quick Start option means, node is supporting for Quick Start, so it can
decrement the TTL and insert the option.)

   In most of the ipv6 stack implementation currently exist(It includes
FreeBSD), ip6_output_function implementation is like this:

   Ip6_output_function()

   {

      ----

      ----

      ----

      ----

      If (HopByHop header need to be insert(any options in under HopByHop
need to insert))

           Insert the options.

      ----

      ----

      ----

      /*Since RFC 2460 mandates even source should process the HopByHop
header, do the processing.*/

      If (HopByHop header is present)

           Process the options.

      ----

      ----

      ----

      ----

   }

   So here what is the advantage we will get by inserting the header and
immediately processing the header? If we inserting the header correctly,
always Processing of the header will be valid. This only I suggested no need
to process in source. 

  And in case of node which is acting as both Host and Router:

    Node behaves differently for Packets which are originated from itself
and for packets which are need to be forwarded.

    For packets originated by itself,

    Ip6_output_function  will be called to send out the packets. HopByHop
header insertion and processing is explained above.

    For packets need to be forwarded:

    Ip6_input_function followed by Ip6_forward_function is called.

    HopByHop header processing will be done in Ip6_input_function during
forwarding. 

   So no question of skipping HopByHop header processing by Node which is
acting both as Host/Router.

In draft we just saying that source node which is inserting the HopByHop
header no need to process it again. It might be any options under HopByHop
header, while inserting only it will insert correctly(If implementation
follows correct specification of that Options!) So again processing the
header is unnecessary what I am feeling. (As in ip6_output_function)

Thanks-

B.Sreenatha Setty,

Message: 5

Date: Thu, 8 Mar 2012 14:42:57 -0500

From: RJ Atkinson <[email-masked]>

To: [email-masked]

Subject: Re: FW: New Version Notification for

      draft-tsou-6man-hbh-header-update-00.txt

Message-ID: <[email-masked]>

Content-Type: text/plain; charset=us-ascii

I agree with Joel H's note here:

      <http://www.ietf.org/mail-archive/web/ipv6/current/msg15503.html>

I also agree with Brian C's note here:

      <http://www.ietf.org/mail-archive/web/ipv6/current/msg15514.html>

I think it important that we do not make changes that effectively close the
door on Quick-Start.

Also, mindful of Brian's scenario, where a single device is acting both as
host and as relay/router, it is very likely that a CALIPSO-enabled host
function would emit a packet that the CALIPSO-enabled router function would
be required to at least parse, lex, and compare with the allowed CALIPSO
label ranges on the candidate output interface.

While CALIPSO is only deployed in selected networks, I understand that those
networks often are built out of off-the-shelf equipment and software.

Yours,

Ran

---

From: RJ Atkinson <[email-masked]>
Date: Fri, 9 Mar 2012 07:38:51 -0500

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