Subject: Re: draft-ietf-ipv6-ula-central-02.txt

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 3 Jul 2007 15:23:28 -0500

Thus spake <[email-masked]>
>> BTW, this business of birthday paradox clashes has been beaten
>> on wrt to other random address assignment paradigms too; in
>> particular, CGAs. There, you have ~60 (?) bits for uniqueness
>> but it has still been implied that any non-zero probability
>> of collision is too great.
>
> In practical terms, zero probability is not to be found in this
> universe.  People who demand zero probability for anything need
> to be educated.  2^-40 probability is as close as you're going
> to get.  Really!

More importantly, the odds of human or technical error that causes a 
collision at a theoretical ULA-C registry is far, far higher than 2^-40. 
The only difference is that if there's a registry, the end-users have 
someone to sue when a collision happens.

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov 

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

---

From: james woodyatt <[email-masked]>
Date: Mon, 9 Jul 2007 11:53:08 -0700

On Jul 3, 2007, at 13:23, Stephen Sprunk wrote:
>
> The only difference is that if there's a registry, the end-users  
> have someone to sue when a collision happens.

This sounds like yet another reason to hate ULA-C.  Seriously.

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

---

From: Roger Jorgensen <[email-masked]>
Date: Tue, 10 Jul 2007 13:38:58 +0200 (CEST)

> This sounds like yet another reason to hate ULA-C.  Seriously.

must be you American (I assume you are) that are so afraid of someone 
being sued.I dont see that as a issue at all, we state a purpose and 
disclaimer and if someone are stupied enough to sue for collision, well 
they are darn stupid then. Sorry the language.

anyway if a collision happen, someone have really screwed up technical 
anyway and should be hung out for drying...

-- 

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

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Jul 2007 10:00:08 -0700

On Jul 10, 2007, at 04:38, Roger Jorgensen wrote:
> must be you American (I assume you are) that are so afraid of  
> someone being sued.I dont see that as a issue at all, we state a  
> purpose and disclaimer and if someone are stupied enough to sue for  
> collision, well they are darn stupid then. Sorry the language.
>
> anyway if a collision happen, someone have really screwed up  
> technical anyway and should be hung out for drying...

I'm sorry.  I'm just finding this whole debate rather surreal.

The purpose of ULA-C/G, as near as I can tell, is to mitigate the  
risk of an already vanishingly low probability collision-- with the  
consequence limited to forcing a network renumbering event, which is  
cheaper and easier with IPv6 than it already is with IPv4.

We expect nodes to be cycling through privacy addresses at a regular  
rate.  We expect them to have more than one address per interface,  
and often more than one interface.  We've already seen how to manage  
the problem of DNS and WHOIS and what-have-you with straight-up RFC  
4193 using synthetic records, but that doesn't seem to have attracted  
the interest of the ULA-C proponents.  Why not?

I'll take this opportunity to repeat myself: If a 1-in-2^40 chance of  
having to renumber a ULA network at every network merge event is  
totally unacceptable to you, then I have to wonder how you manage the  
risks associated with breathing the air in your office building.

And now, I'm seeing people suggest that having an opportunity to  
bring *litigation* against the ULA-C registry in the event of  
collision is supposed to be a *feature* and not a bug.  It makes me  
wonder if this is all some sort of elaborate prank.  Where's the  
hidden camera?  Nice one.  Very funny ha ha ha.  You can come out  
now.  I'm a good sport. No, really.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 10 Jul 2007 17:56:56 +0000

> From: james woodyatt <[email-masked]>
> 
> The purpose of ULA-C/G, as near as I can tell, is to mitigate the  risk of
> an already vanishingly low probability collision--  ...

nope.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 10 Jul 2007 14:22:36 -0500

Thus spake "Roger Jorgensen" <[email-masked]>
> someone being sued.  I dont see that as a issue at all,

You've apparently never been sued in an American court.  The central 
authority will go bankrupt defending themselves, win or lose.

> we state a purpose and disclaimer and if someone are
> stupied enough to sue for collision, well they are darn stupid
> then.

That won't work.  The claimed reason that ULA-L isn't good enough and that 
enterprises need ULA-C is because ULA-L provides no guarantee there'll never 
be a collision.  However, the odds of collision are higher with ULA-C.  That 
means these folks aren't interested in the odds of collision -- they're 
looking for someone to guarantee in writing that it won't happen.  Slap a 
disclaimer on it and they might as well just use ULA-L.

