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

From: <[email-masked]>
Date: Sun, 1 Jul 2007 21:38:10 +0100

>   4) can the ULA-C's be kept out of the DFZ?

Since the IETF has no control whatsoever over the DFZ, then the answer
has to be, no.

The DFZ is the core of the public Internet, one of many internetworks
which use IETF protocols. If the operators of the private networks who
have formed the DFZ, decide that they don't want ULA-C prefixes in the
DFZ, then they won't be there. But that is up to the network operators,
not up to the IETF.

The IETF's role is not limited to only specifying technology that is
useful for the public Internet.

--Michael Dillon

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

---

From: <[email-masked]>
Date: Sun, 1 Jul 2007 21:47:40 +0100

> > > I would support Paul proposal, but with one small change. Paul 
> > > proposes a delegation hierarchy in the ULA-C space:
> > >
> > >>> should be replaced with this one:
> > >>>
> > >>>       | 7 bits |1|  8 bits  | 16 bits | 16 bits | 80 bits  |
> > >>>       +--------+-+----------+---------+---------+----------+
> > >>>       | Prefix |L| Reserved | RIR Num | LIR Num | User Num |
> > >>>       +--------+-+----------+---------+---------+----------+

Something that has been overlooked is the number of bits in each
section. How was this number determined? Is it the right number of bits
for each level? Is there a technical reason for sticking with octet
boundaries here? Does there need to be an actual boundary between the
RIR and LIR section at all?

I think that the RIR section has too many bits (there are 5 of them) and
the LIR section has too few.

It seems to me that the boundary between RIR and LIR should be left
unspecified. IANA can allocate chunks of whatever size is needed to RIRs
as those needs arise. 

--Michael Dillon

---

From: <[email-masked]>
Date: Sun, 1 Jul 2007 21:53:58 +0100

> where in my diffs do i restrict RIRs to the current set of 
> RIRs?  it's expected that there may be more RIRs in the 
> future.

Is this a backdoor attempt to make it possible for sovereign nations to
acquire their own IP allocations as proposed by Houlin Zhao of the ITU?

--Michael Dillon

---

From: Paul Vixie <[email-masked]>
Date: Mon, 02 Jul 2007 01:26:58 +0000

> Something that has been overlooked is the number of bits in each section.
> How was this number determined?

i made it up.  beer was involved.

> Is it the right number of bits for each level?

almost certainly not.

> Is there a technical reason for sticking with octet boundaries here?

no.  (though nibble boundaries are awful nice for operations folks.)

> Does there need to be an actual boundary between the RIR and LIR section at
> all?

i don't think so.  an RIR can allocate blocks-of-adjacent-blocks to LIRs.

> the LIR section has too few.

you sound like a man ready to make a well reasoned counter proposal.  great!

> unspecified. IANA can allocate chunks of whatever size is needed to RIRs

ok by me.  how's this?

    | 7 bits |1| 12 bits |  24 bits  | 80 bits  |
    +--------+-+---------+-----------+----------+
    | Prefix |L| RIR Num | Local Num | User Num |
    +--------+-+---------+-----------+----------+

this would have IANA handing out blocks of /24's to RIRs who could hand out
/48's to end users or blocks of /48's to LIRs (who would then hand out /48's
to end users).  as long as an end user is receiving a /48 and the top 7 bits
are distinctive, it doesn't matter as much what the "middle" looks like.

---

From: Paul Vixie <[email-masked]>
Date: Mon, 02 Jul 2007 01:27:35 +0000

> > where in my diffs do i restrict RIRs to the current set of RIRs?  it's
> > expected that there may be more RIRs in the future.
> 

no.

---

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

Paul,

On 2007-06-29 17:33, Paul Vixie wrote:
> Brian E Carpenter <[email-masked]>:
> 
>> [vixie]
>>> ... and why are we wasting our keystrokes discussing this if there's a
>>> preclusive topic being discussed somewhere entirely else?
>> I don't think it's preclusive. If that discussion does lead to an
>> architectural id/locator split, it will not override what we're discussing
>> here, IMHO. We'll still have IP addresses and they will still need to be
>> unambiguous. Also, that is a discussion that is finally happening after ten
>> years of needing to happen, so it's hardly surprising that it hasn't
>> converged rapidly.
> 
> ok.
> 
>>>> I have a strong feeling there is no consensus forming...
>> [vixie]
>>> i disagree, i've been immersed in this for a month now, and my draft edits
>>> as proposed last night represent my understanding of a potential
>>> consensus, which unlike you i can feel forming.
>> I personally am not part of it then. I don't want to see any structured
>> allocation scheme; a robotic guarantee of uniqueness is all I want to see.
> 
> i've been on the outside of ietf consensus more often than inside, so you've
> got my sympathy if that matters.  also note, the fact that you don't agree
> does not mean consensus isn't forming.

Absolutely. I know what "rough" means in "rough consensus".

> as to your specific concern, i'm
> interested in knowing more about why you want the robotic guaranty of
> uniqueness to be the only feature.  others here have made compelling cases
> for a larger feature set for ULA-C, and yet you are unmoved.  your words...
> 
>> I don't want to facilitate making these things look like a binary hierarchy,
>> because that will cause people to believe for the next 50 years that they
>> aggregate and are routeable. I also don't want to accidentally create a
>> business in selling large integers, which would be the effect of structured
>> registration as opposed to robotic random numbers.
> 
> ...involve a lot of unsupported predictions, and sound somewhat emotional. 

OK, I didn't intend to be emotional there. Let me try to explain. Until
we get something fundamentally different from the routing researchers,
the only model we have is BGP4, and the only way we have to control
the growth in BGP4 table size and dynamics is aggregation. That's basic
and hasn't changed in 25 years. That's why CIDR saved us. So I really
only see two kinds of IP prefix - those that aggregate and those that
don't. We need to encourage the former and discourage the latter (as
far as seeing them in BGP is concerned). In today's jargon, that means
encouraging PA, and limiting PI to a few thousand users that really need
it. ULA-C with structure as you propose is a form of PI. I believe it will
be perceived as an easy way to get PI space, and the pressure to stick
ULA-C prefixes of this kind in the DFZ will become very hard to resist.
I don't see that risk being anywhere near as high for current ULAs
or for centrally registered random ULAs.

> i
> don't think that we should deny others the features they're asking for on the
> basis of what you don't want, especially since the things you say you don't
> want aren't obviously inevitable, or obviously bad, to anybody else we've
> heard from. 

I assume we all want the routing system to continue to scale at an
economically sustainable rate. Can you show that structured ULA-C will be
added to the DFZ at a sufficiently low rate that we won't get into
trouble? What's your estimate of the total number of ULA-C prefixes
needed?

If those numbers fit within reasonable guesses about sustainable
DFZ growth, no problem.

     Brian

---

From: Paul Vixie <[email-masked]>
Date: Mon, 02 Jul 2007 16:53:31 +0000

Brian E Carpenter <[email-masked]>:
> the only model we have is BGP4, ...

i've heard of alternatives but you're right that nothing else has caught on.

>                                 ... and the only way we have to control the
> growth in BGP4 table size and dynamics is aggregation.  That's basic and
> hasn't changed in 25 years. That's why CIDR saved us. 

no.  i don't have objective measurements, but i know that a lot of table size
control is achieved by limiting the horizon of announcements.  ULA-C with my
proposed diffs is just a way to take this a lot further, to legitimize it, to
scale it up to planetary size.

there's been a fundamental misunderstanding in the acadamy as to what actually
happens in the field.  ietf thought that the only connectivity that mattered
was universal connectivity, and fought firewalls and nat for a long while, but
ultimately firewalls and nat and RFC 1918 were all great things for the
internet even though they "violated" the universal connectivity assumptions.

for the record, table size only matters in the DFZ, and only because there are
too many third parties for the budget of any one of them to govern the size of
the table.  away from the DFZ, table size is a self limiting problem, and no
questions of aggregation are even pertinent.

> So I really only see two kinds of IP prefix - those that aggregate and those
> that don't.

that's an extremely informative statement, thank you for sharing it.

> We need to encourage the former and discourage the latter (as far as seeing
> them in BGP is concerned).

if you mean by "BGP", the DFZ, then i'd agree with this statement in isolation
from the one that came before it.

> In today's jargon, that means encouraging PA, and limiting PI to a few
> thousand users that really need it. ULA-C with structure as you propose is a
> form of PI. I believe it will be perceived as an easy way to get PI space,
> and the pressure to stick ULA-C prefixes of this kind in the DFZ will become
> very hard to resist.  I don't see that risk being anywhere near as high for
> current ULAs or for centrally registered random ULAs.

harken back to the above where i referenced "many third parties".  in the DFZ,
what matters is what the tier-1 providers do.  they can afford 2-megaroute
forwarding machinery, they compete aggressively for end-sites against both
other tier-1's and all of the regional or value-add or low-cost tier-2's, and
they really like the PA concept because the renumbering penality gives them a
form of lock-in that even microsoft and apple can only dream about.  if the
tier-1's decide to exchange ULA-C routes with each other, then the rest of the
internet has to do likewise.  and if some really large cash cow of a customer
puts out an RFP to tier-1 saying "we'll buy bandwidth from whoever will route
our ULA-C into the internet core" then it'll be very interesting.  is this
your proposed "pressure to stick" comes from?  because i can think of a dozen
reasons why it can't happen, all based on business strategy and self-interests
of every single party involved in that money chain.

the competing visions as i understand them are "random-prefix ULA-C makes it
impossible to postprocess one's log files on computers outside the
connectivity realm where they were gathered, makes recourse against spammers
and ddos-for-hire crews even harder, and moves the hijacking problem from the
realm where RPKI can help some day to the realm of ``i got it from agnes''(*)"
and "assigned-prefix ULA-C makes it likely that the PI/PA separation regime
will collapse, and take the internet down in flames."

(*) http://www.lyricsdir.com/tom-lehrer-i-got-it-from-agnes-lyrics.html

> trouble?

