Hi Fred, I will respond to what you wrote about header lengths and SEAL in a separate thread.
You wrote: >> 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? I would have thought that if the proposal was "active", that there would be an 8 page summary and analysis document for it, and that the relevant Internet draft be updated within 6 months. Since scalability is part of what you are trying to achieve (from the introduction): This document proposes an architectural framework for IPv6/IPv4 coexistence known as: "IPvLX (IP with virtual Link eXtension)" with goals of limiting core routing table growth while supporting scaling to arbitrarily large numbers of end systems and restoring global Internet transparency. The scheme uses IPv6 for end system interface identification and simple network middleboxes to extend virtual links (VLs) across one or more IPv4 networks. I think it would be good to mention scalability in the abstract. >> 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. How then would your proposal help with the address scaling problem in the IPv4 routing system? >> 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. > > IMHO, it can be a "both/and" situation as opposed to all > one way or the other. I suppose if some set of hosts, such as cellphones each with an IPv4 address or an IPv6 /64, became needed in such numbers that they couldn't all fit on IPv4, then this would mean a large number of users would have native IPv6 addresses only. Then, some subset of other users (implicitly those with IPv4 services only) would have some kind of reason to get IPv6 - for instance to do more direct communication with those mobile hosts than would be the case via whatever gateways etc. would be used otherwise. Then, I suppose, over time the dual stack dual IPv4/IPv6 connection model could spread. All this sounds really messy - everyone being stuck in IPv4 forever or having part of the user base migrate to IPv6, but most never wanting to leave IPv4 because it works fine. Thanks for the link to this overview: http://download.microsoft.com/download/0/7/c/07ca1a49-050c-4928-a13f-67bf812d3f80/ISATAPOverview.doc The detailed technical stuff is pointed to from there: Microsoft Intra-site Automatic Tunnel Addressing Protocol Deployment Guide http://www.microsoft.com/downloads/details.aspx?FamilyID=0f3a8868-e337-43d1-b271-b8c8702344cd&displaylang=en I won't pursue these, because I think that no solution to the IPv4 routing scaling problem will be widely deployed if it relies in some way on hosts having anything to do with IPv6. - 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
