One document matched: draft-ietf-ngtrans-ipv4survey-00.txt

Network Working Group                               Philip J. Nesser II 
draft-ietf-ngtrans-ipv4survey-00.txt         Nesser & Nesser Consulting 
Internet Draft                                               April 2000
								   Expires
Octover 2000

    Survey of IPv4 Addresses in Currently Deployed IETF Standards

This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026.               

Status of this Memo

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/ietf/1id-abstracts.txt

The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
                                                                           

Abstract

This document seeks to document all usage of IPv4 addresses in currently
deployed IETF documented standards.  In order to successfully transition
from an all IPv4 Internet to an all IPv6 Internet, many interim steps will
be taken. One of these steps is the evolution of current protocols that
have IPv4 dependencies.  It is hoped that these protocols (and their
implementations) will be redesigned to be network address independent, but
failing that will at leasy dually support IPv4 and IPv6.  To this end, all
Standards (Full, Draft, Proposed and Experimental) will be survey and any
dependencies will be documented.


1.0 Introduction

1.1 Summary of Results

1.2 Short Historical Perspective

There are many challenges that face the Internet Engineering community.
The foremost of these challenges has been the scaling issue.  How to grow
a network that was envisioned to handle thousands of hosts to one that
will handle tens of millions of networks with billions of hosts.  Over the
years this scaling problem has been overcome with changes to the network
layer and to routing protocols.  (Ignoring the tremendous advances in
computational hardware)

The first "modern" transition to the network layer occurred in during the
early 1980's from the Network Control Protocol (NCP) to IPv4.  This
culminated in the famous "flag day" of January 1, 1983.  This version of
IP was documented in RFC 760.  This was a version of IP with 8 bit network
and 24 bit host addresses.  A year later IP was updated in RFC 791 to
include the famous A, B, C, D, & E class system.

Networks were growing in such a way that it was clear that a need for
breaking networks into smaller pieces was needed.  In October of 1984 RFC
917 was published formalizing the practice of subnetting.  

By the late 1980's it was clear that the current exterior routing protocol
used by the Internet (EGP) was not sufficient to scale with the growth of
the Internet.  The first version of BGP was documented in 1989 in RFC
1105.

The next scaling issues became apparent in the early 1990's was the
exhaustion of the Class B address space.  The growth and commercialization
of the Internet had organizations requesting IP addresses in alarming
numbers.  In May of 1992 over 45% of the Class B space was allocated.  In
early 1993 RFC 1466 was published directing assignment of blocks of Class
C's be given out instead of Class B's.  This solved the problem of address
space exhaustion but had significant impact of the routing infrastructure.

The number of entries in the "core" routing tables began to grow
exponentially as a result of RFC 1466.  This led to the implementation of
BGP4 and CIDR prefix addressing.  This may have solved the problem for the
present but there are still potential scaling issues.

Current Internet growth would have long overwhelmed the current address
space if industry didn't supply a solution in Network Address Translators
(NATs).  To do this the Internet has sacrificed the underlying
"End-to-End" principle.

In the early 1990's the IETF was aware of these potential problems and
began a long design process to create a successor to IPv4 that would
address these issues.  The outcome of that process was IPv6.  

The purpose of this document is not to discuss the merits or problems of
IPv6.  That is a debate that is still ongoing and will eventually be
decided on how well the IETF defines transition mechanisms and how
industry accepts the solution.  The question is not "should," but "if." 


2.0 Methodology

To perform this study each class of IETF standards are investigated in
order of maturity:  Full, Draft, Proposed, and Experimental.
Informational RFC are not addressed.  RFCs that have been obsoleted by
either newer versions or as they have transitioned through the standards
process are not covered.  

3.0 Full Standards

3.01 INTERNET OFFICIAL PROTOCOL STANDARDS. RFC 2600

Although this is classified as a standard, it does not describe a
protocol.  It is a list of assigned protocol numbers and therefore has no
IPv6 transition issues.

3.02 Assigned Numbers. RFC1700

Although this is classified as a standard, it does not describe a
protocol.  It is a list of assigned protocol numbers and therefore has no
IPv6 transition issues.

3.03 Host Requirements. RFC1122, RFC1123

3.03.1 RFC 1122 

RFC 1122 defines requirements for Internet hosts.  In Section 1.1.3
(Internet Protocol Suite), the section on layer 3 (Internet Layer)
mandates hosts implement IP, but does not specify a version requirement. 

Section 3 is devoted to a discussion of IP, ICMP, and IGMP and is riddled
with specific IPv4 requirements.  Any IPv6 only host would be
non-compliant with RFC 1122.  Some of the most obvious problems are shown
below.

In section "3.2.1.1 Version Number" it says: 'A datagram whose version
number is not 4 MUST be silently discarded.'

In section "3.2.1.3 Addressing" is clearly out of date even with the
current addressing of IPv4 addresses.

