Subject: (ngtrans) I-D ACTION:draft-ietf-ngtrans-ipv4survey-01.txt

From: [email-masked]
Date: Thu, 16 Aug 2001 07:02:37 -0400

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Next Generation Transition Working Group of the IETF.

	Title		: Survey of IPv4 Addresses in Currently Deployed IETF 
                          Standards
	Author(s)	: P. Nesser II
	Filename	: draft-ietf-ngtrans-ipv4survey-01.txt
	Pages		: 
	Date		: 15-Aug-01
	
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 least dually support IPv4 and IPv6.  To this end, all Standards (Full, Draft, Proposed and Experimental) will be surveyed and any dependencies will be documented.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-ngtrans-ipv4survey-01.txt

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-ngtrans-ipv4survey-01.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html 
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-ngtrans-ipv4survey-01.txt".
	
NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

---

From: Pekka Savola <[email-masked]>
Date: Fri, 17 Aug 2001 00:01:39 +0300 (EEST)

[ couldn't get MX for [email-masked], hopefully this goes through.. ]

Whew.  I didn't think anyone had ventured to go this far.  No small task,
this.  Thanks for all the hard work.

Reading this through, a few updates wrt. current IPv6 status.  I'm sure
I've missed a few, but anyway...

3.09 RFC 959 File Transfer Protocol

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.

==> RFC2428

3.46 RFC 1201 Transmitting IP traffic over ARCNET networks

The major concerns of this RFC with respect to IPv4 addresses occur in the
resolution of ARCnet 8bit addresses to IPv4 addresses in an "ARPlike"
method.
A similar method, very similar to this RFC, would need to be written to
support
IPv6 addresses over ARCNET.

==> RFC2497

3.54 RFC 2328 OSPF Version 2

This RFC defines a protocol for IPv4 routing.  It is highly assumptive
about address formats being IPv4 in nature.  A new versions of OSPF must
be created to support IPv6.

==> RFC2740

4.01 RFC 951 Bootstrap Protocol (BOOTP)

This protocol is designed specifically for use with IPv4.  A new version
will be required to support IPv6.  For example:

==> Replaced by stateless autoconfiguration and DHCPv6

4.04 RFC 1188 Proposed Standard for the Transmission of IP Datagrams
    over FDDI Networks
[and the Stanard this updates]

==> RFC2467

4.05 RFC 1191 Path MTU discovery (IP-MTU)

The entire process of PMTU discovery is predicated on the use of the DF
bit in the IPv4 header, an ICMP message (also IPv4 dependent) and TCP
MSS option.  There clearly needs to an PMTUv6 functionality.

==> RFC1981

4.24 RFC 1771 A Border Gateway Protocol 4 (BGP-4) (BGP-4)

This RFC defines a protocol used for exchange of IPv4 routing information
and does not support IPv6.  A new EGP must be defined for the echange of
IPv6 routing information.

==> RFC2283 (multiprotocol extensions)

5.054 RFC 1469 IP Multicast over Token-Ring Local Area Networks
      (IP-TR-MC)

This document defines the usage of IPv4 multicast over IEEE 802.5
Token Ring networks.  A new method for IPv6 multicast over these
networks will need to be defined.

==> Some of this covered in RFC2470 (formal definition missing)

5.139 RFC 2003 IP Encapsulation within IP (IPENCAPIP)

This document is designed for use in IPv4 networks.  There are
many referenced to a specified IP version number of 4 and 32-bit
addresses.  An IPv6 Encapsulation within IPv6 is required.

==> RFC2473

5.140 RFC 2004 Minimal Encapsulation within IP (MINI-IP)

This document is designed for use in IPv4 networks.  There are
many referenced to a specified IP version number of 4 and 32-bit
addresses.  A Minimal IPv6 Encapsulation within IPv6 is required.

==> Possibly above.

5.189 RFC 2165 Service Location Protocol (SLP)

==> Extensions in RFC3111.

5.218 RFC 2236 Internet Group Management Protocol, Version 2 (IGMP)

This document describes of version of IGMP used for IPv4 multicast.
A similar methodology for IPv6 multicast needs to be defined.

==> ICMPv6 and MLD (RFC2710)

5.439 RFC 2734 IPv4 over IEEE 1394

This protocol is IPv4 only.  A similar document must be defined for
IPv6.

==> draft-ietf-ipngwg-1394-02.txt

Generic note: Bill Fenner et al. are working on certain MIB updates, which
might reflect to many RFC's out there.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: "Philip J. Nesser II" <[email-masked]>
Date: Thu, 16 Aug 2001 21:58:59 -0700

Pekka,

Thanks for the comments.  What you started below is essentially the next
step in the job and will be the contents of Section 7.  Instead of trying to
do the analysis inline, Section 7 is designed to be the condensation of the
contents of Sections 3, 4, 5, & 6.  Trying to keep track of what was already
fixed/updated/replaced was too much to juggle at once.  Just trying not to
go completely insane while reading all the RFC's was almost too much for me
:-)  (This was my second pass through most of them, and lets just say they
are *not* light bedtime reading.)

I will probably reorganize and put the summary & recommendations up front
when it is finally finished.

Please keep comments and suggestions coming.  All help is most certainly
appreciated.

--->  Phil

(P.S.  I had some DNS problems earlier today and it should be fine now.)

-----Original Message-----
From: [email-masked]
[mailto:[email-masked]]On Behalf Of Pekka Savola
Sent: Thursday, August 16, 2001 2:02 PM
To: [email-masked]
Subject: Re: (ngtrans) I-D ACTION:draft-ietf-ngtrans-ipv4survey-01.txt

==> RFC2428

==> RFC2497

==> RFC2740

==> RFC2467

==> RFC1981

==> RFC2473

==> Possibly above.