Attached is a very rough draft to make IPv6 more deployable.
Don't I forget to forbid some of the so many useless features
of IPv6?
Comments are welcome.
Masataka Ohta
---
INTERNET DRAFT M. Ohta
draft-ohta-sipa-00.txt Tokyo Institute of Technology
May 2003
Simple Internet Protocol, Again
Status of this Memo
This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet- Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/1id-abstracts.html
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html
Abstract
IPv6 has failed to be deployed partly because of its complexity.
IPv6 mostly is a descendant of SIP (Simple Internet Protocol) but has
fatally bloated merging with other proposals and trying to make IPv6
has better functionality than IPv4, which makes IPv6 unnecessarily
complex and, thus, worse than IPv4.
SIPA (Simple Internet Protocol, Again) is a proposal attempting to
restore simplicity to IPv6 sticking to the real world operational
requirements for the IPv4 Internet to make IPv6 more acceptable to
ISPs and end users.
1. Introduction
IPv6 has failed to be deployed partly because of its complexity.
It is a complexity of not only coding but also operation. It should
be noted that, even though running code may be widely available, it
is not because IPv6 is so simple that implementors enjoyed coding
M. Ohta Expires on November 25, 2003 [Page 1]
INTERNET DRAFT Simple Internet Protocol, Again May 2003
(which was why, in good old days, running code principle was a good
measure of protocol quality) but because governments and vendors put
large amount of effort and money on it. Still, among so many IPv4
ISPs, few operate it and ratio of IPv6 end users to IPv4 ones are
even smaller.
Deployment is an operational issue and IPv6 has failed and will
continue to be failing to be deployed.
IPv6 mostly is a descendant of SIP (Simple Internet Protocol) but has
fatally bloated merging with other proposals and trying to make IPv6
have better functionality than IPv4, which makes IPv6 unnecessarily
complex and, thus, worse than IPv4.
SIPA (Simple Internet Protocol, Again) is a proposal attempting to
restore simplicity to IPv6 sticking to the real world operational
requirements for the IPv4 Internet, to make IPv6 more acceptable to
ISPs and end users.
With SIPA, IPv6 should become easy to code and operate.
In this memo, legacy IPv6 is called CIP (Complex IP), "the Internet"
means one in the real world, that is, the IPv4 Internet, and a router
is a host.
2. Requirements
The original requirement for CIP was:
Support large number of hosts large enough to make the IPv6
Internet for everyone.
which resulted in bloated CIP.
The followings are the additional requirements to SIPA based on the
operational reality of the Internet.
Suppress the number of global routing table entries even if
everyone are multihomed to the IPv6 Internet.
Make packet format compatible to CIP to make SIPA work over legacy
routers.
Remove all the features of CIP against the end to end principle.
Remove all the features of CIP not present in IPv4. No
applications on the Internet use them.
M. Ohta Expires on November 25, 2003 [Page 2]
INTERNET DRAFT Simple Internet Protocol, Again May 2003
Remove all the features of CIP not used in IPv4 Internet. No
applications on the Internet use them.
Remove all the features of CIP not useful in IPv4 Internet. No
applications on the Internet need them.
3. Removed Features
The following subsections list features of IPv6 removed to make IPv6
simpler and more deployable.
3.1 IP Header Options
Optional headers are not used on the Internet and is forbidden.
Except for an optional fragmentation header, which is used on the
Internet, a transport header follows immediately after an IP header.
Options visible to routers is a direct violation of the end to end
principle and just harmful.
Note that use of a routing header by MIPv6 is architecturally wrong,
as a home agent is, like mail relays, an end system that it should be
an destination option.
In addition, except for a fragmentation header, destination option is
still forbidden. It should be implemented at protocol (see section
3.3, for example) or transport level.
3.2 ToS & Flow Labels
ToS & flow labels are forbidden. RSVP is far less deployed than IPv6.
Even if it is deployed, removal of IP header options makes it easy
for routers access port numbers or SPI (see section 3.3) that flow
labels are not unnecessary.
While the field for ToS & flow labels is large enough to hold
fragmentation information (because MTU is large) not as an optional
header, it makes SIPA not compatible to CIP.
So, for possible future extension (such as that ECN is proven to be
useful over the Internet), the field should contain 0 at the source
and ignored by routers and the destination.
3.3 IPSEC
ESP is purely optional and should be implemented as Protocol 50. SPI
works as port numbers for resource reservation (if any). AH is
forbidden because its functionality overridden by ESP and its SPI is
M. Ohta Expires on November 25, 2003 [Page 3]
INTERNET DRAFT Simple Internet Protocol, Again May 2003
not located at port number part.
3.4 Path MTU Discoverly
Path MTU discoverly is forbidden. It often does not work over the
Internet for various reasons. As the MTU of the Internet is mostly
1500 that minimum MTU of 1280 is good enough.
Routers are encouraged to silently drop packets lager than 1280 byte
without generating ICMP.
3.5 Stateless Autoconfiguration
IPv6 specific stateless autoconfiguration is ignored. Use DHCP.
All the possible autoconfiguration can be (and is already, for most
of the case) implemented with DHCP over the Internet.
The remaining autoconfiguration features may work in an isolated
private LAN but is not meaningful over the Internet. Note, for
example, that both dentists' offices and cars have preconfigured
locks and keys.
Issues on autoconfiguration in an isolated private LAN may still be
solved, but in a way not affecting the development of the Internet
protocol nor, hopefully, IETF.
3.6 Automatic Renumbering
Automatic renumbering of IP addresses of DNS glue is ignored.
On the Internet, automatic renumbering is trivially easy, as long as
domain names, not raw IP addresses, are used to designate hosts.
However, automatic renumbering of DNS glue is impossible, because
relationship between DNS servers has nothing to do with ISP topology.
3.7 Hosts and Routers
It is a direct violation of the end to end principle to assume
intermediate systems intelligent and end systems dumb. Routers are
hosts relay packets between multiple interfaces, thus, actively
engages in generating routing tables. As has been the tradition of
early days of the Internet, hosts with single interface are still
expected to listen to IGP (e.g. routed -q). Note that DHCP can tell
hosts which IGP to use. Note also that global routing table is
assumed to be small.
3.8 Neighbor Discovery
M. Ohta Expires on November 25, 2003 [Page 4]
INTERNET DRAFT Simple Internet Protocol, Again May 2003
Neighbor discovery is not used on the Internet and is forbidden. It
has hopelessly bloated, partly because of a failed attempt to support
ATM (IPv6 thought multicast over ATM were easy) and partly because of
another failed attempt to support stateless autoconfiguration.
As for address resolution, the original purpose of ND, except for the
last hop, address resolution information for next hop routers become
available from IGP exchange. In other cases, use ARP or let hosts
speak IGP.
3.9 Jumbograms
Jumbograms are not used on the Internet and is forbidden. Super
computers today are massively parallel ones that it has enough scalar
power to handle streams of 64KB of packets.
3.10 Link & Site Local Address
Link and site local address is not used on the Internet and is
forbidden.
Note that a network behind NAT is not a part of the Internet. One may
still use NAT with IPv6, but it has nothing to do with IPv4 or IPv6
specification.
4. Other Restriction to CIP
To ease implementations, a router can forward packets to the next hop
by looking at upper 64 bits of an destination address only.
Multicast address format should be reconsidered accordingly.
A host can accept packets to it by looking at lower 64 bits of an
destination address only.
5. Remaining Works
Multi6 WG is working on site multihoming of IPv6, at least
theoretically.
However, as there can be limited number of ASes operated at TLAs,
support for NLA level ASes multihomed to TLA level ASes must be
discussed somewhere.
Mobility must be tightly integrated with multihoming, as both treats
multiple IP addresses of a host, that current specifications on MIPv6
must be ignored.
6. Security Considerations
M. Ohta Expires on November 25, 2003 [Page 5]
INTERNET DRAFT Simple Internet Protocol, Again May 2003
IPSEC sucks.
7. Author's Address
Masataka Ohta
Graduate School of Information Science and Engineering
Tokyo Institute of Technology
2-12-1, O-okayama, Meguro-ku, Tokyo 152-8552, JAPAN
Phone: +81-3-5734-3299
Fax: +81-3-5734-3299
EMail: mohta@necom830.hpcl.titech.ac.jp
M. Ohta Expires on November 25, 2003 [Page 6]