Subject: Fwd: New Version Notification for draft-mrw-6man-ulac-analysis-00

From: Margaret Wasserman <[email-masked]>
Date: Sun, 11 Nov 2007 22:46:48 -0500

FYI --

I wrote this draft to try to capture the major arguments for and  
against the definition of ULA-Cs.  Please let me know if I've gotten  
anything wrong, or if there are any major arguments (in either  
direction) that I've missed.

Thanks,
Margaret

Begin forwarded message:

> From: IETF I-D Submission Tool <[email-masked]>
> Date: November 11, 2007 10:16:15 PM EST
> To: [email-masked]
> Subject: New Version Notification for draft-mrw-6man-ulac-analysis-00
>
>
> A new version of I-D, draft-mrw-6man-ulac-analysis-00.txt has been  
> successfuly submitted by Margaret Wasserman and posted to the IETF  
> repository.
>
> Filename:	 draft-mrw-6man-ulac-analysis
> Revision:	 00
> Title:		 An Analysis of Centrally Assigned Unique Local Addresses
> Creation_date:	 2007-11-12
> WG ID:		 Independent Submission
> Number_of_pages: 8
>
> Abstract:
> There has been discussion within the IETF IPv6 community for some
> time regarding whether or not to define Centrally Assigned Unique
> Local Addresses (ULA-Cs).  Although many arguments both for and
> against the definition of ULA-Cs have been raised and repeated, our
> discussions have not resulted in consensus about whether or not to
> define this new address type.  This document will summarize the
> arguments for and against the allocation of ULA-Cs, in an attempt to
> help the IETF IPv6 community reach a decision on this issue.
>
>
>
> The IETF Secretariat.
>
>

--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Per Heldal <[email-masked]>
Date: Mon, 12 Nov 2007 10:15:20 +0100

> direction) that I've missed.

Regardless of the listed arguments one may also question IETFs role in
the definition of (any) ULA as there is no technical reason why such an
address-block must be tagged 'special'. If the IETF wants to provide
guidance to the policy-process such should be no stronger than BCPs
(like rfc1918), not technical standards (rfc4193). The regional
registries, through the ICANN/ASO and IANA, may or may not choose to
implement policies that support some form of ULA. There's no need for
the IETF to dictate that process. Also consider the signals such
standards communicate to manufacturers. Misleading standards and
policies have led vendors to introduce artificial limitations in
hardware and software in the past (example: 240/4). Do we really want
that?

//per

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 12 Nov 2007 12:53:18 -0200

If that happens (RIRs not having policies for using ULA), then IETF can ask
IANA to create a new registry for that, and IANA need to do it, no choice
against that IETF decision.

However I still think at least some of the RIRs will get that policy in
place, and I think is the best approach.

Regards,
Jordi

> De: Per Heldal <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Mon, 12 Nov 2007 10:15:20 +0100
> Para: Margaret Wasserman <[email-masked]>
> CC: <[email-masked]>
> Asunto: Re: Fwd: New Version Notification for draft-mrw-6man-ulac-analysis-00
> 

**********************************************
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: Margaret Wasserman <[email-masked]>
Date: Mon, 12 Nov 2007 20:36:09 -0500

Hi Per,

> address-block must be tagged 'special'.

Thanks for raising this point.  Others have made a similar argument  
in the past, and it should definitely be added to the document.  I  
didn't fully understand this point before, but I think I get it now.   
The key point, I think, is that there is no direct connection between  
IETF address block allocations and registry policy.  In this  
particular case, the registries could decide to assign ULA-C  
equivalents from the regular address pool if they thought that would  
be a good idea, or they could choose not to register ULA-Cs,  
regardless of an IETF document allocating a particular address block  
for this purpose.

> If the IETF wants to provide
> the IETF to dictate that process.

I don't think it makes sense to include this argument regarding all  
ULAs in the current document, because RFC 4193 has already been  
published and the case for/against locally-allocated ULAs is outside  
the scope of this document.  Personally, I think that there is a big  
difference between defining locally-assigned ULAs and defining ULA- 
Cs.  In the case of locally-assigned ULAs, RFC 4193 effectively  
removed a block of addresses (the locally-assigned ULAs starting with  
FD00::/8) from the set of addresses that are registry-assigned,  
whereas for ULA-Cs we would by trying (perhaps unsuccessful, as you  
point out) to set central registration policies for a group of  
addresses.

>  Also consider the signals such

This is a very good point, and I think it should be included in the  
document separate from your first argument.  The installation of  
default filters to prevent routing ULAs, for example, might have  
undesirable consequences later.

I think that Geoff Huston has made the same (or a similar) argument  
when he has indicated that it is architecturally unsound to associate  
routing properties with a specific address block. There is no  
inherent guarantee that any registry-assigned address block will be  
routable (you need to arrange for routing with your ISP), so there is  
no need to create a new registry-assigned address block to remove  
that non-existent guarantee.

