Subject: Re: Patrick Faltstrom message: Why SiteLocal is not what solves the problems people want to solve

From: Dan Lanciani <[email-masked]>
Date: Fri, 4 Apr 2003 17:37:21 -0500 (EST)

Patrick wrote:

[...]
|An application *should*always* use the hostname when communicating, and 
|that imply it should not cache the IP address of the peers or itself 
|between the flows are initiated which it needs. Yes, applications fail 
|regarding this, and IP stacks are too bad at keeping the local IP 
|address which happen to be assigned at the time a "listen" call is 
|made. Application should be better at this, and I claim they _are_ 
|getting better as computers more and more move around already today 
|(due to DHCP, 802.11b etc).

Ok, so let's fix all the IP stacks to use names in the packets and in their
APIs.  Then we can fix the DNS to track renumbering events.  Once that is
done we can get rid of site-locals for good.

|The broken 5-tuple is not much we can do anything about, BUT, 
|site-local is not solving this problem either. Yes, I know the idea is 
|that when two nodes can share the site local scoping to minimize the 
|risk for the 5-tuple to break....

You are the third person in the last 24 hours to assert that site-locals
cannot provide for stable internal connections.  Such assertions (which
are obviously based on unstated assumptions about how perfectly any such
solution must work) are very disturbing.  The deprecation of site-locals
supposedly came with some vague assurance that we would look at alternate
ways to provide the functionality that was being removed.  It is far too
convenient to say that in retrospect site-locals never did provide for
stable internal connections and thus we need not consider a replacement (or,
as others have claimed, that we don't even know how to provide a replacement).
Moreover, I'm concerned that stable internal connections will join the growing
list of "features" (including the high availability that should have come from
multi-homing) whose recommended implementation reduces to: send your ISP more
money.

[...]
|I rather see (in my possibly naïve view) sites like 
|this really getting PI address space.

Great.  Let's make this PI space available FIRST and THEN we can get rid
of site-locals with little trouble.

|Yes, aggregation can not happen, 
|but, so what? I claim the number of routes today is still manageable, 
|and the _real_ problem is that an IP address is both for addressing and 
|routing.

Great.  Let's work on that problem now.

[...]
|What one have to remember when talking about all of these problems is 
|how the Internet should work. Not how it is implemented today, because 
|things like NAT etc do exist, and yes, we will continue to see it for a 
|while.
|
|First of all, we have one big mistake regarding addressing, and that is 
|the overload of use of the IP addresses. We use it both as a unique 
|identifier of an endpoint and for routing. addressing != routing

I have made proposals over the years for portable identifiers.  Did you
support them?

|This has created the problems we have with the routing protocols of 
|today, as the Internet is no longer hierarchal. It is a mesh, a 
|complete mesh. And, when navigating a mesh, one need different 
|algorithms and mechanisms than when navigating a hierarchy. Site Local 
|will not solve this problem.

Great.  Let's fix the routing problem FIRST and THEN nobody will care
about site-locals.

|Secondly, the 5-tuple we use for flow identification is rigid, and we 
|don't accept a change of any of the 5 values without having an 
|interrupt in the flow. Maybe we should have some ICMP which say "please 
|redirect flow to this address"? How to secure it? Will Site Local solve 
|this problem? Don't think so...

I can't imagine why you would even ask if site-locals would address this
hypothetical issue in a hypothetical solution...

[...]
|Just Say No to Site Local.

Why not try a more positive approach like, ``Just say yes to PI space.''?
All of the things that you suggest have been proposed many times over
the years.  They are consistently shot down as impossible.  In fact, it
is common knowledge that merely talking about PI space can cause the immediate
death of the net as we know it--unless of course you talk about PI in
conjunction with the deprecation of site-locals.  The it's ok because we
know that once site-locals are gone we can forget about PI again...

				Dan Lanciani
				ddl@danlan.*com
--------------------------------------------------------------------
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: Patrik Fältström <[email-masked]>
Date: Sat, 5 Apr 2003 12:11:53 +0200

> Great.  Let's work on that problem now.

Yes, of course we should. But, I think we can not get real force behind 
such work before we _first_ agree Site Local is not solving this 
problem, and we therefore agree Site Local should go away.

    paf

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Apr 2003 14:21:36 +0300

> problem, and we therefore agree Site Local should go away.

Forgive me for being cynical, but another way to phrase the above is
that the intent is to deny an existing solution to people who are
content with it in order to force them to work on a new one.

	MikaL

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 05 Apr 2003 06:58:15 -0500

Hi Mika,

>content with it in order to force them to work on a new one.

Or, considered another way...

We'd like to deprecate the flawed solution now, before more people
implement it or come to depend on it.

And, we'd like to pursue a viable model for local addressing, without
the flaws and limitations inherent is ambiguous site-local addresses,
because we understand that solutions will be needed for:

         - Addressing for disconnected sites.
         - Addressing for intermittently connected sites.
         - Prefix-based access control.
         - Stable addressing for local connections.

What we _really_ want is to achieve all three of the following
things simultaneously:

         - All addresses are globally routable (note that this doesn't
                 preclude filtering some addresses or address/port combos).
         - Addresses are provider-independent (stable across ISP changes
                 or ISP renumbering, available when not connected, etc.).
         - Core Internet routing tables stay a manageable size.

But, we have not (yet?) come up with a model for provider-independent,
globally-routable addressing that does not result in routing table
bloat.

So, network administrators will be forced to choose between
global-routability and provider-independence for their internal
addressing.  And, as we've learned in IPv4, there are a fairly
large number of people who will choose provider-independence over
global-routability.

So, we do need to provide some solution for provider-independent,
local addressing.  But there is no reason why these addresses
need to be ambiguous.  And, if they are globally unique, they
don't need to be constrained by the limitations of current
site-local addressing that are required because of thier ambiguity
(can't be nested, can't overlap, etc.).

Deprecating site-local addressing does not immediately remove
it from those implementations that include it, and it certainly
doesn't remove it from current network configurations, but it
does send a strong message to people that the current, ambiguous
site-local addresses are not a solution that should be invested
in further.  And, it opens the door to finding new, viable
ways to address the demand for provider-independent addresses.

Margaret

Margaret

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Apr 2003 16:09:23 +0300

Hi Margaret,

The goals you state below are very worthy and, once there are
satisfactory solutions employing unambiguous addressing, I will
certainly be vying for the privilege to be among the first to implement
them.

However, at this point deprecating site-local addresses will simply slow
down real world deployment of IPv6 and, in a very concrete way, take the
pressure off those who are the most motivated to work on better
solutions. The fact that people feel impelled to buy time for the IPv6
WG to do this does not give me great confidence that those solutions
will be arriving any time soon.

Regards,

	MikaL

---

From: "Tony Hain" <[email-masked]>
Date: Sat, 5 Apr 2003 08:26:03 -0800

Margaret Wasserman wrote:
> ...
> What we _really_ want is to achieve all three of the 
> following things simultaneously:
> 
> But, we have not (yet?) come up with a model for 
> provider-independent, globally-routable addressing that does 
> not result in routing table bloat.

So even though the routing research group has not come up with a
solution that simultaneously addresses all three of these in the last 10
years of focused work, the IPv6 WG will promise to come up with a
solution quickly if we just deprecate the only viable approach we know
of first. I guess it shouldn't surprise me that the herd mentality is so
willing to buy the promise of a better way rather than face reality, but
it still does. 

> global-routability and provider-independence for their 
> internal addressing.  And, as we've learned in IPv4, there 
> are a fairly large number of people who will choose 
> provider-independence over global-routability.

They are forced to choose in IPv4 because it is too difficult to assign
multiple addresses to an interface. That issue goes away with IPv6, so
the 'forced to choose' concept is coming from those who don't want to
deal with the issues raised.

> 
> So, we do need to provide some solution for 
> provider-independent, local addressing.  But there is no 
> reason why these addresses need to be ambiguous.  And, if 
> they are globally unique, they don't need to be constrained 
> by the limitations of current site-local addressing that are 
> required because of thier ambiguity (can't be nested, can't 
> overlap, etc.).
> 
> it from those implementations that include it, and it 
> certainly doesn't remove it from current network 
> configurations, but it does send a strong message to people 
> that the current, ambiguous site-local addresses are not a 
> solution that should be invested in further.  And, it opens 
> the door to finding new, viable ways to address the demand 
> for provider-independent addresses.

The door is always open to finding better ways to do things. Instead of
promising greener grass, prove it first. In 10 years, the IRTF RRG has
not figured out a PI space they are willing to live with. It is
incumbent on the IPv6 WG to deliver a viable PI replacement BEFORE
removing the only PI addressing model we have.

Tony

---

From: Margaret Wasserman <[email-masked]>
Date: Sat, 05 Apr 2003 11:31:21 -0500

Tony,

>willing to buy the promise of a better way rather than face reality, but

Please stop twisting and misinterpreting everything that anyone
posts to the list who disagrees with you.  The above is NOT
what I said.

I _said_ that we really want these things, but they are mutually

>deal with the issues raised.

Tony, allowing an interface to have two addresses:

         - One that is globally routable and globally accessible, and
         - One that is stable and local,

is _exactly_ what I am proposing.

However, I am proposing that there is _no reason_ why the stable, local
addresses have to be ambiguous.

Margaret

---

From: Mika Liljeberg <[email-masked]>
Date: 05 Apr 2003 19:56:28 +0300

Margaret,

> addresses have to be ambiguous.

Then I would propose that this solution must be introduced at the same
time the current FECO::/10 is deprecated, in a new version of the
addressing architecture. That I would have no objections to. Let's stop
the April Fools' poll now and start writing some drafts.

	MikaL

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 06 Apr 2003 11:15:10 +0200

Tony,

Tony Hain wrote:
...
> ... It is

This is where we disagree. I think we have learnt since FEC0::/10
was defined (in 1995) that ambiguous PI space is *not* viable, 
as a result of the operational disaster of deploying RFC 1597/1918 
space as defined in 1994. I think it's incumbent on us to 
deprecate this non-viable solution as quickly as possible, and then 
define something better. And I wish we'd seen this much earlier,
since we now have to fix shipped products.

(BTW, "deprecate" doesn't stop those products working.)

As for whether we can do what the RRG has failed to do, of course
not. But it seems fairly clear we can define unambiguous PI space.

   Brian

---

From: Måns Nilsson <[email-masked]>
Date: Sun, 06 Apr 2003 19:03:36 +0200

--On Saturday, April 05, 2003 16:09:23 +0300 Mika Liljeberg
<[email-masked]> wrote:

> solutions. 

I am quite busy in rolling out v6 and v6 services, and nothing of what I do
requires site-local or even benefits from it. What do you mean? 

-- 
Måns Nilsson            Systems Specialist
+46 70 681 7204         KTHNOC  MN1334-RIPE

We're sysadmins. To us, data is a protocol-overhead.

---

From: Mika Liljeberg <[email-masked]>
Date: 06 Apr 2003 21:03:29 +0300

Måns,

> requires site-local or even benefits from it. What do you mean? 

Your customers are mainly universities and research institutes, correct?
I suspect that provider independence is not high on their list of
priorities. If that were true in general, there would be no demand for
PI addresses.

What I mean is that commercial sites which require (or think they
require) provider independence may put off adopting IPv6 while there is
no deployable solution. This will slow commercial deployment of IPv6.

	MikaL

---

From: "Tony Hain" <[email-masked]>
Date: Sun, 6 Apr 2003 20:52:49 -0700

Margaret,

I am not trying to twist words, I am reflecting what I hear as it
applies to the reality of the deployed network. Our primary disagreement
is over process. Forgive me but I can't figure out the technical
differences that exist, because at this point it is not clear to me what
you believe, or if you believe the problems that many network managers
would use SL for are real. 

One thing that is clear is that there is no consensus in the WG as to
what 'deprecate SL' means. Is it 1) remove ambiguity, 2) remove the
definition as a well-known prefix to filter at the border of a site, 3)
change the architecture to remove address scoping, 4) reduce routing
complexity, 5) remove requirements on applications to deal with
differences between prefixes, 6) pacify fear of change

