Subject: Fwd: [[email-masked]: [arin-announce] ARIN Board Advises Internet Community on Migration to IPv6]

From: Fred Baker <[email-masked]>
Date: Mon, 21 May 2007 08:36:54 -0700

Begin forwarded message:

> From: [email-masked]
> Date: May 21, 2007 7:38:28 AM PDT
> To: [email-masked]
> Subject: [[email-masked]: [arin-announce] ARIN Board Advises  
> Internet Community on Migration to IPv6]
>
>
>
> 	this might be of interest to the operator community.
>
> --bill
>
> --------- forwarded ---------------
>
>
> ARIN and the other Regional Internet Registries have distributed
> Internet Protocol version 6, IPv6, alongside IPv4 since 1999.  To  
> date,
> ARIN has issued both protocol versions in tandem and has not advocated
> one over the other. ARIN has closely monitored trends in demand and
> distribution for both protocol versions with the understanding that  
> the
> IPv4 available resource pool would continue to diminish.
>
> The available IPv4 resource pool has now been reduced to the point  
> that
> ARIN is compelled to advise the Internet community that migration to
> IPv6 is necessary for any applications that require ongoing  
> availability
> from ARIN of contiguous IP number resources.
>
> On 7 May 2007, the ARIN Board of Trustees passed the following  
> resolution:
>
> RESOLUTION OF THE BOARD OF TRUSTEES OF ARIN ON INTERNET PROTOCOL
> NUMBERING RESOURCE AVAILABILITY
>
> WHEREAS, community access to Internet Protocol (IP) numbering  
> Resources
> has proved essential to the successful growth of the Internet; and,
>
> WHEREAS, ongoing community access to Internet Protocol version 4  
> (IPv4)
> numbering resources can not be assured indefinitely; and,
>
> WHEREAS, Internet Protocol version 6 (IPv6) numbering resources are
> available and suitable for many Internet applications,
>
> BE IT RESOLVED, that this Board of Trustees hereby advises the  
> Internet
> community that migration to IPv6 numbering resources is necessary for
> any applications which require ongoing availability from ARIN of
> contiguous IP numbering resources; and,
>
> BE IT ORDERED, that this Board of Trustees hereby directs ARIN  
> staff to
> take any and all measures necessary to assure veracity of applications
> to ARIN for IPv4 numbering resources; and,
>
> BE IT RESOLVED, that this Board of Trustees hereby requests the ARIN
> Advisory Council to consider Internet Numbering Resource Policy  
> changes
> advisable to encourage migration to IPv6 numbering resources where  
> possible.
>
> Implementation of this resolution will include both internal and
> external components. Internally, ARIN will review its resource request
> procedures and continue to provide policy experience reports to the
> Advisory Council. Externally, ARIN will send progress announcements to
> the ARIN community as well as the wider technical audience, government
> agencies, and media outlets. ARIN will produce new documentation, from
> basic introductory fact sheets to FAQs on how this resolution will
> affect users in the region. ARIN will focus on IPv6 in many of its
> general outreach activities, such as speaking engagements, trade  
> shows,
> and technical community meetings.
>
> For more information visit the IPv6 Information Center at:
> http://www.arin.net/v6/v6-info.html.
>
> Regards,
>
> Raymond A. Plzak
> President and CEO
> American Registry for Internet Numbers (ARIN)
>
>
> ----- End forwarded message -----

---

From: bill fumerola <[email-masked]>
Date: Mon, 21 May 2007 11:40:48 -0700

> >Internet Community on Migration to IPv6]

that angry mob you see in the distance is the arin-ppml mailing list
heading over to v6ops to discuss ULA-central.

you've been warned. :)

-- billf(@freebsd.org|powerset.com)

---

From: Fred Baker <[email-masked]>
Date: Mon, 21 May 2007 12:35:56 -0700

On May 21, 2007, at 11:40 AM, bill fumerola wrote:
> that angry mob you see in the distance is the arin-ppml mailing  
> list heading over to v6ops to discuss ULA-central.

