Subject: Revising Centrally Assigned ULA draft

From: Brian Haberman <[email-masked]>
Date: Thu, 07 Jun 2007 15:26:52 -0400

All,
     There has been recent activity in the Registry Community looking at
policies utilizing the Centrally Assigned ULA specification that has
expired.  Several people with ties to both the IETF and the RIRs have
been working with the authors to revise the specification in order to
meet the needs of the policy proposals in the RIRs.

     Given that the previous work on Centrally Assigned ULAs was adopted
as an IPv6 WG document, the chairs feel that this upcoming revision
should be considered a continuation of that work.

     The chairs highly encourage people interested in this work to
review and comment on the upcoming revision when it is published.

     As a note, Bob will be the responsible editor for this document and
Brian will be the shepherding WG chair.

Regards,
Brian and Bob

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

---

From: "Durand, Alain" <[email-masked]>
Date: Thu, 7 Jun 2007 16:17:04 -0400

Brian,

Give the heat this proposal is generating (at least in the ARIN region)
it does not seem very constructive to tackle this issue
in a sleeping working group that is not meeting face to face.

   - Alain. 

> -----Original Message-----
> From: Brian Haberman [mailto:[email-masked]] 
> Sent: Thursday, June 07, 2007 3:27 PM
> To: Ipv
> Subject: Revising Centrally Assigned ULA draft
> 
> All,
>      There has been recent activity in the Registry Community 
> looking at policies utilizing the Centrally Assigned ULA 
> specification that has expired.  Several people with ties to 
> both the IETF and the RIRs have been working with the authors 
> to revise the specification in order to meet the needs of the 
> policy proposals in the RIRs.
> 
>      Given that the previous work on Centrally Assigned ULAs 
> was adopted as an IPv6 WG document, the chairs feel that this 
> upcoming revision should be considered a continuation of that work.
> 
>      The chairs highly encourage people interested in this 
> work to review and comment on the upcoming revision when it 
> is published.
> 
>      As a note, Bob will be the responsible editor for this 
> document and Brian will be the shepherding WG chair.
> 
> Regards,
> Brian and Bob
> 
>

---

From: "Tony Hain" <[email-masked]>
Date: Thu, 7 Jun 2007 19:04:24 -0700

ARIN & NANOG are nothing more than heat lately (all hot air?). As I
suggested at NANOG this week, the right thing to do is for the WG to define
the space, and turn it over to IANA to manage. Beyond that it was all policy
anyway, so the fact that it is defined makes no difference if policy chooses
to ignore it. Not defining it leaves policy with no alternative but to
succumb to those that want nothing more than to exercise power through
control of the address space.

I say wrap it up and ship it. 
Tony

> From: Durand, Alain [mailto:[email-masked]]
> Sent: Thursday, June 07, 2007 1:17 PM
> To: Brian Haberman; Ipv
> Subject: RE: Revising Centrally Assigned ULA draft
> 
> Brian,
>

---

From: Paul Vixie <[email-masked]>
Date: Fri, 08 Jun 2007 03:56:39 +0000

> the space, and turn it over to IANA to manage.

the internet's addressing system uses a combination of top-down architectural
guideance (from IAB and IESG and the WGs) and bottom-up operational policy
guideance (from the RIRs).  the fact that this proposal is garnering a lot
of heat from the bottom-up side of the process ought to be a strong hint
that the top-down side ought to listen carefully and use great caution.

> Beyond that it was all policy anyway, so the fact that it is defined makes
> no difference if policy chooses to ignore it. Not defining it leaves policy
> with no alternative but to succumb to those that want nothing more than to
> exercise power through control of the address space.
> 

if that's what we're doing, then, i say kill it.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 08 Jun 2007 09:14:04 +0200

I trust that the new version will include the proposal
for a fully robotic solution for creating and escrowing
guaranteed-unique ULAs. That's the only missing property in
existing ULAs, and we should certainly consider a purely
robotic solution with no need for registry action or registry
policy of any kind.

     Brian

---

From: "Durand, Alain" <[email-masked]>
Date: Fri, 8 Jun 2007 07:59:22 -0400

> From: Paul Vixie [mailto:[email-masked]] 
> Sent: Thursday, June 07, 2007 11:57 PM
> To: 'Ipv'
> Subject: Re: Revising Centrally Assigned ULA draft 
> if that's what we're doing, then, i say kill it

This email exchange is the proof that an open discussion is needed.
The IETF IPv6 wg doing a contraversial thing on its own without
listening to the input from the operational people is not productive,
the last thing the community need is yet another power struggle.

   - Alain.

---

From: Brian Haberman <[email-masked]>
Date: Fri, 08 Jun 2007 11:08:51 -0400

All,

> the last thing the community need is yet another power struggle.

Before this thread gets any deeper in a rat hole, allow me to point out
a few things.

1. The discussion of reviving Centrally Assigned ULAs originated in the
RIR community

2. A new draft of the spec *with significant changes* is being worked on

3. Input for the revised draft is coming from the RIR community

Rather than assume the contents of the draft and argue their merits,
please wait for the posting of the new draft and then comment.

Regards,
Brian

---

From: Bill Manning <[email-masked]>
Date: Fri, 8 Jun 2007 08:15:08 -0700

presuming this course of action is taken, it raises a much larger
issue consisting of the IETF creating "property rights" in the 
address space arena.  To date, (AFAIK)  most legal arguments have
taken the line that IP addresses are NOT property, come from a
common resource that the RIR's administer for the good of the 
community.   ULA-C  carves out a bit of IP space and in the absence
of RIR oversight, creates "property"... creating an ambigious
set of legal issues which will be fought for years.  

I -REALLY- am uncomfortable w/ the IETF, in a mothballed WG,
creating this nightmare for the operational community.

--bill

-- 
--bill

Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).

---

From: Paul Vixie <[email-masked]>
Date: Fri, 08 Jun 2007 15:40:46 +0000

> please wait for the posting of the new draft and then comment.

i understood alain to be asking that the ipv6 wg be de-mothballed in
order that the upcoming revised ULA I-D will be properly reviewed.  i
hope that alain may even be willing to serve as interrim wg chair.

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 8 Jun 2007 09:11:37 -0700

Given that there are other important documents still
being actively finalized within the wg, I don't see
a problem with Brian's suggested approach.

Fred
[email-masked]

> Sent: Friday, June 08, 2007 8:09 AM
> To: Durand, Alain
> Cc: Ipv

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 09 Jun 2007 09:04:30 +0200

On 2007-06-08 17:15, Bill Manning wrote:
> address space arena.  

I decline to take the issue of property rights seriously in a
pseudo-random space of 2**40 natural numbers. I *would* recommend
that the robot be hosted by a trusted organization.

> To date, (AFAIK)  most legal arguments have

IMHO it's just not going to happen, in the absence of scarcity.

> I -REALLY- am uncomfortable w/ the IETF, in a mothballed WG,

As others have pointed out, the fact that this WG isn't currently
meeting f2f is irrelevant. Of course, the debate should include
the entire community, which is why this list is open.

> creating this nightmare for the operational community.

Since ULAs aren't routable, I don't see it. If we were talking
about routable PI, it would be a different matter.

    Brian

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Sat, 9 Jun 2007 10:06:16 -0400

IANA already manages things like enterprise-id numbers. And, then
there's the existing IPv4 address space (how many assigned addresses are
returned or reclaimed?).

While ULA's could potentially be used by a much larger number of
entities, they may also not be used except by larger organizations. Do
you think your average home user or small business would need a ULA?
Would they know to get one? Would they have the knowledge to manage it?

So, I think this "property rights" issue FUD.

Of course, a system like domain name registration where there is a small
annual fee to retain a ULA-C does have merit as it pays for the
registration system and assures that someone has to pay to renew the
assignment. So, if company A buys company B and both have ULA-C's,
company A may decide to let company B's ULA-C expire after a year or two
since there may no longer be a need for it.

- Bernie

-----Original Message-----
From: Brian E Carpenter [mailto:[email-masked]] 
Sent: Saturday, June 09, 2007 3:05 AM
To: Bill Manning
Cc: Brian Haberman; Ipv
Subject: Re: Revising Centrally Assigned ULA draft

    Brian

---

From: Paul Vixie <[email-masked]>
Date: Sat, 09 Jun 2007 15:41:43 +0000

> ... I *would* recommend that the robot be hosted by a trusted organization.

as ietf, itu, icann, ep.net, and isc have all proved, most organizations are
trusted by most people, but no organization is trusted by everybody.  what
specific trust threshold are you aiming for in the above stated requirement?

