Keith Moore wrote: > > I think restricting site-local addresses to sites without > ANY external > > connection is wrong. > > I think expecting applications to cope with a mixture of > site-local and global addresses is not only wrong, but > unworkable, unless all nodes are also guaranteed to have > globals and the site-local > addresses can safely be ignored.
It is clear that some application developers will have to decide if they want to bother with the new capabilities provided by simultaneous support for multiple scopes. That does not mean it is wrong for anyone to use them. As an example (yes hypothetical, but could easily describe the requirements or goals of the vast majority of the fortune 1000); Company X has 125,000 employees globally, with regular reorganizations causing constant office shuffles between regions. Each employee has a laptop, which will have global access, and a network connected printer which will not have global access (we won't bother with the rest of the network connected devices here). There are 100 touch-points to the Internet, with the 3 primary ones running multiple OC-48 access loops. The 'explicit filter lists at the border' model requires keeping 100 tables in sync in the face of constant change, and parsing a 125,000 entry list at OC-48 rates for every packet at 3 of the borders (while this creates demand for very expensive routers, it is not a scalable approach). The 'well-known SL filter at the border' model requires the organization to tell their printer manufacturer to preconfigure all the devices they buy to only accept and auto-configure SL prefixes from the RA (likely a widely demanded item), and put in a 2 entry list that remains static at every border. In addition, it is reasonable and expected that the peer across the border will maintain a matching version of the filter list. The compromise model of 'using 2 public prefixes per segment' allows for a 2 entry static list at every border, which may or may not be considered reasonable to match by the border peer. It does not provide the printer manufacturer a preconfiguration option that matches other customers, and even if it was done, as soon as Company X changes providers, they have to manually touch every printer for the new configuration. It also consumes 2x the public prefix space, to support nodes that will never be accessible from the public network. To make the name service simple in these 3 cases, we will run back-to-back normal dns servers. The primary set facing internally to accommodate dynamic updates, with a slave set facing externally. A periodic process will replicate the information from the source-of-truth internal facing servers to the external ones, but the security team requires it to scrub out all records for internal-only nodes. For model 1, the scrubbing process would have to contact the border filter list (after deciding which was the current source of truth), the parse through it for all 250,000 entries to decide which are replicated. For model 2, the scrubbing process simply has to look for records with the SL prefix and replicate all others. For model 3, the scrubbing process has to look for the bit flag that identifies the private-use public prefix, and replicate all others. Once any one of these processes completes, all nodes are accessable by name in the internal scope, and all nodes that should be accessed from the outside are accessable by name in the global scope. Applications that are expected to *work* across the border will have global scope addresses to use. Multi-party apps that use name-string referals will work across the border, but those that use SL literals will fail by design (note: use of SL == expected to fail across border). Use of filtered global scope addresses makes it impossible for the application to know why it failed to connect. This scenario only addresses 2 devices per employee, so the numbers could easily be 5x this large. Approaches that work in the small, rarely scale well to large distributed environments with constant churn. Another side-effect of choosing SL over global scope prefixes is the simplification of diagnostic efforts for communications within the site. It makes little sense to use RFC 3041 IID's within the boundaries of a site, and avoiding them makes it easier for the support team to correlate network traces. It is reasonable to expect OS vendors to prevent binding a 3041 IID to the SL prefix without explicit configuration. In turn, it would require explicit configuration of every device to recognize the 'private' nodes (either private-use public prefix, or the entire border filter list) to avoid use of a 3041 IID when talking to those nodes. > > > It results in excluding many large network with > > permanent external connection, that currently have deployed > > "site-local-like" addresses and aim at continuing doing so, > because of > > the "advantages" it provides. > > no, it just results in those networks having to use slightly > different security measures for IPv6 than they used for IPv4. The tone of that statement makes it a non-starter as far as the security teams are concerned. The point has to be that the security measures start from exactly the same point they are in IPv4, but with simultaneous use of SL & global prefixes we have the opportunity to expand the functionality of the network by allowing some nodes to avoid the need for nat. The absolute requirement for filtering will trump any complaints about broken applications, which means there will be site-scope address space. If we don't provide an opportunity to move beyond the current model where all nodes are required to live in the single scope of filtered space, by providing simultaneous support for site/global space, we will be stuck with nat forever. Tony > > Keith > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