Maybe you could fill me in on why it is an "angry" mob? v6ops has not  
been asked to be involved in the discussion, and has not prevented it  
from happening. v6ops didn't define the ULA - ipng did. To my  
knowledge, the operational community has not even seen fit to post  
their proposal where v6ops can see it, notwithstanding the fact that  
I have invited them to do so and to use v6ops@ to discuss it. Why  
would they be angry with us?

If you're suggesting that at the coming IETF it might be worthwhile  
to entertain the proposal, given an internet draft I would be willing  
to see that happen.

Speaking strictly for myself, I would ask a few questions. One is why  
one wants to have central allocation of a local address. Not that I  
am opposed to having it (RFC 4193 clearly sets aside part of the  
address space for such), but I would like to understand the argument.  
Related is how a centrally-managed unique global address differs from  
a centrally-managed unique local address; they both look centrally- 
managed and unique to me. If the argument is that BGP will not  
advertise and will not accept a peer's advertisement of a ULA, that  
is true if and only if the appropriate filters are in place, so the  
locality of the address seems pretty similar. One still needs to have  
correct filters. The third is why this needs to be a managed space  
per se. If the desire is for a space that can be used within an ISP  
network and is guaranteed to not overlap that of any routing peer,  
placing the 32 bit AS number into the upper bits of the "Global ID"  
gives each provider a /40 to play with, with no effort on the IANA's  
part. Why not just do so?

---

From: bill fumerola <[email-masked]>
Date: Mon, 21 May 2007 17:36:40 -0700

[ i'm /not/ part of the angry mob :) ]

> would they be angry with us?

they're angry but not to my knowledge at v6ops.

some are angry at folks trying to run around IETF process by submitting
proposals direct to the RIRs.

some are angry at ipng for not giving more guidance on how ULA Central
should be managed.

some are angry that there's no form to fill out RIGHT NOW GIMME GIMME
so they can get their own chunk of ULA-C space.

> address space for such), but I would like to understand the argument.  

well, i think by creating two seperate spaces in RFC4193:3.2 and leaving
it open for future interpretation, people are going to crave direction
if they actually have a use for the space or not. which is why we see
policy proposals in the RIRs on how to manage the space before the space
has really even been defined.

> correct filters. 

companies merge and partner and connect networks together on vague 'site'
lines. maybe some folks worry about colliding (though they shouldn't).

i think that a lot of this has to do with people wanting a backdoor
around PI unicast space. if it's registered somewhere official i can
point to, i can convince someone to route it on my behalf. regardless
of what 4193 says about global routability. note: i'm not supporting
this sort of subversion, but i think it's one way of looking at it.

> The third is why this needs to be a managed space  

this seems like the most reasonable way of distributing ULA that i've
read. apologies if that idea has been around for a while and i'm only
now just hearing it.

if it weren't for the non-routability requirement of the ULA space, i
think this would solve a lot of people's PI v. sub-allocated concerns.

using the 32 bit AS as a key in the some other unicast allocation pool
instantly gives anyone with an AS an allocation. that seems like a nice
way to kickstart PI space. albiet it does get in the way of the RIRs
ability to charge for the unicast space IANA has already assigned them,
but i'm not sure how important that is.

apologies if any of my thoughts here are old hat, i'm new to v6ops.

-- bill

---

From: Fred Baker <[email-masked]>
Date: Mon, 21 May 2007 18:00:52 -0700

> read. apologies if that idea has been around for a while and i'm only

I have no idea if anyone else is discussing it either. I just work  
here... :-)

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 22 May 2007 09:43:04 +0200

> I have no idea if anyone else is discussing it either. I just work  

Go talk to a multi6 survivor...

The problem is that one size never fits all so many ASes will get  
such a block and never use it, and since this is supposed to be  
private space, many people who want it won't have an AS number. Not a  
good idea, IMO.

