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

From: [email-masked]
Date: Mon, 05 Mar 2007 15:50:03 -0500

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-03.txt
	Pages		: 33
	Date		: 2007-3-5
	
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 deployment and integration of
   IPv6.  This document aims to provide the information and
   recommendations relevant to planning the addressing aspects of IPv6
   deployments.  The document also provides IPv6 addressing case studies
   for both an enterprise and an ISP network.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-v6ops-addcon-03.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-03.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-03.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: "John Spence" <[email-masked]>
Date: Thu, 8 Mar 2007 13:33:02 -0500

Hello Gunter, et. al.;  two comments:

1) Section 2.2, regarding ULAs, they are indeed defined as /48.  I
suggested to the ULA RFC writers that the length be relaxed, allowing
for ULAs of any prefix length, such that an organization that had, say,
a /44 routable could also generate a /44 ULA.  The only impact would be
to increase the odds of collisions later if two organizations merged.
The writing team decided not to put that into the RFC, but did say on
the mailing list that since ULAs are internal, there is nothing to stop
an organization from doing just that.

Perhaps in the addconn draft we might make a statement to the effect
that an organization could choose to self-allocate a shorter-than-/48
ULA to match a shorter-than-/48 global allocation, if they chose,
subject to the caution on collisions noted above.

We did discuss this back in March 2006
(http://psg.com/lists/v6ops/v6ops.2006/msg00137.html), and thought
perhaps a note in the text would be appropriate as background, but leave
the emphasis on /48 since that is "per spec".  Just wanted to mention it
again to make sure it was not lost.

2) also Section 2.2, regarding multicast, the text states that:

"As an example of the problems ULAs may cause, when using IPv6 multicast
within the network, the IPv6 default address selection algorithm prefers
the ULA address as the source address for the IPv6 multicast streams. "

Looking at RFC 3484, it says:

"We map unicast link-local to multicast link-local, unicast site-local
to multicast site- local, and unicast global scope to multicast global
scope.  For example, unicast site-local is equal to multicast
site-local, which is smaller than multicast organization-local, which is
smaller than unicast global, which is equal to multicast global."

The RFC does not mention ULA because ULA definition came later, and
site-locals were deprecated.  I would expect that an update of 3484
would apply the same logic for ULA, and, hopefully, implementers today
are implementing scope matching based on ULAs.

Is there another reference that states that ULA unicast source is always
preferred for multicast addresses, where the sending interface has both
ULA and global unicast addresses?

John Spence

---

From: Fred Baker <[email-masked]>
Date: Thu, 8 Mar 2007 15:36:35 -0800

On Mar 8, 2007, at 10:33 AM, John Spence wrote:
> suggested to the ULA RFC writers that the length be relaxed,  
> allowing for ULAs of any prefix length, such that an organization  
> that had, say, a /44 routable could also generate a /44 ULA.

Silly question. What is the difference between one ULA of /44 and 16  
ULAs of /48 that are aggregatable to a /44? Never mind that RFC 4193  
wants you to do something different (section 3.2.1, first sentence) -  
within your own domain, just exactly what stops you from "randomly"  
generating the equivalent of a /44?

---

From: "Gunter Van de Velde \(gvandeve\)" <[email-masked]>
Date: Fri, 9 Mar 2007 10:37:26 +0100

Many thanks for your words and to read the -addcon- document again.

Comment #1:

We can add a phrase saying that different masks could be generated. That
is assuming the WG agrees that a statement needs to be added in the
document. As Fred mentioned earlier today there is no restriction in
using ULA and generating the # of prefixes that are needed for a private
network.

Comment #2:

You are exactly pointing at one of the issues with ULA's. ULA's did not
exist before some RFC's came out, there could be issues as the one
specified in the text. Do you think that fact should be made more clear
in the text?

Groetjes,
G/

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On
Behalf Of John Spence
Sent: Thursday, March 08, 2007 7:33 PM
To: [email-masked]
Subject: draft-ietf-v6ops-addcon-03.txt ... ULAs of shorter-than-/48 and
ULA multicast scope matching ...

John Spence

---

