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

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 3 Jul 2007 16:11:12 -0500

Thus spake "Brian E Carpenter" <[email-masked]>
> On 2007-06-27 16:31, Kevin Kargel wrote:
> ...
>> The problem I see with having small ULA-C allocations is that as people
>> move around geographically those allocations will lose aggrebility.
>
> I don't understand your comment. No ULA prefix aggregates ever - they
> will always be specific routes,

... assuming everyone follows the rules in RFC 4193.  However, what if a /48 
isn't enough for some network and they decide to use a /45?  Is that better 
or worse than eight properly-derived /48s?

> and ULA-C is no different in that respect.

With the current draft, that is correct.  With Paul's proposed changes of 27 
Jun, they definitely aggregate at the LIR and RIR levels, making it much 
harder to defend the position that they won't end up in the DFZ.

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 

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

---

From: Scott Leibrand <[email-masked]>
Date: Tue, 03 Jul 2007 15:36:49 -0700

Stephen Sprunk wrote:
>
> With the current draft, that is correct.  With Paul's proposed changes 
> of 27 Jun, they definitely aggregate at the LIR and RIR levels, making 
> it much harder to defend the position that they won't end up in the DFZ.

I'm not quite following your logic here.  If ARIN allocates ULA-G space 
from a distinct netblock, how does that make it any harder for transit 
providers to filter routes from fc00::/7, reduce their incentive to do 
so, or create an incentive not to?

Thanks,
Scott

---

From: "Stephen Sprunk" <[email-masked]>
Date: Tue, 3 Jul 2007 19:23:29 -0500

Thus spake "Scott Leibrand" <[email-masked]>
> Stephen Sprunk wrote:
>> With the current draft, that is correct.  With Paul's proposed changes of 
>> 27 Jun, they definitely aggregate at the LIR and RIR levels, making it 
>> much harder to defend the position that they won't end up in the DFZ.
>
> providers to filter routes from fc00::/7, reduce their incentive to do so, 
> or create an incentive not to?

If they can be aggregated, there's no reason _not_ to route them in the DFZ. 
With no technical incentive to filter, the financial incentive to _not_ 
filter will win.

ULA-L and ULA-C have a pseudorandom network part specifically to avoid any 
possibility of aggregation, in hopes that'll be sufficient technical 
incentive for them to be filtered.  When you start divvying up those bits 
and giving them meaning, particularly a hierarchical meaning based on the 
RIR and LIR that assigned them, you're no longer working with "local" 
anything.

It's bad enough that ULA-C is reinventing PI space; we don't need ULA-G 
reinventing PA space.

S

---

From: Paul Vixie <[email-masked]>
Date: Wed, 04 Jul 2007 02:23:52 +0000

> > much harder to defend the position that they won't end up in the DFZ.

the aggregation present in that version was unintentional.  if you look at
the actual <http://sa.vix.com/~vixie/ula-global.txt> you'll see that it
recommends that allocations be deliberately nonaggregatable.

> or create an incentive not to?

my concern about aggregation is that if someone receives 8 /48's that are
aligned as a /45 then they could conceivably advertise it as a /45.  i hope
that IANA will allocate nonaligned blocks, or perhaps give even numbers to
one RIR and odd numbers to the next, and that the RIRs and LIRs will do
likewise.

---

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

> one RIR and odd numbers to the next, and that the RIRs and LIRs will do

On the hypothesis that we do something like ULA-G, I agree with that.

There is a statistical sense in which ULA-G would be more *potentially*
aggregatable than ULA or ULA-C. If ULA-G prefixes are allocated
on an RIR/LIR basis, the chance that two logically adjacent prefixes
happen to be used by customers of the same local ISP will be finite,
whereas it's vanishingly small for ULA or ULA-C.

     Brian

---

From: [email-masked]
Date: Wed, 4 Jul 2007 11:18:23 -0400 (EDT)

>> of

Aggregation - bane or boon? Depends on whether it's in the DFZ or not.

However, here are some observations, which might at some point be
paraphrased by someone, along with elements of other postings by me
and lots of other smart folks, into a document to serve as an IPv6
"primer" for both new participants in the v6 world, and old-timers...