4/2 AD - The ambiguity of the current site-local addresses will impact
applications.
We still need to solve the other problems (renumbering and disconnected
sites) but we should do this using an addressing format which can be
made transparent to  applications.

4/2 JB - Ambiguous addresses are a nightmare...

4/2 MT - Scoped addresses as have been pretty well demonstrated take us
down some pretty scary paths.

4/3 AZ - reasons += adds complexity to routing, forwarding, and network
operations;

4/4 ER - It is important to simplify IPv6 DNS, routers and source
address selection.

4/5 RB - i.e. let's solve a routing problem with an address model hack.
pfui!

4/3 MW - This is actually a pretty good match for "deprecation" by
my definition.  We'd keep the prefix in the spec, but mark
it as "deprecated, do not use", or something like that.

4/4 HA - Note: By "Deprecate Site-Local", I mean "Do not require any
application, 
host, router, protocol or IETF practice to have to make special 
consideration for the idea that an IPv6 unicast address outside of the 
link-local range can refer to two different hosts".

4/5 DL - I thought we were voting on something more meaningful, i.e.,
site-locals themselves.  Now I understand that site-locals do not exist
as such and we were just voting on the deprecation of the prefix itself.

Another thing that is not clear is how many of those who are saying 'Yes
- depreciate'  are actually motivated to solve the problems that will be
created by whatever 'deprecate' means. I am not alone in that concern:

4/6 DL - Or are you saying that once site-locals are gone the IETF will
be unwilling to allow any additional changes to the architecture to
solve the renumbering, PI, etc. problems because these problems are not
``enough of a problem'' to warrant fundamental changes in the
architecture?  --> explicitly unanswered

From my perspective, if they really want a change they must participate
in providing an alternative first. It is too easy to be destructive and
walk away, which is exactly what this consensus call is setting up. Most
of the 'Yes' comments are littered with value judgments (bad unnecessary
dubious marginal scary) and show the commenter has no appreciation for
the breadth of the real underlying requirements. Even your messages on
the subject show you don't believe all the problems of the person
fighting the day-to-day battles are real. Given the track record of this
WG, and the lack of wide scale participation by those most effected (end
site network managers), this call is a disaster in process. 

Whenever the I-D editor gets it processed, I have a draft that intends
to identify the requirements for the alternative solutions to work from.
Highlights:

We need address space that is freely available for use by the network
manager. Requiring them to get space from an ISP, or even continually
pay a registry is not a viable plan. While this space might be declared
'unroutable', we need to design it on the assumption that parts of it
may become routed and the routing table needs to stay at a manageable
size. This implies some form of aggregation must be possible.

Stable, local use prefixes are required. There are claims from the ISP
perspective that a disconnected site will need to renumber when it
connects. Renumbering in an IPv6 context means adding a prefix, and
unlike IPv4 it does not mean removing the existing one. There is no
reason for a site that connects to have to renumber nodes that are not
going to use the external connection. In particular there is a need for
existing internal applications to continue working as networks connect
via different prefixes, so a site managed persistent prefix is required.
One example of this type of network is a vehicle that attaches to local
networks when stopped, and wireless networks while mobile. 

