Subject: [nat66] Fwd: I-D Action:draft-iab-ipv6-nat-00.txt

From: Lixia Zhang <[email-masked]>
Date: Thu, 19 Mar 2009 20:39:20 -0700

We should have sent a FYI about this draft earlier.
Comments are most welcome!

Dave and Lixia

Begin forwarded message:

> From: [email-masked]
> Date: March 4, 2009 11:45:02 AM PST
> To: [email-masked]
> Subject: I-D Action:draft-iab-ipv6-nat-00.txt
>
> A New Internet-Draft is available from the on-line Internet-Drafts  
> directories.
>
> 	Title           : IAB Thoughts on IPv6 Network Address Translation
> 	Author(s)       : D. Thaler, L. Zhang
> 	Filename        : draft-iab-ipv6-nat-00.txt
> 	Pages           : 11
> 	Date            : 2009-03-04
>
> There has been much recent discussion on the topic of whether the
> IETF should develop standards for IPv6 Network Address Translators
> (NATs).  This document articulates the architectural issues raised by
> IPv6 NATs, the pros and cons of having IPv6 NATs, and provides the
> IAB's thoughts on the current open issues and the solution space.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-iab-ipv6-nat-00.txt
>
> Internet-Drafts are also available by anonymous FTP at:
> ftp://ftp.ietf.org/internet-drafts/
>
> Below is the data which will enable a MIME compliant mail reader
> implementation to automatically retrieve the ASCII version of the
> Internet-Draft.

---

From: james woodyatt <[email-masked]>
Date: Fri, 20 Mar 2009 10:06:00 -0700

On Mar 19, 2009, at 20:39, Lixia Zhang wrote:
>
> We should have sent a FYI about this draft earlier.  Comments are  
> most welcome!

There are three places in the draft where the phrase "end-to-end  
reachability" is used when I would say that "end-to-end  
addressability" would make the point more clearly.  Because IAB and  
IETF have well embraced the notion that policy enforcing stateful  
firewalls should be widely deployed in the Internet, we've long ago  
pitched out the notion that Internet nodes should be end-to-end  
reachable.  The argument over NAT has always been about end-to-end  
addressability, not reachability.

One sentence in Section 1, Introduction:
>> People who are against standardizing IPv6 NAT argue that there is  
>> no fundamental need for IPv6 NAT, and that as IPv6 continues to  
>> roll out, the Internet should converge towards reinstallation of  
>> the end-to-end REACHABILITY which has been a key factor in the  
>> Internet's success.

Two sentences in Section 3, Architectural Considerations of IPv6 NAT:
>> IPv6 application developers in general should be able to program  
>> based on the assumption of end-to-end REACHABILITY, without having  
>> to address the issue of traversing NAT boxes.
...and...
>> If IPv6 NAT design can achieve this goal, then the Internet as a  
>> whole can strive for (re-installing) the end-to-end REACHABILITY  
>> model.

In fact, one could simply s/reachability/addressability/g on the whole  
draft, and problem solved, but it might be worth noting the  
distinction I'm drawing above between reachability and addressability  
in section 1 or section 2.

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

---

From: Keith Moore <[email-masked]>
Date: Fri, 20 Mar 2009 16:23:07 -0400

james woodyatt wrote:
>> We should have sent a FYI about this draft earlier.  Comments are most
>> welcome!
> 
> reachability" is used when I would say that "end-to-end addressability"
> would make the point more clearly.  Because IAB and IETF have well
> embraced the notion that policy enforcing stateful firewalls should be
> widely deployed in the Internet, we've long ago pitched out the notion
> that Internet nodes should be end-to-end reachable. 

Internet nodes should be e2e reachable unless there is explicit policy
to the contrary from an enterprise network where the traffic originates
or terminates.

 The argument over
> NAT has always been about end-to-end addressability, not reachability.

