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

From: [email-masked]
Date: Fri, 22 Jun 2007 10:09:56 -0700 (PDT)

> I couldn't agree more about less mystery and more transparency.
> The use-case I am most interested in is Mobile Ad-Hoc Networks
> (MANETs) in which two or more MANETs can merge (e.g., due to
> mobility). If each MANET used ULA-C's, then they could inject
> each others' prefixes into their IGPs with no opportunity for
> collision. If each MANET instead used RFC4193 ULAs, then they
> could *probably* still inject each others' prefixes. But,
> however small the risk of collision, RFC4193 ULAs still have
> one drawback that ULA-C's do not - uncertainty.

Certainty in the abstract does not equate to certainty in the
real world.

> So perhaps another question is whether it is too much to ask
> for more certainty (ULA-C) and less mystery (RFC4193 ULA)?

Personally, I am less certain about the probability of ULA-Cs
being administered such that a collision will never happen
than I am about the unlikelyhood of a collision between
randomly assigned ULAs.                       -- George Mitchell

> Fred
> [email-masked]

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 22 Jun 2007 11:05:46 -0700

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] 
> Sent: Friday, June 22, 2007 10:10 AM
> To: [email-masked]
> Subject: RE: draft-ietf-ipv6-ula-central-02.txt
> 

Yes - I have to agree with this statement.
 
> randomly assigned ULAs.                       -- George Mitchell

Would it make you feel more certain if the ULA-Cs were
self-generated by sites exactly as in (RFC4193, Section 3.2)
and then "registered" with a central authority that would
register the address as long as it is not a duplicate? I
don't think ('draft-ietf-ipv6-ula-central', Section 3.2)
currently says that, but it seems like it would result in
a scenario that is no worse than for RFC4193 yet with a
central authority accountable for certifying uniqueness. 

That said, I would be astonished if this idea has not been
entertained and debated before.

Thanks - Fred

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 22 Jun 2007 20:13:23 +0100

Templin, Fred L wrote:
> George Mitchell wrote:

You mean just like what http://www.sixxs.net/tools/grh/ula/ is doing?
Or similarly for IPv4: http://www.chiark.greenend.org.uk/cam-grin/

Debated only a teeny little bit.

The 'problem' that people have with such a mechanism (even if run by IANA)
seems to be that they 'require' reverse DNS and they want a delegation from
ip6.arpa to their nameservers.

IMHO then again, if you are requiring reverse DNS you clearly are connecting
some way or another to the at large Internet, thus then you come back to the
point of asking these folks how one can reach that at-large Internet from
those blocks that are 'local'. Saying "we will just put global unicast IPs for
the reverse DNS servers and route them inside" means you have global unicast
IPs, and I sure hope they won't change, thus clearly there is also some other
form of addresses involved there. And please don't say NAT. If one is going
the NAT way, please stick to IPv4, I don't want to program code for that.

Thus the next iteration: where do those global unicast addresses that are very
stable and can be used for reverse DNS come from? Need some "PI" folks? :)

One possible way to (partially) solve the latter would be to say "fd00::/32 is
services, fd00::53 is always a DNS server which is capable of resolving".
But that proposal of having anycasted recursive 'service' DNS servers got shot
down.

Greets,
 Jeroen

---

From: bill fumerola <[email-masked]>
Date: Fri, 22 Jun 2007 12:54:29 -0700

On Fri, Jun 22, 2007 at 08:13:23PM +0100, Jeroen Massar wrote:
> form of addresses involved there. 

why does wanting to provide PTRs for ULA-C addresses imply they have
   any sort of global connectivity? machines can reach a recursive server
   that is able to reach another ULA-C delegation's NS.

why can't the servers delegated ULA-C prefixes change addresses? i update
   my arpa delegation NS glue occasionally without problems.

why should all the partner companies who i peer with and use our collective
   ULA-C prefixes to communicate also have to setup some half-baked DNS
   "peering" (read: selective slaving) when there is a perfectly good
   way of them finding those PTR records through a decades-long proven
   service? how does slaving scale when i have hundreds of partners?

why does a host having both a ULA-C address and a global unicast address
   cause you grief? i may have entirely different routing policies for
   traffic based on their addressing (global unicast is dumped out local
   transit links, ULA[-C] to ULA[-C] addressing is carried on my backbone,
   VPN network, framerelay cloud, etc).

>                                   And please don't say NAT. If one is going

NAT boogeyman! NAT boogeyman! everyone run, the idea must be bad! (this
has nothing to do with NAT, but way to try to get blood pressure rising).

> stable and can be used for reverse DNS come from? Need some "PI" folks? :)

they can be run from servers in that org's PI allocation.
they can run their own from a PA allocation from that organization's ISP.
they can be slaved by that organization's ISP and NS pointed at the ISP.
they can come from a company (ultradns, everydns, easydns) who provides
  such services.

just like any other reverse delegation works.

if we're going to actually delegate ULA-C blocks to orgs it makes sense
to also delegate reverse to them. we always say (in RIR-land) that
addressing and routing are completely different. i'd argue that addressing
and DNS are not completely similar. don't cause people to come up with
ideas ranging from zany to stupid to dangerous to difficult when the
standard way of operating will do just fine.

giving recursive servers some NS glue for recursives to follow and go
knocking on will reduce load on the IANA/RIR run ip6.arpa NS servers.

-- 
- bill fumerola / [email-masked]

---

From: Jeroen Massar <[email-masked]>
Date: Fri, 22 Jun 2007 21:19:50 +0100

[short version: why ULA-C, when there is IPv6 "PI" space from RIRs already?]

>    that is able to reach another ULA-C delegation's NS.

Thus that recursive server is globally connected. As such hosts on the ULA-C
network are also able to resolve 'global' addresses and most likely end up
trying to send packets there and most likely one day want to connect to it
anyway as one day you might just want to use SIP from your network or do
something else than playing with your neighbors.

>    my arpa delegation NS glue occasionally without problems.

You could, but doesn't that defeat the point of having "your own global unique
space that never changes" if you have to contact an external site and have to
update those pointers all the time, causing delays in updates etc etc etc.

>    service? how does slaving scale when i have hundreds of partners?

For the same reasons that you also expect those companies to connect to the
global Internet and that they have a recursive name server and handle all
their network operations the same way you are doing.

Also you are claiming that PTR finding is done with a 'decades-long proven
service', you are correct, but that service is for Internet hosts, not for
hosts in private (RFC1918) networks.

Thus the question is: How do RFC1918-based interconnected networks nowadays
lookup these PTR records? Because that is the "decades-long proven method" you
are looking for.

Somehow I think it does not involve the Internet as it seems that RFC1918
space points to AS112.

>    cause you grief?

You might want to see one of the other replies where I actually mentioned that
this might be a possible scenario but that it might cause problems too.

> i may have entirely different routing policies for
>    VPN network, framerelay cloud, etc)

You can also make entirely different routing policies for every /64 or for
that matter, take your /48 and split it into a /49 for for local traffic and
another /49 for global traffic, filtering off one of the /49 so that it
doesn't have Internet access.

What is the difference again?

> has nothing to do with NAT, but way to try to get blood pressure rising).

Does your blood pressure rise already that you need to use exclamation marks?

> they can be run from servers in that org's PI allocation.

So they ALSO need a PI allocation next to the ULA-C allocation, wow talking
about wasting address space and doing difficult

See above, just split your /48 into two /49's. Or for that matter, request a
/47 from a RIR justifying where you need it for.

> they can run their own from a PA allocation from that organization's ISP.

You mean a PA assignment, but indeed as mentioned above: when you swap ISP's
you need to change the reverse DNS entries. Can you be offline that long?

> they can be slaved by that organization's ISP and NS pointed at the ISP.

Thus requiring you to again contact an external entity to update your stuff,
while you wanted to be totally independent of the Internet and not to forget,
more importantly from that upstream ISP. What was the point of having this
globally unique address space again? Why not use PA space?

> they can come from a company (ultradns, everydns, easydns) who provides

And thus having a very tight relationship with that organization. See above.

> to also delegate reverse to them.

> we always say (in RIR-land) that addressing and routing are completely
different.

Looking at current policies, that is far from the case.

> i'd argue that addressing

What is wrong with that PI block which you mentioned above? Does not solve all
your problems already?

> knocking on will reduce load on the IANA/RIR run ip6.arpa NS servers.

Having that space not there at all also reduces it.

ULA (RFC4193) doesn't delegate NS reverses either. Nobody seems to have an
issue with that (yet :).

Greets,
 Jeroen

---

From: bill fumerola <[email-masked]>
Date: Fri, 22 Jun 2007 15:04:51 -0700

[ replying to my own, so sorry... ]