I'll capture this argument in the next version of my document, as  
well as you first point.

Let me know if I seem to be misunderstanding what you've said.

Thanks!
Margaret

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 20 Nov 2007 15:28:45 +1300

Per,

> address-block must be tagged 'special'. 

I'm going to disagree. Of course, for RFC 4193 there's no doubt that
an IANA-assigned fixed prefix is needed. But I think the argument is
much the same for any reasonable form of ULA-C prefix; we need them
to be universally identifiable as local prefixes that should only
be routed by an IGP. If you don't want that property, they don't
deserve a name containing "local" and should indeed be allocated
by registry policy. But then they are a different animal and need
a different name.

    Brian

---

From: Per Heldal <[email-masked]>
Date: Tue, 20 Nov 2007 10:04:49 +0100

> by registry policy. But then they are a different animal and need

10 or 15 years ago I would agree. Then the RIRs were just being
established and there was no ICANN/ASO through which the RIR-communities
could set global policies for IANA. IETF was king wrt to policies in an
era when the internet largely was made up of networks belonging to
various government agencies. Both the net and the world of internet
governance has changed a lot since. Today IETF is better off focusing on
how things are supposed to work than trying to decide how they should be
used. 

In recent years I've come across several network devices with
functionality that would be useful, but couldn't be used because their
properties needlessly were linked to the use of private addresses. That
is based on rfc1918 which is only a BCP. With IPv6 we're imho going in
the wrong direction and turning policies into technical standards. RFC
4193 is a standards-track document. Even policies defined through a
governance body may form a base for default configurations in network
devices, but I belive such policies are less likely to be implemented in
silicon.

I don't oppose the definition of ULA, or even ULA-C. To make sense they
have to be globally assigned like you say, but that does not mean they
have to be IETF standards.

//per

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Nov 2007 12:14:32 +0100

> direction) that I've missed.

Not sure how this helps us forward except in triggering another round  
of discussion, to which you'll find my contribution below.

ULAs are largely targeted at fulfilling the need for local, Internet  
Service Provider (ISP)-independent prefixes

This sounds like "provider independent" which is a very different  
ballgame.

The point of ULAs is not that they are independent of any particular  
provider, they're independent of any and all connectivity to the  
internet at large.

There is a widely-held view in the Internet operations community that  
ULA-Cs will end-up being routed across the Internet and will,  
effectively, result in the unlimited allocation of globally routed  
Provider Independent (PI) addresses.

I don't think this is "widely" held, but it's certainly vocally held.

Since addresses are only usable when a rather large part of the  
internet accepts routes for them, it seems rather strange to make this  
assumption in the presence of explicit standards language that these  
addresses are NOT to be used in this way. I.e., the argument is that  
the entire internet is going to to something which is undesireable if  
these addresses are created. However, if the entire internet is doing  
it, wouldn't that action by definition be desireable (regardless of  
whether it's a good idea)?

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Nov 2007 12:17:11 +0100

> against that IETF decision.

I object to the assumption that ULAs would be subject to RIR  
involvement.

RIRs deal with ISPs and the addresses ISPs use on the internet. The  
holders of these addresses aren't ISPs and can't even be necessarily  
assumed to be a customer of an ISP, and the addresses aren't used on  
the internet. As such, it would be unnatural to involve the RIRs here.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Nov 2007 12:25:06 +0100

On 13 nov 2007, at 2:36, Margaret Wasserman wrote:

> when he has indicated that it is architecturally unsound to  
> associate routing properties with a specific address block. There is  
> no inherent guarantee that any registry-assigned address block will  
> be routable (you need to arrange for routing with your ISP), so  
> there is no need to create a new registry-assigned address block to  
> remove that non-existent guarantee.

When ULAs in general were under discussion some years ago, I  
repeatedly posed the question whether ULAs should be considered  
unroutable by design or unroutable because of limitations in routing  
technology. I never got an answer.

In practice, what are you going to do when you do a DNS lookup for  
some random domain name and you get a ULA address? Ignore it because  
you know it's unreachable? Try to send a packet anyway? Choosing the  
wrong action here probably means you'll have to suffer a timeout and  
retry with a different address or fail. (The only thing worse than  
failure is taking a lot of time to fail.)

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 11:36:45 -0000

> This sounds like "provider independent" which is a very 
> different ballgame.
> 
> The point of ULAs is not that they are independent of any 
> particular provider, they're independent of any and all 
> connectivity to the internet at large.