S

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Jul 2007 15:15:39 -0700

On Jul 10, 2007, at 10:56, Paul Vixie wrote:
> [I wrote:]
>> risk of

Hmmm.  I guess the alternative is that the purpose of ULA-C/G is to  
mitigate the risk of collision when merging on the order of hundreds  
of thousands of ULA networks in one routing realm... sort of like  
creating a "local DFZ" of a sort.

Forgive me, but that sounds even more surreal.  It's tough for me to  
imagine how a real organization doing that could fail to qualify for  
a PI allocation, or why such an organization would find it  
unacceptable to have to use a PI allocation without advertising it to  
the public DFZ.  Likewise, it's tough to imagine how an organization  
that doesn't qualify for a PI allocation could be merging enough ULA  
networks together that the risk of collision rises to a level of any  
real significance.

Okay.  Maybe the problem with PI allocations for this purpose is that  
organizations doing all this network merging, i.e. extraordinarily  
paranoid organizations, e.g. the Communist Party, want some kind of  
assurance from the operators of the public Internet that their  
hundreds of thousands of local networks aren't directly reachable  
from the public DFZ in the event a local NOC configures a border  
router improperly.  Obviously, ULA-C can do that better than PI.

Is that the big driving factor here?

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 10 Jul 2007 15:33:45 -0700

>> [james woodyatt]
>> [Paul Vixie]
> [james woodyatt]
> imagine how a real organization doing that could fail to qualify for a 
> PI allocation, or why such an organization would find it unacceptable 
> to have to use a PI allocation without advertising it to the public 
> DFZ.  Likewise, it's tough to imagine how an organization that doesn't 
> qualify for a PI allocation could be merging enough ULA networks 
> together that the risk of collision rises to a level of any real 
> significance.

Perhaps you haven't read or understood what I've written previously.  
The purpose of ULA-G is to allow RIRs to allocate private address space 
in a non-discriminatory manner to organizations who wish to use it 
outside of the DFZ. 

As stated previously, the rules for getting PI space are based on the 
expectation that PI blocks can be announced into the DFZ.  The proposed 
rules for ULA-G space are based on the expectation that ULA-G blocks 
will not be announced into the DFZ, and that they will be allocated out 
of a single global netblock, identified in an RFC, that everyone knows 
can and should be filtered.  As stated quite clearly by Joe Abley in the 
"Why ULA-* will not harm the DFZ" thread, that difference in 
expectation, and ease in filtering when desired or necessary, makes it 
possible to give out ULA-G space in a non-discriminatory manner (which 
is simply not prudent for PI space today).

-Scott

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Jul 2007 17:07:38 -0700

On Jul 10, 2007, at 15:33, Scott Leibrand wrote:
>
> [...]
> As stated previously, the rules for getting PI space are based on  
> the expectation that PI blocks can be announced into the DFZ.  The  
> proposed rules for ULA-G space are based on the expectation that  
> ULA-G blocks will not be announced into the DFZ, and that they will  
> be allocated out of a single global netblock, identified in an RFC,  
> that everyone knows can and should be filtered.  As stated quite  
> clearly by Joe Abley in the "Why ULA-* will not harm the DFZ"  
> thread, that difference in expectation, and ease in filtering when  
> desired or necessary, makes it possible to give out ULA-G space in  
> a non-discriminatory manner (which is simply not prudent for PI  
> space today).

Look, if we want to enable the operation of "very large local DFZ"  
routing realms (in the hundreds of thousands or millions of networks)  
and we're really, really concerned about accidental leakage of local  
prefixes into the DFZ with PI addressing, then I can understand the  
motivation for ULA-G/C.  Is that really what this is all about?  If  
so, then I'd like to see the Introduction revised accordingly.

Here is some proposed text, which I think improves the draft and  
makes it clear what we are intending to do:

>> This document defines the characteristics and technical allocation  
>> requirements for centrally-assigned Unique Local IPv6 addresses,  
>> as defined in [ULA].  They are not expected to be routed in the  
>> default-free zone of the public Internet.  They are intended for  
>> use in pre-arranged interconnection between organizations and  
>> sites in very large local routing realms.
>>
>> All Unique Local IPv6 addresses, as defined in [ULA], have the  
>> following characteristics:
>>
>>   - Globally unique prefix.
>>   - Well known prefix to allow for easy filtering at site
>>     boundaries.
>>   - Internet Service Provider independent and can be used for
>>     communications inside of a site without having any permanent or
>>     intermittent Internet connectivity.
>>   - In practice, applications may treat these addresses like global
>>     scoped addresses.
>>
>> The most important property of ULAs is that they are unique, as  
>> ULA uniqueness allows routing realms to be merged or privately  
>> interconnected with minimal risk of prefix collisions.  The  
>> statistical uniqueness of locally-assigned ULAs is deemed adequate  
>> when routing realms contain a small number of local prefixes, but  
>> insufficient in the case where routing realms routinely comprise  
>> hundreds of thousands or even millions of networks.  A single,  
>> global federated registry for assigning unique local prefixes is  
>> required to address these concerns.  Using ULAs for this purpose  
>> instead of Provider Independent [RIR-PI] addresses has the  
>> attraction of making it easy to prevent leakage of local prefixes  
>> into the default-free zone of the public Internet, thereby  
>> enforcing the requirement to pre-arrange interconnections.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Jul 2007 00:22:27 +0000

> > nope.
> 
> Hmmm.  I guess the alternative is that the purpose of ULA-C/G is to mitigate
> the risk of collision when merging on the order of hundreds of thousands of
> ULA networks in one routing realm... sort of like creating a "local DFZ" of
> a sort.
> 
> Forgive me, but that sounds even more surreal.  ...

if you're going to cons up a potential interpretation without knowing the
real answer, can you at least cons up one that makes sense to you?

> Is that the big driving factor here?

scott@internap has done a fine job of explaining that, today, again.

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 10 Jul 2007 18:15:46 -0700

james woodyatt wrote:
>> expectation that PI blocks can be announced into the DFZ.  The 
>> clearly by Joe Abley in the "Why ULA-* will not harm the DFZ" thread, 
>> that difference in expectation, and ease in filtering when desired or 
>> necessary, makes it possible to give out ULA-G space in a 
>> non-discriminatory manner (which is simply not prudent for PI space 
>> today).
>
> Here is some proposed text, which I think improves the draft and makes 
> it clear what we are intending to do:

First, thank you very much for providing this constructive input.

I don't think that ULA-G prefixes necessarily have to be part of a "very 
large" routing realm to be useful, but I do think that we need to be 
able to support such a scale with the proposed solution.

>>> requirements for centrally-assigned Unique Local IPv6 addresses, as 
>>> defined in [ULA].  They are not expected to be routed in the 
>>> default-free zone of the public Internet.  They are intended for use 
>>> in pre-arranged interconnection between organizations and sites in 
>>> very large local routing realms.

I might suggest we say that "They are intended for use in pre-arranged 
interconnection between organizations and sites in local routing realms 
ranging in scale from small to very large."

>>>
>>> [snip]
>>>
>>> The most important property of ULAs is that they are unique, as ULA 
>>> uniqueness allows routing realms to be merged or privately 
>>> required to address these concerns.  
>>>

In my opinion, it's not the statistical uniqueness of ULA-Ls that is 
insufficient at scale, but the ability to keep track of netblock 
ownership and DNS authority using local mechanisms.  Those problems were 
solved for the public Internet by a hierarchy of registries providing 
WHOIS services, and by a distributed DNS infrastructure providing .arpa 
reverse DNS resolution.  I believe the same solutions are applicable for 
ULA-G addresses. I would propose the following alternate text: "The 
statistical uniqueness of locally-assigned ULAs and the use of local 
methods for registry and reverse DNS services are deemed adequate when 
routing realms contain a small number of local prefixes, but 
insufficient in the case where routing realms routinely comprise 
hundreds of thousands or even millions of networks.  A single, global 
federated registry for assigning and providing registration services for 
unique local prefixes is required to address these concerns."

>>> Using ULAs for this purpose instead of Provider Independent [RIR-PI] 
>>> addresses has the attraction of making it easy to prevent leakage of 
>>> local prefixes into the default-free zone of the public Internet, 
>>> thereby enforcing the requirement to pre-arrange interconnections.

-Scott

---

From: james woodyatt <[email-masked]>
Date: Tue, 10 Jul 2007 19:13:02 -0700