> standard way of operating will do just fine.

correction:
"addressing and DNS are not completely dissimilar"

---

From: bill fumerola <[email-masked]>
Date: Fri, 22 Jun 2007 17:50:10 -0700

[ limiting my comments to the discussion surrounding section 4.1 ]

IFF ULA-C space is to exist and be registered/delegated, delegate the
reverse blocks for that space as well. we so often beat the "addressing
isn't routing" drum weekly. well, DNS isn't routing. DNS+ULA-C is not
an end-run around PIv6. DNS is an integral part of addressing and if
we're going to move forward with ULA-C as delegated addressing then let
us move forward with addressing in its entirety.

if organizations use a ULA-C block in their network, they shouldn't have
to special case their DNS infrastructure such that every recursive server
in their network has to slave from / forward to some special location
to get accurate answers like they do now for RFC1918 and ULA-L.

if different organizations end up routing ULA-C blocks between autonomous
networks they will already have the benefit of accurate PTR answers
without lifting a finger. resolution of a PTR record doesn't inch ULA-C
addresses any further towards being PI space, just towards adding value.

-- bill

---

From: Jeroen Massar <[email-masked]>
Date: Sat, 23 Jun 2007 12:46:14 +0100

> [ limiting my comments to the discussion surrounding section 4.1 ]

You mean avoiding the questions that people ask to your 'arguments'? :)

My main question about ULA-C still stands: how is it different from PI?

What is the advantage that it gives to The Internet, especially in the
light that it will cause that everybody on the Internet will have to
make special provisions to block this out, provide registry services
etc. Which are all already in place for the PI blocks which do exactly
the same thing.

> isn't routing" drum weekly. well, DNS isn't routing.

Without routing there is no DNS. And you are claiming to want to
disconnect the address space from the Internet. As such there is no DNS
that you can access in the first place. Or are you setting up a local
variant? If so why do you need the global one?

> DNS+ULA-C is not an end-run around PIv6.

Then what exactly is the purpose? Saying what it is not, doesn't make it
something.

> DNS is an integral part of addressing and if

So you want a disconnected address space which gets connected to the
Internet? Sorry, but that more or less really implies NAT.

As you know DNS works in two ways: forward and reverse.
You will require forward DNS servers somewhere that have your zones with
local addresses anyway, why not add the reverse ones too?
Are you publishing your forward DNS servers also on the global Internet?
I mean, when you interconnect with another company, you surely want them
to actually get the ULA-C addresses and not the ones that everybody on
the Internet uses, would you not?

I am fairly sure that security people are really happy to hear that they
'for simplicity' have their local DNS servers and the addresses
published on the Internet and accessible from that same Internet, so
that people can nicely traverse the tree and figure out which hosts are
where and find out a lot of information that they are not supposed to be
able to get as they are supposed to be for a local network.

> to get accurate answers like they do now for RFC1918 and ULA-L.

So your previous argument that "they are doing this for decades" was
false and, as I mentioned, they have actually been doing it for a long
time already using local resolvers and split-dns which works fine. It is
indeed not nice, but that is more over inherent to the simple fact that
they chose not to use The Internet in the first place.

The mere fact that you are stating that these companies will otherwise
require split DNS, simply implies that they are going to connect to the
Internet, then _why_ would you want to have those companies get an
address space that can never ever ever use that Internet. Maybe today
they don't want to use it on that Internet, but maybe next year they do.
It is really handy to be able to use SIP globally for instance.
Unless what is going to happen what will most likely going to happen: it
will become active on the Internet!?

If you don't want hosts to talk to "The Big Bad Internet": Firewall it
and as an added bonus to keep it out completely: Don't route it.

Having a DNS server sitting in both networks is not going to help there,
ever tried debugging such a setup? It is indeed a lot of fun and
consultants are very happy to be able to bill you for it.

> without lifting a finger.

They actually DO have to lift a finger: they have to configure Internet
connectivity on machines that are "officially" completely separated from
the Internet.

Lets take the example of The Pentagon* they would really enjoy a "Unique
*LOCAL* Address" Space, because then they can be completely independent
of the Internet. Now you are arguing that it would be a good thing that
they actually connect to that Internet to be able to get DNS!?

*=http://it.slashdot.org/article.pl?sid=07/06/22/021239

See the article, it is funny, though not so funny how they got in.

> resolution of a PTR record doesn't inch ULA-C

Which Value? I can also state that Coke is better than Pepsi, but why?

Also on the point where people say "but I can firewall fc00::/7 easily
and I know that only partner networks are there, while the rest is the
big evil internet", ever thought about the fact that everyone can
generate/pick a ULA address and simply use it? Which is the same as
routing global unicast addresses from a different company. You really
need to trust per prefix, not per fc00::/7 which is an awfully big
block. The security breach might not happen at your place, it just might
happen at a partner...

I am not even going into the simple fact that addresses never should be
trusted as they can still be spoofed way too easily. As such building
your 'firewall' on those assumptions is thus silly at best.

Greets,
 Jeroen

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 25 Jun 2007 07:16:59 -0700

Jeroen,

> Internet? Sorry, but that more or less really implies NAT.

I wouldn't call it a "disconnected address space which gets
connected to the Internet" but rather a "unique local address
space which gets connected to other unique local address
spaces" and IMHO I don't see any implication for NAT there.

Fred

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 25 Jun 2007 16:26:34 +0100

> spaces" and IMHO I don't see any implication for NAT there.

If you are only connecting to another ULA network, then why would one
ever need NS entries in ip6.arpa for this space?

The whole story is about having NS entries in the ip6.arpa tree for the
delegation. When you have a delegation in the Internet ip6.arpa tree,
you also need to query them one way or the other and thus you are
connecting your ULA-based network to that Internet.

Also, people will the notice that they can use reverses from the
Internet, at one point or another will also want to use SIP or various
other protocols and thus end up using the Internet, and there are two
ways to do that: NAT it or simply announce the ULA prefix, renumbering
to a PI block is of course not an option here.

As such, what is the 'local' part again, how local is it really? And how
is ULA-C then different from PI? Why bother people with this ULA-C thing
when they really need PI in the first place? Which they can already get
for $100/year from ARIN and which will be guaranteed unique, just like
all other address space from the RIR's.

Greets,
 Jeroen

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 25 Jun 2007 08:46:05 -0700

> From: Jeroen Massar [mailto:[email-masked]] 
> Sent: Monday, June 25, 2007 8:27 AM
> To: Templin, Fred L
> Cc: bill fumerola; [email-masked]
> Subject: Re: draft-ietf-ipv6-ula-central-02.txt
> 
> Templin, Fred L wrote:
> > Jeroen,
> > 

To aid in connecting to another ULA network.
 
> connecting your ULA-based network to that Internet.

Connecting to the IPv4 Internet in order to query the
ip6.arpa tree should work fine; right?
 
> to a PI block is of course not an option here.

I don't see how that follows, and I do not want IPv6 NAT.

> all other address space from the RIR's.

IMHO, a "site" can be as large as a major corporation's private
Intranet or as small as my laptop, and I don't want to have to
pay $100/yr just to connect my laptop to other sites. 
 
Fred

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 25 Jun 2007 17:00:19 +0100

Templin, Fred L wrote:
[..]
> To aid in connecting to another ULA network.

So you are able to setup routing between those two sites, but feeding
them with NS entries for your reverse is too hard? IMHO the latter is
actually much easier, just find the DNS servers for the site, presto.

> ip6.arpa tree should work fine; right?

Thus you are connecting to the Internet, using IPv4 or IPv6 doesn't
matter, you have a dependency on the Internet. As such you are not
working dis-connected from the Internet and you have a dependency on it.
I was under the impression, clearly wrongly, that people wanted ULA so
they where completely independent of the Internet with no ties there
whatsoever.

> I don't see how that follows, and I do not want IPv6 NAT.

There are a lot of networks that only where "local" and used RFC1918
because of this, then at a certain point "oeh we merge", and they had to
connect to another network (which then clashed and also caused NAT and
other weird things but that is another point). That 'other' network
sometimes was the Internet, as "oeh it is handy that we can access
google/wikipedia/etc" and instead of renumbering, lets NAT, as that is
easy quick and 'cheap', they forget though how much pain it is in the
long run.

>> As such, what is the 'local' part again, how local is it really?
>> And how is ULA-C then different from PI? Why bother people with
>> this ULA-C thing when they really need PI in the first place?
>> Which they can already get for $100/year from ARIN and which will
>> be guaranteed unique, just like all other address space from the RIR's.
> 

A site is a network of computers with a single administration, this can
mean indeed a major corporation (who maybe even require multiple /48's
which is why rfc4193 is a bit off to cover those cases)