Disagree.  NATs impair both addressability and reachability, and we do a
disservice to the community if we pretend otherwise.  NAT (really NAPT)
does harm to reachability because it blocks traffic in one direction
even if this is not explicit policy, and NAPT limits the flexibility of
a site to choose a policy that takes application usage into account. NAT
can also impair reachability when binding state is lost or discarded.

Keith

---

From: Dave Thaler <[email-masked]>
Date: Fri, 20 Mar 2009 13:26:16 -0700

+1 to what Keith said.

-Dave

> -----Original Message-----
> From: Keith Moore [mailto:[email-masked]]
> Sent: Friday, March 20, 2009 1:23 PM
> To: james woodyatt
> Cc: Lixia Zhang; Dave Thaler; [email-masked] Discussion
> Subject: Re: [nat66] Fwd: I-D Action:draft-iab-ipv6-nat-00.txt
>
> james woodyatt wrote:
> most
> addressability"

---

From: james woodyatt <[email-masked]>
Date: Fri, 20 Mar 2009 14:01:12 -0700

On Mar 20, 2009, at 13:23, Keith Moore emitted:
>
> Internet nodes should be e2e reachable unless there is explicit  
> policy to the contrary from an enterprise network where the traffic  
> originates or terminates.

RFC 4864 also recommends that unmanaged residential networks have  
gateways that enforce such policies by default in the absence of  
explicit user intervention to turn it off.  That's not the only  
documentation of IETF consensus on the subject, but it's the one that  
burns for me.

It's been years since I was pilloried [NB: not in IETF] for suggesting  
that the recommendation of residential firewalls by default in RFC  
4864 should be reconsidered before the draft's final publication.  Not  
very many IETF participants came to my defense, much to my surprise  
and dismay.  (Itojun was among the few who honored me with support,  
and I miss him sorely now.)

I think the consensus is clear: IETF and IAB have capitulated on end- 
to-end reachability, and the conflict is over now.  The end-to-end  
action is all about addressability today.

Soon, after NAT66 is approved for the standards track by IESG, despite  
the "strong recommendations" from the IAB in this draft, end-to-end  
addressability in IPv6 will be the result of explicit coordination  
between address realm operators rather than a reasonable expectation  
of the public Internet in general.  Just as it is today with IPv4.   
End-to-end in IPv6 will be a fleeting memory of what could have been.

I've seen the argument frequently advanced that the success of the  
Internet no longer depends on the end-to-end principle.  The  
continuing success of the Internet despite the ubiquitous deployment  
of IPv4/NAT is often cited as the proof of it.  I've yet to see anyone  
meet with success trying to rebut that argument before audiences who  
cannot imagine and/or do not care what future applications might be  
made practical only if end-to-end addressability were to be considered  
a feature of the Internet rather than an error.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Mar 2009 10:06:22 +1300

On 2009-03-21 09:23, Keith Moore wrote:
...
> can also impair reachability when binding state is lost or discarded.

And that, of course, is the critical thing about a hypothetical NAT66
that uses a stateless prefix-rewriting algorithm and doesn't touch
interface identifiers or ports. Its impact is purely on the address
transparency, which is far easier to deal with than reachability
failures.

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 21 Mar 2009 10:27:55 +1300

James,

On 2009-03-21 10:01, james woodyatt wrote:
...
> documentation of IETF consensus on the subject, but it's the one that

As a author of all of RFC2775, 3234 and 4864, I guess I have to react
to this.

Steve Bellovin made a brave attempt in his original distributed firewalls
paper to push back the tide, but it failed. There is, as far as I can see,
no realistic future without corporate and domestic firewalls. A few of them
may be stateless, but not many. Whatever the IETF may think or feel,
corporate IT has decided. RFC4864 simply recognised this reality.
> that the recommendation of residential firewalls by default in RFC 4864
> should be reconsidered before the draft's final publication.  Not very
> many IETF participants came to my defense, much to my surprise and
> dismay.  (Itojun was among the few who honored me with support, and I
> miss him sorely now.)
> 
> I think the consensus is clear: IETF and IAB have capitulated on
> end-to-end reachability, and the conflict is over now.  The end-to-end

