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 protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