On Jul 10, 2007, at 18:15, Scott Leibrand wrote:
>
> I might suggest we say that "They are intended for use in pre- 
> arranged interconnection between organizations and sites in local  
> routing realms ranging in scale from small to very large."

I like that better, yes.  I suppose we needn't tell people not to  
waste money paying a registry service to avoid a N-in-2^40 chance  
where N < 100.  Reminds me: I need to buy a lottery ticket on the way  
home.

> In my opinion, it's not the statistical uniqueness of ULA-Ls that  
> is insufficient at scale, but the ability to keep track of netblock  
> ownership and DNS authority using local mechanisms.  Those problems  
> were solved for the public Internet by a hierarchy of registries  
> providing WHOIS services, and by a distributed DNS infrastructure  
> providing .arpa reverse DNS resolution.  I believe the same  
> solutions are applicable for ULA-G addresses.

As noted previously, synthesizing delegations for authoritative DNS  
content servers and WHOIS servers (and probably whatever has to  
happen for RPKI to work, I'll wager) can solve all those problems for  
all forms of ULA, not just the centrally-assigned ones.  If we're  
going to do that, I'd like to see the general solution rather than  
one that only works when I pay for a registration.

What if using ULA-C actually *increases* my risk of number collision  
at merge time because of registry service errors?  Then I have to  
choose between better assurance against having to renumber and  
enjoying the [arguably dubious] benefits of centrally managed  
authoritative DNS servers, WHOIS servers and what-not for my prefix.

Wouldn't it make more sense to provide all those service to ULA  
prefixes regardless of how they are allocated?

The one remaining issue you bring up here is the need to keep track  
of "ownership" of a local prefix.  This seems kinda tautological to  
me, but Tony Hain has probably explained the reason behind the  
perceived need for this: the functional innumeracy of various bean- 
counters, lawyers and other suits, which makes them incompetent risk  
managers.  Okay, I'll buy that.  We need ULA-C as a technical  
solution to a political problem.  (I love those.  It's the other way  
around that makes me nervous.)

> I would propose the following alternate text: "The statistical  
> uniqueness of locally-assigned ULAs and the use of local methods  
> for registry and reverse DNS services are deemed adequate when  
> global federated registry for assigning and providing registration  
> services for unique local prefixes is required to address these  
> concerns."

I guess I don't have a problem with this edit, but if we're going to  
specify synthetic delegations for registry and reverse DNS services  
for *all* ULA, not just ULA-C/G, then it would seem to complicate the  
introduction to mention it here.  If we're not going to do that, then  
yes: this is a good edit.

What's wrong with Christian Huitema's proposal to synthesize  
delegations?  It would seem to have the attraction of making the  
methods for resolving reverse DNS and WHOIS (and what-not) to have  
the following two desirable properties:

1) When two routing realms, which are each using the same ULA prefix  
(by pseudorandom collision or registry service error), are *NOT*  
merged, then interconnections to either of them from a third routing  
realm will still work.  They both have authoritative reverse DNS  
servers and WHOIS servers that respond in their routing realm.

2) Resolving recursive reverse DNS and WHOIS for an unknown ULA  
prefix doesn't depend on the availability and proper functioning of  
the managed servers of a third party on the public Internet, i.e.  
your ULA registry.  This aids in the construction of ad-hoc networks.

Finally, I also think it's important to retain the text I proposed  
below:

>>>> Using ULAs for this purpose instead of Provider Independent [RIR- 
>>>> PI] addresses has the attraction of making it easy to prevent  
>>>> leakage of local prefixes into the default-free zone of the  
>>>> public Internet, thereby enforcing the requirement to pre- 
>>>> arrange interconnections.

I think it helps to make it clear *why* ULA-C is the preferred  
alternative to RIR-PI for local routing realms that require a global  
number registry service.

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 10 Jul 2007 20:12:04 -0700

james woodyatt wrote:
>> I might suggest we say that "They are intended for use in 
>> pre-arranged interconnection between organizations and sites in local 

Heh.  Bummer the government has a monopoly on lotteries.  I'd love to 
sell you a few.  :-)

