Request for Comments: 3794 Nesser & Nesser Consulting
Category: Informational A. Bergstrom, Ed.
Ostfold University College
June 2004
Survey of IPv4 Addresses in Currently Deployed
IETF Transport Area Standards Track and Experimental Documents
Status of this Memo
This memo provides information for the Internet community. It does
not specify an Internet standard of any kind. Distribution of this
memo is unlimited.
Copyright Notice
Copyright (C) The Internet Society (2004).
Abstract
This document seeks to document all usage of IPv4 addresses in
currently deployed IETF Transport Area 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, and Proposed) as well as Experimental RFCs will be
surveyed and any dependencies will be documented.
Table of Contents
1.0. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2.0. Document Organization. . . . . . . . . . . . . . . . . . . . 2
3.0. Full Standards . . . . . . . . . . . . . . . . . . . . . . . 2
4.0. Draft Standards. . . . . . . . . . . . . . . . . . . . . . . 10
5.0. Proposed Standards . . . . . . . . . . . . . . . . . . . . . 11
6.0. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . 22
7.0. Summary of Results . . . . . . . . . . . . . . . . . . . . . 27
7.1. Standards. . . . . . . . . . . . . . . . . . . . . . . 27
7.2. Draft Standards. . . . . . . . . . . . . . . . . . . . 27
7.3. Proposed Standards . . . . . . . . . . . . . . . . . . 27
7.4. Experimental RFCs. . . . . . . . . . . . . . . . . . . 29
8.0. Security Considerations. . . . . . . . . . . . . . . . . . . 30
9.0. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 30
10.0. Normative Reference. . . . . . . . . . . . . . . . . . . . . 30
11.0. Authors’ Addresses . . . . . . . . . . . . . . . . . . . . . 30
12.0. Full Copyright Statement . . . . . . . . . . . . . . . . . . 31
1.0. Introduction
This document is part of a document set aiming to document all usage
of IPv4 addresses in IETF standards. In an effort to have the
information in a manageable form, it has been broken into 7 documents
conforming to the current IETF areas (Application, Internet,
Operations & Management, Routing, Security, Sub-IP and Transport).
For a full introduction, please see the introduction [1].
2.0. Document Organization
The rest of the document sections are described below.
Sections 3, 4, 5, and 6 each describe the raw analysis of Full,
Draft, and Proposed Standards, and Experimental RFCs. Each RFC is
discussed in its turn starting with RFC 1 and ending with (around)
RFC 3100. The comments for each RFC are "raw" in nature. That is,
each RFC is discussed in a vacuum and problems or issues discussed do
not "look ahead" to see if the problems have already been fixed.
Section 7 is an analysis of the data presented in Sections 3, 4, 5,
and 6. It is here that all of the results are considered as a whole
and the problems that have been resolved in later RFCs are
correlated.
3.0. Full Standards
Full Internet Standards (most commonly simply referred to as
"Standards") are fully mature protocol specification that are widely
implemented and used throughout the Internet.
3.1. RFC 768 User Datagram Protocol
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.2. RFC 793 Transmission Control Protocol
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.3. RFC 907 Host Access Protocol specification
This is a layer 3 protocol, and has as such no IPv4 dependencies.
3.4. NetBIOS Service Protocols. RFC1001, RFC1002
3.4.1. RFC 1001 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A
TCP/UDP TRANSPORT: CONCEPTS AND METHODS
Section 15.4.1. RELEASE BY B NODES defines:
A NAME RELEASE DEMAND contains the following information:
- NetBIOS name
- The scope of the NetBIOS name
- Name type: unique or group
- IP address of the releasing node
- Transaction ID
Section 15.4.2. RELEASE BY P NODES defines:
A NAME RELEASE REQUEST contains the following information:
- NetBIOS name
- The scope of the NetBIOS name
- Name type: unique or group
- IP address of the releasing node
- Transaction ID
A NAME RELEASE RESPONSE contains the following information:
- NetBIOS name
- The scope of the NetBIOS name
- Name type: unique or group
- IP address of the releasing node
- Transaction ID
- Result:
- Yes: name was released
- No: name was not released, a reason code is provided
Section 16. NetBIOS SESSION SERVICE states:
The NetBIOS session service begins after one or more IP
addresses have been found for the target name. These addresses
may have been acquired using the NetBIOS name query
transactions or by other means, such as a local name table or
cache.
Section 16.1. OVERVIEW OF NetBIOS SESSION SERVICE
Session service has three phases:
Session establishment - it is during this phase that the IP
address and TCP port of the called name is determined, and a
TCP connection is established with the remote party.
6.1.1. SESSION ESTABLISHMENT PHASE OVERVIEW
An end-node begins establishment of a session to another node
by somehow acquiring (perhaps using the name query transactions
or a local cache) the IP address of the node or nodes purported
to own the destination name.
Once the TCP connection is open, the calling node sends session
service request packet. This packet contains the following
information:
- Calling IP address (see note)
- Calling NetBIOS name
- Called IP address (see note)
- Called NetBIOS name
NOTE: The IP addresses are obtained from the TCP service
interface.
If a compatible LISTEN exists, and there are adequate
resources, then the session server may transform the existing
TCP connection into the NetBIOS data session. Alternatively,
the session server may redirect, or "retarget" the caller to
another TCP port (and IP address).
If the caller is redirected, the caller begins the session
establishment anew, but using the new IP address and TCP port
given in the retarget response. Again a TCP connection is
created, and again the calling and called node exchange
credentials. The called party may accept the call, reject the
call, or make a further redirection.
17.1. OVERVIEW OF NetBIOS DATAGRAM SERVICE
Every NetBIOS datagram has a named destination and source. To
transmit a NetBIOS datagram, the datagram service must perform
a name query operation to learn the IP address and the
attributes of the destination NetBIOS name. (This information
may be cached to avoid the overhead of name query on subsequent
NetBIOS datagrams.)
17.1.1. UNICAST, MULTICAST, AND BROADCAST
NetBIOS datagrams may be unicast, multicast, or broadcast. A
NetBIOS datagram addressed to a unique NetBIOS name is unicast.
A NetBIOS datagram addressed to a group NetBIOS name, whether
there are zero, one, or more actual members, is multicast. A
NetBIOS datagram sent using the NetBIOS "Send Broadcast
Datagram" primitive is broadcast.
17.1.2. FRAGMENTATION OF NetBIOS DATAGRAMS
When the header and data of a NetBIOS datagram exceeds the
maximum amount of data allowed in a UDP packet, the NetBIOS
datagram must be fragmented before transmission and reassembled
upon receipt.
A NetBIOS Datagram is composed of the following protocol
elements:
- IP header of 20 bytes (minimum)
- UDP header of 8 bytes
- NetBIOS Datagram Header of 14 bytes
- The NetBIOS Datagram data.
18. NODE CONFIGURATION PARAMETERS
- B NODES:
- Node’s permanent unique name
- Whether IGMP is in use
- Broadcast IP address to use
- Whether NetBIOS session keep-alives are needed
- Usable UDP data field length (to control fragmentation)
- P NODES:
- Node’s permanent unique name
- IP address of NBNS
- IP address of NBDD
- Whether NetBIOS session keep-alives are needed
- Usable UDP data field length (to control fragmentation)
- M NODES:
- Node’s permanent unique name
- Whether IGMP is in use
- Broadcast IP address to use
- IP address of NBNS
- IP address of NBDD
- Whether NetBIOS session keep-alives are needed
- Usable UDP data field length (to control fragmentation)
All of the proceeding sections make implicit use of IPv4 addresses
and a new specification should be defined for use of IPv6 underlying
addresses.
3.4.2. RFC 1002 PROTOCOL STANDARD FOR A NetBIOS SERVICE ON A
TCP/UDP TRANSPORT: DETAILED SPECIFICATIONS
Section 4.2.1.3. RESOURCE RECORD defines
RESOURCE RECORD RR_TYPE field definitions:
Symbol Value Description:
A 0x0001 IP address Resource Record (See
REDIRECT NAME QUERY RESPONSE)
Sections 4.2.2. NAME REGISTRATION REQUEST, 4.2.3. NAME
OVERWRITE REQUEST & DEMAND, 4.2.4. NAME REFRESH REQUEST,
4.2.5. POSITIVE NAME REGISTRATION RESPONSE, 4.2.6. NEGATIVE
NAME REGISTRATION RESPONSE, 4.2.7. END-NODE CHALLENGE
REGISTRATION RESPONSE, 4.2.9. NAME RELEASE REQUEST & DEMAND,
4.2.10. POSITIVE NAME RELEASE RESPONSE, 4.2.11. NEGATIVE NAME
RELEASE RESPONSE and Sections 4.2.13. POSITIVE NAME QUERY
RESPONSE all contain 32 bit fields labeled "NB_ADDRESS" clearly
defined for IPv4 addresses Sections 4.2.15. REDIRECT NAME
QUERY RESPONSE contains a field "NSD_IP_ADDR" which also is
designed for a IPv4 address.
Section 4.3.5. SESSION RETARGET RESPONSE PACKET
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| TYPE | FLAGS | LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| RETARGET_IP_ADDRESS |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PORT |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.1. NetBIOS DATAGRAM HEADER
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.2. DIRECT_UNIQUE, DIRECT_GROUP, & BROADCAST
DATAGRAM
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | DGM_LENGTH |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| PACKET_OFFSET | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |
| |
/ SOURCE_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ USER_DATA /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.3. DATAGRAM ERROR PACKET
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | ERROR_CODE |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Section 4.4.4. DATAGRAM QUERY REQUEST
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
4.4.5. DATAGRAM POSITIVE AND NEGATIVE QUERY RESPONSE
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| MSG_TYPE | FLAGS | DGM_ID |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_IP |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| SOURCE_PORT | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ +
| |
/ DESTINATION_NAME /
/ /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
5.3. NetBIOS DATAGRAM SERVICE PROTOCOLS
The following are GLOBAL variables and should be NetBIOS user
configurable:
- BROADCAST_ADDRESS: the IP address B-nodes use to send
datagrams with group name destinations and broadcast
datagrams. The default is the IP broadcast address for a
single IP network.