Subject: RE: another view of fc00::/7

From: "Michel Py" <[email-masked]>
Date: Sat, 7 Jun 2003 10:01:40 -0700

Zefram,

>> Robert Elz wrote:
>> What we're lacking is any way to make a globally-scoped
>> non-routable address. That is, what gives us global
>> scoping in 2000::/3 (and most other unallocated spaces,
>> one presumes) is the routability - the two go hand in
>> hand.

> Zefram wrote:
> Here we're talking about two different things due to the
> two meanings of "scope". You're using the definition where
> scope = domain of routability. I should perhaps have
> clarified, I was using the meaning scope = domain of
> meaningfulness.  Let's not rehash the debate about whether
> these are really distinct in {theory,practice}.

You just can't have two definitions and use one or the other depending
on convenience. Although it is true that in theory scope of
meaningfulness is not the same as scope of routability, unless you have
a proposal to make this happen they're the same for all practical
purposes. So I fully agree with kre when he says that what we're lacking
is any way to make a globally-scoped non-routable address.

I have said in the past that the only way we can "guarantee" that unique
addresses won't be transformed into PI is scope. In theory this is not
true as one might invent a scopeless mechanism to achieve this, but
without seing any signs or ideas about one it remains true for all
practical means.

Any attempt to remove ambiguity in private addresses that have a global
scope will be perverted into wild unaggregated PI which is not
acceptable.

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: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Jun 2003 13:57:35 +0200

Michel Py wrote:
...
> scope will be perverted into wild unaggregated PI which is not

I don't think so, as far as the DFZ goes. What *will* happen, whatever
we do, is exactly what happens today - zillions of VPNs and private
static routes for inter-enterprise connections, that are quite
independent of the public routing tables summarized in the DFZ.

By removing ambiguity, we get rid of a lot of complexity in these
private arrangements, and get rid of many situations where NAT is
the only possible solution.

   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 08 Jun 2003 13:57:35 +0200

Michel Py wrote:
...

   Brian

---

From: Robert Elz <[email-masked]>
Date: Mon, 09 Jun 2003 01:13:07 +0700

Date:        Sun, 08 Jun 2003 13:57:35 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | I don't think so, as far as the DFZ goes. What *will* happen, whatever
  | we do, is exactly what happens today - zillions of VPNs and private
  | static routes for inter-enterprise connections, that are quite
  | independent of the public routing tables summarized in the DFZ.

Yes, for those who want to use non-routable addresses for this purpose,
having a means by which conflicts can be avoided would be a nice advantage.

However, someone needs to explain to me why an IPv6 VPN would want to
use non-routable addresses particularly?   Why not just use the global
addresses that the sites already have.

In the IPv4 world, there's a simple answer - the sites are using 1918
addresses (frequently) internally, and linking, at least parts of, their
internal nets is the aim.  So, their 1918 addresses are what they want to
exchange - which works iff there are no allocation conflicts (which happens
only by chance).

But in IPv6, everyone is going to have global addresses, why can't they
just be used for VPNs?

If the answer is "because we use 1918 addresses in IPv4" then I think
we have some education to do.

If the answer is "we want address stability in our group, even if some of
the members have to change their routable prefixes", then that's fine, but
for this, wouldn't the right answer be to simply create a new prefix for
the VPN, and use that one?   That is in this new address space that's being
created, the organisations that are creating a VPN pick one prefix that
is not in use by any of them (with 2^38 or more prefixes, minimum, to
choose from, that can't be hard) and assign that to all nodes that are
participating in the VPN (allocating subnets from it to the organisations).

If things are done that way, then it is no longer even relevant that
more than one of the organisations happens to have randomly selected the
same prefix - and there is then no longer any requirement that there
be any kind of (pre-existing) uniqueness for this particular usage.

Brian also said (in a different message):

  | To be more precise, we are going to define them in a way that makes them
  | extremely likely to be unique, and then treat them as if they are
  | mathematically unique. To me, that's good enough. 

It would be, but that's the very thing I don't think we should be doing.
If we treat them as if they're unique, someone will forget that they're
not, and start doing something which actually assumes the uniqueness.

Unless we can demonstrate that they are, and must be, unique (to work, or
be useful) we really have to make it very very plain that they are not
unique.

kre

---

From: Benny Amorsen <[email-masked]>
Date: 10 Jun 2003 10:23:09 +0200

> be useful) we really have to make it very very plain that they are not