If you want to have a /48 for your laptop, simply use ULA (RFC4193)
those are free. Or are you simply wanting to have your own IP addresses,
setting up firewalling etc because you have a laptop (or Winnebago
filled with servers) and carrying it around globally through various
buildings and making other networks accept your /48 AND force them to
connect to the Internet to be able to resolve your reverse?

Most likely anyway when you connect your laptop to another site they
will be providing you with an IP address anyway from their site prefix.

Can you clarify the use case you are sketching here a lot more as I
really want to know what actual use case is actually useful that ULA-C
solves, what PI doesn't solve (Drawings + text help). Especially now
that the folks who 'want/need' ULA-C do want to have reverse DNS
available from the Internet, while they want to be local in the first place.

All those cases can be covered perfectly fine by PI. Or is it just that
folks see ULA-C as 'very cheap PI space'?

Greets,
 Jeroen

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 25 Jun 2007 09:33:55 -0700

Jeroen, 

> Sent: Monday, June 25, 2007 9:00 AM
> To: Templin, Fred L

I didn't quite understand this, but I am not a DNS expert.

> working dis-connected from the Internet and you have a 

Only when you want to connect to another site.

> they where completely independent of the Internet with no ties there

I can't speak for the use cases other people might have
in mind.
 
> easy quick and 'cheap', they forget though how much pain it is in the

Again, *no* NAT'ing of IPv6.
 
> A site is a network of computers with a single 
> administration,

A laptop fits this description. Think of one running some
of this new virtualization support whereby there may be
many virtual machines connected up by virtual networks
running within the laptop. (Actually, folks like IBM were
doing this "new" virtualization on their mainframes back
in the 70's...) 

> this can
> those are free.

RFC4193 ULA is good, but could be better. However remote the
possibility of collisions, IMHO there would still be value in
having a 3rd-party mechanism to avoid duplicate assignments
and/or de-conflict duplicates.   

> Or are you simply wanting to have your own IP 
> addresses,

I don't quite understand this, but I want to be able to
drop my laptop down in whatever visited network and have
it connect to other sites w/o having to manually configure
explicit VPNs. 
 
> will be providing you with an IP address anyway from their 

One use I could see for that is if you needed a care-of
address such as used for MIPv6. But, that gets off onto
a completely different line of discussion.
 
> available from the Internet, while they want to be local in 

I already gave my use-case in:

http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html

a drawing is also attached (see below).
 
> folks see ULA-C as 'very cheap PI space'?

Again, I don't know about other folks but for me I see the
price as too high for some "sites" to have to pay.

Fred

---

From: "Kevin Kargel" <[email-masked]>
Date: Mon, 25 Jun 2007 11:38:12 -0500

But can't you do that perfectly well with PI or PA, firewall it as
appropriate and use regular DNS?  

Even if two "unique local address spaces" were carved out of PI or PA,
restricted from public access, and allowed to intercommunicate as a sort
of unauthenticated unencrypted private network using public DNS it still
seems that either PI or PA would suit the need very functionally.   

If it's all about renumbering avoidance, and we made an acronymn for
"Provider Independent" space I suspect we might refer to it as PI.

> From: Templin, Fred L [mailto:[email-masked]] 
> Sent: Monday, June 25, 2007 9:17 AM
> To: Jeroen Massar; bill fumerola
> Cc: [email-masked]
> > > DNS is an integral part of addressing and if we're going to move 
> > > forward with ULA-C as delegated
> > addressing then let

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 25 Jun 2007 18:08:58 +0100

Templin, Fred L wrote:
[..]

> Only when you want to connect to another site.

Thus the moment you are connecting to another site you are forcing one
to also connect to the Internet.

[..]
> Again, *no* NAT'ing of IPv6.

How are you going to use ULA-C addresses as a source and then connect to
 hosts on the global Internet?

[..]
> doing this "new" virtualization on their mainframes back

I have one of those sweet laptops and I have 3 OS's running at the same
time most of the time. I use RFC1918 and simply randomly picked
172.17.123.0/24 which has (upto now :) never collided with the networks
that I visited. ULA (RFC4193) would have that same property. I have to
note that I have to NAT that address space to the network I am at, who
only give me 1 single IP address most of the time (could use bridging
and prolly ask for more addresses per DHCP of course). Having them route
my prefix to me though everytime I walk into a Starbucks or a hotel etc
is really never ever going to happen. There is no "this is my prefix
route my traffic here" protocol (at least yet). Also no single network
operator will ever accept such a protocol as it is their network, not
that of the visitor to control. Viruses and {cr|h}ackers would love it I
guess.

When you are in the position to negotiate the routing part, then having
them turn up DNS, which has to happen for both forward (how else are
they going to locate your host) and reverse hosts is very doable.
This then nullifies the whole requirement of having NS pointers to your
servers, which have to have internet-connected and static addresses
unless you want to update them all the time, which for sure makes the
RIR happy who definitely want to have more cash then for doing that.

Or are your requiring sites you visit to have Internet connectivity as
you only have your servers (forward + reverse) on the Internet?

> and/or de-conflict duplicates.   

It exists: PI space. Get it at ARIN today: $100/year

Which if you have such a high reliability requirement for non-clashes is
very cheap and gives you the possibility to do reverse DNS and even
route it on the global internet, just in case they provide you with
transit at the site you happen to come along.

> it connect to other sites w/o having to manually configure

How are you 'automatically' telling the network to route packets for
'your prefix' to your device? See above.

> address such as used for MIPv6.

Care-of-addresses are simply the address you get per DHCP/RA.

> But, that gets off onto a completely different line of discussion.

It also has nothing to do with connecting to sites.

> http://www1.ietf.org/mail-archive/web/ipv6/current/msg07806.html

As I mentioned above, how are the routing protocols "automatically"
trusting that you own the prefix, or for that matter finding each other
in the first place. This will involve a protocol that can handle this.
When such a protocol exists you can also have it handle your reverse DNS
setup.

I fully agree that there is a need for "Unique Addresses", and these
exist already, it is called: PI.

> price as too high for some "sites" to have to pay.

Thus the only reason for ULA-C seems to be that PI is "too expensive".
Folks are always forgetting that there is a need for a lot of other
things which are way more expensive than that: the actual hardware being
used, power, maintenance, people being payed etc etc etc.

Why would the IETF have to solve the problem of having "expensive
address space" for the few who simply want it for free, by providing
address space which is only cheaper, but for the rest exactly the same
as existing solutions and in the long run will only cause people to use
it on the global Internet and thus becoming a cost factor to everybody?

Is 2^-40 probability really not enough for those sites? If they can't
cough up $100/year, then they most likely don't have a lot of hosts
actually involved and thus renumbering in the case of a collision of ULA
(RFC4193) can't be that high either. If the probability is too high for
them and the cost of renumbering is too high then PI for $100/year is
suddenly really cheap. As such, sorry, but I don't see any problem that
ULA-C will solve. I do see the problems that it will cause in the long run.

Greets,
 Jeroen

---

From: Scott Leibrand <[email-masked]>
Date: Mon, 25 Jun 2007 10:17:08 -0700

Jeroen,

PI space is *not* available, *at any price*, to small sites.

ARIN (and generally, RIR) policy for the allocation of PI space (space 
assigned directly from the RIR to end sites that they can announce into 
the DFZ) is based on the assumption that any such space, once allocated, 
can add an additional route to the BGP table of hundreds of thousands of 
routers across the globe.  Therefore, such policy must be conservative 
in handing out such blocks.

A need has been put forward for registered unique IPv6 address space 
that is not intended to be advertised into the DFZ.  One viable way to 
meet this need is with ULA-C.  Another way would be with a new class of 
"private PI" space out of a dedicated block that DFZ operators would not 
accept routes from.

If you'd like to advocate we create RIR policy for private PI space 
instead of doing ULA-C, please put forth your arguments for why it would 
be better.  Or, if you think that the need presented is too 
insignificant to be worth standardizing 
draft-ietf-ipv6-ula-central-02.txt for, fine.  But please quit telling 
us that we don't need ULA-C because we can just go get PI space today.

-Scott

---

From: Leo Vegoda <[email-masked]>
Date: Mon, 25 Jun 2007 14:12:15 -0400

On 25 Jun 2007, at 1:17pm, Scott Leibrand wrote:

[...]

> PI space is *not* available, *at any price*, to small sites.

How many of these sites that are too small to qualify for PI space  
are likely to have such a large number of inter-site connections that  
there is a credible risk that there will be an address clash?

Regards,

Leo Vegoda
IANA Numbers Liaison

---

From: Scott Leibrand <[email-masked]>
Date: Mon, 25 Jun 2007 11:22:27 -0700

Leo Vegoda wrote:
> How many of these sites that are too small to qualify for PI space are 
> likely to have such a large number of inter-site connections that 

I don't know.  I do suspect, however, that the main benefit of ULA-C 
over ULA-L will be the ability to resolve DNS, rather than the 
additional assurance of uniqueness.  Even with a relatively small number 
of inter-site connections, it is much easier to have your DNS resolvers 
(which presumably have a public IP address as well as a ULA one) walk 
the DNS tree rather than manually configuring them to slave off of each 
other site's DNS servers.  (I would compare it to doing all your 
inter-site routing with static routes instead of using a routing protocol.)

