"sasson, shuki" <[EMAIL PROTECTED]> wrote:
|Hi all, indeed scoping is a pain... specifically since it is not carried as
|a part of the address.
|In any case we should give an escape path out of this ambiguity to a "known"
|world.
|Meaning if a node is configured with a global addresses the global addresses
|will have higher priority being used as a source address over SL.
That's certainly not the behavior I would want. If I go to the trouble of
configuring my systems with stable site-local addresses I want to use those
addresses where possible so as to be independent of the renumbering whims of
my ISP.
Margaret Wasserman <[EMAIL PROTECTED]> wrote:
|What do stack and application vendors need to do to support site-local
|addressing?
A more relevant question might be, ``what do stack and application vendors
have to do to support multiple concurrent addressing scopes including global
and site-local?'' If you are suggesting that the answer is that they don't
have to do anything special then why do you feel the need to restrict site-
local address usage?
|And what makes you think that they are doing those things now?
Did I say that I thought they were doing those things now? I'm not even
convinced that an IPv6 application market exists yet. When and if such
a market exists I would prefer that the products support some notion of
stable local addresses. Currently site-local addresses--and the associated
hack that is scopes--serve this purpose. Without such support the only
alternative will be NAT.
|The majority of stack and application implementations with which I am
|familiar make no distinction at all between site-local address and
|globals.
So are you saying that essentially nobody deals with scopes in a useful way?
That's unfortunate, but it isn't too late to improve the situation.
|This is appropriate if site-locals will be used only on non-globally
|connected sites (so, effectively, site-local == global).
This eliminates the problem by eliminating site-local addresses as a unique
scope. That in turn pretty much gets rid of scopes since link-local was
already a special case that most higher-level code doesn't care about. I've
always been in favor of global addresses and I would happily trade stable
site-locals for stable globals. Where can I get some? Note that if we are
talking about globally unique non-routable addresses it may not eliminate
the need for scopes. But it's certainly a step in the right direction.
"Michel Py" <[EMAIL PROTECTED]> wrote:
|Now, explain me how you design that network (the plane) with deprecating
|site-locals when global addresses are present. Modern plane designs are
|multiple redundant networks that carry data for almost all of the
|plane's devices.
Presumably you are supposed to get a global address for the rudder controller
and hope that the FAA implements a no-renumbering-in-flight rule. The rest
of us with less critical applications will probably just have to make do with
unstable addresses.
The thing that bothers me about this discussion is that it is starting to
sound as if site-local addressing (and all the endless debate about scope and
address selection rules) was just another sham like transparent renumbering.
Until a few days ago site-local addresses (along with the scope baggage they
entail) were a part of the IPv6 vision. Now suddenly they are a minor wart
to be eliminated, and all roads seem to lead back to the situation where the
stability (and cost) of your internal network is directly dependent on your
ISP. This in turn will almost certainly result in the introduction of IPv6
NAT and we will be right back where we started.
Margaret Wasserman <[EMAIL PROTECTED]> wrote:
|Seriously, we have an opportunity, with the introduction of
|IPv6, to advocate new ways of doing things on the new
|network.
|
|Just because people have been doing something one (bad) way
|in the past, doesn't mean that we should advocate that
|approach in IPv6.
Wow. I think I used almost exactly those words a few years back in a futile
argument for global portable identifiers. But you seem to be advocating
constraining v6's addressing to work just as v4's does. How is that new?
One of the (IMHO, very few) benefits of the v6 addressing architecture is
that scoped site-local addresses allow some of the desirable functionality
of NAT and private addressing to integrate smoothly. I'm not saying that
this was a good tradeoff. I would have preferred to see work on the routing
problem so that everybody could have their own stable routable addresses. But
that would have upset the status quo a bit too much and we got scopes instead.
The bottom line is that by hand-waving arguments scoped addressing was declared
feasible while routing portable addresses was declared impossible. The bed has
been made and now we have to lie in it...
"Bound, Jim" <[EMAIL PROTECTED]> wrote:
|Dan,
|
|This is quite a good commentary. What you say is exactly what will
|happen too in the commercial deployment of IPv6 (as opposed to AD,
|research, and non fully supported product where the vendor states you
|can use this in your production network).
|
|But I have heard this TCP long lived connection discussion for a long
|time. Lets discuss.
The address stability issue goes way beyond persistent tcp connections. It
has been discussed extensively in the past. I'm not interested in trying to
falsely reduce the entire issue to a single straw man which can be conveniently
dismissed as unimportant (or tabled until some great new protocol solves the
problem).
|But first anyone who believes they have the right
|to keep telnet up 24 hours a day across global networks is sadly
|mistaken and that's just crazy and lets evil security bad people really
|get to test their skill out.
Security by short-lived connections? I hope this is a joke...
|I know of a user who has to have long lived TCP connections in mission
|critical situation and wants to do it with IPv6. I have advised them to
|NOT use SLs. Here is why. The user implementation will have user
|internal routers across the site (properly defined).
|But people in the site will and must have access out of the site and
|that is why we have that problem long discussed here in reality from a
|few users.
How is this ``why''?
|That is critical for IPv6 to solve right now. Margaret's
|proposal solves that problem and will save lives IMO with IPv6.
Save lives? Aren't you exaggerating a bit? It may save jobs at ISPs since
they will have more revenue from charging for all the addresses that could
have been site-locals... and more control from making it harder to switch
providers... but only until v6 NAT takes off...
|But TCP because we have sites and not multiple links connected using
|global addresses I don't believe provides any more guarantee or
|robustness for a long lived TCP connection on a site. Simply because
|the only reason it will break the site TCP is an error in the network
|administration, router going down (then we get into dual rail but lets
|not go there for now), or the cosmos sends a lighting bolt into the core
|router of the site. So SLs buy a site TCP long lived connections
|nothing I can see over global addresses. The only place that is not
|true is a link. And for that we do have link-local. So I still do not
|see the value of SLs even for long lived connections.
I'm afraid you are missing the point. The internal structure of a site
network is under the control of that site. The administration can make
the network as reliable as their needs require, even provisioning completely
redundant cores to survive that lightning bolt. Contrary to what some people
seem to believe, some entities use their networks for more than just making
connections to the outside world from web browser clients. The stability of
their internal network is important to their business or even to their (or
our) safety. Margaret's proposal forces such sites to depend on the stability
of their ISP just because they want global connectivity. Such an absurdity
will not stand in the market. Under these rules we *will* have v6 NAT in no
time.
|The way to solve long lived connections and this is even more hairy than
|SLs and that is by dynamically reconfiguring the two nodes to use
|different addresses and vendor customized True High Availability for TCP
|and SCTP (I believe SCTP is better now just like IPv6 is better than
|IPv4 but needs more testing and trial networks).
There is always a different/better solution just around the corner. Soon we
will have transparent renumbering and recoverable tcp. I've been hearing this
for years. It's a fantasy. There are many deep dependencies on stable
identifiers at all levels. Networks are going to need stable addresses for the
foreseeable future. ISPs may believe that they can extract arbitrary fees for
providing those stable addresses, but it isn't going to happen.
|So I am not clear your argument of long lived connections is an argument
|for SLs?
That isn't my argument. My argument would be for portable routable addresses
or identifiers, but I lost. The arguments for site-local addressing were made
years ago. It isn't clear why they have all been forgotten.
|It is an argument for other work I believe to be important.
Sure, implement my portable identifier protocol and all the problems will go
away. Or allow portable routable addresses. The hardware has gotten a lot
faster and memory has gotten a lot cheaper. Or solve the renumbering and
address allocation problems without the former. But whatever you do, do
it FIRST and then come back so we can discuss removing the last vestige of
supported end-user-controlled address space.
Keith Moore <[EMAIL PROTECTED]> wrote:
|first, I don't buy that provider-based addresses are inherently that much
|of a burden.
They seem to be enough of a burden to cause NAT to flourish, though.
|and it's far easier to solve the renumbering problem (particularly
|for special-purpose devices) than to solve the SL addressibility problem.
So we are coming full circle? We have the renumbering problem because the
portable address/identifier problem was declared by fiat to be too hard to
even think about solving. We are stuck with site-local addressing because
the renumbering problem turned out to be too difficult to solve in practice.
I've noticed an unfortunate trend towards the following kind of argument: ``X
is bad, unaesthetic, and hard. I don't like x. The world will be much better
if we eliminate x now and replace its functionality with y at some point in
the future. Y is easier, cleaner, and more aesthetic. As soon as someone
manages to implement y everybody will see this. I don't have an implementation
of y right now, of course. But it will happen.'' Site-locals are already at
least a third-order compromise. You aren't even proposing a new "y"...
If you think that the renumbering problem is easy solve, can I make a suggestion
similar to the ones I received when I proposed portable identifiers? Go make it
work. Bring back a few sample implementations that demonstrate transparent
renumbering. Write it up. Get the necessary changes made in whatever standards
are affected. With renumbering solved I think you will see less resistance to
elimination of site-locals, though there is still the address cost issue. Now
in my opinion, renumbering is a very hard problem to solve--much harder than
either portable identifiers or scope propagation. (At least, renumbering is
hard to solve if you don't introduce a level of indirection that is equivalent
to portable identifiers.) But I'd be happy to be proven wrong.
|second, I don't buy that we're stuck with provider-based addresses anyway.
Can you expand on this? If you know a way to get unstuck from provider-based
addresses I'd love to hear about it. With a mechanism for end users to own
portable routable global addresses the need for site-locals would be greatly
reduced. But if you are just talking about a hypothetical future utopia then
it is unreasonable to use this as a reason to deprecate site-locals. The ipv4
address aggregation hack was supposed to be a temporary stopgap until the
hardware caught up. The hardware caught up a long time ago. You still can't
get portable v4 address space in any reasonable way. I see no reason to believe
that v6 addresses will fair any better.
If you are talking about non-routable global addresses then this is a step
in the right direction, but it isn't clear that it removes the need to deal
with scopes and DNS hacks.
If you are talking about 6to4 space then you have found an illusory solution.
|third, I don't buy that every company wants to set up its own infrastructure
|to network to remote devices when they can take bids from competing providers
|who already have infrastructure - or even use a mixture of providers.
|(for instance, you can combine wired, wireless, satellite depending on
|where your devices are)
Do you buy that most companies want to set up their own infrastructure to
network to *local* devices without depending on their ISP? Should access
to my local network printer really depend on an address assignment from my
ISP? Even for remote devices accessed via third-party infrastructure the
increased use of VPNs may well mean that those remote devices will have
addresses local to the the owner.
|fourth, I don't buy that the existence of provider-based addresses is a
|compelling reason to burden us with SLs.
See #1.
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 PROTECTED]
--------------------------------------------------------------------
