[email protected] writes: > > > [Med] This is more complicated compared to the current design in the > > > draft which allows to return a status code. The initiator will then > > > know whether it has to retry with another address family. > > > > I do no see any difference here. > > [Med] The difference is that the status codes in the draft reflect > the capabilities of the responder independently of the address > assignment.
That would be fine, if the responder could return this information before the initiator would do configuration request, so initiator could adjusts its request accordingly, but that would require moving those status notifications to IKE_SA_INIT, and for various reasons we try to keep that as small as possible, so I do not think that is correct place for those notifications. > > > > 2) Initiator is dual stack and requests both address families. If > > > > responder support both in same IKE SA, it will return address for > > > > both. > > > > > > [Med] Yes, but we need also to cover this case: > > > > > > o An initiator asks for both IPv4 and IPv6 addresses, but only one > > > address family can be assigned by the responder for policy > > > reasons. > > > > > > The initiator needs to know why only one address is assigned so that > > > it does not retry; hence the two separate codes. > > > > Initiator will know that it can get the address from the family that > > the responder returned. If there is no > > ADDITIONAL_ADDRESS_FAMILY_POSSIBLE status notification, that means no > > other family is possible, thus there is no point of trying to retry. > > [Med] Isn't odd to return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE for a > request which already asked for both AFs? Nope. We do that with other cases too. I.e., initiator did request for both address families, but responder said he want to do those as separate IKE SAs, and returned addresses for only one address family. The status notification indicates that initiator might create another IKE SA and request another address family in there. If it is not there, it will just have to cope with the address family it got in the response. This is same as what we do with ADDITIONAL_TS_POSSIBLE. > > > > Also I do not think making it MUST to include those notifications is > > > > something we want to do here. > > > > > > [Med] From an interoperability standpoint, MUST is justified here. No? > > > > No, as current implementations do not do that, thus this would make > > all existing implementations not conforming to this, and would most > > likely also require version number upgrade from the 2.0 to something > > larger, so other end would know whether other end supports this > > new MUST or not. > > > > Anyways we always leave that kind of decisions to the policy, i.e., > > even if the implementation is dual-stack, it might not want to request > > both addresses, if it only needs one. > > > > Also you cannot really have MUST do xxx, except yyy. That would be > > SHOULD, but in this case I think MAY is better. > > [Med] If we want more deterministic behaviors of initiators and more > interoperability, MAY is too weak. SHOULD would be OK. I would expect this is something that will be dictated by policy anyways, and unless policy says otherwise implementation that will support both address families always asks for both (I mean why not). So I do not think there is any real difference in MAY or SHOULD. Neither one of them can give any suggestion to the adminstrator making the policy, he will decided what to configure regardless what we do here in our documents. I still think MAY would be correct, but I do not complain if people in the WG think SHOULD is better. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