-Scott

---

From: james woodyatt <[email-masked]>
Date: Mon, 25 Jun 2007 11:55:50 -0700

On Jun 25, 2007, at 09:33, Templin, Fred L wrote:
>> mobility). If each MANET used ULA-C's, then they could inject each  
>> others' prefixes into their IGPs with no opportunity for  
>> could *probably* still inject each others' prefixes. But, however  
>> small the risk of collision, RFC4193 ULAs still have one drawback  
>> that ULA-C's do not - uncertainty.
>>
>> So perhaps another question is whether it is too much to ask for  
>> more certainty (ULA-C) and less mystery (RFC4193 ULA)?

The "no opportunity for collision" thing is really the question here,  
as Brian E. Carpenter said in <http://www1.ietf.org/mail-archive/web/ 
ipv6/current/msg07834.html> and others have said elsewhere.  Most of  
the pushback is directed at this claim that central registration has  
some hope for mitigating an already *epsilon* risk of collision.  I  
don't think simply reiterating the claim is an appropriate response  
to the legitimate rebuttal it's received.

An additional claim we've seen is that ULA-C should offer reverse  
delegations from ip6.arpa in the public DNS horizon, whereas ULA-L  
(straight RFC 4193) does not.  Your use case does not seem to me to  
support the argument for ULA-C, but actually demonstrates its weakness.

When two MANET merge by exchanging ULA prefixes (let's forget about  
ULA-C vs. ULA-L for now, because the name resolution problem is  
common to both), then their DNS horizons must be merged as well.  The  
networks are *ad-hoc*, so they do not have name servers provisioned  
with globally reachable unicast addresses.  If they did, then they  
wouldn't be *ad-hoc* mobile networks.  They'd be *provisioned* mobile  
networks.

So, the two MANET may have name servers, but if so, then they're only  
reachable at ULA addresses and they contain records that are only  
usable inside the merged MANET.  What you need to do is exchange the  
reverse delegations for the ULA prefixes at the same time you  
exchange the prefixes.  You already have to merge two private DNS  
horizons into a single private DNS horizon.  Asking for help from the  
public DNS horizon seems like a very questionable thing to propose.

Looking up the AAAA records containing ULA-C addresses for the peer  
MANET name servers in the public DNS horizon is prohibitively  
expensive for the usage scenario you're proposing.  Let me  
illustrate.  Who will operate the authoritative name servers for the  
global public 0.0.c.f.ip6.arpa domain?  How will mobile *ad-hoc*  
networks get NS records inserted into that zone?  How are they  
changed?  How will registrations be released and made available for  
reuse?  Do registrations expire if you don't pay your bills on time?   
Perhaps most importantly, how do MANET remain *ad-hoc* given such  
provisioning requirements?  All those questions seem to be pressing  
and unanswered.

(p.s. I have long contended with my colleague, Stuart Cheshire, that  
Multicast DNS could use to be extended to support organization-local  
scope multicast, precisely to support ad-hoc ULA-addressed  
internets.  Alas, there hasn't been much perception around here of  
any burning need to do it-- the subject of rendezvous points always  
comes up, and nobody has time to come up to speed on all the latest  
technical aspects of the problem.  Perhaps additional energy should  
be expended there toward those ends?)

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

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 25 Jun 2007 12:50:56 -0700

Jeroen,

I don't quite understand some of your points, so I am
not going to try to make conjectures about those. But,
I will respond to what I can below: 

> Sent: Monday, June 25, 2007 10:09 AM
> To: Templin, Fred L

The way I envision for a site to connect to another site
is via establishing one or more links between the two sites.
Having the two sites come in physical proximity with each
other (e.g., due to mobility) is one way. Establishing
tunnels between them across the Internet is another way.
  
>  hosts on the global Internet?

Not what I am proposing, and not desirable. ULA-C addresses
as source may not be compatible with global IPv6 addresses
as destination. Isn't that what source address selection
is for? I will say again that I do not support IPv6 NAT.
 
> that of the visitor to control. Viruses and {cr|h}ackers 

Having my laptop inject its ULA(-C) prefix into a visited
network's IGP seems like one alternative, and I have not
investigated the various interactions you are describing.
But, injecting the prefix may not be the only alternative
and maybe not even be the best one.

> RIR happy who definitely want to have more cash then for doing that.

This is one part that I didn't understand very well.
 
> you only have your servers (forward + reverse) on the Internet?

Nor this.
 
> transit at the site you happen to come along.

I don't know enough about ARIN/PI to know who can get it, how
much it costs, how filters could be configured to recognize it,
etc. to be able to comment. Pretty much everything I know about
it I am learning through your posts, but my off-the-cuff take
is "seems too expensive for small sites". 

> 'your prefix' to your device? See above.

It doesn't have to be through prefix injection into an IGP
of the visited network as long as there is a means to set
up an edge-to-edge tunnel between my laptop and the site I
want to connect to.
 
> It also has nothing to do with connecting to sites.

I was just responding to your assertion that obtaining a
topologically-correct address from the visited network
was "most likely" going to happen - I was only postulating
about one reason as to why that might be so.
 
> When such a protocol exists you can also have it handle your 

Edge-to-edge tunnels between sites is perhaps one way to
avoid prefix injection in the visited network.
 
> ULA-C will solve. I do see the problems that it will cause in 

I can only represent my use-case in terms of why someone might
want ULA-C; others would have to represent theirs. The only
question I see is the source address selection so as to avoid
IPv6 NAT'ing. Then again, if all your site ever does is to
connect up to other sites with edge-to-edge tunnels then there
should be no interactions between its ULAs and the DFZ.

Fred

---

From: Mark Andrews <[email-masked]>
Date: Tue, 26 Jun 2007 09:35:10 +1000

> >=20
> >=20
> >>> we're going to move forward with ULA-C as delegated=20
> >> addressing then let
> >=20

	Because sites will have *both* ULA-C and ordinary addresses.
	These sites may have private interconnects either due to
	bussiness needs or mergers or ...

	Because globally connected sites will see these addresses
	in logs, received headers etc.  Queries for these addresses will
	be made from sites without reachabilty to these addresses.

	Then there is what do we do with all the reverse queries coming
	from sites that have failed to intercept the reverse queries.

> connecting your ULA-based network to that Internet.

	Not necessarially.  Full disconnected sites will just maintain
	their own C.F.IP6.ARPA registry.
 
> to a PI block is of course not an option here.

	Why are you assuming a IPv4 solution to a IPv6 problem.  If you
	have global reachability you will have global addresses.

	The anwer to how to talk to the Internet is to use a address with
	global scope.
 
> --------------enigA4239CC2518F4B232378ACE5
> Content-Type: application/pgp-signature; name="signature.asc"
> Content-Description: OpenPGP digital signature
> Content-Disposition: attachment; filename="signature.asc"
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.7 (MingW32)
> Comment: Jeroen Massar / http://unfix.org/~jeroen/
> 
> iHUEARECADUFAkZ/3q4uFIAAAAAAFQAQcGthLWFkZHJlc3NAZ251cGcub3JnamVy
> b2VuQHVuZml4Lm9yZwAKCRApqihSMz58I+i9AJwLWj1LkB4GArEMWLj9WI+6jf8V
> rgCgpOKskF+TzmhR+6NMycHte3Cq6os=
> =V6C5
> -----END PGP SIGNATURE-----
> 
> --------------enigA4239CC2518F4B232378ACE5--
> 
> 
> --===============0375020143==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============0375020143==--
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Geoff Huston <[email-masked]>
Date: Tue, 26 Jun 2007 10:01:39 +1000

