> [EMAIL PROTECTED] writes: > > >it is. if a CN does not support HAO, it will send an > ICMP error message > > >pointing to the offending octet. when the MN receives > this message, it > > >starts reverse-tunneling through the Home Agent. where > is the problem? > > >if this is not clearly specified in the MIPv6 draft, it > can be. the > > >binding error functionality can also be substituted by > an ICMP error. > > >Binding Error was specified so that it is easier for > the MN to figure > > >out whats going on. > > > > then I see no reason for the MUST. > > Sez RFC 2119: > > 6. Guidance in the use of these Imperatives > > Imperatives of the type defined in this memo must be > used with care > and sparingly. In particular, they MUST only be used where it is > actually required for interoperation or to limit > behavior which has > potential for causing harm (e.g., limiting retransmisssions) For > example, they must not be used to try to impose a > particular method > on implementors where the method is not required for > interoperability. > > Given that MIPv6 will interoperate without binding > code in CN's, it looks pretty much like a SHOULD > to me. Indeed, the protocol would not be robust if > it didn't consider the case of a non-conformant CN.
=> Exactly, IMHO the support for HAO is tied to RO support which is a SHOULD anyway, so the HAO should follow that. Hesham -------------------------------------------------------------------- IETF IPng Working Group Mailing List IPng Home Page: http://playground.sun.com/ipng FTP archive: ftp://playground.sun.com/pub/ipng Direct all administrative requests to [EMAIL PROTECTED] --------------------------------------------------------------------
