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

From: Mark Andrews <[email-masked]>
Date: Tue, 19 Jun 2007 09:16:38 +1000

4.1 DNS Issues

   AAAA and PTR records for centrally assigned local IPv6 addresses may
   be installed in the global DNS.  This may be useful if these
   addresses are being used for site to site or VPN style applications,
   or for sites that wish to avoid separate DNS systems for inside and
   outside traffic.

   The operational issues relating to this are beyond the scope of this
   document.

	We have to be *very* careful here.  If we allow PTR's to
	be installed in the global DNS then globally reachable
	nameservers *have* to exist for each prefix allocated.
	Otherwise the problems that the AS112 project is trying to
	deal with will appear here as well.

	This is a long term operational cost associated with ULA-C.

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

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

---

From: Thomas Narten <[email-masked]>
Date: Tue, 19 Jun 2007 11:23:27 -0400

> 	This is a long term operational cost associated with ULA-C.

Well, please expand on this so we can discuss in more detail.

My assumption is that some (but not all) ULA-C holders will want to be
able to have PTR records. This seems operationally useful to me, for
those that choose to use them and place them in the public DNS
tree. Thus, we shouldn't ban it outright. That is, the question is
whether the RIRs then would need to support the creation of such
records for registered ULA-C owners.

And help me understand how this equates to the AS112 issues. For sites
that (today) get PI space and don't actually advertise it to the
internet, aren't the DNS issues _exactly_ the same?

Thomas

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 19 Jun 2007 16:54:36 +0100

Thomas Narten wrote:
[..]
>> 	This is a long term operational cost associated with ULA-C.
[..]
> internet, aren't the DNS issues _exactly_ the same?

When the prefix is 'local' why would that need to be rooted into the global
Internet? I get the point about having unique addresses out of the same
namespace, but I don't get why reverses then have to be supplied too.

Which leads to the point I wanted to ask:

 How is ULA-C different from PI?

Yes, the prefix it comes from is different, which allows 'easy filtering'.
But do you suddenly trust fc00::/7 more than global unicast?

Also, unless there is a considerable (important) portion of the Internet
that will not accept ULA-C prefixes, or the ULA-C prefix in question has a
lot of value, this will become a routing mess as people will start
announcing them and using them where possible. PA is also being chopped up
by some who are announcing /48's already and even tricks like getting a /31
and announcing two completely separate /32's without the aggregate /31.

The draft is more or less okay IMHO. But the big question is if it is really
needed when there is PI already that can be used for this same purpose.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Jun 2007 22:14:13 +0300 (EEST)

> internet, aren't the DNS issues _exactly_ the same?

IMHO, if reverse DNS is provided, it should be required that the 
authoritative DNS servers have non-ULA addresses.  I think Mark was 
assuming that ULA address for authoritative delegation point might be 
OK, which would lead to issues if the ULA address is not reachable 
from everywhere where reverse DNS lookups should succeed.

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 19 Jun 2007 20:28:24 +0100

Pekka Savola wrote:
> OK, which would lead to issues if the ULA address is not reachable from
> everywhere where reverse DNS lookups should succeed.

What is the point of that? How can a ULA address reach a global unicast
address or for that matter, how is such a ULA address, which is most likely
going to be the sole user of those reverse servers going to contact any of
the root servers, .arpa servers, RIR servers etc to actually find out where
that server is located in the first place?

Are those people going to do NAT from their ULA space? Then please directly
kill this whole ULA proposal completely. If NAT is involved in anyway it
should never see daylight.

Also, registered the DNS servers in the global DNS thus means that those
machines will be Internet connected, then what is the point of ULA again?

Another point here is that when there will be ULA registrations in the
reverse tree, then there will also be ULA AAAA's in the forward tree, oh boy
we are going to have a nice mess there...

I really can't see how 'registering DNS servers in the global root' is going
to be beneficial to having 'local' address space. It will only wreak a lot
of problems and cause people to do NAT.

Greets,
 Jeroen

---

From: Pekka Savola <[email-masked]>
Date: Tue, 19 Jun 2007 22:41:02 +0300 (EEST)

> should never see daylight.

I do not know the intended deployment scenarios, but in many cases 
where I'd expect ULA-C migth be deployed, I'd expect such sites to 
have some global addresses as well for v4, v6 or both (maybe at a 
different physical site, just for a couple of infrastructure servers 
instead of all hosts, etc.)

You're right that if a ULA(-C) site would have no global addresses 
whatsoever, reverse-DNS delegations can't be done.

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 19 Jun 2007 15:49:57 -0400

> -----Original Message-----
> From: Jeroen Massar [mailto:[email-masked]] 

> that server is located in the first place?

[ ... ]

> we are going to have a nice mess there...

Jeoren, what about this quote from the draft:

4.1 DNS Issues

Bert

---

From: "Manfredi, Albert E" <[email-masked]>
Date: Tue, 19 Jun 2007 15:53:00 -0400

> Jeoren, what about this quote from the draft:

Sorry I mutilated your name again!

Jeroen.

Bert

---

From: "Kevin Kargel" <[email-masked]>
Date: Tue, 19 Jun 2007 15:11:00 -0500

I fail to see the point of mandating non-routable space with allocated
ULA-C.  Any network administrator has the ability and freedom to not
route as much or as little of their PI space as they want.   Why force
constraints on usage?

If they are going to link two physically seperated sites (into a WLAN or
MLAN for example) with 'private' IP's then isn't that just access-listed
PI?

Please explain to me what you could do with ULA-C that you can't do with
PI and an ACL.  I really want to understand.

The only possible use I can figure is so that soho router manufacturers
can have something to hard-code in to their LAN/DHCP defaults, but even
then there would have to be a subnet parameter passed to the router by
DHCP unless one was going to assume that the WAN network was the entire
PI space.

Thanks in advance for the constructive education.

Kevin

> From: Pekka Savola [mailto:[email-masked]] 
> Sent: Tuesday, June 19, 2007 2:41 PM
> To: Jeroen Massar
> Cc: Thomas Narten; Mark Andrews; [email-masked]
> Subject: Re: draft-ietf-ipv6-ula-central-02.txt - reverse DNS
> 
> > What is the point of that? How can a ULA address reach a global 
> > unicast address or for that matter, how is such a ULA 
> address, which 
> > is most likely going to be the sole user of those reverse servers 
> > going to contact any of the root servers, .arpa servers, 
> RIR servers 
> > etc to actually find out where that server is located in 
> the first place?
> >
> > Are those people going to do NAT from their ULA space? Then please 
> > directly kill this whole ULA proposal completely. If NAT is 
> involved 
> > in anyway it should never see daylight.
> 
> I do not know the intended deployment scenarios, but in many 
> cases where I'd expect ULA-C migth be deployed, I'd expect 
> such sites to have some global addresses as well for v4, v6 
> or both (maybe at a different physical site, just for a 
> couple of infrastructure servers instead of all hosts, etc.)
> 
> You're right that if a ULA(-C) site would have no global 
> addresses whatsoever, reverse-DNS delegations can't be done.
> 
> --

---

From: bill fumerola <[email-masked]>
Date: Tue, 19 Jun 2007 13:12:32 -0700

> namespace, but I don't get why reverses then have to be supplied too.

1) by putting it in the global space, every single recursive dns server
in an organization doesn't have to special case (read: slave or conditional
forwarding) ULA reverse zones to get accurate PTR records.

2) two (or more) different organizations who agree to use ULA-C space
(e.g. as part of a partnership) don't have to do even funkier dns tricks
than #1 to have accurate PTR records for both sides.

best of all: by delegating, we avoid the AS112 problem as well.

additionally, there is a draft going through the dnsops WG speaking to
the advantages and pitfalls of reverse dns. wherever possible we should
encourage PTR records to be accurate as possible for as many people as
possible. delegating ULA-C allocations to globally reachable nameservers
hurts no-one and can only potentially be useful information.

> that server is located in the first place?

devices on ULA addresses could contact recursive nameservers that have
a global unicast address and can resolve on their behalf. some machines
may even have both a ULA-C address AND a global address.

> should never see daylight.

this has nothing to do with NAT, but thanks for bringing out the boogeyman.

> machines will be Internet connected, then what is the point of ULA again? 

the delegation should be to global unicast space, not to ULA-C space.

you'll have to find another reason to ask "what's the point?", i guess.

> we are going to have a nice mess there... 
                                                   
people put RFC1918 addresses in A records today and the internet hasn't
imploded as a result yet. if you're a partner of mine, lookup an RFC1918
address i have in the global dns, and you can reach that address through
a prefix i give you as part of our partnership: that RFC1918 record in
the global DNS is useful to you. what's the difference between that and
ULA-C, besides the fact that i don't have to worry about which company's
network addressing tomorrow's merger/acquisition/partnership/etc uses..
like i do with RFC1918.

if you have no relationship with me (or my potential ULA-C space) then
what does it matter to you if i put ULA-C addresses in my forward zones
or have my reverse ULA-C space delegated to a globally reachable server.

i have a great counter-argument: since routing slots are oh so valuable
and are driving policy decisions (e.g. minimum allocation size in ARIN)
and engineering efforts (e.g. SOMEONE MIGHT LEAK ULA-C!), perhaps malloc()
slots in your DNS servers are so important that you might inadvertantly
cache one of my records that points to space you can't reach. in the
interest of the memory footprint DNS servers everywhere we can't allow
ULA[-C] addresses to ever be in the global dns space!

-- 
- bill fumerola / [email-masked]

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 19 Jun 2007 21:15:42 +0100

Manfredi, Albert E wrote:

> Jeroen, what about this quote from the draft:
>

Don't worry about that, that happens everywhere (even I typo it) ;)

>    The operational issues relating to this are beyond the scope of this

Not to mean it nastily but shoving the problem off to something else is a
very easy thing to do. If the ULA-C draft is going to define support for DNS
then it should also mention all the known operational problems that can
occur with it. The entity that will perform the registry function is really
not going to document or figure those things out.

The above hosts are Internet connected and most likely will thus also end up
talking to the Internet at one point or another. I can thus only guess that
they will be wanting to fully connect to the Internet one day and the
generic solution to that problem is NAT. We wanted to get rid of NAT for
IPv6. If NAT is again being done for IPv6 then we can just as well give up
and just keep on using IPv4 as there really is not a single advantage then
anymore to IPv6.

But see below for a scenario that might have actual merit here.

Pekka Savola wrote:
[..]
> I do not know the intended deployment scenarios

And this is the whole problem with ULA-C from what I see.

What are the intended deployment scenarios?
Or to put it better: what is the problem that needs to be solved?

I explicitly noted the drafts existence and instructions how people can and
that they should comment on this, I still have to see a mostly-RIR person
coming up with their views, or better somebody (and rather multiple) folks
that actually want to use it.

ULA (rfc4193) solves the problem of a "routed dental office", pop your boxes
out of the truck, plugin a ULA-capable router box in the middle et presto it
works. This is also already partially what link-locals solve, but those
don't work in a routed manner.

But what is ULA-C supposed to solve, especially in light that "IPv6 PI"
exists and is fairly easy to get?

> but in many cases where
> I'd expect ULA-C migth be deployed, I'd expect such sites to have some
> global addresses as well for v4, v6 or both (maybe at a different
> physical site, just for a couple of infrastructure servers instead of
> all hosts, etc.)

In case you have 'infrastructure servers', aka your local DNS, then it
becomes very easy to let them return answers for your local ip6.arpa tree,
just add the zone as a master. No need for configuring

So, lets assume I have a ULA-C address, how exactly am I going to look up
the reverse? I need to have some kind of global address. When I have a
global address then what is the whole point of ULA, as I am connected already.

**SCENARIO**
One possible scenario could maybe be: use ULA-C local in your local site,
use global (PA) addresses from the upstream ISP, from whom you get a /48
too, thus the number plan is the same, just different first 48 bits. Every
host gets a ULA and a PA address. The PA address might change when changing
ISP. RFC3484 and related work can be used to configure preferring what
address to use. Then you never need to reconfigure your local network and
local addresses are globally unique and can use the Internet.

The big thing there is though: configure your firewalls correctly as the
public addresses do also allow access to everything.

Still, the above can also be accomplished perfectly fine with PI space and
that doesn't require any changes (except RIPE+APNIC policy) to be done.

> whatsoever, reverse-DNS delegations can't be done.

The above example demonstrates that indeed.

Another funny thing there to note is that some people might want to use
ULA-C to 'hide' their infrastructure, as it will be completely disconnected
from the Internet. By introducing reverse dns though, those queries will be
ending up at several DNS servers on the big bad public internet. Of course
the NS record will be cached, but some information does get leaked.

Greets,
 Jeroen

---

From: Thomas Narten <[email-masked]>
Date: Tue, 19 Jun 2007 16:46:44 -0400

> authoritative DNS servers have non-ULA addresses.

For the glue records? Absolutely. Well, actually, this discussion
may need to be nuanced. The requirement should be that that if there
is a PTR record (i.e., with a delegation chain starting at
in-addr.arpa), the authoritative servers that would be traversed in
chasing down the record must all be globally reachable. That probably
means non-ULA addresses, though there might be some edge cases.

> I think Mark was assuming that ULA address for authoritative
> delegation point might be OK, which would lead to issues if the ULA
> address is not reachable from everywhere where reverse DNS lookups
> should succeed.

Not acceptable to have glue records that contain addresses that are not
generally reachable. The DNS is not designed to operate efficiently in
such an environment.

Thomas

---

From: <[email-masked]>
Date: Tue, 19 Jun 2007 21:57:53 +0100

> IMHO, if reverse DNS is provided, it should be required that 
> the authoritative DNS servers have non-ULA addresses. 

Not only that, but since the goal of ULA-C addresses is to provide
something similar to what site-local was going to be, perhaps the RIRs
should operate authoritative reverse DNS servers for the entire ULA-C
space to ensure that reverse DNS for ULA-C addresses is permanently
broken on the public Internet. Of course, anyone who wants to run their
own internal reverse DNS in their own private network, or networks,
should feel free to do so.

Is the goal of this document merely to define the ULA-C address range
well enough to throw it into the lake and see if it sinks or swims? Or
is there some requirement to provide a more workable form of site-local
addresses?

--Michael Dillon

---

From: Bob Hinden <[email-masked]>
Date: Tue, 19 Jun 2007 14:47:19 -0700

> is there some requirement to provide a more workable form of site- 

