Subject: Stupid ULA discussion

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 5 Dec 2007 11:39:19 -0800

ULA is LOCAL.

It has nothing to do with PI.

People need address space to number the links between their SQL and  
web servers. This is completely orthogonal to address space used on  
the internet.

If it's routed at some point, this means we're all getting enough  
money to change our minds on the merits of routing unroutable space so  
by definition, we'll be happy with that.

And again: keep the RIRs out of this, this has nothing to do with  
their current business.

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

---

From: "Christopher Morrow" <[email-masked]>
Date: Wed, 5 Dec 2007 15:23:45 -0500

> It has nothing to do with PI.

sort of correct... I believe the fear here is that if you are in a
world of provider-assigned ip space without any simple hope for
renumbering you will look for ULA-x as a 'no renumbering' solution and
try to find some form of NAT initially that will make this all work
for you with minimal work. If NAT is no longer avaialble and you have
a /48 in ULA-x space that is 'yours' why can't you ask your provider
to route that for you? and all of his peers/customers to do the same?
This could lead to a very large pool/use of ULA-x in 'public' places
in a short period of time. I'm not sure that the Internet today is
ready to accommodate that sort of route growth. (this goes somewhat to
the point below as well)

> web servers. This is completely orthogonal to address space used on

this is also sort of correct. I think that ULA and the like come from
the mentality that in the ipv4 world people numbered lots of
'internal' things out of 1918 space, following that line of logic
people will want to use 'private' space on internal networks in the
ipv6  world as well. They'll also want to, in most cases, have that
space NAT'd to the real world... perhaps not NAT, perhaps some other
equivalent technology, but still a 'private' address in the end.

When I last lobbied for a ULA-x type of option it was for this very
sort of thing, 'internal networks' that might later be connected to
other 'internal networks' and thus I thought that ULA-C might make the
most sense. I think that this all skips over a very real issue which
is 'how does your host/router/blah handle having more than one address
and how does it decide which to use when?' coupled with that is the
'do users want to manage more than one address going forward and all
of the associated foo with that?
(dhcp/dns/service-binding/firewalls/acls/policy-foo/etc)'

I think that somewhere we ought to find the requirement for ULA before
creating something like this. Additionally, without a reasonable
solution for how enterprises deal with their current numbering issues
(multihoming, internal address+NAT) the ULA-x discussion is going to
be mostly headless and directionless...

-Chris

---

From: Mark Smith <[email-masked]>
Date: Thu, 6 Dec 2007 07:17:51 +1030

On Wed, 5 Dec 2007 11:39:19 -0800

> web servers. This is completely orthogonal to address space used on  

It also seems to me that a common assumption in this debate, by people
who consider IPv6 to just be IPv4 with bigger addresses, is that if you
have ULA addressing on a interface, you can't have global addresses as
well. IOW, they're either not aware or forgetting that IPv6 is fully
designed to properly support multiple prefixes on an interface, rather
than it being somewhat of a hack that works under IPv4, but not with
things like DHCPv4.

I think that then warps their perspective on whether ULAs might become PI (should an appropriate routing technology come along), or whether NAT in IPv6 is necessary for global Internet access if you use ULAs.

> And again: keep the RIRs out of this, this has nothing to do with  

Regards,
Mark.

---

From: <[email-masked]>
Date: Wed, 5 Dec 2007 20:56:47 -0000

> People need address space to number the links between their 
> SQL and web servers. This is completely orthogonal to address 
> space used on the internet.

Agreed!

> If it's routed at some point, this means we're all getting 
> enough money to change our minds on the merits of routing 
> unroutable space so by definition, we'll be happy with that.

In other words, any arguments that say "but people will take that
address block and use it on the public Internet" apply equally to
people who use a 3FFE block or just pick some random address block
that is not in use. The only thing that stops people from doing
this is ISPs policing the BGP routes that they hear which will
also stop ULA use. 