james woodyatt wrote:
>>> others' prefixes into their IGPs with no opportunity for collision. 
>>> If each MANET instead used RFC4193 ULAs, then they could *probably* 
>>> still inject each others' prefixes. But, however small the risk of 
>>> collision, RFC4193 ULAs still have one drawback that ULA-C's do not - 
>>> uncertainty.
>>>
>>> So perhaps another question is whether it is too much to ask for more 
>>> certainty (ULA-C) and less mystery (RFC4193 ULA)?
> 
> The "no opportunity for collision" thing is really the question here, as 
> Brian E. Carpenter said in 
> <http://www1.ietf.org/mail-archive/web/ipv6/current/msg07834.html> and 
> others have said elsewhere.  Most of the pushback is directed at this 
> claim that central registration has some hope for mitigating an already 
> *epsilon* risk of collision.  I don't think simply reiterating the claim 
> is an appropriate response to the legitimate rebuttal it's received.

Depends on what level of "collision risk" you are happy with, and this 
depends on the scenario where you are assessing that risk.

- you pick a number from a pool, I pick a number from a pool, then we 
compare numbers - chance of collision = 1 / pool size

- a set of us pick numbers from a pool, and we compare numbers. The 
probability that two or us have picked the same number is the case where 
  a random draw function exceeds 0.5  after 1.24 million random draws. 
The general solution of the probability of a collision after d draws 
from n possible values is given by:

       P = 1 - ((n!) / ((n**d)((n-d)!)))

Given that the value for n here is 2.199,023,255,552, then the objective
is to find the lowest value of d for which P is greater than or equal
to 0.5. In this case the value for d  is some 1.24 million.

i.e. if we all pick numbers and stuff them into the DNS, then by the 
time the 1,240,000 selection had taken place the probability that a 
collision has occurred exceeds 0.5

regards,

     Geoff

---

From: james woodyatt <[email-masked]>
Date: Mon, 25 Jun 2007 18:07:13 -0700

On Jun 25, 2007, at 17:01, Geoff Huston wrote:
>
> i.e. if we all pick numbers and stuff them into the DNS, then by  
> the time the 1,240,000 selection had taken place the probability  
> that a collision has occurred exceeds 0.5

That's only a problem for people who have to pick a number that  
collides with absolutely none of the other 1,240,000 numbers.  I  
think no one will ever have to do that, and *moreover* I think that  
anybody who *does* think they'll have to do that has some explaining  
to do before we worry about their problem.

Who's going to do that, and why?  By the way, that is *NOT* a  
rhetorical question.  I really want to know the answer.

---

From: Bill Manning <[email-masked]>
Date: Mon, 25 Jun 2007 18:58:43 -0700

> to 0.5. In this case the value for d  is some 1.24 million.

	and this is based on a true random selection, yes?
	and we KNOW that humans are good at selecting truely
	random numbers. e.g.  "whats your favorite number between
	1 and 2,199,023,255,552? ...  that would be 42."

> collision has occurred exceeds 0.5

	to Geo... the collision occurs at the point of intersection,
	be it when these sites interconnect or when they share a common
	namespace.

>     Geoff

--bill

---

From: Scott Leibrand <[email-masked]>
Date: Mon, 25 Jun 2007 19:39:51 -0700

Apparently people are still having a hard time visualizing use cases for 
ULA-C, so let me try again to lay one out:

Let's say I build a somewhat ad-hoc wireless mesh network covering a 
residential area to provide Internet service.  For my Internet 
connectivity, I get service from several different ISPs, each of which 
gives me an IPv6 subnet (PA space).  As this is a wireless network based 
on inexpensive hardware often deployed in a residential setting (and 
possibly involves some mobility), I can't count on any portion of my 
network to maintain reachability to any particular ISP uplink.  In 
addition, I am likely to change ISPs over time, and I'm too small to 
qualify for PI space, so I choose to number my internal network 
infrastructure out of private (ULA) space.  In parallel, I also use 
DHCP, DHCP-PD, etc. to assign subnets of my various PA space to users on 
various portions of my network (thereby giving them IPv6 address(es) of 
whichever Internet uplinks are available to them).  (I may also use some 
form of DHCP to assign PA space to my router interfaces, or I may choose 
to hide that detail by doing my mesh networking below layer 3, or I may 
choose to use ULA space there and rewrite the source address of any 
ULA-sourced packets leaving my network for the Internet.)

Now let's say I am thinking a little bit bigger than just my 
neighborhood, and would also like my network to connect to neighboring 
mesh networks.  (This could fairly easily evolve into an arbitrarily 
large internetwork enabling disaster-resistant connectivity across 
neighborhoods, cities, or entire regions.)  In order to facilitate 
troubleshooting, I elect to use ULA-C space for my network 
infrastructure, including router interfaces, (and either rewrite source 
addresses of any packets (presumably ICMP) my routers send out to the 
Internet, or also assign PA space to each interface with something like 
DHCP-PD, so that the router can use IPv6 address selection to use a 
public address for packets destined for public Internet addresses).  As 
before, I would give out PA subnet(s) to users for Internet 
connectivity, but I might also elect to give them ULA addresses to 
communicate with other hosts on my mesh network and neighboring ones.

In a situation like this, I need to be able to resolve PTRs for hosts 
using my neighboring networks' ULA space without any prior knowledge 
about the neighboring wireless network.  If both networks are numbered 
out of ULA-C space, this is easy: I send my PTR queries to my regular 
DNS resolver, which has a PA address and Internet connectivity, and can 
resolve the PTR from the DNS server authoritative for my neighboring 
wireless network's ULA-C block.

So, again, I see that ULA-C is a very simple solution to fill a very 
useful function that cannot be filled by local ULAs alone (at least 
without adding additional complexity to DNS).  Importantly, this 
functionality does not depend on ULA-C providing an additional assurance 
of uniqueness, but on the fact that my block (and its authoritative DNS 
servers) can be registered, and others can query the registered data.

As IPv6 adoption takes hold and dynamic wireless networking becomes 
cheaper and more widespread, I would see this kind of use case, and its 
many permutations, becoming more and more common.  Can you describe a 
way to use existing address types available to small networks (PA and 
ULA-L) and existing DNS technologies to support the requirements listed 
above?  If not, I would argue that we should complete the process of 
ULA-C standardization, as it represents the simplest available solution 
to the problem.

-Scott

---

From: Geoff Huston <[email-masked]>
Date: Tue, 26 Jun 2007 14:00:37 +1000

james woodyatt wrote:
> That's only a problem for people who have to pick a number that collides 
> with absolutely none of the other 1,240,000 numbers.  I think no one 
> will ever have to do that, and *moreover* I think that anybody who 
> *does* think they'll have to do that has some explaining to do before we 
> worry about their problem.
> 
> Who's going to do that, and why?  By the way, that is *NOT* a rhetorical 
> question.  I really want to know the answer.

What I said above was "and stuff them into the DNS" i.e. when you have 
an environment that uniqueness is indeed critical and the number cannot 
collide with any other. i.e. IF you use the DNS for these numbers THEN 
this is a relevant issue.

clear yet?

And before you leap into "I'm never going to use the DNS, so whats the 
problem?" please also note that I'm not saying that putting these 
addresses into the DNS is good, bad or indifferent. What I was 
attempting to point out is that the factors that contribute to the risk 
of a collision depend on the nature of the environment where the numbers 
are used. One can hide in a small closet, lock the door, and in this 
little dark world of just you in your locked closet '1' is an entirely 
reasonable choice for a unique number. In other environments its 
probably a pretty poor choice!

---

From: Paul Vixie <[email-masked]>
Date: Tue, 26 Jun 2007 05:12:56 +0000

> ...

thanks.

> So, again, I see that ULA-C is a very simple solution to fill a very useful
> function that cannot be filled by local ULAs alone (at least without adding
> additional complexity to DNS).  Importantly, this functionality does not
> depend on ULA-C providing an additional assurance of uniqueness, but on the
> fact that my block (and its authoritative DNS servers) can be registered,
> and others can query the registered data.

if you want registration, then you want a new kind of RIR PI space, since it
has to be unique, and the registration data has to be made and kept accurate.

> ...
> Now let's say I am thinking a little bit bigger than just my neighborhood,
> and would also like my network to connect to neighboring mesh networks.

i like this vision, it matches my own.

> (This could fairly easily evolve into an arbitrarily large internetwork
> enabling disaster-resistant connectivity across neighborhoods, cities, or
> entire regions.)

yes.

> In order to facilitate troubleshooting, I elect to use ULA-C space for my
> network infrastructure, including router interfaces, (and either rewrite
> source addresses of any packets (presumably ICMP) my routers send out to the
> DHCP-PD, so that the router can use IPv6 address selection to use a public
> address for packets destined for public Internet addresses).

i was almost going to snort beer out my nose at how funny that was, until the
millisecond when i realized that you didn't know it was funny to say "in order
to facilitate troubleshooting" and then follow with that description of rube
goldbergesque complexity.  why did you leave out the part where the anvil that
had been launched a few moments earlier finally, inevitably, lands on the
coyote's midriff?

but we (both) digress from the real point:

