carping about CARP

Mon Dec 3 02:48:00 UTC 2012

On 12/2/2012 5:28 PM, Adrian Farrel wrote:
> Far be it from me to get involved in a private pissing match, but...
>
> Owen wrote:
>
>> Perhaps we should ask IETF/IANA to allocate a group of protocol numbers
>> to "the wild west". A protocol-number equivalent of RFC-1918 or private ASNs.
>> You can use these for whatever you want, but so can anyone else and if you
>> do, you do so at your own risk.
>>
>> This won't entirely solve the problem, but at least it would provide some
>> level of shield for protocol numbers that are registered to particular
>> purposes through the IETF/IANA process.
>
> Would that be 253 and 254 "Use for experimentation and testing" per RFC 3692?
>
> Of course, no-one like to see their pet protocol designated as an experiment
> (unless they really believe it is something that should be carefully researched
> and tried out in a controlled environment), but the garden-walling that you
> describe seems to fit exactly within the 3692 definitions.
>
> Adrian
>
>

RFC 3692, section 1.1:

"Values reserved for experimental use are never to be made permanent; 
permanent assignments should be obtained through standard processes.  As 
described above, experimental numbers are intended for experimentation 
and testing and are not intended for wide or general deployments.

When protocols that use experimental numbers are included in products, 
the shipping versions of the products must disable recognition of 
protocol experimental numbers by default -- that is, the end user of the 
product must explicitly "turn on" the experimental protocol 
functionality.  In most cases, a product implementation must require the 
end user to configure the value explicitly prior to enabling its usage. 
  Should a product not have a user interface for such end user 
configuration, the product must require explicit re-programming (e.g., a 
special firmware download, or installation of a feature card) to 
configure the experimental number(s) of the protocol(s) implicitly."

Of course the use of 'must' or 'must not' in an RFC never stopped anyone 
from doing the exact opposite.

Jay