> Since ULAs aren't routable, I don't see [a nightmare for the operational
> community].  If we were talking about routable PI, it would be a different
> matter.

in discussions you have evidently not been following, even though they are
occuring on two open mailing lists where this topic is topical, the
operational nightmares are described in detail.  those mailing lists are
[email-masked] and perhaps also [email-masked].

perhaps this is illustrative as to why holding this discussion in a mothballed
IETF WG is unlikely to reach the audience who would be affected by it.

---

From: Paul Vixie <[email-masked]>
Date: Sat, 09 Jun 2007 15:51:35 +0000

> So, I think this "property rights" issue FUD.

please don't shoot the messenger.  but in most of meatspace, if there's a
thing you pay (either one time or recurring) to get exclusive use of, and it's
of value (if you lost your use of it, it would financially injure you), then
it's property.  the RIR system can work only because it has excellent lawyers.
so, until you have consulted an excellent lawyer, please don't argue about
whether the resource system created by ULA-C would be called property or not.

> annual fee to retain a ULA-C does have merit as it pays for the registration
> system and assures that someone has to pay to renew the assignment. So, if
> company A buys company B and both have ULA-C's, company A may decide to let
> company B's ULA-C expire after a year or two since there may no longer be a
> need for it.

as icann has discovered, any mandate that an organization be paid a fee by
users for the use of something that's necessary in common every day life is,
in many parts of meatspace, equivilent to creating a "tax authority".  the
rules governing that are quite sensitive and twisty.  as above, please consult
an excellent lawyer before you decide how easy it would be.

---

From: Mark Smith <[email-masked]>
Date: Sun, 10 Jun 2007 09:15:00 +0930

On Sat, 9 Jun 2007 10:06:16 -0400

> Would they know to get one? Would they have the knowledge to manage it?

Any residential user who needs to have non-globally accessible devices
attached to their home network could use them. Think a networked
printer. Or DVD player, or clothes iron, washing machine, TV etc. As I
think it'd be likely that most residential users would have devices
that they don't want "on the Internet", I think ULA addessing domains
are likely to going to be present in every household.

As for getting a ULA, that's a user interface problem, and I think
that's mostly independent of the addressing space or how to generate
the ULA unique value. A simple enough solution might be that the first
time an Internet home gateway is powered up it generates the ULA, then
starts announcing it as a prefix in RAs. This sort of problem has been
solved before on a number of occasions - IPX, Appletalk or zeroconf
could provide example methods.

Regards,
Mark.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jun 2007 10:40:32 +0200

> specific trust threshold are you aiming for in the above stated requirement?

Since you ask:
IANA, under the IAB's authority and RFC 2860 clause 4.3 exception (b),
i.e. just like any other technical registries run by IANA.

That MoU allows the IETF to pull the plug if it ever needs to.

    Brian

---

From: "Gunter Van de Velde \(gvandeve\)" <[email-masked]>
Date: Mon, 11 Jun 2007 15:14:04 +0200

I suppose most of these users will have big (actually a quite small)
flat infrastructure
to keep it simple? Hence what limits them to use just LL? Why ULA? What 
would be the residential users benefit? Do you think that residential 
users will have small routed networks in the future?

G/

-----Original Message-----
From: Mark Smith
[mailto:[email-masked]] 
Sent: Sunday, June 10, 2007 1:45 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: Revising Centrally Assigned ULA draft

On Sat, 9 Jun 2007 10:06:16 -0400
"Bernie Volz \(volz\)" <[email-masked]> wrote:

> there's the existing IPv4 address space (how many assigned addresses 
> are returned or reclaimed?).
> 

Any residential user who needs to have non-globally accessible devices
attached to their home network could use them. Think a networked
printer. Or DVD player, or clothes iron, washing machine, TV etc. As I
think it'd be likely that most residential users would have devices that
they don't want "on the Internet", I think ULA addessing domains are
likely to going to be present in every household.

As for getting a ULA, that's a user interface problem, and I think
that's mostly independent of the addressing space or how to generate the
ULA unique value. A simple enough solution might be that the first time
an Internet home gateway is powered up it generates the ULA, then starts
announcing it as a prefix in RAs. This sort of problem has been solved
before on a number of occasions - IPX, Appletalk or zeroconf could
provide example methods.

Regards,
Mark.

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 11 Jun 2007 14:31:49 +0100

Mark Smith wrote:

> attached to their home network could use them.[..]

the "normal" ULA (RFC4193) provides this already. The "user interface"
is simply the box that auto generates it and then applies it. Presto.
This thus already is possible today, with todays RFC's (RFC4193).

ULA-C is a completely different beast that is best solved by simply
having organizations to the RIR's and getting a nice /48 or similar
address space they can justify. They call that "PI" which is a dirty
word, but serves the purpose completely.

The only benefit which has been named upto now is that firewalling is
simpler if you know that non fd00::/8 space is The Evil Internet.
But why should you trust address space in any way?!

Greets,
 Jeroen

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 Jun 2007 13:51:49 +0000

> > ... most organizations are trusted by most people, but no organization is
> > trusted by everybody.  what specific trust threshold are you aiming for in
> > the above stated requirement?
> 

can you clarify further?  do you mean "hosted by IANA" or "trusted by IANA" ?