A new version of RFC 1122 should be written.  It should either be IPv6
focused (as the current RFC 1122 is IPv4 focused) and be labeled as such
(i.e. "IPv6 Host Requirements") or should be written generically with
appropriate external links.  The later would be difficult since the
document is meant to be self-contained, so the former is a more likely
solution.

3.03.2 RFC 1123

Section 2.1 "Host Names and Numbers" makes references to applications
making explicit references to "dotted decimal" notation and the form
"#.#.#.#"

Section 5.2.17 "Domain Literals:" says "A mailer MUST be able to accept
and parse an Internet domain literal whose content ("dtext"; see RFC-822)
is a dotted decimal host address." 

There are also many references to IP addresses scattered throughout the
document that make no reference to the format or version of the addresses.

Most of this document (as well as RFC 1122) is a series of references and
consolidation of data from numerous RFCs.  The few references to IPv4
addresses might not warrant a rewrite.  However the technology of the
Internet has changed substantially in the last 11 years.  With a
requirement of rewriting RFC 1122 it makes sense to update this document
for other revisions, not IPv6 related.

RFC 2181 is considered to be an "Update" to RFC1123 but is only related to
DNS issues and does not fix the problems pointed out here.

3.04 Gateway Requirements. RFC1009

It is pointless to attempt to try and quantify the IPv4 references in this
document.  The document specifies operations of IPv4 routers/gateways.
Hence, it makes numerous references that are IPv4 specific.

Like RFC 1122, it is necessary to rewrite this document and create a "IPv6
Gateway Requirements" standard.


3.05 Internet Protocol. RFC0791, RFC0950, RFC0919, RFC0922, RFC792,
     RFC1112

RFC 791 defines IPv4 and will be replaced by the IPv6 specifications.  

RFC 950 specifies IPv4 subnetting and will be replaced by the IPv6
specifications.

RFC 919 is not online and is unavailable for review.

RFC 922 specifies how broadcasts should be treated in the presence of
subnets.  The techniques of this document will be replaced by the IPv6
specifications. 

RFC 792 defines ICMP.  The specification of ICMPv6 will serve as an
update.

RFC 1112 defines IP multicast.  A similar updated version for IPv6
multicasting must be written.


3.06 User Datagram Protocol. RFC0768

Although UDP is a transport protocol there is one reference to the UDP/IP
interface that states;  "The UDP module must be able to determine the
source and destination internet addresses and the protocol field from the
internet header."  This does not force a rewrite of the protocol but will
clearly cause changes in implementations.

3.07 Transmission Control Protocol. RFC0793

Section 3.1 which specifies the header format for TCP.  The TCP header is
free from IPv4 references but there is an inconsistency in the computation
of checksums.  The text says:  "The checksum also covers a 96 bit pseudo
header conceptually prefixed to the TCP header.  This pseudo header
contains the Source Address, the Destination Address, the Protocol, and
TCP length."  The first and second 32-bit words are clearly meant to
specify 32-bit IPv4 addresses.  While no modification of the TCP protocol
is necessitated by this problem, an alternate needs to be specified as an
update document, or as part of another IPv6 document.


3.08 Telnet Protocol. RFC0854, RFC0855

3.08.1 RFC 854

There are no IPv4 dependencies in RFC 854.

3.08.2 RFC 855

There are no IPv4 dependencies in RFC 855.


3.09 File Transfer Protocol. RFC0959

Section 4.1.2 "TRANSFER PARAMETER COMMANDS" the port command has the
following format:  "PORT h1,h2,h3,h4,p1,p2" where h1 is the high order 8
bits of the internet host address.  This needs to be reworked to
transition to IPv6 addressing.

In sections 4.2.1 & 4.2.2 on reply codes, the code "227 Entering Passive
Mode (h1,h2,h3,h4,p1,p2)" also needs to be reworked for IPv6 addressing.  

Section 5.3.2 "FTP COMMAND ARGUMENTS" contains:
      <host-number> ::= <number>,<number>,<number>,<number>
            <port-number> ::= <number>,<number>
            <number> ::= any decimal integer 1 through 255
This is clearly an IPv4 address reference.


3.10 SMTP Service Extensions. RFC821, RFC1869

3.11 Standard for the format of ARPA Internet text messages. RFC0822

3.12 Network Time Protocol. RFC1119

3.13 Domain Name System. RFC1034, RFC1035

3.14 Mail Routing and the Domain System. RFC0974

3.15 Simple Network Management Protocol. RFC1157

3.16 Structure of Management Information. RFC1155

3.17 Management Information Base. RFC1213

3.18 Exterior Gateway Protocol. RFC0904

3.19 NetBIOS Service Protocols. RFC1001, RFC1002

3.20 Echo Protocol. RFC0862

3.21 Discard Protocol. RFC0863

3.22 Character Generator Protocol. RFC0864

3.23 Quote of the Day Protocol. RFC0865