I agree that a ULA-C RFC must state that these addresses are
not the same as "provider independent" addresses and that they
are intended for connectivity that does not involve the public
Internet. I think it would be reasonable for the RFC to contain
a definition of "provider independent" something like the
following:

  Provider Independent addresses are global unicast addresses that
  have been allocated to an organization directly by one of the
  RIRs. As part of the agreement between the RIR and the organization
  receiving the allocation, these addresses are considered to be
  for the use of the receiving organization regardless of how they
  connect to the public Internet.

> I don't think this is "widely" held, but it's certainly vocally held.

Totally agree on this. 

> Since addresses are only usable when a rather large part of 
> the internet accepts routes for them, it seems rather strange 
> to make this assumption in the presence of explicit standards 
> language that these addresses are NOT to be used in this way. 
> I.e., the argument is that the entire internet is going to to 
> something which is undesireable if these addresses are 
> created. However, if the entire internet is doing it, 
> wouldn't that action by definition be desireable (regardless 
> of whether it's a good idea)?

That is a mouthful, but it does seem sensible to assume that
either the public Internet will NOT allow ULA-C addresses to
be used as PI addresses, or, they will allow it, in which case
this is what the operators of the public Internet want. In either
case, the IETF only provides the signal as to what is appropriate.
It cannot force operators to act one way or another.

Does anyone know what is happening with the ULA-G draft?
http://sa.vix.com/~vixie/ula-global.txt

--Michael Dillon.

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 11:41:20 -0000

> In practice, what are you going to do when you do a DNS 
> lookup for some random domain name and you get a ULA address? 
> Ignore it because you know it's unreachable? Try to send a 
> packet anyway? 

You have to send a packet because that is the only way to
discover if it is reachable or not. The address may be for
a device just down the hall from you.

Now you might want to configure your DNS proxy (resursive server)
to not pass through AAAA records with ULA addresses unless they
are from known sources with whom you have a prior arrangement.
But that is a different issue.

--Michael Dillon

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Nov 2007 12:51:43 +0100

> But that is a different issue.

Now the DNS must know about routing?

Yikes!

Isn't this one of the issues that brought NAT-PT down?

---

From: <[email-masked]>
Date: Tue, 20 Nov 2007 12:04:10 -0000

> > Now you might want to configure your DNS proxy (resursive 
> server) to 
> > not pass through AAAA records with ULA addresses unless 
> they are from 
> > known sources with whom you have a prior arrangement.

Why would the DNS need to know anything about routing?
ULA addressing is intended for local use. If an organization
wants to enforce that policy by putting filters in their
routers which talk to the public Internet, they are free 
to do so. If they want to put filters in the DNS servers
which talk to the public Internet, they are free to do
so. The DNS filters are about policy, and have nothing to
do with routing.

You are the one who said that somebody might put ULA 
addresses in AAAA records that are visible to the Internet
instead of running proper split-horizon for their internal
DNS. If I want to protect my DNS and my systems from somebody
elses misconfigurations, then filtering and proxying is the
standard way to do it, regardless of whether we are talking
about routing packets, DNS queries, http queries 
or telephone calls.

--Michael Dillon

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 20 Nov 2007 13:19:18 +0100

> ULA addressing is intended for local use.

Right, so the DNS needs to know what's local and what isn't. (Since my  
own server's IP addresses are the only ones I can remember without a  
working DNS, I always use that one when I'm somewhere where there is  
no working DNS. My server doesn't know what's local at the venue where  
I happen to be at any particular time.)

This gets more complex when you make backdoor connections to other  
users of ULA space.

> If an organization
> to do so.

This is probably the best way to handle it if the routers return the  
right ICMP messages, because that way the hosts immediately know they  
have to retry using a different address. This worked quite well for  
me, I think in Montreal, when the www.ietf.org server had just gained  
IPv6 reachability but it was through a /48 prefix which was filtered  
out by the ISP serving the IETF meeting.

> If they want to put filters in the DNS servers

People are going to do stupid things. It's our job at the IETF to give  
them a decent alternative.

> DNS.

There's nothing proper about two faced DNS. ULA addresses ARE going to  
show up in unexpected places, we need to be prepared to deal with that  
when it happens. I don't believe this is necessarily even a  
misconfiguration.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 20 Nov 2007 11:58:44 -0600

Thus spake Iljitsch van Beijnum
>> If that happens (RIRs not having policies for using ULA), then IETF
>> can ask IANA to create a new registry for that, and IANA need to
>> do it, no choice against that IETF decision.

> I object to the assumption that ULAs would be subject to RIR

I presume you mean ULA-C/G, not ULA.

ULAs (RFC 4193) are deliberately unregistered.

> RIRs deal with ISPs and the addresses ISPs use on the internet.
> The holders of these addresses aren't ISPs and can't even be
> necessarily assumed to be a customer of an ISP, and the
> addresses aren't used on the internet. As such, it would be
> unnatural to involve the RIRs here.