The central ULA's should to be viewed in contrast to the currently  
defined locally assigned ULAs (RFC4193).  They share almost  all of  
the properties except for the degree of uniqueness (and, of course,  
the ability to self-generate the prefix).  Central ULA's are  
guranteed to be unique vs. locally assigned ULA have a very high  
probability of uniqueness.  Centrally assigned ULA's are for  
organizations that need an absolute guarantee of uniqueness, not just  
a very high probability.  This applies to large enterprises who want  
to use these internally and for private connections to other  
enterprises, and for usage currently being discussed in the RIR  
community.

Bob

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 19 Jun 2007 15:07:44 -0700

Here's a use case for ULA-C that demonstrates its usefulness, and 
demonstrates why reverse DNS for ULA-C blocks is a valuable enough 
service that we shouldn't purposefully break it for the public 
Internet.  Let's say, for example, that I'm a very small ISP with IPv6 
PA space from my upstream(s).  I give out subnets of that PA space to my 
customers in an automated dynamic fashion, and I don't run BGP, so I 
don't need or want PI space.

However, I do have some routers with interfaces that need numbering, and 
I'd rather avoid renumbering them when I change upstreams.  Since ULA-C 
is cheap and easy to get, I register myself a block of it, and use it to 
number my router interfaces.  Since I'd rather my customers saw DNS 
names instead of IPv6 addresses in their traceroutes, I delegate the 
reverse DNS for my ULA-C block to a nameserver on my upstream's PA 
space, and set up proper PTR records for all my routers.

Now, whenever anyone does a traceroute into or out of my network, 
they'll see ULA-C addresses in the traceroute.  They don't need to 
actually reach those addresses if they're not in my network, but they 
will at least be able to resolve PTR records for them, so that the 
traceroute cleanly shows whose network they're traversing.

And whenever I decide to switch upstreams, all I have to do is update my 
DHCP servers, update my nameserver's A record to an IP out of my new 
upstream's PA space, and we're done.  I don't have to renumber a single 
router, I don't have to run BGP, and I don't have to litter the DFZ with 
another PI block.

-Scott

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 19 Jun 2007 23:14:36 +0100

Scott Leibrand wrote:
[..]
> they'll see ULA-C addresses in the traceroute

Which won't work, as ULA-C's are not in the routing tables, they won't pass
uRPF checks and thus those packets of yours will get dropped to the floor.

These packets will include ICMP Packet Too Big, and when those get dropped,
your network is broken, which actually is caused by the usage of a LOCAL
prefix on the Internet.

Maybe a fist addendum that has to be made: ULA(-C) *MUST* never appear on
the wire on the global Internet.

If you do that anyway, you simply will cause your network to break:

When you got gear you are going to attach to the internet request a PI or a
PA block and use a global unicast address.

Greets,
 Jeroen

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 19 Jun 2007 15:20:34 -0700

> When you got gear you are going to attach to the internet 

Which Internet? The existing IPv4 one, or a future IPv6 one?

Fred
[email-masked]

---

From: Leo Vegoda <[email-masked]>
Date: Wed, 20 Jun 2007 00:23:46 +0200

On 20 Jun 2007, at 12:07am, Scott Leibrand wrote:

> Internet.  Let's say, for example, that I'm a very small ISP with  
> IPv6 PA space from my upstream(s).  I give out subnets of that PA  
> space to my customers in an automated dynamic fashion, and I don't  
> run BGP, so I don't need or want PI space.
>
> However, I do have some routers with interfaces that need  
> numbering, and I'd rather avoid renumbering them when I change  
> upstreams.  Since ULA-C is cheap and easy to get, I register myself  
> a block of it, and use it to number my router interfaces.  Since  
> I'd rather my customers saw DNS names instead of IPv6 addresses in  
> their traceroutes, I delegate the reverse DNS for my ULA-C block to  
> a nameserver on my upstream's PA space, and set up proper PTR  
> records for all my routers.

Is this not already possible with a /48 PI assignment from ARIN?

Is ULA-C a new solution for a problem that's already been solved with  
PI assignments or does it solve a new problem?

Regards,

-- 
Leo Vegoda
IANA Numbers Liaison

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 19 Jun 2007 15:36:21 -0700

Leo Vegoda wrote:
>> However, I do have some routers with interfaces that need numbering, 
>> and I'd rather avoid renumbering them when I change upstreams.  Since 
>> ULA-C is cheap and easy to get, I register myself a block of it, and 
>> use it to number my router interfaces.  Since I'd rather my customers 
>> saw DNS names instead of IPv6 addresses in their traceroutes, I 
>> delegate the reverse DNS for my ULA-C block to a nameserver on my 
>> upstream's PA space, and set up proper PTR records for all my routers.
>
Yes, but only if you "qualify for an IPv4 assignment or allocation from 
ARIN under the IPv4 policy currently in effect."  That currently means 
you must either be a large network (qualifying for a /20), or you must 
be large enough to run BGP, be multi-homed, and be large enough to 
justify a /22.
> PI assignments or does it solve a new problem?
I believe there is a gap between the current PI policy, which is 
targeted at organizations large enough to qualify for a routing slot, 
and the need many smaller organizations have for their own IP space for 
various internal uses. Some of those organizations will be happy to use 
ULA-L, but some will need a guarantee of uniqueness and the ability to 
list their IP space in DNS (.arpa) and in whois.  If we can meet the 
needs of those organizations without having to relax the requirements 
for PI space, we can reduce future pressure on the DFZ.

-Scott

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 19 Jun 2007 15:42:47 -0700

> Which Internet? The existing IPv4 one, or a future IPv6 one?
Or, to ask the question another way, does it make sense to use uRPF to 
drop packets sourced from ULA-C blocks?  Our current implementations of 
loose uRPF are rooted in IPv4 justifications, most notably that private 
IP space (RFC 1918) is non-unique, so we have no idea where the packet 
came from, so we might as well drop it.  I'm not sure that applies in 
the IPv6 world, where an ICMP packet can be sourced from ULA-C space or 
non-routed PI space and can have perfectly valid DNS and whois 
information associated with its source address.

-Scott

---

From: Jeroen Massar <[email-masked]>
Date: Tue, 19 Jun 2007 23:56:19 +0100

>> Which Internet? The existing IPv4 one, or a future IPv6 one?

That common thing that is commonly present in ISP tables.

Now if ULA-C becomes part of that, then it is not 'local' anymore of course
and we just have another form of PI.

> drop packets sourced from ULA-C blocks?

I refer you to BCP38 for a LOT of reasons on why to enable uRPF checks.
One of those is the most common one: spoofing.

> Our current implementations of loose uRPF are rooted in IPv4 justifications,
> most notably that private IP space (RFC 1918) is non-unique, so we have no
> idea where the packet came from, so we might as well drop it.

And do you have any idea at all where ULA-C packets come from?
Can you send return packets to them?

Remember, that ULA addresses should not be present at all on that generic
thing that people call the Internet.

Or is spoofing again very happily allowed.

Also please take into consideration the recent quibble over RH0. Networks
which do proper uRPF checks didn't have any problems with these packets as
those packets would never be able to pingpong on those networks simply
because of a wrong source address.

> I'm not sure that applies in

Since when do routers look in DNS and whois?

If they would do that we would have id/loc, now that would be great.

> be large enough to run BGP, be multi-homed, and be large enough to

Then change the RIR policy, don't go invent some strange address type that
will only cause problems in the end and will just be a surrogate PI space.

RIR's should be giving out address space on the justification of NEED by the
requesting organization, not by the need to control routing entries because
some ISP's are scared of having to upgrade their routers.

If that latter group is scared, filter out the PI blocks and everything you
don't want to see and let those folks pay you for a slot in your routing tables.

Anything that is going to be connected one way or the other today, tomorrow
or possibly somewhere in the future to that that called 'the Internet' aka
the stuff using global unicast space should steer far and clear from ULA.

Greets,
 Jeroen

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jun 2007 09:33:58 +1000

> internet, aren't the DNS issues _exactly_ the same?

	Yes they are similar but I suspect that the scale of traffic
	will differ markedly.

	One thing I can be certain of.  There will be reverse queries for
	ULA-C space.  A lot of these queries will originate from sites
	using ULA-C but have not setup nameservers to intercept those
	queries because they don't care about the reverse mappings.
	
	Shifting the NXDOMAIN load from the servers for C.F.IP6.ARPA
	will be harder than shifting the load from the IN-ADDR.ARPA
	servers for 10.IN-ADDR.ARPA was because C.F.IP6.ARPA will
	be in use and the NXDOMAIN load will be randomly spread
	below C.F.IP6.ARPA.

	I also believe that most but not all of the sites using
	ULA-C will have other routable space.  Requiring that some
	of the servers are not ULA-C is not a excessive burden.

	Failure to supply nameservers is cost shifting which we
	should not be encouraging.

	I really don't want to have to add C.F.IP6.ARPA to the list
	of namespaces in draft-ietf-dnsop-default-local-zones.  We will
	have failed with ULA-C if that occurs.

	Mark

---

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

> and just keep on using IPv4 as there really is not a single advantage then
I think what we wanted to get rid of in IPv6 was one-to-many NAT, also 
know as PAT (among other names).  In IPv6, we can stick to one-to-one 
NAT, which eliminates most of the nastiness we associate with NAT in 
today's IPv4 world.

> public addresses do also allow access to everything.
I don't think routers are at the point yet where you can easily renumber 
your routers' interfaces when your PA addresses change.  As a result, 
networks wanting to avoid the pain of renumbering, but who don't qualify 
for PI and a global routing slot, might want to do something similar:

Say a network gets a ULA-C block, and numbers everything on their 
network out of that block.  They later connect to the Internet, and get 
a PA block from their upstream, and configure it on their border 
routers.  To avoid reconfiguring all their routers every time they 
change upstreams, they configure one-to-one NAT on their border routers, 
such that every address on their internal network (which is ULA-C) maps 
to the same address, except with different first 48 bits, in their 
provider-allocated block.

This wouldn't present the same kinds of problems you'd get from 
one-to-many NAT, but I'm sure there are some ways where this wouldn't be 
as good as PI space.  However, my first-order evaluation is that it 
would be better to have small networks achieve their provider 
independence this way, rather than by relaxing the PI rules and 
threatening the scalability of the current routing system with a large 
number of additional non-aggregatable netblocks.

Now as expressed earlier, most ULA-C use cases probably won't involve 
NAT.  But if people do elect to use NAT with ULA-C, what problems do you 
see with this kind of use of NAT?  Do you see those problems as worse 
than the problems caused by completely rejecting the original PA-only 
architecture of IPv6 in favor of PI-for-everyone?
> that doesn't require any changes (except RIPE+APNIC policy) to be done.
I agree that PI space, if it were widely available, would meet the same 
needs as ULA-C.  However, I think we need to be realistic that 
PI-for-everyone won't fly, and need to think creatively about ways to 
achieve the same goals (such as provider independence) in such a way 
that we don't impose more public cost than private benefit.

Another thing to consider when evaluating whether to specify something 
like ULA-C is that we can't know what kind of innovation it will make 
possible in the future.  Therefore, the question we should be asking is, 
is there any remaining reason *not* to allow networks to register ULA-C 
space?  When it was last proposed there was: it was thought that 
networks would get ULA-C and use it as PI space.  Now, since PI space is 
readily available to multihomed networks, that is much less likely.  As 
a result, I am in favor of allowing small networks to register their own 
unique private space, as this draft would do.  I can't predict how ULA-C 
will be used, but I'm confident that innovation is a good thing, and 
that we can safely open up the ULA-C sandbox to networks who wish to use it.

-Scott

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jun 2007 10:41:33 +1000

I would have thought that router renumbering should be no
	harder that host renumbering.  Essentially all you are
	changing is the higher (/48 normally) prefix bits.  All
	that is required is a method to distribute the set of
	prefixes in use with a set of tags (global, deprecated,
	ula, advertise in RA, etc.).

	Everything else should flow from that set.  Firewall rules
	should be using that information as it really doesn't matter
	which global prefix a host uses to talk to the world.  They
	are all essentially equal.

	I may we be showing my ignorance here but I don't believe
	that this really is a "to hard" job.

	Mark

---

From: Mark Andrews <[email-masked]>
Date: Wed, 20 Jun 2007 11:21:16 +1000

> 	that this really is a "to hard" job.

	This prompted a jabber discussion extracts of which follow.

<XXXXX> note that people who operate routers are usually all about control. automatic renumbering is scary except maybe on the edge
<marka> There is no loss of control.  It would still require a human to add a prefix to the set of prefixes in use.

<XXXXX> somebody upstream from you renumbers.  what happens?
<marka> With IPv6 I would expect that a both the new and old routes would be published for a period.  The old route would then be withdrawn.  There is plenty of addresses  space.  There is no need for instantious changes in addresses.

<XXXXX> i was talking about control.  your upstream adds new prefix, do you add automatically or do you wait for human to approve it?
<XXXXX> simiarly for your upstream withdrawing, do you withdraw automatically or ...
<marka> I would expect that there would be due notice give so that humans could be involved.

	Mark

---

From: David Conrad <[email-masked]>
Date: Tue, 19 Jun 2007 18:58:22 -0700

Hi,

On Jun 19, 2007, at 5:12 PM, Scott Leibrand wrote:
> I think what we wanted to get rid of in IPv6 was one-to-many NAT,  
> also know as PAT (among other names).  In IPv6, we can stick to one- 
> to-one NAT, which eliminates most of the nastiness we associate  
> with NAT in today's IPv4 world.

Really?

I thought the annoying bit about NAT was the fact that IP addresses  
get encoded into higher layers, thus requiring ALG or deep packet  
inspection.  One-to-one NAT would solve the NAT'd server problem, but  
I thought that was considered a feature by most networks.

Rgds,
-drc

---

From: Bill Manning <[email-masked]>
Date: Tue, 19 Jun 2007 19:25:39 -0700

no renumbering event is "too hard" in isolation ......

 BGP peers, MRTG/CRICKET monitoring, AAAA/ACL configs, syslog all come to mind
 as issues/considerations for router renumbering.  

 and remember tht the router is the distribution engine.... of "the set
 of prefixes in use with a set of tags (global, deprecated, etc)

 one has to be very careful about "catch22 situations, deprecating the
 in use prefixes before the new prefixes are in use.

 operationally, renumbering DNS/DHCP servers is a whole lot easier.

--bill

-- 
--bill

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

---

From: Bill Manning <[email-masked]>
Date: Tue, 19 Jun 2007 19:26:38 -0700

> <marka> I would expect that there would be due notice give so that humans could be involved.

	you expect too much.

-- 
--bill

---

From: Leo Vegoda <[email-masked]>
Date: Wed, 20 Jun 2007 10:23:01 +0200

On 20 Jun 2007, at 12:36am, Scott Leibrand wrote:

[...]