i predict that structured ULA-C will enter the DFZ at the rate of zero, since
there will be an RFC which excuses anyone who wants to filter it out, and 
since there will be many more champions whose livelihoods are threatened by
it than whose livlihoods could be enriched by it.  (it's all about the money.)

> What's your estimate of the total number of ULA-C prefixes needed?

approximately one per family, worldwide, counting only the population who has
electric power.  much much higher than the 2-megaroute level, or the number
of domain names registered in .COM and .DE (the two largest TLDs).

> If those numbers fit within reasonable guesses about sustainable

they don't fit, but they don't have to fit, because they're not going in.

---

From: David Conrad <[email-masked]>
Date: Mon, 2 Jul 2007 11:10:16 -0700

> they don't fit, but they don't have to fit, because they're not  

How is this going to work?  Are you assuming NATv6?

Rgds,
-drc

---

From: Paul Vixie <[email-masked]>
Date: Mon, 02 Jul 2007 18:28:52 +0000

> How is this going to work?  Are you assuming NATv6?

no.  i'm assuming that the days when the DFZ was the center of the internet
are going to end some day.  ad-hoc networking, neighborhood networking,
city networking, personal networking.  folks will use NATv6 or proxies or
PI or PA when they're going through the DFZ.  a lot of the time ULA-C will
be all they need.

(note, this means i think networking will flow along lines defined by enduser
interest, feature levels, technology capabilities, and money; and not by what
the ivory tower folks predict or demand.)

---

From: [email-masked]
Date: Mon, 2 Jul 2007 23:27:10 -0400 (EDT)

> (note, this means i think networking will flow along lines defined by
> enduser interest, feature levels, technology capabilities, and money

Let's not also forget about convenience, and pain.

Here's the main difference between unannounced PI space, and  ULA-C:
ULA-C is designed to never be directly announced into the DFZ.

I've been giving considerable thought to the use cases, and in particular
what it would be like to be responsible for networks at various places
in the topologies of both strictly off-grid ("local", or multi-local),
and connected to and primarily using the DFZ ("Internet" as we think of
it for IPv4).

The interesting thing is, one person's PI is another person's PA.
By that I mean, that the difference between PI and PA, is subjective.

The assignee of a PI block, who then allocates it as PA sub-blocks, is
what differentiates PA from PI. PA exists only from the perspective of the
assignee herself.

The general idea is that the bulk of address assignments used should be,
one would expect and hope, PA, and aggregated, into large assignments
of PI blocks (ideally one per ASN) in the DFZ. The scalability of the
DFZ depends on this, in fact.

On the other hand, PA is a form of "lock-in". Renumbering is painful,
if the scope of the renumbering is large.

If a PA assignment is directly to an "end user", e.g. an enterprise,
this in theory isn't likely to be a large scope, or is at least manageable.

It is when the PA assignments are further subassigned, that the scope
becomes a significant issue, and the pain (of renumbering) grows.

For example, if a large PA block has been given out, and further assigned
to hundreds of customers (of the PA block recipient), each of which has
DNS servers "on the block", if the recipient needs to renumber, the pain
is prohibitive.

Placing the potential recipient in the position of having
to choose between PA, and a difficult-and-costly-to-obtain PI block,
is by its nature harmful to the deployment of IPv6.

And it is for this reason that I advocate reducing or eliminating
costs, and relaxing the requirements for receiving PI space.
For instance, deferring the costs of PI space until the PI block is
added into the DFZ, is one option.

And admittedly, it is the interactions of 1:1 NAT and DNS that causes most
of the problems, under any scheme for handling relocation in connectivity
to the DFZ.

If we presume that PA allocators (e.g. ISPs), in their own
mutual self-interest, regardless of what is on the other side of the link,
limit ingress traffic only to the PA block itself, then what is on the
other side isn't terribly important. (Similar to BCP-38 for IPv4)

And, accordingly, the ingress traffic could be native (the PA block itself),
or 1:1 NATv6 from ULA-C space, or 1:1 NATv6 from PI space.

In a hierarchy of PI-PA assignments, it fundamentally does not matter
whether the PA block itself is being sub-assigned, or if a separate PI
block from which 1:1 NATv6 is instead PA'd and sub-assigned.

There is definitely room for DNS having hooks for handling the 1:1 NAT
issues - and this has to do with the fact that multiple 1:1 NAT'ing can
occur over a single portion of address space.

In the absence of this, however, there are a number of tricks for working
around this, that are workable enough and scalable enough, for the short
term. The very fact that 1:1 NAT tends to be "sticky" (long-lived), and
that 1:1 NAT is deterministic, and even possible to reverse at the edges
of the DFZ.

(I think for clarity, it would be best to discuss those tricks in a
separate thread. But there are definite, concrete approaches that can be
applied, to the best of my knowledge, with currently deployed code.)

The fact that 1:1 NAT isn't strictly a two-tier technology, and that the
total amount of theoretical address space is so immense, even when used in
a particularly inefficient manner, means that doubling or tripling the
effective use (by heavy use of 1:1 NAT), is not a significant cost.

Use of 1:1 NAT keeps the DFZ to a bare minimum, while still giving all the
flexibility for back-door networking at arbitrary scale.

Still, the question of what to use for the other side of NAT is important,
at least in terms of what kinds of solutions to promote, to support in
the IETF protocol and address specifications, and in the RIR policies.

What I propose is, that PI assignment be very significantly relaxed and
promoted, for use in this case.

Why?

Because, use of ULA-C for the other side of PA NATing means that should
an organization at some point need to have multihomed connectivity, the
site would need to renumber. This is because (stating the obvious) only
PI blocks can be announced into the DFZ, and ULA-C are specifically not
allowed into the DFZ.

If, on the other hand, any organization that foresees, at any point in
time, needing to be multihomed, getting PI space early and using it,
with NATv6 into PA space (for access to the DFZ), all is good.

The fact that this scales recursively is also good. Each link in the
chain is a PA to PI mapping (NATv6). And every enterprise in the tree under
a PI in the DFZ, while having its own PI block, while it is single homed,
is still aggregated into a single PI block in the DFZ.

So, the scalability of the DFZ is still limited by growth of entities
which require their own PI block, and renumbering is accomplished by
changing, as opposed to establishing, NATv6 at the single-homed PI block's
edge (upstream towards DFZ PA block). And eventually, removing NATv6
and announcing the PI block directly into the DFZ.

So, what kind of PI blocks should be made available?

I'd suggest that anything on a nibble boundary, that suits the applicant's
needs, honestly.

Simple enterprises doing "flat" networking with autoconfiguration, might
be able to make do with a single /80, which can handle 48 bits of MAC
address autoconfiguration (basically anything ever made with a NIC).

Even complex enterprises, with autoconf stuff, are likely able to make do
with a /72 or a /64. And likewise, as appropriate, /56 and /48 all make
sense, based on need.

The corresponding PA block assignments, while sticky, aren't as fixed
as PI assignments. An entity with a sparsely used PI block, could probably
be assigned a much smaller PA block. The NAT itself, arguably, could be done
by either the upstream or downstream participant, or both - the latter,
for instance, where the first bit is zero for client-side mappings,
and one for dynamic use for anything that does not match the fixed mappings,
to prevent leakage by NAT instead of filtering.

For any large and growing organization, if the end-game of IPv6 network
growth, from single-homed to multihomed, is turning off NAT rather than
changing what block is used for NAT, the net win is obvious, I would hope.
And having this carrot to wave, in addition to the stick of "IPv4 space
is all used up", is an important way to avoid too much delay in making
the eventual move. Getting significant buy-in across the board for IPv6
should be, for all of us, a goal we are consciously pursuing.

In summary:

Having an easily available third option (beyond PA and ULA-C), is something
that I think is important to remove the impediment to migration and/or
deployment of IPv6 on a large scale (numbers of entities deploying as well
as size of entities.)

Brian

---

From: [email-masked]
Date: Tue, 3 Jul 2007 00:16:54 -0400 (EDT)

> will collapse, and take the internet down in flames."

One comment I neglected to make in my previous response was, that
encouraging the use of PI, even when used on the far side of PA NAT,
means that the identity of (and NOC contact info for) anyone who
accidentally leaks packets with a source for which there is no route,
into the DFZ, is more likely to be discoverable, by mere virtue of the
assignments and registration that go along with PI space.

Brian

---

From: Scott Leibrand <[email-masked]>
Date: Mon, 02 Jul 2007 21:35:04 -0700

> assignments and registration that go along with PI space.

Wouldn't that be equally true of ULA-C space?

And in response to your earlier post encouraging the use of 1:1 NATv6, 
wouldn't it be just as easy/beneficial to use ULA-C or ULA-L space for 
the private side of the NAT?  The only difference would be in the 
multihomed case, where allocation of globally-routable PI space could be 
delayed until the recipient applied for their ASN, and the recipient 
network could transition the public side of their NAT to use the new PI 
space, leaving the inside of the network as ULA or ULA-C.

Now all of this ignores the fact that, architecturally, NATs have been 
rejected as bad for end-to-end connectivity.  To minimize problems 
caused by NAT, it would probably be better to use autoconfiguration 
(stateless or DHCP) to assign PA addresses to hosts (in addition to any 
non-globally-routed space used).

-Scott

---

From: Paul Vixie <[email-masked]>
Date: Tue, 03 Jul 2007 04:55:12 +0000

> By that I mean, that the difference between PI and PA, is subjective.

yes.

> DFZ depends on this, in fact.

no.  while it's true in the current system that identity-follows-routing,
that may not always be true, and away from the DFZ, it's already untrue.
therefore we must reject the aggregation-centric view, or at least, constrain
it to only being valid for globally connected devices, reachable from DFZ.

consider an ipv6-reachable light switch in my house.  does anyone still think
that it can have "end to end" connectivity, so that if i want to monitor it
or control it while on vacation, i'll send IPSEC-signed datagrams from my
hotel room to do so?  that i'll subject it to every DDoS attack, stack
smash attack, IPSEC key guessing attack, plus any other attacks i can't
think of or which havn't been invented yet?  or do we think that it'll sit
in fe80:: and be talked to only by some local (hardened) proxy?  or that at
best it'll have a ULA-G address, reachable by my household security company's
local embedded network but no further?

i'm not saying the DFZ will go out of style.  i'm saying that when we fill
half of the IPv6 address space with light switches and toasters and security
cameras and music players, we'll have 18446744073709551616 endpoints, of which
only a handful are "hardened enough" to be allowed to be globally reachable.
so in contrast to the current IPv6 addressing plan where 0/0 is the DFZ other
than a few cutouts like fe80:: and fc00::, if we were going to be realistic
about how stuff was actually going to be connected in this BCP38-free world,
we'd've allocated beef::/16 to the DFZ and assumed that the rest of IPv6
would be used by non-DFZ devices.

fortunately, the difference between 120 bits and 128 bits is minor compared
to the magnitude of the 120 bit mantissa available in my ULA-G proposal.  so,
the fact that the addressing plan assumes "DFZ uber alles" is no great waste.

on the other hand, i like where you went with this, so i'll quote it all in

> becomes a significant issue, and the pain (of renumbering) grows.

yea, verily.  tell it, brother!

> Placing the potential recipient in the position of having to choose between
> PA, and a difficult-and-costly-to-obtain PI block, is by its nature harmful
> to the deployment of IPv6.

as it has been for IPv4, but people coped because there was a legacy swamp.
in the absence of a legacy swamp, the PI/PA split has a chilling effect on
IPv6 deployment, over and above the chilling effect of the technology and
training costs.

> And it is for this reason that I advocate reducing or eliminating costs, and
> relaxing the requirements for receiving PI space.  For instance, deferring
> the costs of PI space until the PI block is added into the DFZ, is one
> option.

i'm not saying whether i agree or disagree with this proposal.  i'll merely
remind you, again, that IETF doesn't set PI policy, that's a regional thing
and you'll need to follow jordi to all the RIR meetings and make your 
proposals to the actual decisionmakers, who are the members of various RIRs.

> of the problems, under any scheme for handling relocation in connectivity

1:1 NAT is only a predictable problem if you think the DFZ will always be
the dominant form of communication.  when i finally get my Dick Tracy Tv
Wrist Watch and i make a wrist-to-wrist call to someone in my same city,
you can bet that my wireless provider and the other-end wireless provider
are going to have private peering, and that ULA-G would work just fine for
us.  and that in the long distance use case, the LCR algorythm will choose
some city-local proxy who might or might not use DFZ on the backside, but
i most likely won't be using the DFZ on my own behalf.

> whether the PA block itself is being sub-assigned, or if a separate PI block
> from which 1:1 NATv6 is instead PA'd and sub-assigned.

agreed.  nor would it matter if the 1:1 NATv6 was to a ULA-G address block.

> flexibility for back-door networking at arbitrary scale.

yup.

> promoted, for use in this case.

you're making this particular case to the wrong audience.

> PI blocks can be announced into the DFZ, and ULA-C are specifically not

you're assuming that someone with ULA-G and 1:1 NAT won't find a comfortable
equilibrium with their ISP whereby their use of PA avoids all lock-in issues.

why?  (isn't this the holy grail of eid/loc separation?)

> with NATv6 into PA space (for access to the DFZ), all is good.

i don't think an organization has to be able to foresee this in order for 
all to be good.  in fact, in your 1:1 NAT case and with some simplistic
assumptions about LCR, multihomed ULA-G might be able to perfectly coexist
with a perfectly-aggregated DFZ.  though we're way off topic by this time.

> is still aggregated into a single PI block in the DFZ.

that would work as well as anything else that's been proposed and better
than most.  (though there's the detail of PI vs. ULA-G and the fact that IETF
is the wrong forum to talk about PI.)

> and announcing the PI block directly into the DFZ.

i don't get that last part.  you're assuming that a 200-megaroute DFZ is
coming to earth within our lifetimes?  but other than that last part i'm
ready to drink this particular koolaid, as long as "require their own PI
block" is semantically equivilent to "owns global POSIP backbone and does
peering and transit in many major markets", which i think it probably is.

> So, what kind of PI blocks should be made available?

(wrong audience.  visit [email-masked] to start, then follow jordi.)

> deployment of IPv6 on a large scale (numbers of entities deploying as well

my summary: ULA-G does everything you want, but can actually be argued here
in ipv6@ rather than having to make new coherent global RIR policy.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 03 Jul 2007 05:01:53 +0000

> ... all of this ignores the fact that, architecturally, NATs have been
> rejected as bad for end-to-end connectivity.  To minimize problems caused by
> NAT, it would probably be better to use autoconfiguration (stateless or
> DHCP) to assign PA addresses to hosts (in addition to any non- globally-
> routed space used).

where PA is available because connectivity to the global internet is
available, i agree.  but if the connectivity realm of interest doesn't happen
to include a the global internet, NAT may not be nec'y even if ULA-G is used.

i think that "architectural rejection" means "academy vs. field" and the
field always wins.

---

From: Scott Leibrand <[email-masked]>
Date: Mon, 02 Jul 2007 23:07:11 -0700

> to include a the global internet, NAT may not be nec'y even if ULA-G is used.
Of course. 

Perhaps we should call them Unique Global Addresses, (UGAs), if that TLA 
isn't too easily confused with the University of Georgia...  Aren't 
acronyms fun?  :-)

If I have a neighborhood network and want to peer with adjacent 
neighborhoods to make an ad-hoc metro network, I'd be happy to announce 
my ULA-G block  and accept whatever UGA/ULA-G/ULA-C/ULA routes my 
neighboring networks would like to announce (with the exception of those 
covered by my block, of course).  I'll be happy to give my hosts U?A 
addresses so they can communicate with the rest of the city at WLAN/MAN 
speeds, as well as PA addresses to communicate with the rest of the 
world at Internet speed.

-Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Jul 2007 10:03:56 +0200

Paul,

On 2007-07-02 18:53, Paul Vixie wrote:
> control is achieved by limiting the horizon of announcements.

Absolutely. And from what I've heard, "a lot" may in fact be as much
as 90% for some ISPs.

> ULA-C with my

And actually that is where we seem to be at odds. I fear that ULA-G will leak.
That's all.
> from the one that came before it.

Yes, I mean the DFZ - as above, I fully understand that there are already
vast numbers of private routes.

> form of lock-in that even microsoft and apple can only dream about.  

As an aside, that's why the normal model in IPv6 is for a user site to
run several PA prefixes simultaneously, and that's why we designed shim6.

> if the

I hope you're right. My argument against structured ULA prefixes is only
to make it less likely to happen.

> realm where RPKI can help some day to the realm of ``i got it from agnes''(*)"

I'm not sure I understand that, given that random ULA-C assignments would
be escrowed in some way, but it will clearly be *easier* to trace
ownership of structured ULA-Cs.

> will collapse, and take the internet down in flames."

I suspect that's an exagerration since this is a statistical game anyway,
but my concern is along that axis.

> it than whose livlihoods could be enriched by it.  (it's all about the money.)

This is the key point. If you're right, there is nothing to be concerned
about.

> of domain names registered in .COM and .DE (the two largest TLDs).

I don't get that. Customers need routeable prefixes. Why do you need
a ULA-C prefix for a customer?

     Brian

---

From: <[email-masked]>
Date: Tue, 3 Jul 2007 09:56:19 +0100

> consider an ipv6-reachable light switch in my house.  does 
> anyone still think that it can have "end to end" 
> connectivity, so that if i want to monitor it or control it 
> while on vacation, i'll send IPSEC-signed datagrams from my 
> hotel room to do so?  that i'll subject it to every DDoS 
> attack, stack smash attack, IPSEC key guessing attack, plus 
> any other attacks i can't think of or which havn't been 
> invented yet?  or do we think that it'll sit in fe80:: and be 
> talked to only by some local (hardened) proxy?  or that at 
> best it'll have a ULA-G address, reachable by my household 
> security company's local embedded network but no further?

This isn't the use-case that matters because, as you pointed out,
light-switches are likely to be hidden behind a master-controller of
some sort. The important use-case is devices which need to behave like a
telephone set, i.e. raise an alarm when there is an incoming connection
attempt and establish a connection upon request of the local user or
some device that proxies for the local user. Of course this
telephone-set device may be an actual VoIP telephone with attached
answering machine. Or it could be something entirely different such as a
medical monitoring device, a home security device which is polled at
random intervals, or a blackberry-like device, etc. etc.

> on the other hand, i like where you went with this, so i'll 
> quote it all in hopes that those who didn't read it the first 
> time will read it now:
> 

Agreed. This is a problem that still needs to be addressed by the IETF.
In IPv4 the excuse was that the number space was limited. But in IPv6 we
no longer need to impose one model on everyone. I'm working on a draft
that presents one possibility.

--Michael Dillon

---

From: Perry Lorier <[email-masked]>
Date: Tue, 03 Jul 2007 21:27:15 +1200

> And actually that is where we seem to be at odds. I fear that ULA-G 
So I might be a bit naive here, but why is this a problem?  ISP's that 
are worried that they're routers can't deal with ULA addresses in their 
DFZ will filter all ULA addresses.  ISP's that want ULA's in their DFZ 
will make sure they dimension their routers such that they can deal  
with it.  Other ISP's will find some kind of middle ground where they 
have some ULA prefixes,The DFZ is certainly not the same everywhere on 
the Internet, by making ULA's easily filterable it gives operators a 
place to start if they want to filter.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 03 Jul 2007 14:06:39 +0000

> Of course. Perhaps we should call them Unique Global Addresses, (UGAs), ...

all PI and PA would be "UGA" though.  ULA-C and ULA-G are more specific.

> neighborhoods to make an ad-hoc metro network, I'd be happy to announce my
> ULA-G block and accept whatever UGA/ULA-G/ULA-C/ULA routes my neighboring
> networks would like to announce (with the exception of those covered by my
> block, of course).

importantly, you would not accept driveby ad-hoc.  i think that if a malware
injection van hits your neighborhood with a pringles-can antenna from a nearby
hillock, that you should be able to decide based on their RIPE-181
registration data and/or their SBGP or RPKI registration data that you don't
know them well enough to admit them into your wireless mesh network.  that's
not going to happen with straight ULA, which is why ULA-C or ULA-G are
necessary for this use case.

> I'll be happy to give my hosts U?A addresses so they can communicate with
> the rest of the city at WLAN/MAN speeds, as well as PA addresses to
> communicate with the rest of the world at Internet speed.

note that in brian's best-possible-world scenario, you'd be able to do what
you want with PI.  however, we're not in that world, and we need the crutch
of leading high-end address bits to tell our NATv6 boxes when to act, and to
tell our DFZ-path routers when not to act.  thus, ULA-G or ULA-C.

---

From: Paul Vixie <[email-masked]>
Date: Tue, 03 Jul 2007 14:53:27 +0000

[paul vixie]
> > ...  i don't have objective measurements, but i know that a lot of table
> > size control is achieved by limiting the horizon of announcements.

[brian carpenter]
> Absolutely. And from what I've heard, "a lot" may in fact be as much

so, we share a supposition that the DFZ is now a minority of "the Internet".

> > ULA-C with my proposed diffs is just a way to take this a lot further, to
> > legitimize it, to scale it up to planetary size.
> 
> And actually that is where we seem to be at odds. I fear that ULA-G will
> leak.  That's all.

consider a spectrum of possibilities:

    --------------------------------------------------------
     O(10^4)                 O(10^6)                O(10^8)

in the leftmost cast, the number of ULA-G prefixes is so small that we could
accomodate them in the DFZ, and the only "problem" would be that it was an end
run around regional (RIR) policymaking.

in the rightmost case, the number of ULA-G prefixes is so large that no single
routing table can hold them, not even the much vaunted 2-megaroute machinery
that's now on various drawing boards.

in the middle, there's a range of size that's large enough to hurt a lot but
small enough to be practical if everybody sends cisco and juniper a great deal
of money.

what is the size of your fear?  i ask because my supposition is that the DFZ
is already a minority and that something like ULA-G (or even ULA-C) would make
it an even smaller minority.  and i consider the rightmost case the likeliest
number of ULA-G routes, and that the number of likely DFZ leaks to be zero.

in the DFZ today are many competitors and thin margins.  for a "leak" to be
successful, one provider has to want to emit a ULA-G route, and virtually all
other providers have to be willing to accept it.  this is so unlikely that i
can't imagine it.  it's not equivilent to the RFC1918 or non-BGP38 emissions
problems, since every "leak" in this case means a competitor signs recurring
revenue for a customer who was in play.  "that is sooooo not going to happen."

> >> We need to encourage the former and discourage the latter (as far as
> >> seeing them in BGP is concerned).

> > if you mean by "BGP", the DFZ, then i'd agree with this statement in
> > isolation from the one that came before it.

> vast numbers of private routes.

then we really do agree that when it comes to the DFZ, aggregation is a MUST.
and our area of disagreement is simply whether deaggregated ULA-G will enter
the DFZ.  i have several times shown why i think that can't happen.  most BGP
operators are looking for any excuse to filter inbound routes, especially TE
routes whose only purpose is to improve the efficiency and service quality of
competitors.  an RFC that strongly recommends that FC00::/7 be filtered will
be an excuse that most of these operators will be thankful for (hopefully
that could mean "beer as in free").

> > ... the tier-1 providers ... can afford 2-megaroute forwarding machinery,
> > they compete aggressively for end-sites against both other tier-1's and
> > all of the regional or value-add or low-cost tier-2's, and they really
> > like the PA concept because the renumbering penality gives them a form of
> > lock-in that even microsoft and apple can only dream about.
> 

on that aside, when i connect up my end host to a LAN that has multiple router
advertisements, it selects exactly one as my default route.  there's no LCR as
in the telephony world.  there's no intent to import the entire routing table
into every host -- the router advertisements i don't select are backups not
competitors.  the shim6 idea makes it more interesting -- how's that working
out in the field?  any significant deployment experiences to report?  (i'm
not just still bitter about the A6/DNAME debacle -- i really want to know.)

> > if the tier-1's decide to exchange ULA-C routes with each other, then the
> > rest of the internet has to do likewise.  and if some really large cash
> > cow of a customer puts out an RFP to tier-1 saying "we'll buy bandwidth
> > from whoever will route our ULA-C into the internet core" then it'll be
> > very interesting.  is this your proposed "pressure to stick" comes from?
> > because i can think of a dozen reasons why it can't happen, all based on
> > business strategy and self-interests of every single party involved in
> > that money chain.
> 
> I hope you're right. My argument against structured ULA prefixes is only to
> make it less likely to happen.

the benefit of ULA-G away from the DFZ is so much greater than the risk of
ULA-G to the DFZ that i can't even consider them simultaneously long enough
to let them compete.  from what you're saying, i don't know if you can either.

> > approximately one per family, worldwide, counting only the population who
> > has electric power.  much much higher than the 2-megaroute level, or the
> > number of domain names registered in .COM and .DE (the two largest TLDs).
> 
> I don't get that.  Customers need routeable prefixes.  Why do you need a
> ULA-C prefix for a customer?

the idea of an internet made up only of customers was never part of the early
vision as it's been told to me.  every device needs a unique identifier for
any number of reasons.  if the DFZ is intolerant of these identifiers, then
they'll show up in other ways, like non-DFZ routing, 1:1 NATv6, ad-hoc IPSEC
tunnel innards, software key/serial numbers, and things we've not imagined.

the DFZ is one way to internet.  only one way.  and it's not the only reason
one might need a registered unique addresses.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 03 Jul 2007 16:54:48 +0200

> place to start if they want to filter.

Of course. But by leak, as I think was clear in later mail, I meant leak
deliberately under economic pressure. Accidental leakage would be
statistically insignificant, I assume, and easily filtered out as you
say.

    Brian

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 03 Jul 2007 08:17:37 -0700

Brian E Carpenter wrote:
>> So I might be a bit naive here, but why is this a problem?  ISP's 
>> that are worried that they're routers can't deal with ULA addresses 
>> in their DFZ will filter all ULA addresses.  ISP's that want ULA's in 
>> their DFZ will make sure they dimension their routers such that they 
>> can deal  with it.  Other ISP's will find some kind of middle ground 
>> where they have some ULA prefixes,The DFZ is certainly not the same 
>> everywhere on the Internet, by making ULA's easily filterable it 
>> gives operators a place to start if they want to filter.
>

Brian,

Can you outline the economic pressures that you believe would lead to a 
ULA-C/ULA-G being accepted by more the majority of tier1ish transit 
providers in the DFZ?  Like Paul, I'm inclined to believe the 
countervailing economic pressures would be much stronger, and that we 
will see very few, if any, ULA routes crossing the magic threshold of 
global routability.  I would love to hear and possibly debate the 
counterarguments.

Thanks,
Scott

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 3 Jul 2007 13:38:43 -0500

Thus spake "Scott Leibrand" <[email-masked]>
> Yes, I agree that any site should be able to get a ULA-C
> assignment, at nominal cost, and that ULA netblocks should
> be kept out of the DFZ.

I think we all agree that ULA prefixes _should_ be kept out of the DFZ, but 
the organizations (IETF, RIRs) debating this policy have absolutely zero 
ability to make it happen.  At most, it's a suggestion to operators, and 
I'll need more than a mere suggestion that a unique prefix isn't routable to 
be even neutral on the topic.

If people want guaranteed-unique addresses, let them go to their RIR for PI 
space.  If their RIR doesn't give such out, they can change the policies. 
If they're unable to change the policies, there obviously is not sufficient 
public support for the idea in the first place, and the IETF has no business 
telling the RIRs they're wrong.

ULA-C is an attempt to get around RIR policy mechanisms, plain and simple. 
Don't give me this "but the RIRs don't have to take it" stuff, because 
registry shopping will occur.  As long as one RIR signs up, we're all going 
to be forced to live with the results.

S

Stephen Sprunk      "Those people who think they know everything
CCIE #3723         are a great annoyance to those of us who do."
K5SSS                                             --Isaac Asimov

---

From: Paul Vixie <[email-masked]>
Date: Tue, 03 Jul 2007 19:45:43 +0000

["Stephen Sprunk" <[email-masked]>]
> ULA-C is an attempt to get around RIR policy mechanisms, plain and simple.

no.  nor ULA-G.  read the drafts.  ask the authors what they're attempting,
and then call us liars if you wish, but do not under any circumstances tell
us what we're attempting.  we already know.

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Jul 2007 10:07:16 +0200

On 2007-07-03 16:06, Paul Vixie wrote:
...
> tell our DFZ-path routers when not to act.  thus, ULA-G or ULA-C.

The reference to NATv6 confuses me. There's nothing about ULA-* that leads to
NAT. Users will have PA (or PI for the lucky few) prefixes for global connectivity.
ULA-* is for local use (in the sense that RFC 4864 uses "local").

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Jul 2007 10:49:06 +0200

> so, we share a supposition that the DFZ is now a minority of "the Internet".

Or possibly that we don't know what "the Internet" is any more...

> consider a spectrum of possibilities:

Certainly. And that is roughly the scale that the RAM debate is
considering, although the working hypothesis there is more like
10^7 prefixes.

> number of ULA-G routes, and that the number of likely DFZ leaks to be zero.

Well, my hypothesis is a network with 10^10 nodes and with 10^7 prefixes
in need of multihoming across the DFZ. But no ULA-* prefixes should be
in the DFZ; so these hypotheses seem to be compatible.

> revenue for a customer who was in play.  "that is sooooo not going to happen."

I have to say that sounds convincing. I suppose there will be
exceptions, but not enough to matter. (An exception is where BigBadCorporation
insists on being accessible only via its junk /48, but every customer
of every ISP wants to reach www.BigBadCorporation.com. Then the incentive
exists to route that /48.)

> that could mean "beer as in free").

Ack, as already stated in RFC 4193 section 4.1 para 3.

> not just still bitter about the A6/DNAME debacle -- i really want to know.)

No. It's really too soon. The shim6 documents are in WG Last Call right now.

> to let them compete.  from what you're saying, i don't know if you can either.

Agree

> one might need a registered unique addresses.

Here we do get into the ID/Loc split discussion that's going on over
in RAM and RRG. *If* that concludes that
  a) a split is needed
  b) the IDs should be in IPv6 address format
  c) they don't need to be cryptographically generated
  and d) they do need to be registered and DNS-able
