Subject: RE: one question...

From: Mark Smith <[email-masked]>
Date: 26 Nov 2002 14:02:15 +1100

On Tue, 2002-11-26 at 13:17, Christian Huitema wrote:
> > > So I've been watching this debate about globally
> > > ~unique site locals and I don't understand how the
> > > end node knows whether a particular destination
> > > address is in scope (reachable) or not. The old
> > > way, it just matched it to its own scoped prefix
> > > and was done with it. What I've been hearing is
> > > some desire to be able to patch together other
> > > sites (extranets)... how would a node know which
> > > scope address to use in that case?
> > 
> > in general the only way for node A to determine whether node B
> > is reachable is for A to send a packet to B.  if A gets a reply
> > from B, B is reachable.  if A gets an ICMP message back, B
> > is not reachable (for temporary or permanent reasons).  if A
> > gets nothing back, either B is (temporarily) unreachable or
> > B doesn't want to answer A.
> > 
> > but you'll never be able to determine this by looking at prefixes.
> 
> Actually, the "Default Address Selection for IPv6" draft includes
> language of that nature. It would have to be amended to take into
> account the GUPI proposal. Something about assuming reachability of GUPI
> if on the same site, but not if on a remote site.

Is there really such thing as a "remote _site_" in the GUPI model ?

Under the GUPI model, I would think you reach a "remote site" or remote
destination (ie not internally connected) via global addressing.

As I understand it, the GUPI model pretty much gets rid of the site
model completely - it really is just catagorising connectivity and
destinations as internal verses external - internal connectivity using
GUPI addressing, via internally administered network infrastructure
(including a VPN), verses external connectivity via the public Internet,
using global addressing.

Mark.

ps. the word "site" we are using in these threads is becoming very
overloaded with slightly different meanings, and it's becoming very
confusing to know what people are referring to when they use the word
"site", even when used multiple times within the same email.

Maybe we should start using terms such as internal destinations (via
GUPI addresses) or external destinations (via global addresses).

It's tempting to use remote verses local destinations, but that also has
some geographical connotations.

--------------------------------------------------------------------
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: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 00:43:09 -0500

> (including a VPN), verses external connectivity via the public Internet,

I wouldn't use the words "internal" and "external" because GUPIs would
surely be used for private connectivity between sites.  I'd use
"private" and "public" instead.  So GUPIs would be used within "private"
sites that (for the most part) didn't have connectivity to the public 
Internet, and for connectivity between "private" sites and other sites;
globals would be used by sites with connecitons to the public Internet.

Keith

---

From: Mark Smith <[email-masked]>
Date: 26 Nov 2002 17:37:30 +1100

> globals would be used by sites with connecitons to the public Internet.

I think your imagined model of how GUPIs would be used might be
different to mine.

As I see it, there are only three basic addressing scenarios, assuming a
network with more than one segment (ie using link local addresses for
internal connectivity is not covered here) :

1) Globals - the address space stability of the global address space
given by your provider is good enough. You use globals for everything,
and have decided that coping with a global renumbering event is cheaper
than the administration of GUPIs. 

2) Globals and GUPIs - you don't want to rely on the stability of your
allocated globals for your internal connectivity, so you roll out GUPI
address space as well. GUPIs are used for your internal communications
ie communications that doesn't travel across links that are part of the
public Internet.

3) GUPIs only - you don't have a Internet connection, you need internal
address space, GUPIs suit. If at a later date you get an Internet
connection, you leave your GUPI address space in place, and roll out
your provider allocated globals.

A network with occasional public Internet connectivity would switch
between scenario 2 and 3, based on the presence of its Internet
connection.

My comments about naming (and pretty much all others on GUPIs) have been
based on scenario 2. I think scenario 2 would be the most common
encountered.

In the conext of my above scenarios, I'd be a bit concerned that the
word "private" has negative IPv4 NAT associations - using it with IPv6
may help people along the path of thinking of using GUPIs and IPv6 NAT.
The word "private" also suggests security, which we don't want to
further endorse. 

