Subject: "IPv6 on by default" comment

From: [email-masked]
Date: Wed, 16 Jul 2003 23:06:13 +0900

due to my (lack of) English speaking skill i may not have delivered
	my comment to everyone, so i post it here again.

	with "there's no RA -> consider everything as onlink" portion of
	ND spec, there's ambiguity.  ND spec does not help us decide which
	interface we should use to send packet out.  i agree that ND spec needs
	clarification on this part (drop "everything as onlink" statement,
	clarify which outgoing interface should be used, etc).

	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)

itojun

---

From: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Thu, 17 Jul 2003 01:52:17 +0900

>>>>> On Wed, 16 Jul 2003 23:06:13 +0900, 
>>>>> [email-masked] said:

> 	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.
					[email-masked]