Christian Huitema wrote: > ... > Bad, bad application developers. We should really punish them! :-)
Recognizing the smile, punishment was not my point. What many are missing here is that the perspective of a single address scope does not, and will not match the reality of the deployed network. > > Seriously, application developers face some very real > problems. The issues are uniqueness in space and uniqueness in time. > > The space dimension is experienced when a host is connected > to several sites, e.g. home network and VPN. If the > application receives a site local address from a local name > service or a local discovery service, it must associate that > address with a site identifier. The first stumbling block is > that most applications don't have this concept, they just > copy the address. > > The second stumbling block is that there are no readily > available site identifiers -- you would need to manage a > unique name space, which is precisely what you don't get from > FFC0::/10. In the absence of site identifier, the routing of > connections to the proper site is haphazard. The application > is supposed to remember that the site local address was > learned through a specific site, i.e. only use in site X the > site local addresses learned from site X's DNS service. This > become quickly very hairy, as the DNS does not in fact have a > concept of site. > > Restricting hosts to handle exactly one site removes some of > the problem. But you then bump into the time dimension. Hosts > may become members of different sites at different times, > e.g. a laptop moving from the office to the airport or to the > home. Addresses learned in one site should not be used in the > next, but for that you must have an easy way to tell that you > have changed sites. Without a site identifier, that can be real hard. > > Tony, these problems are not theoretical. They come very much > on top of the issues encountered by developers porting > applications to IPv6. I have never argued that the problems are theoretical, just that it is unreasonable for applications to blindly pass addresses outside the context where they make sense. The problems you list do raise the bar for application developers, but they are solvable. The other unreasonable point is insisting that the one-time/app cost of a developer dealing with complexity is more expensive than the continual operational costs for the network manager when the complexity is pushed there. > > Using unambiguous addresses solves a lot of the problems: a > multi homed site can route connections to the proper site, > source address selection can work, and moves to another site > can be detected. There are remaining issues, notably dealing > with intermittent connectivity, but these issues are inherent > to any mobility scenario. I agree, but we need to provide the alternatives first. Deprecating SL without providing alternatives for all the requirements will lead us to reinstating them when one of the requirements can't be met. Tony -------------------------------------------------------------------- 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] --------------------------------------------------------------------
