Re: "IPv6 on by default" comment

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

>>>>> On Wed, 16 Jul 2003 23:06:13 +0900, 
>>>>> itojun@iijlab.net said:

> 	KAME implementation, by default, does not honor "consider everything as
> 	onlink" rule because of this ambiguity (therefore we won't experience
> 	the delay).
> 	if "default outgoing interface" gets configred to KAME kernel with
> 	ndp(8) command, the rule will be honored (and will experience the delay)

Actually, the reason why we (KAME) disabled the "everything as onlink"
rule by default is the exact concern that the v6-on-by-default draft
points out; delay to fallback to IPv4.  (I'm not saying the ambiguity
on the interface is not an issue, but this is not the reason why we do
not honor the rule.)  In any event, I agree that the rule in RFC2461
should be more clarified or even revised.

From KAME implementation 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 disable 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