[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: the small stuff
Iljitsch van Beijnum wrote:
Forking
Somehow the assumption crept in that we need to support "context
forking". The trouble with this is that there are two or more context
for communication between the same ULID pair. This is problematic
because now packets must somehow be tagged on their way through the
stack from the application to the shim so the shim knows which context
to apply, based on the wishes of the application.
I don't really see the advantages here. The idea is that this is useful
so different applications can take different paths through the
networks. I have no problem with that, but doing it inside the shim is
a rathole: applications should just select the ULIDs associated with
the desired path. The shim mechanism can then be relegated to repairing
failures, and maybe provide some coarse traffic engineering at the most.
It might be useful to add a shim exchange that can support selecting
the right ULIDs in this case, though: that would be fairly light-weight.
That would be an option.
My understanding is that the request to be able to do forking (which
we've interpreted as different ULP traffic being able to use different
locator pairs to get to the same destination host), was requested by
some transport folks.
I don't know if we have a mechanism to ask them (whoever they were)
whether it is acceptable to do this using a ULID selection mechanism, or
whether the ULIDs should be the same but the locators different.
In either case, the ULP needs to be updated to be capable to make the
shim setup forked context, so I assume there is some flexibility on
their end.
Length fields
I'm not happy with 16 bit length fields or length fields expressed in
64-bit/8-byte units because of padding issues. In the latter case,
padding to an even 8 bytes will always be required which is very
inconvenient for fields with variable length content. Also, a 16-bit
field would either require padding or sometimes straddle 16-bit
boundaries, which means the two bytes must be extracted individually
and then be glued together to form a 16-bit field again.
If we only need longer fields for a very small number of variables,
it's easier to redefine these variables so that they are broken in
255-byte chunks and put in two or more fields.
This is an issue for the shim control messages. They need to be able to
carry
- lists of locators
- CGA parameter data structure
- CGA public key signature
and I think we concluded that at least the last one might be larger than
256 bytes. But I don't know how large the PDS might be.
However, I don't think there will be any significant difference in the
size of these shim control messages if we relax the alignment rules for
the options and make the length field be a single byte.
I'm not personally concerned with saving a few bytes in a control
message that might be a few hundred bytes.
Checksums
We didn't get a chance to discuss the issues surrounding the upper
layer checksum. As I've said before, I think we're best off rewriting
the TCP/UDP checksums along with the addresses. If we don't do this,
transport checksum calculation offloading will be a big problem in
IPv6. The potential for harmful actions from firewalls and such that
don't see a valid checksum is also significant. Howevever, this is
somewhat related to the suppressing of the shim header issue.
And as I've said before, I think this is a very bad idea.
In some cases, such as ESP, the shim might not be able to rewrite the
TCP checksum. So if we were to do this, then we'd end up with the
semantics of the checksum field being different depending on what
extension headers are in place.
I don't understand the statement which ends win "big problem in IPv6".
Are you assuming that a lot of packets will be sent with a locator pair
that is different than the ULID pair?
I think failures are and will be infrequent, so the fraction of shim
capable traffic which will be sent with a locator pair that is different
than the ULID pair will be vanishingly small.
When the ULID pair == locator pair, the packets are exactly as today, so
any checksum offloading will work.
And there are ways to do checksum offloading that is flexible enough to
even handle the (infrequent) case of ULID pair != locator pair.
Demux on source with shim header
A question we also didn't get to explore is on which fields we use to
recognize a shim context when the shim header is present. I think the
assumption has been source/context tag/dest. Since the number of
destination addresses is very small and the sets are going to overlap,
we may as well toss out the destination address. If we also throw out
the source address and do demux on just the context, this means we
don't have to synchronize knowledge of the source locators on both
ends. (I.e., without this the source can only successfully use a
locator when the destination knows it should expect this locator.) And
it allows source address rewriting by routers. The protocol number for
the shim header should be enough to tell the router that this is ok, so
there is no ambiguity in this decision. On the other hand this means
attackers can try to spoof the context tag without needing to get
source address right. So essentially we're giving up on ingress
filtering for the most part.
I think that *if* we want to keep the door open to routers rewriting the
source address field, then we should seriously consider 1) expanding the
context tag to 47 bits and 2) look at the security impact of not using
the source address as part of the lookup of the context on the receiver.
But I don't get the feeling that the WG has come to consensus on whether
we want to consider having routers rewriting the source address.
Erik