I am developing a new proposal to help solve the crisis in routing and addressing, to provide a new form of mobility for both IPv4 and IPv6, and to help improve IPv4 address utilization - and thereby combat the IPv4 address depletion problem.

Ivip - Internet Vastly improved Plumbing (or your choice of several other meanings, such as "Internet Versatile redIrection of Packets" etc.) - is based on some elements of LISP (Locator/ID Separation Protocol), for which there are links at the RRG's wiki page wiki page .

For people who are new to the RRG discussion of the Internet's routing scaling problem, please see this RRG List message msg00623.html for a description of some of the terminology and for an explanation of the above diagram, which depicts multi-homing service restoration and (ITR1) Ivip's "anycast ITRs in the core/DFZ", which are now known as OITRDs (Open ITRs in the DFZ).  Please search the RRG list 2008 archives for "Newbies" for other messages which may help to familiarize you with this discussion.

Please see the ../sram-ip-forwarding/ page for more information on this routing and addressing crisis and for links to mailing lists (previously the RAM and IDR lists, now mainly the RRG list) and to other resources.

2008-06-11 In the last few days there has been a big debate on the RRG list about how rapidly IPv6 will be adopted, which is a vital question when the RRG is deciding whether to recommend a solution for IPv4 and IPv6, or just for IPv6.  

There is a similar debate in the ARIN PPML list under the threads: "IPv6 in the Economist".  This includes some interesting critiques of the IPv6 DNS arrangements by Leo Bicknell and Dean Anderson.  Also, the thread: "Portable address space vs. IPv6 auto-numbering".  That thread starts here and someone who liked my initial message suggested I "blog or wiki it".  

There was an article about IPv6, dated June 5th 2008 in The Economist Technology Quarterly by an unidentified author (Monitor): Your number's up .  Mine is the fourth comment from the bottom here:

8 Page Conceptual Summary and Analysis of Ivip 2008-04-23


This is the most concise introduction to Ivip.  It is written primarily for people who are already up to speed with RRG list discussions.

As of 2008-03-21, "OITRD" is the new name for the ITRs previously known as "anycast ITRs in the core/DFZ": psg.com/lists/rrg/2008/msg00937.html .

A discussion in early March 2008 of the initial version of Ivip-summary.pdf, and of various other aspects of Ivip, is in these messages:  msg00648.html , msg00657.html and msg00682.html .

Changelog:

Comparing LISP-NERD/ALT, APT, Ivip and TRRP (All new 2008-04-21)

• comp/ 

In the future I will update the long ivip-arch ID to become a shorter, purely architectural description to be accompanied by a bunch of new, more specific IDs.  The Ivip Architecture Internet Draft (I-D) version 00 of 2007-07-15 is:

• draft-whittle-ivip-arch-00.html HTML version, with hyperlinks in the references- which usually don't appear in the text or the IETF htmlised text versions. 
• draft-whittle-ivip-arch-00.pdf Easy to print with pagebreaks.
• draft-whittle-ivip-arch-00.txt Plain text with form-feed characters for page breaks. 
• At the IETF site: tools.ietf.org/html/draft-whittle-ivip-arch-00 (Version 01 has the same contents.)

This was completed on 2008-02-19 and concerns the fast push database distribution system.

• draft-whittle-ivip-db-fast-push-00.html 
• draft-whittle-ivip-db-fast-push-00.txt (xml version too)
• draft-whittle-ivip-db-fast-push-00.pdf Plain text, but page breaks work nicely for printing.

• At the IETF site: draft-whittle-ivip-db-fast-push-00 

The complete series of IDs will be something like:

ivip-arch-02	August 2008?	For now, please refer to Ivip-summary.pdf (above) for an architectural overview, to ivip-arch-00 and to the documents listed below.
ivip-db-fast-push-00	Done, see above.	Fast push of mapping data to hundreds of thousands or millions of ITRDs and QSCs all over the Net. Not yet updated to OITRD terminology.  In the next update I intend to go into more detail of the data formats from the RUAS to the Launch system, and then for the packets fanned out by the Replicator system,
ivip-itr-qs	Later, but much of this is in arch-00.	ITRs and Query Servers, their internal functions and how to use them.
ivip-etr-filter	Later, but much of this is in arch-00.	ETR internal functions and how to use them.  Also how outer header source address enables the ETR to respect filtering.
ivip-mobility	There should be a paper describing this, by August at the latest.	TTR internal functions and how to use them for the new kind of mobility provided by Ivip.  Please see messages and diagrams in the Mobility section below.
ivip-pmtud-frag	Later - but will be based on the material here: pmtud-frag/	Ivip is the only map-encap scheme to integrate mechanisms for handling the problems of encapsulated packets exceeding path MTU limits - apart from some recent additions to LISP, which I think are problematic.  (See critique at: lisp-links/.)
ivip-deployment	Later.	Why ISPs and end-users will want what Ivip provides, and how to get the ball rolling.  See the section below on  RRG list discussions for a message regarding the business case for the mapping system and OITRDs.

Ivip's TTR (Translating Tunnel Router) approach to mobility discussed in these messages, (some in reverse order, but this may be the best order to read them in) and in the diagrams below:


Some illustrations:

On 2008-04-21 I devised a new approach to the PMTUD (Path Maximum Transmission Unit Discovery) problems which all map-encap schemes need to deal with.  Please see:


the RRG list discussion of this, and Fred Templin's SEAL ID.

To-do, but see LISP critiques at  lisp-links/ and the Ivip business models message: psg.com/lists/rrg/2008/msg01158.html .

See the Internet Research Task Force Routing Research Group wiki page for similar "summary and analysis" documents for other proposals, according to instructions on 2007-12-20.

The RRG homepage www.irtf.org/charter?gtype=rg&group=rrg contains the charter, instructions for joining the mailing list and a link to the list archives.

Here are some more RRG links:


There is also a RADIR Design Goals document: tools.ietf.org/html/draft-narten-radir-problem-statement (my critique of version 01, 2007-08-09: www.ietf.org/mail-archive/web/ram/current/msg01809.html).

The major map-encap proposals are LISP, APT, Ivip and TRRP. Since the LISP links at the wiki page are incomplete, I have made a page to try to track the latest LISP Internet drafts: lisp-links/ and to link so some critiques of LISP.  

Ivip documentation is pretty detailed - this is about a big topic: the first major change to the routing and addressing architecture of the Net since the early 1980s.  If you only have a few minutes, there is always the script for the Ivip TV advertisement: tv-ad/ .

Here is a Quick Introduction (mid 2007) to the Internet's routing and addressing problems, and to the most significant currently proposed solutions: LISP, eFIT-APT and Ivip.

• quick-intro/  

Slides: LISP-NERD/CONS, eFIT-APT and Ivip - and some challenges common to them all
(Color diagram above added 2007-07-26, pointer to Errata added 2007-07-28.)

• slides/RAM-2007-07-28-rw.pdf  (30k) slides/RAM-2007-07-28-rw.ppt (119k)

Two tables from these slides:


Since BGP's limitations are driving the need for a new architecture, please also see also the discussion of BGP's path hunting, the MRAI timer etc. in the RRG and IDR mailing lists, beginning around 2007-06-20.  I have a little guide to this discussion at:  ../sram-ip-forwarding/##BGP_hunting_MRAI_disc .

A list of messages on the RAM list regarding LISP, between 15 June and 15 July 2007 is available here: ram-messages/ .