Dan, This is quite a good commentary. What you say is exactly what will happen too in the commercial deployment of IPv6 (as opposed to AD, research, and non fully supported product where the vendor states you can use this in your production network).
But I have heard this TCP long lived connection discussion for a long time. Lets discuss. But first anyone who believes they have the right to keep telnet up 24 hours a day across global networks is sadly mistaken and that's just crazy and lets evil security bad people really get to test their skill out. I know of a user who has to have long lived TCP connections in mission critical situation and wants to do it with IPv6. I have advised them to NOT use SLs. Here is why. The user implementation will have user internal routers across the site (properly defined). But people in the site will and must have access out of the site and that is why we have that problem long discussed here in reality from a few users. That is critical for IPv6 to solve right now. Margaret's proposal solves that problem and will save lives IMO with IPv6. But TCP because we have sites and not multiple links connected using global addresses I don't believe provides any more guarantee or robustness for a long lived TCP connection on a site. Simply because the only reason it will break the site TCP is an error in the network administration, router going down (then we get into dual rail but lets not go there for now), or the cosmos sends a lighting bolt into the core router of the site. So SLs buy a site TCP long lived connections nothing I can see over global addresses. The only place that is not true is a link. And for that we do have link-local. So I still do not see the value of SLs even for long lived connections. The way to solve long lived connections and this is even more hairy than SLs and that is by dynamically reconfiguring the two nodes to use different addresses and vendor customized True High Availability for TCP and SCTP (I believe SCTP is better now just like IPv6 is better than IPv4 but needs more testing and trial networks). So I am not clear your argument of long lived connections is an argument for SLs? It is an argument for other work I believe to be important. /jim [Have you ever seen the rain coming down on a sunny day] > -----Original Message----- > From: Dan Lanciani [mailto:ipng-incoming@;danlan.com] > Sent: Monday, October 28, 2002 3:52 PM > To: [EMAIL PROTECTED] > Subject: RE: Limiting the Use of Site-Local > > > I think it's great the folks are starting to consider the > difficult problems associated with site-local addresses in > particular and scoped addresses in general. In the past > these have been glossed over with hand-waving arguments that > scopes would ``just work'' with minimal application > involvement and a little DNS magic. > > Before you try to solve the problems by effectively reducing > scopes to a degenerate case of one and restricting site-local > addresses to sites with no global addresses (or even with no > external connectivity), please keep in mind that site-local > addresses have been offered up as the solution to a number of > other problems which themselves were difficult to hand-wave > away. For example, the ability to have long-term tcp > connections within a site in the face of global address > renumbering has--given the lack of any protocol or > application support for that renumbering--been pushed onto > site-local addressing. (The problem is hardly confined to > tcp, but that's the usual example cited.) > > Any language that reduces site-local addresses to > second-class citizens (or, worse, implies that they should > not be used concurrent with global addresses) will give stack > and application vendors an excuse to fail to support such > configurations. I don't think you want to open such a huge > can of worms as it will entail revisiting every problem that > has been ``resolved'' with an admonition to simply use > site-local addresses. > > Dan Lanciani > ddl@danlan.*com > -------------------------------------------------------------------- > 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] > -------------------------------------------------------------------- > -------------------------------------------------------------------- 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] --------------------------------------------------------------------