(noting that i trust IANA just fine, but that this point isn't academic.)

---

From: Paul Vixie <[email-masked]>
Date: Mon, 11 Jun 2007 14:21:43 +0000

> I suppose most of these users will have big (actually a quite small) flat
> infrastructure to keep it simple? Hence what limits them to use just LL?
> Why ULA?  What would be the residential users benefit?  Do you think that
> residential users will have small routed networks in the future?

i think that the distinction between "provider" and "consumer" will blur in
the following ways.

first, if everybody in the neighborhood has overlapping wireless clouds, so
that neighbor-sets {A B} {B C} {C D} can join clouds owned by neighbors A,
B, and C respectively, that D's preferred path to A will in some cases be
through C and B rather than through their "providers".  this is not just
because their providers might not have as much in-neighborhood capacity due
to backhauling and provider multiplicity, but because this is the topology
many human communities prefer.  consider the legal implications for file
sharing when there is vs. isn't a "provider" which is regulated and subject
to CALEA, as a low hanging example.

second, with COMMONS and things like it sprouting up, there will be networks
built using city-owned infrastructure where virtually all traffic into/outof
that city has a city-owned last mile.  the need for a "provider" will only be
truly notable for traffic into/outof that city, and it will be impractical
for economic reasons ("anti-lockin") to use "provider assigned" addressing.
the city would have to become an LIR in today's model.  ULA and ULA-C could
change all of that, in a bad way, by either requiring a city to run a giant
NAT-PT box and breaking end-to-end on intercity traffic, or by requiring the
"provider" to do so, or by requiring the "provider" to import ULA routes.

to your last question, i do think that residential users will have small
routed networks in the future, rather than a flat neighborhood-wide or even
city-wide L2, simply because the broadcast domain for things like Bonjour 
will be too large otherwise, and the market seems to have embraced "routers"
as their preferred security perimeter (vs hosts, bridges, or repeaters.)

(these are the wages of our sins from not separating routing from identity,
and from assuming that the economic principles underlaying IPv4 routing
would still apply in an IPv6 world.)

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jun 2007 16:23:37 +0200

> (noting that i trust IANA just fine, but that this point isn't academic.)

Yes, good question. My gut feeling is "hosted by". I'm not sure I can
argue rationally for that.

BTW do the ops lists where this is discussed have archives?

     Brian

---

From: Bill Manning <[email-masked]>
Date: Mon, 11 Jun 2007 07:31:51 -0700

> BTW do the ops lists where this is discussed have archives?

	for ARIN's ppml list:   http://www.arin.net/mailing_lists/index.html
	and follow the link for "archives"

--bill

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 11 Jun 2007 17:28:07 +0200

It seems that what you describe is a prime candidate
for metro addressing, not for ULAs of any kind. And a metro
prefix is not really any different from a PA prefix, except
that it's assigned to a municipality.

ULAs should be kept in-house, literally.

     Brian

---

From: james woodyatt <[email-masked]>
Date: Mon, 11 Jun 2007 10:45:57 -0700

> as their preferred security perimeter (vs hosts, bridges, or  

I'd like to note for the record that Bonjour is more than just DNS-SD  
over multicast.  It works quite well over unicast with infrastructure  
content servers by using a few simple extensions to the core  
protocols, e.g. for handling long-lived queries, etc.

In the unlikely event that metro-L2 came to be feasible for other  
reasons, there wouldn't be that much of a problem fitting Bonjour  
into that environment.  While Bonjour was developed for zero- 
configuration networking, it's still perfectly reasonable to use it  
where in managed networks.

> would still apply in an IPv6 world.)

Here here.  This argument seems awfully compelling to me.  Given the  
near ubiquity of IEEE 802.1 for local-area networking in residential  
and small office environments, it's really hard for me to see how  
there is a need for residential users to have routed networks when / 
64 prefixes are almost too cheap to meter (and will continue to be  
until kakistocracy emerges as the dominant form of Internet governance).

I don't see why residential users should even need ULA, much  
centrally assigned ULA.  Is there a thread on one of those ops list  
someone could refer me to read from the archives so I can come up to  
speed on the reasons the operations community thinks otherwise?

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

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jun 2007 09:00:27 +0200

On 2007-06-11 19:45, james woodyatt wrote:
...
> I don't see why residential users should even need ULA, much centrally 
> assigned ULA.  

Assuming you mean "the vast majority of residential users" I agree. But there
will always be exceptions, and there will be a soft boundary between small
offices that have no use for ULAs, and larger ones that maybe do.

Not that it really matters, since ULAs never appear off-site anyway.

    Brian

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Jun 2007 07:27:08 +0000

> Not that it really matters, since ULAs never appear off-site anyway.

depending on what you mean by a site, both in relative and absolute terms
of space and of time, there might be general agreement on this point, or not.

hopefully the regress isn't infinite.  care to take it a step and see?

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 12 Jun 2007 09:45:05 +0200

> hopefully the regress isn't infinite.  care to take it a step and see?

The regression is easy: the site for a given ULA is the routing domain
within which that ULA is not filtered.

That is not intended to be frivolous. If two enterprise networks agree
to recognize each other's ULA, the ULAs can be routed over a link (or VPN)
between those two networks. But both enterprises' ISPs will filter ULAs.

I'm not making this up. Something very like it is current practice on
IPv4; it's just less well defined since we don't have ULA space.

     Brian

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 Jun 2007 17:36:05 +0930

On Mon, 11 Jun 2007 15:14:04 +0200

> users will have small routed networks in the future?

I think it would be wise not to preclude the possibility. 

One thing I'm trying to keep remembering is that while it is easier to
understand IPv6 by thinking of it as "IPv4 with bigger addresses", I
think it is important to remember it is more than that. Inherent
functional constraints in IPv4, mainly due to it's limited addressing,
don't or don't have to exist in IPv6. Two examples of things that I
don't think can be done with IPv4 and probably weren't thought of being
done with IPv6 when the IPv6 addressing size was decided are HIP and
ULA addressing. Next year, or 5 or 10 years time we may have more
things to add to that list.

So, I think it's useful to certainly use IPv4 and it's common
deployment scenarios as a basis for how people will probably use IPv6,
however I think it is also important not to be trapped by it. I think
IPv6 can open up possiblities of solving "IPv4" solved problems in
different or better ways.

People might have routed ULA networks in their home. Maybe a scenario
could be when they come home from work and their Personal Area Network
with a ULA prefix, which covers their mobile phone, music player and
pedometer in their shoes, connects to their wireless home network with
a different ULA. Possibly their mobile phone in this scenario will act
as a Wifi to Bluetooth router between the separate ULA prefixes 

(I think some of the latest high end mobile phones could probably, with
a small software upgrade, act in that capacity today 1- from what I
understand of their capabilities (3G, Wifi, bluetooth), I'd think the
only thing probably missing is the IPv6 routing capability)

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 Jun 2007 17:44:12 +0930

On Mon, 11 Jun 2007 17:28:07 +0200

> ULAs should be kept in-house, literally.

While I'm guessing it is way to late to change the name, I've realised
that they probably should have been called "Unique Internal Addresses".
Unfortunately most non-networking people probably won't realise that
"Local" in ULA means local to your network's administrative domain,
however big or small that is.

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 Jun 2007 17:50:10 +0930

On Tue, 12 Jun 2007 07:27:08 +0000

> of space and of time, there might be general agreement on this point, or not.

I think a better way of describing it is "administrative domain". A
home and the devices in it are an administrative domain - the person who
bought or looks after the devices has to administer, or at least take
ownership of the administration of those devices. That ownership could
be as simple as ringing up an external contractor to get problems
sorted out - this is the same sense that I "administer" the pumbing or
electrical system in my home. 

An "administrative domain" could correspond to a site (a home), or it
might not at all (a personal area network).

Regards,
Mark.

---

From: Bill Manning <[email-masked]>
Date: Tue, 12 Jun 2007 03:35:36 -0700

> might not at all (a personal area network).

	within the routing world, "administrative domain" has avery
	clear meaning - an ASN boundary.

--bill

---

From: Mark Smith <[email-masked]>
Date: Tue, 12 Jun 2007 22:11:19 +0930

On Tue, 12 Jun 2007 03:35:36 -0700

> 	clear meaning - an ASN boundary.

I think it is the other way around. The way to describe
where an ASN boundary can fall is a network's administrative domain,
but not all network administrative domains have ASNs -
self-administered corporate networks that are behind an
ISPs ASN being a common example.

Regards,
Mark.

---

From: Bill Manning <[email-masked]>
Date: Tue, 12 Jun 2007 06:59:11 -0700

> ISPs ASN being a common example.

	thats not what the RFCs or current practice dictate.

--bill

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Jun 2007 16:43:54 +0000

> I think a better way of describing it is "administrative domain". ...

in addition to bmanning's worthy comments, let me say that this redescription

> > hopefully the regress isn't infinite.  care to take it a step and see?

call it a site, call it an administrative domain, call it anything you want.
but explain to me please the relationship between the allocation domain and
the routing domain.  if the network part (allocation domain) is universal,
but the routing domain is not universal, then i need to know what routing
domain you're expecting.  i can advertise my ULA-C to my next door neighbor
but not my across the street neighbor?  i can advertise it to whomever i want
but it will mysteriously not work beyond an unpredictable perimeter?  my city
utility fiber/wireless network hears me but only half of the other residents
hear me?  all local residents hear me but my city's "provider" does not?  my
city's provider hears me but half of their other customers filter me?

if we're going to expect routability to provide connectivity in some cases
but not all, which is what's implied by saying "never appear off-site", then
we need to know what cases and exactly what noncases.  so what's a "site"?
or what's an "administrative domain"?  or call it what you want -- what is it
and how do the routing domain, connectivity domain, and the allocation domain
relate to each other?

if i seem anxious to cut to the chase it's because i've read all this before
when "site local" was first proposed and then later, again, when it was
deprecated.  so let's keep our feet on the ground and define our terms and
make sure we have common understanding before anybody runs out ahead.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Jun 2007 11:19:48 -0700

Paul,

My understanding is that when two sites agree to form a
peering arrangement and are joined, e.g., by a VPN link,
then they should be able to advertise their ULA-C's for
use within the scope of their now-linked sites. So, it's
not about a site freely redistributing its ULA routes
into any other arbitrary site; there should be an explicit
peering arrangement first.

Fred

> Sent: Tuesday, June 12, 2007 9:44 AM
> To: IETF IPv6 Mailing List
> > > of space and of time, there might be general agreement on 
> this point, or
> > > not.
> > >

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 12 Jun 2007 14:57:59 -0400

> and how do the routing domain, connectivity domain, and the 

I think the answers to these questions are exactly the same as they
would be for IPv4 private address blocks, although it's more imperative
in the case of IPv4 that they be non-routable outside whatever
boundaries one sets. So then ...

> make sure we have common understanding before anybody runs out ahead.

Does anyone have an answer to this? Site local were deprecated because
the consensus was that there's no need for "private" addresses in IPv6.
Are these ULA-Cs simply taking their place?

Should routers not forward ULAs under any circumstance?

Bert

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Jun 2007 19:19:52 +0000

in response to this prompt:

Paul Vixie <[email-masked]> wrote:
> > but not all, which is what's implied by saying "never appear off-site",
> > then we need to know what cases and exactly what noncases.  so what's a
> > "site"?  or what's an "administrative domain"?  or call it what you want
> > -- what is it and how do the routing domain, connectivity domain, and the
> > allocation domain relate to each other?

so far, there've been two answers, coincidentally both from boeing.com.

"Templin, Fred L" <[email-masked]> wrote:
> My understanding is that when two sites agree to form a peering arrangement
> and are joined, e.g., by a VPN link, then they should be able to advertise
> their ULA-C's for use within the scope of their now-linked sites.  So, it's
> not about a site freely redistributing its ULA routes into any other
> arbitrary site; there should be an explicit peering arrangement first.

i understand about peering and i would like to agree but i don't.  perhaps i
know too much about peering.  when networks A and B are peers, and network C
is a customer of network B, then A and C will use B for "transit".  there is
no reasonable expectation that ULA-C could be, would be, or should be exempt
from that treatment.  furthermore, if C is B's customer for DFZ reachability,
then C will be able to reach A's ULA-C routes through B's default route, and
will not be able to tell the difference between distant ULA networks and
distant non-ULA networks.  this is one of the reasons i consider the thus-far
definitions of "site" to be so useless: "does not encounter reality well."

"Manfredi, Albert E" <[email-masked]> wrote:
> I think the answers to these questions are exactly the same as they would be
> for IPv4 private address blocks, although it's more imperative in the case
> of IPv4 that they be non-routable outside whatever boundaries one sets. So
> then ...

"more imperative" is a hard tool to operate.  who shouldn't route these, why,
and how will we stop them, and what bad things happen if we can't stop them?

> > if i seem anxious to cut to the chase it's because i've read all this
> > before when "site local" was first proposed and then later, again, when it
> > was deprecated.  so let's keep our feet on the ground and define our terms
> > and make sure we have common understanding before anybody runs out ahead.
> 

site-local was deprecated because nobody could agree what a "site" was, which
in other words means it's down under the same swamp we are now waist deep in.

> Should routers not forward ULAs under any circumstance?

that would be a fine, clean design.  perhaps if it were a hard requirement,
then the "IPv6 Ready" folks would deny the use of the logo to anyone who
leaked packets or routes in this address space, or who provided any kind of
command level override.  make it "nonrouteable" even among two LANs run by
the same sysadmin.  if you want those LANs to talk, then bridge 'em, don't
route 'em.  (but in that case we'd be using link-local, right?)  (what'll we
do if some open source geeks publish free software without a logo on it?)
(and if we don't think these addresses or routes to them could leak, then why
are we asking that they be unique?)

so my previous question stands.  what's a "site"?

---

From: David Conrad <[email-masked]>
Date: Tue, 12 Jun 2007 12:20:54 -0700

On Jun 12, 2007, at 11:57 AM, Manfredi, Albert E wrote:
>> if i seem anxious to cut to the chase it's because i've read
>> all this before when "site local" was first proposed and then  
>> later, again,
>> when it was deprecated.  so let's keep our feet on the ground and  
>> define
>> our terms and make sure we have common understanding before  
>> anybody runs out ahead.
>

I thought "Site Locals" were deprecated because people couldn't agree  
on what a "site" was.

> Are these ULA-Cs simply taking their place?

That's my impression, but then again, I haven't see the revised ULA-C  
draft.

> Should routers not forward ULAs under any circumstance?

Wouldn't that make them "link locals"?

Rgds,
-drc

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 12 Jun 2007 15:36:42 -0400

> in other words means it's down under the same swamp we are 

Okay, I'll gladly agree on both points.

> so my previous question stands.  what's a "site"?

My not-well-articulated point was: if everyone seems to have made RFC
1918 work quite well, why do we need to get overly precise in this time
around?

As far as my own preferences go, I liked site-local and I equally like
mind ULA-Cs with some flexibility. Even though I have no fool-proof
definition for what a "site" is, that covers all possible examples. I've
no trouble at all establishing boundaries for private IPv4 addresses or
for ULA-Cs, when it makes sense for whatever I'm doing.

Is this a little like the RH0 thread? When it was a choice of disabling
by default or removing entirely? My vote is, don't forward ULA-Cs by
default, but let us use them as we used RFC 1918. It was also my vote
when we were discussing site-local.

If we get more restrictive about ULA-Cs, my bet is that something else
will morph to take their place (and the place of site-local addresses).
I guess people just like to have this tool.

Bert

---

From: "Durand, Alain" <[email-masked]>
Date: Tue, 12 Jun 2007 15:42:50 -0400

> From: David Conrad [mailto:[email-masked]] 
> I thought "Site Locals" were deprecated because people 
> couldn't agree on what a "site" was.
> 
> That's my impression, but then again, I haven't see the 
> revised ULA-C draft.

Site local were deprecated because they were re-creating overlapping
address space a la RFC1918. This was considered a bad property
for multi-party applications that couldn't tell if they could
forward them as reference or not.

Some people believed that some kind of 'private addresses' were still
needed and thus needed something to replace site local. They invented
ULA. ULA fixed the (overlapping) addressing issue but did not fix the
routability
issue as has now been demonstrated in multiple post. We are essentially
back to where we were a couple years ago, this time not at the
application
level but at the router level, it is hard to know if those
(local/private)
addresses should be passed to the next hop or not.

I'm of the opinion that the added operational complexity to define sites
and partial inter-site routing overcome the benefit of ULA
especially when PI space is available from RIRs and accomplish
the same thing at no extra cost.

However, I do respect people who have a different opinion and
once again I repeat my call/plea for an open meeting of the IPv6 wg
at next IETF to articulate those issue and decide if the wg should
or not continue on the path of defining those ULA-c despite
the (very) negative feedback from the operational community.

    - Alain.

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 12 Jun 2007 20:47:29 +0100

Manfredi, Albert E wrote:
[..]
> I guess people just like to have this tool.

The "ULA-C tool" already exists: IPv6 PI space from the RIRs.

That satisfies all the needs they can ever have and can even provide
them with reverse DNS without having to do split-dns, though split dns
is most likely already required, how else do you keep certain prefixes
"local"/"internal".

People, like home users or totally disconnected networks that will never
ever ever ever connect to the Internet can use ULA (rfc4193) space that
is auto generated.

Except for the 'you can easily filter on fc00::/8 from slipping onto the
internet' argument, I have not heared any compelling argument in favor
of ULA (except that some people do not want to pay the small fee for a
PI prefix).

People in various operational forums have also raised considerate
arguments against ULA-C and they are expecting people to want to
announce blocks they "own" (and most likely see as property) onto the
Internet. PI exists for that, so lets keep it at one swamp please.

Greets,
 Jeroen

---

From: "Durand, Alain" <[email-masked]>
Date: Tue, 12 Jun 2007 15:49:43 -0400

> From: Manfredi, Albert E [mailto:[email-masked]] 

> 1918 work quite well, why do we need to get overly precise in 
> this time around?

I happen to work for a network that has to deal on a very regular basis
with the nightmare of overlapping RFC1918 space, so I do not share
your opinion that "everyone seems to have made RFC1918 work quite well".

   - Alain.

---

From: Roger Jorgensen <[email-masked]>
Date: Tue, 12 Jun 2007 22:19:38 +0200 (CEST)

On Tue, 12 Jun 2007, Manfredi, Albert E wrote:
<snip>
> when we were discussing site-local.

Why are we even talking about ULA-C now? What you want is nicely covered 
by ULA... not ULA-C but regular plain stright forward ULA.

-- 

------------------------------
Roger Jorgensen              | - ROJO9-RIPE  - RJ85P-NORID
[email-masked]           | - IPv6 is The Key!
-------------------------------------------------------

---

From: Roger Jorgensen <[email-masked]>
Date: Tue, 12 Jun 2007 22:25:46 +0200 (CEST)

On Tue, 12 Jun 2007, Durand, Alain wrote:
<snip>
> the same thing at no extra cost.

... and then, what is the point with ULA-C? Regular ULA are free for 
everyone to use. And for those that need unique address space you have 
"PI"... or UA, Unique Address, as Paul Vixie explained in another post in 
a RIPE mailinglist.

> the (very) negative feedback from the operational community.

Forget ULA-C... If we are moving forward with "PI" as explained elsewhere 
worldwide, we have no use for ULA-C.

--

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 12 Jun 2007 16:28:39 -0400

> From: Roger Jorgensen [mailto:[email-masked]]

> by ULA... not ULA-C but regular plain stright forward ULA.

Largely, but not completely. Think in terms of large platforms that have
several different networks, administered by different entities, but
easily isolated from The Internet or even a larger intranet. ULA-Cs are
convenient to route within the platform, with the knowledge that they
can easily be filtered at edge routers because they are easy to spot.

Just like before, with site-local addresses, I'm sure this can be worked
around, no matter what the decision is. Having to go to a RIR and ask
for PIs is a possibility, although what's nice about ULA-Cs is exactly
that you don't have to go to ask anything of anyone!

I suppose it all depends on one's perspective.

Bert

---

From: Roger Jorgensen <[email-masked]>
Date: Tue, 12 Jun 2007 22:31:26 +0200 (CEST)

> your opinion that "everyone seems to have made RFC1918 work quite well".

I work on a quite similar network and we have the same issues. And I've 
concluded that ULA-C would work great at our place, IF, please note that 
BIG IF there, if we get reverse DNS. Without that, it is useless for us 
and we might just aswell go with regular "PA" address-space.

... again, the "PI" option will work much better than anything ULA-C 
can ever come up with.

--

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Jun 2007 13:34:32 -0700

Paul, 
 
> so far, there've been two answers, coincidentally both from 

Please do not read too much into this. I respect the other
poster's opinions but, as for multiple posters from other
organizations, we are both bringing our own individual
opinions to this that do not necessarily reflect a corporate
position.

Thanks - Fred

---

From: Roger Jorgensen <[email-masked]>
Date: Tue, 12 Jun 2007 22:34:49 +0200 (CEST)

> can easily be filtered at edge routers because they are easy to spot.

that is a good description of the network where I work and as I said in my 
last post, ULA-C would work great IF we had reverse DNS...

> that you don't have to go to ask anything of anyone!

we need some sort of semi-official, semi-accepted as official registry 
runned by someone like the SIXXS registry Jeroen have put up... IF we make 
people "belive" they have to register there, and that site also generate 
ULA prefixes... isn't that ULA-C in a semi-official way?

I'm more and more convince that ULA-C will be a great big hack that will 
hunt us forever... sad.

--

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Jun 2007 20:45:16 +0000

> BIG IF there, if we get reverse DNS. Without that, it is useless for us and
> we might just aswell go with regular "PA" address-space.

so is it the case that the long-dead proposal to add an icmp message type
for "tell me your hostname" would be quite useful in this application?

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Jun 2007 13:48:12 -0700

> for "tell me your hostname" would be quite useful in this application?

RFC4620?

Fred

---

From: Roger Jorgensen <[email-masked]>
Date: Tue, 12 Jun 2007 22:48:52 +0200 (CEST)

> for "tell me your hostname" would be quite useful in this application?

never heard about.

--

---

From: "TJ" <[email-masked]>
Date: Tue, 12 Jun 2007 17:06:38 -0400

... My $.02 or so, inline ... 

>Sent: Tuesday, June 12, 2007 14:58
>To: Paul Vixie; IETF IPv6 Mailing List
>> if we're going to expect routability to provide connectivity in some
>> cases but not all, which is what's implied by saying "never appear
>> off-site", then we need to know what cases and exactly what noncases.
>> so what's a "site"?
>> or what's an "administrative domain"?  or call it what you want --
>> what is it and how do the routing domain, connectivity domain, and the

Exactly right.  It is meant to be a private address space, to be routed /
routable as private address space should be - specifically NOT on the public
internet.

>> before when "site local" was first proposed and then later, again,
>> define our terms and make sure we have common understanding before
>> anybody runs out ahead.
>

My understanding is that Site Locals were deprecated not because private
address space is bad in and of itself, but rather - the human element of
lazy allocation (start low & count up) inevitably leads to addressing
conflicts and, golly, can't we be smarter this time around?

>Should routers not forward ULAs under any circumstance?

Routers, meaning any routers?  Of course they should - the whole point is to
have private IPs that are routable (unlike link-local addresses).
Routers, meaning out in the DFZ - of course not, this is private address
space.  (Except maybe to black-hole them ,that is)

/TJ

---

From: "TJ" <[email-masked]>
Date: Tue, 12 Jun 2007 17:11:36 -0400

... 

>Sent: Tuesday, June 12, 2007 16:29
>To: Roger Jorgensen
>Cc: IETF IPv6 Mailing List
>> Why are we even talking about ULA-C now? What you want is nicely
>> covered by ULA... not ULA-C but regular plain stright forward ULA.
>

And filtering on the normal ULA prefix (or ULA-D, if you will) of FD00::/8
is not easy?
The advantage in ULA-C is the guarantee of global uniqueness, without
"burning" a PI allocation.

>that you don't have to go to ask anything of anyone!

Isn't the whole point of ULA-C that you do, in fact, need to ask someone?

/TJ

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Jun 2007 07:06:59 +0930

On Tue, 12 Jun 2007 06:59:11 -0700

> 	thats not what the RFCs or current practice dictate.

Can you then give me a different term to describe my service provider
employer's corporate customers networks and residential networks I
don't have any administrative role or control over, yet are part of my
service provider employer's ASN ?

If your context is the global Internet, then yes, I can see that it
could be said that these downstream customers fall within our
adminisrative domain, from the perspective of other ASN members of the
Internet. However, when the context isn't the global Internet, and ULAs
are not global addresses, then I don't think you can accurately say
administrative domain = ASN.

Obviously context is everything. In this case, I think ULAs are a more
general context than the specific Internet. A user of a ULA/ULA-C might
never have an Internet connection, so will never need global prefixes
or a global ASN. They'd still have an administrative domain,
encompassing all the devices they administer, to apply that ULA/ULA-C
prefixes to.

Regards,
Mark.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 12 Jun 2007 14:48:57 -0700

> so my previous question stands.  what's a "site"?

Paraphrasing from the 'draft-templin-autoconf-dhcp' definition
for "Mobile Ad-hoc Network (MANET)":

   site
      a connected network region that comprises routers that
      maintain a routing structure among themselves.  A site
      may be as large as an Autonomous System (AS) or as small
      as an individual router, and may also be a subnetwork of a
      larger site.  A router (and its downstream-attached links)
      is a "site" unto itself, and a site can therefore also be
      considered a "site-of-sites".

(Note that the only distinction drawn between "site" and
"MANET" is that some MANETs are less mobile and ad-hoc
than others - and, we would simply call those: "sites".)

Fred

---

From: Paul Vixie <[email-masked]>
Date: Tue, 12 Jun 2007 21:53:51 +0000

> ...  It is meant to be a private address space, to be routed / routable as
> private address space should be - specifically NOT on the public internet.

what we mean it to be routed to is less important than what people who use it
will actually route it to.  let's focus for now on examples involving many
networks run by folks with diverse goals.  any time you propose a rule like
"not meant to be XYZ" you have to be able to say how that rule will get
enforced, and what the internet will look like if enforcement doesn't happen.

> ... and, golly, can't we be smarter this time around?

so far, not.

> have private IPs that are routable (unlike link-local addresses).

that's another voice heard from.

> space.  (Except maybe to black-hole them ,that is)

is the dfz the only place these routes shouldn't go?  how will this be
enforced, if cooperating connectees to the dfz all want to do it anyway?

if we can't agree on "what's a site" then can we ask "what's ``private''" ?

---

From: Mark Smith <[email-masked]>
Date: Wed, 13 Jun 2007 07:31:42 +0930

On Tue, 12 Jun 2007 15:36:42 -0400

> 1918 work quite well, why do we need to get overly precise in this time

RFC1918 doesn't work well at all because it creates
overlapping / duplicated addressing, and NAT, with all it's worts, is
the only way, other than renumbering, to overcome that if you need to
interconnect. It's as ugly as sin to see multiple NAT boxes facing each
other when you have 2 (or more ! - and this happens at corporate DMZs
when building "extranets" to other corporates) duplicate RFC1918
addressing domains that have to be interconnected.

RFC3879, "Deprecating Site Local Addresses" describes the reasons why
site-locals were deprecated, but all those reasons are fundamentally
problems that have and do occur with RFC1918 addressing in IPv4. At
least with IPv6 we have a chance to avoid them. Having had to deal
directly with some of those reasons myself when working with IPv4, I
certainly don't want to go there again in IPv6 if possible.

> for ULA-Cs, when it makes sense for whatever I'm doing.

I agree. I don't think it is that hard to decide on the boundry. I
think fundamentally the thing that is trying to be avoided is that ULAs
become considered "cheap" or "free" PI addressing, and then having
their reachabilty scope slowly increase overtime e.g. initially your
own network, then the networks you directly peer with, then the local city or
other continent etc.

Regards,
Mark.

---

From: "Bernie Volz \(volz\)" <[email-masked]>
Date: Tue, 12 Jun 2007 19:10:44 -0400

Doesn't RFC 4193 already define "site" in a way that is clear for ULAs:

3.3.  Scope Definition

   By default, the scope of these addresses is global.  That is, they
   are not limited by ambiguity like the site-local addresses defined in
   [ADDARCH].  Rather, these prefixes are globally unique, and as such,
   their applicability is greater than site-local addresses.  Their
   limitation is in the routability of the prefixes, which is limited to
   a site and any explicit routing agreements with other sites to
   propagate them (also see Section 4.1).  Also, unlike site-locals, a
   site may have more than one of these prefixes and use them at the
   same time.

A site (or site-of-sites to use the MANET terminology) is defined by the
routability of a particular ULA prefix.

- Bernie 

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Tuesday, June 12, 2007 5:49 PM
To: Paul Vixie; IETF IPv6 Mailing List
Subject: RE: Revising Centrally Assigned ULA draft 

   site

Fred

---

From: Bob Hinden <[email-masked]>
Date: Tue, 12 Jun 2007 16:46:49 -0700

> Are these ULA-Cs simply taking their place?

No, that's not correct.  It had more do with their non-unique  
properties and the notion of a unicast site scope.  This is  
documented in

   RFC3879 "Deprecating Site Local Addresses"

> Should routers not forward ULAs under any circumstance?

Also not correct.  Specific ULAs (/48) are fine to forward inside of  
a site, but the ULA prefix (/7) should be filtered by default at the  
site border.  See Section 4. Operational Guidelines in:

   RFC4193 "Unique Local IPv6 Unicast Addresses"

Bob

p.s. This discussion would be a lot more rational if folks would  
spend some time and reread these documents.  We hope to get the new  
central ULA draft out soon.  One of the authors was traveling and we  
are waiting to get his comments on the text before submitting.

Also, I personally find it pretty odd to see a debate on a document  
before it is published.

---

From: "TJ" <[email-masked]>
Date: Tue, 12 Jun 2007 22:28:59 -0400

Couple more thoughts ...

>Sent: Tuesday, June 12, 2007 17:54
>To: 'IETF IPv6 Mailing List'
>> ...  It is meant to be a private address space, to be routed /
>> routable as private address space should be - specifically NOT on the
>public internet.
>
>what we mean it to be routed to is less important than what people who
>use it will actually route it to.  let's focus for now on examples
>involving many networks run by folks with diverse goals.  any time you
>propose a rule like "not meant to be XYZ" you have to be able to say how
>that rule will get enforced, and what the internet will look like if
>enforcement doesn't happen.

Fair enough, and certainly the world is full of lots of different people /
environments, all with diverse goals.  Some good, some bad - many subjective
:).
Is simply recommending that providers not accept reachability announcements
for ULAs, the same way it is recommended that they not accept RFC1918
announcements, not good enough (and for the same reasons)?

