Re: per-connection config and destination address selection
> On Tue, 30 Jul 2002 14:29:25 +0900, > JINMEI Tatuya <[EMAIL PROTECTED]> said: > This may rather be an implementation issue, so I don't think we need a > major revise of the draft just due to this. But I also think it would > be good to add some note about the dependency in Section 8 before > publishing the draft. I've locally discussed the issue with some people including the author, and would like to propose the attached changes based on the discussion. The changes do not modify the policy of selection rules, so I believe we can agree on them. The author of the draft has already agreed. I'm posting the changes here to see if there is an objection to the changes from other wg members. If not, then the author will revise the draft once again, and in parallel the IESG will approve the draft. So please check the followings, and speak up if you have an objection. There are two changes in Section 5 (Source Address Selection). Change the last sentence in Rule4: Rule 4: Prefer home addresses. If SA is simultaneously a home address and care-of address and SB is not, then prefer SA. Similarly, if SB is simultaneously a home address and care-of address and SA is not, then prefer SB. If SA is just a home address and SB is just a care-of address, then prefer SA. Similarly, if SB is just a home address and SA is just a care-of address, then prefer SB. An implementation may support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer care-of addresses over home addresses. To: An implementation should provide a mechanism allowing an application to reverse the sense of this preference and prefer care-of addresses over home addresses (e.g., via appropriate API extensions). Use of the mechanism should only affect the selection rules for the invoking application. and change the last sentence in: Rule 7: Prefer public addresses. If SA is a public address and SB is a temporary address, then prefer SA. Similarly, if SB is a public address and SA is a temporary address, then prefer SB. An implementation MUST support a per-connection configuration mechanism (for example, a socket option) to reverse the sense of this preference and prefer temporary addresses over public addresses. to: An implementation MUST provide a mechanism allowing an application to reverse the sense of this preference and prefer temporary addresses over public addresses (e.g., via appropriate API extensions). Use of the mechanism should only affect the selection rules for the invoking application. (end of change) The rationale of the changes is that the issue is rather than in the wording in the selection rules. With this change, we avoided the wording "per-connection" and "a socket option", so that the draft will be generic and be independent of implementation details. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
RE: per-connection config and destination address selection
Yes, this is an issue with per-socket configuration of source address selection. I haven't figured out a great solution. Obviously one can imagine passing flags to getaddrinfo but that isn't so attractive. For the temporary vs public addresses, this isn't a big deal because the temporary vs public rule 7 is so low on the list and usually the choice won't affect the common prefix length of the source address with the possible destination addresses. In other words, the choice of the destination address will not be affected if the source selection that happens inside destination address ordering is not configured properly for temporary vs public. For the home vs care-of addresses, it is more of a problem. I don't have enough operational experience with that aspect to have much preference for a solution. Rich > -Original Message- > From: [EMAIL PROTECTED] > [mailto:[EMAIL PROTECTED]] > Sent: Monday, July 29, 2002 10:29 PM > To: [EMAIL PROTECTED] > Subject: per-connection config and destination address selection > > > draft-ietf-ipv6-default-addr-select-08.txt mentions two > per-connection configuration switches for source address > selection. One is for home vs care-of addresses, and the > other is for temporary vs public addresses. > > The value of the switches may affect destination address > selection, because it depends on the expected source address > corresponding to each candidate of destination address. > > I have a feeling that the current draft is not very clear > about the dependency. For example, Section 8 (Implementation > Considerations) indicates that the destination address > selection algorithm can be implemented inside getaddrinfo(). > However, the library function does not always know the value > of per-connection switches in advance. An application may > even not open a socket for the actual connection when calling > getaddrinfo(). > > This may rather be an implementation issue, so I don't think > we need a major revise of the draft just due to this. But I > also think it would be good to add some note about the > dependency in Section 8 before publishing the draft. > > JINMEI, Tatuya > Communication Platform Lab. > Corporate R&D Center, > Toshiba Corp. > [EMAIL PROTECTED] > > IETF IPng Working Group Mailing List > IPng Home Page: http://playground.sun.com/ipng > FTP archive: ftp://playground.sun.com/pub/ipng > Direct all administrative requests to [EMAIL PROTECTED] > > IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
per-connection config and destination address selection
draft-ietf-ipv6-default-addr-select-08.txt mentions two per-connection configuration switches for source address selection. One is for home vs care-of addresses, and the other is for temporary vs public addresses. The value of the switches may affect destination address selection, because it depends on the expected source address corresponding to each candidate of destination address. I have a feeling that the current draft is not very clear about the dependency. For example, Section 8 (Implementation Considerations) indicates that the destination address selection algorithm can be implemented inside getaddrinfo(). However, the library function does not always know the value of per-connection switches in advance. An application may even not open a socket for the actual connection when calling getaddrinfo(). This may rather be an implementation issue, so I don't think we need a major revise of the draft just due to this. But I also think it would be good to add some note about the dependency in Section 8 before publishing the draft. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED]
