Subject: RE: WG Request: Adopt draft-haberman-ipv6-ra-flags-option-00.txt

From: "Durand, Alain" <[email-masked]>
Date: Mon, 5 Feb 2007 16:45:08 -0500

> -----Original Message-----
> From: Bob Hinden [mailto:[email-masked]] 
> 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
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Mon, 5 Feb 2007 14:51:43 -0800

Alain,

> one need to explain what happens if the bits do not match.

All of the existing bits are defined (and referenced in the draft) by  
RFCs and remain in the RA header.  The draft does not change any of  
these bit assignments.  The key text in the draft:

    The bit fields within the option are numbered from left to right  
from
    8 to 47 and follow the numbering of the flag bits in the RA option
    described in Figure 1.

Please suggest text to clarify what you see as an issue.

> I wonder if it is not too late to go that route.

The new bits (8 - 47) define new options.  These options are ignored  
by existing implementations and may be implemented by new  
implementations.  You are correct that one can not define an new  
option that existing implementations need to support.  If  
implementations done see any value in the option, then it won't get  
supported, and vice versa.  All this draft is doing is to define  
additional RA bits.  There are several protocols in the pipeline (in  
other working groups) who need RA bits.

Bob