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

From: <[email-masked]>
Date: Sun, 1 Jul 2007 18:35:03 +0100

> First, s/laptop/platform - where, a "platform" could be 
> something relatively small (like my laptop) or something 
> quite a bit larger (like a cruise ship). Any points 
> in-between (planes, trains, automobiles, etc.) also meet the 
> description. But, all of them are platforms and all of them 
> are also "sites".

Don't forget things like the containers full of suitcase that they load
into airplanes. Or packing crates full of produce stored in a warehouse,
moved into a shipping container, loaded on a truck, transferred to a
ship, transferred to a train, loaded on another truck, and unloaded in
another warehouse cooler. Or medical devices with built-in computers
somewhat analogous to car engine computers, i.e. an insulin drip device
which needs to be docked at the pharmacy for data analysis before they
refill the insulin tank. Basically, IPv6 will be used for stuff which
was sci-fi a few years ago, not just the same old things as IPv4.

--Michael Dillon

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

---

From: Joe Abley <[email-masked]>
Date: Sun, 1 Jul 2007 18:21:10 -0400

Very late to this party, but:

On 27-Jun-2007, at 09:11, Brian E Carpenter wrote:

> We can argue about the meaning of "intrinsically" I guess. But what  
> I mean
> is that they are /48s and I don't expect to see /48s routed globally.
> Architecturally, they are certainly routeable (and so are /128s).
> But I am sure they will be filtered.

I hope they won't all be filtered, since there are a non-trivial  
number of infrastructure services in the DNS which are deployed  
using /48s assigned directly from RIRs under policies designed to  
facilitate critical infrastructure.

I realise that you were talking in far more general terms than this,  
but every time I see someone make blanket statements about "/48s" and  
their presence in the DFZ it makes me twitch. Not all /48s are  
components of larger assignments or allocations.

Joe

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 02 Jul 2007 10:44:55 +0200

On 2007-07-02 00:21, Joe Abley wrote:
>> We can argue about the meaning of "intrinsically" I guess. But what I 
>> mean
> I hope they won't all be filtered, since there are a non-trivial number 
> of infrastructure services in the DNS which are deployed using /48s 
> assigned directly from RIRs under policies designed to facilitate 
> critical infrastructure.

Yes of course. I meant end-user /48s. Thanks for clarifying.

    Brian

> 
> I realise that you were talking in far more general terms than this, but 
> every time I see someone make blanket statements about "/48s" and their 
> presence in the DFZ it makes me twitch. Not all /48s are components of 
> larger assignments or allocations.
> 
> 
> Joe
> 
> 
>

---

From: Bill Manning <[email-masked]>
Date: Mon, 2 Jul 2007 07:49:38 -0700

> components of larger assignments or allocations.

	actually, to borrow a phrase from a mutual associate,
	"I encourage Brian (and others) to filter /48s" .... :)
	
	i think that it will make their IPv6 experience that much
	more enjoyable/useful.

--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: "Stephen Sprunk" <[email-masked]>
Date: Tue, 3 Jul 2007 14:13:07 -0500

Thus spake "Jeroen Massar" <[email-masked]>
> What is the point of that? How can a ULA address reach a
> global unicast address or for that matter, how is such a ULA
> address, which is most likely going to be the sole user of
> those reverse servers going to contact any of the root servers,
> .arpa servers, RIR servers etc to actually find out where that
> server is located in the first place?
...
> Also, registered the DNS servers in the global DNS thus means
> that those machines will be Internet connected, then what is
> the point of ULA again?

The supposed use case for ULA-C is large orgs who interconnect privately 
with other large orgs.  If you _don't_ allow ULA-Cs in the global reverse 
DNS, then every org in the internetwork must hack their local DNS servers to 
recognize every other org's reverse DNS entries.  That is painful and 
unnecessary.

There are operational concerns with putting ULA(-C) addresses in forward 
DNS; nobody argues with that.  However, putting ULA-C addresses in reverse 
DNS harms nobody who can't reach those addresses yet greatly benefits those 
that can.

Of course, if everyone just used PI, none of this would be an issue.

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

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 3 Jul 2007 14:02:56 -0500

Thus spake "Scott Leibrand" <[email-masked]>
> I think what we wanted to get rid of in IPv6 was one-to-many
> NAT, also know as PAT (among other names).  In IPv6, we
> can stick to one-to-one NAT, which eliminates most of the
> nastiness we associate with NAT in today's IPv4 world.

The only legitimate reason to bother with 1:1 NAT is because one can't get 
PI space.  Solution: make PI space available.  Oh, wait, we already did 
that...

However, there are other reasons people use NAT today, mainly because they 
confuse NAT with a stateful firewall.  Such people will continue to use NAT 
(or PAT) even if they have PI or ULA(-C) space on the "inside".

> I agree that PI space, if it were widely available, would meet the
> same needs as ULA-C.  However, I think we need to be realistic
> that PI-for-everyone won't fly, and need to think creatively about
> ways to achieve the same goals (such as provider
> independence) in such a way that we don't impose more public
> cost than private benefit.

If the use is truly private, then there is no public cost.

> When it was last proposed there was: it was thought that
> networks would get ULA-C and use it as PI space.  Now,
> since PI space is readily available to multihomed networks,
> that is much less likely.  As a result, I am in favor of allowing
> small networks to register their own unique private space,
> as this draft would do.

The thing is, if the network is "small", i.e. too small to qualify for PI 
space, then RFC 4193 is more than sufficient.

The only reasonable use cases I've heard for ULA-C are for orgs so big and 
with so many interconnections that ULA is not sufficient; those orgs can get 
PI without any challenges today, which means ULA-C offers nothing new.

I fail to see the "innovation" here.

S

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Jul 2007 13:15:03 +0200

Stephen Sprunk wrote:
> The supposed use case for ULA-C is large orgs who interconnect 
> privately with other large orgs.  If you _don't_ allow ULA-Cs in the 
> global reverse DNS, then every org in the internetwork must hack their 
> local DNS servers to recognize every other org's reverse DNS entries.  
> That is painful and unnecessary.

To borrow your logic, if this space is truly private why should this be 
an issue?
>
> There are operational concerns with putting ULA(-C) addresses in 
> forward DNS; nobody argues with that.  However, putting ULA-C 
> addresses in reverse DNS harms nobody who can't reach those addresses 
> yet greatly benefits those that can.

The delegation must be maintained and occasionally updated.  Who does that?

> Of course, if everyone just used PI, none of this would be an issue.

At this point it is plain to see that ULA-C is nothing but PI address 
space, because the IETF is in no position to enforce otherwise.  So 
please, let's just call it what it is.

Eliot

---

From: Roger Jorgensen <[email-masked]>
Date: Mon, 9 Jul 2007 13:30:04 +0200 (CEST)

On Mon, 9 Jul 2007, Eliot Lear wrote:
<snip>
> At this point it is plain to see that ULA-C is nothing but PI address space, 
> because the IETF is in no position to enforce otherwise.  So please, let's 
> just call it what it is.

