Keith Moore wrote: > > > ... > > > mainly I want a solution to the problem. apps need to be > able to do > > > address referrals and right now the algorithm for selecting > > > which address > > > to use is little better than a guess. anything we can do to > > > make this > > > faster or more reliable is a good thing, and SLs with > > > site-ids are better > > > for this than SLs without site-ids. > > > > I don't agree with the stated requirement. While I agree > that apps need > > a way to do referrals, what says that has to be done using addresses > > rather than name strings? > > first we would need a naming system that is fast and reliable.
and referrals of addresses trades off reliability for a little speed. As you note here, some DNS servers are two faced, so how does referring addresses actually work in that case? The referring node would have to know the entire topology including the DNS server boundaries to be able to send the right addresses (if it could even get a complete list). It would be much simpler for the app to send the name string and let the receiver find the traget address list from its own topological perspective. > > > Clearly referrals using IPv4 addresses can't > > work today, so any app that needs to do a referral will > have to use a > > name. > > no they won't. clearly you live in a fantasy land where DNS > always works > perfectly and lookups take only microseconds. in the real world, DNS > fails to provide the correct answer a significant part of the time and > lookups often take 10 seconds or more. So apps should pass around a potnetially bogus list of addresses? I am all for multi-party apps, but fixing the real problem with DNS seems like a better approach than a hack that will end up failing anyway. > > > What about IPv6 changes that? > > nothing about IPv6 changes that, except that IPv6 has the built-in > expectation that an app may have to deal wth multiple addresses and > somehow choose one of those addresses without any knowledge as > which ones are more likely to work than others. > > and you think *I'm* in a fantasy land. trying to build complex topological information directly into the app will fail more often than not. Pass name strings and follow draft-ietf-ipv6-default-addr-select-08.txt. It will not be as fast, but it will be more reliable. > > > Is it simply to save the receiver of > > the referral from having to resolve an address? If so that > is a bogus > > application design, > > who made you the arbitrer of good application design? who are you to > dismiss applications' real requirements for low latency and > high reliability? > > > because the referrer can't know that it has all the > > possible addresses for the target. > > the referrer can never be sure that it has all of the > possible addresses > for a target, no matter where they were obtained. DNS isn't the sole > authority on such things, and even DNS is sometimes two-faced. > > > In short you are looking to optimize the wrong part of the > > system > > I'm trying to make IPv6 a viable alternative for apps that don't work > well under IPv4+NAT. Part of the problem in doing so is that > the address > selection burden imposed by IPv6 is very similar to problems you get > when trying to make distributed apps work with NAT. > > > and the resulting application failures will leave it no better > > than it is in an IPv4/NAT world. > > that, indeed, is my concern. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
