(B
(B > > 17. APPENDIX A (MULTIHOMED HOSTS)
(B > >
(B > > [...] Under
(B > > similar conditions in the non-multihomed host case, a node
(B > > treats all destinations as residing on-link, and
(B > communication
(B > > proceeds. [...]
(B > >
(B > > This is the so-called "on-link" assumption, which was removed in
(B > > rfc2461bis. Note that we cannot simply remove this
(B > sentence, since it
(B > > would also affect the succeeding sentence.
(B >
(B > And the 03 version reads:
(B >
(B > 1) If no Router Advertisement is received on any interfaces, a
(B > multihomed host will have no way of knowing which
(B > interface to
(B > send packets out on, even for on-link destinations.
(B > One possible approach for a multihomed node would be
(B > to attempt
(B > to perform address resolution on all interfaces, a step
(B > involving significant complexity.
(B >
(B > I'm not sure if this really addresses the issue. Actually, isn't the
(B > "possible approach" (i.e., performing address resolution anyway, when
(B > no RA is received) just a multi-homed version of the "on-link
(B > assumption", which was removed from 2461bis? And, if so, is
(B > there any
(B > special reason for allowing the "removed" feature for the multihomed
(B > case?
(B >
(B
(B=> I don't think it's the same as the on-link assumption. It's suggested as one
(Bpossible approach and is not mandated (on top of being in the appendix), but
(Balso,
(Bit's fine to attempt address resolution because those addresses might actually
(Bbe onlink. I.e. the node does not automatically assume that the addresses are
(Bonlink, which was the case before. We need to somehow address both cases: a)
(Bthere is no router and some of the addresses are in fact onlink, and b) there
(Bis
(Bno RA because there is no native v6 connectivity and everything should go
(Bthrough
(Ba tunnel.
(B
(B > The following is a summary of the comments which are not fully
(B > addressed. I don't necessarily stick to these, but it would be nice
(B > if you could check those once again.
(B
(B=> I'll address the ones that you do mind not being addressed below.
(B
(B >
(B > 1: does not seem to be addressed.
(B
(B=> I took a look at it and didn't find it breaking the initial definition in
(Bthe doc. It is
(Ba mix but it's not a harmful mix. If there are misleading examples please let
(Bme know.
(BI'll look again before sending the next rev.
(B
(B > 2: does not seem to be addressed.
(B
(B=> I can change this, it's not a big issue.
(B
(B > 3: OK, but it needs an editorial change since it includes too short a
(B > line as a result of the change.
(B > 4: the text in 03 is different from what I suggested. Although I
(B > don't push that strongly, I still believe my suggestion is better
(B > than the current text.
(B
(B=> ok. I actually don't see a problem with the current text.
(B
(B > 6: OK, but perhaps "prefix option" should be "prefix information
(B > option". (I should have pointed this out with the WGLC comments)
(B
(B=> ok
(B
(B > 16: does not seem to be addressed.
(B
(B=> ok, will add a ref.
(B
(B > 30: does not seem to be addressed, but this is probably very
(B > minor and
(B > I can lieve with the 03 text.
(B
(B=> Good. I didn't see a need to change it.
(B
(BHesham
(B
(B
(B >
(B > JINMEI, Tatuya
(B > Communication Platform Lab.
(B > Corporate R&D Center,
(B > Toshiba Corp.
(B > [EMAIL PROTECTED]
(B >
(B
(B===========================================================
(BThis email may contain confidential and privileged material for the sole use
(B of the intended recipient. Any review or distribution by others is strictly
(B prohibited. If you are not the intended recipient please contact the sender
(B and delete all copies.
(B===========================================================
(B
(B
(B--------------------------------------------------------------------
(BIETF IPv6 working group mailing list
([email protected]
(BAdministrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
(B--------------------------------------------------------------------