From: "John Spence" <[email-masked]>
Date: Fri, 9 Mar 2007 13:02:00 -0500

Comments inline Gunter.

-----Original Message-----
From: Gunter Van de Velde (gvandeve) [mailto:[email-masked]] 
Sent: Friday, March 09, 2007 1:37 AM
To: John Spence; [email-masked]
Subject: RE: draft-ietf-v6ops-addcon-03.txt ... ULAs of shorter-than-/48
and ULA multicast scope matching ...

>> Hey - fun to participate.  Good document too - nice work (et. al.)! 

Comment #1:

>> I think it would have been better for the ULA spec to have a sentence
saying there is nothing to keep an enterprise from modifying the process
in order to generate a shorter ULA prefix, if that is what they want.
Since they didn't, then I think it reasonable that we point that out
here, as well as pointing out that they can also generate multiple /48s
following the documented process if they don't mind them not
summarizing.  Seems like reasonable guidance.

>> How about something like:

"ULAs are, per the specification, normally /48 prefixes.  Note that a
larger organization with, for example, a /44 allocation, that wanted to
be able to map ULAs one-to-one with global prefixes, could generate 16
ULAs.  These would not summarize, however.  It seems reasonable that the
organization could also simply generate a /44 ULA, by using fewer than
40 bits (36 bits in this example) of the "Global ID" specified in RFC
4193."

Comment #2:

>> I don't know how these things are usually handled.  Is it safe to
assume that implementers reading RFC 3484 will all build their
implementations to give ULAs similar treatment to site-locals?  Will the
IETF start a "3484bis" in order to address ULA?

>> It seems like, for guidance, adding one or two more sentences would
make it a bit more clear.  Perhaps something like this added to the back
of the paragraph beginning "As an example of the problems ...":

"Note that scope matching of unicast source and multicast destinations
is done properly for (now deprecated) site-local addresses, as described
in RFC 3484.  It is expected that, over time, this feature will also be
afforded to ULA scope matching.  In the near term, however, implementers
are cautioned that many deployed devices do not distinguish ULA from
global-scope addresses, leading to the deployment issue cited above."

Groetjes,
G/

-----Original Message-----

John Spence

---

From: Tim Chown <[email-masked]>
Date: Mon, 12 Mar 2007 23:43:44 +0000

> global-scope addresses, leading to the deployment issue cited above."

Seems reasonable.  For #1 the important aspect is the probability of
clashes should two sites merge.

For #2, our comment was made based on observation of actual behaviour
during experiments.   The issue was fed into the work on 3484 updates
that is collating issues to address.

Tim

---

From: Mark Smith <[email-masked]>
Date: Tue, 13 Mar 2007 19:30:51 +1030

Hi,

On Mon, 12 Mar 2007 23:43:44 +0000

> > 40 bits (36 bits in this example) of the "Global ID" specified in RFC

I'm slightly confused be this, and I think the comment about not
being able to summarise 16 /48 ULAs is what is confusing me.
Summarisation seems to me to only be useful if you are going to
announce a summary to an upstream entity of some sort, and is really
only for the benefit of the upstream entity (e.g. upstream ISP, IGP
backbone area, other areas carrying inter-area routes rather than a
default etc.), as it reduces their route table and other routing
resource requirements.

As ULAs are kept within private entity, and therefore there isn't any
upstream entity, is there really any need to summarise to less than
16 /48 ULAs (in your scenario, for example)? If, within your
organisation, your routers can't cope with 16 /48 ULAs, I'd think you
problably have bigger routing problems to deal with (and a default
route only might be a main (and only) solution to that)!

If you were summarising ULAs internally to scale an IGP by dividing the
IGP into areas, would 16 areas, corresponding to the 16 /48s (global
and ULAs), be too many to cope with ? I'm not really sure they would.

I do see the operational benefits of having the /44 to /64 bits in the
global and ULA addresses match. I'm not quite sure I see how
summarisation by itself, which is how I read your paragraph, would be a
justification to do that, when the consequences are increased chances
of collision, should you join your /44 ULA domain with somebody else's.

Have I somehow misunderstood what you're trying to get at?

Regards,
Mark.

---