I think that "internal" and "external" are good description words of
what types of communications is happening in scenario 2.

Regards,
Mark.

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 02:06:30 -0500

One difference between our models may be that you seem to be assuming
that if a network has external connectivity, it has connectivity to
the public Internet.  I do not assume that.  So I see GUPIs as a way 
in which networks that aren't connected to the public Internet can
still get addresses which allow them to establish private connections
to external networks.

Another difference is that I see little reason for a network to support
both GUPIs and globals - if a network has globals then it is probably
better off without GUPIs.   Yes, GUPIs might be more stable than globals,
but this is not necessarily the case - the opposite could also be true.

OTOH I wouldn't try to insist that a network that supports globals
not use GUPIs.  If supporting both kinds of prefixes turns out to be 
the best way for that particular network to operate, fine.  I just
don't see that configuration as being of signifcant value.

Keith

---

From: Mark Smith <[email-masked]>
Date: 26 Nov 2002 19:48:04 +1100

On Tue, 2002-11-26 at 18:06, Keith Moore wrote:
> the public Internet. 

Your right. I have been assuming that external = public Internet.

But I have also assumed that internal != public Internet.

If two organisations decide to connect together via a backdoor
connection, push GUPI routes between each other's routing domain, and
implement two opposite facing firewalls, I would still consider their
connection internal.

 I do not assume that.  So I see GUPIs as a way 
> still get addresses which allow them to establish private connections

With my definitions of internal / external above, I'm struggling to
think of an external network that wouldn't be the Internet.

I can imagine a service provider / telco building a private IPv6 network
for their customer's to connect to, which I think could be an "external"
network using your definition.

OTOH under my definition of internal above, this private telco backbone
could also be considered internal - you would be connecting to a
network  which provides you with connectivity to other, known parties
that are part of this private IPv6 backbone. It is a conscious decision
to obtain connectivity with these other parties. The service provider is
only really providing convenient, managed layer 3 connectivity, and
ensuring better QOS, by providing dedicated bandwidth to known
customers.

I suppose basically I'm considering internal to be any time one
organisation chooses to make its GUPI address space routes available to
another, and accept the other organisation's GUPI address space routes.
The organisation knows who it is talking to and vice versa (I'm not
talking about a trust relationship here though - just the conscious
decision to interconnect to each other's networks and the trading of
GUPI routes).

External under my definition is when you choose to connect to a network,
where you don't know and can't control who else is connected to it - the
public Internet is the only network which I know of that fits this
definition.

> but this is not necessarily the case - the opposite could also be true.

Other than internal links failing, causing destination unreachables,
timeouts etc, what cases would there be where globals are more stable
that GUPIs ?

I'm struggling to think of a failure case for the new GUPI models where
stability would be less than globals.

Renumbering when merging networks was a stability issue we had with
traditional site-locals, but that is the what GUPIs fixes.

I imagine that from the day you switch on your first router and it
generates / you assign your GUPI addressing, your internal GUPI
addressing would stay the same as you build out your network. Internal
communications failures would be caused by all the other typical causes
of failure in the network, but not GUPI addressing itself.

> don't see that configuration as being of signifcant value.

I think there is, but at least they are optional - I would use them, and
you wouldn't :-)

Regards,
Mark.

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 26 Nov 2002 07:47:58 -0500

Hi Mark,

>ie communications that doesn't travel across links that are part of the

You'd have to add three things to this to get to where I hope that
GUPI addresses will take us:

         - GUPI addresses may also be used to communicate over
                 private links with other GUPI-addressed networks.
                 In other words, several companies may use GUPI
                 addresses to communicate with each other over
                 a shared extranet.  These types of networks are
                 quite common in some industries for suppliers/
                 customers or data center/clients.  This wouldn't
                 and shouldn't require that multiple companies
                 share a GUPI prefix, just that they have routes
                 that point to each other.

         - You may have different "levels" of GUPI addresses within
                 a single network...  Some devices may use addresses
                 that are filtered at the department level, some
                 may be filtered at the corporate level, and
                 some may be filtered at the extranet level, for
                 example.

         - Some companies may pay their ISPs to globally route their
                 GUPI addresses.  I know that some people don't
                 want this to be possible, but I'm not sure why.
                 I agree that we should only advise this if we can
                 come up with an aggregable method for allocating
                 GUPI addresses.

