Re: Flow label versus Extension header - protocol itself

[Francis Dupont <Francis.Dupont@enst-bretagne.fr>]

 In your previous mail you wrote:

   > => yes, this is what I believe.
   
   Well, I find that unacceptable. If you and other people feel this  
   strongly, we need to do something about RFC 2460 so it becomes  
   possible to add new extension headers more easily.
   
=> it seems you don't understand the power of IETF: if to publish a
document is enough to enforce something, why not bannish NATs?

   >    Since in this case the only problem that they have is that they  
   > won't
   >    be able to use the new feature (shim6 multihoming) I don't see why
   >    this should be a problem at all.
   
   > => perhaps you should consider the difference between a host and a  
   > router?
   
   Is there a difference?  :-)
   
=> for this discussion yes, shim6 will be implemented into end nodes,
and my concern is about routers and middleboxes.

   There is no requirement that routers be able to parse the entire  
   protocol chain for all packets they forward.
   
=> in fact IMHO they should not... but it is not reasonnable to
ignore classifiers and all kinds of filters.

   >    And since only a tiny percentage of all users has IPv6 in the first
   >    place and a tiny percentage of those users has a firewall, I really
   >    fail to see the problem.
   
   > => you are considering IPv6 as a toy (worse, as your toy) (:-)!
   
   Nope, certainly not. I actually make some money with IPv6. Not a lot,  
   but enough to take it seriously.
   
=> so you should understand that breaking already deployed networks will
cost money and delays.

   But since there isn't a huge installed base we still have the  
   opportunity to "do the right thing"

=> we still have no consensus about what is the right thing, and
only one proposal has clearly a deployment issue...

   even if it's inconvenient for currently deployed systems, because
   the number of such systems is still limited.

=> so we should put the destination address before the source one
in the IPv6 header (to fix a clear mistake of IPv6) too? Even
Steve Deering gave up about this many years ago...
BTW one of the goals of SHIM6 is to be deployed in a reasonnable
time scale, isn't it?
   
   >    The trouble with a destination option is that you need to spend 8
   >    bytes so you get a 4 byte payload, and the possibility of having
   >    multiple destination options that need to be in different places in
   >    the protocol chain is just asking for nasty bugs.
   
   > => so Mobile IPv6 should not work?
   
   Not sure what you mean.

=> Mobile IPv6 uses a destination option at a not-standard-at-its-time place.

   I have no first hand knowledge that MIPv6  
   indeed works, nor do I have a great desire to see it work, because I  
   don't believe it fills much of a need. But obviously mechanisms that  
   use destination options CAN work. It's just that in my opinion,  
   having a destination option costs more in overhead (2 extra bytes)  

=> this overhead is an illusion if the shim6 extension header is 8-byte
aligned and the tag size a power of two...

   and complexity

=> don't joke: destination options are not so complex!

   than it saves in compatibility and potential to save  
   overhead by having more than one option in the header.
   
=> IMHO the main advantage of a destination option is the action about
an unknown one is already known (and encoded into its type), when
the action about an unknown extension header is not or unfortunately
restricted to drop the packet...

   >    Also, we need two
   >    other mechanisms (reachability detection and capability/security
   >    negotiation) that aren't naturally suited to being destination
   
   > => they are not end-to-end?
   
   In most cases they will be. (It should be possible to implement the  
   shim in middleboxes.) However, the reachability detection and  
   negotiation packets will generally not carry higher-layer data so  
   then there would be a destination option as sole payload,

=> piggy-backing or not again... Seriously you should look at the
discussion about this in Mobile IPv6 which, BTW, opened the path
(cf RFC2401bis for instance).

Regards

Francis.Dupont@enst-bretagne.fr