From: Tim Chown <[email-masked]>
Date: Tue, 13 Mar 2007 09:41:12 +0000

> route only might be a main (and only) solution to that)!

Well, were we talking of maybe a /36 rather than a /34, with aggregated
internal routing for sites within the prefix, then I think the above
approach could be useful.

> and ULAs), be too many to cope with ? I'm not really sure they would.

Well, think a little bigger than a /44 example?   What would you say then?

> of collision, should you join your /44 ULA domain with somebody else's.
 
Aligning the bits in the global and ULA addressing plan may have advantages
as you say.   That's the other aspect.

My personal concern is that network admins will pick all zeroes for the
ULA prefix, because they would rather have easy to type addresses than
a potential benefit for leakage/merger/etc.

> Have I somehow misunderstood what you're trying to get at?

No, your question is a good one, and we need some discussion :)

-- 
Tim

---

From: Mark Smith <[email-masked]>
Date: Tue, 13 Mar 2007 22:35:42 +1030

Hi Tim,

On Tue, 13 Mar 2007 09:41:12 +0000

> Well, think a little bigger than a /44 example?   What would you say then?

We'll, I've understood that a /48 was sized to be big enough for
nearly everybody, and those who require larger would only maybe need
a /47 or a /46. A /44 seems extremely large to me (around 1M subnets),
so I'm wondering whether going much shorter is that practical - unless
we might be talking about a service provider, who might have 1M+
distinct subnets, who then maybe would want to have fully matching ULA
subnets. If they're that size, I'd be assuming they'd be aggregating
internally fairly aggressively for both global and ULAs, just to cope
with router limitations. Possibly they might not deploy ULAs for all of
those subnets either - without putting much thought into it, I don't
think there would be that much benefit in assigning ULA subnets to
their customer attachment network edge links. (Possibly SPs may not
deploy ULAs at all, or at least only for their internal corporate /
support networks, not the customer traffic carrying links.)

Regards,
Mark.

---

From: Tim Chown <[email-masked]>
Date: Tue, 13 Mar 2007 15:28:56 +0000

> support networks, not the customer traffic carrying links.)

Fair comment.   I guess we're also nibbling here at the 'what's a site'
question.  I don't know where Thomas Narten's 3177-bis proposal got to,
but if end sites were allocated a /56 you'd probably want a /56 ULA...

Let's see what others on the list think.

-- 
Tim

---

From: "John Spence" <[email-masked]>
Date: Wed, 14 Mar 2007 12:45:03 -0400

> > being able to summarize 16 /48 ULAs is what is confusing me.
> > Summarization seems to me to only be useful if you are going to
> > upstream entity, is there really any need to summarize to less than
> > organization, your routers can't cope with 16 /48 ULAs, I'd think
you
> > probably have bigger routing problems to deal with (and a default
> > If you were summarizing ULAs internally to scale an IGP by dividing
the
> > and ULAs), be too many to cope with ? I'm not really sure they
would.

For me this is all about defining best practices and laying out
alternatives.  All situations are different and the engineer on the
ground best placed to decide how to apply recommendations or
considerations from the RFC.

I agree in most cases people would do fine with multiple (in this
example 256) non-contiguous /48 ULAs, even if they had a /40 (say)
global prefix.  But it seems a reasonable insight to suggest that they
could, for whatever reason, generate a contiguous /40 ULA, modifying the
documented procedure, if that would work better for them in their
specific deployment.  Subject to the caution that the more ULA space
they generate and deploy the greater the odds (although in most all
cases still very, very small) of a collision when merging with a future,
unknown network.  In general even internal aggregation can be valuable,
and having an allocation that lends itself to summarization seems like a
benefit.  Seems like a good thing to enable, and allow the network
designer to decide if they want to take advantage of it.

> > summarization by itself, which is how I read your paragraph, would
be a
> > of collision, should you join your /44 ULA domain with somebody
else's.

I don't think you are more likely to encounter a collision later if you
deploy, say, a contiguous /44 ULA or 16 non-contiguous /48 ULAs
(disclaimer: not a mathematician).  I agree you are more likely to avoid
collision by only generating, say, one /48 ULA to go with your /44
global, if that suits your needs.

