Subject: Simple Internet Protocol, Again

From: Masataka Ohta <[email-masked]>
Date: Mon, 26 May 2003 23:40:46 +0859 ()

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: [email-masked]

M. Ohta               Expires on November 25, 2003              [Page 6]

---

From: Soohong Daniel Park <[email-masked]>
Date: Tue, 27 May 2003 09:25:49 +0900

Hi Ohta.

I've looked over your draft quickly, however I don't see 
what applicability statement is possible.

	Daniel
	Mobile Platform Laboratory, SAMSUNG Electronics

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Masataka Ohta
Sent: Monday, May 26, 2003 11:42 PM
To: [email-masked]
Subject: Simple Internet Protocol, Again

Comments are welcome.

						Masataka Ohta
---

INTERNET DRAFT                                                   M. Ohta

Status of this Memo

Abstract

1. Introduction



2. Requirements



3. Removed Features

3.1 IP Header Options

3.2 ToS & Flow Labels

3.3 IPSEC



3.4 Path MTU Discoverly

3.7 Hosts and Routers

3.8 Neighbor Discovery



3.9 Jumbograms

5. Remaining Works



   IPSEC sucks.

7. Author's Address

   Masataka Ohta

   Phone: +81-3-5734-3299
   Fax: +81-3-5734-3299

---

From: Masataka Ohta <[email-masked]>
Date: Tue, 27 May 2003 10:34:56 +0859 ()

Daniel;

> what applicability statement is possible.

It is a reality check agaist people dreaming of magical
deployment of IPv6.

It can also be a proposal to shutdown activities to further
complicate IPv6.

						Masataka Ohta

---

From: Iljitsch van Beijnum <[email-masked]>
Date: Tue, 27 May 2003 19:16:37 +0200

On dinsdag, mei 27, 2003, at 03:35 Europe/Amsterdam, Masataka Ohta 

> It can also be a proposal to shutdown activities to further

One of your objections against IPv6 as-is is that it is hard to 
implement. But by now a good number of vendors have implemented. 
Wouldn't "simplifying" existing code and increasing the 
interoperability mess (v4, v6complex and v6"simple") be a bigger hassle 
than simply using IPv6 the way it is now?