mohamed.boucadair@xxxxxxxxxx writes: > > At the IETF process level, which I don't master, because of last > > note in §4, shouldn't that document explicitly say it updates > > RFC8598? > > [Med] We discussed this point at the time (and I was personally for > adding the header), but we didn't because the convention in ipsecme > WG is to not add the Update header if implementations are clearly > able to distinguish the cases when an extension is being used even > if the extension would change the behavior defined in the existing > RFCs. In this spec, if the initiator receives any of ENCDNS_IP* > attributes, it will know that it should not expect the > INTERNAL_IP*_DNS even if it receives INTERNAL_DNS_DOMAIN too. The > note you are referring to is to make that clear. I think we usually use updates header if implementations supporting old RFC but not this, needs to change their behavior. I.e., if we just add new attributes, and the implementations of old RFC simply ignore them then everything is fine. But my understanding is that this is not the case here, as if you send INTERNAL_DNS_DOMAIN without INTERNAL_IP*_DNS but with ENCDNS_IP* to implementations supporting old RFC, then that RFC will consider this as a fatal error, and tear down the whole IKE SA, instead of silently ignoring ENCDNS_IP* and INTERNAL_DNS_DOMAIN attributes. So in this case it would be better for the old Split DNS Configuration for IKEv2 RFC8598 implementations to be changed in a way that they recognize this situation and do not consider it as a fatal error. Update to the RFC8598 would not be needed if the RFC8598 implementations would simply ignore both the INTERNAL_DNS_DOMAIN and ENCDNS_IP* in configuration payload, but I do not think that is the case here. So question is not whether it is possible to recognize the situation, it is what happens when you combine new and old implementations. If things works without a need to change old implementations then no updates is needed, if you need to update the old implentations too, then you do need updates header. -- kivinen@xxxxxx -- last-call mailing list last-call@xxxxxxxx https://www.ietf.org/mailman/listinfo/last-call