In a way, people are right when they have a gut feel that ULA-C 
addresses are just like PI addresses. But they forget that they
are also like any other unicast IPv6 address. All addresses work
everywhere on the Internet, except where they are filtered/policed
and ULA-C addresses will be filtered just like any other kind of
address which is technically usable, but defined by policy as unusable.

> And again: keep the RIRs out of this, this has nothing to do 
> with their current business.

Really, this is none of our business. When push comes to shove, the IANA
is responsible for registering numbers and if they want to delegate the
job to RIRs, then they will. 

--Michael Dillon

---

From: Brian Dickson <[email-masked]>
Date: Wed, 05 Dec 2007 13:32:43 -0800

> web servers. This is completely orthogonal to address space used on 
ULA is also UNIQUE.
(Well, for half of ULA, "probably unique").

It would be a service, rather than a disservice, to the community of 
"network admins" (LAN admins), to educate them on the value of uniqueness.

And to point out the existence of a suitable replacement for IPv4's 
10.0.0.0/8 et al, if they want a non-registered, non-unique, truly 
non-routable address space that maps well to their current  RFC 1918 space.

And that would be the IPv4-mapped IPv6 address space for RFC 1918.
I.e. ::ffff:10.0.0.0, ::ffff:172.16.0.0 and ::ffff:192.168.0.0 (as /104, 
/108, and /112 respectively.)

And yes, I know it's ugly and rude.
But it makes it easy for the end admin to manage the dual-stack universe 
between their SQL and web servers.

Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 06 Dec 2007 10:47:41 +1300

> It has nothing to do with PI.

Another way to say it is that there is a default expectation
that ULAs will be filtered and that PI prefixes will be
routed. That's a good enough rationale for having them in
separate parts of the address space - a ULA being routed
or a PI prefix being filtered are both things that should
raise an operational flag, and that will be easier if they're
distinguishable at a glance.

There's no sense in looking for any deeper significance
than that.

      Brian

---

From: "Suresh Krishnan" <[email-masked]>
Date: Wed, 5 Dec 2007 17:04:32 -0500

Hi Brian,

> /108, and /112 respectively.)

Please do not suggest anything remotely close to this. The v4 mapped v6 address 
space is for API compatibility purposes only (i.e. use AF_INET6 with 
v4 addresses). These addresses should never ever appear on the wire.

For more information see section 2.2 of RFC4942 and 
draft-itojun-v6ops-v4mapped-harmful-02.txt (expired draft - google it)

Cheers
Suresh

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Wed, 5 Dec 2007 17:26:24 -0500

> -----Original Message-----
> From: Suresh Krishnan [mailto:[email-masked]] 
> Sent: Wednesday, December 05, 2007 5:05 PM
> To: Brian Dickson; Iljitsch van Beijnum
> Cc: IETF IPv6 Mailing List
> Subject: RE: Stupid ULA discussion
> 
> Hi Brian,
> 

Aww shucks. And I had been holding that concept in my back of
last-resort tricks.

Bert

---

From: Erik Nordmark <[email-masked]>
Date: Wed, 05 Dec 2007 15:01:50 -0800

> v4 addresses). These addresses should never ever appear on the wire.

Never say never. RFC 2765 - a proposed standard - do send them on the wire.

Whether this is a good or bad idea is a different matter - I just wanted 
to point out we have a PS on the books which uses them.

    Erik

---

From: james woodyatt <[email-masked]>
Date: Wed, 5 Dec 2007 15:27:20 -0800

The subject line on this thread is absolutely correct.

On Dec 5, 2007, at 13:32, Brian Dickson wrote:
>> People need address space to number the links between their SQL  
>> and web servers. This is completely orthogonal to address space  
>> used on the internet.
>
> ULA is also UNIQUE.

The phrase you are looking for is "statistically unique."

