Subject: 2461bis update

From: "Soliman, Hesham" <[email-masked]>
Date: Tue, 24 May 2005 10:04:25 -0400

Hi all,

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 think this draft is now ready for the IESG. 

Thanks,
Hesham

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 26 May 2005 04:01:02 +0900

>>>>> On Tue, 24 May 2005 10:04:25 -0400, 
>>>>> "Soliman, Hesham" <[email-masked]> said:

> I think this draft is now ready for the IESG. 

I've not fully checked the entire new version, but from a quick glance
the following comment of mine does not seem to be addressed:

http://www1.ietf.org/mail-archive/web/ipv6/current/msg04811.html
http://www1.ietf.org/mail-archive/web/ipv6/current/msg04818.html

At the very least, the 4th paragraph of Section 7.2.5 needs an
editorial fix for oddly short lines:

     If the target's Neighbor Cache entry is in the INCOMPLETE state when
     the advertisement is received, one of two things happen: If the
     advertisement were solicited, the state is changed to REACHABLE.
     Otherwise, the state is set to STALE. Note that the Override flag is
->   ignored if the entry is in the
->   INCOMPLETE state.

					JINMEI, Tatuya
					Communication Platform Lab.
					Corporate R&D Center, Toshiba Corp.
					[email-masked]

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Thu, 26 May 2005 15:33:48 +0900

> 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

---

From: JINMEI Tatuya / 神明達哉<[email-masked]>
Date: Sat, 28 May 2005 16:10:57 +0900

> raised on the last version. 

Sorry, it's me again...

I guess "bullet 2" (update APPENDIX C based on a recent discussion
about "RS with srcaddr but w/o SLLAO") mentioned in the following is
not addressed in the 03 version:

http://www1.ietf.org/mail-archive/web/ipv6/current/msg04472.html

(you seem to have agreed with the change:
http://www1.ietf.org/mail-archive/web/ipv6/current/msg04473.html )

					JINMEI, Tatuya