Site scoped addresses exist. We must recognize that route filtering ==
scoped addresses, and route filtering will exist despite idealistic
hopes for a single flat routing space. We must also recognize that
network managers want the ability to manage the scope of their name
space and express a comparable policy to what they have for routing.
This will not be easy, and the current round of comments show people
prefer to make it someone else's problem. Also, awhile back you
suggested a partitioned network example as a reason to use global rather
than local addresses, because the partition could be healed through the
Internet. That concept ignores the reality that almost all network
managers would not want file mounts of proprietary content to suddenly
traverse the Internet in the event of an internal partition. There are
very valid reasons for local scope addresses. The idea that applications
can blindly ignore that reality and treat the world as a single space
has to be put behind us.

Once we have the requirements collected, solutions can be proposed. I
expect we will end up with multiple solutions, and it is not clear we
will be able to meet them all without keeping the current SL. That does
not mean we have failed, just that we have work to do. I do believe we
can build a PI that deals with the majority of the ambiguity concerns,
and I suspect that the remaining demands for ambiguous addresses won't
expect or want to be interconnected. We are supposed to be working on
technical approaches to problems, not reacting with fear to what bad
things might happen. 

Tony

---

From: Harald Tveit Alvestrand <[email-masked]>
Date: Mon, 07 Apr 2003 10:41:48 +0200

Tony,