>> providing .arpa reverse DNS resolution.  I believe the same solutions 
>> are applicable for ULA-G addresses.
>
> content servers and WHOIS servers (and probably whatever has to happen 
> for RPKI to work, I'll wager) can solve all those problems for all 
> forms of ULA, not just the centrally-assigned ones.  If we're going to 
> do that, I'd like to see the general solution rather than one that 
> only works when I pay for a registration.

I'd love to see the details of such a solution.  I haven't read up on 
how synthesized delegations would work: all the schemes I've seen so far 
are less scalable than the Internet's distributed DNS hierarchy.

> authoritative DNS servers, WHOIS servers and what-not for my prefix.

Well, I suppose we could fit a few more angels on the head of the 
pin...  :-)  (I don't think the risk of collision in either case is 
something to worry about.)

> The one remaining issue you bring up here is the need to keep track of 
> "ownership" of a local prefix.  This seems kinda tautological to me, 
> but Tony Hain has probably explained the reason behind the perceived 
> need for this: the functional innumeracy of various bean-counters, 
> lawyers and other suits, which makes them incompetent risk managers.  
> Okay, I'll buy that.  We need ULA-C as a technical solution to a 
> political problem.  (I love those.  It's the other way around that 
> makes me nervous.)

Well, it may solve some political problems, but it definitely meets some 
real needs as well.  For example, say I'm parsing mail logs in my spam 
folder, and find a mail server that received my mail from a client using 
a ULA-G address, and then sent it to my mail server using a PA address.  
With whois to track ownership, I can look up the owner and abuse contact 
of the infected client as well as the server that relayed the message.

>> uniqueness of locally-assigned ULAs and the use of local methods for 
>> registry and reverse DNS services are deemed adequate when routing 
>> realms contain a small number of local prefixes, but insufficient in 
>> the case where routing realms routinely comprise hundreds of 
>> thousands or even millions of networks.  A single, global federated 
>> registry for assigning and providing registration services for unique 
>> local prefixes is required to address these concerns."
>
> methods for resolving reverse DNS and WHOIS (and what-not) to have the 
> following two desirable properties:
>
> 2) Resolving recursive reverse DNS and WHOIS for an unknown ULA prefix 
> doesn't depend on the availability and proper functioning of the 
> managed servers of a third party on the public Internet, i.e. your ULA 
> registry.  This aids in the construction of ad-hoc networks.

Those sound like good properties.  Can you point me to Christian 
Huitema's proposal?  I'm not sure I've seen it before.

>
> Finally, I also think it's important to retain the text I proposed below:
>
>>>>> Using ULAs for this purpose instead of Provider Independent 
>>>>> [RIR-PI] addresses has the attraction of making it easy to prevent 
>>>>> leakage of local prefixes into the default-free zone of the public 
>>>>> Internet, thereby enforcing the requirement to pre-arrange 
>>>>> interconnections.
>

I agree, and didn't mean to imply that it should be removed.

-Scott

---

From: Roger Jorgensen <[email-masked]>
Date: Wed, 11 Jul 2007 11:38:56 +0200 (CEST)

On Tue, 10 Jul 2007, james woodyatt wrote:
<snip>
> ULA networks in one routing realm... sort of like creating a "local DFZ" of a 
> sort.
>
> Forgive me, but that sounds even more surreal.  It's tough for me to imagine 
> how a real organization doing that could fail to qualify for a PI allocation, 
> or why such an organization would find it unacceptable to have to use a PI 
> allocation without advertising it to the public DFZ.  Likewise, it's tough to 
> imagine how an organization that doesn't qualify for a PI allocation could be 
> merging enough ULA networks together that the risk of collision rises to a 
> level of any real significance.
>
> organizations doing all this network merging, i.e. extraordinarily paranoid 
> organizations, e.g. the Communist Party, want some kind of assurance from the 
> operators of the public Internet that their hundreds of thousands of local 
> networks aren't directly reachable from the public DFZ in the event a local 
> NOC configures a border router improperly.  Obviously, ULA-C can do that 
> better than PI.
>

PI can be used for almost everything ULA-C/G can be used for, dont think 
anyone disagree on that. The whole ULA-C/G is about the purpose of the 
address space and what it can be used for both now and in the future. 
Strictly internal/private networking right now and ID/LOC or whatever in 
the future... or other thing we dont know about.

It is more about creating a address space that can be used for OTHER thing 
than the DFZ-way of thinking Internet we have now.

