[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: Flow label versus Extension header - protocol itself

On 3-mei-2005, at 12:14, Francis Dupont wrote:

So basically what you're saying is that we need to have a moratorium
on new extension headers just because SOME hard/software used by SOME
people may not support it.

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

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

There is no requirement that routers be able to parse the entire protocol chain for all packets they forward.

   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.

But since there isn't a huge installed base we still have the opportunity to "do the right thing" even if it's inconvenient for currently deployed systems, because the number of such systems is still limited.

   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. 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) and complexity than it saves in compatibility and potential to save overhead by having more than one option in the header.

   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, or we'd have to use another protocol (UDP?) to implement parts of the shim, creating the opportunity for some shim packets to pass filters and some to be blocked, which is a headache.

   options but could very well live in the same extension header as a
   demux option.

=> I don't buy this argument! 

We'll have to disagree then.