This is one of the reasons I proposed having registries that do /not/
pick addresses. If there are several places where an address can be
registered, it should be painfully obvious to everyone that conflicts
will happen. Nobody can claim to be unaware.

/Benny

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jun 2003 11:49:35 +0200

Summary answer to both of kre's points:

If one could go and get a prefix under 2000::/3 today that was not tied 
to an ISP, that would be just fine. But one can't, for good reasons,
so the only solution I see is a lightweight way to get a PI prefix
that isn't ambiguous. Bob's proposal is the best I've seen for this.
That's all I can say, because your arguments are basically sound, but
we don't live in a perfect world.

   Brian

---

From: Robert Elz <[email-masked]>
Date: Tue, 10 Jun 2003 18:02:05 +0700

Date:        Tue, 10 Jun 2003 11:49:35 +0200
    From:        Brian E Carpenter <[email-masked]>
    Message-ID:  <[email-masked]>

  | If one could go and get a prefix under 2000::/3 today that was not tied 
  | to an ISP, that would be just fine.

So, you mean there's a need to have address stability inside the VPN?

That's fine - but I'd like to see that made clear whenever this issue
is raised.  I haven't had anything to do with large VPNs, and with
that lack of experience, I can't see any particular reason why address
stability is any more required there than the internet at large.
That is, I always thought a VPN was more about access control, rather
than anything else.

  | I see is a lightweight way to get a PI prefix that isn't ambiguous.

For stability, you'd want a prefix that doesn't conflict with any of
the prefixes used by the members of the VPN.   For that, whoever is
primarily responsible (someone must be doing access control policy)
can just collect all prefixes in use (ignoring normal global ones as
the first few bits will serve to eliminate those) and generate a new
number that is different than everything connected (the list of
"connected" can include everyone who may someday potentially be
permitted to be a part).   Once allocated the number can be advertised
(as in, on a web page) and anyone who ever feels they might like to
ever become part of that VPN could avoid it.

There's no need for a registry for this.

Of course, Benny's suggestion should also work for this - anyone who
wants runs a registry, most likely with some particular target audience
in mind.   One of those would perhaps be "anyone involved in the auto
industry in any way", another perhaps "airlines" - then after inventing
your own prefix, you go register it with whatever registries seem like
they may keep your number unique, and if there's a conflict in any,
start again.  So a tyre maker might register with both an auto and an
airlines registry, whereas a maker of car radios probably only (or those)
the auto registry (but perhaps also an electronics registry).