And yes you have a good point, internal infrastructure like the above 
operator but that is almost excacly what we (where I work) want to use it 
for! .. just that we will also place some of our customers there to.
(and please dont start the rant about NAT or whatever we need to get them 
onto internet because they are not suppose to be conneted directly to 
internet)

--

---

From: <[email-masked]>
Date: Wed, 11 Jul 2007 11:01:54 +0100

> It is more about creating a address space that can be used 
> for OTHER thing than the DFZ-way of thinking Internet we have now.

Up until now, I've been on the fence regarding ULA-centrally-registered
address space, but after several comments in the past two days, I now
support defining these addresses.

Other factors that I think help make the case:

1) The RIR system is already in place to deal with DFZ grey areas. If we
delegate the central registry function to the RIRs, they can deal with
the details of how such addresses are handed out (automatically or on
demand), charges for maintaining the registry and ip6.int services, and
sorting out the issues of non-aggregation and global routing table
entries.

2) These ULA addresses provide an additional layer of security in a
layered security model. If I use my PI addresses for secret internal
infrastructure, I must block those ranges in my firewall. Networks which
I connect to will likely not block these ranges, so I have one layer of
security. If I use ULA addresses, then the vast majority of other
networks will block the entire ULA range, thus giving me an additional
layer of security. If I need to use ULA addreses to talk to a peer, we
can both punch holes in our filters/firewalls.

3) ULA addresses reduce the administrative burden. If I use some PI
addresses for secret internal infrastructure, I must repeatedly update
filters at the edge to block traffic to these ranges. If I use ULA
addresses, then I simply block the entire ULA range and never need to
update filters.

In general, it seems to me that the benefits fall on the enterprise
network side, and the possibly disadvantages fall on the ISP side. The
IETF needs to provide technology that supports all users of IPv6. Since
there are other mechanisms outside the IETF to deal with the ISPs'
issues, I think we need to go ahead with ULA centrally-registered.

Paul's draft which assigns 12 bits to each RIR seems to be the right
thing since it clearly delineates which RIR is responsible for each
subset range, and therefore if an RIR policy dictates special handling
for certain ULA addresses, there is a simple technical means to
accomplish this.

I'm not sure what the status of Paul's document is since the drafts
directory only contains this one:
http://www.ietf.org/internet-drafts/draft-ietf-ipv6-ula-central-02.txt

Is Paul's superceding that or is there a merge in process?

--Michael Dillon

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 11 Jul 2007 12:21:33 +0100

> support defining these addresses.

My views are also changing, toward positive, based on the discussions,
but there is a big but: the draft needs to say those things too.

The description has to be heavily updated to explain really WHY this
type of addresses (should) exist and for what usages. Also I am pretty
convinced that the naming has to be changed. The RFC4193 ULA naming is
quite accurate, but for the kind of usage that has been discussed
recently ULA is not a good name. Also the draft should very clearly
outline the pro's and con's that this type of address space has for
potential users of it. That they can be used as EID's at a certain point
in time is also that should be documented in the draft.

As such, I am awaiting the new draft.

> sorting out the issues of non-aggregation and global routing table

You most definitely meant ip6.arpa there instead of ip6.int which was
deprecated quite some time ago. Indeed, the RIR's are already in place
if something to the effect of the proposed address space would ever come
to be then they are the places that should be the registries for it.
Inventing new structures for that would not be helpful at all.

> infrastructure, I must block those ranges in my firewall.

Or simply not route them at all. I don't really see this is a benefit.
It is only a benefit against so called fat fingers, but if you have that
problem there are bigger problems at hand, especially in an area where
security is to be required.

> Networks which
> layer of security. If I need to use ULA addresses to talk to a peer, we

Maybe to reflect the above, the draft should definitely state that
firewalls should per default at least propose to block these ranges.

> issues, I think we need to go ahead with ULA centrally-registered.

The question here still remains though: how really different is this
from "PI". In effect it is non-DFZ-PI space that is being defined here.
RIR's themselves could thus also set aside a /20 or something and
allocate /40-/48's from that block for that purpose and state "currently
these might be routable, but in the future they will not be".
Which is quite less of an addressing burn than this.

[..]
> Is Paul's superceding that or is there a merge in process?

I understood that he is busy updating it and tried to submit it, though
submitted it after the -00 deadline. Which means that for the time being
it can't be updated :(

Greets,
 Jeroen

---

