>>>>> On 16 Mar 2003 12:07:57 +0200, >>>>> Mika Liljeberg <[EMAIL PROTECTED]> said:
> No. It's a very specific case of "how to implement the following bit of > next-hop determination" in a host with multiple network interfaces and > how it relates to RFC3484 and destination address selection: > If the Default Router List is empty, > the sender assumes that the destination is on-link. > Until there is a clear understanding, we are sticking with: > If the route search fails, > the sender assumes the destination is unreachable. > I haven't seen comments from any other implementors. It would be very > interesting to hear if you have solved this and how you implemented it. We (KAME) adopted a simple (and perhaps naive approach); using the default interface. However, we disabled the ability to specify the default interface by default due to the exact reason discussed here. For more details, please refer to Section 1.2 of the KAME implementation note, the latest version of which is available at: http://orange.kame.net/dev/cvsweb2.cgi/kame/IMPLEMENTATION?rev=1.329&content-type=text/x-cvsweb-markup The following is the related part of the note. IPv6 on-link determination rule (RFC2461) is quite different from assumptions in BSD IPv4 network code. To implement the behavior in RFC2461 section 6.3.6 (3), the kernel needs to know the default outgoing interface. To configure the default outgoing interface, use commands like "ndp -I de0" as root. Then the kernel will have a "default" route to the interface with the cloning "C" bit being on. This default route will cause to make a neighbor cache entry for every destination that does not match an explicit route entry. Note that we intentionally disables configuring the default interface by default. This is because we found it sometimes caused inconvenient situation while it was rarely useful in practical usage. For example, consider a destination that has both IPv4 and IPv6 addresses but is only reachable via IPv4. Since our getaddrinfo(3) prefers IPv6 by default, an (TCP) application using the library with PF_UNSPEC first tries to connect to the IPv6 address. If we turn on RFC 2461 6.3.6 (3), we have to wait for quite a long period before the first attempt to make a connection fails. If we turn it off, the first attempt will immediately fail with EHOSTUNREACH, and then the application can try the next, reachable address. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- 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] --------------------------------------------------------------------