> Yes, but only if you "qualify for an IPv4 assignment or allocation  
> from ARIN under the IPv4 policy currently in effect."  That  
> currently means you must either be a large network (qualifying for  
> a /20), or you must be large enough to run BGP, be multi-homed, and  
> be large enough to justify a /22.
>>
>> Is ULA-C a new solution for a problem that's already been solved  
>> with PI assignments or does it solve a new problem?
>>
> targeted at organizations large enough to qualify for a routing  
> slot, and the need many smaller organizations have for their own IP  
> space for various internal uses. Some of those organizations will  
> be happy to use ULA-L, but some will need a guarantee of uniqueness  
> and the ability to list their IP space in DNS (.arpa) and in  
> whois.  If we can meet the needs of those organizations without  
> having to relax the requirements for PI space, we can reduce future  
> pressure on the DFZ.

So am I right in reading your answer as saying that the advantage of  
ULA-C is that it solves the same problem that ARIN's IPv6 PI policy  
solves but better. In effect, developing ULA-C helps side-step ARIN's  
policy development process?

Regards,

-- 
Leo Vegoda
IANA Numbers Liaison

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 20 Jun 2007 10:36:21 +0100

> NAT, which eliminates most of the nastiness we associate with NAT in

No it does not eliminate anything, it still requires Layer 4+ rewriting of
addresses, and that is the nasty bit.

Also NAT breaks this cool "new" (ahem) feature called IPSEC, which when
deployed, would also make deep packet inspection impossible. The latter
requiring one to look inside packets too, but not rewriting them.

[..]
> for PI and a global routing slot, might want to do something similar:

DHCP-PD, which can work in most small networks. I am not discussing anything
that has more than say 20 boxes in such a network though but: small network.

> network out of that block.  They later connect to the Internet,

Your example is already failing. When they want to connect to the Internet
somewhere, it is MUCH easier for them to just get a PI block, then they can
always use that even with or without BGP. And maybe one day with a nice
id/loc solution when that comes out.

> and get

This can perfectly be done with PI blocks in exactly the same way. The
advantage here is though that one day the PI block might be used globally,
while the ULA-C one can never be used in that way.

> number of additional non-aggregatable netblocks.

The ARIN PI rules are already very relaxed: cough up $100 US yearly and
presto you have a fine /48 IPv6 PI.

> architecture of IPv6 in favor of PI-for-everyone?

The big problem with NAT that I have as a programmer is that I will have to
make my protocol & program understand NATs and use them. I don't want to
care about them, there is End-To-End.

With a NAT what happens is that the NAT device will have to understand every
protocol out there. Thus I come up with a new protocol which is really cool,
and first I have to convince everybody on the planet to update their NAT
boxes to support that protocol.

That is not going to work, and as such people will write protocols which
have to evade those NAT boxes and are thus more complex and more error prone
and less versatile.

> that we don't impose more public cost than private benefit.

Why would ULA-C fly and PI not? They can be used in exactly the same way
with a huge advantage for the global unicast variant that it can at one
point also be used in BGP and other variants.

Having PI doesn't mean that one is going to announce that to the global
Internet, you can still use it on your local network without ever hooking up
to that beast, but when you want to you can.

For all those ISP's who are 'afraid' of getting a zillion customers who want
to do PI: Well raise the prices.

Isn't that how it works? If you have something people want: make it more
expensive and make more money of it so that you can buy new gear and do
other such investments.

Why are people afraid of doing business? At a certain point getting a PI
block from a RIR might be cheap, but actually routing it will be expensive,
that solves the problem of too many routing slots doesn't it? But does that
depend on the type of address space: no.

> possible in the future.

At least I can tell you what kind of innovation it will stop, see above: all
new protocols not supported by your ALG.

> Therefore, the question we should be asking is,
> space?

The question still is: is there any REAL application of ULA-C which can't be
solved with a normal global unicast prefix?

> When it was last proposed there was: it was thought that
> readily available to multihomed networks, that is much less likely.

The problem here is not that it is less likely, the problem is that
businesses will get ULA-C space and think that it is PI and still will want
to use it as PI.

> As
> unique private space, as this draft would do.

Let them get a nice PI block from a RIR if that is what they need.

> I can't predict how ULA-C will be used

If you can't come up with an actual use case for it yourself, then why
promote it? Especially in the light of the counter arguments given?

> but I'm confident that innovation is a good thing

Which innovation could lead from this? IPv6 NAT is *not* an innovation, it
is repeating the same mistake as IPv4 had: no end to end.

> and that we can safely open up the ULA-C sandbox to networks who wish to use
> it.

Add water to that sandbox and dilute, what you mean is "open up the swamp".
How safe is that?

People will expect it to work, and it won't work, thus that is not 'safe'.

I do have to note one minor thing about NAT: when done in two ways, thus
that the sender NATs to a global address and the receiver NATs back to the
original address, no problem exists, but that is in effect a tunnel, and
that is in effect also what the various current id/loc proposals are looking
at in one way or another.

Greets,
 Jeroen

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Jun 2007 11:56:16 +0200

> 	ula, advertise in RA, etc.).

I think there has been hype on both sides of this question.  Router 
renumbering used to be VERY annoying.  I've now published several times 
on the subject and I can say that it's not as hard as it was, but it's 
not as easy as it could be.  Specifically, prefix delegation should do 
the job for small routers, particularly in the consumer market.  Making 
use of PD in the enterprise is more experimental, I would say, because, 
as Bill alludes, there are quite a number of knobs to play with.  
Consider that a typical enterprise router not only has interface 
addresses and routing subsystems and firewalls, but may also have such 
fun as VRRP/HSRP configurations, load balancing capabilities, 
NetFlow/sflow collectors, multicast configuration that has some unicast 
addresses hidden in it, management configuration (e.g., SNMP, SYSLOG, 
other), and the like.

In my opinion, this means that the router of the future needs to look a 
little different, and this has implications for other subsystems.  Much 
of this could conceivably be hidden with DNS, but the router itself 
needs to function not just deterministically but predictably down to the 
minute in terms of which addresses it is using.  DNS isn't very good at 
that because your TTLs are based on when you query, and are tied to 
relatively fixed configurations, but it can be used for many things even 
so.  And today you can do that in many portions of the configuration - 
but not all.

It is possible to abstract out much of the configuration EVEN WITHOUT 
DNS, and modularize those things that will change.  And we've done 
*some* of that at Cisco, but we all could do more.

Eliot

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 20 Jun 2007 11:11:51 +0100

Eliot Lear wrote:
> on the subject

Any links to the papers?

> and I can say that it's not as hard as it was, but it's

Indeed, but except for firewalling, it is why I mentioned using a "local"
space (PI) or some other 'globally unique chunk that they can keep'.
One will then configure all the internal setups (snmp,syslog,sflow/netflow
etc) using the forever addresses and won't have to care about those anymore.
Routing internally can also happen using those addresses, though the scary
bit is of course when the MTU does change or a Host/Net unreach has to be
sent, the router has to pick the correct global address and not the one
which is only used inside the network. A block like fc00::/7 could make it
easy to then choose the address based on the target, but how sure are you
that the other organization is not using global unicast space for their
internal networks? Even if that dual setup might not be accepted everywhere,
I mean if you have PI why should one want to add the mess of two networks?

> little different, and this has implications for other subsystems.
[..goodbits..]

Which is indeed why I am thinking that ID/LOC is the way to go. One internal
prefix on the local network, and whatever prefix is on the global Internet.
Apply ID/LOC when your packets are going somewhere where you can't use your
local prefix.

Greets,
 Jeroen

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Jun 2007 12:27:17 +0200

>> renumbering used to be VERY annoying.  I've now published several times

There are two that I can point you at, and perhaps the temporal 
difference would be at least amusing:

    * Renumbering: Threat or Menace?, Lear, Katinsky, Tharp, et al,
      Proceedings of the Tenth Systems Administration Conference (LISA96)
    * Procedures for Renumbering an IPv6 Network Without a Flag Day,
      Baker, Lear, Droms, RFC 4192, September, 2005.

I would also add that Tim Chown has done an extensive amount of work in 
this space.

> space (PI) or some other 'globally unique chunk that they can keep'.

Certainly we've heard this argument from large enterprise customers.

> etc) using the forever addresses and won't have to care about those anymore.

Sure.

> which is only used inside the network.

This really depends on just how scary an enterprise routing 
configuration is.  They can be quite complex depending on both their 
internal and external connectivity, and each has some implications for 
the other.  There are quite a number of enterprises that make heavy use 
of BGP internally.  But certainly the point of ULAs was to provide some 
stability in this area.  I think LISP (draft-farinacci-lisp-00.txt) has 
promise here as well, as may Robin's iVIP proposal (see the ram archives 
for details).

> Apply ID/LOC when your packets are going somewhere where you can't use your

If your point is that you should never have to renumber, then that's a 
lovely way to go.  It will still happen, of course, as companies merge 
and grow.  I think IPv6 helps with the latter, but the former is still a 
challenge simply because topologies change.

Eliot

---

From: Perry Lorier <[email-masked]>
Date: Wed, 20 Jun 2007 23:46:20 +1200

> traceroute cleanly shows whose network they're traversing.
Except that uRPF will prevent those traceroute packets from being 
returned to people.  This also breaks pMTU discovery and all the various 
other things that rely on routers returning ICMP messages.

> And whenever I decide to switch upstreams, all I have to do is update 
> my DHCP servers, 
Your DHCP servers would presumably be using prefix delegation to request 
a prefix to allocate and thus wouldn't require any configuration?
> update my nameserver's A record to an IP out of my new upstream's PA 
> space, and we're done.  I don't have to renumber a single router, I 
> don't have to run BGP, and I don't have to litter the DFZ with another 
> PI block.

---

From: <[email-masked]>
Date: Wed, 20 Jun 2007 13:32:23 +0100

> In my opinion, this means that the router of the future needs 
> to look a little different, and this has implications for 
> other subsystems.  Much of this could conceivably be hidden 
> with DNS, 

Since when do IP networks require DNS to function. We run a global IPv4
network with over 10,000 customer sites in over 20 countries, and there
is virtually no DNS on this network at all. After all, it's an IP
network, i.e. its job is forwarding IP packets.

As to why DNS is not used, it has something to do with unneccesarily
trusting third parties to figure out your packet destinations and the
added complexity of DNS. It turns out to be simpler and more flexible to
just use IP addresses directly. If you need to fail-over communications
to a disaster-recovery site, or merely to a backup server, you can
configure two or four IP addresses in the application and let the app
sort out where to send packets. 

DNS should not be overloaded with so many new functions that it becomes
a requirement of running an IP network.

--Michael Dillon

---

From: Eliot Lear <[email-masked]>
Date: Wed, 20 Jun 2007 16:11:43 +0200

Michael,

I totally understand the concern over circular dependencies.  They are 
not to be underestimated.  And in a service provider environment I think 
you must be doubly cautious about them.  However, in an enterprise 
environment it may be appropriate to make certain allowances for certain 
services, and under certain circumstances.  For instance, a load 
balancer may require DNS to be functioning already in order for it to 
service requests.  Similarly, it may be possible to "secondary" a zone 
in order to be able to bring up certain other services, such as NTP.  It 
is *even* possible to retain policy in DNS if one really wants to do so 
under such circumstances, but one has to at that point consider what 
your failsafe is.

Ultimately, however, the administrative issues of renumbering revolve 
around an inability to abstract IP address information.  In solving that 
problem, however one performs the dereference from abstract to concrete, 
one must worry about dependency loops.  A configuration server could 
just as easily be unavailable, for instance, as a name server.

Eliot

---

From: Scott Leibrand <[email-masked]>
Date: Wed, 20 Jun 2007 10:22:14 -0700

Leo Vegoda wrote:
>> from ARIN under the IPv4 policy currently in effect."  That currently 
>> means you must either be a large network (qualifying for a /20), or 
>> you must be large enough to run BGP, be multi-homed, and be large 
>> enough to justify a /22.
>>>
>> and the need many smaller organizations have for their own IP space 
>> for various internal uses. Some of those organizations will be happy 
>> to use ULA-L, but some will need a guarantee of uniqueness and the 
>> ability to list their IP space in DNS (.arpa) and in whois.  If we 
>> can meet the needs of those organizations without having to relax the 
>> requirements for PI space, we can reduce future pressure on the DFZ.
>
No, it solves a similar problem for a different (though possibly 
partially overlapping) set of networks, and reduces the pressure to 
apply a hammer when a screwdriver is what's really needed.

I would anticipate that for ULA-C to be implemented, RIR policy would 
need to be updated to codify how the RIRs would administer ULA-C.  As an 
active member of ARIN's policy process, I see ULA-C as something that 
should be administered by the RIRs, not by a separate registry, so that 
the RIRs can direct applicants to the appropriate resources (PI for 
large or multihomed networks, ULA-C for private, non-routed space for 
those who don't qualify for PI, etc.)

-Scott

---

From: Mark Smith <[email-masked]>
Date: Thu, 21 Jun 2007 03:30:18 +0930

On Tue, 19 Jun 2007 17:12:12 -0700

> NAT, which eliminates most of the nastiness we associate with NAT in 

Getting rid of PAT doesn't eliminate a number of other problems that
NAT creates, which Keith Moore has documented here :

http://www.cs.utk.edu/~moore/what-nats-break.html

I particularly think inhibiting deploying new transport layer protocols
is a real drawback of NAT. It seems that VoIP might be the next "killer
app" for the Internet, and DCCP would be ideal for it. Unfortunately, I
think the IPv4 NATs out there are going to prevent it getting any
deployment traction over IPv4.

---

From: james woodyatt <[email-masked]>
Date: Wed, 20 Jun 2007 11:16:15 -0700

> http://www.cs.utk.edu/~moore/what-nats-break.html

I'd be more sympathetic to arguments like this if we RFC 4864 didn't  
insist on recommending  the deployment of stateful packet filters in  
IPv6 that break most of the things NAT breaks in IPv4.

> I particularly think inhibiting deploying new transport layer  
> protocols is a real drawback of NAT. [...]

That's one of the things broken by the stateful packet filters  
implied by RFC 4864.  It seems to me that NAT for IPv6 isn't really  
all that worse than what we've already recommended there.  Sure,  
everything is still globally addressable, but that really doesn't go  
very far when symmetrical reachability is pretty much broken for  
everything at the edges of the Internet.

If people think they can make arguments for why NAT between ULA-C  
addresses and PA address will solve more problems than it really  
causes— given what other problems we've already bought with the RFC  
4864 packet filters— then I think we should hear them.

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

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Jun 2007 06:33:45 +1000

> I'd be more sympathetic to arguments like this if we RFC 4864 didn't =20
> insist on recommending  the deployment of stateful packet filters in =20
> > I particularly think inhibiting deploying new transport layer =20
> That's one of the things broken by the stateful packet filters =20
> implied by RFC 4864.  It seems to me that NAT for IPv6 isn't really =20
> all that worse than what we've already recommended there.  Sure, =20
> everything is still globally addressable, but that really doesn't go =20
> very far when symmetrical reachability is pretty much broken for =20
> If people think they can make arguments for why NAT between ULA-C =20
> addresses and PA address will solve more problems than it really =20
> causes=97 given what other problems we've already bought with the RFC =20=
> 
> 4864 packet filters=97 then I think we should hear them.

	It's much easier to have a application talk to a firewall if
	it doesn't also have to deal with address/port translations
	that it is not aware of.

---

From: Mark Smith <[email-masked]>
Date: Thu, 21 Jun 2007 07:40:07 +0930

On Wed, 20 Jun 2007 11:16:15 -0700

> IPv6 that break most of the things NAT breaks in IPv4.

How does a statefule firewall, present on the end-node itself, cause
these problems ? It seems to me that you're making the assumption that
the only scenario IPv6 will be deployed in is one where end-nodes
always have an upstream stateful firewalling device. 

That assumption already isn't true now in IPv4 (one example being this
PC) and I think is even more unlikely to be with IPv6. I think any
vendor who produces Internet capable devices (PCs, OSes, mobile phones,
musical keyboards (Internet capable ones do already exist)) that don't
assume they could be attached directly to the wide open Internet are
unlikely to have much success with their product.