then ULA-G would clearly be a candidate, and ULA-C wouldn't.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 04 Jul 2007 10:51:39 +0200

> global routability.  I would love to hear and possibly debate the 

See what I just wrote to Paul. I agree that statistically, the vast
majority of ULA-* prefixes are exempt from my concern. And I guess
a little leakage wouldn't matter.

     Brian

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 4 Jul 2007 14:10:31 -0500

Thus spake "Brian E Carpenter" <[email-masked]>
> The reference to NATv6 confuses me. There's nothing about ULA-*
> that leads to NAT. Users will have PA (or PI for the lucky few) prefixes
> for global connectivity.  ULA-* is for local use (in the sense that RFC
> 4864 uses "local").

One of the arguments by the anti-ULA crowd is that if someone is unable to 
also get PI space, they will NAT their ULAs to PA space rather than 
assigning the PA space to hosts directly, because NAT is perceived as less 
hassle than renumbering every few months.  As a pro-ULA (just not the -C 
or -G variants) person, I have to admit I'd do that if I couldn't get PI 
space.  I'm anti-NAT, like most IETFers, but I'd still use it if it were the 
least-bad option.

There's also the usual "NAT makes me more secure" flamefest, but that 
applies to folks with PI space as well.  There's a lot of PIv4 space hidden 
behind NATs for "security" reasons...

