Skip to main content

Shepherd writeup
draft-ietf-v6ops-cidr-prefix

1. Summary
WG: v6ops.  Also discussed extensively in 6man, but as BCP, better for v6ops.
Shepherd: Lee Howard
AD: Joel Jaeggli

This short document makes a single BCP recommendation: Hardware and software
algorithms should impose no rules on prefix length, but implement
longest-match-first on prefixes of any valid length. In other words, arbitrary
bit boundaries such as 64 bits are arbitrary, and should not be imposed (or
slowed) by routing and forwarding engines. It is submitted as a BCP, since it
makes recommendations to implementers without updating or contravening any
standard.

2. Review and Consensus
Originally discussed in 6man as draft-boucadair-6man-prefix-routing-reco, with
three responsive revisions between June and September 2014.  Revised again and
submitted as draft-ietf-v6ops-cidr-prefix, with an additional revision. The
document was discussed in 6man at IETF91, with several comments, and consensus
that it was sensible as a recommendation, but not as a protocol update, and
therefore more properly belonged in v6ops. It had been discussed on the 6man
mailing list in October 2014, with about ten participants.  There was some
question about whether it was needed or useful, but after discussion objectors
generally removed their objections. There was consensus that the recommendation
is appropriate. Finally, discussion on v6ops list from December 2014 through
February 2015 included a few additional participants. The document was refined
into a clear BCP, with one objector worrying that requiring vendors to support
any length might result in fewer possible routing table entries. Others did not
share this concern. One commenter provided text updates, which were reflected
in the final version. Overall, participants have been very clear in expressing
their support or concerns.

3. Intellectual Property
Authors have verified that they know of no intellectual property encumbrances.

4. Other Points
No references to clean up.
No IANA considerations.
No Security or Privacy considerations.
Back