Robin, See below for some follow-up:
>-----Original Message----- >From: Robin Whittle [mailto:[EMAIL PROTECTED] >Sent: Thursday, April 03, 2008 6:55 PM >To: [email protected] >Cc: Templin, Fred L >Subject: Re: [RRG] RE: Is ISATAP a practical solution? > >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. Are you suggesting for me to revise the IPvLX proposal? >So do IPvLX and ISATAP really belong on the RRG wiki, under the >heading "Active proposals"? I think so; they have been around a lot longer than any of the proposals on your short-list (although admittedly not as long as some of the foundational earlier 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. I think there are those who place faith in header compression as a mitigation for the sort of situations you are describing. >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. Well, when you are doing encaps you are already committed to inflating the size of packets. The SEAL encapsulation does not add a lot beyond the base encapsulation, and there is value in the bits added (IMHO). >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. IMHO, I don't envision the situation in which users would relinquish their existing IPv4 addresses, i.e., even if they move to IPv6. >Maybe humanity will be stuck inhabiting IPv4 more and more >efficiently forever. Something like Positano, Italy: > >http://glamgal.typepad.com/.shared/image.html?/photos/uncategor >ized/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. IMHO, it can be a "both/and" situation as opposed to all one way or the other. >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. Again, header compression has been proposed. >>>>> 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. There's not really much more to it than what I have already said, but here is an overview that should help: http://download.microsoft.com/download/0/7/c/07ca1a49-050c-4928-a13f-67b f812d3f80/ISATAPOverview.doc Thanks - Fred [EMAIL PROTECTED] >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
