Sebastien Tandel wrote:
3) there will be two additional fields shown, which will be clear
(for
packets formatted as per the older version of the spec, where those
two
bits were reserved).
which will be presented as two bits with a semantic and in fact, had
none for the old norm. That's what I wanted to point out.
Yes, but that's not an issue - that's what reserved fields are for. RFC
3344 says, about the bottom 8 bits of the 16-bit field (it's a 16-bit
field even in RFC 3344), "Sent as zero; ignored on reception."
(Hopefully, they made it clear that "sent as zero" means "MUST be sent
as zero" and that "ignored on reception" means "current implementations
should ignore them, but they might be used in the future, so future
implementations might not ignore them, so we really mean it when we say
'MUST be sent as zero".)
I.e., a packet sent by code written to the older version of the spec
isn't advertising UDP Tunnelling support - there was no UDP Tunnelling
support in the older version of the spec, so if code was written to that
older version of the spec, there's no UDP Tunnelling support code.
Thus, the new U bit is correctly displayed for packets sent by code
(correctly) written to the older version of the spec. (Code
*in*correctly written to the older version of the spec, so that the U
bit is set, could confuse recipients of those packets into thinking the
machine supports UDP Tunnelling, so, again, it's correct to display that
bit, so that it's obvious that the machine is advertising something it
doesn't actually offer.)
The same applies to RFC 3543 and advertising Registration Revocation.
So, no, there's no need to control whether to display those to flags or not.