"Probably," my house will still be standing in another thirty years.   
Yet, I'm still paying for fire insurance.  "Statistically," there is  
no chance I'm going to die by being struck on the head directly by a  
newly fallen meteorite.  Am I concerned enough about my exposure to  
the risk of falling meteorites to worry about whether my life  
insurance policy covers it?  Not at all.

Which gives me an idea: I should go into the insurance business,  
selling ULA prefixes that I *GUARANTEE* (for an UNLIMITED TIME!!!) to  
be ABSOLUTELY UNIQUE or I will pay triple the cost of migrating your  
network to a new ULA prefix when a documented collision occurs.  I  
can do this with 5 lines of totally stateless Perl added to some  
stupid web server— it's just a random number generator.  I'll MAKE  
ZILLIONS FAST!

> It would be a service, rather than a disservice, to the community  
> of "network admins" (LAN admins), to educate them on the value of  
> uniqueness.

And the difference between "probably unique" and *statistically*  
unique.  Here's Brad DeLong explaining what kinds of tragedy can  
befall the poor sod who fails to grasp the importance of statistics:

	<http://delong.typepad.com/sdj/2007/12/intellectual-ga.html>

The key sentences...
>> This is the principal insight of the science of statistics. it is  
>> an important insight. It is a powerful insight. It is also not an  
>> *obvious* insight--that's what makes it powerful and important.
>>

Emphasis mine.

> I.e. ::ffff:10.0.0.0, ::ffff:172.16.0.0 and ::ffff:192.168.0.0 (as / 
> 104, /108, and /112 respectively.)
>

Suresh Krishnan is correct.  Please do not suggest anything remotely  
close to this.  Not V4MAPPED addresses.  Not V4COMPAT addresses.  Not  
6to4-prefix addresses.  Not Teredo addresses.  Please do not embed  
RFC 1918 addresses in IPv6 addresses full-stop.  To do so is morally  
equivalent to reinventing the functionality of the deprecated site- 
local addresses in some other corner of the address space for no good  
purpose.  That way lies utter madness.  Go not that way.

> But it makes it easy for the end admin to manage the dual-stack  
> universe between their SQL and web servers.

If we're going to have another round of this discussion, can all the  
participants please make a solemn pledge to read RFC 3879 all the way  
through and to ask the authors, who are both regular participants  
here, for help with the underlying concepts if any of them are  
confusing?  Please?

--
james woodyatt <[email-masked]>
member of technical staff, communications engineering

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 5 Dec 2007 16:13:51 -0800

James, 

> From: james woodyatt [mailto:[email-masked]] 
> Sent: Wednesday, December 05, 2007 3:27 PM
> To: IETF IPv6 Mailing List
> Subject: Re: Stupid ULA discussion
> 
> stupid web server- it's just a random number generator.  I'll MAKE  
> ZILLIONS FAST!

I have seen phony versions of such a "service" advertised by
others at least twice in the past; nice work if you can get it!
 
> RFC 1918 addresses in IPv6 addresses full-stop.

This is exactly why we have ISATAP addresses (RFC4214).

Fred
[email-masked]

> To do so is morally

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 5 Dec 2007 16:25:20 -0800

> There's no sense in looking for any deeper significance

Actually there is, because the public network operator community -thinks- they know what the important/easy issues are for enterprise network operators. Never mind that they have no real clue about how difficult it is to carve up portions of an otherwise aggregated space and keep that correct at all instances over an extended period of time. Clear separation is a great simplifier, and should be good enough, but repetition of this conversation by people that want nothing more than to tell others how to run their network shows it is not. 

The place to look for deeper significance is in address selection. The question continually comes up about how a host could possibly select between a restricted local and a global reach prefix if it has both, and the answer is if they are out of the same aggregate they can't. Putting the local use prefix in a part of the space that makes longest-match address selection trivial is the real value behind ULA-C. 

Tony

---

From: Per Heldal <[email-masked]>
Date: Thu, 06 Dec 2007 01:28:39 +0100

