Hi Thomas,
I am fine with your suggestions. Just the following nit:
Are locator types critical? What happens when a host tries to add or
move to a locator which is not supported by its peer?
I agree with your point that it is probably useful to define some error
behavior to distinguish between unsupported Locator Types and dropped
packets.
There is a HIP NOTIFY mechanism defined in the base spec which could be
reused for this purpose. I would suggest that we define a new Notify
Message Type in the range 31-50 for "LOCATOR_TYPE_UNSUPPORTED", with
the Notification Data field containing the Locator(s) that the receiver
failed to process.
The following rules seem appropriate:
> - a HIP host SHOULD send a NOTIFY error if an unsupported Locator
> Type is received in a LOCATOR parameter, when such Locator
is also declared to be the Preferred locator for the peer
> - otherwise, a HIP host MAY send a NOTIFY error if
an unsupported Locator Type is received in a LOCATOR parameter
Shouldn't the transmission of the NOTIFY be a "MUST" in the special case
where the LOCATOR parameter contains /only/ locators of unsupported type?
The preferred locator would in this case remain the same as before,
meaning that it would be in DEPRECATED status.
Best,
- Christian
--
Christian Vogt, Institute of Telematics, Universitaet Karlsruhe (TH)
www.tm.uka.de/~chvogt/pubkey/
_______________________________________________
Ietf@xxxxxxxx
https://www1.ietf.org/mailman/listinfo/ietf