it is NOT the same, there are several differences and some of them are not 
technical but more manager/non-technical ways of viewing things.

* PI are ment to be used on internet
* ULA-C/G are NOT ment to be used on internet (think we can forget the 
point that some might want todo it really, the chances are low and even 
managers will understand that it aint supposed to be done, most managers 
probably even understand RFC1918 ....)
* PI are the same as PA, there are NO real difference except on how you 
get it and the size of the block, it is what Paul Dixie have called UA 
(unique addresses), nothing else
* ULA-C/G are something completly different, it is more like RFC1918 space 
with some extra features,
- the size (amount of IPs)
- global unique so the current pain anyone with large network have when 
they are interconnecting, merging due to fusions or other reasons dont 
exist
- anyone can, IF the ULA-C/G holder want to, resolve the IP in any given 
ULA-C/G block through the global DNS system (a very very nice thing for 
everyone that hate the pain split-DNS give you...additional 
administration)

and probably a few other things but the above are those I consider most 
important.

-- 

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

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 09 Jul 2007 12:58:56 +0100

Roger Jorgensen wrote:
> it is NOT the same, there are several differences and some of them are
> not technical but more manager/non-technical ways of viewing things.
> 

False, they are "globally unique IPv6 addresses". Where you use them,
nobody cares as they are meant to be used everywhere. Just like ASN's
and everything else that the RIR's provide. They are "globally unique"
and therefor allow you to interconnect to other organizations, if those
are on "The Internet" or just local. Just check the "Prefix In Use" kind
of tools, they show that a lot of PI space is not visible on the
Internet, and even then, being available in BGP doesn't say that those
blocks are actually routed further than the router which routes it into
/dev/null or the firewall which blocks everything or runs it into a
honeypot.

> probably even understand RFC1918 ....)

The chances of people wanting to use ULA-C/G on the Internet are really
high. There is *always* a need to use them on "the Internet", even if
that "Internet" is only an interconnection between several
organizations. At one point or another you will most likely be
connecting to an organization that is on the Internet and that doesn't
want to participate/do difficult with ULA-kind of addresses and then you
are stuck. Why make "ULA" so special and prone to be used on the
Internet anyway after a while, why burden people with it?

> (unique addresses), nothing else

Paul Vixie indeed labeled that correct. The only difference is the size
indeed and who gets them. Also PI is supposed to be assigned to one
single end-site, while PA is allocated to one big organization that
sub-assigns to it's own organizational units/customers.

> * ULA-C/G are something completly different, it is more like RFC1918
> space with some extra features,

UA does that

> they are interconnecting, merging due to fusions or other reasons dont

UA does that

> everyone that hate the pain split-DNS give you...additional administration)

Please explain me how you are going to do *forward DNS* also. You know,
most people type www.google.com, not the ip6.arpa ones and without the
first, the latter is useless. You have to connect the forward zones
anyway, so why not connect the reverse ones also. This has to be split
DNS anyway, as a lot of companies are not willing to connect their
internal systems in ANY way to the global Internet or let alone, expose
those hostnames to that global Internet thing. Of course it is a lot of
fun to be able to resolve big-red-button.oval-room.whitehouse.gov and at
least know where to look for.

Hint for security control freaks: DNS tunneling, you know it is fun :)
And when you are able from your local (ULA) host to resolve a global DNS
name you can do exactly that and more. Also what happens when a local
guy types "www.google.com", do they get routed into oblivion or do you
think they will not want to connect to that or to Wikipedia and a lot of
resources on the Internet? Or are you going to use 2 IP addresses or
more per host and create even a bigger management hell?

Stuffing *LOCAL* reverse DNS in the *GLOBAL* DNS doesn't make any sense.
Either keep it totally local or keep it totally global (thus UA).

So how exactly is this ULA thing different from the UA (PI&PA) space
that is already available? Why bother with ULA when one day you might
most likely want to connect to the Internet anyway and cause pain then?
Why lay that pain unto people?

The only real difference I see is that it is a well known block that
people can force to not route, thus making a 2nd kind of Internet
Citizen and a  monopoly situation for the folks who can and the ones who
can't get UA space.

Now I do see another use for this kind of address space, but then it
should not be called this way. It could be used for ID/LOC solutions,
where these kind of addresses are Explicit-non-DFZ addresses. But if
that is the reason for what folks want to use them, as that is what I am
sort of reading between the lines as actual real usage has still not
been identified, then please just state that.

Greets,
 Jeroen

---

From: <[email-masked]>
Date: Mon, 9 Jul 2007 13:18:21 +0100

> At this point it is plain to see that ULA-C is nothing but PI 
> address space, because the IETF is in no position to enforce 
> otherwise.  So please, let's just call it what it is.

The IETF is not in a position to enforce the special handling of ULA-C
addresses however, IANA via the RIRs is in such a position. The C in
ULA-C refers to a central registry. It is likely that IANA will appoint
the RIRs to handle that function. Since the RIRs only allocate numbers
to organizations who sign a contract with the RIR, this places the RIR
in a legal position to enforce any special rules that may be attached to
ULA-C addresses.

The IETF can state its intent that ULA-C address ranges should not be
announced on the Internet or routed across the Internet outside of
tunneling technologies. The RIRs can then enforce that intent.

If the membership of the RIRs decide that it is valuable to allow ULA-C
addresses to be used on the Internet and that they can handle the
increase of entries in the global routing table, then those members can
collectively override the IETF's intent. 

Essentially, the IETF is placing control over the route announcement
question in the hands of those who are actually impacted by the
question. If there is any dispute over the specifics of how this is
handled, the RIRs are the forum in which it should be worked out. 

--Michael Dillon

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Jul 2007 14:32:55 +0200

On 2007-07-09 13:58, Jeroen Massar wrote:
...
> been identified, then please just state that.

I believe that ULA-G as proposed by Paul is an interesting candidate
for unrouteable EIDs in the sense that the LISP proposal defines "EID".
But that conversation belongs on another list.

However, if we're worried about keeping /48s out of the DFZ, I agree
that it really doesn't matter whether they're called "PI", "ULA",
"2002::/48" or simply /48 holes in PA prefixes. It's the ISPs who
will keep them out, or let them in, not the IETF.

     Brian

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 09 Jul 2007 13:55:40 +0100

> But that conversation belongs on another list.

I fully agree with this and I also support this route. But then don't
call them ULA or assign them any functionality in this area which is
completely misleading. Call the beast what it is supposed to be called.

> will keep them out, or let them in, not the IETF.

Indeed. If we are going to carve a block out which should never show up
in routing tables (except maybe site internal ones etc), then give them
the name that they should have and the description that they should have.

Assigning this /8 as something which is not PI but is PI is only
ambiguous. Giving them the a name like "EID" and stating that these are
not to be used for routing in the DFZ, but can be used globally with the
help of an upcoming protocol which does an ID/LOC split does make sense.
It then all of a sudden is also logical that these blocks will need
reverse DNS delegations, as they will be used _on_ the Internet, but
just not _routed_ on the Internet.