In the network, GUPI addresses would be treated _exactly_ like global
addresses.  And, just like global addresses (which they are), some of
them will be filtered at firewalls in various places.

We will need to do some work to document how other types of leaking
(DNS and routing protocol leaking, in particular) should also be
blocked at the same point as the traffic.  However, this is pretty
commonly done for VPNs in IPv4, so there are some known solutions (route
filtering and split DNS).

There will continue to be application-level and mobility issues with
these addresses, or any type of private or filtered addresses.  The
problems are reduced by the fact that the addresses are not ambiguous,
but the problems are not all eliminated.

However, it seems that people _will_ use filtering to create private
networks.  The best we can do is try to provide a solution that
mitigates the damage.

Margaret

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 08:21:39 -0500

> decision to interconnect to each other's networks and the trading of

Okay, it just seems like an odd use of the word "internal" to me.
(I'm tempted to quote Lewis Carroll here but I won't.  :)

> timeouts etc, what cases would there be where globals are more stable

When the site network is renumbered/reorganized more often than the
site's ISP changes the global prefix assigned to the site.  People
seem to assume that ISPs will want to change prefixes every week
while the site will wisely manage its address space and never need
to reassign suffixes, but it ain't necessarily so.  I've certainly
seen internal renumbering required because of poor address space management
within a site.

Keith

---

From: Mark Smith <[email-masked]>
Date: 27 Nov 2002 00:50:00 +1100

Hi Margaret,

>                  that point to each other.

Totally agree, this is where I think GUPIs fix well the problem with
traditional site-local networks being joined physically via leased
lines, or logically via VPN tunnels.

I imagine that unique GUPI prefixes would be allocated / assigned /
auto-generated on a per "entity" basis, with that "entity" then using
the GUPI prefix on its own network infrastructure.

An entity could be :

1) An individual
2) A house hold
3) an organisation

there are probably other entity types as well.

I've chosen  the word "entity" (without much deep thought though) as it
is very generic - it doesn't imply size or geographical boundary.

Interconnecting entities would involve these steps (pretty much
repeating what you have said above) :

1) play GUPI prefix lotto - if you loose, one of the entities will have
to renumber their network
2) bring up the link(s) between entity network infrastructures, either a
physical circuit or a logical VPN tunnel. Part of this step is
implementing any firewalling if necessary between the entities
3) pushing each entity's GUPI /48 into the other's routing domain.

>                  some may be filtered at the extranet level, for

When you use "levels", am I right in assuming you mean creating
different packet forwarding boundaries via packet filtering ACLs etc,
within the same instance of a GUPI address space ? eg although marketing
and finance are part of the same GUPI address space, ACLs in the network
prevent marketing sending / receiving packets from finance ?

>                  come up with an aggregable method for allocating

I suppose it is just that (near) globally unique site local addresses or
GUPIs are not at the moment trying to solve that problem, people on the
mailing list don't want financially able people to turn it into a
solution to that problem, without it being designed properly.

Regards,
Mark.

---

From: Mark Smith <[email-masked]>
Date: 27 Nov 2002 01:16:54 +1100

Hi Keith,

> (I'm tempted to quote Lewis Carroll here but I won't.  :)

It probably is, although the terms internal and external in this context
remind me of the way "internal" and "external" are used to describe
routes in an IGP. An IGP prefers its internal routes over equivalent
external routes because it discovered them itself, verses just being
told the external route and an arbitrary metric.

Here is an alternative analogy - you can choose your friends
(organisations you communicate with by directly connecting with
(logically or physically) and trading GUPI /48 prefixes), you can't
choose you relatives (everybody else on the public Internet, for which
you use global addresses).

