One document matched: draft-hain-prefix-consider-00.txt
Internet Draft T. Hain
Document: draft-hain-prefix-consider-00.txt Cisco
Expires: September 2005 April 2005
Considerations for prefix length assignments in the
Global Unicast Address Format
Status of this Memo
This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026 [1].
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six
months and may be updated, replaced, or obsoleted by other documents
at any time. It is inappropriate to use Internet-Drafts as
reference material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
IPR Statement
"By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79."
(See RFC 3978[RFC3978] section 5.1.)
All Internet-Drafts must include the following statements near the
end of the document:
"Copyright (C) The Internet Society (2005).
This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors
retain all their rights."
"This document and the information contained herein are provided on
an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE
REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE
INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR
IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF
THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE."
Abstract
Hain Expires - October 2005 1
Considerations for prefix length assignments April 2005
in the Global Unicast Address Format
This document discusses the issues that should be considered by
service providers as they assign address space to customers. It is
informational in nature as allocation policies are developed
elsewhere.
Conventions used in this document
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in
this document are to be interpreted as described in RFC-2119 [2].
Hain Expires - October 2005 2
Considerations for prefix length assignments April 2005
in the Global Unicast Address Format
Introduction
Several service providers have expressed concern that a single
policy of always allocating a ::/48 to a site is both ambiguous and
constraining on their business practice. First the definition of
'site' leaves open the question of is this a customer, a customer
campus, or a single building (to some degree that language is
intentionally ambiguous to allow for any of the above without being
restrictive). Then the apparent single value for all customers
removes their ability to differentiate levels of service through the
amount of address space provided.
History
The single prefix length policy recommendation was specifically
targeted to counter the IPv4 practice of assigning a single address
and/or charging customers per active address. Extreme conservation
embodied in per address charging is naturally countered by consumers
through the use of NAT technologies to conform to the restriction on
one hand while achieving their real goal on the other. Since NAT
devices introduce an impediment to new application deployment,
and/or require operationally complex helper technologies, the
community developing IPv6 wanted to ensure that all the effort to
provide sufficient address space to remove the need for NAT was not
undermined by misguided business practices. While the global policy
does allow for the assignment of ::/128 values, this is expected to
be rare as the service provider will never know if the receiving
device is really a router meaning it should have handed out a
minimum of a subnet prefix.
The ::/48 value was selected in recognition that larger
organizations would need a sufficient number of bits for local
subnet management, coupled with the realization that even if they
were handed out to individuals there would be enough to provide
multiple ::/48 prefixes to every person projected to be alive in
2050. The intense focus on conservation that has developed among the
service providers for managing IPv4 can't seem to adjust to the
reality that there are and will be enough ::/48's to cover the need.
Technical issues to consider
While any length prefix may be assigned, there are technical reasons
to restrict the set. Consistent management oversight of the forward
address space assignments and the reverse DNS tree suggest that all
assignments should be on nibble boundaries. Choosing other than
nibble boundaries ensures that multiple organizations will need to
manage the affected DNS reverse zone.
Assigning individual ::/64 subnet prefixes is likely to lead to
discontiguous assignments over time (even in the initial discussions
Hain Expires - October 2005 3
Considerations for prefix length assignments April 2005
in the Global Unicast Address Format
about DOCSIS 3.0 it was clear that multiple subnets per customer
were likely due to the differing media types involved). Aggregation
per customer simplifies several management issues, so planning ahead
by avoiding individual ::/64 prefix assignments will minimize future
renumbering.
Recommendation
Allocating on nibble boundaries would lead to the choices of ::/48,
::/52, ::/56, ::/60, and ::/64. Future proofing by avoiding the
assignment of individual ::/64's would take that off the list. Very
large global enterprises are likely to acquire substantial multiples
of ::/48 prefixes so they are not a real concern here. For those
service providers that believe they absolutely need to differentiate
levels of service through address space this leads to a
recommendation of:
Large businesses -> ::/48
Medium businesses -> ::/52
Small business/home office -> ::/56
Commodity consumer -> ::/60
RIR Considerations
Future versions of the global IPv6 allocation policy could soften
the wording around recommended prefix lengths, but really should
include the technical discussion about reverse zone alignment.
Security Considerations
There are no security issues discussed in this informational
document.
RFC Editor Considerations
This space left intentionally blank.
IANA Considerations
This space left intentionally blank.
Acknowledgments
Discussion of these issues have occurred over time at many venues,
and unfortunately I don't recall everyone involved.
Author's Addresses
Tony Hain
Cisco Systems
500 108th Ave. N.E. Suite 400
Bellevue, Wa. 98004
Email: alh-ietf@tndh.net
Hain Expires - October 2005 4
Considerations for prefix length assignments April 2005
in the Global Unicast Address Format
References
1 RFC-2026, Bradner, S., "The Internet Standards Process --
Revision 3", BCP 9, RFC 2026, October 1996.
2 RFC-2119, Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997
Hain Expires - October 2005 5
| PAFTECH AB 2003-2026 | 2026-04-23 09:49:03 |