The problem is that the randomly generated ULA blocks still hold the  
potential for clashes upon mergers, and people are bitten by that  
with RFC 1918 space so they're not prepared to take a one-in-2^40  
risk. Or more likely, the risk that the randomization rules aren't  
followed properly. Another advantage of ULA-c is that it's possible  
to get the reverse DNS delegated, which can be helpful.

So why don't we implement a way for people to get centrally assigned  
ULAs? The simple way to do this is to sell prefixes of a suitable  
size (I'm thinking 20 bits worth) to people who are prepared to run a  
registry for further distribution. In practice, this means that  
pretty much everyone who sells domains will be selling ULA-cs, too.  
Simple, easy.

---

From: Shane Kerr <[email-masked]>
Date: Tue, 22 May 2007 10:18:13 +0200

All,

On Mon, May 21, 2007 at 12:35:56PM -0700, Fred Baker wrote:
> If the desire is for a space that can be used within an ISP network
> and is guaranteed to not overlap that of any routing peer,  placing
> the 32 bit AS number into the upper bits of the "Global ID"  gives
> each provider a /40 to play with, with no effort on the IANA's

Using a 32-bit AS number as the basis of an address makes a lot of
sense. It doesn't really solve the "missing RFC 1918" problem for IPv6
though. Anyone who can get an AS number can get a /32 from an RIR, so
there's not much motivation for this type of private space. (Note, I'd
fully support a draft that outlines the 32-bit AS address space idea.)

There are already at least two ways to get unique local IPv6 blocks
today:

1. get a /48 from someone with an RIR allocated block (of course)

2. take an IPv4 address and convert it to a 2002::/48 block

In the case of #1, you can either use your own block, or get some
sort of guarantee from the organization you got it from that they
won't hand it out to someone else.

And you *can* use the pseudo-random ULA from RFC 4193, which anyone
who understands probability will be quite okay with. (The chances that
*you* will ever connect to another network that chose the same ULA are
really, really small. In fact the chances are really small that
*anyone* will ever have a collision are very small, if we assume that
these networks are not highly connected.)

I really think ULA is a solution looking for a problem.

--
Shane

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 May 2007 13:08:09 +0200

