Hi Fred, Thanks for your reply. I apologise for taking one message, on incremental deployability and responding to it as if it was part of another discussion about routing scalability.
I thought ISATAP was intended as a mechanism of dealing with the routing scaling problem, because it is mentioned in the RRG wiki: http://www3.tools.ietf.org/group/irtf/trac/wiki/RoutingResearchGroup but I now realise it is mentioned there because it has something to do with IPvLX: http://tools.ietf.org/html/draft-templin-ipvlx-08 Yet this ID hasn't been revised since May last year, its abstract doesn't mention the routing scaling problem, and I don't recall it being discussed on the RRG or RAM list. So do IPvLX and ISATAP really belong on the RRG wiki, under the heading "Active proposals"? Sorry if my previous message was overly long. I was trying to explain my criteria to encourage further discussion. You wrote: > It interests me to see that you would invest an > extensive analysis in ISATAP, which you previously > categorized as a transition mechanism. Perhaps a > better term (which has been used by others) is a > "coexistence" mechanism, where IPv6 and IPv4 are > expected to coexist in the network for the > forseeable future. The reason I mentioned ISATAP in my "Taxonomy: 25 questions" message was that it is mentioned on the RRG wiki page. The first two questions were intended to weed out anything which wasn't a potentially practical proposal (according to my criteria) for solving the routing scaling problem. > It seems you take a somewhat dim view of the potential > role for IPv6 in general in terms of addressing the > routing scaling issue. I have a dimmer view of IPv6 than many IETF folks. I think 64 bit addresses would have been better. With 128, there are 32 bytes of address in every packet - which seems like overkill when there are millions of people sending two-way streams of 50 VoIP packets a second with only 20 bytes of payload. However there are creative uses of the extra bits, such as Six/One. This address burden gets worse with any map-encap tunneling header, so I am keen to keep Ivip encapsulation as minimal as possible: IP-in-IP. LISP involves a LISP header and therefore a UDP header as well. I am also keen to avoid anything like a SEAL header, at least on the shorter packets in any map-encap tunnel. Since the five map-encap schemes could work with IPv6, if we could somehow get everyone off IPv4 and onto IPv6, then it would be possible to solve both routing scalability and the address shortage problem. The trouble is, no-one knows how to make a new addressing system which people could painlessly change over to while not needing an IPv4 address, but still be able to communicate with any IPv4 host. > Based on who you ask, though, > I think you would find that there are those in the > IETF that feel that we have no other choice but to > ensure a successful deployment of IPv6 and to ensure > that routing scaling is not adversely impacted in the > process. I understand and agree with the long-term argument: the extremely desirable goal of NAT-free any-to-any communication without being cramped for address space. However I am not sure if this is a "no other choice" goal. Now, and for the foreseeable future, there is no direct reason why ordinary net users would want IPv6. Until virtually everyone has IPv6, it is impossible to imagine why ordinary users would want to relinquish their IPv4 addresses. Maybe humanity will be stuck inhabiting IPv4 more and more efficiently forever. Something like Positano, Italy: http://glamgal.typepad.com/.shared/image.html?/photos/uncategorized/dsc00216.jpg with each end-user network making the most of its little public patch of one or a few IP addresses, all crowded together. That is ugly compared to us moving to a more expansive addressing scheme - and IPv6 is the only one on offer. I suspect that if NATs and their traversal become more standardised that the "IPv4 forever" wouldn't be so disastrous and that "no other choice but IPv6" would prove to be wrong. The one thing I could imagine making IPv4 completely unworkable would be every cellphone on the planet having its own mobile public IP address, which I think could be done with the map-encap approach to mobility. Since there are 3.3 billion such devices now, IPv4 could never do that. But then think of those bloated IPv6 addresses chewing up bandwidth on cell-phone radio links carrying streams of VoIP packets. >>>> Also, ISATAP is a transition mechanism, requiring an IPv4 address. >>> >>> A private IPv4 address; yes. There are lots of those >>> available within end sites without impacting routing >>> scaling within the core. >>> >> OK - so all hosts with a public address in an ISATAP upgraded >> network would need to be reconfigured in some way to have an >> additional non-public IPv4 address? > > Nodes that have public IPv4 addresses and with access to > the global Internet would prefer to use 6to4 [RFC3056] > over using ISATAP. OK. >> I have never tried running IPv6, but I imagine that not all >> applications will make the right decision (however defined) about >> choosing between IPv4 or IPv6 addresses - and of many or most can't >> use IPv6 at all. If the upgrade to ISATAP or whatever causes flaky >> behavior or confusion for users, it is a non-starter. > > Again, to my understanding, there are address selection > rules and APIs used for this purpose. OK, but my impression is that there would be some flakiness from the point of view of the ordinary user. >> Since my criteria (10) and above involve end-users having continued, >> full communication with the rest of the world's IPv4 hosts, >> including with some of their hosts operating with their existing >> stable public IPv4 addresses because they are servers, I don't see >> how ISATAP could achieve this and help with one or the other of the >> problems: routing scaling or IPv4 address depletion. >> >> Perhaps you could explain by way of an example how ISATAP would help? > > ISATAP supports communicating endpoints that use IPv6 > w/o disrupting any pre-existing IPv4 infrastructure nor > interfering with future IPv4 deployment. We haven't > talked yet about the role of IPv4 NATs, but IMHO we can > simply acknowledge that NATs exist and leave it at that. OK. My expectation that ISATAP should considered as a way of helping with routing scaling was mine alone - not what you wrote. >> Suppose there is a company with 1000 staff, 1000 desktop PCs of >> various flavours - Windoze, Mac, GNU/Linux etc. There are also a >> bunch of servers of similar flavours, some on private addresses and >> others on public addresses in the PA or PI space the company >> currently uses. Some of these servers and routers are publicly >> addressable, for the public and for employees doing email, VPN etc. >> when in other locations. Some of these desktop machines, printers, >> routers, servers etc. can handle IPv6 and others can't. Some can be >> reconfigured and some can't. >> >> The company must keep all this going. Whatever effort it makes to >> deploy ISATAP (or any other scheme) needs to be paid for immediately >> or within months by benefits such as: >> >> 1 - A cheaper, more flexible approach to multihoming, >> portability, TE etc. than the current PI approach, or >> than be converting from current PA space to new >> PI space using conventional BGP management. >> >> 2 - Whatever benefits the company might gain from having >> some or all of its machines able to use IPv6. (This >> is no benefit at all at present for most users, since >> any host worth connecting to will make itself available >> on IPv4, not just on IPv6.) >> >> 3 - Some other benefits? >> >> The fact that adoption helps with the routing scalability or IPv4 >> address depletion problem now or in the future is not a benefit to >> the company. >> >> What exactly would the company need to do to adopt ISATAP? >> >> What changes to routers and hosts would this involve? >> >> What new boxes or new address assignments would be needed? > > All that is needed to enable ISATAP is to turn it on > through relatively simple administrative actions. Then, > end systems and routers that understand ISATAP should > "just work". I was hoping for a more detailed description, but since ISATAP isn't a contender for solving the routing scaling problem, this list is not the appropriate place to go into such detail. Googling "ISATAP" deployment turns up a number of pages. However, with "ISATAP" only returning 49k pages, I guess it is not very widely used. "6to4" turns up 131k. >> How scalable is ISATAP's provision of IPv6 connectivity? For >> instance, if 10% or 70% of end-user networks adopted ISATAP, would >> this tangle up the IPv6 routing system? > > I don't see how, i.e., I don't see any undesireable > interactions with the IPv6 routing system. Without knowing how ISATAP worked, I was wondering whether as a transition mechanism it involved arrangements which were sub-optimal compared to whatever is the best way of doing native IPv6 connectivity. >> If so, what steps would >> end-users need to take to get a different kind of IPv6 connection, >> perhaps with different addresses, which would not make a mess of the >> IPv6 routing system? > > There probably should be a pecking-order of sorts, e.g., > > 1) use native IPv6 if available, else: > 2) use 6to4 if available, else: > 3) use ISATAP if available, else: > 4) use TEREDO if avaialble > > and, ideally, the selection would be done w/o explicit > end-user involvement. OK. Thanks for this. >> What benefits for the company result in the next 6 months? >> >> Although I know little about ISATAP, I think I know enough to say >> that it doesn't meet my criteria. >> >> Perhaps you can show me the way through the problems I foresee, or >> suggest some other criteria which ISATAP satisfies, and still >> provides reasonably immediate benefits to early adoptors - whilst >> making some kind of contribution to solving the routing scaling and >> IPv4 address depletion problems. > > As I said above, IMHO the IPv6 debate needs to be taken > to a higher level and is not specific to just ISATAP. OK - I think this comes down to whether the end-user really has a direct need for IPv6 connectivity. At present, and for the foreseeable future, most end-users don't. - Robin -- to unsubscribe send a message to [EMAIL PROTECTED] with the word 'unsubscribe' in a single line as the message text body. archive: <http://psg.com/lists/rrg/> & ftp://psg.com/pub/lists/rrg
