Paul Wouters writes: > On Tue, 22 Sep 2020, Valery Smyslov wrote: > > >> That is not how the CP payloads work. The initiator sends a set > >> it is okay with and the responder picks what it prefers from that > >> set. Or an error if it deems all of it bad. > > > > Exactly. However, with different attribute types the client can > > indicate its capabilities too and can prioritize them (by adding > > attributes to the request in the order of client's preference). > > I don't think the Configuration Payload order significies a > preference for anything? Does RFC 7296 really say that?
Not exactly. It does say that for Security Association Payloads, and I think mostly people have been assuming that same applies for other things too (like CERTREQs, or Hash algorithm negotiation of RFC 7427). It would be logical to assume same applies to the Configuration Payloads, for example the first DNS server address is the preferred, or the first INTERNAL_IP_ADDRESS returned is preferred one and others are aliases... -- kivi...@iki.fi _______________________________________________ IPsec mailing list IPsec@ietf.org https://www.ietf.org/mailman/listinfo/ipsec
