[xcp] Embedding XCP signalling in IP header
mathis at psc.edu
Wed Aug 18 19:47:33 PDT 2004
I don't think this works unless you can absolutely disable fragmentation in
both endpoints and the path. I still do not understand all of the strangeness
that middle boxes might attempt, but it could be argued that they are at least
as wrong when something breaks. Note that in most stacks fragment reassembly
happens long before protocol dispatch and port matching (it has to!), which
greatly complicates overloading the bits.
This also prevents XCP from being used under some middle services, e.g. NFS/UDP
which typically relies on IP fragmentation as its packetization layer. (Note
that draft-mathis-pmtud-method-02.txt recommends and several OS's already set
DF on IPv4 fragments to prevent re-fragmentation.)
It may be true that if MF and Frag Offset are both zero, then the IP ID is
effectively unused and could be transparently redefined (possibly keyed on bit
16 as well). This slightly different way of specifying it (which may be the
same as your proposal) has the advantage that it is stateless at the IP layer
and interoperates with standard fragmentation, but the transport layer can
detect corruption (e.g. unexpected fragmentation.) Note that if there is
unexpected fragmentation and the IP ID is effectively constant, major data
corruption is likely. See draft-mathis-frag-harmful-00.txt Down stream changes
to the IP ID may also result in complete protocol failure.
If the transport protocol detects fragmentation, it should disable XCP on the
I believe that this breaks header compression (it assumes roughly sequential IP
IDs) and collides with at least one other proposal to overload IP ID.
Matt Mathis http://www.psc.edu/~mathis
"My heart is in the work." -- Andrew Carnegie
On Wed, 18 Aug 2004, Marko Zec wrote:
> On Wednesday 18 August 2004 19:14, Tim Shepard wrote:
>> I very quickly skimmed your text.
>> I believe this would be incompatible with current stacks. Just
>> because the DF bit may be turned on does not mean that a host
>> receiving an IPv4 header with something other than zero in the MF and
>> Fragment Offset fields will ignore them. I believe it will continue
>> to use those fields to reassemble the complete datagram.
> Good point. Here's how the proposed scheme takes care of this issue (copy and
> paste from the original draft):
> End nodes must maintain XCP capabilities state on per connection and per
> flow basis. That said, each end node is allowed to transmit only frames
> of Type 0 (XCP-CPR) until it has determined its peer is XCP capable.
> XCP-CPR (capability probe) format:
> 0 1 2 3
> 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
> |0|0|0|0|R| Unu | Time To Live |1|1|0|0|0|0|0|0|0|0|0|0|0|0|0|0|
> | | | | |P| sed | Check | | | | | | | | | | | | | | | | |
> Bit 4: (RP) Reverse Path 0 = not XCP capable, 1 = XCP capable.
> Bits 8-15: (XCP-TTL) Time To Live Check
> XCP-CPR transmission:
> The transmitting endpoint must fill in the fields in XCP-CPR header
> as follows:
> RP flag is set to the per-connection state indicating whether the
> reverse path (from the receiver to the sender) is XCP capable.
> Initially the node has no knowledge on network path capabilities, so
> it must set the RP flag to zero.
> XCP-TTL must be set to exactly the same value as in the standard IP
> header TTL field.
> All other bits have to be cleared, in order not to confuse receiving
> endpoints incapable of XCP processing. Otherwise, such nodes might
> interpret the Fragment Offset field, which would result in
> transmitted packet ending up in the reassembly buffer and never
> being propagated the upper protocol layer.
> So, in other words, the XCP-CPR message format has been choosen precisely to
> prevent non-XCP hosts from being fooled by receiving XCP messages. Once both
> peers confirm to each other they can speak XCP, there's no fear of
> misinterpretation of messages stored inside the Fragment Offset field, so we
> can then safely start using all those bits in XCP-FWD and XCP-RFL messages.
>> In other
>> words, the DF bit means "do not fragment further". You can still do
>> end-to-end fragmentation and reassembly with IPv4 and yet have the DF
>> bit turned on in all the packets carrying the fragments.
>> (Can someone confirm this?)
>> -Tim Shepard
>> shep at alum.mit.edu
More information about the xcp