Ivip
-
Internet Vastly improved Plumbing
(or your choice of several other meanings, such as "Internet Versatile
redIrection of Packets" etc.) is a
proposal I began in June 2007 to help
solve the crisis in routing and
addressing (AKA the" routing scaling problem"), 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.
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 RRG-2009/ for links to
the RRG and
to other
resources regarding scalable routing and addressing. 2009-04-23
After an extensive discussion with Bill
Herrin about anycast and "disaster recovery" arrangements, I suggested
an additional function for core-edge separation schemes such as LISP,
APT, Ivip and TRRP. (It could also work with the host-based core-edge
elimination scheme, but I think core-edge separation is better.)
This is a "Distance Server", which enables an ITR to choose, or
have chosen for it, the ETR from a list of ETRs which is "closest" in
BGP terms. Please see this RRG message and discuss it there:
Currently,
and with existing core-edge separation proposals, the best way of doing
"anycast" is the current, conventional, BGP-based approach. This
works well, but is highly unscalable. With "Distance Servers", Ivip
etc. could do much the same thing in a highly scalable fashion.
A new page
RRG-2009/constraints/
has a draft list of constraints on any scalable routing solution which
result from our reliance on widespread voluntary adoption. Please
comment on this in the RRG list.
2009-04-15
Updated the Summary and Analysis document
#summary with a more detailed discussion of how a
Multihoming Monitoring Company's system would be the authoritative
source of mapping when there was a failure of one ETR or the other, but
when both ETRs were working fine, would accept real-time mapping
changes from the end-user network itself for the purpose of real-time
adjustment of the load sharing between the two ETRs and their
associated ISPs and links.
2009-03-21
Added a page
namespace/
as part of trying to determine the meaning of the noun "namespace".
This is part of a debate on the LISP list about whether or not
statements about LISP involving separate namespaces for EIDs and RLOCs
are accurate or not. This is probably more than anyone ever
wanted to know about the meaning of the term, but since the debate has
involved the suggestion that "namespace" may have "a lot of other
definitions floating around" I tried to find them - without success.
2009-03-01
Added a page
RRG-2009/rec/
listing what I think is missing from the current version of the RRG's
draft recommendations, which are to be completed in March 2009.
This
paper:
the
authors argue that "core-edge separation" approaches is
a better way of achieving scalable routing and addressing
than "core-edge elimination" schemes. Core-edge separation
schemes are "Strategy A" in Bill Herrin's taxonomy (below) and in the
3.3 taxonomy of the draft RRG recommendations. Core-edge
separation proposals include LISP, APT, Ivip, TRRP and
Six/One Router.
2008-12-21
Updated the Summary and Analysis document (
#summary) to include mentioning of "Forwarding
with modified IP headers" as
an alternative to encapsulation.
Steve Russert and I have finished a paper
on the TTR Mobility extensions to Ivip, or to other core-edge
separation solutions to the routing scaling problem. See below:
#mobile.
2008-08-12 (updated a little
2008-08-23)
Forwarding with modified
headers: I have devised two
systems for getting packets from ITRs to ETRs without
encapsulation or address
translation. Both systems require a modest upgrade to most
or
all core (DFZ) routers and for some or many internal routers - but
would make for a much simpler, more efficient
system, with no PMTUD problems and simpler ITRs and ETRs. An
overview of these systems is now in the
#summary document.
ETR
Address Forwarding (EAF) - for IPv4More Fragments bit.
Fragment Offset.
Checksum.
Prefix Label
Forwarding (PLF) - for IPv6I
don't yet have an Internet draft for this, but the proposal is
described in detail here:
ivip6/
.
The current plan is to use a 19 bit value in the proposed
new Forwarding Label to get the packet from the ITR to one of 524,287
provider networks to which the new kind of end-user networks connect.
Each such recipient provider network can have effectively
unlimited numbers of ETRs.
There is a another page exploring
extending this system to be used by edge networks, with each such
network, including the just-mentioned recipient provider networks, able
to use 2^19 values of the proposed Forwarding Label to get the packet
from its border router to any one of 524,287 ETRs, again without any
encapsulation, PMTUD problems etc.
ivip6/lfe/Also,
a little
research page on which upper layer protocols look at bits in the IPv4
or IPv6 headers, in terms of their checksums - and which fields the
IPsec Authentication Header looks at:
checksums/
.
The
Forwarding approaches are more difficult to introduce, since they
require modest upgrades to most or all core routers, and to some, many
or all internal routers of networks which have ITRs or ETRs.
However, there are profound benefits:
- No encapsulation overheads.
- No
PMTUD problems.
- Simpler ITRs and ETRs.
In the long term, the cost of upgrading
core routers is insignificant, since the extra functions can be built
into new gear. So the long-term goal of Ivip is to run entirely
with EAF for IPv4 and PLF for IPv6.
There will be three
potential realisations for each of the Internets that Ivip could be
applied to. (Unfortunately, the IPv6 Internet is a different
Internet from the IPv4 Internet. Ideally they would be one thing,
but they are not.)
The term Ivip
refers to the overall architecture of both systems: Ivip4 and Ivip6.
| For IPv4 | For IPv6 | Notes |
| Ivip4e | Ivip6e | Encapsulation only. It would make
no sense to deploy ITRs and ETRs which could only do encapsulation,
when
in the long-term the system should work with Forwarding. So I
would never recommend Ivip or anything like it be deployed only with an
encapsulation capability. |
| Ivip4ef | Ivip6ef | Advantages:
Easy to deploy initially, since it uses
encapsulation and does not depend on upgraded core and internal routers.
Can
be switched over to Forwarding when the routers are upgraded.
Disadvantages:
Packet overhead when using encapsulation.
More complex ITRs and ETRs to cope as best
as possible with the PMTUD problems inherent in encapsulation |
| Ivip4f | Ivip6f | Advantages:
Go straight to the most efficient and
elegant mode of operation - simpler ITRs and ETRs and no encapsulation
overhead.
No need to figure out the PMTUD stuff
and create ITRs and ETRs which can handle it.
Disadvantage:
Can only be deployed once most routers are
upgraded - however, maybe that won't be too hard, so we should consider
this as a viable option. This is especially the case for IPv6,
where there is not much urgency and there are few deployed routers.
|
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.
See
also my July 2008 discussion
psg.com/lists/rrg/2008/msg02045.html responding
to David Conrad, regarding IPv6 adoption and "Dual Stack Lite".
In
late 2008, some more discussion of the difficulties in adopting IPv6
can be found in an IETF list discussion, especially these messages from
Thomas Narten and Keith Moore:
TN1
,
KM1
and
TN2.
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.
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.)
Two tables from these slides:
General
features|
| SHIM6 | Mobile
IPv6 | LISP-
NERD | LISP-
CONS or ALT | APT | Ivip |
| Address
portability | | | Y | Y | Y | Y |
| Multihoming | Y | | Y | Y | Y | Y |
| Mobility | | Y | | | | Y |
| IPv4 too | | | Y | Y | Y | Y |
Multihoming and Traffic Engineering
functionality|
| LISP-
NERD | LISP-
CONS or ALT | APT | Ivip |
| Address ITRs do complex
communications, accept and forward ICMP etc.? | Yes | Yes | Yes +
Default
Mappers | No |
| ETRs communicate with ITRs? | Yes | Yes | Yes +
Default
Mappers | No |
| Real time decisions for
multihoming service restoration and traffic engineering. | Functionality
fixed in protocols, controlled by mapping data and implemented in
real-time by ITRs etc. | No
built-in MH or load sharing functions. Open ended - relies on
external systems
chosen by end-user, and fast replication of mapping changes to all ITRs. |
Complex
communications, responding to ICMP etc.
= security problems
and heavy load for router's CPU.
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/ .
