Re: Article: Mobile security flaw delivers yet another blow toIPv6
At 3:06 PM -0500 3/25/02, Meritt James wrote: It's a setback for those who are eager to get IPv6 out there, says Steve Deering, a Cisco engineer who helped design IPv6 and serves on the IETF's Internet Architecture Board. The Mobile IP working group has been working on this since 1991. It's been a long process. And at 6:29 PM -0500 3/26/02, Meritt James wrote: Actually, I was more interested in the quote rather than the IPv6. You notice that the portion I extracted (which contained the quote) was NOT the lead in, or summary article. It was a position taken by a person that we know for for those who were not in attendance. James, As noted, this was from a year ago, when the Mobile IPv6 spec was sent back to the working group to come up with a different approach to authenticating binding updates (which they have now done). Although the quotes are accurate, they are combined in a misleading way. The Mobile IP group obviously has not been working on IPv6 mobility since 1991; that's (approximately) when it started working on IPv*4* mobility. The article included several other, more serious distortions and exaggerations of what I said (as almost always happens, as anyone who talks to journalists knows), starting with the title. Please don't take it as an accurate report of what really happened or what I thought or said about it. Steve
Re: Why IPv6 is a must?
At 8:36 AM -0500 11/29/01, Eric Rosen wrote: Sure, in theory one could add zillions of new globally routable addresses without increasing the size of the routing tables in the default-free zone at all. The skepticism is about whether there is (or even could be) a realistic plan to make this happen. What's the realistic plan to prevent the IPv4 routing table from growing to 2^32 route entries? Steve
Re: Why IPv6 is a must?
At 3:23 PM -0500 11/28/01, Eric Rosen wrote: Granted, it's easier to talk about the evils of NAT than to explain how billions of new routable addresses are going to be added to the existing routing system. It's not the size (of the address) that matters, but how you use it. Whether you assign one IPv4 address per subscriber and make them use NAT, or give them each a block of a zillion IPv6 addresses, the routing cost is the same. If you really believe it's the total number of addresses that determines the size/cost of the routing system, you'd better start working on moving the world away from IPv4 to IPv-1 with 17-bit addresses. Steve
Re: Why is IPv6 a must?
At 12:46 AM -0500 11/12/01, J. Noel Chiappa wrote: Needless to say, the sight of IPv6 proponents ranting about how nobody has ever come up with a fully specified way to do [ID/locator separation], while the protocol they are defending contains, apparently unbeknown to them, the perfect counter-evidence to this sterile claim, is extremely educational as to the general clue level. Noel, Way back in June of 1992 on the big-internet mailing list, I pointed out to you how the (then relatively new) proposed mechanism for doing mobile IP indeed accomplished the task of separating identity from location, when necessary, and that the reuse of IP addresses for identifiers in that case was an important part of making it work. You, on the other hand, insisted that the identifier be taken from a different, flat space, which would then *not* be amenable to using the same binding mechanism as mobile IP, and I'm *still* waiting to hear your alternative mechanism. What's especially amusing is that although I keep pointing this wonderfully ironic and devastating counter-argument out, some IPv6 proponents keep trotting out this same old lame, bogus point. Ah no, the really amusing irony is hearing you now holding up as your devastating counter-argument the one mechanism that, to us old-timers who became IPv6 proponents, looked like it would actually work and scale up (and which was specified concretely enough to make those judgements), but which was previously dismissed by you because its identifiers weren't pure enough. Steve
ipngwg / ngtrans interim meeting
Information about the interim meeting of the IPv6 working groups on May 30, 31, and June 1 is now available at http://research.microsoft.com/ietf-ipv6-meeting.
Re: NAT natural example, Re: [midcom] WG scope/deliverables
[I've taken the bulk of my response to Ed's last reply to private mail, since I assume few here are interested in tedious arguments about exactly how the Internet is analogous to the postal system, but I'll just make his one public observation:] At 9:45 PM -0800 2/15/01, Ed Gerck wrote: I agree that you can define many different analogies, from that example. But, as above, if you consider the way that information is received then a NAT box is IMO one valid analogy for reception because it satisfies the functionality observed in a NAT box when receiving packets. Your postal example doesn't entail the modification of an address on the received package, which is the defining characteristic of a NAT. Your postal analogy does show how you can get nice properties of address portability and location-hiding within a local network *without* resorting to address modification, i.e., it shows that you can have the flexibility you so prize without doing NAT. Maybe that's the lesson you should draw from this "naturally occurring" analog to packet networks. Steve
Re: NAT natural example, Re: [midcom] WG scope/deliverables
At 8:12 AM -0800 2/16/01, Ed Gerck wrote: 1. there is a natural need for heterogeneous address systems and, Agreed. 2. therefore, there is a natural need for address translation. Only if there's some need to interconnect them, and even then only as a temporary measure, if at all, because there is an alternative and preferable way to deal with heterogeneous address systems -- and the only long-term successful way if history is any guide -- which is to layer a homogenous address system on top of them, which is the basic idea behind IP. Yes, the first attempt to join networks using different address systems is often to install translators, which is the way "interworking" was done before IP and Pup were invented, the way email systems were interconnected before universal adoption of the [EMAIL PROTECTED] name space, and the way people are gluing together the phone network and IP phones, not to mention the IPv4 and IPv6 Internets, today. Such approaches have always turned out to be so complex, fragile, unmanageable, unscalable, and function-limiting that they are sooner or later abandoned in favor of the one-global-namespace approach. If people understood that they didn't "need" to do translation, they just might take that step sooner and save everyone a lot of grief. Steve
Re: NAT natural example, Re: [midcom] WG scope/deliverables
At 3:41 PM -0800 2/15/01, Ed Gerck wrote: "Steven M. Bellovin" wrote: You give a name to your house (say, "The Tulip") and the post office knows where The Tulip is. If you move, you can do the same at your new location, provided there is no conflict. ...Note that this is a natural example of NAT, in which the post office is doing the address translation to a local address that only that post office knows, but which is globally reachable through that post office. And the post office does so without changing the global addresses or the local addresses. They also do it without removing the original destination address and replacing it with another one -- the original envelope arrives at the house with the destination address still saying "The Tulip", i.e., it has not been translated, and thus is not analogous to NAT. If delivery is accomplished by having all the necessary the UK post offices and postpersons remember a routing from "The Tulip" to its current street address, then its IP analog is having the routers within a site maintain a host route for a specific IP address. If, on the other hand, only the UK-entry post office maintains the mapping and sticks the original envelope inside another envelope (or puts a yellow sticky note over the original address), addressed to The Tulip's current street address, then its IP analog is having the border router maintain a tunnel to an individual interior host, encapsulating the original packet with another header. A closer postal analog to the typical port-and-address-mapping NAT is a system in which postal envelopes only have room for a street address or a town name, but not both. If I send a letter to someone outside my town, the letter starts off with a return address of: Steve Deering 123 Main Street and the town's post office overwrites that return address, changing it to: Priscilla Presley San Jose, CA, USA and they remember for a while that they did that, so that if my correspondent decides to reply to that return address, the town post office knows who it should be delivered to. (They replaced my name because someone else named Steve Deering recently sent mail from another street address in my town, and the only way to keep the replies separate is to change the name that I will be [temporarily] known by in the outside world.) At some point, they discard the remembered mapping, to free up some names. Perhaps they do that based on a time-out, in which case the mapping may disappear before we are finished corresponding, and thus cause our communication to fail. Or maybe they open up our letters and look at the contents to try to identify the final letter of our correspondence, to guess when we might be done. Of course that latter approach doesn't help if they don't understand what language our letters are written in, so maybe they decide to limit us to only a small choice of languages, and just discard anything they don't understand. Furthermore, no one outside my town can initiate a correspondence with me, unless I work out some arrangement with the post office to get long term external use of someone's (preferably my own) name. Or else I have to go and get a town name for myself. I don't want to be philosophical about this, but IMO this example actually supports the view that NATs are naturally occuring solutions to provide for local flexibility without decreasing global connectivity. Since the example was not an example of a NAT, I don't think it supports any such view. However, I suppose a postal system like the one I described might "naturally occur" as a response to having envelopes that were no longer big enough to contain full addresses. But I think it much more likely that post offices and people would somehow arrange to just use bigger envelopes, rather than incurring all the extra complexity, cost, fragility, and loss of functionality of the translating approach, except as a temporary stop-gap. Unless, that is, we were talked out of it by folks claiming that changing the size of envelopes would be an impossibly large task, and that we're better off anyway with the translating system, because our personal names and street addresses can be kept secret within our town, and we can change the name of our town any time we like without bothering anybody in it. Steve
Re: Addresses and ports and taxes -- oh my!
At 8:49 AM +0200 8/4/00, Anthony Atkielski wrote: Not relevant. IPv6 will be exhausted by overly-generous allocation of address space, just like IPv4. I've already explained in the past why this must be so. In part, it comes from the subjective impression that any new address space is "more than we'll ever need" and the tendency to overallocate in consequence, until it's too late; this is probably the most common engineering mistake in IT history. Another reason why IPv6 is not nearly as large as it appears to be is that IP addresses are closely linked to routing, instead of being randomly assigned; and this routing imposes severe restrictions on how the address space can be used. Both issues are routinely and completely overlooked,... They have not been overlooked by those who have been working on IPv6 address allocation policy. Steve
Re: Addresses and ports and taxes -- oh my!
At 8:36 AM +0200 8/4/00, Anthony Atkielski wrote: I think we'll see IP addressable toasters and washing machines just after we all switch from automobiles to hovercars and from telephones to Picturephones. According to predictions being made by futurists for the past few decades, all of these things are due to happen Real Soon Now. The mere fact that some predicted technologies never materialized does not mean that all predicted technologies will fail to materialize. Steve
Re: I-D ACTION:draft-dommety-mobileip-anchor-handoff-01.txt
At 6:35 AM -0400 7/25/00, [EMAIL PROTECTED] wrote: Title: Local and Indirect Registration for Anchoring Handoffs Author(s): G. Dommety, T. Ye ...This document proposes enchantments to reduce the latencies involved... Somebody's been reading too much Harry Potter. Nice thought, though. Steve
RE: IP over MIME (was Re: WAP Is A Trap -- Reject WAP)
At 4:16 PM -0400 6/21/00, Brijesh Kumar wrote: WAP's goal is not to replace IP, but mediate between non-IP wireless devices, and existing IP based wire line applications. There are no "IP based wire line applications". Applications based on IP don't depend on, or know, or care that their packets flow over wires or fibres or RF waves or IR waves or wet string, or any combination thereof. That's one of the neat things about IP. Steve
Re: draft-ietf-nat-protocol-complications-02.txt
At 2:42 PM -0700 4/26/00, David R. Conrad wrote: Perhaps it is obvious to you, however it has been implied that one of the advantages of v6 is that it has a limited number of TLAs which would be found the the DFZ of the v6 Internet. The truth is subtly different than what what was implied or thought to be implied, as I have tried to explain (with limited success, obviously), but that's beside the point of your message: My point was that this is not an advantage of v6 but rather an advantage of starting fresh and that the limitations on TLAs is not an artifact of the v6 protocol, but rather an administrative limit established by policy Yes, that's right. If I understand correctly, you are upset by the imprecise shorthand of saying "this is an advantage of IPv6 over IPv4" and would prefer that we were careful always to say "this is an advantage of the IPv6 addressing plan over the addressing plan of the existing IPv4 Internet, an advantage of starting fresh". Fair enough. Or are you asking us not to mention it at all, perhaps because there is a plan to undertake a major renumbering of the IPv4 Internet so that there will be a similarly small limit on the number of globally-advertised IPv4 prefixes required to ensure reachability of all IPv4 customers? -- something quite malleable over time (perhaps more so now given the creation of ICANN). In what way do you think the creation of ICANN might have made it easy or easier to impose address changes on IPv4 customers? IPv4 could in theory have 2^32 TLAs and IPv6 could in theory have 2^128 TLAs. Are you saying that 2^32 TLAs would be OK? No more than I would assume you'd say 2^128 TLAs would be OK. So you agree there is a need to limit the number of TLAs to a number less than that permitted by the address size, even for IPv4. The longer address of IPv6 does not introduce a new problem in this regard, contrary to what you seemed to imply -- whatever method or policy you would use to limit the number of TLAs in IPv4 could just as well be used in IPv6. Or do you, perhaps, think we really ought to be moving to a version of IP with 16-bit addresses, to avoid the risk of creating too many TLAs? :-) Steve
Re: draft-ietf-nat-protocol-complications-02.txt
At 8:48 AM -0700 4/25/00, Bill Manning wrote: and this is different from only carrying the 253 usable /8 prefixes in IPv4 how? The set of customers who have addresses under a given IPv4 /8 prefix greater than 127 do not all aggregate into a single topological subregion (e.g., a single ISP), and therefore more granular routes must be widely disseminated to make those customers reachable. That's the difference. Steve
Re: draft-ietf-nat-protocol-complications-02.txt
At 10:22 AM -0700 4/25/00, Bill Manning wrote: Given the nature of trans-oceanic b/w vs. local b/w arguments I've heard over the years, I'd say that these delegations are esentially constrained to topological subregions and that for the most part, having the largest incumbent ISPs in each region announce the respective /8 would roughly meet the IPv6, heirarchical aggregation argument. A few counter-points: - As you know, I am a fan of geographic addressing (to provide a real, scalable, user-friendly solution to most of the multihoming and renumbering problems), but as you also know, proposals to do any sort of geographic routing have usually been met with hostility and derision from the ISP community and others, because of the topological constraints and interchange requirements it would impose on the ISPs. I welcome you to try, but don't get your hopes up. - Are there not a large number of Class B addresses (and Class C addresses, but maybe those have all been filtered out by now) that were assigned before the registries were established, and thus not aggregatable under the registry allocation prefixes? - Why are we talking about this? Yes, you could adopt the same or a similar address allocation/aggregation policy in IPv4 as has been specified for IPv6, if you were starting all over again with IPv4. But so what? Steve
Re: draft-ietf-nat-protocol-complications-02.txt
At 11:16 AM -0700 4/25/00, Bill Manning wrote: And why do you think that the ISP community and others will not meet the IPv6 routing proposal with anything less than the "hostility and derision" that came from the previous attempts to impose "topological constraints and interchange requirements" on them? I was talking about the requirements of geographic addressing and routing. The IPv6 addressing and routing plan does not impose those requirements. Rather, the IPv6 addressing and routing plan is just the CIDR plan that is being used today by that community for IPv4, with some policy proposals to attempt to limit the number of prefixes that must be globally advertised, something that many in that community have said over and over again is of vital importance. (Of course, some will respond with hostility and derision to any plan, even if it's exactly what they would argue for, if it comes in IPv6 clothing.) % - Are there not a large number of Class B addresses (and Class C %addresses, but maybe those have all been filtered out by now) %that were assigned before the registries were established, and %thus not aggregatable under the registry allocation prefixes? Yup, a bunch. OK, so because of that, just changing the IPv4 Internet today to advertise only /8s globally would not be functionally equivalent to just advertising IPv6 TLAs, which was your original question. % - Why are we talking about this? Yes, you could adopt the same %or a similar address allocation/aggregation policy in IPv4 as %has been specified for IPv6, if you were starting all over again %with IPv4. But so what? Well, for two reasons: a) IPv4 address delegation policy, since about 1996 has been done at a gross level, on continental bounds (e.g. the RIR model) so there is a rough alignment with the proposed IPv6 plan, at least as far as "modern" delegations are concerned. This is something that could be exploited for testing to see if the IPv6 delegation/aggregation plan is actually going to fly. Huh? We have been "testing" that for some years in the IPv4 world, and we have adopted it for IPv6. What further testing do you have in mind, and in what salient way do you think the IPv6 delegation/aggregation plan is different? b) We have IPv4 addresses as legacy environments that -RIGHT NOW- are showing problems with computing/maintaining state in a dynamic world. If we can "prove" the solution in the IPv4 world, then that would remove much of the "hostility derision" when moving on to IPv6. Huh? You want to stop routing to IPv4 prefixes that don't aggregate under /8s in order to "prove" that we shouldn't allocate such prefixes in IPv6??? Steve
Re: IPv6: Past mistakes repeated?
Anthony, One interesting example: OSI NSAP addresses are variable length, with a theoretical limit of 255 bytes I believe (perhaps there's an escape mechanism to grow them longer?). There was an "implementors' agreement" to limit the maximum length in actual use to 20 bytes "for now", to make implementations practical. Two things happened: (1) Almost all of the addressing plans designed for NSAPAs produced addresses that were *exactly* 20 bytes long, in some cases inserting padding in the middle of the address to fill it out to 20 bytes! I suspect that was done to make the address allocation job easier, e.g., making sure delegation boundaries fell on byte boundaries. (2) Many of the implementations ended up with the 20-byte limit wired into them, such that the use of addresses longer than 20 bytes would have required updating most of the installed base (the changes being of a similar nature to those required to modify an IPv4 application or protocol to support IPv6). This (admittedly anecdotal) example led me to surmise that: - any variable-length address scheme will have a maximum size imposed upon it, for pragmatic implementation reasons. - any variable-length address scheme will quickly degenerate into a fixed-length scheme of maximum size, for human nature reasons (the humans being the people doing the address allocation). At which point, you are back to the problem you were trying to avoid. I think the only reason this hasn't happened in the phone system is due to resistance by humans to reading, writing, and entering very long strings of digits. Unfortunately, computers aren't as fussy. Perhaps you could think of IPv6 addresses as variable-length addresses within a fixed-size container, in which the variable-length part is in the middle and not at the right hand end? :-) Anyway, as pointed out by others, the IPv6 work anticipates that there may be a need to "rebalance" the address assignments (i.e., renumber) in the future, if/when our predictions of where the growth will be turn out to be wrong, which ought to be less painful than making the changes to deployed implementations that your scheme would require whenever a significant number of addresses started to exceed the length that caused traps into the exception-handling code. And we avoid the risk of having many very long addresses (in this case, longer than 16 bytes) being used, which is important for a connectionless protocol like IP, in which the addresses are overhead in every packet. Steve
Re: multihoming (was Re:draft-ietf-nat-protocol-complications-02.txt)
At 1:11 PM -0700 4/25/00, Paul Francis wrote: For me, your statement certainly reinforces the idea that multihoming in IPv6 is indeed very difficult. More accurately: multihoming in IP (any version) is indeed very difficult. The problems are a fundamental consequence of having to do hierarchical addressing and routing. IPv6 is no worse than IPv4 in this regard, and there are some features of IPv6 that might actually make make it better (e.g., host support for multiple addresses on a single interface). I read your statement as follows: IPv6 does not solve the multihoming problem. Instead, it tries to minimize the damage by: 1. discouraging the use of multihoming, primarily may making multihomed customers pay more for it. 2. forcing paths to multihomed sites to be less efficient (at least for all but one of the ISP connection points) and or, 3. limiting the regions of the internet for which multihoming is effective for a given customer. Is this an accurate representation? Not at all. Try this: IPv4 has one, problematical solution to the site multihoming problem: advertise the site's prefix globally (or, at least, beyond more than a single ISP's domain). This has obvious scaling problems as a solution to multihoming a very large number of sites (e.g., millions of households, as in Sean's example). People have accused IPv6 of lacking that one (non-scalable) solution to multihoming, based on a misunderstanding of the IPv6 address architecture. That accusation is false, and nothing in IPv6 prevents the use of the same, lousy multihoming solution we have today for IPv4. IPv6 includes support for *additional* potential solutions to multihoming in which, rather than a site having a single prefix advertised globally, the site has multiple, aggregatable prefixes, and something more intelligent is done in the site's border routers and/or the the end hosts. This is work-in-progress, and is likely to produce solutions with a different (but, we hope, acceptable in many contexts) set of shortcomings. Steve
Re: draft-ietf-nat-protocol-complications-02.txt
At 4:32 PM +0200 4/24/00, Sean Doran wrote: Unfortunately, IPv6's current addressing architecture makes it very difficult to do this sort of traditional multihoming if one is not a TLA. This is a significant step backward from the current IPv4 situation, where one can persuade various operators to accept more-specific prefixes (coloured with appropriate community attributes) in order to optimize return traffic from particular parts of the Internet. Sean, That is widely claimed but incorrect. Nothing in the IPv6 addressing architecture prevents a user from negotiating with multiple operators to accept any prefix assigned to that user. IPv6 retains the same capability as IPv4 in that respect. Therefore, in order to support IPv6 house-network multihoming, so as to preserve at least these three features of traditional multihoming, either the current IPv6 addressing architecture's restrictions on who can be a TLA must be abandoned (so each house becomes a TLA),... The consequences of those restrictions are not what you imagined, but even so, making each house a TLA does not strike me as a scalable multihoming solution for very large numbers of houses, given the current state of the routing art. ...or NATs must be used to rewrite house-network addresses into various PA address ranges supplied by the multiple providers. That's not the only possible alternative, and it is an alternative that creates a bunch of other unsolved problems (see earlier messages in this thread). IPv6's larger address space is merely a necessary piece of an Internet which will not run out of numbers. Wow, we actually agree on something! (Though I could quibble over the "merely".) Steve
Re: To address or NAT to address?
At 8:27 AM -0800 12/2/99, Yakov Rekhter wrote: With this in mind I hope that the same folks who complained about increased dependencies on DNS by NATs, would be equally vocal in complaining about increased reliance on the DNS by IPv6 (which claimed to be an improvement over NATs). Yakov, Observing that IPv6 has increased reliance on DNS, as does NAT, would not invalidate claims that IPv6 is an improvement over NAT; the claimed improvement is not solely, or even primarily, one of reduced DNS reliance. (Since you brought it up, I'll pedantically point out that IPv6 does not rely on the DNS at all -- it works just fine in the absence of a DNS service, unlike some of the NAT variants and the direction in which NAT apparently must evolve to keep up with the growth and functional demands of the Internet.) Steve
Re: To address or NAT to address?
At 2:01 PM -0800 12/2/99, David R. Conrad wrote: DNS is supposed to be a way to resolve domain names into IP addresses. As a hammer is supposed to be a way to pound nails. However, when it is perceived that all you have is a hammer, it is amazing what begins to look like nails. How else would one get an IP(v6) address from a domain name other than by using DNS? Am I missing something here? Yes. The DNS has grown a bit from a simple lookup mechanism. David, I think the point Charlie was making is that IP addresses are precisely the kinds of nails that the DNS was designed to hammer. Are you claiming that because the DNS has been used to pound other things, it is no longer any good for hammering (IP address) nails? Steve
