3. 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.
This specification defines IPv4; IPv6 has been specified in separate
documents.
This specification defines ICMP, and is inherently IPv4 dependent.
There are no IPv4 dependencies in this specification.
There are many implicit assumptions about the use of IPv4 addresses
in this document.
3.5. RFC 894std41 Standard for the transmission of IP datagrams over
This specification specifically deals with the transmission of IPv4
packets over Ethernet.
3.6. RFC 895std42 Standard for the transmission of IP datagrams over
This specification specifically deals with the transmission of IPv4
packets over experimental Ethernet.
There are no IPv4 dependencies in this specification.
This specification defines broadcasting for IPv4; IPv6 uses multicast
so this is not applicable.
This specification defines how broadcasts should be treated in the
presence of subnets. IPv6 uses multicast so this is not applicable.
This specification defines IPv4 subnetting; similar functionality is
part of IPv6 addressing architecture to begin with.
3.11. RFC 1034std13 Domain Names: Concepts and Facilities
In Section 3.6, "Resource Records", the definition of A record is:
RDATA which is the type and sometimes class dependent
data which describes the resource:
A For the IN class, a 32 bit IP address
And Section 5.2.1, "Typical functions" defines:
1. Host name to host address translation.
This function is often defined to mimic a previous HOSTS.TXT based
function. Given a character string, the caller wants one or more
32 bit IP addresses. Under the DNS, it translates into a request
for type A RRs. Since the DNS does not preserve the order of RRs,
this function may choose to sort the returned addresses or select
the "best" address if the service returns only one choice to the
client. Note that a multiple address return is recommended, but a
single address may be the only way to emulate prior HOSTS.TXT
services.
2. Host address to host name translation
This function will often follow the form of previous functions.
Given a 32 bit IP address, the caller wants a character string.
The octets of the IP address are reversed, used as name
components, and suffixed with "IN-ADDR.ARPA". A type PTR query is
used to get the RR with the primary name of the host. For
example, a request for the host name corresponding to IP address
1.2.3.4 looks for PTR RRs for domain name "4.3.2.1.IN-ADDR.ARPA".
There are, of course, numerous examples of IPv4 addresses scattered
throughout the document.
3.12. RFC 1035std13 Domain Names: Implementation and Specification
Section 3.4.1, "A RDATA format", defines the format for A records:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS A 32 bit Internet address.
Hosts that have multiple Internet addresses will have multiple A
records.
A records cause no additional section processing. The RDATA section
of an A line in a master file is an Internet address expressed as
four decimal numbers separated by dots without any embedded spaces
(e.g.,"10.2.0.52" or "192.0.5.6").
And Section 3.4.2, "WKS RDATA", format is:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PROTOCOL | |
+--+--+--+--+--+--+--+--+ |
| |
/ <BIT MAP> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
ADDRESS An 32 bit Internet address
PROTOCOL An 8 bit IP protocol number
<BIT MAP> A variable length bit map. The bit map
must be a multiple of 8 bits long.
The WKS record is used to describe the well known services supported
by a particular protocol on a particular internet address. The
PROTOCOL field specifies an IP protocol number, and the bit map has
one bit per port of the specified protocol. The first bit
corresponds to port 0, the second to port 1, etc. If the bit map
does not include a bit for a protocol of interest, that bit is
assumed zero. The appropriate values and mnemonics for ports and
protocols are specified in RFC1010(-> 1060(-> 1340(-> 1700hist(-> 3232)))).
For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP
port 25 (SMTP). If this bit is set, a SMTP server should be
listening on TCP port 25; if zero, SMTP service is not supported on
the specified address.
The purpose of WKS RRs is to provide availability information for
servers for TCP and UDP. If a server supports both TCP and UDP, or
has multiple Internet addresses, then multiple WKS RRs are used.
WKS RRs cause no additional section processing.
Section 3.5, "IN-ADDR.ARPA domain", describes reverse DNS lookups and
is clearly IPv4 dependent.
There are, of course, numerous examples of IPv4 addresses scattered
throughout the document.
3.13. RFC 1042std43 Standard for the transmission of IP datagrams over IEEE
This specification specifically deals with the transmission of IPv4
packets over IEEE 802 networks.
There are a variety of methods used in this standard to map IPv4
addresses to 32 bits fields in the HYPERchannel headers. This
specification does not support IPv6.
3.15. RFC 1055std47 Nonstandard for transmission of IP datagrams over serial
This specification is more of an analysis of the shortcomings of SLIP
which is unsurprising. The introduction of PPP as a general
replacement of SLIP has made this specification essentially unused.
No update need be considered.
3.16. RFC 1088std48 Standard for the transmission of IP datagrams over
This specification documents a technique to encapsulate IP packets
inside NetBIOS packets.
The technique presented of using NetBIOS names of the form
IP.XX.XX.XX.XX will not work for IPv6 addresses since the length of
IPv6 addresses will not fit within the NetBIOS 15 octet name
limitation.
This specification defines IP multicast. Parts of the document are
IPv4 dependent.
3.18. RFC 1132std49 Standard for the transmission of 802.2 packets over IPX
There are no IPv4 dependencies in this specification.
The major concerns of this specification with respect to IPv4
addresses occur in the resolution of ARCnet 8bit addresses to IPv4
addresses in an "ARPlike" method. This is incompatible with IPv6.
This specification defines running IPv4 and ARP over SMDS. The
methods described could easily be extended to support IPv6 packets.
This specification defines the use of IPv4 address on FDDI networks.
There are numerous IPv4 dependencies in the specification.
In particular the value of the Protocol Type Code (2048 for IPv4) and
a corresponding Protocol Address length (4 bytes for IPv4) needs to
be created. A discussion of broadcast and multicast addressing
techniques is also included, and similarly must be updated for IPv6
networks. The defined MTU limitation of 4096 octets of data (with
256 octets reserved header space) should remain sufficient for IPv6.
There are no IPv4 dependencies in this specification.
3.23. RFC 1662std51 PPP in HDLC-like Framing
There are no IPv4 dependencies in this specification.
There are no IPv4 dependencies in this specification.