3.24 Active Users Protocol. RFC0866

3.25 Daytime Protocol. RFC0867

3.26 Time Server Protocol. RFC0868

3.27 Binary Transmission Telnet Option. RFC0856

3.28 Echo Telnet Option. RFC0857

3.29 Suppress Go Ahead Telnet Option. RFC0858

3.30 Status Telnet Option. RFC0859

3.31 Timing Mark Telnet Option. RFC0860

3.32 Extended Options List Telnet Option. RFC0861

3.33 Trivial File Transfer Protocol. RFC1350

3.34 Routing Information Protocol. RFC1058

3.35 ISO Transport Service on top of the TCP (Version: 3). RFC1006

3.36 Transmission of IP and ARP over FDDI Networks. RFC1390

3.37 An Ethernet Address Resolution Protocol. RFC0826

3.38 A Reverse Address Resolution Protocol. RFC0903

3.39 Interface Message Processor: Specifications for the
     Interconnection of a Host and an IMP 

3.40 Host Access Protocol specification. RFC1221

3.41 Standard for the transmission of IP datagrams over Ethernet
     networks. RFC0894

3.42 Standard for the transmission of IP datagrams over experimental
     Ethernetnetworks. RFC0895

3.43 Standard for the transmission of IP datagrams over IEEE 802
     networks. RFC1042

3.44 DCN Local-Network Protocols. RFC0891

3.45 Internet Protocol on Network System's HYPERchannel: Protocol
     Specification. RFC1044

3.46 Transmitting IP traffic over ARCNET networks. RFC1201

3.47 Nonstandard for transmission of IP datagrams over serial lines:
     SLIP. RFC1055

3.48 Standard for the transmission of IP datagrams over NetBIOS
     networks. RFC1088

3.49 Standard for the transmission of 802.2 packets over IPX networks,
     RFC1132

3.50 Definitions of Managed Objects for the Ethernet-like Interface
     Types. RFC1643

3.51 The Point-to-Point Protocol (PPP). RFC1661, RFC1662

3.52 The Transmission of IP Datagrams over the SMDS Service. RFC1209

3.53 Post Office Protocol - Version 3. RFC1939

3.54 OSPF Version 2. RFC2328

3.55 Multiprotocol Interconnect over Frame Relay. RFC2427

3.56 RIP Version 2. RFC2453

3.57 RIP Version 2 Protocol Applicability Statement. RFC1722

3.58 Structure of Management Information Version 2 (SMIv2. RFC2578,
     RFC2579






Appendix A: Cross-reference of RFC Numbers and Location in Document

RFC Number	Section Number
------------------------------------------------------------------------
114	Section 3.09
141	Section 3.09
172	Section 3.09
238	Section 3.09
265	Section 3.09
281	Section 3.09
294	Section 3.09
354	Section 3.09
385	Section 3.09
412	Section 3.09
414	Section 3.09
430	Section 3.09
438	Section 3.09
448	Section 3.09
454	Section 3.09
458	Section 3.09
463	Section 3.09
468	Section 3.09
475	Section 3.09
478	Section 3.09
479	Section 3.09
480	Section 3.09
506	Section 3.09
520	Section 3.09
532	Section 3.09
542	Section 3.09
571	Section 3.09
593	Section 3.09
607	Section 3.09
614	Section 3.09
624	Section 3.09
630	Section 3.09
640	Section 3.09
686	Section 3.09
691	Section 3.09
697	Section 3.09
737	Section 3.09
743	Section 3.09
751	Section 3.09
765	Section 3.09
768	Section 3.06
776	Section 3.09
791	Section 3.05
792	Section 3.05
793	Section 3.07
854	Section 3.08.1
855	Section 3.08.2
919	Section 3.05
922	Section 3.05
949	Section 3.09
950	Section 3.05
959	Section 3.09
1009	Section 3.04
1083	Section 3.01
1100	Section 3.01
1112	Section 3.05
1122	Section 3.03.1
1123	Section 3.03.2
1130	Section 3.01
1140	Section 3.01
1200	Section 3.01
1250	Section 3.01
1280	Section 3.01
1360	Section 3.01
1410	Section 3.01
1500	Section 3.01
1540	Section 3.01
1600	Section 3.01
1610	Section 3.01
1700	Section 3.02
1720	Section 3.01
1780	Section 3.01
1800	Section 3.01
1880	Section 3.01
1920	Section 3.01
2000	Section 3.01
2200	Section 3.01
2300	Section 3.01
2400	Section 3.01
2500	Section 3.01
2600	Section 3.01



Authors Address

Please contact the author with any questions, comments or suggestions at:

Philip J. Nesser II
Principal
Nesser & Nesser Consulting
13501 100th Ave NE, #5202 
Kirkland, WA 98034
phil@nesser.com
(425)481-4303 (voice)
(425)482-9721 (fax)



This draft expires in October 2000.