The notion of "default" is a bit of a problem, when you have both the
DFZ "universe" and the ULA-* multiverse (which is what ULA's are).

Each group of connected ULA "sites", is its own little internet.
Or intranet, or extranet, depending on what floats your boat.
There can, and will, be zillions of these, including overlapping
domains which individual ULA sites are members of.

Fundamentally, the DFZ doesn't care what happens outside of the DFZ.
And as long as the tech works everywhere, to achieve the desired goals,
that should be enough.

The thing we need to be concerned about is not only route leakage, but
packet leakage, especially if it has the ability to affect the core
infrastructure, e.g. DNS.

Here's what is interesting about both the ULA space(s) as proposed, and
the DFZ space. Each is allocated out of a block which is easily
identifiable, and not only that, but which can serve as a covering
aggregate (or a few covering aggregates, if need be).

And in each routing domain (DFZ or ULA multiverse), the concept of default
is generally restricted to members of that domain.

So, Best Common Practice should be to never install a true default route,
except when also installing covering aggregates for both spaces, the other
of which points to the bit bucket.

E.g. in the DFZ, have ULA covering aggregate pointing to null0.
E.g. in any ULA site or collection of sites, have DFZ covering aggregate
pointing to null0.
E.g. in both spaces, only install ::/0 if the corresponding example above
is also installed.

Also interesting is the fact that in ULA routing domains (of which there
can be zillions), scalability can be achieved on the routing side, when
the topology happens to lend itself accordingly, by having any "core" site
carry lots of ULA routes, and "edge" sites carry a ULA aggregate
pseudo-default which points towards the core site.

All of this, again, points towards my earlier observation. ULA-* should be
recommended only for use when there is no desire or need to directly
participate in the DFZ.

Brian Dickson

---

From: Scott Leibrand <[email-masked]>
Date: Wed, 04 Jul 2007 12:47:34 -0700

[email-masked] wrote:
>>>> With the current draft, that is correct.  With Paul's proposed changes of 27 Jun, they definitely aggregate at the LIR and RIR levels, making it much harder to defend the position that they won't end up in the DFZ.
>>>>         

Apparently I'm not using the same set of assumptions as most of the 
other folks here.  We all seem to agree that ULA prefixes should stay 
out of the DFZ, but I'm not quite sure why aggregatability of ULA space 
is a bad thing.  At least in my decision process, it doesn't much matter 
if the ULA routes I'm receiving are /48's or /45's: my decision to 
filter (if I'm doing Internet transit) or accept them (if I'm operating 
a metro network) will be the same.

> And as long as the tech works everywhere, to achieve the desired goals,

Agreed.

> E.g. in both spaces, only install ::/0 if the corresponding example above

Or, if a site is a member both of a ULA multiverse than the DFZ 
universe, it could contain both a 2000::/3 Internet default pointing to 
a transit provider, and a fc00::/7 ULA default pointing to your ULA 
"core", as you described below.

> pseudo-default which points towards the core site.

Agreed.

> recommended only for use when there is no desire or need to directly

I would say it a little differently, that ULA addresses should be 
recommended for use only for connections to other ULA-addressed networks 
outside the DFZ.  A site using ULA addresses in this way could also use 
Internet addresses (PA or PI) in parallel, allowing hosts to select 
2000::/3 addresses when communicating across the DFZ, and fc00::/7 
addresses when communicating with other ULA networks.

-Scott

---

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

[vixie]
> > aligned as a /45 then they could conceivably advertise it as a /45.  i
> > hope that IANA will allocate nonaligned blocks, or perhaps give even
> > numbers to one RIR and odd numbers to the next, and that the RIRs and LIRs
> > will do likewise.

[carpenter]
> aggregatable than ULA or ULA-C. If ULA-G prefixes are allocated on an
> RIR/LIR basis, the chance that two logically adjacent prefixes happen to be
> used by customers of the same local ISP will be finite, whereas it's
> vanishingly small for ULA or ULA-C.

so perhaps we need to retain the randomness idea with instructions that IANA
and every RIR and LIR use it to ensure nonaggregatability?

---

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

scott liebrand has already followed up on most of what i thought interesting

> infrastructure, e.g. DNS.

in RFC 1918 land, it's impossible for a root name server to know where the
junk-source queries are coming from, since 192.168.1.100 looks the same no
matter who leaks it.  in any ULA plan, "recourse" has to exist, such that
when someone sends you a DNS query you can't reply to because it's from a
ULA-verse that you're not part of, you can still look it up in WHOIS.  i've
got a metric buttload of leaked corporate identifiers on hand that i have
no way to embarrass anybody with because by definition i cannot know the
identity of the leaker.  let's ensure that ad-hoc networking doesn't mean
"recourse-free networking".  (therefore ULA-G's WHOIS requirements.)

---

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

Thus spake "Paul Vixie" <[email-masked]>
> ULA-verse that you're not part of, you can still look it up in WHOIS.

Wouldn't such packets be considered bogons and get blocked (either via 
specific filters for fc00::/7 or uRPF) at the edge of your network before 
the server even saw them?

Besides, ULA (RFC 4193) blocks _can't_ be registered because there is no 
central authority and no guaranteed uniqueness.  ULA-C/G are different 
beasts, and if passed should have WHOIS and RDNS servers.

S

---

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

> the server even saw them?

right up to the point where they fill one of my peering circuits, yes.
after that, i have to track them back to the source and stop them there.

> beasts, and if passed should have WHOIS and RDNS servers.

fortunately then, ULA hasn't caught on.  ULA-C or ULA-G could catch on.

---

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

> fortunately then, ULA hasn't caught on.  

Actually, we have no way of knowing that, which is
a feature, not a bug.

    Brian

---

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

> and every RIR and LIR use it to ensure nonaggregatability?

When I think about it, this isn't such a big deal. If it's convenient
for an ISP to aggregate a few ULA-G prefixes on a local basis, for routing
within the ISP's domain, so what? The ULA prefix should still be filtered
at transit points.

I'm still not convinced about ULA-C/G but if this was an IESG ballot,
I'd be an 'abstain' at this point.

     Brian