From: <[email-masked]>
Date: Wed, 11 Jul 2007 12:51:13 +0100

> The question here still remains though: how really different 
> is this from "PI". In effect it is non-DFZ-PI space that is 
> being defined here.

PI (Provider Independent) is not a relevant term to refer to addresses
that are allocated to end-user organizations for use in their own
networks. There is no provider in such a scenario, therefore the
addresses are neither provider-independent nor provider-dependent. In
fact, they are local to the end-user network which is why people have
been referring to them as Unique Local Addresses (ULA). It appears that
we are accumulating enough changes from the original ULA that it is not
correct to refer to them as ULA addresses that are centrally registered.
However, they are Unique, and they are Local. Perhaps ULRA (Unique Local
Registered Addresses) is sufficiently different from ULA that people
will not accidentally look to RFC 4193 for advice?

--Michael Dillon

---

From: Per Heldal <[email-masked]>
Date: Wed, 11 Jul 2007 14:08:41 +0200

> Which is quite less of an addressing burn than this.

It's much easier/faster to identify any ULA-space (FC00::/7) in one
comparison than having to match individual (possibly variable)
RIR-ranges (for filtering etc). Especially if/when such algorithms are
implemented in silicon for enhanced performance.

//per

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Jul 2007 14:15:26 +0000

> than the DFZ-way of thinking Internet we have now.

yup.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Jul 2007 14:23:37 +0000

> for certain ULA addresses, there is a simple technical means to

it's expected that iana will hand out blocks of 100 RIR-sized ULA-G blocks
to each RIR, similar to how ASN blocks are assigned, just to save paperwork.
but yes, since each RIR will have its own chunks of this space, they can do
whatever their regional member-driven policy development process tells them
to do as far as carving it up and handing it out to LIRs, endusers, etc.

> Is Paul's superceding that or is there a merge in process?

the other authors of ula-global have not commented on my hijackery.  they
might be supportive, or angry, or complacent, about the draft-fork i made.
maybe they'll want their names removed.  maybe they'll want to merge ula-g
into ula-c and have my name removed.  maybe they'll want the fork to stay.

the i-d editor determined that my submission came after the chicago cutoff,
which really oughtn't apply for WG's that are not meeting, but so it goes.

the WG chairs have ignored my mail thus far.

so my take is, suggested changes and statements of opposition||support can
be made based on the text at http://sa.vix.com/~vixie/ula-global.txt.  i'll
be rev'ing the draft based on james' and scott's comments shortly.

---

From: Paul Vixie <[email-masked]>
Date: Wed, 11 Jul 2007 14:32:07 +0000

> will not accidentally look to RFC 4193 for advice?

suits me.

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 11 Jul 2007 08:59:04 -0700

> so, then I'd like to see the Introduction revised accordingly.

Not to pick on James' post, but several have mentioned that
large routing realms would be one reason to require ULA-G/C
and it has not yet been suggested that the reverse DNS could
itself be thought of as a "large routing realm" of sorts
(depending on how applications use the information they find
there). ULA-G/C would ideally allow collision-free population
of the reverse DNS even with O(10^6) or more delegations.

I can't comment furhter on Paul's proposal other than to say
that *some* authority(s) needs to be responsible for the
collision free delegations.

Fred
[email-masked]

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 11 Jul 2007 10:01:05 -0700

I have a few points on Paul's draft:

Nit - LocalNum = 28 bits (you lost 4 bits somewhere)

Minor point - 5.1 is not globally true yet, but should be

Major complaint -  aggregation
	There needs to be at least a modest capability to aggregate. I
understand the aversion to having these show up in the DFZ, but if 5.1 were
really true that would not be an issue. The use case that needs to be
supported is for internal aggregation of private peering clusters. Global
organizations have many external relationships, but typically have them
clustered in small groupings for logistics reasons. At the same time they
don't necessarily want to carry the explicit routes for every organization
throughout their internal network. If the ULA-C/G space has some modest
aggregation  like sparse allocation of the RIR num block to allow clustering
subsequent block to the same RIR and a suggestion for E-W-N-S regional
management within the RIR space, then it would be possible to aggregate the
internal routes to these private peering clusters. 

5.6 last sentence seems to be prescriptive, and would be more descriptive if
opened with 'It is expected that ...'

