RFC 3177 (IPv6 Address Assignment to End Sites) Has Been Obsoleted

Posted on in Networking

For those that don't follow the ARIN Public Policy Mailing List, the following is excerpted from a post by Thomas Narten in response to the announcement that the <acronym title="Internet Engineering Steering Group">IESG</acronym> has approved a new document to replace the existing RFC 3177 (IPv6 Address Assignment to End Sites).

<!--more-->

> The IESG has approved the following document:
> - 'IPv6 Address Assignment to End Sites'
> (draft-ietf-v6ops-3177bis-end-sites-01.txt) as a BCP

Quoting from the Introduction:

This document obsoletes RFC 3177, updating its recommendations in the following ways:

1) It is no longer recommended that /128s be given out. While there may be some cases where assigning only a single address may be justified, a site by definition implies multiple subnets and multiple devices.

2) RFC 3177 specifically recommended using prefix lengths of /48, /64 and /128. Specifying a small number of fixed boundaries has raised concerns that implementations and operational practices might become "hard-coded" to recognize only those fixed boundaries (i.e., a return to "classful addressing"). The actual intention has always been that there be no hard-coded boundaries within addresses, and that CIDR continues to apply to all bits of the routing prefixes.

3) This document moves away from the previous recommendation that a single default assignment size (e.g., a /48) makes sense for all end sites in the general case. End sites come in different shapes and sizes, and a one-size-fits-all approach is not necessary or appropriate.

This document does, however, reaffirm an important assumption behind RFC 3177:

A key principle for address management is that end sites always be able to obtain a reasonable amount of address space for their actual and planned usage, and over time ranges specified in years rather than just months. In practice, that means at least one /64, and in most cases significantly more. One particular situation that must be avoided is having an end site feel compelled to use IPv6-to-IPv6 Network Address Translation or other burdensome address conservation techniques because it could not get sufficient address space.

Slaptijack's Koding Kraken