> In a situation like this, I need to be able to resolve PTRs for hosts using
> my neighboring networks' ULA space without any prior knowledge about the
> neighboring wireless network.

which wouldn't be nec'y if both of these networks were in some new kind of PI
space that was allocated out of a prefix designated by IANA for non-DFZ use.
(i keep bringing the discussion back to that point because asking IANA to
designate such a prefix ought to be the IETF's reaction to the ULA-C draft.)

but i still digress, let's get to the meat of it:

> If both networks are numbered out of ULA-C space, this is easy: I send my
> PTR queries to my regular DNS resolver, which has a PA address and Internet
> connectivity, and can resolve the PTR from the DNS server authoritative for
> my neighboring wireless network's ULA-C block.

here you're equating, dangerously in my opinion, three unrelated concepts:

	1. "public internet"
	2. "PA address"
	3. "internet connectivity"

please re-think this in terms of "connectivity realms", of which the DFZ is
one, and the american automotive exchange is another, and every fortune-2000
internal network is another, and every ad-hoc wireless mesh is another.  in
these terms, you'd have successfully pointed out that a given host may be in
more than one connectivity realm, and that it's impossible to know in advance
whether a network peer you reach in realm A can reach the same realm B that
you can reach.  now take it one step further -- stop according the DFZ any
special status, treat it as just another connectivity realm to which any
given network peer of yours may or may not have access.

> As IPv6 adoption takes hold and dynamic wireless networking becomes cheaper
> and more widespread, I would see this kind of use case, and its many
> permutations, becoming more and more common.

me too.

> Can you describe a way to use existing address types available to small
> networks (PA and ULA-L) and existing DNS technologies to support the
> requirements listed above?  If not, I would argue that we should complete
> the process of ULA-C standardization, as it represents the simplest
> available solution to the problem.

i see ULA-C as a giant rubber band and some rocket powered roller skates
which will finally, really, we mean it this time, allow the coyote to catch
that darn roadrunner.

the simpler solution is to recognize the following primary facts of reality:

1. every host needs a lan-scoped address
2. most hosts also need one or more global-scoped addresses
3. each of those global-scoped addresses will be in some connectivity realm
4. many of those connectivity realms will transitively, invisibly, overlap
5. the DFZ or "public internet" isn't special, it's just a connectivity realm
6. of all connectivity realms, the DFZ may not always be the largest one
7. all global-scoped addresses need ongoing reliable DNS and WHOIS support
8. address DNS/WHOIS support is traditionally a regional, bottom-up function

if we can get agreement on those, then the resulting conclusions are easy.

---

From: Christian Huitema <[email-masked]>
Date: Mon, 25 Jun 2007 22:28:51 -0700

> addresses into the DNS is good, bad or indifferent.

What about "indifferent"?

Suppose that we pre-populate the ip6.arpa tree with synthetic name
server records, so that the name server for a given ULA prefix
<ula-48>::/48 (ULA-C or not) always resolves to <ula-48>::1 (or any
other suitably chosen anycast host identifier). Then DNS look-up will
always point to the closest instantiation of that anycast address, or to
nothing at all if the prefix is not reachable. Voila, DNS look-up
without any central registration...

-- Christian Huitema

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 26 Jun 2007 10:59:36 +0100

> without any central registration...

I almost proposed that, BUT, that breaks the whole point that some
people are using ::1 or ::53 or whatever magic constant for something
else already. People tend to use the first subnet on their LAN already.
It would indeed 'solve' the problem given here, but only partially as
you still don't have the really important bit: Forward resolving. How is
one magically going to tell where to find microsoft.com? Both have the
same root :(

I once proposed a 'well known anycasted DNS server address', so that we
can always say 2001:db8::53 and 192.0.2.53 are DNS. The 'local' DNS
server is simply the closest one found in the routing tables. ISP's can
then simply route this to their recursive nameservers and presto, no
configuration of that part needed. Unfortunately, only one such root can
exist in a network, if you join two networks you still have to tell both
networks where forward + reverse servers exist.

Greets,
 Jeroen

---

From: Leo Vegoda <[email-masked]>
Date: Tue, 26 Jun 2007 08:08:00 -0400

On 25 Jun 2007, at 10:39pm, Scott Leibrand wrote:

> Apparently people are still having a hard time visualizing use  
> cases for ULA-C, so let me try again to lay one out:

[...]

> In addition, I am likely to change ISPs over time, and I'm too  
> small to qualify for PI space,

It seems that if you qualified for PI space you wouldn't want ULA-C  
space. Is that right?

-- 
Leo Vegoda
IANA Numbers Liaison

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 26 Jun 2007 13:54:33 +0100

Leo Vegoda wrote:
>> Apparently people are still having a hard time visualizing use cases
>> for ULA-C, so let me try again to lay one out:
> 
> [...]
> 
>> In addition, I am likely to change ISPs over time, and I'm too small
>> to qualify for PI space,
> 

Most of the times, from what I understand. But one case was raised where
it would 'be easy to filter out ULA and distinguish from Internet
space', thus a site would have 2 prefixes: "Local" using ULA and
"Global" using PI. Which IMHO would only run into a lot of problems and
even more complexity etc. It is at least a case which has been
mentioned, but if anybody would actually ever use that. Especially with
the "we do IPv4 like this thus we do IPv6 like that also" mindset that
will not be a common network setup I guess.

Greets,
 Jeroen

---

From: james woodyatt <[email-masked]>
Date: Tue, 26 Jun 2007 12:39:55 -0700

On Jun 25, 2007, at 22:28, Christian Huitema wrote:
> other suitably chosen anycast host identifier). Then DNS look-up  
> will always point to the closest instantiation of that anycast  
> address, or to nothing at all if the prefix is not reachable.  
> Voila, DNS look-up without any central registration...

On Jun 26, 2007, at 02:59, Jeroen Massar wrote:
> It would indeed 'solve' the problem given here, but only partially  
> as you still don't have the really important bit: Forward resolving.

I like the idea of asking IANA to define an anycast address for  
synthetically populating <global-id>.0.0.d.f.ip6.arpa domains with  
matching NS and AAAA records for the ULA-addressed name servers.   
Resolvers could easily implement this rule and reduce the load on the  
public DNS servers.  I think the concern about forward resolution and  
split horizons is orthogonal, and it should be deferred.  There is  
only one horizon required for reverse DNS resolutions of global scope  
addresses.

I also like the idea of asking IANA to reserve a prefix for RIR's to  
allocate for non-DFZ use.  That effectively addresses the perceived  
need for a registry to mitigate the risk of birthday paradox  
collision with ULA.

I'd like to see drafts for both of these (alas, I don't have the time  
to write them myself).  In the process of revising RFC 4193 for the  
reverse DNS magic, we should also return fc00::/8 to IANA and  
eliminate the 'L' bit, which I'm on record as saying I think was a  
bad idea from the start.

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 26 Jun 2007 17:38:17 -0700

>> ULA-C, so let me try again to lay one out:

And thank you for your thoughtful and reasoned response.

> has to be unique, and the registration data has to be made and kept accurate.

Yeah, to me that's what ULA-C should be, a block of space defined by the 
IETF, delegated by IANA to the RIRs, and administered as "unique local" 
or "private PI" space.  I don't care whether we call it ULA-C and 
allocate it out of FC00, or if we call it private PI and chose a 
different subnet.

> but we (both) digress from the real point:

I'm not sure which aspects of what I outline you would consider 
unnecessarily complex, but I agree that is tangential to our discussion, 
so we can follow that up offline if you like.

> but i still digress, let's get to the meat of it:

I'm not sure this is a digression.  What you're describing is exactly 
what I think ULA-C should be: a well-known block (that DFZ operators 
would filter announcements from) from which PI assignments can be made 
without the restrictions required on public PI space to avoid routing 
table bloat.

> given network peer of yours may or may not have access.

While I agree with this analysis in the abstract, and would not opposed 
a private PI policy based on it (as it would likely be quite robust), 
I'm not sure that we can simply see the public Internet as just another 
connectivity realm.  I believe that the history of the Internet, and the 
architecture we have built up to support it (particularly the addressing 
architecture, as defined by the IETF and delegated from IANA to the RIRs 
to ISPs and to end sites), require that we consider the public Internet 
to be a unique connectivity realm.

> 1. every host needs a lan-scoped address

Link-local.  Done.

> 3. each of those global-scoped addresses will be in some connectivity realm

Agreed.

> 6. of all connectivity realms, the DFZ may not always be the largest one