IMHO it is thus much better to put this ULA-C proposal on ice and await
the requirements and structure that that the upcoming ID/LOC proposal.

Although, I guess that they will be quite like what Paul proposed in
delegation structure, but the description of the addresses and the name
will be different and more appropriate to what they will be actually
used for.

The above is also why I say "/48's are not a big problem", as when the
routing tables get too large, ISP's will start filtering, forcing the
/48 PI users to start using their address space as EID's. Having a
special block which solely restricts this is of course a good thing. The
RIR's can then easily explain "these kind are EID's and are 'cheap',
while these kind are accepted in the DFZ". Now what the RIR's policies
will be on who can get what kind of addresses is of course to be
questioned and something the RIR's will have to fight out with their
membership.

Greets,
 Jeroen

---

From: Eliot Lear <[email-masked]>
Date: Mon, 09 Jul 2007 15:07:11 +0200

Having had my name on RFC 1918, I think understand some of the issues.  
There is precisely one that I find at all interesting in this proposal, 
having stated the concern in RFC 1627:

    * avoiding collisions, and Geoff Huston's math demonstrates the
      likelihood of that happening

But one needn't have reverse lookups delegated in the root to address 
this concern.

I also understand something about the differences between ULA-C and RFC 
1918.  For one, this space will be unique within the limits of human 
error.  RFC 1918 not being unique meant that providers really had no 
choice about blocking it, and IANA had no method to insert reverse 
addresses to a particular site.

Eliot

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 9 Jul 2007 09:53:20 -0500

Thus spake "Eliot Lear" <[email-masked]>
> Stephen Sprunk wrote:
>> The supposed use case for ULA-C is large orgs who
>> interconnect privately with other large orgs.  If you _don't_
>> allow ULA-Cs in the global reverse DNS, then every org in
>> the internetwork must hack their local DNS servers to
>> recognize every other org's reverse DNS entries.  That is
>> painful and unnecessary.
>
> To borrow your logic, if this space is truly private why should
> this be an issue?

That hinges on the meaning of "private".  Imagine a private internet for the 
aviation industry; there would be thousands of players, each supposedly with 
their own ULA-C/G block.  Every player would need to hack their DNS servers 
to account for every other player's RDNS settings, and any time someone new 
joined or someone existing wanted to update their settings, thousands of 
other operators would need to change their hacks to keep things working. 
The odds of that being successful in practice are so low they're not worth 
considering.

>> There are operational concerns with putting ULA(-C)
>> addresses in  forward DNS; nobody argues with that. However, putting 
>> ULA-C addresses in reverse DNS harms
>> nobody who can't reach those addresses yet greatly
>> benefits those that can.
>

Whoever is designated as the central authority.  It is necessary for there 
to be a database to keep blocks unique, and that database will need billing 
and contact information, so the addition of a couple of NS entries for each 
block is trivial.  All we're discussing now is whether that information is 
exposed via the global DNS.

> otherwise.  So please, let's just call it what it is.

Exactly.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 9 Jul 2007 09:48:12 -0500

Thus spake <[email-masked]>
> The IETF is not in a position to enforce the special handling of
> ULA-C addresses however, IANA via the RIRs is in such a
> position. The C in ULA-C refers to a central registry. It is likely
> that IANA will appoint the RIRs to handle that function. Since the
> RIRs only allocate numbers to organizations who sign a contract
> with the RIR, this places the RIR in a legal position to enforce
> any special rules that may be attached to ULA-C addresses.

Good grief.  The RIRs today cannot guarantee ULA-C addresses _won't_ be 
routed any more than they can guarantee PI/PA addresses _will_ be routed. 
You seem to be proposing a shift in RIR policy where anyone who doesn't play 
ball with arbitrary IETF rules get their allocations/assignments revoked... 
Sorry, but I'm not signing that contract, nor is anyone else.  It'd never 
pass community consensus.

> Essentially, the IETF is placing control over the route
> announcement question in the hands of those who are actually
> impacted by the question. If there is any dispute over the
> specifics of how this is handled, the RIRs are the forum in
> which it should be worked out.

RIRs have no power to do that today.  Routability of prefixes is solely in 
the hands of ISPs that accept (or not) those routes.  And we do _not_ want a 
world where some group of ivory tower academics and vendors tell operators 
what they _must_ do on their own networks.  The Internet is successful due 
to cooperation inspired by enlightened self-interest, not central control.

S

---

From: "Stephen Sprunk" <[email-masked]>
Date: Mon, 9 Jul 2007 10:05:45 -0500

Thus spake "Roger Jorgensen" <[email-masked]>
> it is NOT the same, there are several differences and some
> of them are not technical but more manager/non-technical
> ways of viewing things.
>

No, PI is meant to be used anywhere IP is used.  A large fraction of PI 
space isn't routed on the Internet, and even in v4 there are several /8s 
that are used privately.

> * ULA-C/G are NOT ment to be used on internet

OTOH, there's no way for the IETF or RIRs to stop it from happening.  I'm 
not saying it will, but it is irresponsible to claim it won't when there's 
no mechanism to enforce that.

> * PI are the same as PA, there are NO real difference except
> on how you get it and the size of the block, it is what Paul Dixie
> have called UA (unique addresses), nothing else

PI vs PA merely depends on your perspective, i.e. whether you're the 
original recipient from the RIR.

> * ULA-C/G are something completly different, it is more like
> RFC1918 space with some extra features,

This is a big disadvantage for ULA (of any flavor) space; you can get much 
bigger PI (or even PA) prefixes than the fixed /48 of ULA.

> - global unique so the current pain anyone with large network
> have when they are interconnecting, merging due to fusions or
> other reasons dont exist

That's no advantage over PI/PA space.

> - anyone can, IF the ULA-C/G holder want to, resolve the IP in
> any given ULA-C/G block through the global DNS system (a
> very very nice thing for everyone that hate the pain split-DNS
> give you...additional administration)

There's no consensus yet that ULA-C/G will appear in the global DNS.  PI/PA 
space definitely will.

> and probably a few other things but the above are those I
> consider most important.

If you start with the solution, one can always find problems that it solves. 
However, if you start with a defined problem, the solution may not be what 
you expect.  Every example you've given so far is solved at least as well by 
PI space as by ULA space, and in some cases better by PI.

S

---

From: <[email-masked]>
Date: Mon, 9 Jul 2007 16:56:00 +0100

> announcement 
> RIRs have no power to do that today.  Routability of prefixes 
> is solely in the hands of ISPs that accept (or not) those 
> routes.  

And ISPs happen to be members of the RIRs and therefore they have a
voice in the policies of the RIRs. Therefore, RIRs do have the power to
prevent ULA-C route announcements and the RIRs are the forum for
interested parties, such as ISPs and address holders, to work out the
issue. Not the IETF.

