Keith, On 2008-02-19 20:02, Keith Moore wrote: > I hate to rain on the parade, but... > >>> 1. ULAs will give enterprises the addressing autonomy that they >>> seek (as RFC 1918 addresses do with IPv4) >> >> Correct. That's available today. >> >>> ; but that 2. Enterprises will NOT need to use NAT to make those >>> ULAs globally reachable (instead using work going on in RRG). >> >> No. When a client system wants to go outside the corporate network, >> it will need to use a second address that belongs to a globally >> routable prefix. > > I still find the notion of "client system", as representative of > anything typical for a computer on a network, to be very dubious. > General purpose computers tend to function as clients for some > protocols, servers for others, and for some protocols they may assume > both roles. Especially in this day of widespread p2p and otherwise > multiparty apps, it should not be assumed that an ordinary general > purpose computer only functions as a client...not even when > communicating with external hosts. Nevertheless, in the context of enterprise networks that I was addressing, they are perceived and managed as clients, and the successful p2p solutions deal with the fact that they have temporary addresses, get rebooted, and are hidden behind middleboxes. So I'm sticking to my assertion that long-term address stability just isn't an issue for desktop and laptop systems. (NAT is an issue, because it breaks sessions.) > I also think it's asking a lot to expect hosts or apps to know when they > need to use a particular address or kind of address...though it might be > reasonable for there to be a small number of special cases for critical, > inherently local apps (if any such apps actually exist). I agree that asking for anything significantly beyond RFC 3484 would be a stretch. But I don't think we need to. > >> But there's no reason to care about whether that address has a >> particularly long lifetime, so it really doesn't matter whether it's >> from PI or PA space or whether it will change next time you reboot the >> client. > > The application certainly has reason to care about the lifetime of an > address that it chooses or that is chosen on its behalf...even if that > application is only, for the moment, functioning as a client. My point is that this is a solved problem in practice. Probably not solved in the way you or I would like, but solved nevertheless. Brian _______________________________________________ Ietf@xxxxxxxx http://www.ietf.org/mailman/listinfo/ietf