Subject: Some comments regarding draft-ietf-ipngwg-default-addr-select-05.txt

From: Stig Venaas <[email-masked]>
Date: Mon, 30 Jul 2001 14:46:47 +0200

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?

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.

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

Stig
--------------------------------------------------------------------
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: "Tony Hain" <[email-masked]>
Date: Mon, 30 Jul 2001 11:38:38 -0700

Stig Venaas wrote:

> 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.

Consider that an IPv4 network is nothing more than an NBMA link to an IPv6 node that implements 6to4 and/or ISATAP and your perception of address sorting for nodes in an IPv4-only net may change.

> 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.

Your use of the terms on-link & default route together could be part of the confusion. For one, the concept of a default route applies to the next hop used when there is no obvious path for this destination, and for all on-link nodes there is an obvious path. For the other, the next hop for the default route is by definition on-link. I can't say without a picture what that last line means, but if an implementation believes that all addresses exist on its link, that implementation would appear to be broken. In an IPv4 world it might have made sense to try an arp for an off-link prefix since most nodes only have one useful address, but in an IPv6 world it makes little sense to try ND for an off-link prefix when the link-local address should work and is the appropriate scope. 

> Or does anyone think that we actually should use this 
> algorithm then as well; preferring RFC 1918 destination 
> for 1918 source etc?

The intent in the draft is that 1918's get treated as site local, while draft-ietf-zeroconf-ipv4-linklocal-03.txt are treated as link-local. This sets up the IPv4 space with the same scopes so the addr-select rules apply equally. If the IPv6 scopes don't match but the IPv4 ones do then IPv4 should be used.

Tony

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 31 Jul 2001 13:58:05 +0200 (CEST)

> Your use of the terms on-link & default route together could be part of the
> confusion. For one, the concept of a default route applies to the next hop
> used when there is no obvious path for this destination, and for all on-link
> nodes there is an obvious path. For the other, the next hop for the default
> route is by definition on-link. I can't say without a picture what that last
> line means, but if an implementation believes that all addresses exist on
> its link, that implementation would appear to be broken. 

A node that conforms to RFC 2461 should treat all addresses as being on
its link in one case - so I don't think the implementation is broken but
correct.

The text that Stig quoted from RFC 2461 says at the end
   If the Default Router List is empty,
   the sender assumes that the destination is on-link.

In Unix implementations a possible implementation of this aspect
is by creating this route
	route add default <hostname> -interface
where <hostname> is the hostname/IP address assigned to the node.

One possible way of making the draft clearer would be to, instead of using the
implementation concept of a routing table, express the rule using 
the conceptual model in RFC 2461.

  Erik

---

From: Pekka Savola <[email-masked]>
Date: Tue, 31 Jul 2001 15:09:21 +0300 (EEST)

> the conceptual model in RFC 2461.

One other source of confusion might be that some implementations, when
setting routes manually (ie. not autoconfed), instead of setting _default_
route, prefer something like 2000::/3 so "illegal addresses" won't be
forwarded.

This is an effective default route AFAIS, but might not be one if you go
by the definition above.

-- 
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

---

From: Erik Nordmark <[email-masked]>
Date: Tue, 31 Jul 2001 14:44:04 +0200 (CEST)

> route, prefer something like 2000::/3 so "illegal addresses" won't be

They are not illegal by any means - see below.

> This is an effective default route AFAIS, but might not be one if you go

That would be a very bad idea. What if IANA and the regional registries start
handing out addresses outside of this range tomorrow? Then that implementation
would not be able to talk to nodes that get addresses from the new range.

For this reason the text in <draft-ietf-ipngwg-addr-arch-v3-06.txt>
has been clarified to state

   Future specifications may redefine one or more sub-ranges of the
   global unicast space for other purposes, but unless and until that
   happens, implementations must treat all addresses that do not start
   with any of the above-listed prefixes as global unicast addresses.

Basically implementations shouldn't have any rules about any prefixes
other than
	::0/128
	::1/128
	0::/3	(and longer prefixes for ipv4-mapped etc)
	ff80::/10
	fec0::/10
	ff00::/8

Do we need to make this more clear?

  Erik

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 31 Jul 2001 12:32:35 -0700

> where <hostname> is the hostname/IP address assigned to the node.

I had always read that section as 'if you don't know a router simply try ND as a last resort'. I would still consider an implementation broken if it interpreted the lack of a router entry to mean that it should declare one of its interfaces to be the default route. I realize this is simply a semantic difference, but mixing the routing table with the neighbor cache seems like an operational disaster waiting to happen. 

> One possible way of making the draft clearer would be to, instead 
> of using the implementation concept of a routing table, express 
> the rule using the conceptual model in RFC 2461.

I didn't read the rule as being restricted to a routing table because it included 'or the current next-hop neighbor'. I agree that could be interpreted as a router, but it could also be just the destination pointed to by the NC entry. How about 'or the current next-hop in the neighbor cache for DB is known to be unreachable'?

Tony