Iljitsch van Beijnum wrote: > On 19-sep-2007, at 0:10, Keith Moore wrote: > >> What bugs me is that I think that the existence of mini-cores (or more >> generally, a large number of private interconnections between networks >> using ULA prefixes) leads to a world where it becomes important to have >> a particular kind of source address to talk to a particular kind of >> destination address, and in which applications are expected to choose >> the right source address in order to talk to a particular kind of >> destination address. So the sources addresses available to a particular >> host end up being like a keyring. I don't think that's a good burden to >> put on apps, and I don't think that using addresses like authentication >> tokens is a good way to go. > > I don't think having a large set of source addresses with different > reachability is a good thing, but it's likely unavoidable to have > several. > > If applications don't want to worry about addressing issues, the only > solution is that applications don't get to see addresses in the first > place. If you can find a good way to let hosts and network stacks sort out those addressing issues, then fewer applications will bother to manage those addresses themselves. But absent such a way to do that (and trial-and-error is not a good way, nor is IPv6 "address selection") then more applications will be forced to manage those addresses in order to provide decent service to users. Or to put it another way, as long as an application can provide better service by explicitly managing addresses than one that doesn't explicitly manage addresses, there will be incentives for apps to explicitly manage addresses and many apps will do so. There's a whole separate issue in that networks trying to do filtering on the basis of source and/or destination address hides policy from applications. So the application doesn't know whether it is violating policy or routing around a failure of the network. And realistically, the answer is probably different for different applications. Keith _______________________________________________ Ietf@xxxxxxxx https://www1.ietf.org/mailman/listinfo/ietf