draft-ietf-v6ops-ipv4survey-int-01.txt | draft-ietf-v6ops-ipv4survey-int-02.txt | |||
---|---|---|---|---|
Network Working Group Philip J. Nesser II | ||||
draft-ietf-v6ops-ipv4survey-int-01.txt Nesser & Nesser Consulting | ||||
Internet Draft Cleveland Mickles | ||||
AOL Time Warner | ||||
June 2003 | ||||
Expires December 2003 | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed | IPv6 Operations C. Mickles | |||
Internet-Draft | ||||
Expires: March 31, 2004 P. Nesser | ||||
Nesser & Nesser Consulting | ||||
Oct 2003 | ||||
This document is an Internet-Draft and is in full conformance with | Survey of IPv4 Addresses in Currently Deployed IETF Internet Area | |||
all provisions of Section 10 of RFC2026. | Standards | |||
draft-ietf-v6ops-ipv4survey-int-02.txt | ||||
Status of this Memo | Status of this Memo | |||
This document is an Internet-Draft and is in full conformance with | ||||
all provisions of Section 10 of RFC2026. | ||||
Internet-Drafts are working documents of the Internet Engineering | Internet-Drafts are working documents of the Internet Engineering | |||
Task Force (IETF), its areas, and its working groups. Note that other | Task Force (IETF), its areas, and its working groups. Note that other | |||
groups may also distribute working documents as Internet-Drafts. | groups may also distribute working documents as Internet-Drafts. | |||
Internet-Drafts are draft documents valid for a maximum of six | Internet-Drafts are draft documents valid for a maximum of six months | |||
months and may be updated, replaced, or obsoleted by other documents at | and may be updated, replaced, or obsoleted by other documents at any | |||
any time. It is inappropriate to use Internet-Drafts as reference | time. It is inappropriate to use Internet-Drafts as reference | |||
material or to cite them other than as "work in progress." | material or to cite them other than as "work in progress." | |||
The list of current Internet-Drafts can be accessed at | The list of current Internet-Drafts can be accessed at http:// | |||
http://www.ietf.org/ietf/1id-abstracts.txt | www.ietf.org/ietf/1id-abstracts.txt. | |||
The list of Internet-Draft Shadow Directories can be accessed at | The list of Internet-Draft Shadow Directories can be accessed at | |||
http://www.ietf.org/shadow.html. | http://www.ietf.org/shadow.html. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | This Internet-Draft will expire on March 31, 2004. | |||
Copyright Notice | ||||
Copyright (C) The Internet Society (2003). All Rights Reserved. | ||||
Abstract | Abstract | |||
This document seeks to document all usage of IPv4 addresses in | This document seeks to document all usage of IPv4 addresses in | |||
currently deployed IETF Internet Area documented standards. In order | currently deployed IETF Internet Area documented standards. In order | |||
to successfully transition from an all IPv4 Internet to an all IPv6 | 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 | Internet, many interim steps will be taken. One of these steps is the | |||
evolution of current protocols that have IPv4 dependencies. It is | evolution of current protocols that have IPv4 dependencies. It is | |||
hoped that these protocols (and their implementations) will be | hoped that these protocols (and their implementations) will be | |||
redesigned to be network address independent, but failing that will at | redesigned to be network address independent, but failing that will | |||
least dually support IPv4 and IPv6. To this end, all Standards (Full, | at least dually support IPv4 and IPv6. To this end, all Standards | |||
Draft, and Proposed) as well as Experimental RFCs will be surveyed | (Full, Draft, and Proposed) as well as Experimental RFCs will be | |||
and any dependencies will be documented. | surveyed and any dependencies will be documented. | |||
1.0 Introduction.............................................02 | Table of Contents | |||
2.0 Document Organization....................................03 | ||||
3.0 Full Standards...........................................03 | ||||
4.0 Draft Standards..........................................09 | ||||
5.0 Proposed Standards.......................................13 | ||||
6.0 Experimental RFCs........................................34 | ||||
7.0 Summary of Results......................................43 | ||||
8.0 Security Considerations..................................51 | ||||
9.0 References...............................................51 | ||||
10.0 Acknowledgements........................................51 | ||||
11.0 Author's Addresses......................................52 | ||||
12.0 Intellectual Property Statement.........................52 | ||||
13.0 Full Copyright Statement...............................53 | ||||
1.0 Introduction | 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . 9 | |||
2. Document Organization . . . . . . . . . . . . . . . . . . 10 | ||||
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . 11 | ||||
3.1 RFC 791 Internet Protocol . . . . . . . . . . . . . . . . 11 | ||||
3.2 RFC 792 Internet Control Message Protocol . . . . . . . . 11 | ||||
3.3 RFC 826 Ethernet Address Resolution Protocol . . . . . . . 11 | ||||
3.4 RFC 891 DCN Local-Network Protocols . . . . . . . . . . . 11 | ||||
3.5 RFC 894 Standard for the transmission of IP datagrams | ||||
over Ethernet networks . . . . . . . . . . . . . . . . . . 11 | ||||
3.6 RFC 895 Standard for the transmission of IP datagrams | ||||
over experimental Ethernet networks . . . . . . . . . . . 11 | ||||
3.7 RFC 903 Reverse Address Resolution Protocol . . . . . . . 11 | ||||
3.8 RFC 919 Broadcasting Internet Datagrams . . . . . . . . . 11 | ||||
3.9 RFC 922 Broadcasting Internet datagrams in the presence | ||||
of subnets . . . . . . . . . . . . . . . . . . . . . . . . 11 | ||||
3.10 RFC 950 Internet Standard Subnetting Procedure . . . . . . 12 | ||||
3.11 RFC 1034 Domain Names: Concepts and Facilities . . . . . . 12 | ||||
3.12 RFC 1035 Domain Names: Implementation and Specification . 13 | ||||
3.13 RFC 1042 Standard for the transmission of IP datagrams | ||||
over IEEE 802 networks . . . . . . . . . . . . . . . . . 14 | ||||
3.14 RFC 1044 Internet Protocol on Network System's | ||||
HYPERchannel: Protocol Specification . . . . . . . . . . 14 | ||||
3.15 RFC 1055 Nonstandard for transmission of IP datagrams | ||||
over serial lines: SLIP . . . . . . . . . . . . . . . . . 14 | ||||
3.16 RFC 1088 Standard for the transmission of IP datagrams | ||||
over NetBIOS networks . . . . . . . . . . . . . . . . . . 15 | ||||
3.17 RFC 1112 Host Extensions for IP Multicasting . . . . . . . 15 | ||||
3.18 RFC 1132 Standard for the transmission of 802.2 packets | ||||
over IPX networks . . . . . . . . . . . . . . . . . . . . 15 | ||||
3.19 RFC 1201 Transmitting IP traffic over ARCNET networks . . 15 | ||||
3.20 RFC 1209 The Transmission of IP Datagrams over the SMDS | ||||
Service . . . . . . . . . . . . . . . . . . . . . . . . . 15 | ||||
3.21 RFC 1390 Transmission of IP and ARP over FDDI Networks . . 15 | ||||
3.22 RFC 1661 The Point-to-Point Protocol (PPP) . . . . . . . . 15 | ||||
3.23 RFC 1662 PPP in HDLC-like Framing . . . . . . . . . . . . 16 | ||||
3.24 RFC 2427 Multiprotocol Interconnect over Frame Relay . . . 16 | ||||
4. Draft Standards . . . . . . . . . . . . . . . . . . . . . 17 | ||||
4.1 RFC 951 Bootstrap Protocol (BOOTP) . . . . . . . . . . . . 17 | ||||
4.2 RFC 1188 Proposed Standard for the Transmission of IP | ||||
Datagrams over FDDI Networks . . . . . . . . . . . . . . . 18 | ||||
4.3 RFC 1191 Path MTU discovery . . . . . . . . . . . . . . . 18 | ||||
4.4 RFC 1356 Multiprotocol Interconnect on X.25 and ISDN . . . 18 | ||||
4.5 RFC 1534 Interoperation Between DHCP and BOOTP . . . . . . 18 | ||||
4.6 RFC 1542 Clarifications and Extensions for the | ||||
Bootstrap Protocol . . . . . . . . . . . . . . . . . . . . 18 | ||||
4.7 RFC 1629 Guidelines for OSI NSAP Allocation in the | ||||
Internet . . . . . . . . . . . . . . . . . . . . . . . . . 18 | ||||
4.8 RFC 1762 The PPP DECnet Phase IV Control Protocol (DNCP) . 18 | ||||
4.9 RFC 1989 PPP Link Quality Monitoring . . . . . . . . . . . 18 | ||||
4.10 RFC 1990 The PPP Multilink Protocol (MP) . . . . . . . . . 18 | ||||
4.11 RFC 1994 PPP Challenge Handshake Authentication | ||||
Protocol (CHAP) . . . . . . . . . . . . . . . . . . . . . 19 | ||||
4.12 RFC 2067 IP over HIPPI . . . . . . . . . . . . . . . . . . 19 | ||||
4.13 RFC 2131 Dynamic Host Configuration Protocol . . . . . . . 20 | ||||
4.14 RFC 2132 DHCP Options and BOOTP Vendor Extensions . . . . 20 | ||||
4.15 RFC 2390 Inverse Address Resolution Protocol . . . . . . . 20 | ||||
4.16 RFC 2460 Internet Protocol, Version 6 (IPv6) | ||||
Specification . . . . . . . . . . . . . . . . . . . . . . 20 | ||||
4.17 RFC 2461 Neighbor Discovery for IP Version 6 (IPv6) . . . 20 | ||||
4.18 RFC 2462 IPv6 Stateless Address Autoconfiguration . . . . 20 | ||||
4.19 RFC 2463 Internet Control Message Protocol (ICMPv6) for | ||||
the Internet Protocol Version 6 (IPv6) Specification . . 20 | ||||
4.20 RFC 3596 DNS Extensions to support IP version 6 . . . . . 20 | ||||
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . 21 | ||||
5.1 RFC 1234 Tunneling IPX traffic through IP networks . . . . 21 | ||||
5.2 RFC 1256 ICMP Router Discovery Messages . . . . . . . . . 22 | ||||
5.3 RFC 1277 Encoding Network Addresses to Support | ||||
Operation over Non-OSI Lower Layers . . . . . . . . . . . 22 | ||||
5.4 RFC 1332 The PPP Internet Protocol Control Protocol | ||||
(IPCP) . . . . . . . . . . . . . . . . . . . . . . . . . . 22 | ||||
5.5 RFC 1377 The PPP OSI Network Layer Control Protocol | ||||
(OSINLCP) . . . . . . . . . . . . . . . . . . . . . . . . 22 | ||||
5.6 RFC 1378 The PPP AppleTalk Control Protocol (ATCP) . . . . 22 | ||||
5.7 RFC 1469 IP Multicast over Token-Ring Local Area | ||||
Networks . . . . . . . . . . . . . . . . . . . . . . . . . 22 | ||||
5.8 RFC 1552 The PPP Internetworking Packet Exchange | ||||
Control Protocol (IPXCP) . . . . . . . . . . . . . . . . . 22 | ||||
5.9 RFC 1570 PPP LCP Extensions . . . . . . . . . . . . . . . 23 | ||||
5.10 RFC 1598 PPP in X.25 PPP-X25 . . . . . . . . . . . . . . . 23 | ||||
5.11 RFC 1618 PPP over ISDN . . . . . . . . . . . . . . . . . . 23 | ||||
5.12 RFC 1663 PPP Reliable Transmission . . . . . . . . . . . . 23 | ||||
5.13 RFC 1752 The Recommendation for the IP Next Generation | ||||
Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 23 | ||||
5.14 RFC 1755 ATM Signaling Support for IP over ATM . . . . . . 23 | ||||
5.15 RFC 1763 The PPP Banyan Vines Control Protocol (BVCP) . . 23 | ||||
5.16 RFC 1764 The PPP XNS IDP Control Protocol (XNSCP) . . . . 23 | ||||
5.17 RFC 1973 PPP in Frame Relay . . . . . . . . . . . . . . . 23 | ||||
5.18 RFC 1981 Path MTU Discovery for IP version 6 . . . . . . . 23 | ||||
5.19 RFC 1982 Serial Number Arithmetic . . . . . . . . . . . . 23 | ||||
5.20 5.21 RFC 1995 Incremental Zone Transfer in DNS . . . . . . 24 | ||||
5.21 RFC 1996 A Mechanism for Prompt Notification of Zone | ||||
Changes (DNS NOTIFY) . . . . . . . . . . . . . . . . . . . 24 | ||||
5.22 RFC 2003 IP Encapsulation within IP . . . . . . . . . . . 24 | ||||
5.23 RFC 2004 Minimal Encapsulation within IP . . . . . . . . . 24 | ||||
5.24 RFC 2005 Applicability Statement for IP Mobility Support . 24 | ||||
5.25 RFC 2022 Support for Multicast over UNI 3.0/3.1 based | ||||
ATM Networks . . . . . . . . . . . . . . . . . . . . . . . 24 | ||||
5.26 RFC 2043 The PPP SNA Control Protocol (SNACP) . . . . . . 24 | ||||
5.27 RFC 2097 The PPP NetBIOS Frames Control Protocol (NBFCP) . 24 | ||||
5.28 RFC 2113 IP Router Alert Option . . . . . . . . . . . . . 24 | ||||
5.29 RFC 2125 The PPP Bandwidth Allocation Protocol (BAP) / | ||||
The PPP Bandwidth Allocation Control Protocol (BACP) . . . 25 | ||||
5.30 RFC 2136 Dynamic Updates in the Domain Name System (DNS | ||||
UPDATE) . . . . . . . . . . . . . . . . . . . . . . . . . 25 | ||||
5.31 RFC 2181 Clarifications to the DNS Specification . . . . . 25 | ||||
5.32 RFC 2225 Classical IP and ARP over ATM . . . . . . . . . . 25 | ||||
5.33 RFC 2226 IP Broadcast over ATM Networks . . . . . . . . . 25 | ||||
5.34 RFC 2241 DHCP Options for Novell Directory Services . . . 25 | ||||
5.35 RFC 2242 NetWare/IP Domain Name and Information . . . . . 26 | ||||
5.36 RFC 2290 Mobile-IPv4 Configuration Option for PPP IPCP . . 26 | ||||
5.37 RFC 2308 Negative Caching of DNS Queries (DNS NCACHE) . . 26 | ||||
5.38 RFC 2331 ATM Signaling Support for IP over ATM - UNI | ||||
Signaling 4.0 Update . . . . . . . . . . . . . . . . . . . 26 | ||||
5.39 RFC 2332 NBMA Next Hop Resolution Protocol (NHRP) . . . . 26 | ||||
5.40 RFC 2333 NHRP Protocol Applicability . . . . . . . . . . . 27 | ||||
5.41 RFC 2335 A Distributed NHRP Service Using SCSP . . . . . . 27 | ||||
5.42 RFC 2363 PPP Over FUNI . . . . . . . . . . . . . . . . . . 27 | ||||
5.43 RFC 2364 PPP Over AAL5 . . . . . . . . . . . . . . . . . . 27 | ||||
5.44 RFC 2371 Transaction Internet Protocol Version 3.0 | ||||
(TIPV3) . . . . . . . . . . . . . . . . . . . . . . . . . 27 | ||||
5.45 RFC 2464 Transmission of IPv6 Packets over Ethernet | ||||
Networks . . . . . . . . . . . . . . . . . . . . . . . . . 29 | ||||
5.46 RFC 2467 Transmission of IPv6 Packets over FDDI Networks . 29 | ||||
5.47 RFC 2470 Transmission of IPv6 Packets over Token Ring | ||||
Networks . . . . . . . . . . . . . . . . . . . . . . . . . 29 | ||||
5.48 RFC 2472 IP Version 6 over PPP . . . . . . . . . . . . . . 29 | ||||
5.49 RFC 2473 Generic Packet Tunneling in IPv6 Specification . 29 | ||||
5.50 RFC 2484 PPP LCP Internationalization Configuration | ||||
Option . . . . . . . . . . . . . . . . . . . . . . . . . . 29 | ||||
5.51 RFC 2485 DHCP Option for The Open Group's User | ||||
Authentication Protocol . . . . . . . . . . . . . . . . . 29 | ||||
5.52 RFC 2486 The Network Access Identifier . . . . . . . . . . 29 | ||||
5.53 RFC 2491 IPv6 over Non-Broadcast Multiple Access (NBMA) | ||||
networks . . . . . . . . . . . . . . . . . . . . . . . . . 29 | ||||
5.54 RFC 2492 IPv6 over ATM Networks . . . . . . . . . . . . . 29 | ||||
5.55 RFC 2497 Transmission of IPv6 Packets over ARCnet | ||||
Networks . . . . . . . . . . . . . . . . . . . . . . . . . 30 | ||||
5.56 RFC 2507 IP Header Compression . . . . . . . . . . . . . . 30 | ||||
5.57 RFC 2526 Reserved IPv6 Subnet Anycast Addresses . . . . . 30 | ||||
5.58 RFC 2529 Transmission of IPv6 over IPv4 Domains without | ||||
Explicit Tunnels . . . . . . . . . . . . . . . . . . . . . 30 | ||||
5.59 RFC 2563 DHCP Option to Disable Stateless | ||||
Auto-Configuration in IPv4 Clients . . . . . . . . . . . . 30 | ||||
5.60 RFC 2590 Transmission of IPv6 Packets over Frame Relay | ||||
Networks Specification . . . . . . . . . . . . . . . . . . 30 | ||||
5.61 RFC 2601 ILMI-Based Server Discovery for ATMARP . . . . . 30 | ||||
5.62 RFC 2602 ILMI-Based Server Discovery for MARS . . . . . . 30 | ||||
5.63 RFC 2603 ILMI-Based Server Discovery for NHRP . . . . . . 30 | ||||
5.64 RFC 2610 DHCP Options for Service Location Protocol . . . 30 | ||||
5.65 RFC 2615 PPP over SONET/SDH . . . . . . . . . . . . . . . 31 | ||||
5.66 RFC 2625 IP and ARP over Fibre Channel . . . . . . . . . . 31 | ||||
5.67 RFC 2671 Extension Mechanisms for DNS (EDNS0) . . . . . . 31 | ||||
5.68 RFC 2672 Non-Terminal DNS Name Redirection . . . . . . . . 31 | ||||
5.69 RFC 2673 Binary Labels in the Domain Name System . . . . . 31 | ||||
5.70 RFC 2675 IPv6 Jumbograms . . . . . . . . . . . . . . . . . 31 | ||||
5.71 RFC 2684 Multiprotocol Encapsulation over ATM | ||||
Adaptation Layer 5 . . . . . . . . . . . . . . . . . . . . 31 | ||||
5.72 RFC 2685 Virtual Private Networks Identifier . . . . . . . 31 | ||||
5.73 RFC 2686 The Multi-Class Extension to Multi-Link PPP . . . 31 | ||||
5.74 RFC 2687 PPP in a Real-time Oriented HDLC-like Framing . . 32 | ||||
5.75 RFC 2688 Integrated Services Mappings for Low Speed | ||||
Networks . . . . . . . . . . . . . . . . . . . . . . . . . 32 | ||||
5.76 RFC 2710 Multicast Listener Discovery (MLD) for IPv6 . . . 32 | ||||
5.77 RFC 2711 IPv6 Router Alert Option . . . . . . . . . . . . 32 | ||||
5.78 RFC 2728 The Transmission of IP Over the Vertical | ||||
Blanking Interval of a Television Signal . . . . . . . . . 32 | ||||
5.79 RFC 2734 IPv4 over IEEE 1394 . . . . . . . . . . . . . . . 33 | ||||
5.80 RFC 2735 NHRP Support for Virtual Private Networks . . . . 33 | ||||
5.81 RFC 2765 Stateless IP/ICMP Translation Algorithm (SIIT) . 33 | ||||
5.82 RFC 2766 Network Address Translation - Protocol | ||||
Translation (NAT-PT) . . . . . . . . . . . . . . . . . . . 33 | ||||
5.83 RFC 2776 Multicast-Scope Zone Announcement Protocol | ||||
(MZAP) . . . . . . . . . . . . . . . . . . . . . . . . . . 33 | ||||
5.84 RFC 2782 A DNS RR for specifying the location of | ||||
services . . . . . . . . . . . . . . . . . . . . . . . . . 33 | ||||
5.85 RFC 2794 Mobile IP Network Access Identifier Extension | ||||
for IPv4 . . . . . . . . . . . . . . . . . . . . . . . . . 33 | ||||
5.86 RFC 2834 ARP and IP Broadcast over HIPPI-800 . . . . . . . 33 | ||||
5.87 RFC 2835 IP and ARP over HIPPI-6400 . . . . . . . . . . . 35 | ||||
5.88 RFC 2855 DHCP for IEEE 1394 . . . . . . . . . . . . . . . 35 | ||||
5.89 RFC 2874 DNS Extensions to Support IPv6 Address | ||||
Aggregation and Renumbering . . . . . . . . . . . . . . . 35 | ||||
5.90 RFC 2893 Transition Mechanisms for IPv6 Hosts and | ||||
Routers . . . . . . . . . . . . . . . . . . . . . . . . . 36 | ||||
5.91 RFC 2916 E.164 number and DNS . . . . . . . . . . . . . . 36 | ||||
5.92 RFC 2937 The Name Service Search Option for DHCP . . . . . 36 | ||||
5.93 RFC 3004 The User Class Option for DHCP . . . . . . . . . 36 | ||||
5.94 RFC 3011 The IPv4 Subnet Selection Option for DHCP . . . . 36 | ||||
5.95 RFC 3021 Using 31-Bit Prefixes for IPv4 P2P Links . . . . 36 | ||||
5.96 RFC 3024 Reverse Tunneling for Mobile IP, revised . . . . 36 | ||||
5.97 RFC 3046 DHCP Relay Agent Information Option . . . . . . . 36 | ||||
5.98 RFC 3056 Connection of IPv6 Domains via IPv4 Clouds . . . 36 | ||||
5.99 RFC 3068 An Anycast Prefix for 6to4 Relay Routers . . . . 36 | ||||
5.100 RFC 3074 DHC Load Balancing Algorithm . . . . . . . . . . 37 | ||||
5.101 RFC 3077 A Link-Layer Tunneling Mechanism for | ||||
Unidirectional Links . . . . . . . . . . . . . . . . . . . 37 | ||||
5.102 RFC 3115 Mobile IP Vendor/Organization-Specific | ||||
Extensions . . . . . . . . . . . . . . . . . . . . . . . . 37 | ||||
5.103 RFC 3145 L2TP Disconnect Cause Information . . . . . . . . 37 | ||||
5.104 RFC 3344 IP Mobility Support for IPv4 . . . . . . . . . . 37 | ||||
5.105 RFC 3376 Internet Group Management Protocol, Version 3 . . 37 | ||||
5.106 RFC 3402 Dynamic Delegation Discovery System (DDDS) | ||||
Part Two: The Algorithm . . . . . . . . . . . . . . . . . 37 | ||||
5.107 RFC 3403 Dynamic Delegation Discovery System (DDDS) | ||||
Part Three: The Domain Name System (DNS) Database . . . . 37 | ||||
5.108 RFC 3404 Dynamic Delegation Discovery System (DDDS) | ||||
Part Four: The Uniform Resource Identifiers (URI) . . . . 37 | ||||
5.109 RFC 3513 IP Version 6 Addressing Architecture . . . . . . 37 | ||||
5.110 RFC 3518 Point-to-Point Protocol (PPP) Bridging Control | ||||
Protocol (BCP) . . . . . . . . . . . . . . . . . . . . . . 38 | ||||
6. Experimental RFCs . . . . . . . . . . . . . . . . . . . . 39 | ||||
6.1 RFC 1149 Standard for the transmission of IP datagrams | ||||
on avian carriers . . . . . . . . . . . . . . . . . . . . 39 | ||||
6.2 RFC 1183 New DNS RR Definitions . . . . . . . . . . . . . 39 | ||||
6.3 RFC 1226 Internet protocol encapsulation of AX.25 frames . 39 | ||||
6.4 RFC 1241 Scheme for an internet encapsulation protocol: | ||||
Version 1 . . . . . . . . . . . . . . . . . . . . . . . . 39 | ||||
6.5 RFC 1307 Dynamically Switched Link Control Protocol . . . 39 | ||||
6.6 RFC 1393 Traceroute Using an IP Option . . . . . . . . . . 40 | ||||
6.7 RFC 1433 Directed ARP . . . . . . . . . . . . . . . . . . 40 | ||||
6.8 RFC 1464 Using the Domain Name System To Store | ||||
Arbitrary String Attributes . . . . . . . . . . . . . . . 40 | ||||
6.9 RFC 1475 TP/IX: The Next Internet . . . . . . . . . . . . 40 | ||||
6.10 RFC 1561 Use of ISO CLNP in TUBA Environments . . . . . . 40 | ||||
6.11 RFC 1712 DNS Encoding of Geographical Location . . . . . . 41 | ||||
6.12 RFC 1735 NBMA Address Resolution Protocol (NARP) . . . . . 41 | ||||
6.13 RFC 1768 Host Group Extensions for CLNP Multicasting . . . 42 | ||||
6.14 RFC 1788 ICMP Domain Name Messages . . . . . . . . . . . . 42 | ||||
6.15 RFC 1797 Class A Subnet Experiment . . . . . . . . . . . . 42 | ||||
6.16 RFC 1819 Internet Stream Protocol Version 2 (ST2) | ||||
Protocol Specification - Version ST2+ . . . . . . . . . . 42 | ||||
6.17 RFC 1868 ARP Extension - UNARP . . . . . . . . . . . . . . 43 | ||||
6.18 RFC 1876 A Means for Expressing Location Information in | ||||
the Domain Name System . . . . . . . . . . . . . . . . . . 43 | ||||
6.19 RFC 1888 OSI NSAPs and IPv6 . . . . . . . . . . . . . . . 43 | ||||
6.20 RFC 2009 GPS-Based Addressing and Routing . . . . . . . . 43 | ||||
6.21 RFC 2143 Encapsulating IP with the SCSI . . . . . . . . . 43 | ||||
6.22 RFC 2345 Domain Names and Company Name Retrieval . . . . . 43 | ||||
6.23 RFC 2443 A Distributed MARS Service Using SCSP . . . . . . 43 | ||||
6.24 RFC 2471 IPv6 Testing Address Allocation . . . . . . . . . 44 | ||||
6.25 RFC 2520 NHRP with Mobile NHCs . . . . . . . . . . . . . . 44 | ||||
6.26 RFC 2521 ICMP Security Failures Messages . . . . . . . . . 44 | ||||
6.27 RFC 2540 Detached Domain Name System (DNS) Information . . 44 | ||||
6.28 RFC 2823 PPP over Simple Data Link (SDL) using | ||||
SONET/SDH with ATM-like framing . . . . . . . . . . . . . 44 | ||||
6.29 RFC 3123 A DNS RR Type for Lists of Address Prefixes . . . 44 | ||||
6.30 RFC 3168 The Addition of Explicit Congestion | ||||
Notification (ECN) to IP . . . . . . . . . . . . . . . . 44 | ||||
6.31 RFC 3180 GLOP Addressing in 233/8 . . . . . . . . . . . . 44 | ||||
7. Summary of the Results . . . . . . . . . . . . . . . . . . 45 | ||||
7.1 Standards . . . . . . . . . . . . . . . . . . . . . . . . 45 | ||||
7.1.1 RFC 791 Internet Protocol . . . . . . . . . . . . . . . . 45 | ||||
7.1.2 RFC 792 Internet Control Message Protocol . . . . . . . . 45 | ||||
7.1.3 RFC 891 DCN Networks . . . . . . . . . . . . . . . . . . . 45 | ||||
7.1.4 RFC 894 IP over Ethernet . . . . . . . . . . . . . . . . . 45 | ||||
7.1.5 RFC 895 IP over experimental Ethernets . . . . . . . . . . 45 | ||||
7.1.6 RFC 922 Broadcasting Internet Datagrams in the Presence | ||||
of Subnets . . . . . . . . . . . . . . . . . . . . . . . . 45 | ||||
7.1.7 RFC 950 Internet Standard Subnetting Procedure . . . . . . 46 | ||||
7.1.8 RFC 1034 Domain Names: Concepts and Facilities . . . . . . 46 | ||||
7.1.9 RFC 1035 Domain Names: Implementation and Specification . 46 | ||||
7.1.10 RFC 1042 IP over IEEE 802 . . . . . . . . . . . . . . . . 46 | ||||
7.1.11 RFC 1044 IP over HyperChannel . . . . . . . . . . . . . . 46 | ||||
7.1.12 RFC 1088 IP over NetBIOS . . . . . . . . . . . . . . . . . 46 | ||||
7.1.13 RFC 1112 Host Extensions for IP Multicast . . . . . . . . 46 | ||||
7.1.14 RFC 1122 Requirements for Internet Hosts . . . . . . . . . 46 | ||||
7.1.15 RFC 1201 IP over ARCNET . . . . . . . . . . . . . . . . . 46 | ||||
7.1.16 RFC 1209 IP over SMDS . . . . . . . . . . . . . . . . . . 47 | ||||
7.1.17 RFC 1390 Transmission of IP and ARP over FDDI Networks . . 47 | ||||
7.2 Draft Standards . . . . . . . . . . . . . . . . . . . . . 47 | ||||
7.2.1 RFC 951 Bootstrap Protocol (BOOTP) . . . . . . . . . . . . 47 | ||||
7.2.2 RFC 1191 Path MTU Discovery . . . . . . . . . . . . . . . 47 | ||||
7.2.3 RFC 1356 Multiprotocol Interconnect on X.25 and ISDN . . . 47 | ||||
7.2.4 RFC 1990 The PPP Multilink Protocol (MP) . . . . . . . . . 47 | ||||
7.2.5 RFC 2067 IP over HIPPI . . . . . . . . . . . . . . . . . . 47 | ||||
7.2.6 RFC 2131 DHCP . . . . . . . . . . . . . . . . . . . . . . 47 | ||||
7.3 Proposed Standards . . . . . . . . . . . . . . . . . . . . 48 | ||||
7.3.1 RFC 1234 Tunneling IPX over IP . . . . . . . . . . . . . . 48 | ||||
7.3.2 RFC 1256 ICMP Router Discovery . . . . . . . . . . . . . . 48 | ||||
7.3.3 RFC 1277 Encoding Net Addresses to Support Operation | ||||
Over Non OSI Lower Layers . . . . . . . . . . . . . . . . 48 | ||||
7.3.4 RFC 1332 PPP Internet Protocol Control Protocol (IPCP) . . 48 | ||||
7.3.5 RFC 1469 IP Multicast over Token Ring . . . . . . . . . . 48 | ||||
7.3.6 RFC 2003 IP Encapsulation within IP . . . . . . . . . . . 48 | ||||
7.3.7 RFC 2004 Minimal Encapsulation within IP . . . . . . . . . 48 | ||||
7.3.8 RFC 2022 Support for Multicast over UNI 3.0/3.1 based | ||||
ATM Networks . . . . . . . . . . . . . . . . . . . . . . . 48 | ||||
7.3.9 RFC 2113 IP Router Alert Option . . . . . . . . . . . . . 48 | ||||
7.3.10 RFC 2165 SLP . . . . . . . . . . . . . . . . . . . . . . . 49 | ||||
7.3.11 RFC 2225 Classical IP & ARP over ATM . . . . . . . . . . . 49 | ||||
7.3.12 RFC 2226 IP Broadcast over ATM . . . . . . . . . . . . . . 49 | ||||
7.3.13 RFC 2371 Transaction IPv3 . . . . . . . . . . . . . . . . 49 | ||||
7.3.14 RFC 2625 IP and ARP over Fibre Channel . . . . . . . . . . 49 | ||||
7.3.15 RFC 2672 Non-Terminal DNS Redirection . . . . . . . . . . 49 | ||||
7.3.16 RFC 2673 Binary Labels in DNS . . . . . . . . . . . . . . 49 | ||||
7.3.17 IP over Vertical Blanking Interval of a TV Signal (RFC | ||||
2728) . . . . . . . . . . . . . . . . . . . . . . . . . . 49 | ||||
7.3.18 RFC 2734 IPv4 over IEEE 1394 . . . . . . . . . . . . . . . 49 | ||||
7.3.19 RFC 2834 ARP & IP Broadcasts Over HIPPI 800 . . . . . . . 49 | ||||
7.3.20 RFC 2835 ARP & IP Broadcasts Over HIPPI 6400 . . . . . . . 50 | ||||
7.3.21 RFC 3344 Mobility Support for IPv4 . . . . . . . . . . . . 50 | ||||
7.3.22 RFC 3376 Internet Group Management Protocol, Version 3 . . 50 | ||||
7.4 Experimental RFCs . . . . . . . . . . . . . . . . . . . . 50 | ||||
7.4.1 RFC 1393 Traceroute using an IP Option . . . . . . . . . . 50 | ||||
7.4.2 RFC 1307 Dynamically Switched Link Control Protocol . . . 50 | ||||
7.4.3 RFC 1735 NBMA Address Resolution Protocol (NARP) . . . . . 50 | ||||
7.4.4 RFC 1788 ICMP Domain Name Messages . . . . . . . . . . . . 50 | ||||
7.4.5 RFC 1868 ARP Extension - UNARP . . . . . . . . . . . . . . 50 | ||||
7.4.6 RFC 2143 IP Over SCSI . . . . . . . . . . . . . . . . . . 51 | ||||
7.4.7 RFC 3180 GLOP Addressing in 233/8 . . . . . . . . . . . . 51 | ||||
8. Security Considerations . . . . . . . . . . . . . . . . . 52 | ||||
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . 53 | ||||
Normative References . . . . . . . . . . . . . . . . . . . 54 | ||||
Authors' Addresses . . . . . . . . . . . . . . . . . . . . 54 | ||||
Intellectual Property and Copyright Statements . . . . . . 55 | ||||
This document is part of a document set aiming to document all usage of | 1. Introduction | |||
IPv4 addresses in IETF standards. In an effort to have the information | ||||
in a manageable form, it has been broken into 7 documents conforming | This document is part of a document set aiming to document all usage | |||
to the current IETF areas (Application, Internet, Management & | of IPv4 addresses in IETF standards. In an effort to have the | |||
Operations, Routing, Security, Sub-IP and Transport). | information in a manageable form, it has been broken into 7 documents | |||
conforming to the current IETF areas (Application, Internet, | ||||
Management & Operations, Routing, Security, Sub-IP and Transport). | ||||
This specific document focuses on usage of IPv4 addresses within the | This specific document focuses on usage of IPv4 addresses within the | |||
Internet area. | Internet area. | |||
For a full introduction, please see the intro[1] draft. | For a full introduction, please see the introduction [1] document. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
2.0 Document Organization | 2. Document Organization | |||
The following sections 3, 4, 5, and 6 each describe the raw analysis | The following sections 3, 4, 5, and 6 each describe the raw analysis | |||
of Full, Draft, and Proposed Standards, and Experimental RFCs. Each | of Full, Draft, and Proposed Standards, and Experimental RFCs. Each | |||
RFC is discussed in turn starting with RFC 1 and ending with RFC 3247. | RFC is discussed in turn starting with RFC 1 and ending in (about) | |||
The comments for each RFC are "raw" in nature. That is, each RFC is | RFC 3100. The comments for each RFC are "raw" in nature. That is, | |||
discussed in a vacuum and problems or issues discussed do not "look | each RFC is discussed in a vacuum and problems or issues discussed do | |||
ahead" to see if any of the issues raised have already been fixed. | not "look ahead" to see if any of the issues raised have already been | |||
fixed. | ||||
Section 7 is an analysis of the data presented in Sections 3, 4, 5, | 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 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. | and the problems that have been resolved in later RFCs are | |||
correlated. | ||||
3.0 Full Standards | 3. Full Standards | |||
Full Internet Standards (most commonly simply referred to as | Full Internet Standards (most commonly simply referred to as | |||
"Standards") are fully mature protocol specification that are widely | "Standards") are fully mature protocol specification that are widely | |||
implemented and used throughout the Internet. | implemented and used throughout the Internet. | |||
3.01 Internet Protocol. RFC0791, RFC0950, RFC0919, RFC0922, RFC792, | 3.1 RFC 791 Internet Protocol | |||
3.01.1 RFC 791 defines IPv4 and will be replaced by the IPv6 | This specification defines IPv4 and is replaced by the IPv6 | |||
specifications. | specifications. | |||
3.01.2 RFC 950 specifies IPv4 subnetting and will be replaced by the | 3.2 RFC 792 Internet Control Message Protocol | |||
IPv6 specifications. | ||||
3.01.3 RFC 919 is not online and is unavailable for review. | This specification defines ICMP, and is inherently IPv4 dependent. | |||
3.01.4 RFC 922 specifies how broadcasts should be treated in the | 3.3 RFC 826 Ethernet Address Resolution Protocol | |||
presence of subnets. The techniques of this document will be replaced | ||||
by the IPv6 specifications. | ||||
3.01.5 RFC 792 defines ICMP. The specification of ICMPv6 will serve | There are no IPv4 dependencies in this specification. | |||
as an update. | ||||
3.01.6 RFC 1112 defines IP multicast. A similar updated version for | 3.4 RFC 891 DCN Local-Network Protocols | |||
IPv6 multicasting must be written. | ||||
3.02 Domain Name System. RFC1034, RFC1035 | There are many implicit assumptions about the use of IPv4 addresses | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | in this document. | |||
3.02.1 RFC 1034 Domain Concepts and Facilities | 3.5 RFC 894 Standard for the transmission of IP datagrams over Ethernet | |||
networks | ||||
In Section 3.6. Resource Records the definition of A records is: | This specification specifically deals with the transmission of IPv4 | |||
packets over Ethernet. | ||||
RDATA which is the type and sometimes class dependent data | 3.6 RFC 895 Standard for the transmission of IP datagrams over | |||
which describes the resource: | experimental Ethernet networks | |||
This specification specifically deals with the transmission of IPv4 | ||||
packets over experimental Ethernet. | ||||
3.7 RFC 903 Reverse Address Resolution Protocol | ||||
There are no IPv4 dependencies in this specification. | ||||
3.8 RFC 919 Broadcasting Internet Datagrams | ||||
This specification defines broadcasting for IPv4; IPv6 uses multicast | ||||
so this is not applicable. | ||||
3.9 RFC 922 Broadcasting Internet datagrams in the presence of subnets | ||||
This specification defines how broadcasts should be treated in the | ||||
presence of subnets. IPv6 uses multicast so this is not applicable. | ||||
3.10 RFC 950 Internet Standard Subnetting Procedure | ||||
This specification defines IPv4 subnetting; similar functionality is | ||||
part of IPv6 addressing architecture to begin with. | ||||
3.11 RFC 1034 Domain Names: Concepts and Facilities | ||||
In Section 3.6, "Resource Records", the definition of A record is: | ||||
RDATA which is the type and sometimes class dependent | ||||
data which describes the resource: | ||||
A For the IN class, a 32 bit IP address | A For the IN class, a 32 bit IP address | |||
In Section 5.2.1. Typical functions defines | And Section 5.2.1, "Typical functions" defines: | |||
1. Host name to host address translation. | 1. Host name to host address translation. | |||
This function is often defined to mimic a previous HOSTS.TXT | This function is often defined to mimic a previous HOSTS.TXT | |||
based function. Given a character string, the caller wants | based function. Given a character string, the caller wants | |||
one or more 32 bit IP addresses. Under the DNS, it | one or more 32 bit IP addresses. Under the DNS, it | |||
translates into a request for type A RRs. Since the DNS does | translates into a request for type A RRs. Since the DNS does | |||
not preserve the order of RRs, this function may choose to | not preserve the order of RRs, this function may choose to | |||
sort the returned addresses or select the "best" address if | sort the returned addresses or select the "best" address if | |||
the service returns only one choice to the client. Note that | the service returns only one choice to the client. Note that | |||
a multiple address return is recommended, but a single | a multiple address return is recommended, but a single | |||
address may be the only way to emulate prior HOSTS.TXT | address may be the only way to emulate prior HOSTS.TXT | |||
services. | services. | |||
2. Host address to host name translation | 2. Host address to host name translation | |||
This function will often follow the form of previous | This function will often follow the form of previous | |||
skipping to change at page 10, line ? | skipping to change at page 12, line 48 | |||
This function will often follow the form of previous | This function will often follow the form of previous | |||
functions. Given a 32 bit IP address, the caller wants a | functions. Given a 32 bit IP address, the caller wants a | |||
character string. The octets of the IP address are reversed, | character string. The octets of the IP address are reversed, | |||
used as name components, and suffixed with "IN-ADDR.ARPA". A | 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 | type PTR query is used to get the RR with the primary name of | |||
the host. For example, a request for the host name | the host. For example, a request for the host name | |||
corresponding to IP address 1.2.3.4 looks for PTR RRs for | corresponding to IP address 1.2.3.4 looks for PTR RRs for | |||
domain name "4.3.2.1.IN-ADDR.ARPA". | domain name "4.3.2.1.IN-ADDR.ARPA". | |||
There are, of course, numerous examples of IPv4 addresses scattered | There are, of course, numerous examples of IPv4 addresses scattered | |||
throughout the document. There is currently a large debate ongoing | throughout the document. | |||
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. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
3.02.2 RFC 1035 DOMAIN NAMES - IMPLEMENTATION AND SPECIFICATION | 3.12 RFC 1035 Domain Names: Implementation and Specification | |||
Section 3.4.1. A RDATA format defines the format for A records: | Section 3.4.1, "A RDATA format", defines the format for A records: | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
| ADDRESS | | | ADDRESS | | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
where: | where: | |||
ADDRESS A 32 bit Internet address. | ADDRESS A 32 bit Internet address. | |||
Hosts that have multiple Internet addresses will have | Hosts that have multiple Internet addresses will have | |||
multiple A records. | multiple A records. | |||
A records cause no additional section processing. The | A records cause no additional section processing. The | |||
RDATA section of an A line in a master file is an Internet | RDATA section of an A line in a master file is an Internet | |||
address expressed as four decimal numbers separated by dots | address expressed as four decimal numbers separated by dots | |||
without any imbedded spaces (e.g.,"10.2.0.52" or "192.0.5.6"). | without any imbedded spaces (e.g.,"10.2.0.52" or "192.0.5.6"). | |||
Section 3.4.2. WKS RDATA format | And Section 3.4.2, "WKS RDATA", format is: | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
| ADDRESS | | | ADDRESS | | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
| PROTOCOL | | | | PROTOCOL | | | |||
+--+--+--+--+--+--+--+--+ | | +--+--+--+--+--+--+--+--+ | | |||
| | | | | | |||
/ <BIT MAP> / | / <BIT MAP> / | |||
/ / | / / | |||
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | |||
where: | where: | |||
ADDRESS An 32 bit Internet address | ADDRESS An 32 bit Internet address | |||
PROTOCOL An 8 bit IP protocol number | PROTOCOL An 8 bit IP protocol number | |||
<BIT MAP> A variable length bit map. The bit map | <BIT MAP> A variable length bit map. The bit map | |||
skipping to change at page 10, line ? | skipping to change at page 14, line 10 | |||
The WKS record is used to describe the well known services | The WKS record is used to describe the well known services | |||
supported by a particular protocol on a particular internet | supported by a particular protocol on a particular internet | |||
address. The PROTOCOL field specifies an IP protocol number, | address. The PROTOCOL field specifies an IP protocol number, | |||
and the bit map has one bit per port of the specified protocol. | 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. | 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 | If the bit map does not include a bit for a protocol of | |||
interest, that bit is assumed zero. The appropriate values and | interest, that bit is assumed zero. The appropriate values and | |||
mnemonics for ports and protocols are specified in [RFC-1010]. | mnemonics for ports and protocols are specified in [RFC-1010]. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
For example, if PROTOCOL=TCP (6), the 26th bit corresponds to | 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 | 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 | listening on TCP port 25; if zero, SMTP service is not supported | |||
on the specified address. | on the specified address. | |||
The purpose of WKS RRs is to provide availability information for | The purpose of WKS RRs is to provide availability information for | |||
servers for TCP and UDP. If a server supports both TCP and UDP, | servers for TCP and UDP. If a server supports both TCP and UDP, | |||
or has multiple Internet addresses, then multiple WKS RRs are | or has multiple Internet addresses, then multiple WKS RRs are | |||
used. | used. | |||
WKS RRs cause no additional section processing. | WKS RRs cause no additional section processing. | |||
Section 3.5. IN-ADDR.ARPA domain describe reverse DNS lookups and | Section 3.5, "IN-ADDR.ARPA domain", describes reverse DNS lookups and | |||
is clearly IPv4 dependent. | is clearly IPv4 dependent. | |||
There are, of course, numerous examples of IPv4 addresses scattered | There are, of course, numerous examples of IPv4 addresses scattered | |||
throughout the document. | throughout the document. | |||
3.03 RFC 894 Standard for the transmission of IP datagrams over | 3.13 RFC 1042 Standard for the transmission of IP datagrams over IEEE | |||
Ethernet networks | 802 networks | |||
This protocol specifically deals with the transmissions of IPv4 packets | This specification specifically deals with the transmission of IPv4 | |||
over Ethernet. A similar RFC must exist for transmission of IPv6 | packets over IEEE 802 networks. | |||
packets. | ||||
3.04 RFC 895 Standard for the transmission of IP datagrams over | 3.14 RFC 1044 Internet Protocol on Network System's HYPERchannel: | |||
experimental Ethernet networks | Protocol Specification | |||
This protocol specifically deals with the transmissions of IPv4 packets | There are a variety of methods used in this standard to map IPv4 | |||
over Ethernet. It is probably unnecessary to provide an updated RFC | addresses to 32 bits fields in the HYPERchannel headers. This | |||
because of the unlikelihood of the existence of this layer 2 medium. | specification does not support IPv6. | |||
3.05 RFC 1042 Standard for the transmission of IP datagrams over IEEE | 3.15 RFC 1055 Nonstandard for transmission of IP datagrams over serial | |||
802 networks | lines: SLIP | |||
This protocol specifically deals with the transmissions of IPv4 packets | This specification is more of a analysis of the shortcomings of SLIP | |||
over Ethernet. A similar RFC must exist for transmission of IPv6 | which is unsurprising. The introduction of PPP as a general | |||
packets, particularly for 802.5 networks. | replacement of SLIP has made this specification essentially unused. | |||
No update need be considered. | ||||
3.06 RFC 891 DCN Local-Network Protocols | 3.16 RFC 1088 Standard for the transmission of IP datagrams over NetBIOS | |||
networks | ||||
There are many implicit assumptions about the use of IPv4 addresses in | This specification documents a technique to encapsulate IP packets | |||
this document. It is unlikely to require any updates since no DCN | inside NetBIOS packets. | |||
networks are in existence. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 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. | ||||
3.07 RFC 1044 Internet Protocol on Network System's HYPERchannel: | 3.17 RFC 1112 Host Extensions for IP Multicasting | |||
Protocol Specification | ||||
There are a variety of methods used in this standard to map IPv4 | This specification defines IP multicast. Parts of the document are | |||
addresses to 32 bits fields in the HYPERchannel headers. A new | IPv4 dependent. | |||
version of the standard will need to be written do support IPv6 on | ||||
HYPERchannel networks. | ||||
3.08 RFC 1201 Transmitting IP traffic over ARCNET networks | 3.18 RFC 1132 Standard for the transmission of 802.2 packets over IPX | |||
networks | ||||
The major concerns of this RFC with respect to IPv4 addresses occur | There are no IPv4 dependencies in this specification. | |||
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.09 RFC 1055 Nonstandard for transmission of IP datagrams over serial | 3.19 RFC 1201 Transmitting IP traffic over ARCNET networks | |||
lines: | ||||
SLIP | ||||
This RFC is more of a analysis of the shortcomings of SLIP which is | The major concerns of this specification with respect to IPv4 | |||
unsurprising. The introduction of PPP as a general replacement of SLIP | addresses occur in the resolution of ARCnet 8bit addresses to IPv4 | |||
has made this protocol essentially unused. No update need be | addresses in an "ARPlike" method. This is incompatible with IPv6. | |||
considered. | ||||
3.10 RFC 1088 Standard for the transmission of IP datagrams over | 3.20 RFC 1209 The Transmission of IP Datagrams over the SMDS Service | |||
NetBIOS networks | ||||
This RFC documents a technique to encapsulate IP packets inside NetBIOS | This specification defines running IPv4 and ARP over SMDS. The | |||
packets. | methods described could easily be extended to support IPv6 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.11 The Point-to-Point Protocol (PPP). RFC1661, RFC1662 | 3.21 RFC 1390 Transmission of IP and ARP over FDDI Networks | |||
3.11.1 RFC 1661 The Point-to-Point Protocol (PPP) | This specification defines the use of IPv4 address on FDDI networks. | |||
There are numerous IPv4 dependencies in the specification. | ||||
The Point-to-Point Protocol (PPP) | 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.11.2 RFC 1662 PPP in HDLC-like Framing | 3.22 RFC 1661 The Point-to-Point Protocol (PPP) | |||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 3.23 RFC 1662 PPP in HDLC-like Framing | |||
3.12 RFC 1209 The Transmission of IP Datagrams over the SMDS Service | There are no IPv4 dependencies in this specification. | |||
This RFC defines running IPv4 and ARP over SMDS. The methods described | 3.24 RFC 2427 Multiprotocol Interconnect over Frame Relay | |||
could easily be extended to support IPv6 packets, but a new RFC would | ||||
be required. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | There are no IPv4 dependencies in this specification. | |||
4.0 Draft Standards | 4. Draft Standards | |||
Draft Standards represent the penultimate standard level in the IETF. | Draft Standards represent the penultimate standard level in the IETF. | |||
A protocol can only achieve draft standard when there are multiple, | A protocol can only achieve draft standard when there are multiple, | |||
independent, interoperable implementations. Draft Standards are | independent, interoperable implementations. Draft Standards are | |||
usually quite mature and widely used. | usually quite mature and widely used. | |||
4.01 RFC 951 Bootstrap Protocol (BOOTP) | 4.1 RFC 951 Bootstrap Protocol (BOOTP) | |||
This protocol is designed specifically for use with IPv4. A new | This protocol is designed specifically for use with IPv4, for | |||
version will be required to support IPv6. For example: | example: | |||
Section 3. Packet Format | Section 3. Packet Format | |||
All numbers shown are decimal, unless indicated otherwise. The | All numbers shown are decimal, unless indicated otherwise. The | |||
BOOTP packet is enclosed in a standard IP [8] UDP [7] datagram. For | BOOTP packet is enclosed in a standard IP [8] UDP [7] datagram. For | |||
simplicity it is assumed that the BOOTP packet is never fragmented. | simplicity it is assumed that the BOOTP packet is never fragmented. | |||
Any numeric fields shown are packed in 'standard network byte | Any numeric fields shown are packed in 'standard network byte | |||
order', i.e. high order bits are sent first. | order', i.e. high order bits are sent first. | |||
In the IP header of a bootrequest, the client fills in its own IP | 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 | source address if known, otherwise zero. When the server address is | |||
unknown, the IP destination address will be the 'broadcast address' | unknown, the IP destination address will be the 'broadcast address' | |||
255.255.255.255. This address means 'broadcast on the local cable, | 255.255.255.255. This address means 'broadcast on the local cable, | |||
(I don't know my net number)' [4]. | (I don't know my net number)' [4]. | |||
... | ||||
FIELD BYTES DESCRIPTION | FIELD BYTES DESCRIPTION | |||
----- ----- --- | ----- ----- --- | |||
... | ||||
[...] | ||||
ciaddr 4 client IP address; | ciaddr 4 client IP address; | |||
filled in by client in bootrequest if known. | filled in by client in bootrequest if known. | |||
yiaddr 4 'your' (client) IP address; | yiaddr 4 'your' (client) IP address; | |||
filled by server if client doesn't | filled by server if client doesn't | |||
know its own address (ciaddr was 0). | know its own address (ciaddr was 0). | |||
siaddr 4 server IP address; | siaddr 4 server IP address; | |||
returned in bootreply by server. | returned in bootreply by server. | |||
giaddr 4 gateway IP address, | giaddr 4 gateway IP address, | |||
used in optional cross-gateway booting. | used in optional cross-gateway booting. | |||
Since the packet format is a fixed 300 bytes in length, an updated | Since the packet format is a fixed 300 bytes in length, an updated | |||
version of the protocol could easily accommodate an additional 48 bytes | version of the specification could easily accommodate an additional | |||
(4 IPV6 fields of 16 bytes to replace the existing 4 IPv4 fields of | 48 bytes (4 IPv6 fields of 16 bytes to replace the existing 4 IPv4 | |||
4 bytes). | fields of 4 bytes). | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 4.2 RFC 1188 Proposed Standard for the Transmission of IP Datagrams | |||
over FDDI Networks | ||||
4.02 RFC 1191 Path MTU discovery (IP-MTU) | This document is clearly informally superceded by RFC 1390, | |||
"Transmission of IP and ARP over FDDI Networks", even though no | ||||
formal deprecation has been done. Therefore, this specification is | ||||
not considered further in this memo. | ||||
The entire process of PMTU discovery is predicated on the use of the DF | 4.3 RFC 1191 Path MTU discovery | |||
bit in the IPv4 header, an ICMP message (also IPv4 dependent) and TCP | ||||
MSS option. There clearly needs to an PMTUv6 functionality. | ||||
4.03-zzzz RFC 1356 Multiprotocol Interconnect on X.25 and ISDN | 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. This is not compatible with IPv6. | ||||
There are IPv4 dependencies within this RFC. | 4.4 RFC 1356 Multiprotocol Interconnect on X.25 and ISDN | |||
4.04 RFC 1534 Interoperation Between DHCP and BOOTP (DHCP-BOOTP) | Section 3.2 defines an NLPID for IP as follows: | |||
There are no IPv4 dependencies in this protocol. | 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. | ||||
4.05 RFC 1542 Clarifications and Extensions for the Bootstrap Protocol | Clearly a new NLPID would need to be defined for IPv6 packets. | |||
There are no new issues other than those presented in Section 4.01 | 4.5 RFC 1534 Interoperation Between DHCP and BOOTP | |||
above. | ||||
4.06 RFC 1629 Guidelines for OSI NSAP Allocation in the Internet | There are no IPv4 dependencies in this specification. | |||
(OSI-NSAP) | ||||
There are no IPv4 dependencies in this protocol. | 4.6 RFC 1542 Clarifications and Extensions for the Bootstrap Protocol | |||
4.07 RFC 1762 The PPP DECnet Phase IV Control Protocol (DNCP) | There are no new issues other than those presented in Section 4.1. | |||
(PPP-DNCP) | ||||
There are no IPv4 dependencies in this protocol. | 4.7 RFC 1629 Guidelines for OSI NSAP Allocation in the Internet | |||
4.08 RFC 1989 PPP Link Quality Monitoring (PPP-LINK) | There are no IPv4 dependencies in this specification. | |||
There are no IPv4 dependencies in this protocol. | 4.8 RFC 1762 The PPP DECnet Phase IV Control Protocol (DNCP) | |||
4.09 RFC 1990 The PPP Multilink Protocol (MP) (PPP-MP) | There are no IPv4 dependencies in this specification. | |||
Section 5.1.3. Endpoint Discriminator Option defines a Class header | 4.9 RFC 1989 PPP Link Quality Monitoring | |||
field. | ||||
There are no IPv4 dependencies in this specification. | ||||
4.10 RFC 1990 The PPP Multilink Protocol (MP) | ||||
Section 5.1.3, "Endpoint Discriminator Option", defines a Class | ||||
header field: | ||||
Class | Class | |||
The Class field is one octet and indicates the identifier | The Class field is one octet and indicates the identifier | |||
address space. The most up-to-date values of the LCP Endpoint | address space. The most up-to-date values of the LCP Endpoint | |||
Discriminator Class field are specified in the most recent | Discriminator Class field are specified in the most recent | |||
"Assigned Numbers" RFC [7]. Current values are assigned as | "Assigned Numbers" RFC [7]. Current values are assigned as | |||
follows: | follows: | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
0 Null Class | 0 Null Class | |||
1 Locally Assigned Address | 1 Locally Assigned Address | |||
2 Internet Protocol (IP) Address | 2 Internet Protocol (IP) Address | |||
3 IEEE 802.1 Globally Assigned MAC Address | 3 IEEE 802.1 Globally Assigned MAC Address | |||
4 PPP Magic-Number Block | 4 PPP Magic-Number Block | |||
5 Public Switched Network Directory Number | 5 Public Switched Network Directory Number | |||
A new class field needs to be defined by the IANA for IPv6 addresses. | A new class field needs to be defined by the IANA for IPv6 addresses. | |||
4.10 RFC 1994 PPP Challenge Handshake Authentication Protocol | 4.11 RFC 1994 PPP Challenge Handshake Authentication Protocol (CHAP) | |||
(CHAP) (PPP-CHAP) | ||||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
4.11 RFC 2067 IP over HIPPI (IP-HIPPI) | 4.12 RFC 2067 IP over HIPPI | |||
Section 5.1 Packet Formats contains the following excerpt: | Section 5.1, "Packet Formats", contains the following excerpt: | |||
EtherType (16 bits) SHALL be set as defined in Assigned Numbers [8]: | 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). | IP = 2048 ('0800'h), ARP = 2054 ('0806'h), RARP = 32,821 ('8035'h). | |||
Section 5.5 MTU has the following definition: | Section 5.5, "MTU", has the following definition: | |||
The MTU for HIPPI-SC LANs is 65280 bytes. | The MTU for HIPPI-SC LANs is 65280 bytes. | |||
This value was selected because it allows the IP packet to fit in | 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 | 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 | is 40 bytes at the present time; there are 216 bytes of room for | |||
expansion. | expansion. | |||
HIPPI-FP Header 8 bytes | HIPPI-FP Header 8 bytes | |||
HIPPI-LE Header 24 bytes | HIPPI-LE Header 24 bytes | |||
skipping to change at page 11, line 48 | skipping to change at page 20, line 4 | |||
one 64K byte buffer with up to 256 bytes of overhead. The overhead | 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 | is 40 bytes at the present time; there are 216 bytes of room for | |||
expansion. | expansion. | |||
HIPPI-FP Header 8 bytes | HIPPI-FP Header 8 bytes | |||
HIPPI-LE Header 24 bytes | HIPPI-LE Header 24 bytes | |||
IEEE 802.2 LLC/SNAP Headers 8 bytes | IEEE 802.2 LLC/SNAP Headers 8 bytes | |||
Maximum IP packet size (MTU) 65280 bytes | Maximum IP packet size (MTU) 65280 bytes | |||
------------ | ------------ | |||
Total 65320 bytes (64K - 216) | Total 65320 bytes (64K - 216) | |||
This definition is not applicable for IPv6 packets since packets can | This definition is not applicable for IPv6 packets since packets can | |||
be larger than the IPv4 limitation of 65280 bytes. | be larger than the IPv4 limitation of 65280 bytes. | |||
4.12 RFC 2131 Dynamic Host Configuration Protocol (DHCP) | 4.13 RFC 2131 Dynamic Host Configuration Protocol | |||
This version of DHCP is highly assumptive of IPv4. Significant work | ||||
on DHCPv6 has been done and is ongoing. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
4.13 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.14-zzzz RFC 2332 NBMA Next Hop Resolution Protocol (NHRP) | ||||
There are IPv4 dependencies within this RFC. | This version of DHCP is highly assumptive of IPv4. It is not | |||
compatible with IPv6. | ||||
4.15-zzzz RFC 2390 Inverse Address Resolution Protocol (IARP) | 4.14 RFC 2132 DHCP Options and BOOTP Vendor Extensions | |||
There are IPv4 dependencies within this RFC. | This is an extension to an IPv4-only specification. | |||
4.16-zzzz RFC 2427 Multiprotocol Interconnect over Frame Relay | 4.15 RFC 2390 Inverse Address Resolution Protocol | |||
There are IPv4 dependencies within this RFC. | There are no IPv4 dependencies in this specification. | |||
4.17 RFC 2460 Internet Protocol, Version 6 (IPv6) Specification (IPV6) | 4.16 RFC 2460 Internet Protocol, Version 6 (IPv6) Specification | |||
This document defines IPv6 and has no IPv4 issues. | This document defines IPv6 and has no IPv4 issues. | |||
4.18 RFC 2461 Neighbor Discovery for IP Version 6 (IPv6) (IPV6-ND) | 4.17 RFC 2461 Neighbor Discovery for IP Version 6 (IPv6) | |||
This document defines an IPv6 related protocol and has no IPv4 issues. | This document defines an IPv6 related specification and has no IPv4 | |||
issues. | ||||
4.19 RFC 2462 IPv6 Stateless Address Autoconfiguration (IPV6-AUTO) | 4.18 RFC 2462 IPv6 Stateless Address Autoconfiguration | |||
This document defines an IPv6 related protocol and has no IPv4 issues. | This document defines an IPv6 related specification and has no IPv4 | |||
issues. | ||||
4.20 RFC 2463 Internet Control Message Protocol (ICMPv6) for the Internet | 4.19 RFC 2463 Internet Control Message Protocol (ICMPv6) for the | |||
Protocol Version 6 (IPv6) Specification (ICMPv6) | Internet Protocol Version 6 (IPv6) Specification | |||
This document defines an IPv6 related protocol and has no IPv4 issues. | This document defines an IPv6 related specification and has no IPv4 | |||
issues. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 4.20 RFC 3596 DNS Extensions to support IP version 6 | |||
5.0 Proposed Standards | This specification defines the AAAA record for IPv6 as well as PTR | |||
records using the ip6.arpa domain, and as such has no IPv6 issues. | ||||
5. Proposed Standards | ||||
Proposed Standards are introductory level documents. There are no | Proposed Standards are introductory level documents. There are no | |||
requirements for even a single implementation. In many cases Proposed | requirements for even a single implementation. In many cases | |||
are never implemented or advanced in the IETF standards process. They | Proposed are never implemented or advanced in the IETF standards | |||
therefore are often just proposed ideas that are presented to the | process. They therefore are often just proposed ideas that are | |||
Internet community. Sometimes flaws are exposed or they are one of | presented to the Internet community. Sometimes flaws are exposed or | |||
many competing solutions to problems. In these later cases, no | they are one of many competing solutions to problems. In these later | |||
discussion is presented as it would not serve the purpose of this | cases, no discussion is presented as it would not serve the purpose | |||
discussion. | of this discussion. | |||
5.01 RFC 1234 Tunneling IPX traffic through IP networks (IPX-IP) | 5.1 RFC 1234 Tunneling IPX traffic through IP networks | |||
The section "Unicast Address Mappings" has the following text: | The section "Unicast Address Mappings" has the following text: | |||
For implementations of this memo, the first two octets of the host | 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 | number will always be zero and the last four octets will be the | |||
node's four octet IP address. This makes address mapping trivial | node's four octet IP address. This makes address mapping trivial | |||
for unicast transmissions: the first two octets of the host number | for unicast transmissions: the first two octets of the host number | |||
are discarded, leaving the normal four octet IP address. The | are discarded, leaving the normal four octet IP address. The | |||
encapsulation code should use this IP address as the destination | encapsulation code should use this IP address as the destination | |||
address of the UDP/IP tunnel packet. | address of the UDP/IP tunnel packet. | |||
This mapping will not be able to work with IPv6 addresses. | This mapping will not be able to work with IPv6 addresses. | |||
There are also numerous discussions on systems keeping a "peer list" | There are also numerous discussions on systems keeping a "peer list" | |||
to map between IP and IPX addresses. The specifics are not discussed | to map between IP and IPX addresses. The specifics are not discussed | |||
in the document and are left to the individual implementation. | in the document and are left to the individual implementation. | |||
The section "Maximum Transmission Unit" | The section "Maximum Transmission Unit" also has some implications on | |||
IP addressing: | ||||
Although larger IPX packets are possible, the standard maximum | Although larger IPX packets are possible, the standard maximum | |||
transmission unit for IPX is 576 octets. Consequently, 576 octets | transmission unit for IPX is 576 octets. Consequently, 576 octets | |||
is the recommended default maximum transmission unit for IPX packets | is the recommended default maximum transmission unit for IPX packets | |||
being sent with this encapsulation technique. With the eight octet | being sent with this encapsulation technique. With the eight octet | |||
UDP header and the 20 octet IP header, the resulting IP packets will | 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 | be 604 octets long. Note that this is larger than the 576 octet | |||
maximum size IP implementations are required to accept [3]. Any IP | maximum size IP implementations are required to accept [3]. Any IP | |||
implementation supporting this encapsulation technique must be | implementation supporting this encapsulation technique must be | |||
capable of receiving 604 octet IP packets. | capable of receiving 604 octet IP packets. | |||
As improvements in protocols and hardware allow for larger, | As improvements in protocols and hardware allow for larger, | |||
unfragmented IP transmission units, the 576 octet maximum IPX packet | unfragmented IP transmission units, the 576 octet maximum IPX packet | |||
size may become a liability. For this reason, it is recommended | size may become a liability. For this reason, it is recommended | |||
that the IPX maximum transmission unit size be configurable in | that the IPX maximum transmission unit size be configurable in | |||
implementations of this memo. | implementations of this memo. | |||
also has some implications on IP addressing. | 5.2 RFC 1256 ICMP Router Discovery Messages | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
5.02 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.03 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. | This specification defines a mechanism very specific to IPv4. | |||
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 | 5.3 RFC 1277 Encoding Network Addresses to Support Operation over | |||
as: | Non-OSI Lower Layers | |||
_______________________________________________________________________ | Section 4.5, "TCP/IP (RFC 1006) Network Specific Format" describes a | |||
|Part_____|_|_____IDP_________|___________________DSP__________________| | structure that reserves 12 digits for the textual representation of | |||
_ | an IP address. | |||
|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| | ||||
_ | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
This 12 octet field for decimal versions of IP addresses is | This 12 octet field for decimal versions of IP addresses is | |||
insufficient for a decimal version of IPv6 addresses. It is possible | insufficient for a decimal version of IPv6 addresses. It is possible | |||
to define a new encoding using the 20 digit long IP Address + Port + | 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 | Transport Set fields in order to accommodate a binary version of an | |||
IPv6 address, port number and Transport Set. There are several | IPv6 address, port number and Transport Set. There are several | |||
schemes that could be envisioned. | schemes that could be envisioned. | |||
5.04 RFC 1332 The PPP Internet Protocol Control Protocol (IPCP) | 5.4 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. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
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. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | This specification defines a mechanism for devices to assign IPv4 | |||
addresses to PPP clients once PPP negotiation is completed. Section | ||||
3, "IPCP Configuration Options", defines IPCP option types which | ||||
embed the IP address in 4-byte long fields. This is clearly not | ||||
enough for IPv6. | ||||
It is clearly designed to allow new Option Types to be added and should | However, the specification is clearly designed to allow new Option | |||
offer no problems for use with IPv6 once appropriate options have been | Types to be added and Should offer no problems for use with IPv6 once | |||
defined. | appropriate options have been defined. | |||
5.05 RFC 1377 The PPP OSI Network Layer Control Protocol (OSINLCP) | 5.5 RFC 1377 The PPP OSI Network Layer Control Protocol (OSINLCP) | |||
(PPP-OSINLC) | ||||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
5.06 RFC 1378 The PPP AppleTalk Control Protocol (ATCP) (PPP-ATCP) | 5.6 RFC 1378 The PPP AppleTalk Control Protocol (ATCP) | |||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
5.07 RFC 1469 IP Multicast over Token-Ring Local Area Networks | 5.7 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 | This document defines the usage of IPv4 multicast over IEEE 802.5 | |||
Token Ring networks. A new method for IPv6 multicast over these | Token Ring networks. This is not compatible with IPv6. | |||
networks will need to be defined. | ||||
5.08 RFC 1552 The PPP Internetworking Packet Exchange Control | 5.8 RFC 1552 The PPP Internetworking Packet Exchange Control Protocol | |||
Protocol (IPXCP) (IPXCP) | (IPXCP) | |||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
5.09 RFC 1570 PPP LCP Extensions (PPP-LCP) | 5.9 RFC 1570 PPP LCP Extensions | |||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
5.10 RFC 1598 PPP in X.25 PPP-X25 | 5.10 RFC 1598 PPP in X.25 PPP-X25 | |||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
5.11 RFC 1618 PPP over ISDN (PPP-ISDN) | ||||
There are no IPv4 dependencies in this protocol. | 5.11 RFC 1618 PPP over ISDN | |||
5.12 RFC 1663 PPP Reliable Transmission (PPP-TRANS) | There are no IPv4 dependencies in this specification. | |||
There are no IPv4 dependencies in this protocol. | 5.12 RFC 1663 PPP Reliable Transmission | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | There are no IPv4 dependencies in this specification. | |||
5.13 RFC 1752 The Recommendation for the IP Next Generation Protocol | 5.13 RFC 1752 The Recommendation for the IP Next Generation Protocol | |||
(IPNG) | ||||
This document defines a roadmap for IPv6 development and is not | This document defines a roadmap for IPv6 development and is not | |||
relevant to this discussion. | relevant to this discussion. | |||
5.14 RFC 1755 ATM Signaling Support for IP over ATM (ATM) | 5.14 RFC 1755 ATM Signaling Support for IP over ATM | |||
There are no IPv4 dependencies in this protocol. | ||||
5.15 RFC 1763 The PPP Banyan Vines Control Protocol (BVCP) (BVCP) | ||||
There are no IPv4 dependencies in this protocol. | ||||
5.16 RFC 1764 The PPP XNS IDP Control Protocol (XNSCP) (XNSCP) | There are no IPv4 dependencies in this specification. | |||
There are no IPv4 dependencies in this protocol. | 5.15 RFC 1763 The PPP Banyan Vines Control Protocol (BVCP) | |||
5.17 RFC 1886 DNS Extensions to support IP version 6 (DNS-IPV6) | There are no IPv4 dependencies in this specification. | |||
This RFC defines the AAAA record for IPv6 as well as PTR records | 5.16 RFC 1764 The PPP XNS IDP Control Protocol (XNSCP) | |||
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.18 RFC 1973 PPP in Frame Relay (PPP-FRAME) | There are no IPv4 dependencies in this specification. | |||
There are no IPv4 dependencies in this protocol. | 5.17 RFC 1973 PPP in Frame Relay | |||
5.19 RFC 1981 Path MTU Discovery for IP version 6 MTU-IPV6 | There are no IPv4 dependencies in this specification. | |||
This protocol describes an IPv6 related protocol and is not discussed | 5.18 RFC 1981 Path MTU Discovery for IP version 6 | |||
in this document. | ||||
5.20 RFC 1982 Serial Number Arithmetic (SNA) | This specification describes an IPv6 related specification and is not | |||
discussed in this document. | ||||
There are no IPv4 dependencies in this protocol. | 5.19 RFC 1982 Serial Number Arithmetic | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | There are no IPv4 dependencies in this specification. | |||
5.21 RFC 1995 Incremental Zone Transfer in DNS (DNS-IZT) | 5.20 5.21 RFC 1995 Incremental Zone Transfer in DNS | |||
Although the examples used in this document use IPv4 addresses, | Although the examples used in this document use IPv4 addresses, | |||
(i.e. A records) there is nothing in the protocol to preclude | (i.e., A records) there is nothing in the specification to preclude | |||
full and proper functionality using IPv6. | full and proper functionality using IPv6. | |||
5.22 RFC 1996 A Mechanism for Prompt Notification of Zone Changes (DNS | 5.21 RFC 1996 A Mechanism for Prompt Notification of Zone Changes (DNS | |||
NOTIFY) (DNS-NOTIFY) | NOTIFY) | |||
There are no IPv4 dependencies in this protocol. | ||||
5.23 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.24 RFC 2003 IP Encapsulation within IP (IPENCAPIP) | There are no IPv4 dependencies in this specification. | |||
This document is designed for use in IPv4 networks. There are | 5.22 RFC 2003 IP Encapsulation within IP | |||
many referenced to a specified IP version number of 4 and 32-bit | ||||
addresses. An IPv6 Encapsulation within IPv6 is required. | ||||
5.25 RFC 2004 Minimal Encapsulation within IP (MINI-IP) | This document is designed for use in IPv4 networks. There are many | |||
references to a specified IP version number of 4 and 32-bit | ||||
addresses. This is incompatible with IPv6. | ||||
This document is designed for use in IPv4 networks. There are | 5.23 RFC 2004 Minimal Encapsulation within IP | |||
many referenced to a specified IP version number of 4 and 32-bit | ||||
addresses. A Minimal IPv6 Encapsulation within IPv6 is required. | ||||
5.26 RFC 2005 Applicability Statement for IP Mobility Support | This document is designed for use in IPv4 networks. There are many | |||
references to a specified IP version number of 4 and 32-bit | ||||
addresses. This is incompatible with IPv6. | ||||
This RFC documents the interoperation of IPv4 mobility as documented | 5.24 RFC 2005 Applicability Statement for IP Mobility Support | |||
in the preceding 3 section. | ||||
5.27 RFC 2022 Support for Multicast over UNI 3.0/3.1 based ATM | This specification documents the interoperation of IPv4 Mobility | |||
Networks (MULTI-UNI) | Support; this is not relevant to this discussion. | |||
This protocol specifically maps IPv4 multicast and a new version is | 5.25 RFC 2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks | |||
required to support IPv6 multicast. | ||||
5.28 RFC 2043 The PPP SNA Control Protocol (SNACP) (PPP-SNACP) | This specification specifically maps IPv4 multicast in UNI based ATM | |||
networks. This is incompatible with IPv6. | ||||
There are no IPv4 dependencies in this protocol. | 5.26 RFC 2043 The PPP SNA Control Protocol (SNACP) | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | There are no IPv4 dependencies in this specification. | |||
5.29 RFC 2097 The PPP NetBIOS Frames Control Protocol (NBFCP) | 5.27 RFC 2097 The PPP NetBIOS Frames Control Protocol (NBFCP) | |||
(PPP-NBFCP) | ||||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
5.30 RFC 2113 IP Router Alert Option (ROUT-ALERT) | 5.28 RFC 2113 IP Router Alert Option | |||
This document provides a new mechanism for IPv4. It is expected that | This document provides a new mechanism for IPv4. This is incompatible | |||
a similar functionality will be included in IPv6. | with IPv6. | |||
5.31 RFC 2125 The PPP Bandwidth Allocation Protocol (BAP) / The | 5.29 RFC 2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP | |||
PPP Bandwidth Allocation Control Protocol (BACP) (BAP-BACP) | Bandwidth Allocation Control Protocol (BACP) | |||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
5.32 RFC 2136 Dynamic Updates in the Domain Name System (DNS | 5.30 RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE) | |||
UPDATE) (DNS-UPDATE) | ||||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
5.33 RFC 2181 Clarifications to the DNS Specification (DNS-CLAR) | 5.31 RFC 2181 Clarifications to the DNS Specification | |||
There are no IPv4 dependencies in this protocol. The only reference | There are no IPv4 dependencies in this specification. The only | |||
to IP addresses discuss the use of any cast address, so it should be | reference to IP addresses discuss the use of an anycast address, so | |||
assumed that these mechanisms are IPv6 operable. | but one can assume that these techniques are IPv6 operable. | |||
5.34 RFC 2225 Classical IP and ARP over ATM (IP-ATM) | 5.32 RFC 2225 Classical IP and ARP over ATM | |||
>From the many references in this document it is clear that this | 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 is designed for IPv4 only. It is only later in the document | |||
document that it is implicitly stated, as in: | that it is implicitly stated, as in: | |||
ar$spln - length in octets of the source protocol address. Value | ar$spln - length in octets of the source protocol address. Value | |||
range is 0 or 4 (decimal). For IPv4 ar$spln is 4. | range is 0 or 4 (decimal). For IPv4 ar$spln is 4. | |||
ar$tpln - length in octets of the target protocol address. Value | ar$tpln - length in octets of the target protocol address. Value | |||
range is 0 or 4 (decimal). For IPv4 ar$tpln is 4. | range is 0 or 4 (decimal). For IPv4 ar$tpln is 4. | |||
and | ||||
and: | ||||
For backward compatibility with previous implementations, a null | For backward compatibility with previous implementations, a null | |||
IPv4 protocol address may be received with length = 4 and an | IPv4 protocol address may be received with length = 4 and an | |||
allocated address in storage set to the value 0.0.0.0. Receiving | 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 | stations must be liberal in accepting this format of a null IPv4 | |||
address. However, on transmitting an ATMARP or InATMARP packet, a | address. However, on transmitting an ATMARP or InATMARP packet, a | |||
null IPv4 address must only be indicated by the length set to zero | null IPv4 address must only be indicated by the length set to zero | |||
and must have no storage allocated. | and must have no storage allocated. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 5.33 RFC 2226 IP Broadcast over ATM Networks | |||
A new specification for IPv6 must be defined. | ||||
5.35 RFC 2226 IP Broadcast over ATM Networks | ||||
This document is limited to IPv4 multicasting. A new specification | ||||
for IPv6 must be defined. | ||||
5.36 RFC 2236 Internet Group Management Protocol, Version 2 (IGMP) | ||||
This document describes of version of IGMP used for IPv4 multicast. | This document is limited to IPv4 multicasting. This is incompatible | |||
A similar methodology for IPv6 multicast needs to be defined. | with IPv6. | |||
5.37 RFC 2241 DHCP Options for Novell Directory Services | 5.34 RFC 2241 DHCP Options for Novell Directory Services | |||
(DHCP-NDS) | ||||
This document defines extensions for the IPv4 only version of | This is an extension to an IPv4-only specification. | |||
DHCP and it is expected that similar options will be present in | ||||
DHCPv6. | ||||
5.38 RFC 2242 NetWare/IP Domain Name and Information (NETWAREIP) | 5.35 RFC 2242 NetWare/IP Domain Name and Information | |||
Once again these are options to the IPv4 version of DHCP. It is | This is an extension to an IPv4-only specification, for example: | |||
expected that similar options will for IPv6 will exist in DHCPv6. | ||||
PREFERRED_DSS (code 6) | PREFERRED_DSS (code 6) | |||
Length is (n * 4) and the value is an array of n IP addresses, | 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 | each four bytes in length. The maximum number of addresses is 5 | |||
and therefore the maximum length value is 20. The list contains | and therefore the maximum length value is 20. The list contains | |||
the addresses of n NetWare Domain SAP/RIP Server (DSS). | the addresses of n NetWare Domain SAP/RIP Server (DSS). | |||
NEAREST_NWIP_SERVER (code 7) | NEAREST_NWIP_SERVER (code 7) | |||
skipping to change at page 21, line 48 | skipping to change at page 26, line 26 | |||
NEAREST_NWIP_SERVER (code 7) | NEAREST_NWIP_SERVER (code 7) | |||
Length is (n * 4) and the value is an array of n IP addresses, | 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 | each four bytes in length. The maximum number of addresses is 5 | |||
and therefore the maximum length value is 20. The list contains | and therefore the maximum length value is 20. The list contains | |||
the addresses of n Nearest NetWare/IP servers. | the addresses of n Nearest NetWare/IP servers. | |||
PRIMARY_DSS (code 11) | PRIMARY_DSS (code 11) | |||
Length of 4, and the value is a single IP address. This field | Length of 4, and the value is a single IP address. This field | |||
identifies the Primary Domain SAP/RIP Service server (DSS) for | identifies the Primary Domain SAP/RIP Service server (DSS) for | |||
this NetWare/IP domain. NetWare/IP administration utility uses | this NetWare/IP domain. NetWare/IP administration utility uses | |||
this value as Primary DSS server when configuring a secondary | this value as Primary DSS server when configuring a secondary | |||
DSS server. | DSS server. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 5.36 RFC 2290 Mobile-IPv4 Configuration Option for PPP IPCP | |||
5.39 RFC 2290 Mobile-IPv4 Configuration Option for PPP IPCP | This document is designed for use with Mobile IPv4. There are | |||
numerous referrals to other IP "support" mechanisms (i.e. ICMP Router | ||||
Discover Messages) that specifically refer to the IPv4 of ICMP. | ||||
This protocol is IPv4 specific. It is expected that similar | 5.37 RFC 2308 Negative Caching of DNS Queries (DNS NCACHE) | |||
methods will be developed for Mobile IPv6. | ||||
5.40 RFC 2308 Negative Caching of DNS Queries (DNS NCACHE) | Although there are numerous examples in this document that use IPv4 | |||
(DNS-NCACHE) | "A" records, there is nothing in the specification that limits its | |||
effectiveness to IPv4. | ||||
Although there are numerous examples in this document that use | 5.38 RFC 2331 ATM Signaling Support for IP over ATM - UNI Signaling 4.0 | |||
IPv4 "A" records, there is nothing in the protocol that limits | Update | |||
its effectiveness to IPv4. | ||||
5.41 RFC 2331 ATM Signaling Support for IP over ATM - UNI Signaling | There are no IPv4 dependencies in this specification. | |||
4.0 Update (UNI-SIG) | ||||
There are no IPv4 dependencies in this protocol. | 5.39 RFC 2332 NBMA Next Hop Resolution Protocol (NHRP) | |||
5.42-zzzz RFC 2333 NHRP Protocol Applicability | 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. | ||||
There are IPv4 dependencies within this RFC. | 5.40 RFC 2333 NHRP Protocol Applicability | |||
5.43-zzzz RFC 2335 A Distributed NHRP Service Using SCSP | 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. | ||||
There are IPv4 dependencies within this RFC. | 5.41 RFC 2335 A Distributed NHRP Service Using SCSP | |||
5.44 RFC 2363 PPP Over FUNI (PPP-FUNI) | There are no IPv4 dependencies in this specification. | |||
There are no IPv4 dependencies in this protocol. | 5.42 RFC 2363 PPP Over FUNI | |||
5.45 RFC 2364 PPP Over AAL5 (PPP-AAL) | There are no IPv4 dependencies in this specification. | |||
There are no IPv4 dependencies in this protocol. | 5.43 RFC 2364 PPP Over AAL5 | |||
5.46 RFC 2371 Transaction Internet Protocol Version 3.0 TIPV3 | There are no IPv4 dependencies in this specification. | |||
5.44 RFC 2371 Transaction Internet Protocol Version 3.0 (TIPV3) | ||||
This document states: | This document states: | |||
TIP transaction manager addresses take the form: | TIP transaction manager addresses take the form: | |||
<hostport><path> | <hostport><path> | |||
The <hostport> component comprises: | The <hostport> component comprises: | |||
<host>[:<port>] | <host>[:<port>] | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
where <host> is either a <dns name> or an <ip address>; and <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 | is a decimal number specifying the port at which the transaction | |||
manager (or proxy) is listening for requests to establish TIP | manager (or proxy) is listening for requests to establish TIP | |||
connections. If the port number is omitted, the standard TIP port | connections. If the port number is omitted, the standard TIP port | |||
number (3372) is used. | number (3372) is used. | |||
A <dns name> is a standard name, acceptable to the domain name | A <dns name> is a standard name, acceptable to the domain name | |||
service. It must be sufficiently qualified to be useful to the | service. It must be sufficiently qualified to be useful to the | |||
receiver of the command. | receiver of the command. | |||
An <ip address> is an IP address, in the usual form: four decimal | An <ip address> is an IP address, in the usual form: four decimal | |||
numbers separated by period characters. | numbers separated by period characters. | |||
and further along it states: | And further along it states: | |||
A TIP URL takes the form: | A TIP URL takes the form: | |||
tip://<transaction manager address>?<transaction string> | tip://<transaction manager address>?<transaction string> | |||
where <transaction manager address> identifies the TIP transaction | where <transaction manager address> identifies the TIP transaction | |||
manager (as defined in Section 7 above); and <transaction string> | manager (as defined in Section 7 above); and <transaction string> | |||
specifies a transaction identifier, which may take one of two forms | specifies a transaction identifier, which may take one of two forms | |||
(standard or non-standard): | (standard or non-standard): | |||
i. "urn:" <NID> ":" <NSS> | i. "urn:" <NID> ":" <NSS> | |||
A standard transaction identifier, conforming to the proposed | A standard transaction identifier, conforming to the proposed | |||
Internet Standard for Uniform Resource Names (URNs), as specified | Internet Standard for Uniform Resource Names (URNs), as specified | |||
by RFC2141; where <NID> is the Namespace Identifier, and <NSS> is | by RFC2141; where <NID> is the Namespace Identifier, and <NSS> is | |||
the Namespace Specific String. The Namespace ID determines the | the Namespace Specific String. The Namespace ID determines the | |||
syntactic interpretation of the Namespace Specific String. The | syntactic interpretation of the Namespace Specific String. The | |||
Namespace Specific String is a sequence of characters representing | Namespace Specific String is a sequence of characters representin | |||
a transaction identifier (as defined by <NID>). The rules for the | a transaction identifier (as defined by <NID>). The rules for the | |||
contents of these fields are specified by [6] (valid characters, | contents of these fields are specified by [6] (valid characters, | |||
encoding, etc.). | encoding, etc.). | |||
This format of <transaction string> may be used to express global | This format of <transaction string> may be used to express global | |||
transaction identifiers in terms of standard representations. | transaction identifiers in terms of standard representations. | |||
Examples for <NID> might be <iso> or <xopen>. e.g. | Examples for <NID> might be <iso> or <xopen>. e.g. | |||
tip://123.123.123.123/?urn:xopen:xid | tip://123.123.123.123/?urn:xopen:xid | |||
Note that Namespace Ids require registration. See [7] for details | Note that Namespace Ids require registration. See [7] for details | |||
on how to do this. | on how to do this. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
ii. <transaction identifier> | ii. <transaction identifier> | |||
A sequence of printable ASCII characters (octets with values in | A sequence of printable ASCII characters (octets with values in | |||
the range 32 through 126 inclusive (excluding ":") representing a | the range 32 through 126 inclusive (excluding ":") representing a | |||
transaction identifier. In this non-standard case, it is the | transaction identifier. In this non-standard case, it is the | |||
combination of <transaction manager address> and <transaction | combination of <transaction manager address> and <transaction | |||
identifier> which ensures global uniqueness. e.g. | identifier> which ensures global uniqueness. e.g. | |||
tip://123.123.123.123/?transid1 | tip://123.123.123.123/?transid1 | |||
It is not hard to assume that the production of an updated protocol | These are incompatible with IPv6. | |||
specification that supports IPv6 could be accomplished. | ||||
5.47 RFC 2373 IP Version 6 Addressing Architecture, | 5.45 RFC 2464 Transmission of IPv6 Packets over Ethernet Networks | |||
This RFC documents IPv6 addressing and is not discussed in this | This specification documents a method for transmitting IPv6 packets | |||
document. | over Ethernet and is not considered in this discussion. | |||
5.48 RFC 2374 An IPv6 Aggregatable Global Unicast Address Format, | 5.46 RFC 2467 Transmission of IPv6 Packets over FDDI Networks | |||
This RFC documents IPv6 addressing and is not discussed in this | This specification documents a method for transmitting IPv6 packets | |||
document. | over FDDI and is not considered in this discussion. | |||
5.49 RFC 2464 Transmission of IPv6 Packets over Ethernet Networks | 5.47 RFC 2470 Transmission of IPv6 Packets over Token Ring Networks | |||
This RFC documents a method for transmitting IPv6 packets over | This specification documents a method for transmitting IPv6 packets | |||
ethernet and is not considered in this discussion. | over Token Ring and is not considered in this discussion. | |||
5.50 RFC 2470 Transmission of IPv6 Packets over Token Ring | 5.48 RFC 2472 IP Version 6 over PPP | |||
Networks | ||||
This RFC documents a method for transmitting IPv6 packets over | This specification documents a method for transmitting IPv6 packets | |||
token ring and is not considered in this discussion. | over PPP and is not considered in this discussion. | |||
5.51 RFC 2472 IP Version 6 over PPP (IPv6-PPP) | 5.49 RFC 2473 Generic Packet Tunneling in IPv6 Specification | |||
This RFC documents a method for transmitting IPv6 packets over | This specification documents an IPv6 aware specification and is not | |||
PPP and is not considered in this discussion. | considered in this discussion. | |||
5.52 RFC 2473 Generic Packet Tunneling in IPv6 Specification | 5.50 RFC 2484 PPP LCP Internationalization Configuration Option | |||
This RFC documents an IPv6 aware protocol and is not considered | There are no IPv4 dependencies in this specification. | |||
in this discussion. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 5.51 RFC 2485 DHCP Option for The Open Group's User Authentication | |||
Protocol | ||||
5.53 RFC 2484 PPP LCP Internationalization Configuration Option | This is an extension to an IPv4-only specification. | |||
There are no IPv4 dependencies in this protocol. | 5.52 RFC 2486 The Network Access Identifier | |||
5.54 RFC 2485 DHCP Option for The Open Group's User | There are no IPv4 dependencies in this specification. | |||
Authentication Protocol | ||||
This document defines extensions for the IPv4 only version of | 5.53 RFC 2491 IPv6 over Non-Broadcast Multiple Access (NBMA) networks | |||
DHCP and it is expected that similar options will be present in | ||||
DHCPv6. | ||||
5.55 RFC 2486 The Network Access Identifier (NAI) | This specification documents a method for transmitting IPv6 packets | |||
over NBMA networks and is not considered in this discussion. | ||||
There are no IPv4 dependencies in this protocol. | 5.54 RFC 2492 IPv6 over ATM Networks | |||
5.56 RFC 2491 IPv6 over Non-Broadcast Multiple Access | This specification documents a method for transmitting IPv6 packets | |||
(NBMA) networks (IPv6-NBMA) | over ATM networks and is not considered in this discussion. | |||
This RFC documents a method for transmitting IPv6 packets over | 5.55 RFC 2497 Transmission of IPv6 Packets over ARCnet Networks | |||
NBMA networks and is not considered in this discussion. | ||||
5.57 RFC 2492 IPv6 over ATM Networks (IPv6ATMNET) | This specification documents a method for transmitting IPv6 packets | |||
over ARCnet networks and is not considered in this discussion. | ||||
This RFC documents a method for transmitting IPv6 packets over | 5.56 RFC 2507 IP Header Compression | |||
ATM networks and is not considered in this discussion. | ||||
5.58 RFC 2497 Transmission of IPv6 Packets over ARCnet | This specification is both IPv4 and IPv6 aware. | |||
Networks | ||||
This RFC documents a method for transmitting IPv6 packets over | 5.57 RFC 2526 Reserved IPv6 Subnet Anycast Addresses | |||
ARCnet networks and is not considered in this discussion. | ||||
5.59 RFC 2507 IP Header Compression | This specification documents IPv6 addressing and is not discussed in | |||
this document. | ||||
This protocol is both IPv4 and IPv6 aware. | 5.58 RFC 2529 Transmission of IPv6 over IPv4 Domains without Explicit | |||
Tunnels | ||||
5.60 RFC 2526 Reserved IPv6 Subnet Anycast Addresses | This specification documents IPv6 transmission methods and is not | |||
discussed in this document. | ||||
This RFC documents IPv6 addressing and is not discussed in this | 5.59 RFC 2563 DHCP Option to Disable Stateless Auto-Configuration in | |||
document. | IPv4 Clients | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | This is an extension to an IPv4-only specification. | |||
5.61 RFC 2529 Transmission of IPv6 over IPv4 Domains without | 5.60 RFC 2590 Transmission of IPv6 Packets over Frame Relay Networks | |||
Explicit Tunnels | Specification | |||
This RFC documents IPv6 transmission methods and is not discussed | This specification documents IPv6 transmission method over Frame | |||
in this document. | Relay and is not discussed in this document. | |||
5.62 RFC 2563 DHCP Option to Disable Stateless Auto-Configuration | 5.61 RFC 2601 ILMI-Based Server Discovery for ATMARP | |||
in IPv4 Clients | ||||
This document is only designated for IPv4. It is expected that | This specification is both IPv4 and IPv6 aware. | |||
similar functionality is available in DHCPv6. | ||||
5.63 RFC 2590 Transmission of IPv6 Packets over Frame Relay | 5.62 RFC 2602 ILMI-Based Server Discovery for MARS | |||
Networks Specification | ||||
This RFC documents IPv6 transmission method over Frame Relay and is | This specification is both IPv4 and IPv6 aware. | |||
not discussed in this document. | ||||
5.64-zzzz RFC 2601 ILMI-Based Server Discovery for ATMARP | 5.63 RFC 2603 ILMI-Based Server Discovery for NHRP | |||
There are IPv4 dependencies within this RFC. | This specification is both IPv4 and IPv6 aware. | |||
5.65-zzzz RFC 2602 ILMI-Based Server Discovery for MARS | 5.64 RFC 2610 DHCP Options for Service Location Protocol | |||
There are IPv4 dependencies within this RFC. | This is an extension to an IPv4-only specification. | |||
5.66-zzzz RFC 2603 ILMI-Based Server Discovery for NHRP | 5.65 RFC 2615 PPP over SONET/SDH | |||
There are IPv4 dependencies within this RFC. | There are no IPv4 dependencies in this specification. | |||
5.67 RFC 2610 DHCP Options for Service Location Protocol | 5.66 RFC 2625 IP and ARP over Fibre Channel | |||
This document is only designated for IPv4. It is expected that | This document states: | |||
similar functionality is available in DHCPv6. | ||||
5.68 RFC 2615 PPP over SONET/SDH | Objective and Scope: | |||
There are no IPv4 dependencies in this protocol. | 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. | ||||
5.69 RFC 2671 Extension Mechanisms for DNS (EDNS0) (EDNS0) | This is incompatible with IPv6. | |||
There are no IPv4 dependencies in this protocol. | 5.67 RFC 2671 Extension Mechanisms for DNS (EDNS0) | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | There are no IPv4 dependencies in this specification. | |||
5.70 RFC 2672 Non-Terminal DNS Name Redirection | 5.68 RFC 2672 Non-Terminal DNS Name Redirection | |||
This document is only defined for IPv4 addresses. A similar | This document is only defined for IPv4 addresses. An IPv6 | |||
specification for IPv6 addresses should be defined. | specification may be needed. | |||
5.71 RFC 2673 Binary Labels in the Domain Name System (DNS) | 5.69 RFC 2673 Binary Labels in the Domain Name System | |||
This document is only defined for IPv4 addresses. A similar | This document is only defined for IPv4 addresses. An IPv6 | |||
specification for IPv6 addresses should be defined. | specification may be needed. | |||
5.72 RFC 2675 IPv6 Jumbograms | 5.70 RFC 2675 IPv6 Jumbograms | |||
This document defines a IPv6 packet format and is therefore not | This document defines a IPv6 packet format and is therefore not | |||
discussed in this document. | discussed in this document. | |||
5.73-zzzz RFC 2684 Multiprotocol Encapsulation over ATM Adaptation | 5.71 RFC 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5 | |||
There are IPv4 dependencies within this RFC. | There are no IPv4 dependencies in this specification. | |||
5.74 RFC 2686 The Multi-Class Extension to Multi-Link PPP | 5.72 RFC 2685 Virtual Private Networks Identifier | |||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
5.75 RFC 2687 PPP in a Real-time Oriented HDLC-like Framing | 5.73 RFC 2686 The Multi-Class Extension to Multi-Link PPP | |||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
5.76 RFC 2688 Integrated Services Mappings for Low Speed Networks | 5.74 RFC 2687 PPP in a Real-time Oriented HDLC-like Framing | |||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
5.77 RFC 2710 Multicast Listener Discovery (MLD) for IPv6 | 5.75 RFC 2688 Integrated Services Mappings for Low Speed Networks | |||
(MLD-IPv6) | ||||
This document defines an IPv6 specific protocol and is not discussed | There are no IPv4 dependencies in this specification. | |||
in this document. | ||||
5.78 RFC 2711 IPv6 Router Alert Option | 5.76 RFC 2710 Multicast Listener Discovery (MLD) for IPv6 | |||
This document defines an IPv6 specific protocol and is not discussed | This document defines an IPv6 specific specification and is not | |||
in this document. | discussed in this document. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 5.77 RFC 2711 IPv6 Router Alert Option | |||
5.79 RFC 2728 The Transmission of IP Over the Vertical Blanking | This document defines an IPv6 specific specification and is not | |||
Interval of a Television Signal | discussed in this document. | |||
5.78 RFC 2728 The Transmission of IP Over the Vertical Blanking Interval | ||||
of a Television Signal | ||||
The following data format is defined: | The following data format is defined: | |||
0 1 2 3 | 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 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) | | |0| group | uncompressed IP header (20 bytes) | | |||
+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+ + | |||
| | | | | | |||
: .... : | : .... : | |||
skipping to change at page 28, line 32 | skipping to change at page 32, line 48 | |||
| | | | | | |||
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| | payload (<1472 bytes) | | | | payload (<1472 bytes) | | |||
+-+-+-+-+-+-+-+-+ + | +-+-+-+-+-+-+-+-+ + | |||
| | | | | | |||
: .... : | : .... : | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| CRC | | | CRC | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
This protocol is IPv4 dependent. Updates must be made to support | This is incompatible with IPv6. | |||
IPv6. | ||||
5.80 RFC 2734 IPv4 over IEEE 1394 | 5.79 RFC 2734 IPv4 over IEEE 1394 | |||
This protocol is IPv4 only. A similar document must be defined for | This specification is IPv4 only. | |||
IPv6. | ||||
5.81-zzzz RFC 2735 NHRP Support for Virtual Private Networks | 5.80 RFC 2735 NHRP Support for Virtual Private Networks | |||
There are IPv4 dependencies within this RFC. | This specification implies only IPv4 operations, but does not seem to | |||
present any reason that it would not function for IPv6. | ||||
5.82 RFC 2765 Stateless IP/ICMP Translation Algorithm (SIIT) | 5.81 RFC 2765 Stateless IP/ICMP Translation Algorithm (SIIT) | |||
(SIIT) | ||||
This protocol defines a method for IPv6 transition and is not | This specification defines a method for IPv6 transition and is not | |||
discussed in this document. | discussed in this document. | |||
5.83 RFC 2766 Network Address Translation - Protocol | 5.82 RFC 2766 Network Address Translation - Protocol Translation | |||
Translation (NAT-PT) (NAT-PT) | (NAT-PT) | |||
This protocol defines a method for IPv6 transition and is not | This specification defines a method for IPv6 transition and is not | |||
discussed in this document. | discussed in this document. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 5.83 RFC 2776 Multicast-Scope Zone Announcement Protocol (MZAP) | |||
5.84 RFC 2776 Multicast-Scope Zone Announcement Protocol (MZAP) | ||||
(MZAP) | ||||
This protocol is both IPv4 and IPv6 aware and needs no changes. | This specification is both IPv4 and IPv6 aware and needs no changes. | |||
5.85 RFC 2782 A DNS RR for specifying the location of services | 5.84 RFC 2782 A DNS RR for specifying the location of services | |||
(DNS-SRV) | ||||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
5.86 RFC 2794 Mobile IP Network Access Identifier Extension for | 5.85 RFC 2794 Mobile IP Network Access Identifier Extension for IPv4 | |||
IPv4 | ||||
This document defines an IPv4 specific protocol and a similar | This is an extension to an IPv4-only specification. | |||
functionality must be defined for Mobile IPv6. | ||||
5.87 RFC 2834 ARP and IP Broadcast over HIPPI-800 | 5.86 RFC 2834 ARP and IP Broadcast over HIPPI-800 | |||
This document uses the generic term "IP Address" in the text but | This document uses the generic term "IP Address" in the text but it | |||
it also contains the text: | also contains the text: | |||
The HARP message has several fields that have the following format | The HARP message has several fields that have the following format | |||
and values: | and values: | |||
Data sizes and field meaning: | Data sizes and field meaning: | |||
ar$hrd 16 bits Hardware type | ar$hrd 16 bits Hardware type | |||
ar$pro 16 bits Protocol type of the protocol fields below | ar$pro 16 bits Protocol type of the protocol fields below | |||
ar$op 16 bits Operation code (request, reply, or NAK) | ar$op 16 bits Operation code (request, reply, or NAK) | |||
ar$pln 8 bits byte length of each protocol address | ar$pln 8 bits byte length of each protocol address | |||
ar$rhl 8 bits requester's HIPPI hardware address length (q) | ar$rhl 8 bits requester's HIPPI hardware address length (q) | |||
skipping to change at page 30, line 4 | skipping to change at page 34, line 31 | |||
ar$hrd - SHALL contain 28. (HIPARP) | ar$hrd - SHALL contain 28. (HIPARP) | |||
ar$pro - SHALL contain the IP protocol code 2048 (decimal). | ar$pro - SHALL contain the IP protocol code 2048 (decimal). | |||
ar$op - SHALL contain the operational value (decimal): | ar$op - SHALL contain the operational value (decimal): | |||
1 for HARP_REQUESTs | 1 for HARP_REQUESTs | |||
2 for HARP_REPLYs | 2 for HARP_REPLYs | |||
8 for InHARP_REQUESTs | 8 for InHARP_REQUESTs | |||
9 for InHARP_REPLYs | 9 for InHARP_REPLYs | |||
10 for HARP_NAK | 10 for HARP_NAK | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
ar$pln - SHALL contain 4. | ar$pln - SHALL contain 4. | |||
and later: | And later: | |||
31 28 23 21 15 10 7 2 0 | 31 28 23 21 15 10 7 2 0 | |||
+-----+---------+-+-+-----------+---------+-----+---------+-----+ | +-----+---------+-+-+-----------+---------+-----+---------+-----+ | |||
0 | 04 |1|0| 000 | 03 | 0 | | 0 | 04 |1|0| 000 | 03 | 0 | | |||
+---------------+-+-+---------------------+---------------+-----+ | +---------------+-+-+---------------------+---------------+-----+ | |||
1 | 45 | | 1 | 45 | | |||
+-----+-+-------+-----------------------+-----------------------+ | +-----+-+-------+-----------------------+-----------------------+ | |||
2 |[LA] |W|MsgT= 0| 000 | Dest. Switch Addr | | 2 |[LA] |W|MsgT= 0| 000 | Dest. Switch Addr | | |||
+-----+-+-------+-----------------------+-----------------------+ | +-----+-+-------+-----------------------+-----------------------+ | |||
3 | 2 | 2 | 000 | Source Switch Addr | | 3 | 2 | 2 | 000 | Source Switch Addr | | |||
skipping to change at page 30, line 53 | skipping to change at page 35, line 29 | |||
+-----------------------------------------------+---------------+ | +-----------------------------------------------+---------------+ | |||
16 | Requester HW Address bytes 7 - q | Tgt HW byte 0 | | 16 | Requester HW Address bytes 7 - q | Tgt HW byte 0 | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
17 | Target HIPPI Hardware Address bytes 1 - 4 | | 17 | Target HIPPI Hardware Address bytes 1 - 4 | | |||
+---------------------------------------------------------------+ | +---------------------------------------------------------------+ | |||
18 | Target HIPPI Hardware Address bytes 5 - 8 | | 18 | Target HIPPI Hardware Address bytes 5 - 8 | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
19 |Tgt HW byte 9-x| FILL | FILL | FILL | | 19 |Tgt HW byte 9-x| FILL | FILL | FILL | | |||
+---------------+---------------+---------------+---------------+ | +---------------+---------------+---------------+---------------+ | |||
HARP - InHARP Message | HARP - InHARP Message | |||
Which make this protocol only IPv4 aware. An update is required to | ||||
support IPv6. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | This is incompatible with IPv6. | |||
5.88 RFC 2835 IP and ARP over HIPPI-6400 (GSN) (GSN) | 5.87 RFC 2835 IP and ARP over HIPPI-6400 | |||
This document states: | This document states: | |||
The Ethertype value SHALL be set as defined in Assigned Numbers [18]: | The Ethertype value SHALL be set as defined in Assigned Numbers | |||
[18]: | ||||
IP 0x0800 2048 (16 bits) | IP 0x0800 2048 (16 bits) | |||
This is IPv4 limited and as expected (after reviewing the previous | This is limited to IPv4, and similar to the previous section, | |||
section) requires an update to support IPv6. There are numerous other | incompatible with IPv6. There are numerous other points in the | |||
points in the documents that confirms this assumption. | documents that confirm this assumption. | |||
5.89 RFC 2855 DHCP for IEEE 1394 | ||||
This document is only designated for IPv4. It is expected that | 5.88 RFC 2855 DHCP for IEEE 1394 | |||
similar functionality is available in DHCPv6. | ||||
5.90 RFC 2874 DNS Extensions to Support IPv6 Address Aggregation | This is an extension to an IPv4-only specification. | |||
and Renumbering | ||||
This document defines a protocol to interact with IPv6 and is not | 5.89 RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and | |||
considered in this document. | Renumbering | |||
This document defines a specification to interact with IPv6 and is | ||||
not considered in this document. | ||||
5.91 RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers | 5.90 RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers | |||
(TRANS-IPV6) | ||||
This document defines a transition mechanism for IPv6 and is not | This document defines a transition mechanism for IPv6 and is not | |||
considered in this document. | considered in this document. | |||
5.92 RFC 2915 The Naming Authority Pointer (NAPTR) DNS Resource | 5.91 RFC 2916 E.164 number and DNS | |||
Record (NAPTR) | ||||
There are no IPv4 dependencies in this protocol. | ||||
5.93 RFC 2916 E.164 number and DNS | ||||
There are no IPv4 dependencies in this protocol. | ||||
5.94 RFC 2937 The Name Service Search Option for DHCP | There are no IPv4 dependencies in this specification. | |||
This document is only designated for IPv4. It is expected that | 5.92 RFC 2937 The Name Service Search Option for DHCP | |||
similar functionality is available in DHCPv6. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | This is an extension to an IPv4-only specification. | |||
5.95 RFC 3004 The User Class Option for DHCP | 5.93 RFC 3004 The User Class Option for DHCP | |||
This document is only designated for IPv4. It is expected that | This is an extension to an IPv4-only specification. | |||
similar functionality is available in DHCPv6. | ||||
5.96 RFC 3011 The IPv4 Subnet Selection Option for DHCP | 5.94 RFC 3011 The IPv4 Subnet Selection Option for DHCP | |||
This document is specifically designed for IPv4. | This is an extension to an IPv4-only specification. | |||
5.97 RFC 3021 Using 31-Bit Prefixes on IPv4 Point-to-Point Links | 5.95 RFC 3021 Using 31-Bit Prefixes for IPv4 P2P Links | |||
This document is IPv4 specific and a similar technique could also | This specification is specific to IPv4 address architecture, where a | |||
be defined for IPv6. | modification was needed to use both addresses of a 31-bit prefix. | |||
This is possible by IPv6 address architecture, but in most cases not | ||||
recommended; see RFC 3627, Use of /127 Prefix Length Between Routers | ||||
Considered Harmful. | ||||
5.98 RFC 3024 Reverse Tunneling for Mobile IP, revised | 5.96 RFC 3024 Reverse Tunneling for Mobile IP, revised | |||
This protocol assumes IPv4 addressing. An updated Mobile IPv6 | This is an extension to an IPv4-only specification. | |||
specification should include this functionality. | ||||
5.99 RFC 3046 DHCP Relay Agent Information Option | 5.97 RFC 3046 DHCP Relay Agent Information Option | |||
This document is only designated for IPv4. It is expected that | This is an extension to an IPv4-only specification. | |||
similar functionality is available in DHCPv6. | ||||
5.100 RFC 3056 Connection of IPv6 Domains via IPv4 Clouds | 5.98 RFC 3056 Connection of IPv6 Domains via IPv4 Clouds | |||
This is an IPv6 related document and is not discussed in this | This is an IPv6 related document and is not discussed in this | |||
document. | document. | |||
5.101 RFC 3068 An Anycast Prefix for 6to4 Relay Routers | 5.99 RFC 3068 An Anycast Prefix for 6to4 Relay Routers | |||
This is an IPv6 related document and is not discussed in this | This is an IPv6 related document and is not discussed in this | |||
document. | document. | |||
5.102 RFC 3074 DHC Load Balancing Algorithm | 5.100 RFC 3074 DHC Load Balancing Algorithm | |||
There are no IPv4 dependencies in this protocol. | ||||
5.103 RFC 3077 A Link-Layer Tunneling Mechanism for Unidirectional | There are no IPv4 dependencies in this specification. | |||
Links | ||||
This protocol is both IPv4 and IPv6 aware and needs no changes. | 5.101 RFC 3077 A Link-Layer Tunneling Mechanism for Unidirectional Links | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | This specification is both IPv4 and IPv6 aware and needs no changes. | |||
5.104 RFC 3115 Mobile IP Vendor/Organization-Specific Extensions | 5.102 RFC 3115 Mobile IP Vendor/Organization-Specific Extensions | |||
This is an enhancement for Mobile IPv4. It is expected that a | This is an extension to an IPv4-only specification. | |||
similar capability will be in Mobile IPv6. | ||||
5.105 RFC 3145 L2TP Disconnect Cause Information | 5.103 RFC 3145 L2TP Disconnect Cause Information | |||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 5.104 RFC 3344 IP Mobility Support for IPv4 | |||
6.0 Experimental RFCs | There are IPv4 dependencies in this specification. | |||
Experimental RFCs typically define protocols that do not have widescale | 5.105 RFC 3376 Internet Group Management Protocol, Version 3 | |||
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.01 RFC 1183 New DNS RR Definitions (DNS-RR) | This document describes of version of IGMP used for IPv4 multicast. | |||
This is not compatible with IPv6. | ||||
There are no IPv4 dependencies in this protocol. | 5.106 RFC 3402 Dynamic Delegation Discovery System (DDDS) Part Two: The | |||
Algorithm | ||||
6.02 RFC 1226 Internet protocol encapsulation of AX.25 frames | There are no IPv4 dependencies in this specification. | |||
(IP-AX.25) | ||||
There are no IPv4 dependencies in this protocol. | 5.107 RFC 3403 Dynamic Delegation Discovery System (DDDS) Part Three: | |||
The Domain Name System (DNS) Database | ||||
6.03 RFC 1241 Scheme for an internet encapsulation protocol: Version | There are no IPv4 dependencies in this specification. | |||
1 (IN-ENCAP) | ||||
This protocol specifies a protocol that assumes IPv4 but does not | 5.108 RFC 3404 Dynamic Delegation Discovery System (DDDS) Part Four: | |||
actually have any limitations which would limit its operation in | The Uniform Resource Identifiers (URI) | |||
an IPv6 environment. | ||||
6.04 RFC 1393 Traceroute Using an IP Option (TRACE-IP) | There are no IPv4 dependencies in this specification. | |||
This document uses an IPv4 option. It is therefore limited to IPv4 | 5.109 RFC 3513 IP Version 6 Addressing Architecture | |||
networks. A different technique must be developed for IPv6. | ||||
6.05 RFC 1433 Directed ARP (DIR-ARP) | This specification documents IPv6 addressing and is not discussed in | |||
this document. | ||||
There are no IPv4 dependencies in this protocol. | 5.110 RFC 3518 Point-to-Point Protocol (PPP) Bridging Control Protocol | |||
(BCP) | ||||
6.06 RFC 1464 Using the Domain Name System To Store Arbitrary String | There are no IPv4 dependencies in this specification. | |||
Attributes | ||||
There are no IPv4 dependencies in this protocol. | 6. Experimental RFCs | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 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.07 RFC 1475 TP/IX: The Next Internet (TP-IX) | 6.1 RFC 1149 Standard for the transmission of IP datagrams on avian | |||
carriers | ||||
This document defines IPv7 and has been abandoned by the IETF as a | There are no IPv4 dependencies in this specification. In fact the | |||
feasible design. It is not considered in this document. | flexibility of this specification is such that all versions of IP | |||
should function within its boundaries, presuming that the packets | ||||
remain small enough to be transmitted with the 256 milligrams weight | ||||
limitations. | ||||
6.08 RFC 1561 Use of ISO CLNP in TUBA Environments (CLNP-TUBA) | 6.2 RFC 1183 New DNS RR Definitions | |||
This document defines the use of NSAPA addressing and does not | There are no IPv4 dependencies in this specification. | |||
use any version of IP, so there are no IPv4 dependencies in this | ||||
protocol. | ||||
6.09 RFC 1712 DNS Encoding of Geographical Location (DNS-ENCODE) | 6.3 RFC 1226 Internet protocol encapsulation of AX.25 frames | |||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
6.10 RFC 1735 NBMA Address Resolution Protocol (NARP) (NARP) | 6.4 RFC 1241 Scheme for an internet encapsulation protocol: Version 1 | |||
This document defines a protocol that is IPv4 specific. A new | This specification defines a specification that assumes IPv4 but does | |||
version would need to be documented to support IPv6. | not actually have any limitations which would limit its operation in | |||
an IPv6 environment. | ||||
4. Packet Formats | 6.5 RFC 1307 Dynamically Switched Link Control Protocol | |||
NARP requests and replies are carried in IP packets as protocol type | This specification is IPv4 dependent, for example: | |||
54. This section describes the packet formats of NARP requests and | ||||
replies: | ||||
NARP Request | 3.1 Control Message Format | |||
0 1 2 3 | 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 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 | | | Identifier | Total length | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| 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. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
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 | | | Function | Event Status | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Type | Code | Unused | | | Endpoint 1 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Destination IP address | | | Endpoint 2 | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Source IP address | | | Message | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| NBMA length | NBMA address | | | Body | | |||
+-+-+-+-+-+-+-+-+ | | ||||
| (variable length) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Source and Destination IP Address | Endpoint addresses: 32 bits each | |||
Respectively, these are the IP addresses of the NARP requestor and | ||||
the target terminal for which the NBMA address is desired. | ||||
6.11 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.12 RFC 1788 ICMP Domain Name Messages (ICMP-DM) | The internet addresses of the two communicating parties for | |||
which the link is being prepared. | ||||
This protocol is used for updates to the in-addr.arp reverse DNS | 6.6 RFC 1393 Traceroute Using an IP Option | |||
maps, and is limited to IPv4. | ||||
6.13 RFC 1797 Class A Subnet Experiment | This document uses an IPv4 option. It is therefore limited to IPv4 | |||
networks, and is incompatible with IPv6. | ||||
This document is specific to IPv4. | 6.7 RFC 1433 Directed ARP | |||
6.14 RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol | There are no IPv4 dependencies in this specification. | |||
Specification - Version ST2+ (ST2) | ||||
This protocol is IPv4 limited. In fact it is the definition of | 6.8 RFC 1464 Using the Domain Name System To Store Arbitrary String | |||
IPv5. See below. | Attributes | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | There are no IPv4 dependencies in this specification. | |||
Both ST2 and IP apply the same addressing schemes to identify | 6.9 RFC 1475 TP/IX: The Next Internet | |||
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 | This document defines IPv7 and has been abandoned by the IETF as a | |||
feasible design. It is not considered in this document. | ||||
GroupName generation is similar to Stream ID generation. The | 6.10 RFC 1561 Use of ISO CLNP in TUBA Environments | |||
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 | This document defines the use of NSAP addressing and does not use any | |||
fields of the IP header should be filled in according to the same | version of IP, so there are no IPv4 dependencies in this | |||
rules that apply to any other IP packet. Three fields of special | specification. | |||
interest are: | ||||
o Protocol is 5, see [RFC1700], to indicate an ST packet is enclosed, | 6.11 RFC 1712 DNS Encoding of Geographical Location | |||
as opposed to TCP or UDP, for example. | ||||
and | There are no IPv4 dependencies in this specification. | |||
The following permanent IP multicast addresses have been assigned to | 6.12 RFC 1735 NBMA Address Resolution Protocol (NARP) | |||
ST: | ||||
224.0.0.7 All ST routers (intermediate agents) | This document defines a specification that is IPv4 specific, for | |||
224.0.0.8 All ST hosts (agents) | example: | |||
In addition, a block of transient IP multicast addresses, | 4. Packet Formats | |||
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 | NARP requests and replies are carried in IP packets as protocol type | |||
field, a header checksum, a unique id, and the stream origin 32-bit | 54. This section describes the packet formats of NARP requests and | |||
IP address. The unique id and the stream origin 32-bit IP address | replies: | |||
form the stream id (SID). This is shown in Figure 10. Please refer | ||||
to Section 10.6 for an explanation of the notation. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | NARP Request | |||
0 1 2 3 | 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 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 | | | Version | Hop Count | Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| 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 | | | Type | Code | Unused | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| GroupCreationTime | | | Destination IP address | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| GroupInitiatorIPAddress | | | Source IP address | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| Relationship | N | | | NBMA length | NBMA address | | |||
+-+-+-+-+-+-+-+-+ | | ||||
| (variable length) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 13: Group Parameter | Source and Destination IP Addresses | |||
Respectively, these are the IP addresses of the NARP requestor | ||||
o GroupUniqueID, GroupInitiatorIPAddress, and GroupCreationTime | and the target terminal for which the NBMA address is desired. | |||
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 | And: | |||
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. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | NARP Reply | |||
0 1 2 3 | 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 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 | | | Version | Hop Count | Checksum | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| 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 | | | Type | Code | Unused | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IP Address 1 | | | Destination IP address | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
: ... : | | Source IP address | | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
| IP Address N | | | NBMA length | NBMA address | | |||
+-+-+-+-+-+-+-+-+ | | ||||
| (variable length) | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | |||
Figure 17: RecordRoute | 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. | ||||
o PBytes is the length of the parameter in bytes. Length is | This is incompatible with IPv6. | |||
determined by the agent (target or origin) that first introduces | ||||
the parameter. Once set, the length of the parameter remains | ||||
unchanged. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 6.13 RFC 1768 Host Group Extensions for CLNP Multicasting | |||
o FreeOffset indicates the offset, relative to the start of the | This specification defines multicasting for CLNP, which is not an IP | |||
parameter, for the next IP address to be recorded. When the | protocol, and therefore has no IPv4 dependencies. | |||
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 | 6.14 RFC 1788 ICMP Domain Name Messages | |||
processing this parameter. | ||||
10.3.6 Target and TargetList | This specification is used for updates to the in-addr.arpa reverse | |||
DNS maps, and is limited to IPv4. | ||||
Several control messages use a parameter called TargetList (PCode = | 6.15 RFC 1797 Class A Subnet Experiment | |||
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 | This document is specific to IPv4 address architecture, and as such, | |||
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 | has no IPv6 dependencies. | |||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| Target IP Address | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
| TargetBytes | SAPBytes | SAP : Padding | | ||||
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ||||
Figure 18: Target | 6.16 RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol | |||
Specification - Version ST2+ | ||||
There are many other examples, but it does not serve any purpose to | This specification is IPv4 limited. In fact it is the definition of | |||
include them all. | IPv5. It has been abandoned by the IETF as feasible design, and is | |||
not considered in this discussion. | ||||
6.15 RFC 1868 ARP Extension - UNARP (UNARP) | 6.17 RFC 1868 ARP Extension - UNARP | |||
This protocol specifies IPv4 ARP. It is expected that a similar | This specification defines an extension to IPv4 ARP to delete entries | |||
method should be implemented in IPv6. | from ARP caches on a link. | |||
6.16 RFC 1876 A Means for Expressing Location Information in the | 6.18 RFC 1876 A Means for Expressing Location Information in the Domain | |||
Domain Name System (DNS-LOC) | Name System | |||
This document defines a methodology for applying this technology | This document defines a methodology for applying this technology | |||
which is IPv4 dependent. The protocol itself has no IPv4 | which is IPv4 dependent. The specification itself has no IPv4 | |||
dependencies. | dependencies. | |||
6.17 RFC 1888 OSI NSAPs and IPv6 | 6.19 RFC 1888 OSI NSAPs and IPv6 | |||
This is an IPv6 related document and is not discussed in this | This is an IPv6 related document and is not discussed in this | |||
document. | document. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 6.20 RFC 2009 GPS-Based Addressing and Routing | |||
6.18 RFC 2009 GPS-Based Addressing and Routing (GPS-AR) | ||||
The document states: | The document states: | |||
The future version of IP (IP v6) will certainly have a sufficient | The future version of IP (IP v6) will certainly have a sufficient | |||
number of bits in its addressing space to provide an address for | number of bits in its addressing space to provide an address for | |||
even smaller GPS addressable units. In this proposal, however, we | even smaller GPS addressable units. In this proposal, however, we | |||
assume the current version of IP (IP v4) and we make sure that 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 | manage the addressing space more economically than that. We will | |||
call the smallest GPS addressable unit a GPS-square. | call the smallest GPS addressable unit a GPS-square. | |||
6.19 RFC 2143 Encapsulating IP with the Small Computer System | This specification does not seem to have real IPv4 dependencies. | |||
Interface (IP-SCSI) | ||||
This protocol will only operate using IPv4. As stated in the | 6.21 RFC 2143 Encapsulating IP with the SCSI | |||
This specification will only operate using IPv4. As stated in the | ||||
document: | document: | |||
It was decided that the ten byte header offers the greatest | It was decided that the ten byte header offers the greatest | |||
flexibility for encapsulating version 4 IP datagrams for the | flexibility for encapsulating version 4 IP datagrams for the | |||
following reasons: | following reasons: [...] | |||
6.20 RFC 2345 Domain Names and Company Name Retrieval | This is incompatible with IPv6. | |||
There are no IPv4 dependencies in this protocol. | 6.22 RFC 2345 Domain Names and Company Name Retrieval | |||
6.21-zzzz RFC 2443 A Distributed MARS Service Using SCSP (MARS-SCSP) | There are no IPv4 dependencies in this specification. | |||
There are IPv4 dependencies within this RFC. | 6.23 RFC 2443 A Distributed MARS Service Using SCSP | |||
6.22 RFC 2471 IPv6 Testing Address Allocation | 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.24 RFC 2471 IPv6 Testing Address Allocation | ||||
This is an IPv6 related document and is not discussed in this | This is an IPv6 related document and is not discussed in this | |||
document. | document. | |||
6.23 RFC 2481 A Proposal to add Explicit Congestion Notification | 6.25 RFC 2520 NHRP with Mobile NHCs | |||
(ECN) to IP (ECN-IP) | ||||
This protocol is both IPv4 and IPv6 aware and needs no changes. | This specification is both IPv4 and IPv6 aware and needs no changes. | |||
6.24-zzzz RFC 2520 NHRP with Mobile NHCs | 6.26 RFC 2521 ICMP Security Failures Messages | |||
There are IPv4 dependencies within this RFC. | There are no IPv4 dependencies in this specification. | |||
6.25 RFC 2521 ICMP Security Failures Messages (ICMP-SEC) | 6.27 RFC 2540 Detached Domain Name System (DNS) Information | |||
There are no IPv4 dependencies in this protocol. | There are no IPv4 dependencies in this specification. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 6.28 RFC 2823 PPP over Simple Data Link (SDL) using SONET/SDH with | |||
ATM-like framing | ||||
6.26 RFC 2540 Detached Domain Name System (DNS) Information | There are no IPv4 dependencies in this specification. | |||
(DNS-INFO) | ||||
There are no IPv4 dependencies in this protocol. | 6.29 RFC 3123 A DNS RR Type for Lists of Address Prefixes | |||
6.27 RFC 2770 GLOP Addressing in 233/8 | This specification is both IPv4 and IPv6 aware and needs no changes. | |||
This document is specific to IPv4. | 6.30 RFC 3168 The Addition of Explicit Congestion Notification (ECN) to | |||
IP | ||||
6.28 RFC 2823 PPP over Simple Data Link (SDL) using SONET/SDH with | This specification is both IPv4 and IPv6 aware and needs no changes. | |||
ATM-like framing (PPP-SDL) | ||||
There are no IPv4 dependencies in this protocol. | 6.31 RFC 3180 GLOP Addressing in 233/8 | |||
6.29 RFC 3123 A DNS RR Type for Lists of Address Prefixes (APL RR) | This document is specific to IPv4 multicast addressing. | |||
This protocol is both IPv4 and IPv6 aware and needs no changes. | 7. Summary of the Results | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | In the initial survey of RFCs 52 positives were identified out of a | |||
total of 185, broken down as follows: | ||||
7.0 Summary of Results | Standards 17 of 24 or 70.83% | |||
In the initial survey of RFCs 62 positives were identified out of a | Draft Standards 6 of 20 or 30.00% | |||
total of 159, broken down as follows: | ||||
Standards 16 of 18 or 88.89% | Proposed Standards 22 of 110 or 20.00% | |||
Draft Standards 6 of 16 or 37.50% | ||||
Proposed Standards 35 of 98 or 35.71% | Experimental RFCs 7 of 31 or 22.58% | |||
Experimental RFCs 5 of 27 or 18.52% | ||||
Of those identified many require no action because they document | Of those identified many require no action because they document | |||
outdated and unused protocols, while others are document protocols | outdated and unused protocols, while others are document protocols | |||
that are actively being updated by the appropriate working groups. | that are actively being updated by the appropriate working groups. | |||
Additionally there are many instances of standards that should be | Additionally there are many instances of standards that should be | |||
updated but do not cause any operational impact if they are not | updated but do not cause any operational impact if they are not | |||
updated. The remaining instances are documented below. | updated. | |||
7.1 Standards | 7.1 Standards | |||
7.1.01 STD3 Requirements for Internet Hosts (RFC 1122 ) | 7.1.1 RFC 791 Internet Protocol | |||
RFC 1122 is essentially a requirements document for IPv4 hosts and a | ||||
similar document for IPv6 hosts should be written. | ||||
7.1.02 STD 5 Internet Protocol (RFC 791, 922, 792, & 1122) | ||||
RFC 791 has been updated in the definition of IPv6 in RFC 2460. | RFC 791 has been updated in the definition of IPv6 in RFC 2460. | |||
RFC 922 has been included in the IPv6 Addressing Architecture, RFC | 7.1.2 RFC 792 Internet Control Message Protocol | |||
2373. | ||||
RFC 792 has been updated in the definition of ICMPv6 in RFC 2463. | RFC 792 has been updated in the definition of ICMPv6 in RFC 2463. | |||
RFC 1122 has been updated in the definition of Multicast Listener | 7.1.3 RFC 891 DCN Networks | |||
Discovery in RFC 2710. | ||||
7.1.03 STD 13 Domain Name System (RFCs 1034 & 1035) | ||||
New resource records for IPv6 addresses have been defined (AAAA & A6). | DCN has long since been ceased to be used, so this specification is | |||
no longer relevant. | ||||
7.1.04 STD 41 IP over Ethernet (RFC 894) | 7.1.4 RFC 894 IP over Ethernet | |||
This problem has been fixed by RFC2464, A Method for the Transmission | This problem has been fixed by RFC2464, A Method for the Transmission | |||
of IPv6 Packets over Ethernet Networks. | of IPv6 Packets over Ethernet Networks. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 7.1.5 RFC 895 IP over experimental Ethernets | |||
7.1.05 STD 42 IP over Experimental Ethernets (RFC 895) | ||||
See above section. | ||||
7.1.06 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.07 STD 44 DCN Networks (RFC 891) | ||||
This protocol is no longer used and an updated protocol should not be | ||||
created. | ||||
7.1.08 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.09 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.10 STD 48 IP over Netbios (RFC 1088) | ||||
A new protocol specification for tunneling IPv6 packets through | ||||
Netbios networks should be defined. | ||||
7.1.11 STD 52 IP over SMDS (RFC 1209) | ||||
An updated protocol for the transmission of IPv6 packets over SMDS | ||||
must be written. | ||||
7.2 Draft Standards | ||||
7.2.1 Boot Protocol (RFC 951) | ||||
This problem has been fixed in the DHCPv6 and Auto Configuration | It is believed that experimental Ethernet networks are not being used | |||
protocols of IPv6: RFC 2462: IPv6 Stateless Address Autoconfiguration, | anymore, so the specification is no longer relevant. | |||
and Dynamic Host Configuration Protocol for IPv6 (DHCPv6) currently an | ||||
Internet Draft. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 7.1.6 RFC 922 Broadcasting Internet Datagrams in the Presence of Subnets | |||
7.2.2 Path MTU Discovery (RFC 1191) | Broadcasting is not used in IPv6, but similar functionality has been | |||
included in RFC 3513, IPv6 Addressing Architecture. | ||||
This problem has been fixed in RFC 1981, Path MTU Discovery for IP | 7.1.7 RFC 950 Internet Standard Subnetting Procedure | |||
version 6. | ||||
7.2.3 The PPP Multilink Protocol (RFC 1990) | Broadcasting is not used in IPv6, but similar functionality has been | |||
included in RFC 3513, IPv6 Addressing Architecture. | ||||
A new class identifier for IPv6 packets must be registered with | 7.1.8 RFC 1034 Domain Names: Concepts and Facilities | |||
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.4 IP over HIPPI (RFC 2067) | The problems have been fixed by defining new resource records for | |||
IPv6 addresses. | ||||
An updated protocol for the transmission of IPv6 packets over HIPPI MAY | 7.1.9 RFC 1035 Domain Names: Implementation and Specification | |||
be written. | ||||
7.2.5 DHCP (RFC 2131) | The problems have been fixed by defining new resource records for | |||
IPv6 addresses. | ||||
The problems are being fixed by the work of the DHC WG. Several very | 7.1.10 RFC 1042 IP over IEEE 802 | |||
advanced IDs address all the issues. | ||||
7.2.6 DHCP Options (RFC 2132) | This problem has been fixed by RFC2470, Transmission of IPv6 Packets | |||
over Token Ring Networks. | ||||
The problems are being fixed by the work of the DHC WG. Several very | 7.1.11 RFC 1044 IP over HyperChannel | |||
advanced IDs address all the issues. | ||||
7.3 Proposed Standards | No updated document exists for this specification. It is unclear | |||
whether one is needed. | ||||
7.3.01 Tunneling IPX over IP (RFC 1234) | 7.1.12 RFC 1088 IP over NetBIOS | |||
This problem remains unresolved and a new protocol specification | No updated document exists for this specification. It is unclear | |||
must be created. | whether one is needed. | |||
7.3.02 ICMP Router Discovery (RFC 1256) | 7.1.13 RFC 1112 Host Extensions for IP Multicast | |||
This problem has been resolved in RFC 2461, Neighbor Discovery for | The IPv4-specific parts of RFC 1112 have been updated in RFC 2710, | |||
IP Version 6 (IPv6) | Multicast Listener Discovery for IPv6. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
7.3.03 Encoding Net Addresses to Support Operation Over Non OSI Lower | 7.1.14 RFC 1122 Requirements for Internet Hosts | |||
Layers (RFC 1277) | ||||
This problem is unresolved, but it MAY be resolved with the creation | RFC 1122 is essentially a requirements document for IPv4 hosts. | |||
of a new encoding scheme definition. | Similar work is in progress | |||
(draft-ietf-ipv6-node-requirements-xx.txt). | ||||
7.3.04 PPP Internet Protocol Control Protocol (RFC 1332) | 7.1.15 RFC 1201 IP over ARCNET | |||
This problem has been resolved in RFC 2472, IP Version 6 over PPP. | This problem has been fixed by RFC 2497, A Method for the | |||
Transmission of IPv6 Packets over ARCnet Networks. | ||||
7.3.05 IP Multicast over Token Ring (RFC 1469) | 7.1.16 RFC 1209 IP over SMDS | |||
The functionality of this specification has been essentially covered | No updated document exists for this specification. It is unclear | |||
in RFC 2470, IPv6 over Token Ring in section 8. | whether one is needed. | |||
7.3.06 IP Mobility Support (RFC 2002) | 7.1.17 RFC 1390 Transmission of IP and ARP over FDDI Networks | |||
The problems are being resolved by the Mobile IP WG and there is | This problem has been fixed by RFC 2467, "Transmission of IPv6 | |||
a mature ID (draft-ietf-mobileip-ipv6-15.txt) | Packets over FDDI Networks". | |||
7.3.07 IP Encapsulation within IP (RFC 2003) | 7.2 Draft Standards | |||
This functionality for Mobile IPv6 is accomplished using the Routing | 7.2.1 RFC 951 Bootstrap Protocol (BOOTP) | |||
Header as defined in RFC 2460, Internet Protocol, Version 6 (IPv6) | ||||
Specification. | ||||
7.3.08 Minimal Encapsulation within IP (RFC 2004) | This problem has been fixed by RFC 2462, IPv6 Stateless Address | |||
Autoconfiguration, and RFC3315, Dynamic Host Configuration Protocol | ||||
for IPv6 (DHCPv6). | ||||
See Section 7.3.27 | 7.2.2 RFC 1191 Path MTU Discovery | |||
7.3.09 Applicability Statement for IP Mobility Support (2005) | This problem has been fixed in RFC 1981, Path MTU Discovery for IP | |||
version 6. | ||||
See Section 7.3.26 | 7.2.3 RFC 1356 Multiprotocol Interconnect on X.25 and ISDN | |||
7.3.10 IP Router Alert Option (RFC 2113) | This problem can be fixed by defining a new NLPID for IPv6. Note that | |||
an NLPID has already been defined in RFC 2427, Multiprotocol | ||||
Interconnect over Frame Relay. | ||||
The problems identified are resolved in RFC 2711, IPv6 Router | 7.2.4 RFC 1990 The PPP Multilink Protocol (MP) | |||
Alert Option. | ||||
7.3.11 SLP (RFC 2165) | A new class identifier ("6") for IPv6 packets has been registered | |||
with the IANA by the original author, fixing this problem. | ||||
The problems have been addressed in RFC 3111, Service Location | 7.2.5 RFC 2067 IP over HIPPI | |||
Protocol Modifications for IPv6. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | No updated document exists for this specification. It is unclear | |||
whether one is needed. | ||||
7.3.12 Classical IP & ARP over ATM (RFC 2225) | 7.2.6 RFC 2131 DHCP | |||
The problems have been resolved in RFC 2492, IPv6 over ATM | This problem has been fixed in RFC 3315, Dynamic Host Configuration | |||
Networks. | Protocol for IPv6 (DHCPv6). | |||
7.3.13 IP Broadcast over ATM (RFC 2226) | Further, the consensus of the DHC WG has been that the options | |||
defined for DHCPv4 will not be automatically "carried forward" to | ||||
DHCPv6. Therefore, any further analysis of additionally specified | ||||
DHCPv4 Options has been omitted from this memo. | ||||
The problems have been resolved in RFC 2492, IPv6 over ATM | 7.3 Proposed Standards | |||
Networks. | ||||
7.3.14 IGMPv2 (RFC 2236) | 7.3.1 RFC 1234 Tunneling IPX over IP | |||
The problems have been resolved in RFC 2710, Multicast Listener | No updated document exists for this specification. In practice, the | |||
Discovery (MLD) for IPv6. | similar effect can be achieved by the use of a layer 2 tunneling | |||
protocol. It is unclear whether an updated document is needed. | ||||
7.3.15 DHCP Options for NDS (RFC 2241) | 7.3.2 RFC 1256 ICMP Router Discovery | |||
The problems are being fixed by the work of the DHC WG. Several very | This problem has been resolved in RFC 2461, Neighbor Discovery for IP | |||
advanced IDs address all the issues. | Version 6 (IPv6). | |||
7.3.16 Netware/IP Domain Name and Information (RFC 2242) | 7.3.3 RFC 1277 Encoding Net Addresses to Support Operation Over Non OSI | |||
Lower Layers | ||||
The problems are being fixed by the work of the DHC WG. Several very | No updated document exists for this specification; the problem might | |||
advanced IDs address all the issues. | be resolved by the creation of a new encoding scheme if necessary. It | |||
is unclear whether an update is needed. | ||||
7.3.17 Mobile IPv4 Comfit Options for PPP IPCP (RFC 2290) | 7.3.4 RFC 1332 PPP Internet Protocol Control Protocol (IPCP) | |||
The problems are not being addressed and must be addressed in a new | This problem has been resolved in RFC 2472, IP Version 6 over PPP. | |||
protocol. | ||||
7.3.18 Transaction IP v3 (RFC 2371) | 7.3.5 RFC 1469 IP Multicast over Token Ring | |||
The problems identified are not addressed and a new standard MAY | The functionality of this specification has been essentially covered | |||
be defined. | in RFC 2470, Transmission of IPv6 Packets over Token Ring Networks. | |||
7.3.19 DHCP Option for Open Group User Authentication Protocol | 7.3.6 RFC 2003 IP Encapsulation within IP | |||
(RFC 2485) | ||||
The problems are being fixed by the work of the DHC WG. Several very | This problem has been fixed by defining different IP-in-IP | |||
advanced IDs address all the issues. | encapsulation, for example, RFC 2473, Generic Packet Tunneling in | |||
IPv6 Specification. | ||||
7.3.20 DHCP Option to Disable Stateless Autoconfiguration | 7.3.7 RFC 2004 Minimal Encapsulation within IP | |||
(RFC 2563) | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | ||||
The problems are being fixed by the work of the DHC WG. Several very | No updated document exists for this specification. It is unclear | |||
advanced IDs address all the issues. | whether one is needed. | |||
7.3.21 Non-Terminal DNS Redirection (RFC 2672) | 7.3.8 RFC 2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks | |||
The problems have not been addressed and a new specification MAY | No updated document exists for this specification. It is unclear | |||
be defined. | whether one is needed. | |||
7.3.22 Binary Labels in DNS (RFC 2673) | 7.3.9 RFC 2113 IP Router Alert Option | |||
The problems have not been addressed and a new specification MAY | This problem has been fixed in RFC 2711, IPv6 Router Alert Option. | |||
be defined. | ||||
7.3.23 IP over Vertical Blanking Interval of a TV Signal (RFC 2728) | 7.3.10 RFC 2165 SLP | |||
The problems have not been addressed and a new specification MAY | The problems have been addressed in RFC 3111, Service Location | |||
be defined. | Protocol Modifications for IPv6. | |||
7.3.24 IPv4 over IEEE 1394 (RFC 2734) | 7.3.11 RFC 2225 Classical IP & ARP over ATM | |||
This problem is being addressed by the IPv6 WG and an ID exists | The problems have been resolved in RFC 2492, IPv6 over ATM Networks. | |||
(draft-ietf-ipngwg-ipngwg-1394-02.txt). | ||||
7.3.25 Mobile IP Network Access Identity Extensions for IPv4 | 7.3.12 RFC 2226 IP Broadcast over ATM | |||
(RFC 2794) | ||||
The problems are not being addressed and must be addressed in a new | The problems have been resolved in RFC 2492, IPv6 over ATM Networks. | |||
protocol. | ||||
7.3.26 ARP & IP Broadcasts Over HIPPI 800 (RFC 2834) | 7.3.13 RFC 2371 Transaction IPv3 | |||
The problems are not being addressed and MAY be addressed in a new | No updated document exists for this specification. It is unclear | |||
protocol. | whether one is needed. | |||
7.3.27 ARP & IP Broadcasts Over HIPPI 6400 (RFC 2835) | 7.3.14 RFC 2625 IP and ARP over Fibre Channel | |||
The problems are not being addressed and MAY be addressed in a new | There is work in progress to fix these problems | |||
protocol. | (draft-desanti-ipv6-over-fibre-channel-02.txt). | |||
7.3.28 DHCP for IEEE 1394 (RFC 2855) | 7.3.15 RFC 2672 Non-Terminal DNS Redirection | |||
This problem is being dually addressed by the IPv6 and DHC WGs and IDs | No updated document exists for this specification. It is unclear | |||
exists that address this issue. | whether one is needed. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 7.3.16 RFC 2673 Binary Labels in DNS | |||
7.3.29 DHCP Name Server Search Option (RFC 2937) | No updated document exists for this specification. It is unclear | |||
whether one is needed. | ||||
The problem is being fixed by the work of the DHC WG. Several very | 7.3.17 IP over Vertical Blanking Interval of a TV Signal (RFC 2728) | |||
advanced IDs address all the issues. | ||||
7.3.30 DHCP User Class Option (RFC 3004) | No updated document exists for this specification. It is unclear | |||
whether one is needed. | ||||
The problem is being fixed by the work of the DHC WG. Several very | 7.3.18 RFC 2734 IPv4 over IEEE 1394 | |||
advanced IDs address all the issues. | ||||
7.3.31 IPv4 Subnet Selection DHCP Option (RFC 3011) | This problem has been fixed by RFC 3146, Transmission of IPv6 Packets | |||
Over IEEE 1394 Networks. | ||||
The problem is being fixed by the work of the DHC WG. Several very | 7.3.19 RFC 2834 ARP & IP Broadcasts Over HIPPI 800 | |||
advanced IDs address all the issues. | ||||
7.3.32 Using 31-Bit Prefixes for IPv4 P2P Links (RFC 3021) | No updated document exists for this specification. It is unclear | |||
whether one is needed. | ||||
No action is needed. | 7.3.20 RFC 2835 ARP & IP Broadcasts Over HIPPI 6400 | |||
7.3.33 Reverse Tunneling for Mobile IP (RFC 3024) | No updated document exists for this specification. It is unclear | |||
whether one is needed. | ||||
The problems are not being addressed and must be addressed in a new | 7.3.21 RFC 3344 Mobility Support for IPv4 | |||
protocol. | ||||
7.3.34 DHCP Relay Agent Information Option (RFC 3046) | The problems have been resolved by two upcoming RFCs, already waiting | |||
publication (draft-ietf-mobileip-ipv6-24.txt and | ||||
draft-ietf-mobileip-mipv6-ha-ipsec-06.txt). | ||||
The problem is being fixed by the work of the DHC WG. Several very | Since the first Mobile IPv4 specification in RFC 2002, a number of | |||
advanced IDs address all the issues. | extensions to it have been specified. As all of these depend on on | |||
MIPv4, they have been omitted from further analysis in this memo. | ||||
7.3.35 Mobile IP Vender/Organization Specific Extensions (RFC 3115) | 7.3.22 RFC 3376 Internet Group Management Protocol, Version 3 | |||
The problems are not being addressed and must be addressed in a new | This problem is being fixed by MLDv2 specification | |||
protocol. | (draft-vida-mld-v2-xx.txt). | |||
7.4 Experimental RFCs | 7.4 Experimental RFCs | |||
7.4.1 Traceroute using an IP Option (RFC 1393) | 7.4.1 RFC 1393 Traceroute using an IP Option | |||
This protocol relies on IPv4 and a new protocol standard MAY be | This specification relies on the use of an IPv4 option. No | |||
produced. | replacement document exists, and it is unclear whether one is needed. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 7.4.2 RFC 1307 Dynamically Switched Link Control Protocol | |||
7.4.2 NBMA ARP (RFC 1735) | No updated document exists for this specification. It is unclear | |||
whether one is needed. | ||||
7.4.3 RFC 1735 NBMA Address Resolution Protocol (NARP) | ||||
This functionality has been defined in RFC 2491, IPv6 over | This functionality has been defined in RFC 2491, IPv6 over | |||
Non-Broadcast Multiple Access (NBMA) networks and RFC 2332, NBMA | Non-Broadcast Multiple Access (NBMA) networks and RFC 2332, NBMA Next | |||
Next Hop Resolution Protocol. | Hop Resolution Protocol (NHRP). | |||
7.4.3 ST2+ Protocol (RFC 1819) | 7.4.4 RFC 1788 ICMP Domain Name Messages | |||
This protocol relies on IPv4 and a new protocol standard MAY be | No updated document exists for this specification. However, DNS | |||
produced. | Dynamic Updates should provide similar functionality, so an update | |||
does not seem necessary. | ||||
7.4.4 ARP Extensions (RFC 1868) | 7.4.5 RFC 1868 ARP Extension - UNARP | |||
This protocol relies on IPv4 and a new protocol standard MAY be | This mechanism defined a mechanism to purge ARP caches on a link. | |||
produced. | That functionality already exists in RFC 2461, Neighbor Discovery for | |||
IPv6. | ||||
7.4.5 IP Over SCSI (RFC 2143) | 7.4.6 RFC 2143 IP Over SCSI | |||
This protocol relies on IPv4 and a new protocol standard MAY be | No updated document exists for this specification. It is unclear | |||
produced. | whether one is needed. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | 7.4.7 RFC 3180 GLOP Addressing in 233/8 | |||
8.0 Security Considerations | Similar functionality is provided by RFC 3306, Unicast-Prefix-based | |||
IPv6 Multicast Addresses, and no action is necessary. | ||||
8. Security Considerations | ||||
This memo examines the IPv6-readiness of specifications; this does | This memo examines the IPv6-readiness of specifications; this does | |||
not have security considerations in itself. | not have security considerations in itself. | |||
9.0 References | 9. Acknowledgements | |||
9.1 Normative | ||||
[1] [Survey of IPv4 Addresses in Currently Deployed IETF Standards] | The author would like to acknowledge the support of the Internet | |||
Philip J. Nesser II, Andreas Bergstrom. "Introduction to the | Society in the research and production of this document. Additionally | |||
Survey ", draft-ietf-v6ops-ipv4survey-intro-01.txt | the author would like to thanks his partner in all ways, Wendy M. | |||
IETF work in progress, June 2003 | Nesser. | |||
[2] [Survey of IPv4 Addresses in Currently Deployed IETF Standards] | The editor, Cleveland Mickles, would like to thank Steve Bellovin and | |||
Philip J. Nesser II, Andreas Bergstrom: " IETF Sub-IP Area | Russ Housley for their comments and Pekka Savola for his comments and | |||
Standards ", draft-ietf-v6ops- ipv4survey-subip-01.txt, | guidance during the editing of this document. Additionally he would | |||
IETF work in progress. June 2003, | like to thank his wife, Lesia, for her patient support. | |||
10.0 Acknowledgements | Pekka Savola helped in editing the latest versions of the document. | |||
The author would like to acknowledge the support of the Internet | Normative References | |||
Society in the research and production of this document. | ||||
Additionally the author would like to thanks his partner in all | ||||
ways, Wendy M. Nesser. | ||||
The editor, Cleveland Mickles, would like to thank Steve Bellovin | [1] II, P. and A. Bergstrom, "Introduction to the Survey of IPv4 | |||
and Russ Housley for their comments and Pekka Savola for his comments | Addresses in Currently Deployed IETF Standards", | |||
and guidance during the editing of this document. Additionally the | draft-ietf-v6ops-ipv4survey-intro-04 (work in progress), October | |||
editor would like to thank, his wife, Lesia R. Mickles for her patient | 2003. | |||
support. | ||||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | Authors' Addresses | |||
11.0 Author's Addresses | Cleveland Mickles | |||
Please contact the authors with any questions, comments or suggestions | Reston, VA 20191 | |||
at: | USA | |||
Cleveland Mickles (Primary Editor) | EMail: cmickles.ee88@gtalumni.org | |||
America Online, Inc (owned by AOL Time Warner) | ||||
12100 Sunrise Valley Drive. Phone: +1 703-265-5618 | ||||
Reston, VA 20191, USA Email: micklesc@aol.net | ||||
Philip J. Nesser II (Author) | Philip J. Nesser II | |||
Principal | ||||
Nesser & Nesser Consulting | Nesser & Nesser Consulting | |||
13501 100th Ave NE, #5202 Phone: +1 425 481 4303 | 13501 100th Ave NE, #5202 | |||
Kirkland, WA 98034 Email: phil@nesser.com | Kirkland, WA 98034 | |||
Fax: +1 425 48 | USA | |||
12.0 Intellectual Property Statement | EMail: phil@nesser.com | |||
Intellectual Property Statement | ||||
The IETF takes no position regarding the validity or scope of any | The IETF takes no position regarding the validity or scope of any | |||
intellectual property or other rights that might be claimed to | intellectual property or other rights that might be claimed to | |||
pertain to the implementation or use of the technology described in | pertain to the implementation or use of the technology described in | |||
this document or the extent to which any license under such rights | this document or the extent to which any license under such rights | |||
might or might not be available; neither does it represent that it | might or might not be available; neither does it represent that it | |||
has made any effort to identify any such rights. Information on the | has made any effort to identify any such rights. Information on the | |||
IETF's procedures with respect to rights in standards-track and | IETF's procedures with respect to rights in standards-track and | |||
standards-related documentation can be found in BCP-11. Copies of | standards-related documentation can be found in BCP-11. Copies of | |||
claims of rights made available for publication and any assurances | claims of rights made available for publication and any assurances of | |||
of licenses to be made available, or the result of an attempt made | licenses to be made available, or the result of an attempt made to | |||
to obtain a general license or permission for the use of such | obtain a general license or permission for the use of such | |||
proprietary rights by implementors or users of this specification | proprietary rights by implementors or users of this specification can | |||
can be obtained from the IETF Secretariat. | be obtained from the IETF Secretariat. | |||
The IETF invites any interested party to bring to its attention any | The IETF invites any interested party to bring to its attention any | |||
copyrights, patents or patent applications, or other proprietary | copyrights, patents or patent applications, or other proprietary | |||
rights which may cover technology that may be required to practice | rights which may cover technology that may be required to practice | |||
this standard. Please address the information to the IETF Executive | this standard. Please address the information to the IETF Executive | |||
Director. | Director. | |||
Internet Area: Survey of IPv4 Addresses Currently Deployed Mar. 2003 | Full Copyright Statement | |||
13.0 Full Copyright Statement | ||||
Copyright (C) The Internet Society (2000). All Rights Reserved. | Copyright (C) The Internet Society (2003). All Rights Reserved. | |||
This document and translations of it may be copied and furnished to | This document and translations of it may be copied and furnished to | |||
others, and derivative works that comment on or otherwise explain it | others, and derivative works that comment on or otherwise explain it | |||
or assist in its implementation may be prepared, copied, published | or assist in its implementation may be prepared, copied, published | |||
and distributed, in whole or in part, without restriction of any | and distributed, in whole or in part, without restriction of any | |||
kind, provided that the above copyright notice and this paragraph | kind, provided that the above copyright notice and this paragraph are | |||
are included on all such copies and derivative works. However, this | included on all such copies and derivative works. However, this | |||
document itself may not be modified in any way, such as by removing | document itself may not be modified in any way, such as by removing | |||
the copyright notice or references to the Internet Society or other | the copyright notice or references to the Internet Society or other | |||
Internet organizations, except as needed for the purpose of develop- | Internet organizations, except as needed for the purpose of | |||
ing Internet standards in which case the procedures for copyrights | developing Internet standards in which case the procedures for | |||
defined in the Internet Standards process must be followed, or as | copyrights defined in the Internet Standards process must be | |||
required to translate it into languages other than English. The lim- | followed, or as required to translate it into languages other than | |||
ited permissions granted above are perpetual and will not be revoked | English. | |||
by the Internet Society or its successors or assigns. This document | ||||
and the information contained herein is provided on an "AS IS" basis | The limited permissions granted above are perpetual and will not be | |||
and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DIS- | revoked by the Internet Society or its successors or assignees. | |||
CLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED | ||||
TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT | This document and the information contained herein is provided on an | |||
INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR | "AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING | |||
FITNESS FOR A PARTICULAR PURPOSE. | TASK FORCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING | |||
BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION | ||||
HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF | ||||
MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. | ||||
Acknowledgment | ||||
Funding for the RFC Editor function is currently provided by the | ||||
Internet Society. | ||||
End of changes. | ||||
This html diff was produced by rfcdiff 1.23, available from http://www.levkowetz.com/ietf/tools/rfcdiff/ |