>> ... and, golly, can't we be smarter this time around?

I wouldn't be that negative; the fact that we are attempting to solve a
problem is a good sign, no?
(providing a method to accomplish a nearly-collision-free private address
space ... which (to me) seems to be a noticeable improvement.)

>> Routers, meaning any routers?  Of course they should - the whole point
>> is to have private IPs that are routable (unlike link-local
>addresses).
>

I think I am merely passing along the sentiment of the authors of the RFC,
albeit poorly paraphrased.
To quote:
	Abstract
		   This document defines an IPv6 unicast address format that
is globally
		   unique and is intended for local communications, usually
inside of a
		   site.  These addresses are not expected to be routable on
the global
		   Internet.
That says, to me anyway, that they are to be routable - but not globally
routable.

>> Routers, meaning out in the DFZ - of course not, this is private
>> address space.  (Except maybe to black-hole them ,that is)
>

I am not fully sure we need to define "site".  Even in the abstract above
(wherein it mentions "site") the meat of the statement seems to focus on the
"private" aspect, which I believe we have recommendations and policies in
place to manage (again, a la RFC1918).
	Does everyone follow them, no.  
	Are they perfect, no.  
	Do we have enough policy, and experience with that policy, to move
forward - I would think so. 
	... ?

Again - just MHO.
/TJ

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 Jun 2007 21:23:44 +0000