S

---

From: Joe Abley <[email-masked]>
Date: Wed, 4 Jul 2007 15:21:01 -0400

On 4-Jul-2007, at 04:07, Brian E Carpenter wrote:

> that leads to
> NAT.

There's nothing about RFC 1918 that leads to NAT, either. But it  
seems likely that the vast majority of RFC 1918-numbered devices in  
the world have a default route pointing at one.

Joe

---

From: Perry Lorier <[email-masked]>
Date: Thu, 05 Jul 2007 13:23:38 +1200

Stephen Sprunk wrote:
> One of the arguments by the anti-ULA crowd is that if someone is unable 
> to also get PI space, they will NAT their ULAs to PA space rather than 
> assigning the PA space to hosts directly, because NAT is perceived as 
> less hassle than renumbering every few months.  

Except with v6 you can quite easily have multiple prefixes on an 
interface.  So you can have your ULA prefixes for your internal services 
(dns servers, smtp servers, whatever) and use your globally routable 
IPv6 addresses for IPv6 connectivity.

Things get a bit more annoying if you have internet facing services 
(public webservers, etc), but no more annoying than it was in the world 
of NAT.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Jul 2007 01:53:39 +0000

> > less hassle than renumbering every few months.

i don't understand.  yes they will do that because PA space is expensive in
that way.  but why is that bad and who is it bad for?

> Except with v6 you can quite easily have multiple prefixes on an interface.
> So you can have your ULA prefixes for your internal services (dns servers,
> smtp servers, whatever) and use your globally routable IPv6 addresses for
> IPv6 connectivity.

for client side connections, i wonder if we're going to see path assymmetry?
that is, if i have routes for 0::/0 and for fc00::/7, and i have interface
addresses in 2001::/16 and in fc00::/6, and i make outbound tcp connections,
is there any requirement in the IPv6 stack documentation that my tcp endpoint
use an address that's consistent with the routing table entry it follows?  in
times past, it took an actual separate interface to get most BSD stacks to
work this way.  (especially for UDP services like NFS, NTP, and DNS, for 
which this kind of symmetry is also important.)

if end systems having multiple addresses supernetted on the same LAN are able
to use a DFZ-verse source address when reaching the ULA-verse, or vice versa,
then this supernetting/multihoming capability buys us precisely nothing.  i'm
ignorant at this level of IPv6 spec detail, so, i'm asking.

> Things get a bit more annoying if you have internet facing services (public
> webservers, etc), but no more annoying than it was in the world of NAT.

it's actually much easier for the server side, since you can just answer with
source addresses consistent with whichever supernetted interface address your
NAT box contacted you, and your NAT box will flow-map you on the outbound
side.  outbound (usually this means "client-side") is the real trouble spot.

---

From: Paul Vixie <[email-masked]>
Date: Thu, 05 Jul 2007 02:20:30 +0000

[vixie]
> > is now a minority of "the Internet".

[carpenter]
> "the Internet" is any more...