Yes, it's certainly the case that intentional non-reachability is
now a feature of the Internet, and not one designed by the IETF. But
the most unpleasant contortions seem to me not to be around
this point, but around the failure of address referrals caused by
NAT (and in the future, by non-commutative connectivity in a mixed
set of v4/v6 peers).

> between address realm operators rather than a reasonable expectation of
> the public Internet in general.  Just as it is today with IPv4. 

If you mean that corporate intranets will want to be isolated from
e2e routing, I'm sure that's inevitable. But that does not, thanks
to IPv6 multi-prefix addressing, nullify global addressing in the way
that RFC1918 did. I'm sure that as time goes on, a new generation of
corporate IT managers will come to deploy IPv6 using the IPv6 model,
instead of just blindly copying the IPv4 model. Give it time.

> Internet no longer depends on the end-to-end principle.  The continuing
> success of the Internet despite the ubiquitous deployment of IPv4/NAT is
> often cited as the proof of it.  

Maybe, but that's due to a misunderstanding of what the e2e principle
actually is. The thread that includes
http://www.ietf.org/mail-archive/web/int-area/current/msg01910.html
applies.

> I've yet to see anyone meet with
> success trying to rebut that argument before audiences who cannot
> imagine and/or do not care what future applications might be made
> practical only if end-to-end addressability were to be considered a
> feature of the Internet rather than an error.

Yes, that is a subtle argument to make, but it clearly involves showing
how solutions like Skype and BitTorrent bend over backwards to implement
the e2e principle on a network that has lost e2e transparency. Which
takes us, I think, way outside the scope of *this* list.

CU in SF.

   Brian

---

From: james woodyatt <[email-masked]>
Date: Fri, 20 Mar 2009 16:58:41 -0700

On Mar 20, 2009, at 14:27, Brian E Carpenter wrote:
> e2e routing, I'm sure that's inevitable.

No, I mean that we may expect to see both corporate and residential  
networks wanting to be insulated from e2e *addressing*, not just  
routing.  I predict they may come to regard address referrals being  
broken by translators, except within explicitly coordinated address  
realms and mediated by middleboxes (like residential gateways), as a  
*feature* of NAT66 rather than an error.  Certainly, some of my  
colleagues already think that way.

Sure, you could say they're *blindly* copying the IPv4/NAT model, but  
they don't see it that way.  They think the IPv4/NAT model is better  
than the IPv6 model *because* it breaks address referrals.  They like  
that referrals generally don't work unless you're in the same address  
realm or there's an application rendezvous service somewhere mediating  
address realm traversal-- *that's* a service that can usually be  
blocked by default and opened only where policy allows.

> But that does not, thanks

Give it time give it time... I'd like to see the IESG tell the NAT66  
proponents they should "give it time" -- let them go ask IRTF for a  
new research group.

I don't expect that would go over well.

---

From: Ted Hardie <[email-masked]>
Date: Fri, 20 Mar 2009 17:26:13 -0700

At 4:58 PM -0700 3/20/09, james woodyatt wrote:
> They think the IPv4/NAT model is better 

To put this another way, there is a group of administrators that does not
want to be on the Internet. They do want a set of services delivered over IP.

Have I got that right?
				Ted

---

From: David Morris <[email-masked]>
Date: Fri, 20 Mar 2009 17:52:30 -0700 (PDT)

> want to be on the Internet. They do want a set of services delivered over IP.

And probaly want to deliver one or more services in the same fashion.

Dave Morris

---

From: Keith Moore <[email-masked]>
Date: Fri, 20 Mar 2009 20:00:11 -0500

> colleagues already think that way.

Yes, a lot of people are now so accustomed to a "router" being a NAT
that they think this is just how things are supposed to work.  And
because they think this is how things are supposed to work, they will
work to find reasons to justify things working that way, so that they
don't have to change their world views.  (sigh)

> address realm traversal-- *that's* a service that can usually be blocked
> by default and opened only where policy allows.