(I'm aware of the IPv6 CPE design work that's going on, and
have been meaning to point out whether that work should be completely
based on the assumption of an upstream firewalling device (have been a
bit time short recently). It's certainly a feasible scenario. However I
think we'd probably be being a bit short sighted if we assumed that
that is the only IPv6 deployment scenario, and I think that eventually
it's probably going to be more likely an exception rather than a rule -
if all the devices are looking after themselves independantly, adding
another protection device upstream in the network doesn't add all that
much additional security value, compared to the costs, financial and
technical, it incurs.)

---

From: james woodyatt <[email-masked]>
Date: Wed, 20 Jun 2007 16:11:01 -0700

On 20 Jun 2007, at 15:10, Mark Smith wrote:
> On Wed, 20 Jun 2007 11:16:15 -0700 james woodyatt <[email-masked]>  
> wrote:
>>
> How does a stateful firewall, present on the end-node itself, cause  
> these problems?

We see this all the time today with stateful packet filters in IPv4  
nodes at global unicast addresses.  Application binds to a socket for  
accepting connections, but that isn't enough for accepting incoming  
connections.  Application need to obtain authorization to request the  
firewall to allow incoming connections.  That involves asking a user  
for a password.  Bletch.

Moreover, firewall knows how to track state for TCP and UDP, because  
that's all the transports the IP stack knows about.  It would be  
reasonable to port implementations of SCTP and DCCP to live there as  
well, but nobody bothers because the firewall doesn't know about  
those transports and needs to be taught about them from scratch.   
Consequently, applications that should use DCCP or SCTP, use TCP or  
UDP instead, so they can work with the firewall interface they have.

Firewalls don't get upgraded to support SCTP and DCCP because  
applications are all limping along with TCP and UDP.  Egg: meet chicken.

> It seems to me that you're making the assumption that the only  
> scenario IPv6 will be deployed in is one where end-nodes always  
> have an upstream stateful firewalling device.

This is likely to be *more* common in the future than it already is  
today.  Residential IPv6 gateway devices are shipping now in consumer- 
grade Wi-Fi AP/router products, and they include these packet filters  
turned on by default.  More are forthcoming.  Their owners are rarely  
even made aware of these packet filters.  Most won't discover them  
until they try to do something silly and stupid, like receive  
incoming VoIP calls over IPv6, fail utterly, and then *maybe* track  
down the source of the ICMP "administratively prohibited" errors to  
their own router.

Architecture is hard, folks.  Despite our best laid architectural  
planz, we are certain to be plagued with middleboxes at every level  
of the Internet.  They're going to interfere with everything.   
Basically, if it's known to work today over IPv4/NAT, then there's a  
pretty good chance it will still work tomorrow over IPv6.  That's  
about the best we can hope for at this point.

If NAT between PA and ULA-C unicast addresses solves a problem for  
somebody, without breaking anything important that isn't already  
broken by something else we've already done, then why shouldn't we be  
pragmatic and define a mostly sensible way for them to do it?

p.s. Readers are encouraged to consider whether this message is a  
devil's advocacy.

---

From: Perry Lorier <[email-masked]>
Date: Thu, 21 Jun 2007 14:03:24 +1200

james woodyatt wrote:
>> On Wed, 20 Jun 2007 11:16:15 -0700 james woodyatt <[email-masked]> wrote:
>>>
> firewall to allow incoming connections.  That involves asking a user for 
> a password.  Bletch.

And then there is no real standard for asking for that authorization in 
the first place.  A lot of applications embed UPnP, which I guess is as 
close to a standard for being able to request a listening port as we 
have.  Many protocols have ways of testing to see if a listening port 
really is listening, since there is no real local feedback from 
firewalls that your listening port is being filtered or NAT'd or had any 
number of other things done to it.

And then we get software developers abusing what is really a bug in 
stateful boxes in the name of "nat transversal".  Operators and end 
users regularly say "Your new application should support nat 
transversal" rather than fixing the underlying problems.

> well, but nobody bothers because the firewall doesn't know about those 
> transports and needs to be taught about them from scratch.  
> Consequently, applications that should use DCCP or SCTP, use TCP or UDP 
> instead, so they can work with the firewall interface they have.
> 

And these boxes don't support this "new fangled" IPv6 thing either. 
Operators claim theres no point in pushing IPv6 out to customers coz 
their CPE's don't support it.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2007 10:36:51 +0200

> not going to document or figure those things out.

I see Thomas' argument for tolerating occasional use of AAAA entries in the
global DNS for ULAs - but it seems that it leads to too many complications
to be recommended. Since I'm sure the IETF isn't ready yet to endorse the
reality of split DNS deployment, wouldn't it be best to say that ULA-Cs
SHOULD NOT be included in the global DNS? (And that is a significant
difference in scope and intent compared with PI.)

     Brian

> ------------------------------------------------------------------------
>

---

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

> router, I don't have to run BGP, and I don't have to litter the DFZ with 

Scott, what feature of existing ULAs makes them unsuitable for this
usage today? In the ridiculously unlikely event of a ULA prefix clash,
this would be detected up-front when trying to set up the reverse
delegation, and then you'd simply generate a different ULA prefix.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Jun 2007 10:52:08 +0200

> those who don't qualify for PI, etc.)

This is the place for me to say that I believe the draft is wrong in
delegating this as an RIR policy matter. Like existing ULAs, ULA-C
should be treated as *technical* address space, and we should specify
that assignments will be made and recorded by a single instance of
a robot, operated by a trusted party. Designation of that trusted party
could certainly be a matter for IANA to negotiate with the community.

I see only downsides (unnecessary costs and useless policy discussions)
in treating this as anything but a purely technical matter. Let's leave
the policy discussions for matters where fairness and route scaling
are at stake. ULAs are plentiful (so there is no fairness issue) and
not WAN-routeable (so there is no route scaling issue).

If we don't do this, ULA-C has no noticeable advantage over PI
and we should just forget it IMHO.

    Brian

---

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

>>>> IPv6 that break most of the things NAT breaks in IPv4.

I'd like to say, as co-author of RFC 4864, that in my mind it simply
recognizes the reality that firewalls exist, will exist for the
foreseeable future, and will include stateful filters, so we have to
deal with it. (more below)

> their CPE's don't support it.

All true. So please start a thread on the v6ops list about
draft-ietf-v6ops-cpe-simple-security and draft-woodyatt-ald,
where there is some attempt to tackle these issues. James is too modest...

     Brian

---

From: <[email-masked]>
Date: Thu, 21 Jun 2007 10:32:08 +0100

> It seems to me that you're 
> making the assumption that the only scenario IPv6 will be 
> deployed in is one where end-nodes always have an upstream 
> stateful firewalling device. 

Even if the stateful firewalling algorithm is being executed by an
upstream device, the fact that the IPv6 destination address is globally
known means that the device knows exactly which internal device is the
intended destination of the packet. This makes it easier for additional
software on the upstream device to do something intelligent that will
not break connectivity in the way that IPv4 NAT/PAT does.

For instance, there could be an application on the end host that
receives notifications from the upstream device so that the user can
accept the packet flow. Or there could be a bit of software on the
upstream device that recognizes this particular packet as belonging to a
known protocol which should be allowed through. Some of this already
exists in IPv4 such as application layer gateways, but some is yet to be
developed.

IPv6 brings a fundamental difference, that the end hosts can use
globally unique addresses and that the upstream gateways do not need to
do any address translation in order to apply stateful firewalling. Once
this becomes more widely understood, then some creative solutions like
the host notification mentioned above, could be implemented. 

Also, firewalling is a process. It has already been pointed out that the
process could take place on the end hosts. It can also be distributed
between the end host and an upstream gateway. Or even partly distributed
to a 3rd party host inside the perimeter by diverting the packet flow
such as is often done with proxy caching. Because of the broad
possibilities it is hard to make absolute statements about what effect
firewalls will have on any particular protocol.

--Michael Dillon

---

From: <[email-masked]>
Date: Thu, 21 Jun 2007 10:48:41 +0100

> applications are all limping along with TCP and UDP.  Egg: 

Sounds like a good area for standardization so that this state of
affairs is not carried forward into IPv6. And especially, if there is a
standard way for upstream gateways with stateful filtering to talk to
end hosts with stateful filtering, then the two of them can agree to
divide the work such that the DCCP-related code runs on the end host.

> If NAT between PA and ULA-C unicast addresses solves a 
> problem for somebody, without breaking anything important 
> that isn't already broken by something else we've already 
> done, then why shouldn't we be pragmatic and define a mostly 
> sensible way for them to do it?

No. 
End hosts that need to communicate on the Internet should have globally
unique IPv6 addresses end-to-end. ULA is for end hosts that do not need
to communicate beyond the boundaries of an administrative domain. And
since IPv6 allows multiple addresses per end-host, those hosts who need
to be schizophrenic can use both ULA and globally unique addresses.
Network Address Translation does not seem to offer anything new here.

--Michael Dillon

---

From: <[email-masked]>
Date: Thu, 21 Jun 2007 10:54:53 +0100

> This is the place for me to say that I believe the draft is 
> wrong in delegating this as an RIR policy matter. Like 
> existing ULAs, ULA-C should be treated as *technical* address 
> space, and we should specify that assignments will be made 
> and recorded by a single instance of a robot, operated by a 
> trusted party. Designation of that trusted party could 
> certainly be a matter for IANA to negotiate with the community.

In my earlier comment I mentioned that the RIRs should stock a supply of
already-generated ULA-C addresses so that the applicants did not have to
wait while 5 RIRs worked out whether or not there was a conflict. Add
that to Brian's comment above and you have a scenario where IANA runs
the robot, ensures global uniqueness (just like they do with IP
addresses) and allocates a supply of ULA-C addresses to an RIR when
their supply runs low. Since running the robot and maintaining the
database of already-generated ULA-C addresses is a minor technical
matter requiring very little technical infrastructure, it seems
reasonable for the RFC to specify that IANA should do this.

--Michael Dillon

---

From: Mark Smith <[email-masked]>
Date: Thu, 21 Jun 2007 19:51:46 +0930

On Wed, 20 Jun 2007 16:11:01 -0700

> firewall to allow incoming connections.  That involves asking a user  

While I agree that isn't the ideal interface, I really think that
mostly is a user interface/OS implementation problem, not a network
architecture or protocol problem. Why should we "fix" the problem
within the network when the problem is fundamentally occuring at the
boundary between the application and the OS i.e. the networking API.

I'm sure you know this, security comes at the cost of
convenience. If somebody doesn't want to have to "put up" with these
sorts of prompts, then I think that means that they've got their
security settings too high or too sensitive. 

Effort certainly needs to be put into trying to make Internet security
as convenient as it can be. However, a line has to be drawn to identify
the point where if security is made any more convenient than "this",
security is being compromised, and people will be forced to make a
choice between convenience and security.

> applications are all limping along with TCP and UDP.  Egg: meet chicken.

Well, most of the ADSL CPE that my company sells to customers runs
Linux internally (and this is 3rd party commodity CPE, not something
we've put together ourselves). And here is what I've found under the
manual page for the current version of the command line firewalling
configuration utility :

 dccp
       --source-port,--sport [!] port[:port]

       --destination-port,--dport [!] port[:port]

...

  sctp
       --source-port,--sport [!] port[:port]

       --destination-port,--dport [!] port[:port]

       --chunk-types [!] all|any|only chunktype[:flags] [...]
              The  flag  letter  in  upper  case indicates that the flag is to
              match if set, in the lower case indicates to match if unset.

So once a web interface is wrapped around that and/or appropriate
defaults are set, I think the chicken has not only hatched but it is
nearly roasted. Of course these devices are also doing NAT commonly, so
at least for IPv4, it'd be somewhat of a wasted effort.

> down the source of the ICMP "administratively prohibited" errors to  

Ask yourself what is the most widely used communications device that
people use. If you can't guess that, ask yourself what recently
announced product from your employer has generated worldwide publicity,
popularity and demand months before it is going to be released, even in
places where it is unlikely to be released in any time soon.

Will that have a firewall on it, or will the customers of that also
have to buy an iFirewall to go with it, because the device itself won't
do firewalling, even though I'd be guessing the OS sitting on it is
easily capable of doing so, and would have enough processing power to do it.

If it doesn't have firewall on it, and the customer doesn't have a
bluetooth or wifi iFirewall in their pocket, where is the carrier going
to put the firewall for all of their customers. How is that firewall
going to scale to support 1000s, 10s or 100s of 1000s of updates to
rules. How is that central firewall going to protect the device from
other malicious customers who are also behind it, and therefore who's
malicious traffic doesn't go through the upstream carrier firewall (I'm
guessing that teenagers would get much more fun out of DoSing the old
man down the road's phone rather than one overseas, because they might
be able to physically see the reaction)

What I'm interpreting you to be saying is :

(a) you seem to be making a very broad and general statement that NAT
is necessary for IPv6

(b) yet your only deployment scenario is one where there is an upstream
stateful firewall that is owned and in control of the person who owns
the downstream devices, and is in close proximity to the devices that
it is protecting.

You may not be exactly saying (a), however it seems to me you're going
close to it.

My argument to those points is :