>       considered a "site-of-sites".

by this, any connected network region comprising routers that maintain routing
structure among themselves, up to the size of an autonomous system but perhaps
as small as a single router, is a "site".  nothing is said (here) about what
else these routers might be attached to, so i assume that there can be
connectivity to other sites or to the dfz but that it's not required.  i take
the term "downstream" to mean "toward less connected sites", which would be
meaningless if all sites were equally well connected (either to each other or
to the dfz) but that's not a problem.

this is a fine high level definition of "site", from what i can see, but i
have a question... what is the difference between a site-of-sites made up of
autonomous system sized sites, vs. a site-of-sites made up of leaf sites?  if
a site can be considered a "site of sites", then the automotive exchange
network or the global internet could be shoehorned into fitting this
definition.  i don't think that's the intent, and so, where's the fine print?

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 Jun 2007 21:26:36 +0000

> routability of a particular ULA prefix.

from a process point of view that would be circular, since we're hoping
to use the meaning of "site" to help us define the proposed rules for ULA.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 13 Jun 2007 14:34:06 -0700

Paul,

I appreciate the feedback, and I'll take it under serious
consideration for my MANET/Autoconf draft. But, I'm not
sure anymore that we need to sweat the details of exactly
what is a site within the context of these discussions.

Someone pointed out that ([RFC4193], Section 4) provides
operational guidelines, and I think the same guidelines
would be true for ULA-Cs as they are for ULAs?