Yes, there are people who believe that also.

Keith

---

From: Keith Moore <[email-masked]>
Date: Fri, 20 Mar 2009 20:00:41 -0500

> want to be on the Internet. They do want a set of services delivered over IP.

yes, except that they still want to call it the Internet.

Keith

---

From: "Hardie, Ted" <[email-masked]>
Date: Sat, 21 Mar 2009 15:31:58 -0700

From: Keith Moore [[email-masked]]

>Keith

I think that the reality is a little different and a little worse.  They don't want to connect
to the Internet, but they do want a set of services delivered over IP.  The easiest way
to get those set of services has historically been to get connected to the Internet, then
cripple the connection so that it is limited to those services.  

But this does not work, as the users those administrators try to control actually want
access to the Internet, not a restricted set of services (e.g. they want access to their
"home" email, their personal IM accounts, social networks, and so on).  So they
use whatever services are provided to tunnel whatever access they want.  The
* over HTTP set is very prolific, and I have personally seen even relatively unsophisticated
users manage an HTTP-based proxy tunnel to get to what they want.

So there is an arms race:  the administrators ban further services, then implement
deep packet inspection, then try to control access in further ways (by banning
local installation of apps, and so on).

Where this gets really scary is when the upstreams selling to various markets decide
that they don't need to deliver full Internet connectivity (even if that is what they
are advertising), because "everybody" just breaks it.  Or what "everybody" wants
is something where deep packet inspection, or peer-to-peer performance hindrance
or something else is just the default case.

James' original point is that these administrators want address referrals to break,
because it gives them a huge leg up in the arms race to control their users.  But
what worries a lot of us is that this has been a terrible default state in IPv4; if it is
retained into IPv6 by mechanisms like this (*especially* if it becomes the default state
in IPv6), there is essentially no chance that v6 can be a unifying namespace for
the Internet as a whole.  Since v4 is not and the DNS is not (cf.  "split DNS"), we
will be going forward with no unifying default namespace *at all*.  

That means one of two things:  some set of namespaces (like DHT-based overlay network
namespaces) replaces the IP layer as the critical namespace for new applications,
and IP becomes "lower layer gunk" to route around; or the Internet becomes a
platform for networks offering services (think IMS or NGN) rather than retaining 
its capacity to allow application traffic to flow between arbitrary interested parties.

To speak bluntly, most of the people steering industry in this direction have no
intent to head their ships for these rocks (and may not see them as rocks at all);
they are trying to accomplish small things that turn out to have very big aggregate
consequences.  But if this body, which does understand the consequences,
decides it wants to build the tools to further this, it has no excuse that it does so
unknowingly.  The folks pointing out the consequences have been doing so for
years.

Speaking, obviously, as an individual,

Ted Hardie

---

From: Fred Baker <[email-masked]>
Date: Sun, 22 Mar 2009 15:39:31 -0700

On Mar 20, 2009, at 1:23 PM, Keith Moore wrote:

> NATs impair both addressability and reachability, and we do a

That's true of IPv4/IPv4 NATs. It's not true of NAT66 - explicitly.

It would be really nice if we could stay in the general vicinity of  
the topic.

---

From: Keith Moore <[email-masked]>
Date: Sun, 22 Mar 2009 18:14:38 -0700

> That's true of IPv4/IPv4 NATs. It's not true of NAT66 - explicitly.

Not clear.  Any time it becomes necessary to use a particular v6 address
from a particular scope in order to reach a peer, reachability is
harmed.  Any time a NAT creates an alias for an existing address that,
if used, might cause pessimal routing of traffic, reachability is harmed.

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 01:18:56 -0700

> if used, might cause pessimal routing of traffic, reachability is  

I'm not sure I get your point.

