Julien Laganier: I have a couple of questions regarding the dependance between SEND and default address selections algorithms [RFC3484]. While using SEND, a node only benefits from SEND if itself and its on-link correspondent (that is, either an on-link router or the other communication endpoint if it's on-link) both uses a CGA to mutually denotes each other. Hence, perhaps the SEND protocol specification should state that: "Rule X: Prefer CGA. If SA is a CGA and SB is not, then prefer SA." ? In case the remaining questions being: o Where should this check be done relatively to others source address selection rules (like home/CoA or public/tmp checks)? o Should the sense of this preference be reversible for (mostly diagnostic) applications that aren't interested in having a "secure" network (e.g., parallel fping) ? An addendum might be "Implementations MUST/SHOULD provide a mechanism allowing an application to reverse the sense of this preference and prefer non-CG-Addresses over CG-Addresses (e.g., via appropriate API extensions)." What do you folks think? BTW, I co-authored a draft about a source address selection API allowing to tweak RFC3484 specified default behavior that partly address the CGA case: ---------------- Jari Arkko: > While using SEND, a node only benefits from SEND if itself and its on-link > correspondent (that is, either an on-link router or the other communication > endpoint if it's on-link) both uses a CGA to mutually denotes each other. There might be some partial benefits if one of the parties uses SEND. But I agree. > Hence, perhaps the SEND protocol specification should state that: "Rule X: > Prefer CGA. If SA is a CGA and SB is not, then prefer SA." ? I think this is what should happen, not sure yet who needs to actually state that and in which document. > In case the remaining questions being: > > o Where should this check be done relatively to others source address > selection rules (like home/CoA or public/tmp checks)? Good question. This appears to depend on the user preferences of e.g. security vs. availability or security vs. speed. Anyway, perhaps the practical thing that will happen is that if your node is CGA-enabled, it probably has all of its addresses CGA addresses, and does not use a mixture. It can still communicate with non-SEND nodes, who do not realize that the addresses are so different. So maybe the order really doesn't matter that much. But it must still be defined. It looks like one of the SEND documents would be an appropriate place to put the default... I would say the new rule would go between rules 2 and 3 in RFC 3484. What do you think? > o Should the sense of this preference be reversible for (mostly diagnostic) > applications that aren't interested in having a "secure" network (e.g., > parallel fping) ? An addendum might be "Implementations MUST/SHOULD provide a > mechanism allowing an application to reverse the sense of this preference and > prefer non-CG-Addresses over CG-Addresses (e.g., via appropriate API > extensions)." We may have a general mechanism for that already. RFC 3484 says: This specification optionally allows for the possibility of administrative configuration of policy that can override the default behavior of the algorithms. The policy override takes the form of a configurable table that specifies precedence values and ... So, it seems to me that if you want to tweak the default then this would suffice, or? I think the case is different for care-of/home addresses because you have a *dynamic* need to prefer care-of addresses in certain cases. ---------------- Erik Nordmark: The table can describe preferences for prefixes and nothing more. Thus unless you pit CGA addresses in different prefixes, which would be a really BAD idea, you can't use that mechanism AFAIK. ---------------- Jari Arkko: > The table can describe preferences for prefixes and nothing more. Ouch. > Thus unless you pit CGA addresses in different prefixes, which would be > a really BAD idea, you can't use that mechanism AFAIK. In that case I agree. This means that we do need an API. --Jari ---------------- Julien Laganier responds to Jari Arkko: > Anyway, perhaps the practical thing that will happen is that > if your node is CGA-enabled, it probably has all of its addresses > CGA addresses, and does not use a mixture. It can still communicate > with non-SEND nodes, who do not realize that the addresses are > so different. So maybe the order really doesn't matter that > much. But it must still be defined. It looks like one of the SEND > documents would be an appropriate place to put the default... I agree it's a good simplification if a CGA-enabled has all of its addresses CGA addresses, but I would like to have a mean to make diagnostic tools avoid SeND processing. I guess we agreed that it requires an API cuz it cannot be done with system defaults (a diagnostic tools doesn't fall in the default category). Thus, the API should allow either 1) to choose a non-CGA address, or 2) disable SeND processing. It's not yet clear to me which is the best solution. > I would say the new rule would go between rules 2 and 3 in > RFC 3484. What do you think? My first idea was to put the new rule at the end of the list, so that, hopefully, it doesn't disturb too much regular address selection processing :-) But it makes sense to me to put the new CGA preference rule between rules 2 and 3, though I'm not sure it doesn't conflicts with others rules, like those related to MobileIP for example. Suppose, for instance, that your CoA is a CGA (e.g., your attachment LAN is SeND-enabled) and your HoA is not (e.g., your home network isn't SeND-enabled): An application would prefer to use the CoA as a source address, which negates rule 4 (prefer HoA). I don't know if this is really an issue. What do mobile-ip guys think? ---------------- James Kempf: So how about if the draft-ietf-send-ndopts says: A SEND=enabled node SHOULD use CGA addresses by default, but MAY use nonCGA addresses for testing, diagnostics, and other purposes. The node MAY provide an API to switch address type, but such an API is not considered further in this document. ...since an API is out of scope of the SEND group. > I would say the new rule would go between rules 2 and 3 in > RFC 3484. What do you think? Changing RFC 3484 is not within the scope of the SEND group's charter. Pekka and I will inform the IESG about this when we send the document to them, so they can figure out how to get the change made. > SeND-enabled) and your HoA is not (e.g., your home network isn't > SeND-enabled): An application would prefer to use the CoA as a source > address, which negates rule 4 (prefer HoA). > > I don't know if this is really an issue. What do mobile-ip guys think? We don't have to figure this out now. ---------------- Vijay Devarapalli responds to Julien Laganier: > I don't know if this is really an issue. What do mobile-ip guys think? well, if you have a CGA CoA and non-CGA CoA, the rule can be 'prefer a CGA CoA'. between HoA and CoA, you have to always prefer the HoA irrespective of whether the HoA/CoA is a CGA address or not. ---------------- Richard Draves: I think the preference for CGA would be at the end of the list, in rule 7. Somehow it feels similar to the public/temporary address preference. ---------------- Julien Laganier responds to Vijay Devarapalli: > well, if you have a CGA CoA and non-CGA CoA, the rule can be > 'prefer a CGA CoA'. between HoA and CoA, you have to always > prefer the HoA irrespective of whether the HoA/CoA is a CGA > address or not. So It seems that this new rule should be put at the end of the list, as Richard proposed (in rule 7), thus avoiding conflicts with MIP-related and others address selections rules. This probably implies, as some people stated before, that a SeND-enabled node should be configured with CGA only addresses. ---------------- Erik Nordmark: There is a proposed API in draft-chakrabarti-ipv6-addrselect-api-02.txt What seems to be missing though are the default rules for how to handle CGA addresses; need to understand in what order checks for CGA vs. non-CGA would occur compared to the other checks and tiebreakers in the default address selection RFC. ---------------- Jari Arkko: I'm trying to close this issue. We have already agreed that Samita's API draft is doing the right thing. I think you James said also that an update of the default source address selection rules for IPv6 & CGAs is not a task that we should do here. Is this correct? What does that leave to be done? Perhaps there is still need to state that the CGA addresses should be used, without stating anything about the preference rule ordering? Also, we may need to provide an informational reference to Samita's draft. How about this, to be inserted to Section 7: By default, a SEND-enabled node SHOULD use only CGAs as its own addresses. Other types of addresses MAY be used in testing, diagnostics or other purposes. However, this document does not describe how to choose different types of addresses for different communications. A dynamic selection can be provided by an API, such as the one defined in [draft-chakrabarti]. ---------------- ---------------- ----------------