"Michel Py" <[EMAIL PROTECTED]> wrote:
|I support the idea that a _subnet_ should not have both site-local and
|global addresses, not a site. Please also read what I posted earlier
|concerning deprecation.
Could you clarify this position?
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.
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?
|> In this situation, why/how would "Router B" ever route any
|> packets? The control device(s) will only have site-local
|> addresses, so they can't send packets that will be routed
|> by "Router B", nor can any systems to left of Router B
|> (outside the site?) send packets to the control devices...
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.
I think that a number of constraints on site-local addresses are being bandied
about without much thought as to their impact. Any one of these constraints
probably makes site-locals useless for the purposes originally promised. Given
subject of these messages I suppose that could be the idea, but it's going to
cause a lot of confusion...
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]
--------------------------------------------------------------------