Thanks - Fred

> Sent: Wednesday, June 13, 2007 2:24 PM

---

From: Paul Vixie <[email-masked]>
Date: Wed, 13 Jun 2007 21:43:51 +0000

> would be true for ULA-Cs as they are for ULAs?

when there's a draft for ula-c, we'll know.  it's been described here as
"ula but with working in-addr.arpa lookups", and as long as the domain of
"lookups have to work within" is the same as the domain as "can reach ipv6
addresses within" then it may not make much difference whether the words
"local" or "site" are used, or if used, what they're made to mean.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jun 2007 11:21:04 +0200

> by ULA... not ULA-C but regular plain stright forward ULA.

Exactly. If you want some private address space that no ISP will route,
but which you may care to use in your own network or with your
business partners via VPNs, get yourself a ULA, which is self-service.
And do what you need to do in your internal DNS; it will never appear
in the global DNS. (And don't rely on reverse DNS for your internal
operations, but that's a really silly thing to do anyway.)

The *only* possible argument for centrally allocated ULAs is for those
who believe that the birthday paradox in a 2^40 address space causes
a real danger of colliding with another business partner's ULA prefix.
As I've said, we can easily have a robot to take care of that (in fact,
the prototype is up and running, thanks Jeroen).

There seems to be a lot of confusion in part of this discussion. If
a ULA prefix does escape from its intended scope, it will be *exactly*
like any other non-aggregatable prefix that escapes. ULAs don't add to, or
remove from, the difficulties of dealing with non-aggregatable prefixes.

As for what is a site for ULA purposes: it's whatever network(s) decide
to use and route a given ULA prefix. Its boundary is a set of routers
that don't route that prefix further outwards.

     Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Jun 2007 11:30:14 +0200

Operators have said that they will not be able to use ULA, but they could
use ULA-C, for example for thinks like microallocations for internal
infrastructure's.

I think the policy proposal that I sent to several regions includes text and
links to other documents that can clarify this perspective.

For example in RIPE NCC:
http://www.ripe.net/ripe/policies/proposals/2007-05.html

Regards,
Jordi

> De: Brian E Carpenter <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Thu, 14 Jun 2007 11:21:04 +0200
> Para: Roger Jorgensen <[email-masked]>
> CC: IETF IPv6 Mailing List <[email-masked]>
> Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned ULA
> draft
> 

**********************************************
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: Thu, 14 Jun 2007 11:42:20 +0200

> use ULA-C, for example for thinks like microallocations for internal

Since there is no practical difference between ULA and ULA-C, they
need to explain...

The argument about private addresses at the end of
http://www.arin.net/policy/proposals/2006_2.html
makes no sense. ULA and ULA-C are both private addresses.

     Brian

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Thu, 14 Jun 2007 11:56:44 +0200

Just avoiding ANY collision risk. VERY VERY VERY LOW is not enough for them.

Regards,
Jordi

> Responder a: <[email-masked]>
> Fecha: Thu, 14 Jun 2007 11:42:20 +0200
> Para: <[email-masked]>
> CC: <[email-masked]>
> Asunto: Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally Assigned
> ULA draft
> 
>> 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.
>> 
>> 
>> 
>> 

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

---

From: Jeroen Massar <[email-masked]>
Date: Thu, 14 Jun 2007 11:00:11 +0100

[cc'ing RIPE address policy + ARIN PPML where the discussion on this
happened, I have not seen any 'operators' who have said the below, if
there are they are there and can thus raise their voices because they
will see this message; removed the silly spam scoring subject...]

