Manfredi, Albert E wrote:
The ID seems clear enough and achieves the goals of removing any
specific mention of prefix length or conservation of address space. The
next question is, who makes the policy on what size of prefix the
customers are assigned? I assume each ISP.
Actually, no, in that reductionist view it's the customers, by choosing
the ISPs that offer what they want. One of the motivations for the original
/48 recommendation was to avoid a reflex reaction in which /64 would
be considered adequate for a domestic or small business customer - we want
home subnetting to be considered the norm. I don't think that motivation
has changed, even if a rigid boundary at /48 no longer looks optimal.
Not to say there's anything wrong with this, but it seems to me that as
written, this ID would make it acceptable for ISPs to assign 64-bit
prefixes.
Thus, it
remains highly desirable to provide end sites with enough space (on
both initial and subsequent assignments) to last several years.
Fortunately, this goal can be achieved in a number of ways and does
not require that all end sites receive the same default size
assignment.
If that's desirable enough, maybe the IETF can make that IETF policy,
and we're back to wondering whether some default min size should be made
mandatory.
Mandatory is a strong word. But the notion that norm is a prefix *shorter*
than /64 seems necessary.
I guess this boils down to "who sets the policy?"
How about "nobody" ? Seriously,if we have a strong technical recommendation
that customer prefixes SHOULD be shorter than /64 to allow subnetting,
is any policy needed?
Brian
Bert
-----Original Message-----
From: Thomas Narten [mailto:[EMAIL PROTECTED]
Sent: Friday, March 10, 2006 10:46 AM
To: [email protected]
Subject: FWD: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-01.txt
FYI. This is a revised version of a document the WG discussed in
Paris. At the time the WG (at least those in the room) agreed to make
this a WG document. But that probably needs to be reevaluated, given
the changes.
This version is fairly heavily changed. Pretty much all of the text
relating to "conservation of address space" arguments and ideas on
using other sized boundaries has been removed. I think that text has
been superceded by events, and is really the purview of the RIR
community.
What I think this document should do is update/replace 3177 and to
document any architectural/standards issues related to the /48
boundary (or changing that boundary to something else).
Comments welcome (and the document is very short!)
Thomas
------- Forwarded Message
From: [EMAIL PROTECTED]
To: [email protected]
Cc:
Date: Thu, 09 Mar 2006 15:50:03 -0500
Subject: I-D ACTION:draft-narten-ipv6-3177bis-48boundary-01.txt
Reply-To: [EMAIL PROTECTED]
--NextPart
A New Internet-Draft is available from the on-line
Internet-Drafts directories.
Title : IPv6 Address Allocation to End Sites
Author(s) : T. Narten, et al.
Filename : draft-narten-ipv6-3177bis-48boundary-01.txt
Pages : 7
Date : 2006-3-9
RFC 3177 argued that in IPv6, end sites should be assigned /48 blocks
in most cases. The Regional Internet Registries (RIRs) adopted those
recommendations in 2002 and they have been in effect ever since.
This document revisits and updates the IAB/IESG recommendations on
the assignment of IPv6 address space to end sites. The exact choice
of how much address space to assign end sites is a policy issue under
the purview of the RIRs, subject to IPv6 architectural
considerations. This document reviews those architectural
considerations and reiterates that changing the /48 recommendation is
one of policy, and has minimal impact on the IPv6 architecture and on
IETF Standards.
This document obsoletes RFC 3177 and reclassifies it as historic.
A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-narten-ipv6-3177bis-
48boundary-01.txt
To remove yourself from the I-D Announcement list, send a message to
[EMAIL PROTECTED] with the word unsubscribe in
the body of the message.
You can also visit
https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.
Internet-Drafts are also available by anonymous FTP. Login
with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
"get draft-narten-ipv6-3177bis-48boundary-01.txt".
A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt
Internet-Drafts can also be obtained by e-mail.
Send a message to:
[EMAIL PROTECTED]
In the body type:
"FILE
/internet-drafts/draft-narten-ipv6-3177bis-48boundary-01.txt".
NOTE: The mail server at ietf.org can return the document in
MIME-encoded form by using the "mpack" utility. To use this
feature, insert the command "ENCODING mime" before the "FILE"
command. To decode the response(s), you will need "munpack" or
a MIME-compliant mail reader. Different MIME-compliant
mail readers
exhibit different behavior, especially when dealing with
"multipart" MIME messages (i.e. documents which have been split
up into multiple messages), so check your local documentation on
how to manipulate these messages.
Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.
--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"
--OtherAccess
Content-Type: Message/External-body; access-type="mail-server";
server="[EMAIL PROTECTED]"
Content-Type: text/plain
Content-ID: <[EMAIL PROTECTED]>
ENCODING mime
FILE /internet-drafts/draft-narten-ipv6-3177bis-48boundary-01.txt
--OtherAccess
Content-Type: Message/External-body;
name="draft-narten-ipv6-3177bis-48boundary-01.txt";
site="ftp.ietf.org"; access-type="anon-ftp";
directory="internet-drafts"
Content-Type: text/plain
Content-ID: <[EMAIL PROTECTED]>
--OtherAccess--
--NextPart
Content-Type: text/plain; charset="us-ascii"
MIME-Version: 1.0
Content-Transfer-Encoding: 7bit
Content-Disposition: inline
_______________________________________________
I-D-Announce mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/i-d-announce
--NextPart--
------- End of Forwarded Message
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email protected]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
