Re: dual stack & IPv6 on by default

[JINMEI Tatuya / $B?@L@C#:H(B <jinmei@isl.rdc.toshiba.co.jp>]

>>>>> On 16 Mar 2003 12:07:57 +0200, 
>>>>> Mika Liljeberg <mika.liljeberg@welho.com> 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.
					jinmei@isl.rdc.toshiba.co.jp