Hi Mika,
> > 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. I agree with you and I still have reservations about source address selection for those performance reasons. > > > 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. Yes. I can be done with new ICMP types or options. > > > 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. Agreed. Others need to jump in here. I think we have a hole. /jim > > 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 PROTECTED] --------------------------------------------------------------------
