Citerat fr�n Tony Hain <[EMAIL PROTECTED]>:
> No, I am using a well established construct of limiting access by
> restricting where prefixes get routed, and limiting access by filtering
> on
> header bit patterns. That is not overloading on the IP address any more
> than
> current practice does.
Limiting access based on restricting where prefixes gets routed does not
require a standards based scoped range of addresses. This can be done with any
addresses. Therefore something called "site locals" are not required to
continue to use prefix route filtering.
> Then why do network managers every have limitations on routing
> announcements, both sent and heard? It is because they want to limit
> access.
Do not confuse limit access (1) = prevent hacking, DoS attacks with limit
access (2) = not provide a service.
Filtering on routes sent is commonplace to ensure that the route receiver gets
a proper picture of the world and does not try to use the network to access
things they shouldn't (transit for example).
Filtering on routes received is commonplace to ensure that the next guy doesn't
swamp your routingtable becasue somebody down the line screwed things up. Don't
trust anybody elses routing.
Neither of these requires anything called "site locals". Both describe the
primary use of route filtering. If somebody thereby also gains a bit of extra
security because the next guy doesn't know about a certain prefix, fine. Site
locals would add nothing here.
(1) is done with firewalls, packet filters, encrypted communications, secured
operating systems and other such measures way before route-filtering.
> > > Restricted routing is just one component in a comprehensive
> > security
> > > plan.
> >
> > Since it doesn't really do the job,
>
> What job? Provide perfect security? If that is the case, what does the
> job
> today? If such a product exists, why is route filtering so prevalent?
Among who? You continue to talk about consumers and how things would be easier
for them with site-locals. No consumers are using route filtering today. No
consumers will need to use route filtering.
ISPs use route filtering. People with corporate networks use route filtering.
But they do it for the other reasones (see above), not for security. Thus "site
locals" add nothing new.
> The network is not the simple Internet of 1990, and extrapolating that
> growth forward says we must not be architecting in bottlenecks.
> Particularly
> when they are simply based on favored operational practice of a few
> large
> entities. The consumer doesn't want to know about the technology that
> makes
> the Wal-mart appliance work, they just want to bring it home and turn it
> on.
Site-locals will not make consumer products any cheaper, easier or better. On
the contrary, site locals will make them more complex, less interoperable and
as a consequence more expensive to the consumer because he has to buy more of
them to make things work!
Just look at NAT. How many different ways have been invented to go around NAT,
to make applications work through NAT and to take advantage of things that are
readily accepted through NAT and firewalls ("Lets run Protocol A over HTTP
because it gets through everywhere...") just to avoid having to do a REAL
solution?
That is application developer creativity working for you on network layer
problems. And you want more of that??
--------------------------------------------------------------------
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]
--------------------------------------------------------------------