I'm open to alternative describing words - I initially thought about
on-site (internal) and off-site (external), but wanted to avoid the word
"site" - people's default understanding of it is geographical, I didn't
want to imply any sort of geographical scope for my "internal"
communications.

> seen internal renumbering required because of poor address space management

I agree - while I've known (and been thankful) that a /48 gives you 65K
subnets, its only when I read this did it really occur to me that some
organisations will need to use aggregation within their /48 - /64
address space to shrink their route tables. Pretty obvious really, I
just got a bit blinded by having so many subnets to play with :-) 

Regards,
Mark.

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 09:20:47 -0500

> you use global addresses).

offhand, I like calling them "friends" and "relatives" - to me it 
conveys the right intiutive sense of what is going on.   

Keith

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 09:17:50 -0500

>                  private links with other GUPI-addressed networks.

Or for that matter, to communicate over private links with other
networks that use globals.  I don't see why it matters whether the 
other sites are using GUPIs or not - all that matters is that you 
have unique addresses for your site.  GUPIs shouldn't be thought to
have any special significance to apps, they're just a way to get 
a unique prefix when you don't have stable public Internet connectivity.

The other thing that seems strange about this statement (to me anyway)
is the idea that you use GUPIs for specific purposes or links.
Ideally from my point-of-view you should have as few prefixes as possible
and you should accept traffic for all of those prefixes on each
of your links, and you should use packet filtering rather than prefix
advertisement to control what kind of traffic you accept (and emit).
That way, apps don't have to pick the "right prefix" in order to work.

>                  some may be filtered at the extranet level, for

absolutely.  of course, you can do this with global prefixes also.

>                  come up with an aggregable method for allocating

I don't know about "global routing".  I can certainly imagine paying
an ISP to route my GUPI-addressed traffic to specific locations,
or perhaps throughout its network.  I suppose I can also imagine    
paying my ISP to make arrangements with other ISPs to route my 
GUPI-addressed traffic in their networks.  But I don't understand
how my ISP can guarantee that every network in the world will choose
to accept a reasonable amount of money for routing my GUPIs. 

It certainly seems important that GUPIs not be globally routable without 
a special arrangement.  But I also wonder whether a market for routing 
GUPIs would not degrade Internet service for everyone by inflating the 
sizes of routing tables and increasing convergence times.   I suspect
that some constraints on use of GUPIs are necessary unless there are
technical means of allowing dissimilar prefixes for topologically
close networks to be aggregated for the purpose of routing computations 
and probably advertisements also.

> filtering and split DNS).

I don't think we should try to prevent leakage at any layer above
a routing protocol.  We certainly shouldn't depend on addresses
not leaking.  Sites can implement two-faced DNS if they wish (and
deal with the operational problems that result) but in all cases
app writers need to make sure that their apps do reasonable things 
when given addresses that they cannot reach.

> networks.  The best we can do is try to provide a solution that

right.

Keith

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 26 Nov 2002 10:12:34 -0500

>a unique prefix when you don't have stable public Internet connectivity.

I stand corrected...  I agree with you completely.

>absolutely.  of course, you can do this with global prefixes also.

Definitely.

>    I suspect

Why to the prefixes for topologically close networks need to be
dissimilar.  There is at least one proposal in multi6 for aggregable
provider-independent addressing.  I'm not sure how well it would
work, because I haven't examined it in detail...

>when given addresses that they cannot reach.

Right...  And, given the wide proliferation of filtering and
firewalls, they must already be doing this today.  IPv6 site-locals
add a new twist -- ambiguous addressing.  That's the part I think we
should try to avoid.

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 26 Nov 2002 10:07:10 -0500

>to renumber their network

This assumes some sort of locally-generated GUPI addresses.  There is
also the possibility of externally allocated GUPI addresses.  I don't
think that we've made a decision one way or the other yet, and I don't
think we can/should make a decision between different GUPI address
allocation methods until we have documented what problems we are
trying to solve.

>different packet forwarding boundaries via packet filtering ACLs etc,

Yes.

>within the same instance of a GUPI address space ?

What does this mean?

