Hi Tero, all, Any chance to conclude this issue? In particular, is there a benefit in following your proposal compared to the current approach in the draft?
Thank you. Cheers, Med > -----Message d'origine----- > De : IPsec [mailto:[email protected]] De la part de > [email protected] > Envoyé : jeudi 31 janvier 2019 08:17 > À : Tero Kivinen > Cc : IPsecME WG > Objet : Re: [IPsec] TR: I-D Action: draft-ietf-ipsecme-ipv6-ipv4-codes-02.txt > > 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 _______________________________________________ IPsec mailing list [email protected] https://www.ietf.org/mailman/listinfo/ipsec