indeed, we don't.  one of the reasons i was dragging seth breidbart's
definition out and re-airing it here a few weeks back is that these
discussions are an indirect attack on the idea of a "largest closure".

that is, someone with access to a large set of private routes and also
to the "public internet" is part of a larger symmetric closure than
someone who is only connected to the "public internet".  i think the
closure has become nonsymmetric, and nobody noticed until this moment.

> > in the DFZ today are many competitors and thin margins.  for a "leak" to
> > be successful, one provider has to want to emit a ULA-G route, and
> > virtually all other providers have to be willing to accept it.  this is so
> > unlikely that i can't imagine it.  it's not equivilent to the RFC1918 or
> > non-BGP38 emissions problems, since every "leak" in this case means a
> > competitor signs recurring revenue for a customer who was in play.  "that
> > is sooooo not going to happen."
> 
> I have to say that sounds convincing.  I suppose there will be exceptions,
> but not enough to matter.  (An exception is where BigBadCorporation insists
> on being accessible only via its junk /48, but every customer of every ISP
> wants to reach www.BigBadCorporation.com.  Then the incentive exists to
> route that /48.)

the concept of "incentive" presupposes a value system and "incentee", and in
the DFZ, there is not a value system in common among enough potential
incentees to make what you're talking about feasible except through error
or accident.

[carpenter]

> > ... the shim6 idea makes it more interesting -- how's that working out in
> > the field?  any significant deployment experiences to report?  (i'm not
> > just still bitter about the A6/DNAME debacle -- i really want to know.)

> No. It's really too soon. The shim6 documents are in WG Last Call right now.

so, it's been designed, but noone knows whether it will have any effect on
this problem space.  let's leave it out of the discussion, then.

> > ULA-G to the DFZ that i can't even consider them simultaneously long
> > enough to let them compete.  from what you're saying, i don't know if you
> > can either.
> 
> Agree

that's good to hear confirmed.

> > ...  every device needs a unique identifier for any number of reasons.  if
> > the DFZ is intolerant of these identifiers, then they'll show up in other
> > ways, like non-DFZ routing, 1:1 NATv6, ad-hoc IPSEC tunnel innards,
> > software key/serial numbers, and things we've not imagined.  the DFZ is
> > one way to internet.  only one way.  and it's not the only reason one
> > might need a registered unique addresses.
> 

code first, then spec.  let's allocate a couple ten million ULA-G prefixes and
see how the field develops it.  should be way more interesting than waiting to
see if this year's iteration of the ivory tower "do we need an id/loc split?"
debate ends any more remarkably than previous ones.

---

From: Perry Lorier <[email-masked]>
Date: Thu, 05 Jul 2007 14:52:04 +1200

Paul Vixie wrote:
> use an address that's consistent with the routing table entry it follows?  

Yeah.  RFC 3484 "Default address selection for Internet Protocol version 
6 (  6)".

Basically (massive oversimplifications here) it says:

* if connecting to an address, if you can use that as the source address 
use that.

* don't bother with addresses that aren't scoped enough.  (Don't use 
link local to connect to a globally scoped address, but you can use a 
globally scoped address to connect to a link local if you really had to).

* Avoid deprecated addresses (addresses which you've not seen Router 
Advertisements for in a while)

* Prefer home addresses when using mobile IP

* Prefer the outgoing interface IP over some other IP

* Prefer "matching label" (addresses of the same type, such as 6to4, 
teredo, whatever)

* Prefer public addresses over temporary addresses (or if an application 
asks the reverse)

* Do whatever you feel like if you can think of a reasonable rule to go 
here.

* Use the longest matching prefix.

Theres also a whole heap of stuff about how to choose a destination 
address given a set of them (eg from DNS) and how the system 
administrator should be able to influence these decisions.

 > in

Yeah, part of IPv6 working well with multiple prefixes on an interface 
is better selection of source/destination addresses.

> ignorant at this level of IPv6 spec detail, so, i'm asking.

You can use the "least greater or equally scoped address".  So you will 
always prefer using a ULA address to talk to another ULA address.  If 
you only have globally routable and link local scoped address you can 
only use the globally routable address to speak to the ULA address (the 
link local source address isn't going to be useful).

When considering destination addresses I believe you can reply because 
you can assume it's reachable since you received a message.

All this magic is hidden inside the stub resolvers/kernel.  If you call 
getaddrinfo(3) you'll get back a sorted set of v6 (and v4 I guess) 
addresses that are likely to work, in preferential order so applications 
(in general) don't have to care.  I guess this encourages people to 
publish ula, globally scoped and even link local addresses in DNS since 
it will mean your clients will be able to figure out which of those 
address is the best for them to use.

> side.  outbound (usually this means "client-side") is the real trouble spot.

Hrm, I guess.  Updating DNS server glue is annoying (has anyone ever 
considered having DNS servers send signed UPDATE messages to 
register/deregister their glue?  It would certainly make things a lot 
easier for administrators.), but almost everything else should be easily 
done via updating DNS.

---

From: "Stephen Sprunk" <[email-masked]>
Date: Wed, 4 Jul 2007 22:11:04 -0500

Thus spake "Perry Lorier" <[email-masked]>
> (dns servers, smtp servers, whatever) and use your globally routable IPv6 
> addresses for IPv6 connectivity.

The fact that one _can_ assign both ULAs and PA space to hosts is 
irrelevant; I'm well aware of that.  NAT is perceived by IT folks as less 
hassle than renumbering hosts.  PA space implies frequent renumbering. 
Therefore, many (most?) IT depts who cannot get PI space will use NAT rather 
than assign PA space to hosts.

S

---

From: Perry Lorier <[email-masked]>
Date: Thu, 05 Jul 2007 17:43:05 +1200

Stephen Sprunk wrote:
>>> One of the arguments by the anti-ULA crowd is that if someone is 
>>> unable to also get PI space, they will NAT their ULAs to PA space 
>>> rather than assigning the PA space to hosts directly, because NAT is 
>>> perceived as less hassle than renumbering every few months.
>>
>> interface.  So you can have your ULA prefixes for your internal 
>> services (dns servers, smtp servers, whatever) and use your globally 
>> routable IPv6 addresses for IPv6 connectivity.
> 
> irrelevant; I'm well aware of that.  NAT is perceived by IT folks as 
> less hassle than renumbering hosts.  PA space implies frequent 
> renumbering. Therefore, many (most?) IT depts who cannot get PI space 
> will use NAT rather than assign PA space to hosts.

However in IPv4 you can have PA xor PI space, you can't have both at the 
same time.  With IPv6 you can have PA+"private PI" (aka ULA) space.

My router can dish out some different PA space every time my dialup 
modem reconnects if my internal network is all using ULA internally. 
I'm not really sure that situation really is "renumbering" in the 
traditional sense even tho I'm not using NAT nor am I using public PI space.

Changing your PI space every time your modem dials up is perhaps a bit 
extreme, but it shows that you can ""renumber"" your network rapidly in 
some situations.  Problems occur for externally facing services, but 
that doesn't seem insurmountable for an organisation that's likely to 
only change PI space at most every year or so.

If your choices are PI vs PA then yeah NAT does look very attractive, 
but if you can have PA and "private"-PI (aka ULA) then things look a lot 
less blurred (IMHO).

Not having ULA space won't stop people from randomly picking address 
ranges to use.  Not having NAT boxes easily available for v6 however 
might make people rethink their assumptions.

---

From: Scott Leibrand <[email-masked]>
Date: Wed, 04 Jul 2007 23:32:38 -0700

Perry Lorier wrote:
>>>> rather than assigning the PA space to hosts directly, because NAT 
>>>> is perceived as less hassle than renumbering every few months.
>>>

Yes, many IT depts will probably do that.  IMO, that's fine.  The IT 
folks I know may not be fully versed in all the details of what NATs 
break, but they know they break some things, and they know how to gather 
enough information to make a decision about what's best for their 
business.  So IMO, if they think NATs are best for their situation, 
that's fine.  Often they don't want their users to have end-to-end 
connectivity, and while I would be most upset if my ISP made that 
decision for me, I can only really get upset about my employer doing it 
if it negatively impacts my productivity somehow.

>
> However in IPv4 you can have PA xor PI space, you can't have both at 
> the same time.  With IPv6 you can have PA+"private PI" (aka ULA) space.
>
> extreme, but it shows that you can ""renumber"" your network rapidly 
> in some situations.  

The other possibility is that a heterogeneous corporation may decide to 
use ULA-G space internally, NAT it at the edge, and also assign PA space 
via DHCP or RA's wherever it's easy to do.  If they can give 80% of 
their users public IPs with only 20% of the effort, they can probably 
just NAT the other 20% and be fine.   As always, we have to just give 
people the tools and the documentation about how to use them, and then 
trust that they'll make a good decision for their particular situation.

-Scott

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Jul 2007 09:11:03 +0200

> will use NAT rather than assign PA space to hosts.

I don't see why. Most IT managers are painfully aware of the hassle
caused by NAT (e.g. when setting up their VoIP infrastructure
or their remote-acess VPN infrastructure). Hopefully they will read
RFC 4192 and 4864 and apply appropriate pressure to their suppliers.

     Brian

---

From: "Stephen Sprunk" <[email-masked]>
Date: Thu, 5 Jul 2007 19:59:41 -0500

>> Therefore, many (most?) IT depts who cannot get PI space will use NAT 
>> rather than assign PA space to hosts.
>

See above.

> some situations.

A single host is easy to renumber.  A small network with one router is only 
slightly more complicated.  However, renumbering a medium-sized or large 
network can take months to years to accomplish and hundreds of thousands of 
dollars in manpower.

> Problems occur for externally facing services,

As a general rule, clients are easy to renumber, whereas servers are 
difficult and firewalls are even worse.  And I'm including human costs and 
resistance in that; changing the address on an interface is almost a 
nonevent in comparison.

> but that doesn't seem insurmountable for an organisation that's likely to

Why would you ever change PI space?  The issue is changing PA space, and 
that's something that may need to be done every few weeks as upstream links 
go up and down.  Compare to the cost of a NAT box and the choice is easy.

> If your choices are PI vs PA then yeah NAT does look very attractive, but 
> if you can have PA and "private"-PI (aka ULA) then things look a lot less 
> blurred (IMHO).

IMHO, you underestimate how much IT folks hate renumbering.

S

---

From: Mark Andrews <[email-masked]>
Date: Fri, 06 Jul 2007 12:31:36 +1000

> go up and down.  Compare to the cost of a NAT box and the choice is easy.

	Please justify this assumption.

	Are you still thinking that there would be a single PA per
	host?  If you are connected to the same upstream via multiple
	paths then there is/should be no need to renumber.  If you
	are connected to multiple upstreams then you have multiple
	PA prefixes on each and every box.  It should be be as easy
	as having the routers deprecating the prefix advertisements
	to have all the end systems select alternate PA addresses
	when initiating sessions.
 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 06 Jul 2007 09:47:19 +0200

On 2007-07-06 02:59, Stephen Sprunk wrote:
...

> that's something that may need to be done every few weeks as upstream 
> links go up and down.  

Absolutely not. If you have 3 ISPs you run 3 PA prefixes all the time.
If you drop or add an ISP you drop or add a prefix in a planned manner.
RFC 4192.

> Compare to the cost of a NAT box and the choice 
> is easy.

That's true if you don't put the indirect operational and user
costs of NAT, plus the opportunity cost of innovation blocked
by NAT, into the equation. It *is* hard to get this into the budget
unless you think strategically, and factor in the way IPv6 is
designed to handle multiple PA prefixes simultaneously.

>> but if you can have PA and "private"-PI (aka ULA) then things look a 
>> lot less blurred (IMHO).
> 

They hate renumbering IPv4 networks. I do too, having managed such an
operation a couple of times. It's as a result of that hatred that
IPv6 came out as it is, making RFC 4192 possible.

This is *not* to say that anyone will renumber weekly, and big networks
will avoid it (and are therefore candidates for PI). But for smaller
networks, the hatred should be substantially less, and balance the hatred
of NAT.

    Brian

---

From: "Stephen Sprunk" <[email-masked]>
Date: Fri, 6 Jul 2007 14:41:02 -0500

>> Why would you ever change PI space?  The issue is changing PA
>> space, and that's something that may need to be done every few
>> weeks as upstream links go up and down.
>

When my link to one of those three ISPs goes down, I have a 1/3 chance of 
each outbound connection failing because the return path is broken (or my 
other two upstreams do uRPF).  I also have a 1/3 chance of each inbound 
connection failing until I update DNS to remove the relevant AAAA records; 
smarter clients will try multiple addresses for inbound connections, but 
there'll be a delay and not all clients are that smart.

The alternative is to renumber the entire network every time a link goes up 
or down.

>> Compare to the cost of a NAT box and the choice is easy.
>
> by NAT, into the equation.

Most of the operational and innovation costs of NAT are also present with a 
stateful firewall, which any sane organization will be using, because it's 
really the stateful inspection that burns you.

> It *is* hard to get this into the budget unless you think strategically,
> and factor in the way IPv6 is designed to handle multiple PA prefixes
> simultaneously.

When presented with the choice between a paradigm shift and continuing along 
the present path, most people will pick the latter.  In this case, that 
means moving either from NAT+RFC1918 to NAT+RFC4193 or from PIv4 to PIv6.

> IPv6 came out as it is, making RFC 4192 possible.

Again, RFC 4192 ignores all of the non-technical aspects of renumbering. 
That's probably appropriate, given the IETF's domain, but it's only a tiny 
part of what must be done.  Changing the address on an interface takes a few 
seconds; the change control processes leading up to it can burn months of 
manpower.

You might convince me that if you do it frequently enough, the cost will be 
low, but I don't want to work anywhere that renumbers often enough to be 
good at it.  That reminds me of a scene in _Broken Arrow_ where a character 
comments he doesn't know whether to be more scared that they lost a nuclear 
weapon or that it happens often enough the military has a name for it.

> networks, the hatred should be substantially less, and balance the hatred

It's the smaller folks that can't get PI that hate NAT the least, because 
they tend to have less-educated staff (or rely on consultants/vendors) and 
may even see NAT as a good thing ("it makes me secure!"), not the evil that 
it really is.

S

---

From: Roger Jorgensen <[email-masked]>
Date: Sat, 7 Jul 2007 22:18:32 +0200 (CEST)

> it to only being valid for globally connected devices, reachable from DFZ.

There are cases where the network administrators dont care about the 
global DFZ, aggregation or whatever, they just want enough IP for their 
INTERNAL usage. And now are we back to what we (where I work) need ULA-C/G 
for...

- we don't need the full internet connectivity or reachability, we simply 
dont care whats on the internet from our point of view. We have RIR 
assigned IPblock for _all_ our global needs and let our chosen ISP provide 
us global internet when they announce _our_ RIR assigned netblock
- unique addresses so when we interconnect to other organization we dont 
get collision ever, neither now or in 10years time. ULA-L simple isnt 
enough, 2^40 is not good enough. No point in argueing over that.
- we dont want NAT anywhere in our network, that break the end to end 
connectivity we need for lots of things. Our internal video or phone 
system or whatever other application we have/will get.
- we need full reverse DNS control over the ULA-C/G blocks we have (we 
will get several thousands of them) since that way the other organization 
just have to go to the internet root DNS to lookup our IPs, they dont need 
to tune their DNS for reaching thing in OUR network.
(we are looking at something between 500 and upto 10 000 or more unique 
ULA-C/G blocks for or network and use)
- ...

sure we could use PI, but we dont need any of the features on the internet 
really... and for those features we need we have our RIR assigned netblock 
for that purpose.

sure we could just get a bigger PA block from our RIR but they dont buy 
_OUR_ arguments for why we need more IP, which is okay since it is our 
INTENRAL network that required the amount of IP we need. We dont have any 
issues to justify that we need a /32 after the current policies, or any of 
the other I've seen suggested.

And dont come telling us how we should structure our INTENRAL network, we 
have our reasons and our requirments, good or bad from others point of 
view, but they are the guidelines we are running our network and business 
after.I really doubt anyone like to be told that since it is strictly 
internal:)

