[Sorry I've been traveling and I'm just catching up on this thread.] As it happens my implementation does do some caching - the equivalent of a destination cache entry also caches the source address to use for that destination, if the application hasn't specified a source address.
Section 8 (Implementation Considerations) discusses implementation issues that would affect the correctness of the implementation. It talks about caching from the point of view of what happens if you are working with stale information. I don't see the need for explicit advice to implementators about how to code a high-performance implementation. It would be hard to write such a section - the details of different implementations and their deployment environments vary widely. In his original email Pekka raised another couple issues - > 1. another issue struct me while re-reading: the draft > discusses source/destination address selection separately: > with S, select D from D_1, D_2, ..., D_n, or with D, select S > from S_1, S_2, ..., S_n. If I understood correctly a fairly > common case of S_1, S_2, ..., S_n *AND* D_1, D_1, ..., D_n > was not elaborated more (a brief mention in section 2?). I think section 6 is quite clear about this. For each destination address D, you select a source address Source(D) and you use Source(D) when sorting the destination addresses. > 2. IMO, I think sections 3.2 and 3.3 may be a bit ambiguous > wrt. mapped addresses and scopes. Is it supposed to say that > if I have configured '::ffff:10.0.0.1' on an interface (for > some reason..), treat it as global (per 3.3), but if I'm > communicating via IPv4 (and it was just added to destination > address selection as a mapped address ::ffff:10.0.0.1, treat > is as site-local (per 3.2))?!? This surely got me confused! When you are dealing with IPv4 addresses in section 6, you look at the IPv4 address's scope. Section 6 says The algorithm sorts together both IPv6 and IPv4 addresses. To find the attributes of an IPv4 address in the policy table, the IPv4 address should be represented as an IPv4-mapped address. It does not say to calculate the scope of an IPv4 address by representing it as an IPv4-mapped address and then applying section 3.3. Instead section 3.2 says explicitly how you calculate the scope of an IPv4 address. Section 3.3 is saying that when you are calculating the scope of an IPv6 address, you don't need to recognize the various IPv6 address forms that have an embedded IPv4 address and extract the IPv4 address and look at that. Instead the RFC 2373 definition of the scope of an IPv6 address, based on the high bits of the IPv6 address, is correct. Rich -------------------------------------------------------------------- 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] --------------------------------------------------------------------