Spence

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 16 Mar 2007 15:04:17 +0100

On 2007-03-13 13:05, Mark Smith wrote:

...

> a /47 or a /46. A /44 seems extremely large to me (around 1M subnets),

Well, suppose you were running something like an army of
one million soldiers, each with a personal network for their
equipment? One million mobile subnets. I'm not saying that
is a common requirement, but I don't think we should exclude
such things by construction.

On 2007-03-13 16:28, Tim Chown wrote:

...

> but if end sites were allocated a /56 you'd probably want a /56 ULA...

A /48 ULA would do just fine. They aren't going to be in short supply.

     Brian

---

From: Tim Chown <[email-masked]>
Date: Fri, 16 Mar 2007 17:10:12 +0000

> A /48 ULA would do just fine. They aren't going to be in short supply.

I would assume doing that would affect the collision probabilities?

-- 
Tim

---

From: Rémi Denis-Courmont <[email-masked]>
Date: Fri, 16 Mar 2007 20:00:00 +0200

> I would assume doing that would affect the collision probabilities?

This is about ULAs, that are not supposed to become part of the public 
Internet ever. As such, I will assume that it is the probability which 
matters, is that of a conflict between my network prefix and my 
girlfriend's prefix, or BigCorp's prefix and GrossFirma's prefix or 
FooPublicBureau's and BarStateAgency's. However, the probability that 
there is one or more conflict between all of the existing (but 
disconnectd) ULAs is not an issue.

If I'm not mistaken, the probability of two uniformly random /48 
colliding is exactly the same as (2^8)² = 65536 times the probability 
of two /56 colliding. That is to say under 10^(-12) for the whole 
fd00::/8. So, yes, it's much bigger, but that's merely in proportion to 
the number of possible prefixes.

This shall not be construed as an endorsment of /48 by me.

-- 
Rémi Denis-Courmont
http://www.remlab.net/

---

From: Christian Huitema <[email-masked]>
Date: Fri, 16 Mar 2007 11:04:00 -0700

> I would assume doing that would affect the collision probabilities?

Basic maths: the probability of at least one collision is proportional
to the number of allocations (networks) and inversely proportional to
the size of the address space. With a /48, the ULA address space is 40
bits wide, 2^40. If you run the numbers, the probabilities of at least
one collision for the various examples cited in the discussion are:

	For 256 independent /48 prefixes: 6 E-8
	For 2 independent /40 prefixes:   9 E-10
	For 1,000,000 independent /48 prefixes: 0.9 (90%)
	For 1,000,000 independent /56 prefixes: 0.003 (0.3%)
	For 1,000,000 independent /64 prefixes: 1.4 E-5 (i.e. a success
rate of 99.9986%, not quite five nines)

Of course, this can be mitigated in all sorts of ways, e.g. running a
registry...

-- Christian Huitema

---

From: Christian Huitema <[email-masked]>
Date: Fri, 16 Mar 2007 13:06:44 -0700

> > > >question.  I don't know where Thomas Narten's 3177-bis proposal
> got
> > to,

.. oops, bad typo. It is proportional to the square of the number of
allocations! This is reflected in the computations below.

---

From: Mark Smith <[email-masked]>
Date: Mon, 19 Mar 2007 21:32:31 +1030

Hi Brian,

On Fri, 16 Mar 2007 15:04:17 +0100

> such things by construction.

That's an interesting example to think about. It would make sense that
each soldier would have a subnet from within their military's /48 or
shorter prefix(es).

OTOH, is there some other alternative addressing or routing model where
the military could take advantage of one of the soldier's own
individual global and/or ULA /48s, rather than giving each solider "only"
one subnet ? 

Regards,
Mark.

---

From: Mohacsi Janos <[email-masked]>
Date: Tue, 20 Mar 2007 11:34:55 +0100 (CET)

Hi Gunter,
 	Some comments to the draft-ietf-v6ops-addcon-03 after request of 
Fred in the wg meeting. I think the document is well written and gives 
some useful insights for IPv6 address allocation.

1.

In introduction the treatment of PI can be simpler - policy might 
change over the time in different RIRs:

"In each case the prefix received is provider assigned (PA) or
provider independent (PI).

We do not discuss PI policy here.... "

2.

2.2 para 4 - I am not a native speaker, but I would change:

A site using ULAs may or may not also deploy globals.
|
V
A site using ULAs may or may not also deploy global addresses.

3.

2.2 para 5 - the multicast RPF checks are only applicable in PIM routing 
enviroment, might be others also. Therefore I would add explicit reference 
to IPv6 PIM ....

4.

2.3 6bone address space could be treated more directly. 6bone address 
space must not be used since this space might be used in the global IPv6 
in the future.

5.

I would consider other hints to configure subnet ids with classification:
- using existing systems
    - translate the existing subnet number into IPv6 subnet id
    - translate the VLAN id into IPv6 subnet id

- rethink
    - allocate according to your need

- aggreagate
    - aggregate according to the topology, service or structure of the
      organisation as described in 2.4

6. 
The case studies might be moved into an appendix.

Regards,

Janos Mohacsi
Network Engineer, Research Associate, Head of Network Planning and Projects
NIIF/HUNGARNET, HUNGARY
Key 70EF9882: DEC2 C685 1ED4 C95A 145F  4300 6F64 7B00 70EF 9882

---

From: Tim Chown <[email-masked]>
Date: Mon, 26 Mar 2007 13:35:07 +0100

> > Of course, this can be mitigated in all sorts of ways, e.g. running a

What did ever become of the centrally assigned ULA proposal?

The question here is what text should we put in the addon draft?  We
would like to have some text for three cases:

a) Site has multiple /48 prefixes (e.g. a /44) and wishes to use ULAs
b) Site has one /48 and wishes to use ULAs 
c) Site has a less-than-/48 prefix (e.g. a /56 or /64) and wishes to use ULAs

For a) the discussion was whether to pick 16 'random' /48 ULA prefixes or
to pick one ULA prefix using 36 random bits rather than 40.

For b) I think we have no issue :)

For c) does the site use a random 48-bit ULA prefix with 0's to the actual
network boundary, or does it minimise collision likelihood (in particular for
cases of network merger or overlap) by randomising the bits to the network 
boundary?

The simplest text is to use fixed /48 ULAs in all cases.   The text could
describe the above three cases and state that conclusion and note briefly
the tradeoffs.

-- 
Tim

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 26 Mar 2007 16:15:02 +0200

On 2007-03-26 14:35, Tim Chown wrote:
...
> to pick one ULA prefix using 36 random bits rather than 40.

I would recommend the first as being strictly conformant
to the spec, but observe that the second does not create
architectural issues.

> cases of network merger or overlap) by randomising the bits to the network 

Architecturally, it doesn't matter. The collision issue seems
negligible to me. So I think it *really* doesn't matter. I think
I would just use zeros.

> describe the above three cases and state that conclusion and note briefly

+1

     Brian

---

From: Gert Doering <[email-masked]>
Date: Tue, 27 Mar 2007 18:22:01 +0200

Hi,

> What did ever become of the centrally assigned ULA proposal?

Funny coincidence.

Work is underway "just now" in all of the 5 RIR regions to get a protocol
adopted to have the RIRs and NRO do this (that is "centrally assign ULAs").

I expect that this will need a year or so to finish, so a bit of patience
will be needed...

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  98999

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 27 Mar 2007 17:40:11 +0100

That's me I guess :-)

Yes, I can confirm, I'm working on this, hopefully will have a draft of
policy proposals (not-IETF work) to be submitted to the 5 RIR's during this
week or so.

Also checking with the I-D authors to revive the expired draft.

Regards,
Jordi

> De: Gert Doering <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Tue, 27 Mar 2007 18:22:01 +0200
> Para: <[email-masked]>
> Asunto: Re: draft-ietf-v6ops-addcon-03.txt ... ULAs of shorter-than-/48 and

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 28 Mar 2007 14:47:50 +0200

> Also checking with the I-D authors to revive the expired draft.

You'd better, because right now no address space is allocated for this.
RFC 4193 simply reserves L=0; the IETF would have to assign it before
IANA could allocate space to the RIRs.

    Brian