> Keith Moore wrote:
> > ...
> > > Lets use the
> > > following example:
> > > | |
> > > A -|-- B --|- C
> > > | |
> > > SL | SL&G | Global
> > >
> > > What Keith is asking for is that B should be able to tell C
> > about the SL
> > > for A because A doesn't have a global address.
> >
> > B has no way of knowing whether or not there is a route from A to C.
>
> In this example B knows the scopes don't match.
so what? the fact that A used a limited-scope address to talk to B
doesn't doesn't tell B anything about whether A and C can communicate
directly. B knows nothing, absolutely nothing, about the network
connectivity between A and C and there's absolutely no way B can
make *any* inferences about connectivity by looking at any set
of A's and C's addresses. furthermore, there's nothing that any
address selection rule can do to change this situation.
> > But if there *is* a route from A to C, then there needs to be a an
> > address for A that B can give to C, even if A is not connected to the
> > public Internet.
>
> This is where we fundamentally disagree. If A is not connected to the
> public Internet, there is no 'NEED' for B to be able to tell C about it.
that's insane. what you're saying is that we don't need to care about
whether applications can interoperate if their hosts aren't all connected
to the public internet. the bottom line is that people need apps that
work even when all of their hosts aren't connected to the public internet,
and the burden is going to be on apps to make this work whether you
think it's reasonable or not. our only choice is to decide whether
we're going to force those apps to be less reliable by burdening them
with ambiguous addresses.
> The number of places where by intent a node is disconnected from the
> public Internet, yet might be able to interact with nodes on the public
> Internet and not in its local routing domain, is so small that it is
> both not worth solving, and creates more confusion than solutions.
try again. there are lots of private enterprise networks today
that are interconnected by NATs whether or not there is any connection
(via a NAT) to the public Internet, and there are lots of apps that
have to run on spaces where public and private networks overlap -
essentially every enterprise network today has apps that run in an
environment like this. are you saying you're going to make it as
difficult (or worse) for those apps to use v6 as v4+NAT? I don't think
that's a viable option.
> > > If the argument is that the network for B could leak the
> > > routes for A into the SP for C;
> > > 1) is the site policy for A being violated by advertising it?
> >
> > there's no way for the app to know the site policy, so it's a
> > moot question.
>
> Then why is it passing around addresses?
you may as well ask why DNS passes around addresses. DNS isn't
aware of the policy either, and even though 2-faced DNS attempts
to limit exposure of addresses that aren't usable there's no way
the DNS server can know who gets those addresses and whether
they're authorized to talk to ports on those hosts. bottom line is
just because you get an address from DNS or anywhere else doesn't
mean for certain that you can actually send traffic to it.
> > > 4) how does the app on B know that A has a route to C, particularly
> > > since it knows it doesn't have a global address for A?
> >
> > A's SL might or might not be valid for C.
>
> This only happens when NAT is involved.
NO, Tony. It's possible for A and C to be in different sites,
even though B can talk to both of them. It's also possible for
them to be in the same site, even though B has a SL address for
one and a global addres for the other.
> > There's no presumption that B is routing traffic from A to C. Rather
> > B is an app that is forced to live in a world where it is trying to
> > communicate with multiple peers, or maybe even coordinate activities
> > among multiple peers, where some of its peers are connected to the
> > public Internet and some are not. B cannot be expected to have any
> > idea which peers can talk to which other peers, or for that matter,
> > which peers' addresses are valid in which other peers'
> > addressing realms,
> > because we've forced apps to deal with ambiguous addresses.
>
> Globally unique addresses don't solve any of these issues.
globally unique addresses are not a complete solution - there is no
complete solution. but they minimize the potential for some errors
and make it easier to quickly detect other conditions that prevent
an address pair from being used, and thus make it easier for
applications to recover quickly from those conditions. e.g. it's much
better to get an ICMP unreachable when trying to send to an address
than to have to wait for a timeout.
> I agree that
> unambiguous addresses in the context of routability is required. In the
> example, B knows the scopes don't match, so without route leaking it
> knows the two sides can't see each other.
no it doesn't because B has no way of knowing whether it has *all*
of the addresses for both A and C, and nothing can be inferred from
the fact that A chose a SL address for B and C chose a global address
for B. especially when different connections (sometimes even within
the same app) have different needs that quite reasonably affect
address selection, and when network connectivity can vary from one
time to the next and at different places in the network at the same time.
> > At least if we make it possible for everyone to have
> > unambiguous addresses
> > then we can plausibly impose the contraint on apps that they
> > should only
> > use unambiguous addresses in referrals. B still won't be able to tell
> > whether A and C can communicate directly, but at least it can
> > give C an
> > address for A which is unambiguous, and which allows C to
> > *quickly* determine
> > whether it can talk to A.
>
> The time it takes to determine reachability is the same, and global
> uniqueness will not change that.
I don't think so. with an unambiguous/global address the router knows
whether or not it has a route to the destination, and can issue an
unreachable ICMP immediately if this is not the case. with an ambiguous
address there may be a need to do routing (in the case of SL) and ND
for a host that might not even be at that site, and the only indication
that you can't reach that host is an ND timeout, which might or might
not result in an ICMP message being sent back across routers after the
timeout has expired. (often we don't get them in IPv4, so I don't
expect we'll get them in IPv6 either...)
of course if the destination is down you'll get the timeout in any case,
but we assume that's a rare situation. the difference is that when trying
to use SLs from a remote network you'll have to wait for a timeout
anytime you're using a nonlocal SL - and the timeout tells the sender
*no* information about whether the host is up or down. how often this
happens is highly dependent on how your network is interconnected with
others' and where your apps live relative to that topology.
> >
> > > Global uniqueness in the SL space
> > > doesn't solve any of the above problems.
> >
> > forget about SL space for the moment because it's confusing the issue.
> > if you give A a globally unique address, then C can make some
> > sense of it.
> > if you force A to have an ambiguous address, then C can't
> > tell whether
> > A is unreachable, or whether A's address is simply not valid.
>
> and the practical difference is?
response time, overall reliability, and the effort/complexity that apps
need to expend in trying to deal with multiple addresses, detecting errors,
and recovering from errors.
> > the notion of "SL context" is a network-centric view. apps don't have
> > any idea about such contexts.
>
> and rather than figure out how to give them such knowledge you are
> arguing to remove the mechanism.
even asuming you can resonably teach apps about network topology
(going against 20+ years of internet architecture), please explain
how you are going to teach apps about network topology without giving
them any way to determine which addresses are in which part of the
network. it simply can't be done. you can beat your head against
the wall as long as you want, but you won't get anywhere except
a bruised head. this is what the NAT/RSIP/MIDCOM people have been
trying to do and it's basically accomplished zilch except to serve as
a demonstration on how utterly fruitless and futile that line of
investigation is.
> There is no requirement that any app
> use SL, just as there is no requirement for a network manager to
> announce them. If an app wanted to stay within the bounds of the local
> routing administration, restricting itself to SL would be the first step
> to accomplishing that.
an app could restrict itself to SL, or it could restrict itself to
not using SL. but users that try to use SL are going to wonder
why they have to force their apps to live in one world or another.
what this basically means is that SL has very limited utility,
and that we need a mechanism that allows sites to have globally
unique addresses whether or not they're connected to the public
Internet. And once we have the better mechanism then SL should
probably be discouraged so that apps don't have the burden of
dealing with them. that doesn't mean that we have to try to eradicate
SL from the face of the Earth, but it's certainly not clear why
we should bother to support SL and the complexity that comes with
it if we can solve the same problem via simpler and more reliable means.
> > apps and hosts have to cope with
> > overlapping network contexts and interfaces on multiple networks that
> > are in different contexts. app cannot be expected to stay
> > within some
> > invisible network context; actually quite often apps are expected to
> > work across such boundaries.
>
> All of the administratively created boundaries are there explicitly to
> prevent apps from working across them.
perhaps, but the boundaries aren't as clean as you want to pretend. the
fact that B can talk to both A and C does not mean that direct
communication between A and C is permitted. nor would the inability
of either A or C to talk to B mean that communicaiton between A and C
were forbidden. the only way to know if there's a boundary between
A and C is for one of them to try to talk to the other.
> If we remove NAT from the set by
> moving to IPv6, we are left with the case where some administrator has
> decided that apps should not arbitrarily work, but you are insisting on
> making that possible despite the administrator.
No. if the administrator doesn't want A and C to talk to each
other then the administrator sets up a filter that blocks traffic
between A and C (it could be either at A or at C or in between). the
administrator doesn't necessarily tell B about it, B might not even been
in that administrator's control, and there's no way for B to know that
such a filter exists from looking at information it has about A and C.
> If an address is ambiguous outside its realm of routability, who cares?
not being on the public internet is not the same thing as "outside the
realm of routability".
> Either the routing system has a unique entry for the node, so all the
> participants can get there, or the address is outside this realm of
> routability, and they wouldn't get there even if the address is unique.
No. The routing system is not monolithic, routing policy domains
and addressing domains can overlap, and hosts may exist in multiple
domains or at the intersection of multiple domains. It's not as if all
of the interconnections between a set of communicating hosts are either
permitted or forbidden at the same time.
> > wrong. B has no idea whether A's SL address is valid for C.
> > it might be obvious from looking at the drawing that C cannot use
> > the SL address for A, but it's not obvious to B from the information
> > available to it.
>
> B knows that it only has a global for C and a SL for A, so it can't
> refer one to the other with any hope that the connection will actually
> work.
basically true, but B has no way of knowing whether this will work even
if both A and C have SLs, or if both A and C have globals. the best
B can do under any circumstances is to say "A, here is the set of
addresses I have for C" (or "C, here is the set of addresses I
have for A") and let A (or C) sort it out as best it can. B cannot
make a reliable decision on A or C's behalf as to whether they can
connect or, if there are multiple addresses, which address is the one
to use.
> As long as there is no NAT in the path, there is no way that routing
> would work if the SL for A, B, & C are from different realms.
that's simply incorrect. any of A, B and C can exist in multiple realms,
and B doesn't know which realms A and C (or for that matter B) are in.
> Assuming
> we add the ability for local management of site-ids, if A & C have a
> private connection the prefix A tells B would have to be the same as the
> one it tells C,
so given that multiple prefixes are available to A and C, how are A and C
going to arrange to choose the same prefix when talking to B?
don't say that they should use the same address selection algorithm,
after all they may have different needs, or their current network
connectivity at the time they each started talking to B might have
been different.
> or routing within A would fail to deliver the packets.
> At the same time, there is no reason that the disconnected sites of Q,
> R, & S couldn't use the same set of site-ids.
presuming that {Q R S } and {A B C} always stayed disjoint, which is
a difficult condition to enforce. here's the question - given that
there could well be a good reason for such private networks to merge
(e.g. say that company Q merged with company A) do you really want to
force NATv6s on them? or massive renumbering of all of the sites
involved, even those not involved in the merger?
ambiguous addresses are just a nightmare.
> > > Since this is the problem for the disconnected site, the requirement
> > > needs to be that an app never passes around mixed scope addresses.
> >
> > I don't know what a "mixed scope" address is.
>
> Not clearly stated... an app should not pass around an address set
> unless all the scopes match.
that's a truly bizarre idea. nobody would adhere to such a rule
unless (maybe) we made it easy for all hosts to have global addresses.
and the rule wouldn't solve the problem anyway. you're trying to
get apps to enforce arbitrary restrictions on interconnection which
are not dictated by site policies, and which would actually prevent
many kinds of distributed apps from serving their purposes.
what is a proxy, after all, if not an app component that lives in
the intersection of policy domains that mediates communication
between peers in those various domains? are you going to say that
proxies can't exist because you're refusing to allow them to
mediate between apps that choose different addressing scopes?
> > The requirement should be that every network can get globally-unique
> > addresses for each of its hosts, and that it's free to interconnect
> > using those addresses with any other network that will agree
> > to connect
> > to it.
>
> That is a nice idea, and if we had a mechanism for PI addresses this
> would be possible. Help promote the need for PI, and stop trying to turn
> SL into PI. There is a need for both.
As I've said before, I'm all for having PI addresses. I don't personally
care whether SL is the mechanism or there is some other mechanism,
as long as we get PI addresses that sites can use to interconnect
between themselves. I don't even care if they're aggregatable
(though others might).
On the other hand, if we have PI addresses, I'm unconvinced of the need
for SLs in that case. Perhaps someone can cite a use case for SLs
that would not be met by PIs. Until I see that use case then my
presumption is that we'd be better off with PIs and without SLs.
> > That way, every host and app that needs one can get a globally
> > unique address, and apps can then be discouraged from using ambiguous
> > addresses. It doesn't mean that every app can route traffic to
> > any other potential peer that it knows about, but that's a given.
>
> There are apps that don't want arbitrary global accessability, and this
> requirement would force them to have it anyway.
No. Nothing stops an app from refusing any connection (or ignoring
any input) it wants to refuse (ignore), and nothing stops a site from
blocking traffic on any source/dest pair it wants.
Keith
--------------------------------------------------------------------
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 PROTECTED]
--------------------------------------------------------------------
