Dan, > 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. 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. The problem you have with 2 is that you want PI, like everyone else, which is quite another animal. > 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? Subnet is a poor choice of words, let's say vlan, or Ethernet segment instead, sorry about the confusion. > 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. 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. 2. From an enterprise perspective, it's a draw. Yes it does save router ports but the other side of this coin is that administering several address ranges on the same vlan is an administrative overhead and nullifies most of the perks of site-locals in terms of security. 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 believe this would be fine with many, as I can't recall >> anybody that supported site-locals doing it for the >> site-locals themselves but for what they provide, see below. > It's more a matter of supporting scoping and address selection > rules for what they provide. It doesn't matter what you call > the local addresses. OTOH, I'd rather have a block of private addresses without scoping than SLs with scoping that does not work. If the developers don't want or can't deliver scoping with SL, I need a backup plan and since there appears to be some momentum for it I'll take it. Of course, this would lead to networks that are using non-scoped private addresses, but the one thing network administrators do not like is uncertainty. That being said, my choice is still to keep SLs and scoping, but let me make sure that everyone understands that I do not design a network with promises, I design a network with what I have tested to be working. As of today the only thing I have to design a network that requires private addresses is a prefix hijack that obviously is not scoped, since there is some uncertainty in what would be available as far as SLs are concerned. In this light, a private /32 clearly labeled as not publicly routable would be an enhancement. Michel. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