NAT66 enables a network to place an address translating DMZ between  
itself and its service provider. On the public side, the address is a  
PA address, very much like the address that shim6 would use. In both  
cases, any datagram headed to that address goes through that ISP and  
that DMZ or one of those DMZs if the network has multiple with the  
same SP. The difference between shim6 and NAT66 in the case is that  
the host itself isn't aware that it is using the address (it is using  
a ULA or some other address), while with shim6 the host is aware of  
the fact. I don't see how that impacted either reachability or  
routing. In both cases, every host that the network authorized to be  
externally reachable is in fact reachable, and at an address that  
permits a peer across the network to specifically select it.

Fill me in? Be specific, please. There is a lot of emotion and  
hyperbole masquerading as reasonable fact flying in this debate, and  
the best way to demonstrate that there is meat in a comment is to lay  
it out.

If your point is that NAT66 doesn't give a PI prefix to the edge  
network, you are correct that it doesn't. That said, arguing against  
one solution because it isn't a different solution is an invalid  
argument; if a given network would really prefer to implement a  
different solution, it probably will. We're discussing *this*  
solution, which is a 1:1 NAT, not 1:many NATs such as are used in  
IPv4, and not PI addressing, and we are discussing it in the context  
of usage in a network that chooses to do so.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Mar 2009 05:06:22 -0700

At 1:18 AM -0700 3/23/09, Fred Baker wrote:
>The difference between shim6 and NAT66 in the case is that 
>a ULA or some other address),

Just to be clear, what does "some other address" encompass
as possibilities?  Can you see any case where it would be using
some other PA address, PI address, or link-local?

				Ted

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 06:43:30 -0700

> some other PA address, PI address, or link-local?

The NAT66 draft describes a scenario in which the hosts in a network  
are using one set of addresses, whether PA from some other ISP or ULA,  
and send packets using that address through a DMZ that changes the  
prefix (the upper 64 bits) by a stated algorithm. A network with many  
ISPs might have many such DMZs between itself and its DMZs. The host  
would therefore think it is using the interior address while its peer  
would observe it using one of the various exterior addresses that  
result from the use of the same interface identifier with the various  
prefixes in question, and the checksum algorithm.

I would be surprised to see a link-local address in that context, as  
IPv6 systems aren't supposed to use them unless the address of the  
peer is also link-local.

So what I am saying is that system A would see system B, in the  
following, as having PA addresses from three different ISPs, but B  
would see itself as only using one ULA. The DMZ systems doing the  
translation make the change. If it were a shim6 network, B would  
directly use the three overlaid PA prefixes, and would itself use the  
three PA addresses.

                                        +-----+  |
                                        |ISP 1|--+
                                        / DMZ |  |
                                       /+-----+  |
                                      /          |
                                     /  +-----+  | +---+
          +---+                     /   |ISP 2|--+-| B |
          | A -----  The Internet  -----| DMZ |  | +---+
          +---+                     \   +-----+  |
                                     \           |
                                      \ +-----+  |
                                       \|ISP 3|--+
                                        | DMZ |  |
                                        +-----+  |

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Mar 2009 09:31:59 -0700

Some comments below; sorry that my first query wan't
as cogent as I'd like--early mornings without coffee aren't
the best for coherence.

>prefixes in question, and the checksum algorithm.

Imagine for a moment that an organization has gotten PI space from
an RIR.  It has a choice now to find upstreams who will announce that
prefix to the global routing table.  This proposal appears to allow it
to also insert some 1:1 mapping box at a network border, and to change
from that PI space to PA space.  (It might do that because it was cheaper
than getting the upstream to carry the traffic and carry the routes).  Doing
that means it has at least one type of address independence that ULAs
do not allow:  it can announce these prefixes into the global routing table
if it turns out it needs to do so *without further renumbering*.  ULAs
force you to have some PA-holding upstream; they may be independent from
any single single one, but you are stuck with the class (a duopoly for many
places in the U.S.). 

Note that I have further concerns about ULA's defined sizes and lack
of aggregation for this use.  (I fully admit that I have these concerns
partly because people don't do dense deployment all that well, but
I don't see much change there.  Educating folks about advances
there may help assuage this concern).

>IPv6 systems aren't supposed to use them unless the address of the 