That way, it is very likely that anyone (who had bothered to register)
in any likely field would have a number distinct from everyone else,
without expecting or requiring me, at my house, to bother registering
anything with anyone (as I personally don't want a VPN like this, and
don't care who else is using the same non-routable numbers as I use).

Both methods avoid the "this is globally unique" fiction, and hence
make it very unlikely that someone will later attempt to depend upon
that (as in the "everyone we know has a number that is unique").

kre

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jun 2003 13:37:43 +0200

> will happen. Nobody can claim to be unaware.

That's also why I personally would be happy with pseudo-random
probably-unique prefixes, but Bob's idea of a 10 Euro registry for
unique pseudo-random numbers is aimed at people who want a bit
more assurance. In all cases, your mileage may vary.

  Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 10 Jun 2003 15:30:29 +0200

> So, you mean there's a need to have address stability inside the VPN?

Yes, but more than that, inside a shifting population of company networks
that are constantly joining and leaving virtual organizations. You can 
imagine the gymnastics of this unless there is a reasonably high
probability that there will be no collision between prefixes.

> That is, I always thought a VPN was more about access control, rather

Traditionally, yes, but traditionally we haven't viewed distributed 
computing as a resource purchased on demand. This is changing, and the
work-arounds for Net 10 are becoming onerous.

> There's no need for a registry for this.

That doesn't solve the N**2 problem where any customer may want
to join any VPN at any time. We don't want everybody to start numbering
at 1. 
 
> the auto registry (but perhaps also an electronics registry).

That's a lot of complexity compared with either a generic pseudo-random
algorithm or a global registry. (I can't see a logical objection
to multiple registries, if IANA gives them each a prefix, but I don't
see a benefit either.)

> don't care who else is using the same non-routable numbers as I use).

But I don't believe that in the future world of computing as a
utility service, we can assume that customers and service providers
are neatly segmented into fields of application.

> that (as in the "everyone we know has a number that is unique").

Well, somebody will depend on it whatever we write, but you have a point,
which is why I've always said that I'd settle for "probably unique".

   Brian

---

From: Shannon -jj Behrens <[email-masked]>
Date: Tue, 10 Jun 2003 09:04:32 -0700

Earlier, I suggested that an ISP could delegate addresses out of its
existing aggregated, global unicast address block for free without
providing connectivity.  Having seen all of the email on this subject,
I believe that such an ISP could actually sell prefixes for which it
doesn't provide direct connectivity.  Such addresses could be used for
VPN's, etc. without fear of collision.  Traffic destined to such
addresses on the Internet would be aggregated to the ISP, and probably
sent to /dev/null.  For an additional fee, the ISP could tunnel such
traffic back its customers.  The prefixes would be sold for a fixed,
one-time fee.

Pros
====

no collisions:
	Multiple ISP's could sell prefixes in such a manner, and there
	would be no fear of collisions.

no fear of increasing fees:
	The fee for such prefixes would be one-time and fixed.  This
	would be bound by a legal contract with the customer.
	
hijacking similar to existing system:
	The danger of "evil" ISP's doing "evil" things is equivalent
	to our existing system.  Furthermore, this is mitigated by the
	fact that there is no well known prefix, such as fee0::.

Cons
====

no convenient prefix:
	Since any ISP could sell addresses in such a manner, there is
	no convenient prefix such as fee0::.  Thus, OS's cannot
	provide default address selection behavior, nor can firewalls
	automatically filter such prefixes.

out of business:
	It's still possible that the ISP might go out of business.
	Hopefully, the ISP could provide paperwork to its RIR
	concerning all of the customers that had purchased such
	prefixes so that the RIR could avoid reallocation of such
	address prefixes.

Best Regards,
-jj

-- 
Hacker is to software engineer as 
Climbing Mt. Everest is to building a Denny's there.
--------------------------------------------------------------------
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: Bob Hinden <[email-masked]>
Date: Wed, 11 Jun 2003 12:39:36 -0700

jj,

>traffic back its customers.  The prefixes would be sold for a fixed,

Is this just another form of a registry?  Also, a lot of the motivation for 
this type of addresses was to get addresses that are provider 
independent.  While they are not intended to be routable, the seem provider 
oriented to me.

Also, it doesn't by itself, meet the need of people who want to be able to 
create a prefix locally.

Bob

---

From: Shannon -jj Behrens <[email-masked]>
Date: Wed, 11 Jun 2003 13:23:40 -0700

On Wed, Jun 11, 2003 at 12:39:36PM -0700, Bob Hinden wrote:
> Is this just another form of a registry?  

Yes.  However, I think that it's more likely to succeed than our
previous registry ideas because the addresses come from the
aggregated, global unicast address space.  Thus, there can be no
arguments about who owns what addresses.  If I buy a prefix from
Earthlink, it comes from Earthlink's address block.  Outsiders can't
even tell it's not a normal prefix (which is a blessing and a curse),
let alone state that they also purchased the prefix from some other
ISP.

> Also, a lot of the motivation for 

It's true that they're not completely provider independent.  On the
other hand, once you have purchase the prefix, you don't need to
associate with the ISP again (assuming they don't have recurring
fees).  Naturally, you'll want a legal contract that says the ISP
can't revoke the allocation, etc.  

You're free to use the prefix in any way you want, which matches the
spirit of provider-independent, non-routable addresses.  In
particular, the ISP you buy these addresses from probably isn't your
carrier.

> Also, it doesn't by itself, meet the need of people who want to be able to 

That's true.  I'm not trying to solve that problem since there are
other reasonable solutions in the works for that problem.  My solution
is more appropriate for managed networks who really want completely
unique addresses.

Best Regards,
-jj

---

From: Benny Amorsen <[email-masked]>
Date: 11 Jun 2003 22:54:17 +0200

On 2003-06-11 at 22:23, Shannon -jj Behrens wrote:

> Outsiders can't even tell it's not a normal prefix (which is a
> blessing and a curse), let alone state that they also purchased the
> prefix from some other ISP.

I think that is a curse. It means that in normal circumstances I can
expect to see what was supposed to be my unique addresses advertised by
routing protocols as part of a larger aggregated space.

However, this is something that will happen no matter what anyone says.
I would just prefer that /my/ non-routable addresses stayed out of the
global routing tables.

/Benny

---

From: Shannon -jj Behrens <[email-masked]>
Date: Wed, 11 Jun 2003 14:05:23 -0700

On Wed, Jun 11, 2003 at 10:54:17PM +0200, Benny Amorsen wrote:
> I think that is a curse. 

As I mentioned earlier, the harder problem is that there isn't an
easily recognizeable prefix such as fec0 that stacks and firewalls can
give special treatment to.

> It means that in normal circumstances I can

That's true.  However, (please forgive me naivete concerning routing)
you'll just have to use a more specific route for your own usage of
those unique addresses.

> I would just prefer that /my/ non-routable addresses stayed out of the

Several people such as yourself (e.g. Michele Py) have suggested that
"local" addresses will be advertised no matter what.  Others have
stated that there is no such thing as unique unless there's a route in
the DFZ to prove the uniqueness (e.g. kre, if I remember right).  My
solution simply takes the lemons and makes lemonade.

Best Regards,
-jj

---

From: Pekka Savola <[email-masked]>
Date: Thu, 12 Jun 2003 09:08:12 +0300 (EEST)

> let alone state that they also purchased the prefix from some other

With current RIR rules, *no* ISP can give an absolute guarantee that it's 
prefix couldn't, at one point, be pulled off.

So, it seems to me that creating implicit assumption that addresses 
allocated today from RIR's are "magical" and "will never be revoked", and 
"the ISP can give legal guarantees the prefix will never clash".

It seems to me that *practically*, recurring fees are a feature.  If an 
ISP goes bankrupt, some other ISP actually has an incentive to obtain its 
business and the prefix -- in hope of getting a share of those recurring 
fees :-).  Otherwise, the prefix could just rot and be returned to RIR 
(for example).

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Bob Hinden <[email-masked]>
Date: Thu, 12 Jun 2003 10:27:35 -0700