6.1 - One point of the entire ULA space is that this is a different
'filtering process'. Where typical filters block packets received at the
border for the target address, the ULA space is about not even having a
route for that packet in the first place. Yes there is no more or less
security than any other unicast address when routing announcements and
packet filtering match, but the default assumption that ULA is a bogon
routing announcement should add a layer of security that can't be done with
PI for most use cases.

Tony 

> -----Original Message-----
> From: Paul Vixie [mailto:[email-masked]]
> Sent: Wednesday, July 11, 2007 7:24 AM
> To: [email-masked]
> Subject: Re: draft-ietf-ipv6-ula-central-02.txt
>

---

From: Roger Jorgensen <[email-masked]>
Date: Wed, 11 Jul 2007 20:33:06 +0200 (CEST)

<snip>
> internal routes to these private peering clusters.

IF we assume and prepare the ground for aggregation, would that just make 
it easier in the future for this type of addresses being leaked?

Anyway, 3.1 mention:
" Local Num  Identifiers assigned by an RIR (or LIR) for each /48 as
               allocated to an end site or user.  It is expected that
               allocations by an RIR to an LIR will be in blocks of 1000
               consecutive Local Nums, to amortize administrative workload."

which again give us some sort of aggregation... is this something we want? 
(althought it would fit us, where I work, perfectly since we would get 
almost all the space we need quite easy:-)

But then again 5.5 say it is recommanded to not allocate aligned blocks...

maybe clean up the wording on those part a bit?

<snip>

--

---

From: Scott Leibrand <[email-masked]>
Date: Wed, 11 Jul 2007 12:52:43 -0700

Roger Jorgensen wrote:
> IF we assume and prepare the ground for aggregation, would that just 
> make it easier in the future for this type of addresses being leaked?

<snip>

> which again give us some sort of aggregation... is this something we 
> want? (althought it would fit us, where I work, perfectly since we 
> would get almost all the space we need quite easy:-)

I would agree with Tony that aggregation of ULA-G space should be 
allowed.  I know there are many others who disagree, but IMO mutually 
assured destruction isn't called for here.  As long as we have an 
expectation that routes will be filtered, and have the ability to easily 
do so, I don't think it matters whether we have lots of non-aggregated 
routes or fewer aggregated ones...

-Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 12 Jul 2007 10:05:13 +0200

> routes or fewer aggregated ones...

I'd also add a heretical comment: if they agggregate, it doesn't *matter*
if they leak. In fact, they *will* leak up to the point where they
hit a shorter filter. That's physics.

    Brian

---

From: Paul Vixie <[email-masked]>
Date: Thu, 12 Jul 2007 14:35:04 +0000

> >> want? (althought it would fit us, where I work, perfectly since we would
> >> get almost all the space we need quite easy:-)

> > I would agree with Tony that aggregation of ULA-G space should be allowed.
> > I know there are many others who disagree, but IMO mutually assured
> > destruction isn't called for here.  As long as we have an expectation that
> > routes will be filtered, and have the ability to easily do so, I don't
> > think it matters whether we have lots of non-aggregated routes or fewer
> > aggregated ones...

> I'd also add a heretical comment: if they agggregate, it doesn't *matter* if
> they leak. In fact, they *will* leak up to the point where they hit a
> shorter filter. That's physics.

ok, intentional unaggregatability is out.

---

From: Roger Jorgensen <[email-masked]>
Date: Tue, 24 Jul 2007 08:39:18 +0200 (CEST)

so what has happen to this? Still no feedback from authors or chairs or?

On Wed, 11 Jul 2007, Paul Vixie wrote:
<snip>

--

---

From: <[email-masked]>
Date: Tue, 24 Jul 2007 09:58:06 +0100

> so what has happen to this? Still no feedback from authors or 

The WG chairs have asked the authors of the draft to review and edit it
because there is not currently consensus on ULA-C. If those authors are
smart, they will work with Vixie and incorporate some of the comments
from this list as well. Once they have finished editing, they will
submit a new draft and we will have something to comment on.

Or they may simply go away having given up on finding consensus. In that
case, Vixie's draft is still in play I believe.

I suggest that you contact the authors directly if you have some
concerns. Not all work occurs on the list.

--Michael Dillon

---

From: Paul Vixie <[email-masked]>
Date: Tue, 24 Jul 2007 11:13:50 +0000

> so what has happen to this? Still no feedback from authors or chairs or?

nothing.