Frankly, this whole effort challenges the notion I had of IPv6 scopes
enough that I am still not sure I understand it well.  If the box doing
this has an interface on the link, I am not sure why it cannot do this
translation using link-local addresses.  I can picture a wireless box
designed to do this, for example. 

Is that a good idea?  No, as it further confuses the host stack about whether
scopes have a real meaning they need to know and care about, but I
don't think I yet understand how that scenario is logically distinct
from these proposals.

Thanks for your considered responses,
				Ted

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 12:06:01 -0700

On Mar 23, 2009, at 9:31 AM, Ted Hardie wrote:
> an RIR.  It has a choice now to find upstreams who will announce  
> that prefix to the global routing table.  This proposal appears to  
> allow it to also insert some 1:1 mapping box at a network border,  
> and to change from that PI space to PA space.

That is certainly an option, and please don't understand me to be  
arguing against it in a legislative sense. That said, if one has PI  
and chooses to run PA, one wonders about the real need for PI  
addressing - I would expect that the network might release its PI  
prefix. If one isn't willing to release the PI space, then I really do  
wonder about the NAT usage. It will technically work, I just think the  
policy questions get really muddy.

At the end of the day, I think that there is a place for PI - with a  
handwaving gesture, it ca be argued that anyone that can justify an AS  
number and in fact has multiple upstreams is probably well-served by  
PI. That said, the line of reasoning that takes the RIRs into PI space  
ultimately results in the same kind of swamp we have in the IPv4 route  
table. If "insanity" is defined as "applying the same algorithms to  
the same data and expecting a different result", those who complain  
about the IPv4 route table and request PI space are insane. I think  
providing a way to reach address independence that doesn't use PI and  
looks to the ISPs like PA has a material benefit. So I would expect  
O(10^4) PI networks world-wide, and the vast majority using a  
different model, such as this one.

> designed to do this, for example.

"Cannot" and "is not supposed to" are two different things. The  
definition of link-local has elements of locality on a link, which I  
think bear consideration.

> don't think I yet understand how that scenario is logically distinct

True, and at one point in the past few months I myself have wondered  
whether unsubnetted SOHO and residential networks would be just as  
happy with link-local. But I think that it is better to use a ULA if  
one is looking for a local address as that is what it is designed for.

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Mar 2009 13:50:41 -0700

At 12:06 PM -0700 3/23/09, Fred Baker wrote:
>prefix.

I suspect most multi-homing is a result of concern about
poor service coupled with capture.  Having PI space give you the
fullest field of options to handle that problem; the fact that only
a portion of allocated PI would then appear immediately in the
routing table seems like a benefit to me.

>If one isn't willing to release the PI space, then I really do 
>about the IPv4 route table and request PI space are insane.

And those who recommend the general use of an address range which
is deliberately designed to have very limited aggregation are
not?  ULAs don't do CIDR, last I heard.  There is a very serious risk
in deploying ULAs that the cost of getting a routing table slot for
one is a function of how hungry a set of ISPs gets.  There seems to
me a legitimate worry that deploying on the basis of ULA+PA
because of concerns with routing table growth could backfire badly.
If you find it doesn't work for any compelling application, the result
seems to be market pressure to route ULA.  And the routing table goes
boom in yet another tragedy of the commons.

Perhaps I'm paranoid, or fret too easily.   But I wouldn't bet on insane.

>I think 

I think that if the local "cost" to generate a ULA is anything above
0 (and I include maintenance calls), the chance of deployment based
on link-local gets to be pretty high.  If that doesn't worry you, given
3484, I'd like to understand why.  All v6 scopes have collapsed at that
point, right?

			regards,
				Ted Hardie

---

From: Fred Baker <[email-masked]>
Date: Mon, 23 Mar 2009 14:24:21 -0700

On Mar 23, 2009, at 1:50 PM, Ted Hardie wrote:

> not?  ULAs don't do CIDR, last I heard.

They do it just as well as any other /48, which is what the RIRs are  
allocating as PI space.