I haven't surveyed all of the RIRs, but at least one (ARIN) has explicit 
policy allowing registration of addresses _not_ for use on the public 
internet, either in isolation or as part of completely private network(s). 
One is encouraged to use private/local addressing in such cases when 
feasible, but not required.

Since PIv6 has happened, the _only_ remaining justification for ULA-C/G is 
that it can be handed out to anyone who asks without meeting any bar for 
"need" (based on DFZ slots), because ULA-Xs contains an evil bit in the 
address that says "I hope nobody routes this".  However, if LISP gets 
anywhere, there is no reason for the RIRs to enforce _any_ bar on PI 
addresses (v4 or v6) because they won't need to show up in the DFZ anymore. 
As it stands, ARIN's rejection rate for PIv6 requests is under 3%; is 
solving this "problem" really worth our time, or should we be focusing on 
things like LISP that solve _real_ problems for _many_ people?

S

Stephen Sprunk         "God does not play dice."  --Albert Einstein
CCIE #3723         "God is an inveterate gambler, and He throws the
K5SSS        dice at every possible opportunity." --Stephen Hawking

---

From: Geoff Huston <[email-masked]>
Date: Mon, 26 Nov 2007 17:29:55 +1100

some corrections / comments

1 Locally assined ULAs are not unique - the use of the term 
"probabilistic uniqueness" is meaningless. What is closer to the mark is 
the observation that in most context of overlapping use that involve 
only a subset of locally assigned UALS the probability of collision is 
mall assuming that each local selection was perfectly random

2.1  ULA-Cs are "assuredly unique" i.e. they do not just offer a greater 
level of assurance of uniqueness than locally assigned ULAs - they are 
intended to be unique.

2.2 confuses the concept of uniqueness and traceability - what is 
missing here is the observation that "uniqueness" is by its very nature 
a public declaration and that public declaration is usually carried in 
some form of managed registry.

Traceability is a separate concept, and due to the central registry it 
could be possible to allow ULA-Cs to be traceable

3.2 appears to not to mention the costs of registry maintenance and 
looks only at registration. Indeed, one of the major issues with ULAs 
has been the assumption on the part of some that registry services are 
cheap to set up and cheap to operate, while others observe registry 
operations in other parts of the address space and observe that a 
managed accurate registry is neither simple nor cheap to operatoe.

regards,

   Geoff

Margaret Wasserman wrote:
> 
> FYI --
> 
> I wrote this draft to try to capture the major arguments for and against 
> the definition of ULA-Cs.  Please let me know if I've gotten anything 
> wrong, or if there are any major arguments (in either direction) that 
> I've missed.
> 
> Thanks,
> Margaret
>

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Mon, 26 Nov 2007 11:09:01 +0100

> I presume you mean ULA-C/G, not ULA.

For the purpose of the above objection, I'm not making that  
distinction, but for the random bits derived ULAs there doesn't seem  
to be much danger of RIR involvement.

> I haven't surveyed all of the RIRs, but at least one (ARIN) has  
> explicit policy allowing registration of addresses _not_ for use on  
> the public internet, either in isolation or as part of completely  
> private network(s).

I fail to see how that makes a material difference.

> As it stands, ARIN's rejection rate for PIv6 requests is under 3%;  
> is solving this "problem" really worth our time

Not sure what you mean by "solving this problem". Some people want ULA- 
C. Presumably, they'll be willing to pay reasonable registration  
costs. Find a few parties willing to run registries and be done with it.

I'll also observe that you can turn an address into a domain name and  
that the domain selling business is both making good money and has  
enough competition to keep prices reasonable.

---

From: <[email-masked]>
Date: Mon, 26 Nov 2007 13:07:48 -0000

> Not sure what you mean by "solving this problem". Some people 
> want ULA- C. Presumably, they'll be willing to pay reasonable 
> registration costs. Find a few parties willing to run 
> registries and be done with it.

The IETF doesn't need to find anyone to run registries. The registry
task is delegated to the IANA. In the case of IP addresses, the IANA
has further delegated the task to 5 regional RIRs. I don't think that
ULA-C or G addresses are important enough to deviate from this
structure.
The RIRs already have the capability to communicate with applicants in
several languages and it would be expensive and complex for IANA to
do this kind of work directly.

One advantage of delegating this to the RIRs through IANA is that the
IETF does not need to deal with the issue of ULA-C addresses becoming
a cheap form of PI addresses since the control of that issue will be
in the RIRs. If the network operators do not want ULA-C to become a
cheap
form of PI addresses, then they will maintain strict ULA filters and 
participate in their RIR's grass-roots democratic process. In fact, 
a final ULA-C or G RFC should really contain some language that explains
this fact and explains why the IETF does not see the need to take any
specific action on the cheap PI issue.

--Michael Dillon