I am not sure whether this is a deficiency in this model. Currently, even if M/O is turned off, the nodes which had triggered stateful protocol will continue using it. Unless or otherwise you reboot all the nodes in the link, you cannot make the nodes to switch to stateless autoconf. This could be solved by carrying some more information in the RAs rather than a single bit.
~Vijay Soliman Hesham wrote: > > > FWIW, I really think that there is no point in going round > > and round again > > > in this discussion when there is no harm done by keeping them. > > > Removing them is not backward compatible for 2461 anyway. > > > So I recommend we leave them as defined. > > > > I see your points, and I actually expected this type of responses. I > > do not necessarily stick to introducing the radical change. However, > > it seems to me that the actual effects on 2461 is minimum. RFC2461 > > basically only defines some syntaxes of the M/O bits, and leaves > > almost all the details of the semantics to RFC2462. So, we > > could even > > keep the wording in RFC2461(bis), and only deprecate the usage in > > RFC2462. (Again, I'd like to emphasize that I'm not insisting on > > introducing the change. I'm saying this only when we could > > ever agree > > on the changes from RFC2462's perspective (i.e., the usage side)). > >=> I'm not personally worried about the amount of work involved in updating >2461. It can be done in a few minutes. The reasons I oppose this are: > > - We should stop revisiting design decisions unless there is a clear >danger > in the current spec. I don't see any. I realise that you're not driving >this change > I'm trying to address the whole thread. It seems counter productive to >me. > > - It's not a backward compatible change, so I actually think it's more >harmful > to remove them. > > >Hesham > > > > > > JINMEI, Tatuya > > Communication Platform Lab. > > Corporate R&D Center, > > Toshiba Corp. > > [EMAIL PROTECTED] > > > >======================================================== >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 PROTECTED] >Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 >-------------------------------------------------------------------- > > -------------------------------------------------------------------- IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 --------------------------------------------------------------------
