Hi Tero, Please see inline.
Cheers, Med > -----Message d'origine----- > De : Tero Kivinen [mailto:[email protected]] > Envoyé : mercredi 30 janvier 2019 21:42 > À : BOUCADAIR Mohamed TGI/OLN > Cc : IPsecME WG > Objet : RE: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt > > [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. [Med] That wasn't my point. My comment is that the codes are static even if they are made during address configuration. That is: (1) An IPv4-only responder will always include IP4_ONLY_ALLOWED independently of the request (IPv4, IPv6, IPv4 and IPv6). (2) An IPv6-only responder will always include IP6_ONLY_ALLOWED independently of the request. (3) A dual-stack responder configured with an IPv4 preference will always include IP4_ONLY_ALLOWED in a response to a dual-stack request. (4) A dual-stack responder configured with an IPv6 preference will always include IP6_ONLY_ALLOWED in a response to a dual-stack request. The behavior of the initiator is more deterministic, e.g., when case (1) is encountered: - An IPv6 initiator will stop trying asking for IPv6 addresses. - A dual-stack initiator who asked for both won't try with a separate request for IPv6 - A dual-stack initiator who asked first for IPv4 won't sent a request for IPv6 - A dual-stack initiator who asked first for IPv6 will send a request for IPv4 Now consider that ADDITIONAL_ADDRESS_FAMILY_POSSIBLE is to be defined, this code will returned with the following conditions: (a) An IPv4-only responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE only if the initiator asked for IPv6. (b) An IPv6-only responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE only if the initiator asked for IPv4. (c) A dual-stack responder will include ADDITIONAL_ADDRESS_FAMILY_POSSIBLE if the initiator asked for both, but for policy matters only one AF can be assigned per request. The behavior of the initiator is less deterministic, e.g., case (c): A dual-stack initiator who asked for both but got only IPv6 or IPv4 does not know why the other address is not assigned. It will then send a request to try to get an address. Protocols with rich error codes makes it easier to adjust the behavior, to diagnostic, etc. > > > > > > 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. [Med] OK, I see, this is doing the same job as what we used to have in -01: o SINGLE_AF_SUPPORTED: This status type indicates that only a single address family can be assigned per request, not both. This status type is returned when an initiator requested both IPv4 and IPv6 addresses/prefixes in the same request, but only a single address family can be assigned per request by the responder. The address family preference is defined by a policy that is local to the responder. If a responder receives a request for both IPv4 and IPv6 address families, it replies with the preferred address family and includes SINGLE_AF_SUPPORTED notification status type. Upon receipt of this status type, the initiator MAY re-issue another configuration request to ask for an additional address family. I have removed that code because the message I got from the working group is to reduce the number of codes. > 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
