Subject: RE: Implementation worries about default address selection

From: "Richard Draves" <[email-masked]>
Date: Wed, 16 Oct 2002 10:20:36 -0700

[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-masked]
--------------------------------------------------------------------

---

From: Pekka Savola <[email-masked]>
Date: Wed, 16 Oct 2002 21:59:18 +0300 (EEST)

> destination, if the application hasn't specified a source address.

Yep, that seems like a sane approach.

> 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

I agree.
 
> 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).
  
> 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