Hi Tero, Thank you for the comments.
Please see inline. Cheers, Med > -----Message d'origine----- > De : Tero Kivinen [mailto:[email protected]] > Envoyé : mardi 29 janvier 2019 15:21 > À : BOUCADAIR Mohamed TGI/OLN > Cc : IPsecME WG > Objet : [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt > > [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. > [Med] Let's see what is complicated with these two codes. > 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. [Med] Yes. If it also supports another family it may > return ADDITIONAL_ADDRESS_FAMILY_POSSIBLE too. [Med] An initiator which is interested to receive both would naturally include both in its initial request. 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). [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. > > 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. 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. [Med] I'm afraid this is more complicated compared with the current design which assumes that an initiator which interested to receive both AFs will include both in the initial request. > > 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? 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
