-------------------- Jari Arkko (2005-10-19): https://www.machshav.com/pipermail/mobike/2005-October/001133.html *minimal conformance requirements* > Note that both peers can have their own policies about what addresses > are acceptable to use. A minimal "mobile client" could have a policy > that says that only the responder's address specified in local > configuration is acceptable. This kind of client does not have to > send or process ADDITIONAL_*_ADDRESS notifications. Similarly, a > simple "VPN gateway" that has only a single address, and is not going > to change it, does not need to send or understand > ADDITIONAL_*_ADDRESS notifications. > > I think we discussed this previously (and I have not yet checked what the result of that discussion was). However, the above client text sounds a bit too flexible in my opinion. -------------------- Jari Arkko (2005-10-23): https://www.machshav.com/pipermail/mobike/2005-October/001159.html I checked issue #46 where we discussed this before. The conclusion appeared to be that for the gateway the current text is OK. On the client part I don't think we decided anything. However, when thinking about this it seems that even the gateway part is suspect. It is true that you don't need the additional addresses on a gateway that is a responder. However, if this gateway is working in gateway-to-gateway mode and is an initiator towards the peer gateway which has multiple addresses, then we need it. We could try to describe all this, but I think the cost of that is greater than simply saying that nodes that conform to this specification need to be able to understand the additional addresses. It is another matter what needs to be sent. Here's a proposed text change: Note that both peers can have their own policies about what addresses are acceptable to use. A minimal "mobile client" could have a policy that says that only the responder's address specified in local configuration is acceptable. This kind of client does not have to send or process ADDITIONAL_*_ADDRESS notifications. Similarly, a simple "VPN gateway" that has only a single address, and is not going to change it, does not need to send or understand ADDITIONAL_*_ADDRESS notifications. => Note that a node that has only a single address at any given time does not need to send ADDITIONAL_*_ADDRESS notifications, but all nodes that support this specification must understand the reception of such notifications. However, nodes MAY have their own policies about what addresses are acceptable to use. -------------------- Jari Arkko (2005-10-23): https://www.machshav.com/pipermail/mobike/2005-October/001162.html I noticed that Section 6.5 also has some text on this. Aligning the above proposal with that: Note that a node that has only a single address at any given time does not need to send ADDITIONAL_*_ADDRESS notifications, but all nodes that support this specification must understand the reception of such notifications. However, nodes MAY have their own policies about what local or peer addresses are acceptable. One possible policy on a client is that it refuses to talk to other gateway addresses than the configured one. This policy would imply that it should ignore peer's additional addresses, and, since it is the initiator, it does not need to send its own additional addresses as it will be in charge of all address changes in any case. -------------------- Tero Kivinen (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001174.html That is ok for me. -------------------- Pasi Eronen (2005-10-24): https://www.machshav.com/pipermail/mobike/2005-October/001182.html I think the problem can be fixed simply by changing "client" to "initiator" and "gateway" to "responder". IMHO this is even more confusing than the original text... Having a single address at any given time doesn't really have much to do with this paragraph. Even if a node has several addresses, it does not need to send ADDITIONAL_*_ADDRESS notifications if either (1) it doesn't want to use those addresses for IPsec traffic, or (2) the node is the initiator, and it does not want to use any other responder addresses. Furthermore, the responder does not have to understand ADDITIONAL_*_ADDRESS notifications (beyond treating them like any other unrecognized status notification; that is, ignoring them) if it's not going to change its address. How about rephrasing this as follows? Note that both peers can have their own policies about what addresses are acceptable to use, and certain types of policies may simplify implementation. For instance, if the responder has a single fixed address, it does need to process ADDITIONAL_*_ADDRESS notifications it receives (beyond ignoring unrecognized status notifications as already required in [IKEv2]). Furthermore, if the initiator has a policy saying that only the responder address specified in local configuration is acceptable, it does not have to send its own additional addresses to the responder (since the responder does not need them except when changing its own address). -------------------- Jari Arkko (2005-10-24) https://www.machshav.com/pipermail/mobike/2005-October/001183.html Yes. Yes -- as long as we are talking about a "responder" and not a "gateway". Works for me. Thanks. -------------------- Mohan Parthasarathy (2005-10-25): https://www.machshav.com/pipermail/mobike/2005-October/001211.html > How about rephrasing this as follows? > > Note that both peers can have their own policies about what > addresses are acceptable to use, and certain types of policies > may simplify implementation. For instance, if the responder > has a single fixed address, it does need to process > ADDITIONAL_*_ADDRESS notifications it receives (beyond > ignoring unrecognized status notifications as already required > in [IKEv2]). Furthermore, if the initiator has a policy saying In section 4.5, it talks about how a responder can try a different address for its peer. The responder itself has only one address but it can try different peer addresses. Or Are you saying that the policy says don't try different peer addresses ? > that only the responder address specified in local > configuration is acceptable, it does not have to send its own > additional addresses to the responder (since the responder > does not need them except when changing its own address). > This is still confusing to me :-) -------------------- Pasi Eronen (2005-10-28): https://www.machshav.com/pipermail/mobike/2005-October/001238.html That part of Section 4.5 (in -04; Section 3.6 in -05) talks about what is done when the responder's address changes. The text about having a "single _fixed_ address" was trying to say that the address doesn't change, so that part of Section 4.5 doesn't apply. --------------------