> use ULA-C, for example for thinks like microallocations for internal

I really wonder where you got that idea, as I know of no such operator
who would ever say that. If there are any, let them bring up their
argumentation, please don't come up with "somebody said that" it does
not work that way.

Real network operators, especially involved in the RIPE or other RIR's,
have more than enough address space from their PA allocations that they
can easily receive and they very well know how to use a /48 from that
for internal infrastructure as everybody does this. The IPv6 PA policies
even describe that a /48 can be used per POP of the owner of the PA block.

Also in the ARIN region any organization can get a /48 PI block for
about $100/year, as such these organizations won't be needing this
address space either as they can easily take a /64 out of that for those
needs. Firewalling is the key here.

> http://www.ripe.net/ripe/policies/proposals/2007-05.html

That is your proposal indeed. No "Operator" has stood behind this and
various people from various organizations have clearly asked you and the
RIPE NCC to *freeze* this proposal till at least the IETF has worked out.

Anybody needing a "globally unique" block can get either PA or PI space.
ULA-C as such is useless.

Greets,
 Jeroen

---

From: Roger Jorgensen <[email-masked]>
Date: Thu, 14 Jun 2007 12:32:18 +0200 (CEST)

On Thu, 14 Jun 2007, Jeroen Massar wrote:
<snip>
>> use ULA-C, for example for thinks like microallocations for internal

what operators? I cant remember to have seen one operator supporting that 
point of view. My point of view from a LIR/network point of view etc was 
that ULA-C could be usefull but without reverse DNS it is useless. Maybe 
even with reverse DNS we want todo it the correct way by using our 
netblock we got from RIPE.

--

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 14 Jun 2007 12:35:06 +0200

> Just avoiding ANY collision risk. VERY VERY VERY LOW is not enough for them.

Fine. Then Jeroen's robot is necessary and sufficient.

    Brian

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Thu, 14 Jun 2007 11:24:22 -0400

> the prototype is up and running, thanks Jeroen).

Here is a quote from an expirted I-D:

http://tools.ietf.org/html/draft-ietf-ipv6-ula-central-01

   The major difference between the locally assigned Unique local
   addresses defined in [ULA] and the centrally assigned local addresses
   defined in this document is that they are uniquely assigned and the
   assignments can be escrowed to resolve any disputes regarding
   duplicate assignments.

   It is expected that large managed sites will prefer central
   assignments and small or disconnected sites will prefer local
   assignments.  It is recommended that sites planning to use Local IPv6
   addresses for extensive inter-site communication, initially or as a
   future possibility, use a centrally assigned prefix as there is no
   possibility of assignment conflicts.  Sites are free to choose either
   approach

The second paragraph is what I'd be most interested in. Not for the
reason cited, but because if I want to configure multiple "sites"
exactly the same, that would seem to be the most direct approach.

I suppose I could also do the standard ULA for one site, then copy those
addresses in the others. Isn't that exactly the same as centrally
administered ULAs?

Bert

---

From: james woodyatt <[email-masked]>
Date: Thu, 14 Jun 2007 11:09:33 -0700

> Just avoiding ANY collision risk. VERY VERY VERY LOW is not enough  

My attitude is that IETF should tell them that's THEIR problem, not  
OURS.  Has the operator community explained why the odds of a  
collision in a 2^40 address space pose an unacceptable risk to them,  
which they can't mitigate without the participation of an Internet  
Society organization?

---

From: Joe Abley <[email-masked]>
Date: Fri, 15 Jun 2007 07:41:53 -0400

On 14-Jun-2007, at 14:09, james woodyatt wrote:

> collision in a 2^40 address space pose an unacceptable risk to  
> them, which they can't mitigate without the participation of an  
> Internet Society organization?

If you're an operator, providing IPv6 access and presumably globally- 
unique, globally-reachable address space to customers, why is it  
necessary to use private address space to number your infrastructure?  
You already have PI address space. Isn't it easier just to assign  
some of that space for internal use (as the harmonised bits of the  
RIR IPv6 allocation policy allows, I think) than to bother with ULA?

With IPv4, motivations of cost/scarcity might induce ISPs to use RFC  
1918 addresses to number interfaces which don't require global  
reachability. Those motivations surely don't exist with IPv6.

Perhaps by "operator" you meant something other than "ISP", Jordi?

Joe

---

From: "TJ" <[email-masked]>
Date: Fri, 15 Jun 2007 08:05:57 -0400

>From: james woodyatt [mailto:[email-masked]]
>Sent: Thursday, June 14, 2007 14:10
>Subject: Re: [***SPAM*** Score/Req: 10.4/4.5] Re: Revising Centrally
>Assigned ULA draft
>
>OURS.  Has the operator community explained why the odds of a collision
>in a 2^40 address space pose an unacceptable risk to them, which they
>can't mitigate without the participation of an Internet Society
>organization?

If it "isn't our problem" then the original ULA RFC shouldn't have made the
provision at all.
They (correctly, IMHO) did make a provision for globally unique ULAs
(ULA-C), so actually making these usable / real is, in fact, "our problem".

/TJ ... still not fully understanding why all the confusion/debate is going
on about this (or, why it is happening now), and still just adding my ~$.02

---

From: Thomas Narten <[email-masked]>
Date: Fri, 15 Jun 2007 10:19:15 -0400

Jeroen Massar <[email-masked]> writes:

> > Operators have said that they will not be able to use ULA, but they cou=
> ld

> argumentation, please don't come up with "somebody said that" it does