> There is a very serious risk

So you would prefer to allocate PI space in /48s and guarantee the  
routing table explosion.

> Perhaps I'm paranoid, or fret too easily.   But I wouldn't bet on  

Well, you and I can discuss that in the presence of suitable adult  
beverages. :-)

> 3484, I'd like to understand why.  All v6 scopes have collapsed at  

<head scratching>
     <delay/>
</head scratching>

So I work for one of those evil vendor companies that makes these  
things. I find myself thinking in terms of "how difficult is it to  
make a ULA that is likely to be different than someone else's ULA". I  
find myself wondering not whether, but how many, random number  
generators are implemented in such devices, and whether a seed like  
the time of day at boot or the MAC address of the interior interface  
might come into play as a seed.  Or what happens if I just use the  
lower N bits of the MAC address stuffed into the ULA top prefix.

And I think about the issues that using a link-local address in a non- 
NAT'd environment brings into play.

I think the ULA would be orders of magnitude simpler than trying to  
use link-local in a non-local scope. really.

How does this relate to the NAT66 proposal?

---

From: Ted Hardie <[email-masked]>
Date: Mon, 23 Mar 2009 15:20:53 -0700

>They do it just as well as any other /48, which is what the RIRs are 

Well, I'm most familiar with the ARIN region, and its policy manual
says:

6.5.8. Direct assignments from ARIN to end-user organizations
6.5.8.1. Criteria
To qualify for a direct assignment, an organization must:
	1.	not be an IPv6 LIR; and
	2.	qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect, or demonstrate efficient utilization of all direct IPv4 assignments and allocations, each of which must be covered by any current ARIN RSA.
6.5.8.2. Initial assignment size
Organizations that meet the direct assignment criteria are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation justifying the need for additional subnets. An HD-Ratio of .94 must be met for all assignments larger than a /48.
These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44. This reservation may be assigned to other organizations later, at ARIN's discretion.
6.5.8.3. Subsequent assignment size
Additional assignments may be made when the need for additional subnets is justified. Justification will be determined based on the .94 HD-Ratio metric. When possible, assignments will be made from an adjacent address block.

So /48 is the default, not the only size available, and they are likely reserving
adjacent address blocks to hand out in case of need.  So the aggregation possibilities
look better to me in PI space from an RIR than they do in ULA space.
( Text taken from https://www.arin.net/policy/nrpm.html#six29 )

>So you would prefer to allocate PI space in /48s and guarantee the 

Note that in the thought experiment I just went through with you,
orgs with PI space can use this proposed mechanism and stay off
the global routing table.  They only appear on it if they need to
move from PA-providers to announcing their own prefixes.  That
is, they may not appear until the same moment that they would
appear in the "purchase a routing slot for your ULA" moment
(admittedly maybe earlier).  The key is that they would be able to
go that route without opening the ULA floodgates *and* their
addresses could be aggregated.

>lower N bits of the MAC address stuffed into the ULA top prefix.

I don't think you're thinking like the customer I have in mind.  If a provider
finds that having all traffic originate from a single scope eliminates support
calls from grandma with her cable set-top box, why wouldn't they have their
boxes map from that single address scope and eliminate the previous global scope
entirely?  

>use link-local in a non-local scope. really.

Maybe so.
>How does this relate to the NAT66 proposal?

It's at the boundaries of mapping from one v6 address range to others, and
I'm trying to understand where the boundaries of the proposals are.  "Not
the target, but not logically excluded" seems to be the signpost on this
particular borderland.

Maybe I'm reading it wrong, of course, but that's my current take.

					Ted

---

From: Keith Moore <[email-masked]>
Date: Mon, 23 Mar 2009 15:37:58 -0700

> And I think about the issues that using a link-local address in a
> non-NAT'd environment brings into play.

trying to use a link-local address with a NAT is even more insane.

> I think the ULA would be orders of magnitude simpler than trying to use
> link-local in a non-local scope. really.

simpler for whom?