On 2007-05-22 09:43, Iljitsch van Beijnum wrote:
...
> ULAs? The simple way to do this is to sell prefixes of a suitable size 
> (I'm thinking 20 bits worth) to people who are prepared to run a 
> registry for further distribution. In practice, this means that pretty 
> much everyone who sells domains will be selling ULA-cs, too. Simple, easy.

No need to create a market in integers. We can surely invent a robot
to allocate and escrow pseudo-random 40 bit numbers at negligible cost,
and therefore set up a free service.

     Brian

-- 
NEW: Preferred email for non-IBM matters: [email-masked]

---

From: Fred Baker <[email-masked]>
Date: Tue, 22 May 2007 08:46:18 -0700

> I really think ULA is a solution looking for a problem.

I half agree.

Bottom line, a ULA is a private address - an address that one can use  
to identify internal things that people outside don't need to know  
how to route to. It differs from site-local, which it replaced, in  
what I consider a relatively minor way: there is potentially a  
different administration-local for every site, maybe multiple such.

This is eminently doable with global space; one simply doesn't  
advertise a portion of one's global space outside one's own shop.  
Yes, that depends on having the right filters all around one's  
periphery; so does the ULA. The big advantage of the ULA, as near as  
I can tell, is that it is a filter everyone has agreed to, not only  
"do not advertise" but "do not accept advertisements of".

I can think of lots of good reasons for administration-local  
addressing. Internal servers, loopback addresses of routers,  
switches, and other network elements, anything one doesn't want  
external things reaching is a good place to use an administration- 
local address. So a ULA is in some respects a solution to the  
administration-local addressing problem that we all agree to.

If we're going to manage them centrally, though, a lot of that  
disappears. If someone outside can predict that I am using a given  
ULA, and they can figure out how to present one to my edge router,  
then I have to not only not advertise the ULA to my peer but defend  
against datagrams bearing the address at my firewall. That pretty  
much puts us back where we are right now. At that, I scratch my head.

It would be really good, if we want to discuss this, to have an I-D  
to discuss.

---

From: Thomas Narten <[email-masked]>
Date: Tue, 22 May 2007 12:00:54 -0400

> It would be really good, if we want to discuss this, to have an I-D  

I'm looking at doing this with some others. Stay tuned.

Thomas

---

From: james woodyatt <[email-masked]>
Date: Tue, 22 May 2007 10:51:18 -0700

On May 22, 2007, at 00:43, Iljitsch van Beijnum wrote:
>
> ...so they're not prepared to take a one-in-2^40 risk...

How do they breathe?

> Another advantage of ULA-c is that it's possible to get the reverse  
> DNS delegated

Why on Earth would anyone want to delegate the public reverse DNS for  
addresses that aren't supposed to be reachable outside their private  
DNS horizon?

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

---

From: bill fumerola <[email-masked]>
Date: Tue, 22 May 2007 11:09:19 -0700

> and therefore set up a free service.

someone already has:

http://www.dnsstuff.com/tools/rfc4193.ch

-- bill

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 May 2007 01:39:49 +0200

[Bounced earlier today - excuses if it's a duplicate]

On 22-mei-2007, at 13:08, Brian E Carpenter wrote:

>> So why don't we implement a way for people to get centrally  
>> assigned ULAs? The simple way to do this is to sell prefixes of a  
>> suitable size (I'm thinking 20 bits worth) to people who are  
>> prepared to run a registry for further distribution. In practice,  
>> this means that pretty much everyone who sells domains will be  
>> selling ULA-cs, too. Simple, easy.

> and therefore set up a free service.

True. However, a small incentive against using up space unnecessarily  
is probably a good idea, and having to track payment is the best  
possible incentive for keeping good records. If there is also reverse  
DNS involved this looks almost identical to the domain name business  
so why not reuse a model that has proven successful in the past?

In any event, in my opinion, it's important to keep the RIRs out of  
this, because they're not equipped to deal with individual users on  
the scale that may be required, and having ISPs give out private  
space the same way they give out public space makes even less sense.

---

From: Christian Huitema <[email-masked]>
Date: Tue, 22 May 2007 23:18:23 -0700

> > and therefore set up a free service.

If I created such a service, I would do something along the lines of
crypto-generated addresses, e.g. something like crypto-generated
prefixes, where the prefix is the SHA-256 hash of a public key, the name
of the domain claiming it, and a "salt" string. Of course, ULA-c only
leaves 40 bits to allocate, so for safety reasons you will require that
the hash ends with the claimed 40 bits, and starts with a string of N
zeroes. If two companies claim the same 40 bit strings, whichever has
the lower hash wins. Simple, allows for distributed registries, etc...

-- Christian Huitema

---

From: Gert Doering <[email-masked]>
Date: Wed, 23 May 2007 09:08:56 +0200

Hi

On Wed, May 23, 2007 at 01:39:49AM +0200, Iljitsch van Beijnum wrote:
> the scale that may be required, 

I haven't seen word from any of the RIRs that this might be an issue.

Gert Doering
        -- NetMaster
-- 
Total number of prefixes smaller than registry allocations:  113403

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (89) 32356-444            USt-IdNr.: DE813185279

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 May 2007 10:23:19 +0200

On 2007-05-22 19:51, james woodyatt wrote:
> addresses that aren't supposed to be reachable outside their private DNS 
> horizon?

Bingo. In the real world, most candidates for using ULAs have been
running split DNS for years, and the ULA boundary will coincide
with the DNS boundary. Any context in which a ULA will be used
"off site" (e.g. over a VPN) will also need the "on site" DNS.

This is current practice with IPv4, made messy by the ambiguity
of RFC 1918. All ULAs do is clean up that mess.

      Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 23 May 2007 10:28:10 +0200

> http://www.dnsstuff.com/tools/rfc4193.ch

I prefer
http://www.kame.net/~suz/gen-ula.html
because it lets me enter my own 802 address, but yes - the only thing
to be added is an escrow file so that the exact same ULA never gets
issued twice, and a throttle to prevent DOS.

     Brian

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 May 2007 12:08:25 +0200

On 23-mei-2007, at 10:23, Brian E Carpenter wrote:

>>> Another advantage of ULA-c is that it's possible to get the  
>>> reverse DNS delegated

>> Why on Earth would anyone want to delegate the public reverse DNS  
>> for addresses that aren't supposed to be reachable outside their  
>> private DNS horizon?

> running split DNS for years,

Split DNS is a very dirty hack, we shouldn't promote that. See the AS  
112 project for how well stuff that's supposed to be internal stays  
internal.

> and the ULA boundary will coincide

Simple solution: automatically delegate the DNS for ULAs to two  
addresses inside the ULA block in question and everything that leaks  
out is redirected back inside. This can also work with hash-generated  
ULAs, though, if someone can build a DNS server that and generate the  
required records on the fly. And it could apply to 6to4, RFC 1918...

---

From: james woodyatt <[email-masked]>
Date: Wed, 23 May 2007 12:48:47 -0700

On May 23, 2007, at 03:08, Iljitsch van Beijnum wrote:
> Split DNS is a very dirty hack, we shouldn't promote that.

Strange.  Section 4.4 of RFC 4193 seems expressly to prohibit-- with  
a normative "MUST NOT"-- the sending of reverse ULA-to-name queries  
to name servers operating in the global DNS horizon.  How are we  
supposed to use them *without* splitting from the public DNS horizon?

While I'm on the subject... doesn't IETF already prohibit recursive  
DNS resolvers operating in the global DNS horizon to follow name  
server delegations through names that have no AAAA records with  
globally routable addresses in them?  If not, then I'd call that an  
oversight.

Also, I think RFC 4193 could be a little stronger.  It should  
prohibit DNS servers operating in the global DNS horizon from sending  
recursive responses containing AAAA records with ULA in them, and it  
should require DNS resolvers operating recursively in the global DNS  
horizon to ignore all AAAA records containing ULA in them.

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Wed, 23 May 2007 22:42:22 +0200

[CCing dnsop just in case they haven't had this discussion a million  
times before]

> Strange.  Section 4.4 of RFC 4193 seems expressly to prohibit--  
> with a normative "MUST NOT"-- the sending of reverse ULA-to-name  
> queries to name servers operating in the global DNS horizon.

I'm quickly reaching the point where I don't even care about RFCs  
claiming authority over stuff like this.

With IPv6, we wanted to get back to a single address space, where  
there may not be universal reachability, but there IS universal  
addressability, i.e., it doesn't change with your vantage point. But  
by including language like this we get to _address_ the entire IPv6  
internet, which is good, but we don't get to _name_ it regardless of  
vantage point, which is bad.

> How are we supposed to use them *without* splitting from the public  
> DNS horizon?

Good question. I hope the authors of RFC 4193 are asking themselves  
exactly that.

Split DNS is a really, really bad idea, because it's very hard to  
control the flow of DNS requests in a non-trivial network, and any  
leaks create problems that persist for a long time because of caching.

And what about the situation where companies X and Y have a VPN  
tunnel between them so their ULA networks are linked. Setting up  
routing for this is trivial (unless you run out of RFC 1930 private  
AS numbers) but how would this work DNS-wise? This gets real complex  
real fast if you can't touch the root servers for ULA addresses.

> globally routable addresses in them?  If not, then I'd call that an  

What's the use of forbidding (prohibiting has the connotation of  
implied successfulness) something that happens all the time and isn't  
going to stop?

---

From: james woodyatt <[email-masked]>
Date: Wed, 23 May 2007 14:51:53 -0700

On May 23, 2007, at 13:42, Iljitsch van Beijnum wrote:
> AS numbers) but how would this work DNS-wise? This gets real  
> complex real fast if you can't touch the root servers for ULA  
> addresses.

Obviously, I can't look up your name servers for  
$YOUR_ULA_PREFIX.ip6.arpa in the global DNS horizon.  You have to  
provide them to me when we merge our networks, and I have to  
configure my DNS resolving proxies to use them instead of the global  
DNS when looking up names for nodes in your prefix.  Furthermore, I  
already need to configure my resolving proxies to search your DNS  
horizon if I want to resolve names for the addresses in your ULA  
prefix, and I don't particularly want to disclose the names of  
addresses in my ULA prefixes on the global DNS horizon, so you're  
going to have to do the same as me.

This is just a fact of life with IPv6 VPN and ULA.  If I connect my  
home network up to the Apple network through a VPN tunnel, I expect  
all my lookups for Apple-internal DNS names to resolve properly, and  
they won't if I'm only searching the global DNS horizon.  This  
virtual private DNS horizoning already works fine with IPv4 VPN  
tunnels.  There's no reason to think it won't just carry forward  
naturally into IPv6 VPN tunneling, so I fail to see the big deal.

> implied successfulness) something that happens all the time and  
> isn't going to stop?

