Subject: RE: dual stack & IPv6 on by default

From: Mika Liljeberg <[email-masked]>
Date: 16 Mar 2003 12:07:57 +0200

Hi Jim,

[The following quote concerns RFC3484 and destination address selection]

> >An implementation can't really know that a destination address 
> >is unreachable, unless it does a route search and, failing to 
> >find one, proceeds to try to ND all routerless links as well. 
> >Is that what we should do?
> 
> I think today this is the bottom line only answer.

That's too bad, because it means that the DNS resolver would have do
this for the whole candidate destination address list. That takes time.
I would much prefer do a route search only.

> But your mail thread makes me wonder if we need to do more and I think
> so.

RFC1122 clarified and corrected several small details in the IPv4
specifications. I think the node requirements spec could do the same for
any fuzzy bits in the IPv6 specificatons.

> But it would have to be in the context of ND.  ND is a requirement to
> use IPv6.

I agree. This is just a detail that needs to be clarified somehow.

> Feels like an edge that could be "do this if ND don't work"?

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.

Thanks,

	MikaL

--------------------------------------------------------------------
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: JINMEI Tatuya / 神明達哉 <[email-masked]>
Date: Mon, 17 Mar 2003 16:31:10 +0900

>>>>> On 16 Mar 2003 12:07:57 +0200, 
>>>>> Mika Liljeberg <[email-masked]> said:

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