> And we do _not_ want a world where some group of 
> ivory tower academics and vendors tell operators what they 
> _must_ do on their own networks. 

Precisely why the IETF delegates this type of thing through IANA to the
RIRs.

> The Internet is successful 
> due to cooperation inspired by enlightened self-interest, not 
> central control.

Which is why there are 5 separate regional RIRs which are ultimately
controlled by the self-interested parties cooperating with each other in
each region. If the IETF states its intent for ULA-C addresses, that
does not mean there is any kind of central control.

--Michael Dillon

---

From: "Kevin Kargel" <[email-masked]>
Date: Mon, 9 Jul 2007 11:06:50 -0500

All it would mean is that the aviation industry that wanted its
"private" network would have to host a "root" DNS server for that
network and advise it's members to include it in their hints.  I don't
see that being a big issue. In fact it makes sense from a security
perspective.  

And again, with trivial ACL's the "private" network could be managed out
of PI/PA.

> -----Original Message-----
> From: Stephen Sprunk [mailto:[email-masked]] 
> Sent: Monday, July 09, 2007 9:53 AM
> To: Eliot Lear
> Cc: Thomas Narten; Mark Andrews; [email-masked]; Pekka Savola
> Subject: Re: draft-ietf-ipv6-ula-central-02.txt
> 
> >> global reverse DNS, then every org in the internetwork must hack 
> >> their local DNS servers to recognize every other org's reverse DNS 
> >> entries.  That is painful and unnecessary.
> >
> > To borrow your logic, if this space is truly private why 
> should this 
> > be an issue?
> 
> That hinges on the meaning of "private".  Imagine a private 
> internet for the aviation industry; there would be thousands 
> of players, each supposedly with their own ULA-C/G block.  
> Every player would need to hack their DNS servers to account 
> for every other player's RDNS settings, and any time someone 
> new joined or someone existing wanted to update their 
> settings, thousands of other operators would need to change 
> their hacks to keep things working. 
> The odds of that being successful in practice are so low 
> they're not worth considering.
> 
> Whoever is designated as the central authority.  It is 
> necessary for there to be a database to keep blocks unique, 
> and that database will need billing and contact information, 
> so the addition of a couple of NS entries for each block is 
> trivial.  All we're discussing now is whether that 
> information is exposed via the global DNS.
>

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 Jul 2007 16:57:32 +0000

[eliot lear]
> Having had my name on RFC 1918, I think understand some of the issues.

forgive them, eliot.  my name is on ULA-G but a lot of people (including
you, for example) still assume that i don't understand all of the issues.

> RFC 1918 not being unique meant that providers really had no choice about
> blocking it, and IANA had no method to insert reverse addresses to a
> particular site.

it's true about iana, but i still don't see that blocking 1918 is universal.
here's the packet and byte count on hkg1a.f.root-servers.net's rfc1918 rules,
38 days since the last counter reset.  i can add it all up from all 100+
f-root servers, but hong kong seems pretty representative.

00600    328489    22366217 deny ip from 10.0.0.0/8 to any in
00700     64258     4284170 deny ip from 172.16.0.0/12 to any in
00800  18840507  1240700651 deny ip from 192.168.0.0/16 to any in

as the contributor of the DNS-related paragraph near the end of RFC 1918
section 5, i can tell you that whatever the RFC says will only be a general
hint to operators and implementors, who will proceed to do whatever they
darn well want.

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 09 Jul 2007 18:04:44 +0100

Paul Vixie wrote:
[..]
> hint to operators and implementors, who will proceed to do whatever they

Can we then not make the very simple conclusion that ULA's will be
routed on the Internet and such are nothing else but an alternative for
"PI"? As such there is absolutely no reason at all to have this kind of
address space for this purpose.

Why should the IETF try to play with RIR policies where it's membership
chooses if "PI" space becomes available or not?

As I mentioned before, it should not be called "Local" in any form, as
it will never be "Local", unless the definition of "Local" is only
Earth, and does not include Mars and other planets, yet.

Greets,
 Jeroen

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 Jul 2007 17:09:02 +0000

> "PI"?

