Suresh,
On Aug 2, 2006, at 12:17 PM, ext Suresh Krishnan wrote:
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.
Thanks.
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".
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.
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 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
Cheers
Suresh
--------------------------------------------------------------------
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
--------------------------------------------------------------------
