[email protected] writes: > First of all, I'd like to thank all those of you who commented > during the ipsecme meeting on this draft. This is exactly the > feedback I was looking for. > > The message I got from the WG after watching the recording is to > reduce the number of requested codes which I did in -02. This is > almost close to what is suggested by Valery and Tero. I hope that > this issue is now closed.
Sorry, for taking this long to come back to this, but I think it is still too complicated. We have following cases: 1) Initiator only supports/wants one address family, and it requests it. If responder supports that address family it will give address from that address family. If it also supports another family it may return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE too. If responder does not support address family requested it will return INTERNAL_ADDRESS_FAILURE (and perhaps include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE if request would succeed with another address family). 2) Initiator is dual stack and requests both address families. If responder support both in same IKE SA, it will return address for both. If it only supports one at time then it returns address for that and include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE to indicate that making another IKE SA will allow asking another set addresses. Also I do not think making it MUST to include those notifications is something we want to do here. I think the responder MAY include them if it feels like, but of course 3gpp can then make their own requirements that this feature must be supported there... I.e., ADDITIONAL_ADDRESS_FAMILY_POSSIBLE status notification indicates that regardless whether your request succeeded or failed, the responder would support another address family than what you asked (if request failed), or what was returned (if request succeeded). As addresses are part of the IKE SA, I guess that if initiator asks for both, but do get only one of them and also got status of ADDITIONAL_ADDRESS_FAMILY_POSSIBLE, then it needs to make new IKE SA and request that another address family in that another IKE SA. -- [email protected] _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
