Subject: Comments on draft-haberman-ipv6-ra-flags-option-00.txt

From: Suresh Krishnan <[email-masked]>
Date: Wed, 02 Aug 2006 15:17:10 -0400

Hi Bob and Brian,

   Thanks for writing this document. I read this and I feel it is a 
simple and effective way to extend the flags in a RA. I appreciate the 
fact that it does not take away 1 bit from the original RA flags to 
indicate the presence of this option.

Minor comment:
The following text in RFC2461 section 6.1.2 may need to be updated to 
accommodate this option.
"The contents of any defined options that are not specified to be used
  with Router Advertisement messages MUST be ignored and the packet
  processed as normal.  The only defined options that may appear are
  the Source Link-Layer Address, Prefix Information and MTU options.
  An advertisement that passes the validity checks is called a "valid
  advertisement".

   In a slightly related note, I feel that any document which is 
assigned one of these flags MUST be indicated as updating the ND 
specification (RFC2461/RFC2461bis). If this is not done it is highly 
likely people would assume that those bits are unallocated. e.g. 
RFC3775, RFC4191 and RFC4389 use these flag bits but do not update 
RFC2461. So a new draft author may wrongly assume the bit to be 
available for use. I saw a presentation in the 16ng meeting where the 
authors were trying to reuse the MIPv6 Home agent bit for their proposal.

I DO LIKE the idea of the IANA registry for these bits, but until that 
is setup we may still have issues with people using conflicting bits. In 
the meantime, is it possible for the ipv6 wg to be the "guardian" :-) 
for these bits? The dna working group is working on a protocol which 
updates IPv6 neighbor discovery and we would like to use two flag bits 
(bit 6 and bit 7) and it would be great if we can get those bits allocated.

Cheers
Suresh

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Bob Hinden <[email-masked]>
Date: Fri, 4 Aug 2006 01:19:27 -0700

Suresh,

On Aug 2, 2006, at 12:17 PM, ext Suresh Krishnan wrote:

> simple and effective way to extend the flags in a RA. I appreciate  
> the fact that it does not take away 1 bit from the original RA  
> flags to indicate the presence of this option.

Thanks.

> Minor comment:
> The following text in RFC2461 section 6.1.2 may need to be updated  
> to accommodate this option.

My reading of that paragraph is that it is discussing options that  
are not intended for RA messages.  If a new option says it defined  
for RA messages, then it would pass this test and be processed.  We  
could add some text to the draft that says that the new option is for  
RA messages and is valid.

> specification (RFC2461/RFC2461bis). If this is not done it is  
> highly likely people would assume that those bits are unallocated.  
> e.g. RFC3775, RFC4191 and RFC4389 use these flag bits but do not  
> update RFC2461. So a new draft author may wrongly assume the bit to  
> be available for use. I saw a presentation in the 16ng meeting  
> where the authors were trying to reuse the MIPv6 Home agent bit for  
> their proposal.

I agree that any document defining new ND options should say it is  
updating the ND RFC.

The reason we propose creating an IANA registry for these bits is to  
avoid the confusion you cite.  Also, we defined two bits that can be  
used for experimentation.

> I DO LIKE the idea of the IANA registry for these bits, but until  
> that is setup we may still have issues with people using  
> conflicting bits. In the meantime, is it possible for the ipv6 wg  
> to be the "guardian" :-) for these bits? The dna working group is  
> working on a protocol which updates IPv6 neighbor discovery and we  
> would like to use two flag bits (bit 6 and bit 7) and it would be  
> great if we can get those bits allocated.

I think this would work.  Hopefully, it won't take too long to get  
this draft approved and published.  It isn't too complicated :-)

Bob