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

[sreenatha <[e-mail]>]

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 <[e-mail]>

To: [e-mail]

Subject: Re: FW: New Version Notification for

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

Message-ID: <[e-mail]>

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