Wireshark · Wireshark-dev: Re: [Wireshark-dev] [PATCH] Improved support for MIPv4

[Guy Harris <guy@xxxxxxxxxxxx>]

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.