During the IESG Review, A comment was raised about the problem that can occur 
if the NAT (public) and AC (private) addresses are the same.

> >>> Section 4.6.11., paragraph 1:
> >>>   The CAPWAP Local IPv4 Address message element is sent by either 
> >>> the
> >>>   WTP, in the Join Request, or by the AC, in the Join Response. The
> >>>   CAPWAP Local IPv4 Address message element is used to communicate 
> >>> the
> >>>   IP Address of the transmitter.  The receiver uses this to 
> >>> determine
> >>>   whether a middlebox exists between the two peers, by comparing the
> >>>   source IP address of the packet against the value of the message
> >>>   element.
> >>
> >>  This is not a reliable technique for NAT detection, because it fails  
> >> when address spaces are overlapping. (Same for Section 4.6.12.)
> >
> > OK - I understand, but what are the possibilities of both the AC
> > *and* the NAT
> > box having the same IP Address? Given that we want to detect a 
> > middlebox, which by nature is transparent, what would you recommend we 
> > do? Either we put in the rule we currently have, add a disclaimer that 
> > there is a 2^32 chance of this not working (if the addresses overlap, 
> > so make sure your configuration doesn't do this) or some other 
> > mechanism. I would welcome recommendations.
> 
> I believe that mentioning the issue and pointing out that it should 
> be avoided through careful configuration, as you describe) is sufficient.

OK, I would therefore propose adding the following text to the NAT 
Considerations section:

<proposed text>
11.  NAT Considerations
[...]
   Note that this middlebox detection technique is not foolproof.  If
   the public IP address assigned to the NAT is identical to the private
   IP address used by the AC, detection by the WTP would fail.  This
   failure can lead to various protocol errors, so it is therefore
   necessary for deployments to ensure that the NAT's IP address is not
   the same as the ACs.
</proposed text>

PatC