Perhaps not, especially depending on your definition of "largest".  
However, any connectivity realm that approaches the public Internet in 
terms of the number and diversity of interconnected participants will 
require an addressing and routing framework to meet the various needs of 
its different participants in a mutually acceptable manner.  As long as 
we're talking about IPv6, that addressing framework will need to coexist 
with the addressing framework of the public Internet.  Given the current 
Internet addressing architecture, that means we need some way to 
partition off part of the IPv6 address space, designate it as "not to be 
routed in the DFZ", and assign pieces of that space to anyone wishing to 
internetwork in a connectivity realm other than the DFZ.

> 8. address DNS/WHOIS support is traditionally a regional, bottom-up function

Agreed, which is why I advocate that ULA-C space (or whatever we end up 
calling the space that fills the needs described above) be assigned to 
Regional Internet Registries (RIRs), who can then assign it to end users 
and provide appropriate DNS and WHOIS support.  I would also support 
allowing the RIRs to allocate such non-DFZ-routed space to Local 
Internet Registries (LIRs), so that they can serve their 
members/customers by reassigning such space and providing DNS and/or 
WHOIS services in a method (and possibly a connectivity realm) not 
served by the RIRs directly.

> if we can get agreement on those, then the resulting conclusions are easy.

Given our slightly differing opinions on the special significance of the 
"public Internet" connectivity realm, I would love to hear what 
conclusions you draw based on the above points.  I would draw the 
following conclusions:

    * There is a need to allocate and assign IPv6 address space, in a
      non-restrictive manner, to entities wishing to internetwork
      outside of the public Internet's DFZ.
    * There is a need to provide reliable DNS and WHOIS support for
      these addresses.  The methods of providing such DNS support should
      include, but should not be limited to, allowing registrants to
      delegate DNS authority to servers reachable from the public
      Internet.  Other methods for providing reliable DNS support for
      these addresses should be explored, but no method should be
      allowed which imposes an undue burden on Internet DNS infrastructure.

-Scott

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 26 Jun 2007 23:48:05 -0500

Thus spake "Scott Leibrand" <[email-masked]>
>> which wouldn't be nec'y if both of these networks were in some
>> new kind of PI space that was allocated out of a prefix designated
>> by IANA for non-DFZ use.  (i keep bringing the discussion back
>> to that point because asking IANA to designate such a prefix
>> ought to be the IETF's reaction to the ULA-C draft.)
>>
> I'm not sure this is a digression.  What you're describing is
> exactly what I think ULA-C should be: a well-known block (that
> DFZ operators would filter announcements from) from which PI
> assignments can be made without the restrictions required on
> public PI space to avoid routing table bloat.

If this is what we mean by "private PI", then I'm against that too. 
Dressing up ULA-C with a different prefix and name but retaining all of the 
operational stupidity doesn't solve any problems.    A turd by any other 
name smells just as foul.

If we want to issue address space to folks for "private" use, it needs to be 
out of the same block(s) that the RIRs use to allocate space for "public" 
use, because sooner or later those "private" networks are going to end up 
being publicly routed.

If we are concerned that giving "real" PI space to every org that asks for 
it will result in the immediate death of the DFZ, then there needs to be 
some sort of tag attached to blocks that says whether or not the registrant 
has met whatever the current rules are for deserving a routing slot.  If 
routing certificates ever take off, they could contain a flag that gives the 
current public routability status, or the RIR could just not issue a 
certificate at all if someone hasn't met the bar.  That's an entirely 
separate matter from whether or not they get addresses.

One could also argue that the RIRs do not belong in the routability decision 
path at all, since their job is to ensure uniqueness, and some other 
quasi-public entity responsible for the health of the DFZ would produce 
"routability" certificates.  That also gives rise to the possibility of 
different models than we have today, like a market where people could buy 
and sell routing slots.

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: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jun 2007 13:00:49 +0200

Scott, you say

> In a situation like this, I need to be able to resolve PTRs for hosts using my neighboring networks' ULA space

Why do you need to do this?

     Brian

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 27 Jun 2007 12:15:02 +0100

Brian E Carpenter wrote:
>> using my neighboring networks' ULA space
> 

The need can be seen, but the big question is: why does one need it in
the *global* root.

If one is in a non-Internet-connected setup, you will have to also setup
DNS for the, IMHO way more important, forward zones. If one can manage
that, then setting up the reverse is just an extra line in the config.

When one argues "yes but I don't want split DNS and it needs to be in
the global DNS", then simply don't opt for *local* addresses.

Either the ULA-C space is *local* or it is *global*. When it is global,
then you need what the RIR's dub PI. If you can't get PI for your use,
then talk to the RIR's and define a new policy there.

One thing that can be accomplished by the ULA-C draft is to update the
ULA draft, deprecating the L/G bit, making that bit part of the random
pool (letting folks simply select it themselves) and defining that the
reverse in the global root should point to the AS112 servers.

Greets,
 Jeroen

---

From: "Kevin Kargel" <[email-masked]>
Date: Wed, 27 Jun 2007 09:31:31 -0500

I keep thinking that all of this sounds like people looking for default
solutions to custom problems.  If you want to have a custom connection
between specific private networks there will necessarily be some custom
configuration.  A plug-and-play solution just will not work without
adding rediculous layers of complexity to the method.

Early network and protocol designers worked very hard to keep K.I.S.S.
as a basic principle.  Lower complexity will of course mean reduced
functionality, but it also means increased reliability and easier
healing.

It is sort of like the operating system on your workstation..  if you
want to preload every possible driver for every possible piece of
hardware that is certainly possible, and may even make things easier for
someone.  It will also make everyone's system requirements huge,
increase boot time drastically, affect performance and add many
administrative requirements for patches and updates.

The basic network protocols should be as simple as absolutely possible,
with the minimum core set functionality required.  If end users want
added features then they need to figure out how to do that within the
protocol framework.

I have yet to see a consensus that ULA-C is a basic required capability,
though I have seen cases explained where it would be useful to a small
number of users.  The decision to make is whether the benefit to the few
who would take advantage of it is worth the cost to the rest of the
world.

The problem I see with having small ULA-C allocations is that as people
move around geographically those allocations will lose aggrebility.
Until everyone in the world has big iron routers (When you want to send
me mine for free I will be happy to accept it) many or most network
administrators will be forced to filter small routes to protect their
route processors.  This may also apply to the root DNS servers.  They
too must have some limit of routes they can serve.

> From: james woodyatt [mailto:[email-masked]] 
> Sent: Monday, June 25, 2007 8:07 PM
> To: IETF IPv6 Mailing List
> That's only a problem for people who have to pick a number 
> that collides with absolutely none of the other 1,240,000 
> numbers.  I think no one will ever have to do that, and 
> *moreover* I think that anybody who *does* think they'll have 
> to do that has some explaining to do before we worry about 
> their problem.
>

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jun 2007 16:55:19 +0200

On 2007-06-27 16:31, Kevin Kargel wrote:
...
> move around geographically those allocations will lose aggrebility.

I don't understand your comment. No ULA prefix aggregates ever - they
will always be specific routes, and ULA-C is no different in that respect.

     Brian

---

From: Scott Leibrand <[email-masked]>
Date: Wed, 27 Jun 2007 11:26:08 -0700

> Why do you need to do this?

For all the same reasons I need to resolve PTRs of hosts on the 
Internet.  I'm a network engineer, so my main reason for wanting PTRs is 
for traceroute, but I'm sure anyone running a server serving the 
neighborhoods would also like to be able to resolve information about 
the IPs of connecting clients, etc.

-Scott

---

From: Paul Vixie <[email-masked]>
Date: Wed, 27 Jun 2007 22:04:02 +0000

(headers trimmed)

> From: Scott Leibrand <[email-masked]>
> 
> Paul Vixie wrote:
> > please re-think this in terms of "connectivity realms", of which the DFZ
> > is one, and the american automotive exchange is another, ..., and every
> > ad-hoc wireless mesh is another.  ...
> 
> ... I'm not sure that we can simply see the public Internet as just another
> architecture, as defined by the IETF and delegated from IANA to the RIRs to
> ISPs and to end sites), require that we consider the public Internet to be a
> unique connectivity realm.

assume for a moment that FC00::/16 becomes reserved for "non-public internet"
due to actions by IETF, IESG, and IANA; assume furthermore than some RIRs ask
IANA for /32 slice of this and adopt policies allowing their members to request
/48 allocations.  assume that fred templin gets one for his laptop and manages
to speak a routing protocol with every wireless cloud operator he sits in, so
that for each of those AS's, his /48 is "reachable" by other folks in the same
AS.

