[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Review comments on draft-ietf-shim6-proto-03.txt
El 16/02/2006, a las 20:26, Erik Nordmark escribió:
Geoff Huston wrote:
In response to your query (and Erik can correct me if I'm wrong) It
is my understanding in the specification that whenever the ULID pair
is used as the locator pair then the SHIM6 extension header (the
context value) is omitted from the packet. This allies to the initial
contact pahse, and also in any subsequent time when the SHIM selects
the ULID pair as the current locator pair.
Correct. But folks have also suggested that we should allow the shim6
extension header all the time i.e., even if the receiver doesn't have
to rewrite the locators. I don't see any harm in allowing this for
folks that want their packets to be bigger...
FWIW, i think may be useful if we ever want to support prefix rewriting
by exit routers. I mean, if we want to support this, the way i
understand this could be, is that endpoints would establish a shim
session between them and then they would let routers to rewrite source
prefixes for those packets belonging to the established context. In
that case, it would necesary for the ednpoint to identify those packets
that belong to the shim context hence they should include the payload
header even if they are using the ulids as locators.
So, i would suggest to allow this behaviour, or at least not explicitly
i.e. it is my understanding that the packet header is simply an
implicit "please perform an address substitution" instruction to the
other end, and the locator pair plus the context value identifies the
particular substitution to a ULID pair that the remote end should
perform. If the locators are the ULID then no substitution is
necessary, and no extension header is necessary.
At least thats the way I interpret the specification, and I was
wondering if this should be explicitly stated in the spec.
If we allow the above, it is really "please lookup the context state
and check if you need to replace the locators", but since replacing
the locator pair with the identical locator pair can be still viewed
as a replacement, that's just a detail.
Any ideas where such text would best belong in the specification?
imho it would be enough to make sure that the document does not
precludes such behaviour...
OTOH, we could include a note in the Sending/receiving payload packets