That which is not forbidden is easily made mandatory. <smiley/>

If recursive resolvers operating in the global DNS horizon are  
permitted to follow delegations to name servers on ULA prefixes, then  
those delegations cannot be guaranteed to resolve to the same name  
servers everywhere.  Is that something we think resolvers are now  
doing all the time?  ...that we believe isn't going to stop?  ...that  
we think isn't an abomination against all that is hallowed in the  
name of the Internet Society?

Why do resolvers need to do this, and why can't they be made to stop?

Look at it this way: a prohibition would serve to define the  
boundaries of the global DNS horizon better, making it the  
responsibility of the resolver to search only one horizon recursively  
at a time, i.e. a recursive search that begins at the global DNS root  
MUST NOT leave the global DNS horizon.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 24 May 2007 11:26:55 +0200

On 2007-05-23 23:51, james woodyatt wrote:
>> And what about the situation where companies X and Y have a VPN tunnel 
>> between them so their ULA networks are linked. Setting up routing for 
>> this is trivial (unless you run out of RFC 1930 private AS numbers) 
>> but how would this work DNS-wise? This gets real complex real fast if 
>> you can't touch the root servers for ULA addresses.
> 
> provide them to me when we merge our networks, and I have to configure 
> my DNS resolving proxies to use them instead of the global DNS when 
> looking up names for nodes in your prefix.  Furthermore, I already need 
> to configure my resolving proxies to search your DNS horizon if I want 
> to resolve names for the addresses in your ULA prefix, and I don't 
> particularly want to disclose the names of addresses in my ULA prefixes 
> on the global DNS horizon, so you're going to have to do the same as me.