Let's take two steps back, stop discussing possible solutions for a
moment and discuss the problem statement.  I'd like it to be possible for
an enterprise to:

         - Have resources (i.e nodes or services) that are accessible
                 only to sub-groups within the enterprise (i.e.
                 departments).  Example:  a printer that only marketing
                 is allowed to use.
         - Have resources that are available to the whole enterprise,
                 but that are not accessible outside the enterprise.
                 Example:  An HR benefits website.
         - Have resources that are available on an extranet (between a
                 selected group of enterprises) that are not accessible
                 to all other enterprises.  Example:  A supplier/customer
                 network.
         - Have resources that are globally available, and be able to
                 send global traffic. Example:  Google.

All of these things can be achieved without site-locals, using
provider-allocated global addresses and appropriate configurations of
firewalls, ACLs, route filtering and split DNS.

The key here is to control access/reachability.  IPv6 site-local
addresses (as currently defined) don't significantly help with this
problem, because they only provide one level of "local" addressing
(Would I use them at the department level?  At the enterprise level?),
and their ambiguity prevents them from being nested.  Their ambiguity
also causes numerous other architectural problems and does not,
inherent offer any benefits related to this problem statement.

However, some people have argued that network administrators will
choose to use site-locals at one of these boundaries (probably the
enterprise-wide boundary) in order to achieve ISP independence.  In
other words, they want to make sure that they don't have to renumber
their internal firewalls, ACLs, etc. if they change ISPs and/or
their ISP renumbers.

This is a real issue, and a real benefit of site-local addressing.
However, the ambiguity of site-local addresses causes a lot of
problems in this sort of situation.  Wouldn't it be better, instead,
if people had a way to get provider-independent addresses that were
globally unique?  Enter GUPI addresses...  Addresses that are _just_
like ISP-provided global addresses, except that they belong to the
enterprise and don't need to be changed when you switch ISPs and/or
the ISP renumbers.

Sounds good, but it opens some basic (and related questions):

         - How will these addresses be allocated and/or generated?
         - Will enterprises end up paying their ISPs to route these
                 addresses globally?
                 - If so, we need an aggregable way to allocate/generate
                         these addresses, so that they won't cause
                         explosive growth of the IPv6 core routing tables.
                 - If not, then we can probably just allocate these
                         addresses sequentially and/or randomly.

Also, we need to consider whether there are other addressing-related
problems in enterprise environment.  Are there other needs for
local and/or provider-independent addressing? I don't really know.

Now, I have a second type of problem statement:

For the home environment, it would be nice to be able to ship
nodes that are configured, by default, only to be accessible
locally -- i.e. storage devices or home security systems (I'm
actually not that worried that hackers will use my printer :-)).

Since these devices will be installed and used by fairly
unsophisticated users (like me :-)) who do not want to set-up
firewalls, ACLs and split DNS to protect their resources, it would
be good if there were a way for these addresses to recognize
certain prefixes as inherently "local", and only accept traffic
from nodes with addresses within those prefixes.

Steve Bellovin has proposed a new RA mechanism that would allow some
prefixes to be tagged at "local" (and would even provide multiple
levels of "local"), so that we could get the access control benefits
of local addressing without the need to use overlapping private
addresses.

It might be useful to have a home gateway generate some sort of
addresses (current site-locals, site-locals with random numbers to
make them unique, other types of addresses?) for use on the
local network, and tag those addresses as "local" in RAs.

Would home users want to (or ever be allowed to) pay their ISPs
to globally route their provider-independent addresses?  If so,
we would need a way to assign aggregable addresses.  If not, it
might be sufficient to assign them sequentially and/or randomly.

Are there other problems that NATs solve for the home environment
that we need to find an architecturally sound way to solve in IPv6?
I don't really know.

And, are there any needs for local addressing within ISPs or other
types of provider networks?  If so, what are the needs in those
environments?

It isn't even clear that a single solution will serve for all of
these environments.

But, until we understand what problem we are trying to solve, I think
it is quite premature to argue over the details of what random
number generator it would be best to use...

Margaret

---

