Ivip (Internet Vastly Improved Plumbing) Architecture
draft-whittle-ivip-arch-04
Document | Type |
Expired Internet-Draft
(individual)
Expired & archived
|
|
---|---|---|---|
Author | Robin Whittle | ||
Last updated | 2010-03-08 | ||
RFC stream | (None) | ||
Intended RFC status | (None) | ||
Formats | |||
Stream | Stream state | (No stream defined) | |
Consensus boilerplate | Unknown | ||
RFC Editor Note | (None) | ||
IESG | IESG state | Expired | |
Telechat date | (None) | ||
Responsible AD | (None) | ||
Send notices to | (None) |
This Internet-Draft is no longer active. A copy of the expired Internet-Draft is available in these formats:
Abstract
Ivip (Internet Vastly Improved Plumbing) is a Core-Edge Separation solution to the routing scaling problem, for both IPv4 and IPv6. It provides portable address "edge" address space which is suitable for multihoming and inbound traffic engineering (TE) to end-user networks of all types and sizes - in a manner which imposes far less load on the DFZ control plane than the only current method of achieving these benefits: separately advertised PI prefixes. Ivip includes two extensions for ITR-to-ETR tunneling without encapsulation and the Path MTU Discovery problems which result from encapsulation - one for IPv4 and the other for IPv6. Both involve modifying the IP header and require most DFZ routers to be upgraded. Ivip is a good basis for the TTR (Translating Tunnel Router) approach to mobility, in which mobile hosts retain an SPI micronet of one or more IPv4 addresses (or IPv6 /64s) no matter what addresses or access network they are using, including behind NAT and on SPI addresses. TTR mobility for both IPv4 and IPv6 involves generally optimal paths, works with unmodified correspondent hosts and supports all application protocols.
Authors
(Note: The e-mail addresses provided for the authors of this Internet-Draft may no longer be valid.)