[xcp] Embedding XCP signalling in IP header
Tim Shepard
shep at alum.mit.edu
Thu Aug 19 04:31:12 PDT 2004
> > OK, why not use some mechanism (IPv4 option or TCP option, it doesn't
> > seem to matter) to query the other end's ability to use XCP and then
> > when you get an affirmative response, switching to an XCP header that
> > sits between IPv4 and IPv6? That seems much simpler to me.
>
>
> That would certainly be nice. But what if hosts decide to do the switch, but
> the path appears to be not XCP-capable? What about firewalls / NATs, traffic
> engineering / policy based routing schemes etc. which might all be making
> decisions based on the protocol field in the IP header, which would be
> changed once the switch from TCP to XCP would be made? And how would all this
> stuff be implemented on end nodes (switching the encapsulation method in the
> middle of a connection)? All those issues do not look that simple to me...
[ah, I missed this the first time it went by, and wound up replying to
later messages without having seen this context. -Tim]
The middlebox questions are certainly relevant.
The middlebox questions are relevant for your incompatible reuse of
the fragmentation fields also. Traffic engineering or policy based
routing schemes that look beyond the IP header to peek at the TCP port
numbers will be broken by the non-zero fragment offset fields. NATs
and firewalls will also be confused by the apparently fragmented
packets that they are receiving. Some firewalls reassemble IP
fragments so that they can inspect the content before forwarding the
packet on.
Middleboxes will be a challenge for XCP whatever the encoding scheme
may be.
> And how would all this
> stuff be implemented on end nodes (switching the encapsulation method in the
> middle of a connection)? All those issues do not look that simple to me...
I don't see what would be difficult for endnode stacks to handle a
switch in encapsulation method (TCP/IP to TCP/XCP/IP) after an initial
SYN SYN-ACK exchange. It seems simpler to do that then switch the
semantics of the IPv4 fragmenation-related fields in the middle of a
connection.
A separate header between IP and TCP with a new protocol number in the
IP header is unambiguous to anyone trying to debug why some middlebox
or endhost stack is not cooperating.
-Tim Shepard
shep at alum.mit.edu
More information about the xcp
mailing list