> This suggestion leads to the model where hosts with multiple > interfaces will assume that all its interfaces are in the > same site (e.g. have the same site-local zone id) unless > explicitly configured to have multiple sites. While routers > will default to having a unique site-local zone id for each > interface (thus rendering SLs to link-local behavior) unless > explicitly configured to have multiple interfaces in the > same site. > > This difference in behavior for hosts and routers leads to > some interesting issues. One big one is how the site-local > zone ids are setup and potentially changed when a host > becomes a router or vice versa. > > What are others' opinions on this issue?
The correct default really depends on the intended use of the node. Having interfaces default to being in different site-local scope zones makes sense for specialized boxes whose purpose is to be a site boundary router, like a home gateway router which has a WAN interface and one or more LAN interfaces. For these types of specialized nodes, it probably makes sense to default the WAN interface to one site-local scope zone and the LAN interface(s) to a separate site-local scope zone. The same type of logic could be applied to nodes which act as firewalls, where the "public" interfaces are in one site-local scope zone and the "private" intranet interfaces are in a different site-local scope zone. In this case, other configuration information can be used to derive the default site-local scope zones for the firewall's interfaces. For a typical host or router, though, a better default would be to have all interfaces in the same site-local scope zone. This is more consistent with what is shipping today. Indeed, many of the routers which ship today are not capable of being configured as a site boundary router, much less default to that behavior. Keep in mind that vast majority of hosts also support IP forwarding (although it may not be enabled by default), so this effectively says these hosts must be capable of being multi-sited. And I don't think we have a good enough grasp on what the impacts are to support multi-sited hosts. Not to mention the problem Brian raises above on having different defaults based on whether a node is a host or a router - the site-local scope zone IDs will change as IP forwarding is enabled or disabled. Since the scope zone ID is part of the sockaddr structure and is needed to identify the remote partner when using non-global addresses, this could (and very well may) result in loss of connectivity for active connections. Assuming that the use of site-local addresses is not restricted to sites which are not connected to the global internet or other sites (which is my preference), what I'd like to see is this (or another) WG define exactly what support is needed to make this work. This includes standards to define what a site boundary router needs to implement, including updates to routing protocols and the forwarding logic as defined in the scoped addressing architecture. It should also include a BCP which defines application impacts associated with using site-local addresses in these environments and gives guidance on how to work around the problems. For hosts, we should indicate that the current standards only specify how a single-sited host should behave, and multi-sited host support is undefined pending possible future standards work. But lets stop trying to define the default site-local scope zone configuration for hosts and routers. If a router can act as a site boundary router, the router vendor can decide the appropriate default configuration for their product, and whether certain interfaces should be in the same site-local scope zone or in different site-local scope zones by default. Roy -------------------------------------------------------------------- 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] --------------------------------------------------------------------
