Keith Moore wrote:
Even then, there will still be cases where the right thing to do
is to talk directly to a locator. And there will also be lots
of apps for which a locator is good enough that probably
shoudn't be made dependent on the mapping service.
Agree.
So I lean towards a view
On Wed, 22 Jan 2003 03:34:19 +0100 (CET)
Erik Nordmark [EMAIL PROTECTED] wrote:
] Granted that this is a hard problem, but we seem to be spending emails
] on multiple subsets of this problem (in different WGs) thus I think it
] would be worth-while to concentrate thinking on the
sorry about that; I replied to an ancient message. for some reason my
mail server had this one marked as unread even though it was read
a long time ago.
Keith
On Tue, 15 Jul 2003 19:23:35 -0400
Keith Moore [EMAIL PROTECTED] wrote:
] On Wed, 22 Jan 2003 03:34:19 +0100 (CET)
] Erik Nordmark
On Wed, Jan 22, 2003 at 03:34:19 +0100, Erik Nordmark wrote:
Granted that this is a hard problem, but we seem to be spending emails
on multiple subsets of this problem (in different WGs) thus I think it
would be worth-while to concentrate thinking on the identifier/locator
separation
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
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
From: Keith Moore [EMAIL PROTECTED]
Subject: Re: Taking two steps back (Was: Re: one question...)
Date: Tue, 26 Nov 2002 15:29:52 -0500
The lack of global routability of site-local addresses is a
feature, not a bug.
I don't think we have concensus on that. there seem to be at least
2) There seems to be a need for a globally unique version of Site Local
addresses (GUSL), so we should just define a new block for them.
These would require registration, and perhaps a fee, just like when
you get a domain name.
I think it's still up in the air as to whether these
From: Keith Moore [EMAIL PROTECTED]
Subject: Re: Taking two steps back (Was: Re: one question...)
Date: Mon, 02 Dec 2002 10:48:43 -0500
2) There seems to be a need for a globally unique version of Site Local
addresses (GUSL), so we should just define a new block for them
From: David Borman [EMAIL PROTECTED]
IPv4 has globally routable GUPI (GRUPI) addresses. That's all it had
in the early days. The explosion in the size of the routing tables is
was forced changes such as CIDR and new addresses being allocated from
ISP blocks. The only reason we still have
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
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
On Tue, 2002-11-26 at 18:06, Keith Moore wrote:
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.
Your right. I have been assuming that external = public Internet.
But I have also
Hi Mark,
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
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
Hi Margaret,
On Tue, 2002-11-26 at 23:47, Margaret Wasserman wrote:
Hi Mark,
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
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
Hi Keith,
On Wed, 2002-11-27 at 00:21, Keith Moore wrote:
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
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
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
This assumes some sort of locally-generated GUPI addresses. There is
also the possibility
Mark,
Mark Smith
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
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
- GUPI addresses may also be used to communicate over
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
Why do 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...
I haven't seen that proposal, so I can't
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.
Why to the prefixes for
Margaret,
Margaret Wasserman wrote:
- 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
Margaret,
- How will these addresses be allocated and/or generated?
Charlie Perkins has proposed a perfectly good way.
- Will enterprises end up paying their ISPs to route these
addresses globally?
They will try if there is a chance it works.
- If so, we need an aggregable way to
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)
Hi Michel,
I agree with the assessment, time to be realistic in what could reach
consensus.
Since all we've had so far is a discussion between a few people
during a vacation week for many in the U.S., I think it would be
premature to try to claim any sort of consensus.
I would personally
On Wed, 2002-11-27 at 02:54, Michel Py wrote:
Mark,
Mark Smith
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
On 27 Nov 2002, Mark Smith wrote:
[...]
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) :
Pekka Savola writes:
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.
I agree with this. I'm having a *real* hard time
figuring out the set of problems that people
are claiming could be
Mohan,
Mohan Parthasarathy wrote:
I am just trying to understand this part. From what I
can understand, the relative stability of the GUPI
addresses with respect to global addresses is higher.
Is that the sole reason why you would pay an ISP to
route these prefixes instead of getting a
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
Mark Smith wrote:
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,
I think yes, but only if we address the unreachability /
not-publicly-routable issue at the same time.
The one thing that won't fly is to pervert the use of FEC0::/10 for
globally routable purposes. It is not why IANA allocated that prefix. It
would be simpler to ask for a new prefix, when time has come.
I agree that FEC0::/10 should not be used for this purpose.
Michel Py wrote:
The lack of global routability of site-local addresses
is a feature, not a bug.
Keith Moore wrote:
I don't think we have concensus on that.
There is a DS in the queue, because it has reached consensus. This is
part of the IPv6 architecture. What lacks consensus is to change
Michel Py wrote:
The lack of global routability of site-local addresses
is a feature, not a bug.
Keith Moore wrote:
I don't think we have concensus on that.
There is a DS in the queue, because it has reached consensus. This is
part of the IPv6 architecture. What lacks consensus is
Michel Py writes:
There is no relation. What we are trying to do here is to remove the
ambiguity of site-local addresses, not to create globally routable PI.
These are different topics.
This is not entirely clear. There seems to be a
fair amount of cake-and-eat-it-too going on here
when
Keith,
The lack of global routability of site-local addresses is a
feature,
not a bug.
I don't think we have concensus on that. there seem to be at
least a few people who want PI addresses that *are*
routable, or at least, for which such restrictions are not imposed.
I am just
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
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
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
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
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
45 matches
Mail list logo
