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

From: [email-masked]
Date: Fri, 02 Jun 2006 15:50:02 -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-00.txt
	Pages		: 20
	Date		: 2006-6-2
	
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 guideliness 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-00.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-00.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-00.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: Tue, 13 Jun 2006 09:25:00 +0200

Just a few comments on this:

> 1.  Introduction
> 
>    The Internet Protocol Version 6 (IPv6) Addressing Architecture [23]
>    defines three main types of addresses: unicast, anycast and
>    multicast.  This document focuses on unicast addresses, for which
>    there are currently three principal allocated types: Global Unique
>    Addresses [12] ('globals'), Unique Local IPv6 Addresses [22] (ULAs)
>    and 6bone address space [3].

It's a bit odd to include 6bone space as a "focus" item since all
you say is that it's history.

> 2.2.  Unique Local IPv6 Addresses
...
>    Because a ULA and a global site prefix are both /48 length, an
>    administrator can choose to use the same subnetting (and host
>    addressing) plan for both prefixes.

The RIRs are moving away from a rigid /48 policy. It would be safer
to start this sentence with "When" instead of "Because".
And on the same topic...

> 2.4.  Network Level Design Considerations

I suggest adding a bullet at the end of this section along these
lines:

o It is possible that as registry policies evolve, a small site
   may experience an increase in prefix length when renumbering,
   e.g. from /48 to /56. For this reason, the best practice is
   number subnets compactly rather than sparsely, and to
   use low-order bits as much as possible when numbering subnets.
   In other words, even if a /48 is allocated, act as though
   only a /56 is available. Clearly, this advice does not apply
   to large sites and enterprises that have an intrinsic need
   for a /48 prefix.

       Brian

---

From: "Gunter Van de Velde \(gvandeve\)" <[email-masked]>
Date: Tue, 13 Jun 2006 10:56:05 +0200

Hi Brian,

Many thanks for this swift response.

See inline GV>

>    and 6bone address space [3].

It's a bit odd to include 6bone space as a "focus" item since all you say is
that it's history.

GV> maybe a rewording would help here. The intention was to mention that the
focus area
is unicast addresses. The address ranges were just given as the three
principal allocated 
types. 

...
>    addressing) plan for both prefixes.

The RIRs are moving away from a rigid /48 policy. It would be safer to start
this sentence with "When" instead of "Because".
And on the same topic...

GV> sounds ok to me.

GV> ok. 

Groetjes,
G/

---

From: Mark Smith <[email-masked]>
Date: Wed, 14 Jun 2006 22:14:39 +0930

Hi,

On Tue, 13 Jun 2006 09:25:00 +0200

> Just a few comments on this:

<snip>

>    to large sites and enterprises that have an intrinsic need

Other than knowing it has been going on, I'm not up to date with what
has been discussed regarding this policy change. 

From the brief info I read a while back, the proposal was two sizes of
allocations, /48s or /56s. Has that changed at all to being a varying
prefix value between /48 and /56 ?

In either case, I'm wondering if there are methods of address
management from the ISP side of things to allow for smaller customers
who might exceed a /56 allocation. For example, very quickly off of the
top of my head, one way an ISP could handle this would be allocate each
small customer a /48, but only assign them the first /56 out of it. If
the customer needs more address space they then get the full /48 that
was pre-allocated for them. Of course, that means the ISP may end up
effectively running out of address space before much of it has actually
been used. At that point the ISP could then start allocating
further /56s out of the previously allocated /48s (best out of only one
of them until it is used up I'm sure), although the problem of course
is out of which customers allocated /48 to the new /56s come from. If
the allocations sizes are fixed at /48 and /56, I suppose if the
customer who's previous /48 the new, different customer's /56 was
allocated does exceed their original /56, then they could renumber to a
new /48 allocation. At least then their addressing would have been stable
for quite a while. Maybe if the new /56 was allocated out of the first
ever allocated /48, then it is fairly likely the first customer will
probably never grow beyond their original /56 assignment, as I'd guess
there would have been quite a length of time from between the first /48
allocation and the last.

Anyway, I haven't put much thought into it, so there may be far better
ways to deal with the ISP side of the /48, /56 policy change. I think
it would be good to cover any methods of dealing with it in this draft
if possible.

Regards,
Mark.