this argument seems to be one of invoking a large group of people not 
present (in this case "the person fighting the day-to-day battles" and "end 
site network managers") in support of your viewpoint.

have you considered the possibility that of all those people who say that 
the solution proposed, ambiguous site-locals, is not a good one, many 
actually are of the class of people whose interest you claim to defend, and 
disagree with you?

I agree with you that the Right Thing is to get the requirements on the
table. But I think spending the WG's time and the implementors' time in 
specifying, designing and implementing protocols and code that 
special-cases FEC0::/10 is a waste of resources - we've looked at that 
solution to the requirements, and it does not fulfil the requirements for a 
solution.

BTW....

> pay a registry is not a viable plan.

I've been duly chastised before because I suggested that when people roll 
out million-dollar internal networks, or even 100-dollar PDAs, a few-dollar 
additional outlay per deployment scenario is a show-stopper.

The biggest problem with paying a dollar (and why "free" is usually better) 
is that it often takes a hundred dollars' worth of overhead to get to pay 
it.

But I think we should focus on "acceptable overhead", not "free as in beer".

                            Harald

---

From: Leif Johansson <[email-masked]>
Date: Mon, 07 Apr 2003 10:37:31 +0200

Harald Tveit Alvestrand wrote:

>
>
> have you considered the possibility that of all those people who say 
> that the solution proposed, ambiguous site-locals, is not a good one, 
> many actually are of the class of people whose interest you claim to 
> defend, and disagree with you? 

I agree. Moreover the argument has been refuted by a few people on the 
list who at least
seem to believe that they are involved in day-to-day operation of 
networks, myself humbly
included. The logic of the counter-argument that we are "only" running 
research networks
that for some reason are fundamentally different from other types of 
networks continue to
ellude me.

    leifj

---

From: Margaret Wasserman <[email-masked]>
Date: Mon, 07 Apr 2003 06:23:07 -0400

Hi Tony,

At 08:52 PM 4/6/2003 -0700, Tony Hain wrote:
>Forgive me but I can't figure out the technical

 From reading your posts, I think that our technical positions are
reasonably close.  I think that we both see the flaws with site-local
addressing and would like to see it replaced with something better.
I also think that we both realize that the "real" solution would be
globally-routable PI addresses, but we also understand that we can't
get there fast enough (if at all) so we need some type of local PI
addressing in the meantime.  We mainly disagree about the value
that site-locals have today.

You believe that they are a valuable tool for network administrators
today -- as local, PI addressing.

I think where I stand is pretty clear...

I wrote a 30+ page document that outlines the problems and benefits
with site-local addressing and concludes that the problems far
outweigh the benefits.

I proposed the "limited" model to constrain site-local addresses
to completely disconnected networks.

I do think that the following needs are "real":

         1 Addressing for disconnected sites.
         2 Addressing for intermittently connected sites.
         3 The need for local access control.
         4 The need for provider-independent local addresses that
                 remain stable when providers change/renumber.

I just don't think that site-local addressing (ambiguous scoped
addressing, as defined in the scoped addressing architecture and
as allocated in prefix FEC0::/10) is the right solution to any
of these problems.  It is known to have substantial problems, and
I think that we should stop encouraging people to invest in it
further (in specifications, implementations, etc.)

The first one (disconnected) is relatively easy.  I'd rather that
people registered a local, PI address, and I think we should offer
that option.  Some people won't agree/choose to register, so we will
also need to offer some type of auto-generated option.  But, there
is NO reasonable justification for why these addresses need to be
ambiguous, so they shouldn't be.  That also means that they shouldn't
be allocated from FECO::/10, because some implementations already
include special handling of those addresses as ambiguous.  So, my
"limited" model is flawed.  I accept that.

The addressing for #2 may be handled the same way as #1, but
actually making connections survive disconnection and re-connection
at a new global address is more complicated than that, as it requires
that all local connections/applications prefer site-local addresses
while global connections/applications use global addresses.  We will
need to figure out if this can be done in a way that is completely
compatible with behaving optimally on stably connected networks, or
if it will be necessary for implementations to get some type of
configuration hint regarding which way they should behave.  Or,
possibly, we need to consider a different solution for this
case.  I agree that we need to understand what the actual requirements
are here, before we can evaluate solutions.

We already have a couple of drafts that address #3 without site-
local addresses.

