Subject: RE: 2461bis update

From: "Soliman, Hesham" <[email-masked]>
Date: Thu, 26 May 2005 10:17:06 -0400

> > 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?
 > 

=> I don't think it's the same as the on-link assumption. It's suggested as one 
possible approach and is not mandated (on top of being in the appendix), but also, 
it's fine to attempt address resolution because those addresses might actually
be onlink. I.e. the node does not automatically assume that the addresses are
onlink, which was the case before. We need to somehow address both cases: a)
there is no router and some of the addresses are in fact onlink, and b) there is 
no RA because there is no native v6 connectivity and everything should go through 
a tunnel.

 > 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.

=> I'll address the ones that you do mind not being addressed below.

 > 
 > 1: does not seem to be addressed.

=> I took a look at it and didn't find it breaking the initial definition in the doc. It is 
a mix but it's not a harmful mix. If there are misleading examples please let me know.
I'll look again before sending the next rev.

 > 2: does not seem to be addressed.

=> I can change this, it's not a big issue.

 > 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.

=> ok. I actually don't see a problem with the current text.

 > 6: OK, but perhaps "prefix option" should be "prefix information
 >    option".  (I should have pointed this out with the WGLC comments)

=> ok

 > 16: does not seem to be addressed.

=> ok, will add a ref.

 > 30: does not seem to be addressed, but this is probably very 
 > minor and
 >     I can lieve with the 03 text.

=> Good. I didn't see a need to change it.

Hesham

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

===========================================================
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: Fri, 27 May 2005 02:42:07 +0900

>>>>> On Thu, 26 May 2005 10:17:06 -0400, 
>>>>> "Soliman, Hesham" <[email-masked]> said:

> => I don't think it's the same as the on-link assumption. It's
> suggested as one possible approach and is not mandated (on top of
> being in the appendix), but also, it's fine to attempt address
> resolution because those addresses might actually be
> onlink. I.e. the node does not automatically assume that the
> addresses are onlink, which was the case before. We need to somehow
> address both cases: a) there is no router and some of the addresses
> are in fact onlink, and b) there is no RA because there is no native
> v6 connectivity and everything should go through a tunnel.

Whether or not the text indicates the "on-link assumption", I still
don't think the current 03 text is appropriate in this context.  In
fact, it's possible for a single-homed host to not receive any RA on
its only interface, and "it would be fine to attempt address
resolution because those addresses might actually be onlink".  So, why
should we then mention that in the multi-homed context?

Additionally, though I'm not sure if this is related to this exact
context, I suspect "attempting address resolution anyway" does not
really help your case (b) above, since in this case the other end of
the tunnel is most likely a router, and what the host should do is
just to send the packet to the link, not trying address resolution for
the destination.

My primary suggestion is thus to remove "problem 1)" of Appendix A.
Or, if we still want to emphasize the "complexity" of the multi-homed
case, I'd rewrite it to:

     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.  The same
        argument applies to a singlehomed node that does not receive
        any Router Advertisement, but the step in the multihomed case
        involves significant complexity.

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