Subject: (ipv6) globally unique private addresses

From: "Michel Py" <[email-masked]>
Date: Mon, 4 Nov 2002 13:49:22 -0800

Thomas,

> Thomas Narten wrote:
> What about globally unique?

This has three sides:
1. Will it appeal to the network administrators.
2. How easy can we make it for the user.
3. How many hurdles do we have to clear in order to get this going.

Please allow me to develop this a little.

1. Will it appeal to the network administrators.
------------------------------------------------
> Well, there are no guarantees, but if there was a chunk
> of address space reserved for "globally unique, but no
> expectation that it will ever be routed on the public
> internet", and it came out of a well known prefix, I'd
> expect that enough ISPs would filter on them to keep
> them from being usefully routable in a global sense.

One of the arguments that has been used and possibly abused about this
is that if it was true, we would never see 10.0.0.0/8 or 192.168.1.0/24
in the DFZ, and we do; which leads us to:

> I don't follow what you mean by "ambiguous".

It means everyone uses the same address, and this has a very thought
property: it makes your chances of these addresses being routed properly
routed over the Internet close to zero. Let's say, at a given time, 10
different sites leak 192.168.1.0 to the DFZ, including you. What are the
chances of a hacker in a random location getting to "your" 192.168.1.0?
Practically not much. Besides, hackers are not going to look for this.

OTOH, if the private address is globally unique (not ambiguous) and it
leaks to the DFZ, it immediately identifies that you screwed up your
routing or have been hacked.

To take the argument further, what I mentioned above is only the result
of mis-configuration or hacking, and it is not the only concern, see
below.

> Well, there are no guarantees, but if there was a chunk
> of address space reserved for "globally unique, but no
> expectation that it will ever be routed on the public
> internet", and it came out of a well known prefix, I'd
> expect that enough ISPs would filter on them to keep
> them from being usefully routable in a global sense.

This can be doubted, especially in the lack of a multihoming solution.
There have been ideas around about mechanisms such as embedding the ASN
in the high bits of a site-local address to make it globally unique.
This can of mechanism could be applied as well to this private block we
are talking about.
My recollection about this is that lots of people made the point that it
would not take many end-sites that are lobbying for PI to pay their ISPs
to leak these addresses in the defaultless table to get to a fait
accompli that would have re-invented PI. Skipping the discussion about
PI being bad, this would still leave us with addresses that had been
intended originally to be not publicly routable but have become so,
which does not fit the bill.

2. How easy can we make it for the user.
----------------------------------------

> Not immediately clear one can get uniqueness without some
> sort of registration. But the registration might be fairly
> painless.

One has to be pragmatic and easy registration and/or low fee would not
be show stoppers. At this point I do not have major concerns about this.

3. How many hurdles do we have to clear in order to get this going.
-------------------------------------------------------------------
- As I mentioned before, there is a fine line between globally unique
private addresses and PI, and this fine line is ISPs filtering them. Not
accounting for misconfigurations, only a few end-sites paying ISPs to
actively leak these as a replacement for PI might become uncontrollable
and be percept as an unacceptable risk.
- No matter what addressing scheme is being used, there is no way this
would fit in a prefix longer than a /16, if this long. The consensual
level required to get such a block allocated is high.

This where I stand:

With my network administrator hat on:
- I do not buy the idea that a block of globally unique addresses would
not be also globally routable. At least, not until I see the multihoming
situation unwrap.
- Even if I did, I would still prefer ambiguous addresses.
- And why should I bother anyway because site-locals give me what I need
today.

With my IETF participant hat on:
This sounds like good idea. That being said, it is going to be a long
though battle no matter what, and given the fact that it is not as good
as what site-locals provides to the network administrator, it is
questionable if it would be worth the effort as adoption is largely
unknown.

Also, globally unique private addresses and ambiguous ones are not
mutually incompatible, why not both?

Michel.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Michel Py" <[email-masked]>
Date: Mon, 4 Nov 2002 20:02:31 -0800

Dan,

> Dan Lanciani wrote:
> Let's say I have an Ethernet segment with 20 workstations
> and 5 printers. I determine that two of the workstations
> need access to the Internet so I rent 2 global addresses
> from my ISP.  Are you saying that at this point for all
> the workstations to continue using the printers I have to
> either:
> 1. Rent an additional 23 global addresses from my ISP
> making the entire subnet global -or-
> 2. Interpose a router between the 2 globally connected
> workstations and the remaining 18 workstations plus 5
> printers, forcing the 2 globally connected workstations
> to use their global addresses to talk to site-locals on
> the printers (thus making such connections depend on the
> ISP).  In order to change which workstations have global
> access I would have to move them between subnets.

Either one. I don't see what your problem is with 1, because the
smallest you can get is a /64 anyway, which is enough for more printers
and workstations than you will ever have.

The problem you have with 2 is that you want PI, like everyone else,
which is quite another animal.

> Or are you saying that site-local and global addresses
> should not appear in packets on the same subnet at all
> (rather than as addresses of a single machine on a
> subnet) in which case only #1 would work?

I don't see the difference? Subnet is a poor choice of words, let's say
vlan, or Ethernet segment instead, sorry about the confusion.

> I believe Margaret is implying a restriction here that
> connections cannot be made between a site-local address
> and a global address. That would invalidate solution #2 above.

There is no such restriction.

I'm afraid the design that allows both a public and a site-local on the
same host (or at least on the same interface) is going to be scrapped
and here are the reasons:
1. The developers are whining about it.
2. From an enterprise perspective, it's a draw. Yes it does save router
ports but the other side of this coin is that administering several
address ranges on the same vlan is an administrative overhead and
nullifies most of the perks of site-locals in terms of security.

