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)
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)
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)
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)
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)
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)
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)
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)
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)
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)
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 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)
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 valued - that's why the IPv6 packet format ended up being simpler than
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)
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)
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)
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 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)
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)
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
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: 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
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: 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)
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: 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)
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)
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: 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)
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: 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: 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)
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)
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: 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)
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: 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)
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)
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)
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)
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)
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: 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)
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)
Jari, On Sep 13, 2007, at 1:05 PM, Jari Arkko wrote: We had an opportunity to fix that, but we blew it. I think everyone agrees that having that flexibility (ease of renumbering, no routing explosion in the core etc) would be good. So would world peace, motherhood, and apple pie. What are you willing to give up for it? But I would suggest that instead of playing the what if or I told you so games, we collectively focus on solving the problem. And I would suggest by ignoring history we are doomed to repeat it. I am not engaging in I told you so because I didn't -- you'll note I used we. I am merely pointing out that we're either at or very quickly approaching a crossroads and the choices we have are constrained by the reality of the Internet today and past decisions we, the IETF, have made. IPv6 _is_ IPv4 with more bits and it is being deployed that way. One can argue that it shouldn't be that way and that there should be a paradigm shift in the enterprises, ISPs, and grandmothers of the world, but commercial reality makes such a shift very, very hard. And getting it solved means having a solution that actually works, has all the little details (like what the security is etc) worked out, fits with the incentives that the various players have, and so on. Do you believe IPv4 (or ANY other successful large scale technology), when it was designed, had all the little details worked out? 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. 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. 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. 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. 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 Thu, Sep 13, 2007 at 11:05:22PM +0300, Jari Arkko wrote: David, We had an opportunity to fix that, but we blew it. I think everyone agrees that having that flexibility (ease of renumbering, no routing explosion in the core etc) would be good. But I would suggest that instead of playing the what if or I told you so games, we collectively focus on solving the problem. And getting it solved means having a solution that actually works, has all the little details (like what the security is etc) worked out, fits with the incentives that the various players have, and so on. And we have a place for that work to happen in the IRTF. There's a lot of promising work, but they don't have a final solution yet; the details do matter (and I suspect that they also mattered back at the time IPv6 was being designed). Jari the old PIER wg had some useful ideas on the scope fo the renumbering problem... if the IRTF wants to revisit the problem that might be a good place to start. --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)
David Conrad wrote: IPv6 _is_ IPv4 with more bits and it is being deployed that way. Probably not really. 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, and having major changes to the minimum required set of capabilities is more than just a few more bits. Deering's SIP qualified as such a minor upgrade (if an upward compatible addressing scheme had been chosen.) The current IPv6 suite probably does not. 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: 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. Those aren't his exact words, but I don't feel like wasting the time to go find that email from him - but if you doubt that I have accurately captured the sense of what he said, I'll be happy to look for it. Noel ___ 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: 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. One can argue that it shouldn't be that way and that there should be a paradigm shift in the enterprises, ISPs, and grandmothers of the world, but commercial reality makes such a shift very, very hard. Transition requires that the technology meet people where they are, which is why you note that IPv6 is being deployed like IPv4. Then once they get over the basic education hump they can think about the different capabilities to move beyond the historical limitations. 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. Until people get their heads out of the IPv4 darkness they will keep insisting on making IPv6 deployments look the same. And getting it solved means having a solution that actually works, has all the little details (like what the security is etc) worked out, fits with the incentives that the various players have, and so on. Do you believe IPv4 (or ANY other successful large scale technology), when it was designed, had all the little details worked out? If anyone doubts this point, note that the IETF still creates more IPv4 specific RFCs than IPv6 ones. Until the IESG/IAB get serious about stopping all work on the dead-end IPv4 protocol, people will continue to argue that IPv6 is not ready for deployment. 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. 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. There are operational practices that originate from lack-of-memory/lack-of-reliable-resolution that end up embedding IP addresses in places that make it very costly to change them later. The work was done on the endpoint side to simplify renumbering, because touching the larger number of them was clearly a problem, but it was not done in the firewall/management system area. 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. 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. 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 ___ 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 2:22 AM, David Conrad wrote: And I would suggest by ignoring history we are doomed to repeat it. I am not engaging in I told you so because I didn't -- you'll note I used we. I am merely pointing out that we're either at or very quickly approaching a crossroads and the choices we have are constrained by the reality of the Internet today and past decisions we, the IETF, have made. Well, yes. But I do find myself wondering what tool one might really want to use here and how it differs from what we do in IPv4. Correct me if I am wrong (but not here - let's have that discussion on v6ops). To my way of thinking, the process described in RFC 4192 can't really be automated start to finish, and it is nonetheless pretty much the right process. Parts of it can be, such as once an operator decides he wants to add a new prefix to every router interface in his network, the database he uses to manage such things can ssh to each router and add the prefixes, and similarly when he decides to later remove the old, the database can do that. But the big problem in renumbering isn't getting the addresses assigned. It is finding and fixing all the places where that address was used in numeric form to ensure that they now have the right new value. Since human screwup behavior isn't automated, fixing human screwups is difficult to automate. So we can have tools that help with the major steps, but a lot of the verification process can only be done by observation. Recriminations and rants aren't going to make that much different. 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. 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. ___ 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
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)
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)
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. 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)
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)
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: 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 words, one design error can be used to justify another? sort of like the blind leading the blind? No. People should work on making
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