Pekka,

Good points.

>prefix couldn't, at one point, be pulled off.

That is consistent with my understanding of the RIR policies.  I think they 
go to some length to make it clear that the prefixes allocated to an ISP 
are not owned by the ISP and to their customers.  For example section 4.1 
of RIPE267

  http://www.ripe.net/ripe/docs/ipv6policy.html

  4.1. Address space not to be considered property

  It is contrary to the goals of this document and is not in the
  interests of  the Internet community as a whole for address space
  to be considered freehold property.

  The policies in this document are based upon the understanding that
  globally unique IPv6 unicast address space is licensed for use rather
  than owned. Specifically, IP addresses will be allocated and assigned
  on a license basis, with licenses subject to renewal on a periodic basis.
  .....

>fees :-).  Otherwise, the prefix could just rot and be returned to RIR

In this case there is also the problem that if the contact information for 
the allocation is lost or out of date, then it will be difficult for 
whoever obtains the assets of the bankrupt ISP to determine if the 
allocation is still in use.  Consequently there is a reasonable likelihood 
that it will be reassigned to someone else and made routable.

The more I think about it the less I like the idea that prefixes from the 
globally routable address space will be used for local addressing.  I 
understand there isn't anything that can stop this from happening 
occasionally, but I strongly doubt that it would ever become official RIR 
policy.

Bob