#4 is only really solved by stable, unique, globally-routable,
provider-independent addresses, but it could be partially solved
by any solution to #1 (just like SLs partially solve it).  Let
me explain why it isn't solved by just giving two addresses to
every machine...  Assume I have a 200  node network with 10
routers.

         - If I use only global PA addresses, when my provider
                 changes, I will need to change the global
                 prefixes on my 30 routers, update my DNS,
                 update any access lists/security associations
                 on my 200 hosts (perhaps automatically), etc.
                 I will need to do this before any global
                 access will work.  In the meantime, local
                 access would continue to work until my formerly
                 PA addresses become invalid (not just un-preferred,
                 invalid), then it will start to fail if I haven't
                 renumbered yet.

         - If I use both global PA addresses and local prefixes,
                 when my provider changes, I will need to change
                 the global prefixes on my 30 routers, update
                 my (split) DNS, update any access list/security
                 associates related to global addresses on my 200
                 hosts (perhaps automatically), etc.  I will need
                 to do this before any global access will work,
                 although local access that actually uses site-local
                 addresses (if I have any applications that know
                 that they want to use site-local addresses) will
                 continue to work indefinitely, and any local access
                 that uses global prefixes will work until my
                 old PA prefix becomes invalid, as above.

Compare both of the cases above to what I do if I have NAT:

         - If I use NAT with internal local addressing and external
                 PA addressing, when my provider changes, I
                 renumber one side of my NAT box. Period.

So, it is my opinion that if people put the level of value on
provider-independence that you suggest (and I believe you), then
they will choose NAT (and probably IPv4) unless/until we figure out
a way to provide NAT-less, provider-independent global addressing
in IPv6.  [Note:  I did not say that SL == NAT, nor did I say
that SLs increase the value of NAT, etc.  I think that we have
this problem with or without site-local addresses.]

I know that we don't know how to solve that problem right now.  But,
could we please stop arguing about site-local addresses (which
_don't_ solve that problem at all, and don't solve any problem well)
and start working on solutions to the real problem?

Margaret

---

From: "Fred L. Templin" <[email-masked]>
Date: Mon, 07 Apr 2003 10:41:36 -0700

Brian,

> not. But it seems fairly clear we can define unambiguous PI space.

Can you say more about this? Is there a proposal defining an
unambiguous PI space that I may have missed?

Thanks,

Fred
[email-masked]

---

From: "Charles E. Perkins" <[email-masked]>
Date: Mon, 07 Apr 2003 12:08:29 -0700

Hello Margaret,

I'm only an occasional drop-in, but:

Margaret Wasserman wrote:

>              I think that we both see the flaws with site-local

I can readily agree with this also.

> globally-routable PI addresses,

I think it might be better to get global uniqueness first, and NOT
attempt global routability.  It is most likely not easy to get
scalable global routability from PI addresses.  So, if that's true
we should not make the deprecation depend on this difficult thing.
But anyway site-locals don't offer global routability, and so if we
supply a globally unique set of addresses, that are NOT routable until
they get to be routable later, isn't that good enough?

I think if they're not routable, they're already (by nullity)
provider independent.  If we supply a routing protocol later for
them, then so much the better.

>                  remain stable when providers change/renumber.

I would add (5): globally unique addresses, or _at least_
            (5a): addresses that are astronomically likely to be unique.

It seems to me that we can get all of these later by tinkering with the
concept of global routability.  I didn't write any specific 30+ page
document for doing this tinkering, though...

> ambiguous, so they shouldn't be.

Doesn't this mean that you also wish to mandate the same as my
requirement 5{,a}?

> are here, before we can evaluate solutions. 

I agree with your last sentence here, and I also suggest that the
work in doing so will take a while.  It could be related to the problem
of allowing an ad hoc network to utilize the advertised routing
prefix of an Internet Gateway (see [manet]).  Ideas for solution
are available, but I don't believe the complete solution is known.
Or, it might be related to the ideas being developed within the [nemo]
(Network Mobility) working group...

> We already have a couple of drafts that address #3 without site-

Could you say a little more?  Is it related to authorization?

                  ..........

> this problem with or without site-local addresses.]

I think this is an excellent challenge, and one we should try
to meet.  It seems to me that we ought not to make the discussion
about site-local depend on it, though.

Along the way, though, perhaps it's good to recognize that after
all a NAT _is_ a "router" -- to a destination address which is implicit
in other information available to the NAT but not to the source.
The organization of the NAT's "route table" is not controlled by
a traditional routing protocol.  Perhaps we have to broaden our
understanding of "routing" to include such other sorts of devices,
before we can obtain the desired "global routability" of PI
addresses.   Or, maybe not -- it's just an idea...!

