> I've been discussing destination address selection with some
> people, in particular how getaddrinfo() ideally should sort
> IPv4 addresses in the case that a host is placed in an
> IPv4-only network, and how this works with the algorithm in the draft.
>
> The first destination rule is:
>
> Rule 1: Avoid unusable destinations.
> If there is no route to DB or the current next-hop neighbor for DB
> is known to be unreachable or if Source(DB) is undefined, then sort
> DA before DB. Similarly, if there is no route to DA or the current
> next-hop neighbor for DA is known to be unreachable or if
> Source(DA)
> is undefined, then sort DB before DA.
> For IPv6 destination addresses, the
>
> First of all, the paragraph actually ends like this in the
> draft. Is something missing, or should the last words be removed?
Yup, some unfinished editing there in the -05 version. Ignore the last
words.
> My first thought was that this rule for an IPv6 host in an
> IPv4-only network with no known IPv6 routers would be enough
> to have IPv4 addresses sorted before IPv6 addresses. There
> was however some confusion in our discussion because some
> implementations have in this case an on-link default route,
> which means you actually have a route for all IPv6 addresses.
> I think this route should be ignored, and maybe it should be
> made clear in the draft. This on-link default route is just a
> way of implementing the following part of the conceptual
> sending algorithm in RFC 2460:
>
> Next-hop determination for a given unicast destination operates as
> follows. The sender performs a longest prefix match against the
> Prefix List to determine whether the packet's destination is on- or
> off-link. If the destination is on-link, the next-hop
> address is the
> same as the packet's destination address. Otherwise, the sender
> selects a router from the Default Router List (following the rules
> described in Section 6.3.6). If the Default Router List is empty,
> the sender assumes that the destination is on-link.
>
> That's how I see it anyway, I would like comments on this.
Actually the first couple examples in section 9.2 were supposed to
illustrate this scenario. The IPv6-capable host will presumably have
some IPv6 addresses, even though it is in an IPv4-only network (meaning
no IPv6 router available). For example, it will have a link-local IPv6
address on its lan interface and an IPv6 loopback address. So when a DNS
name resolves to two addresses, global IPv4 and global IPv6, the "prefer
matching scope" rule causes the IPv4 address to be sorted first.
It seems there are two problems with the phrase "no route" in Rule 1:
- RFC 2461 conceptual model doesn't have routes
- The RFC 2461 "assume destination is on-link" fallback - is this a
route or not?
When I wrote "no route", I was really thinking "if for whatever internal
error reason, the implementation can not convert the destination address
to a next-hop neighbor".
Perhaps it would be best to just remove the "no route" clause from Rule
1, and say that a destination D is considered unusable if Source(D) is
undefined or if the next-hop neighbor for D is known to be unreachable.
> Another issue that came up:
>
> It seems reasonable that IPv6 applications use this algorithm
> while IPv4 applications that don't care about IPv6 do not. Or
> does anyone think that we actually should use this algorithm
> then as well; preferring RFC 1918 destination for 1918 source
> etc? One way of doing this might be to use the algorithm in
> getaddrinfo() if AI_V4MAPPED is set, but leave the addresses
> unsorted otherwise (also for AI_ALL).
Hmm. I guess I was thinking all uses of getaddrinfo() would want the
sorting, even IPv4 applications. In any case, I don't like the
AI_V4MAPPED suggestion - plenty of IPv6 applications will not use that
flag. It could be something like - if the caller specifies that only
IPv4 addresses are desired, then the sorting is not done. But if the
caller specifies IPv6 addresses or leaves the family unspecified, then
the sorting is done.
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]
--------------------------------------------------------------------