I think this demonstrates very clearly why repeating that split DNS is evil
will get us nowhere. Split DNS is very widely used, so (like RFC 1918 and NAT)
its evilness has to be dealt with. And no, I don't think that's easy.

    Brian

> This is just a fact of life with IPv6 VPN and ULA.  If I connect my home 
> network up to the Apple network through a VPN tunnel, I expect all my 
> lookups for Apple-internal DNS names to resolve properly, and they won't 
> if I'm only searching the global DNS horizon.  This virtual private DNS 
> horizoning already works fine with IPv4 VPN tunnels.  There's no reason 
> to think it won't just carry forward naturally into IPv6 VPN tunneling, 
> so I fail to see the big deal.
> 
> If recursive resolvers operating in the global DNS horizon are permitted 
> to follow delegations to name servers on ULA prefixes, then those 
> delegations cannot be guaranteed to resolve to the same name servers 
> everywhere.  Is that something we think resolvers are now doing all the 
> time?  ...that we believe isn't going to stop?  ...that we think isn't 
> an abomination against all that is hallowed in the name of the Internet 
> Society?
> 
> Look at it this way: a prohibition would serve to define the boundaries 
> of the global DNS horizon better, making it the responsibility of the 
> resolver to search only one horizon recursively at a time, i.e. a 
> recursive search that begins at the global DNS root MUST NOT leave the 
> global DNS horizon.
> 
> 
> --