(a) lets not assume NAT is the only way to solve these problems, as we
already know, recognise and suffer from problems that NAT has created
from IPv4. Let's get creative, and try to solve these problems without
incuring the costs of address translation.

(b) don't assume that what is most likely to be the most common IPv4
case is going to be the most common IPv6 case. Even better, think about
how and where IPv6 is different to IPv4, and try to then identify
possible scenarios that were impossible with IPv4, and then ensure that
IPv4 "thinking" applied to IPv6 doesn't inherently preclude options
that are only possible with IPv6.

> pragmatic and define a mostly sensible way for them to do it?

That's the crux. Why is NAT immediately sensible, just because it was
somewhat effective in IPv4, when we're moving to something new ? It
reminds me a bit of the cliche, "if the only tool you have is a hammer,
every problem looks like a nail."

> p.s. Readers are encouraged to consider whether this message is a  

That's fair enough, but the devil also usually wants you to accept
things you really shouldn't, and you'll end up paying a price far
higher than you ever imagined :-) People, including me, call NAT "evil"
for a reason :-)

Regards,
Mark.

---

From: Mark Andrews <[email-masked]>
Date: Thu, 21 Jun 2007 20:27:29 +1000

> difference in scope and intent compared with PI.)

	It really is no worse than having any other address which is
	partly or fully firewalled off.  The big difference between
	ULA-C and ULA-L is the the former is guarenteed to be unique
	and the later is not.  Ambigious addresses in the DNS are bad.
	Non reachable (except for nameservers) arn't.

	Mark

---

From: Thomas Narten <[email-masked]>
Date: Thu, 21 Jun 2007 09:56:21 -0400

> difference in scope and intent compared with PI.)

Note: a key question is whether the RIRs (as they hand out ULA-C
blocks) allow PTRs to be inserted in the DNS. They either do or they
don't. Saying folk "SHOULD NOT" doesn't answer a key question
definitively.

Note: we have no say/control over whether AAAA records contain
ULAs. End sites can (and will) do what they want here; we have no way
of preventing that (though we can recommend they don't and explain why
it may not be a good idea).

Thomas

---

From: Thomas Narten <[email-masked]>
Date: Thu, 21 Jun 2007 09:59:29 -0400

> 	Non reachable (except for nameservers) arn't.

I don't think it's that black/white. Unreachable addresses for
delegations are bad because they result in long time outs for end
users. That is not good and should be discouraged. So, there is a
difference depending on whether one is talking about AAAA or PTR
records.

That said, I agree that ambiguous addresses are a different and much
worse problem.

Thomas

---

From: Scott Leibrand <[email-masked]>
Date: Thu, 21 Jun 2007 09:00:03 -0700

> delegation, and then you'd simply generate a different ULA prefix.
As far as I know there's no mechanism to delegate reverse DNS for a 
locally generated ULA, since there's no "ownership".  IMO any move to 
start delegating .arpa authority for ULAs would be de facto ULA-C, so if 
we're going to do that we should do it right and do the other 
registration functions that should go along with the DNS delegation.

-Scott

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Jun 2007 18:03:30 +0000

> As far as I know there's no mechanism to delegate reverse DNS for a locally
> generated ULA, since there's no "ownership".  IMO any move to start
> delegating .arpa authority for ULAs would be de facto ULA-C, so if we're
> going to do that we should do it right and do the other registration
> functions that should go along with the DNS delegation.

not to disparage either participant shown above personally, but, this
argument is beyond nuttiness.  mark andrews has a draft out about local
domain name service for RFC 1918, and his fundamental observation is
that there is no need for the resolution perimeter of a PTR to differ
from the routing perimeter of the IP address described by that PTR.  yet
here we have a large set of folks who unlike mark andrews are not experts
at DNS, telling us that yes we do need to be able to resolve a PTR from
places where the addresses won't be routable, and then using this ignorant
and false assertion to justify a global registry of unique but unreachable
address blocks, each having its own globally reachable nameservers for PTRs.

what's wrong with this picture?  is there a use case we can all study?

---

From: james woodyatt <[email-masked]>
Date: Thu, 21 Jun 2007 11:42:28 -0700

On Jun 21, 2007, at 11:03, Paul Vixie wrote:
>
> mark andrews has [observed] that there is no need for the  
> resolution perimeter of a PTR to differ from the routing perimeter  
> of the IP address described by that PTR.  yet here we have a large  
> set of folks who [are] telling us that yes we do need to be able to  
> resolve a PTR from places where the addresses won't be routable
> [...]
> what's wrong with this picture?

My heretical opinion follows.

We successfully deprecated site-local unicast addressing by painting  
it with the stink of IPv4 network address translation.  However, we  
retained the technical consensus that unreachable nodes still need to  
be uniquely addressable, and what's more: these unreachable global  
scope unicast addresses must be assigned from a registry with a  
single global root.

My heretical opinion is that the second technical consensus is  
wrong.  We should deprecate the 'L' bit in the ULA address type and  
make all ULA into locally allocated addresses.  That way, we will  
have carved off a well-known prefix (like all the other non-routable  
prefixes) where nodes are neither uniquely addressable nor reachable  
on the public Internet.  I contend the 'L' bit was never a good idea;  
it was a placeholder for those wishing to retain network address  
translation in IPv6.  There, I said it.

I view all these attempts to establish a global registry for  
allocating unreachable, yet uniquely addressable (from the public  
Internet) unicast addresses with suspicion.  Arguments about the  
unacceptability of the birthday paradox risk in an prefix designator  
space with 2^40 possible birthdays seem to be driven either by 1) a  
frightening level of innumeracy, or 2) an ulterior motive that  
proponents cannot admit publicly.  I fail to see any other alternatives.

It boggles my mind that so many smart people seem to believe that ULA- 
C is absolutely necessary to the operability of the IPv6 Internet.  I  
keep asking to see an explanation for why the risk of collision is  
unacceptable, and nobody seems to be able to point me toward it.  If  
what you really want is to have IPv6 NAT, then let's see the real  
arguments for why you want that.  If any of them aren't properly  
addressed in RFC 4864 and draft-ietf-v6ops-scanning- 
implications-03.txt, then let's figure out what to do about it.

---

From: Leo Vegoda <[email-masked]>
Date: Thu, 21 Jun 2007 20:53:41 +0200

On 20 Jun 2007, at 7:22pm, Scott Leibrand wrote:

[...]

>> So am I right in reading your answer as saying that the advantage  
>> of ULA-C is that it solves the same problem that ARIN's IPv6 PI  
>> policy solves but better. In effect, developing ULA-C helps side- 
>> step ARIN's policy development process?
>>

I am not sure I understand what you mean by applying a hammer. How is  
ULA-C a screwdriver?

Regards,

-- 
Leo Vegoda
IANA Numbers Liaison

---

From: "Kevin Kargel" <[email-masked]>
Date: Thu, 21 Jun 2007 14:25:41 -0500

I concur wholeheartedly on all points.  If one wants a universally
visable address use PI .  With IPv6 if an organization cannot or refuses
to get their own PI space they can get space from their provider.  When
they choose to change providers they are not renumbering, they are just
re-prefixing..  I don't think it will be that painful.  

Hosts with no need to contact the world can use ULA..  hosts that need
to contact the world directly can use PI.  Simple proposition.

For the folks that really want to use NATv6 I don't see anything
preventing them from doing it.  It doesn't make any sense to me but then
it doesn't have to.  They can do whatever they want within their network
boundaries and they don't have to ask anyone.  I see no reason for a
rule legitimizing a policy that is already within the sysadmin's purvue.

Publicly advertised address and/or defined space should be public
address space and routable.  Unrouted address space does not need to be
publicly advertised or defined.  I see no reason to complicate that.

Kevin

:$s/worry/happy/g 

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

---

From: Scott Leibrand <[email-masked]>
Date: Thu, 21 Jun 2007 12:48:39 -0700

Paul Vixie wrote:
> from the routing perimeter of the IP address described by that PTR.  

Feel free to disparage me as a newbie as appropriate.  :-) 

Can you point me to the name of the referenced I-D?  Unfortunately I 
haven't had time to closely follow new I-D's, and am only involved in 
this discussion because of my ARIN PPML involvement.

> yet here we have a large set of folks who unlike mark andrews are not experts
Maybe the I-D answers this, but how do you resolve PTRs for some random 
section of .arpa if you don't have glue NS records pointing you to the 
name servers for that subdomain?  In terms of use case, say my network 
connects privately to a network using ULAs.  I traceroute to a host on 
that network, and try to resolve PTRs for the ULA block.  If the block 
is ULA-C, my DNS server (which may be a completely independent local 
instance of BIND without forwarders) can traverse the tree from the 
root, get the proper delegations to the NS's for the ULA-C (which will 
need to be on public IPs), and resolve the PTRs.  If the block is local 
ULA, however, I don't know how my independent local resolver is supposed 
to find out which name servers are authoritative for the ULA block.

I guess what it comes down to is that the intended use case for ULA-C is 
to connect a bunch of companies with private address space on a private 
network.  In that kind of use case, close integration of DNS 
infrastructure seems unlikely, so without delegating DNS authority from 
the root, I don't see how you can provide good reverse DNS resolution in 
such a use case.  Therefore, I support draft-ietf-ipv6-ula-central-02's 
requirement to support DNS delegation, with the caveat that such 
delegation must be to public addresses (that NS records should not point 
to ULAs).

Thanks,
Scott

---

From: Scott Leibrand <[email-masked]>
Date: Thu, 21 Jun 2007 13:06:07 -0700

Leo Vegoda wrote:
>>> solves but better. In effect, developing ULA-C helps side-step 
>>> ARIN's policy development process?
>>>
Fair enough.  Currently, ARIN PI policy requires that to qualify for 
IPv6 PI space, you meet the requirements for IPv4 PI space, which is 
that you must be multihomed (running BGP) and qualify for a /22, or you 
must qualify for a /20.  The justification for this is that, since such 
a PI allocation usually ends up in the Internet routing tables (the 
DFZ), we should have a standard that limits the number of blocks given 
out, and gives them out to networks that somehow justify a slot in 
everyone's routing tables.

There are a number of smaller networks that wish to avoid "provider 
lock-in" by avoiding the perceived difficulty of renumbering their 
infrastructure when switching providers (and hence PA blocks), and who 
perceive the current policy as unfair.  As a result, there are proposals 
on ARIN's PPML at least once a year to liberalize ARIN's PI policy in 
some fashion.  Some of these have succeeded, such as the move to change 
the smallest block allocated down to a /22 (from a /20 before, IIRC).  
Others have not, due to pushback from operators concerned about 
increasing the rate of growth of the routing table.

For many smaller networks, the real goal is stable addressing, not the 
ability to route their netblock across the entire DFZ.  Therefore, I 
believe some of those networks would be well served by ULA-C space.  
Since such space does not impose a cost on third party operators, it can 
be given out freely. 

If ULA-C is not available, I believe many of those networks will instead 
push for PI space.  Once they get it, the path of least resistance is 
announcing it globally, so most recipients of PI space will do so, 
increasing pressure on the routing table and requiring more rapid 
upgrades (to replace all Supervisor2's in Cisco 6500/7600s running BGP, 
for example).

If ULA-C is available, I believe many networks will be able to use it to 
number their internal infrastructure, and simply use some sort of NAT to 
translate that into their current PA block when traffic sourced from 
their routers passes out onto the Internet.  They can dynamically assign 
their customers/hosts PA space with DHCP, so that end-to-end 
connectivity never needs to be NAT'd.

Much of this can also be done with ULA-L, but I believe that the lack of 
"ownership" and the inability to do proper reverse DNS makes that 
solution not quite as good as ULA-C for many networks.

-Scott

---

From: Leo Vegoda <[email-masked]>
Date: Thu, 21 Jun 2007 23:23:42 +0200

On 21 Jun 2007, at 10:06pm, Scott Leibrand wrote:

[...]

> If ULA-C is not available, I believe many of those networks will  
> instead push for PI space.  Once they get it, the path of least  
> resistance is announcing it globally, so most recipients of PI  
> space will do so, increasing pressure on the routing table and  
> requiring more rapid upgrades (to replace all Supervisor2's in  
> Cisco 6500/7600s running BGP, for example).

History shows us that lots of legacy IPv4 assignments are not visible  
in routeviews, RIS and other BGP route collecting projects. Why would  
IPv6 be different?

> If ULA-C is available, I believe many networks will be able to use  
> it to number their internal infrastructure, and simply use some  
> sort of NAT to translate that into their current PA block when  
> traffic sourced from their routers passes out onto the Internet.   
> They can dynamically assign their customers/hosts PA space with  
> DHCP, so that end-to-end connectivity never needs to be NAT'd.
>
> Much of this can also be done with ULA-L, but I believe that the  
> lack of "ownership" and the inability to do proper reverse DNS  
> makes that solution not quite as good as ULA-C for many networks.

I wouldn't be surprised if some folks saw the lack of an external  
root for regular ULAs as an advantage. And while I appreciate that  
routing table growth is expensive, should we be encouraging people to  
NAT the interfaces on their internal routing infrastructure?

Regards,

-- 
Leo Vegoda
IANA Numbers Liaison

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Jun 2007 15:26:34 -0700

Maybe I am missing the point, but there seems to be
an implication that ULA-C necessarily implies IPv6
NAT; am I misinterpreting? If not, then I don't quite
understand why this implication is being drawn. Can
someone please explain?

Thanks - Fred

---

From: Paul Vixie <[email-masked]>
Date: Thu, 21 Jun 2007 22:43:20 +0000

> Can you point me to the name of the referenced I-D?  ...

http://www.ietf.org/internet-drafts/draft-ietf-dnsop-default-local-zones-02.txt

> section of .arpa if you don't have glue NS records pointing you to the name
> servers for that subdomain?

by asking for a use case, i'm pointing out that if you can't be reached by
an ip packet from "there", then your need to look up a PTR corresponding to
an address in "there" is unfathomable.

> I guess what it comes down to is that the intended use case for ULA-C is to
> connect a bunch of companies with private address space on a private
> network.

the idea that someone would only need PI for "public networking" is bizarre.
quite a lot of normal IPv4 space is never advertised into the "default free
zone" but it's universally unique and used "privately" with passion & verve,
and there is no reason to expect that IPv6 PI won't be used the same way.

a global RIR policy to support this "private network" use case would suggest
that each RIR lay aside a /32 worth of space that was meant to be carved up
in /48 chunks for folks who needed smaller chunks of address space for private
networking, with advice to the community that no address space in these /32's
be advertised to the DFZ, and that it be filtered out if seen in the DFZ.  an
RIR could theoretically come up with a "private space only" membership class
with lower fees.  whois and PTR-space NS RRsets would be managed normally.