Regards,
Charlie P.

---

From: Greg Daley <[email-masked]>
Date: Tue, 08 Apr 2003 10:36:47 +1000

Hi Charlie,

A add-on about GUPI and Global Routability is below.

> they get to be routable later, isn't that good enough?

I think that you're right in that we need a solution now,
but I believe that if we can find a solution which has qualities
which support global routability, then this should be favoured.

We don't know if people will even want these addresses routed,
and there's not much point putting the big effort in to fully
preparing for routability if no one wants this.
On the other hand, we may be able to ensure that we create
a GUPI addressing scheme which meets GrouPI basic requirements:
(aggregation, uniqueness, permanence).

This may discount schemes which rely upon random prefix
allocations though.

There is a good discussion about the concept of 'address ownership'
(PI) and 'address lending' (PA) in rfc 2008/BCP7. This points
out pitfalls to PI which may prevent routability in any case.

[rest snipped]

Greg D.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 08 Apr 2003 10:03:54 +0200

> unambiguous PI space that I may have missed?

I think there have been several half proposals, but you can see
the Tony Hain and Andrew White drafts for fairly full examples.

   Brian

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 08 Apr 2003 09:31:48 -0700

Hello Greg,

> which support global routability, then this should be favoured.

Suppose we had a solution that guaranteed uniqueness and
provider independence, but didn't have any obvious features
to support routability.  How long should we wait before going
forward with the solution achieving the smaller goal?

> preparing for routability if no one wants this.

Check.

> (aggregation, uniqueness, permanence).

I'm beginning to think this is impossible, as I will explain below.

> This may discount schemes which rely upon random prefix

Such schemes do not offer hopes for aggregation...

> out pitfalls to PI which may prevent routability in any case.

Here's why PI may be the same as non-aggregable.

Supposing we define the "provider" as the "lowest point
in the hierarchy outside one's domain", which is (practically
speaking) about the same thing as the "point of attachment"
to "the Internet".  A provider-independent address would then
be an address which is independent of (i.e., not related to)
its point of attachment to the Internet.

Intuitively, one cannot remain aggregable to the address
of every such potential point of attachment.  This seems
pretty clear to me, but if I am missing something please
let me know!

Notice, by the way, that private addresses in a NATted domain
are both provider independent and (from the point of view
of the rest of the Internet) non-aggregated :-).

Based on these points, I think we should concentrate on
defining a set of unique, provider-independent == non-aggregable
addresses to fulfill the needs of those who had wanted
to use site-local addresses.  We would also specify that
the default-free zone MUST NOT contain routes for such
addresses.

Regards,
Charlie P.

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 9 Apr 2003 09:00:47 +1000

G'day Charlie,

> its point of attachment to the Internet.

:-)  Good point.  I guess the exception is geographical routing
stuff, where routes to Melbourne and Sydney aggregate to a
route to Australia if you're far enough away.

> the default-free zone MUST NOT contain routes for such

I think that's fair enough, and gets us a quick, good, solution
to the current problem of SLAs.  I think the geographically
aggregable addressing this is worth looking at further, but I
don't think there's any need to hold up the SLA->GUPI move for
it.  After all, GUPI space may still be useful even with a
geographically routable scope.

-----N
--
Nick 'Sharkey' Moore                    <[email-masked]>
Research Fellow, CTIE                   Tel: +61 3 9905 3707
Monash University,  Australia           Fax: +61 3 9905 5358

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 08 Apr 2003 17:00:18 -0700

G'day Nick,

>route to Australia if you're far enough away.
It's an interesting point.  I guess one could route according to
any locators that have a usable map.  For geographical,
the map is pretty natural.  For routing according to usual signaling
pathways, locality in the map conveniently corresponds to
ease of signaling, which makes protocols work well.  Maybe
geographical routing would work better if the routers were known
to have some some sort of signal pathways across adjacent counties.

It's also interesting to note that for geographically dependent
but provider independent addressing, portability is lost.
In other words, it doesn't matter who the provider is as long
as you don't move and they live nearby somehow.

Regards,
Charlie P.

---