Another reason for not using RIR assigned IP for our internel network 
usage are the justification we have to provide for getting a bigger block 
from RIPE. Or that it might be harder to explain why we need 500-10000++ 
PI blocks from RIPE than to just get ULA-C/G from whoever provide it. RIRs 
or IANA direct through a robot. For us it doesnt mather much really, we 
just need some UNIQUE IP addresses for our internal usage WITH global 
reverse DNS possibility...

I guess other enterprises see this the same way. They simply want INTERNAL 
unique IP addresses with global reverse DNS options, nothing less, nothing 
more.
They probably wont bother to become LIR just for internal IP, their ISP(s) 
provide them with their internet connectivity, and they can probably 
easy justify to get PI if they want that.

-- 

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

---

From: "Stephen Sprunk" <[email-masked]>
Date: Sat, 7 Jul 2007 21:16:23 -0500

Thus spake "Roger Jorgensen" <[email-masked]>
> (we are looking at something between 500 and upto 10 000 or
> more unique ULA-C/G blocks for or network and use)

That's going to get expensive, no matter how little the central authority 
charges.  Well, unless the central authority does bulk discounts, but I see 
no reason they would since there's no economy of scale in issuing thousands 
of prefixes that can't be aggregated, unlike aggregatable PI/PA space.

> I guess other enterprises see this the same way. They simply
> want INTERNAL unique IP addresses with global reverse DNS
> options, nothing less, nothing more.  They probably wont bother
> to become LIR just for internal IP, their ISP(s) provide them
> with their internet connectivity, and they can probably easy
> justify to get PI if they want that.

RIPE hasn't caught up to ARIN yet, apparently.  ARIN provides for direct PI 
assignments to end users with very minimal qualifications and no need to 
become an LIR (which get a /32 at minimum).  /48 is the minimum direct 
assignment size, and while you do have to "justify" a shorter prefix, all 
requests are approved.  Ebay, for instance, just got a /41.  And, while 
there's a nontrivial fee for the initial assignment, the annual maintenance 
(regardless of how large the block is) is only $100/yr.  I doubt your 
central authority is going to charge less than that for 10,000+ distinct 
blocks.

AfriNIC, I've read, has a similar policy except that the prefix must be 
advertised publicly within one year; ARIN has no requirement that the prefix 
_ever_ be advertised.

I do not see a requirement to pass ULA-C/G merely because some RIRs have 
failed to meet their respective communities' needs.  If you're unhappy with 
what RIPE offers, either show up and propose policy changes or 
(less-preferred) route around the failure and get space from ARIN.

S

---

From: Perry Lorier <[email-masked]>
Date: Sun, 08 Jul 2007 18:30:22 +1200

> When my link to one of those three ISPs goes down, I have a 1/3 chance 
> of each outbound connection failing because the return path is broken 
> (or my other two upstreams do uRPF).  I also have a 1/3 chance of each 
> inbound connection failing until I update DNS to remove the relevant 
> AAAA records; smarter clients will try multiple addresses for inbound 
> connections, but there'll be a delay and not all clients are that smart.
>

Generally applications that support IPv6 support step-down through 
addresses, otherwise dual stack hosts that don't have a v6 connection 
can't connect to services that are dual stack.  This is the kind of bug 
that IPv6 enabled applications get fixed extremely quickly.

---

From: Roger Jorgensen <[email-masked]>
Date: Sun, 8 Jul 2007 10:16:38 +0200 (CEST)

> of prefixes that can't be aggregated, unlike aggregatable PI/PA space.

Did you notice I didnt mention the price, cheap or not one time in my 
mail? We know it will cost so we dont consider that yet. Make ULA-C/G more 
expensive than PI and we likely will use PI, make PI more expensive and it 
is not an options. You see the price dont mather! It is the technical 
options and possibilities that are important.

and we do NOT care about aggregation much either since it is our own 
internal network we are talking about.

In short, none of the two, economy or aggregation, are important when 
talking about ULA-C/G. (none of them should be announced to DMZ anyway so 
why wasting time on that?:))

> (regardless of how large the block is) is only $100/yr.  I doubt your central 
> authority is going to charge less than that for 10,000+ distinct blocks.
>

you totaly missread what I wrote. A PI policy will most likely be in place 
in RIPE region to at some point soon, thats why I said we could choice 
from PI or ULA-C/G.

Did you also notice that I said we have already got our own PA assignment, 
a /32, for all our external needs?

Almost all ULA-C/G usecases can be solved by using either PA or PI type of 
addresses from the RIRs but why not give the enterprises an options to use 
something similar to RFC1918 addresses? Thats what we are talking about, 
another set of addresses for inter-network use, NOT DFZ/global Internet 
usage.
(sure there is a chance someone will start announcing them to the DFZ for 
some stupid reasons, then we can either hope the other ISP are smart 
enough to show the RFC we maybe will publish and reject it, or we can 
simply depreciate the addresses, or just live with it. But that chance is 
small anyway so why bother using time on that?)

--

---

From: Mark Andrews <[email-masked]>
Date: Mon, 09 Jul 2007 11:36:16 +1000

> The alternative is to renumber the entire network every time a link goes up 

	No. You don't have to renumber.  You just have to deprecate
	the addresses associated with the downed link.  This is the
	sort of thing routers should be able to do automatically.

	As for uRPF you will either have a problem with that all
	the time or none of the time.   If your ISP doesn't do BCP
	38 correctly (uRPF is not doing BPC 38 correctly) then
	choose ISPs that offer BCP 38 support (i.e. they allow you
	to send packets out with *any* of your PA addresses, not
	just the ones they assigned to you).

	The alternative is to introduce source address routing
	within your network.
 
> really the stateful inspection that burns you.

	NAT introduces costs above and beyond those of a stateful firewall.
	And as for stateful firewalls, applications should be able to
	talk to them to open up reply traffic if needed.
 
> seconds; the change control processes leading up to it can burn months of 

	Real renumbering events are rare.

	You are wanting NAT to provide multi-homing support.  This
	does not require you to renumber.  There is no need to use
	NAT for this with IPv6.  IPv6 provides the mechanisms to
	move the source address selection back to the end host
	(where it belongs).

---

From: [email-masked]
Date: Mon, 9 Jul 2007 00:52:06 -0400 (EDT)