i think the disconnect here is that a lot of folks are assuming that the RIR
system only allocates "public" address space.  that's not true today, and it
never has been true (compare historical allocations vs. DFZ advertisements),
and there's no reason to try to make it true or to assume that it ever will
be true.  RIRs allocate universally unique space.  how it's used (public vs.
private) is not an RIR concern.

---

From: james woodyatt <[email-masked]>
Date: Thu, 21 Jun 2007 16:11:12 -0700

On Jun 21, 2007, at 15:26, Templin, Fred L wrote:
>
> Maybe I am missing the point, but there seems to be an implication  
> that ULA-C necessarily implies IPv6 NAT; am I misinterpreting? If  
> not, then I don't quite understand why this implication is being  
> drawn. Can someone please explain?

I'm not going so far as to say the implication is there.  I'm just  
have a very difficult time taking seriously the concern about merge  
risks associated with renumbering due to the birthday paradox in a  
2^40 number space without something more substantial to go on than a  
bald-faced assertion that any small but non-zero probability of  
collision is unacceptable.  The alternative explanation that makes  
the most sense to me is that some influential organizations, which  
are too small to warrant their own PI space, are resisting migration  
to IPv6 unless they can use NAT with private addresses, and they  
won't [or can't] explain why the arguments in RFC 4864 and draft-ietf- 
v6ops-scanning-implications-03.txt are failing to persuade them.

---

From: Scott Leibrand <[email-masked]>
Date: Thu, 21 Jun 2007 17:12:55 -0700

>> drawn. Can someone please explain?
No, ULA-C doesn't require NAT, any more than RFC 1918 or ULA-L space does.

> collision is unacceptable.

That assertion has been made, but I don't think we can treat it as 
anything more than a preference by non-technical business people.

>   The alternative explanation that makes the most sense to me is that 
> some influential organizations, which are too small to warrant their 
> own PI space, are resisting migration to IPv6 unless they can use NAT 
> with private addresses, and they won't [or can't] explain why the 
> arguments in RFC 4864 and 
> draft-ietf-v6ops-scanning-implications-03.txt are failing to persuade 
> them.
>
Whether people end up using NAT or not, RFC 4864 specifically states 
that "When changing ISPs or ISPs readjust their addressing pool, DHCP-PD 
[12] can be used as an almost zero-touch external mechanism for prefix 
change in conjunction with a ULA prefix for internal connection 
stability."  This implies, as I have argued previously, that it is 
appropriate in some cases, particularly the absence of PI space, to use 
a ULA prefix for numbering internal infrastructure like router 
interfaces.  If I am a network operator doing so, I would like my 
internal infrastructure addresses to have valid PTRs, which requires DNS 
delegation, which requires ULA-C.

To my mind, the main advantage of ULA-C over ULA-L is the ability to 
register your space and delegate reverse DNS authority to the 
appropriate name servers, such that anyone on your network or any 
privately-connected network can resolve PTR requests for addresses in 
your ULA block.

-Scott

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 21 Jun 2007 17:22:21 -0700

> From: Scott Leibrand [mailto:[email-masked]] 
> Sent: Thursday, June 21, 2007 5:13 PM
> Subject: Re: draft-ietf-ipv6-ula-central-02.txt
> 
> james woodyatt wrote:

That matches my understanding, which leaves me sort of
wondering how NAT has crept into these discussions. 

> anything more than a preference by non-technical business people.

I have seen both sides of this street being played in other
working group contexts (sometimes even by the same people).
Some say: "probability of collision must be zero", and others
say: "birthday paradox says risk of collision is practically
nil". Wouldn't ULA-C satisfy both sides?

Fred

---

From: Scott Leibrand <[email-masked]>
Date: Thu, 21 Jun 2007 17:28:26 -0700

> an address in "there" is unfathomable.
I get that.  But just because I *do* have IP reachability to "there", 
that doesn't mean my local resolver is configured to go "there" for DNS 
resolution.  That's why I need to have a delegation chain pointing to 
the appropriate name server over "there".
> with lower fees.  whois and PTR-space NS RRsets would be managed normally.

You just did an excellent job of describing ULA-C.  The only difference 
is that ULA-C is being specified top-down through the RFC process, 
rather than being put together in an ad-hoc bottom-up process that may 
be different for each RIR.
> private) is not an RIR concern.
It is true that someone who can get a PI allocation can use it for 
internal use just as they would with ULA-C.  However, since someone who 
can get a PI allocation can easily put it in the DFZ, the RIR membership 
has made restricting the distribution of PI  space an RIR concern 
through the policy process.  The RIRs could elect to allocate 
private-use-only PI out of a special block, but such space is less 
likely to remain out of the DFZ, because the designation of it as 
not-to-be-routed would not carry the force of an RFC standard, and there 
would not be a single block (FC00::/7) to filter, but several different 
blocks, one from each RIR who chose to create private-use PI space.  As 
such, I believe that the IETF should designate ULA-C and hand it off to 
IANA and the RIRs to manage, rather than having the RIRs designate 
private-use-only PI space.

-Scott

---

From: james woodyatt <[email-masked]>
Date: Thu, 21 Jun 2007 18:10:47 -0700

On Jun 21, 2007, at 17:22, Templin, Fred L wrote
> [...] Some say: "probability of collision must be zero", and others  
> say: "birthday paradox says risk of collision is practically nil".  
> Wouldn't ULA-C satisfy both sides?

One of those two sides is presenting technical criteria for  
satisfying unstated and mysterious non-technical goals.  Is it too  
much to ask for less mystery and more transparency in working group  
proceedings?

---

From: Mark Andrews <[email-masked]>
Date: Fri, 22 Jun 2007 12:19:15 +1000

> to find out which name servers are authoritative for the ULA block.

	You publish D.F.IP6.ARPA and C.F.IP6.ARPA and maintain delegations
	within them for all the ULA (L or C) networks that are reachable.
	Each site then becomes a slave.

		zone "C.F.IP6.ARPA" {
			type slave;
			masters { FC...; };
			file "C.F.IP6.ARPA"
		};

		zone "D.F.IP6.ARPA" {
			 type slave;
			 masters { FD...; };
			 file "D.F.IP6.ARPA"
		 };

	The only question is who maintains the D.F.IP6.ARPA registry
	you are using.  Yourself, someone else in your group of
	networks or the RIRs.  C.F.IP6.ARPA already excludes the RIRs
	from this role.

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Jun 2007 03:53:31 +0000

> I get that.  But just because I *do* have IP reachability to "there", that
> doesn't mean my local resolver is configured to go "there" for DNS
> resolution.  That's why I need to have a delegation chain pointing to the
> appropriate name server over "there".

it sounds like what you want to propose is "something like BGP for DNS stubs"
then.  if you have a private relationship to other networks, then you should
be able to express that relationship in both routing and DNS technologies.  i
guess this means i should add "stub zones" to my "metazones" work and publish
that, since it would obviate this entire use case and perhaps many others.

> > a global RIR policy to support this "private network" use case would
> > suggest that each RIR lay aside a /32 worth of space that was meant to be
> > carved up in /48 chunks for folks who needed smaller chunks of address
> > space for private networking, with advice to the community that no address
> > space in these /32's be advertised to the DFZ, and that it be filtered out
> > if seen in the DFZ.  an RIR could theoretically come up with a "private
> > space only" membership class with lower fees.  whois and PTR-space NS
> > RRsets would be managed normally.
> 
> You just did an excellent job of describing ULA-C.  The only difference is
> that ULA-C is being specified top-down through the RFC process, rather than
> being put together in an ad-hoc bottom-up process that may be different for
> each RIR.

my only reason for quoting my own text above yours up there is so you can go
back and see the word "global" before the words "RIR policy".  are we done?

> It is true that someone who can get a PI allocation can use it for internal
> use just as they would with ULA-C.  However, since someone who can get a PI
> allocation can easily put it in the DFZ, the RIR membership has made
> restricting the distribution of PI space an RIR concern through the policy
> process.

which is, perhaps, the reason i'm suggesting a new global RIR policy on this.

> The RIRs could elect to allocate private-use-only PI out of a special block,
> but such space is less likely to remain out of the DFZ, because the
> designation of it as not-to-be-routed would not carry the force of an RFC
> standard,

you have got to be kidding me.  have you not been watching the snippets of
RFC1918-sourced traffic that i've been forwarding to nanog@ all these years?
there is no "force of", either for an RFC "standard" or for an RIR policy.
everything leaks, all the time.  however, as Enigo Montoya said in The
Princess Bride, "i know something you do not."  which is that due in part to
the endless route-theft by spammers and phishers and ddos'ers, RPKI is afoot.
this may or may not stop bad guys from doing bad things, but it will certainly
stop good guys from doing bad things.  none of which matters, since from an
RIR policy point of view, the recommendation of unroutability is meant to make
the policy self-consistent and edible.  it will have no more or less force
than the similar recommendation made in RFC 1918, and everybody knows that.

> and there would not be a single block (FC00::/7) to filter, but several
> different blocks, one from each RIR who chose to create private-use PI
> space.  As such, I believe that the IETF should designate ULA-C and hand it
> off to IANA and the RIRs to manage, rather than having the RIRs designate

i could live with that if i had to.  it's the "iana runs a PTR registration
robot" and the "enduser selects their own prefix" elements of prior proposals
i havn't been able to sit with.  i see this as something every RIR ought to
do, and that every ISP ought to follow.  the RIR policy process is
quintessentially regional and bottom-up, and i believe it will work fine for
this application.  the addresses described by ULA-C are uniquely global, and
to assume that only the IETF, not the RIRs, can allocate "private" ones is
counter to my understanding of the mission of every RIR.  if IETF is to act,
let it be to recommend that IANA reserve FC00 and allocate /32's to the RIRs
if a request from an RIR comes in with the magic "RFC WXYZ" box checked.  the
*only* advantage to this is that DFZ participants who want to filter FC00 can
avoid tracking per-RIR bogon lists.  but please note, as you consider these
matters, that any RIR at any time could declare a /32 for this purpose and
start doing regional allocations out of it, and all DFZ participants are
already prepared, process-wise, to track this and implement if it happens.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jun 2007 09:49:44 +0200

On 2007-06-21 20:03, Paul Vixie wrote:
> not to disparage either participant shown above personally, 

As it happens I agree with you Paul; but I left out a hypothetical
or two in my argument aiming to show that Scott's use case didn't
add up in my mind.

     Brian

> but, this

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 22 Jun 2007 10:08:06 +0200

On 2007-06-21 18:00, Scott Leibrand wrote:
...
> locally generated ULA, since there's no "ownership".  

Please read RFC 4193 section 4.4.

     Brian

---

From: "Kevin Kargel" <[email-masked]>
Date: Fri, 22 Jun 2007 08:17:40 -0500

I believe the implication comes when people assume that ULA-C addresses
will be applied on hosts that need direct communication with the DFZ.
As ULA-C is "non-routable" then NAT or some sort of proxy would be
required.

In a network I was designing it would be a non-issue.  If a host
required access to the DFZ it would get a PI address.  Why make things
complicated when you can make them simple? 

> From: Templin, Fred L [mailto:[email-masked]] 
> Sent: Thursday, June 21, 2007 5:27 PM
> To: Leo Vegoda; Scott Leibrand
> Cc: [email-masked]
> Subject: RE: draft-ietf-ipv6-ula-central-02.txt
> 
> Maybe I am missing the point, but there seems to be an 
> implication that ULA-C necessarily implies IPv6 NAT; am I 
> misinterpreting? If not, then I don't quite understand why 
> this implication is being drawn. Can someone please explain?
> 
> Thanks - Fred

---

From: "Kevin Kargel" <[email-masked]>
Date: Fri, 22 Jun 2007 08:23:40 -0500

So why are we expending so much effort getting them to switch to IPv6
earlier?  When IPv6 is the mainstream method of addressing they will get
swept along.  If a network admin wants to drag their feet and do things
the hard way they have a right to do that.  The rest of us don't need to
go out of our way to accommodate them.

> Sent: Thursday, June 21, 2007 6:11 PM
> > that ULA-C necessarily implies IPv6 NAT; am I 
> misinterpreting? If not, 
> > then I don't quite understand why this implication is being 
> drawn. Can 
> > someone please explain?
> 
> I'm not going so far as to say the implication is there.  I'm 
> just have a very difficult time taking seriously the concern 
> about merge risks associated with renumbering due to the 
> birthday paradox in a 2^40 number space without something 
> more substantial to go on than a bald-faced assertion that 
> any small but non-zero probability of collision is 
> unacceptable.  The alternative explanation that makes the 
> most sense to me is that some influential organizations, 
> which are too small to warrant their own PI space, are 
> resisting migration to IPv6 unless they can use NAT with 
> private addresses, and they won't [or can't] explain why the 
> arguments in RFC 4864 and draft-ietf-

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 22 Jun 2007 08:02:15 -0700

> much to ask for less mystery and more transparency in working group  

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.

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

Fred

---

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

> From: Kevin Kargel [mailto:[email-masked]] 
> Sent: Friday, June 22, 2007 6:18 AM
> To: Templin, Fred L; Leo Vegoda; Scott Leibrand
> Cc: [email-masked]

But, don't the multi-addressing capabilities of IPv6 already
solve that? If the communications scope is within a site (or,
between two merged sites) then ULA-C can be used. If instead
the scope crosses the DFZ, then a globally-routable address
must be used. Why would we ask site border routers to NAT
IPv6 when the problem is solved by address selection at the
source and filtering at the site border routers?

Fred

---

From: Scott Leibrand <[email-masked]>
Date: Fri, 22 Jun 2007 11:49:57 -0700

> Please read RFC 4193 section 4.4.
As I read RFC 4193 section 4.4, it confirms my previous understanding 
that there is no mechanism (and should be no mechanism) for delegating 
reverse DNS for a locally generated ULA.  To my mind, this is a reason 
for adopting draft-ietf-ipv6-ula-central-02.txt: the registration of the 
ULA-C blocks allows the registrar to delegate reverse DNS authority (to 
servers with globally routable non-ULA addresses) while avoiding the 
problems outlined in RFC 4193 section 4.4.

-Scott

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Jun 2007 19:35:18 +0000

> ULA-C blocks allows the registrar

who is the registrar?