Maybe the assertion came from those who supported ARIN Policy Proposal
2006-2: Micro-allocations for Internal Infrastructure
(http://www.arin.net/policy/proposals/2006_2.html), where using a /48
out of their aggregate did not solve the technical problem at hand.

At that time, the question was raised whether ULA-P solved the problem
adequately. The answer I heard was a very clear "no". And ULA-C (if
had existed then) would have.

Thomas

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 15 Jun 2007 15:14:43 +0000

If you doubt about folks stating anything, then you should read *before*
minutes of meetings. I'm now off-line in a plane, so can't point you to a
specific URL, but this has been said at least in one ARIN meeting.

It has been clear across all this discussion in several exploders, that
there are both opinions, people that want ULA-C and people that don't. What
you need to be smart here is to realize that those than don't want ULA-C
have no any objective reason to oppose to it, because implementing ULA-C has
no negative impact in others. While opposing to it has negative impact to
all: Folks will use global space (PA or PI) for doing the function of ULA-C
an this is a waste, yes a small waste but a waste.

It seems to me irresponsible and unbalanced to do or try things like
changing the HD-ratio or the default assignment size to end-sites because it
is a waste, and then oppose to those that want to have ULA-C, not impacting
in others and avoiding one further small saving in global unicast space.

I'm not trying to convince anyone about supporting ULA-C, because it seems
an impossible mission at least for a few, but at least, don't object to it
if having it doesn't force you in any further implications, which is the
case.

Regards,
Jordi

> De: Jeroen Massar <[email-masked]>
> Organización: Unfix
> Fecha: Thu, 14 Jun 2007 11:00:11 +0100
> CC: ARIN People Posting Mailing List <[email-masked]>, <[email-masked]>,
> "[email-masked]" <[email-masked]>
> Asunto: Re: Revising Centrally Assigned ULA draft
> 

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

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Fri, 15 Jun 2007 15:24:11 +0000

They need a trusted entity running the tool to void any clash chance, that's
one good reason for making it different than ULA.

Regards,
Jordi

> Asunto: [***SPAM*** Score/Req: 10.4/4.5] Re: [***SPAM*** Score/Req: 10.4/4.5]
> Re: Revising Centrally Assigned ULA draft
> 

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

---

From: Mark Smith <[email-masked]>
Date: Sat, 16 Jun 2007 08:19:11 +0930

On Fri, 15 Jun 2007 15:13:40 -0500
"Kevin Kargel" <[email-masked]> wrote:

> I agree wholeheartedly.  There is nothing you can do with ULA-C that you
> can't do with PI and a minor firewall rule or two.  Leaving the space as
> PI gives it either-or capability, putting it as ULA reduces PI.  (And
> don't talk about 'more PI than we could ever use'..  remember when Mr.
> Gates told us you would never need more than 640K of RAM?)(of course he
> denies it now..)
> 
>  

I understand that that was an IBM design decision - they chose to allow
384KB out of the 1MB of address space of the 8086/8088 for option ROMs
for add-in cards. That decision was made during the design of the
original IBM PC (i.e. the one before the XT), which originally came
with 16KB of RAM (and a audio cassette interface for storage, no serial
ports or printer ports, and a monochrome 4KB text adaptor). Allowing
384KB for option ROMs allowed for plenty of IO card expansion, because
the platform was initially very barebones, and 640KB was extremely
large amount of RAM at the time. The OS at the time didn't
provide device drivers, unlike today's OSes - the option ROMs was were
that functionality resided. When you look at that problem, at the time
it was addressed, the 640KB/384KB boundary seems, at least to me, to be
quite reasonable.

The IBM PC architecture was never expected to (a) set an industry
standard and (b) ever last as long as it has. Gates was unlikely to
have ever been consulted on it, or conversely, was only ever agreeing
with a decision that had already been made.

Don't use this (mis)quote as a lack of design foresight, use it as an
example of wildly unexpected success. IPv6 doesn't have the addressing
quantity constraints that IPv4 has, so allow for wildly different and
expanded uses of it and it's large address space. 

As a general example of how IPv6's "large" addressing
could be used, look at Ethernet. Nobody needs 2^47 unicast addresses on
a LAN segment. We "waste" millions of addresses everytime we enable a
new LAN segment. The Ethernet address space we "waste" when a point to
point ethernet link is brought up is the most "obscene" amount of
address space "waste" I've ever seen in my life - because a
point-to-point link doesn't even need addressing - the frame is either
for this end or the other end.

So what has all that "wasted" Ethernet address space got us ? _Convenience_

It is convenient that we can plug an Ethernet card in and not have to
worry about configuring addresses or addressing collisions.
Non-technical people can buy a network card at the local
electrical store, plug it into their computer, and the ethernet
functionality work (installing device drivers is obviously not a
problem that ethernet attemps to solve). It's the original
"plug-and-play".

With Ethernet, we get a lot of convenience at the cheap price of 32 or
so bits of "wasted" address space (on the rough assumption that nobody
would ever build an ethernet segment with more than 65K nodes), or 64
bits in each packet.

Here's what the people who chose 48 bit addressing for Ethernet said
about the decision :

"48-bit host numbers lead to large Ethernet and internet packets. We
believe that this will not pose a problem as both local and public data
networks continue to offer higher bandwidths at reasonable costs, and
the memory and logic costs associated with storing and processing these
numbers continue to become lower with the advances in LSI technology."
("48-bit Absolute Internet and Ethernet Host Numbers", Yogan K. Dalal
and Robert S. Printis - definately worth a read)

When did they say it ? 1981! 26 years ago!

The problem with applying an IPv4 mentality to an IPv6 addressing
problem is that IPv4 hasn't been an abundant resource for 15 or so
years. We've had to give up operational convenience with it because we
needed to ensure functionality as the Internet grew. When it came to
the crunch, convenience had to be sacrificed.

IPv6 address space is abundant, so we can now go back to placing value on
operational convenience. All we need to do is ensure there isn't any
reckless use of IPv6's address space.

So, getting back to the ULA topic :

If (non-globally routed) PI is the answer to the ULA-C question, is
there going to be enough (non-globally routed) PI so that I can get a
(non-globally routed) PI allocation for my home, at a small charge for
the guaranteed uniqueness e.g. US$10 per annum ? How about my Personal
Area Network that interconnects my mobile phone, portable music player
and pedometer in my shoes. Will there be enough (non-globally routed)
PI that everybody on the planet who might end up having that sort of
PAN can get a (non-globally routed) PI address allocation, should they
want one ? How about if they want separate allocations for both their
PAN and their home network.

If the answer is no, then (non-globally routed) PI it isn't solving the
ULA/ULA-C problem.

> > From: [email-masked] [mailto:[email-masked]] On 
> > Behalf Of Owen DeLong
> > Sent: Friday, June 15, 2007 2:41 PM
> > To: [email-masked]
> > Cc: ARIN People Posting Mailing List; [email-masked]; 
> > [email-masked]
> > Subject: Re: [ppml] Revising Centrally Assigned ULA draft
> > 
> > 
> > On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote:
> > 
> > > minutes of meetings. I'm now off-line in a plane, so can't 
> > point you 
> > > to a specific URL, but this has been said at least in one ARIN 
> > > meeting.
> > >
> > > It has been clear across all this discussion in several exploders, 
> > > that there are both opinions, people that want ULA-C and 
> > people that 
> > > don't. What you need to be smart here is to realize that those than 
> > > don't want ULA-C have no any objective reason to oppose to 
> > it, because 
> > > implementing ULA-C has no negative impact in others. While 
> > opposing to 
> > > it has negative impact to
> > > all: Folks will use global space (PA or PI) for doing the 
> > function of 
> > > ULA-C an this is a waste, yes a small waste but a waste.
> > >
> > Jordi,
> > 	You have this backwards.  Using PI for the purposes of 
> > ULA-C is no waste at all.  Sectioning off a huge chunk of 
> > address space for ULA-C is the waste.
> > If it's all PI, then, it can seamlessly move between being 
> > unrouted or routed as the address-holder sees fit and as 
> > needs change.  If it is set aside as ULA, then, the address 
> > space is forever wasted and cannot (theoretically) be used as 
> > routable space, no matter how little of it is needed for ULA-C.
> > 
> > 	Those of us who oppose ULA-C have what we believe to be 
> > an objective position that it provides no additional benefit 
> > over PI space while simultaneously creating some unnecessary 
> > classification of addresses that makes their status in the 
> > routing table ill-defined at best.  In our opinion, this 
> > carries the potential for significant consequences globally.
> > 
> > 	Just because we do not agree with you does not mean 
> > that our concerns are not legitimate.
> > 
> > 	Do I think UUNET and others should be able to get 
> > secondary microallocations to solve the problem they 
> > presented? Absolutely.  Do I think that we need to set aside 
> > a /8, /12, /16, or whatever separate from the rest of PI 
> > space to do it? No.
> > We should just issue them a /48 or whatever it is they need 
> > from the general pool of available PI space and be done with 
> > it.  No waste at all.  No negative consequences to anyone.  
> > No ambiguous status as to where you can or can't route the 
> > addresses, etc.
> > 
> > Owen
> > 
> > _______________________________________________
> > This message sent to you through the ARIN Public Policy 
> > Mailing List ([email-masked]).
> > Manage your mailing list subscription at:
> > http://lists.arin.net/mailman/listinfo/ppml
> > 
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> ([email-masked]).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml

---

From: Owen DeLong <[email-masked]>
Date: Fri, 15 Jun 2007 12:40:52 -0700

On Jun 15, 2007, at 8:14 AM, JORDI PALET MARTINEZ wrote:

> that
Jordi,
	You have this backwards.  Using PI for the purposes of ULA-C is no  
waste
at all.  Sectioning off a huge chunk of address space for ULA-C is  
the waste.
If it's all PI, then, it can seamlessly move between being unrouted  
or routed as
the address-holder sees fit and as needs change.  If it is set aside  
as ULA, then,
the address space is forever wasted and cannot (theoretically) be  
used as
routable space, no matter how little of it is needed for ULA-C.

	Those of us who oppose ULA-C have what we believe to be an objective
position that it provides no additional benefit over PI space while  
simultaneously
creating some unnecessary classification of addresses that makes  
their status
in the routing table ill-defined at best.  In our opinion, this  
carries the potential
for significant consequences globally.

	Just because we do not agree with you does not mean that our concerns
are not legitimate.

	Do I think UUNET and others should be able to get secondary  
microallocations
to solve the problem they presented? Absolutely.  Do I think that we  
need to set
aside a /8, /12, /16, or whatever separate from the rest of PI space  
to do it? No.
We should just issue them a /48 or whatever it is they need from the  
general
pool of available PI space and be done with it.  No waste at all.  No  
negative
consequences to anyone.  No ambiguous status as to where you can or  
can't
route the addresses, etc.

Owen

---

From: Randy Bush <[email-masked]>
Date: Fri, 15 Jun 2007 12:58:12 -1000

> PAN and their home network.

these are rir policy and price issues.  they are not technical issues.
except for routability, which, as smb says, don't think you ain't gonna
want to connect it some day; you will.

randy

---

From: "Kevin Kargel" <[email-masked]>
Date: Fri, 15 Jun 2007 15:13:40 -0500

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 18 Jun 2007 09:42:35 +0200

Jordi, my point is that technically, this is trivial, if
the community concludes it's a good idea.  There is running
code. So no need for an administrative solution since a robot
can do it cheaper and better. But it isn't the IETF that
should decide who the operational community will trust
to run the robot.

The only real question is whether the 40 pseudo-random bits
are a feature or a bug. If they're a bug, stick to PI.

    Brian