From: Greg Daley <[email-masked]>
Date: Wed, 09 Apr 2003 10:13:46 +1000

Hi Charlie,

I don't think I'm interested in waiting
for ideas to drop from the sky either...

A few comments inline.

> forward with the solution achieving the smaller goal?

Not very long at all, I'm interested in working
out if any solutions cater for these, which can
be explored before the next meeting.

Simultaneously I'd suggest looking at other
collision avoidance systems (randmoness).
This doesn't look like it's going to be
too hard to do itself, though.

> pretty clear to me, but if I am missing something please

You're right about this, when we look at moving between
providers as moving between branches of a hierarchy.

I've been thinking about existing routing schemes outside
the Internet.   Traditionally, we can contrast the
telephony and postal systems.

Addressing in telephony systems is partially tied to
geography, with a part of the address prefix bound
to a regional allocation (in the same way that RIRs do).
Subsequent routable blocks are handled by Service Providers,
and addresses are tied to these blocks (the way PA addresses
are in IPv6).

In some locations, movement of a customer between
service providers allows an requests for an address at the
routable block owner, to be forwarded to the new SP.
(we probably want to avoid these sort of overlays though).

In the postal system, there's a hierarchical address
system which delivers mail to country and region,
before the distribution to town/street kicks in.

In some places, it may be simple to allocate a service
provider to look after a 'internet postal addresses' for a
region or town, in the same way that incumbent
carriers handle fixed telephony lines in various locations.

While this may not be simple in such a dynamic marketplace
as in USA, there may be ways that SP's could exchange routes
within regions.  This could order to cover the situation where
a SP receives 'postally addressed' packets, which are actually
serviced by a peer service provider in the same region.

At this stage I'm not sure how messy this would get, but
peering relationships would have to be established between
all players in a region (may be dependent on the eventual
addressing scheme).

Most changes of service provider will not involve location
change.  Therefore, changes between one service provider
and another need not modify the route tables outside
the local postal area.

> of the rest of the Internet) non-aggregated :-).

If only they were useful :)

> the default-free zone MUST NOT contain routes for such

Indeed. If there's no likely candidate for global routability
by the next IETF, I'll be voting for that.

Greg.

---

From: Greg Daley <[email-masked]>
Date: Wed, 09 Apr 2003 10:41:39 +1000

Hi Charlie,

> to have some some sort of signal pathways across adjacent counties.

Counties or countries?
for small distances, moving the 50-100km between one region and
another may not be a big issue.

Advertised routes may be able to take care of this for you.
This may make sense if the minimum distance to a destination
for one of N paths takes you a certain number of zones/hops/km.
The metrics could be related to the topology (rather than
existing routing topologies).

I'm not sure that it would be as cheap to route this way though.

> as you don't move and they live nearby somehow.

This may be an issue in Silicon Valley, especially in those
'startup-suites' which pop up ;)

If people are looking for large blocks of land from which to
get an big permanent aggregatable prefix, I'm sure that we
could sell them some land in outback Australia
(Just mind the RTT, sand and snakes though).

Greg

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Wed, 9 Apr 2003 14:22:41 +1000

> to have some some sort of signal pathways across adjacent counties.

Yeah, it doesn't work perfectly unless the network is "meshy".

On the other hand, it'd be interesting to see how aggregable those
routes would be if the (lat,long)->prefix map was done well.

> but provider independent addressing, portability is lost.

Yeah, "provider independent" vs. "locational independent", to look
at it another way.  But that'll get us involved in the identity
vs locality debate again :-)

-----Nick

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 09 Apr 2003 16:35:58 +0200

> route to Australia if you're far enough away.

If the relevant ISPs in Oz don't share the same trans-Pacific
route, they don't aggregate at all.

   Brian

---

From: "Nick 'Sharkey' Moore" <[email-masked]>
Date: Thu, 10 Apr 2003 08:22:34 +1000

> route, they don't aggregate at all.

Well, they might for a router on the east coast, which might just
look at the address and go "Oh, the antipodes.  Send it to California."
The Californian router then has to look at it and decide is it
for Melbourne or for Sydney or for Auckland.  

I realize that this kind of 'geographical scope' isn't very useful
for a lot of things, and I'm certainly not advocating the replacement
of the current scheme with it.  I think it's got some charms though.

Right, back to replacing SLAs ...

-----sharks