>                                   to delegate reverse DNS authority (to 

none of this explains why it's not a simple RIR policy matter to create a
new kind of PI space that's cheaper/easier to get due to the recommendation
that it not be accepted into the DFZ.

---

From: Scott Leibrand <[email-masked]>
Date: Fri, 22 Jun 2007 13:03:06 -0700

>> ULA-C blocks allows the registrar

The draft under discussion assumes, as do I, that it will be the local 
RIR, in my case ARIN.

> that it not be accepted into the DFZ.

It could be done that way, but if it is, don't expect a "global" 
policy.  In addition, the netblock for ULA-C is already reserved by 
previous RFCs, out of a well known ULA netblock.  It seems like a simple 
IETF matter to approve a version of draft-ietf-ipv6-ula-central that 
directs IANA to assign portions of this netblock to RIRs for them to use 
in the manner specified in the draft.

If the IETF decides not to advance draft-ietf-ipv6-ula-central in favor 
of allowing RIRs to do something similar on their own, that will likely 
be what happens.  But if the RIRs were to advance a policy that looks 
like ULA-C at this point, they would be accused of doing an end run 
around the IETF process.  So here we are.

-Scott

---

From: Paul Vixie <[email-masked]>
Date: Fri, 22 Jun 2007 20:26:00 +0000

> ... It seems like a simple IETF matter to approve a version of
> draft-ietf-ipv6-ula-central that directs IANA to assign portions of this
> netblock to RIRs for them to use in the manner specified in the draft.

if we're all agreed on that as an approach, and we're no longer considering
asking IANA to run a registration robot or asking network owners to choose
their own prefixes at random, then this is the first i've heard of it.

> If the IETF decides not to advance draft-ietf-ipv6-ula-central in favor of
> allowing RIRs to do something similar on their own, that will likely be what
> happens.  But if the RIRs were to advance a policy that looks like ULA-C at
> this point, they would be accused of doing an end run around the IETF
> process.  So here we are.

i think that's a succinct summary of the status, but i hope that the final
document (writ by whomever under whatever banner) takes account of the
possibility that a private internet can be arbitrarily large, even perhaps
larger than the current DFZ, at which point words like "public" and "private"
and "DFZ" would become meaningless, and the distinction held by FC00 likewise
meaningless.  RFC 1918 had no such dragons to slay, since everybody already
knew what an autonomous system was, and that definition isn't subjective nor
malleable based on the size and shape of the connected internet.

---

From: Fred Baker <[email-masked]>
Date: Fri, 22 Jun 2007 14:03:11 -0700

>> renumbering used to be VERY annoying.  I've now published several  

A paper which in-my-non-humble-opinion covers a lot of the bases is

http://www.ietf.org/rfc/rfc4192.txt
4192 Procedures for Renumbering an IPv6 Network without a Flag Day. F.
      Baker, E. Lear, R. Droms. September 2005. (Format: TXT=52110  
bytes)
      (Updates RFC2072) (Status: INFORMATIONAL)

Actually, all renumbering is trivial, as long as nobody every  
actually writes down an address and always uses a name. The problem  
is - there are any number of places where people either are forced to  
or in fact do choose to write down an address. As soon as that  
happens, that is a place that has to be remembered and written again  
when the address needs to be changed. Documentation and human memory  
being what it is, every place where an address gets written down is a  
place that will be re-discovered because something isn't working as  
expected when a renumbering happens.

The ideal thing, of course, is that all configurations of all  
equipment are centrally managed from a common database, and all one  
has to do is change the database.

"the". It's an english word with a very interesting property. It is  
*singular*. As a result, it is very rarely the right word...
--------------------------------------------------------------------
IETF IPv6 working group mailing list
[email-masked]
Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------

---

From: Fred Baker <[email-masked]>
Date: Fri, 22 Jun 2007 14:04:34 -0700

On Jun 19, 2007, at 5:41 PM, Mark Andrews wrote:

> 	changing is the higher (/48 normally) prefix bits.

assuming that all prefixes are 48 bits long, fine. Guess what. That's  
only the *first* broken assumption...

---

From: Mark Smith <[email-masked]>
Date: Sat, 23 Jun 2007 08:05:47 +0930

On Thu, 21 Jun 2007 11:42:28 -0700

> My heretical opinion follows.
<snip>

I agree with James' heretical opinion.

It seems to me that without realising it, we might be discussing
specific instances and coming from different positions on the general
points of 

* the locator and to a slightly lesser extent the identifier properties
of addresses 

* if identifier and locators should come from the same or different
number space, and for different scenarios, how important it is that
they come from the same or different number spaces

* uses of the identifier property only, and the scope of validity for
that identifier **

* uses of the locator property only and the scope of validity for that
locator (e.g. "site", global)

Maybe if we classify the different use scenarios that are being
discussed for ULAs/ULA-Cs using the above points, we'll be in a better
position to evaluate the pro's and con's of ULAs verses ULA-Cs.

Regards,
Mark.

** To explain this better using an example, I think BGPv4 originally
specified that the BGP router ID, carried in the BGP payload, must be
an IPv4 address. I'd be guessing that at the time the key property that
was being sort was BGP router ID uniqueness, and using a global IPv4
address/number value as that ID was a convenient and sure way of
achieving it. I seem to remember reading somewhere that this
requirement has now been relaxed , as it has been recognised that as
long as the BGP router-id is unique within the boundary where
uniqueness is essential, it doesn't have to be a global IPv4 address
(maybe for "pure" IPv6 BGP scenarios, where there wasn't a need to have
the BGP router-id the size of an IPv6 address, but there isn't a global
IPv4 address on the device to assign the router-id value from). It's
certainly still useful to use a global IPv4 address as the BGP
router-id, as if you use the OAM IPv4 address for the device as the BGP
router-id, implying that it is also a locator, it can be very useful for
operational troubleshooting. I think OSPF was less strict on the OSPF
router-id being a global IPv4 address, because OSPF won't ever be
visible globally, however setting the router-id to a global IPv4
address and making that address reachable i.e. an OAM loopback on the
router, is also very common and convenient.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 25 Jun 2007 08:58:32 +0200

> for more certainty (ULA-C) and less mystery (RFC4193 ULA)?

So, you reckon the chance of an administrative error in ULA-C
land giving two users the same prefix is less than the
2^-40 chance of a ULA clash between two users?

    Brian

---

From: Tim Chown <[email-masked]>
Date: Mon, 25 Jun 2007 14:17:27 +0100

> I would also add that Tim Chown has done an extensive amount of work in 

Well, it was the 6NET team, and some documentation can be found here:

http://www.6net.org/publications/deliverables/D3.6.1.pdf
http://www.6net.org/publications/deliverables/D3.6.2.pdf

and also

Chown, T., Thompson, M., Ford, A., and S. Venaas, "Things to
think about when Renumbering an IPv6 network 
(draft-chown-v6ops-renumber-thinkabout-05.txt)", March 2007.

but the feeling in v6ops certainly seems to be 'we don't want to renumber,
we'd rather have PI or look at id/loc longer term' so specific effort on
making renumbering easier isn't really being made (in that wg at least).

> challenge simply because topologies change.

IPv6 certainly helps, but doesn't trivialise it by any means.
 
-- 
Tim

---

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

> From: Brian E Carpenter [mailto:[email-masked]] 
> Sent: Sunday, June 24, 2007 11:59 PM
> To: Templin, Fred L
> Cc: james woodyatt; IETF IPv6 Mailing List

Maybe; maybe not. But, with ULA-C, there is a (trusted?) entity
that is accountable for assuring uniqueness and someone to turn
to in the event of ties. There is also the concept of having
sites self-generate the ULA-Cs and "register" them with a 3rd
party entity, which puts the control in the end user's hands
while still having an accountable 3rd party.

BTW, this business of birthday paradox clashes has been beaten
on wrt to other random address assignment paradigms too; in
particular, CGAs. There, you have ~60 (?) bits for uniqueness
but it has still been implied that any non-zero probability
of collision is too great.

Fred

---

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

On Tue, 19 Jun 2007, Pekka Savola wrote:
> authoritative DNS servers have non-ULA addresses.  I think Mark was assuming 
> that ULA address for authoritative delegation point might be OK, which would 
> lead to issues if the ULA address is not reachable from everywhere where 
> reverse DNS lookups should succeed.

... and then you are back to being bound to some IP addresses (for 
your DNS) belong to someone and you might not want that at all. 
Enterprises changing providers also need to change IP for their DNS, or 
simple get PI for these IP addresses. And if you get PI, why ULA-C?!

-- 

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

---

From: Roger Jorgensen <[email-masked]>
Date: Wed, 27 Jun 2007 00:34:30 +0200 (CEST)

> difference in scope and intent compared with PI.)

I like the idea of having DNS combined with ULA-C but that just poison the 
entire idea of global unique private IP space in IPv6.

So yes, remove the entire part about DNS from this draft, simply state 
ULA-C provide no reverse in the global DNS, or how it can be phrased best. 
Maybe "ULA-C should not be included in the global DNS" is good enough.

and at the same time state that if you required global DNS get it from the 
RIRs.

--

---

From: Roger Jorgensen <[email-masked]>
Date: Wed, 27 Jun 2007 00:42:29 +0200 (CEST)

On Thu, 21 Jun 2007, james woodyatt wrote:
<snip>
>
> We successfully deprecated site-local unicast addressing by painting it with 
> the stink of IPv4 network address translation.  However, we retained the 
> technical consensus that unreachable nodes still need to be uniquely 
> addressable, and what's more: these unreachable global scope unicast 
> My heretical opinion is that the second technical consensus is wrong.  We 
> should deprecate the 'L' bit in the ULA address type and make all ULA into 
> locally allocated addresses.  That way, we will have carved off a well-known 
> prefix (like all the other non-routable prefixes) where nodes are neither 
> uniquely addressable nor reachable on the public Internet.  I contend the 'L' 
> bit was never a good idea; it was a placeholder for those wishing to retain 
> network address translation in IPv6.  There, I said it.

agree... let's go back to the original RFC defining ULA and remove that 
bit and using this entire thread over the last few months as a reason why 
it never should be global unique etc....

--

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 26 Jun 2007 16:17:43 -0700

> simple get PI for these IP addresses. And if you get PI, why ULA-C?!

Discussions on this list seem to indicate that globally
routable PI might not be attainable for very small sites
such as my laptop. That would be an example of where I
can't get my own PI prefix, right?

Fred

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jun 2007 13:09:35 +0200

On 2007-06-27 00:42, Roger Jorgensen wrote:
>> scope unicast addresses must be assigned from a registry with a single 
>> global root.
>>
>> My heretical opinion is that the second technical consensus is wrong.  
>> We should deprecate the 'L' bit in the ULA address type and make all 
>> ULA into locally allocated addresses.  That way, we will have carved 
>> off a well-known prefix (like all the other non-routable prefixes) 
>> where nodes are neither uniquely addressable nor reachable on the 
>> public Internet.  I contend the 'L' bit was never a good idea; it was 
>> a placeholder for those wishing to retain network address translation 
>> in IPv6.  There, I said it.

I believe that is a misunderstanding of the L bit in RFC 4193. All
it means is: this address was allocated using the procedure defined
in RFC 4193.

In every other respect it is a no-op and there is no difference between
ULAs defined with L=1 and L=0.

> bit and using this entire thread over the last few months as a reason 
> why it never should be global unique etc....

Oh, let's undeprecate site local at the same time then and recreate
the mess in its entirety. (I don't think so.)

     Brian

---

From: Pekka Savola <[email-masked]>
Date: Wed, 27 Jun 2007 15:17:35 +0300 (EEST)

Catching up on email..

> and we should just forget it IMHO.

Brian, it would be useful if you could elaborate a bit on "not 
WAN-routeable".  Some people seem to consider that as one of the major 
reasons how ULA differs from PI, and I guess that leads to conclude 
that ULAs have no significant impact on DFZ whereas PI might.

Specifically, I do not see any (feasible) way how router vendors could 
by default drop ULA packets at some (undefined) border.  This is for 
two reasons; 1) it is not algorithmically possible to define which 
interfaces form "ULA border" where such a filter should be applied 
automatically, and 2) most vendors seem to have a policy that changes 
to default behaviour (could affect existing deployments) are 
unacceptable or at least very strongly frowned upon.

Why do you believe ULA addresses are intrinsically not WAN routable? 
Is there something I'm missing?

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 27 Jun 2007 15:11:49 +0200

On 2007-06-27 14:17, Pekka Savola wrote:
> reasons how ULA differs from PI, and I guess that leads to conclude that 
> ULAs have no significant impact on DFZ whereas PI might.
> 
> by default drop ULA packets at some (undefined) border.  This is for two 
> reasons; 1) it is not algorithmically possible to define which 
> automatically, and 2) most vendors seem to have a policy that changes to 
> default behaviour (could affect existing deployments) are unacceptable 
> or at least very strongly frowned upon.
> 
> Why do you believe ULA addresses are intrinsically not WAN routable? Is 
> there something I'm missing?

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

     Brian

---

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

Brian E Carpenter wrote:
[..]
> is that they are /48s and I don't expect to see /48s routed globally.

Quickly checking http://www.sixxs.net/tools/grh/, taking a rather long
raw-dump of it, cut&pasting it into a textfile and doing some shell
magic, I got the following nice prefixes (full list below)

    639 32
    216 48
     32 35
     30 40
    216 48
      1 52
      2 56
     87 64
      3 124
      7 126
      8 128

I therefor can thus easily conclude that filtering is not happening that
heavily at all. /48's actually will EASILY pass most filters. Most of
the /64's are IX prefixes btw. Until we get certificates in BGP and
until routing strain is not being felt and operators don't want to
filter having a /48 from any block will be easy. Most ISP's do only
accept 2000::/3 indeed though.

Btw, that covered 1088 different prefixes using 89441 possible paths and
only 814 unique ASN's in those paths. So already there are a couple of
ASN's announcing multiple prefixes: 1088*100/814 = 13.3% overhead there.
If thus every active-ish ASN today got a prefix, we would end up with
40k + 13.3% =~ 53k prefixes. Still a lot lower than IPv4, but in that
setup I am assuming nobody will be doing TE, and people will do TE.

> But I am sure they will be filtered.

I have also seen /128's globally being routed over multiple ASN's see
below the /128's are present.

Greets,
 Jeroen

--
      1 16		(2002::/16 :)
      2 19
      3 20
      3 21
      1 22
      3 24
      2 26
      2 27
      5 28
      1 29
      2 30
      1 31
    639 32
     10 33
      3 34
     32 35
      1 36
      1 39
     30 40
      4 42
      1 43
      3 44
      5 45
      7 46
      1 47
    216 48
      1 52
      2 56
     87 64
      3 124
      7 126
      8 128

---

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

Thanks for the facts. It does seem like a childhood illness
though - obviously it isn't sustainable as IPv6 grows up.

     Brian

---

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

> though - obviously it isn't sustainable as IPv6 grows up.

