>>>>> On Tue, 24 May 2005 10:04:25 -0400, >>>>> "Soliman, Hesham" <[EMAIL PROTECTED]> said:
> I submitted an updated revision of 2461bis which includes > the resolutions that were agreed on by the WG in the last meeting > (the SLLAO thread). It also includes fixes for the comments Tatuya > raised on the last version. I've checked the latest version of the draft with my previous comments (different ones from what we're discussing in a separate branch of this thread): http://www1.ietf.org/mail-archive/web/ipv6/current/msg04369.html Not all of them were addressed in the 03 version, but I can live with the current text for most of them. One (possibly) substantial point is comment 17, which was: > 17. APPENDIX A (MULTIHOMED HOSTS) > > [...] Under > similar conditions in the non-multihomed host case, a node > treats all destinations as residing on-link, and communication > proceeds. [...] > > This is the so-called "on-link" assumption, which was removed in > rfc2461bis. Note that we cannot simply remove this sentence, since it > would also affect the succeeding sentence. And the 03 version reads: 1) If no Router Advertisement is received on any interfaces, a multihomed host will have no way of knowing which interface to send packets out on, even for on-link destinations. One possible approach for a multihomed node would be to attempt to perform address resolution on all interfaces, a step involving significant complexity. I'm not sure if this really addresses the issue. Actually, isn't the "possible approach" (i.e., performing address resolution anyway, when no RA is received) just a multi-homed version of the "on-link assumption", which was removed from 2461bis? And, if so, is there any special reason for allowing the "removed" feature for the multihomed case? In the sense of the removal of the on-link assumption, perhaps the right answer is: "If no Router Advertisement is received on any interfaces, the host will simply not be able to send any packets on any link outside itself (but this is not different from the single-homed case)." The following is a summary of the comments which are not fully addressed. I don't necessarily stick to these, but it would be nice if you could check those once again. 1: does not seem to be addressed. 2: does not seem to be addressed. 3: OK, but it needs an editorial change since it includes too short a line as a result of the change. 4: the text in 03 is different from what I suggested. Although I don't push that strongly, I still believe my suggestion is better than the current text. 6: OK, but perhaps "prefix option" should be "prefix information option". (I should have pointed this out with the WGLC comments) 7: does not seem to be addressed, but I don't mind that. 11: slightly different from what I suggested. But I don't mind that. 13: does not seem to be addressed. (But the text is the same as RFC2461, and we can probably just live with that.) 16: does not seem to be addressed. 30: does not seem to be addressed, but this is probably very minor and I can lieve with the 03 text. JINMEI, Tatuya Communication Platform Lab. Corporate R&D Center, Toshiba Corp. [EMAIL PROTECTED] -------------------------------------------------------------------- IETF IPv6 working group mailing list [email protected] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
