"Michel Py" <[EMAIL PROTECTED]> wrote:
|> Dan Lanciani wrote:
|> Let's say I have an Ethernet segment with 20 workstations
|> and 5 printers. I determine that two of the workstations
|> need access to the Internet so I rent 2 global addresses
|> from my ISP. Are you saying that at this point for all
|> the workstations to continue using the printers I have to
|> either:
|> 1. Rent an additional 23 global addresses from my ISP
|> making the entire subnet global -or-
|> 2. Interpose a router between the 2 globally connected
|> workstations and the remaining 18 workstations plus 5
|> printers, forcing the 2 globally connected workstations
|> to use their global addresses to talk to site-locals on
|> the printers (thus making such connections depend on the
|> ISP). In order to change which workstations have global
|> access I would have to move them between subnets.
|
|Either one.
So your position is that I must do one of those two rather than using
site-local addresses on the one segment along with the two globals? I
believe that this restriction renders site-locals useless for many
applications. I would be forced to opt for NAT.
|I don't see what your problem is with 1, because the
|smallest you can get is a /64 anyway, which is enough for more printers
|and workstations than you will ever have.
There seems to be a persistent notion that ISPs are going to change their
business models just because the IP header version field increases by 2.
I don't buy it. Show me proof.
|The problem you have with 2 is that you want PI, like everyone else,
|which is quite another animal.
Huh? The problem I have with #2 is that it requires me to add a router
and further requires me to rewire (even if only virtually with VLANs)
just to shift who has global access. It has absolutely nothing to do
with provider-independent routable address space.
|> Or are you saying that site-local and global addresses
|> should not appear in packets on the same subnet at all
|> (rather than as addresses of a single machine on a
|> subnet) in which case only #1 would work?
|
|I don't see the difference?
There is a huge difference. If you ban packets with global addresses from
your site-local subnet then the site-local machines (obviously) can't talk
to globally-connected machines via their global addresses. In my example,
this makes #2 impossible.
|Subnet is a poor choice of words, let's say
|vlan, or Ethernet segment instead, sorry about the confusion.
No confusion, that's the subnet I thought you meant.
|> I believe Margaret is implying a restriction here that
|> connections cannot be made between a site-local address
|> and a global address. That would invalidate solution #2 above.
|
|There is no such restriction.
There's no restriction on having site-locals and globals on one subnet
either, but we seem to be talking about adopting one or more of these
restrictions.
|I'm afraid the design that allows both a public and a site-local on the
|same host (or at least on the same interface) is going to be scrapped
|and here are the reasons:
|1. The developers are whining about it.
That isn't clear.
|2. From an enterprise perspective, it's a draw. Yes it does save router
|ports
It also provides stable, local addresses even to machines that require global
access. Which is where I came in...
|but the other side of this coin is that administering several
|address ranges on the same vlan is an administrative overhead
Any particular administration is free to not take advantage of site-locals
and thus not incur this overhead.
|and
|nullifies most of the perks of site-locals in terms of security.
Any particular administration is free to not configure globals and site-locals
on the same interface if it believes that there is a security issue.
|So, it's a tosser on the network admin side; if it was without
|consequences I would have elected to keep it, but if the developers want
|to scrap it, so be it as far as I'm concerned.
I cannot support your position. This restricted version of site-locals
may have some marginal security benefit, but it fails to deliver on the
original promise of flexible scoping. It will just cause confusion for
administrators who will think they can control their address allocations...
until they actually try to do it. If it comes down to a choice between
crippled site-locals and no site-locals I am forced to vote for no site-locals.
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]
--------------------------------------------------------------------
