[quagga-dev 10839] Re: non-sequential netmasks support for RIPv2
carlsonj at workingcode.com
Thu Oct 24 13:27:06 BST 2013
On 10/24/13 08:05, Arjun Prasad wrote:
> @James Carlson
>>A non-contiguous netmask is one where the 1-bits are not packed in the
>>uppermost bits of the mask. For example, 255.255.1.0 would be a
>>non-contiguous netmask, because the uppermost 16 bits are set, but then
>>there's a gap of seven 0 bits before the next 1-bit in the mask
> Then what is the need for having this non-contiguous netmask concept.
> Why this term came? As per doc this term is there in ripV2 rfc (rhough i
> didn't find).
Quite simply, there is no need for non-contiguous masks.
The RIP-2 RFC (2453) allows each route to carry a 32-bit netmask in
certain situations in which a RIP-1 listener would not be confused.
Besides interoperability issues, the RFC doesn't specify much in the way
of limitations on the way in which the netmask may be set, so it's
*possible* to set it to a value with a non-contiguous set of 1-bits.
And, yes, years ago when I worked at Xylogics, I do recall running into
one or two highly confused individuals who insisted that they wanted to
run subnets with non-contiguous masks. If those people still exist and
are still confused about IP subnetting all these years later, and
additionally want to run Quagga for RIP-2 support, then maybe (maybe!)
there's a case to be made for implementing it. I very much doubt it,
Perhaps more importantly, a real routing software implementation doesn't
just base its feature set on a couple of RFCs. You really do need to
read all of the relevant ones, and I suggest referring to RFC 1812
(router requirements), particularly section 18.104.22.168 on CIDR, which is
relevant in this case.
Routers SHOULD always treat a route as a network prefix, and SHOULD
reject configuration and routing information inconsistent with that
Non-contiguous masks (as I previously mentioned) fall outside that
model. Yes, you can violate a SHOULD in an RFC if you need to, but you
have to have a pretty compelling reason to do so. In this case, it's
hard to see what that reason might be.
(You can even violate stronger language with a good enough reason. For
example, RFC 2453 section 5.2 says that if you're a RIP-2 router and
you're configured to run with authentication disabled, then
authenticated packets "shall be discarded." That's obviously quite
silly, and most implementations I know intentionally and flagrantly
violate it ... except when going for conformance tests. ;-})
James Carlson 42.703N 71.076W <carlsonj at workingcode.com>
More information about the Quagga-dev