So, it's a tosser on the network admin side; if it was without
consequences I would have elected to keep it, but if the developers want
to scrap it, so be it as far as I'm concerned.

>> I believe this would be fine with many, as I can't recall
>> anybody that supported site-locals doing it for the
>> site-locals themselves but for what they provide, see below.

> It's more a matter of supporting scoping and address selection
> rules for what they provide.  It doesn't matter what you call
> the local addresses.

OTOH, I'd rather have a block of private addresses without scoping than
SLs with scoping that does not work. If the developers don't want or
can't deliver scoping with SL, I need a backup plan and since there
appears to be some momentum for it I'll take it. Of course, this would
lead to networks that are using non-scoped private addresses, but the
one thing network administrators do not like is uncertainty.

That being said, my choice is still to keep SLs and scoping, but let me
make sure that everyone understands that I do not design a network with
promises, I design a network with what I have tested to be working. As
of today the only thing I have to design a network that requires private
addresses is a prefix hijack that obviously is not scoped, since there
is some uncertainty in what would be available as far as SLs are
concerned. In this light, a private /32 clearly labeled as not publicly
routable would be an enhancement.

Michel.

---

From: "Michel Py" <[email-masked]>
Date: Tue, 5 Nov 2002 08:15:29 -0800

Dan,

> Dan Lanciani wrote:
> So your position is that I must do one of those two rather
> than using site-local addresses on the one segment along
> with the two globals? I believe that this restriction
> renders site-locals useless for many applications.
> I would be forced to opt for NAT.

You don't have NAT and you are not going to write yourself. Forget it.

>> I don't see what your problem is with 1, because the
>> smallest you can get is a /64 anyway, which is enough
>> for more printers and workstations than you will ever have. 

> There seems to be a persistent notion that ISPs are going to
> change their business models just because the IP header
> version field increases by 2. I don't buy it. Show me proof.

The IID is 64 bits, please read the addressing architecture draft. Same
as a v4 ISP could not give you less than ONE IPv4 address, a v6 ISP can
not give you less than ONE /64.

> If you ban packets with global addresses from your
> site-local subnet then the site-local machines
> (obviously) can't talk to globally-connected machines
> via their global addresses.  In my example, this makes
> #2 impossible.

Sorry, I misread you. There is no such restriction.

> There's no restriction on having site-locals and globals
> on one subnet either, but we seem to be talking about
> adopting one or more of these restrictions.

That is called political compromise. However, I am glad you contributed
your feelings, and I would stick to what I wrote in my original answer
about this: If it's only me, ok to scrap it. If some other people do
insist on having this feature, keep it.

> I cannot support your position.  This restricted version of
> site-locals may have some marginal security benefit, but it
> fails to deliver on the original promise of flexible scoping.
> It will just cause confusion for administrators who will
> think they can control their address allocations... until
> they actually try to do it.

Okay, I tried, no cigar. I actually think exactly as you do, so let's
stick to site-locals as we both want them. No restriction other than
what Bob Hinden mentioned yesterday.

Michel.

---

From: Dan Lanciani <[email-masked]>
Date: Tue, 5 Nov 2002 14:30:40 -0500 (EST)

"Michel Py" <[email-masked]> wrote:

|You don't have NAT and you are not going to write yourself. Forget it.

I write tcp/ip stacks and associated drivers for a living.  Some of my OEM
customers use these components to build NAT products.  I assure you that if
I want v6 NAT I will have it.  Even if I don't want it I will probably have it.
The way things are going, it looks like everyone will have it.  If they have
v6 at all.

|> There seems to be a persistent notion that ISPs are going to
|> change their business models just because the IP header
|> version field increases by 2. I don't buy it. Show me proof.
|
|The IID is 64 bits, please read the addressing architecture draft. Same
|as a v4 ISP could not give you less than ONE IPv4 address, a v6 ISP can
|not give you less than ONE /64.

I'm sorry, but you are wrong.  Many ISPs run their networks as big bridged
segments.  They can and they will use a single /64 for such segments,
allocating customer addresses out of that chunk on a pay-per-address basis.
It could even be argued (and I'm sure they will argue) that this is the most
natural arrangement: what was a single v4 subnet will become a single v6 subnet.
Dialup providers will almost certainly use a /128 because that is the closest
to what they are doing now.  It doesn't matter what a draft (or any other
document) says.  Such papers are not binding on ISPs.  Remember, many ISPs use
addresses as a substitute for bandwidth.  That's why some of them are so hot to
detect and eliminate v4 NAT.

				Dan Lanciani
				ddl@danlan.*com

---

From: "Michel Py" <[email-masked]>
Date: Tue, 5 Nov 2002 16:41:45 -0800

> Margaret Wasserman wrote:
> As far as I can tell, Michel's view on this does
> not represent the majority view of people who
> favour the use of site-local addresses for
> private addressing.

I gave up on that one. I thought it would be consensual, obviously it is
not.

> Due to the way that we expect IPv6 address to be
> allocated (a /64 per subnet) and assigned (using
> address autoconfiguration), though, there will be
> a tendency for all of the nodes on a single network
> to use the same set of prefixes. If a global
> prefix is advertised on the subnet, all nodes on
> that subnet would configure global addresses.
> Obviously, this could be overridden using manual
> configuration or by using DHCPv6 for address
> assignment.

Which is the very reason I mentioned earlier that from the enterprise
perspective it was a draw. 25 workstations, you don't have an issue if 3
need public addresses, but if you have a subnet with 200 hosts, and 100
of them need public addresses, the administrative cost associated with
100 static IPs or 100 DHCP reservations is not negligible. Compare this
with creating another VLAN in the layer 3 switch.

Michel.