On Wed, 16 Oct 2002, Richard Draves wrote: > 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.
Yep, that seems like a sane approach. > 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. Disagree: the section starts by examining the issues with destination address selection _only_, and never seems to move to discussing source address selection (or generic cache management). That is clearly inadequate IMO, and appears to be something just simply forgotten. > 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. I agree. > 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. I don't really understand the complexity of this but okay. (I wonder if this has been implemented in any libc w/ source available). > > 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. This is clarifies this a bit, but I believe there should an extra section in either 3.2 or 3.3 that spells out the difference explicitly, like adding something like the following in 3.2, before the last paragraph: It should be noted that only real IPv4 addresses, used in the destination address selection, and represented as IPv4-mapped addresses may have a different scope than global; other cases are described in the section below. This difference also worries me a bit and I wonder if there could be problems with tthis distinction. What if node has mapped addresses configured (for some reason), or DNS returns both 1.2.3.4 and ::ffff:1.2.3.4. You probably convert the IPv4 address to a mapped address but you need to add some bitflag to check which of them was "real". btw. there is typo around 'lookup' in section 3.2 line 5, I believe. -- Pekka Savola "Tell me of difficulties surmounted, Netcore Oy not those you stumble over and fall" Systems. Networks. Security. -- Robert Jordan: A Crown of Swords -------------------------------------------------------------------- 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] --------------------------------------------------------------------