It indeed most likely won't in the very long term.

But hopefully the id/loc mechanisms or shim6 or similar solutions will
make sure that the "IPv6 DFZ" will only contain PA prefixes at a certain
point. Which will limit the number of routes there significantly and
still providing end-sites with full flexibility to change their
up/downstreams on the fly.

At a point where the IPv6 DFZ grows too large, ISP's will start
filtering smaller prefixes (>=/48), and they will drop off the Internet,
then immediately these sites will need to use id/loc. Hopefull the
forced part never happens and people simply realize the constraints that
we are then working in.

It might also happen that vendors find ways to make it scalable and then
everything is fine too. Up to that point though, there should not be an
artificial barrier for end-sites to be able to get globally unique
address space. The other point that they actually fit in the routing
tables is a problem that can be solved with the above.

Greets,
 Jeroen

---

From: james woodyatt <[email-masked]>
Date: Wed, 27 Jun 2007 09:31:29 -0700

On Jun 27, 2007, at 04:09, Brian E Carpenter wrote:
>>> painting it with the stink of IPv4 network address translation.   
>>> However, we retained the technical consensus that unreachable  
>>> nodes still need to be uniquely addressable, and what's more:  
>>> these unreachable global scope unicast addresses must be assigned  
>>> from a registry with a single global root.
>>>
>>> wrong.  We should deprecate the 'L' bit in the ULA address type  
>>> and make all ULA into locally allocated addresses.  That way, we  
>>> will have carved off a well-known prefix (like all the other non- 
>>> routable prefixes) where nodes are neither uniquely addressable  
>>> nor reachable on the public Internet.  I contend the 'L' bit was  
> in RFC 4193.  In every other respect it is a no-op and there is no  
> difference between ULAs defined with L=1 and L=0.

I don't think I've ever been confused about that.

>> agree... let's go back to the original RFC defining ULA and remove  
>> that bit and using this entire thread over the last few months as  
>> a reason why it never should be global unique etc....
>

Please, in the name of all that is hallowed, please, let's leave site- 
local in the oubliette where it belongs.

I merely contend-- albeit heretically-- that "L=0" in RFC 4193 is  
nonsense.  We should hand fc00::/8 back to IANA and revise RFC 4193  
so that fd00::/8 is the ULA prefix identifier, where all addresses  
are allocated according to to the procedure currently defined, have  
global scope, are not routed in the DFZ and receive synthetic reverse  
delegations in 0.0.d.f.ip6.arpa to an anycast address reserved by IANA.

---

From: Leo Vegoda <[email-masked]>
Date: Wed, 27 Jun 2007 12:55:48 -0400

> though - obviously it isn't sustainable as IPv6 grows up.

Most childhood illnesses go away but the /48 assignments made by ARIN  
and APNIC are permanent. What incentive is there - or will there be -  
for those organisations to return their prefixes and take PA space  
from one or more of their upstream providers? Presumably that  
incentive is what will keep ULA-C prefixes within a single site.

Regards,

-- 
Leo Vegoda
IANA Numbers Liaison

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 27 Jun 2007 18:03:10 +0100

Leo Vegoda wrote:
> for those organisations to return their prefixes and take PA space from
> one or more of their upstream providers?

ISPs can then force them. "Oh you want to announce a /48? Cool, but show
us the money". It will then be cheaper to use their PA block on the
'outside' as a Locator, while using their own PI block as a Identifier.
Filtering by the majority of the ISP's, accepting only /32's or for that
matter only blocks from PA space, resolves all of that, with a little
bit of force but it will work.

As such the space doesn't need to be returned and the space can be used
now nicely in the DFZ, and when the id/loc mechanisms come along people
can slowly migrate to those mechanisms. This even avoids any renumbering
and thus should make a lot of people really happy.

> Presumably that incentive is what will keep ULA-C prefixes within a single site.

In effect one can indeed also use ULA-C kind of addresses as
"Identifiers" as they are truly globally unique just like PI, but that
is the whole point why ULA-C is futile: they _are_ just like PI ;)
Except that they will be carved out of a special prefix and handled in a
strange way. Also as they are not "Internet addresses" but intended for
disconnected sites and thus should never traverse the Internet except
for in a VPN in the first place.

Greets,
 Jeroen

---

From: Jeroen Massar <[email-masked]>
Date: Wed, 27 Jun 2007 18:16:03 +0100

james woodyatt wrote:
[..]

> nonsense. We should hand fc00::/8 back to IANA and revise RFC 4193 so
> that fd00::/8 is the ULA prefix identifier, where all addresses are
> allocated according to to the procedure currently defined, have global
> scope, are not routed in the DFZ and receive synthetic reverse

The Local/Global bit is correct in the specification and also what
differentiates the two spaces, the L bit set (thus fd00::/8 RFC4193)
means that the prefix is locally generated and not 100% guaranteed
unique, although 2^-40 is pretty close to that. This is exactly what we
have now. Without the L bit (thus fc00::/8 and proposed ULA-C) we
require some kind of registry to intervene and keep a list to make sure
that there is no collision.

I agree on the handing back of fd00::/8. The need for an address space
like ULA-C is covered by PI already(*1). There are a few corner cases
like "very small sites" but these can be resolved with proper RIR
policies. It is IMHO very wrong that there are folks who want to
restrict RIR's providing address space to end-sites due to 'routing
table' issues which are not existent yet and of which various vendors
have mentioned already that it is and will not be a problem.

What you thus propose above is adding the synthetic 0.0.d.f.ip6.arpa
method as an addition to RFC4193.

Although I partially like the idea it only solves the reverse problem.
It does not solve the forward problem. Because of the latter one still
has to configure DNS on both (or all of the other) connecting sites
anyway to link up these address spaces for the forward zones. One can
then also easily add this for reverses.

This then also doesn't deviate from current practice in both IPv4 and
IPv6. It also doesn't squander a part (/64?) of the /48. Randomly
picking an address in that /48 makes the whole /48 useless as people
can't depend on the full /48 being theirs anymore to slash up(*2).
Also a lot of deployed IPv6 sites use the first /48 for their first
network already or for similar purposes. Next to that there will be at
some point an expectancy that the same synthetic mechanism exists for
the rest of the ip6.arpa zone.

*1 = If one really wanted to one could simply become LIR, request a /32,
then started providing /48's to their customers, who would be people who
simply wanted a chunk of address space. This solves *ALL* this hassle
about ULA-C. The LIR could be setup as a join venture owned by the users
of the address space, thus as long as at least one of them has some cash
they can keep the LIR running and keep the address space.

*2 = as a side note, for SixXS we provide in general two sizes of
prefixes: /64 which is used for tunnels and /48 which is used for
subnets. The /48 is routed fully to the user, as such they can do
anything they want with it, chunk it up in any way possible. If they
then ever move to another ISP they can use the exact name numberplan.
The only 'renumbering pain' left is locating where they have all the
first 48 bits stored and changing those.

Greets,
 Jeroen

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 Jun 2007 10:19:04 -0700

> for in a VPN in the first place.

Also except that they are attainable by very small sites at a
(presumably) nominal cost. (Plus, the "except for in a VPN" is
likely to be good enough for the kinds of connections ULA-C
sites will want to make.)

Fred

---

From: "Kevin Kargel" <[email-masked]>
Date: Wed, 27 Jun 2007 12:49:24 -0500

Everything comes at some cost.  Small sites will be able to get PA from
their providers.  The 'cost' will be renumbering if they change
providers.  

With ULA-C the cost will be in administration.  ULA-C will have the same
administrative load as PI and PA space, so I don't understand why the
cost would be cheaper.  In fact if ULA-C is announcable via DNS the
aggregate cost of managing many small allocation blocks at the root DNS
servers will be higher than managing the relatively fewer large blocks
of PI/PA, so in reality ULA-C costs should be the same or greater.  The
issue is not cost per IP address but cost per database entry.

> Sent: Wednesday, June 27, 2007 12:19 PM
> To: Jeroen Massar; Leo Vegoda
> Cc: [email-masked]; Brian E Carpenter; Pekka Savola
> Subject: RE: ULA and WAN-routability
> 
> > Except that they will be carved out of a special prefix and 
> handled in 
> > a strange way. Also as they are not "Internet addresses" 
> but intended 
> > for disconnected sites and thus should never traverse the Internet 
> > except for in a VPN in the first place.
> 
> (presumably) nominal cost. (Plus, the "except for in a VPN" 
> is likely to be good enough for the kinds of connections 
> ULA-C sites will want to make.)
> 
> Fred

---

From: Leo Vegoda <[email-masked]>
Date: Wed, 27 Jun 2007 13:57:32 -0400

On 27 Jun 2007, at 1:03pm, Jeroen Massar wrote:

[...]

>> from

I don't remember many ISPs trying to force their customers with  
several classful assignments to renumber into a single PA assignment.  
Why do you think ISPs will try and force renumber (or re-prefixing)  
costs on their existing customers?

Regards,

-- 
Leo Vegoda
IANA Numbers Liaison

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 Jun 2007 11:04:23 -0700

> their providers.  The 'cost' will be renumbering if they change

But, very small sites that get ULA-Cs will realize the
benefit of prefix portability and with no routing table
scaling issues in the DFZ.  
 
> cost would be cheaper.

I thought the ULA-C registry was supposed to be something
very simple like a robot.

> In fact if ULA-C is announcable via DNS the

I don't quite know how to characterize this or compare it,
but the cost to the small sites is an altogether different
metric than the cost to the DNS.

Fred

---

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

Leo Vegoda wrote:
> I don't remember many ISPs trying to force their customers with several
> classful assignments to renumber into a single PA assignment. Why do you
> think ISPs will try and force renumber (or re-prefixing) costs on their
> existing customers?

With the in-progress/proposed/... id/loc & shim6 mechanisms you don't
renumber, they keep using their own PI block. See it as automatically
tunneling over the Internet to the remote site.

Current situation:

2001:db8::42/48
+-----+
| YOU |---------[ Upstream ]---{ The Internet }-----{ Them }
+-----+

Versus the to-maybe-one-day-be-situation:

2001:db8::42/48
+-----+
| YOU |----*-----[ Upstream ]---{ The Internet }----*--- { Them }
+-----+    ^                                        ^
           |                                        |
            \----- id/loc or shim6 mechanism -------/

The "YOU" keeps their nice comfortable /48 and adds the new mechanism,
presto. It looks/feels like a automated tunnel mechanism. Of course the
exact details are not out on this yet, and I might describe it
completely wrongly above wrong what it finally will be.

The core thing is: No DFZ entries for "PI sites", but the "PI sites" do
use their own address space and have full control over it.

ISP's can then simply provide two services "BGP" or "Normal /48", prize
will make people move at some places and not at others and in some cases
filtering will force people to move.

Greets,
 Jeroen

---

From: Roger Jorgensen <[email-masked]>
Date: Wed, 27 Jun 2007 20:38:46 +0200 (CEST)

> very simple like a robot.

yes but that's before we all started to consider what troubles we could 
get into by opening up ULA-C...

--

---

From: Paul Vixie <[email-masked]>
Date: Wed, 27 Jun 2007 20:14:27 +0000

> Discussions on this list seem to indicate that globally routable PI might
> not be attainable for very small sites such as my laptop. That would be an
> example of where I can't get my own PI prefix, right?
> 

on a site small enough to be its own network (like your laptop), i don't see a
use case for addresses other than ::1/128.  ("host-local" is a solved problem.)

if you broaden your example to include multiple virtual operating systems each
needing their own address so that they can communicate over a virtual bridge,
then "lan-local" (fe80::/16) is available.

if your laptop is joining an actual LAN (wired, wireless, etc) then it will 
have to have addresses assigned by that actual LAN's administrator, which might
include both fe80::/16 and something else.

it's in that final case where it's "something else" that the question of PI
comes in.  i don't think you're suggesting that your laptop have its own PI
for self-communication, and i don't think you're suggesting that your laptop's
PI ought to be connected by a routing protocol to the local network.

at best your need for laptop-level PI would be so that you could perform
routing over a VPN or tunnel whose endpoint was within the local (actual LAN)
administrator's control.

is this a use case worth pursuing for the purpose of defining internet
technology to support it?  because it seems to me that the mobile-IP folks
have scratched out a plan for this which involves using on your laptop
addresses assigned by the VPN hub, and speaking no routing protocol.

---

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

Paul,

I am talking about a "laptop" that connects an arbitrarily-
complex internal network of virtual hosts and routers, and
an arbitrarily-complex set of external devices attached on,
e.g., Ethernet, Bluetooth, etc. I am attaching the diagram
again (slightly updated) in case folks might have missed
it in my earlier message.

So, it can't just be link-local-for-all, because then there
is no opportunity for off-link communications when in fact
the laptop may connect many links. Also, if my laptop ever
needs to connect up with other sites (be it planned or ad-hoc;
via phisical links or virtual) it will need to have something
like ULA-C to avoid collisions. And, I don't want to have to
inject a globally-routable prefix into the DFZ for it.

Fred

> From: Paul Vixie [mailto:[email-masked]] 
> Sent: Wednesday, June 27, 2007 1:14 PM
> To: [email-masked]
> routable PI might

---

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

> From: "Templin, Fred L" <[email-masked]>
> 
> e.g., Ethernet, Bluetooth, etc. ...

so, there's a routing protocol here?

> the laptop may connect many links.

if the laptop is going to connect to many links, then it will
get an address assigned for each of those links, by DHCP or
stateless autoconf or even manual config.  giving the laptop
its own UA will only make sense if there's a routing protocol
by which that UA-block is advertised into the networks the
laptop connects with.  so can you explain the routing?

>                                     Also, if my laptop ever

forget the DFZ for a minute.  you will have to inject your UA
into the network(s) you attach to.  how's that going to work?
(and what's the horizon of that injection?)

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 27 Jun 2007 15:34:23 -0700

> > e.g., Ethernet, Bluetooth, etc. ...

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

Where do you mean by "here"?
 
> laptop connects with.  so can you explain the routing?

Advertising the ULA block into a (visited) network that
only provides transit for the platform's communications
is not required. But, maybe that's not what you meant
 
> (and what's the horizon of that injection?)

You establish a link between two sites - perhaps aided by
information in the DNS. Then, you either have the IGPs
operating in the two formerly separate sites form an
adjacency over the link, or you set up static routes.

Fred

---

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

> get into by opening up ULA-C...

I think that's beside the point. We need some rules in the draft that
make sure that this space is delegated to IANA as technical address
space, with an obligation on IANA to ensure it remains very low cost
to acquire and use locally. I think the facts of physics and economics
will ensure that it's expensive to route and impractical to put in the
global DNS.

    Brian