> > for LL as currently defined, ambiguity is part of the > > equation. another kind of address might provide a way to > > resolve that ambiguity. > > There is nothing about the address type the creates ambiguity. These > addresses are not meant to be used off of the current link. That means not > forwarding packets containing them to other links (including in the content > part). Since the routers will only see the headers, it becomes the > application's responsibility to keep them on-link. If the application can't > do that it simply can't put them in packets.
All well and good, until someone starts saying that it's okay to expect apps to use v4LL addresses. > > networks are designed to support apps. it's not as if apps > > can tolerate arbitrary amounts of delay, loss, jitter, etc. > > providing sane addressing is just another aspect of good > > network design. > > Networks and applications are designed to allow people to accomplish tasks. > Sometimes the network designs are focused on very specific tasks and the > applications needed to accomplish them. The fact that other apps are run on > that same network is an artifact of the flexibility of IP. Trying to require > the network to be designed to optimally support the other apps is not > realistic. Trying to require apps to run on arbitrary networks isn't realistic either. If you understand that you're building a network to support a very specific set of apps, you can cut corners, but then you're responsible for whatever you create. it's not IETF's job to specify how that network operates or the constraints for apps running on that network. it's IETF's job to specify how a general purpose network operates, and how apps need to behave if they expect to function on general purpose networks. > > > Expecting the network to be globally > > > accessable and flat is not reality. > > > > the network has never been flat in reality, but part of the > > purpose of IP has always been to provide the illusion of a > > flat network. > > That would be the purpose of the illusionary session layer ... uh, no. that's what layer 3 is for. you have heard of routing? > > we're also a long way from any time when it > > could be expected that every host in the network could access > > any other host in the network, but nobody's asking for that > > now (and I wish you'd stop claiming that people were). > > 'networks are designed to support apps. ' appears to be demanding that the > network provide global accessibility. certainly not what I had in mind. of course if the network administratively prevents the app from communicating, you don't expect the app to work. but then the responsibility is (or should be) clear. > > ... > > yes, it can - because it's a slippery slope from saying > > "here's a hint" to "it's okay to do this". and the hints > > aren't of much use to the apps > > For the apps you care about, maybe, but that does not represent all apps. the apps that work with LL anyway don't need the hints. the apps that can't work with LL could use the hints to avoid using those addresses, but the existence of those hints doesn't help if those apps are expected to work with LL addresses. it's not the existence of v6 LL addresses that causes the problems, it's the idea that they're suitable for general purpose use. > > unless it's to say "it's okay to ignore these addresses". > > what you're arguing is that it's > > not okay for apps to ignore these addresses - and that makes > > the hints irrelevant. > > It is not ok to ignore them, but it is ok to use the hint in prioritizing. > Some apps will want to prioritize them high while others like your favorites > will want to prioritize them low. prioritizing doesn't make the app work. it just changes when and how the failures are detected. > Refusing to allow them to be used only > ensures that app doesn't work without explicit manual intervention. nobody has suggested refusing to allow them to be used - what is at issue here is whether it's okay to mislead people. -------------------------------------------------------------------- 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] --------------------------------------------------------------------