> And again: keep the RIRs out of this, this has nothing to do with  

Let's pull the IETF out of policy instead, and be happy to focus on
technical matters ;)  To do so may even prove crucial to maintain IETF
as a technical authority in the longer term.

By that I mean that the IETF shouldn't be involved in address
distribution matters unless there's technical reason for it, and ULA
does IMHO not qualify as such. Any randomly selected address-block can
be either routable or useless on the internet depending on what the
operational policies are, regardless of what the IETF says. It doesn't
matter what it is called. IETF shouldn't even care. Existing RFCs that
deal with local-addressing (in the context of "private addresses") for
v6 are really unnecessary, and should at least be changed from technical
standards to BCPs (in line with rfc1918).

The days when the only way to form global policies for IANA was through
the IETF are over. If there's a need for global allocation of addresses
for special purposes those needs should be communicated to the ICANN ASO
(or whatever that'll be in the future if the UN-IGF gets their way)
which in turn will request IANA to make an appropriate allocation. In
practise that would require the RIR-communities (not to be confused with
the operational units who handle the registration process) to pass
unified requests for a global policy to the ASO. IANA may later choose
to delegate coordination tasks for ULA-G/C/whatever back to
RIR-operations, but that's just another practical issue the IETF doesn't
need to bother with.

//per

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 07 Dec 2007 10:32:03 +1300

On 2007-12-06 13:28, Per Heldal wrote:
...
> distribution matters unless there's technical reason for it,

That is well understood and was written into the IETF/IANA
agreement 7 years ago.

> and ULA
> does IMHO not qualify as such. 

IMHO ULA does qualify, in fact must qualify, since ULAs
have technical impact (see my previous note and Tony Hain's
comment on it).

To go further, PI should qualify too, since the allocation of
PI poses a serious technical threat to the scaling of the
routing system.

     Brian

---

From: Per Heldal <[email-masked]>
Date: Fri, 07 Dec 2007 01:02:40 +0100

> have technical impact (see my previous note and Tony Hain's

I still consider it more of an operational issue than a technical one.
It's naive to think that every standard can be made such that there are
no limits. Users, operators and vendors have to be able to deal with it.

>distinguishable at a glance.

This doesn't make it an IETF issue. No policy-making body worthy of
operating in this field would be short of people who understand this
issue. 

As a comment to your statement Tony wrote:
>Actually there is, because the public network operator community
>-thinks- they know what the important/easy issues are for enterprise
>network operators. Never mind that they have no real clue about how
>difficult it is to carve up portions of an otherwise aggregated space
>and keep that correct at all instances over an extended period of time.
>Clear separation is a great simplifier, and should be good enough, but
>repetition of this conversation by people that want nothing more than
>to tell others how to run their network shows it is not. 

This assumes that policy-making organisations are dictated by network
operators. That is simply false. I don't intend to start a discussion of
which policy-making body is more democratic. It is however relevant to
mention that the organisations in the ASO represent a combination of
individuals, SMBs, large enterprises, academic communities and network
operators. Governments and national regulators have also started to pay
attention and take part in the processes in recent years. 

> PI poses a serious technical threat to the scaling of the

As does an explosive growth in PA blocks being assigned, new TE schemes
causing massive fragmentation, and a number of other things. If IETF
needs detailed control of the routing table's size, you have to address
those policy-issues too.

For the record; I don't oppose any particular definition of ULA. I just
don't want them as IETF standards. It's dangerous to generalise, but
standards are often hard-coded or even implemented in silicon, while
policies at best form a base for default configurations. Regardless of
where the decision is made it'll eventually end up as an entry in IANA's
list of allocated address-ranges. 

Any of a number of suggested methods for an id/locator-split has the
potential of solving the scalability issue -- at least for edge
networks. That'll largely take care of PI, and even the dreaded ULA-C(G)
may then be routed globally with no impact on the DFZ should anyone feel
like doing so.

//per