RE: site local addresses (was Re: Fw: Welcome to the InterNAT...)

["Michel Py" <[e-mail]>]

Ted,

>>> Ted Hardie wrote:
>>> I think we then to consider whether the current need
>>> is for: "non-routed globally unique space" or for
>>> something else.  If the answer is "non-routed globally
>>> unique space", then the follow-on question is "Why not
>>> get globally unique space and simply decide not to
>>> route it?".

>> Michel Py wrote:
>> Because such thing does not exist, it's called PI and
>> is not available to IPv6 end-sites. And if it ever is,
>> it will cost money or other annoyances to obtain.

> Ted Hardie wrote:
> I don't think something needs to be provider independent
> to fit this bill.  Getting a slice of the global address
> space from some provider and choosing not route a portion
> of it (even if that portion is 100%) seems to me to
> create "non-routed globally unique space".

Does not work if you change providers and your former provider allocates
this address space to someone else; the space then ceases to be globally
unique. See below for a detailed technical case scenario. The collision
risk is way too high.

Here's the topology. Replace "SL addr" with "non-routed globally unique
space" if you wish; talking about which you could also have a look at
this:
http://arneill-py.sacramento.ca.us/ipv6mh/draft-py-ipv6-gusl-00.txt
(disclaimer: unpublished unfinished text, but it's not like I never
thought about it before).

I used this topo before as an example of a utility company that has
IP-enabled control devices. This is a fairly common topology.


<-------------------- Global Addresses ----------------><-- SL addr -->
+-----+
| ISP |    :
+--+--+    :
   !       :
+--+---------+  +----------+     +----------+     +----------+
| Router A : +--|< Firewall+--+--|< Firewall+--+--+ Router B +---+
+------------+  +----------+  |  +----------+  |  +----------+   |
           :                  |                |                 |
           :              +---+--+          +--+---+        +----+----+
           :              | DFZ  |          | Host |        | Control |
           :              | Host |          +------+        | Device  |
           :              +------+                          +---------+
---Site -->:<-------------------------- Site ------------------------->
           :

- Router A is the SBR.
- DFZ hosts need to be able to talk to hosts between the internal
firewall and router B, but not to the control devices.
- DFZ hosts need to be able to talk to the outside.
- Hosts between the internal firewall and router B need to be able to
talk to everybody.
- Control devices are accessible only from hosts between the internal
firewall and router B.

The name of the game here is not renumbering the control devices if the
ISP changes. There can be scores of them; this is not even open to
discussion. Even NATv6 will be chosen over renumbering if need be and
this includes developing the NATv6 code in-house if required.

Argument heard a thousand times: You don't care about the prefix you use
for these because it's not routable.

Rebuttal given a thousand times: Wrong. You do route this prefix inside
the site. If the prefix is being used both inside and outside you're SOL
as hosts between the internal firewall and router B won't be able to
talk to both.

What is the risk? A LIR gets a /32, a site gets a /48. That's 64k sites
per LIR at most. On a large LIR, the collision risk might be 1/3 or 1/4,
not the kind of chance I take.

OTOH, if I use a random /48 out of a private /24 block, the collision
risk to the outside is zero and the collision risk if I have to merge
with another site is 1 out of 16 Million (2^24) and this is the kind of
odds I'm willing to take. I would prefer site-locals as it's a /10 that
can make the collision risk for site mergers zero, but I'd deal with a
/24.

PA re-used addresses just don't cut it.


> Are you concerned that doing so has some impact on the
> routing system that needs to be considered?

No. I am concerned about impacts on the routing system but this is an
unrelated issue.


> Money and other annoyances are certainly concerns we
> all face.  In that spirit please understand that
> keeping site local costs different money and creates
> different annoyances.

This is irrelevant. Let's look at the situation:
- You want to deprecate site-locals.
- What does it cost me? Nothing. If SLs go away I can hijack any prefix
of my own choosing to replace them, these days I have my eyes on a hole
in the 6to4 space: 2002:0A00::/24.
- What can you do about me hijacking a prefix? Nothing.
- What do I gain: Actually, hijacking is more flexible than the
"exclusive" model that Bob and Margaret have compromised on (I support
it for the sake of compromise not because I like it). Someone said that
a compromise is something that pleases no one, and to this regard the
"exclusive" model is a very good one.
- What problems have we (as engineers) solved by having me hijack a
prefix instead of using site-locals? None. We have put an embarrassing
issue under the carpet for now.
- What is the impact for app developers that support the deprecation?
Now it's easier but tomorrow it's even worse than with site-locals
because I can do anything I want with my hijacked prefix opposed to
playing it by the rules with site-locals. And apps can't make educated
decisions because they don't know which prefix I have hijacked.
- Who's going to fix it tomorrow? App developers, not me. Pay me now or
pay me later with interest is what this deal is about.


Michel.