what would stop these wireless cloud operators from privately peering with
each other and turning off the filter that we all hope normally prevents FC00
routes out of BGP?  we know they will want to do this, just as they want to
share RADIUS and towers -- it makes the wireless world appear to be more
unified and means more revenue for everybody.  now assume that someone like
ISC or CENIC is present at a peering exchange and one of these wireless ISP's
solicits a BGP relationship with us.  would they want to send us their FC00
/48's?  you betcha!  would we want to take them?  you betcha!

the only time these /48's aren't likely to be accepted or offered is by a
transit provider.  in private peering relationships, they'll be seen as a
value-add by most peers.

which connectivity realm is the "public" one in that scenario?  is it the one
that includes more reachable places?  or the one we _call_ the "public" one?

> ..., any connectivity realm that approaches the public Internet in terms of
> the number and diversity of interconnected participants will require an
> addressing and routing framework to meet the various needs of its different
> participants in a mutually acceptable manner.

the wonderful thing about the internet is that plans don't matter.  what exists
is whatever a lot of people decide to do.  for a lot of people, accepting /48's
from their peers will make good "cost:benefit sense".  for others, not so much.
so, address space in FC00::/16 will not be as reachable by some as by others,
and thus won't be as valuable as other address space that's more universally
reachable.  however, to call it "private" is an exceptional misnomer.  it'll be
advertised among consenting networks, and it will work for a lot of users and
a lot of applications.  when it doesn't work, all heck will break loose, just
like today when "public" address space goes unreachable for some people.  

> As long as we're talking about IPv6, that addressing framework will need to
> coexist with the addressing framework of the public Internet.  Given the
> current Internet addressing architecture, that means we need some way to

we can designate it any way we want.  let's designate it however we have to
designate it in order to start using it.  then we'll find out the real facts,
because real users will do real things.  if the DFZ must be ostensibly defended
from two million /48 end site announcements, then let's ostensibly defend it.
however, just privately, just among the smallish subset of folks who read this
mailing list, we all know that the DFZ fiction will simply get more fictional.

to the meat, then:

> and provide appropriate DNS and WHOIS support.

ok by me.

> I would also support allowing the RIRs to allocate such non-DFZ-routed space
> to Local Internet Registries (LIRs), so that they can serve their members /
> customers by reassigning such space and providing DNS and/or WHOIS services
> in a method (and possibly a connectivity realm) not served by the RIRs
> directly.

also ok by me.

> ... I would draw the following conclusions:
> 

i'd say "from both its own connectivity realm and from the DFZ" where you've
said "the public internet" above, but otherwise, i can live with that summary.

---

From: [email-masked]
Date: Wed, 27 Jun 2007 14:15:47 -0400 (EDT)

I totally agree with Stephen and others than regardless of original
intent 'private' PI routes will end up public, whether by intention down
the road, by accident, or by hi-jacking.  It strikes me that the way to
address this is after the allocation process by means of routing
authentication only - RADB and it's ilk now, certificates later maybe. 
Call me naive but I thought a key factor in v6 deployment is that there
is enough to go round so NAT / PA will not be forced onto organizations
that don't want it - surely it's enough of a burden to get PI space,
manage it in RADB/DNS, setup BGP, pay an ISP to receive your
advertisements (there's a whole other choke point here where ISPs can
institute their own policies on what is reasonable).

  I'm young and inexperienced compared to many of you I know, but I can't
see the IPv6 table being < 300K routes in a few years, but neither can I
see it being double that - whilst I see some pent up demand for
multi-homing using PI space, I also see many people who will continue
using NAT in IPv6 because that's their security guys dogma (it isn't
mine & I'm not interested in that whole discussion again).  It will
continue to require a degree of clue to participate in the global table,
and if people need to announce their aggregates to make things work
that's a lesson they will learn (or that their ISPs will share/force
upon them)

Regards

Simon Hamilton-Wilkes

> On Tue, 2007-06-26 at 23:48 -0500, Stephen Sprunk wrote:
> But if we do this shouldn't we also take steps to prevent abuse
> (hijacking etc) of those "private" blocks. History has shown that
> unannounced PI-blocks that nobody is missing can be abused for a long
> time before anybody cries foul. We may have made a hash of v4, but
> shouldn't have to make the same mistake from the start with v6. Maybe
> RIRs should announce "private" or otherwise "quarantined" blocks from a
> special AS so that they can easily be identified and filtered ...
> although they'd end up wasting space in the DFZ (whatever that is;).
>
> ... which is closely related to the following:
>>
> Until there's a reliable mechanism to verify the origin of a prefix all
> we can do is try to cope through policies. Is the lack of
> route-certificates an excuse to not try to do something about the
> problem in the meantime?
>
>
>>
> Isn't that like calling for a "global internet constitution"?
>
> What about a mechanism to establish some form of "common ground" on
> which routing-policy-decisions can be made. To "navigate" the world of
> routing an allocation-policies today is like navigating an aircraft
> without the ability to adjust the altimeter for varying air-pressure.
> There are too many inconsistent and independent sources of information
> with widely varying quality and formats. Things would be easier if
> inter-domain-routers were required to form a relation to
> address-registries for all network-domains in which they wish to operate
> (normally ARIN + RIRs + possibly private) in addition to whatever
> routing policies each operator choose to implement (in reality they
> already do but the quality that information tend to vary a lot with
> operator clue). Registries would then have to announce the allocation
> policies (blocks and prefix-lengths) through standardised formats and
> mechanisms/protocols available globally. Address-space that is not
> covered by a policy would by definition be unused (hence the need for
> separate bogon-filtering and the related debogonizing-issues would be
> mostly eliminated).
>
> Combine this with:
>
> - A strong recommendation from address registries to announce aggregates
> for optimum visibility/routability (note: _recommendation_ not
> _requirement_). In reality this is just a formalisation of current
> practise.
>
> - Standards which must require IDR implementations to never drop
> aggregates even if the available set of more-specifics cover the entire
> block specified by the allocation policy. A 3rd party might choose to
> ignore the smaller blocks and would loose "visibility" without the
> aggregate. (note: path selection algorithms based on
> longest-prefix-match would not be affected).
>
> (- Maybe even a BGP node should be able to tell its peer(s) that it
> doesn't want to receive routes more specific than allocation policies.
> Although it might be hard to ensure that different ASes conform to the
> same allocation policies.)
>
>
> With such a thing in place one would at least have a fair chance of
> knowing how local routing-policy decisions might affect routability. Now
> you can safely ignore TE-churn from distant networks while choosing to
> accept more specifics from peers and others in your "neighbourhood" and
> still feel reasonably confident that you're not loosing anything
> important.
>
> In a better world that has route-certificates and unlimited
> IDR-scalability this makes no sense, but will we get there in time to
> avoid trouble.
>
>
> //per
>
> _______________________________________________
> This message sent to you through the ARIN Public Policy Mailing List
> ([email-masked]).
> Manage your mailing list subscription at:
> http://lists.arin.net/mailman/listinfo/ppml
>

---

From: Per Heldal <[email-masked]>
Date: Wed, 27 Jun 2007 13:54:33 +0200

Combine this with:

//per

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jun 2007 10:00:09 +0200

> the IPs of connecting clients, etc.

The L in ULA means local. If you can *see* your neighbours' ULA prefixes,
they have become local to you, so I agree you will need their AAAA and PRT
records in your local DNS. If you use ULAs this way, you have added scope
boundaries in the DNS that must correspond to the routing scope boundaries
for ULA prefixes.

I don't think anything called Local should be used this way, but that's
an operational choice. It still doesn't mean that global DNS needs to know
anything about these prefixes. RFC 4193 seems correct to me.

      Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jun 2007 10:12:40 +0200

On 2007-06-27 13:54, Per Heldal wrote:
> (hijacking etc) of those "private" blocks. 

No, I don't think so. ULAs are for local use. We provide a mechanism
to ensure that they are extremely likely to be unique, but as long as
they are used locally, and confined locally both by routing and by
DNS, it actually doesn't matter operationally if someone else uses the
same prefix in their local area.

     Brian

---

From: Per Heldal <[email-masked]>
Date: Thu, 28 Jun 2007 10:46:26 +0200

> same prefix in their local area.

I wasn't talking about ULA at all, but about an attempt to limit abuse
of PI or even PA space whenever such blocks are allocated but not
announced externally. Whether allocated PI is used for private purposes
by accident or intentionally doesn't matter in that respect. ULA is no
problem as it's trivial to block all of it with one single
config-statement.

The rest of my rant was about my wish to formalise and automate the
relation between allocation policies and operational practises. I.e. why
keep pretending registry-policies have nothing to do with routing when
so many IDRs in the DFZ has a config full of stuff derived from those
policies?

//per

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 28 Jun 2007 10:53:59 +0200

> problem as it's trivial to block all of it with one single

Then we agree, but please change the Subject when you change the subject :-)

     Brian