Sally Floyd; > "As Figure 5 shows, in many cases no connection was established when > the [IP] Record Route Option or the [IP] Timestamp Option was included in > the SYN packet. When IP Option X [a new IP Option; e.g., QuickStart] > is included in the SYN segment, the connection was not established > to over 70% of the web servers tested. This does not bode well for > the deployment of new IP options in the Internet." It implies that mobile IPv6 depndeing on routing header may not work. > If something like QuickStart was ever standardized, > the IP Option would only be needed on the path *from* the web server > to the browser. Presumeably if the web server wanted to use something > like QuickStart, it could have the firewall configured to allow the > IP QuickStart Option not to be blocked on the outgoing SYN packet? > And the receiver could have the firewall on their end configured > to allow the IP QuickStart option on the incoming SYN packet to > pass? I don't know. Presumeably if the web server wanted to use something like PMTUD, it could have the firewall configured to allow related ICMP not to be blocked. And the receiver could have the firewall on their end configured to allow the ICMP to pass. You know. > However, the fact that connections fail today > when unknown IP Options are used on the SYN from the browser to the > web server does not *necessarily* mean that there is no hope for > using IP Options for in-band signalling. Same for PMTUD with out-band signalling. > The good news is that known or unknown TCP options are not blocked > on paths to web servers. Or at any rate, the connection still > succeeds in being established... As long as routers are not required to look into TCP options, they are likely to interoperate even with complex TCP options. Masataka Ohta _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf