[v6ops] Protocol Action: 'IPv6 Prefix Length Recommendation for Forwarding' to Best Current Practice (draft-ietf-v6ops-cidr-prefix-03.txt)

The IESG <iesg-secretary@ietf.org> Mon, 01 June 2015 17:48 UTC

Return-Path: <iesg-secretary@ietf.org>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (ietfa.amsl.com [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 01F181B2FDD; Mon, 1 Jun 2015 10:48:42 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -101.9
X-Spam-Level:
X-Spam-Status: No, score=-101.9 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, USER_IN_WHITELIST=-100] autolearn=ham
Received: from mail.ietf.org ([4.31.198.44]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id aWG2Pm-AWftR; Mon, 1 Jun 2015 10:48:40 -0700 (PDT)
Received: from ietfa.amsl.com (localhost [IPv6:::1]) by ietfa.amsl.com (Postfix) with ESMTP id A574F1B2FF0; Mon, 1 Jun 2015 10:48:33 -0700 (PDT)
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
From: The IESG <iesg-secretary@ietf.org>
To: IETF-Announce <ietf-announce@ietf.org>
X-Test-IDTracker: no
X-IETF-IDTracker: 6.0.3.p1
Auto-Submitted: auto-generated
Precedence: bulk
Message-ID: <20150601174833.29781.73064.idtracker@ietfa.amsl.com>
Date: Mon, 01 Jun 2015 10:48:33 -0700
Archived-At: <http://mailarchive.ietf.org/arch/msg/v6ops/dfF6LL_Nwh7eL0zhY9zfdR5WnVw>
Cc: v6ops mailing list <v6ops@ietf.org>, v6ops chair <v6ops-chairs@tools.ietf.org>, RFC Editor <rfc-editor@rfc-editor.org>
Subject: [v6ops] Protocol Action: 'IPv6 Prefix Length Recommendation for Forwarding' to Best Current Practice (draft-ietf-v6ops-cidr-prefix-03.txt)
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.15
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops/>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 01 Jun 2015 17:48:42 -0000

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:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-cidr-prefix/





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.

Personnel

Shepherd: Lee Howard
AD: Joel Jaeggli