no.  i showed you packet leaks, not route leaks.  (did i misunderstand the
minimum technical skillset nec'y for participation on this mailing list?)

> As I mentioned before, it should not be called "Local" in any form, as it
> will never be "Local", unless the definition of "Local" is only Earth, and
> does not include Mars and other planets, yet.

if we're down to the label engineering, then everything hard is now done?  or
are you making a funny that's intended to show absurdity somewhere?

in any case i called it "local" in ULA-G because i was stealing wholesale from
ULA-C (and i suspect they called it "local" because they were stealing from
ULA).  if you propose a term other than "private" (which is taken by RFC 1918)
that means "non-public" in the sense meant by ULA-G and ULA-C and ULA, there
might be great rejoicing.

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 09 Jul 2007 18:25:56 +0100

> minimum technical skillset nec'y for participation on this mailing list?)

Sorry, but not everybody is fluent in the language of the networking
gods. I am pretty sure that you understood that I mean with it that
these packets are being routed, that is forwarded, over several routers.
Clearly the networks that are between your example site and the sender
don't employ any filtering at all, clearly all of your upstreams don't
do this either, though that might be simply because you will claim that
that is for 'research purposes' (which is a noble cause as otherwise we
would not be able to tell that these packets even exist).

As you mention indeed the RFC1918 routes are mostly being filtered, at
least most of the time. Check for instance RIPE's RIS which clearly
shows that RFC1918 leaks do occur. Indeed that doesn't make it globally
routed, but that they exist and happen says enough.

To illustrate my point, before being told again that I have to have a
'minimal skilset' and that they are not leaked, see the following:

http://www.ris.ripe.net/perl-risapp/prefixinuse.do?rrc_id=1000&Submit=Submit&.submit=type&sortby=time&outype=html&preftype=mspec&interval=1&prefix=10.0.0.0/8
8<---------------------------------------------------------------------
The last announcement occurred on 2007-07-05 08:31:00Z. 44 entries are
found for 10.0.0.0/8.

Prefix    	Last announced  ↓ 	Origin AS
10.20.90.0/24 	2007-06-12 09:12:16Z	23352
10.250.250.0/24 2007-06-12 09:12:16Z	23352
10.43.0.0/16 	2007-06-22 05:21:58Z	8402
10.120.0.0/16 	2007-06-22 05:21:58Z	8402
10.215.0.0/16 	2007-06-22 05:21:58Z	8402
10.35.0.0/16 	2007-06-22 05:21:58Z	8402
10.90.0.0/16 	2007-06-22 05:21:58Z	8402
10.121.0.0/16 	2007-06-22 05:21:58Z	8402
10.11.0.0/16 	2007-06-22 05:21:58Z	8402
10.138.0.0/16 	2007-06-22 05:21:58Z	8402
10.64.12.0/24 	2007-06-22 05:21:58Z	8402
10.75.0.0/16 	2007-06-22 05:21:58Z	8402
10.129.0.0/16 	2007-06-22 05:21:58Z	8402
10.3.2.0/24 	2007-06-22 05:21:58Z	8402
10.139.0.0/16 	2007-06-22 05:21:58Z	8402
10.38.0.0/16 	2007-06-22 05:21:58Z	8402
10.123.0.0/16 	2007-06-22 05:21:58Z	8402
10.74.0.0/16 	2007-06-22 05:21:58Z	8402
10.41.0.0/16 	2007-06-22 05:21:58Z	8402
10.76.0.0/16 	2007-06-22 05:21:58Z	8402
10.69.43.0/24 	2007-06-27 22:09:56Z	5410
10.69.42.0/24 	2007-06-27 22:09:56Z	5410
10.2.3.40/29 	2007-06-28 07:05:27Z	8402
10.0.0.16/30 	2007-06-28 10:00:39Z	2819
10.0.0.0/30 	2007-06-28 10:00:39Z	2819
10.0.0.20/30 	2007-06-28 10:00:39Z	2819
10.0.0.4/30 	2007-06-28 10:00:39Z	2819
10.0.0.12/30 	2007-06-28 10:00:39Z	2819
10.0.0.8/30 	2007-06-28 10:00:39Z	2819
10.10.0.0/20 	2007-06-29 04:05:58Z	8402
10.221.0.0/16 	2007-06-29 04:05:58Z	8402
10.227.0.0/16 	2007-06-29 11:50:19Z	8402
10.222.60.0/24 	2007-06-29 11:50:19Z	8402
10.222.81.0/24 	2007-06-29 11:50:19Z	8402
10.181.0.0/16 	2007-06-29 11:50:19Z	8402
10.130.0.0/16 	2007-06-29 11:50:19Z	8402
10.13.0.0/16 	2007-06-29 11:50:19Z	8402
10.69.191.0/24 	2007-07-03 15:01:27Z	5410
10.69.192.0/24 	2007-07-03 15:01:27Z	5410
10.193.14.64/27 2007-07-05 08:31:00Z	34245
10.11.12.0/24 	2007-07-05 08:31:00Z	34245
10.193.14.32/27 2007-07-05 08:31:00Z	34245
10.193.3.0/24 	2007-07-05 08:31:00Z	34245
10.11.13.0/24 	2007-07-05 08:31:00Z	34245
--------------------------------------------------------------------->8

Now please state again that people should have a 'minimal skillset'.
Thank you for your attention.

> are you making a funny that's intended to show absurdity somewhere?

Unique Local Addresses-Global <--- Local Global? Very good naming.

And it won't be local anyway as it is primarily intended to most likely
interconnect to other sites, and at that from the few examples given to
a very large amount of sites, similar to "PI" space.

> might be great rejoicing.

As I mentioned before, but clearly you missed out on, it is "Non-DFZ" or
"non-globaly-routed" maybe, as that is what, from what I understand from
the minimal amount of actual descriptions of what this address space is
going to be intended for, is the actual use.

Those cases and descriptions & examples of how this type of addresses
might actually be used are very welcome to be described in the draft
btw. As that would actually illustrate why exactly these addresses are
needed. Also having them in the draft allows one to actually discuss them.

Greets,
 Jeroen

---

From: Mark Smith <[email-masked]>
Date: Tue, 10 Jul 2007 07:36:58 +0930

On Mon, 09 Jul 2007 18:25:56 +0100

> > might be great rejoicing.

*** "INTERNAL" ***

Woohoo, I'm off to party! (at work)

---

From: bill fumerola <[email-masked]>
Date: Mon, 9 Jul 2007 16:44:18 -0700

On Mon, Jul 09, 2007 at 09:48:12AM -0500, Stephen Sprunk wrote:
> You seem to be proposing a shift in RIR policy where anyone who doesn't 
> play ball with arbitrary IETF rules get their allocations/assignments 
> revoked... Sorry, but I'm not signing that contract, nor is anyone else.  
> It'd never pass community consensus.
>
> the hands of ISPs that accept (or not) those routes.  And we do _not_ want 
> a world where some group of ivory tower academics and vendors tell 
> operators what they _must_ do on their own networks.  The Internet is 
> successful due to cooperation inspired by enlightened self-interest, not 
> central control.

AfriNIC apparently has decided they can get into the routability business
by stipulating that PIv6 space allocated must be 'announced' within a
year or it will be taken back. the first time they use that clause to
take back space, they'll have solidified that ability in their region.

power assumed is power allowed is power granted.

i agree that the routability verbiage in the AfriNIC PIv6 policy is bad
policy. i agree that each standards body and community service provider
has their place in making the the bits spin around the world properly.
i dispute that the IETF is powerless to give IANA and operators more
optionality (that they may choose to use or not use) simply because there
exists one other cat-skinning technique (depending where the cat currently
resides).

will ULA-* packets escape networks? yes. bogus packets leak out of
networks all the time. there's every reason to block packets from ULA-*
prefixes not in use by you everywhere possible as it applies to your
network.  private agreements to exchange ULA-[CG] routes between partner
companies notwithstanding.

will ULA-* routes leak? yes, but plenty of bogus routes leak now. RFC1918
prefixes, prefixes that aren't allocated, prefixes that people know "it's
ok to steal from those for internal use, since my customers will never
need routability to those prefixes", prefixes leaked out of just plain
stupidity. stopping ULA-[CG] will have zero impact on bogus routes in
the table: other efforts are addressing that, hopefully with success.

wouldn't it be nice if we could attach a contact to those leaked routes
and/or packets? it may not always be accurate, but it'd give a better
starting point than figuring out where that packet sourced 10.5.15.5
came from. i'm not saying depend on it, just that more accountability
cannot be a bad thing.

wouldn't it be nice to discuss what value ULA-[CG] prefixes could add,
instead of bringing up every possible way network addressing can be
abused.  this is the wrong forum to discuss well known abusive/bogus/broken
engineering. that can be applied to any address class.

i don't expect to change any opinions on this very religious topic. i
just hope that this doesn't get reduced to being passed back and forth
as Not Our Problem between RIRs and this WG. i hope bad RIR policies &
proposals aren't being used as examples of why this something the IETF
should stay out of.

should the I-D become standard: i hope people violently opposed to
ULA-[CG] don't use it, don't route it, don't announce it, and don't
accept announcements of it. that is the benefit of autonomous systems.
i hope people in favor of it are able to use the space in ways that help
them build the networks they want with all the possible tools and methods
available to them. used incorrectly, those operators will face all the
usual consequences of those who operate poorly run networks.

-- bill (who will stop leaking packets on the topic)

---

From: Per Heldal <[email-masked]>
Date: Tue, 10 Jul 2007 12:13:58 +0200

> no mechanism to enforce that.

<sarcasm>
What is the mechanism to force operators to carry ULA prefixes?
</sarcasm>

Scalability-issues and operator's desire to combat abuse will keep ULA
out of the DFZ. If there were no limits on inter-domain-routing and we
had the ability to verify the authenticity of every prefix announced
none of this would be an issue. Then we could all have our own prefixes
and use them as we please. Private or public. 

Until such mechanisms are in place ULA-prefixes are likely to be
rejected by the majority of transit operators. ULA-blocks split in their
individual /48s (due to incompetence, accident or malice) won't fit in
any current or near-future routing hardware nor is there a reliable
mechanism to manage exceptions on a mass-scale.

ULA-C/G might be treated equal to PI some time in the future, but not
until there's a routing architecture able to cope with true PI-for-all.
If we're really concerned about end-users shouldn't we, as long as we're
unable to solve the basic architectural problems, instead work to
eliminate the arguments supporting the use of the various forms of ULA
or even PI?
(Should renumbering still be an issue regardless of the size of a site?
Why do we let rogue domain-registries and registrars take hostages and
limit portability? etc. etc...???)

/per

---

From: Per Heldal <[email-masked]>
Date: Tue, 10 Jul 2007 12:43:46 +0200

> take back space, they'll have solidified that ability in their region.

No, the AfriNIC community incl major trasit-operators in the region have
agreed to do that. The NIC does nothing other than what its community
asks for.

Unannounced blocks (PA or PI) and other "holes" in IR-assigned ranges
should imho be limited until there are good and reliable mechanisms to
verify the origin of individual prefixes. Hence it makes sense to
implement aggressive policies to reclaim unused space and restrict
private blocks to ULA.

//per

---

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

<snip>
> least know where to look for.

think most enterprises are willing to take that chance and only use _one_ 
forward zone no mather if it will be internal or external.

I personal dont like to expose internal thing to internet but I've 
realized that the it is quite harmless from a security point of view.

> more per host and create even a bigger management hell?

heard about proxy-servers? or http-relay, or transparent proxies ? They

> Either keep it totally local or keep it totally global (thus UA).

where exactly will this extra load on the GLOBAL DNS be? maybe a how is 
better to ask. I only see one place where there will be additional 
workload and thats for the root-servers. Most of the usage of ULA-C/G are 
said to be local so the highest usage will be on the far-bottom of the 
dns-structure. Just a few cases where network interconnect will there be 
created load on the root-servers.

This suggest is just for "scaring" off people and to make it less easy to 
get global DNS for ULA-C/G, nothing else.
What if we made the system so that getting global DNS for your ULA-C/G 
prefix become optional and it will have to be requested seperatly from 
the regular way of getting those prefixes?  In practice, when you request 
a ULA-C/G you dont get asked for reverse DNS servers, you will have to do 
that somewhere else...

> Why lay that pain unto people?

what pain? I fail to see that except for the extra load mention furter up.

> Citizen and a  monopoly situation for the folks who can and the ones who

It is NOT supposed to be routed so no one should be forced to not route 
it. The real solution to this whole DMZ issue is to make PI so easy to get 
that everyone that need it can get it. Could even make the cost exactly 
the same and use the above mention not-mention-DNS during request of 
ULA-C/G to... just that alone could create that little extra touch to 
the thing whole thing and send them towards PI instead of ULA-C/G except 
for those that really really want ULA-C/G.

...

> been identified, then please just state that.

well, let ULA-C/G be the first step on this ID/LOC solution path? We will 
need it one way or another anyway...

--

---

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

On Mon, 9 Jul 2007, Eliot Lear wrote:
> Having had my name on RFC 1918, I think understand some of the issues.  There 
> is precisely one that I find at all interesting in this proposal, having 
> stated the concern in RFC 1627:
>
> But one needn't have reverse lookups delegated in the root to address this 
> concern.

correct, that is two different thing, but combined they make ULA-C very 
usefull for alot of internal network thing in any big network.

--

---

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

<snip>
> OTOH, there's no way for the IETF or RIRs to stop it from happening.  I'm not 
> saying it will, but it is irresponsible to claim it won't when there's no 
> mechanism to enforce that.

the point are to state that the purpose are NOT to be routed in the DFZ, 
not to make sure it never happen. That make-sure are upto those that use 
the address space and route it, not use as other also have stated.

<snip>
> There's no consensus yet that ULA-C/G will appear in the global DNS.  PI/PA 

that is why I state that ULA-C/G without DNS is not usable, it is a very 
usefull OPTION to have. Not something that everyone might want or want to 
use, but it is an option for those that want it...

<snip>
> PI space as by ULA space, and in some cases better by PI.

I am completly aware of that from a techincal point of view UA (PI and PA) 
vs. ULA-C/G are almost identifical. It is again the PURPOSE that are 
different, not the technical possibilities.

I would claim that the purpose part would decide what address space I 
would be using if I was about to build something.
Why is in the longer-context, right now we are making up the bricks you 
later can use for other things, like ID/LOC etc...

--

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Tue, 10 Jul 2007 09:58:52 +0100

In many RIRs the existing policies for IPv6 PA also state somehow that the
prefix need to be announced (AND aggregated) in a specific time (1 or 2
years), so this is not something new. I'm not saying it is good or bad, I
agree or disagree, just as an info.

Regards,
Jordi

> De: bill fumerola <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Mon, 9 Jul 2007 16:44:18 -0700
> Para: Stephen Sprunk <[email-masked]>
> CC: <[email-masked]>
> Asunto: Re: draft-ietf-ipv6-ula-central-02.txt
> 

**********************************************
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: Mark Andrews <[email-masked]>
Date: Wed, 11 Jul 2007 00:21:42 +1000

> created load on the root-servers.

	Wrong.  The load will not be on the root servers.  It will
	however be on the C.F.IP6.INT servers for all the active
	ULA-C blocks that do not have nameservers configured for
	them.

	There will still be leaked packets going to the root servers
	but that will be much less than the traffic going to the
	C.F.IP6.INT if there arn't delegations made.

	We know from the AS112 expriences with RFC 1918 address
	that queries will be emitted if there arn't internal zones
	configured.  We also know that the aggregate traffic will
	be large.

	The point of requesting that globally reachable nameservers
	exist is to absorb that traffic.  I expect that in most
	cases there will be multi-homed nameservers which answer
	both internal and external queries.  Once you have to setup
	a nameserver you may as well allow the zone to be populated.

	Any queries that come out of the site will get referrals
	back to these, presumably, on site nameservers.  Not that
	efficient but also not a large impact on the infrastucture
	servers.

	If the site chooses to out source the servers then I expect
	the out sourcing providers will have a variable scale
	depending upon the query load.  If a site chooses to let
	queries for on site addresses leave the site it will be
	reflected in query load and presumably price.

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

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

Thus spake "Per Heldal" <[email-masked]>
> What is the mechanism to force operators to carry ULA prefixes?

Money.

Sooner or later, we're going to run out of IPv4 space.  Let's say Ebay 
hadn't been able to get their PIv6 /41.  The only other viable way they'd be 
able to reach all of the new IPv6-only eyeballs is to use ULA-C/G addresses. 
The only way ISPs would be able to give their eyeballs access to that 
content is by accepting that route.  Voila, ULA-C/G becomes the de facto PI 
space.

Note that this scenario is one of several that caused ARIN to pass its PIv6 
policy last year.

> mechanism to manage exceptions on a mass-scale.

Routers in the DFZ are limited by the number of slots available, not by the 
length of the prefixes.  Routers don't care whether they've got a million 
/32s or half a million /32s and half a million /48s.

PI /48s do work just fine in the DFZ.  There's no reason why ULA-C/G(/L) 
/48s wouldn't work just as well.  As Jeroen showed, some ISPs can't even be 
bothered to filter 10/8 from the DFZ and that doesn't even do anything 
useful due to collisions.  Why are we expecting they'll filter ULA space 
much better, or even at all -- just because the IETF asked nicely?

S

---

From: Per Heldal <[email-masked]>
Date: Wed, 11 Jul 2007 01:04:42 +0200

> Note that this scenario is one of several that caused ARIN to pass its PIv6 

My understanding was that the dominating argument supporting PI-policies
was simply to match the capability of ipv4 ... bummer. Even back then I
thought the randomness implied with ULA would make it useless for this
purpose.

> /32s or half a million /32s and half a million /48s.

Since when did anyone argue that pfxlen affects the size of a fib-entry?

> much better, or even at all -- just because the IETF asked nicely?

I'd expect operators to implement relatively aggressive schemes for
prefix-filtering for ipv6 in their own interest to secure an environment
with stable services for their customers. 

FC00::/8 represent 2^40 /48s. With registries handing out unique
prefixes using a random algorithm to choose from the available pool how
do you pick which ones to make exceptions for and still prevent abuse?
The number of exceptions it is possible to handle will eventually be
limited by known factors such as storage for configuration and
route-filter processing capabilities.

Compare that to PI /48s (or even PA /32s) allocated _sequentially_ from
an address-block as recommended by the RIR-community. With allocations
made from a huge block your prefix filters don't need to allow more than
a fraction of that block initially. Maybe it's enough to accept the bit
that is actually used + x% for growth in the immediate future and then
add procedures for frequent updates.

To achieve operational stability it is necessary to make sure the
potential max no of prefixes given maximum fragmentation (within limits
given by RIR-policies) of currently allocated address-space doesn't
exceed the capacity of DFZ hardware, while even leaving space for TE and
local routing. General acceptance of random /48s out of a /8 doesn't fit
well in that picture and it makes ULA-C very different from PI from the
backbone operator perspective. 

//per

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 10 Jul 2007 16:32:57 -0700

Stephen Sprunk wrote:
>
> If you start with the solution, one can always find problems that it 
> solves. However, if you start with a defined problem, the solution may 
> not be what you expect.  Every example you've given so far is solved 
> at least as well by PI space as by ULA space, and in some cases better 
> by PI.

Stephen makes a good point, so maybe I'll try defining what I see as the 
problem space here.  First, I'll outline the current forms of IPv6 
addresses and some of their characteristics:

    * Provider Assigned or Provider Aggregatable (PA) addresses are
      assigned by IPv6 transit providers to their customers.  These
      addresses are *readily available* to pretty much any sized
      network,  and *globally registered* (can be looked up via WHOIS
      and DNS), but are *temporary* (assigned roughly for the duration
      of the contract with the provider).  Because these addresses come
      out of a provider aggregate, they are covered by an aggregate
      route (usually a /32), ensuring that they are *globally routable*
      (in the DFZ).
    * Provider Independent (PI) addresses are assigned by a Regional
      Internet Registry (RIR) directly to end user organizations,
      usually as /48's.  Recipients of such addresses expect to be able
      to announce their /48 to their transit providers, and expect that
      announcement to be accepted by most/all other networks providing
      Internet transit service to ensure they are *globally routable*. 
      Because of this expectation, the rules for getting IPv6 PI space
      require an organization to be running a network of several hundred
      machines and multihomed with BGP to two or more transit
      providers.  As a result, PI addresses are *not readily available*
      to all networks, but because they are not limited to the duration
      of a contract with a transit provider, they are more or less
      *permanent*.  As with PA addresses, they are *globally registered*.
    * Locally assigned Unique Local Addresses (ULA-L) are *not globally
      routable* and *not globally registered*, because they are randomly
      assigned and used by an organization.  They are extremely *readily
      available*, and *permanent* (except in the rare case of a
      collision, which is more likely to be caused by failure to follow
      the recommended assignment algorithm than by random chance).

To put it another way, here are the four pairs of characteristics, and 
the list of which kinds of space fall into each:

Readily available:        PA and ULA-L
Not readily available:    PI

Globally registered:      PA and PI
Not globally registered:  ULA-L

Globally routable:        PA and PI
Not globally routable:    ULA-L

Permanent:                PI and ULA-L
Temporary:                PA

Now an ideal new type of IP space would be *readily available*, 
*globally registered*, *globally routable*, and *permanent*.  However, 
due to the current routing architecture of the Internet, no such 
solution currently exists.  Therefore, the next best thing would be to 
have three types of IP space that each met three of the four desired 
characteristics.  (I leave out the possibility of having globally 
routable space that is not also globally registered.)  We have two of 
the three already: PA space is *readily available*, *globally 
registered*, and *globally routable*, and PI space is *globally 
registered*, *globally routable*, and *permanent*.  However, we don't 
have any sort of space that is *readily available*, *globally 
registered*, and *permanent*, because ULA-L is *not globally registered*.

As concisely stated by Paul Vixie, "ad-hoc local networking depends on 
the same global framework as public networking, for example, in-addr 
services, RPKI, and whois."  I would add that there are numerous other 
forms of private networking and internetworking that also depend on 
those services.

So, that's the problem statement: we need IPv6 addresses that are 
readily available to all applicants without discrimination, permanently 
assigned as long as the recipient continues to need the space, and that 
come with the kind of in-addr, whois, and possibly RPKI services 
provided by global registration.  I can think of at least three ways to 
solve that problem, but I'll save that for another message.

-Scott

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 10 Jul 2007 18:28:29 -0700

You may have received an answer to this already, but I am just catching up
and since you asked for help understanding, I thought I would provide some
context. 

The RIR community is being spun up that ULA-C is nothing more than PI
because some members want to retain control over who has addresses and how
much. PI is a hot issue because there is a potential impact to the global
routing system if it runs unchecked. 

ULA L or C is about a space that is not intended to show up in the global
routing system. As such it should not have the same restrictions over who
can have it that PI would have. 

Yes an organization with PI could implement an acl or simply limit the
length of the prefix that is announced to routing and have the same effect
---from their perspective---. From the perspective of the rest of the world
though, it is not clear if a PI block is intended to be globally routed or
not so they can't filter it arbitrarily. ULA has the upfront global
expectation that if it shows up it is a bogon that should be filtered. 

ULA-L is targeted at the soho router default config and organizations that
just don't want to deal with the RIRs. Their probability of collision is low
enough relative to their likelihood of multiple connections that it really
doesn't matter. 

ULA-C is about organizations that really want to have public bogon filtering
to help restrict access to a given network, but also want to ensure that
future mergers and acquisitions or partnerships that form will not have any
possibility of collision. 

This should never have been a big deal, but when all the RIRs were refusing
to allow any PI space ULA-C was seen as an end-around that policy. Even now,
only ARIN & APnic allow PI, so ULA-C is still perceived to be a problem for
the DFZ. 

My suggestion to both the RIPE and ARIN communities has been to embrace
ULA-C and give every member a ULA-C block in addition to whatever else they
ask for. If they don't own the space someone will, then there will be
competing registries and a real risk that ULA becomes PI due to easier
access or lower cost. If a ULA-C requires RIR membership, the member can
choose whatever space makes sense for their deployment and all this RIR/IETF
noise will not matter. 

Tony

> From: Kevin Kargel [mailto:[email-masked]]
> Sent: Tuesday, June 19, 2007 1:11 PM
> To: [email-masked]
> Subject: RE: draft-ietf-ipv6-ula-central-02.txt - reverse DNS
> 
> I fail to see the point of mandating non-routable space with allocated
> ULA-C.  Any network administrator has the ability and freedom to not
> route as much or as little of their PI space as they want.   Why force
> constraints on usage?
> 
> If they are going to link two physically seperated sites (into a WLAN
> or
> MLAN for example) with 'private' IP's then isn't that just access-
> listed
> PI?
> 
> Please explain to me what you could do with ULA-C that you can't do
> with
> PI and an ACL.  I really want to understand.
> 
> The only possible use I can figure is so that soho router manufacturers
> can have something to hard-code in to their LAN/DHCP defaults, but even
> then there would have to be a subnet parameter passed to the router by
> DHCP unless one was going to assume that the WAN network was the entire
> PI space.
> 
> Thanks in advance for the constructive education.
> 
> Kevin
> 
> 
> 
> 
> > From: Pekka Savola [mailto:[email-masked]]
> > Sent: Tuesday, June 19, 2007 2:41 PM
> > To: Jeroen Massar
> > Cc: Thomas Narten; Mark Andrews; [email-masked]
> > Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS
> >
> > On Tue, 19 Jun 2007, Jeroen Massar wrote:
> > > What is the point of that? How can a ULA address reach a global
> > > unicast address or for that matter, how is such a ULA
> > address, which
> > > is most likely going to be the sole user of those reverse servers
> > > going to contact any of the root servers, .arpa servers,
> > RIR servers
> > > etc to actually find out where that server is located in
> > the first place?
> > >
> > > Are those people going to do NAT from their ULA space? Then please
> > > directly kill this whole ULA proposal completely. If NAT is
> > involved
> > > in anyway it should never see daylight.
> >
> > I do not know the intended deployment scenarios, but in many
> > cases where I'd expect ULA-C migth be deployed, I'd expect
> > such sites to have some global addresses as well for v4, v6
> > or both (maybe at a different physical site, just for a
> > couple of infrastructure servers instead of all hosts, etc.)
> >
> > You're right that if a ULA(-C) site would have no global
> > addresses whatsoever, reverse-DNS delegations can't be done.
> >
> > --
> > Pekka Savola                 "You each name yourselves king, yet the
> > Netcore Oy                    kingdom bleeds."
> > Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
> >

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 10 Jul 2007 18:47:08 -0700

Lawyers and Sarbanes-Oxley type regulations drive some organizations to want
a registry that they can take to court if there is a future business-loss
due to an address collision. 

ULA has absolutely nothing to do with NAT, and all discussions about
IPv6-IPv6 NAT are a waste of time by those who want to cling to a comfort
source. People use address space in a variety of ways, and it is not
appropriate for the IETF or RIR community to tell them they can't do that.
What is appropriate is to set aside blocks that are recognizable for uses
that might have a detrimental impact on other uses. 

PI is not available to everyone because it has an impact on the global
routing system.

ULA-L is not appropriate for people with lawyers that want absolutes. 

ULA-C is not a real problem to implement, it just takes shutting down those
who want to make sure they retain control through the PI review process. 

Even those who acquire PI may want to use ULA-C to ensure that the multiple
layers of bogon filtering keep a private network private despite the best
efforts of fat-fingered network operators that are prone to typo's.

Tony

> From: james woodyatt [mailto:[email-masked]]
> Sent: Thursday, June 21, 2007 11:42 AM
> To: IETF IPv6 Mailing List
> Subject: Re: draft-ietf-ipv6-ula-central-02.txt use case
> 
> On Jun 21, 2007, at 11:03, Paul Vixie wrote:
> >
> > mark andrews has [observed] that there is no need for the
> > resolution perimeter of a PTR to differ from the routing perimeter
> > of the IP address described by that PTR.  yet here we have a large
> > set of folks who [are] telling us that yes we do need to be able to
> > resolve a PTR from places where the addresses won't be routable
> > [...]
> > what's wrong with this picture?
> 
> My heretical opinion follows.
> 
> We successfully deprecated site-local unicast addressing by painting
> it with the stink of IPv4 network address translation.  However, we
> retained the technical consensus that unreachable nodes still need to
> be uniquely addressable, and what's more: these unreachable global
> scope unicast addresses must be assigned from a registry with a
> single global root.
> 
> My heretical opinion is that the second technical consensus is
> wrong.  We should deprecate the 'L' bit in the ULA address type and
> make all ULA into locally allocated addresses.  That way, we will
> have carved off a well-known prefix (like all the other non-routable
> prefixes) where nodes are neither uniquely addressable nor reachable
> on the public Internet.  I contend the 'L' bit was never a good idea;
> it was a placeholder for those wishing to retain network address
> translation in IPv6.  There, I said it.
> 
> I view all these attempts to establish a global registry for
> allocating unreachable, yet uniquely addressable (from the public
> Internet) unicast addresses with suspicion.  Arguments about the
> unacceptability of the birthday paradox risk in an prefix designator
> space with 2^40 possible birthdays seem to be driven either by 1) a
> frightening level of innumeracy, or 2) an ulterior motive that
> proponents cannot admit publicly.  I fail to see any other
> alternatives.
> 
> It boggles my mind that so many smart people seem to believe that ULA-
> C is absolutely necessary to the operability of the IPv6 Internet.  I
> keep asking to see an explanation for why the risk of collision is
> unacceptable, and nobody seems to be able to point me toward it.  If
> what you really want is to have IPv6 NAT, then let's see the real
> arguments for why you want that.  If any of them aren't properly
> addressed in RFC 4864 and draft-ietf-v6ops-scanning-
> implications-03.txt, then let's figure out what to do about it.