I think we should avoid any "straw man" arguments, as those tend not to
actually help advance the subject matter.

Just because one way of accomplishing a particular networking objective,
involves particularly unpleasant choices, does not mean that the technology
involved is at fault. It is also possible that the design choice was a case
of not using the right tool for the right job.

>> If you drop or add an ISP you drop or add a prefix in a planned manner.

I beg to differ.

PI space is available, from most if not all RIRs.
The criteria for obtaining such is reasonable, and having multiple
ISPs, i.e. being multihomed, generally accomplishes this.

ISPs are expected to have PA space available to assign to their customers.
This does not mean that every customer can only ever use PA space from
their ISP. It only means that customers who do not have their own PI space,
will be able to get PA space from their ISP.

If you are multihomed, the community generally expects you to use PI space.
And that community includes your ISPs.

If we did not need to have PI space being announced from anyone other than
the core of the DFZ (those entities which are generally considered "tier 1"
for lack of a better description), then we would only have AS paths of
length 1, and we would be able to run EGP (the predecessor of BGP).

And clearly the collection of RFCs describing IPv6 numbering schemes are
robust enough, and the routing protocols inclusive enough, that PI space
can be announced via ISPs, in addition to their own PA aggregates.

> The alternative is to renumber the entire network every time a link goes

You should, in this case, have a PI block, not be using anyone's PA block,
let along 3 x PA blocks. If you are using PI, you are running BGP, and
single link failures are the kind of thing that are relatively minor events
for any multi-connected entity, such as your network. No renumbering is
needed.

> means moving either from NAT+RFC1918 to NAT+RFC4193 or from PIv4 to PIv6.

Our collective job is to ensure that scalable solutions are disseminated,
not only in the RFCs, but in the actual implementations that customers use.

This may mean some small amount of customer education. Everyone wins when
the end customers (no matter whose customers they are) make a choice which
is not only right for them, but good for the community as a whole.

If anyone is multihomed currently, and using NAT+RFC1918, then having the
option to go to PIv6 will likely make their life much easier. The fact
that they would never need to renumber, is just a bonus.
(They will have to renumber, in moving to IPv6 in any flavour, remember.)

>>>> lot

---

From: Paul Vixie <[email-masked]>
Date: Mon, 09 Jul 2007 05:01:20 +0000

> actually help advance the subject matter.

while i agree, i think this doesn't go far enough.  can people who post
here say whether they are in favour or opposed to the outstanding drafts
and if they're opposed (or even if not) can they offer suggestions for
improvement?

ultimately the "advancement" of the subject matter will be measured by
consensus-driven standards, and not merely by well worded arguments, with
winners and losers, in the mailing list archive.

---

From: [email-masked]
Date: Mon, 9 Jul 2007 01:25:16 -0400 (EDT)

> to tune their DNS for reaching thing in OUR network.

You are referring to "other organization(s)". Will these be entities to whom
you directly connect, or have VPN connections to? Or do you mean,
generally, the Internet at large?

Without NAT, ULA is *not* allowed into the DFZ. Period.
You don't want NAT.
You *must* then choose to use PA blocks assigned by ISPs, or your own PI
block(s).

You may not care about the global DFZ, but if you plan on connecting to
it, it certainly cares about you, and everyone else. Specifically, that
certain rules be observed, ruthlessly. Everything else goes, however. Once
you have your address space, it is yours to do with as you wish. There is
no limit to the way you carve it up - google "VLSM" (variable-length
subnet mask) to get some good ideas. But what goes into the DFZ is
something all members of the DFZ care very greatly about.

> the other I've seen suggested.

You should not be dealing with PA blocks if you have the need for global
reverse DNS that you control, and for the size and complexity of your
network(s). PI is where you should be looking, and nowhere else.

And, since we're discussing ULA, your needs suddenly become irrelevant.

Sorry. Thanks for providing your input.

> after.I really doubt anyone like to be told that since it is strictly

What can you tell us about the needs of each of the 500-10000++ blocks you
think you need? Specifically, size (in terms of 2^N hosts per block, with
groupings of sizes to the nearest multiple of 8)?

E.g. - need 8,000 blocks of 2^8 hosts, 1,500 blocks of 2^16 hosts, and 500
blocks of 2^32 hosts.

Even if you have 32,000 blocks of 2^48 hosts, that is still only 2^64 of
address space. This would easily be managed by the use of a single /64.

If you have *one* PI block, of /64 or larger (e.g. /48 or /32), I think it
should be pretty clear that you should be able to subdivide your space
in any way you see fit. All of those subdivisions would be internal only,
as far as networks carried on anyone's routers - no one outside of your
infrastructure would see anything other than your single PI block.

> reverse DNS possibility...

I believe, if you look carefully, most RIRs have policies that permit the
assignment of PI blocks in IPv6 to anyone who *would* qualify for PI block
in IPv4 space. And the requirement for PI in IPv4 is certainly something
you would qualify for...

> easy justify to get PI if they want that.

The general argument on ULA-C/ULA-G vs PI is this - PI is what should be
used if you want globally unique address space, and will want this to be
known (without NAT) on reverse query lookups, to anyone else who is
connected indirectly (via the DFZ).

The model for ULA-C/ULA-G is one of non-Internet connected networks, or
networks who may use Internet-based transparent transport services, such
as VPN or MPLS-VPN or whatever else. VPN-VPN connections, which have in
the past been referred to as "extra-nets", are what are envisioned.
Globally unique addresses used by all such VPNs, mean that interconnnecting
them, deliberately or accidentally, permanently or temporarily, just works.

And, just because you plan on running an internal network, does not mean
that none of that network will want to reach the outside world. If it does,
certainly plan on using firewalls, but don't plan on using NAT just because
you used NAT in IPv4. There's nothing wrong with mixing ULA address space
and PI or PA address space on your internal infrastructure - that too is
meant to just work, and might well suit your needs. But if you plan on
having everything on your internal network reach out to the internet, my
advice is to get a single PI block and use that from the very beginning.

Exactly *how* you use that is your business and yours alone.

But, the community at large *will* tell you - we do not intend on allowing
anyone to get, use, and announce, large quantities of PI *blocks*.
The scalability of the DFZ requires very conservative growth and use of
numbers of prefixes, regardless of their size. It is router slots, aka
prefixes, aka netblocks in the DFZ, that we care about. Nothing in that is
impacted by the size of the blocks in question.

