IPv6 Prefix Length Recommendation for Forwarding

Approval announcement
Draft of message to be sent after approval:

From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
Cc: RFC Editor <rfc-editor@rfc-editor.org>,
    v6ops mailing list <v6ops@ietf.org>,
    v6ops chair <v6ops-chairs@tools.ietf.org>
Subject: Protocol Action: 'IPv6 Prefix Length Recommendation for Forwarding' to Best Current Practice (draft-ietf-v6ops-cidr-prefix-03.txt)

The IESG has approved the following document:
- 'IPv6 Prefix Length Recommendation for Forwarding'
  (draft-ietf-v6ops-cidr-prefix-03.txt) as Best Current Practice

This document is the product of the IPv6 Operations Working Group.

The IESG contact persons are Benoit Claise and Joel Jaeggli.

A URL of this Internet Draft is:

Technical Summary

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.

Document Quality

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.


Shepherd: Lee Howard
AD: Joel Jaeggli