ARIN-PPML Message

[arin-ppml] RFC 3177 has been obsoleted

The IETF document "IPv6 Address Assignment to End Sites" (RFC 3177)
has been updated and replaced:

> 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.

Thomas

------- Forwarded Message

From: The IESG <iesg-secretary at ietf.org>
To: IETF-Announce <ietf-announce at ietf.org>
Cc: v6ops mailing list <v6ops at ietf.org>,
        Internet Architecture Board <iab at iab.org>,
        v6ops chair <v6ops-chairs at tools.ietf.org>,
        RFC Editor <rfc-editor at rfc-editor.org>
Date: Wed, 12 Jan 2011 11:50:42 -0800
Subject: [v6ops] Protocol Action: 'IPv6 Address Assignment to End Sites' to
	BCP	(draft-ietf-v6ops-3177bis-end-sites-01.txt)

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

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

The IESG contact persons are Ron Bonica and Dan Romascanu.

A URL of this Internet Draft is:
http://datatracker.ietf.org/doc/draft-ietf-v6ops-3177bis-end-sites/




    Technical Summary 

   RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks
   in most cases. The Regional Internet Registries (RIRs) adopted that
   recommendation in 2002, but began reconsidering the policy in 2005.
   This document revisits and updates the RFC 3177 recommendations on
   the assignment of IPv6 address space to end sites.  The exact choice
   of how much address space to assign end sites is an issue for the
   operational community. The role of the IETF is limited to providing
   guidance on IPv6 architectural and operational considerations. This
   document reviews the architectural and operational considerations of
   end site assignments as well as the motivations behind the original
   3177 recommendations. Moreover, the document clarifies that a one-
   size-fits-all recommendation of /48 is not nuanced enough for the
   broad range of end sites and is no longer recommended as a single
   default.

   This document updates and replaces RFC 3177.
 

    Working Group Summary 

The IPv6 Operations Working Group very solidly supported the specific
changes in proposed policy from RFC 3177. These are:

1) It is no longer recommended that /128s be given out. While ther 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.

    Document Quality 

The document appears to be of very high quality and essentially unanimous
support.

Personnel

Fred Baker is shepherd for this document.


 
_______________________________________________
v6ops mailing list
v6ops at ietf.org
https://www.ietf.org/mailman/listinfo/v6ops

------- End of Forwarded Message