From: Margaret Wasserman <[email-masked]>
Date: Tue, 26 Nov 2002 10:38:43 -0500

> > Why do the prefixes for topologically close networks need to be
>I haven't seen that proposal, so I can't comment on it.
>
>but if the routing system can acquire the capability to aggregate
>dissimilar prefixes, then we don't need to worry nearly as much about
>trying to discourage global routing of PI addresses.

True.  Unfortunately, I'm not sure that anyone has figured out a good
way to skin this cat from either end...

Margaret

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 10:34:47 -0500

---

From: Keith Moore <[email-masked]>
Date: Tue, 26 Nov 2002 11:57:13 -0500

> firewalls, ACLs, route filtering and split DNS.

I'm entirely in agreement with the above.  However perhaps even another
step back is in order.

*any* use of addresses for access control is a dubious idea at best.
there are too many internal threats, and too many ways to tunnel
external threats to an 'interior' node.

so I think the purpose of packet and route filtering is not to allow
addresses to be used for access control, but instead to protect the
network itself (say against DoS attacks) and to make it easier
to analyze your network for threats.  for instance, by restricting the 
number of hosts that can receive external traffic from port 80, you
only have to analyze the cgi scripts on those hosts that are authorized.
but you still need to do port scans on your other hosts to make sure that 
they're not running unauthorized web servers.  and you still need to require
good authentication for any resource that is worth protecting.

I'm all for having flexible address filtering, but let's not sell it as
an access control mechanism.

Keith

---

From: Mark Smith <[email-masked]>
Date: 27 Nov 2002 07:39:12 +1100

Hi Margaret,

I agree it is useful to consider the problem we are trying to solve,
however, my understanding has been that we have been trying to solve the
same problem that traditional site-locals were created to solve.

I've generally understood the goals of traditional site-locals were :

1) internal / local / site / friend / entity (take your pick) address
space that was independent of the global address space assigned by the
(one or more) upstream global connectivity provider(s). 

2) no external registration required for this "site local" address
space.

3) communications sessions (eg TCP sessions) using these "site local"
addresses where impervious to global renumbering events.

Traditional site-local addressing (fec0::/48 (:: /10-/48) ) met those
goals.

However, there were some limitations :

1) the "site" name and explanation in the addressing RFC predominantly
implies a geographical scope or size for this address space. While
people on the ML have said that the word "site" in "site-local" doesn't
really have geographical connotations, it is hard to forget the root
English definition of the word. In practical terms, I might build a
network which considers the whole of Australia as a site when using
site-local addressing, which sounds a bit odd.

2) when two entities using site-local addressing attempt to interconnect
or merge their networks there is a good chance of subnet addressing
collision, necessitating some amount of renumbering of parts of one or
the other entities' networks

3) because site-local addressing is duplicated, there is referral
ambiguity once multiple sites are connected together via a single
router. There were also DNS issues (Keith is the expert on this problem
:-) ).

4) any others I've probably forgotten.

5) oops, forgot about people wanting to use site-local to site-local
IPv6 NAT when merging / interconnecting networks, rather than
renumbering site-local prefixes.

Pekka Savola suggested creating near globally unique site local
addressing, by filling the /10 through /48 bits of fec0::/48 with a
pseudo random or near unique number, derived from a hash of certain
values such as MAC addresses or time of day or other reasonable values.

This doesn't seem to be a new idea, Paul Francis proposed the same thing
in the following ietf draft (worth a read, covers a lot of what has been
coming up in emails recently about GUPIs / (near) unique site local
addresses) :

http://www.join.uni-muenster.de/drafts/draft-francis-ipngwg-unique-site-local-00.txt

I've always assumed that the original goals haven't changed, just that
near globally unique site local addressing was a solution which
addressed the traditional site-local limitations.

My discussions and thoughts on things like naming / use etc have really
only been in the context of having a better "site-local" solution.

Are we happy with the existing problem definition, that (near) globally
unique site local addressing is a better solution for than traditional
site-local addressing, or have the recent discussions on near globally
unique site local addressing / GUPIs caused us to inadvertently loose
focus on our problem definition, making it necessary for us to restate
and redefine it ?

