Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On 2007-10-12 16:27, Jun-ichiro itojun Hagino wrote: On 2007-10-11 23:46, Jun-ichiro itojun Hagino wrote: Not viewed from the socket programmer's point of view. Look at how an AF_INET6 socket behaves when given an address like :::192.0.2.3 afaik the behavior is then exactly what you describe. Whether the stacks are independent code modules or alternate paths through the same code is irrelevant to the externally observed behavior. see draft-ietf-v6ops-security-overview-06.txt section 2.2. Sure. I absolutely don't like to see ::/96 on the wire. then we'd have to deprecate SIIT at least. still, you cannot be sure that :::0:0/96 are not on the wire. I agree, it just isn't obvious that such packets will be delivered... Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On Oct 12, 2007, at 8:13 AM, Keith Moore wrote: there's precious little time left to do that Umm, Keith, we're *already* 'out' (in some sense) of IPv4 space, and have been for a decade or more. Given that addresses are still available for the time being, I'm not sure what sense you mean there. The only thing that's about to change is that the cost of v4 addresses will go up slightly. The black market in addresses is now inevitable. As demand climbs, more people with assigned addresses will switch to NAT and put their prefixes on the market, providing the 'supply' side of the equation. This situation will persist, with the 'demand' side slowly driving prices up. Only when v6 becomes sufficiently attractive will it begin to be possible to deploy v6 only sites and reduce demand. So, until both content providers and 'eyeballs' see some obvious and compelling advantage to deploying v6, we have a game of chicken, which no one will win. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Noel Chiappa wrote: > > From: Keith Moore <[EMAIL PROTECTED]> > > >> Wouldn't it make more sense to put the effort into morphing v6 into > >> something that *IS* attractive? > > > there's precious little time left to do that > > Umm, Keith, we're *already* 'out' (in some sense) of IPv4 space, and have > been for a decade or more. > Given that addresses are still available for the time being, I'm not sure what sense you mean there. (of course, without NAT we would have reached this point years ago.) > Why do you think there are all those blasted NAT boxes out there? > Different reasons. A big one is because the commodity IPv4 connection is a /32, and it turns out that lots of customers have reason to hook up more than one host. Another one is that pretty much everyone uses Windows, which has a long history of (deliberately introduced) insecurity, and people have been duped into thinking that private networks and NATs offer substantial protection. Groupthink is also a big factor, I suspect. People bought NATs because their friends did. Also, NATs spread at a time when most widely-used Internet apps were client-server. > So the future just holds a *different* kind of 'running out of > IPv4'addresses, which, when it happens, the world will deal with in what > seems at the time to be the most cost-effective way of dealing with the > problem, even if it's ugly (q.v. NAT) > Why do you believe that the world chooses the most cost-effective solution?As far as I can tell the market mostly engages in hill-climbing, which rarely produces an optimal result. Now if instead you had said people would do whatever seemed to be easiest, without much regard to the long-term cost, I'd probably agree with you. Maybe I should buy stock in application hosting firms that "own" substantial chunks of IPv4 space. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> From: Keith Moore <[EMAIL PROTECTED]> >> Wouldn't it make more sense to put the effort into morphing v6 into >> something that *IS* attractive? > there's precious little time left to do that Umm, Keith, we're *already* 'out' (in some sense) of IPv4 space, and have been for a decade or more. Why do you think there are all those blasted NAT boxes out there? So the future just holds a *different* kind of 'running out of IPv4' addresses, which, when it happens, the world will deal with in what seems at the time to be the most cost-effective way of dealing with the problem, even if it's ugly (q.v. NAT). Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> The IPv4 clock will wind down right after the last FORTRAN compiler is > decomissioned. Wouldn't it make more sense to put the effort into > morphing v6 into something that *IS* attractive? hope you can do that in time... (i mean, not just for the States but for the entire planet) for me, IPv6 itself is attractive enough (that's why i'm putting so much time on it). if it can lose some of the extra meat which makes it a little bit more complex than it should be, it would be super. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> The IPv4 clock will wind down right after the last FORTRAN compiler is > decomissioned. actually it looks like FORTRAN is going to outlast IPv4 by several years. > Wouldn't it make more sense to put the effort into morphing v6 into > something that *IS* attractive? perhaps, though there's precious little time left to do that, and still a lot of denial to overcome. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On Oct 11, 2007, at 12:46 PM, Brian E Carpenter wrote: I can't possibly disagree with that, but my interest is in getting the implemented code deployed before the IPv4 clock winds down. The IPv4 clock will wind down right after the last FORTRAN compiler is decomissioned. Wouldn't it make more sense to put the effort into morphing v6 into something that *IS* attractive? Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> On 2007-10-11 23:46, Jun-ichiro itojun Hagino wrote: > >> Not viewed from the socket programmer's point of view. > >> Look at how an AF_INET6 socket behaves when given > >> an address like :::192.0.2.3 > >> afaik the behavior is then exactly what you describe. > >> Whether the stacks are independent code modules or > >> alternate paths through the same code is irrelevant > >> to the externally observed behavior. > > > > see draft-ietf-v6ops-security-overview-06.txt section 2.2. > > Sure. I absolutely don't like to see ::/96 on the wire. then we'd have to deprecate SIIT at least. still, you cannot be sure that :::0:0/96 are not on the wire. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Dave, On 2007-10-12 04:07, Dave Crocker wrote: ... The underlying point of my note was: One would think that a 15-year project that was pursued to solve a fundamental Internet limitation but has achieved such poor adoption and use would motivate some worrying about having made some poor decisions. A quick response that says "we talked about that" but says no more seems a little bit facile. Yet your response continues down the path of "What was decided was fine. No, I'm on the path of trying to be precise and accurate about what was decided. Since it's engineering, it isn't perfect. So let's dismiss expressions of concerns about it by citing a previous decision, as if that choice was inevitable." In particular, my point was that a v6-specific API was not immediately required. The approach to IPv6 could have been vastly more incremental, so as to make its adoption vastly less disruptive. But you have to start by considering the benefits of such an approach. Brian, the approach to IPv6 ignored protecting the installed base and ignored finding a way to have the lowest possible barriers to adoption. As 15 years of non-adoption has demonstrated, the value proposition for adopters also was not compelling. To repeat: At some point, it would help to take history as being instructive, rather than to dismiss attempts at considering alternatives. This might not change the situation with IPv6, but it could have an effect on other, future work. I can't possibly disagree with that, but my interest is in getting the implemented code deployed before the IPv4 clock winds down. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On 2007-10-11 23:46, Jun-ichiro itojun Hagino wrote: Not viewed from the socket programmer's point of view. Look at how an AF_INET6 socket behaves when given an address like :::192.0.2.3 afaik the behavior is then exactly what you describe. Whether the stacks are independent code modules or alternate paths through the same code is irrelevant to the externally observed behavior. see draft-ietf-v6ops-security-overview-06.txt section 2.2. Sure. I absolutely don't like to see ::/96 on the wire. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Dave, Reordering your comments slightly.,.. --On Thursday, 11 October, 2007 11:07 -0400 Dave Crocker <[EMAIL PROTECTED]> wrote: > To repeat: At some point, it would help to take history as > being instructive, rather than to dismiss attempts at > considering alternatives. > > This might not change the situation with IPv6, but it could > have an effect on other, future work. It is hard to predict the future. It is almost equally hard to draw firm conclusions from the fairly recent past, especially when drawing those conclusions requires understanding the counterfactual implications of various choices. I agree that history is instructive and should not be ignored, but think we should hesitate to jump to conclusions about what it tells us. > The approach to IPv6 could have been vastly more incremental, > so as to make its adoption vastly less disruptive. But you > have to start by considering the benefits of such an approach. > > Brian, the approach to IPv6 ignored protecting the installed > base and ignored finding a way to have the lowest possible > barriers to adoption. As 15 years of non-adoption has > demonstrated, the value proposition for adopters also was not > compelling. Examining a value proposition requires asking both the question "how hard, expensive, or risky is it for me to do this?" and "how do I benefit if I do?". Larger benefits justify larger investments; a perception of few benefits may not justify even a small investment. From that perspective, even small changes to something that is perceived as working satisfactorily involve risks of bugs and disruption. There is no way to make a change zero-cost and zero-risk. Certainly it is reasonable to hypothesize, as you are doing, that decisions about transition and compatibilities with IPv6 created a bad value proposition by making transition too complicated and costly. But it is equally reasonable to hypothesize that the error lay in our failure to address enough other issues -- to solve enough other problems -- to create real "pull" for making changes, no matter how cheap those changes appeared to be. Would IPv6 have been more successful had the solution addressed fundamental routing issues more directly? If it somehow made small-site multihoming more straightforward and plausible? If it incorporated a solution to the semantic and management issues implied by RFC 3514? If it solved some other real or imagined problem with IP? If we had simultaneously overhauled TCP to support more connection-agile or address-insensitive use of applications? As things have turned out, we've pretty much ended up with "IPv4 with more bits". Selling that one to the community is hard except on the basis of either an anti-NAT campaign or one based on the imminent falling of the sky. The former is made more difficult by the observation that most user organizations do not perceive that they are suffering real harm from NATs (whether that perception is correct or incorrect is irrelevant) and more difficult yet by concerns that IPv6 will not eliminate some of the factors that cause NATs. The latter is made more difficult by too many prior predictions, some unrealistic over-marketing, and an inability to see the sky moving downward and accurately and convincingly anticipate the dire effects of its coming down. Can one demonstrate that, given those factors, an easier transition process would have made a significant difference? Possibly it would have, but I don't think there is any way to be convinced. On the other hand, had IPv6 offered more than what the market seems to see as a mostly-theoretical improvement (elimination of NATs) and avoidance of a future address space catastrophe) -- some obvious advantages to those who who already have deployed IPv4 installations and the address space needed to support them-- would we have seen wider adoption? Again, there is no way to know for sure but, if the answer is "yes", then it is hard to guess how much difference a slightly easier transition would have made. So, let us by all means look at history and try to learn its lessons. But let us also be sure we know what those lessons actually are, rather than using the historical argument to justify a position that may not be supported by the evidence. best, john ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> The underlying point of my note was: > >> One would think that a 15-year project that was pursued to solve a >> fundamental Internet limitation but has achieved such poor adoption >> and use >> would motivate some worrying about having made some poor decisions. A >> quick response that says "we talked about that" but says no more seems a >> little bit facile. > > Yet your response continues down the path of "What was decided was > fine. So let's dismiss expressions of concerns about it by citing a > previous decision, as if that choice was inevitable." In particular, > my point was that a v6-specific API was not immediately required. perhaps not. but without such an API, software would not have been able to migrate. so at the point when people started to actually want to use the extended addresses, the software would not have been there. > To repeat: At some point, it would help to take history as being > instructive, rather than to dismiss attempts at considering alternatives. yes. but it's not instructive to pick apart the solution that was chosen and claim that some other solution would have produced a better result, without applying similar analysis to the alternative. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Brian E Carpenter wrote: No more than having your TCP use selective acks constitutes a 'dual stack', relative to having TCP not use selective acks. While what I suggested isn't that "minor" an enhancement to the stack, neither does it constitute an entirely separate stack. To repeat: Dual stack is entirely separate. Not viewed from the socket programmer's point of view. Look at how an AF_INET6 socket behaves when given an address like :::192.0.2.3 afaik the behavior is then exactly what you describe. Apparently you missed most of the rest of my note, such as: Yes, it is not perfectly compatible. The only way to achieve that is to have purely syntactic differences. Oh. Wait a minute. hat I described -- as a first step for adoption -- would have been a purely syntactic difference, albeit one that set the basis for fixing the only problem that IPv6 was originally asked to solve: bigger address space. Exploiting that basis would have been moved to a strictly administrative step. Prior to exploiting it, interoperability between IPv4 and IPv6 could have been perfect and easy. The underlying point of my note was: One would think that a 15-year project that was pursued to solve a fundamental Internet limitation but has achieved such poor adoption and use would motivate some worrying about having made some poor decisions. A quick response that says "we talked about that" but says no more seems a little bit facile. Yet your response continues down the path of "What was decided was fine. So let's dismiss expressions of concerns about it by citing a previous decision, as if that choice was inevitable." In particular, my point was that a v6-specific API was not immediately required. The approach to IPv6 could have been vastly more incremental, so as to make its adoption vastly less disruptive. But you have to start by considering the benefits of such an approach. Brian, the approach to IPv6 ignored protecting the installed base and ignored finding a way to have the lowest possible barriers to adoption. As 15 years of non-adoption has demonstrated, the value proposition for adopters also was not compelling. To repeat: At some point, it would help to take history as being instructive, rather than to dismiss attempts at considering alternatives. This might not change the situation with IPv6, but it could have an effect on other, future work. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> From: [EMAIL PROTECTED] (Jun-ichiro itojun Hagino) > Cc: ietf@ietf.org > > > Not viewed from the socket programmer's point of view. > > Look at how an AF_INET6 socket behaves when given > > an address like :::192.0.2.3 > > afaik the behavior is then exactly what you describe. > > Whether the stacks are independent code modules or > > alternate paths through the same code is irrelevant > > to the externally observed behavior. > > see draft-ietf-v6ops-security-overview-06.txt section 2.2. My view is that ":::192.0.0.2" totally identical with "192.0.0.2" (internally inside the host stack implementation). There will be no functional difference anywhere in API, whichever form is used. I realize, that the above is not easy to achieve using the legacy POSIX socket API, which has has different sized address structures for IPv4 and IPv6. In Symbian OS, there is no such problem. The generic address structure allocation (TInetAddr) can hold both IPv4 and IPv6 address. Thus, the there is only one IP stack, which just happens to do IPv4, when address is IPv4 (either 192.0.0.2 or :::192.0.0.2"). Real IPv6 addresses trigger IPv6 processing. Logically stack implements *one* "INET family" (PF_INET) with two possible address families "AF_INET" and "AF_INET6". Applications can be written totally agnostic on whether connection is over IPv4 or IPv6. All sockets are just opened as AF_INET, and the addresses used determine whether IPv4 or IPv6 gets used. On listening "undefined address family" can be used to accept both IPv4 and IPv6 for the same socket (TCP or UDP). Receiving ":::127.0.0.1" from network is not going to work as an attack, because of "strong model", and 127.0.0.1 is not configured for the real interface (=> destination 127.0.0.1 does not match configured address and gets dropped). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> Not viewed from the socket programmer's point of view. > Look at how an AF_INET6 socket behaves when given > an address like :::192.0.2.3 > afaik the behavior is then exactly what you describe. > Whether the stacks are independent code modules or > alternate paths through the same code is irrelevant > to the externally observed behavior. see draft-ietf-v6ops-security-overview-06.txt section 2.2. itojun ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On 2007-10-11 03:17, Dave Crocker wrote: Thomas Narten wrote: Dave Crocker <[EMAIL PROTECTED]> writes: 4. The v6 stack would need to have a v4 mode, for use by v4 applications -- applications that use v4 addresses. Um, sounds an awful lot like dual-stack to me. Hosts (that understand It's not. No more than having your TCP use selective acks constitutes a 'dual stack', relative to having TCP not use selective acks. While what I suggested isn't that "minor" an enhancement to the stack, neither does it constitute an entirely separate stack. To repeat: Dual stack is entirely separate. Not viewed from the socket programmer's point of view. Look at how an AF_INET6 socket behaves when given an address like :::192.0.2.3 afaik the behavior is then exactly what you describe. Whether the stacks are independent code modules or alternate paths through the same code is irrelevant to the externally observed behavior. Brian That's the approach that was chosen. IPv6 is an incompatible protocol module, compared with IPv4. Independent addressing. Independent interfacing. Independent management. What I described was a compatible upgrade. Very different beast. Yes, it is not perfectly compatible. The only way to achieve that is to have purely syntactic differences. Oh. Wait a minute. hat I described -- as a first step for adoption -- would have been a purely syntactic difference, albeit one that set the basis for fixing the only problem that IPv6 was originally asked to solve: bigger address space. Exploiting that basis would have been moved to a strictly administrative step. Prior to exploiting it, interoperability between IPv4 and IPv6 could have been perfect and easy. But it would have had the feature of being adopted as no more than a software upgrade (and availability of syntax-translating routers.) IPv6) also must be able to originate and receive either IPv4 packets or the bigger IPv6 ones. Sure, the details may be somewhat different, but fundamentally, we have dual stack, with IPv6 nodes needing to support IPv4 for backwards compatability. And what I described was an approach that would have permitted a "pure" IPv6 host, where interaction with an IPv4 host required a syntax-translating relay of some sort. This approach does not prohibit having a host implement both formats, but what is fundamental is that it does not require it. This is in marked contrast with what we have now, needing a much hairier different translating relay, independent address administration and, really, independent operations and management. V6 is an independent network from V4. And in the network, routers have to understand both the original IPv4 format, plus the new IPv6 format. Yes, anything looking at a format must understand it. If IPv4 traffic is mixed with IPv6 traffic, then yes the routers need to understand both. The difference in what I described is that networks that do only one of the formats would nonetheless be part of a unified global service. What we instead have is that we have two separate services. Separate addressing, separate management. Very much larger barrier to adoption. (For reference, I am being so painfully redundant in making my points, here, because it seems to be necessary.) If there was a magic "trivial" transition/upgrade strategy, we would have done it years ago. You must have been participating in different discussions than I was. If one looks at the style of discussion now, what we see is an effort to dismiss criticisms and alternatives, rather than counter them seriously. This is what took place back then, too. Timely deadlines were dismissed. Simplicity was dismissed. Integration was dismissed. The ones that I was around suffered from a classic second-system syndrome of a) lack of pressure to delivery a timely solution, b) feature creep, c) lack of concern for interoperability. Brian's reference to a history that discussed this, and other, alternatives entirely ignores the differences between "discussing" and "taking seriously". That is, what he does not do is explain why a simpler approach was rejected. One would think that a 15-year project that was pursued to solve a fundamental Internet limitation but has achieved such poor adoption and use would motivate some worrying about having made some poor decisions. A quick response that says "we talked about that" but says no more seems a little bit facile. d/ ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> To repeat: Dual stack is entirely separate. > > That's the approach that was chosen. IPv6 is an incompatible protocol > module, compared with IPv4. Independent addressing. Independent > interfacing. Independent management. > > What I described was a compatible upgrade. Very different beast. > > Yes, it is not perfectly compatible. The only way to achieve that is > to have purely syntactic differences. > > Oh. Wait a minute. hat I described -- as a first step for adoption > -- would have been a purely syntactic difference, albeit one that set > the basis for fixing the only problem that IPv6 was originally asked > to solve: bigger address space. > > Exploiting that basis would have been moved to a strictly > administrative step. Prior to exploiting it, interoperability between > IPv4 and IPv6 could have been perfect and easy. > > But it would have had the feature of being adopted as no more than a > software upgrade (and availability of syntax-translating routers.) You make it sound like a trivial step, but it's not. That "no more than a software upgrade" is fairly equivalent to the effort required to upgrade IPv4 software to IPv6 today (different APIs, different DNS records, updated apps, and difficulties for p2p apps) and I'll note that after 15 years that effort is still not complete (especially for software that isn't bundled with operating systems). And "the availability of syntax-translating routers" can't necessarily be assumed either, particularly not if there would have been a need to draw firm borders between legacy IPv4 and enhanced IPv4 enclaves. (though perhaps NATs would have evolved in that direction). >> IPv6) also must be able to originate and receive either IPv4 packets >> or the bigger IPv6 ones. Sure, the details may be somewhat different, >> but fundamentally, we have dual stack, with IPv6 nodes needing to >> support IPv4 for backwards compatability. > > And what I described was an approach that would have permitted a > "pure" IPv6 host, where interaction with an IPv4 host required a > syntax-translating relay of some sort. As you probably remember, the "syntax-translating relay" approach at the boundary of different mail enclaves (ASCII-only vs. 8-bit transparent, ASCII headers vs. UTF-8 headers) has been discussed several times and generally rejected in favor of per-message negotiation, mostly because of that difficulty of drawing a clean boundary between enclaves (and also the difficulty of having flag days during which an entire enclave upgrades). Offhand I'm not sure why IP networks would find this kind of operation any easier. > This approach does not prohibit having a host implement both formats, > but what is fundamental is that it does not require it. This is in > marked contrast with what we have now, needing a much hairier > different translating relay, independent address administration and, > really, independent operations and management. V6 is an independent > network from V4. Independent address administration, and treating v6 as a separate network from v4, do impose a barrier to adoption. I understand why IPv6 didn't go this way. But I also wonder if the costs of having IPv6 be completely separate were as well-understood as the advantages. I think too many people assumed that everyone would independently adopt IPv6 in the absence of any immediate advantage to doing so, and also that the barriers to "adopting IPv6" looked far simpler in the mid-1990s than they are today. >> And in the network, routers have to understand both the original IPv4 >> format, plus the new IPv6 format. > > Yes, anything looking at a format must understand it. If IPv4 traffic > is mixed with IPv6 traffic, then yes the routers need to understand both. > > The difference in what I described is that networks that do only one > of the formats would nonetheless be part of a unified global service. not clear. for instance, would enhanced IPv4 hosts universally be able to reach one another? or would the absence of translating relays in some cases make their connectivity spotty? > (For reference, I am being so painfully redundant in making my points, > here, because it seems to be necessary.) The problem might not be that people don't understand what you are saying, but that people don't so readily accept that the alternative would have been as simple and easy as you seem to think. >> If there was a magic "trivial" transition/upgrade strategy, we would >> have done it years ago. > > You must have been participating in different discussions than I was. > If one looks at the style of discussion now, what we see is an effort > to dismiss criticisms and alternatives, rather than counter them > seriously. People may differ on what constitutes a dismissal versus a serious counterargument. > This is what took place back then, too. Timely deadlines were > dismissed. Simplicity was dismissed. Integration was dismissed. That's a bit of an over-simplification. Simplicity was highly
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Thomas Narten wrote: Dave Crocker <[EMAIL PROTECTED]> writes: 4. The v6 stack would need to have a v4 mode, for use by v4 applications -- applications that use v4 addresses. Um, sounds an awful lot like dual-stack to me. Hosts (that understand It's not. No more than having your TCP use selective acks constitutes a 'dual stack', relative to having TCP not use selective acks. While what I suggested isn't that "minor" an enhancement to the stack, neither does it constitute an entirely separate stack. To repeat: Dual stack is entirely separate. That's the approach that was chosen. IPv6 is an incompatible protocol module, compared with IPv4. Independent addressing. Independent interfacing. Independent management. What I described was a compatible upgrade. Very different beast. Yes, it is not perfectly compatible. The only way to achieve that is to have purely syntactic differences. Oh. Wait a minute. hat I described -- as a first step for adoption -- would have been a purely syntactic difference, albeit one that set the basis for fixing the only problem that IPv6 was originally asked to solve: bigger address space. Exploiting that basis would have been moved to a strictly administrative step. Prior to exploiting it, interoperability between IPv4 and IPv6 could have been perfect and easy. But it would have had the feature of being adopted as no more than a software upgrade (and availability of syntax-translating routers.) IPv6) also must be able to originate and receive either IPv4 packets or the bigger IPv6 ones. Sure, the details may be somewhat different, but fundamentally, we have dual stack, with IPv6 nodes needing to support IPv4 for backwards compatability. And what I described was an approach that would have permitted a "pure" IPv6 host, where interaction with an IPv4 host required a syntax-translating relay of some sort. This approach does not prohibit having a host implement both formats, but what is fundamental is that it does not require it. This is in marked contrast with what we have now, needing a much hairier different translating relay, independent address administration and, really, independent operations and management. V6 is an independent network from V4. And in the network, routers have to understand both the original IPv4 format, plus the new IPv6 format. Yes, anything looking at a format must understand it. If IPv4 traffic is mixed with IPv6 traffic, then yes the routers need to understand both. The difference in what I described is that networks that do only one of the formats would nonetheless be part of a unified global service. What we instead have is that we have two separate services. Separate addressing, separate management. Very much larger barrier to adoption. (For reference, I am being so painfully redundant in making my points, here, because it seems to be necessary.) If there was a magic "trivial" transition/upgrade strategy, we would have done it years ago. You must have been participating in different discussions than I was. If one looks at the style of discussion now, what we see is an effort to dismiss criticisms and alternatives, rather than counter them seriously. This is what took place back then, too. Timely deadlines were dismissed. Simplicity was dismissed. Integration was dismissed. The ones that I was around suffered from a classic second-system syndrome of a) lack of pressure to delivery a timely solution, b) feature creep, c) lack of concern for interoperability. Brian's reference to a history that discussed this, and other, alternatives entirely ignores the differences between "discussing" and "taking seriously". That is, what he does not do is explain why a simpler approach was rejected. One would think that a 15-year project that was pursued to solve a fundamental Internet limitation but has achieved such poor adoption and use would motivate some worrying about having made some poor decisions. A quick response that says "we talked about that" but says no more seems a little bit facile. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Dave Crocker <[EMAIL PROTECTED]> writes: > 4. The v6 stack would need to have a v4 mode, for use by v4 > applications -- applications that use v4 addresses. Um, sounds an awful lot like dual-stack to me. Hosts (that understand IPv6) also must be able to originate and receive either IPv4 packets or the bigger IPv6 ones. Sure, the details may be somewhat different, but fundamentally, we have dual stack, with IPv6 nodes needing to support IPv4 for backwards compatability. And in the network, routers have to understand both the original IPv4 format, plus the new IPv6 format. If there was a magic "trivial" transition/upgrade strategy, we would have done it years ago. Really. Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Stephen, Perhaps, if the folks hadn't been so dogmatically against NAT at the time, the v4-to-v6 transition model would have worked similarly and we'd be done with it by now... I doubt it. The underlying problem with NAT doesn't go away whatever you do. IMHO, there probably isn't any true solution that doesn't involve a mechanism for distributing address-to-address mappings in some shape or form, so that all parties have the same view of whatever address mapping applies to a given e2e traffic flow. (It doesn't matter for this argument whether you're using the address mapping to perform NAT, encapsulation, or SHIM6 type address-swapping.) If you try to design a better NAT-PT, I'm pretty sure it will involve signalling back to the IPv6 side that "your correspondent believes that your address is :::192.0.2.3", or some such. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: perfect hindsight (was Re: Call for action vs. lost opportunity (Was: Re: Renumbering))
On 2007-10-10 12:44, Keith Moore wrote: Brian - is it provable that no design for a follow-on to IPv4 would have provided that backward compatibility? Or were there architectural and engineering decisions that chose other features over backward compatibility? 1. Take the original, simple Deering specification. 2. Declare the initial IPv6 address space as being the current IPv4 address space, with all upper bits zero. 3. The requirement for connecting a v6 stack to a v4 stack is a very simple IP header-mapping translation, with no loss of information at the IP level. 4. The v6 stack would need to have a v4 mode, for use by v4 applications -- applications that use v4 addresses. Close. But that still wouldn't have let hosts with extended addresses (nonzero upper bits) converse with hosts that only had v4 capability, even assuming that "very simple IP header mapping translation" in the signal path. The upgraded hosts could have sent packets to the v4-only hosts but not vice versa. Indeed. And that was the problem with my own proposal (aeiou) which was in some ways even simpler - it preserved the existing 32 bit address space and added a 32 bit address extension to be used within sites. Exactly the same issue as Keith points out applied, except that it was the nonzero _lower_ extension bits that would prevent 2-way communication with legacy hosts. Around about IETF 25 through 29, this class of ideas was thoroughly discussed. Brian Of course, if we could have all agreed on an approach like that 15 years ago, and convinced stack vendors to add the stack extensions long before they were needed, AND somehow manage to get those extensions well tested, AND updated all of the APIs and applications to be able to use extended addresses, not to mention DNS, then we might have made our transition a lot easier. That's a big IF though. My experience is that seldom-used extensions don't tend to work very well. And if we had (at least initially) embedded IPng addresses inside IPv4 packets, by any of various means (IPAE had one approach, 6to4 another, and embedding the extended bits in an IPv4 option a third) and assumed that we would start out routing IPng packets over the IPv4 Internet, we could have avoided coupling (at least) several difficult problems: (a) upgrading the network to use larger addresses, (b) renumbering the network to improve routing scalability, (c) simplifying the packet format. (but it's at least conceivable that if IPng had been designed as an extension to IPv4, to be carried at least initially over IPv4 networks, then NATs would have evolved in such a way as to facilitate use of extended addresses between participating pairs of hosts. not that this would have been obvious circa 1992. ). As it turned out, the approach chosen coupled those three problems with at least two other problems: the one of having to upgrade apps, stacks, and DNS; and the problem of forcing apps to choose between multiple source and destination addresses. And finally there's the problem of marketing/mindshare - trying to get people to understand and accept the subtle differences between IPv4 and IPv6 instead of selling them an enhanced version of IPv4. By comparison, the notion of "extended addressing" was already familiar from the PC world. It might have been much easier to sell IPv4 with extended addresses than to sell the "new" IPv6. This is, I believe, a classic case of second-system effect. Trying to solve several problems at once significantly raises the difficulty of solving any of them, particularly when adoption of the solution requires parties with vastly different interests (like carrier ISPs, enterprise networks, OS developers, and application developers) to all buy into the solution within a narrow timeframe. By contrast, decoupling the solutions might have allowed a more incremental adoption of all of the ideas, or most of them. (renumbering for routing scalability might still have been a hard sell) Of course, the devil is in the details. And the delay in adopting IPv6 further compounded the difficulties, because networks have changed a lot since 15 years ago. NATs, firewalls, intrusion detection, interception proxies, were much rarer in the early 1990s. All of these are affected by IPv6, and all of these impose further barriers to adoption of IPv6. But there's no point in kicking ourselves about this now. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
perfect hindsight (was Re: Call for action vs. lost opportunity (Was: Re: Renumbering))
>> Brian - is it provable that no design for a follow-on to IPv4 would >> have provided that backward compatibility? Or were there >> architectural and engineering decisions that chose other features >> over backward compatibility? > > >1. Take the original, simple Deering specification. > >2. Declare the initial IPv6 address space as being the current > IPv4 address space, with all upper bits zero. > >3. The requirement for connecting a v6 stack to a v4 stack is a > very simple IP header-mapping translation, with no loss of information > at the IP level. > >4. The v6 stack would need to have a v4 mode, for use by v4 > applications -- applications that use v4 addresses. Close. But that still wouldn't have let hosts with extended addresses (nonzero upper bits) converse with hosts that only had v4 capability, even assuming that "very simple IP header mapping translation" in the signal path. The upgraded hosts could have sent packets to the v4-only hosts but not vice versa. Of course, if we could have all agreed on an approach like that 15 years ago, and convinced stack vendors to add the stack extensions long before they were needed, AND somehow manage to get those extensions well tested, AND updated all of the APIs and applications to be able to use extended addresses, not to mention DNS, then we might have made our transition a lot easier. That's a big IF though. My experience is that seldom-used extensions don't tend to work very well. And if we had (at least initially) embedded IPng addresses inside IPv4 packets, by any of various means (IPAE had one approach, 6to4 another, and embedding the extended bits in an IPv4 option a third) and assumed that we would start out routing IPng packets over the IPv4 Internet, we could have avoided coupling (at least) several difficult problems: (a) upgrading the network to use larger addresses, (b) renumbering the network to improve routing scalability, (c) simplifying the packet format. (but it's at least conceivable that if IPng had been designed as an extension to IPv4, to be carried at least initially over IPv4 networks, then NATs would have evolved in such a way as to facilitate use of extended addresses between participating pairs of hosts. not that this would have been obvious circa 1992. ). As it turned out, the approach chosen coupled those three problems with at least two other problems: the one of having to upgrade apps, stacks, and DNS; and the problem of forcing apps to choose between multiple source and destination addresses. And finally there's the problem of marketing/mindshare - trying to get people to understand and accept the subtle differences between IPv4 and IPv6 instead of selling them an enhanced version of IPv4. By comparison, the notion of "extended addressing" was already familiar from the PC world. It might have been much easier to sell IPv4 with extended addresses than to sell the "new" IPv6. This is, I believe, a classic case of second-system effect. Trying to solve several problems at once significantly raises the difficulty of solving any of them, particularly when adoption of the solution requires parties with vastly different interests (like carrier ISPs, enterprise networks, OS developers, and application developers) to all buy into the solution within a narrow timeframe. By contrast, decoupling the solutions might have allowed a more incremental adoption of all of the ideas, or most of them. (renumbering for routing scalability might still have been a hard sell) Of course, the devil is in the details. And the delay in adopting IPv6 further compounded the difficulties, because networks have changed a lot since 15 years ago. NATs, firewalls, intrusion detection, interception proxies, were much rarer in the early 1990s. All of these are affected by IPv6, and all of these impose further barriers to adoption of IPv6. But there's no point in kicking ourselves about this now. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Thus spake "Tony Li" <[EMAIL PROTECTED]> On Oct 9, 2007, at 11:29 AM, David Conrad wrote: On Oct 9, 2007, at 9:43 AM, Tony Li wrote: Any new design would have necessarily required more bits to address more end systems. Making legacy systems interact with these additional addressing bits without some form of gateway, NAT or other translation would indeed be challenging. You're literally trying to expand the size of the namespace that a legacy implementation will recognize. 32 bit AS numbers. Fortunately, the legacy BGP implementations don't need to recognize the new part of the namespace. They only see the legacy space, including AS_TRANS. The new namespace is translated (with major amounts of information loss) into the old namespace for their benefit. This still doesn't provide a mechanism for legacy systems to interact directly with new systems. For example, you can't have a legacy system directly peer with a system using a 32 bit AS number. Instead, it has to be remapped to AS_TRANS. So, it's just NAT for BGP. ;-) Does that mean the IETF is going to deprecate 32-bit ASNs like was done to NAT-PT? ;-) Perhaps, if the folks hadn't been so dogmatically against NAT at the time, the v4-to-v6 transition model would have worked similarly and we'd be done with it by now... S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Ralph Droms wrote: Brian - is it provable that no design for a follow-on to IPv4 would have provided that backward compatibility? Or were there architectural and engineering decisions that chose other features over backward compatibility? 1. Take the original, simple Deering specification. 2. Declare the initial IPv6 address space as being the current IPv4 address space, with all upper bits zero. 3. The requirement for connecting a v6 stack to a v4 stack is a very simple IP header-mapping translation, with no loss of information at the IP level. 4. The v6 stack would need to have a v4 mode, for use by v4 applications -- applications that use v4 addresses. You are now done with an initial v6 deployment. Note the absence of dual stack in any single host, the minimal incompatibility between the two versions of IP, and so on. A continuing series of incremental changes would permit incremental benefit of the larger address space in IP, routing, applications, etc. Has the added 15 years brought more functionality than this approach would have permitted? Is deployment easier? d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On Oct 9, 2007, at 11:29 AM, David Conrad wrote: On Oct 9, 2007, at 9:43 AM, Tony Li wrote: Any new design would have necessarily required more bits to address more end systems. Making legacy systems interact with these additional addressing bits without some form of gateway, NAT or other translation would indeed be challenging. You're literally trying to expand the size of the namespace that a legacy implementation will recognize. 32 bit AS numbers. Fortunately, the legacy BGP implementations don't need to recognize the new part of the namespace. They only see the legacy space, including AS_TRANS. The new namespace is translated (with major amounts of information loss) into the old namespace for their benefit. This still doesn't provide a mechanism for legacy systems to interact directly with new systems. For example, you can't have a legacy system directly peer with a system using a 32 bit AS number. Instead, it has to be remapped to AS_TRANS. So, it's just NAT for BGP. ;-) Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On Oct 9, 2007, at 9:43 AM, Tony Li wrote: Any new design would have necessarily required more bits to address more end systems. Making legacy systems interact with these additional addressing bits without some form of gateway, NAT or other translation would indeed be challenging. You're literally trying to expand the size of the namespace that a legacy implementation will recognize. 32 bit AS numbers. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On Oct 9, 2007, at 8:49 AM, Ralph Droms wrote: is it provable that no design for a follow-on to IPv4 would have provided that backward compatibility? Hi Ralph, I don't know about 'provable', but there's a strong argument as to why that's challenging. Any new design would have necessarily required more bits to address more end systems. Making legacy systems interact with these additional addressing bits without some form of gateway, NAT or other translation would indeed be challenging. You're literally trying to expand the size of the namespace that a legacy implementation will recognize. And, I guess I'll stop here as I'm rehashing a train that long ago left the station... While the train has left the station, it seems like it can still be modified while in motion. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Brian - OK, I agree that a wide range of tunneling/translation mechanisms have been considered; was the transition problem considered during the basic design? In any event, in my opinion we don't have a fundamental level of backward compatibility that would solve the current deployment issues. - Ralph On Oct 6, 2007, at Oct 6, 2007,4:14 PM, Brian E Carpenter wrote: On 2007-10-05 09:12, Ralph Droms wrote: Typo: should read IPv6 ~= IPv4+more_bits... - Ralph On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote: Regarding transition: On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote: Unless I've missed something rather basic, in the case of IPv6, very little attention was paid to facilitating transition by maximizing interoperability with the IPv4 installed base. Dave, I have to agree with you in this regard. We may have achieved neither significant new capabilities because IPv6 ~= IPv6+more_bits, nor ease of transition because transition wasn't thoroughly evaluated early on in the design process... Ralph, that last assertion simply isn't true. Migration/transition/ co-existence was on the radar screen right from the start. The dual stack model was chosen explicitly to allow for co-existence, and in particular so that dual stack servers can serve both IPv4 and IPv6 clients, and that is running code. There's a fundamental difficulty in having IPvX-only clients working with IPvY-only servers except via application-level relays. It isn't a consequence of design details of v4 and v6. I'm sure we could have done better, but this was very definitely thought about. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Brian - is it provable that no design for a follow-on to IPv4 would have provided that backward compatibility? Or were there architectural and engineering decisions that chose other features over backward compatibility? And, I guess I'll stop here as I'm rehashing a train that long ago left the station... - Ralph On Oct 6, 2007, at Oct 6, 2007,4:14 PM, Brian E Carpenter wrote: On 2007-10-05 09:12, Ralph Droms wrote: Typo: should read IPv6 ~= IPv4+more_bits... - Ralph On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote: Regarding transition: On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote: Unless I've missed something rather basic, in the case of IPv6, very little attention was paid to facilitating transition by maximizing interoperability with the IPv4 installed base. Dave, I have to agree with you in this regard. We may have achieved neither significant new capabilities because IPv6 ~= IPv6+more_bits, nor ease of transition because transition wasn't thoroughly evaluated early on in the design process... Ralph, that last assertion simply isn't true. Migration/transition/ co-existence was on the radar screen right from the start. The dual stack model was chosen explicitly to allow for co-existence, and in particular so that dual stack servers can serve both IPv4 and IPv6 clients, and that is running code. There's a fundamental difficulty in having IPvX-only clients working with IPvY-only servers except via application-level relays. It isn't a consequence of design details of v4 and v6. I'm sure we could have done better, but this was very definitely thought about. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On 2007-10-05 09:12, Ralph Droms wrote: Typo: should read IPv6 ~= IPv4+more_bits... - Ralph On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote: Regarding transition: On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote: Unless I've missed something rather basic, in the case of IPv6, very little attention was paid to facilitating transition by maximizing interoperability with the IPv4 installed base. Dave, I have to agree with you in this regard. We may have achieved neither significant new capabilities because IPv6 ~= IPv6+more_bits, nor ease of transition because transition wasn't thoroughly evaluated early on in the design process... Ralph, that last assertion simply isn't true. Migration/transition/ co-existence was on the radar screen right from the start. The dual stack model was chosen explicitly to allow for co-existence, and in particular so that dual stack servers can serve both IPv4 and IPv6 clients, and that is running code. There's a fundamental difficulty in having IPvX-only clients working with IPvY-only servers except via application-level relays. It isn't a consequence of design details of v4 and v6. I'm sure we could have done better, but this was very definitely thought about. Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Typo: should read IPv6 ~= IPv4+more_bits... - Ralph On Oct 4, 2007, at Oct 4, 2007,4:52 AM, Ralph Droms wrote: Regarding transition: On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote: Unless I've missed something rather basic, in the case of IPv6, very little attention was paid to facilitating transition by maximizing interoperability with the IPv4 installed base. Dave, I have to agree with you in this regard. We may have achieved neither significant new capabilities because IPv6 ~= IPv6+more_bits, nor ease of transition because transition wasn't thoroughly evaluated early on in the design process... - Ralph ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Regarding transition: On Sep 14, 2007, at Sep 14, 2007,3:43 PM, Dave Crocker wrote: Unless I've missed something rather basic, in the case of IPv6, very little attention was paid to facilitating transition by maximizing interoperability with the IPv4 installed base. Dave, I have to agree with you in this regard. We may have achieved neither significant new capabilities because IPv6 ~= IPv6+more_bits, nor ease of transition because transition wasn't thoroughly evaluated early on in the design process... - Ralph ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On 25-sep-2007, at 2:18, Mark Andrews wrote: You are comingling way too many things here. Let me simply conclude that foo.example.org is the first name that is tried and since it exists what comes back for that name is what's going to be used. Actually it isn't specified what should happen. If you don't make queries most(all?) existing search algorithms will continue to foo.example.net. Remember, in the DNS, a name can exist yet have not records associated with it (rcode=NOERROR ancount=0 is returned for all types). Looks like you're right, at least as far as my Mac is concerned. I set up two subdomains test1 and test2 with each the hosts a, b, c and d with the following addresses: IPv6 IPv4 a.test1 X X b.test1 X - c.test1 - X d.test1 - - a.test2 - - b.test2 - X c.test2 X - d.test2 X X Then I set up test1.runningipv6.net, test2.runningipv6.net up as my search domains. (Info is still in there, feel free to try for yourself. TTL is 20 seconds.) Results on my Mac running the latest updates with both IPv4 and IPv6 connectivity: (host talks directly to the DNS and looks for both A and ) $ host a a.test1.runningipv6.net has address 192.0.2.101 a.test1.runningipv6.net has IPv6 address 2001:db8:1::a $ host b b.test1.runningipv6.net has IPv6 address 2001:db8:1::b $ host c c.test1.runningipv6.net has address 192.0.2.103 $ host d d.test2.runningipv6.net has address 192.0.2.204 d.test2.runningipv6.net has IPv6 address 2001:db8:2::d (traceroute only does IPv4) $ traceroute a traceroute to a.test1.runningipv6.net (192.0.2.101), 64 hops max, 40 byte packets $ traceroute b traceroute to b.test2.runningipv6.net (192.0.2.202), 64 hops max, 40 byte packets $ traceroute c traceroute to c.test1.runningipv6.net (192.0.2.103), 64 hops max, 40 byte packets $ traceroute d traceroute to d.test2.runningipv6.net (192.0.2.204), 64 hops max, 40 byte packets (traceroute6 only does IPv6) $ traceroute6 a traceroute6 to a.test1.runningipv6.net (2001:db8:1::a) from $ traceroute6 b traceroute6 to b.test1.runningipv6.net (2001:db8:1::b) from $ traceroute6 c traceroute6 to c.test2.runningipv6.net (2001:db8:2::c) from $ traceroute6 d traceroute6 to d.test2.runningipv6.net (2001:db8:2::d) from (telnet does both IPv4 and IPv6) $ telnet a Trying 2001:db8:1::a... $ telnet b Trying 2001:db8:1::b... $ telnet c Trying 2001:db8:2::c... $ telnet d Trying 2001:db8:2::d... So your issue that the results are inconsistent is certainly real. I'd say that the best way to avoid this is not having a search domain at all, or at the very least not several. If someone wants to spend time to come up with a reasonable guideline of how to behave that gives the same results regardless of the type of connectivity that's available, that would be good but probably extremely hard to do. People like to use unqualified *and* partially qualified hostnames. People also like to drive without seat belts. We don't let them do that either... Or at least, we don't listen to their complaints when the results are inferior to those obtained while driving _with_ a seatbelt. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
> Mark Andrews wrote: > >>> Actually getaddrinfo() not asking for all the time is > >>> broken if you add in searching which most/all getaddrinfo() > >>> calls do. > >>> > >>> You want to get to the *same* name when searching regardless > >>> of whether it has A, or & A records. > >>> > >> +1 > >> > >> and furthermore the result needs to be the same regardless of whether > >> this is done on an IPv4-only, IPv6-only, or dual-stack and > >> dual-connected machine. > >> > > > > In otherwords it need to be independent of the setting of > > AI_ADDRCONFIG. > Well, that's not saying quite the same thing that I was trying to say. > > The /name/ on which the query is based should be independent of whether > AI_ADDRCONFIG is set. However the /result/ of the query can still > differ based on whether that flag is set. And if AI_ADDRCONFIG is not > set, the result of the query should be the same regardless of whether > the host has IPv4 access, IPv6 access, or both. This implies that the > query is being done on the same name in both cases. It also means that you need to stop searching if there is a A or record regardless of which address families are configured. This notion that a IPv4 only box doesn't need to make queries is completely bogus. > (Actually I think that AI_ADDRCONFIG is so ambiguously defined as to be > fairly useless in practice. But I also think that searching through > multiple zones is a bad idea.) > > Keith Mark P.S. I think hotels will quickly fix the brokenness now that Vista is shipped. This won't fix all the DNS breakage they cause but that part will go away. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Mark Andrews wrote: >>> Actually getaddrinfo() not asking for all the time is >>> broken if you add in searching which most/all getaddrinfo() >>> calls do. >>> >>> You want to get to the *same* name when searching regardless >>> of whether it has A, or & A records. >>> >> +1 >> >> and furthermore the result needs to be the same regardless of whether >> this is done on an IPv4-only, IPv6-only, or dual-stack and >> dual-connected machine. >> > > In otherwords it need to be independent of the setting of > AI_ADDRCONFIG. Well, that's not saying quite the same thing that I was trying to say. The /name/ on which the query is based should be independent of whether AI_ADDRCONFIG is set. However the /result/ of the query can still differ based on whether that flag is set. And if AI_ADDRCONFIG is not set, the result of the query should be the same regardless of whether the host has IPv4 access, IPv6 access, or both. This implies that the query is being done on the same name in both cases. (Actually I think that AI_ADDRCONFIG is so ambiguously defined as to be fairly useless in practice. But I also think that searching through multiple zones is a bad idea.) Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
> > > Actually getaddrinfo() not asking for all the time is > > broken if you add in searching which most/all getaddrinfo() > > calls do. > > > > You want to get to the *same* name when searching regardless > > of whether it has A, or & A records. > > +1 > > and furthermore the result needs to be the same regardless of whether > this is done on an IPv4-only, IPv6-only, or dual-stack and > dual-connected machine. In otherwords it need to be independent of the setting of AI_ADDRCONFIG. > Keith -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
> Actually getaddrinfo() not asking for all the time is > broken if you add in searching which most/all getaddrinfo() > calls do. > > You want to get to the *same* name when searching regardless > of whether it has A, or & A records. +1 and furthermore the result needs to be the same regardless of whether this is done on an IPv4-only, IPv6-only, or dual-stack and dual-connected machine. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
> On 25-sep-2007, at 0:34, Mark Andrews wrote:
>
> > Actually getaddrinfo() not asking for all the time is
> > broken if you add in searching which most/all getaddrinfo()
> > calls do.
>
> > You want to get to the *same* name when searching regardless
> > of whether it has A, or & A records. There are two
> > way to achieve this.
>
> I don't understand what you're saying: "get the same name"? We're
> talking about getting addresses, we already have the name.
>
> > getaddrinfo("foo") and getaddrinfo("ftp.uu.net")
>
> > search "example.org example.net example.com"
>
> You really don't want to have a list of search domains, the ambiguity
> will bite you at some point. Better to stick with fully qualified names.
>
> > foo.example.org A 1.2.3.4
> > foo.example.net A 2001::1
> > *.example.com A 1.2.3.5
> > *.example.com A 2001::2
>
> (Don't you mean for the IPv6 addresses?)
Yes.
> You are comingling way too many things here. Let me simply conclude
> that foo.example.org is the first name that is tried and since it
> exists what comes back for that name is what's going to be used.
Actually it isn't specified what should happen.
If you don't make queries most(all?) existing search
algorithms will continue to foo.example.net. Remember, in
the DNS, a name can exist yet have not records associated
with it (rcode=NOERROR ancount=0 is returned for all types).
Similarly if you don't make A queries you will end up with
ftp.uu.net.example.com.
RFC 3493 says:
For example, when using the DNS, a query for records should
occur only if the node has at least one IPv6 address configured
(other than IPv6 loopback) and a query for A records should occur
only if the node has at least one IPv4 address configured (other
than the IPv4 loopback).
This is actually dangerous when searching is done.
> I'm
> reasonably sure this is even the case when "what comes back" is an
> empty set.
And in the deployed code this co-mingling occurs. It's reality
and we, the IETF, should define what it the best/safest/correct
behaviour when that occurs.
People like to use unqualified *and* partially qualified hostnames.
We should be writting specifications that take this into account.
We have not done that for getaddrinfo().
Mark
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On 25-sep-2007, at 0:34, Mark Andrews wrote:
Actually getaddrinfo() not asking for all the time is
broken if you add in searching which most/all getaddrinfo()
calls do.
You want to get to the *same* name when searching regardless
of whether it has A, or & A records. There are two
way to achieve this.
I don't understand what you're saying: "get the same name"? We're
talking about getting addresses, we already have the name.
getaddrinfo("foo") and getaddrinfo("ftp.uu.net")
search "example.org example.net example.com"
You really don't want to have a list of search domains, the ambiguity
will bite you at some point. Better to stick with fully qualified names.
foo.example.org A 1.2.3.4
foo.example.net A 2001::1
*.example.com A 1.2.3.5
*.example.com A 2001::2
(Don't you mean for the IPv6 addresses?)
You are comingling way too many things here. Let me simply conclude
that foo.example.org is the first name that is tried and since it
exists what comes back for that name is what's going to be used. I'm
reasonably sure this is even the case when "what comes back" is an
empty set.
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
> On 24-sep-2007, at 2:07, Mark Andrews wrote:
>
> >>> I suppose, in theory, a DNS query over v4 might return an
> >>> record that _is_ accessible via one of my link-local addresses or
> >>> the loopback address.
>
> >> Yeah right. Try again.
>
> > Don't you have "localhost ::1" and "localhost A
> > 127.0.0.1" configured in you DNS?
>
> You got me there. :-)
>
> I don't think that specific case warrants asking for records all
> the time for everything even though there is no IPv6 connectivity,
> though. The proper way to do this is probably to make localhost a
> special case in the resolver library. This also helps avoiding
> weirdness when some joker puts "localhost" with a non-localhost
> address in one of your search domains.
Actually getaddrinfo() not asking for all the time is
broken if you add in searching which most/all getaddrinfo()
calls do.
You want to get to the *same* name when searching regardless
of whether it has A, or & A records. There are two
way to achieve this.
1. you stop when you get a NODATA response.
2. you stop when there is a A or record at the name.
The IETF/POSIX needs to specify what is the correct algorithm
to use when searching. Note the first cannot be applies to
anyother backend than the DNS.
getaddrinfo("foo") and getaddrinfo("ftp.uu.net")
search "example.org example.net example.com"
foo.example.org A 1.2.3.4
foo.example.net A 2001::1
*.example.com A 1.2.3.5
*.example.com A 2001::2
What is the correct response on a
* IPv4 only machine
* IPv6 only machine
* dual stack machine
Note ftp.uu.net does NOT have records
Mark
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED]
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
>>> Obviously this should be fixed. But: you may ask yourself: why is your >>> system doing lookups when you obviously don't have IPv6 >>> connectivity? > >> Because the application asked it to do them? > > Did it? > > If you look up the getaddrinfo() man page (see top Google hits for a > link to the implementation in your favorite OS) you'll see that it's > possible to specify a protocol family or "accept any protocol family > supported by the operating system". > > (But: protocol family? Didn't we call these things address families?) > > In my opinion, when the application says "unspecified", it's entirely > reasonable for the OS to only supply addresses of a type that > currently has reachability. Well, I'm not sure what the specification means by this. But that's kind of a separate issue. The point is that the application might well have a need for records and to request records in a DNS lookup even if the local host doesn't have external IPv6 connectivity - or perhaps no IPv6 connectivity at all. You don't want API second-guessing this stuff. >> Here's the thing. I don't want getnameinfo() or any other API that does >> DNS lookup to act differently depending on whether the system seems to >> have external IPv6 connectivity or not (unless the app explicitly asked >> for this), because my app might have a valid reason for wanting to know >> if there's an record associated with a name even if the system >> doesn't have external IPv6 connectivity. > > I agree that if an application specifically asks for something the OS > etc shouldn't pretend it doesn't exist if it does, but I disagree that > there are significant valid cases where this is required. Whenever I look at what it takes to make IPv6 transition viable, I find cases where it is essential to be able to host a IPv4 service on an IPv6-only network and vice versa. So I disagree. >> The view of DNS needs to be >> consistent from one host to another and one query to another if we want >> applications to work reliably. > > Sure. (Hence the evilness of two-faced DNS. Yes, flame away.) However, > that doesn't apply here: there is no requirement that if someone asks > for one record type, she is informed of all other record types as well. Provided that they get what they ask for. > Following your logic, the Windows logic of always asking for > records when IPv6 is enabled doesn't go far enough: it should ask for > records even when IPv6 is disabled administratively. If the app requests them, yes. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On 24-sep-2007, at 2:07, Mark Andrews wrote: I suppose, in theory, a DNS query over v4 might return an record that _is_ accessible via one of my link-local addresses or the loopback address. Yeah right. Try again. Don't you have "localhost ::1" and "localhost A 127.0.0.1" configured in you DNS? You got me there. :-) I don't think that specific case warrants asking for records all the time for everything even though there is no IPv6 connectivity, though. The proper way to do this is probably to make localhost a special case in the resolver library. This also helps avoiding weirdness when some joker puts "localhost" with a non-localhost address in one of your search domains. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On 24-sep-2007, at 4:16, Keith Moore wrote: Obviously this should be fixed. But: you may ask yourself: why is your system doing lookups when you obviously don't have IPv6 connectivity? Because the application asked it to do them? Did it? If you look up the getaddrinfo() man page (see top Google hits for a link to the implementation in your favorite OS) you'll see that it's possible to specify a protocol family or "accept any protocol family supported by the operating system". (But: protocol family? Didn't we call these things address families?) In my opinion, when the application says "unspecified", it's entirely reasonable for the OS to only supply addresses of a type that currently has reachability. Here's the thing. I don't want getnameinfo() or any other API that does DNS lookup to act differently depending on whether the system seems to have external IPv6 connectivity or not (unless the app explicitly asked for this), because my app might have a valid reason for wanting to know if there's an record associated with a name even if the system doesn't have external IPv6 connectivity. I agree that if an application specifically asks for something the OS etc shouldn't pretend it doesn't exist if it does, but I disagree that there are significant valid cases where this is required. The view of DNS needs to be consistent from one host to another and one query to another if we want applications to work reliably. Sure. (Hence the evilness of two-faced DNS. Yes, flame away.) However, that doesn't apply here: there is no requirement that if someone asks for one record type, she is informed of all other record types as well. Following your logic, the Windows logic of always asking for records when IPv6 is enabled doesn't go far enough: it should ask for records even when IPv6 is disabled administratively. And MX records, TXT records... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Stephane Bortzmeyer wrote: > On Sun, Sep 23, 2007 at 10:16:26PM -0400, > Keith Moore <[EMAIL PROTECTED]> wrote > a message of 53 lines which said: > > >> I don't want getnameinfo() or any other API that does DNS lookup to >> act differently depending on whether the system seems to have >> external IPv6 connectivity or not (unless the app explicitly asked >> for this), >> > > getaddrinfo() or getnameinfo() are *not* supposed to do DNS lookups, > they are supposed to do name-to-address mapping, using whatever system > they were configured for (may be the DNS, may be LDAP, may be > /etc/hosts). > yeah, I know. and that's *broken*. because if people want apps to use DNS names, then apps need a consistent way to do DNS name lookups from one app to another. why shouldn't the standard name lookup API do this? >> because my app might have a valid reason for wanting to know if >> there's an record associated with a name even if the system >> doesn't have external IPv6 connectivity. >> > > OK, then it requires a low-level system call, doing only DNS lookups > (this API already exists, BTW). getaddrinfo() is for applications who > want the high-level view. > there's no standard API to do this. and there needs to be. >> More generally, I don't want anything that handles DNS queries - >> > > Then, getaddrinfo() is out of scope, since it was never conceived as a > DNS debugging tool who said anything about debugging?there are a number of apps that are required, as a matter of standards conformance, to do DNS queries if they want to operate correctly. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On Sun, Sep 23, 2007 at 10:16:26PM -0400, Keith Moore <[EMAIL PROTECTED]> wrote a message of 53 lines which said: > I don't want getnameinfo() or any other API that does DNS lookup to > act differently depending on whether the system seems to have > external IPv6 connectivity or not (unless the app explicitly asked > for this), getaddrinfo() or getnameinfo() are *not* supposed to do DNS lookups, they are supposed to do name-to-address mapping, using whatever system they were configured for (may be the DNS, may be LDAP, may be /etc/hosts). > because my app might have a valid reason for wanting to know if > there's an record associated with a name even if the system > doesn't have external IPv6 connectivity. OK, then it requires a low-level system call, doing only DNS lookups (this API already exists, BTW). getaddrinfo() is for applications who want the high-level view. > More generally, I don't want anything that handles DNS queries - Then, getaddrinfo() is out of scope, since it was never conceived as a DNS debugging tool. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
>> because their boxes break horribly when confronted with an >> lookup. This has been going on for _years_ and the operators and >> vendors obviously don't care even though the problem is blatantly >> obvious. > > Obviously this should be fixed. But: you may ask yourself: why is your > system doing lookups when you obviously don't have IPv6 > connectivity? Because the application asked it to do them? Here's the thing. I don't want getnameinfo() or any other API that does DNS lookup to act differently depending on whether the system seems to have external IPv6 connectivity or not (unless the app explicitly asked for this), because my app might have a valid reason for wanting to know if there's an record associated with a name even if the system doesn't have external IPv6 connectivity. For instance, my app might have an RSIP or socks or explicitly controlled NAT service available that can let it access the IPv6 network, or it might be providing referrals to peers that can make use of an IPv6 address. More generally, I don't want anything that handles DNS queries - be it the API or a cache server or any intermediary or really even an authoritative server, to be trying to make guesses about how to interpret a query based on anything other than the information in that query - class, query RR type, name, etc. The view of DNS needs to be consistent from one host to another and one query to another if we want applications to work reliably. Over-clever APIs, NATs with DNS ALG, other intermediaries that try to guess what the app wants or needs are not doing a service to anybody. They're just making the DNS less predictable, less consistent, and less usable by apps. (as for multi-faced DNS, it is is a mixed blessing at best) As for intermediaries that try to intercept DNS queries and screw with the query or the results: In general, the problem with intermediaries is that they need to be smarter than both endpoints. Intermediaries essentially always fail at this. One reason is that endpoints are so diverse in their implementations and needs. Another reason is that intermediaries tend to be invisible (not "transparent" which is something different). So when things break, attention is focused on the endpoints even though the intermediary is responsible for the breakage. But the last thing you need is an API that tries to second guess what the intermediary is doing and work around bugs in the intermediary. Because that just makes the system as a whole even less predictable, and makes it take longer to get the broken intermediaries fixed. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
> On 21-sep-2007, at 20:33, Stephen Sprunk wrote: > > >> Obviously this should be fixed. But: you may ask yourself: why > >> is your system doing lookups when you obviously don't > >> have IPv6 connectivity? Almost all boxes these days have internal IPv6 connectivity. > > Anyone from Microsoft listening? > > > I suppose, in theory, a DNS query over v4 might return an > > record that _is_ accessible via one of my link-local addresses or > > the loopback address. > > Yeah right. Try again. Don't you have "localhost ::1" and "localhost A 127.0.0.1" configured in you DNS? > > As long as v6 is _enabled_ on a Windows box, it does queries, > > even if it has to send them via v4. > > Looks like you're right, and it also seems to be a system-wide thing, > because Safari on Windows also first generates a query for a > record and then for a A record on XP with IPv6 enabled but with no > local IPv6 router and a private address = no 6to4. > > On the Mac it's A first and then but only when there's actual > IPv6 connectivity. This won't trigger related bugs too badly > even when IPv6 is enabled. > > > I'm told WinXP isn't even capable of doing DNS over v6. > > You can't set up an IPv6 address for a DNS resolver, no. > > >>> Whether I can live with that in a particular case depends on what > >>> percentage of the userbase will see "some problems" if that > >>> brokenness is exposed. > > >> Ah yes, the "if enough people do something wrong it becomes > >> right" doctrine. So here in Holland we have "alcohol free" beer > >> that contains 0.5% alcohol, and megabytes are now 100 > >> bytes. > > > That complaint doesn't resonate so well when you're writing in a > > language whose "rules" are defined by whatever people do and if > > enough people do something "wrong" it gets reclassified as "right". > > I don't think these redefinitions can be classified as a language issue. > > I'll be happy to repeat my statements in a language that has a > committee that gets to decide what's officially correct in the > language, but I don't think that helps for a variety of reasons, one > being that the committees don't get it right much of the time either. > > > There's a difference between de jure and de facto standards. > > That's not to say that de jure standards are not needed -- they > > obviously are -- but when the majority of people are ignoring them, > > you can't just stick your head in the sand and ignore the de facto > > reality. That _should_ be a sign that the de jure standards need > > rewriting after one reviews _why_ the de facto standard has diverged. > > Within the context of what we're doing in the IETF, that's extremely > simple: programmers are lazy. And if they're not lazy themselves, > their bosses don't give them enough time to do non-lazy work. I know > a programmer who is held in very high regard who will write two extra > pages of code just to do bounds checking for possible a buffer > overflow that can't even happen in the first place, but he never > checks for overflow conditions. If he'd written a TCP implementation, > sessions would break after transmitting (at most) 4 GB of data > because after 4294967295 the TCP sequence number becomes 0 again but > his code doesn't check for this transition. > > Why bother with details like that if you can simply make the field > bigger and let the support people clean up the mess a few years down > the road when you run out of the extra bits? Which brings us back to > the topic of the discussion: why do things the hard way if it's so > easy to put an IP address in a configuration file? > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On 21-sep-2007, at 20:33, Stephen Sprunk wrote: Obviously this should be fixed. But: you may ask yourself: why is your system doing lookups when you obviously don't have IPv6 connectivity? Anyone from Microsoft listening? I suppose, in theory, a DNS query over v4 might return an record that _is_ accessible via one of my link-local addresses or the loopback address. Yeah right. Try again. As long as v6 is _enabled_ on a Windows box, it does queries, even if it has to send them via v4. Looks like you're right, and it also seems to be a system-wide thing, because Safari on Windows also first generates a query for a record and then for a A record on XP with IPv6 enabled but with no local IPv6 router and a private address = no 6to4. On the Mac it's A first and then but only when there's actual IPv6 connectivity. This won't trigger related bugs too badly even when IPv6 is enabled. I'm told WinXP isn't even capable of doing DNS over v6. You can't set up an IPv6 address for a DNS resolver, no. Whether I can live with that in a particular case depends on what percentage of the userbase will see "some problems" if that brokenness is exposed. Ah yes, the "if enough people do something wrong it becomes right" doctrine. So here in Holland we have "alcohol free" beer that contains 0.5% alcohol, and megabytes are now 100 bytes. That complaint doesn't resonate so well when you're writing in a language whose "rules" are defined by whatever people do and if enough people do something "wrong" it gets reclassified as "right". I don't think these redefinitions can be classified as a language issue. I'll be happy to repeat my statements in a language that has a committee that gets to decide what's officially correct in the language, but I don't think that helps for a variety of reasons, one being that the committees don't get it right much of the time either. There's a difference between de jure and de facto standards. That's not to say that de jure standards are not needed -- they obviously are -- but when the majority of people are ignoring them, you can't just stick your head in the sand and ignore the de facto reality. That _should_ be a sign that the de jure standards need rewriting after one reviews _why_ the de facto standard has diverged. Within the context of what we're doing in the IETF, that's extremely simple: programmers are lazy. And if they're not lazy themselves, their bosses don't give them enough time to do non-lazy work. I know a programmer who is held in very high regard who will write two extra pages of code just to do bounds checking for possible a buffer overflow that can't even happen in the first place, but he never checks for overflow conditions. If he'd written a TCP implementation, sessions would break after transmitting (at most) 4 GB of data because after 4294967295 the TCP sequence number becomes 0 again but his code doesn't check for this transition. Why bother with details like that if you can simply make the field bigger and let the support people clean up the mess a few years down the road when you run out of the extra bits? Which brings us back to the topic of the discussion: why do things the hard way if it's so easy to put an IP address in a configuration file? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On 20-sep-2007, at 21:19, Stephen Sprunk wrote: Sometimes ignoring a problem really does make it go away. Install a workaround, on the other hand, and the brokenness remains non-obvious so it persists. If often persists whether it remains non-obvious or not. I can't count how many hotels I've visited where I have to disable v6 on my laptop for v4 DNS to work Yes, hotels are the worst. In Chicago two months ago they used a NAT timeout in my hotel that was so short that my SSH, IMAP and IM sessions timed out every few minutes. Same problem with most WiFi hotspots; I think they use the same all-in-one boxes for HTTP-interception, DNS, DHCP, etc. There are few vendors in that space whose boxes _aren't_ broken in myriad different ways. Operators don't care because they've already gotten your money by the time you discover the brokenness. because their boxes break horribly when confronted with an lookup. This has been going on for _years_ and the operators and vendors obviously don't care even though the problem is blatantly obvious. Obviously this should be fixed. But: you may ask yourself: why is your system doing lookups when you obviously don't have IPv6 connectivity? Anyone from Microsoft listening? I suppose, in theory, a DNS query over v4 might return an record that _is_ accessible via one of my link-local addresses or the loopback address. As long as v6 is _enabled_ on a Windows box, it does queries, even if it has to send them via v4. I'm told WinXP isn't even capable of doing DNS over v6. I'm not advocating going around and breaking implementations that don't fully conform with specs on purpose, but if doing the right thing means that out-of-spec implementations see some problems, I can usually live with that. Whether I can live with that in a particular case depends on what percentage of the userbase will see "some problems" if that brokenness is exposed. Ah yes, the "if enough people do something wrong it becomes right" doctrine. So here in Holland we have "alcohol free" beer that contains 0.5% alcohol, and megabytes are now 100 bytes. That complaint doesn't resonate so well when you're writing in a language whose "rules" are defined by whatever people do and if enough people do something "wrong" it gets reclassified as "right". There's a difference between de jure and de facto standards. That's not to say that de jure standards are not needed -- they obviously are -- but when the majority of people are ignoring them, you can't just stick your head in the sand and ignore the de facto reality. That _should_ be a sign that the de jure standards need rewriting after one reviews _why_ the de facto standard has diverged. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On 20-sep-2007, at 21:19, Stephen Sprunk wrote: Sometimes ignoring a problem really does make it go away. Install a workaround, on the other hand, and the brokenness remains non-obvious so it persists. If often persists whether it remains non-obvious or not. I can't count how many hotels I've visited where I have to disable v6 on my laptop for v4 DNS to work Yes, hotels are the worst. In Chicago two months ago they used a NAT timeout in my hotel that was so short that my SSH, IMAP and IM sessions timed out every few minutes. because their boxes break horribly when confronted with an lookup. This has been going on for _years_ and the operators and vendors obviously don't care even though the problem is blatantly obvious. Obviously this should be fixed. But: you may ask yourself: why is your system doing lookups when you obviously don't have IPv6 connectivity? I'm not advocating going around and breaking implementations that don't fully conform with specs on purpose, but if doing the right thing means that out-of-spec implementations see some problems, I can usually live with that. Whether I can live with that in a particular case depends on what percentage of the userbase will see "some problems" if that brokenness is exposed. Ah yes, the "if enough people do something wrong it becomes right" doctrine. So here in Holland we have "alcohol free" beer that contains 0.5% alcohol, and megabytes are now 100 bytes. For instace, we accomodate multi-faced DNS because most "major" web sites would become inaccessible if it weren't. ??? How come? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On 19-sep-2007, at 17:48, Stephen Sprunk wrote: All of those things are broken, of course. That doesn't change the fact they exist and folks in the operational community will not be impressed with a "solution" that ignores those problems. Sometimes ignoring a problem really does make it go away. Install a workaround, on the other hand, and the brokenness remains non-obvious so it persists. If often persists whether it remains non-obvious or not. I can't count how many hotels I've visited where I have to disable v6 on my laptop for v4 DNS to work because their boxes break horribly when confronted with an lookup. This has been going on for _years_ and the operators and vendors obviously don't care even though the problem is blatantly obvious. I'm not advocating going around and breaking implementations that don't fully conform with specs on purpose, but if doing the right thing means that out-of-spec implementations see some problems, I can usually live with that. Whether I can live with that in a particular case depends on what percentage of the userbase will see "some problems" if that brokenness is exposed. For instace, we accomodate multi-faced DNS because most "major" web sites would become inaccessible if it weren't. If you are proposing a new protocol that would not accomodate it, forcing users to choose between that protocol and being able to access Google, Yahoo, CNN, MySpace, etc., it's obvious which the masses will choose. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On 19-sep-2007, at 17:48, Stephen Sprunk wrote: All of those things are broken, of course. That doesn't change the fact they exist and folks in the operational community will not be impressed with a "solution" that ignores those problems. Sometimes ignoring a problem really does make it go away. Install a workaround, on the other hand, and the brokenness remains non-obvious so it persists. I'm not advocating going around and breaking implementations that don't fully conform with specs on purpose, but if doing the right thing means that out-of-spec implementations see some problems, I can usually live with that. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Thus spake "Iljitsch van Beijnum" <[EMAIL PROTECTED]> On Sep 13, 2007, at 20:52 , Keith Moore wrote: How do you renumber the IP address stored in the struct sockaddr_in in a long running critical application? Disconnect current session, reconnect. Many proprietary protocols do not have the ability to checkpoint a connection and resume it on a different socket. It is not uncommon to require human intervention to retry a connection, or to have to redo all the work from scratch. It is also not uncommon for server applications to crash if their IP address is changed out from under them, or refuse to load with a new IP address. Applications that don't respect DNS TTLs are broken for many reasons, not just network renumbering. Since when is it the job of applications to manage DNS TTLs? It's not. However, many applications are coded to ask DNS once for each name and cache the result forever; this is a problem for long-lived processes, particularly servers, though it can even be seen in common web browsers. Some OSes include a caching resolver that has similar bugs. Some ISPs have caching nameservers that increase TTLs. All of those things are broken, of course. That doesn't change the fact they exist and folks in the operational community will not be impressed with a "solution" that ignores those problems. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
Thus spake "Spencer Dawkins" <[EMAIL PROTECTED]> My apologies for intruding, because I haven't been following the technology during the past couple of years, but V6OPS did an informational RFC on renumbering without a flag day (http://www.ietf.org/rfc/rfc4192.txt) in 2005. I thought the document was helpful when I last looked at it (prepublication). It's helpful in that it documents how to solve maybe a quarter to a half of the technology problems with renumbering. It doesn't solve a lot of other ones, including _any_ of the human problems. The human problems are easily 90% of the effort involved in renumbering. That many of those problems are self-imposed is irrelevant, since they are political problems, not technical problems, and thus outside the scope of the IETF's work. Perhaps better tools would make it easier to solve those political problems, but telling people that change control processes or security rules are "wrong" is just going to get you ignored. S Stephen Sprunk "God does not play dice." --Albert Einstein CCIE #3723 "God is an inveterate gambler, and He throws the K5SSSdice at every possible opportunity." --Stephen Hawking ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Call for action vs. lost opportunity (Was: Re: Renumbering)
> Are there any documents that give adoption instructions for > what are expected to be common scenarios? These would be > step-by-step cookbooks, with explanations for when they apply > and when they don't? There are lots and lots of documents in lots and lots of places. Many of them were written years ago and include deprecated stuff, such as 6bone. They are written from numerous points of view, i.e. enterprise, academic campus, Research & Education Network, European, etc. > Given the adoption hurdles IPv6 has been showing, then > efforts to both make it easy and publicize/document that it's > easy could be helpful. Yes. Given that the IPv4 exhaustion date is now within the planning horizon of ISPs, ARIN has set up a wiki at http://www.getipv6.info to document how to use IPv6. Since ARIN's audience is ISPs, this is taking the ISP point of view to the problem. For instance, if you are an end user, 6to4 is something that you configure to dip your toes in IPV6 and see how it works without touching existing IPv4 infrastructure. But for an ISP, 6to4 is a relay service that you configure in several routers to ensure that an end user's early experience with IPv6 is more positive and less likely to include high hop count, and high latency caused by trombone-shaped tunneling architecture. IMHO the type of document that Dave is talking about requires many authors. A wiki is well-suited to creating such documents. But it needs contributors who know something about IPv6 who will write up some of this cookbook material, or dust off old papers and presentations and copy the key bits, with corrections, into the wiki. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Tony Hain wrote: The fact that people -can- deploy IPv6 the same way they deploy IPv4 is a feature, not a requirement that they actually deploy it that way. Statements like yours only confuse people because they take it literally rather than in context that current deployments are not looking at the protocol differences beyond 'more bits'. Are there any documents that give adoption instructions for what are expected to be common scenarios? These would be step-by-step cookbooks, with explanations for when they apply and when they don't? We often create capabilities that are both easy to start using and quite flexibile in the considerable range of what they permit. Focus on the latter and things look too complicated. Focus only on the former and things look too limited. Easy to start using is great for initial adoption and immediate benefit. Given the adoption hurdles IPv6 has been showing, then efforts to both make it easy and publicize/document that it's easy could be helpful. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Call for action vs. lost opportunity (Was: Re: Renumbering)
David Conrad wrote: > Tony, > > On Sep 13, 2007, at 5:29 PM, Tony Hain wrote: > > David Conrad wrote: > >> > >> IPv6 _is_ IPv4 with more bits and it is being deployed that way. > > No it is not, and you need to stop claiming that because it > > confuses people > > into limiting their thinking to the legacy IPv4 deployment model. > > I'm not particularly interested in getting into a "Yes it is! No it > isn't!" debate. I will merely point out that IPv6 has been > implemented and is being deployed as IPv4 with more bits. As I said, > you can argue it shouldn't be this way, but reality often sucks. I am not looking for a never-ending debate either. What people are overlooking is that part of any viable transition plan is to allow people to deploy the new widget in a way that they understand and are comfortable with. The fact that people -can- deploy IPv6 the same way they deploy IPv4 is a feature, not a requirement that they actually deploy it that way. Statements like yours only confuse people because they take it literally rather than in context that current deployments are not looking at the protocol differences beyond 'more bits'. When people start from the perspective that 'the names both start with IP and they are both packet delivery systems but they are different protocols' then find the similarities, they are much better off than when they start from the 'just more bits' perspective. > > I might suggest that the reason why major core infrastructures like > the telephony system, utility grids, etc. are often hodgepodges of > hacks and kludges is because the business case to throw out > successful deployment models and existing plants is difficult to > make. And when you do, you generally want to insure a high level of > backwards compatibility so that you don't have to change everything > to make use of the new bits. Either you need backwards compatibility, or you need the ability to support both until the old systems die off naturally. There was plenty of time to support both for a graceful transition, but people seem to want to wait until they are forced to change before they start, so the actual shift will be ugly and costly. > > > There are way too many arguments > > (even on this list of relatively smart people) where the fundamental > > difference of simultaneous use of multiple addresses is the key to > > thinking > > differently between the versions. > > Can you point to one widely used application, API, or operating > system (that doesn't require manual intervention) that supports this? > The applications you are looking for can't exist or be economically supported in IPv4/nat, so they have yet to make it to the market place. That does not mean 'we must restrict IPv6 deployments to match IPv4', even if the initial deployments are happening that way. There is a strong tendency to only worry about supporting current applications, but we really need to be building a framework to allow new applications to appear that failed economically in the past. While IPv4 is a good protocol, the general attitude that 'if it can't be done with IPv4 it is not worth doing' needs to go away. Tony ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
On 2007-9-17, at 17:40, ext John Day wrote: Fast Select was a single packet that opened, transfered data, and closed a connection. The same as what Mr. Ford's description. What you outline above is very different from SST. I'm surprised that after reading the paper you'd think that there are strong similarities. Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
Fast Select was a single packet that opened, transfered data, and closed a connection. The same as what Mr. Ford's description. There was nothing remotely "transactional" about Fast Select. It was a direct counter to the proposal to put datagrams in X.25. It was a silly idea, then and it remains so. Deeper thinking about the nature of the problem would have yielded simpler results than SST. I do admit to taking a cheap shot at one of the more obvious weirdnesses in an amazingly weird paper as SIGCOMM continues to promulgate the groupthink, rather than break it. At 15:07 +0100 2007/09/17, Tony Finch wrote: On Mon, 17 Sep 2007, John Day wrote: I am afraid that I must agree with Fred. There is nothing very new in this paper and its publication is merely another indication of how far down the blind alley we have gone. I was surprised SIGCOMM even published dressing up X.25 Fast Select with fancy words. Amazing. Isn't Fast Select more like RFC 1644 TCP for Transactions than Ford's Structured Streams? IIUC, X.25 and SCTP have similarly static multiplexing configurations and delimited records, unlike SST. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
On Mon, 17 Sep 2007, John Day wrote: > I am afraid that I must agree with Fred. There is nothing very new in this > paper and its publication is merely another indication of how far down the > blind alley we have gone. I was surprised SIGCOMM even published dressing up > X.25 Fast Select with fancy words. Amazing. Isn't Fast Select more like RFC 1644 TCP for Transactions than Ford's Structured Streams? IIUC, X.25 and SCTP have similarly static multiplexing configurations and delimited records, unlike SST. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: session layers, was Re: Renumbering ... Should we consider an association thatspans transports?
This is not an academic institution. We do not as the founder of my Oxford
College put it, have to 'care more for novelty than for truth'.
What failed in 1980 may have failed because it was a bad idea or because it was
a good idea whose time has not yet come. Or it may have failed for no other
reason than a different choice was made.
> -Original Message-
> From: Fred Baker [mailto:[EMAIL PROTECTED]
> Sent: Monday, September 17, 2007 5:14 AM
> To: Lars Eggert
> Cc: ext Tony Finch; Keith Moore; IETF-Discussion
> Subject: Re: session layers,was Re: Renumbering ... Should we
> consider an association thatspans transports?
>
> Dumb question of the month. With the exception of the last
> claim ("...can prioritize..."), this could just as easily
> describe SCTP.
> What here is new? And define "prioritize"?
>
> On Sep 17, 2007, at 2:02 AM, Lars Eggert wrote:
> > You might be interested in Bryan Ford's SST paper from this year's
> > SIGCOMM:
> >
> > Structured Streams: a New Transport Abstraction. Bryan Ford. ACM
> > SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. http://
> > www.brynosaurus.com/pub/net/sst-abs.html
> >
> > Abstract: Internet applications currently have a choice
> between stream
> > and datagram transport abstractions. Datagrams efficiently support
> > small transactions and streams are suited for long-running
> > conversations, but neither abstraction adequately supports
> > applications like HTTP that exhibit a mixture of
> transaction sizes, or
> > applications like FTP and SIP that use multiple transport
> instances.
> > Structured Stream Transport (SST) enhances the traditional stream
> > abstraction with a hierarchical hereditary structure, allowing
> > applications to create lightweight child streams from any existing
> > stream. Unlike TCP streams, these lightweight streams incur neither
> > 3-way handshaking delays on startup nor TIME-WAIT periods on close.
> > Each stream offers independent data transfer and flow control,
> > allowing different transactions to proceed in parallel without
> > head-of-line blocking, but all streams share one congestion control
> > context. SST supports both reliable and best-effort
> delivery in a way
> > that semantically unifies datagrams with streams and solves the
> > classic “large datagram” problem, where a datagram's loss
> probability
> > increases exponentially with fragment count. Finally, an
> application
> > can prioritize its streams relative to each other and adjust
> > priorities dynamically through out-of-band signaling. A user-space
> > prototype shows that SST is TCP-friendly to within 2%, and performs
> > comparably to a user-space TCP and to within 10% of kernel TCP on a
> > WiFi network.
> >
> > Lars___
> > Ietf mailing list
> > Ietf@ietf.org
> > https://www1.ietf.org/mailman/listinfo/ietf
>
> ___
> Ietf mailing list
> Ietf@ietf.org
> https://www1.ietf.org/mailman/listinfo/ietf
>
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On 14 Sep 2007 at 09:38 -0400, Thomas Narten allegedly wrote: > David Conrad <[EMAIL PROTECTED]> writes: > > As I have said elsewhere, I've come to believe that one of the > > fundamental failures of the IETF is that it permits or even > > encourages protocol design to be directed by corner cases. But corner cases do need to be considered. If nothing else they inform the design. If there is a process failure, it's a failure to correctly evaluate the significance of the corner cases considered. Coming up with the corner cases is clever, but figuring out which ones to take seriously is harder, as it requires accurately predicting technological, cultural, political and economic futures. We could use some more capability there. > This is sometimes very true. But I disagree that this is the reason > we haven't done an ID/Loc split yet. At the end of the day, we have > yet to see a real design fleshed out in enough detail that folk can > honestly say "yep, I think we can make this work in practice and I > think I understand how the pieces will all fit together". And I'm > talking about _all_ the pieces, not just the 80% that are the > easiest and we know how to do. Agree (but we're trying for the next 5%). > > Actually, I suspect if the work were to happen in the IRTF, it would > > be doomed. The IRTF is, after all, focused on research. > > If there is engineering work to do, make the case it is ready for the > IETF. Personally, I think the ID/Loc work is still in that gray area > between engineering and research. Ready for engineering means we know > how to do it, there are no hard problems to still work out. We just > need to agree on a standard way to do something. > > On the other hand, if we don't know how to do a scalable mapping > part yet, that sounds like research to me. (Insert long-running > discussion here about how DNS is or is not good enough to provide > this functionality.) I prefer to keep things out of WGs until we know what it is we're supposed to *engineer*, or at least until figuring that out won't take long. > > I can imagine the people in the IRTF contributing towards a solution > > but that isn't where a solution will come from. Given real world > > constraints, a solution will come from engineers (protocol, network, > > hardware, and/or software), singly or working together, coming up > > with an approach that meets real world requirements (not what > > researchers believe are real world requirements). It almost > > certainly won't be architecturally pure and it probably won't be > > pretty, but it will probably meet commercial and operational needs. > > Yep. But I would hope that the research side can do the work that > leads to answering the previous question with an answer of "yep, I > think we know how to this and can make it work and just need to agree > on the bits." It's a continuum. RRG is full of people who consider themselves engineers and who participate in the IETF as well. swb ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
I am afraid that I must agree with Fred. There is nothing very new
in this paper and its publication is merely another indication of how
far down the blind alley we have gone. I was surprised SIGCOMM even
published dressing up X.25 Fast Select with fancy words. Amazing.
At 2:13 -0700 2007/09/17, Fred Baker wrote:
Dumb question of the month. With the exception of the last claim
("...can prioritize..."), this could just as easily describe SCTP.
What here is new? And define "prioritize"?
On Sep 17, 2007, at 2:02 AM, Lars Eggert wrote:
You might be interested in Bryan Ford's SST paper from this year's SIGCOMM:
Structured Streams: a New Transport Abstraction. Bryan Ford. ACM
SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan.
http://www.brynosaurus.com/pub/net/sst-abs.html
Abstract: Internet applications currently have a choice between
stream and datagram transport abstractions. Datagrams efficiently
support small transactions and streams are suited for long-running
conversations, but neither abstraction adequately supports
applications like HTTP that exhibit a mixture of transaction sizes,
or applications like FTP and SIP that use multiple transport
instances. Structured Stream Transport (SST) enhances the
traditional stream abstraction with a hierarchical hereditary
structure, allowing applications to create lightweight child
streams from any existing stream. Unlike TCP streams, these
lightweight streams incur neither 3-way handshaking delays on
startup nor TIME-WAIT periods on close. Each stream offers
independent data transfer and flow control, allowing different
transactions to proceed in parallel without head-of-line blocking,
but all streams share one congestion control context. SST supports
both reliable and best-effort delivery in a way that semantically
unifies datagrams with streams and solves the classic "large
datagram" problem, where a datagram's loss probability increases
exponentially with fragment count. Finally, an application can
prioritize its streams relative to each other and adjust priorities
dynamically through out-of-band signaling. A user-space prototype
shows that SST is TCP-friendly to within 2%, and performs
comparably to a user-space TCP and to within 10% of kernel TCP on a
WiFi network.
Lars___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
Hi Lars,
comment in-line.
Best regards
Michael
On Sep 17, 2007, at 12:11 PM, Lars Eggert wrote:
On 2007-9-17, at 12:13, ext Fred Baker wrote:
Dumb question of the month. With the exception of the last claim
("...can prioritize..."), this could just as easily describe SCTP.
What here is new? And define "prioritize"?
For how this relates to SCTP, let me refer you to Section 6. (And
yes, there are obvious similarities here to SCTP, but also RFC2140-
like integrated congestion control, etc.)
"Prioritize" meaning how a sender allocates the available path
capacity for the SST "bundle" between connection instances. A demo
that Bryan did that showed HTTP over SST dynamically adjusted
priorities such that objects that were being rendered on the screen
were transmitted at a higher priority, even while scrolling around
a large page.
The SCTP sender can handle multiple messages in different stream send
queues in different ways.
I call the selection function the "stream scheduling function". Using
different scheduling
functions at the sender side you can get different "fairness
concepts". Message based
round robin would get the fairness concept of having the same number
of messages in each
stream, doing a weighted fair queueing based scheduler you can share
the bandwidth equally
between the different streams and so on. Priorities are also simple
to implement and have
an analysed in
http://www.cis.udel.edu/~amer/PEL/poc/pdf/sci2004-heinz-SCTP-
Prioritized-Multistreaming.pdf
The nice thing with the scheduling function is: it is a sender only
thing. The receiver has
to follow some simple rules, which almost all SCTP implementation do
anyway.
On Sep 17, 2007, at 2:02 AM, Lars Eggert wrote:
You might be interested in Bryan Ford's SST paper from this
year's SIGCOMM:
Structured Streams: a New Transport Abstraction. Bryan Ford. ACM
SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. http://
www.brynosaurus.com/pub/net/sst-abs.html
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
On 2007-9-17, at 12:13, ext Fred Baker wrote:
Dumb question of the month. With the exception of the last claim
("...can prioritize..."), this could just as easily describe SCTP.
What here is new? And define "prioritize"?
For how this relates to SCTP, let me refer you to Section 6. (And
yes, there are obvious similarities here to SCTP, but also RFC2140-
like integrated congestion control, etc.)
"Prioritize" meaning how a sender allocates the available path
capacity for the SST "bundle" between connection instances. A demo
that Bryan did that showed HTTP over SST dynamically adjusted
priorities such that objects that were being rendered on the screen
were transmitted at a higher priority, even while scrolling around a
large page.
On Sep 17, 2007, at 2:02 AM, Lars Eggert wrote:
You might be interested in Bryan Ford's SST paper from this year's
SIGCOMM:
Structured Streams: a New Transport Abstraction. Bryan Ford. ACM
SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. http://
www.brynosaurus.com/pub/net/sst-abs.html
smime.p7s
Description: S/MIME cryptographic signature
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
Dumb question of the month. With the exception of the last claim
("...can prioritize..."), this could just as easily describe SCTP.
What here is new? And define "prioritize"?
On Sep 17, 2007, at 2:02 AM, Lars Eggert wrote:
You might be interested in Bryan Ford's SST paper from this year's
SIGCOMM:
Structured Streams: a New Transport Abstraction. Bryan Ford. ACM
SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. http://
www.brynosaurus.com/pub/net/sst-abs.html
Abstract: Internet applications currently have a choice between
stream and datagram transport abstractions. Datagrams efficiently
support small transactions and streams are suited for long-running
conversations, but neither abstraction adequately supports
applications like HTTP that exhibit a mixture of transaction sizes,
or applications like FTP and SIP that use multiple transport
instances. Structured Stream Transport (SST) enhances the
traditional stream abstraction with a hierarchical hereditary
structure, allowing applications to create lightweight child
streams from any existing stream. Unlike TCP streams, these
lightweight streams incur neither 3-way handshaking delays on
startup nor TIME-WAIT periods on close. Each stream offers
independent data transfer and flow control, allowing different
transactions to proceed in parallel without head-of-line blocking,
but all streams share one congestion control context. SST supports
both reliable and best-effort delivery in a way that semantically
unifies datagrams with streams and solves the classic “large
datagram” problem, where a datagram's loss probability increases
exponentially with fragment count. Finally, an application can
prioritize its streams relative to each other and adjust priorities
dynamically through out-of-band signaling. A user-space prototype
shows that SST is TCP-friendly to within 2%, and performs
comparably to a user-space TCP and to within 10% of kernel TCP on a
WiFi network.
Lars___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
On 2007-9-14, at 21:54, ext Tony Finch wrote: On Fri, 14 Sep 2007, Keith Moore wrote: I actually don't think that having multiple concurrent TCP connections between two peers is a bad thing. sure we could have a transport protocol that provided multiple streams, but why bother when concurrent TCP connections works pretty well? I agree, except that "pretty well" is a bit crappy when every connection has to re-establish authentication and encryption - which is what drives some protocols to implement their own multiplexing. mumble. I don't have a problem with multiple TCP connections, but OTOH I think that using TCP close for framing is bad application design. so I don't view persistent connections in HTTP as a workaround, I view it as fixing a design flaw in HTTP/1.0. I agree, especially because some software has problems telling the difference between clean and dirty closes. However there's a latency / efficiency trade-off, and TCP pushes you towards pipelining multiple transactions down a few connections even when a more natural design might have greater concurrency. mumble. You might be interested in Bryan Ford's SST paper from this year's SIGCOMM: Structured Streams: a New Transport Abstraction. Bryan Ford. ACM SIGCOMM 2007, August 27-31, 2007, Kyoto, Japan. http:// www.brynosaurus.com/pub/net/sst-abs.html Abstract: Internet applications currently have a choice between stream and datagram transport abstractions. Datagrams efficiently support small transactions and streams are suited for long-running conversations, but neither abstraction adequately supports applications like HTTP that exhibit a mixture of transaction sizes, or applications like FTP and SIP that use multiple transport instances. Structured Stream Transport (SST) enhances the traditional stream abstraction with a hierarchical hereditary structure, allowing applications to create lightweight child streams from any existing stream. Unlike TCP streams, these lightweight streams incur neither 3- way handshaking delays on startup nor TIME-WAIT periods on close. Each stream offers independent data transfer and flow control, allowing different transactions to proceed in parallel without head- of-line blocking, but all streams share one congestion control context. SST supports both reliable and best-effort delivery in a way that semantically unifies datagrams with streams and solves the classic “large datagram” problem, where a datagram's loss probability increases exponentially with fragment count. Finally, an application can prioritize its streams relative to each other and adjust priorities dynamically through out-of-band signaling. A user-space prototype shows that SST is TCP-friendly to within 2%, and performs comparably to a user-space TCP and to within 10% of kernel TCP on a WiFi network. Lars smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On 14-sep-2007, at 22:34, Greg Skinner wrote: When routing connectivity could be restored quickly, the maintained state at both ends of the TCP connection would allow the application to proceed normally. However, this practice doesn't seem to have made it into the application-writing community at large, because lots of applications fail for just this reason. What I experienced is that when logged in to a Unix machine from a Windows machine, if the address went away or the connectivity was lost and an ICMP unreachable came back, the Windows box would terminate the session, while pretty much everything else would keep the session alive for some time so you could put the address back / restore connectivity and the session was still there if the other side hand't timed out / reset. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Call for action vs. lost opportunity (Was: Re: Renumbering)
> I wonder if even > writing a BCP about this even makes sense at this point, > because the application writers (or authors of the references > the application writers use) may never see the draft, or even > be concerned that it's something they should check for. I think that it does make sense to write a draft because the growing effort to roll out IPv6 is causing lots of people to review their applications and how they communicate on the network. I would expect that some percentage of those applications would end up being changed if such a draft were available. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Call for action vs. lost opportunity (Was: Re: Renumbering)
> I'm not particularly interested in getting into a "Yes it is! > No it isn't!" debate. I will merely point out that IPv6 has > been implemented and is being deployed as IPv4 with more > bits. If more people would get involved in developing a best practices document for IPv6, perhaps through a wiki like www.getipv6.info then this would be less of a problem. We need some document to point to in order to explain why IPv6 is not just IPv4 with more bits. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Renumbering
I have to say that this latest thread about renumbering has been entertaining; besides the usual trolls I have never seen as many un-experienced, incompetent, or both, contributors who think just because they have read something about it in a magazine while waiting at the dentist entitles them to an opinion. And no, I don't have to be politically correct. Unlike most of the bozos mentioned above, I have actually been in the trenches renumbering real-world networks. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> From: Greg Skinner <[EMAIL PROTECTED]>
> It seemed like a reasonable thing to do to treat something like a net
> or host unreachable as a transient condition ...
> However, this practice doesn't seem to have made it into the
> application-writing community at large, because lots of applications
> fail for just this reason.
Then they are violating an explicit MUST in RFC-1122 ("Requirements for
Internet Hosts -- Communication Layers", October 1989), which says:
3.2.2.1 Destination Unreachable
A Destination Unreachable message that is received with code 0 (Net), 1
(Host), or 5 (Bad Source Route) may result from a routing transient and
MUST therefore be interpreted as only a hint, not proof, that the specified
destination is unreachable
This problem (people interpreting Unreachables as hard errors) was a problem
back then, 20 years ago, which is why we put that text in the RFC.
> I wonder if even writing a BCP about this even makes sense at this
> point, because the application writers (or authors of the references
> the application writers use) may never see the draft, or even be
> concerned that it's something they should check for.
I agree that it may be a waste of time, because they are *already* disobeying
an explicit requirements RFC.
Noel
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On Fri, Sep 14, 2007 at 07:48:45AM -0400, Keith Moore wrote: > [sorry, lost attribution here] > > TCP protects you from lots of stuff, but it doesn't really let you > > recover from the remote endpoint rebooting, for example... > well, duh. if the endpoint fails then all of the application-level > state goes away. TCP can't be responsible for recovering from the loss > of higher-level state. but we're not talking about endpoint failures, > we're talking about the failure of the network. TCP is supposed to > recover from transient network failures. it wasn't designed to cope > with endpoint address changes, of course, because the network as > designed wasn't expected to fail in that way. When I was first learning about networking back in the mid-1980s, I worked on a project involving mobile hosts. The hosts were permitted to change their IP addresses, but TCP-level connectivity needed to remain intact. The loss of a route to some network (or host within that network) might trigger an ICMP unreachable, but the applications (e.g. telnet, ftp) needed to be rewritten not to close in such a situation. It seemed like a reasonable thing to do to treat something like a net or host unreachable as a transient condition, and allow the application to proceed as if nothing serious had happened. When routing connectivity could be restored quickly, the maintained state at both ends of the TCP connection would allow the application to proceed normally. However, this practice doesn't seem to have made it into the application-writing community at large, because lots of applications fail for just this reason. I wonder if even writing a BCP about this even makes sense at this point, because the application writers (or authors of the references the application writers use) may never see the draft, or even be concerned that it's something they should check for. > > (And something that's common in today's IPv4 deployments: NAT > > timeouts. I got bitten by that in Chicago, I think they were only a > > few minutes in my hotel, drove me insane because anything other than > > HTTP didn't work for long.) > given that NATs violate the most fundamental assumption behind IP (that > an address means the same thing everywhere in the network), it's hardly > surprising that they break TCP. After installing a NAT firewall/router, I noticed my ssh connections would drop when left idle for awhile. That never happened before -- I could go away from my machine for hours, and as long as client and server machines were up, with no network dynamics, everything would work fine when I returned. But is it TCP itself that's failing, or ssh interpreting the timeout as a non-transient condition, and telling TCP to close? I think a reasonable compromise for application writers who are concerned about allocating resources to connections that might really need to close (e.g. because the remote end really did crash, or there was a really long timeout), is to allow the user to specify the behavior for the application to take when a level 3 error condition occurs. --gregbo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
David, David Conrad wrote: That sort of equivalence statement applies when the new version is a minor upgrade to the previous, rather than require massive changes to the infrastructure AND to client applications. Having to run parallel stacks, having substantial changes to administration and operations, I believe that _if_ there was IPv6 support in network management, provisioning, back end systems, CPE, router ASICs, etc., there wouldn't A rather large IF, don't you think? Something like "IF everyone in the world wanted peace, peace would be easy to achieve." That's the lesson of the installed base: Making a change to the infrastructure is ALWAYS a very big deal indeed. Unless I've missed something rather basic, in the case of IPv6, very little attention was paid to facilitating transition by maximizing interoperability with the IPv4 installed base. need to be significant change to administration or operation. You would obviously need to change systems to deal with 128 bit values in ACLs and filters, etc., but that should be a simple SMOP. In terms of Programming tends to be the smallest issue for large scale transitions. Admin and ops tend to be the large concerns. So once your SMOP is taken care of, there is the not-so SMO admin and ops for the entire Internet, with what seems to be little incremental benefit for incremental adoption. Incremental benefit for incremental adoption has typically been the key to gaining large-scale adoption, particularly for improvements to an entrenched service. Of course what turns out to be a big deal is getting to the point where that starting "if" statement passes. Right. However, the point of my statement is that in reality, IPv6 must be treated pretty much the same as the thing is it attempting to replace. In a standalone sense, perhaps. That is, in terms of conceptual issues, perhaps. Alas, since you are in the ops world, you know that there is rather a large difference between concept and practice. IPv6 must modify decades of installed base software, management and use and it is pursuing this as a wholly parallel software, admin and ops effort. and having major changes to the minimum required set of capabilities is more than just a few more bits. Can you give an example of what you mean by this? I'd be glad to be disabused of this understanding: IPv6 is is pursuing this as a wholly parallel software, admin and ops effort. That it re-uses some code is nice but isn't the issue. *Entirely new IP Address allocations, starting with an RIR, moving on to all infrastructure entries and including DNS, and parallel operations of such things as routing, Neighbor Discovery protocols, IPv6 Stateless Address Autoconfiguration, ICMP. (Maybe more?) * Dual, simultaneous admin and ops activities, for IPv4 and IPv6. That's a big deal. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: session layers, was Re: Renumbering ... Should we consider an association that spans transports?
On Fri, 14 Sep 2007, Keith Moore wrote: > > I actually don't think that having multiple concurrent TCP connections > between two peers is a bad thing. sure we could have a transport > protocol that provided multiple streams, but why bother when concurrent > TCP connections works pretty well? I agree, except that "pretty well" is a bit crappy when every connection has to re-establish authentication and encryption - which is what drives some protocols to implement their own multiplexing. > mumble. I don't have a problem with multiple TCP connections, but OTOH > I think that using TCP close for framing is bad application design. so > I don't view persistent connections in HTTP as a workaround, I view it > as fixing a design flaw in HTTP/1.0. I agree, especially because some software has problems telling the difference between clean and dirty closes. However there's a latency / efficiency trade-off, and TCP pushes you towards pipelining multiple transactions down a few connections even when a more natural design might have greater concurrency. mumble. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Bill, On Sep 14, 2007, at 2:15 AM, Bill Manning wrote: On Thu, Sep 13, 2007 at 05:29:39PM -0700, Tony Hain wrote: IPv6 _is_ IPv4 with more bits and it is being deployed that way. beating this dead horse... The official IETF state sport. actually, David is profoundly wrong. Frequently. IPv6 is an entirely new address family - it has erie similarities to IPv4, but is not backward compatable. The "with more bits" part wasn't an offhand comment. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On Sep 13, 2007, at 6:01 PM, Fred Baker wrote: What would be Really Nice would be to in some way ensure that applications never saw IP addresses at all - they *only* worked on names, and maintained no knowledge in the application of what address was used. I always thought an opportunity was missed when coming up with the socket interface for IPv6 in that we didn't push the management of the address down to the kernel, having the kernel return a 'handle' (like a file handle) in struct sockaddr_in instead of the bit pattern that was actually used on the network. We might even have been able to use the class E address space as the handle thereby making the upgrade to IPv6 much more transparent to applications than it is now. Water under the bridge. Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Dave, On Sep 13, 2007, at 5:43 PM, Dave Crocker wrote: David Conrad wrote: IPv6 _is_ IPv4 with more bits and it is being deployed that way. That sort of equivalence statement applies when the new version is a minor upgrade to the previous, rather than require massive changes to the infrastructure AND to client applications. Having to run parallel stacks, having substantial changes to administration and operations, I believe that _if_ there was IPv6 support in network management, provisioning, back end systems, CPE, router ASICs, etc., there wouldn't need to be significant change to administration or operation. You would obviously need to change systems to deal with 128 bit values in ACLs and filters, etc., but that should be a simple SMOP. In terms of provisioning, the only change that _might_ be necessary is changing the default customer allocation from a /28 (or whatever) to a /48. This might imply a change in some aspects of business models for those folks who charge extra for IP addresses, but I can't really see that as being that big a deal. Of course what turns out to be a big deal is getting to the point where that starting "if" statement passes. However, the point of my statement is that in reality, IPv6 must be treated pretty much the same as the thing is it attempting to replace. If not, you're requiring 1 billion people to change the way they do things and we have given them (a) no reason to and (b) no real tools to do it. This won't work. and having major changes to the minimum required set of capabilities is more than just a few more bits. Can you give an example of what you mean by this? Thanks, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Tony, On Sep 13, 2007, at 5:29 PM, Tony Hain wrote: David Conrad wrote: IPv6 _is_ IPv4 with more bits and it is being deployed that way. No it is not, and you need to stop claiming that because it confuses people into limiting their thinking to the legacy IPv4 deployment model. I'm not particularly interested in getting into a "Yes it is! No it isn't!" debate. I will merely point out that IPv6 has been implemented and is being deployed as IPv4 with more bits. As I said, you can argue it shouldn't be this way, but reality often sucks. I might suggest that the reason why major core infrastructures like the telephony system, utility grids, etc. are often hodgepodges of hacks and kludges is because the business case to throw out successful deployment models and existing plants is difficult to make. And when you do, you generally want to insure a high level of backwards compatibility so that you don't have to change everything to make use of the new bits. There are way too many arguments (even on this list of relatively smart people) where the fundamental difference of simultaneous use of multiple addresses is the key to thinking differently between the versions. Can you point to one widely used application, API, or operating system (that doesn't require manual intervention) that supports this? Regards, -drc ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
Tony Finch wrote: > On Thu, 13 Sep 2007, Keith Moore wrote: > > >> Offhand I don't know why it should be necessary to build a mechanism >> that spans several transport lifetimes. >> > > TLS session caches. HTTP cookies. FTP control connections. > okay fine (at least for the first two) but should that information be managed by the application, or at a lower layer? particularly if it needs to be shared among multiple instances of a service that may reside on different hosts? > Apps that want to deal with concurrent data streams within one user's > session currently have to establish and authenticate multiple TCP > connections (e.g. HTTP, IMAP) or re-implement TCP's multiplexing and > windowing at the application level (e.g. BEEP, ssh). > I actually don't think that having multiple concurrent TCP connections between two peers is a bad thing. sure we could have a transport protocol that provided multiple streams, but why bother when concurrent TCP connections works pretty well? > A session layer would allow an app to establish a security context once > then re-use it when establishing new transport connections, so that > re-connecting can be cheap and concurrent data streams can be simple. > Unfortunately TCP doesn't share congestion information between > connections, which penalises new bulk-data streams and requires > workarounds at the application level (e.g. HTTP/1.1 persistent > connections). > mumble. I don't have a problem with multiple TCP connections, but OTOH I think that using TCP close for framing is bad application design. so I don't view persistent connections in HTTP as a workaround, I view it as fixing a design flaw in HTTP/1.0. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On Thu, 13 Sep 2007, David Conrad wrote: > On Sep 13, 2007, at 11:43 AM, Tony Finch wrote: > > On Thu, 13 Sep 2007, David Conrad wrote: > > > > > > How do you renumber the IP address stored in the struct sockaddr_in in a > > > long running critical application? > > > > Applications that don't respect DNS TTLs are broken for many reasons, not > > just network renumbering. > > Then pretty much every IP-aware application ever written is broken. Not entirely. Applications that use short-lived connections are generally OK (so long as the implementation talks to its resolver in a sensible way - many screw this up). This covers HTTP and most email protocols. Many apps with long-lived TCP connections can recover OK from a broken connection. Long-lived UDP associations can be a problem - renumbering an NTP server is a pain. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering ... Should we consider an association that spans transports?
On Thu, 13 Sep 2007, Keith Moore wrote: > Offhand I don't know why it should be necessary to build a mechanism > that spans several transport lifetimes. TLS session caches. HTTP cookies. FTP control connections. Apps that want to deal with concurrent data streams within one user's session currently have to establish and authenticate multiple TCP connections (e.g. HTTP, IMAP) or re-implement TCP's multiplexing and windowing at the application level (e.g. BEEP, ssh). A session layer would allow an app to establish a security context once then re-use it when establishing new transport connections, so that re-connecting can be cheap and concurrent data streams can be simple. Unfortunately TCP doesn't share congestion information between connections, which penalises new bulk-data streams and requires workarounds at the application level (e.g. HTTP/1.1 persistent connections). (I have been thinking along similar lines to Karl.) Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
David Conrad <[EMAIL PROTECTED]> writes: > Do you believe IPv4 (or ANY other successful large scale technology), > when it was designed, had all the little details worked out? No, of course not. But the analogy is misleading, IMO. When IPv4 was designed, it was used by a _very_ small set of players and very few people really depended on it. Making changes was easier. Experimenting with a "play" system is always easier. Today, the Internet is part of the world's basic infrastructure. We're kind of past the point of being able to say "let's just bet the farm on this, and see if we can work out the open issues later". > As I have said elsewhere, I've come to believe that one of the > fundamental failures of the IETF is that it permits or even > encourages protocol design to be directed by corner cases. This is sometimes very true. But I disagree that this is the reason we haven't done an ID/Loc split yet. At the end of the day, we have yet to see a real design fleshed out in enough detail that folk can honestly say "yep, I think we can make this work in practice and I think I understand how the pieces will all fit together". And I'm talking about _all_ the pieces, not just the 80% that are the easiest and we know how to do. > In this particular case, it isn't even clear to me there is > agreement on what the problem we're trying to solve actually is. Yes, this is a key issue (like in so many cases). People are all over the map in terms of (picking ID/loc as an example), how frequently the mapping needs to be able to change. Once a week? Every few minutes? Quickly enough for mobility, etc. These sorts of questions are critical to answer before focussing too much on solutions. > > And we have a place for that work to happen in the IRTF. > Actually, I suspect if the work were to happen in the IRTF, it would > be doomed. The IRTF is, after all, focused on research. If there is engineering work to do, make the case it is ready for the IETF. Personally, I think the ID/Loc work is still in that gray area between engineering and research. Ready for engineering means we know how to do it, there are no hard problems to still work out. We just need to agree on a standard way to do something. On the other hand, if we don't know how to do a scalable mapping part yet, that sounds like research to me. (Insert long-running discussion here about how DNS is or is not good enough to provide this functionality.) > I can imagine the people in the IRTF contributing towards a solution > but that isn't where a solution will come from. Given real world > constraints, a solution will come from engineers (protocol, network, > hardware, and/or software), singly or working together, coming up > with an approach that meets real world requirements (not what > researchers believe are real world requirements). It almost > certainly won't be architecturally pure and it probably won't be > pretty, but it will probably meet commercial and operational needs. Yep. But I would hope that the research side can do the work that leads to answering the previous question with an answer of "yep, I think we know how to this and can make it work and just need to agree on the bits." Thomas ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Call for action vs. lost opportunity (Was: Re: Renumbering)
> given that NATs violate the most fundamental assumption > behind IP (that an address means the same thing everywhere in > the network), it's hardly surprising that they break TCP. Has RFC 2526 been deprecated? -- Michael Dillon P.S. RFC 2526 - Reserved IPv6 Subnet Anycast Addresses ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
>> What we'd really need is a RR type specifically intended to map >> service names onto instance ID+address pairs, and also a special >> query type that wasn't defined to return all of the matching RR >> records, but would instead return a random subset or a subset based >> on heuristics, and finally an instance ID to address mapping service. > Once again, I don't see why this would be a valid requirement. > > And as I understand it, people who need this today typically host a > service behind a single address and use a load balancer to spread > incoming requests over a set of servers in such a way that the same > client returns to the same server. yes, that's typically how it's done today, because it tends to work better than playing games with DNS. Though part (not all) of the reason it works better is that DNS wasn't designed to support this. >>> Applications need to deal with TCP connections breaking for all >>> sorts of reasons. Renumbering should be a relatively infrequent >>> event compared to all the other possible ways a TCP connection can >>> fail. >> Mumble. Seems like the whole point of TCP was to recover from such >> failures at a lower level. > TCP protects you from lots of stuff, but it doesn't really let you > recover from the remote endpoint rebooting, for example... well, duh. if the endpoint fails then all of the application-level state goes away. TCP can't be responsible for recovering from the loss of higher-level state. but we're not talking about endpoint failures, we're talking about the failure of the network. TCP is supposed to recover from transient network failures. it wasn't designed to cope with endpoint address changes, of course, because the network as designed wasn't expected to fail in that way. > (And something that's common in today's IPv4 deployments: NAT > timeouts. I got bitten by that in Chicago, I think they were only a > few minutes in my hotel, drove me insane because anything other than > HTTP didn't work for long.) given that NATs violate the most fundamental assumption behind IP (that an address means the same thing everywhere in the network), it's hardly surprising that they break TCP. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
hmm. I'm not sure you're talking about the same thing. DNS is a rendezvous protocol. I I want to open a session with , I translate 's name to an adddress and open a TCP connection. Having done so, the application doesn't need either the name or the address as long as the session is stable. It uses its socket. Now, if the session takes a hike, there are issues. If you're using SCTP, those are relatively fixable (draft-ietf-tsvwg-addip-sctp); in TCP, at least at this point, one closes and reopens the socket with a new address. What is needed is knowledge of the new address, which in the internet draft comes from the peer through the socket. So in SCTP there actually is a solution, and DNS TTLs are not relevant to the question. Yes, if the name is retained and not re-translated on a session failure even though the TTL has expired, that's a problem. It's a different problem. On Sep 13, 2007, at 10:43 PM, Tony Finch wrote: On Thu, 13 Sep 2007, David Conrad wrote: How do you renumber the IP address stored in the struct sockaddr_in in a long running critical application? Applications that don't respect DNS TTLs are broken for many reasons, not just network renumbering. Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ IRISH SEA: SOUTHERLY, BACKING NORTHEASTERLY FOR A TIME, 3 OR 4. SLIGHT OR MODERATE. SHOWERS. MODERATE OR GOOD, OCCASIONALLY POOR. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Renumbering
> I remember Bill Clinton describing trying to develop an Internet standard like 'nailing jello to the wall'. Actually he said that trying to censor the Internet was like trying to nail jello to the wall. See the press release from the U.S. Embassy in China where he made the remark in the context of the Great Firewall of China. http://www.usembassy-china.org.cn/press/release/2000/clinton38.html With hindsight, and knowing the many ways in which people have subverted the Great Firewall he was quite right. In the IETF context, I think it proves the rule of "be conservative about what you send, be liberal about what you accept" because the jello comes from the way people actually use IETF technology in the real world. The IETF is incapable of designing a solution to a problem. We can only design protocols which create possibilities for the real solution designers to leverage. Engineers like to have end-to-end control of a problem in order to design end-to-end solutions but that is often not possible in the real world, and especially not possible when your work is restricted to the vicinity of layer 3. --Michael Dillon ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On Thu, Sep 13, 2007 at 05:29:39PM -0700, Tony Hain wrote:
> David Conrad wrote:
> >
> > IPv6 _is_ IPv4 with more bits and it is being deployed that way.
>
> No it is not, and you need to stop claiming that because it confuses people
> into limiting their thinking to the legacy IPv4 deployment model.
>
... {elided}
>
> If there is research to do towards this, it will be in the arena of social
> engineering. Once it is clear how to stop operators from deciding the most
> expedient thing to do is embed the current IP address into some
> configuration, then engineering can build the tool to enforce that. It is
> very difficult to get people to realize that the accumulation of short term
> cost savings will turn on them as a sizable cost when changes become
> necessary.
>
> Tony
beating this dead horse...
actually, David is profoundly wrong. IPv6 is an entirely
new address family - it has erie similarities to IPv4, but
is not backward compatable.
--bill
Opinions expressed may not even be mine by the time you read them, and
certainly don't reflect those of any other entity (legal or otherwise).
___
Ietf mailing list
Ietf@ietf.org
https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On 14-sep-2007, at 5:34, Keith Moore wrote: What we'd really need is a RR type specifically intended to map service names onto instance ID+address pairs, and also a special query type that wasn't defined to return all of the matching RR records, but would instead return a random subset or a subset based on heuristics, and finally an instance ID to address mapping service. Once again, I don't see why this would be a valid requirement. And as I understand it, people who need this today typically host a service behind a single address and use a load balancer to spread incoming requests over a set of servers in such a way that the same client returns to the same server. Applications need to deal with TCP connections breaking for all sorts of reasons. Renumbering should be a relatively infrequent event compared to all the other possible ways a TCP connection can fail. Mumble. Seems like the whole point of TCP was to recover from such failures at a lower level. TCP protects you from lots of stuff, but it doesn't really let you recover from the remote endpoint rebooting, for example... (And something that's common in today's IPv4 deployments: NAT timeouts. I got bitten by that in Chicago, I think they were only a few minutes in my hotel, drove me insane because anything other than HTTP didn't work for long.) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Renumbering
On Thu, Sep 13, 2007 at 07:43:38PM +0100, Tony Finch wrote: > On Thu, 13 Sep 2007, David Conrad wrote: > > > > How do you renumber the IP address stored in the struct sockaddr_in in a > > long running critical application? > > Applications that don't respect DNS TTLs are broken for many reasons, not > just network renumbering. > > Tony. I know of one application that relied on long-lived DNS hostname to IP mappings and ignored DNS TTLs. Search engine crawlers cached the IP addresses for pages that had been fetched, and used those addresses even though the TTLs had expired. This resulted in pages from whatever content lived at those new IP addresses showing up unexpectedly (incorrectly) in search engine results. I don't know if this has been fixed, but it's an example of application usage that bypassed IETF recommendations for a presumably good cause (performance reasons). Another application with a similar reliance that is seeing some growth is the use of IP addresses for geotargeting. The geotargeting provider attempts to determine the physical location of the IP address for various purposes, such as to choose what ads to display. I imagine people on this list can see the flaws of doing this, but nevertheless it persists. I don't know how the geotargeting providers plan to handle IPv6, but it's another example of how people develop applications in ways that the IETF may not anticipate (because they discourage such applications), but make migration to IPv6 difficult because of the installed base that depends upon specific uses of IPv4 addresses. --gregbo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
>> I also don't have a lot of faith in "should be", not when I've seen DHCP >> servers routinely refuse to renew leases after very short times, nor >> when I've heard people say that a site should be able to renumber every >> day. >> > > So, someone misconfigured something. Such misconfigurations > usually get fixed fast. > In all of the cases where I've seen the DHCP thing happen, it was deliberate. And no, stupid network admins do not get fixed quickly. At least, not as a general rule. The Peter Principle applies here as to that profession as any other. "address leasing" is one of the fundamental design flaws of DHCP. Of course, that's also water under the bridge. > Getting the automation to the state where a daily renumber > is possible is an achievable goal. If we were doing that > the long running apps would have been fixed long ago. And if we could make the sun run backwards then we wouldn't need streetlights. Never mind those people on the other side of the world... You want to make applications be slower, less reliable, and more complex in order to make routing easier. It's understandable that you might feel that way, but don't expect everyone else to go along with it. Now if you find a way to solve the problems you are concerned about, while also providing a truly viable solution for others, Then we might make some progress. But mere handwaving won't cut it. You have to make a convincing case that your solution is comprehensive. > The > fact that they aren't is more a matter of pressure than > anything else. That's why I started with a large period > when I was suggesting that router and firewall vendors > actually renumber themselves periodically. It was to keep > the problem in the management space rather than the application > space. > Yes, but firewall and router boxes are relatively easy to renumber, because there are a smaller number of vendors and a smaller number of interfaces. Apps are much harder because they are so diverse. > Have each vendor work on their part of the problem is the > way to go. > Lots of apps vendors out there would have to come to some sort of agreement. Any purported solution had better be very versatile. Of course, a lot of the problem is a security problem. Find a decent (efficient, mostly reliable, easy to configure, and works across administrative domain boundaries) way for hosts and nets to quickly distinguish trustworthy traffic from untrustworthy traffic without using IP addresses and you'd probably decrease application configuration of addresses by an order of magnitude, maybe two. (and also note that any renumbering scheme can't been seen as weakening the relationship between IP address and trustworthiness - that relationship is already too weak as it is, but people will cling to it until there's something better) >> I used to try to get people to specify a minimum amount of time that a >> non-deprecated address should be expected to be valid - say a day. Then >> application writers and application protocol designers would have an >> idea about whether they needed a strategy for recovery from a >> renumbering event, and what kind of strategy they needed. But the only >> people who seemed to like this idea were application area people. >> >>> Until applications deal nicely with the other failure modes, >>> complaints about renumbering causing problems at the >>> application level are just noise. >>> >>> >> in other words, one design error can be used to justify another? sort >> of like the blind leading the blind? >> > > No. People should work on making renumbering work efficiently. > I don't disagree that it's worthy of further investigation. I just don't think that it's likely to succeed anytime soon, which is to say, within a decade or maybe two. Automated renumbering is not going to alleviate the need for PI space or for the routing system to be able to somehow handle large numbers of PI prefixes. Something else might, but not automated renumbering. At least, that's what my intuition says. That doesn't mean don't try, it means don't depend on that being the solution. >> I see a significant difference between a design flaw in a particular >> application that cripples that application, and a design flaw in a lower >> layer that cripples all applications. >> > > Reconnect is a reasonable strategy for most applications. > Sounds very naive to my ears. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> > >>> To my small mind, forcing a new DNS lookup in the event of a > >>> TCP session failure and restart would be a good thing. > >>> > >> perhaps, but it won't work reliably as long as there can be more than > >> one host associated with a DNS name, nor will it work as long as DNS > >> name-to-address mapping is used to distribute load over a set of hosts. > >> > > > > We already have the DNS hooks to distingish services from > > hosts. We had them for the last 8 years. > > > Yes but SRV records weren't really meant to handle this case either. > And they actually can make applications less reliable because they > introduce a new dependency on DNS (another lookup that can fail, in a > different zone and potentially on a different server, another piece of > configuration data that can be incorrect.) What we'd really need is a > RR type specifically intended to map service names onto instance > ID+address pairs, and also a special query type that wasn't defined to > return all of the matching RR records, but would instead return a random > subset or a subset based on heuristics, and finally an instance ID to > address mapping service. But arguably DNS isn't the right place to do > that at all - there should instead be a generic referral service at > layer 3 or 4. > > Of course, part of the reason that people started using A records to > refer to multiple hosts was that a number of applications "just worked" > when they did that. And I remember when people used to object loudly to > such things, and insist that a DNS name and a host name had to be the > same thing. Anyway, this kind of overloading of A records has been such > a widespread practice for so long that I don't see it changing. And > it's not as if we came up with a better way of doing things for IPv6 > addresses. > >> in other words, doing another DNS lookup of the original DNS name only > >> looks like a good way to solve the problem if you don't look very deep. > >> > >> now if you somehow got a host-specific (or narrower) identifier as a > >> result of setting up the initial connection (maybe via a TCP option), > >> and you had a way to map that host-specific identifer to its current IP > >> address (assume for now that you're using DNS, though there are still > >> other problems with that) - then you could do a different kind of lookup > >> to get the new IP address and use that to do a restart. > >> > >> even then, it wouldn't help the numerous applications which don't have a > >> way to cleanly recover from dropped TCP connections. (remember, TCP > >> was supposed to make sure data were retransmitted as necessary and that > >> duplicated data were sorted out, provide a clean close, that sort of > >> thing. once you expect apps to handle dropped connections they have to > >> re-implement TCP functionality at a higher layer.) > >> > > > > Applications need to deal with TCP connections breaking for > > all sorts of reasons. Renumbering should be a relatively > > infrequent event compared to all the other possible ways a > > TCP connection can fail. > > > Mumble. Seems like the whole point of TCP was to recover from such > failures at a lower level. And I remember how people used to say that > TCP was better than X.25 VCs (in part) because TCP would recover from > temporary network outages that would cause hangups in X.25. > > I also don't have a lot of faith in "should be", not when I've seen DHCP > servers routinely refuse to renew leases after very short times, nor > when I've heard people say that a site should be able to renumber every > day. So, someone misconfigured something. Such misconfigurations usually get fixed fast. Getting the automation to the state where a daily renumber is possible is an achievable goal. If we were doing that the long running apps would have been fixed long ago. The fact that they aren't is more a matter of pressure than anything else. That's why I started with a large period when I was suggesting that router and firewall vendors actually renumber themselves periodically. It was to keep the problem in the management space rather than the application space. Have each vendor work on their part of the problem is the way to go. > I used to try to get people to specify a minimum amount of time that a > non-deprecated address should be expected to be valid - say a day. Then > application writers and application protocol designers would have an > idea about whether they needed a strategy for recovery from a > renumbering event, and what kind of strategy they needed. But the only > people who seemed to like this idea were application area people. > > Until applications deal nicely with the other failure modes, > > complaints about renumbering causing problems at the > > application level are just noise. > > > in other w
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> Have you ever used the term "layer violation", or heard it used by > someone else? Occasionally :) > Having the application know the network layer address is just slightly > worse than having it know what it's Ethernet address is or what port > it is attached to. The flip side to this is that an immense amount of additional complexity is required to truly make applications agnostic of lower layers. "Classic" TCP/IPv4 was a lot simpler and more deployable than it would have been with a genuine ID/LOC split. By making the assumption that an address was "good enough" as an endpoint identifier, made implementation on modest 1980s era hardware, not to mention slow networks, a lot more practical. And in the days before laptops and before the net got big enough to make prefix aggregation necessary, this was a reasonable assumption. It seems that a lot of successful protocols were originally optimized for deployability rather than optimized for longevity. I suspect that those protocols tend to be more successful, even in the long term, than those that are initially optimized for longevity over deployability :) IPv4 is one example, DNS is another, HTTP is a third, I suspect BGP is a fourth, and I'm sure there are many more. > There are a few cases in which it has a real need to know. In all > except those few, believe me, every whine I hear about renumbering is > in my ears a whine about the layer violation. Make it go away, and the > renumbering problem will be *much* easier to solve. Well, every time I hear a whine in IETF about how people "should" or "should not" do things a certain way, I ask myself whether this is really a reflection of the network architecture's failure to solve some important problem. After all, if there were a better way to solve the problem within the bounds of the architecture, people would probably find it sooner or later. Various practices that some of us might label as dubious, including NATs, using IP addresses as authentication tokens, using a single DNS name as a way to name a service that's actually implemented by a large pool of hosts, or layer violations in general, are all attributed to failures of the architecture or failures to implement key features in our core protocols in a timely fashion. So the reason people are writing applications that look at IP addresses is because the network doesn't give them the tools that they need to write good apps without looking at IP addresses. (And they need to do that even more in a NATted environment, or in an environment where hosts have multiple source and/or destination addresses with different characteristics, so it's not like the architecture is moving in a direction to discourage layer violations). It's a bit unrealistic to expect those applications to change in order to solve the renumbering problem, without providing those tools. The incentives all favor solving your own problem (or making your own customers happy) even at the risk of creating a problem for someone else, not to solve someone else's problem even though it makes your own product less functional, efficient, or reliable. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Renumbering
I remember Bill Clinton describing trying to develop an Internet standard like 'nailing jello to the wall'. From: Iljitsch van Beijnum [mailto:[EMAIL PROTECTED] Sent: Thu 13/09/2007 5:24 PM To: Keith Moore Cc: Tony Finch; IETF-Discussion Subject: Re: Renumbering On Sep 13, 2007, at 20:52 , Keith Moore wrote: >>> How do you renumber the IP address stored in the struct >>> sockaddr_in in a >>> long running critical application? Disconnect current session, reconnect. >> Applications that don't respect DNS TTLs are broken for many >> reasons, not >> just network renumbering. Since when is it the job of applications to manage DNS TTLs? > Since neither TCP nor UDP respect DNS TTLs it seems a bit of a stretch > to expect apps to do so. Right. > And for that matter, a DNS name is not a host name, and hasn't > reliably > been a host name since at least the mid 1980s. Just because you get > address A1 from doing a lookup on a name at time T1 and an address A1 > from doing the same lookup at time T2, doesn't mean that those > addresses > will connect to the same (layer 3 or higher) stack. > So even if we somehow magically changed our existing transport > protocols > to be able to support changes to endpoint addresses on the fly, DNS > names as they are currently used are not suitable as endpoint > identifiers for such a purpose. At best, existing DNS names serve as > identifiers for the initial contact only. This falls under the heading of "nobody is stopping us from doing this and it works today so now it's a feature and it can never be taken away". Giving in to this logic means that it's impossible to change ANYTHING. As the saying goes, in an infinite universe, everything that's possible, does indeed exist. The internet is pretty much an infinite universe these days. As for renumbering, on a Cisco router, I can make the following configuration: ! interface Ethernet1 ipv6 address autoconfig ipv6 dhcp client pd dhcpv6prefix ! interface Ethernet2 ipv6 address dhcpv6prefix 0:0:0:A0::/64 eui-64 ! This way, the router obtains an IPv6 prefix dynamically from a DHCPv6 prefix delegation server and then sends out router advertisements using that prefix. So you can renumber the router and all the hosts connected through it by changing one entry in a DHCPv6 server config. However, I don't think this method applies everywhere (such as in filters) but obviously that's something that would be possible if desired. Even with the current state of the art I'd say that renumbering clients is not a big deal. Renumbering servers is more difficult, though. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
>>> To my small mind, forcing a new DNS lookup in the event of a >>> TCP session failure and restart would be a good thing. >>> >> perhaps, but it won't work reliably as long as there can be more than >> one host associated with a DNS name, nor will it work as long as DNS >> name-to-address mapping is used to distribute load over a set of hosts. >> > > We already have the DNS hooks to distingish services from > hosts. We had them for the last 8 years. > Yes but SRV records weren't really meant to handle this case either. And they actually can make applications less reliable because they introduce a new dependency on DNS (another lookup that can fail, in a different zone and potentially on a different server, another piece of configuration data that can be incorrect.) What we'd really need is a RR type specifically intended to map service names onto instance ID+address pairs, and also a special query type that wasn't defined to return all of the matching RR records, but would instead return a random subset or a subset based on heuristics, and finally an instance ID to address mapping service. But arguably DNS isn't the right place to do that at all - there should instead be a generic referral service at layer 3 or 4. Of course, part of the reason that people started using A records to refer to multiple hosts was that a number of applications "just worked" when they did that. And I remember when people used to object loudly to such things, and insist that a DNS name and a host name had to be the same thing. Anyway, this kind of overloading of A records has been such a widespread practice for so long that I don't see it changing. And it's not as if we came up with a better way of doing things for IPv6 addresses. >> in other words, doing another DNS lookup of the original DNS name only >> looks like a good way to solve the problem if you don't look very deep. >> >> now if you somehow got a host-specific (or narrower) identifier as a >> result of setting up the initial connection (maybe via a TCP option), >> and you had a way to map that host-specific identifer to its current IP >> address (assume for now that you're using DNS, though there are still >> other problems with that) - then you could do a different kind of lookup >> to get the new IP address and use that to do a restart. >> >> even then, it wouldn't help the numerous applications which don't have a >> way to cleanly recover from dropped TCP connections. (remember, TCP >> was supposed to make sure data were retransmitted as necessary and that >> duplicated data were sorted out, provide a clean close, that sort of >> thing. once you expect apps to handle dropped connections they have to >> re-implement TCP functionality at a higher layer.) >> > > Applications need to deal with TCP connections breaking for > all sorts of reasons. Renumbering should be a relatively > infrequent event compared to all the other possible ways a > TCP connection can fail. > Mumble. Seems like the whole point of TCP was to recover from such failures at a lower level. And I remember how people used to say that TCP was better than X.25 VCs (in part) because TCP would recover from temporary network outages that would cause hangups in X.25. I also don't have a lot of faith in "should be", not when I've seen DHCP servers routinely refuse to renew leases after very short times, nor when I've heard people say that a site should be able to renumber every day. I used to try to get people to specify a minimum amount of time that a non-deprecated address should be expected to be valid - say a day. Then application writers and application protocol designers would have an idea about whether they needed a strategy for recovery from a renumbering event, and what kind of strategy they needed. But the only people who seemed to like this idea were application area people. > Until applications deal nicely with the other failure modes, > complaints about renumbering causing problems at the > application level are just noise. > in other words, one design error can be used to justify another? sort of like the blind leading the blind? I see a significant difference between a design flaw in a particular application that cripples that application, and a design flaw in a lower layer that cripples all applications. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
> Fred Baker wrote: > > What would be Really Nice would be to in some way ensure that > > applications never saw IP addresses at all - they *only* worked on > > names, and maintained no knowledge in the application of what address > > was used. To my small mind, forcing a new DNS lookup in the event of a > > TCP session failure and restart would be a good thing. > perhaps, but it won't work reliably as long as there can be more than > one host associated with a DNS name, nor will it work as long as DNS > name-to-address mapping is used to distribute load over a set of hosts. We already have the DNS hooks to distingish services from hosts. We had them for the last 8 years. Some services actually use these hooks. > in other words, doing another DNS lookup of the original DNS name only > looks like a good way to solve the problem if you don't look very deep. > > now if you somehow got a host-specific (or narrower) identifier as a > result of setting up the initial connection (maybe via a TCP option), > and you had a way to map that host-specific identifer to its current IP > address (assume for now that you're using DNS, though there are still > other problems with that) - then you could do a different kind of lookup > to get the new IP address and use that to do a restart. > > even then, it wouldn't help the numerous applications which don't have a > way to cleanly recover from dropped TCP connections. (remember, TCP > was supposed to make sure data were retransmitted as necessary and that > duplicated data were sorted out, provide a clean close, that sort of > thing. once you expect apps to handle dropped connections they have to > re-implement TCP functionality at a higher layer.) Applications need to deal with TCP connections breaking for all sorts of reasons. Renumbering should be a relatively infrequent event compared to all the other possible ways a TCP connection can fail. Until applications deal nicely with the other failure modes, complaints about renumbering causing problems at the application level are just noise. > > The authors of RFC 4778 would take exception - they want to be able to > > log into the right place when everything is in flames. Apart from > > that, though, managing addresses through names would go a *long* way > > toward making renumbering easier. We already have many of those > > capabilities, though. We have to as an industry consistently use them > > that way. > and yet, it's quite clear that DNS as it currently exists is not > adequate for this. not the query protocol, nor the data caching model, > nor the APIs, nor the security (at least as deployed), nor the names > that we're currently using, and probably not even the replication > mechanism. which might be why the industry hasn't started consistently > using DNS for this. > > Keith > > > ___ > Ietf mailing list > Ietf@ietf.org > https://www1.ietf.org/mailman/listinfo/ietf -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
On Sep 14, 2007, at 6:03 AM, Keith Moore wrote: perhaps, but it won't work reliably as long as there can be more than one host associated with a DNS name, nor will it work as long as DNS name-to-address mapping is used to distribute load over a set of hosts. well, this presumes that the application wants to get to the same instance of the peer, as opposed to getting to "an" instance of the peer. If the reason the session was lost was that the peer has gone out of service or is unreachable, insisting on the same instance of the peer has its down sides. So there is probably some solution, as you suggest, such as having the application accept a peer-specific name for the purpose - if it has to retry, it can try the instance-specific name first, and if that fails, try the more general name. Note that when I say "name", I am not limiting myself to a DNS name. I'm quite happy to see some other form of name if the apps folks want to design one, for all the reasons you cite. IMHO, some form of true directory, with unicode directly supported, would be a wonderful thing. I'm not the first to suggest that, as you know well. I'm waiting for those who understand those issues better than I do to make the proposal. Haven't seen it yet. Have you ever used the term "layer violation", or heard it used by someone else? Having the application know the network layer address is just slightly worse than having it know what it's Ethernet address is or what port it is attached to. There are a few cases in which it has a real need to know. In all except those few, believe me, every whine I hear about renumbering is in my ears a whine about the layer violation. Make it go away, and the renumbering problem will be *much* easier to solve. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Fred Baker wrote: > What would be Really Nice would be to in some way ensure that > applications never saw IP addresses at all - they *only* worked on > names, and maintained no knowledge in the application of what address > was used. To my small mind, forcing a new DNS lookup in the event of a > TCP session failure and restart would be a good thing. perhaps, but it won't work reliably as long as there can be more than one host associated with a DNS name, nor will it work as long as DNS name-to-address mapping is used to distribute load over a set of hosts. in other words, doing another DNS lookup of the original DNS name only looks like a good way to solve the problem if you don't look very deep. now if you somehow got a host-specific (or narrower) identifier as a result of setting up the initial connection (maybe via a TCP option), and you had a way to map that host-specific identifer to its current IP address (assume for now that you're using DNS, though there are still other problems with that) - then you could do a different kind of lookup to get the new IP address and use that to do a restart. even then, it wouldn't help the numerous applications which don't have a way to cleanly recover from dropped TCP connections. (remember, TCP was supposed to make sure data were retransmitted as necessary and that duplicated data were sorted out, provide a clean close, that sort of thing. once you expect apps to handle dropped connections they have to re-implement TCP functionality at a higher layer.) > The authors of RFC 4778 would take exception - they want to be able to > log into the right place when everything is in flames. Apart from > that, though, managing addresses through names would go a *long* way > toward making renumbering easier. We already have many of those > capabilities, though. We have to as an industry consistently use them > that way. and yet, it's quite clear that DNS as it currently exists is not adequate for this. not the query protocol, nor the data caching model, nor the APIs, nor the security (at least as deployed), nor the names that we're currently using, and probably not even the replication mechanism. which might be why the industry hasn't started consistently using DNS for this. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Noel Chiappa wrote: > > From: "Tony Hain" <[EMAIL PROTECTED]> > > > David Conrad wrote: > > >> IPv6 _is_ IPv4 with more bits and it is being deployed that way. > > > No it is not, > > No less a person than the IPv6 'architect' himself stated that IPv6 and > IPv4 were architecturally identical, that IPv4 got it all basically right, > and that IPv6 was nothing more than IPv4 with a little cleaned up > engineering. > I'm sure it started out that way. It didn't end up that way. A few changes here and there had rather significant (perhaps unintended) effects. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Call for action vs. lost opportunity (Was: Re: Renumbering)
Tony Hain wrote: > Until people get their heads out of the IPv4 darkness they will keep > insisting on making IPv6 deployments look the same. > Perhaps, but there's such a thing as IPv6 darkness also. For instance, the assumption that existing applications can survive changes in the IP addresses of the hosts on which they reside without significant changes to those applications. Or the assumption that it's reasonable for applications to have to deal with multiple source and destination IP addresses without access to routing or topology information. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
