Subject: I-D ACTION:draft-ietf-v6ops-addcon-01.txt

From: [email-masked]
Date: Tue, 11 Jul 2006 18:50:01 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the IPv6 Operations Working Group of the IETF.

	Title		: IPv6 Unicast Address Assignment Considerations
	Author(s)	: G. Van de Velde, et al.
	Filename	: draft-ietf-v6ops-addcon-01.txt
	Pages		: 30
	Date		: 2006-7-11
	
One fundamental aspect of any IP communications infrastructure is its
addressing plan.  With its new address architecture and allocation
policies, the introduction of IPv6 into a network means that network
designers and operators need to reconsider their existing approaches
to network addressing.  Lack of guidelines on handling this aspect of
network design could slow down the integration of IPv6.  This draft
aims to provide the information and recommendations relevant to
planning the addressing aspects of IPv6 deployments.  The draft also
provides IPv6 addressing case studies for both an enterprise and an
ISP network.  In this first version of the draft we aim to provoke
discussion on this important topic; more detailed case study texts
will follow.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addcon-01.txt

To remove yourself from the I-D Announcement list, send a message to 
[email-masked] 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-ietf-v6ops-addcon-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-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-v6ops-addcon-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.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 19 Jul 2006 17:37:14 +0200

> 2.4.2.  Address Space Conservation
> 
>    Despite the large IPv6 address space which enables easier subnetting,
>    it still is important to ensure an efficient use of this resource.
>    Some addressing schemes, while facilitating aggregation and
>    management, could lead to significant numbers of addresses being
>    unused.  Address conservation requirements are less stringent in IPv6
>    but they should still be observed.
> 
>    The proposed HD [8] value for IPv6 is 0.94 compared to the current
>    value of 0.96 for IPv4.  Note that for IPv6 HD is calculated for
>    sites (i.e. on a basis of /48), instead of based on addresses like
>    with IPv4.

Perhaps it would be wiser to make the parenthesis
      (e.g. on a basis of /48)

Thanks for adding the ISP case. Some comments...

> 5.2.1.2.  IPv6 addressing schema requirements from the ISP perspective
>           of the Service Provider
> 
>    From ISP perspective the following basic requirements could be
>    identified:
>    o  The IPv6 address allocation schema must be able to realize a
>       maximal aggregation of all IPv6 address delegations to customers
>       into the /20 of the Service Provider.  Only this /20 will be
>       routed and injected from the Service Provider into the global
>       routing table (DFZ).  This strong aggregation keeps the routing
>       tables of the DFZ small and eases filtering and access control
>       very much.  (Note: A strong aggregation e.g. on POP or LER basis
>       limits as well the numbers of customer routes that are visible
>       within the ISP network.)

I'm quite concerned by this. Basically, why? Are we really expecting
ISPs to have so many customer sites that they can't simply flat-route
internally? Yes, that may be slightly less attractive for an MPLS
based ISP rather than for one using IP routing, but it has horrible
consequences because of the way it constrains address assignment.

> 5.2.1.3.  IPv6 addressing schema requirements from the Network Access
>           provider perspective of the Service Provider
> 
>    As already done for the LIR and the ISP roles of the SP it is also
>    necessary to identify requirements that come from its Network Access
>    Provider role.  Some of the basic requirements are:
>    o  The IPv6 addressing schema of the SP must be flexible enough to
>       adapt changes that are injected from the customer side.  This
>       covers changes that are based on the raising IPv6 address needs of
>       the customer as well as changes that come from topological
>       modifications (e.g. when the customer moves from one point of
>       network attachment (POP) to another).

I don't understand "changes that are injected from the customer side."
Does this mean injected by a routing protocol? What sort of flexibility
do you mean? And when a customer changes POP, well, see my previous
comment. That should just be a routing change.

> 5.2.2.1.1.  'Big' customers

Really big customers with many sites and an internal network will
be connected at multiple POPs. You don't discuss this case.
Again, it breaks the idea that customer address space can be aggregated
by POP topology.

     Brian

---

From: "John Spence" <[email-masked]>
Date: Fri, 21 Jul 2006 06:52:34 -0700

Olaf;

Looking good.

I believe that there are no prefixes allocated by IETF at this time that
meet the criteria for allocation of longer-than-64-bit prefix lengths (start
with ::/3) except for very special-use specific addresses and Embedded IPv4.
I know IETF documents should take a long view, but it seems reasonable to me
that to discourage this practice (ISPs allocating /126's for point-to-point
connections from the 2000::/3 space, for example) a note would be a good
idea.

http://www.iana.org/assignments/ipv6-address-space

John Spence, Command Information
[email-masked]