Regards,
Mark.

---

From: Pekka Savola <[email-masked]>
Date: Tue, 26 Nov 2002 23:51:53 +0200 (EET)

On 27 Nov 2002, Mark Smith wrote:
[...]
> addressed the traditional site-local limitations.
[...]

This is my assumption as well, and should be remembered when discussing 
these solutions.
 
If we don't try to invent new uses for site-locals, nearly uniques are 
just fine, for all intents and purposes IMO.

But this discussion is pretty much useless until we have a draft about the
problem statement, as it affects which kind of properties are useful.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Michael Thomas <[email-masked]>
Date: Tue, 26 Nov 2002 14:10:31 -0800 (PST)

> problem statement, as it affects which kind of properties are useful.

   I agree with this. I'm having a *real* hard time
   figuring out the set of problems that people
   are claiming could be solved.

       Mike

---

From: Richard Carlson <[email-masked]>
Date: Wed, 27 Nov 2002 09:56:34 -0600

I'm having a lot of trouble understanding what we are trying to accomplish 
with this email discussion.  From my, probably simplistic, view we are 
missing a fundamental construct of IPv6 addresses.  That construct is that 
v6 address have some kind of scope attached to them.  That scope is meant 
to limit how far they can reach or where they can be used.  Am I 
understanding the v6 address architecture correctly?

I think we all agree that there are Link Local (LL) addresses which can 
only be used for communications between nodes on a single link, i.e., 
completely non-routable.

There are also Global addresses which provide a globally unique IPv6 
address to an Internet node.  These addresses may be routed anywhere on the 
global Internet.  Note: administrative filtering and address blocking may 
prevent Internet nodes from establishing an end-to-end connection.

In between these 2 extremes (LL and Global) there is a range of other 
scopes.  Margaret pointed out some of these including different divisions 
in a single organization or manufacture/supplier relationships.  The Site 
Local (SL) address was suppose to enable these types of relationships.

The talk of GUPI addresses doesn't seem to capture this limited scope 
function.  Am I missing something?

 From my perspective the base address document should make this idea of 
multiple scopes very clear.

We certainly have a good handle on what a global address should do, and the 
LL addresses are also well defined.  The trouble is that we never had SL's 
before and the concept of a 'site' is ambiguous so its hard to figure out 
what to do with them.   Since we don't have any operational experience with 
these limited scope addresses, we should leave the documentation of them to 
the future when this experience is gained.

Rich

------------------------------------

Richard A. Carlson                              e-mail: [email-masked]
Network Research Section                        phone:  (630) 252-7289
Argonne National Laboratory                     fax:    (630) 252-4021
9700 Cass Ave. S.
Argonne,  IL 60439

---

From: Keith Moore <[email-masked]>
Date: Wed, 27 Nov 2002 12:18:22 -0500

> understanding the v6 address architecture correctly?

Perhaps.  But what we're finding is that while scopes might be necessary
for corner cases (e.g. LL is certainly useful for configuration purposes), 
it's a bad idea to expect everything (hosts, apps, routing)
to have to deal with them.   And there's also a limit to which it's a good
idea to wire notions of scope into the addressing architecture, and reserve
even more address blocks for scopes that have dubious utility for the future.

Just as wiring in notions of "class" into IPv4 turned out to be a limitation,
wiring in more notions of "scope" into IPv6 might also turn out to be a 
limitation.

> Local (SL) address was suppose to enable these types of relationships.

That's not my understanding of the intent of SLs, and at any rate SLs 
as currently specified don't work well for this case - there are too
many constraints and assumptions attached to them.

> function.  Am I missing something?

Limited scope is a bad idea for anything that's going to be used outside
of an isolated environment.

> what to do with them.   

It's worse than that.  a- there are *conflicting* assumptions about what to do
with them.  b- SLs are a major pain for applications that have to span scope
bounaries.

But let's not rehash that discussion again.  It's in the list archives.

Keith