> -----Original Message-----
> From: Bob Hinden [mailto:[EMAIL PROTECTED] 
> RFC2461, Section 4.2 says the following about new options:
> 
>        Future versions of this protocol may define new option types.
>        Receivers MUST silently ignore any options they do not 
> recognize
>        and continue processing the message.
> 
> Any legacy host that didn't support the new option also 
> wouldn't know how to support anything defined in the 
> extension space.  So I don't think there is a problem with 
> legacy hosts.

One thing I found unclear from the draft was if the 'legacy' bits
will be 'ported' or not to the new space. If they are 'ported',
one need to explain what happens if the bits do not match.

Also, if a new bit is deemed essential and must be reserved in the RA,
I wonder how this could in practise be deployed in a real network
given the number of existing implementations. In other words,
I wonder if it is not too late to go that route.


> > We have a number of bits that are currently defined that may be 
> > questionable, (the best example: O & M), so I would like to 
> see some 
> > more justification why more bits are needed for the general RA case 
> > and maybe some clean-up of the current bits before we embark into 
> > defining a new space for potentially questionable new cases.
> 
> The intent of the draft was to document in one place all of 
> the current bits and provide a way of creating new ones.
> 
> In my personal view, any discussion cleaning up the RA bits 
> would take a very long time (based on the time it took for 
> the w.g. to agree on the current text on the O&M bits), so I 
> see very little value in trying to clean up the bits.  
> Further, back to your first question, cleaning up the bits 
> would create a significant operational problem.

IMHO, the O&M debacle demonstrates that specifying bits before
their usage is well understood is not wise.

   - Alain.

--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

Reply via email to