If you need to have 1000000 blocks internally, that's fine - but those
will need to be aggregated by you into one single PI block when you talk
to the world, or however many blocks your minimal topological needs can
justify.
(Or aggregated by one or more ISPs in PA blocks, that's fine too.)

Brian

---

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

> 	sort of thing routers should be able to do automatically.

Indeed, and reachability detection is a necessary part of a
robust IPv6 implementation regardless of any of this, since
multiple addresses for the same host is a design feature
of IPv6.

     Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 09 Jul 2007 10:05:21 +0200

> ISPs, i.e. being multihomed, generally accomplishes this.

That's unfortunately true, but since it doesn't scale to the ten
million or so networks we expect to desire multihoming, it will
only work for a few years. That's why we need other solutions.

     Brian

---

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

On Mon, 9 Jul 2007, [email-masked] wrote:
<snip>
> generally, the Internet at large?

yes they have their own internet connection, and they are closed network 
much like ours, some have interent but have closed zones (DMZ) we 
communicate with. In neither cases does internet mather since it is two 
network that interconnect through a direct connection totaly outside 
internet.

> You *must* then choose to use PA blocks assigned by ISPs, or your own PI

no, for _all_ our internal communicate we are consider to use ULA 
addresses, may be using some addresses from our PA block or a PI block 
for some special services, depending.
No one are allowed to communicate direct out of our network so they will 
anyway have to go through some sort of "relay", mail-servers, webproxies 
etc... and them again will communicate with internet through DMZ setups 
with our PA-addresses.
(and yeah we know there are services that dont can be sent through 
relayes but thats okay, we have other solution for them)

> something all members of the DFZ care very greatly about.

you didnt either read the entire mail... we have a PA block we use for our 
external needs. ULA-C/G are for _internal_ usage, nothing else.

> Sorry. Thanks for providing your input.

eh we have PA for _our_ external needs, that one are okay.
We have PI for some special usage (there will quite certain be some needs 
for it someday).
And for the big internal usage we are consider to use ULA-C/G if it will 
provide us with global reverse control... that is any of our ULA-C/G 
addresses can be looked up through the global DNS.

what part is irrelevant?

<snip>
> them, deliberately or accidentally, permanently or temporarily, just works.

Excactly that is why we need GLOBAL unique ULA blocks for our usage. We 
dont know who we will private/direct interconnect with in the future but 
it will not be over internet.

> Exactly *how* you use that is your business and yours alone.

forget our external needs, they are taken care of by our PA block, or PI 
block if we want that for some special usage.
It is the internal networking that are the issue now. ULA-C/G looks like 
the best candidate if it goes through.

> (Or aggregated by one or more ISPs in PA blocks, that's fine too.)

externaly we have PA so forget that. Internal we have three options 
with lots of variation on howto implement it:
- use our PA block one way or another
- use PI blocks (several different onces)
- use ULA-C/G

--

---

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

>> That's going to get expensive, no matter how little the central
>> authority charges.  Well, unless the central authority does bulk
>> discounts, but I see no reason they would since there's no
>> economy of scale in issuing thousands of prefixes that can't
>> be aggregated, unlike aggregatable PI/PA space.
>
> Did you notice I didnt mention the price, cheap or not one time
> in my mail? We know it will cost so we dont consider that yet.
> Make ULA-C/G more expensive than PI and we likely will use
> PI, make PI more expensive and it is not an options. You see
> the price dont mather! It is the technical options and
> possibilities that are important.

I've seen three reasons for ULA-C/G proposed:

1.  People can't get PI space
    - This shouldn't apply to you.
2.  ULA-C/G will be cheaper than PI space.
    - This remains to be seen.
3.  ULA-C/G won't be publicly routed.
    - There's no requirement you route PI space.

> and we do NOT care about aggregation much either since it
> is our own internal network we are talking about.

You don't do any route summarization within your internal network?  Must be 
nice not to have to worry about that.

>> I do not see a requirement to pass ULA-C/G merely because
>> some RIRs have failed to meet their respective communities'
>> needs.  If you're unhappy with what RIPE offers, either show
>> up and propose policy changes or (less-preferred) route
>> around the failure and get space from ARIN.
>
> you totaly missread what I wrote. A PI policy will most likely be
> in place in RIPE region to at some point soon, thats why I said
> we could choice from PI or ULA-C/G.

So, then, the question is what does ULA-C/G buy you that PI does not?

> Did you also notice that I said we have already got our own PA
> assignment, a /32, for all our external needs?

Okay, so you already have more addresses than you could possibly need.  When 
you said PA, I assumed you had a typical /48 block(s) from your upstream(s) 
and that wasn't enough space and/or you wanted provider independence that 
you didn't have today.

> Almost all ULA-C/G usecases can be solved by using either PA
> or PI type of  addresses from the RIRs but why not give the
> enterprises an options to use something similar to RFC1918
> addresses?

We already have something similar to RFC 1918: RFC 4193.

ULA-C/G is _not_ similar to RFC 1918; it is PI by another name.

> Thats what we are talking about, another set of addresses for
> inter-network use, NOT DFZ/global Internet usage.

Addresses are addresses; you can use PI space for private use just as easily 
as, if not more easily than, you can use any other type of space.

S

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 09 Jul 2007 18:55:30 +0200

This is not correct. PI is not available from 2 RIRs, and there is not a
clear view of when it will become available. In one of them, because the
timing of the Policy Development Process, it will take at least 15 months to
get it implemented and this in the case it is approved in the next meeting
in almost one year from now.

In the other one, even PA is not available unless you have 200 customers
(this is the same in other RIRs that already have PI).

I'm not saying that this is related to ULA-C, I still believe it should be
kept separated, and ULA-C is NOT to be used as a replacement of PA/PI, and
indeed, I'm convinced it will not happen because if you try that you can
never be sure that your ULA-C is globally routed and consequently is 100%
reachable. Anyway, I though it is important to clarify what I have explained
above.

Regards,
Jordi

> De: Brian E Carpenter <[email-masked]>
> Responder a: <[email-masked]>
> Fecha: Mon, 09 Jul 2007 10:05:21 +0200
> Para: <[email-masked]>
> CC: Stephen Sprunk <[email-masked]>, <[email-masked]>
> Asunto: Re: I-D ACTION:draft-ietf-ipv6-ula-central-02.txt
> 

**********************************************
The IPv6 Portal: http://www.ipv6tf.org

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.

---

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

> in almost one year from now.

In other words you are trying to get "ULA PI" because the RIR policies
take too long? You do realize that the ULA policies will have to also go
through the same RIR communities and that they will be handled with the
same skepticism as that those "PI" proposals (which allow a single
end-user site to get a /32, which is really laughable) are being dealt with.

> (this is the same in other RIRs that already have PI).

The IETF is not the place to discuss RIR policies. If the people who
want to force through the new policies made up policies which actually
made any sense and where fair to everybody then they would have been
accepted already.

With the current views on ULA (lets see how the next update of the draft
will be) it is nothing more than just another variant of PI with a very
weak attempt to avoid RIR policies, nothing else.

If you really want to have "PI" in those RIR regions then come up with a
good policy proposal on the RIR list, don't try to push it through. That
is not how consensus works.

Greets,
 Jeroen

---

From: JORDI PALET MARTINEZ <[email-masked]>
Date: Mon, 09 Jul 2007 21:58:31 +0200

Jeroen,

As usually, you're trying confuse folks, manipulate words and read the text
with your own thinking, not what is actually in the email text.

I'm not going to spend too much time on this, just clarify for the benefit
of others. Current proposals for PI aren't /32, as you know very well, as
you discussed about those proposals in the RIPE NCC address policy WG.

And read twice my text, which was only with a clarification purpose about
something wrong in the thread:
"I'm not saying that this is related to ULA-C, I still believe it should be
kept separated, and ULA-C is NOT to be used as a replacement of PA/PI, ...".

So if you want to manipulate text, please, do with your own emails, not with
clarifications from others.

Regards,
Jordi

> De: Jeroen Massar <[email-masked]>
> Organización: Unfix
> Fecha: Mon, 09 Jul 2007 18:09:06 +0100
> Para: <[email-masked]>
> CC: <[email-masked]>

Bye 6Bone. Hi, IPv6 !
http://www.ipv6day.org

---

From: Jeroen Massar <[email-masked]>
Date: Mon, 09 Jul 2007 21:28:14 +0100

> with your own thinking, not what is actually in the email text.

Wow, what has this to do with the whole ULA-C debate? Can you actually
supply any technical arguments instead of personal insults?

Clearly your words are ambiguous otherwise I could not read something
else in them now could I?

Write a draft about this with clear text, instead of trying to insult me
and trying to discredit what I write.

There is no intention, at least from my side, of "trying to confuse
folks" and there is no need to "manipulate words", what you propose is
wrong, and that is where I comment on.

As you are clearly accusing me of various bad things here, can you at
least exactly point out where I "manipulate words"? As then we can clear
those issues up instead of just having you throw rocks at me without any
grounds whatsoever.

> of others.

Thank you for explaining other people what you think on this subject.
Can you also provide TECHNICAL arguments and actual facts?

> Current proposals for PI aren't /32, as you know very well, as

Funny that you apparently know what I "know well", sorry you really
don't know how my mind works and neither do others. Weird that you are
trying to accuse me of manipulation of words. Amazing.

What I very well know is that those proposals do contain the loophole
that allow any end user organization to simply request a /32 as there is
no claim for justification given in the proposed documents.

It is also why several people have stated no support for those
proposals. If there was a simple rule of justification then they would
have been passed a long time ago. The proposed text though is ambiguous
and open for interpretation in too many ways.

Also that discussion belongs on the RIR lists though, not here. Go there
to accuse me of "manipulating your words".

> kept separated, and ULA-C is NOT to be used as a replacement of PA/PI, ...".

That you believe that it should not be used for it doesn't mean that it
won't be used for it and that is what it is about here.

As can be seen very clearly from ris.ripe.net, see my other mail, even
RFC1918 is being leaked and routed. As that happens, it will for sure
happen for any form of "ULA" that is currently proposed as those are
globally unique and it would make sense that they are being routed as
that is what people need them for: Alternative PI because one can't get
it from the RIR's directly.

> clarifications from others.

Thank you for the insults. The next time you try to do that at least
come up with real arguments.

Please bring up TECHNICAL arguments and facts for the discussion that we
are trying to have here instead of trying to insult members of this list
by you not being able/wanting to understand what I am writing.

If wordings of what I am writing is unclear, then ask for clarification
instead.

Greets,
 Jeroen

---

From: bill fumerola <[email-masked]>
Date: Mon, 9 Jul 2007 15:38:38 -0700

> kept separated, and ULA-C is NOT to be used as a replacement of PA/PI, ...".

i was already drafting a mail pointing out that the only part of your
mail he didn't quote was the one that deflated his entire attack on you.
i don't always agree with your proposals and suggestions, but please
continue to stick up for yourself when this happens. i didn't have enough
time in the day to do so when it was done to me.

> clarifications from others.

seriously. his replies to my mails were so misquoted i barely recognized
them as my own, my examples were extended to such stupid extremes (see
also: strawman) that i couldn't believe a networking professional would
even consider drawing such conclusions from those examples, and in general
my mails were returned with such hostility that i wonder if Mr. Massar's
purpose here is trying to achieve consensus or simply trying to detract
anyone from participating who doesn't share his own opinion.

i must admit, going on the RIR mailing lists and screaming "this is an
IETF problem, leave it alone" and then going to IETF mailing lists
screaming "this is a RIR problem, leave it alone" makes for a very
compelling and potentially successful technique.

kudos, Mr. Massar. kudos.

-- bill (in favor of the direction the vixie-global draft provides or
	 working towards a central-03 draft incorporating ideas from
	 the vixie draft)

---

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

>     - There's no requirement you route PI space.

Nobody is required to route anything. It's recommendations from trusted
sources that count. 

Following the RIRs acceptance and implementation of PI policies most
such recommendations have been adjusted to allow /48s in PI-ranges in
addition to the existing /32s for PAs.

//per

---

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

On Mon, 9 Jul 2007, Jeroen Massar wrote:
<snip>
> weak attempt to avoid RIR policies, nothing else.

it is the PURPOSE part we seems to disagree on. ULA-C/G are NOT ment for 
DMZ while UA (PI/PA) are ment to be routed there.

--

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 10 Jul 2007 13:56:30 -0500

Thus spake "Mark Andrews" <[email-masked]>
> sort of thing routers should be able to do automatically.

Are the routers going to summon all the affected folks to a change control 
meeting, verify the approvals, do the necessary post-change testing, etc? 
Are they going to update all the firewall configs, DNS, etc?

Even the above automatic address deprecation part isn't available yet, 
despite a decade of folks claiming that renumbering is easy, and that's not 
even the hard part.

> NAT introduces costs above and beyond those of a stateful firewall.

That's like saying having a broken leg is an additional cost above and 
beyond the cost of death.  Not breaking your leg doesn't make you any less 
dead.

> talk to them to open up reply traffic if needed.

Yeah, try to sell that to any enterprise security department.  It's the 
applications and users that security folks are trying to protect their 
networks from in the first place, and internal users are a much, much bigger 
threat to security than external folks are.

>> part of what must be done.  Changing the address on an interface takes
>> a few seconds; the change control processes leading up to it can burn
>> months of manpower.
>

That all depends what you call "real".  Any event that breaks connectivity 
(including established connections) for more than a few seconds is "real" to 
me.

> You are wanting NAT to provide multi-homing support.  This does not
> require you to renumber.  There is no need to use NAT for this with IPv6.
> IPv6 provides the mechanisms to move the source address selection
> back to the end host (where it belongs).

For the record, I hate NAT, for all the reasons that most of IETFers do. 
What I'm saying is that NAT is considered by the market to be less evil than 
the alternatives the IETF has proposed to date.  Until folks recognize that, 
no progress will be made.

I'd much prefer to see widespread use of PI space, and significant effort 
put into an id/loc split scheme so that the DFZ doesn't implode as a result. 
OTOH, router vendors are claiming the ability to support two million routes 
today and ten million in a few years, so we have time to work on that.

S

---

From: Mark Andrews <[email-masked]>
Date: Wed, 11 Jul 2007 10:48:10 +1000

> Are they going to update all the firewall configs, DNS, etc?

	There are no firewall changes to make.  There are no DNS
	changes to make.  Just because a prefix is deprecated it
	doesn't suddenly become invalid.  When the link is restored
	the prefix will be reinstated.

	Do multi-homing NAT boxes in the IPv4 world cause a change
	control meeting?

	All this is doing is moving the source address selection
	from boxes in the middle of the network to the edge nodes.
 
> despite a decade of folks claiming that renumbering is easy, and that's not 

	We are not talking about renumbering.  We are talking about
	address selection.  All the boxes will continue to have all
	the addresses before, during and after the link down event.

> beyond the cost of death.  Not breaking your leg doesn't make you any less 

	So you don't think have packets change addresses and ports
	as they cross the NAT is not a additional cost especially
	for humans trying to diagnose problem?

	It definitely much easier to see traffic flows on two sided
	of a box if you don't have to also match different address
	and ports.
 
> threat to security than external folks are.

	That is why the firewall should be on the node and not in the
	middle of the network.  Every box protects itself from every
	other box including internal boxes.
 
> (including established connections) for more than a few seconds is "real" to 

	I said renumbering events not link outages.  If you don't have
	a routing slot for the prefix you are using, which describes PA
	addresses, then nothing a end site can do will prevent established
	connections from failing if the link to where the covering prefix
	traffic is sent fails.
 
> today and ten million in a few years, so we have time to work on that.

	Well until that comes along, providing a multi-homing solution
	that will work with existing without resorting to NAT is something
	we should be striving for.

	If there are pieces missing we should be indentifying them and
	getting vendors to implement them.  As for using multiple PA
	about the only thing I see missing is detection of the trigger
	events (link down).
 
	IPv6 has a different management paradigm to IPv4.  Education
	is important.