Network Working Group Philip J. Nesser II draft-ietf-ngtrans-ipv4survey-02.txt Nesser & Nesser Consulting Internet Draft March 2002 Expires September 2002 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 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. 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 to 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 "when." 1.3 A Brief Aside Throughout this document there are discussions on how protocols might be updated to support IPv6 addresses. Although current thinking is that IPv6 should suffice as the dominant network layer protocol for the lifetime of the author, it is not unreasonable to contemplate further upgrade to IP. Work done by the IRTF Interplanetary Internet Working Group shows one idea of far reaching thinking. It may be a reasonable idea (or may not) to consider designing protocols in such a way that they can be either IP version aware or independent. This idea must be balanced against issues of simplicity and performance. Therefore it is recommended that protocol designer keep this issue in mind in future designs. Just as a reminder, remember the words of Jon Postel: "Be conservative in what you send; be liberal in what you accept from others." 1,4 An Observation on the Classification of Standards It has become clear during the course of this investigation that there has been little management of the status of standards over the years. Some attempt has been made by the introduction of the classification of standards into Full, Draft, Proposed, Experimental, and Historic. However, there has not been a concerted effort to actively manage the classification for older standards. Standards are only classified as Historic when either a newer version of the protocol is deployed, it is randomly noticed that an RFC describes a long dead protocol, or a serious flaw is discovered in a protocol. Another issue is the status of Proposed Standards. Since this is the entry level position for protocols entering the standards process, many old protocols or non- implemented protocols linger in this status indefinitely. This problem also exists for Experimental Standards. Similarly the problem exists for the Best Current Practices (BCP) and For You Information (FYI) series of documents. It is the intention of the author to actively pursue the active management of protocol series. There is no current responsibility in the management structure of the IETF (WG, AD, IESG, IETF-Chair, IAB RFC Editor, or IANA) to perform this function. All of these positions are usually concerned with the current and future developments of protocols in the standards process (i.e. they look at the present and the future, but not the past). It is likely that unless this function is formalized in some way, that any individual effort will be of limited duration. It is therefore proposed that this responsibility be embodied formally. Three possible suggestion are the creation of a working group in the General Area be created to actively and periodically review the status of RFC classifications. A second possibility is to more formally and actively have this duty taken up by the RFC Editor. A final possibility is the creation of a permanent position (similar to the RFC Editor) who is responsible for the active management of the document series. To exemplify this point, there are 61 Full Standards, only 4 of which have been reclassified to Historic. There are 65 Draft Standards, 611 Proposed Standards, and 150 Experimental RFCs, of which only 66 have been reclassified as Historic. That is a rate of less than 8%. It should be obvious that in the more that 30 years of protocol development and documentation there should be at least as many (if not a majority of) protocols that have been retired compared to the ones that are currently active. Please note that there is occasionally some confusion of the meaning of a "Historic" classification. It does NOT necessarily mean that the protocol is not being used. A good example of this concept is the Routing Information Protocol(RIP) version 1. There are many thousands of sites using this protocol even though it has Historic status. There are potentially hundreds of otherwise classified RFC's that should be reclassified. 2.0 Methodology To perform this study each class of IETF standards are investigated in order of maturity: Full, Draft, and Proposed, as well as 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. Please note that a side effect of this choice of methodology is that some protocols that are defined by a series of RFC's that are of different levels of standards maturity are covered in different spots in the document. Likewise other natural groupings (i.e. MIBs, SMTP extensions, IP over FOO, PPP, DNS, etc.) could easily be imagined. 2.1 Scope The procedure used in this investigation is an exhaustive reading of the applicable RFC's. This task involves reading approximately 25000 pages of protocol specifications. To compound this, it was more than a process of simple reading. It was necessary to attempt to understand the purpose and functionality of each protocol in order to make a proper determination of IPv4 reliability. The author has made ever effort to make this effort and the resulting document as complete as possible, but it is likely that some subtle (or perhaps not so subtle) dependence was missed. The author encourage those familiar (designers, implementers or anyone who has an intimate knowledge) with any protocol to review the appropriate sections and make comments. 2.2 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 RFC 3247. The comments for each RFC is "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. Section 8 is a discussion of protocols that assume a "long term" stability in IP addresses. That is protocols that depend on the address being known and/or stable for a longer period than a connection. This is a difficult analysis because this issue mighty be tightly related to implementations. Appendix A is a cross-reference table between RFC numbers and the document section in which it is discussed. 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.01 RFC 2600 INTERNET OFFICIAL PROTOCOL STANDARDS 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 RFC 1700 Assigned Numbers 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 reasons, 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 RFC 1009 Gateway Requirements 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 RFC 791 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 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.07 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.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 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. 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.10.1 RFC 821 Section 4.1.2 "Command Syntax" contains the following reference: <dotnum> ::= <snum> "." <snum> "." <snum> "." <snum> The is clearly an IPv4 address reference. There is also the following paragraph: Sometimes a host is not known to the translation function and communication is blocked. To bypass this barrier two numeric forms are also allowed for host "names". One form is a decimal integer prefixed by a pound sign, "#", which indicates the number is the address of the host. Another form is four small decimal integers separated by dots and enclosed by brackets, e.g., "[123.255.37.2]", which indicates a 32-bit ARPA Internet Address in four 8-bit fields. 3.10.2 RFC 1869 There are no IPv4 dependencies in RFC 1869. 3.11 RFC 822 Standard for the format of ARPA Internet text messages 6.2.3. "DOMAIN TERMS" contains the following text: A domain-ref must be THE official name of a registry, network, or host. It is a symbolic reference, within a name sub- domain. At times, it is necessary to bypass standard mechan- isms for resolving such references, using more primitive information, such as a network host address rather than its associated host name. To permit such references, this standard provides the domain- literal construct. Its contents must conform with the needs of the sub-domain in which it is interpreted. Domain-literals which refer to domains within the ARPA Inter- net specify 32-bit Internet addresses, in four 8-bit fields noted in decimal, as described in Request for Comments #820, "Assigned Numbers." For example: [10.0.3.19] Note: THE USE OF DOMAIN-LITERALS IS STRONGLY DISCOURAGED. It is permitted only as a means of bypassing temporary system limitations, such as name tables which are not complete. 3.12 RFC 1305 Network Time Protocol (Version 3) Section 3.2.1 Common Variables defines the following variable definitions: Peer Address (peer.peeraddr, pkt.peeraddr), Peer Port (peer.peerport,pkt.peerport): These are the 32-bit Internet address and 16-bit port number of the peer. Host Address (peer.hostaddr, pkt.hostaddr), Host Port (peer.hostport,pkt.hostport): These are the 32-bit Internet address and 16-bit port number of the host. They are included among the state variables to support multi-homing. Section 3.4.3 Receive Procedures defines the following procedure: The source and destination Internet addresses and ports in the IP and UDP headers are matched to the correct peer. If there is no match a new instantiation of the protocol machine is created and the association mobilized. Section 3.6 Access Control Issues proposes a simple authentication scheme as follows: If a more comprehensive trust model is required, the design can be based on an access-control list with each entry consisting of a 32-bit Internet address, 32-bit mask and three-bit mode. If the logical AND of the source address (pkt.peeraddr) and the mask in an entry matches the corresponding address in the entry and the mode (pkt.mode) matches the mode in the entry, the access is allowed; otherwise an ICMP error message is returned to the requestor. Through appropriate choice of mask, it is possible to restrict requests by mode to individual addresses, a particular subnet or net addresses, or have no restriction at all. The access-control list would then serve as a filter controlling which peers could create associations. Appendix B Section 3 (i.e. B.3 Commands) defines the following command: Set Trap Address/Port (6): The command association identifier, status and data fields are ignored. The address and port number for subsequent trap messages are taken from the source address and port of the control message itself. The initial trap counter for trap response messages is taken from the sequence field of the command. The response association identifier, status and data fields are not significant. Implementations should include sanity timeouts which prevent trap transmissions if the monitoring program does not renew this information after a lengthy interval. The address clearly assumes an IPv4 address. There are numerous places in sample code and algorithms use the above mentioned variables. It seems that there is no reason to modify the actual protocol. A small number of text changes and an update to implementations to understand both IPv4 and IPv6 addresses can achieve an NTP that works on both network layer protocols. 3.13 Domain Name System. RFC1034, RFC1035 3.13.1 RFC 1034 Domain Concepts and Facilities In Section 3.6. Resource Records the definition of A records 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 In 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. There is currently a large debate ongoing in the DNS community over the use of A6 or AAAA record types for the resolution of IPv6 addresses. The fact that current A records are insufficient to support IPv6 is not unknown to the Internet community. 3.13.2 RFC 1035 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 imbedded spaces (e.g.,"10.2.0.52" or "192.0.5.6"). Section 3.4.2. WKS RDATA format +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | 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 [RFC-1010]. 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 describe reverse DNS lookups and is clearly IPv4 dependent. There are, of course, numerous examples of IPv4 addresses scattered throughout the document. 3.14 RFC 974 Mail Routing and the Domain System The examples section of this RFC uses the well established A records which have previously been discussed. 3.15 RFC 1157 Simple Network Management Protocol Beginning in Section 3.2.6.3.2 atTable Object Type Names thru the rest of Section 3 there are numerous references to the use of IPv4 addresses as part of OIDs. Section 4. Protocol Specification specifies the format of an SNMP packet which uses the overall format of: RFC1157-SNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks FROM RFC1155-SMI; Section 4.1.3.1. Example of Table Traversal has many uses of IPv4 addresses in its example of table transversal. Section 5. Definitions reiterates the use of IPv4 addresses. RFC1157-SNMP DEFINITIONS ::= BEGIN IMPORTS ObjectName, ObjectSyntax, NetworkAddress, IpAddress, TimeTicks FROM RFC1155-SMI; 3.16 RFC 1155 Structure of Management Information Section 3.2.3.2. IpAddress defines the following: This application-wide type represents a 32-bit internet address. It is represented as an OCTET STRING of length 4, in network byte-order. There are several instances of the use of this definition in the rest of the document. 3.17 RFC 1213 Management Information Base There are far too many instances of IPv4 addresses is this document to enumerate here. Clearly the entire IP OID sub tree is rife with IPv4 dependencies. A new sub tree needs to be defined to deal with IPv6 addresses leaving the current sub tree intact for IPv4 address information. 3.18 RFC 904 Exterior Gateway Protocol This RFC has been depreciated to Historic status and is not considered. 3.19 NetBIOS Service Protocols. RFC1001, RFC1002 3.19.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. 16.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.19.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 RESPONSEall 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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. There is also a large amount of pseudo code for most of the protocols functionality that make no specific reference to IPv4 addresses. However they assume the use of the above defined packets. The pseudo code may be valid for IPv6 as long as the packet formats are updated. 3.20 RFC 862 Echo Protocol There are no IPv4 dependencies in this protocol. 3.21 RFC 863 Discard Protocol There are no IPv4 dependencies in this protocol. 3.22 RFC 864 Character Generator Protocol There are no IPv4 dependencies in this protocol. 3.23 RFC 865 Quote of the Day Protocol There are no IPv4 dependencies in this protocol. 3.24 RFC 866 Active Users Protocol There are no IPv4 dependencies in this protocol. 3.25 RFC 867 Daytime Protocol There are no IPv4 dependencies in this protocol. 3.26 RFC 868 Time Server Protocol There are no IPv4 dependencies in this protocol. 3.27 RFC 856 Binary Transmission Telnet Option There are no IPv4 dependencies in this protocol. 3.28 RFC 857 Echo Telnet Option There are no IPv4 dependencies in this protocol. 3.29 RFC 858 Suppress Go Ahead Telnet Option There are no IPv4 dependencies in this protocol. 3.30 RFC 859 Status Telnet Option There are no IPv4 dependencies in this protocol. 3.31 RFC 860 Timing Mark Telnet Option There are no IPv4 dependencies in this protocol. 3.32 RFC 861 Extended Options List Telnet Option There are no IPv4 dependencies in this protocol. 3.33 RFC 1350 Trivial File Transfer Protocol There are no IPv4 dependencies in this protocol. 3.34 RFC 1058 Routing Information Protocol This RFC has been reclassified as historic and replace by STD 56. See Section 3.56 for its further discussion. 3.35 RFC 1006 ISO Transport Service on top of the TCP (Version: 3) Section 5. The Protocol defines a mapping specification Mapping parameters is also straight-forward: network service TCP ------- --- CONNECTION RELEASE Called address server's IP address (4 octets) Calling address client's IP address (4 octets) 3.36 RFC 1390 Transmission of IP and ARP over FDDI Networks This RFC documents the use of IPv4 address on FDDI networks. It is clear that a new RFC defining the use of IPv6 addresses in a similar manner is required. 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. 3.37 RFC 826 An Ethernet Address Resolution Protocol There are no IPv4 dependencies in this protocol. 3.38 RFC 903 A Reverse Address Resolution Protocol There are no IPv4 dependencies in this protocol. 3.39 Interface Message Processor: Specifications for the Interconnection of a Host and an IMP This standard has be reclassified as Historic and is not considered in this discussion. 3.40 RFC 1221 Host Access Protocol specification There are no IPv4 dependencies in this protocol. 3.41 RFC 894 Standard for the transmission of IP datagrams over Ethernet networks This protocol specifically deals with the transmissions of IPv4 packets over Ethernet. A similar RFC must exist for transmission of IPv6 packets. 3.42 RFC 895 Standard for the transmission of IP datagrams over experimental Ethernetnetworks This protocol specifically deals with the transmissions of IPv4 packets over Ethernet. It is probably unnecessary to provide an updated RFC because of the unlikelihood of the existence of this layer 2 medium. 3.43 RFC 1042 Standard for the transmission of IP datagrams over IEEE 802 networks This protocol specifically deals with the transmissions of IPv4 packets over Ethernet. A similar RFC must exist for transmission of IPv6 packets, particularly for 802.5 networks. 3.44 RFC 891 DCN Local-Network Protocols There are many implicit assumptions about the use of IPv4 addresses in this document. It is unlikely to require any updates since no DCN networks are in existence. 3.45 RFC 1044 Internet Protocol on Network System's HYPERchannel: Protocol Specification There are a variety of methods used in this standard to map IPv4 addresses to 32 bits fields in the HYPERchannel headers. A new version of the standard will need to be written do support IPv6 on HYPERchannel networks. 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. 3.47 RFC 1055 Nonstandard for transmission of IP datagrams over serial lines: SLIP This RFC is more of a analysis of the shortcomings of SLIP which is unsurprising. The introduction of PPP as a general replacement of SLIP has made this protocol essentially unused. No update need be considered. 3.48 RFC 1088 Standard for the transmission of IP datagrams over NetBIOS networks This RFC 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. A new scheme must be invented to similarly encapsulate IPv6 packets. 3.49 RFC 1132 Standard for the transmission of 802.2 packets over IPX networks, This document is clearly intended to only be valid for IPv4 addresses but could be extended for IPv6 packets. The specification is not tightly written since it assumes 20 byte IP headers, but adds the term "usually" which has most likely been implemented as a hard value. A new, more tightly specified, RFC could be written to allow IPv6 packets, 3.50 RFC 1643 Definitions of Managed Objects for the Ethernet-like Interface Types There are no IPv4 dependencies in this protocol. 3.51 The Point-to-Point Protocol (PPP). RFC1661, RFC1662 3.51.1 RFC 1661 The Point-to-Point Protocol (PPP) The Point-to-Point Protocol (PPP) 3.51.2 RFC 1662 PPP in HDLC-like Framing There are no IPv4 dependencies in this protocol. 3.52 RFC 1209 The Transmission of IP Datagrams over the SMDS Service This RFC defines running IPv4 and ARP over SMDS. The methods described could easily be extended to support IPv6 packets, but a new RFC would be required. 3.53 RFC 1939 Post Office Protocol - Version 3 There are no IPv4 dependencies in this protocol. 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. 3.55 RFC 2427 Multiprotocol Interconnect over Frame Relay Section 11. Appendix A - NLPIDS and PIDs List of Commonly Used NLPIDs 0x00 Null Network Layer or Inactive Set (not used with Frame Relay) 0x08 Q.933 [2] 0x80 SNAP 0x81 ISO CLNP 0x82 ISO ESIS 0x83 ISO ISIS 0x8E IPv6 0xB0 FRF.9 Data Compression [14] 0xB1 FRF.12 Fragmentation [18] 0xCC IPv4 0xCF PPP in Frame Relay [17] already has a NLPID defined for the transmission of IPv6 packets. 3.56 RFC 2453 RIP Version 2 RIPv2 is only intended for IPv4 networks. IPv6 routing functionality is contain in RIPng documented in RFC 2080. 3.57 RFC 1722 RIP Version 2 Protocol Applicability Statement RIPv2 is only intended for IPv4 networks. IPv6 routing functionality is contain in RIPng documented in RFC 2081. 3.58 Structure of Management Information Version 2 (SMIv2. RFC2578, RFC2579 3.58.1 RFC 2578 Structure of Management Information Version 2 (SMIv2) Section 7.1.5. IpAddress defines: The IpAddress type represents a 32-bit internet address. It is represented as an OCTET STRING of length 4, in network byte-order. Note that the IpAddress type is a tagged type for historical reasons. Network addresses should be represented using an invocation of the TEXTUAL-CONVENTION macro [3]. Note the depreciated status of this type. 3.58.2 RFC 2579 Textual Conventions for SMIv2 There are no IPv4 dependencies in this protocol. 3.59 RFC 2819 Remote Network Monitoring Management Information Base (RMON-MIB) There are no IPv4 dependencies in this protocol. 3.60 RFC 2920 SMTP Service Extension for Command Pipelining (SMTP-pipe) There are no IPv4 dependencies in this protocol. 3.61 RFC 2289 A One-Time Password System (ONE-PASS) There are no IPv4 dependencies in this protocol. 4.0 Draft Standards Draft Standards represent the penultimate standard level in the IETF. A protocol can only achieve draft standard when there are multiple, independent, interoperable implementations. Draft Standards are usually quite mature and widely used. 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: Section 3. Packet Format All numbers shown are decimal, unless indicated otherwise. The BOOTP packet is enclosed in a standard IP [8] UDP [7] datagram. For simplicity it is assumed that the BOOTP packet is never fragmented. Any numeric fields shown are packed in 'standard network byte order', i.e. high order bits are sent first. In the IP header of a bootrequest, the client fills in its own IP source address if known, otherwise zero. When the server address is unknown, the IP destination address will be the 'broadcast address' 255.255.255.255. This address means 'broadcast on the local cable, (I don't know my net number)' [4]. ... FIELD BYTES DESCRIPTION ----- ----- --- ... ciaddr 4 client IP address; filled in by client in bootrequest if known. yiaddr 4 'your' (client) IP address; filled by server if client doesn't know its own address (ciaddr was 0). siaddr 4 server IP address; returned in bootreply by server. giaddr 4 gateway IP address, used in optional cross-gateway booting. Since the packet format is a fixed 300 bytes in length, an updated version of the protocol could easily accommodate an additional 48 bytes (4 IPV6 fields of 16 bytes to replace the existing 4 IPv4 fields of 4 bytes). 4.02 RFC 954 NICNAME/WHOIS (NICNAME) There are no IPv4 dependencies in this protocol. 4.03 RFC 1184 Telnet Linemode Option (TOPT-LINE) There are no IPv4 dependencies in this protocol. 4.04 RFC 1188 Proposed Standard for the Transmission of IP Datagrams over FDDI Networks In the "Packet Format" Section the following text is seen: The 24-bit Organization Code in the SNAP must be zero, and the remaining 16 bits are the EtherType from Assigned Numbers [13] (IP = 2048, ARP = 2054). In the "Address Resolution" Section the following text is seen: The protocol type code for IP is 2048 [13]. The hardware address length is 6. The protocol address length (for IP) is 4. In the "Multicast Support" Section An IP multicast address is mapped to an FDDI group address by placing the low order 23 bits of the IP address into the low order 23 bits of the FDDI group address 01-00-5E-00-00-00 (in "canonical" order). [See 13, page 20.] For example, the IP multicast address: 224.255.0.2 maps to the FDDI group address: 01-00-5E-7F-00-02 in which the multicast (group) bit is the low order bit of the first octet (canonical order). When bit-reversed for transmission in the destination MAC address field of an FDDI frame (native order), it becomes: 80-00-7A-FE-00-40 that is, with the multicast (group) bit as the high order bit of the first octet, that being the first bit transmitted on the medium. There is also a reserved amount of 256 bytes for new header information which would allow the use of IPv6 addresses without modification of the overall MTU. 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. 4.06 RFC 1288 The Finger User Information Protocol (FINGER) There are no IPv4 dependencies in this protocol. 4.07 RFC 1305 Network Time Protocol (Version 3) Specification, Implementation (NTPV3) There are no new issues than those presented in Section 3.12 of this document. 4.08 RFC 1356 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode (IP-X.25) Section 3.2 defines an NLPID for IP as follows: The value hex CC (binary 11001100, decimal 204) is IP [6]. Conformance with this specification requires that IP be supported. See section 5.1 for a diagram of the packet formats. Clearly a new NLPID would need to be defined for IPv6 packets. 4.09 RFC 1493 Definitions of Managed Objects for Bridges (BRIDGE-MIB) There are no IPv4 dependencies in this protocol. 4.10 RFC 1534 Interoperation Between DHCP and BOOTP (DHCP-BOOTP) There are no IPv4 dependencies in this protocol. 4.11 RFC 1542 Clarifications and Extensions for the Bootstrap Protocol There are no new issues other than those presented in Section 4.01 above. 4.12 RFC 1559 DECnet Phase IV MIB Extensions (DECNET-MIB) There are no IPv4 dependencies in this protocol. 4.13 RFC 1575 An Echo Function for CLNP (ISO 8473) (ISO-TS-ECH) There are no IPv4 dependencies in this protocol. 4.14 RFC 1629 Guidelines for OSI NSAP Allocation in the Internet (OSI-NSAP) There are no IPv4 dependencies in this protocol. 4.15 RFC 1652 SMTP Service Extension for 8bit-MIMEtransport There are no IPv4 dependencies in this protocol. 4.16 RFC 1657 Definitions of Managed Objects for the Fourth Version of the Border Gateway Protocol (BGP-4) using SMIv2 (BGP-4-MIB) The MIB defined in this RFC deals with objects in a BGP4 based routing system and therefore contain many objects that are limited by the IpAddress 32-bit value defined in MIB2. Clearly the values of this MIB are limited to IPv4 addresses. No update is needed, although a new MIB should be defined for BGP++ to allow management of IPv6 addresses and routes. 4.17 RFC 1658 Definitions of Managed Objects for Character Stream Devices using SMIv2 There are no IPv4 dependencies in this protocol. 4.18 RFC 1659 Definitions of Managed Objects for RS-232-like Hardware Devices using SMIv2 There are no IPv4 dependencies in this protocol. 4.19 RFC 1660 Definitions of Managed Objects for Parallel-printer-like Hardware Devices using SMIv2 There are no IPv4 dependencies in this protocol. 4.20 RFC 1694 Definitions of Managed Objects for SMDS Interfaces using SMIv2 (SIP-MIB) This MIB definition defines the following subtree: ipOverSMDS OBJECT IDENTIFIER ::= { smdsApplications 1 } -- Although the objects in this group are read-only, at the -- agent's discretion they may be made read-write so that the -- management station, when appropriately authorized, may -- change the addressing information related to the -- configuration of a logical IP subnetwork implemented on -- top of SMDS. -- This table is necessary to support RFC1209 (IP-over-SMDS) -- and gives information on the Group Addresses and ARP -- Addresses used in the Logical IP subnetwork. -- One SMDS address may be associated with multiple IP -- addresses. One SNI may be associated with multiple LISs. ipOverSMDSTable OBJECT-TYPE SYNTAX SEQUENCE OF IpOverSMDSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The table of addressing information relevant to this entity's IP addresses." ::= { ipOverSMDS 1 } ipOverSMDSEntry OBJECT-TYPE SYNTAX IpOverSMDSEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "The addressing information for one of this entity's IP addresses." INDEX { ipOverSMDSIndex, ipOverSMDSAddress } ::= { ipOverSMDSTable 1 } IpOverSMDSEntry ::= SEQUENCE { ipOverSMDSIndex IfIndex, ipOverSMDSAddress IpAddress, ipOverSMDSHA SMDSAddress, ipOverSMDSLISGA SMDSAddress, ipOverSMDSARPReq SMDSAddress } ipOverSMDSIndex OBJECT-TYPE SYNTAX IfIndex MAX-ACCESS read-only STATUS current DESCRIPTION "The value of this object identifies the interface for which this entry contains management information. " ::= { ipOverSMDSEntry 1 } ipOverSMDSAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address to which this entry's addressing information pertains." ::= { ipOverSMDSEntry 2 } ipOverSMDSHA OBJECT-TYPE SYNTAX SMDSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The SMDS Individual address of the IP station." ::= { ipOverSMDSEntry 3 } ipOverSMDSLISGA OBJECT-TYPE SYNTAX SMDSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The SMDS Group Address that has been configured to identify the SMDS Subscriber-Network Interfaces (SNIs) of all members of the Logical IP Subnetwork (LIS) connected to the network supporting SMDS." ::= { ipOverSMDSEntry 4 } ipOverSMDSARPReq OBJECT-TYPE SYNTAX SMDSAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The SMDS address (individual or group) to which ARP Requests are to be sent." ::= { ipOverSMDSEntry 5 } Although these OIDs are intended for IPv4 addresses, a similar MIB can be defined for IPv6 addressing. 4.21 RFC 1724 RIP Version 2 MIB Extension (RIP2-MIB) As might be expected, this RFC is filled with IPv4 dependencies since it defines a MIB for an IPv4 only routing protocol. A new MIB for RIPng is required. 4.22 RFC 1748 IEEE 802.5 MIB using SMIv2 (802.5-MIB) There are no IPv4 dependencies in this protocol. 4.23 RFC 1762 The PPP DECnet Phase IV Control Protocol (DNCP) (PPP-DNCP) There are no IPv4 dependencies in this protocol. 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 exchange of IPv6 routing information. 4.25 RFC 1772 Application of the Border Gateway Protocol in the Internet (BGP-4-APP) This RFC is a discussion of the use of BGP4 on the Internet. Since BGP4 is limited to IPv4 addresses, it is expected that a similar document will be created to be paired with the definition of the next generation BGP. 4.26 RFC 1777 Lightweight Directory Access Protocol There are no IPv4 dependencies in this protocol. 4.27 RFC 1778 The String Representation of Standard Attribute Syntaxes There are no IPv4 dependencies in this protocol. 4.28 RFC 1832 XDR: External Data Representation Standard (XDR) There are no IPv4 dependencies in this protocol. 4.29 RFC 1850 OSPF Version 2 Management Information Base (OSPF-MIB) This MIB defines managed objects for OSPFv2 which is a protocol used to exchange IPv4 routing information. Since OSPFv2 is limited to IPv4 addresses a new MIB is required to support a new version of OSPF that is IPv6 aware. 4.30 RFC 1864 The Content-MD5 Header Field (CON-MD5) There are no IPv4 dependencies in this protocol. 4.31 RFC 1905 Protocol Operations for Version 2 of the Simple Network Management Protocol (SNMPv2) (OPS-MIB) Section 4.2.2.1. Example of Table Traversal and Section 4.2.3.1. Another Example of Table Traversal both use OID's from MIB2 whose data contains IPv4 addresses. Other than their use in these example sections there are no IPv4 dependencies in this protocol. 4.32 RFC 1906 Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2) (TRANS-MIB) Section 2 Definitions contains the following OID definition: SnmpUDPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d/2d" STATUS current DESCRIPTION "Represents a UDP address: octets contents encoding 1-4 IP-address network-byte order 5-6 UDP-port network-byte order " SYNTAX OCTET STRING (SIZE (6)) Section 8.1. Usage Example also contains examples which use IPv4 address, but it has no significance in the operation of the protocol. 4.33 RFC 1907 Management Information Base for Version 2 of the Simple Network Management Protocol (SNMPv2) (SNMPv2-MIB) There are no IPv4 dependencies in this protocol. 4.34 RFC 1989 PPP Link Quality Monitoring (PPP-LINK) There are no IPv4 dependencies in this protocol. 4.35 RFC 1990 The PPP Multilink Protocol (MP) (PPP-MP) Section 5.1.3. Endpoint Discriminator Option defines a Class header field. Class The Class field is one octet and indicates the identifier address space. The most up-to-date values of the LCP Endpoint Discriminator Class field are specified in the most recent "Assigned Numbers" RFC [7]. Current values are assigned as follows: 0 Null Class 1 Locally Assigned Address 2 Internet Protocol (IP) Address 3 IEEE 802.1 Globally Assigned MAC Address 4 PPP Magic-Number Block 5 Public Switched Network Directory Number A new class field needs to be defined by the IANA for IPv6 addresses. 4.36 RFC 1994 PPP Challenge Handshake Authentication Protocol (CHAP) (PPP-CHAP) There are no IPv4 dependencies in this protocol. 4.37 RFC 2045 Multipurpose Internet Mail Extensions (MIME) Part One: Format of Internet Message Bodies (MIME) There are no IPv4 dependencies in this protocol. 4.38 RFC 2046 Multipurpose Internet Mail Extensions (MIME) Part Two: Media Types (MIME-MEDIA) There are no IPv4 dependencies in this protocol. 4.39 RFC 2047 MIME (Multipurpose Internet Mail Extensions) Part Three: Message Header Extensions for Non-ASCII Text (MIME-MSG) There are no IPv4 dependencies in this protocol. 4.40 RFC 2049 Multipurpose Internet Mail Extensions (MIME) Part Five: Conformance Criteria and Examples (MIME-CONF) There are no IPv4 dependencies in this protocol. 4.41 RFC 2067 IP over HIPPI (IP-HIPPI) Section 5.1 Packet Formats contains the following excerpt: EtherType (16 bits) SHALL be set as defined in Assigned Numbers [8]: IP = 2048 ('0800'h), ARP = 2054 ('0806'h), RARP = 32,821 ('8035'h). Section 5.5 MTU has the following definition: The MTU for HIPPI-SC LANs is 65280 bytes. This value was selected because it allows the IP packet to fit in one 64K byte buffer with up to 256 bytes of overhead. The overhead is 40 bytes at the present time; there are 216 bytes of room for expansion. HIPPI-FP Header 8 bytes HIPPI-LE Header 24 bytes IEEE 802.2 LLC/SNAP Headers 8 bytes Maximum IP packet size (MTU) 65280 bytes ------------ Total 65320 bytes (64K - 216) This definition is not applicable for IPv6 packets since packets can be larger than the IPv4 limitation of 65280 bytes. 4.42 RFC 2115 Management Information Base for Frame Relay DTEs Using SMIv2 (FRAME-MIB) This MIB has several examples of mapping IPv4 addresses to multiple Frame Relay DLCI's and monitoring their connections. A new set of OID's needs to be defined to allow this functionality for IPv6. 4.43 RFC 2131 Dynamic Host Configuration Protocol (DHCP) This version of DHCP is highly assumptive of IPv4. Significant work on DHCPv6 has been done and is ongoing. 4.44 RFC 2132 DHCP Options and BOOTP Vendor Extensions (DHCP-BOOTP) This version of DHCP is highly assumptive of IPv4. Significant work on DHCPv6 has been done and is ongoing. 4.45 RFC 2279 UTF-8, a transformation format of ISO 10646 (UTF-8) There are no IPv4 dependencies in this protocol. 4.46 RFC 2347 TFTP Option Extension (TFTP-Ext) There are no IPv4 dependencies in this protocol. 4.47 RFC 2348 TFTP Blocksize Option (TFTP-Blk) In the Section Blocksize Option Specification the following example is given: For example: +-------+--------+---+--------+---+--------+---+--------+---+ | 1 | foobar | 0 | octet | 0 | blksize| 0 | 1428 | 0 | +-------+--------+---+--------+---+--------+---+--------+---+ is a Read Request, for the file named "foobar", in octet (binary) transfer mode, with a block size of 1428 octets (Ethernet MTU, less the TFTP, UDP and IP header lengths). Clearly the example blocksize would not work with IPv6 header sizes, but it has no real signifigance on since larger blocksizes are available. 4.48 RFC 2349 TFTP Timeout Interval and Transfer Size Options (TFTP-Opt) There are no IPv4 dependencies in this protocol. 4.49 RFC 2355 TN3270 Enhancements (TN3270E) There are no IPv4 dependencies in this protocol. 4.50 RFC 2390 Inverse Address Resolution Protocol (IARP) There are no IPv4 dependencies in this protocol. 4.51 RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax (URI-GEN) Section 3.2.2. Server-based Naming Authority states: The host is a domain name of a network host, or its IPv4 address as a set of four decimal digit groups separated by ".". Literal IPv6 addresses are not supported. ... Note: A suitable representation for including a literal IPv6 address as the host part of a URL is desired, but has not yet been determined or implemented in practice. 4.52 RFC 2460 Internet Protocol, Version 6 (IPv6) Specification (IPV6) This document defines IPv6 and has no IPv4 issues. 4.53 RFC 2461 Neighbor Discovery for IP Version 6 (IPv6) (IPV6-ND) This document defines an IPv6 related protocol and has no IPv4 issues. 4.54 RFC 2462 IPv6 Stateless Address Autoconfiguration (IPV6-AUTO) This document defines an IPv6 related protocol and has no IPv4 issues. 4.55 RFC 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification (ICMPv6) This document defines an IPv6 related protocol and has no IPv4 issues. 4.56 RFC 2571 An Architecture for Describing SNMP Management Frameworks (ARCH-SNMP) There are no IPv4 dependencies in this protocol. 4.57 RFC 2572 Message Processing and Dispatching for the Simple Network Management Protocol (SNMP) (MPD-SNMP) There are no IPv4 dependencies in this protocol. 4.58 RFC 2573 SNMP Applications (SNMP-APP) There are no IPv4 dependencies in this protocol. 4.59 RFC 2574 User-based Security Model (USM) for version 3 of the Simple Network Management Protocol (SNMPv3) (USM-SNMPV3) There are no IPv4 dependencies in this protocol. 4.60 RFC 2575 View-based Access Control Model (VACM) for the Simple Network Management Protocol (SNMP) (VACM-SNMP) There are no IPv4 dependencies in this protocol. 4.61 RFC 2616 Hypertext Transfer Protocol -- HTTP/1.1 (HTTP) Section 3.2.2 http URL states: The "http" scheme is used to locate network resources via the HTTP protocol. This section defines the scheme-specific syntax and semantics for http URLs. http_URL = "http:" "//" host [ ":" port ] [ abs_path [ "?" query ]] If the port is empty or not given, port 80 is assumed. The semantics are that the identified resource is located at the server listening for TCP connections on that port of that host, and the Request-URI for the resource is abs_path (section 5.1.2). The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1900 [24]). The text is version neutral but it is unclear whether individual implementations will support IPv6 addresses. In fact the use of the ":" separator in IPv6 addresses will cause misinterpretation when parsing URI's. There are other discussions regarding a server recognizing its own IP addresses, spoofing DNS/IP address combinations, as well as the issues regarding multiple HTTP servers running on a single IP interface. The text is version neutral, but clearly remains an implementation issue. 4.62 RFC 2617 HTTP Authentication: Basic and Digest Access Authentication Section 3.2.1 The WWW-Authenticate Response Header include he following text: (Note: including the IP address of the client in the nonce would appear to offer the server the ability to limit the reuse of the nonce to the same client that originally got it. However, that would break proxy farms, where requests from a single user often go through different proxies in the farm. Also, IP address spoofing is not that hard.) Section 4.5 Replay Attacks contains the text: Thus, for some purposes, it is necessary to protect against replay attacks. A good Digest implementation can do this in various ways. The server created "nonce" value is implementation dependent, but if it contains a digest of the client IP, a time-stamp, the resource ETag, and a private server key (as recommended above) then a replay attack is not simple. An attacker must convince the server that the request is coming from a false IP address and must cause the server to deliver the document to an IP address different from the address to which it believes it is sending the document. An attack can only succeed in the period before the time-stamp expires. Digesting the client IP and time-stamp in the nonce permits an implementation which does not maintain state between transactions. Both of these statements are IP version independent and once again must rely on the implementers discretion. 4.63 RFC 2790 Host Resources MIB There are no IPv4 dependencies in this protocol. 4.64 RFC 2863 The Interfaces Group MIB (INTERGRMIB) There are no IPv4 dependencies in this protocol. There is some discussion in one OID about an interface performing a self test, but it is IP version independent. 4.65 RFC 2865 Remote Authentication Dial In User Service (RADIUS) (RADIUS) Section 3. Packet Format has the following notes: Identifier The Identifier field is one octet, and aids in matching requests and replies. The RADIUS server can detect a duplicate request if it has the same client source IP address and source UDP port and Identifier within a short span of time. and A RADIUS server MUST use the source IP address of the RADIUS UDP packet to decide which shared secret to use, so that RADIUS requests can be proxied. This text is version neutral but implementers should allow for the use of both IPv4 and IPv6 addresses. Section 5. Attributes defines a number of IP specific attributes: 4 NAS-IP-Address 8 Framed-IP-Address 9 Framed-IP-Netmask 10 Framed-Routing 14 Login-IP-Host 22 Framed-Route and definitions for the "value" field of the following type: address 32 bit value, most significant octet first. The attributes are further defined as follows: 5.4. NAS-IP-Address Description This Attribute indicates the identifying IP Address of the NAS which is requesting authentication of the user, and SHOULD be unique to the NAS within the scope of the RADIUS server. NAS-IP- Address is only used in Access-Request packets. Either NAS-IP- Address or NAS-Identifier MUST be present in an Access-Request packet. Note that NAS-IP-Address MUST NOT be used to select the shared secret used to authenticate the request. The source IP address of the Access-Request packet MUST be used to select the shared secret. A summary of the NAS-IP-Address Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 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 | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 4 for NAS-IP-Address. Length 6 Address The Address field is four octets. 5.8. Framed-IP-Address Description This Attribute indicates the address to be configured for the user. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that address, but the server is not required to honor the hint. A summary of the Framed-IP-Address Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 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 | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 8 for Framed-IP-Address. Length 6 Address The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS Should allow the user to select an address (e.g. Negotiated). The value 0xFFFFFFFE indicates that the NAS should select an address for the user (e.g. Assigned from a pool of addresses kept by the NAS). Other valid values indicate that the NAS should use that value as the user's IP address. 5.9. Framed-IP-Netmask Description This Attribute indicates the IP netmask to be configured for the user when the user is a router to a network. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint by the NAS to the server that it would prefer that netmask, but the server is not required to honor the hint. A summary of the Framed-IP-Netmask Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 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 | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 9 for Framed-IP-Netmask. Length 6 Address The Address field is four octets specifying the IP netmask of the user. 5.14. Login-IP-Host Description This Attribute indicates the system with which to connect the user, when the Login-Service Attribute is included. It MAY be used in Access-Accept packets. It MAY be used in an Access-Request packet as a hint to the server that the NAS would prefer to use that host, but the server is not required to honor the hint. A summary of the Login-IP-Host Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 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 | Length | Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 14 for Login-IP-Host. Length 6 Address The Address field is four octets. The value 0xFFFFFFFF indicates that the NAS SHOULD allow the user to select an address. The value 0 indicates that the NAS SHOULD select a host to connect the user to. Other values indicate the address the NAS SHOULD connect the user to. 5.22. Framed-Route Description This Attribute provides routing information to be configured for the user on the NAS. It is used in the Access-Accept packet and can appear multiple times. A summary of the Framed-Route Attribute format is shown below. The fields are transmitted from left to right. 0 1 2 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- | Type | Length | Text ... +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+- Type 22 for Framed-Route. Length >= 3 Text The Text field is one or more octets, and its contents are implementation dependent. It is intended to be human readable and MUST NOT affect operation of the protocol. It is recommended that the message contain UTF-8 encoded 10646 [7] characters. For IP routes, it SHOULD contain a destination prefix in dotted quad form optionally followed by a slash and a decimal length specifier stating how many high order bits of the prefix to use. That is followed by a space, a gateway address in dotted quad form, a space, and one or more metrics separated by spaces. For example, "192.168.1.0/24 192.168.1.1 1 2 -1 3 400". The length specifier may be omitted, in which case it defaults to 8 bits for class A prefixes, 16 bits for class B prefixes, and 24 bits for class C prefixes. For example, "192.168.1.0 192.168.1.1 1". Whenever the gateway address is specified as "0.0.0.0" the IP address of the user SHOULD be used as the gateway address. There are also several example authentication sequences that use the attributes discussed above and hence have IPv4 addresses. Although the definitions in this RFC are limited to IPv4 addresses, the protocol is easily extensible for new attribute types. It is therefore relatively simple to create new IPv6 specific attributes. 5.0 Proposed Standards Proposed Standards are introductory level documents. There are no requirements for even a single implementation. In many cases Proposed are never implemented or advanced in the IETF standards process. They therefore are often just proposed ideas that are presented to the Internet community. Sometimes flaws are exposed or they are one of many competing solutions to problems. In these later cases, no discussion is presented as it would not serve the purpose of this discussion. 5.001 RFC 698 Telnet extended ASCII option (TOPT-EXT) There are no IPv4 dependencies in this protocol. 5.002 RFC 726 Remote Controlled Transmission and Echoing Telnet option (TOPT-REM) There are no IPv4 dependencies in this protocol. 5.003 RFC 727 Telnet logout option (TOPT-LOGO) There are no IPv4 dependencies in this protocol. 5.004 RFC 735 Revised Telnet byte macro option (TOPT-BYTE) There are no IPv4 dependencies in this protocol. 5.005 RFC 736 Telnet SUPDUP option (TOPT-SUP) There are no IPv4 dependencies in this protocol. 5.006 RFC 749 Telnet SUPDUP-Output option (TOPT-SUPO) There are no IPv4 dependencies in this protocol. 5.007 RFC 779 Telnet send-location option (TOPT-SNDL) There are no IPv4 dependencies in this protocol. 5.008 RFC 885 Telnet end of record option (TOPT-EOR) There are no IPv4 dependencies in this protocol. 5.009 RFC 927 TACACS user identification Telnet option (TOPT-TACAC) There are no IPv4 dependencies in this protocol. 5.010 RFC 933 Output marking Telnet option (TOPT-OM) There are no IPv4 dependencies in this protocol. 5.011 RFC 946 Telnet terminal location number option (TOPT-TLN) Section "TTYLOC Number" states: The TTYLOC number is a 64-bit number composed of two (2) 32-bit numbers: The 32-bit official ARPA Internet host address (may be any one of the addresses for multi-homed hosts) and a 32-bit number representing the terminal on the specified host. The host address of [0.0.0.0] is defined to be "unknown", the terminal number of FFFFFFFF (hex, r or-1 in decimal) is defined to be "unknown" and the terminal number of FFFFFFFE (hex, or -2 in decimal) is defined to be "detached" for processes that are not attached to a terminal. Although there is a dependency here, it is unlikely to be of any major signifigance. 5.012 RFC 977 Network News Transfer Protocol (NNTP) There are no IPv4 dependencies in this protocol. 5.013 RFC 1041 Telnet 3270 regime option (TOPT-3270) There are no IPv4 dependencies in this protocol. 5.014 RFC 1043 Telnet Data Entry Terminal option: DODIIS implementation (TOPT-DATA) There are no IPv4 dependencies in this protocol. 5.015 RFC 1053 Telnet X.3 PAD option (TOPT-X.3) There are no IPv4 dependencies in this protocol. 5.016 RFC 1073 Telnet window size option (TOPT-NAWS) There are no IPv4 dependencies in this protocol. 5.017 RFC 1079 Telnet terminal speed option (TOPT-TS) There are no IPv4 dependencies in this protocol. 5.018 RFC 1091 Telnet terminal-type option (TOPT-TERM) There are no IPv4 dependencies in this protocol. 5.019 RFC 1096 Telnet X display location option (TOPT-XDL) There are no IPv4 dependencies in this protocol. 5.020 RFC 1144 Compressing TCP/IP headers for low-speed serial links (IP-CMPRS) This RFC is specifically oriented towards TCP/IPv4 packet headers and will not work in it's current form. Significant work has already been done on similar algorithms for TCP/IPv6 headers. 5.021 RFC 1195 Use of OSI IS-IS for routing in TCP/IP and dual environments (IS-IS) This documents specifies a protocol for the exchange of IPv4 routing information. It is incompatible with IPv6. There are is substantial work being done on a newer version of IS-IS that should include IPv6 routing. 5.022 RFC 1234 Tunneling IPX traffic through IP networks (IPX-IP) The section "Unicast Address Mappings" has the following text: For implementations of this memo, the first two octets of the host number will always be zero and the last four octets will be the node's four octet IP address. This makes address mapping trivial for unicast transmissions: the first two octets of the host number are discarded, leaving the normal four octet IP address. The encapsulation code should use this IP address as the destination address of the UDP/IP tunnel packet. This mapping will not be able to work with IPv6 addresses. There are also numerous discussions on systems keeping a "peer list" to map between IP and IPX addresses. The specifics are not discussed in the document and are left to the individual implementation. The section "Maximum Transmission Unit" Although larger IPX packets are possible, the standard maximum transmission unit for IPX is 576 octets. Consequently, 576 octets is the recommended default maximum transmission unit for IPX packets being sent with this encapsulation technique. With the eight octet UDP header and the 20 octet IP header, the resulting IP packets will be 604 octets long. Note that this is larger than the 576 octet maximum size IP implementations are required to accept [3]. Any IP implementation supporting this encapsulation technique must be capable of receiving 604 octet IP packets. As improvements in protocols and hardware allow for larger, unfragmented IP transmission units, the 576 octet maximum IPX packet size may become a liability. For this reason, it is recommended that the IPX maximum transmission unit size be configurable in implementations of this memo. also has some implications on IP addressing. 5.023 RFC 1239 Reassignment of experimental MIBs to standard MIBs (STD-MIBs) There are no IPv4 dependencies in this protocol. 5.024 RFC 1256 ICMP Router Discovery Messages (ICMP-ROUT) This RFC documents a protocol that is very specific to IPv4 and a successor will be needed to provide the functionality. 5.025 RFC 1269 Definitions of Managed Objects for the Border Gateway Protocol: Version 3 (BGP-MIB) The use of BGP3 has been depreciated and is not discussed. 5.026 RFC 1274 The COSINE and Internet X.500 Schema There are no IPv4 dependencies in this protocol. 5.027 RFC 1276 Replication and Distributed Operations extensions to provide an Internet Directory using X.500 There are no IPv4 dependencies in this protocol. 5.028 RFC 1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers Section 4.5 TCP/IP (RFC 1006) Network Specific Format states: The IDP and 2 digit prefix identifies a TCP/IP network where RFC 1006 is applied. It is necessary to use an IP Address, as there are insufficient bits to fit in a domain. It is structured as follows: __________________________________________________________ |_Digit___||_1-12____|13-17_(optional)_|18-22_(optional)_|_ |_Meaning_||IP_Address_|____port_______|__Transport_Set__|_ For TCP/IP there shall be a 20 digit long network-specific part. First 12 digits are for the IP address. The port number can be up to 65535, and needs 5 digits (this is optional, and is defaulted as defined in RFC 1006). Finally, there is a third part to the address, which is defined here as ``transport set'' that indicates what kind of IP-based transport protocols is used. This is a decimal number from 0-65535 which is really a 16-bit flag word. 1 is TCP, 2 is UDP. Further values of this code are assigned by the IANA. If the transport set is not there or no bits are set, it means ``default'' which is TCP. This is encoded in 5 digits. For example, the IP Address 10.0.0.6 with port 9 over UDP is encoded as: ____________________________________________________________________________ |Part______|_|_____IDP_________|____________________DSP____________________| _ |Component_|_|AFI__|___IDI_____|Prefix_|___IP_Address_____|_Port__|_T_Set__| _ |Octet_____|_|____|____________|_1-2___|______3-14________|_15-19_|_20-24__| _ |Value_____|T|elex_|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__| __ |Cncrt_Dec_|_|54___|007_28722__|__03___|_010_000_000_006__|_00009_|_00002__| _ |Cncrt_Bin_|_|54___|00_72_87_22_|_03___|01_00_00_00_00_06_|00_00_9|0_00_02_| _ This 12 octet field for decimal versions of IP addresses is insufficient for a decimal version of IPv6 addresses. It is possible to define a new encoding using the 20 digit long IP Address + Port + Transport Set fields in order to accommodate a binary version of an IPv6 address, port number and Transport Set. There are several schemes that could be envisioned. 5.029 RFC 1285 FDDI Management Information Base (FDDI-MIB) There are no IPv4 dependencies in this protocol. 5.030 RFC 1314 A File Format for the Exchange of Images in the Internet (NETFAX) There are no IPv4 dependencies in this protocol. 5.031 RFC 1323 TCP Extensions for High Performance (TCP-EXT) There are no IPv4 dependencies in this protocol. 5.032 RFC 1328 X.400 1988 to 1984 downgrading There are no IPv4 dependencies in this protocol. 5.033 RFC 1332 The PPP Internet Protocol Control Protocol (IPCP) (PPP-IPCP) This document defines a protocol for devices to assign IPv4 addresses to PPP clients once PPP negotiation is completed. Section 3. IPCP Configuration Options defines the following: The most up-to-date values of the IPCP Option Type field are specified in the most recent "Assigned Numbers" RFC [6]. Current values are assigned as follows: 1 IP-Addresses 2 IP-Compression-Protocol 3 IP-Address 3.1. IP-Addresses Description The use of the Configuration Option IP-Addresses has been deprecated. It has been determined through implementation experience that it is difficult to ensure negotiation convergence in all cases using this option. RFC 1172 [7] provides information for implementations requiring backwards compatibility. The IP- Address Configuration Option replaces this option, and its use is preferred. This option SHOULD NOT be sent in a Configure-Request if a Configure-Request has been received which includes either an IP- Addresses or IP-Address option. This option MAY be sent if a Configure-Reject is received for the IP-Address option, or a Configure-Nak is received with an IP-Addresses option as an appended option. Support for this option MAY be removed after the IPCP protocol status advances to Internet Draft Standard. 3.3. IP-Address Description This Configuration Option provides a way to negotiate the IP address to be used on the local end of the link. It allows the sender of the Configure-Request to state which IP-address is desired, or to request that the peer provide the information. The peer can provide this information by NAKing the option, and returning a valid IP-address. If negotiation about the remote IP-address is required, and the peer did not provide the option in its Configure-Request, the option SHOULD be appended to a Configure-Nak. The value of the IP-address given must be acceptable as the remote IP-address, or indicate a request that the peer provide the information. By default, no IP address is assigned. A summary of the IP-Address Configuration Option format is shown below. The fields are transmitted from left to right. 0 1 2 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 | Length | IP-Address +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ IP-Address (cont) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Type 3 Length 6 IP-Address The four octet IP-Address is the desired local address of the sender of a Configure-Request. If all four octets are set to zero, it indicates a request that the peer provide the IP-Address information. Default No IP address is assigned. It is clearly designed to allow new Option Types to be added and should offer no problems for use with IPv6 once appropriate options have been defined. 5.034 RFC 1370 Applicability Statement for OSPF This document discusses a version of OSPF that is limited to IPv4. It is expected that a similar document be assigned for when a version of OSPF that supports IPv6 is established. 5.035 RFC 1372 Telnet Remote Flow Control Option (TOPT-RFC) There are no IPv4 dependencies in this protocol. 5.036 RFC 1377 The PPP OSI Network Layer Control Protocol (OSINLCP) (PPP-OSINLC) There are no IPv4 dependencies in this protocol. 5.037 RFC 1378 The PPP AppleTalk Control Protocol (ATCP) (PPP-ATCP) There are no IPv4 dependencies in this protocol. 5.038 RFC 1381 SNMP MIB Extension for X.25 LAPB (SNMP-LAPB) There are no IPv4 dependencies in this protocol. 5.039 RFC 1382 SNMP MIB Extension for the X.25 Packet Layer (SNMP-X.25) There are no IPv4 dependencies in this protocol. 5.040 RFC 1397 Default Route Advertisement In BGP2 and BGP3 Version of The Border Gateway Protocol BGP2 and BGP3 are both depreciated and therefore are not discussed in this document. 5.041 RFC 1403 BGP OSPF Interaction (BGP-OSPF) This document discusses the interaction between two routing protocols and how they exchange IPv4 information. A similar document should be produced when versions of OSPF and BGP that support IPv6. 5.042 RFC 1413 Identification Protocol (IDENT) There are no IPv4 dependencies in this protocol. 5.043 RFC 1414 Identification MIB (IDENT-MIB) There are no IPv4 dependencies in this protocol. 5.044 RFC 1415 FTP-FTAM Gateway Specification (FTP) This document defines a gateway for interaction between FTAM and FTP. As long as the problems associated with the FTP protocol identified above are addressed, this protocol specification does not add any other dependencies. 5.045 RFC 1418 SNMP over OSI (SNMP-OSI) There are no IPv4 dependencies in this protocol. 5.046 RFC 1419 SNMP over AppleTalk (SNMP-AT) There are no IPv4 dependencies in this protocol. 5.047 RFC 1420 SNMP over IPX (SNMP-IPX) There are no IPv4 dependencies in this protocol. 5.048 RFC 1421 Privacy Enhancement for Internet Electronic Mail: Part I (PEM-ENC) There are no IPv4 dependencies in this protocol. 5.049 RFC 1422 Privacy Enhancement for Internet Electronic Mail: Part II (PEM-CKM) There are no IPv4 dependencies in this protocol. 5.050 RFC 1423 Privacy Enhancement for Internet Electronic Mail: Part III (PEM-ALG) There are no IPv4 dependencies in this protocol. 5.051 RFC 1424 Privacy Enhancement for Internet Electronic Mail: Part IV (PEM-KEY) There are no IPv4 dependencies in this protocol. 5.052 RFC 1441 Introduction to version 2 of the Internet-standard Network Management Framework (SNMPv2) There are no IPv4 dependencies in this protocol. 5.053 RFC 1461 SNMP MIB extension for Multiprotocol Interconnect over X.25 (X25-MIB) The following OIDs are defined in Section 4 "Definitions": mioxPleLastFailedEnAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE(2..128)) ACCESS read-only STATUS mandatory DESCRIPTION "The last Encapsulated address that failed to find a corresponding X.121 address and caused mioxPleEnAddrToX121LkupFlrs to be incremented. The first octet of this object contains the encapsulation type, the remaining octets contain the address of that type that failed. Thus for an IP address, the length will be five octets, the first octet will contain 204 (hex CC), and the last four octets will contain the IP address. For a snap encapsulation, the first byte would be 128 (hex 80) and the rest of the octet string would have the snap header." ::= { mioxPleEntry 4 } mioxPeerEnAddr OBJECT-TYPE SYNTAX OCTET STRING (SIZE (0..128)) ACCESS read-write STATUS mandatory DESCRIPTION "The Encapsulation address of the remote host mapped by this table entry. A length of zero indicates the remote IP address is unknown or unspecified for use as a PLE default. The first octet of this object contains the encapsulation type, the remaining octets contain an address of that type. Thus for an IP address, the length will be five octets, the first octet will contain 204 (hex CC), and the last four octets will contain the IP address. For a snap encapsulation, the first byte would be 128 (hex 80) and the rest of the octet string would have the snap header." DEFVAL { ''h } ::= { mioxPeerEntry 7 } mioxPeerEncType OBJECT-TYPE SYNTAX INTEGER (0..256) ACCESS read-write STATUS mandatory DESCRIPTION "The value of the encapsulation type. For IP encapsulation this will have a value of 204 (hex CC). For SNAP encapsulated packets, this will have a value of 128 (hex 80). For CLNP, ISO 8473, this will have a value of 129 (hex 81). For ES-ES, ISO 9542, this will have a value of 130 (hex 82). A value of 197 (hex C5) identifies the Blacker X.25 encapsulation. A value of 0, identifies the Null encapsulation. This value can only be written when the mioxPeerStatus object with the same mioxPeerIndex has a value of underCreation. Setting this object to a value of 256 deletes the entry. When deleting an entry, all other entries in the mioxPeerEncTable with the same mioxPeerIndex and with an mioxPeerEncIndex higher then the deleted entry, will all have their mioxPeerEncIndex values decremented by one." ::= { mioxPeerEncEntry 2 } Updated values of the first byte of these OID's can be defined to support IPv6 addresses. 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. 5.055 RFC 1471 The Definitions of Managed Objects for the Link Control Protocol of the Point-to-Point Protocol (PPP/LCPMIB) There are no IPv4 dependencies in this protocol. 5.056 RFC 1472 The Definitions of Managed Objects for the Security Protocols of the Point-to-Point Protocol (PPP/SECMIB) There are no IPv4 dependencies in this protocol. 5.057 RFC 1473 The Definitions of Managed Objects for the IP Network Control Protocol of the Point-to-Point Protocol (PPP/IPMIB) Every OID in the MIB contain IPv4 addresses. A new MIB must be defined for OIDs for similar IPv6 addresses. 5.058 RFC 1474 The Definitions of Managed Objects for the Bridge Network Control Protocol of the Point-to-Point Protocol (PPP/Bridge) There are no IPv4 dependencies in this protocol. 5.059 RFC 1478 An Architecture for Inter-Domain Policy Routing (IDPR-ARCH) The architecture described in this documents has no IPv4 dependencies. 5.060 RFC 1479 Inter-Domain Policy Routing Protocol Specification: Version 1 (IDPR) There are no IPv4 dependencies in this protocol. 5.061 RFC 1494 Equivalences between 1988 X.400 and RFC-822 Message Bodies (Equiv) There are no IPv4 dependencies in this protocol. 5.062 RFC 1496 Rules for downgrading messages from X.400/88 to X.400/84 when MIME content-types are present in the messages (HARPOON) There are no IPv4 dependencies in this protocol. 5.063 RFC 1502 X.400 Use of Extended Character Sets There are no IPv4 dependencies in this protocol. 5.064 RFC 1510 The Kerberos Network Authentication Service (V5) (KERBEROS) Although this protocol specifies optional use of host addresses, there are no specific requirements that the addresses be IPv4. The protocol has no IPv4 dependencies, but implementations might have issues. 5.065 RFC 1512 FDDI Management Information Base (FDDI-MIB) There are no IPv4 dependencies in this protocol. 5.066 RFC 1513 Token Ring Extensions to the Remote Network Monitoring MIB There are no IPv4 dependencies in this protocol. 5.067 RFC 1515 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) There are no IPv4 dependencies in this protocol. 5.068 RFC 1517 Applicability Statement for the Implementation of Classless Inter-Domain Routing (CIDR) (CIDR) This document deals exclusively with IPv4 addressing issue. 5.069 RFC 1518 An Architecture for IP Address Allocation with CIDR (CIDR-ARCH) This document deals exclusively with IPv4 addressing issue. 5.070 RFC 1519 Classless Inter-Domain Routing (CIDR): an Address Assignment and Aggregation Strategy (CIDR-STRA) This document deals exclusively with IPv4 addressing issue. 5.071 RFC 1525 Definitions of Managed Objects for Source Routing Bridges (SRB-MIB) There are no IPv4 dependencies in this protocol. 5.072 RFC 1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP) (IPXCP) There are no IPv4 dependencies in this protocol. 5.073 RFC 1553 Compressing IPX Headers Over WAN Media (CIPX) (CIPX) There are no IPv4 dependencies in this protocol. 5.074 RFC 1570 PPP LCP Extensions (PPP-LCP) There are no IPv4 dependencies in this protocol. 5.075 RFC 1572 Telnet Environment Option (TOPT-ENVIR) There are no IPv4 dependencies in this protocol. 5.076 RFC 1582 Extensions to RIP to Support Demand Circuits (RIP-DC) This protocol is an extension to a protocol for exchanging IPv4 routing information. In Section 3. IP Routing Information Protocol Version 1 shows: Followed by up to 25 routing entries (each 20 octets) 0 1 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | address family identifier (2) | must be zero (2) | +-------------------------------+-------------------------------+ | IP address (4) | +---------------------------------------------------------------+ | must be zero (4) | +---------------------------------------------------------------+ | must be zero (4) | +---------------------------------------------------------------+ | metric (4) | +---------------------------------------------------------------+ . . The format of an IP RIP datagram in octets, with each tick mark representing one bit. All fields are in network order. The four octets: sequence number (2), fragment number (1) and number of fragments (1) are not present in the original RIP specification. They are only present if command takes the values 7 or 8. Figure 2. IP Routing Information Protocol packet format The section referencing RIPv2 refers back to the above text. 5.077 RFC 1584 Multicast Extensions to OSPF (OSPF-Multi) This document defines the use of IPv4 multicast to an IPv4 routing protocol. A similar mechanism must be defined for IPv6. 5.078 RFC 1587 The OSPF NSSA Option (OSPF-NSSA) This document defines an extension to an IPv4 routing protocol and it is assumed that any updated version of OSPF to support IPv6 will contain an appropriate update for this option. 5.079 RFC 1598 PPP in X.25 PPP-X25 There are no IPv4 dependencies in this protocol. 5.080 RFC 1611 DNS Server MIB Extensions (DNS-S-MIB) The following OID is defined: DnsServZoneEntry ::= SEQUENCE { dnsServZoneName DnsNameAsIndex, dnsServZoneClass DnsClass, dnsServZoneLastReloadSuccess DnsTime, dnsServZoneLastReloadAttempt DnsTime, dnsServZoneLastSourceAttempt IpAddress, dnsServZoneStatus RowStatus, dnsServZoneSerial Counter32, dnsServZoneCurrent TruthValue, dnsServZoneLastSourceSuccess IpAddress } There are two instances of IPv4 assumptions. New OIDs can be defined for IPv6 addressing. Similarly: -- DNS Zone Source Table dnsServZoneSrcTable OBJECT-TYPE SYNTAX SEQUENCE OF DnsServZoneSrcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "This table is a list of IP addresses from which the server will attempt to load zone information using DNS zone transfer operations. A reload may occur due to SNMP operations that create a row in dnsServZoneTable or a SET to object dnsServZoneReload. This table is only used when the zone is loaded via zone transfer." ::= { dnsServZone 2 } dnsServZoneSrcEntry OBJECT-TYPE SYNTAX DnsServZoneSrcEntry MAX-ACCESS not-accessible STATUS current DESCRIPTION "An entry in the name server zone source table." INDEX { dnsServZoneSrcName, dnsServZoneSrcClass, dnsServZoneSrcAddr } ::= { dnsServZoneSrcTable 1 } DnsServZoneSrcEntry ::= SEQUENCE { dnsServZoneSrcName DnsNameAsIndex, dnsServZoneSrcClass DnsClass, dnsServZoneSrcAddr IpAddress, dnsServZoneSrcStatus RowStatus } dnsServZoneSrcName OBJECT-TYPE SYNTAX DnsNameAsIndex MAX-ACCESS not-accessible STATUS current DESCRIPTION "DNS name of the zone to which this entry applies." ::= { dnsServZoneSrcEntry 1 } dnsServZoneSrcClass OBJECT-TYPE SYNTAX DnsClass MAX-ACCESS not-accessible STATUS current DESCRIPTION "DNS class of zone to which this entry applies." ::= { dnsServZoneSrcEntry 2 } dnsServZoneSrcAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "IP address of name server host from which this zone might be obtainable." ::= { dnsServZoneSrcEntry 3 } 5.081 RFC 1612 DNS Resolver MIB Extensions (DNS-R-MIB) As in the previous section the following IPv4 dependent OIDs are defined: DnsResConfigSbeltEntry ::= SEQUENCE { dnsResConfigSbeltAddr IpAddress, dnsResConfigSbeltName DnsName, dnsResConfigSbeltRecursion INTEGER, dnsResConfigSbeltPref INTEGER, dnsResConfigSbeltSubTree DnsNameAsIndex, dnsResConfigSbeltClass DnsClass, dnsResConfigSbeltStatus RowStatus } dnsResConfigSbeltAddr OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "The IP address of the Sbelt name server identified by this row of the table." ::= { dnsResConfigSbeltEntry 1 } and DnsResLameDelegationEntry ::= SEQUENCE { dnsResLameDelegationSource IpAddress, dnsResLameDelegationName DnsNameAsIndex, dnsResLameDelegationClass DnsClass, dnsResLameDelegationCounts Counter32, dnsResLameDelegationStatus RowStatus } dnsResLameDelegationSource OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS not-accessible STATUS current DESCRIPTION "Source of lame delegation." ::= { dnsResLameDelegationEntry 1 } and DnsResCacheRREntry ::= SEQUENCE { dnsResCacheRRName DnsNameAsIndex, dnsResCacheRRClass DnsClass, dnsResCacheRRType DnsType, dnsResCacheRRTTL DnsTime, dnsResCacheRRElapsedTTL DnsTime, dnsResCacheRRSource IpAddress, dnsResCacheRRData OCTET STRING, dnsResCacheRRStatus RowStatus, dnsResCacheRRIndex Integer32, dnsResCacheRRPrettyName DnsName } dnsResCacheRRSource OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Host from which RR was received, 0.0.0.0 if unknown." ::= { dnsResCacheRREntry 6 } and DnsResNCacheErrEntry ::= SEQUENCE { dnsResNCacheErrQName DnsNameAsIndex, dnsResNCacheErrQClass DnsQClass, dnsResNCacheErrQType DnsQType, dnsResNCacheErrTTL DnsTime, dnsResNCacheErrElapsedTTL DnsTime, dnsResNCacheErrSource IpAddress, dnsResNCacheErrCode INTEGER, dnsResNCacheErrStatus RowStatus, dnsResNCacheErrIndex Integer32, dnsResNCacheErrPrettyName DnsName } dnsResNCacheErrSource OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "Host which sent the authoritative error, 0.0.0.0 if unknown." ::= { dnsResNCacheErrEntry 6 } 5.082 RFC 1618 PPP over ISDN (PPP-ISDN) There are no IPv4 dependencies in this protocol. 5.083 RFC 1628 UPS Management Information Base (UPS-MIB) There are no IPv4 dependencies in this protocol. 5.084 RFC 1648 Postmaster Convention for X.400 Operations There are no IPv4 dependencies in this protocol. 5.085 RFC 1663 PPP Reliable Transmission (PPP-TRANS) There are no IPv4 dependencies in this protocol. 5.086 RFC 1666 Definitions of Managed Objects for SNA NAUs using SMIv2 SNANAU-MIB There are no IPv4 dependencies in this protocol. 5.087 RFC 1692 Transport Multiplexing Protocol (TMux) (TMUX) Section 6. Implementation Notes is states: Because the TMux mini-header does not contain a TOS field, only segments with the same IP TOS field should be contained in a single TMux message. As most systems do not use the TOS feature, this is not a major restriction. Where the TOS field is used, it may be desirable to hold several messages under construction for a host, one for each TOS value. Segments containing IP options should not be multiplexed. This is clearly IPv4 specific, but a simple restatement in IPv6 terms will allow complete functionality. 5.088 RFC 1696 Modem Management Information Base (MIB) using SMIv2 MODEM-MIB There are no IPv4 dependencies in this protocol. 5.089 RFC 1697 Relational Database Management System (RDBMS) Management Information Base (MIB) using SMIv2 RDBMS-MIB There are no IPv4 dependencies in this protocol. 5.090 RFC 1731 IMAP4 Authentication Mechanisms (IMAP4-AUTH) There are no IPv4 dependencies in this protocol. 5.091 RFC 1734 POP3 AUTHentication command (POP3-AUTH) There are no IPv4 dependencies in this protocol. 5.092 RFC 1738 Uniform Resource Locators (URL) (URL) Section 3.1. Common Internet Scheme Syntax states: host The fully qualified domain name of a network host, or its IP address as a set of four decimal digit groups separated by ".". Fully qualified domain names take the form as described in Section 3.5 of RFC 1034 [13] and Section 2.1 of RFC 1123 [5]: a sequence of domain labels separated by ".", each domain label starting and ending with an alphanumerical character and possibly also containing "-" characters. The rightmost domain label will never start with a digit, though, which syntactically distinguishes all domain names from the IP addresses. Clearly this is only valid when using IPv4 addresses. Later in Section 5. BNF for specific URL schemes the following text is presented: ; URL schemeparts for ip based protocols: ip-schemepart = "//" login [ "/" urlpath ] login = [ user [ ":" password ] "@" ] hostport hostport = host [ ":" port ] host = hostname | hostnumber 5.093 RFC 1740 MIME Encapsulation of Macintosh Files - MacMIME (MacMIME) There are no IPv4 dependencies in this protocol. 5.094 RFC 1742 AppleTalk Management Information Base II (AT-MIB) The following OIDs are defined: KipEntry ::= SEQUENCE { kipNetStart ATNetworkNumber, kipNetEnd ATNetworkNumber, kipNextHop IpAddress, kipHopCount INTEGER, kipBCastAddr IpAddress, kipCore INTEGER, kipType INTEGER, kipState INTEGER, kipShare INTEGER, kipFrom IpAddress } kipNextHop OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The IP address of the next hop in the route to this entry's destination network." ::= { kipEntry 3 } kipBCastAddr OBJECT-TYPE SYNTAX IpAddress ACCESS read-write STATUS mandatory DESCRIPTION "The form of the IP address used to broadcast on this network." ::= { kipEntry 5 } kipFrom OBJECT-TYPE SYNTAX IpAddress ACCESS read-only STATUS mandatory DESCRIPTION "The IP address from which the routing entry was learned via the AA protocol. If this entry was not created via the AA protocol, it should contain IP address 0.0.0.0." ::= { kipEntry 10 } 5.095 RFC 1745 BGP4/IDRP for IP---OSPF Interaction (BGP4/IDRP) This document discusses the interaction between two routing protocols and how they exchange IPv4 information. A similar document should be produced when versions of OSPF and BGP that support IPv6. 5.096 RFC 1747 Definitions of Managed Objects for SNA Data Link Control (SDLC) using SMIv2 SDLCSMIv2 There are no IPv4 dependencies in this protocol. 5.097 RFC 1749 IEEE 802.5 Station Source Routing MIB using SMIv2 802.5-SSR There are no IPv4 dependencies in this protocol. 5.098 RFC 1752 The Recommendation for the IP Next Generation Protocol (IPNG) This document defines a roadmap for IPv6 development and is not relevant to this discussion. 5.099 RFC 1755 ATM Signaling Support for IP over ATM (ATM) There are no IPv4 dependencies in this protocol. 5.100 RFC 1759 Printer MIB (Print-MIB) There are no IPv4 dependencies in this protocol. 5.101 RFC 1763 The PPP Banyan Vines Control Protocol (BVCP) (BVCP) There are no IPv4 dependencies in this protocol. 5.102 RFC 1764 The PPP XNS IDP Control Protocol (XNSCP) (XNSCP) There are no IPv4 dependencies in this protocol. 5.103 RFC 1767 MIME Encapsulation of EDI Objects (MIME-EDI) There are no IPv4 dependencies in this protocol. 5.104 RFC 1781 Using the OSI Directory to Achieve User Friendly Naming (OSI-Dir) There are no IPv4 dependencies in this protocol. 5.105 RFC 1793 Extending OSPF to Support Demand Circuits (OSPF-DC) There are no IPv4 dependencies in this protocol other than the fact that it is an new functionality for a routing protocol that only supports IPv4 networks. It is assumed that a future update to OSPF to support IPv6 will also support this functionality. 5.106 RFC 1798 Connection-less Lightweight X.500 Directory Access Protocol (CLDAP) Section 5.2. Client Implementations makes the following observation: For simple lookup applications, use of a retry algorithm with multiple servers similar to that commonly used in DNS stub resolver implementations is recommended. The location of a CLDAP server or servers may be better specified using IP addresses (simple or broadcast) rather than names that must first be looked up in another directory such as DNS. It is not specific to IPv4 and compliance with IPv6 will be implementation dependent. 5.107 RFC 1808 Relative Uniform Resource Locators (URL) There are no IPv4 dependencies in this protocol. 5.108 RFC 1812 Requirements for IP Version 4 Routers This document is only intended to describe requirements for IPv4 implementations in routers and is not discussed in this document. 5.109 RFC 1828 IP Authentication using Keyed MD5 There are no IPv4 dependencies in this protocol. The operations described operate on the entire IP packet without specifying that the IP packet be IPv4 or IPv6. 5.110 RFC 1829 The ESP DES-CBC Transform There are no IPv4 dependencies in this protocol. The operations described operate on the entire IP packet without specifying that the IP packet be IPv4 or IPv6. 5.111 RFC 1831 RPC: Remote Procedure Call Protocol Specification Version 2 RPC There are no IPv4 dependencies in this protocol. 5.112 RFC 1833 Binding Protocols for ONC RPC Version 2 In Section 2.1 RPCBIND Protocol Specification (in RPC Language) there is the following code fragment: * Protocol family (r_nc_protofmly): * This identifies the family to which the protocol belongs. The * following values are defined: * NC_NOPROTOFMLY "-" * NC_LOOPBACK "loopback" * NC_INET "inet" * NC_IMPLINK "implink" * NC_PUP "pup" * NC_CHAOS "chaos" * NC_NS "ns" * NC_NBS "nbs" * NC_ECMA "ecma" * NC_DATAKIT "datakit" * NC_CCITT "ccitt" * NC_SNA "sna" * NC_DECNET "decnet" * NC_DLI "dli" * NC_LAT "lat" * NC_HYLINK "hylink" * NC_APPLETALK "appletalk" * NC_NIT "nit" * NC_IEEE802 "ieee802" * NC_OSI "osi" * NC_X25 "x25" * NC_OSINET "osinet" * NC_GOSIP "gosip" It is clear that the value for NC_INET is intended for the IP protocol and is seems clear that it is IPv4 dependent. 5.113 RFC 1835 Architecture of the WHOIS++ service (WHOIS++) There are no IPv4 dependencies in this protocol. 5.114 RFC 1847 Security Multiparts for MIME: Multipart/Signed and Multipart/Encrypted (MIME-Encyp) There are no IPv4 dependencies in this protocol. 5.115 RFC 1848 MIME Object Security Services (MIME-Sec) There are no IPv4 dependencies in this protocol. 5.116 RFC 1886 DNS Extensions to support IP version 6 (DNS-IPV6) This RFC defines the AAAA record for IPv6 as well as PTR records using the ip6.int domain. There is currently a large debate going on in the IPv6 and DNS community over the validity of AAAA versus A6 records. 5.117 RFC 1889 RTP: A Transport Protocol for Real-Time Applications (RTP) In general this protocol makes many references to running on UDP over IP unicast, as well as multicast addresses. There seems to be no reason that it will run effectively over IPv6 unicast and multicast. The only possible point is in Section A.7 Computing the RTCP Transmission Interval which contains the following code fragment: /* * Very first call at application start-up uses half the min * delay for quicker notification while still allowing some time * before reporting for randomization and to learn about other * sources so the report interval will converge to the correct * interval more quickly. The average RTCP size is initialized * to 128 octets which is conservative (it assumes everyone else * is generating SRs instead of RRs: 20 IP + 8 UDP + 52 SR + 48 * SDES CNAME). */ if (initial) { rtcp_min_time /= 2; *avg_rtcp_size = 128; } which assumes an IPv4 header length of 20 bytes. It seems a simple update to this code to check for IP version and pick a value appropriate for the IP version. 5.118 RFC 1890 RTP Profile for Audio and Video Conferences with Minimal Control (RTP-AV) There are no IPv4 dependencies in this protocol. 5.119 RFC 1891 SMTP Service Extension for Delivery Status Notifications (SMTP-DSN) There are no IPv4 dependencies in this protocol. 5.120 RFC 1892 The Multipart/Report Content Type for the Reporting of Mail System Administrative Messages (MIME-RPT) There are no IPv4 dependencies in this protocol. 5.121 RFC 1893 Enhanced Mail System Status Codes (EMS-CODE) There are no IPv4 dependencies in this protocol. 5.122 RFC 1894 An Extensible Message Format for Delivery Status Notifications (DSN) There are no IPv4 dependencies in this protocol. 5.123 RFC 1913 Architecture of the Whois++ Index Service,WHOIS++A Section 6.5. Query referral makes the following statement: When referrals are included in the body of a response to a query, each referral is listed in a separate SERVER-TO-ASK block as shown below. # SERVER-TO-ASK Version-number: // version number of index software, used to insure // compatibility Body-of-Query: // the original query goes here Server-Handle: // WHOIS++ handle of the referred server Host-Name: // DNS name or IP address of the referred server Port-Number: // Port number to which to connect, if different from the // WHOIS++ port number This syntax does not necessarily have any IPv4 dependencies but implementations should be modified to check the incoming packet to see which IP version the original request used in order to determine whether returning an IPv6 address is reasonable. 5.124 RFC 1914 How to Interact with a Whois++ Mesh (WHOIS++) This document states beginning in Section 4: A client can cache all information it gets from a server for some time. For example records, IP-addresses of Whois++ servers, the Directory of Services server etc. A client can itself choose for how long it should cache the information. The IP-address of the Directory of Services server might not change for a day or two, and neither might any other information. 4.1. Caching a Whois++ servers hostname An example of cached information that might change is the cached hostname, IP-address and portnumber which a client gets back in a servers-to-ask response. That information is cached in the server since the last poll, which might occurred several weeks ago. Therefore, when such a connection fails, the client should fall back to use the serverhandle instead, which means that it contacts the Directory of Services server and queries for a server with that serverhandle. By doing this, the client should always get the last known hostname. An algorithm for this might be: response := servers-to-ask response from server A IP-address := find ip-address for response.hostname in DNS connect to ip-address at port response.portnumber if connection fails { connect to Directory of Services server query for host with serverhandle response.serverhandle response := response from Directory of Services server IP-address := find ip-address for response.hostname in DNS connect to ip-address at port response.portnumber if connection fails { exit with error message } } Query this new server but these statements are IP version neutral. 5.125 RFC 1928 SOCKS Protocol Version 5 (SOCKSV5) This protocol is IPv6 aware and will function normally on either IPv4 and IPv6. 5.126 RFC 1929 Username/Password Authentication for SOCKS V5 (AUTH-SOCKS) There are no IPv4 dependencies in this protocol. 5.127 RFC 1961 GSS-API Authentication Method for SOCKS Version 5 (GSSAPI-SOC) There are no IPv4 dependencies in this protocol. 5.128 RFC 1962 The PPP Compression Control Protocol (CCP) (PPP-CCP) There are no IPv4 dependencies in this protocol. 5.129 RFC 1964 The Kerberos Version 5 GSS-API Mechanism (GSSAPI-KER) There are no IPv4 dependencies in this protocol. 5.130 RFC 1968 The PPP Encryption Control Protocol (ECP) (PPP-ECP) There are no IPv4 dependencies in this protocol. 5.131 RFC 1973 PPP in Frame Relay (PPP-FRAME) There are no IPv4 dependencies in this protocol. 5.132 RFC 1981 Path MTU Discovery for IP version 6 MTU-IPV6 This protocol describes an IPv6 related protocol and is not discussed in this document. 5.133 RFC 1982 Serial Number Arithmetic (SNA) There are no IPv4 dependencies in this protocol. 5.134 RFC 1985 SMTP Service Extension for Remote Message Queue Starting (SMTP-ETRN) There are no IPv4 dependencies in this protocol. 5.135 RFC 1995 Incremental Zone Transfer in DNS (DNS-IZT) Although the examples used in this document use IPv4 adddresses, (i.e. A records) there is nothing in the protocol to preclude full and proper functionality using IPv6. 5.136 RFC 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY) (DNS-NOTIFY) There are no IPv4 dependencies in this protocol. 5.137 RFC 1997 BGP Communities Attribute (BGP-COMM) Although the protocol enhancements have no IPv4 dependencies, it is an update to an IPv4 only routing protocol. It is expected that a newer version of BGP that is IPv6 aware will also implement this enhancement. 5.138 RFC 2002 IP Mobility Support (MOBILEIPSU) This document is designed for use in IPv4 networks. There are numerous referrals to other IP "support" mechanisms (i.e. ICMP Router Discover Messages) that specifically refer to the IPv4 of ICMP. An IP Mobility protocol for IPv6 is required. 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. 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. 5.141 RFC 2005 Applicability Statement for IP Mobility Support This RFC documents the interoperation of IPv4 mobility as documented in the preceding 3 section. 5.142 RFC 2006 The Definitions of Managed Objects for IP Mobility Support using SMIv2 (MOBILEIPMI) This document defines a MIB for the Mobile IPv4 documents described immediately above. Without enumeration, let it be stated that a new MIB for IPv6 Mobility is required. 5.143 RFC 2011 SNMPv2 Management Information Base for the Internet Protocol using SMIv2 (MIB-IP) Approximately 1/3 of the OIDs defined in this document are clearly IPv4 dependent. A new MIB for IPv6 OIDs is required. 5.144 RFC 2012 SNMPv2 Management Information Base for the Transmission Control Protocol using SMIv2 (MIB-TCP) A number of OIDs in this MIB assumes IPv4 addresses, as is noted in the note reproduced below: IESG Note: The IP, UDP, and TCP MIB modules currently support only IPv4. These three modules use the IpAddress type defined as an OCTET STRING of length 4 to represent the IPv4 32-bit internet addresses. (See RFC 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 internet addresses. 5.145 RFC 2013 SNMPv2 Management Information Base for the User Datagram Protocol using SMIv2 (MIB-UDP) A number of OIDs in this MIB assumes IPv4 addresses, as is noted in the note reproduced below: IESG Note: The IP, UDP, and TCP MIB modules currently support only IPv4. These three modules use the IpAddress type defined as an OCTET STRING of length 4 to represent the IPv4 32-bit internet addresses. (See RFC 1902, SMI for SNMPv2.) They do not support the new 128-bit IPv6 internet addresses. 5.146 RFC 2015 MIME Security with Pretty Good Privacy (PGP) (MIME-PGP) There are no IPv4 dependencies in this protocol. 5.147 RFC 2017 Definition of the URL MIME External-Body Access-Type (URL-ACC) There are no IPv4 dependencies in this protocol. 5.148 RFC 2018 TCP Selective Acknowledgement Options (TCP-ACK) There are no IPv4 dependencies in this protocol. 5.149 RFC 2020 IEEE 802.12 Interface MIB (802.12-MIB) There are no IPv4 dependencies in this protocol. 5.150 RFC 2021 Remote Network Monitoring Management Information Base Version 2 using SMIv2 (RMON-MIB) The following OIDs are defined: addressMapNetworkAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address for this relation. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { addressMapEntry 2 } nlHostAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network address for this nlHostEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { nlHostEntry 2 } nlMatrixSDSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network source address for this nlMatrixSDEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { nlMatrixSDEntry 2 } nlMatrixSDDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network destination address for this nlMatrixSDEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { nlMatrixSDEntry 3 } nlMatrixDSSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network source address for this nlMatrixDSEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { nlMatrixDSEntry 2 } nlMatrixDSDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS not-accessible STATUS current DESCRIPTION "The network destination address for this nlMatrixDSEntry. This is represented as an octet string with specific semantics and length as identified by the protocolDirLocalIndex component of the index. For example, if the protocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { nlMatrixDSEntry 3 } nlMatrixTopNSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the source host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated nlMatrixTopNProtocolDirLocalIndex. For example, if the protocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { nlMatrixTopNEntry 3 } nlMatrixTopNDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the destination host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated nlMatrixTopNProtocolDirLocalIndex. For example, if the nlMatrixTopNProtocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { nlMatrixTopNEntry 4 } alMatrixTopNSourceAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the source host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated alMatrixTopNProtocolDirLocalIndex. For example, if the alMatrixTopNProtocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { alMatrixTopNEntry 3 } alMatrixTopNDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-only STATUS current DESCRIPTION "The network layer address of the destination host in this conversation. This is represented as an octet string with specific semantics and length as identified by the associated alMatrixTopNProtocolDirLocalIndex. For example, if the alMatrixTopNProtocolDirLocalIndex indicates an encapsulation of ip, this object is encoded as a length octet of 4, followed by the 4 octets of the ip address, in network byte order." ::= { alMatrixTopNEntry 4 } trapDestProtocol OBJECT-TYPE SYNTAX INTEGER { ip(1), ipx(2) } MAX-ACCESS read-create STATUS current DESCRIPTION "The protocol with which to send this trap." ::= { trapDestEntry 3 } trapDestAddress OBJECT-TYPE SYNTAX OCTET STRING MAX-ACCESS read-create STATUS current DESCRIPTION "The address to send traps on behalf of this entry. If the associated trapDestProtocol object is equal to ip(1), the encoding of this object is the same as the snmpUDPAddress textual convention in [RFC1906]: -- for a SnmpUDPAddress of length 6: -- -- octets contents encoding -- 1-4 IP-address network-byte order -- 5-6 UDP-port network-byte order If the associated trapDestProtocol object is equal to ipx(2), the encoding of this object is the same as the snmpIPXAddress textual convention in [RFC1906]: -- for a SnmpIPXAddress of length 12: -- -- octets contents encoding -- 1-4 network-number network-byte order -- 5-10 physical-address network-byte order -- 11-12 socket-number network-byte order This object may not be modified if the associated trapDestStatus object is equal to active(1)." ::= { trapDestEntry 4 } All of the OIDs above (except trapDestProtocol) imply IPv4 addresses but since they use a SYNTAX of OCTET STRING, they should work fine for IPv6 addresses. A new legitimate value of trapDestProtocol (i.e. SYNTAX addition of ipv6(3) should make this protocol IPv6 functional. 5.151 RFC 2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks (MULTI-UNI) This protocol specifically maps IPv4 multicast and a new version is required to support IPv6 multicast. 5.152 RFC 2024 Definitions of Managed Objects for Data Link Switching using SMIv2 (DLSW-MIB) The following OIDs are defined: TAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a transport service address. For dlswTCPDomain, a TAddress is 4 octets long, containing the IP-address in network-byte order." SYNTAX OCTET STRING (SIZE (0..255)) -- DLSw over TCP dlswTCPDomain OBJECT IDENTIFIER ::= { dlswDomains 1 } -- for an IP address of length 4: -- -- octets contents encoding -- 1-4 IP-address network-byte order -- DlswTCPAddress ::= TEXTUAL-CONVENTION DISPLAY-HINT "1d.1d.1d.1d" STATUS current DESCRIPTION "Represents the IP address of a DLSw which uses TCP as a transport protocol." SYNTAX OCTET STRING (SIZE (4)) Additionally there are many OIDs that use a SYNTAX of TAddress within the document. Interestingly the SYNTAX for TAddress is an OCTET string of up to 256 characters. It could easily accommodate a similar hybrid format for IPv6 addresses. A new OID to enhance functionality for DlswTCPAddress can be added to support IPv6 addresses. 5.153 RFC 2025 The Simple Public-Key GSS-API Mechanism (SPKM) (SPKM) There are no IPv4 dependencies in this protocol. 5.154 RFC 2029 RTP Payload Format of Sun's CellB Video Encoding (RTP-CELLB) There are no IPv4 dependencies in this protocol. 5.155 RFC 2032 RTP Payload Format for H.261 Video Streams (RTP-H.261) There are no IPv4 dependencies in this protocol. 5.156 RFC 2034 SMTP Service Extension for Returning Enhanced Error Codes (SMTP-ENH) There are no IPv4 dependencies in this protocol. 5.157 RFC 2043 The PPP SNA Control Protocol (SNACP) (PPP-SNACP) There are no IPv4 dependencies in this protocol. 5.158 RFC 2051 Definitions of Managed Objects for APPC using SMIv2 (SNANAU-APP) There are no IPv4 dependencies in this protocol. 5.159 RFC 2056 Uniform Resource Locators for Z39.50 (URLZ39.50) There are no IPv4 dependencies in this protocol. 5.160 RFC 2060 Internet Message Access Protocol - Version 4rev1 (IMAPV4) There are no IPv4 dependencies in this protocol. 5.161 RFC 2077 The Model Primary Content Type for Multipurpose Internet Mail Extensions (MIME-MODEL) There are no IPv4 dependencies in this protocol. 5.162 RFC 2079 Definition of an X.500 Attribute Type and an Object Class to Hold Uniform Resource Identifiers (URIs) (URI-ATT) There are no IPv4 dependencies in this protocol. 5.163 RFC 2080 RIPng for IPv6 (RIPNG-IPV6) This RFC documents a protocol for exchanging IPv6 routing information and is not discussed in this document. 5.164 RFC 2082 RIP-2 MD5 Authentication (RIP2-MD5) This RFC documents a security mechanism for an IPv4 only routing protocol. It is expected that a similar (or better) mechanism will be developed for RIPng. 5.165 RFC 2085 HMAC-MD5 IP Authentication with Replay Prevention (HMAC-MD5) This document defines an IP version independent protocol and has no IPv4 dependencies. 5.166 RFC 2086 IMAP4 ACL extension (IMAP4-ACL) There are no IPv4 dependencies in this protocol. 5.167 RFC 2087 IMAP4 QUOTA extension (IMAP4-QUO) There are no IPv4 dependencies in this protocol. 5.168 RFC 2088 IMAP4 non-synchronizing literals (IMAP4-LIT) There are no IPv4 dependencies in this protocol. 5.169 RFC 2091 Triggered Extensions to RIP to Support Demand Circuits (RIP-TRIG) This RFC defines an enhancement for an IPv4 routing protocol and while it has no IPv4 dependencies it is inherintely limited to IPv4. It is expected that a similar mechanism will be implemented in RIPng. 5.170 RFC 2096 IP Forwarding Table MIB (TABLE-MIB) This MIB defines many OIDs that are IPv4 dependent. It is expected that another MIB for similar IPv6 addresses will be developed. 5.171 RFC 2097 The PPP NetBIOS Frames Control Protocol (NBFCP) (PPP-NBFCP) There are no IPv4 dependencies in this protocol. 5.172 RFC 2108 Definitions of Managed Objects for IEEE 802.3 Repeater Devices using SMIv2 802 (3-MIB) There are no IPv4 dependencies in this protocol. 5.173 RFC 2113 IP Router Alert Option (ROUT-ALERT) This document provides a new mechanism for IPv4. It is expected that a similar functionality will be included in IPv6. 5.174 RFC 2122 VEMMI URL Specification (VEMMI-URL) Section 3) Description of the VEMMI scheme states: The VEMMI URL scheme is used to designate multimedia interactive services conforming to the VEMMI standard (ITU/T T.107 and ETS 300 709). A VEMMI URL takes the form: vemmi://<host>:<port>/<vemmiservice>; <attribute>=<value> as specified in Section 3.1. of RFC 1738. If :<port> is omitted, the port defaults to 575 (client software may choose to ignore the optional port number in order to increase security). The <vemmiservice> part is optional and may be omitted. It is possible that the <host> portion to contain an IPv4 only address as defined in RFC 1738 (see above). Once the problem is clarified for RFC 1738, this issue will automatically be resolved. 5.175 RFC 2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP) (BAP-BACP) There are no IPv4 dependencies in this protocol. 5.176 RFC 2126 ISO Transport Service on top of TCP (ITOT) (ITOT) This protocol is IPv6 aware and has no issues. 5.177 RFC 2127 ISDN Management Information Base using SMIv2 (ISDN-MIB) There are no IPv4 dependencies in this protocol. 5.178 RFC 2128 Dial Control Management Information Base using SMIv2 (DC-MIB) There are no IPv4 dependencies in this protocol. 5.179 RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE) (DNS-UPDATE) There are no IPv4 dependencies in this protocol. 5.180 RFC 2141 URN Syntax (URN-SYNTAX) There are no IPv4 dependencies in this protocol. 5.181 RFC 2142 "Mailbox Names for Common Services, Roles and Functions" (MAIL-SERV) There are no IPv4 dependencies in this protocol. 5.182 RFC 2156 MIXER (Mime Internet X.400 Enhanced Relay): Mapping between X.400 and RFC 822/MIME (MIXER) There are no IPv4 dependencies in this protocol. 5.183 RFC 2157 Mapping between X.400 and RFC-822/MIME Message Bodies There are no IPv4 dependencies in this protocol. 5.184 RFC 2158 X.400 Image Body Parts There are no IPv4 dependencies in this protocol. 5.185 RFC 2159 A MIME Body Part for FAX There are no IPv4 dependencies in this protocol. 5.186 RFC 2160 Carrying PostScript in X.400 and MIME There are no IPv4 dependencies in this protocol. 5.187 RFC 2163 Using the Internet DNS to Distribute MIXER Conformant Global Address Mapping (MCGAM) (DNS-MCGAM) There are no IPv4 dependencies in this protocol. 5.188 RFC 2164 Use of an X.500/LDAP directory to support MIXER address mapping There are no IPv4 dependencies in this protocol. 5.189 RFC 2165 Service Location Protocol (SLP) Sections 7. Service Type Request Message Format, and 9. Service Registration Message Format each have a 80 bit field from addr-spec (see below) which would not support IPv6 addresses. In Section 20.1. Previous Responders' Address Specification The previous responders' Address Specification is specified as <Previous Responders' Address Specification> ::= <addr-spec> | <addr-spec>, <Previous Responders' Address Specification> i.e., a list separated by commas with no intervening white space. The Address Specification is the address of the Directory Agent or Service Agent which supplied the previous response. The format for Address Specifications in Service Location is defined in section 20.4. The comma delimiter is required between each <addr-spec>. The use of dotted decimal IP address notation should only be used in environments which have no Domain Name Service. Example: RESOLVO.NEATO.ORG,128.127.203.63 and further in Section 20.4. Address Specification in Service Location The address specification used in Service Location is: <addr-spec> ::= [<user>:<password>@]<host>[:<port>] <host> ::= Fully qualified domain name | dotted decimal IP address notation When no Domain Name Server is available, SAs and DAs must use dotted decimal conventions for IP addresses. Otherwise, it is preferable to use a fully qualified domain name wherever possible as renumbering of host addresses will make IP addresses invalid over time. All of Section 21 defines the requirements for each of the elements of this protocol. The discussion makes many statements that seem to imply IPv4, but the statements are general enough that they can still operate on IPv6. Section 22. Configurable Parameters and Default Values states: There are several configuration parameters for Service Location. Default values are chosen to allow protocol operation without the need for selection of these configuration parameters, but other values may be selected by the site administrator. The configurable parameters will allow an implementation of Service Location to be more useful in a variety of scenarios. Multicast vs. Broadcast All Service Location entities must use multicast by default. The ability to use broadcast messages must be configurable for UAs and SAs. Broadcast messages are to be used in environments where not all Service Location entities have hardware or software which supports multicast. Multicast Radius Multicast requests should be sent to all subnets in a site. The default multicast radius for a site is 32. This value must be configurable. The value for the site's multicast TTL may be obtained from DHCP using an option which is currently unassigned. Once again nothing here precludes IPv6. Section 23. Non-configurable Parameters states: IP Port number for unicast requests to Directory Agents: UDP and TCP Port Number: 427 Multicast Addresses Service Location General Multicast Address: 224.0.1.22 Directory Agent Discovery Multicast Address: 224.0.1.35 A range of 1024 contiguous multicast addresses for use as Service Specific Discovery Multicast Addresses will be assigned by IANA. Clearly there needs to be equivalent IPv6 multicast addresses, 5.190 RFC 2177 IMAP4 IDLE command (IMAP4-IDLE) There are no IPv4 dependencies in this protocol. 5.191 RFC 2181 Clarifications to the DNS Specification (DNS-CLAR) There are no IPv4 dependencies in this protocol. The only reference to IP addresses discuss the use of any cast address, so it should be assumed that these mechanisms are IPv6 operable. 5.192 RFC 2183 Communicating Presentation Information in Internet Messages: The Content-Disposition Header Field There are no IPv4 dependencies in this protocol. 5.193 RFC 2190 RTP Payload Format for H.263 Video Streams There are no IPv4 dependencies in this protocol. 5.194 RFC 2192 IMAP URL Scheme (IMAP-URL) There are no IPv4 dependencies in this protocol. 5.195 RFC 2193 IMAP4 Mailbox Referrals (IMAP4MAIL) In Section 6. Formal Syntax referral_response_code = "[" "REFERRAL" 1*(SPACE <url>) "]" ; See [RFC-1738] for <url> definition leaves a dependency on RFC 1738 URL definitions. Presuming the issues discussed for that RFC are resolved, this protocol becomes IPv6 aware. 5.196 RFC 2195 IMAP/POP AUTHorize Extension for Simple Challenge/ Response (IMAPPOPAU) There are no IPv4 dependencies in this protocol. 5.197 RFC 2198 RTP Payload for Redundant Audio Data (RTP-RAD) There are no IPv4 dependencies in this protocol. 5.198 RFC 2203 RPCSEC_GSS Protocol Specification (RPCSEC-GSS) There are no IPv4 dependencies in this protocol. 5.199 RFC 2205 Resource ReSerVation Protocol (RSVP) -- Version 1 Functional Specification (RSVP) In Section 1. Introduction the statement is made: RSVP operates on top of IPv4 or IPv6, occupying the place of a transport protocol in the protocol stack. Appendix A defines all of the header formats for RSVP and there are multiple formats for both IPv4 and IPv6. There are no IPv4 dependencies in this protocol. 5.200 RFC 2206 RSVP Management Information Base using SMIv2 (RSVP-MIB) All OIDs in this MIB have options for both IPv4 and IPv6. There are no IPv4 dependencies in this protocol. 5.201 RFC 2207 RSVP Extensions for IPSEC Data Flows (RSVP-IPSEC) The defined IPsec extensions are valid for both IPv4 & IPv6. There are no IPv4 dependencies in this protocol. 5.202 RFC 2210 The Use of RSVP with IETF Integrated Services (RSVP-IS) There are no IPv4 dependencies in this protocol. 5.203 RFC 2211 Specification of the Controlled-Load Network Element Service There are no IPv4 dependencies in this protocol. 5.204 RFC 2212 Specification of Guaranteed Quality of Service (GQOS) There are no IPv4 dependencies in this protocol. 5.205 RFC 2213 Integrated Services Management Information Base using SMIv2 This MIB is IPv6 aware and therefore there are no IPv4 dependencies in this protocol. 5.206 RFC 2214 Integrated Services Management Information Base Guaranteed Service Extensions using SMIv2 There are no IPv4 dependencies in this protocol. 5.207 RFC 2215 General Characterization Parameters for Integrated Service Network Elements There are no IPv4 dependencies in this protocol. 5.208 RFC 2218 A Common Schema for the Internet White Pages Service There are no IPv4 dependencies in this protocol. 5.209 RFC 2221 IMAP4 Login Referrals (IMAP4LOGIN) In the referral syntax presented in this document the string USER@SERVER2 is presented. No specifications on the formatting of "SERVER2" is presented. It is up to individual implementations to decide acceptable values for the hostname. This may or may not include explicit IPv6 addresses. 5.210 RFC 2222 Simple Authentication and Security Layer (SASL) (SASL) There are no IPv4 dependencies in this protocol. 5.211 RFC 2225 Classical IP and ARP over ATM (IP-ATM) >From the many references in this document it is clear that this document is designed for IPv4 only. It is only later in the document that it is implicitly stated, as in: ar$spln - length in octets of the source protocol address. Value range is 0 or 4 (decimal). For IPv4 ar$spln is 4. ar$tpln - length in octets of the target protocol address. Value range is 0 or 4 (decimal). For IPv4 ar$tpln is 4. and For backward compatibility with previous implementations, a null IPv4 protocol address may be received with length = 4 and an allocated address in storage set to the value 0.0.0.0. Receiving stations MUST be liberal in accepting this format of a null IPv4 address. However, on transmitting an ATMARP or InATMARP packet, a null IPv4 address MUST only be indicated by the length set to zero and MUST have no storage allocated. A new specification for IPv6 must be defined. 5.212 RFC 2226 IP Broadcast over ATM Networks This document is limited to IPv4 multicasting. A new specification for IPv6 must be defined. 5.213 RFC 2227 Simple Hit-Metering and Usage-Limiting for HTTP There are no IPv4 dependencies in this protocol. 5.214 RFC 2228 FTP Security Extensions (FTPSECEXT) There are no IPv4 dependencies in this protocol. 5.215 RFC 2231 MIME Parameter Value and Encoded Word Extensions: Character Sets, Languages, and Continuations (MIME-EXT) There are no IPv4 dependencies in this protocol. 5.216 RFC 2232 Definitions of Managed Objects for DLUR using SMIv2 (DLUR-MIB) There are no IPv4 dependencies in this protocol. 5.217 RFC 2234 Augmented BNF for Syntax Specifications: ABNF (ABNF) There are no IPv4 dependencies in this protocol. 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. 5.219 RFC 2238 Definitions of Managed Objects for HPR using SMIv2 (HPR-MIB) There are no IPv4 dependencies in this protocol. 5.220 RFC 2241 DHCP Options for Novell Directory Services (DHCP-NDS) This document defines extensions for the IPv4 only version of DHCP and it is expected that similar options will be present in DHCPv6. 5.221 RFC 2242 NetWare/IP Domain Name and Information (NETWAREIP) Once again these are options to the IPv4 version of DHCP. It is expected that similar options will for IPv6 will exist in DHCPv6. PREFERRED_DSS (code 6) Length is (n * 4) and the value is an array of n IP addresses, each four bytes in length. The maximum number of addresses is 5 and therefore the maximum length value is 20. The list contains the addresses of n NetWare Domain SAP/RIP Server (DSS). NEAREST_NWIP_SERVER (code 7) Length is (n * 4) and the value is an array of n IP addresses, each four bytes in length. The maximum number of addresses is 5 and therefore the maximum length value is 20. The list contains the addresses of n Nearest NetWare/IP servers. PRIMARY_DSS (code 11) Length of 4, and the value is a single IP address. This field identifies the Primary Domain SAP/RIP Service server (DSS) for this NetWare/IP domain. NetWare/IP administration utility uses this value as Primary DSS server when configuring a secondary DSS server. 5.222 RFC 2243 OTP Extended Responses (OTP-ER) There are no IPv4 dependencies in this protocol. 5.223 RFC 2244 ACAP -- Application Configuration Access Protocol (ACAP) There are no IPv4 dependencies in this protocol. 5.224 RFC 2245 Anonymous SASL Mechanism (SASL-ANON) There are no IPv4 dependencies in this protocol. 5.225 RFC 2246 The TLS Protocol Version 1.0 There are no IPv4 dependencies in this protocol. 5.226 RFC 2247 Using Domains in LDAP/X.500 Distinguished Names There are no IPv4 dependencies in this protocol. 5.227 RFC 2250 RTP Payload Format for MPEG1/MPEG2 Video (RTP-MPEG) There are no IPv4 dependencies in this protocol. 5.228 RFC 2251 Lightweight Directory Access Protocol (v3) (LDAPV3) There are no IPv4 dependencies in this protocol. 5.229 RFC 2252 Lightweight Directory Access Protocol (v3): Attribute Syntax Definitions (LDAP3-ATD) There are no IPv4 dependencies in this protocol. 5.230 RFC 2253 Lightweight Directory Access Protocol (v3): UTF-8 String Representation of Distinguished Names (LDAP3-UTF8) Section 7.1. Disclosure states: Distinguished Names typically consist of descriptive information about the entries they name, which can be people, organizations, devices or other real-world objects. This frequently includes some of the following kinds of information: - the common name of the object (i.e. a person's full name) - an email or TCP/IP address - its physical location (country, locality, city, street address) - organizational attributes (such as department name or affiliation) Without putting any limitations on the version of the IP address. With that single caveat, there are no IPv4 dependencies in this protocol. 5.231 RFC 2254 The String Representation of LDAP Search Filters (STR-LDAP) There are no IPv4 dependencies in this protocol. 5.232 RFC 2255 The LDAP URL Format (LDAP-URL) There are no IPv4 dependencies in this protocol. 5.233 RFC 2256 A Summary of the X.500(96) User Schema for use with LDAPv3 There are no IPv4 dependencies in this protocol. 5.234 RFC 2266 Definitions of Managed Objects for IEEE 802.12 Repeater Devices There are no IPv4 dependencies in this protocol. 5.235 RFC 2284 PPP Extensible Authentication Protocol (EAP) (PPP-EAP) There are no IPv4 dependencies in this protocol. 5.236 RFC 2287 Definitions of System-Level Managed Objects for Applications (SLM-APP) There are no IPv4 dependencies in this protocol. 5.237 RFC 2290 Mobile-IPv4 Configuration Option for PPP IPCP This protocol is IPv4 specific. It is expected that similar methods will be developed for Mobile IPv6. 5.238 RFC 2293 Representing Tables and Subtrees in the X.500 Directory (SUBTABLE) There are no IPv4 dependencies in this protocol. 5.239 RFC 2294 Representing the O/R Address hierarchy in the X.500 Directory Information Tree (OR-ADD) There are no IPv4 dependencies in this protocol. 5.240 RFC 2298 An Extensible Message Format for Message Disposition Notifications (EMF-MDN) There are no IPv4 dependencies in this protocol. 5.241 RFC 2301 File Format for Internet Fax (FFIF) There are no IPv4 dependencies in this protocol. 5.242 RFC 2302 Tag Image File Format (TIFF) - image/tiff MIME Sub-type Registration (TIFF) There are no IPv4 dependencies in this protocol. 5.243 RFC 2303 Minimal PSTN address format in Internet Mail (MIN-PSTN) There are no IPv4 dependencies in this protocol. 5.244 RFC 2304 Minimal FAX address format in Internet Mail (MINFAX-IM) There are no IPv4 dependencies in this protocol. 5.245 RFC 2305 A Simple Mode of Facsimile Using Internet Mail (SMFAX-IM) There are no IPv4 dependencies in this protocol. 5.246 RFC 2308 Negative Caching of DNS Queries (DNS NCACHE) (DNS-NCACHE) Although there are numerous examples in this document that use IPv4 "A" records, there is nothing in the protocol that limits its effectiveness to IPv4. 5.247 RFC 2320 Definitions of Managed Objects for Classical IP and ARP Over ATM Using SMIv2 (IPOA-MIB) (IPOA-MIB) This MIB is wholly dependent of IPv4. A new MIB for IPv6 is required to provide the same functionality 5.248 RFC 2326 Real Time Streaming Protocol (RTSP) (RTSP) Section 3.2 RTSP URL defines: The "rtsp" and "rtspu" schemes are used to refer to network resources via the RTSP protocol. This section defines the scheme-specific syntax and semantics for RTSP URLs. rtsp_URL = ( "rtsp:" | "rtspu:" ) "//" host [ ":" port ] [ abs_path ] host = <A legal Internet host domain name of IP address (in dotted decimal form), as defined by Section 2.1 of RFC 1123 \cite{rfc1123}> port = *DIGIT Although later in that section the following text is added: The use of IP addresses in URLs SHOULD be avoided whenever possible (see RFC 1924 [19]). Some later examples show: Example: C->S: DESCRIBE rtsp://server.example.com/fizzle/foo RTSP/1.0 CSeq: 312 Accept: application/sdp, application/rtsl, application/mheg S->C: RTSP/1.0 200 OK CSeq: 312 Date: 23 Jan 1997 15:35:06 GMT Content-Type: application/sdp Content-Length: 376 v=0 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=mjh@isi.edu (Mark Handley) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 3456 RTP/AVP 0 m=video 2232 RTP/AVP 31 m=whiteboard 32416 UDP WB a=orient:portrait which implies the use of the "IP4" tag and it should be possible to use an "IP6" tag. There are also numerous other similar examples using the "IP4" tag. There seems to be nothing that requires IPv4, and a small set of updates can be created to document IPv6 functionality. 5.249 RFC 2327 SDP: Session Description Protocol (SDP) Like the previous document, a sample SDP description is given as: An example SDP description is: v=0 o=mhandley 2890844526 2890842807 IN IP4 126.16.64.4 s=SDP Seminar i=A Seminar on the session description protocol u=http://www.cs.ucl.ac.uk/staff/M.Handley/sdp.03.ps e=mjh@isi.edu (Mark Handley) c=IN IP4 224.2.17.12/127 t=2873397496 2873404696 a=recvonly m=audio 49170 RTP/AVP 0 m=video 51372 RTP/AVP 31 m=application 32416 udp wb a=orient:portrait Later an explicit discussion of the network addressing scheme is given: <network type> is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet". <address type> is a text string giving the type of the address that follows. Initially "IP4" and "IP6" are defined. <address> is the globally unique address of the machine from which the session was created. For an address type of IP4, this is either the fully-qualified domain name of the machine, or the dotted-decimal representation of the IP version 4 address of the machine. For an address type of IP6, this is either the fully-qualified domain name of the machine, or the compressed textual representation of the IP version 6 address of the machine. For both IP4 and IP6, the fully-qualified domain name is the form that SHOULD be given unless this is unavailable, in which case the globally unique address may be substituted. A local IP address MUST NOT be used in any context where the SDP description might leave the scope in which the address is meaningful. Although later in the definitions of connection types the following text is found: Connection Data c=<network type> <address type> <connection address> The "c=" field contains connection data. A session announcement must contain one "c=" field in each media description (see below) or a "c=" field at the session-level. It may contain a session-level "c=" field and one additional "c=" field per media description, in which case the per-media values override the session-level settings for the relevant media. The first sub-field is the network type, which is a text string giving the type of network. Initially "IN" is defined to have the meaning "Internet". The second sub-field is the address type. This allows SDP to be used for sessions that are not IP based. Currently only IP4 is defined. The third sub-field is the connection address. Optional extra subfields may be added after the connection address depending on the value of the <address type> field. For IP4 addresses, the connection address is defined as follows: o Typically the connection address will be a class-D IP multicast group address. If the session is not multicast, then the connection address contains the fully-qualified domain name or the unicast IP address of the expected data source or data relay or data sink as determined by additional attribute fields. It is not expected that fully-qualified domain names or unicast addresses will be given in a session description that is communicated by a multicast announcement, though this is not prohibited. If a unicast data stream is to pass through a network address translator, the use of a fully-qualified domain name rather than an unicast IP address is RECOMMENDED. In other cases, the use of an IP address to specify a particular interface on a multi-homed host might be required. Thus this specification leaves the decision as to which to use up to the individual application, but all applications MUST be able to cope with receiving both formats. o Conferences using an IP multicast connection address must also have a time to live (TTL) value present in addition to the multicast address. The TTL and the address together define the scope with which multicast packets sent in this conference will be sent. TTL values must be in the range 0-255. The TTL for the session is appended to the address using a slash as a separator. An example is: c=IN IP4 224.2.1.1/127 Hierarchical or layered encoding schemes are data streams where the encoding from a single media source is split into a number of layers. The receiver can choose the desired quality (and hence bandwidth) by only subscribing to a subset of these layers. Such layered encodings are normally transmitted in multiple multicast groups to allow multicast pruning. This technique keeps unwanted traffic from sites only requiring certain levels of the hierarchy. For applications requiring multiple multicast groups, we allow the following notation to be used for the connection address: <base multicast address>/<ttl>/<number of addresses> If the number of addresses is not given it is assumed to be one. Multicast addresses so assigned are contiguously allocated above the base address, so that, for example: c=IN IP4 224.2.1.1/127/3 would state that addresses 224.2.1.1, 224.2.1.2 and 224.2.1.3 are to be used at a ttl of 127. This is semantically identical to including multiple "c=" lines in a media description: c=IN IP4 224.2.1.1/127 c=IN IP4 224.2.1.2/127 c=IN IP4 224.2.1.3/127 Multiple addresses or "c=" lines can only be specified on a per- media basis, and not for a session-level "c=" field. It is illegal for the slash notation described above to be used for IP unicast addresses. This is probably because the definitions for IPv6 multicast was not standardized at the time of this documents production. A similar mechanism for IPv6 multicast could defined in a straightforward manner. 5.250 RFC 2331 ATM Signaling Support for IP over ATM - UNI Signaling 4.0 Update (UNI-SIG) There are no IPv4 dependencies in this protocol. 5.251 RFC 2332 NBMA Next Hop Resolution Protocol (NHRP) (NHRP) This document is very generic in its design and seems to be able to support numerous layer 3 addressing schemes and should include both IPv4 and IPv6. 5.252 RFC 2333 NHRP Protocol Applicability Statement This document is very generic in its design and seems to be able to support numerous layer 3 addressing schemes and should include both IPv4 and IPv6. 5.253 RFC 2334 Server Cache Synchronization Protocol (SCSP) (SCSP) The only reference to IPv4 specific issues is shown below: Cache Key This is a database lookup key that uniquely identifies a piece of data which the originator of a CSA Record wishes to synchronize with its peers for a given "Protocol ID/Server Group ID" pair. This key will generally be a small opaque byte string which SCSP will associate with a given piece of data in a cache. Thus, for example, an originator might assign a particular 4 byte string to the binding of an IP address with that of an ATM address. Generally speaking, the originating server of a CSA record is responsible for generating a Cache Key for every element of data that the given server originates and which the server wishes to synchronize with its peers in the SG. Since this is only an example, it does not preclude the use of IPv6 addresses as well. It is most likely an implementation issue. 5.254 RFC 2335 A Distributed NHRP Service Using SCSP (NHRP-SCSP) There are no IPv4 dependencies in this protocol. 5.255 RFC 2338 Virtual Router Redundancy Protocol (VRRP) This protocol is IPv4 specific. See the following: 5.1 VRRP Packet Format This section defines the format of the VRRP packet and the relevant fields in the IP header. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |Version| Type | Virtual Rtr ID| Priority | Count IP Addrs| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Auth Type | Adver Int | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | . | | . | | . | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address (n) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data (1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Authentication Data (2) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 5.2 IP Field Descriptions 5.2.1 Source Address The primary IP address of the interface the packet is being sent from. 5.2.2 Destination Address The IP multicast address as assigned by the IANA for VRRP is: 224.0.0.18 This is a link local scope multicast address. Routers MUST NOT forward a datagram with this destination address regardless of its TTL. There are numerous other references to 32-bit IP addresses. There does not seem to be any reason that a new version of this protocol could be straightforwardly be developed for IPv6. 5.256 RFC 2342 IMAP4 Namespace (IMAP4NAME) There are no IPv4 dependencies in this protocol. 5.257 RFC 2359 IMAP4 UIDPLUS extension (IMAP4UIDPL) There are no IPv4 dependencies in this protocol. 5.258 RFC 2363 PPP Over FUNI (PPP-FUNI) There are no IPv4 dependencies in this protocol. 5.259 RFC 2364 PPP Over AAL5 (PPP-AAL) There are no IPv4 dependencies in this protocol. 5.260 RFC 2368 The mailto URL scheme (URLMAILTO) There are no IPv4 dependencies in this protocol. 5.261 RFC 2369 The Use of URLs as Meta-Syntax for Core Mail List Commands and their Transport through Message Header Fields There are no IPv4 dependencies in this protocol. 5.262 RFC 2370 The OSPF Opaque LSA Option (OSPF-LSA) There are no IPv4 dependencies in this protocol other than the fact that it is an new functionality for a routing protocol that only supports IPv4 networks. It is assumed that a future update to OSPF to support IPv6 will also support this functionality. 5.263 RFC 2371 Transaction Internet Protocol Version 3.0 TIPV3 This document states: TIP transaction manager addresses take the form: <hostport><path> The <hostport> component comprises: <host>[:<port>] where <host> is either a <dns name> or an <ip address>; and <port> is a decimal number specifying the port at which the transaction manager (or proxy) is listening for requests to establish TIP connections. If the port number is omitted, the standard TIP port number (3372) is used. A <dns name> is a standard name, acceptable to the domain name service. It must be sufficiently qualified to be useful to the receiver of the command. An <ip address> is an IP address, in the usual form: four decimal numbers separated by period characters. and further along it states: A TIP URL takes the form: tip://<transaction manager address>?<transaction string> where <transaction manager address> identifies the TIP transaction manager (as defined in Section 7 above); and <transaction string> specifies a transaction identifier, which may take one of two forms (standard or non-standard): i. "urn:" <NID> ":" <NSS> A standard transaction identifier, conforming to the proposed Internet Standard for Uniform Resource Names (URNs), as specified by RFC2141; where <NID> is the Namespace Identifier, and <NSS> is the Namespace Specific String. The Namespace ID determines the syntactic interpretation of the Namespace Specific String. The Namespace Specific String is a sequence of characters representing a transaction identifier (as defined by <NID>). The rules for the contents of these fields are specified by [6] (valid characters, encoding, etc.). This format of <transaction string> may be used to express global transaction identifiers in terms of standard representations. Examples for <NID> might be <iso> or <xopen>. e.g. tip://123.123.123.123/?urn:xopen:xid Note that Namespace Ids require registration. See [7] for details on how to do this. ii. <transaction identifier> A sequence of printable ASCII characters (octets with values in the range 32 through 126 inclusive (excluding ":") representing a transaction identifier. In this non-standard case, it is the combination of <transaction manager address> and <transaction identifier> which ensures global uniqueness. e.g. tip://123.123.123.123/?transid1 It is not hard to assume that the production of an updated protocol specification that supports IPv6 could be accomplished. 5.264 RFC 2373 IP Version 6 Addressing Architecture, This RFC documents IPv6 addressing and is not discussed in this document. 5.265 RFC 2374 An IPv6 Aggregatable Global Unicast Address Format, This RFC documents IPv6 addressing and is not discussed in this document. 5.266 RFC 2380 RSVP over ATM Implementation Requirements This protocol is both IPv4 and IPv6 aware. 5.267 RFC 2381 Interoperation of Controlled-Load Service and Guaranteed Service with ATM There does not seem any inherent IPv4 limitations in this protocol, but it assumes work of other standards that have IPv4 limitations. 5.268 RFC 2384 POP URL Scheme (POP-URL) The following dependencies are in this document: A POP URL is of the general form: pop://<user>;auth=<auth>@<host>:<port> Where <user>, <host>, and <port> are as defined in RFC 1738, and some or all of the elements, except "pop://" and <host>, may be omitted. Since RFC 1738 has a potential IPv4 limitation, this protocol will be IPv6 compliant when RFC 1738 is updated. 5.269 RFC 2385 Protection of BGP Sessions via the TCP MD5 Signature Option Although the protocol enhancements have no IPv4 dependencies, it is an update to an IPv4 only routing protocol. It is expected that a newer version of BGP that is IPv6 aware will also implement this enhancement. 5.270 RFC 2387 The MIME Multipart/Related Content-type (MIME-RELAT) There are no IPv4 dependencies in this protocol. 5.271 RFC 2388 Returning Values from Forms: multipart/form-data There are no IPv4 dependencies in this protocol. 5.272 RFC 2389 Feature negotiation mechanism for the File Transfer Protocol There are no IPv4 dependencies in this protocol. 5.273 RFC 2392 Content-ID and Message-ID Uniform Resource Locators (CIDMID-URL) There are no IPv4 dependencies in this protocol. 5.274 RFC 2393 IP Payload Compression Protocol (IPComp) (IPCOMP) This protocol is both IPv4 and IPv6 aware. 5.275 RFC 2397 The "data" URL scheme (DATA-URL) There are no IPv4 dependencies in this protocol. 5.276 RFC 2401 Security Architecture for the Internet Protocol (IPSEC) This protocol is both IPv4 and IPv6 aware. 5.277 RFC 2402 IP Authentication Header (IP-AUTH) This protocol is both IPv4 and IPv6 aware. 5.278 RFC 2403 The Use of HMAC-MD5-96 within ESP and AH There are no IPv4 dependencies in this protocol. 5.279 RFC 2404 The Use of HMAC-SHA-1-96 within ESP and AH There are no IPv4 dependencies in this protocol. 5.280 RFC 2405 The ESP DES-CBC Cipher Algorithm With Explicit IV (ESPDES-CBC) There are no IPv4 dependencies in this protocol. 5.281 RFC 2406 IP Encapsulating Security Payload (ESP) (ESP) This protocol is both IPv4 and IPv6 aware. 5.282 RFC 2407 The Internet IP Security Domain of Interpretation for ISAKMP (ISAKMPSEC) This protocol is both IPv4 and IPv6 aware. 5.283 RFC 2408 Internet Security Association and Key Management Protocol (ISAKMP) (ISAKMP) This protocol is both IPv4 and IPv6 aware. 5.284 RFC 2409 The Internet Key Exchange (IKE) (IKE) There are no IPv4 dependencies in this protocol. 5.285 RFC 2410 The NULL Encryption Algorithm and Its Use With IPsec There are no IPv4 dependencies in this protocol. 5.286 RFC 2417 Definitions of Managed Objects for Multicast over UNI 3.0/3.1 based ATM Networks There are many OIDs defined in this MIB which are IPv4 only. A similar MIB for IPv6 OIDs should be created. 5.287 RFC 2419 The PPP DES Encryption Protocol, Version 2 (DESE-bis) (DESE-bis) There are no IPv4 dependencies in this protocol. 5.288 RFC 2420 The PPP Triple-DES Encryption Protocol (3DESE) (3DESE) There are no IPv4 dependencies in this protocol. 5.289 RFC 2421 Voice Profile for Internet Mail - version 2 (MIME-VP2) There are no IPv4 dependencies in this protocol. 5.290 RFC 2422 Toll Quality Voice - 32 kbit/s ADPCM MIME Sub-type Registration (MIME-ADPCM) There are no IPv4 dependencies in this protocol. 5.291 RFC 2423 VPIM Voice Message MIME Sub-type Registration (MIME-VPIM) There are no IPv4 dependencies in this protocol. 5.292 RFC 2424 Content Duration MIME Header Definition (CONT-DUR) There are no IPv4 dependencies in this protocol. 5.293 RFC 2425 A MIME Content-Type for Directory Information (TXT-DIR) There are no IPv4 dependencies in this protocol. 5.294 RFC 2426 vCard MIME Directory Profile (MIME-VCARD) There are no IPv4 dependencies in this protocol. 5.295 RFC 2428 FTP Extensions for IPv6 and NATs This RFC documents an IPv6 extension and is not considered in this discussion. 5.296 RFC 2429 RTP Payload Format for the 1998 Version of ITU-T Rec. H.263 Video (H.263+) There are no IPv4 dependencies in this protocol. 5.297 RFC 2431 RTP Payload Format for BT.656 Video Encoding There are no IPv4 dependencies in this protocol. 5.298 RFC 2435 RTP Payload Format for JPEG-compressed Video There are no IPv4 dependencies in this protocol. 5.299 RFC 2439 BGP Route Flap Damping Although the protocol enhancements have no IPv4 dependencies, it is an update to an IPv4 only routing protocol. It is expected that a newer version of BGP that is IPv6 aware will also implement this enhancement. 5.300 RFC 2440 OpenPGP Message Format There are no IPv4 dependencies in this protocol. 5.301 RFC 2444 The One-Time-Password SASL Mechanism (OTP-SASL) There are no IPv4 dependencies in this protocol. 5.302 RFC 2445 Internet Calendaring and Scheduling Core Object Specification (iCalendar) (ICALENDAR) Section 4.8.4.7 Unique Identifier states: Property Name: UID Purpose: This property defines the persistent, globally unique identifier for the calendar component. Value Type: TEXT Property Parameters: Non-standard property parameters can be specified on this property. Conformance: The property MUST be specified in the "VEVENT", "VTODO", "VJOURNAL" or "VFREEBUSY" calendar components. Description: The UID itself MUST be a globally unique identifier. The generator of the identifier MUST guarantee that the identifier is unique. There are several algorithms that can be used to accomplish this. The identifier is RECOMMENDED to be the identical syntax to the [RFC 822] addr-spec. A good method to assure uniqueness is to put the domain name or a domain literal IP address of the host on which the identifier was created on the right hand side of the "@", and on the left hand side, put a combination of the current calendar date and time of day (i.e., formatted in as a DATE-TIME value) along with some other currently unique (perhaps sequential) identifier available on the system (for example, a process id number). Using a date/time value on the left hand side and a domain name or domain literal on the right hand side makes it possible to guarantee uniqueness since no two hosts should be using the same domain name or IP address at the same time. Though other algorithms will work, it is RECOMMENDED that the right hand side contain some domain identifier (either of the host itself or otherwise) such that the generator of the message identifier can guarantee the uniqueness of the left hand side within the scope of that domain. Although it does not explicitly state the use of IPv4 addresses, they are explicit in RFC 822. It should explicitly disallow the use of IPv4 addresses. 5.303 RFC 2446 iCalendar Transport-Independent Interoperability Protocol (iTIP) Scheduling Events, BusyTime, To-dos and Journal Entries (ITIP) There are no IPv4 dependencies in this protocol. 5.304 RFC 2447 iCalendar Message-Based Interoperability Protocol (iMIP) (IMIP) There are no IPv4 dependencies in this protocol. 5.305 RFC 2449 POP3 Extension Mechanism (POP3-EXT) There are no IPv4 dependencies in this protocol. 5.306 RFC 2451 The ESP CBC-Mode Cipher Algorithms There are no IPv4 dependencies in this protocol. 5.307 RFC 2452 IP Version 6 Management Information Base for the Transmission Control Protocol This RFC documents an IPv6 MIB and is not considered in this discussion. 5.308 RFC 2454 IP Version 6 Management Information Base for the User Datagram Protocol This RFC documents an IPv6 MIB and is not considered in this discussion. 5.309 RFC 2455 Definitions of Managed Objects for APPN (APPN-MIB) There are no IPv4 dependencies in this protocol. 5.310 RFC 2456 Definitions of Managed Objects for APPN TRAPS There are no IPv4 dependencies in this protocol. 5.311 RFC 2457 Definitions of Managed Objects for Extended Border Node (EBN-MIB) There are no IPv4 dependencies in this protocol. 5.312 RFC 2459 Internet X.509 Public Key Infrastructure Certificate and CRL Profile This protocol is both IPv4 and IPv6 aware. 5.313 RFC 2464 Transmission of IPv6 Packets over Ethernet Networks This RFC documents a method for transmitting IPv6 packets over ethernet and is not considered in this discussion. 5.314 RFC 2465 Management Information Base for IP Version 6: Textual Conventions and General Group This RFC documents an IPv6 MIB and is not considered in this discussion. 5.315 RFC 2466 Management Information Base for IP Version 6: ICMPv6 Group (ICMPv6-MIB) This RFC documents an IPv6 MIB and is not considered in this discussion. 5.316 RFC 2467 Transmission of IPv6 Packets over FDDI Networks This RFC documents a method for transmitting IPv6 packets over FDDI and is not considered in this discussion. 5.317 RFC 2470 Transmission of IPv6 Packets over Token Ring Networks This RFC documents a method for transmitting IPv6 packets over token ring and is not considered in this discussion. 5.318 RFC 2472 IP Version 6 over PPP (IPv6-PPP) This RFC documents a method for transmitting IPv6 packets over PPP and is not considered in this discussion. 5.319 RFC 2473 Generic Packet Tunneling in IPv6 Specification This RFC documents an IPv6 aware protocol and is not considered in this discussion. 5.320 RFC 2474 Definition of the Differentiated Services Field (DS Field) in the IPv4 and IPv6 Headers This protocol is both IPv4 and IPv6 aware. 5.321 RFC 2476 Message Submission There are several discussions of using IP Address authorization schemes, but the protocol does not limit those addresses to IPv4. 5.322 RFC 2478 The Simple and Protected GSS-API Negotiation Mechanism There are no IPv4 dependencies in this protocol. 5.323 RFC 2480 Gateways and MIME Security Multiparts There are no IPv4 dependencies in this protocol. 5.324 RFC 2484 PPP LCP Internationalization Configuration Option There are no IPv4 dependencies in this protocol. 5.325 RFC 2485 DHCP Option for The Open Group's User Authentication Protocol This document defines extensions for the IPv4 only version of DHCP and it is expected that similar options will be present in DHCPv6. 5.326 RFC 2486 The Network Access Identifier (NAI) There are no IPv4 dependencies in this protocol. 5.327 RFC 2487 SMTP Service Extension for Secure SMTP over TLS There are no IPv4 dependencies in this protocol. 5.328 RFC 2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks (IPv6-NBMA) This RFC documents a method for transmitting IPv6 packets over NBMA networks and is not considered in this discussion. 5.329 RFC 2492 IPv6 over ATM Networks (IPv6ATMNET) This RFC documents a method for transmitting IPv6 packets over ATM networks and is not considered in this discussion. 5.330 RFC 2493 Textual Conventions for MIB Modules Using Performance History Based on 15 Minute Intervals There are no IPv4 dependencies in this protocol. 5.331 RFC 2494 Definitions of Managed Objects for the DS0 and DS0 Bundle Interface Type There are no IPv4 dependencies in this protocol. 5.332 RFC 2495 Definitions of Managed Objects for the DS1 E1 DS2 and E2 Interface Types There are no IPv4 dependencies in this protocol. 5.333 RFC 2496 Definitions of Managed Object for the DS3/E3 Interface Type (DS3-E3-MIB) There are no IPv4 dependencies in this protocol. 5.334 RFC 2497 Transmission of IPv6 Packets over ARCnet Networks This RFC documents a method for transmitting IPv6 packets over ARCnet networks and is not considered in this discussion. 5.335 RFC 2507 IP Header Compression This protocol is both IPv4 and IPv6 aware. 5.336 RFC 2508 Compressing IP/UDP/RTP Headers for Low-Speed Serial Links This protocol is both IPv4 and IPv6 aware. 5.337 RFC 2509 IP Header Compression over PPP (IPCOM-PPP) This protocol is both IPv4 and IPv6 aware. 5.338 RFC 2510 Internet X.509 Public Key Infrastructure Certificate Management Protocols (PKICMP) There are no IPv4 dependencies in this protocol. 5.339 RFC 2511 Internet X.509 Certificate Request Message Format (X.509-CRMF) There are no IPv4 dependencies in this protocol. 5.340 RFC 2512 Accounting Information for ATM Networks There are no IPv4 dependencies in this protocol. 5.341 RFC 2513 Managed Objects for Controlling the Collection and Storage of Accounting Information for Connection- Oriented Networks There are no IPv4 dependencies in this protocol. 5.342 RFC 2514 Definitions of Textual Conventions and OBJECT-IDENTITIES for ATM Management (ATM-TC-OID) There are no IPv4 dependencies in this protocol. 5.343 RFC 2515 Definitions of Managed Objects for ATM Management (ATM-MIBMAN) This MIB defines the following OIDs: AtmInterfaceConfEntry ::= SEQUENCE { atmInterfaceMaxVpcs INTEGER, atmInterfaceMaxVccs INTEGER, atmInterfaceConfVpcs INTEGER, atmInterfaceConfVccs INTEGER, atmInterfaceMaxActiveVpiBits INTEGER, atmInterfaceMaxActiveVciBits INTEGER, atmInterfaceIlmiVpi AtmVpIdentifier, atmInterfaceIlmiVci AtmVcIdentifier, atmInterfaceAddressType INTEGER, atmInterfaceAdminAddress AtmAddr, atmInterfaceMyNeighborIpAddress IpAddress, atmInterfaceMyNeighborIfName DisplayString, atmInterfaceCurrentMaxVpiBits INTEGER, atmInterfaceCurrentMaxVciBits INTEGER, atmInterfaceSubscrAddress AtmAddr } atmInterfaceMyNeighborIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-write STATUS current DESCRIPTION "The IP address of the neighbor system connected to the far end of this interface, to which a Network Management Station can send SNMP messages, as IP datagrams sent to UDP port 161, in order to access network management information concerning the operation of that system. Note that the value of this object may be obtained in different ways, e.g., by manual configuration, or through ILMI interaction with the neighbor system." ::= { atmInterfaceConfEntry 11 } atmInterfaceConfGroup2 OBJECT-GROUP OBJECTS { atmInterfaceMaxVpcs, atmInterfaceMaxVccs, atmInterfaceConfVpcs, atmInterfaceConfVccs, atmInterfaceMaxActiveVpiBits, atmInterfaceMaxActiveVciBits, atmInterfaceIlmiVpi, atmInterfaceIlmiVci, atmInterfaceMyNeighborIpAddress, atmInterfaceMyNeighborIfName, atmInterfaceCurrentMaxVpiBits, atmInterfaceCurrentMaxVciBits, atmInterfaceSubscrAddress } STATUS current DESCRIPTION "A collection of objects providing configuration information about an ATM interface." ::= { atmMIBGroups 10 } Clearly a subsequent MIB must define equivalent IPv6 OIDs. 5.344 RFC 2518 HTTP Extensions for Distributed Authoring -- WEBDAV (WEBDAV) There are no IPv4 dependencies in this protocol. 5.345 RFC 2526 Reserved IPv6 Subnet Anycast Addresses This RFC documents IPv6 addressing and is not discussed in this document. 5.346 RFC 2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels This RFC documents IPv6 transmission methods and is not discussed in this document. 5.347 RFC 2530 Indicating Supported Media Features Using Extensions to DSN and MDN There are no IPv4 dependencies in this protocol. 5.348 RFC 2532 Extended Facsimile Using Internet Mail There are no IPv4 dependencies in this protocol. 5.349 RFC 2533 A Syntax for Describing Media Feature Sets There are no IPv4 dependencies in this protocol. 5.350 RFC 2534 Media Features for Display, Print, and Fax There are no IPv4 dependencies in this protocol. 5.351 RFC 2535 Domain Name System Security Extensions (DNS-SECEXT) There are no IPv4 dependencies in this protocol. There are discussions of A and AAAA records in the document, but have no real implications on IPv4 dependency or on any IP related address records. 5.352 RFC 2536 DSA KEYs and SIGs in the Domain Name System (DNS) There are no IPv4 dependencies in this protocol. 5.353 RFC 2537 RSA/MD5 KEYs and SIGs in the Domain Name System (DNS) There are no IPv4 dependencies in this protocol. 5.354 RFC 2538 Storing Certificates in the Domain Name System (DNS) (SC-DNS) Section 3.1 X.509 CERT RR Names Some X.509 versions permit multiple names to be associated with subjects and issuers under "Subject Alternate Name" and "Issuer Alternate Name". For example, x.509v3 has such Alternate Names with an ASN.1 specification as follows: GeneralName ::= CHOICE { otherName [0] INSTANCE OF OTHER-NAME, rfc822Name [1] IA5String, dNSName [2] IA5String, x400Address [3] EXPLICIT OR-ADDRESS.&Type, directoryName [4] EXPLICIT Name, ediPartyName [5] EDIPartyName, uniformResourceIdentifier [6] IA5String, iPAddress [7] OCTET STRING, registeredID [8] OBJECT IDENTIFIER } uses a potential IPv4 only address. It goes on with the following example: Example 2: Assume that an X.509v3 certificate is issued to /CN=James Hacker/L=Basingstoke/O=Widget Inc/C=GB/ with Subject Alternate names of (a) domain name widget.foo.example, (b) IPv4 address 10.251.13.201, and (c) string "James Hacker <hacker@mail.widget.foo.example>". Then the storage locations recommended, in priority order, would be (1) widget.foo.example, (2) 201.13.251.10.in-addr.arpa, and (3) hacker.mail.widget.foo.example. Since the definition of X.509v3 certificates is not discussed in this document it is unclear if IPv6 addresses are also supported in the above mentioned field. 5.355 RFC 2539 Storage of Diffie-Hellman Keys in the Domain Name System (DNS) (DHK-DNS) There are no IPv4 dependencies in this protocol. 5.356 RFC 2543 SIP: Session Initiation Protocol (SIP) In Section 2 SIP Uniform Resource Locators the following specification is made: SIP-URL = "sip:" [ userinfo "@" ] hostport url-parameters [ headers ] hostport = host [ ":" port ] host = hostname | IPv4address hostname = *( domainlabel "." ) toplabel [ "." ] IPv4address = 1*digit "." 1*digit "." 1*digit "." 1*digit Later it states: The issue of IPv6 literal addresses in URLs is being looked at elsewhere in the IETF. SIP implementers are advised to keep up to date on that activity. Further: URL parameters: SIP URLs can define specific parameters of the request. URL parameters are added after the host component and are separated by semi-colons. The transport parameter determines the transport mechanism (UDP or TCP). UDP is to be assumed when no explicit transport parameter is included. The maddr parameter provides the server address to be contacted for this user, overriding the address supplied in the host field. This address is typically a multicast address, but could also be the address of a backup server. The ttl parameter determines the time-to-live value of the UDP multicast packet and MUST only be used if maddr is a multicast address and the transport protocol is UDP. The user parameter was described above. For example, to specify to call j.doe@big.com using multicast to 239.255.255.1 with a ttl of 15, the following URL would be used: sip:j.doe@big.com;maddr=239.255.255.1;ttl=15 and then: sip:alice@10.1.2.3 and in Section 4.2.6 REGISTER A client uses the REGISTER method to register the address listed in the To header field with a SIP server. A user agent MAY register with a local server on startup by sending a REGISTER request to the well-known "all SIP servers" multicast address "sip.mcast.net" (224.0.1.75). There are many examples of transactions which use IPv4 only addresses. This protocol clearly needs to be updated for IPv6. 5.357 RFC 2545 Use of BGP-4 Multiprotocol Extensions for IPv6 Inter-Domain Routing This RFC documents IPv6 routing methods and is not discussed in this document. 5.358 RFC 2554 SMTP Service Extension for Authentication There are no IPv4 dependencies in this protocol. 5.359 RFC 2557 MIME Encapsulation of Aggregate Documents, such as HTML (MHTML) (MHTML) There are no IPv4 dependencies in this protocol. 5.360 RFC 2558 Definitions of Managed Objects for the SONET/SDH Interface Type There are no IPv4 dependencies in this protocol. 5.361 RFC 2559 Internet X.509 Public Key Infrastructure Operational Protocols - LDAPv2 There are no IPv4 dependencies in this protocol. 5.362 RFC 2560 X.509 Internet Public Key Infrastructure Online Certificate Status Protocol - OCSP (PKIX) There are no IPv4 dependencies in this protocol. 5.363 RFC 2561 Base Definitions of Managed Objects for TN3270E Using SMIv2 The document states: The MIB defined by this memo supports use of both IPv4 and IPv6 addressing. This protocol is both IPv4 and IPv6 aware. 5.364 RFC 2562 Definitions of Protocol and Managed Objects for TN3270E Response Time Collection Using SMIv2 (TN3270E-RT-MIB) (TN2370E-RT) Several OIDs rely on imports from RFC 2561 and therefore the protocol is both IPv4 and IPv6 aware. 5.365 RFC 2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients This document is only designated for IPv4. It is expected that similar functionality is available in DHCPv6. 5.366 RFC 2564 Application Management MIB (APP-MIB) The following OID is defined: ApplTAddress ::= TEXTUAL-CONVENTION STATUS current DESCRIPTION "Denotes a transport service address. For snmpUDPDomain, an ApplTAddress is 6 octets long, the initial 4 octets containing the IP-address in network-byte order and the last 2 containing the UDP port in network-byte order. Consult 'Transport Mappings for Version 2 of the Simple Network Management Protocol (SNMPv2)' for further information on snmpUDPDomain." SYNTAX OCTET STRING (SIZE (0..255)) A new OID should be defined to handle IPv6 addresses. 5.367 RFC 2576 Coexistence between Version 1 Version 2 and Version 3 of the Internet-standard Network Management Framework (SNMP) This document states: (11) For any object with a SYNTAX of NetworkAddress, the SYNTAX MUST be changed to IpAddress. Note that the use of NetworkAddress in new MIB documents is strongly discouraged (in fact, new MIB documents should be written using SMIv2, which does not define NetworkAddress). and defines the OID: snmpTrapAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS accessible-for-notify STATUS current DESCRIPTION "The value of the agent-addr field of a Trap PDU which is forwarded by a proxy forwarder application using an SNMP version other than SNMPv1. The value of this object SHOULD contain the value of the agent-addr field from the original Trap PDU as generated by an SNMPv1 agent." ::= { snmpCommunityMIBObjects 3 } This clearly points out a lack of IPv6 awareness in this protocol. 5.368 RFC 2581 TCP Congestion Control (TCP-CC) There are no IPv4 dependencies in this protocol. 5.369 RFC 2584 Definitions of Managed Objects for APPN/HPR in IP Networks Many of the OIDs described in this document assume the use of the IPv4 only TOS header bits. It is therefore IPv4 only in nature and will not support IPv6 interfaces. An updated MIB should be created. 5.370 RFC 2585 Internet X.509 Public Key Infrastructure Operational Protocols: FTP and HTTP There are no IPv4 dependencies in this protocol. 5.371 RFC 2587 Internet X.509 Public Key Infrastructure LDAPv2 Schema There are no IPv4 dependencies in this protocol. 5.372 RFC 2589 Lightweight Directory Access Protocol (v3): Extensions for Dynamic Directory Services (LDAPv3) There are no IPv4 dependencies in this protocol. 5.373 RFC 2590 Transmission of IPv6 Packets over Frame Relay Networks Specification This RFC documents IPv6 transmission method over Frame Relay and is not discussed in this document. 5.374 RFC 2591 Definitions of Managed Objects for Scheduling Management Operations There are no IPv4 dependencies in this protocol. 5.375 RFC 2592 Definitions of Managed Objects for the Delegation of Management Script There are no IPv4 dependencies in this protocol. 5.376 RFC 2594 Definitions of Managed Objects for WWW Services There are no IPv4 dependencies in this protocol. 5.377 RFC 2595 Using TLS with IMAP, POP3 and ACAP There are no IPv4 dependencies in this protocol. 5.378 RFC 2596 Use of Language Codes in LDAP There are no IPv4 dependencies in this protocol. 5.379 RFC 2597 Assured Forwarding PHB Group This protocol is both IPv4 and IPv6 aware. 5.380 RFC 2598 An Expedited Forwarding PHB This protocol is both IPv4 and IPv6 aware. 5.381 RFC 2601 ILMI-Based Server Discovery for ATMARP This protocol is both IPv4 and IPv6 aware. 5.382 RFC 2602 ILMI-Based Server Discovery for MARS This protocol is both IPv4 and IPv6 aware. 5.383 RFC 2603 ILMI-Based Server Discovery for NHRP This protocol is both IPv4 and IPv6 aware. 5.384 RFC 2605 Directory Server Monitoring MIB There are no IPv4 dependencies in this protocol. 5.385 RFC 2608 Service Location Protocol, Version 2 (SLP) In Section 8.1. Service Request 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Service Location header (function = SrvRqst = 1) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <PRList> | <PRList> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <service-type> | <service-type> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <scope-list> | <scope-list> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of predicate string | Service Request <predicate> \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | length of <SLP SPI> string | <SLP SPI> String \ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ <PRList> is the Previous Responder List. This <string-list> contains dotted decimal notation IP (v4) addresses, and is iteratively multicast to obtain all possible results (see Section 6.3). UAs SHOULD implement this discovery algorithm. SAs MUST use this to discover all available DAs in their scope, if they are not already configured with DA addresses by some other means. and later: A SA silently drops all requests which include the SA's address in the <PRList>. An SA which has multiple network interfaces MUST check if any of the entries in the <PRList> equal any of its interfaces. An entry in the PRList which does not conform to an IPv4 dotted decimal address is ignored: The rest of the <PRList> is processed normally and an error is not returned. A new version of the protocol must be defined to support IPv6 environments. 5.386 RFC 2609 Service Templates and Service: Schemes This document defines: The ABNF for a service: URL is: hostnumber = ipv4-number ipv4-number = 1*3DIGIT 3("." 1*3DIGIT) There are many other references to the hostnumber in the document. There should be an update to support IPv6. 5.387 RFC 2610 DHCP Options for Service Location Protocol This document is only designated for IPv4. It is expected that similar functionality is available in DHCPv6. 5.388 RFC 2613 Remote Network Monitoring MIB Extensions for Switched Networks Version 1.0 There are no IPv4 dependencies in this protocol. 5.389 RFC 2615 PPP over SONET/SDH There are no IPv4 dependencies in this protocol. 5.390 RFC 2618 RADIUS Authentication Client MIB This RFC defines the following OIDs: RadiusAuthServerEntry ::= SEQUENCE { radiusAuthServerIndex Integer32, radiusAuthServerAddress IpAddress, radiusAuthClientServerPortNumber Integer32, radiusAuthClientRoundTripTime TimeTicks, radiusAuthClientAccessRequests Counter32, radiusAuthClientAccessRetransmissions Counter32, radiusAuthClientAccessAccepts Counter32, radiusAuthClientAccessRejects Counter32, radiusAuthClientAccessChallenges Counter32, radiusAuthClientMalformedAccessResponses Counter32, radiusAuthClientBadAuthenticators Counter32, radiusAuthClientPendingRequests Gauge32, radiusAuthClientTimeouts Counter32, radiusAuthClientUnknownTypes Counter32, radiusAuthClientPacketsDropped Counter32 } radiusAuthServerAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The IP address of the RADIUS authentication server referred to in this table entry." ::= { radiusAuthServerEntry 2 } There needs to be an update to allow an IPv6 based OID for this value. 5.391 RFC 2619 RADIUS Authentication Server MIB This MIB defines the followings OIDs: RadiusAuthClientEntry ::= SEQUENCE { radiusAuthClientIndex Integer32, radiusAuthClientAddress IpAddress, radiusAuthClientID SnmpAdminString, radiusAuthServAccessRequests Counter32, radiusAuthServDupAccessRequests Counter32, radiusAuthServAccessAccepts Counter32, radiusAuthServAccessRejects Counter32, radiusAuthServAccessChallenges Counter32, radiusAuthServMalformedAccessRequests Counter32, radiusAuthServBadAuthenticators Counter32, radiusAuthServPacketsDropped Counter32, radiusAuthServUnknownTypes Counter32 } radiusAuthClientAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The NAS-IP-Address of the RADIUS authentication client referred to in this table entry." ::= { radiusAuthClientEntry 2 } There needs to be an update to allow an IPv6 based OID for this value. 5.392 RFC 2622 Routing Policy Specification Language (RPSL) (RPSL) The only objects in the version of RPSL that deal with IP addresses are defined as: <ipv4-address> An IPv4 address is represented as a sequence of four integers in the range from 0 to 255 separated by the character dot ".". For example, 128.9.128.5 represents a valid IPv4 address. In the rest of this document, we may refer to IPv4 addresses as IP addresses. <address-prefix> An address prefix is represented as an IPv4 address followed by the character slash "/" followed by an integer in the range from 0 to 32. The following are valid address prefixes: 128.9.128.5/32, 128.9.0.0/16, 0.0.0.0/0; and the following address prefixes are invalid: 0/0, 128.9/16 since 0 or 128.9 are not strings containing four integers. There seems to be an awareness of IPv6 because of the terminology but it is not specifically defined. Therefore additional objects for IPv6 addresses and masks need to be defined. 5.393 RFC 2623 NFS Version 2 and Version 3 Security Issues and the NFS Protocol's Use of RPCSEC_GSS and Kerberos V5 There are no IPv4 dependencies in this protocol. 5.394 RFC 2625 IP and ARP over Fibre Channel This document states: Objective and Scope: The major objective of this specification is to promote interoperable implementations of IPv4 over FC. This specification describes a method for encapsulating IPv4 and Address Resolution Protocol (ARP) packets over FC. Therefore a similar method will need to be defined for IPv6. 5.395 RFC 2630 Cryptographic Message Syntax There are no IPv4 dependencies in this protocol. 5.396 RFC 2631 Diffie-Hellman Key Agreement Method There are no IPv4 dependencies in this protocol. 5.397 RFC 2632 S/MIME Version 3 Certificate Handling There are no IPv4 dependencies in this protocol. 5.398 RFC 2633 S/MIME Version 3 Message Specification There are no IPv4 dependencies in this protocol. 5.399 RFC 2634 Enhanced Security Services for S/MIME There are no IPv4 dependencies in this protocol. 5.400 RFC 2640 Internationalization of the File Transfer Protocol There are no IPv4 dependencies in this protocol. 5.401 RFC 2645 ON-DEMAND MAIL RELAY (ODMR) SMTP with Dynamic IP Addresses (ODMR-SMTP) There are no IPv4 dependencies in this protocol. 5.402 RFC 2646 The Text/Plain Format Parameter There are no IPv4 dependencies in this protocol. 5.403 RFC 2651 The Architecture of the Common Indexing Protocol (CIP) (CIP) There are no IPv4 dependencies in this protocol. 5.404 RFC 2652 MIME Object Definitions for the Common Indexing Protocol (CIP) There are no IPv4 dependencies in this protocol. 5.405 RFC 2653 CIP Transport Protocols There are no IPv4 dependencies in this protocol. 5.406 RFC 2658 RTP Payload Format for PureVoice(tm) Audio There are no IPv4 dependencies in this protocol. 5.407 RFC 2661 Layer Two Tunneling Protocol "L2TP" (L2TP) There are no IPv4 dependencies in this protocol. 5.408 RFC 2662 Definitions of Managed Objects for the ADSL Lines (MIB) There are no IPv4 dependencies in this protocol. 5.409 RFC 2665 Definitions of Managed Objects for the Ethernet-like Interface Types (MIB) There are no IPv4 dependencies in this protocol. 5.410 RFC 2667 IP Tunnel MIB The Abstract of this document says: This memo defines a Management Information Base (MIB) for use with network management protocols in the Internet community. In particular, it describes managed objects used for managing tunnels of any type over IPv4 networks. Extension MIBs may be designed for managing protocol-specific objects. Likewise, extension MIBs may be designed for managing security-specific objects. This MIB does not support tunnels over non-IPv4 networks (including IPv6 networks). Management of such tunnels may be supported by other MIBs. A similar MIB for tunneling over IPv6 should be defined. 5.411 RFC 2668 Definitions of Managed Objects for IEEE 802.3 Medium Attachment Units (MAUs) (MAU-MIB) There are no IPv4 dependencies in this protocol. 5.412 RFC 2669 DOCSIS Cable Device MIB Cable Device Management Information Base for DOCSIS compliant Cable Modems and Cable Modem Termination Systems This document states: Please note that the DOCSIS 1.0 standard only requires Cable Modems to implement SNMPv1 and to process IPv4 customer traffic. Design choices in this MIB reflect those requirements. Future versions of the DOCSIS standard are expected to require support for SNMPv3 and IPv6 as well. 5.413 RFC 2670 Radio Frequency (RF) Interface Management Information Base for MCNS/DOCSIS compliant RF interfaces (MIB) This MIB defines the following OIDs: DocsIfCmtsCmStatusEntry ::= SEQUENCE { docsIfCmtsCmStatusIndex Integer32, docsIfCmtsCmStatusMacAddress MacAddress, docsIfCmtsCmStatusIpAddress IpAddress, docsIfCmtsCmStatusDownChannelIfIndex InterfaceIndexOrZero, docsIfCmtsCmStatusUpChannelIfIndex InterfaceIndexOrZero, docsIfCmtsCmStatusRxPower TenthdBmV, docsIfCmtsCmStatusTimingOffset Unsigned32, docsIfCmtsCmStatusEqualizationData OCTET STRING, docsIfCmtsCmStatusValue INTEGER, docsIfCmtsCmStatusUnerroreds Counter32, docsIfCmtsCmStatusCorrecteds Counter32, docsIfCmtsCmStatusUncorrectables Counter32, docsIfCmtsCmStatusSignalNoise TenthdB, docsIfCmtsCmStatusMicroreflections Integer32 } docsIfCmtsCmStatusIpAddress OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "IP address of this Cable Modem. If the Cable Modem has no IP address assigned, or the IP address is unknown, this object returns a value of 0.0.0.0. If the Cable Modem has multiple IP addresses, this object returns the IP address associated with the Cable interface." ::= { docsIfCmtsCmStatusEntry 3 } IPv6 OIDs should be defined. 5.414 RFC 2671 Extension Mechanisms for DNS (EDNS0) (EDNS0) There are no IPv4 dependencies in this protocol. 5.415 RFC 2672 Non-Terminal DNS Name Redirection This document is only defined for IPv4 addresses. A similar specification for IPv6 addresses should be defined. 5.416 RFC 2673 Binary Labels in the Domain Name System (DNS) This document is only defined for IPv4 addresses. A similar specification for IPv6 addresses should be defined. 5.417 RFC 2674 Definitions of Managed Objects for Bridges with Traffic Classes, Multicast Filtering and Virtual LAN Extensions (MIB) There are no IPv4 dependencies in this protocol. 5.418 RFC 2675 IPv6 Jumbograms This document defines a IPv6 packet format and is therefore not discussed in this document. 5.419 RFC 2677 Definitions of Managed Objects for the NBMA Next Hop Resolution Protocol (NHRP) (NHRP-MIB) There are no IPv4 dependencies in this protocol. 5.420 RFC 2678 IPPM Metrics for Measuring Connectivity (IPPM-MET) This protocol only supports IPv4. An updated protocol for IPv6 will need to be defined. 5.421 RFC 2679 A One-way Delay Metric for IPPM This protocol only supports IPv4. An updated protocol for IPv6 will need to be defined. 5.422 RFC 2680 A One-way Packet Loss Metric for IPPM This protocol only supports IPv4. An updated protocol for IPv6 will need to be defined. 5.423 RFC 2681 A Round-trip Delay Metric for IPPM This protocol only supports IPv4. An updated protocol for IPv6 will need to be defined. 5.424 RFC 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5 There are no IPv4 dependencies in this protocol. 5.425 RFC 2685 Virtual Private Networks Identifier (VPN) There are no IPv4 dependencies in this protocol. 5.426 RFC 2686 The Multi-Class Extension to Multi-Link PPP There are no IPv4 dependencies in this protocol. 5.427 RFC 2687 PPP in a Real-time Oriented HDLC-like Framing There are no IPv4 dependencies in this protocol. 5.428 RFC 2688 Integrated Services Mappings for Low Speed Networks There are no IPv4 dependencies in this protocol. 5.429 RFC 2710 Multicast Listener Discovery (MLD) for IPv6 (MLD-IPv6) This document defines an IPv6 specific protocol and is not discussed in this document. 5.430 RFC 2711 IPv6 Router Alert Option This document defines an IPv6 specific protocol and is not discussed in this document. 5.431 RFC 2712 Addition of Kerberos Cipher Suites to Transport Layer Security (TLS) (TLS) There are no IPv4 dependencies in this protocol. 5.432 RFC 2720 Traffic Flow Measurement: Meter MIB This protocol is both IPv4 and IPv6 aware and needs no changes. 5.433 RFC 2725 Routing Policy System Security There are no IPv4 dependencies in this protocol. 5.434 RFC 2726 PGP Authentication for RIPE Database Updates There are no IPv4 dependencies in this protocol. 5.435 RFC 2728 The Transmission of IP Over the Vertical Blanking Interval of a Television Signal The following data format is defined: 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| group | uncompressed IP header (20 bytes) | +-+-+-+-+-+-+-+-+ + | | : .... : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | uncompressed UDP header (8 bytes) | +-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | payload (<1472 bytes) | +-+-+-+-+-+-+-+-+ + | | : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ This protocol is IPv4 dependent. Updates must be made to support IPv6. 5.436 RFC 2730 Multicast Address Dynamic Client Allocation Protocol (MADCAP) (MADCAP) This protocol is both IPv4 and IPv6 aware and needs no changes. 5.437 RFC 2732 Format for Literal IPv6 Addresses in URL's This document defines an IPv6 specific protocol and is not discussed in this document. 5.438 RFC 2733 An RTP Payload Format for Generic Forward Error Correction This protocol is dependent on SDP which has IPv4 dependencies. Once that limitation is fixed, then this protocol should support IPv6. 5.439 RFC 2734 IPv4 over IEEE 1394 This protocol is IPv4 only. A similar document must be defined for IPv6. 5.440 RFC 2735 NHRP Support for Virtual Private Networks This protocol implies only IPv4 operations, but does not seem to present any reason that it would not function for IPv6. 5.441 RFC 2737 Entity MIB (Version 2) The TAddress Syntax is used in this MIB which contains IPv4 assumptions and need to be updated. entLogicalTAddress OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The transport service address by which the logical entity receives network management traffic, formatted according to the corresponding value of entLogicalTDomain. For snmpUDPDomain, a TAddress is 6 octets long, the initial 4 octets containing the IP-address in network-byte order and the last 2 containing the UDP port in network-byte order. Consult 'Transport Mappings for Version 2 of the Simple Network Management Protocol' (RFC 1906 [RFC1906]) for further information on snmpUDPDomain." 5.442 RFC 2738 Corrections to "A Syntax for Describing Media Feature Sets" There are no IPv4 dependencies in this protocol. 5.443 RFC 2739 Calendar Attributes for vCard and LDAP There are no IPv4 dependencies in this protocol. 5.444 RFC 2740 OSPF for IPv6 This document defines an IPv6 specific protocol and is not discussed in this document. 5.445 RFC 2741 Agent Extensibility (AgentX) Protocol Version 1 (SNMP) This protocol contains definitions for IPv4 only objects, by reference and all examples use only IPv4 addressing. However, there does not seem to be any reason that it could not easily be modified to support IPv6 addresses. 5.446 RFC 2742 Definitions of Managed Objects for Extensible SNMP Agents There are no IPv4 dependencies in this protocol. 5.447 RFC 2743 Generic Security Service Application Program Interface Version 2 Update 1 There are no IPv4 dependencies in this protocol. 5.448 RFC 2744 Generic Security Service API Version 2 : C-bindings There are no IPv4 dependencies in this protocol. 5.449 RFC 2745 RSVP Diagnostic Messages This protocol is both IPv4 and IPv6 aware and needs no changes. 5.450 RFC 2746 RSVP Operation Over IP Tunnels This protocol is both IPv4 and IPv6 aware and needs no changes. 5.451 RFC 2747 RSVP Cryptographic Authentication This protocol is both IPv4 and IPv6 aware and needs no changes. 5.452 RFC 2748 The COPS (Common Open Policy Service) Protocol (COPS) This protocol is both IPv4 and IPv6 aware and needs no changes. 5.453 RFC 2749 COPS usage for RSVP There are no IPv4 dependencies in this protocol. 5.454 RFC 2750 RSVP Extensions for Policy Control There are no IPv4 dependencies in this protocol. 5.455 RFC 2751 Signaled Preemption Priority Policy Element (RSVP) There are no IPv4 dependencies in this protocol. 5.456 RFC 2752 Identity Representation for RSVP There are no IPv4 dependencies in this protocol. 5.457 RFC 2765 Stateless IP/ICMP Translation Algorithm (SIIT) (SIIT) This protocol defines a method for IPv6 transition and is not discussed in this document. 5.458 RFC 2766 Network Address Translation - Protocol Translation (NAT-PT) (NAT-PT) This protocol defines a method for IPv6 transition and is not discussed in this document. 5.459 RFC 2769 Routing Policy System Replication (RPSL) There are no IPv4 dependencies in this protocol. 5.460 RFC 2776 Multicast-Scope Zone Announcement Protocol (MZAP) (MZAP) This protocol is both IPv4 and IPv6 aware and needs no changes. 5.461 RFC 2782 A DNS RR for specifying the location of services (DNS SRV) (DNS-SRV) There are no IPv4 dependencies in this protocol. 5.462 RFC 2784 Generic Routing Encapsulation (GRE) (GRE) This protocol is only defined for IPv4. The document states: o IPv6 as Delivery and/or Payload Protocol This specification describes the intersection of GRE currently deployed by multiple vendors. IPv6 as delivery and/or payload protocol is not included Therefore, a new version must be defined for IPv6. 5.463 RFC 2787 Definitions of Managed Objects for the Virtual Router Redundancy Protocol As stated in the Overview section: Since the VRRP protocol is intended for use with IPv4 routers only, this MIB uses the SYNTAX for IP addresses which is specific to IPv4. Thus, changes will be required for this MIB to interoperate in an IPv6 environment. 5.464 RFC 2788 Network Services Monitoring MIB There are no IPv4 dependencies in this protocol. 5.465 RFC 2789 Mail Monitoring MIB There are no IPv4 dependencies in this protocol. 5.466 RFC 2793 RTP Payload for Text Conversation There are no IPv4 dependencies in this protocol. 5.467 RFC 2794 Mobile IP Network Access Identifier Extension for IPv4 This document defines an IPv4 specific protocol and a similar functionality must be defined for Mobile IPv6. 5.468 RFC 2796 BGP Route Reflection - An Alternative to Full Mesh (IBGP) Although the protocol enhancements have no IPv4 dependencies, it is an update to an IPv4 only routing protocol. It is expected that a newer version of BGP that is IPv6 aware will also implement this enhancement. Conceptually there should be no issues with the protocol operating in and IPv6 aware BGP. 5.469 RFC 2797 Certificate Management Messages over CMS There are no IPv4 dependencies in this protocol. 5.470 RFC 2806 URLs for Telephone Calls There are no IPv4 dependencies in this protocol. 5.471 RFC 2814 SBM (Subnet Bandwidth Manager): A Protocol for RSVP-based Admission Control over IEEE 802-style networks This protocol claims to be both IPv4 and IPv6 aware, but all of the examples are given with IPv4 addresses. That, by itself is not a telling point but the following statement is made: a) LocalDSBMAddrInfo -- current DSBM's IP address (initially, 0.0.0.0) and priority. All IP addresses are assumed to be in network byte order. In addition, current DSBM's L2 address is also stored as part of this state information. which could just be sloppy wording. Perhaps a short document clarifying the text is appropriate. 5.472 RFC 2815 Integrated Service Mappings on IEEE 802 Networks There are no IPv4 dependencies in this protocol. 5.473 RFC 2829 Authentication Methods for LDAP There are no IPv4 dependencies in this protocol. 5.474 RFC 2830 Lightweight Directory Access Protocol (v3): Extension for Transport Layer Security (LDAP) There are no IPv4 dependencies in this protocol. 5.475 RFC 2831 Using Digest Authentication as a SASL Mechanism There are no IPv4 dependencies in this protocol. 5.476 RFC 2833 RTP Payload for DTMF Digits, Telephony Tones and Telephony Signals There are no IPv4 dependencies in this protocol. 5.477 RFC 2834 ARP and IP Broadcast over HIPPI-800 This document uses the generic term "IP Address" in the text but it also contains the text: The HARP message has several fields that have the following format and values: Data sizes and field meaning: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type of the protocol fields below ar$op 16 bits Operation code (request, reply, or NAK) ar$pln 8 bits byte length of each protocol address ar$rhl 8 bits requester's HIPPI hardware address length (q) ar$thl 8 bits target's HIPPI hardware address length (x) ar$rpa 32 bits requester's protocol address ar$tpa 32 bits target's protocol address ar$rha qbytes requester's HIPPI Hardware address ar$tha xbytes target's HIPPI Hardware address Where : ar$hrd - SHALL contain 28. (HIPARP) ar$pro - SHALL contain the IP protocol code 2048 (decimal). ar$op - SHALL contain the operational value (decimal): 1 for HARP_REQUESTs 2 for HARP_REPLYs 8 for InHARP_REQUESTs 9 for InHARP_REPLYs 10 for HARP_NAK ar$pln - SHALL contain 4. and later: 31 28 23 21 15 10 7 2 0 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 0 | 04 |1|0| 000 | 03 | 0 | +---------------+-+-+---------------------+---------------+-----+ 1 | 45 | +-----+-+-------+-----------------------+-----------------------+ 2 |[LA] |W|MsgT= 0| 000 | Dest. Switch Addr | +-----+-+-------+-----------------------+-----------------------+ 3 | 2 | 2 | 000 | Source Switch Addr | +---------------+---------------+-------+-----------------------+ 4 | 00 00 | | +-------------------------------+ | 5 | Destination ULA | +-------------------------------+-------------------------------+ 6 | [LA] | | +-------------------------------+ | 7 | Source ULA | +===============+===============+===============+===============+ 8 | AA | AA | 03 | 00 | +---------------+---------------+---------------+---------------+ 9 | 00 | 00 | Ethertype (2054) | +---------------+---------------+-------------------------------+ 10 | hrd (28) | pro (2048) | +---------------+---------------+---------------+---------------+ 11 | op (ar$op) | pln (6) | rhl (q) | +---------------+---------------+---------------+---------------+ 12 | thl = (x) | Requester IP Address upper (24 bits) | +---------------------------------------------------------------+ 13 | Req. IP lower | Target IP Address upper (24 bits) | +---------------+-----------------------------------------------+ 14 | Tgt. IP lower | Requester HIPPI Hardware Address bytes 0 - 2 | +---------------+-----------------------------------------------+ 15 | Requester HIPPI Hardware Address bytes 3 - 6 | +-----------------------------------------------+---------------+ 16 | Requester HW Address bytes 7 - q | Tgt HW byte 0 | +---------------+---------------+---------------+---------------+ 17 | Target HIPPI Hardware Address bytes 1 - 4 | +---------------------------------------------------------------+ 18 | Target HIPPI Hardware Address bytes 5 - 8 | +---------------+---------------+---------------+---------------+ 19 |Tgt HW byte 9-x| FILL | FILL | FILL | +---------------+---------------+---------------+---------------+ HARP - InHARP Message Which make this protocol only IPv4 aware. An update is required to support IPv6. 5.478 RFC 2835 IP and ARP over HIPPI-6400 (GSN) (GSN) This document states: The Ethertype value SHALL be set as defined in Assigned Numbers [18]: IP 0x0800 2048 (16 bits) This is IPv4 limited and as expected (after reviewing the previous section) requires an update to support IPv6. There are numerous other points in the documents that confirms this assumption. 5.479 RFC 2837 Definitions of Managed Objects for the Fabric Element in Fibre Channel Standard There are no IPv4 dependencies in this protocol. 5.480 RFC 2842 Capabilities Advertisement with BGP-4 Although the protocol enhancements have no IPv4 dependencies, it is an update to an IPv4 only routing protocol. It is expected that a newer version of BGP that is IPv6 aware will also implement this enhancement. Conceptually there should be no issues with the protocol operating in and IPv6 aware BGP. 5.481 RFC 2845 Secret Key Transaction Authentication for DNS (TSIG) (TSIG) There are no IPv4 dependencies in this protocol. 5.482 RFC 2846 GSTN Address Element Extensions in E-mail Services There are no IPv4 dependencies in this protocol. 5.483 RFC 2847 LIPKEY - A Low Infrastructure Public Key Mechanism Using SPKM (LIPKEY) There are no IPv4 dependencies in this protocol. 5.484 RFC 2848 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services This protocol is dependent on SDP & SIP which has IPv4 dependencies. Once these limitations are fixed, then this protocol should support IPv6. 5.485 RFC 2849 The LDAP Data Interchange Format (LDIF) - Technical Specification (LDIF) There are no IPv4 dependencies in this protocol. 5.486 RFC 2851 Textual Conventions for Internet Network Addresses This MIB defines a new set of OIDs for that allow new MIB's to use multiple versions of IP. Currently IPv4 and IPv6 addressing is defined. Update of the many MIBs previously identified as having IPv4 dependencies could easily be updated using this new set of IP address abstractions. 5.487 RFC 2852 Deliver By SMTP Service Extension There are no IPv4 dependencies in this protocol. 5.488 RFC 2853 Generic Security Service API Version 2 : Java Bindings The document uses the InetAddress variable which does not necessarily limit it to IPv4 addresses so there are no IPv4 dependencies in this protocol. 5.489 RFC 2855 DHCP for IEEE 1394 This document is only designated for IPv4. It is expected that similar functionality is available in DHCPv6. 5.490 RFC 2856 Textual Conventions for Additional High Capacity Data Types (SNMP) There are no IPv4 dependencies in this protocol. 5.491 RFC 2857 The Use of HMAC-RIPEMD-160-96 within ESP and AH There are no IPv4 dependencies in this protocol. 5.492 RFC 2858 Multiprotocol Extensions for BGP-4 (MEXT-BGP4) In the Abstract Currently BGP-4 [BGP-4] is capable of carrying routing information only for IPv4 [IPv4]. This document defines extensions to BGP-4 to enable it to carry routing information for multiple Network Layer protocols (e.g., IPv6, IPX, etc...). The extensions are backward compatible - a router that supports the extensions can interoperate with a router that doesn't support the extensions. The document is therefore no examined further in this document. 5.493 RFC 2862 RTP Payload Format for Real-Time Pointers There are no IPv4 dependencies in this protocol. 5.494 RFC 2864 The Inverted Stack Table Extension to the Interfaces Group MIB There are no IPv4 dependencies in this protocol. 5.495 RFC 2872 Application and Sub Application Identity Policy Element for Use with RSVP There are no IPv4 dependencies in this protocol. 5.496 RFC 2873 TCP Processing of the IPv4 Precedence Field This protocol documents a technique using IPv4 headers. A similar technique, if needed, will need to be defined for IPv6. 5.497 RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering This document defines a protocol to interact with IPv6 and is not considered in this document. 5.498 RFC 2875 Diffie-Hellman Proof-of-Possession Algorithms There are no IPv4 dependencies in this protocol. 5.499 RFC 2878 PPP Bridging Control Protocol (BCP) (PPP-BCP) There are no IPv4 dependencies in this protocol. 5.500 RFC 2879 Content Feature Schema for Internet Fax (V2) There are no IPv4 dependencies in this protocol. 5.501 RFC 2883 An Extension to the Selective Acknowledgement (SACK) Option for TCP (SACK) There are no IPv4 dependencies in this protocol. 5.502 RFC 2890 Key and Sequence Number Extensions to GRE There are no IPv4 dependencies in this protocol. 5.503 RFC 2891 LDAP Control Extension for Server Side Sorting of Search Results There are no IPv4 dependencies in this protocol. 5.504 RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers (TRANS-IPV6) This document defines a transition mechanism for IPv6 and is not considered in this document. 5.505 RFC 2894 Router Renumbering for IPv6 This document defines an IPv6 only document and is not concerned in this document. 5.506 RFC 2895 Remote Network Monitoring MIB Protocol Identifier Reference (RMON-MIB) This MIB is both IPv4 and IPv6 aware and needs no changes. 5.507 RFC 2907 MADCAP Multicast Scope Nesting State Option This protocol is both IPv4 and IPv6 aware and needs no changes. 5.508 RFC 2910 Internet Printing Protocol/1.1: Encoding and Transport (IPP-E-T) There are no IPv4 dependencies in this protocol. 5.509 RFC 2911 Internet Printing Protocol/1.1: Model and Semantics (IPP-M-S) There are no IPv4 dependencies in this protocol. 5.510 RFC 2912 Indicating Media Features for MIME Content There are no IPv4 dependencies in this protocol. 5.511 RFC 2913 MIME Content Types in Media Feature Expressions There are no IPv4 dependencies in this protocol. 5.512 RFC 2915 The Naming Authority Pointer (NAPTR) DNS Resource Record (NAPTR) There are no IPv4 dependencies in this protocol. 5.513 RFC 2916 E.164 number and DNS There are no IPv4 dependencies in this protocol. 5.514 RFC 2918 Route Refresh Capability for BGP-4 There are no IPv4 dependencies in this protocol. 5.515 RFC 2919 List-Id: A Structured Field and Namespace for the Identification of Mailing Lists There are no IPv4 dependencies in this protocol. 5.516 RFC 2925 Definitions of Managed Objects for Remote Ping, Traceroute, and Lookup Operations This MIB mostly is IPv4 and IPv6 aware. There are a few assumptions that are problems thought. In the following OIDs: pingCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion to be transmitted in a ping operation in octets. A ping request is usually an ICMP message encoded into an IP packet. An IP packet has a maximum size of 65535 octets. Subtracting the size of the ICMP or UDP header (both 8 octets) and the size of the IP header (20 octets) yields a maximum size of 65507 octets." DEFVAL { 0 } ::= { pingCtlEntry 5 } traceRouteCtlDataSize OBJECT-TYPE SYNTAX Unsigned32 (0..65507) UNITS "octets" MAX-ACCESS read-create STATUS current DESCRIPTION "Specifies the size of the data portion of a traceroute request in octets. A traceroute request is essentially transmitted by encoding a UDP datagram into a IP packet. So subtracting the size of a UDP header (8 octets) and the size of a IP header (20 octets) yields a maximum of 65507 octets." DEFVAL { 0 } ::= { traceRouteCtlEntry 6 } There is clearly an assumption of IPv4 header sizes. 5.517 RFC 2930 Secret Key Establishment for DNS (TKEY RR) (TKEY-RR) There are no IPv4 dependencies in this protocol. 5.518 RFC 2931 DNS Request and Transaction Signatures (SIG(0)s) There are no IPv4 dependencies in this protocol. 5.519 RFC 2932 IPv4 Multicast Routing MIB This protocol is only defined for IPv4 and a similar MIB must be defined for IPv6. 5.520 RFC 2933 Internet Group Management Protocol MIB As stated in this document: Since IGMP is specific to IPv4, this MIB does not support management of equivalent functionality for other address families, such as IPv6. 5.521 RFC 2935 Internet Open Trading Protocol (IOTP) HTTP Supplement (IOTP-HTTP) There are no IPv4 dependencies in this protocol. 5.522 RFC 2937 The Name Service Search Option for DHCP This document is only designated for IPv4. It is expected that similar functionality is available in DHCPv6. 5.523 RFC 2938 Identifying Composite Media Features There are no IPv4 dependencies in this protocol. 5.524 RFC 2940 Definitions of Managed Objects for Common Open Policy Service (COPS) Protocol Clients This MIB is both IPv4 and IPv6 aware and needs no changes. 5.525 RFC 2941 Telnet Authentication Option (TOPT-AUTH) There are no IPv4 dependencies in this protocol. 5.526 RFC 2942 Telnet Authentication: Kerberos Version 5 There are no IPv4 dependencies in this protocol. 5.527 RFC 2943 TELNET Authentication Using DSA There are no IPv4 dependencies in this protocol. 5.528 RFC 2944 Telnet Authentication: SRP There are no IPv4 dependencies in this protocol. 5.529 RFC 2945 The SRP Authentication and Key Exchange System There are no IPv4 dependencies in this protocol. 5.530 RFC 2946 Telnet Data Encryption Option There are no IPv4 dependencies in this protocol. 5.531 RFC 2947 Telnet Encryption: DES3 64 bit Cipher Feedback There are no IPv4 dependencies in this protocol. 5.532 RFC 2948 Telnet Encryption: DES3 64 bit Output Feedback There are no IPv4 dependencies in this protocol. 5.533 RFC 2949 Telnet Encryption: CAST-128 64 bit Output Feedback There are no IPv4 dependencies in this protocol. 5.534 RFC 2950 Telnet Encryption: CAST-128 64 bit Cipher Feedback There are no IPv4 dependencies in this protocol. 5.535 RFC 2954 Definitions of Managed Objects for Frame Relay Service (FR-MIB) There are no IPv4 dependencies in this protocol. 5.536 RFC 2955 Definitions of Managed Objects for Monitoring and Controlling the Frame Relay/ATM PVC Service Interworking Function There are no IPv4 dependencies in this protocol. 5.537 RFC 2959 Real-Time Transport Protocol Management Information Base There are numerous uses of the included TAddress Syntax which is IPv4 dependent as noted above. For example: rtpSessionRemAddr OBJECT-TYPE SYNTAX TAddress MAX-ACCESS read-create STATUS current DESCRIPTION "The address to which RTP packets are sent by the RTP system. In an IP multicast RTP session, this is the single address used by all senders and receivers of RTP session data. In a unicast RTP session this is the unicast address of the remote RTP system. 'The destination address pair may be common for all participants, as in the case of IP multicast, or may be different for each, as in the case of individual unicast network address pairs.' See RFC 1889, 'RTP: A Transport Protocol for Real-Time Applications,' sec. 3. The transport service is identified by rtpSessionDomain. For snmpUDPDomain, this is an IP address and even-numbered UDP Port with the RTCP being sent on the next higher odd-numbered port, see RFC 1889, sec. 5." ::= { rtpSessionEntry 3 } There are a total of 8 instances of this. 5.538 RFC 2960 Stream Control Transmission Protocol This protocol is both IPv4 and IPv6 aware and needs no changes. 5.539 RFC 2961 RSVP Refresh Overhead Reduction Extensions This protocol is both IPv4 and IPv6 aware and needs no changes. 5.540 RFC 2965 HTTP State Management Mechanism This document makes many references to the IP addresses of hosts but has no fundamental reasons why they could not be either IPv4 or IPv6 addresses. 5.541 RFC 2971 IMAP4 ID extension There are no IPv4 dependencies in this protocol. 5.542 RFC 2976 The SIP INFO Method There are no IPv4 dependencies in this protocol. 5.543 RFC 2981 Event MIB There are no IPv4 dependencies in this protocol. 5.544 RFC 2982 Distributed Management Expression MIB There are no IPv4 dependencies in this protocol. 5.545 RFC 2984 Use of the CAST-128 Encryption Algorithm in CMS There are no IPv4 dependencies in this protocol. 5.546 RFC 2987 Registration of Charset and Languages Media Features Tags There are no IPv4 dependencies in this protocol. 5.547 RFC 2988 Computing TCP's Retransmission Timer There are no IPv4 dependencies in this protocol. 5.548 RFC 2996 Format of the RSVP DCLASS Object There are no IPv4 dependencies in this protocol. 5.549 RFC 2997 Specification of the Null Service Type There are no IPv4 dependencies in this protocol. 5.550 RFC 3003 The audio/mpeg Media Type There are no IPv4 dependencies in this protocol. 5.551 RFC 3004 The User Class Option for DHCP This document is only designated for IPv4. It is expected that similar functionality is available in DHCPv6. 5.552 RFC 3006 Integrated Services in the Presence of Compressible Flows This document defines a protocol that discusses compressible flows, but only in an IPv4 context. When IPv6 compressible flows are defined, a similar technique should also be defined. 5.553 RFC 3007 Secure Domain Name System (DNS) Dynamic Update There are no IPv4 dependencies in this protocol. 5.554 RFC 3008 Domain Name System Security (DNSSEC) Signing Authority (DNSSEC) There are no IPv4 dependencies in this protocol. 5.555 RFC 3009 Registration of parityfec MIME types There are no IPv4 dependencies in this protocol. 5.556 RFC 3010 NFS version 4 Protocol (NFSv4) This protocol is both IPv4 and IPv6 aware and needs no changes. 5.557 RFC 3011 The IPv4 Subnet Selection Option for DHCP This document is specifically designed for IPv4. 5.558 RFC 3012 Mobile IPv4 Challenge/Response Extensions This document is specifically designed for IPv4. 5.559 RFC 3014 Notification Log MIB This document contains OIDs that are IPv4 specific: nlmLogVariableIpAddressVal OBJECT-TYPE SYNTAX IpAddress MAX-ACCESS read-only STATUS current DESCRIPTION "The value when nlmLogVariableType is 'ipAddress'. Although this seems to be unfriendly for IPv6, we have to recognize that there are a number of older MIBs that do contain an IPv4 format address, known as IpAddress. IPv6 addresses are represented using TAddress or InetAddress, and so the underlying datatype is OCTET STRING, and their value would be stored in the nlmLogVariableOctetStringVal column." ::= { nlmLogVariableEntry 9 } Not withstanding the note in the DESCRIPTION. 5.560 RFC 3015 Megaco Protocol Version 1.0 (MEGACO) This protocol is both IPv4 and IPv6 aware and needs no changes. 5.561 RFC 3016 RTP Payload Format for MPEG-4 Audio/Visual Streams There are no IPv4 dependencies in this protocol. 5.562 RFC 3017 XML DTD for Roaming Access Phone Book The following 2 sections show an IPv4 limitation. 6.2.1. DNS Server Address The dnsServerAddress element represents the IP address of the Domain Name Service (DNS) server which should be used when connected to this POP. The address is represented in the form of a string in dotted- decimal notation (e.g., 192.168.101.1). Syntax: <!-- Domain Name Server IP address --> <!ELEMENT dnsServerAddress (#PCDATA)> <!ATTLIST dnsServerAddress value NOTATION (IPADR) #IMPLIED> 6.2.9. Default Gateway Address The defaulttGatewayAddress element represents the address of the default gateway which should be used when connected to this POP. The address is represented in the form of a string in dotted-decimal notation (e.g., 192.168.101.1). Syntax: <!-- Default Gateway IP address (in dotted decimal notation) --> <!ELEMENT defaultGatewayAddress (#PCDATA)> <!ATTLIST defaultGatewayAddress value NOTATION (IPADR) #IMPLIED> It should be fairly straightforward to implement elements that are IPv6 aware. 5.563 RFC 3019 IP Version 6 Management Information Base for The Multicast Listener Discovery Protocol This is an IPv6 related document and is not discussed in this document. 5.564 RFC 3020 Definitions of Managed Objects for Monitoring and Controlling the UNI/NNI Multilink Frame Relay Function There are no IPv4 dependencies in this protocol. 5.565 RFC 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links This document is IPv4 specific and a similar technique could also be defined for IPv6. 5.566 RFC 3023 XML Media Types There are no IPv4 dependencies in this protocol. 5.567 RFC 3024 Reverse Tunneling for Mobile IP, revised This protocol assumes IPv4 addressing. An updated Mobile IPv6 specification should include this functionality. 5.568 RFC 3028 Sieve: A Mail Filtering Language There are no IPv4 dependencies in this protocol. 5.569 RFC 3030 SMTP Service Extensions for Transmission of Large and Binary MIME Messages There are no IPv4 dependencies in this protocol. 5.570 RFC 3031 Multiprotocol Label Switching Architecture (MPLS) There are no IPv4 dependencies in this protocol. 5.571 RFC 3032 MPLS Label Stack Encoding This protocol is both IPv4 and IPv6 aware and needs no changes. 5.572 RFC 3033 The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol This protocol is both IPv4 and IPv6 aware and needs no changes. 5.573 RFC 3034 Use of Label Switching on Frame Relay Networks Specification There are no IPv4 dependencies in this protocol. 5.574 RFC 3035 MPLS using LDP and ATM VC Switching There are no IPv4 dependencies in this protocol. 5.575 RFC 3036 LDP Specification This protocol is both IPv4 and IPv6 aware and needs no changes. 5.576 RFC 3038 VCID Notification over ATM link for LDP There are no IPv4 dependencies in this protocol. 5.577 RFC 3039 Internet X.509 Public Key Infrastructure Qualified Certificates Profile There are no IPv4 dependencies in this protocol. 5.578 RFC 3041 Privacy Extensions for Stateless Address Autoconfiguration in IPv6 This is an IPv6 related document and is not discussed in this document. 5.579 RFC 3042 Enhancing TCP's Loss Recovery Using Limited Transmit There are no IPv4 dependencies in this protocol. 5.580 RFC 3046 DHCP Relay Agent Information Option This document is only designated for IPv4. It is expected that similar functionality is available in DHCPv6. 5.581 RFC 3047 RTP Payload Format for ITU-T Recommendation G.722.1 There are no IPv4 dependencies in this protocol. 5.582 RFC 3049 TN3270E Service Location and Session Balancing There are no IPv4 dependencies in this protocol. 5.583 RFC 3055 Management Information Base for the PINT Services Architecture There are no IPv4 dependencies in this protocol. 5.584 RFC 3056 Connection of IPv6 Domains via IPv4 Clouds This is an IPv6 related document and is not discussed in this document. 5.585 RFC 3057 ISDN Q.921-User Adaptation Layer There are no IPv4 dependencies in this protocol. 5.586 RFC 3059 Attribute List Extension for the Service Location Protocol (SLPv2) There are no IPv4 dependencies in this protocol. 5.587 RFC 3060 Policy Core Information Model -- Version 1 Specification (CIM) There are no IPv4 dependencies in this protocol. 5.588 RFC 3062 LDAP Password Modify Extended Operation There are no IPv4 dependencies in this protocol. 5.589 RFC 3065 Autonomous System Confederations for BGP (BGP-ASC) There are no IPv4 dependencies in this protocol. 5.590 RFC 3068 An Anycast Prefix for 6to4 Relay Routers This is an IPv6 related document and is not discussed in this document. 5.591 RFC 3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay (L2TP-FR) There are no IPv4 dependencies in this protocol. 5.592 RFC 3074 DHC Load Balancing Algorithm There are no IPv4 dependencies in this protocol. 5.593 RFC 3075 XML-Signature Syntax and Processing There are no IPv4 dependencies in this protocol. 5.594 RFC 3077 A Link-Layer Tunneling Mechanism for Unidirectional Links This protocol is both IPv4 and IPv6 aware and needs no changes. 5.595 RFC 3080 The Blocks Extensible Exchange Protocol Core (BEEP) There are no IPv4 dependencies in this protocol. 5.596 RFC 3081 Mapping the BEEP Core onto TCP There are no IPv4 dependencies in this protocol. 5.597 RFC 3084 COPS Usage for Policy Provisioning (COPS-PR) (COPS-PR) This is an IPv4 only protocol. A version for IPv6 must be defined. 5.598 RFC 3090 DNS Security Extension Clarification on Zone Status There are no IPv4 dependencies in this protocol. 5.599 RFC 3095 Robust Header Compression (ROHC): Framework and four profiles This protocol is both IPv4 and IPv6 aware and needs no changes. 5.600 RFC 3097 RSVP Cryptographic Authentication -- Updated Message Type Value (RSVP) There are no IPv4 dependencies in this protocol. 5.601 RFC 3107 Carrying Label Information in BGP-4 (SDP) There are no IPv4 dependencies in this protocol. 5.602 RFC 3108 Conventions for the use of the Session Description Protocol (SDP) for ATM Bearer Connections This protocol is currently limited to IPv4 as amplified below: The range and format of the <rtcpPortNum> and <rtcpIPaddr> subparameters is per [1]. The <rtcpPortNum> is a decimal number between 1024 and 65535. It is an odd number. If an even number in this range is specified, the next odd number is used. The <rtcpIPaddr> is expressed in the usual dotted decimal IP address representation, from 0.0.0.0 to 255.255.255.255. and <rtcpIPaddr> IP address for receipt Dotted decimal, 7-15 chars of RTCP packets 5.603 RFC 3110 RSA/SHA-1 SIGs and RSA KEYs in the Domain Name System (DNS) There are no IPv4 dependencies in this protocol. 5.604 RFC 3111 Service Location Protocol Modifications for IPv6 This is an IPv6 related document and is not discussed in this document. 5.605 RFC 3115 Mobile IP Vendor/Organization-Specific Extensions This is an enhancement for Mobile IPv4. It is expected that a similar capability will be in Mobile IPv6. 5.606 RFC 3118 Authentication for DHCP Messages This document is only designated for IPv4. It is expected that similar functionality is available in DHCPv6. 5.607 RFC 3119 A More Loss-Tolerant RTP Payload Format for MP3 Audio There are no IPv4 dependencies in this protocol. 5.608 RFC 3122 Extensions to IPv6 Neighbor Discovery for Inverse Discovery Specification This is an IPv6 related document and is not discussed in this document. 5.609 RFC 3124 The Congestion Manager This document is IPv4 limited since it uses the IPv4 TOS header field. 5.610 RFC 3140 Per Hop Behavior Identification Codes There are no IPv4 dependencies in this protocol. 5.611 RFC 3145 L2TP Disconnect Cause Information There are no IPv4 dependencies in this protocol. 6.0 Experimental RFCs Experimental RFCs typically define protocols that do not have widescale implementation or usage on the Internet. They are often propriety in nature or used in limited arenas. They are documented to the Internet community in order to allow potential interoperability or some other potential useful scenario. In a few cases they are presented as alternatives to the mainstream solution to an acknowledged problem. 6.001 RFC 908 Reliable Data Protocol (RDP) This document is IPv4 limited as stated in the following section: 4.1 IP Header Format When used in the internet environment, RDP segments are sent using the version 4 IP header as described in RFC791, "Internet Protocol." The RDP protocol number is ??? (decimal). The time- to-live field should be set to a reasonable value for the network. All other fields should be set as specified in RFC-791. A new protocol specification would be needed to support IPv6. 6.002 RFC 909 Loader Debugger Protocol (LDP) There are no IPv4 dependencies in this protocol. 6.003 RFC 938 Internet Reliable Transaction Protocol functional and interface specification (IRTP) This protocol specification states: 4.1 State Variables Each IRTP is associated with a single internet address. The synchronization mechanism of the IRTP depends on the requirement that each IRTP module knows the internet addresses of all modules with which it will communicate. For each remote internet address, an IRTP module must maintain the following information (called the connection table): rem_addr (32 bit remote internet address) A new specification that is IPv6 aware would need to be created. 6.004 RFC 998 NETBLT: A bulk data transfer protocol (NETBLT) This RFC states: The active end specifies a passive client through a client-specific "well-known" 16 bit port number on which the passive end listens. The active end identifies itself through a 32 bit Internet address and a unique 16 bit port number. Clearly, this is IPv4 dependent, but could easily be modified to support IPv6 addressing. 6.005 RFC 1004 Distributed-protocol authentication scheme (COOKIE-JAR) There are no IPv4 dependencies in this protocol. 6.006 RFC 1045 VMTP: Versatile Message Transaction Protocol (VMTP) This protocol has many IPv4 dependencies in its implementation appendices. For operations over IPv6 a similar implementation procedure must be defined. The IPv4 specific information is show below. IV.1. Domain 1 For initial use of VMTP, we define the domain with Domain identifier 1 as follows: +-----------+----------------+------------------------+ | TypeFlags | Discriminator | Internet Address | +-----------+----------------+------------------------+ 4 bits 28 bits 32 bits The Internet address is the Internet address of the host on which this entity-id is originally allocated. The Discriminator is an arbitrary value that is unique relative to this Internet host address. In addition, the host must guarantee that this identifier does not get reused for a long period of time after it becomes invalid. ("Invalid" means that no VMTP module considers in bound to an entity.) One technique is to use the lower order bits of a 1 second clock. The clock need not represent real-time but must never be set back after a crash. In a simple implementation, using the low order bits of a clock as the time stamp, the generation of unique identifiers is overall limited to no more than 1 per second on average. The type flags were described in Section 3.1. An entity may migrate between hosts. Thus, an implementation can heuristically use the embedded Internet address to locate an entity but should be prepared to maintain a cache of redirects for migrated entities, plus accept Notify operations indicating that migration has occurred. Entity group identifiers in Domain 1 are structured in one of two forms, depending on whether they are well-known or dynamically allocated identifiers. A well-known entity identifier is structured as: +-----------+----------------+------------------------+ | TypeFlags | Discriminator |Internet Host Group Addr| +-----------+----------------+------------------------+ 4 bits 28 bits 32 bits with the second high-order bit (GRP) set to 1. This form of entity identifier is mapped to the Internet host group address specified in the low-order 32 bits. The Discriminator distinguishes group identifiers using the same Internet host group. Well-known entity group identifiers should be allocated to correspond to the basic services provided by hosts that are members of the group, not specifically because that service is provided by VMTP. For example, the well-known entity group identifier for the domain name service should contain as its embedded Internet host group address the host group for Domain Name servers. A dynamically allocated entity identifier is structured as: +-----------+----------------+------------------------+ | TypeFlags | Discriminator | Internet Host Addr | +-----------+----------------+------------------------+ 4 bits 28 bits 32 bits with the second high-order bit (GRP) set to 1. The Internet address in the low-order 32 bits is a Internet address assigned to the host that dynamically allocates this entity group identifier. A dynamically allocated entity group identifier is mapped to Internet host group address 232.X.X.X where X.X.X are the low-order 24 bits of the Discriminator subfield of the entity group identifier. We use the following notation for Domain 1 entity identifiers <10> and propose it use as a standard convention. <flags>-<discriminator>-<Internet address> where <flags> are [X]{BE,LE,RG,UG}[A] X = reserved BE = big-endian entity LE = little-endian entity RG = restricted group UG = unrestricted group A = alias and <discriminator> is a decimal integer and <Internet address> is in standard dotted decimal IP address notation. V.1. Authentication Domain 1 A principal identifier is structured as follows. +---------------------------+------------------------+ | Internet Address | Local User Identifier | +---------------------------+------------------------+ 32 bits 32 bits VI. IP Implementation VMTP is designed to be implemented on the DoD IP Internet Datagram Protocol (although it may also be implemented as a local network protocol directly in "raw" network packets.) The well-known entity identifiers specified to date are: VMTP_MANAGER_GROUP RG-1-224.0.1.0 Managers for VMTP operations. VMTP_DEFAULT_BECLIENT BE-1-224.0.1.0 Client entity identifier to use when a (big-endian) host has not determined or been allocated any client entity identifiers. VMTP_DEFAULT_LECLIENT LE-1-224.0.1.0 Client entity identifier to use when a (little-endian) host has not determined or been allocated any client entity identifiers. Note that 224.0.1.0 is the host group address assigned to VMTP and to which all VMTP hosts belong. 6.007 RFC 1075 Distance Vector Multicast Routing Protocol (IP-DVMRP) This document defines a protocol for IPv4 multicast routing. A similar mechanism must be defined for IPv6 multicast routing (or the functionality must be included in other "standard" IPv6 routing protocols.) 6.008 RFC 1143 The Q Method of Implementing TELNET Option Negotiation There are no IPv4 dependencies in this protocol. 6.009 RFC 1146 TCP alternate checksum options (TCP-ACO) There are no IPv4 dependencies in this protocol. 6.010 RFC 1149 Standard for the transmission of IP datagrams on avian carriers There are no IPv4 dependencies in this protocol. In fact the flexibility of this protocol is such that all versions of IP should function within its boundaries, presuming that the packets remains small enough to be transmitted with the 256 milligrams weight limitations. 6.011 RFC 1151 Version 2 of the Reliable Data Protocol (RDP) (RDP) There are no IPv4 dependencies in this protocol. 6.012 RFC 1153 Digest message format (DMF-MAIL) There are no IPv4 dependencies in this protocol. 6.013 RFC 1159 Message Send Protocol There are no IPv4 dependencies in this protocol. 6.014 RFC 1165 Network Time Protocol (NTP) over the OSI Remote Operations Service (NTP-OSI) The only dependency is in the implementation Appendix: ClockIdentifier ::= CHOICE { referenceClock[0] PrintableString, inetaddr[1] OCTET STRING, psapaddr[2] OCTET STRING } and depending on the implementation this might not even be an issue. 6.015 RFC 1176 Interactive Mail Access Protocol: Version 2 (IMAP2) There are no IPv4 dependencies in this protocol. 6.016 RFC 1183 New DNS RR Definitions (DNS-RR) There are no IPv4 dependencies in this protocol. 6.017 RFC 1187 Bulk Table Retrieval with the SNMP (SNMP-BULK) There are no IPv4 dependencies in this protocol. 6.018 RFC 1204 Message Posting Protocol (MPP) (MPP) There are no IPv4 dependencies in this protocol. 6.019 RFC 1224 Techniques for managing asynchronously generated alerts (ALERTS) There are no IPv4 dependencies in this protocol. 6.020 RFC 1226 Internet protocol encapsulation of AX.25 frames (IP-AX.25) There are no IPv4 dependencies in this protocol. 6.021 RFC 1235 Coherent File Distribution Protocol (CFDP) This protocol assumes IPv4 multicast, but could be converted to IPv6 multicast with a little effort. The ticket server replies with a "This is Your Ticket" (TIYT) packet containing the ticket. Figure 2 shows the format of this packet. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 'T' | 'I' | 'Y' | 'T' | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | "ticket" | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | BLKSZ (by default 512) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | FILSZ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP address of CFDP server (network order) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | client UDP port# (cfdpcln) | server UDP port# (cfdpsrv) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Fig. 2: "This Is Your Ticket" packet. 6.022 RFC 1238 CLNS MIB for use with Connectionless Network Protocol (ISO 8473) and End System to Intermediate System (ISO 9542) (CLNS-MIB) There are no IPv4 dependencies in this protocol. 6.023 RFC 1241 Scheme for an internet encapsulation protocol: Version 1 (IN-ENCAP) This protocol specifies a protocol that assumes IPv4 but does not actually have any limitations which would limit its operation in an IPv6 environment. 6.024 RFC 1279 X.500 and Domains This protocol specifies a protocol that assumes IPv4 but does not actually have any limitations which would limit its operation in an IPv6 environment. 6.025 RFC 1307 Dynamically Switched Link Control Protocol (DSLCP) This protocol is IPv4 dependent. See: 3.1 Control Message Format 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Total length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Event Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Body | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Endpoint addresses: 32 bits each The internet addresses of the two communicating parties for which the link is being prepared. 6.026 RFC 1312 Message Send Protocol 2 (MSP2) There are no IPv4 dependencies in this protocol. 6.027 RFC 1339 Remote Mail Checking Protocol (RMCP) There are no IPv4 dependencies in this protocol. 6.028 RFC 1383 An Experiment in DNS Based IP Routing (DNS-IP) This proposal is IPv4 limited: This record is designed for easy general purpose extensions in the DNS, and its content is a text string. The RX record will contain three fields: - A record identifier composed of the two characters "RX". This is used to disambiguate from other experimental uses of the "TXT" record. - A cost indicator, encoded on up to 3 numerical digits. The corresponding positive integer value should be less that 256, in order to preserve future evolutions. - An IP address, encoded as a text string following the "dot" notation. The three strings will be separated by a single comma. An example of record would thus be: ___________________________________________________________________ | domain | type | record | value | | - | | | | |*.27.32.192.in-addr.arpa | IP | TXT | RX, 10, 10.0.0.7| |_________________________|________|__________|___________________| which means that for all hosts whose IP address starts by the three octets "192.32.27" the IP host "10.0.0.7" can be used as a gateway, and that the preference value is 10. 6.029 RFC 1393 Traceroute Using an IP Option (TRACE-IP) This document uses an IPv4 option. It is therefore limited to IPv4 networks. A different technique must be developed for IPv6. 6.030 RFC 1411 Telnet Authentication: Kerberos Version 4 (TEL-KER) There are no IPv4 dependencies in this protocol. 6.031 RFC 1412 Telnet Authentication: SPX (TEL-SPX) There are no IPv4 dependencies in this protocol. 6.032 RFC 1433 Directed ARP (DIR-ARP) There are no IPv4 dependencies in this protocol. 6.033 RFC 1440 SIFT/UFT: Sender-Initiated/Unsolicited File Transfer (SIFT) There are no IPv4 dependencies in this protocol. 6.034 RFC 1459 Internet Relay Chat Protocol (IRCP) There are two spots in this document that are limited to IPv4 addressing. 203 RPL_TRACEUNKNOWN "???? <class> [<client IP address in dot form>]" and In specifying hostnames, both domain names and use of the 'dot' notation (127.0.0.1) should both be accepted. It should be relatively simple to add support for IPv6. 6.035 RFC 1464 Using the Domain Name System To Store Arbitrary String Attributes There are no IPv4 dependencies in this protocol. 6.036 RFC 1465 Routing Coordination for X.400 MHS Services Within a Multi Protocol / Multi Network Environment Table Format V3 for Static Routing There are no IPv4 dependencies in this protocol. 6.037 RFC 1475 TP/IX: The Next Internet (TP-IX) This document defines IPv7 and has been abandoned by the IETF as a feasible design. It is not considered in this document. 6.038 RFC 1476 RAP: Internet Route Access Protocol (RAP) This document defines an IPv7 routing protocol and has been abandoned by the IETF as a feasible design. It is not considered in this document. 6.039 RFC 1505 Encoding Header Field for Internet Messages (EHF-MAIL) There are no IPv4 dependencies in this protocol. 6.040 RFC 1507 DASS - Distributed Authentication Security Service (DASS) There are no IPv4 dependencies in this protocol. 6.041 RFC 1528 Principles of Operation for the TPC.INT Subdomain: Remote Printing -- Technical Procedures (REM-PRINT) There are no IPv4 dependencies in this protocol. 6.042 RFC 1561 Use of ISO CLNP in TUBA Environments (CLNP-TUBA) This document defines the use of NSAPA addressing and does not use any version of IP, so there are no IPv4 dependencies in this protocol. 6.043 RFC 1592 Simple Network Management Protocol Distributed Protocol Interface Version 2.0 (SNMP-DPI) There are no IPv4 dependencies in this protocol. 6.044 RFC 1608 Representing IP Information in the X.500 Directory (X500-DIR) There are no IPv4 dependencies in this protocol. 6.045 RFC 1609 Charting Networks in the X.500 Directory (X500-CHART) There are no IPv4 dependencies in this protocol. 6.046 RFC 1639 FTP Operation Over Big Address Records (FOOBAR) (FOOBAR) This document defines a method for overcoming FTP IPv4 limitations and is therefore both IPv4 and IPv6 aware. 6.047 RFC 1641 Using Unicode with MIME (MIME-UNI) There are no IPv4 dependencies in this protocol. 6.048 RFC 1644 T/TCP -- TCP Extensions for Transactions Functional Specification (T/TCP) There are no IPv4 dependencies in this protocol. 6.049 RFC 1693 An Extension to TCP : Partial Order Service (TCP-POS) There are no IPv4 dependencies in this protocol. 6.050 RFC 1712 DNS Encoding of Geographical Location (DNS-ENCODE) There are no IPv4 dependencies in this protocol. 6.051 RFC 1735 NBMA Address Resolution Protocol (NARP) (NARP) This document defines a protocol that is IPv4 specific. A new version would need to be documented to support IPv6. 4. Packet Formats NARP requests and replies are carried in IP packets as protocol type 54. This section describes the packet formats of NARP requests and replies: NARP Request 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Hop Count | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NBMA length | NBMA address | +-+-+-+-+-+-+-+-+ | | (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source and Destination IP Addresses Respectively, these are the IP addresses of the NARP requestor and the target terminal for which the NBMA address is desired. and NARP Reply 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Version | Hop Count | Checksum | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Code | Unused | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Destination IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Source IP address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NBMA length | NBMA address | +-+-+-+-+-+-+-+-+ | | (variable length) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Source and Destination IP Address Respectively, these are the IP addresses of the NARP requestor and the target terminal for which the NBMA address is desired. 6.052 RFC 1756 Remote Write Protocol - Version 1.0 (RWP) There are no IPv4 dependencies in this protocol. 6.053 RFC 1765 OSPF Database Overflow (OSPF-OVFL) There are no IPv4 dependencies in this protocol other than the fact that it is an new functionality for a routing protocol that only supports IPv4 networks. It is assumed that a future update to OSPF to support IPv6 will also support this functionality. 6.054 RFC 1768 Host Group Extensions for CLNP Multicasting (CLNP-MULT) This document defines an IPv9 multicast protocol and has been abandoned by the IETF as a feasible design. It is not considered in this document. 6.055 RFC 1788 ICMP Domain Name Messages (ICMP-DM) This protocol is used for updates to the in-addr.arp reverse DNS maps, and is limited to IPv4. 6.056 RFC 1791 TCP And UDP Over IPX Networks With Fixed Path MTU There are no IPv4 dependencies in this protocol. 6.057 RFC 1792 TCP/IPX Connection Mib Specification (TCP/IPXMIB) There are no IPv4 dependencies in this protocol. 6.058 RFC 1797 Class A Subnet Experiment This document is specific to IPv4. 6.059 RFC 1801 MHS use of the X.500 Directory to support MHS Routing There are no IPv4 dependencies in this protocol. 6.060 RFC 1804 Schema Publishing in X.500 Directory There are no IPv4 dependencies in this protocol. 6.061 RFC 1806 Communicating Presentation Information in Internet Messages: The Content-Disposition Header There are no IPv4 dependencies in this protocol. 6.062 RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+ (ST2) This protocol is IPv4 limited. In fact it is the definition of IPv5. See below. Both ST2 and IP apply the same addressing schemes to identify different hosts. ST2 and IP packets differ in the first four bits, which contain the internetwork protocol version number: number 5 is reserved for ST2 (IP itself has version number 4). As a network layer protocol, like IP, ST2 operates independently of its underlying subnets. Existing implementations use ARP for address resolution, and use the same Layer 2 SAPs as IP. 8.2 Group Name Generator GroupName generation is similar to Stream ID generation. The GroupName includes a 16-bit unique identifier, a 32-bit creation timestamp, and a 32-bit IP address. Group names are globally unique. A GroupName includes the creator's IP address, so this reduces a global uniqueness problem to a simple local problem. IP-encapsulated ST packets begin with a normal IP header. Most fields of the IP header should be filled in according to the same rules that apply to any other IP packet. Three fields of special interest are: o Protocol is 5, see [RFC1700], to indicate an ST packet is enclosed, as opposed to TCP or UDP, for example. and The following permanent IP multicast addresses have been assigned to ST: 224.0.0.7 All ST routers (intermediate agents) 224.0.0.8 All ST hosts (agents) In addition, a block of transient IP multicast addresses, 224.1.0.0 - 224.1.255.255, has been allocated for ST multicast groups. For instance, the following two functions could be made available: The ST Header also includes an ST Version Number, a total length field, a header checksum, a unique id, and the stream origin 32-bit IP address. The unique id and the stream origin 32-bit IP address form the stream id (SID). This is shown in Figure 10. Please refer to Section 10.6 for an explanation of the notation. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ST=5 | Ver=3 |D| Pri | 0 | TotalBytes | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | HeaderChecksum | UniqueID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | OriginIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 10: ST Header o ST is the IP Version Number assigned to identify ST packets. The value for ST is 5. o OriginIPAddress is the second element of the SID. It is the 32-bit IP address of the stream origin, see Section 8.1. 10.3.2 Group The Group parameter (PCode = 2) is an optional argument used to indicate that the stream is a member in the specified group. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode = 2 | PBytes = 16 | GroupUniqueID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GroupCreationTime | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | GroupInitiatorIPAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Relationship | N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 13: Group Parameter o GroupUniqueID, GroupInitiatorIPAddress, and GroupCreationTime together form the GroupName field. They are allocated by the group name generator function, see Section 8.2. GroupUniqueID and GroupCreationTime are implementation specific and have only local definitions. 10.3.3 MulticastAddress The MulticastAddress parameter (PCode = 3) is an optional parameter that is used when using IP encapsulation and setting up an IP multicast group. This parameter is used to communicate the desired IP multicast address to next-hop ST agents that should become members of the group, see Section 8.8. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode = 3 | PBytes = 8 | 0 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IPMulticastAddress | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 15: MulticastAddress o IPMulticastAddress is the 32-bit IP multicast address to be used to receive data packets for the stream. 10.3.5 RecordRoute The RecordRoute parameter (PCode = 5) is used to request that the route between the origin and a target be recorded and delivered to the user application. The ST agent at the origin (or target) including this parameter, has to determine the parameter's length, indicated by the PBytes field. ST agents processing messages containing this parameter add their receiving IP address in the position indicated by the FreeOffset field, space permitting. If no space is available, the parameter is passed unchanged. When included by the origin, all agents between the origin and the target add their IP addresses and this information is made available to the application at the target. When included by the target, all agents between the target and the origin, inclusive, add their IP addresses and this information is made available to the application at the origin. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PCode = 5 | PBytes | 0 | FreeOffset | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ : ... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | IP Address N | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 17: RecordRoute o PBytes is the length of the parameter in bytes. Length is determined by the agent (target or origin) that first introduces the parameter. Once set, the length of the parameter remains unchanged. o FreeOffset indicates the offset, relative to the start of the parameter, for the next IP address to be recorded. When the FreeOffset is greater than, or equal to, PBytes the RecordRoute parameter is full. o IP Address is filled in, space permitting, by each ST agent processing this parameter. 10.3.6 Target and TargetList Several control messages use a parameter called TargetList (PCode = 6), which contains information about the targets to which the message pertains. For each Target in the TargetList, the information includes the 32-bit IP address of the target, the SAP applicable to the next higher layer protocol, and the length of the SAP (SAPBytes). Consequently, a Target structure can be of variable length. Each entry has the format shown in Figure 18. 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Target IP Address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | TargetBytes | SAPBytes | SAP : Padding | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 18: Target There are many other examples, but it does not serve any purpose to include them all. 6.063 RFC 1845 SMTP Service Extension for Checkpoint/Restart There are no IPv4 dependencies in this protocol. 6.064 RFC 1846 SMTP 521 Reply Code There are no IPv4 dependencies in this protocol. 6.065 RFC 1851 The ESP Triple DES Transform (ESP3DES) There are no IPv4 dependencies in this protocol. 6.066 RFC 1863 A BGP/IDRP Route Server alternative to a full mesh routing (BGP-IDRP) This protocol is both IPv4 and IPv6 aware and needs no changes. 6.067 RFC 1868 ARP Extension - UNARP (UNARP) This protocol specifies IPv4 ARP. It is expected that a similar method should be implemented in IPv6. 6.068 RFC 1873 Message/External-Body Content-ID Access Type (CONT-MT) There are no IPv4 dependencies in this protocol. 6.069 RFC 1874 SGML Media Types (SGML-MT) There are no IPv4 dependencies in this protocol. 6.070 RFC 1876 A Means for Expressing Location Information in the Domain Name System (DNS-LOC) This document defines a methodology for applying this technology which is IPv4 dependent. The protocol itself has no IPv4 dependencies. 6.071 RFC 1888 OSI NSAPs and IPv6 This is an IPv6 related document and is not discussed in this document. 6.072 RFC 1901 Introduction to Community-based SNMPv2 (SNMPV2CB) There are no IPv4 dependencies in this protocol. 6.073 RFC 1909 An Administrative Infrastructure for SNMPv2 (SNMPV2AI) There are no IPv4 dependencies in this protocol. 6.074 RFC 1910 User-based Security Model for SNMPv2 (SNMPV2SM) There are no IPv4 dependencies in this protocol. 6.075 RFC 1949 Scalable Multicast Key Distribution (SMKD) This protocol assumes the use of IGMP and is therefore limited to IPv4 multicast. It is assumed that a similar mechanism may be defined for IPv6 multicasting. 6.076 RFC 1966 BGP Route Reflection An alternative to full mesh IBGP (BGP-RR) Although the protocol enhancements have no IPv4 dependencies, it is an update to an IPv4 only routing protocol. It is expected that a newer version of BGP that is IPv6 aware will also implement this enhancement. Conceptually there should be no issues with the protocol operating in and IPv6 aware BGP. 6.077 RFC 1986 Experiments with a Simple File Transfer Protocol for Radio Links using Enhanced Trivial File Transfer Protocol (ETFTP) (ETFTP) This protocol is IPv4 dependent. See below: Table 3: ETFTP Data Encapsulation +------------+------------+------------+------------+-----------+ |Ethernet(14)| | |ETFTP/ | | |SLIP(2) |IP(20) |UDP(8) |NETBLT(24) |DATA(1448) | |AX.25(20) | | | | | +------------+------------+------------+------------+-----------+ 6.078 RFC 2009 GPS-Based Addressing and Routing (GPS-AR) The document states: The future version of IP (IP v6) will certainly have a sufficient number of bits in its addressing space to provide an address for even smaller GPS addressable units. In this proposal, however, we assume the current version of IP (IP v4) and we make sure that we manage the addressing space more economically than that. We will call the smallest GPS addressable unit a GPS-square. 6.079 RFC 2016 Uniform Resource Agents (URAs) (URAS) There are no IPv4 dependencies in this protocol. 6.080 RFC 2066 TELNET CHARSET Option (TOPT-CHARS) There are no IPv4 dependencies in this protocol. 6.081 RFC 2075 IP Echo Host Service (IP-Echo) There are no IPv4 dependencies in this protocol. 6.082 RFC 2090 TFTP Multicast Option (TFTP-MULTI) This protocol is limited to IPv4 multicast. It is expected that a similar functionality could be implemented on top of IPv6 multicast. 6.083 RFC 2093 Group Key Management Protocol (GKMP) Specification (GKMP-SPEC) There are no IPv4 dependencies in this protocol. 6.084 RFC 2094 Group Key Management Protocol (GKMP) Architecture (GKMP-ARCH) There are no IPv4 dependencies in this protocol. 6.085 RFC 2120 Managing the X.500 Root Naming Context (X.500-NAME) There are no IPv4 dependencies in this protocol. 6.086 RFC 2143 Encapsulating IP with the Small Computer System Interface (IP-SCSI) This protocol will only operate using IPv4. As stated in the document: It was decided that the ten byte header offers the greatest flexibility for encapsulating version 4 IP datagrams for the following reasons: 6.087 RFC 2154 OSPF with Digital Signatures (OSPF-DIG) This OSPF option is IPv4 limited. See the following packet format: 7.2. Router Public Key Certificate A router public key certificate is a package of data signed by a Trusted Entity. This certificate is included in the router PKLSA and in the router configuration information. To change any of the values in the certificate, a new certificate must be obtained from a TE. 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 +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | Router Id | +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | TE Id | TE Key Id | Rtr Key Id | Sig Alg | +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | Create Time | +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | Key Field Length | Router Role | #Net Ranges | +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | IP Address | +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | Address Mask | +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | IP Address/Address Mask for each Net Range ... / | ... / +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | Router Public Key | +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ | Certification / +-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-*-+-+-+-+-+-+-+-+ #NET RANGES The number of network ranges that follow. A network range is defined to be an IP Address and an Address Mask. This list of ranges defines the addresses that the Router is permitted to advertise in its Router Links LSA. Valid values are 0-255. If there are 0 ranges the router cannot advertise anything. This is not generally useful. One range with address=0 and mask=0 will allow a router to advertise any address. IP ADDRESS & ADDRESS MASK Define a range of addresses that this router may advertise. Each is a 32 bit value. One range with address=0 and mask=0 will allow a router to advertise any address. 6.088 RFC 2161 A MIME Body Part for ODA (MIME-ODA) There are no IPv4 dependencies in this protocol. 6.089 RFC 2162 MaXIM-11 - Mapping between X.400 / Internet mail and Mail-11 mail (MAP-MAIL) There are no IPv4 dependencies in this protocol. 6.090 RFC 2168 Resolution of Uniform Resource Identifiers using the Domain Name System There are no IPv4 dependencies in this protocol. 6.091 RFC 2169 A Trivial Convention for using HTTP in URN Resolution There are no IPv4 dependencies in this protocol. 6.092 RFC 2189 Core Based Trees (CBT version 2) Multicast Routing This document specifies a protocol that depends on IPv4 multicast. It is expected that it could easily be updated to support IPv6 multicasting. 7.3. JOIN_REQUEST Packet Format 0 1 2 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 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CBT Control Packet Header | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | group address | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | target router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | originating router | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | option type | option len | option value | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 3. JOIN_REQUEST Packet Format JOIN_REQUEST Field Definitions o group address: multicast group address of the group being joined. For a "wildcard" join (see [5]), this field contains the value of INADDR_ANY. o target router: target (core) router for the group. o originating router: router that originated this JOIN_REQUEST. There are many other packet formats defined in the document that show this limitation as well. 6.093 RFC 2201 Core Based Trees (CBT) Multicast Routing Architecture See previous section for the IPv4 limitation in this protocol. 6.094 RFC 2217 Telnet Com Port Control Option (TOPT-COMPO) There are no IPv4 dependencies in this protocol. 6.095 RFC 2295 Transparent Content Negotiation in HTTP (TCN-HTTP) There are no IPv4 dependencies in this protocol. 6.096 RFC 2296 HTTP Remote Variant Selection Algorithm -- RVSA/1.0 (HTTP-RVSA) There are no IPv4 dependencies in this protocol. 6.097 RFC 2307 An Approach for Using LDAP as a Network Information Service (LDAP-NIS) This protocol assumes IPv4 addressing in its schema. As is: ( nisSchema.1.19 NAME 'ipHostNumber' DESC 'IP address as a dotted decimal, eg. 192.168.1.1, omitting leading zeros' EQUALITY caseIgnoreIA5Match SYNTAX 'IA5String{128}' ) ( nisSchema.1.20 NAME 'ipNetworkNumber' DESC 'IP network as a dotted decimal, eg. 192.168, omitting leading zeros' EQUALITY caseIgnoreIA5Match SYNTAX 'IA5String{128}' SINGLE-VALUE ) ( nisSchema.1.21 NAME 'ipNetmaskNumber' DESC 'IP netmask as a dotted decimal, eg. 255.255.255.0, omitting leading zeros' EQUALITY caseIgnoreIA5Match SYNTAX 'IA5String{128}' SINGLE-VALUE ) The document does try to provide some IPv6 support as in: Hosts with IPv6 addresses MUST be written in their "preferred" form as defined in section 2.2.1 of [RFC1884], such that all components of the address are indicated and leading zeros are omitted. This provides a consistent means of resolving ipHosts by address. but the format defines has been replaced and it is no longer valid. 6.098 RFC 2310 The Safe Response Header Field There are no IPv4 dependencies in this protocol. 6.099 RFC 2337 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM This protocol is designed for IPv4 multicast and a new mechanism must be defined for IPv6 multicasting. 6.100 RFC 2343 RTP Payload Format for Bundled MPEG (RTP-MPEG) There are no IPv4 dependencies in this protocol. 6.101 RFC 2345 Domain Names and Company Name Retrieval There are no IPv4 dependencies in this protocol. 6.102 RFC 2362 Protocol Independent Multicast-Sparse Mode (PIM-SM): Protocol Specification (PIM-SM) This protocol is both IPv4 and IPv6 aware and needs no changes. 6.103 RFC 2414 Increasing TCP's Initial Window (TCP-WIN) There are no IPv4 dependencies in this protocol. 6.104 RFC 2443 A Distributed MARS Service Using SCSP (MARS-SCSP) This document gives default values for use on IPv4 networks, but is designed to be extensible so it will work with IPv6 with appropriate IANA definitions. 6.105 RFC 2471 IPv6 Testing Address Allocation This is an IPv6 related document and is not discussed in this document. 6.106 RFC 2481 A Proposal to add Explicit Congestion Notification (ECN) to IP (ECN-IP) This protocol is both IPv4 and IPv6 aware and needs no changes. 6.107 RFC 2483 URI Resolution Services Necessary for URN Resolution There are no IPv4 dependencies in this protocol. 6.108 RFC 2520 NHRP with Mobile NHCs (NHRP-MNHCS) This protocol is both IPv4 and IPv6 aware and needs no changes. 6.109 RFC 2521 ICMP Security Failures Messages (ICMP-SEC) There are no IPv4 dependencies in this protocol. 6.110 RFC 2522 Photuris: Session-Key Management Protocol (PHOTURIS-S) There are no IPv4 dependencies in this protocol. 6.111 RFC 2523 Photuris: Extended Schemes and Attributes (PHOTURIS-E) There are no IPv4 dependencies in this protocol. 6.112 RFC 2540 Detached Domain Name System (DNS) Information (DNS-INFO) There are no IPv4 dependencies in this protocol. 6.113 RFC 2567 Design Goals for an Internet Printing Protocol (IPP-DG) There are no IPv4 dependencies in this protocol. 6.114 RFC 2568 Rationale for the Structure of the Model and Protocol for the Internet Printing Protocol (IPP-RAT) There are no IPv4 dependencies in this protocol. 6.115 RFC 2569 Mapping between LPD and IPP Protocols There are no IPv4 dependencies in this protocol. 6.116 RFC 2582 The NewReno Modification to TCP's Fast Recovery Algorithm There are no IPv4 dependencies in this protocol. 6.117 RFC 2593 Script MIB Extensibility Protocol Version 1.0 There are no IPv4 dependencies in this protocol. 6.118 RFC 2649 An LDAP Control and Schema for Holding Operation Signatures There are no IPv4 dependencies in this protocol. 6.119 RFC 2654 A Tagged Index Object for use in the Common Indexing Protocol There are no IPv4 dependencies in this protocol. 6.120 RFC 2655 CIP Index Object Format for SOIF Objects There are no IPv4 dependencies in this protocol. 6.121 RFC 2656 Registration Procedures for SOIF Template Types There are no IPv4 dependencies in this protocol. 6.122 RFC 2657 LDAPv2 Client vs. the Index Mesh There are no IPv4 dependencies in this protocol. 6.123 RFC 2659 Security Extensions For HTML There are no IPv4 dependencies in this protocol. 6.124 RFC 2660 The Secure HyperText Transfer Protocol There are no IPv4 dependencies in this protocol. 6.125 RFC 2676 QoS Routing Mechanisms and OSPF Extensions There are IPv4 dependencies in this protocol. IT requires the use of the IPv4 TOS header field. It is assumed that a future update to OSPF to support IPv6 will also support this functionality. 6.126 RFC 2692 SPKI Requirements There are no IPv4 dependencies in this protocol. 6.127 RFC 2693 SPKI Certificate Theory There are no IPv4 dependencies in this protocol. 6.128 RFC 2716 PPP EAP TLS Authentication Protocol There are no IPv4 dependencies in this protocol. 6.129 RFC 2724 RTFM: New Attributes for Traffic Flow Measurement There are no IPv4 dependencies in this protocol. 6.130 RFC 2756 Hyper Text Caching Protocol (HTCP/0.0) (HTCP) This protocol claims to be aware of both IPv4 & IPv6 addresses but it does make the following statement: SIGNATURE is a COUNTSTR [3.1] which holds the HMAC-MD5 digest (see [RFC 2104]), with a B value of 64, of the following elements, each of which is digested in its "on the wire" format, including transmitted padding if any is covered by a field's associated LENGTH: IP SRC ADDR [4 octets] IP SRC PORT [2 octets] IP DST ADDR [4 octets] IP DST PORT [2 octets] HTCP MAJOR version number [1 octet] HTCP MINOR version number [1 octet] SIG-TIME [4 octets] SIG-EXPIRE [4 octets] HTCP DATA [variable] KEY-NAME (the whole COUNTSTR [3.1]) [variable] This SIGNATURE calculation should be expanded to support IPv6 16 byte addresses. 6.131 RFC 2758 Definitions of Managed Objects for Service Level Agreements Performance Monitoring This protocol is both IPv4 and IPv6 aware and needs no changes. 6.132 RFC 2762 Sampling of the Group Membership in RTP This protocol is IPv4 limited. It is also reliant on the underlying assumptions of RTP which is also IPv4 specific. 6.133 RFC 2770 GLOP Addressing in 233/8 This document is specific to IPv4. 6.134 RFC 2773 Encryption using KEA and SKIPJACK This protocol is both IPv4 and IPv6 aware and needs no changes. 6.135 RFC 2774 An HTTP Extension Framework There are no IPv4 dependencies in this protocol. 6.136 RFC 2786 Diffie-Helman USM Key Management Information Base and Textual Convention There are no IPv4 dependencies in this protocol. 6.137 RFC 2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing (PPP-SDL) There are no IPv4 dependencies in this protocol. 6.138 RFC 2844 OSPF over ATM and Proxy-PAR There are numerous IPv4 dependencies in this protocol as well as the fact that it is for a routing protocol that only supports IPv4 networks. It is assumed that a future update to OSPF to support IPv6 will also support this functionality. 6.139 RFC 2859 A Time Sliding Window Three Colour Marker (TSWTCM) (TSWTCM) This protocol is both IPv4 and IPv6 aware and needs no changes. 6.140 RFC 2861 TCP Congestion Window Validation This protocol is both IPv4 and IPv6 aware and needs no changes. 6.141 RFC 2903 Generic AAA Architecture There are no IPv4 dependencies in this protocol. 6.142 RFC 2909 The Multicast Address-Set Claim (MASC) Protocol (MASC) This protocol is both IPv4 and IPv6 aware and needs no changes. 6.143 RFC 2934 Protocol Independent Multicast MIB for IPv4 This document is specific to IPv4. 6.144 RFC 2974 Session Announcement Protocol (SAP) This protocol is both IPv4 and IPv6 aware and needs no changes. 6.145 RFC 3018 Unified Memory Space Protocol Specification This protocol seems to be extensible to support IPv6 but only has definitions for IPv4 addresses in this specification. 6.146 RFC 3029 Internet X.509 Public Key Infrastructure Data Validation and Certification Server Protocols There are no IPv4 dependencies in this protocol. 6.147 RFC 3063 MPLS Loop Prevention Mechanism There are no IPv4 dependencies in this protocol. 6.148 RFC 3082 Notification and Subscription for SLP This protocol is both IPv4 and IPv6 aware and needs no changes. 6.149 RFC 3088 OpenLDAP Root Service An experimental LDAP referral service >From the document: The service supports LDAPv3 and LDAPv2+ [LDAPv2+] clients over TCP/IPv4. Future incarnations of this service may support TCP/IPv6 or other transport/internet protocols. 6.150 RFC 3123 A DNS RR Type for Lists of Address Prefixes (APL RR) This protocol is both IPv4 and IPv6 aware and needs no changes. 7.0 Summary of Results In the initial survey of RFCs 177 positives were identified, broken down as follows: Standards 26 or 38.25% Draft Standards 19 or 29.23% Proposed Standards 110 or 17.94% Experimental RFCs 23 or 20.13% Of those identified many require no action because they document outdated and unused protocols (see STD 44/RFC 891 in Section 3.44 for example), while others are document protocols that are actively being updated by the appropriate working groups (SNMP MIBs for example). Additionally there are many instances of standards that SHOULD be updated but do not cause any operational impact (STD 3/RFCs 1122 & 1123 for example) if they are not updated. The remaining instances are documented below. The author has attempted to organize the results in a format that allows easy reference to other protocol designers. The following recommendations uses the documented terms "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" described in RFC 2119. They should only be interpreted in the context of RFC 2119 when they appear in all caps. That is, the word "should" in the previous SHOULD NOT be interpreted as in RFC 2119. The assignment of these terms has been based entirely on the authors perceived needs for updates and should not be taken as an official statement. 7.1 Standards 7.1.1 STD3 Requirements for Internet Hosts (RFC 1122 & 1123) RFC 1122 is essentially a requirements document for IPv4 hosts and a similar document for IPv6 hosts SHOULD be written. RFC 1123 SHOULD be updated to include advances in application protocols, as well as tightening language regarding IP addressing. 7.1.2 STD 4 Router Requirements (RFC 1812) RFC 1812 SHOULD be updated to include IPv6 Routing Requirements (once they are finalized) 7.1.3 STD 5 Internet Protocol (RFC 791, 922, 792, & 1122) RFC 791 has been updated in the definition of IPv6 in RFC 2460. RFC 922 has been included in the IPv6 Addressing Architecture, RFC 2373. RFC 792 has been updated in the definition of ICMPv6 in RFC 2463. RFC 1122 has been updated in the definition of Multicast Listener Discovery in RFC 2710. 7.1.4 STD 7 Transmission Control Protocol (RFC 793) Section 3.1 defines the technique for computing the TCP checksum that uses the 32 bit source and destination IPv4 addresses. This problem is addressed in RFC 2460 Section 8.1. 7.1.5 STD 9 File Transfer Protocol (RFC 959) Problems have been fixed in RFC 2428 FTP Extensions for IPv6 and NATs 7.1.6 STD 10 Simple Mail Transfer Protocol (RFC 821) The use of literal IP addresses as part of email addresses (i.e. phil@10.10.10.10) is depreciated and therefore no additional specifications for using literal IPv6 addresses SHOULD NOT be defined. 7.1.7 STD 11 Standard for the format of ARPA Internet Text Messages RFC 822 See the above section (7.1.6). 7.1.8 STD 12 Network Time Protocol (RFC 1305) As documented in Section 3.12 above, there are many specific steps that assume the use of 32-bit IPv4 addresses. An updated specification to support NTP over IPv6 packets MUST be created. 7.1.9 STD 13 Domain Name System (RFCs 1034 & 1035) New resource records for IPv6 addresses have been defined (AAAA & A6). 7.1.10 STD 15 Simple Network Management Protocol (RFCs 1157, 1155, 1213) The limitations identified have been addressed. 7.1.11 STD 19 Netbios over TCP/UDP (RFCs 1001 & 1002) These two RFCs have many inherent IPv4 assumptions and a new set of protocols MUST be defined. 7.1.12 STD 35 ISO Transport over TCP (RFC 1006) This problem has been fixed in RFC 2126, ISO Transport Service on top of TCP. 7.1.13 STD 36 IP and ARP over FDDI (RFC 1390) This problem has been fixed by RFC2467, A Method for the Transmission of IPv6 Packets over FDDI Networks. 7.1.14 STD 41 IP over Ethernet (RFC 894) This problem has been fixed by RFC2464, A Method for the Transmission of IPv6 Packets over Ethernet Networks. 7.1.15 STD 42 IP over Experimental Ethernets (RFC 895) See above section. 7.1.16 STD 43 IP over IEEE 8.02 (RFC 1042) The functionality of this RFC is included in subsequent standards defining IPv6 over XXX. 7.1.17 STD 44 DCN Networks (RFC 891) This protocol is no longer used and an updated protocol SHOULD NOT be created. 7.1.18 STD 45 IP over HyperChannel (RFC 1044) No updated document exists for this protocol. It is unclear whether one is needed. An updated protocol MAY be created. 7.1.19 STD 46 IP over Arcnet (RFC 1201) This problem has been fixed by RFC 2497, A Method for the Transmission of IPv6 Packets over ARCnet Networks. 7.1.20 STD 48 IP over Netbios (RFC 1088) A new protocol specification for tunneling IPv6 packets through Netbios networks SHOULD be defined. 7.1.21 STD 49 802.2 Over IPX (RFC 1132) This protocol specification is not tightly defined and it can easily be updated to tighten the language and explicitly include IPv6 packets. Since it defines a generic way of tunneling many protocols over IPX networks and the large installed base of IPX networks, an updated RFC SHOULD be written. 7.1.22 STD 52 IP over SMDS (RFC 1209) An updated protocol for the transmission of IPv6 packets over SMDS MUST be written. 7.1.23 STD 54 OSPF (RFC 2328) This problem has been fixed by RFC 2740, OSPF for IPv6. 7.1.24 STD 56 RIPv2 (RFC 2453) This problem has been fixed by RFC 2080, RIPng for IPv6. 7.2 Draft Standards 7.2.1 Boot Protocol (RFC 951) This problem has been fixed in the DHCPv6 and Auto Configuration protocols of IPv6: RFC 2462: IPv6 Stateless Address Autoconfiguration, and Dynamic Host Configuration Protocol for IPv6 (DHCPv6) currently an Internet Draft. 7.2.2 IP over FDDI (RFC 1188) See Section 7.1.13. 7.2.3 Path MTU Discovery (RFC 1191) This problem has been fixed in RFC 1981, Path MTU Discovery for IP version 6. 7.2.4 Network Time Protocol (RFC 1305) See Section 7.1.8. 7.2.5 Multiprotocol Interconnect on X.25 and ISDN in the Packet Mode (RFC 1356) This problem can be fixed by defining a new NLPID for IPv6. 7.2.6 BGP4 MIB (RFC 1657) This problem is currently being addressed by the Inter Domain Routing (IDR) WG and an ID exists (draft-ietf-idr-bgp4-mib-09.txt). 7.2.7 SMDS MIB (RFC 1694) See Section 7.1.22. Once a specification for IPv6 over SMDS is created a new MIB MUST be defined. 7.2.8 RIPv2 MIB (RFC 1724) See Section 7.1.24. This problem is currently being addressed by the RIP WG and an ID exists (draft-ietf-rip-mib-01.txt). 7.2.9 Border Gateway Protocol 4 (RFC 1771) This problem has been fixed in RFC2283, Multiprotocol Extensions for BGP-4. 7.2.10 OSPFv2 MIB (RFC 1850) This problem is currently being addressed by the OSPF WG and an ID exists (draft-ietf-ospf-ospfv3-mib-04.txt). 7.2.11 Transport MIB (RFC 1906) The problem has been fixed in RFC 2454, IPv6 Management Information Base for the User Datagram Protocol. 7.2.12 The PPP Multilink Protocol (RFC 1990) A new class identifier for IPv6 packets MUST be registered with the IANA. It is RECOMMENDED that the (currently unassigned) value of 6 be assigned by the IANA with a description of "Internet Protocol (IPv6) Address." An application for this assignment has been sent to the IANA. 7.2.13 IP over HIPPI (RFC 2067) An updated protocol for the transmission of IPv6 packets over HIPPI MAY be written. 7.2.14 Frame Relay MIB (RFC 2115) The problem has been fixed in RFC 2954, Definitions of Managed Objects for Frame Relay Service. 7.2.15 DHCP (RFC 2131) The problems are being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 7.2.16 DHCP Options (RFC 2132) The problems are being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 7.2.17 URI (RFC 2396) URI's allow the literal use of IPv4 addresses but have no specific recommendations on how to represent literal IPv6 addresses. This problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. 7.2.18 HTTP (RFC 2616) HTTP allows the literal use of IPv4 addresses but have no specific recommendations on how to represent literal IPv6 addresses. This problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. 7.2.19 RADIUS (RFC 2865) The problems have been resolved in RFC 3162, RADIUS and IPv6. 7.3 Proposed Standards 7.3.1 Telnet Terminal LOC (RFC 946) There is a dependency in the definition of the TTYLOC Number which would require an updated version of the protocol. However, since this functionality is of marginal value today, a newer version MAY be created. 7.3.2 TCP/IP Header Compression over Slow Serial Links (RFC 1144) This problem has been resolved in RFC2508, Compressing IP/UDP/RTP Headers for Low-Speed Serial Links. See also RFC 2507 & RFC 2509. 7.3.3 IS-IS (RFC 1195) This problem is being addressed by the IS-IS WG and a ID is currently available (draft-ietf-isis-ipv6-02.txt) 7.3.4 Tunneling IPX over IP (RFC 1234) This problem remains unresolved and a new protocol specification MUST be created. 7.3.5 ICMP Router Discovery (RFC 1256) This problem has been resolved in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6) 7.3.6 Encoding Net Addresses to Support Operation Over Non OSI Lower Layers (RFC 1277) This problem is unresolved, but it MAY be resolved with the creation of a new encoding scheme definition. 7.3.7 PPP Internet Protocol Control Protocol (RFC 1332) This problem has been resolved in RFC 2472, IP Version 6 over PPP. 7.3.8 Applicability Statement for OSPFv2 (RFC 1370) This problem has been resolved in RFC 2740, OSPF for IPv6. 7.3.9 MIB for Multiprotocol Interconnect over X.25 (RFC 1461) This problem has not been addressed. A new specification SHOULD be created. 7.3.10 IP Multicast over Token Ring (RFC 1469) The functionality of this specification has been essentially covered in RFC 2470, IPv6 over Token Ring in section 8. 7.3.11 PPP IPCP MIB (RFC 1473) There is no updated MIB to cover the problems outlined. A new MIB MUST be defined. 7.3.12 Applicability of CIDR (RFC 1517) The contents of this specification has been treated in various IPv6 addressing architecture RFCS. See RFC 2373 & 2374. 7.3.13 CIDR Architecture (RFC 1518) The contents of this specification has been treated in various IPv6 addressing architecture RFCS. See RFC 2373 & 2374. 7.3.14 RIP Extensions for Demand Circuits (RFC 1582) This problem has been addressed in RFC 2080, RIPng for IPv6. 7.3.15 OSPF Multicast Extensions (RFC 1584) This functionality has been covered in RFC 2740, OSPF for IPv6. 7.3.16 OSPF NSSA Option (RFC 1587) This functionality has been covered in RFC 2740, OSPF for IPv6. 7.3.17 DNS Server MIB (RFC 1611) The problems have not been addressed and a new MIB MUST be defined. 7.3.18 DNS Resolver MIB (RFC 1612) The problems have not been addressed and a new MIB MUST be defined. 7.3.19 Uniform Resource Locators (RFC 1738) This problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. 7.3.20 Appletalk MIB (RFC 1742) The problems have not been addressed and a new MIB SHOULD be defined. 7.3.21 BGP4/IDRP OSPF Interaction (RFC 1745) The problems are addressed in the combination of RFC2283, Multiprotocol Extensions for BGP-4 and RFC 2740, OSPF for IPv6. 7.3.22 OSPF For Demand Circuits (RFC 1793) This functionality has been covered in RFC 2740, OSPF for IPv6. 7.3.23 IPv4 Router Requirements (RFC 1812) See Section 7.1.2. 7.3.24 ONC RPC v2 (RFC 1833) The problems can be resolved with a definition of the NC_INET6 protocol family. 7.3.25 RTP (RFC 1889) A modification of the algorithm defined in A.7 to support both IPv4 and IPv6 addresses SHOULD be defined. 7.3.26 IP Mobility Support (RFC 2002) The problems are being resolved by the Mobile IP WG and there is a mature ID (draft-ietf-mobileip-ipv6-15.txt) 7.3.27 IP Encapsulation within IP (RFC 2003) This functionality for Mobile IPv6 is accomplished using the Routing Header as defined in RFC 2460, Internet Protocol, Version 6 (IPv6) Specification. 7.3.28 Minimal Encapsulation within IP (RFC 2004) See Section 7.3.27 7.3.29 Applicability Statement for IP Mobility Support (2005) See Section 7.3.26 7.3.30 The Definitions of Managed Objects for IP Mobility Support using SMIv2 (RFC 2006) The problems are being resolved by the Mobile IP WG and there is an ID (draft-ietf-mobileip-rfc2006bis-00.txt) 7.3.31 SMIv2 MIB IP (RFC 2011) The problems have been addressed in RFC 2851, Textual Conventions for Internet Network Addresses, and RFC 2465, Management Information Base for IP Version 6: Textual Conventions and General Group. 7.3.32 SNMPv2 MIB TCP (RFC 2012) The problems have been addressed in RFC 2452, IPv6 Management Information Base for the Transmission Control Protocol. 7.3.33 SNMPv2 MIB UDP (RFC 2013) The problems have been addressed in RFC 2454, IPv6 Management Information Base for the User Datagram Protocol. 7.3.34 RMON MIB (RFC 2021) The problems have been addressed in RFC 2819, Remote Network Monitoring Management Information Base. 7.3.35 Support for Multicast over UNI 3.0/3.1 based ATM Networks (RFC 2022) The problems MUST be addressed in a new protocol. 7.3.36 DataLink Switching using SMIv2 MIB (RFC 2022) The problems have not been addressed and a new MIB SHOULD be defined. 7.3.37 RIPv2 MD5 Authentication (RFC 2082) This functionality has been assumed by the use of the IPsec AH header as defined in RFC 1826, IP Authentication Header. 7.3.38 RIP Triggered Extensions for Demand Circuits (RFC 2091) This functionality is provided in RFC 2080, RIPng for IPv6. 7.3.39 IP Forwarding Table MIB (RFC 2096) This issue is being worked on by the IPv6 WG and an ID exists to address this (draft-ietf-ipngwg-rfc2096-update-00.txt) 7.3.40 IP Router Alert Option (RFC 2113) The problems identified are resolved in RFC 2711, IPv6 Router Alert Option. 7.3.41 SLP (RFC 2165) The problems have been addressed in RFC 3111, Service Location Protocol Modifications for IPv6. 7.3.42 Classical IP & ARP over ATM (RFC 2225) The problems have been resolved in RFC 2492, IPv6 over ATM Networks. 7.3.43 IP Broadcast over ATM (RFC 2226) The problems have been resolved in RFC 2492, IPv6 over ATM Networks. 7.3.44 IGMPv2 (RFC 2236) The problems have been resolved in RFC 2710, Multicast Listener Discovery (MLD) for IPv6. 7.3.45 DHCP Options for NDS (RFC 2241) The problems are being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 7.3.46 Netware/IP Domain Name and Information (RFC 2242) The problems are being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 7.3.47 Mobile IPv4 Comfit Options for PPP IPCP (RFC 2290) The problems are not being addressed and MUST be addressed in a new protocol. 7.3.48 Classical IP & ARP over ATM MIB (RFC 2320) The problems identified are not addressed and a new MIB MUST be defined. 7.3.49 RTSP (RFC 2326) Problem has been acknowledged by the RTSP developer group and will be addressed in the move from Proposed to Draft Standard. This problem is also addressed in RFC 2732, IPv6 Literal Addresses in URL's. 7.3.50 SDP (RFC 2327) One problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. The other problem can be addressed with a minor textual clarification. This MUST be done if the document is to transition from Proposed to Draft. 7.3.51 VRRP (RFC 2338) The problems identified are being addressed by the VRRP WG and there is an ID (draft-ietf-vrrp-ipv6-spec-02.txt). 7.3.53 OSPF Opaque LSA Option (RFC 2370) This problem has been fixed by RFC 2740, OSPF for IPv6. 7.3.54 Transaction IP v3 (RFC 2371) The problems identified are not addressed and a new standard MAY be defined. 7.3.55 POP3 URL Scheme (RFC 2384) The problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. 7.3.56 Protection of BGP via TCP MD5 Signatures (RFC 2385) These issues are addressed via using BGP4 plus RFC 2283, Multiprotocol Extensions for BGP-4. 7.3.57 Multicast over UNI 3.0/3.1 ATM MIB (RFC 2417) The problems identified are not addressed and a new MIB MUST be defined. 7.3.58 BGP Route Flap Dampening (RFC 2439) These issues are addressed via using BGP4 plus RFC 2283, Multiprotocol Extensions for BGP-4. 7.3.59 DHCP Option for Open Group User Authentication Protocol (RFC 2485) The problems are being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 7.3.60 ATM MIB (RFC 2515) The problems identified are not addressed and a new MIB MUST be defined. 7.3.61 SIP (RFC 2543) One problem is addressed in RFC 2732, IPv6 Literal Addresses in URL's. The other problem is being addressed by the SIP WG and many IDs exist correcting the remaining problems. 7.3.62 TN3270 MIB (RFC 2562) The problems identified are not addressed and a new MIB MAY be defined. 7.3.63 DHCP Option to Disable Stateless Autoconfiguration (RFC 2563) The problems are being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 7.3.64 Application MIB (RFC 2564) The problems identified are not addressed and a new MIB MAY be defined. 7.3.65 Coexistence of SNMP v1, v2, & v3 (RFC 2576) There are no real issues that can be resolved. 7.3.66 Definitions of Managed Objects for APPN/HPR in IP Networks (RFC 2584) The problems identified are not addressed and a new MIB MAY be defined. 7.3.67 SLP v2 (RFC 2608) The problems have been addressed in RFC 3111, Service Location Protocol Modifications for IPv6. 7.3.68 RADIUS MIB (RFC 2618) The problems have not been addressed and a new MIB SHOULD be defined. 7.3.69 RADIUS Authentication Server MIB (RFC 2619) The problems have not been addressed and a new MIB SHOULD be defined. 7.3.70 RPSL (RFC 2622) Additional objects MUST be defined for IPv6 addresses and prefixes. 7.3.71 IP & ARP Over FibreChannel (RFC 2625) A new standard MUST be defined to fix these problems. 7.3.72 IPv4 Tunnel MIB (RFC 2667) The problems have not been addressed and a new MIB SHOULD be defined. 7.3.73 DOCSIS MIB (RFC 2669) This problem is currently being addressed by the IPCDN WG and an ID is available (draft-ietf-ipcdn-device-mibv2-01.txt). 7.3.74 RF MIB For DOCSIS (RFC 2670) This problem is currently being addressed by the IPCDN WG and an ID is available (draft-ietf-ipcdn-docs-rfmibv2-01.txt). 7.3.75 Non-Terminal DNS Redirection (RFC 2672) The problems have not been addressed and a new specification MAY be defined. 7.3.76 Binary Labels in DNS (RFC 2673) The problems have not been addressed and a new specification MAY be defined. 7.3.77 IPPM Metrics (RFC 2678) The IPPM WG is working to resolve these issues. 7.3.78 IPPM One Way Delay Metric for IPPM (RFC 2679) The IPPM WG is working to resolve these issues. An ID is available (draft-ietf-ippm-owdp-03.txt). 7.3.79 IPPM One Way Packet Loss Metric for IPPM (RFC 2680) The IPPM WG is working to resolve these issues. 7.3.80 Round Trip Delay Metric for IPPM (RFC 2681) The IPPM WG is working to resolve these issues. 7.3.81 IP over Vertical Blanking Interval of a TV Signal (RFC 2728) The problems have not been addressed and a new specification MAY be defined. 7.3.82 IPv4 over IEEE 1394 (RFC 2734) This problem is being addressed by the IPv6 WG and an ID exists (draft-ietf-ipngwg-ipngwg-1394-02.txt). 7.3.83 Entity MIB Version 2 (RFC 2737) The problems have not been addressed and a new MIB SHOULD be defined. 7.3.84 AgentX Protocol V1 (RFC 2741) The problems have not been addressed and a new protocol MAY be defined. 7.3.85 GRE (RFC 2784) The problems have not been addressed and a new protocol SHOULD be defined. 7.3.86 VRRP MIB (RFC 2787) The problems have not been addressed and a new MIB SHOULD be defined. 7.3.87 Mobile IP Network Access Identity Extensions for IPv4 (RFC 2794) The problems are not being addressed and MUST be addressed in a new protocol. 7.3.88 BGP Route Reflector (RFC 2796) These issues are addressed via using BGP4 plus RFC 2283, Multiprotocol Extensions for BGP-4. 7.3.89 ARP & IP Broadcasts Over HIPPI 800 (RFC 2834) The problems are not being addressed and MAY be addressed in a new protocol. 7.3.90 ARP & IP Broadcasts Over HIPPI 6400 (RFC 2835) The problems are not being addressed and MAY be addressed in a new protocol. 7.3.91 Capabilities Advertisement in BGP4 (RFC 2842) These issues are addressed via using BGP4 plus RFC 2283, Multiprotocol Extensions for BGP-4. 7.3.92 The PINT Service Protocol: Extensions to SIP and SDP for IP Access to Telephone Call Services(RFC 2848) This protocol is dependent on SDP & SIP which has IPv4 dependencies. Once these limitations are fixed, then this protocol should support IPv6. 7.3.93 DHCP for IEEE 1394 (RFC 2855) This problem is being dually addressed by the IPv6 and DHC WGs and IDs exists that address this issue. 7.3.94 TCP Processing of the IPv4 Precedence Field (RFC 2873) The problems are not being addressed and MAY be addressed in a new protocol. 7.3.95 MIB For Traceroute, Pings and Lookups (RFC 2925) The problems have not been addressed and a new MIB MAY be defined. 7.3.96 IPv4 Multicast Routing MIB (RFC 2932) This problem is currently being addressed by the IDR WG and several IDs exist. 7.3.97 IGMP MIB (RFC 2933) This problem is currently being addressed by the IDR WG. 7.3.98 DHCP Name Server Search Option (RFC 2937) The problem is being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 7.3.99 DHCP User Class Option (RFC 3004) The problem is being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 7.3.99 Integrated Services in the Presence of Compressible Flows (RFC 3006) This document defines a protocol that discusses compressible flows, but only in an IPv4 context. When IPv6 compressible flows are defined, a similar technique should also be defined. 7.3.100 IPv4 Subnet Selection DHCP Option (RFC 3011) The problem is being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 7.3.101 Mobile IPv4 Challenge Response Extension (RFC 3012) The problems are not being addressed and MUST be addressed in a new protocol. 7.3.102 XML DTP For Roaming Access Phone Books (RFC 3017) Extensions SHOULD be defined to support IPv6 addresses. 7.3.103 Using 31-Bit Prefixes for IPv4 P2P Links (RFC 3021) No action is needed. 7.3.104 Reverse Tunneling for Mobile IP (RFC 3024) The problems are not being addressed and MUST be addressed in a new protocol. 7.3.105 DHCP Relay Agent Information Option (RFC 3046) The problem is being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 7.3.106 SDP For ATM Bearer Connections (RFC 3108) The problems are not being addressed and SHOULD be addressed in a new protocol. 7.3.107 Mobile IP Vender/Organization Specific Extensions (RFC 3115) The problems are not being addressed and MUST be addressed in a new protocol. 7.3.108 Authentication for DHCP Messages (RFC 3118) The problem is being fixed by the work of the DHC WG. Several very advanced IDs address all the issues. 7.3.109 The Congestion Manager (RFC 3124) An update to this document can be simply define the use of the IPv6 Traffic Class field since it is defined to be exactly the same as the IPv4 TOS field. 7.4 Experimental RFCs 7.4.1 Reliable Data Protocol (RFC 908) This protocol relies on IPv4 and a new protocol standard MAY be produced. 7.4.2 Internet Reliable Transaction Protocol functional and interface specification (RFC 938) This protocol relies on IPv4 and a new protocol standard MAY be produced. 7.4.3 NETBLT: A bulk data transfer protocol (RFC 998) This protocol relies on IPv4 and a new protocol standard MAY be produced. 7.4.4 VMTP: Versatile Message Transaction Protocol (RFC 1045) This protocol relies on IPv4 and a new protocol standard MAY be produced. 7.4.5 Distance Vector Multicast Routing Protocol (RFC 1075) This protocol is a routing protocol for IPv4 multicast routing. It is no longer in use and SHOULD NOT be redefined. 7.4.6 Distance Vector Multicast Routing Protocol (RFC 1235) This protocol relies on IPv4 and a new protocol standard SHOULD NOT be produced. 7.4.7 Dynamically Switched Link Control Protocol (RFC 1307) This protocol relies on IPv4 and a new protocol standard SHOULD NOT be produced. 7.4.8 An Experiment in DNS Based IP Routing (RFC 1383) This protocol relies on IPv4 DNS RR and a new protocol standard SHOULD NOT be produced. 7.4.9 Traceroute using an IP Option (RFC 1393) This protocol relies on IPv4 and a new protocol standard MAY be produced. 7.4.10 IRC Protocol (RFC 1459) This protocol relies on IPv4 and a new protocol standard SHOULD be produced. 7.4.11 NBMA ARP (RFC 1735) This functionality has been defined in RFC 2491, IPv6 over Non-Broadcast Multiple Access (NBMA) networks and RFC 2332, NBMA Next Hop Resolution Protocol. 7.4.12 ST2+ Protocol (RFC 1819) This protocol relies on IPv4 and a new protocol standard MAY be produced. 7.4.13 ARP Extensions (RFC 1868) This protocol relies on IPv4 and a new protocol standard MAY be produced. 7.4.14 Scalable Multicast Key Distribution (RFC 1949) This protocol relies on IPv4 IGMP Multicast and a new protocol standard MAY be produced. 7.4.15 Simple File Transfer Using Enhanced TFTP (RFC 1968) This protocol relies on IPv4 and a new protocol standard MAY be produced. 7.4.16 TFTP Multicast Option (RFC 2090) This protocol relies on IPv4 IGMP Multicast and a new protocol standard MAY be produced. 7.4.17 IP Over SCSI (RFC 2143) This protocol relies on IPv4 and a new protocol standard MAY be produced. 7.4.18 Core Based Trees (CBT version 2) Multicast Routing (RFC 2189) This protocol relies on IPv4 IGMP Multicast and a new protocol standard MAY be produced. 7.4.19 Using LDAP as a NIS (RFC 2307) This document tries to provide IPv6 support but it relies on an outdated format for IPv6 addresses. A new specification MAY be produced. 7.4.20 Intra-LIS IP multicast among routers over ATM using Sparse Mode PIM (RFC 2337) This protocol relies on IPv4 IGMP Multicast and a new protocol standard MAY be produced. 7.4.21 QoS Routing Mechanisms and OSPF Extensions (RFC 2676) An update to this document can be simply define the use of the IPv6 Traffic Class field since it is defined to be exactly the same as the IPv4 TOS field. 7.4.22 OSPF over ATM and Proxy-PAR (RFC 2844 This protocol relies on IPv4 and a new protocol standard MAY be produced. 7.4.23 Protocol Independent Multicast MIB for IPv4 (RFC 2934) The problems have not been addressed and a new MIB SHOULD be defined. 8.0 Discussion of "Long Term" Stability of Addresses on Protocols In attempting this analysis it was determined that a full scale analysis is well beyond the scope of this document. Instead a short discussion is presented on how such a framework might be established. A suggested approach would be to do an analysis of protocols based on their overall function, similar (but not strictly) to the OSI network reference model. It might be more appropriate to frame the discussion in terms of the different Areas of the IETF. The problem is fundamental to the overall architecture of the Internet and its future. One of the stated goals of the IPng (now IPv6) was "automatic" and "easy" address renumbering. An additional goal is "stateless autoconfiguration." To these ends, a substantial amount of work has gone into the development of such protocols as DHCP and Dynamic DNS. This goes against the Internet age-old "end-to-end principle." Most protocol designs implicitly count on certain underlying principles that currently exist in the network. For example, the design of packet switched networks allows upper level protocols to ignore the underlying stability of packet routes. When paths change in the network, the higher level protocols are typically unaware and uncaring. This works well since whether the packet goes A-B-C-D-E-F or A-B-X-Y-Z-E-F is of little consequence. In a world where endpoints (i.e. A and F in the example above) change at a "rapid" rate, a new model for protocol developers should be considered. It seems that a logical development would be a change in the operation of the Transport layer protocols. The current model is essentially a choice between TCP and UDP, Neither of these protocols provides any mechanism for an orderly handoff of the connection if and when the network endpoint (IP) addresses changes. Perhaps a third major transport layer protocol should be developed, or perhaps updated TCP & UDP specifications that include this function might be a better solution. There are many, many variables that would need to go into a successful development of such a protocol. Some issues to consider are: timing principles; overlap periods as an endpoint moves from address A, to addresses A & B (answers to both), to only B; delays due to the recalculation of routing paths, etc... Appendix A: Cross-reference of RFC Numbers and Location in Document RFC Section ------------------- RFC 698 5.001 RFC 726 5.002 RFC 727 5.003 RFC 735 5.004 RFC 736 5.005 RFC 749 5.006 RFC 768 3.06 RFC 779 5.007 RFC 791 3.05 RFC 793 3.07 RFC 821 3.10.1 RFC 822 3.11 RFC 826 3.37 RFC 854 3.08.1 RFC 855 3.08.2 RFC 856 3.27 RFC 857 3.28 RFC 858 3.29 RFC 859 3.30 RFC 860 3.31 RFC 861 3.32 RFC 862 3.20 RFC 863 3.21 RFC 864 3.22 RFC 865 3.23 RFC 866 3.24 RFC 867 3.25 RFC 868 3.26 RFC 885 5.008 RFC 891 3.44 RFC 894 3.41 RFC 895 3.42 RFC 903 3.38 RFC 904 3.18 RFC 908 6.001 RFC 909 6.002 RFC 927 5.009 RFC 933 5.010 RFC 938 6.003 RFC 946 5.011 RFC 951 4.01 RFC 954 4.02 RFC 959 3.09 RFC 974 3.14 RFC 977 5.012 RFC 998 6.004 RFC 1004 6.005 RFC 1006 3.35 RFC 1009 3.04 RFC 1034 3.13.1 RFC 1035 3.13.2 RFC 1041 5.013 RFC 1042 3.43 RFC 1043 5.014 RFC 1044 3.45 RFC 1045 6.006 RFC 1053 5.015 RFC 1055 3.47 RFC 1058 3.34 RFC 1073 5.016 RFC 1075 6.007 RFC 1079 5.017 RFC 1088 3.48 RFC 1091 5.018 RFC 1096 5.019 RFC 1122 3.03.1 RFC 1123 3.03.2 RFC 1132 3.49 RFC 1143 6.008 RFC 1144 5.020 RFC 1146 6.009 RFC 1149 6.010 RFC 1151 6.011 RFC 1153 6.012 RFC 1155 3.16 RFC 1157 3.15 RFC 1159 6.013 RFC 1165 6.014 RFC 1176 6.015 RFC 1183 6.016 RFC 1184 4.03 RFC 1187 6.017 RFC 1188 4.04 RFC 1191 4.05 RFC 1195 5.021 RFC 1201 3.46 RFC 1204 6.018 RFC 1209 3.52 RFC 1213 3.17 RFC 1221 3.40 RFC 1224 6.019 RFC 1226 6.020 RFC 1234 5.022 RFC 1235 6.021 RFC 1238 6.022 RFC 1239 5.023 RFC 1241 6.023 RFC 1256 5.024 RFC 1269 5.025 RFC 1274 5.026 RFC 1276 5.027 RFC 1277 5.028 RFC 1279 6.024 RFC 1285 5.029 RFC 1288 4.06 RFC 1305 3.12 RFC 1305 4.07 RFC 1307 6.025 RFC 1312 6.026 RFC 1314 5.030 RFC 1323 5.031 RFC 1328 5.032 RFC 1332 5.033 RFC 1339 6.027 RFC 1350 3.33 RFC 1356 4.08 RFC 1370 5.034 RFC 1372 5.035 RFC 1377 5.036 RFC 1378 5.037 RFC 1381 5.038 RFC 1382 5.039 RFC 1383 6.028 RFC 1390 3.36 RFC 1393 6.029 RFC 1397 5.040 RFC 1403 5.041 RFC 1411 6.030 RFC 1412 6.031 RFC 1413 5.042 RFC 1414 5.043 RFC 1415 5.044 RFC 1418 5.045 RFC 1419 5.046 RFC 1420 5.047 RFC 1421 5.048 RFC 1422 5.049 RFC 1423 5.050 RFC 1424 5.051 RFC 1433 6.032 RFC 1440 6.033 RFC 1441 5.052 RFC 1459 6.034 RFC 1461 5.053 RFC 1464 6.035 RFC 1465 6.036 RFC 1469 5.054 RFC 1471 5.055 RFC 1472 5.056 RFC 1473 5.057 RFC 1474 5.058 RFC 1475 6.037 RFC 1476 6.038 RFC 1478 5.059 RFC 1479 5.060 RFC 1493 4.09 RFC 1494 5.061 RFC 1496 5.062 RFC 1502 5.063 RFC 1505 6.039 RFC 1507 6.040 RFC 1510 5.064 RFC 1512 5.065 RFC 1513 5.066 RFC 1515 5.067 RFC 1517 5.068 RFC 1518 5.069 RFC 1519 5.070 RFC 1525 5.071 RFC 1528 6.041 RFC 1534 4.10 RFC 1542 4.11 RFC 1552 5.072 RFC 1553 5.073 RFC 1559 4.12 RFC 1561 6.042 RFC 1570 5.074 RFC 1572 5.075 RFC 1575 4.13 RFC 1582 5.076 RFC 1584 5.077 RFC 1587 5.078 RFC 1592 6.043 RFC 1598 5.079 RFC 1608 6.044 RFC 1609 6.045 RFC 1611 5.080 RFC 1612 5.081 RFC 1618 5.082 RFC 1628 5.083 RFC 1629 4.14 RFC 1639 6.046 RFC 1641 6.047 RFC 1643 3.50 RFC 1644 6.048 RFC 1648 5.084 RFC 1652 4.15 RFC 1657 4.16 RFC 1658 4.17 RFC 1659 4.18 RFC 1660 4.19 RFC 1661 3.51.1 RFC 1662 3.51.2 RFC 1663 5.085 RFC 1666 5.086 RFC 1692 5.087 RFC 1693 6.049 RFC 1694 4.20 RFC 1696 5.088 RFC 1697 5.089 RFC 1700 3.02 RFC 1712 6.050 RFC 1722 3.57 RFC 1724 4.21 RFC 1731 5.090 RFC 1734 5.091 RFC 1735 6.051 RFC 1738 5.092 RFC 1740 5.093 RFC 1742 5.094 RFC 1745 5.095 RFC 1747 5.096 RFC 1748 4.22 RFC 1749 5.097 RFC 1752 5.098 RFC 1755 5.099 RFC 1756 6.052 RFC 1759 5.100 RFC 1762 4.23 RFC 1763 5.101 RFC 1764 5.102 RFC 1765 6.053 RFC 1767 5.103 RFC 1768 6.054 RFC 1771 4.24 RFC 1772 4.25 RFC 1777 4.26 RFC 1778 4.27 RFC 1781 5.104 RFC 1788 6.055 RFC 1791 6.056 RFC 1792 6.057 RFC 1793 5.105 RFC 1797 6.058 RFC 1798 5.106 RFC 1801 6.059 RFC 1804 6.060 RFC 1806 6.061 RFC 1808 5.107 RFC 1812 5.108 RFC 1819 6.062 RFC 1828 5.109 RFC 1829 5.110 RFC 1831 5.111 RFC 1832 4.28 RFC 1833 5.112 RFC 1835 5.113 RFC 1845 6.063 RFC 1846 6.064 RFC 1847 5.114 RFC 1848 5.115 RFC 1850 4.29 RFC 1851 6.065 RFC 1863 6.066 RFC 1864 4.30 RFC 1868 6.067 RFC 1869 3.10.2 RFC 1873 6.068 RFC 1874 6.069 RFC 1876 6.070 RFC 1886 5.116 RFC 1888 6.071 RFC 1889 5.117 RFC 1890 5.118 RFC 1891 5.119 RFC 1892 5.120 RFC 1893 5.121 RFC 1894 5.122 RFC 1901 6.072 RFC 1905 4.31 RFC 1906 4.32 RFC 1907 4.33 RFC 1909 6.073 RFC 1910 6.074 RFC 1913 5.123 RFC 1914 5.124 RFC 1928 5.125 RFC 1929 5.126 RFC 1939 3.53 RFC 1949 6.075 RFC 1961 5.127 RFC 1962 5.128 RFC 1964 5.129 RFC 1966 6.076 RFC 1968 5.130 RFC 1973 5.131 RFC 1981 5.132 RFC 1982 5.133 RFC 1985 5.134 RFC 1986 6.077 RFC 1989 4.34 RFC 1990 4.35 RFC 1994 4.36 RFC 1995 5.135 RFC 1996 5.136 RFC 1997 5.137 RFC 2002 5.138 RFC 2003 5.139 RFC 2004 5.140 RFC 2005 5.141 RFC 2006 5.142 RFC 2009 6.078 RFC 2011 5.143 RFC 2012 5.144 RFC 2013 5.145 RFC 2015 5.146 RFC 2016 6.079 RFC 2017 5.147 RFC 2018 5.148 RFC 2020 5.149 RFC 2021 5.150 RFC 2022 5.151 RFC 2024 5.152 RFC 2025 5.153 RFC 2029 5.154 RFC 2032 5.155 RFC 2034 5.156 RFC 2043 5.157 RFC 2045 4.37 RFC 2046 4.38 RFC 2047 4.39 RFC 2049 4.40 RFC 2051 5.158 RFC 2056 5.159 RFC 2060 5.160 RFC 2066 6.080 RFC 2067 4.41 RFC 2075 6.081 RFC 2077 5.161 RFC 2079 5.162 RFC 2080 5.163 RFC 2082 5.164 RFC 2085 5.165 RFC 2086 5.166 RFC 2087 5.167 RFC 2088 5.168 RFC 2090 6.082 RFC 2091 5.169 RFC 2093 6.083 RFC 2094 6.084 RFC 2096 5.170 RFC 2097 5.171 RFC 2108 5.172 RFC 2113 5.173 RFC 2115 4.42 RFC 2120 6.085 RFC 2122 5.174 RFC 2125 5.175 RFC 2126 5.176 RFC 2127 5.177 RFC 2128 5.178 RFC 2131 4.43 RFC 2132 4.44 RFC 2136 5.179 RFC 2141 5.180 RFC 2142 5.181 RFC 2143 6.086 RFC 2154 6.087 RFC 2156 5.182 RFC 2157 5.183 RFC 2158 5.184 RFC 2159 5.185 RFC 2160 5.186 RFC 2161 6.088 RFC 2162 6.089 RFC 2163 5.187 RFC 2164 5.188 RFC 2165 5.189 RFC 2168 6.090 RFC 2169 6.091 RFC 2177 5.190 RFC 2181 5.191 RFC 2183 5.192 RFC 2189 6.092 RFC 2190 5.193 RFC 2192 5.194 RFC 2193 5.195 RFC 2195 5.196 RFC 2198 5.197 RFC 2201 6.093 RFC 2203 5.198 RFC 2205 5.199 RFC 2206 5.200 RFC 2207 5.201 RFC 2210 5.202 RFC 2211 5.203 RFC 2212 5.204 RFC 2213 5.205 RFC 2214 5.206 RFC 2215 5.207 RFC 2217 6.094 RFC 2218 5.208 RFC 2221 5.209 RFC 2222 5.210 RFC 2225 5.211 RFC 2226 5.212 RFC 2227 5.213 RFC 2228 5.214 RFC 2231 5.215 RFC 2232 5.216 RFC 2234 5.217 RFC 2236 5.218 RFC 2238 5.219 RFC 2241 5.220 RFC 2242 5.221 RFC 2243 5.222 RFC 2244 5.223 RFC 2245 5.224 RFC 2246 5.225 RFC 2247 5.226 RFC 2250 5.227 RFC 2251 5.228 RFC 2252 5.229 RFC 2253 5.230 RFC 2254 5.231 RFC 2255 5.232 RFC 2256 5.233 RFC 2266 5.234 RFC 2279 4.45 RFC 2284 5.235 RFC 2287 5.236 RFC 2289 3.61 RFC 2290 5.237 RFC 2293 5.238 RFC 2294 5.239 RFC 2295 6.095 RFC 2296 6.096 RFC 2298 5.240 RFC 2301 5.241 RFC 2302 5.242 RFC 2303 5.243 RFC 2304 5.244 RFC 2305 5.245 RFC 2307 6.097 RFC 2308 5.246 RFC 2310 6.098 RFC 2320 5.247 RFC 2326 5.248 RFC 2327 5.249 RFC 2328 3.54 RFC 2331 5.250 RFC 2332 5.251 RFC 2333 5.252 RFC 2334 5.253 RFC 2335 5.254 RFC 2337 6.099 RFC 2338 5.255 RFC 2342 5.256 RFC 2343 6.100 RFC 2345 6.101 RFC 2347 4.46 RFC 2348 4.47 RFC 2349 4.48 RFC 2355 4.49 RFC 2359 5.257 RFC 2362 6.102 RFC 2363 5.258 RFC 2364 5.259 RFC 2368 5.260 RFC 2369 5.261 RFC 2370 5.262 RFC 2371 5.263 RFC 2373 5.264 RFC 2374 5.265 RFC 2380 5.266 RFC 2381 5.267 RFC 2384 5.268 RFC 2385 5.269 RFC 2387 5.270 RFC 2388 5.271 RFC 2389 5.272 RFC 2390 4.50 RFC 2392 5.273 RFC 2393 5.274 RFC 2396 4.51 RFC 2397 5.275 RFC 2401 5.276 RFC 2402 5.277 RFC 2403 5.278 RFC 2404 5.279 RFC 2405 5.280 RFC 2406 5.281 RFC 2407 5.282 RFC 2408 5.283 RFC 2409 5.284 RFC 2410 5.285 RFC 2414 6.103 RFC 2417 5.286 RFC 2419 5.287 RFC 2420 5.288 RFC 2421 5.289 RFC 2422 5.290 RFC 2423 5.291 RFC 2424 5.292 RFC 2425 5.293 RFC 2426 5.294 RFC 2427 3.55 RFC 2428 5.295 RFC 2429 5.296 RFC 2431 5.297 RFC 2435 5.298 RFC 2439 5.299 RFC 2440 5.300 RFC 2443 6.104 RFC 2444 5.301 RFC 2445 5.302 RFC 2446 5.303 RFC 2447 5.304 RFC 2449 5.305 RFC 2451 5.306 RFC 2452 5.307 RFC 2453 3.56 RFC 2454 5.308 RFC 2455 5.309 RFC 2456 5.310 RFC 2457 5.311 RFC 2459 5.312 RFC 2460 4.52 RFC 2461 4.53 RFC 2462 4.54 RFC 2463 4.55 RFC 2464 5.313 RFC 2465 5.314 RFC 2466 5.315 RFC 2467 5.316 RFC 2470 5.317 RFC 2471 6.105 RFC 2472 5.318 RFC 2473 5.319 RFC 2474 5.320 RFC 2476 5.321 RFC 2478 5.322 RFC 2480 5.323 RFC 2481 6.106 RFC 2483 6.107 RFC 2484 5.324 RFC 2485 5.325 RFC 2486 5.326 RFC 2487 5.327 RFC 2491 5.328 RFC 2492 5.329 RFC 2493 5.330 RFC 2494 5.331 RFC 2495 5.332 RFC 2496 5.333 RFC 2497 5.334 RFC 2507 5.335 RFC 2508 5.336 RFC 2509 5.337 RFC 2510 5.338 RFC 2511 5.339 RFC 2512 5.340 RFC 2513 5.341 RFC 2514 5.342 RFC 2515 5.343 RFC 2518 5.344 RFC 2520 6.108 RFC 2521 6.109 RFC 2522 6.110 RFC 2523 6.111 RFC 2526 5.345 RFC 2529 5.346 RFC 2530 5.347 RFC 2532 5.348 RFC 2533 5.349 RFC 2534 5.350 RFC 2535 5.351 RFC 2536 5.352 RFC 2537 5.353 RFC 2538 5.354 RFC 2539 5.355 RFC 2540 6.112 RFC 2543 5.356 RFC 2545 5.357 RFC 2554 5.358 RFC 2557 5.359 RFC 2558 5.360 RFC 2559 5.361 RFC 2560 5.362 RFC 2561 5.363 RFC 2562 5.364 RFC 2563 5.365 RFC 2564 5.366 RFC 2567 6.113 RFC 2568 6.114 RFC 2569 6.115 RFC 2571 4.56 RFC 2572 4.57 RFC 2573 4.58 RFC 2574 4.59 RFC 2575 4.60 RFC 2576 5.367 RFC 2578 3.58.1 RFC 2579 3.58.2 RFC 2581 5.368 RFC 2582 6.116 RFC 2584 5.369 RFC 2585 5.370 RFC 2587 5.371 RFC 2589 5.372 RFC 2590 5.373 RFC 2591 5.374 RFC 2592 5.375 RFC 2593 6.117 RFC 2594 5.376 RFC 2595 5.377 RFC 2596 5.378 RFC 2597 5.379 RFC 2598 5.380 RFC 2600 3.01 RFC 2601 5.381 RFC 2602 5.382 RFC 2603 5.383 RFC 2605 5.384 RFC 2608 5.385 RFC 2609 5.386 RFC 2610 5.387 RFC 2613 5.388 RFC 2615 5.389 RFC 2616 4.61 RFC 2617 4.62 RFC 2618 5.390 RFC 2619 5.391 RFC 2622 5.392 RFC 2623 5.393 RFC 2625 5.394 RFC 2630 5.395 RFC 2631 5.396 RFC 2632 5.397 RFC 2633 5.398 RFC 2634 5.399 RFC 2640 5.400 RFC 2645 5.401 RFC 2646 5.402 RFC 2649 6.118 RFC 2651 5.403 RFC 2652 5.404 RFC 2653 5.405 RFC 2654 6.119 RFC 2655 6.120 RFC 2656 6.121 RFC 2657 6.122 RFC 2658 5.406 RFC 2659 6.123 RFC 2660 6.124 RFC 2661 5.407 RFC 2662 5.408 RFC 2665 5.409 RFC 2667 5.410 RFC 2668 5.411 RFC 2669 5.412 RFC 2670 5.413 RFC 2671 5.414 RFC 2672 5.415 RFC 2673 5.416 RFC 2674 5.417 RFC 2675 5.418 RFC 2676 6.125 RFC 2677 5.419 RFC 2678 5.420 RFC 2679 5.421 RFC 2680 5.422 RFC 2681 5.423 RFC 2684 5.424 RFC 2685 5.425 RFC 2686 5.426 RFC 2687 5.427 RFC 2688 5.428 RFC 2692 6.126 RFC 2693 6.127 RFC 2710 5.429 RFC 2711 5.430 RFC 2712 5.431 RFC 2716 6.128 RFC 2720 5.432 RFC 2724 6.129 RFC 2725 5.433 RFC 2726 5.434 RFC 2728 5.435 RFC 2730 5.436 RFC 2732 5.437 RFC 2733 5.438 RFC 2734 5.439 RFC 2735 5.440 RFC 2737 5.441 RFC 2738 5.442 RFC 2739 5.443 RFC 2740 5.444 RFC 2741 5.445 RFC 2742 5.446 RFC 2743 5.447 RFC 2744 5.448 RFC 2745 5.449 RFC 2746 5.450 RFC 2747 5.451 RFC 2748 5.452 RFC 2749 5.453 RFC 2750 5.454 RFC 2751 5.455 RFC 2752 5.456 RFC 2756 6.130 RFC 2758 6.131 RFC 2762 6.132 RFC 2765 5.457 RFC 2766 5.458 RFC 2769 5.459 RFC 2770 6.133 RFC 2773 6.134 RFC 2774 6.135 RFC 2776 5.460 RFC 2782 5.461 RFC 2784 5.462 RFC 2786 6.136 RFC 2787 5.463 RFC 2788 5.464 RFC 2789 5.465 RFC 2790 4.63 RFC 2793 5.466 RFC 2794 5.467 RFC 2796 5.468 RFC 2797 5.469 RFC 2806 5.470 RFC 2814 5.471 RFC 2815 5.472 RFC 2819 3.59 RFC 2823 6.137 RFC 2829 5.473 RFC 2830 5.474 RFC 2831 5.475 RFC 2833 5.476 RFC 2834 5.477 RFC 2835 5.478 RFC 2837 5.479 RFC 2842 5.480 RFC 2844 6.138 RFC 2845 5.481 RFC 2846 5.482 RFC 2847 5.483 RFC 2848 5.484 RFC 2849 5.485 RFC 2851 5.486 RFC 2852 5.487 RFC 2853 5.488 RFC 2855 5.489 RFC 2856 5.490 RFC 2857 5.491 RFC 2858 5.492 RFC 2859 6.139 RFC 2861 6.140 RFC 2862 5.493 RFC 2863 4.64 RFC 2864 5.494 RFC 2865 4.65 RFC 2872 5.495 RFC 2873 5.496 RFC 2874 5.497 RFC 2875 5.498 RFC 2878 5.499 RFC 2879 5.500 RFC 2883 5.501 RFC 2890 5.502 RFC 2891 5.503 RFC 2893 5.504 RFC 2894 5.505 RFC 2895 5.506 RFC 2903 6.141 RFC 2907 5.507 RFC 2909 6.142 RFC 2910 5.508 RFC 2911 5.509 RFC 2912 5.510 RFC 2913 5.511 RFC 2915 5.512 RFC 2916 5.513 RFC 2918 5.514 RFC 2919 5.515 RFC 2920 3.60 RFC 2925 5.516 RFC 2930 5.517 RFC 2931 5.518 RFC 2932 5.519 RFC 2933 5.520 RFC 2934 6.143 RFC 2935 5.521 RFC 2937 5.522 RFC 2938 5.523 RFC 2940 5.524 RFC 2941 5.525 RFC 2942 5.526 RFC 2943 5.527 RFC 2944 5.528 RFC 2945 5.529 RFC 2946 5.530 RFC 2947 5.531 RFC 2948 5.532 RFC 2949 5.533 RFC 2950 5.534 RFC 2954 5.535 RFC 2955 5.536 RFC 2959 5.537 RFC 2960 5.538 RFC 2961 5.539 RFC 2965 5.540 RFC 2971 5.541 RFC 2974 6.144 RFC 2976 5.542 RFC 2981 5.543 RFC 2982 5.544 RFC 2984 5.545 RFC 2987 5.546 RFC 2988 5.547 RFC 2996 5.548 RFC 2997 5.549 RFC 3003 5.550 RFC 3004 5.551 RFC 3006 5.552 RFC 3007 5.553 RFC 3008 5.554 RFC 3009 5.555 RFC 3010 5.556 RFC 3011 5.557 RFC 3012 5.558 RFC 3014 5.559 RFC 3015 5.560 RFC 3016 5.561 RFC 3017 5.562 RFC 3018 6.145 RFC 3019 5.563 RFC 3020 5.564 RFC 3021 5.565 RFC 3023 5.566 RFC 3024 5.567 RFC 3028 5.568 RFC 3029 6.146 RFC 3030 5.569 RFC 3031 5.570 RFC 3032 5.571 RFC 3033 5.572 RFC 3034 5.573 RFC 3035 5.574 RFC 3036 5.575 RFC 3038 5.576 RFC 3039 5.577 RFC 3041 5.578 RFC 3042 5.579 RFC 3046 5.580 RFC 3047 5.581 RFC 3049 5.582 RFC 3055 5.583 RFC 3056 5.584 RFC 3057 5.585 RFC 3059 5.586 RFC 3060 5.587 RFC 3062 5.588 RFC 3063 6.147 RFC 3065 5.589 RFC 3068 5.590 RFC 3070 5.591 RFC 3074 5.592 RFC 3075 5.593 RFC 3077 5.594 RFC 3080 5.595 RFC 3081 5.596 RFC 3082 6.148 RFC 3084 5.597 RFC 3088 6.149 RFC 3090 5.598 RFC 3095 5.599 RFC 3097 5.600 RFC 3107 5.601 RFC 3108 5.602 RFC 3110 5.603 RFC 3111 5.604 RFC 3115 5.605 RFC 3118 5.606 RFC 3119 5.607 RFC 3122 5.608 RFC 3123 6.150 RFC 3124 5.609 RFC 3140 5.610 RFC 3145 5.611 References This document is an analysis of approximately 900 different RFC's and the author refers the reader to the index of standards available from the RFC editor for more specific information on any individual RFC. The RFC editor can currently be reach at the following URL: http://www.rfc-editor.org Acknowledgements The author would like to acknowledge the support of the Internet Society in the research and production of this document. 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 Email: phil@nesser.com Phone: +1 425 481 4303 Fax: +1 425 482 9721 This draft expires in September 2002.
Datatracker
Report a datatracker bug
draft-ietf-ngtrans-ipv4survey-02
None
| Document | Document type |
Expired Internet-Draft
(ngtrans WG)
Expired & archived
|
|
|---|---|---|---|
| Select version | |||
| Compare versions | |||
| Author |
Philip J. Nesser II
Email authors |
||
| RFC stream |
|
||
| Intended RFC status | (None) | ||
| Other formats | |||
| Additional resources | Mailing list discussion |