Network Working Group C. Mickles, Ed.
Request for Comments: 3790
Category: Informational P. Nesser, II
Nesser & Nesser Consulting
June 2004
Network Working Group C. Mickles, Ed.
Request for Comments: 3790
Category: Informational P. Nesser, II
Nesser & Nesser Consulting
June 2004
Survey of IPv4 Addresses in Currently Deployed IETF Internet Area Standards Track and Experimental Documents
当前部署的IETF Internet区域标准跟踪和实验文档中IPv4地址的调查
Status of this Memo
本备忘录的状况
This memo provides information for the Internet community. It does not specify an Internet standard of any kind. Distribution of this memo is unlimited.
本备忘录为互联网社区提供信息。它没有规定任何类型的互联网标准。本备忘录的分发不受限制。
Copyright Notice
版权公告
Copyright (C) The Internet Society (2004).
版权所有（C）互联网协会（2004年）。
Abstract
摘要
This document seeks to document all usage of IPv4 addresses in currently deployed IETF Internet Area documented standards. In order to successfully transition from an all IPv4 Internet to an all IPv6 Internet, many interim steps will be taken. One of these steps is the evolution of current protocols that have IPv4 dependencies. It is hoped that these protocols (and their implementations) will be redesigned to be network address independent, but failing that will at least dually support IPv4 and IPv6. To this end, all Standards (Full, Draft, and Proposed) as well as Experimental RFCs will be surveyed and any dependencies will be documented.
本文档旨在记录当前部署的IETF互联网区域文件化标准中IPv4地址的所有使用情况。为了成功地从全IPv4 Internet过渡到全IPv6 Internet，将采取许多临时步骤。其中一个步骤是发展具有IPv4依赖关系的当前协议。人们希望这些协议（及其实现）将被重新设计为与网络地址无关，但如果不能做到这一点，则至少会同时支持IPv4和IPv6。为此，将调查所有标准（完整、草案和提议）以及实验性RFC，并记录任何相关性。
Table of Contents
目录
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Document Organization. . . . . . . . . . . . . . . . . . . . 9
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. RFC 791 Internet Protocol . . . . . . . . . . . . . . 9
3.2. RFC 792 Internet Control Message Protocol . . . . . . 9
3.3. RFC 826 Ethernet Address Resolution Protocol. . . . . 9
3.4. RFC 891 DCN Local-Network Protocols . . . . . . . . . 10
3.5. RFC 894 Standard for the transmission of IP datagrams
over Ethernet networks. . . . . . . . . . . . . . . . 10
3.6. RFC 895 Standard for the transmission of IP datagrams
over experimental Ethernet networks . . . . . . . . . 10
3.7. RFC 903 Reverse Address Resolution Protocol . . . . . 10
3.8. RFC 919 Broadcasting Internet Datagrams . . . . . . . 10
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Document Organization. . . . . . . . . . . . . . . . . . . . 9
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. RFC 791 Internet Protocol . . . . . . . . . . . . . . 9
3.2. RFC 792 Internet Control Message Protocol . . . . . . 9
3.3. RFC 826 Ethernet Address Resolution Protocol. . . . . 9
3.4. RFC 891 DCN Local-Network Protocols . . . . . . . . . 10
3.5. RFC 894 Standard for the transmission of IP datagrams
over Ethernet networks. . . . . . . . . . . . . . . . 10
3.6. RFC 895 Standard for the transmission of IP datagrams
over experimental Ethernet networks . . . . . . . . . 10
3.7. RFC 903 Reverse Address Resolution Protocol . . . . . 10
3.8. RFC 919 Broadcasting Internet Datagrams . . . . . . . 10
3.9. RFC 922 Broadcasting Internet datagrams in the
presence of subnets . . . . . . . . . . . . . . . . . 10
3.10. RFC 950 Internet Standard Subnetting Procedure. . . . 10
3.11. RFC 1034 Domain Names: Concepts and Facilities. . . . 10
3.12. RFC 1035 Domain Names: Implementation and
Specification . . . . . . . . . . . . . . . . . . . . 11
3.13. RFC 1042 Standard for the transmission of IP datagrams
over IEEE 802 networks . . . . . . . . . . . . . . . 13
3.14. RFC 1044 Internet Protocol on Network System's
HYPERchannel: Protocol Specification . . . . . . . . 13
3.15. RFC 1055 Nonstandard for transmission of IP datagrams
over serial lines: SLIP . . . . . . . . . . . . . . . 13
3.16. RFC 1088 Standard for the transmission of IP
datagrams over NetBIOS networks . . . . . . . . . . . 13
3.17. RFC 1112 Host Extensions for IP Multicasting. . . . . 13
3.18. RFC 1132 Standard for the transmission of 802.2
packets over IPX networks . . . . . . . . . . . . . . 13
3.19. RFC 1201 Transmitting IP traffic over ARCNET
networks. . . . . . . . . . . . . . . . . . . . . . . 13
3.20. RFC 1209 The Transmission of IP Datagrams over the
SMDS Service. . . . . . . . . . . . . . . . . . . . . 14
3.21. RFC 1390 Transmission of IP and ARP over FDDI
Networks. . . . . . . . . . . . . . . . . . . . . . . 14
3.22. RFC 1661 The Point-to-Point Protocol (PPP). . . . . . 14
3.23. RFC 1662 PPP in HDLC-like Framing . . . . . . . . . . 14
3.24. RFC 2427 Multiprotocol Interconnect over Frame Relay. 14
4. Draft Standards . . . . . . . . . . . . . . . . . . . . . . 14
4.1. RFC 951 Bootstrap Protocol (BOOTP). . . . . . . . . . 14
4.2. RFC 1188 Proposed Standard for the Transmission of IP
Datagrams over FDDI Networks. . . . . . . . . . . . . 15
4.3. RFC 1191 Path MTU discovery . . . . . . . . . . . . . 15
4.4. RFC 1356 Multiprotocol Interconnect on X.25 and ISDN. 15
4.5. RFC 1534 Interoperation Between DHCP and BOOTP. . . . 16
4.6. RFC 1542 Clarifications and Extensions for the
Bootstrap Protocol. . . . . . . . . . . . . . . . . . 16
4.7. RFC 1629 Guidelines for OSI NSAP Allocation in the
Internet. . . . . . . . . . . . . . . . . . . . . . . 16
4.8. RFC 1762 The PPP DECnet Phase IV Control Protocol
(DNCP). . . . . . . . . . . . . . . . . . . . . . . . 16
4.9. RFC 1989 PPP Link Quality Monitoring. . . . . . . . . 16
4.10. RFC 1990 The PPP Multilink Protocol (MP). . . . . . . 16
4.11. RFC 1994 PPP Challenge Handshake Authentication
Protocol (CHAP) . . . . . . . . . . . . . . . . . . . 17
4.12. RFC 2067 IP over HIPPI. . . . . . . . . . . . . . . . 17
4.13. RFC 2131 Dynamic Host Configuration Protocol. . . . . 17
4.14. RFC 2132 DHCP Options and BOOTP Vendor Extensions . . 17
4.15. RFC 2390 Inverse Address Resolution Protocol. . . . . 17
3.9. RFC 922 Broadcasting Internet datagrams in the
presence of subnets . . . . . . . . . . . . . . . . . 10
3.10. RFC 950 Internet Standard Subnetting Procedure. . . . 10
3.11. RFC 1034 Domain Names: Concepts and Facilities. . . . 10
3.12. RFC 1035 Domain Names: Implementation and
Specification . . . . . . . . . . . . . . . . . . . . 11
3.13. RFC 1042 Standard for the transmission of IP datagrams
over IEEE 802 networks . . . . . . . . . . . . . . . 13
3.14. RFC 1044 Internet Protocol on Network System's
HYPERchannel: Protocol Specification . . . . . . . . 13
3.15. RFC 1055 Nonstandard for transmission of IP datagrams
over serial lines: SLIP . . . . . . . . . . . . . . . 13
3.16. RFC 1088 Standard for the transmission of IP
datagrams over NetBIOS networks . . . . . . . . . . . 13
3.17. RFC 1112 Host Extensions for IP Multicasting. . . . . 13
3.18. RFC 1132 Standard for the transmission of 802.2
packets over IPX networks . . . . . . . . . . . . . . 13
3.19. RFC 1201 Transmitting IP traffic over ARCNET
networks. . . . . . . . . . . . . . . . . . . . . . . 13
3.20. RFC 1209 The Transmission of IP Datagrams over the
SMDS Service. . . . . . . . . . . . . . . . . . . . . 14
3.21. RFC 1390 Transmission of IP and ARP over FDDI
Networks. . . . . . . . . . . . . . . . . . . . . . . 14
3.22. RFC 1661 The Point-to-Point Protocol (PPP). . . . . . 14
3.23. RFC 1662 PPP in HDLC-like Framing . . . . . . . . . . 14
3.24. RFC 2427 Multiprotocol Interconnect over Frame Relay. 14
4. Draft Standards . . . . . . . . . . . . . . . . . . . . . . 14
4.1. RFC 951 Bootstrap Protocol (BOOTP). . . . . . . . . . 14
4.2. RFC 1188 Proposed Standard for the Transmission of IP
Datagrams over FDDI Networks. . . . . . . . . . . . . 15
4.3. RFC 1191 Path MTU discovery . . . . . . . . . . . . . 15
4.4. RFC 1356 Multiprotocol Interconnect on X.25 and ISDN. 15
4.5. RFC 1534 Interoperation Between DHCP and BOOTP. . . . 16
4.6. RFC 1542 Clarifications and Extensions for the
Bootstrap Protocol. . . . . . . . . . . . . . . . . . 16
4.7. RFC 1629 Guidelines for OSI NSAP Allocation in the
Internet. . . . . . . . . . . . . . . . . . . . . . . 16
4.8. RFC 1762 The PPP DECnet Phase IV Control Protocol
(DNCP). . . . . . . . . . . . . . . . . . . . . . . . 16
4.9. RFC 1989 PPP Link Quality Monitoring. . . . . . . . . 16
4.10. RFC 1990 The PPP Multilink Protocol (MP). . . . . . . 16
4.11. RFC 1994 PPP Challenge Handshake Authentication
Protocol (CHAP) . . . . . . . . . . . . . . . . . . . 17
4.12. RFC 2067 IP over HIPPI. . . . . . . . . . . . . . . . 17
4.13. RFC 2131 Dynamic Host Configuration Protocol. . . . . 17
4.14. RFC 2132 DHCP Options and BOOTP Vendor Extensions . . 17
4.15. RFC 2390 Inverse Address Resolution Protocol. . . . . 17
4.16. RFC 2460 Internet Protocol, Version 6 (IPv6)
Specification . . . . . . . . . . . . . . . . . . . . 17
4.17. RFC 2461 Neighbor Discovery for IP Version 6 (IPv6) . 18
4.18. RFC 2462 IPv6 Stateless Address Autoconfiguration . . 18
4.19. RFC 2463 Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6)
Specification. . . . . . . . . . . . . . . . . . . . 18
4.20. RFC 3596 DNS Extensions to support IP version 6 . . . 18
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . 18
5.1. RFC 1234 Tunneling IPX traffic through IP networks. . 18
5.2. RFC 1256 ICMP Router Discovery Messages . . . . . . . 19
5.3. RFC 1277 Encoding Network Addresses to Support
Operation over Non-OSI Lower Layers . . . . . . . . . 19
5.4. RFC 1332 The PPP Internet Protocol Control Protocol
(IPCP). . . . . . . . . . . . . . . . . . . . . . . . 19
5.5. RFC 1377 The PPP OSI Network Layer Control Protocol
(OSINLCP) . . . . . . . . . . . . . . . . . . . . . . 20
5.6. RFC 1378 The PPP AppleTalk Control Protocol (ATCP). . 20
5.7. RFC 1469 IP Multicast over Token-Ring Local Area
Networks. . . . . . . . . . . . . . . . . . . . . . . 20
5.8. RFC 1552 The PPP Internetworking Packet Exchange
Control Protocol (IPXCP). . . . . . . . . . . . . . . 20
5.9. RFC 1570 PPP LCP Extensions . . . . . . . . . . . . . 20
5.10. RFC 1598 PPP in X.25 PPP-X25. . . . . . . . . . . . . 20
5.11. RFC 1618 PPP over ISDN. . . . . . . . . . . . . . . . 20
5.12. RFC 1663 PPP Reliable Transmission. . . . . . . . . . 20
5.13. RFC 1752 The Recommendation for the IP Next
Generation Protocol . . . . . . . . . . . . . . . . . 20
5.14. RFC 1755 ATM Signaling Support for IP over ATM. . . . 20
5.15. RFC 1763 The PPP Banyan Vines Control Protocol (BVCP) 21
5.16. RFC 1764 The PPP XNS IDP Control Protocol (XNSCP) . . 21
5.17. RFC 1973 PPP in Frame Relay . . . . . . . . . . . . . 21
5.18. RFC 1981 Path MTU Discovery for IP version 6. . . . . 21
5.19. RFC 1982 Serial Number Arithmetic . . . . . . . . . . 21
5.20. 5.21 RFC 1995 Incremental Zone Transfer in DNS. . . . 21
5.21. RFC 1996 A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY). . . . . . . . . . . . . . . . . 21
5.22. RFC 2003 IP Encapsulation within IP . . . . . . . . . 21
5.23. RFC 2004 Minimal Encapsulation within IP. . . . . . . 21
5.24. RFC 2005 Applicability Statement for IP Mobility
Support . . . . . . . . . . . . . . . . . . . . . . . 21
5.25. RFC 2022 Support for Multicast over UNI 3.0/3.1 based
ATM Networks. . . . . . . . . . . . . . . . . . . . . 22
5.26. RFC 2043 The PPP SNA Control Protocol (SNACP) . . . . 22
5.27. RFC 2097 The PPP NetBIOS Frames Control Protocol
(NBFCP) . . . . . . . . . . . . . . . . . . . . . . . 22
5.28. RFC 2113 IP Router Alert Option . . . . . . . . . . . 22
4.16. RFC 2460 Internet Protocol, Version 6 (IPv6)
Specification . . . . . . . . . . . . . . . . . . . . 17
4.17. RFC 2461 Neighbor Discovery for IP Version 6 (IPv6) . 18
4.18. RFC 2462 IPv6 Stateless Address Autoconfiguration . . 18
4.19. RFC 2463 Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6)
Specification. . . . . . . . . . . . . . . . . . . . 18
4.20. RFC 3596 DNS Extensions to support IP version 6 . . . 18
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . 18
5.1. RFC 1234 Tunneling IPX traffic through IP networks. . 18
5.2. RFC 1256 ICMP Router Discovery Messages . . . . . . . 19
5.3. RFC 1277 Encoding Network Addresses to Support
Operation over Non-OSI Lower Layers . . . . . . . . . 19
5.4. RFC 1332 The PPP Internet Protocol Control Protocol
(IPCP). . . . . . . . . . . . . . . . . . . . . . . . 19
5.5. RFC 1377 The PPP OSI Network Layer Control Protocol
(OSINLCP) . . . . . . . . . . . . . . . . . . . . . . 20
5.6. RFC 1378 The PPP AppleTalk Control Protocol (ATCP). . 20
5.7. RFC 1469 IP Multicast over Token-Ring Local Area
Networks. . . . . . . . . . . . . . . . . . . . . . . 20
5.8. RFC 1552 The PPP Internetworking Packet Exchange
Control Protocol (IPXCP). . . . . . . . . . . . . . . 20
5.9. RFC 1570 PPP LCP Extensions . . . . . . . . . . . . . 20
5.10. RFC 1598 PPP in X.25 PPP-X25. . . . . . . . . . . . . 20
5.11. RFC 1618 PPP over ISDN. . . . . . . . . . . . . . . . 20
5.12. RFC 1663 PPP Reliable Transmission. . . . . . . . . . 20
5.13. RFC 1752 The Recommendation for the IP Next
Generation Protocol . . . . . . . . . . . . . . . . . 20
5.14. RFC 1755 ATM Signaling Support for IP over ATM. . . . 20
5.15. RFC 1763 The PPP Banyan Vines Control Protocol (BVCP) 21
5.16. RFC 1764 The PPP XNS IDP Control Protocol (XNSCP) . . 21
5.17. RFC 1973 PPP in Frame Relay . . . . . . . . . . . . . 21
5.18. RFC 1981 Path MTU Discovery for IP version 6. . . . . 21
5.19. RFC 1982 Serial Number Arithmetic . . . . . . . . . . 21
5.20. 5.21 RFC 1995 Incremental Zone Transfer in DNS. . . . 21
5.21. RFC 1996 A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY). . . . . . . . . . . . . . . . . 21
5.22. RFC 2003 IP Encapsulation within IP . . . . . . . . . 21
5.23. RFC 2004 Minimal Encapsulation within IP. . . . . . . 21
5.24. RFC 2005 Applicability Statement for IP Mobility
Support . . . . . . . . . . . . . . . . . . . . . . . 21
5.25. RFC 2022 Support for Multicast over UNI 3.0/3.1 based
ATM Networks. . . . . . . . . . . . . . . . . . . . . 22
5.26. RFC 2043 The PPP SNA Control Protocol (SNACP) . . . . 22
5.27. RFC 2097 The PPP NetBIOS Frames Control Protocol
(NBFCP) . . . . . . . . . . . . . . . . . . . . . . . 22
5.28. RFC 2113 IP Router Alert Option . . . . . . . . . . . 22
5.29. RFC 2125 The PPP Bandwidth Allocation Protocol (BAP)
/ The PPP Bandwidth Allocation Control Protocol
(BACP) . . . . . . . . . . . . . . . . . . . . . . . . 22
5.30. RFC 2136 Dynamic Updates in the Domain Name System
(DNS UPDATE). . . . . . . . . . . . . . . . . . . . . 22
5.31. RFC 2181 Clarifications to the DNS Specification. . . 22
5.32. RFC 2225 Classical IP and ARP over ATM. . . . . . . . 22
5.33. RFC 2226 IP Broadcast over ATM Networks . . . . . . . 23
5.34. RFC 2241 DHCP Options for Novell Directory Services . 23
5.35. RFC 2242 NetWare/IP Domain Name and Information . . . 23
5.36. RFC 2290 Mobile-IPv4 Configuration Option for PPP
IPCP. . . . . . . . . . . . . . . . . . . . . . . . . 24
5.37. RFC 2308 Negative Caching of DNS Queries (DNS NCACHE) 24
5.38. RFC 2331 ATM Signaling Support for IP over ATM - UNI
Signaling 4.0 Update. . . . . . . . . . . . . . . . . 24
5.39. RFC 2332 NBMA Next Hop Resolution Protocol (NHRP) . . 24
5.40. RFC 2333 NHRP Protocol Applicability. . . . . . . . . 24
5.41. RFC 2335 A Distributed NHRP Service Using SCSP. . . . 24
5.42. RFC 2363 PPP Over FUNI. . . . . . . . . . . . . . . . 24
5.43. RFC 2364 PPP Over AAL5. . . . . . . . . . . . . . . . 24
5.44. RFC 2371 Transaction Internet Protocol Version 3.0
(TIPV3) . . . . . . . . . . . . . . . . . . . . . . . 25
5.45. RFC 2464 Transmission of IPv6 Packets over Ethernet
Networks. . . . . . . . . . . . . . . . . . . . . . . 26
5.46. RFC 2467 Transmission of IPv6 Packets over FDDI
Networks. . . . . . . . . . . . . . . . . . . . . . . 26
5.47. RFC 2470 Transmission of IPv6 Packets over Token Ring
Networks. . . . . . . . . . . . . . . . . . . . . . . 26
5.48. RFC 2472 IP Version 6 over PPP. . . . . . . . . . . . 26
5.49. RFC 2473 Generic Packet Tunneling in IPv6
Specification . . . . . . . . . . . . . . . . . . . . 26
5.50. RFC 2484 PPP LCP Internationalization Configuration
Option. . . . . . . . . . . . . . . . . . . . . . . . 26
5.51. RFC 2485 DHCP Option for The Open Group's User
Authentication Protocol . . . . . . . . . . . . . . . 27
5.52. RFC 2486 The Network Access Identifier. . . . . . . . 27
5.53. RFC 2491 IPv6 over Non-Broadcast Multiple Access
(NBMA) Networks . . . . . . . . . . . . . . . . . . . 27
5.54. RFC 2492 IPv6 over ATM Networks . . . . . . . . . . . 27
5.55. RFC 2497 Transmission of IPv6 Packets over ARCnet
Networks. . . . . . . . . . . . . . . . . . . . . . . 27
5.56. RFC 2507 IP Header Compression. . . . . . . . . . . . 27
5.57. RFC 2526 Reserved IPv6 Subnet Anycast Addresses . . . 27
5.58. RFC 2529 Transmission of IPv6 over IPv4 Domains
without Explicit Tunnels. . . . . . . . . . . . . . . 27
5.59. RFC 2563 DHCP Option to Disable Stateless
Auto-Configuration in IPv4 Clients. . . . . . . . . . 27
5.29. RFC 2125 The PPP Bandwidth Allocation Protocol (BAP)
/ The PPP Bandwidth Allocation Control Protocol
(BACP) . . . . . . . . . . . . . . . . . . . . . . . . 22
5.30. RFC 2136 Dynamic Updates in the Domain Name System
(DNS UPDATE). . . . . . . . . . . . . . . . . . . . . 22
5.31. RFC 2181 Clarifications to the DNS Specification. . . 22
5.32. RFC 2225 Classical IP and ARP over ATM. . . . . . . . 22
5.33. RFC 2226 IP Broadcast over ATM Networks . . . . . . . 23
5.34. RFC 2241 DHCP Options for Novell Directory Services . 23
5.35. RFC 2242 NetWare/IP Domain Name and Information . . . 23
5.36. RFC 2290 Mobile-IPv4 Configuration Option for PPP
IPCP. . . . . . . . . . . . . . . . . . . . . . . . . 24
5.37. RFC 2308 Negative Caching of DNS Queries (DNS NCACHE) 24
5.38. RFC 2331 ATM Signaling Support for IP over ATM - UNI
Signaling 4.0 Update. . . . . . . . . . . . . . . . . 24
5.39. RFC 2332 NBMA Next Hop Resolution Protocol (NHRP) . . 24
5.40. RFC 2333 NHRP Protocol Applicability. . . . . . . . . 24
5.41. RFC 2335 A Distributed NHRP Service Using SCSP. . . . 24
5.42. RFC 2363 PPP Over FUNI. . . . . . . . . . . . . . . . 24
5.43. RFC 2364 PPP Over AAL5. . . . . . . . . . . . . . . . 24
5.44. RFC 2371 Transaction Internet Protocol Version 3.0
(TIPV3) . . . . . . . . . . . . . . . . . . . . . . . 25
5.45. RFC 2464 Transmission of IPv6 Packets over Ethernet
Networks. . . . . . . . . . . . . . . . . . . . . . . 26
5.46. RFC 2467 Transmission of IPv6 Packets over FDDI
Networks. . . . . . . . . . . . . . . . . . . . . . . 26
5.47. RFC 2470 Transmission of IPv6 Packets over Token Ring
Networks. . . . . . . . . . . . . . . . . . . . . . . 26
5.48. RFC 2472 IP Version 6 over PPP. . . . . . . . . . . . 26
5.49. RFC 2473 Generic Packet Tunneling in IPv6
Specification . . . . . . . . . . . . . . . . . . . . 26
5.50. RFC 2484 PPP LCP Internationalization Configuration
Option. . . . . . . . . . . . . . . . . . . . . . . . 26
5.51. RFC 2485 DHCP Option for The Open Group's User
Authentication Protocol . . . . . . . . . . . . . . . 27
5.52. RFC 2486 The Network Access Identifier. . . . . . . . 27
5.53. RFC 2491 IPv6 over Non-Broadcast Multiple Access
(NBMA) Networks . . . . . . . . . . . . . . . . . . . 27
5.54. RFC 2492 IPv6 over ATM Networks . . . . . . . . . . . 27
5.55. RFC 2497 Transmission of IPv6 Packets over ARCnet
Networks. . . . . . . . . . . . . . . . . . . . . . . 27
5.56. RFC 2507 IP Header Compression. . . . . . . . . . . . 27
5.57. RFC 2526 Reserved IPv6 Subnet Anycast Addresses . . . 27
5.58. RFC 2529 Transmission of IPv6 over IPv4 Domains
without Explicit Tunnels. . . . . . . . . . . . . . . 27
5.59. RFC 2563 DHCP Option to Disable Stateless
Auto-Configuration in IPv4 Clients. . . . . . . . . . 27
5.60. RFC 2590 Transmission of IPv6 Packets over Frame
Relay Networks Specification. . . . . . . . . . . . . 28
5.61. RFC 2601 ILMI-Based Server Discovery for ATMARP . . . 28
5.62. RFC 2602 ILMI-Based Server Discovery for MARS . . . . 28
5.63. RFC 2603 ILMI-Based Server Discovery for NHRP . . . . 28
5.64. RFC 2610 DHCP Options for Service Location Protocol . 28
5.65. RFC 2615 PPP over SONET/SDH . . . . . . . . . . . . . 28
5.66. RFC 2625 IP and ARP over Fibre Channel. . . . . . . . 28
5.67. RFC 2661 Layer Two Tunneling Protocol (L2TP). . . . . 28
5.68. RFC 2671 Extension Mechanisms for DNS (EDNS0) . . . . 28
5.69. RFC 2672 Non-Terminal DNS Name Redirection. . . . . . 29
5.70. RFC 2673 Binary Labels in the Domain Name System. . . 29
5.71. RFC 2675 IPv6 Jumbograms. . . . . . . . . . . . . . . 29
5.72. RFC 2684 Multiprotocol Encapsulation over ATM
Adaptation Layer 5. . . . . . . . . . . . . . . . . . 29
5.73. RFC 2685 Virtual Private Networks Identifier. . . . . 29
5.74. RFC 2686 The Multi-Class Extension to Multi-Link PPP. 29
5.75. RFC 2687 PPP in a Real-time Oriented HDLC-like
Framing . . . . . . . . . . . . . . . . . . . . . . . 29
5.76. RFC 2688 Integrated Services Mappings for Low Speed
Networks. . . . . . . . . . . . . . . . . . . . . . . 29
5.77. RFC 2710 Multicast Listener Discovery (MLD) for IPv6. 29
5.78. RFC 2711 IPv6 Router Alert Option . . . . . . . . . . 29
5.79. RFC 2728 The Transmission of IP Over the Vertical
Blanking Interval of a Television Signal. . . . . . . 30
5.80. RFC 2734 IPv4 over IEEE 1394. . . . . . . . . . . . . 30
5.81. RFC 2735 NHRP Support for Virtual Private Networks. . 30
5.82. RFC 2765 Stateless IP/ICMP Translation Algorithm
(SIIT). . . . . . . . . . . . . . . . . . . . . . . . 30
5.83. RFC 2766 Network Address Translation - Protocol
Translation (NAT-PT). . . . . . . . . . . . . . . . . 30
5.84. RFC 2776 Multicast-Scope Zone Announcement Protocol
(MZAP). . . . . . . . . . . . . . . . . . . . . . . . 31
5.85. RFC 2782 A DNS RR for specifying the location of
services. . . . . . . . . . . . . . . . . . . . . . . 31
5.86. RFC 2794 Mobile IP Network Access Identifier
Extension for IPv4. . . . . . . . . . . . . . . . . . 31
5.87. RFC 2834 ARP and IP Broadcast over HIPPI-800. . . . . 31
5.88. RFC 2835 IP and ARP over HIPPI-6400 . . . . . . . . . 33
5.89. RFC 2855 DHCP for IEEE 1394 . . . . . . . . . . . . . 33
5.90. RFC 2874 DNS Extensions to Support IPv6 Address
Aggregation and Renumbering . . . . . . . . . . . . . 33
5.91. RFC 2893 Transition Mechanisms for IPv6 Hosts and
Routers . . . . . . . . . . . . . . . . . . . . . . . 33
5.92. RFC 2916 E.164 number and DNS . . . . . . . . . . . . 33
5.93. RFC 2937 The Name Service Search Option for DHCP. . . 33
5.94. RFC 3004 The User Class Option for DHCP . . . . . . . 33
5.95. RFC 3011 The IPv4 Subnet Selection Option for DHCP. . 33
5.60. RFC 2590 Transmission of IPv6 Packets over Frame
Relay Networks Specification. . . . . . . . . . . . . 28
5.61. RFC 2601 ILMI-Based Server Discovery for ATMARP . . . 28
5.62. RFC 2602 ILMI-Based Server Discovery for MARS . . . . 28
5.63. RFC 2603 ILMI-Based Server Discovery for NHRP . . . . 28
5.64. RFC 2610 DHCP Options for Service Location Protocol . 28
5.65. RFC 2615 PPP over SONET/SDH . . . . . . . . . . . . . 28
5.66. RFC 2625 IP and ARP over Fibre Channel. . . . . . . . 28
5.67. RFC 2661 Layer Two Tunneling Protocol (L2TP). . . . . 28
5.68. RFC 2671 Extension Mechanisms for DNS (EDNS0) . . . . 28
5.69. RFC 2672 Non-Terminal DNS Name Redirection. . . . . . 29
5.70. RFC 2673 Binary Labels in the Domain Name System. . . 29
5.71. RFC 2675 IPv6 Jumbograms. . . . . . . . . . . . . . . 29
5.72. RFC 2684 Multiprotocol Encapsulation over ATM
Adaptation Layer 5. . . . . . . . . . . . . . . . . . 29
5.73. RFC 2685 Virtual Private Networks Identifier. . . . . 29
5.74. RFC 2686 The Multi-Class Extension to Multi-Link PPP. 29
5.75. RFC 2687 PPP in a Real-time Oriented HDLC-like
Framing . . . . . . . . . . . . . . . . . . . . . . . 29
5.76. RFC 2688 Integrated Services Mappings for Low Speed
Networks. . . . . . . . . . . . . . . . . . . . . . . 29
5.77. RFC 2710 Multicast Listener Discovery (MLD) for IPv6. 29
5.78. RFC 2711 IPv6 Router Alert Option . . . . . . . . . . 29
5.79. RFC 2728 The Transmission of IP Over the Vertical
Blanking Interval of a Television Signal. . . . . . . 30
5.80. RFC 2734 IPv4 over IEEE 1394. . . . . . . . . . . . . 30
5.81. RFC 2735 NHRP Support for Virtual Private Networks. . 30
5.82. RFC 2765 Stateless IP/ICMP Translation Algorithm
(SIIT). . . . . . . . . . . . . . . . . . . . . . . . 30
5.83. RFC 2766 Network Address Translation - Protocol
Translation (NAT-PT). . . . . . . . . . . . . . . . . 30
5.84. RFC 2776 Multicast-Scope Zone Announcement Protocol
(MZAP). . . . . . . . . . . . . . . . . . . . . . . . 31
5.85. RFC 2782 A DNS RR for specifying the location of
services. . . . . . . . . . . . . . . . . . . . . . . 31
5.86. RFC 2794 Mobile IP Network Access Identifier
Extension for IPv4. . . . . . . . . . . . . . . . . . 31
5.87. RFC 2834 ARP and IP Broadcast over HIPPI-800. . . . . 31
5.88. RFC 2835 IP and ARP over HIPPI-6400 . . . . . . . . . 33
5.89. RFC 2855 DHCP for IEEE 1394 . . . . . . . . . . . . . 33
5.90. RFC 2874 DNS Extensions to Support IPv6 Address
Aggregation and Renumbering . . . . . . . . . . . . . 33
5.91. RFC 2893 Transition Mechanisms for IPv6 Hosts and
Routers . . . . . . . . . . . . . . . . . . . . . . . 33
5.92. RFC 2916 E.164 number and DNS . . . . . . . . . . . . 33
5.93. RFC 2937 The Name Service Search Option for DHCP. . . 33
5.94. RFC 3004 The User Class Option for DHCP . . . . . . . 33
5.95. RFC 3011 The IPv4 Subnet Selection Option for DHCP. . 33
5.96. RFC 3021 Using 31-Bit Prefixes for IPv4 P2P Links . . 33
5.97. RFC 3024 Reverse Tunneling for Mobile IP, revised . . 34
5.98. RFC 3046 DHCP Relay Agent Information Option. . . . . 34
5.99. RFC 3056 Connection of IPv6 Domains via IPv4 Clouds . 34
5.100. RFC 3068 An Anycast Prefix for 6to4 Relay Routers . . 34
5.101. RFC 3070 Layer Two Tunneling Protocol (L2TP) over
Frame Relay . . . . . . . . . . . . . . . . . . . . . 34
5.102. RFC 3074 DHC Load Balancing Algorithm . . . . . . . . 34
5.103. RFC 3077 A Link-Layer Tunneling Mechanism for
Unidirectional Links. . . . . . . . . . . . . . . . . 34
5.104. RFC 3115 Mobile IP Vendor/Organization-Specific
Extensions. . . . . . . . . . . . . . . . . . . . . . 34
5.105. RFC 3145 L2TP Disconnect Cause Information. . . . . . 34
5.106. RFC 3344 IP Mobility Support for IPv4 . . . . . . . . 34
5.107. RFC 3376 Internet Group Management Protocol,
Version 3 . . . . . . . . . . . . . . . . . . . . . . 35
5.108. RFC 3402 Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm . . . . . . . . . . . . . . . 35
5.109. RFC 3403 Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database. . 35
5.110. RFC 3513 IP Version 6 Addressing Architecture . . . . 35
5.111. RFC 3518 Point-to-Point Protocol (PPP) Bridging
Control Protocol (BCP). . . . . . . . . . . . . . . . 35
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . 35
6.1. RFC 1149 Standard for the transmission of IP
datagrams on avian carriers . . . . . . . . . . . . . 35
6.2. RFC 1183 New DNS RR Definitions . . . . . . . . . . . 35
6.3. RFC 1226 Internet protocol encapsulation of AX.25
frames. . . . . . . . . . . . . . . . . . . . . . . . 36
6.4. RFC 1241 Scheme for an internet encapsulation
protocol: Version 1 . . . . . . . . . . . . . . . . . 36
6.5. RFC 1307 Dynamically Switched Link Control Protocol . 36
6.6. RFC 1393 Traceroute Using an IP Option. . . . . . . . 36
6.7. RFC 1433 Directed ARP . . . . . . . . . . . . . . . . 36
6.8. RFC 1464 Using the Domain Name System To Store
Arbitrary String Attributes . . . . . . . . . . . . . 37
6.9. RFC 1475 TP/IX: The Next Internet . . . . . . . . . . 37
6.10. RFC 1561 Use of ISO CLNP in TUBA Environments . . . . 37
6.11. RFC 1712 DNS Encoding of Geographical Location. . . . 37
6.12. RFC 1735 NBMA Address Resolution Protocol (NARP). . . 37
6.13. RFC 1768 Host Group Extensions for CLNP Multicasting. 38
6.14. RFC 1788 ICMP Domain Name Messages. . . . . . . . . . 38
6.15. RFC 1797 Class A Subnet Experiment. . . . . . . . . . 38
6.16. RFC 1819 Internet Stream Protocol Version 2 (ST2)
Protocol Specification - Version ST2+ . . . . . . . . 39
6.17. RFC 1868 ARP Extension - UNARP. . . . . . . . . . . . 39
6.18. RFC 1876 A Means for Expressing Location Information
in the Domain Name System . . . . . . . . . . . . . . 39
5.96. RFC 3021 Using 31-Bit Prefixes for IPv4 P2P Links . . 33
5.97. RFC 3024 Reverse Tunneling for Mobile IP, revised . . 34
5.98. RFC 3046 DHCP Relay Agent Information Option. . . . . 34
5.99. RFC 3056 Connection of IPv6 Domains via IPv4 Clouds . 34
5.100. RFC 3068 An Anycast Prefix for 6to4 Relay Routers . . 34
5.101. RFC 3070 Layer Two Tunneling Protocol (L2TP) over
Frame Relay . . . . . . . . . . . . . . . . . . . . . 34
5.102. RFC 3074 DHC Load Balancing Algorithm . . . . . . . . 34
5.103. RFC 3077 A Link-Layer Tunneling Mechanism for
Unidirectional Links. . . . . . . . . . . . . . . . . 34
5.104. RFC 3115 Mobile IP Vendor/Organization-Specific
Extensions. . . . . . . . . . . . . . . . . . . . . . 34
5.105. RFC 3145 L2TP Disconnect Cause Information. . . . . . 34
5.106. RFC 3344 IP Mobility Support for IPv4 . . . . . . . . 34
5.107. RFC 3376 Internet Group Management Protocol,
Version 3 . . . . . . . . . . . . . . . . . . . . . . 35
5.108. RFC 3402 Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm . . . . . . . . . . . . . . . 35
5.109. RFC 3403 Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database. . 35
5.110. RFC 3513 IP Version 6 Addressing Architecture . . . . 35
5.111. RFC 3518 Point-to-Point Protocol (PPP) Bridging
Control Protocol (BCP). . . . . . . . . . . . . . . . 35
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . 35
6.1. RFC 1149 Standard for the transmission of IP
datagrams on avian carriers . . . . . . . . . . . . . 35
6.2. RFC 1183 New DNS RR Definitions . . . . . . . . . . . 35
6.3. RFC 1226 Internet protocol encapsulation of AX.25
frames. . . . . . . . . . . . . . . . . . . . . . . . 36
6.4. RFC 1241 Scheme for an internet encapsulation
protocol: Version 1 . . . . . . . . . . . . . . . . . 36
6.5. RFC 1307 Dynamically Switched Link Control Protocol . 36
6.6. RFC 1393 Traceroute Using an IP Option. . . . . . . . 36
6.7. RFC 1433 Directed ARP . . . . . . . . . . . . . . . . 36
6.8. RFC 1464 Using the Domain Name System To Store
Arbitrary String Attributes . . . . . . . . . . . . . 37
6.9. RFC 1475 TP/IX: The Next Internet . . . . . . . . . . 37
6.10. RFC 1561 Use of ISO CLNP in TUBA Environments . . . . 37
6.11. RFC 1712 DNS Encoding of Geographical Location. . . . 37
6.12. RFC 1735 NBMA Address Resolution Protocol (NARP). . . 37
6.13. RFC 1768 Host Group Extensions for CLNP Multicasting. 38
6.14. RFC 1788 ICMP Domain Name Messages. . . . . . . . . . 38
6.15. RFC 1797 Class A Subnet Experiment. . . . . . . . . . 38
6.16. RFC 1819 Internet Stream Protocol Version 2 (ST2)
Protocol Specification - Version ST2+ . . . . . . . . 39
6.17. RFC 1868 ARP Extension - UNARP. . . . . . . . . . . . 39
6.18. RFC 1876 A Means for Expressing Location Information
in the Domain Name System . . . . . . . . . . . . . . 39
6.19. RFC 1888 OSI NSAPs and IPv6 . . . . . . . . . . . . . 39
6.20. RFC 2009 GPS-Based Addressin and Routing. . . . . . . 39
6.21. RFC 2143 Encapsulating IP with the SCSI . . . . . . . 39
6.22. RFC 2345 Domain Names and Company Name Retrieval. . . 40
6.23. RFC 2443 A Distributed MARS Service Using SCSP. . . . 40
6.24. RFC 2471 IPv6 Testing Address Allocation. . . . . . . 40
6.25. RFC 2520 NHRP with Mobile NHCs. . . . . . . . . . . . 40
6.26. RFC 2521 ICMP Security Failures Messages. . . . . . . 40
6.27. RFC 2540 Detached Domain Name System (DNS)
Information . . . . . . . . . . . . . . . . . . . . . 40
6.28. RFC 2823 PPP over Simple Data Link (SDL) using
SONET/SDH with ATM-like framing . . . . . . . . . . . 40
6.29. RFC 3123 A DNS RR Type for Lists of Address Prefixes. 40
6.30. RFC 3168 The Addition of Explicit Congestion
Notification (ECN) to IP . . . . . . . . . . . . . . 40
6.31. RFC 3180 GLOP Addressing in 233/8 . . . . . . . . . . 40
7. Summary of the Results . . . . . . . . . . . . . . . . . . . 41
7.1. Standards . . . . . . . . . . . . . . . . . . . . . . 41
7.1.1. RFC 791 Internet Protocol . . . . . . . . . . 41
7.1.2. RFC 792 Internet Control Message Protocol . . 41
7.1.3. RFC 891 DCN Networks. . . . . . . . . . . . . 41
7.1.4. RFC 894 IP over Ethernet. . . . . . . . . . . 41
7.1.5. RFC 895 IP over experimental Ethernets. . . . 41
7.1.6. RFC 922 Broadcasting Internet Datagrams in
the Presence of Subnets . . . . . . . . . . . 41
7.1.7. RFC 950 Internet Standard Subnetting
Procedure. . . . . . . . . . . . . . . . . . 42
7.1.8. RFC 1034 Domain Names: Concepts and
Facilities. . . . . . . . . . . . . . . . . . 42
7.1.9. RFC 1035 Domain Names: Implementation and
Specification . . . . . . . . . . . . . . . . 42
7.1.10. RFC 1042 IP over IEEE 802 . . . . . . . . . . 42
7.1.11. RFC 1044 IP over HyperChannel . . . . . . . . 42
7.1.12. RFC 1088 IP over NetBIOS. . . . . . . . . . . 42
7.1.13. RFC 1112 Host Extensions for IP Multicast . . 42
7.1.14. RFC 1122 Requirements for Internet Hosts. . . 42
7.1.15. RFC 1201 IP over ARCNET . . . . . . . . . . . 42
7.1.16. RFC 1209 IP over SMDS . . . . . . . . . . . . 43
7.1.17. RFC 1390 Transmission of IP and ARP over FDDI
Networks. . . . . . . . . . . . . . . . . . . 43
7.2. Draft Standards . . . . . . . . . . . . . . . . . . . 43
7.2.1. RFC 951 Bootstrap Protocol (BOOTP). . . . . . 43
7.2.2. RFC 1191 Path MTU Discovery . . . . . . . . . 43
7.2.3. RFC 1356 Multiprotocol Interconnect on X.25
and ISDN. . . . . . . . . . . . . . . . . . . 43
7.2.4. RFC 1990 The PPP Multilink Protocol (MP). . . 43
7.2.5. RFC 2067 IP over HIPPI. . . . . . . . . . . . 43
7.2.6. RFC 2131 DHCP . . . . . . . . . . . . . . . . 43
6.19. RFC 1888 OSI NSAPs and IPv6 . . . . . . . . . . . . . 39
6.20. RFC 2009 GPS-Based Addressin and Routing. . . . . . . 39
6.21. RFC 2143 Encapsulating IP with the SCSI . . . . . . . 39
6.22. RFC 2345 Domain Names and Company Name Retrieval. . . 40
6.23. RFC 2443 A Distributed MARS Service Using SCSP. . . . 40
6.24. RFC 2471 IPv6 Testing Address Allocation. . . . . . . 40
6.25. RFC 2520 NHRP with Mobile NHCs. . . . . . . . . . . . 40
6.26. RFC 2521 ICMP Security Failures Messages. . . . . . . 40
6.27. RFC 2540 Detached Domain Name System (DNS)
Information . . . . . . . . . . . . . . . . . . . . . 40
6.28. RFC 2823 PPP over Simple Data Link (SDL) using
SONET/SDH with ATM-like framing . . . . . . . . . . . 40
6.29. RFC 3123 A DNS RR Type for Lists of Address Prefixes. 40
6.30. RFC 3168 The Addition of Explicit Congestion
Notification (ECN) to IP . . . . . . . . . . . . . . 40
6.31. RFC 3180 GLOP Addressing in 233/8 . . . . . . . . . . 40
7. Summary of the Results . . . . . . . . . . . . . . . . . . . 41
7.1. Standards . . . . . . . . . . . . . . . . . . . . . . 41
7.1.1. RFC 791 Internet Protocol . . . . . . . . . . 41
7.1.2. RFC 792 Internet Control Message Protocol . . 41
7.1.3. RFC 891 DCN Networks. . . . . . . . . . . . . 41
7.1.4. RFC 894 IP over Ethernet. . . . . . . . . . . 41
7.1.5. RFC 895 IP over experimental Ethernets. . . . 41
7.1.6. RFC 922 Broadcasting Internet Datagrams in
the Presence of Subnets . . . . . . . . . . . 41
7.1.7. RFC 950 Internet Standard Subnetting
Procedure. . . . . . . . . . . . . . . . . . 42
7.1.8. RFC 1034 Domain Names: Concepts and
Facilities. . . . . . . . . . . . . . . . . . 42
7.1.9. RFC 1035 Domain Names: Implementation and
Specification . . . . . . . . . . . . . . . . 42
7.1.10. RFC 1042 IP over IEEE 802 . . . . . . . . . . 42
7.1.11. RFC 1044 IP over HyperChannel . . . . . . . . 42
7.1.12. RFC 1088 IP over NetBIOS. . . . . . . . . . . 42
7.1.13. RFC 1112 Host Extensions for IP Multicast . . 42
7.1.14. RFC 1122 Requirements for Internet Hosts. . . 42
7.1.15. RFC 1201 IP over ARCNET . . . . . . . . . . . 42
7.1.16. RFC 1209 IP over SMDS . . . . . . . . . . . . 43
7.1.17. RFC 1390 Transmission of IP and ARP over FDDI
Networks. . . . . . . . . . . . . . . . . . . 43
7.2. Draft Standards . . . . . . . . . . . . . . . . . . . 43
7.2.1. RFC 951 Bootstrap Protocol (BOOTP). . . . . . 43
7.2.2. RFC 1191 Path MTU Discovery . . . . . . . . . 43
7.2.3. RFC 1356 Multiprotocol Interconnect on X.25
and ISDN. . . . . . . . . . . . . . . . . . . 43
7.2.4. RFC 1990 The PPP Multilink Protocol (MP). . . 43
7.2.5. RFC 2067 IP over HIPPI. . . . . . . . . . . . 43
7.2.6. RFC 2131 DHCP . . . . . . . . . . . . . . . . 43
7.3. Proposed Standards. . . . . . . . . . . . . . . . . . 44
7.3.1. RFC 1234 Tunneling IPX over IP. . . . . . . . 44
7.3.2. RFC 1256 ICMP Router Discovery. . . . . . . . 44
7.3.3. RFC 1277 Encoding Net Addresses to Support
Operation Over Non OSI Lower Layers . . . . . 44
7.3.4. RFC 1332 PPP Internet Protocol Control
Protocol (IPCP) . . . . . . . . . . . . . . . 44
7.3.5. RFC 1469 IP Multicast over Token Ring . . . . 44
7.3.6. RFC 2003 IP Encapsulation within IP . . . . . 44
7.3.7. RFC 2004 Minimal Encapsulation within IP. . . 44
7.3.8. RFC 2022 Support for Multicast over UNI
3.0/3.1 based ATM Networks. . . . . . . . . . 44
7.3.9. RFC 2113 IP Router Alert Option . . . . . . . 45
7.3.10. RFC 2165 SLP. . . . . . . . . . . . . . . . . 45
7.3.11. RFC 2225 Classical IP & ARP over ATM. . . . . 45
7.3.12. RFC 2226 IP Broadcast over ATM. . . . . . . . 45
7.3.13. RFC 2371 Transaction IPv3 . . . . . . . . . . 45
7.3.14. RFC 2625 IP and ARP over Fibre Channel. . . . 45
7.3.15. RFC 2672 Non-Terminal DNS Redirection . . . . 45
7.3.16. RFC 2673 Binary Labels in DNS . . . . . . . . 45
7.3.17. IP over Vertical Blanking Interval of a TV
Signal (RFC 2728) . . . . . . . . . . . . . . 45
7.3.18. RFC 2734 IPv4 over IEEE 1394. . . . . . . . . 45
7.3.19. RFC 2834 ARP & IP Broadcasts Over HIPPI 800 . 46
7.3.20. RFC 2835 ARP & IP Broadcasts Over HIPPI 6400. 46
7.3.21. RFC 3344 Mobility Support for IPv4. . . . . . 46
7.3.22. RFC 3376 Internet Group Management Protocol,
Version 3 . . . . . . . . . . . . . . . . . . 46
7.4. Experimental RFCs . . . . . . . . . . . . . . . . . . 46
7.4.1. RFC 1307 Dynamically Switched Link Control
Protocol. . . . . . . . . . . . . . . . . . . 46
7.4.2. RFC 1393 Traceroute using an IP Option. . . . 46
7.4.3. RFC 1735 NBMA Address Resolution Protocol
(NARP). . . . . . . . . . . . . . . . . . . . 46
7.4.4. RFC 1788 ICMP Domain Name Messages. . . . . . 46
7.4.5. RFC 1868 ARP Extension - UNARP. . . . . . . . 47
7.4.6. RFC 2143 IP Over SCSI . . . . . . . . . . . . 47
7.4.7. RFC 3180 GLOP Addressing in 233/8 . . . . . . 47
8. Security Considerations . . . . . . . . . . . . . . . . . . 47
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References. . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . 48
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 49
7.3. Proposed Standards. . . . . . . . . . . . . . . . . . 44
7.3.1. RFC 1234 Tunneling IPX over IP. . . . . . . . 44
7.3.2. RFC 1256 ICMP Router Discovery. . . . . . . . 44
7.3.3. RFC 1277 Encoding Net Addresses to Support
Operation Over Non OSI Lower Layers . . . . . 44
7.3.4. RFC 1332 PPP Internet Protocol Control
Protocol (IPCP) . . . . . . . . . . . . . . . 44
7.3.5. RFC 1469 IP Multicast over Token Ring . . . . 44
7.3.6. RFC 2003 IP Encapsulation within IP . . . . . 44
7.3.7. RFC 2004 Minimal Encapsulation within IP. . . 44
7.3.8. RFC 2022 Support for Multicast over UNI
3.0/3.1 based ATM Networks. . . . . . . . . . 44
7.3.9. RFC 2113 IP Router Alert Option . . . . . . . 45
7.3.10. RFC 2165 SLP. . . . . . . . . . . . . . . . . 45
7.3.11. RFC 2225 Classical IP & ARP over ATM. . . . . 45
7.3.12. RFC 2226 IP Broadcast over ATM. . . . . . . . 45
7.3.13. RFC 2371 Transaction IPv3 . . . . . . . . . . 45
7.3.14. RFC 2625 IP and ARP over Fibre Channel. . . . 45
7.3.15. RFC 2672 Non-Terminal DNS Redirection . . . . 45
7.3.16. RFC 2673 Binary Labels in DNS . . . . . . . . 45
7.3.17. IP over Vertical Blanking Interval of a TV
Signal (RFC 2728) . . . . . . . . . . . . . . 45
7.3.18. RFC 2734 IPv4 over IEEE 1394. . . . . . . . . 45
7.3.19. RFC 2834 ARP & IP Broadcasts Over HIPPI 800 . 46
7.3.20. RFC 2835 ARP & IP Broadcasts Over HIPPI 6400. 46
7.3.21. RFC 3344 Mobility Support for IPv4. . . . . . 46
7.3.22. RFC 3376 Internet Group Management Protocol,
Version 3 . . . . . . . . . . . . . . . . . . 46
7.4. Experimental RFCs . . . . . . . . . . . . . . . . . . 46
7.4.1. RFC 1307 Dynamically Switched Link Control
Protocol. . . . . . . . . . . . . . . . . . . 46
7.4.2. RFC 1393 Traceroute using an IP Option. . . . 46
7.4.3. RFC 1735 NBMA Address Resolution Protocol
(NARP). . . . . . . . . . . . . . . . . . . . 46
7.4.4. RFC 1788 ICMP Domain Name Messages. . . . . . 46
7.4.5. RFC 1868 ARP Extension - UNARP. . . . . . . . 47
7.4.6. RFC 2143 IP Over SCSI . . . . . . . . . . . . 47
7.4.7. RFC 3180 GLOP Addressing in 233/8 . . . . . . 47
8. Security Considerations . . . . . . . . . . . . . . . . . . 47
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References. . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . 48
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 49
This document is part of a document set aiming to document all usage of IPv4 addresses in IETF standards. In an effort to have the information in a manageable form, it has been broken into 7 documents conforming to the current IETF areas (Application, Internet, Management & Operations, Routing, Security, Sub-IP and Transport).
本文档是旨在记录IETF标准中IPv4地址的所有使用情况的文档集的一部分。为了使信息具有可管理的形式，已将其分为符合当前IETF领域（应用、互联网、管理和运营、路由、安全、子IP和传输）的7个文档。
This specific document focuses on usage of IPv4 addresses within the Internet area.
本特定文档重点介绍Internet区域内IPv4地址的使用。
For a full introduction, please see the introduction [1] document.
有关完整的介绍，请参见介绍[1]文档。
The following sections 3, 4, 5, and 6 each describe the raw analysis of Full, Draft, and Proposed Standards, and Experimental RFCs. Each RFC is discussed in turn starting with RFC 1 and ending in (about) RFC 3100. The comments for each RFC are "raw" in nature. That is, each RFC is discussed in a vacuum and problems or issues discussed do not "look ahead" to see if any of the issues raised have already been fixed.
以下第3、4、5和6节分别描述了完整、草案和拟议标准以及实验RFC的原始分析。依次讨论每个RFC，从RFC 1开始，到RFC 3100结束。每个RFC的注释本质上是“原始”的。也就是说，每个RFC都是在真空中讨论的，所讨论的问题不会“向前看”，以查看所提出的任何问题是否已经得到解决。
Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 6. It is here that all of the results are considered as a whole and the problems that have been resolved in later RFCs are correlated.
第7节是对第3、4、5和6节中提供的数据的分析。正是在这里，所有的结果都被视为一个整体，并且在以后的RFC中解决的问题被关联起来。
Full Internet Standards (most commonly simply referred to as "Standards") are fully mature protocol specification that are widely implemented and used throughout the Internet.
完整的互联网标准（通常简称为“标准”）是在整个互联网上广泛实施和使用的完全成熟的协议规范。
This specification defines IPv4; IPv6 has been specified in separate documents.
本规范定义了IPv4；IPv6已在单独的文档中指定。
This specification defines ICMP, and is inherently IPv4 dependent.
此规范定义了ICMP，并且本质上依赖于IPv4。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are many implicit assumptions about the use of IPv4 addresses in this document.
本文档中有许多关于IPv4地址使用的隐含假设。
3.5. RFC 894 Standard for the transmission of IP datagrams over Ethernet networks
3.5. 通过以太网传输IP数据报的RFC 894标准
This specification specifically deals with the transmission of IPv4 packets over Ethernet.
本规范专门涉及通过以太网传输IPv4数据包。
3.6. RFC 895 Standard for the transmission of IP datagrams over experimental Ethernet networks
3.6. RFC 895在实验以太网上传输IP数据报的标准
This specification specifically deals with the transmission of IPv4 packets over experimental Ethernet.
本规范专门涉及通过实验以太网传输IPv4数据包。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This specification defines broadcasting for IPv4; IPv6 uses multicast so this is not applicable.
本规范定义了IPv4的广播；IPv6使用多播，因此这不适用。
This specification defines how broadcasts should be treated in the presence of subnets. IPv6 uses multicast so this is not applicable.
本规范定义了在存在子网的情况下如何处理广播。IPv6使用多播，因此这不适用。
This specification defines IPv4 subnetting; similar functionality is part of IPv6 addressing architecture to begin with.
本规范定义了IPv4子网；类似的功能是IPv6寻址体系结构的一部分。
In Section 3.6, "Resource Records", the definition of A record is:
在第3.6节“资源记录”中，记录的定义为：
RDATA which is the type and sometimes class dependent data which describes the resource:
RDATA是描述资源的类型数据，有时是类相关数据：
A For the IN class, a 32 bit IP address
对于类中的，一个32位IP地址
And Section 5.2.1, "Typical functions" defines:
第5.2.1节“典型功能”定义：
1. Host name to host address translation.
1. 主机名到主机地址的转换。
This function is often defined to mimic a previous HOSTS.TXT based function. Given a character string, the caller wants one or more 32 bit IP addresses. Under the DNS, it translates into a request for type A RRs. Since the DNS does not preserve the order of RRs, this function may choose to sort the returned addresses or select the "best" address if the service returns only one choice to the client. Note that a multiple address return is recommended, but a single address may be the only way to emulate prior HOSTS.TXT services.
此函数通常被定义为模仿以前基于HOSTS.TXT的函数。给定一个字符串，调用方需要一个或多个32位IP地址。在DNS下，它转换为a型RRs请求。由于DNS不保留RRs的顺序，因此如果服务仅向客户端返回一个选项，此函数可以选择对返回的地址进行排序或选择“最佳”地址。请注意，建议使用多地址返回，但单个地址可能是模拟以前的HOSTS.TXT服务的唯一方法。
2. Host address to host name translation
2. 主机地址到主机名的转换
This function will often follow the form of previous functions. Given a 32 bit IP address, the caller wants a character string. The octets of the IP address are reversed, used as name components, and suffixed with "IN-ADDR.ARPA". A type PTR query is used to get the RR with the primary name of the host. For example, a request for the host name corresponding to IP address 1.2.3.4 looks for PTR RRs for domain name "4.3.2.1.IN-ADDR.ARPA".
此函数通常遵循以前函数的形式。给定32位IP地址，调用方需要一个字符串。IP地址的八位字节是反向的，用作名称组件，并以“IN-ADDR.ARPA”作为后缀。类型PTR查询用于获取带有主机主名称的RR。例如，请求IP地址1.2.3.4对应的主机名时，会查找域名“4.3.2.1.IN-ADDR.ARPA”的PTR RRs。
There are, of course, numerous examples of IPv4 addresses scattered throughout the document.
当然，本文档中有许多IPv4地址的示例。
Section 3.4.1, "A RDATA format", defines the format for A records:
第3.4.1节“RDATA格式”定义了记录的格式：
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
哪里：
ADDRESS A 32 bit Internet address.
地址一个32位的因特网地址。
Hosts that have multiple Internet addresses will have multiple A records.
具有多个Internet地址的主机将具有多个A记录。
A records cause no additional section processing. The RDATA section of an A line in a master file is an Internet address expressed as four decimal numbers separated by dots without any embedded spaces (e.g.,"10.2.0.52" or "192.0.5.6").
A记录不会导致额外的节处理。主文件中A行的RDATA部分是一个互联网地址，表示为四个由点分隔的十进制数字，没有任何嵌入空格（例如，“10.2.0.52”或“192.0.5.6”）。
And Section 3.4.2, "WKS RDATA", format is:
第3.4.2节“WKS RDATA”的格式为：
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PROTOCOL | |
+--+--+--+--+--+--+--+--+ |
| |
/ <BIT MAP> /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| PROTOCOL | |
+--+--+--+--+--+--+--+--+ |
| |
/ <BIT MAP> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
哪里：
ADDRESS An 32 bit Internet address
地址一个32位的因特网地址
PROTOCOL An 8 bit IP protocol number
协议一个8位IP协议号
<BIT MAP> A variable length bit map. The bit map must be a multiple of 8 bits long.
<BIT MAP>可变长度位图。位图必须是8位长度的倍数。
The WKS record is used to describe the well known services supported by a particular protocol on a particular internet address. The PROTOCOL field specifies an IP protocol number, and the bit map has one bit per port of the specified protocol. The first bit corresponds to port 0, the second to port 1, etc. If the bit map does not include a bit for a protocol of interest, that bit is assumed zero. The appropriate values and mnemonics for ports and protocols are specified in RFC1010.
WKS记录用于描述特定互联网地址上特定协议支持的众所周知的服务。协议字段指定IP协议编号，位图中指定协议的每个端口有一个位。第一位对应端口0，第二位对应端口1，等等。如果位图不包括感兴趣的协议的位，则该位假定为零。RFC1010中规定了端口和协议的适当值和助记符。
For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP port 25 (SMTP). If this bit is set, a SMTP server should be listening on TCP port 25; if zero, SMTP service is not supported on the specified address.
例如，如果协议=TCP（6），则第26位对应于TCP端口25（SMTP）。如果设置了此位，SMTP服务器应在TCP端口25上侦听；如果为零，则指定地址不支持SMTP服务。
The purpose of WKS RRs is to provide availability information for servers for TCP and UDP. If a server supports both TCP and UDP, or has multiple Internet addresses, then multiple WKS RRs are used.
WKS RRs的目的是为TCP和UDP服务器提供可用性信息。如果服务器同时支持TCP和UDP，或具有多个Internet地址，则使用多个WKS RRs。
WKS RRs cause no additional section processing.
WKS RRs不会导致额外的区段处理。
Section 3.5, "IN-ADDR.ARPA domain", describes reverse DNS lookups and is clearly IPv4 dependent.
第3.5节“IN-ADDR.ARPA域”描述了反向DNS查找，并且明显依赖于IPv4。
There are, of course, numerous examples of IPv4 addresses scattered throughout the document.
当然，本文档中有许多IPv4地址的示例。
3.13. RFC 1042 Standard for the transmission of IP datagrams over IEEE 802 networks
3.13. 在IEEE 802网络上传输IP数据报的RFC 1042标准
This specification specifically deals with the transmission of IPv4 packets over IEEE 802 networks.
本规范专门涉及通过IEEE 802网络传输IPv4数据包。
3.14. RFC 1044 Internet Protocol on Network System's HYPERchannel: Protocol Specification
3.14. RFC 1044网络系统超通道上的Internet协议：协议规范
There are a variety of methods used in this standard to map IPv4 addresses to 32 bits fields in the HYPERchannel headers. This specification does not support IPv6.
本标准中使用了多种方法将IPv4地址映射到超通道头中的32位字段。此规范不支持IPv6。
3.15. RFC 1055 Nonstandard for transmission of IP datagrams over serial lines: SLIP
3.15. RFC 1055通过串行线路传输IP数据报的非标准：SLIP
This specification is more of an analysis of the shortcomings of SLIP which is unsurprising. The introduction of PPP as a general replacement of SLIP has made this specification essentially unused. No update need be considered.
本规范更多地分析了滑动的缺点，这并不奇怪。PPP作为滑动的一般替代品的引入使得本规范基本上未被使用。不需要考虑更新。
3.16. RFC 1088 Standard for the transmission of IP datagrams over NetBIOS networks
3.16. 通过NetBIOS网络传输IP数据报的RFC 1088标准
This specification documents a technique to encapsulate IP packets inside NetBIOS packets.
本规范记录了一种将IP数据包封装在NetBIOS数据包中的技术。
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.
使用IP.XX.XX.XX.XX格式的NetBIOS名称的技术不适用于IPv6地址，因为IPv6地址的长度不符合NetBIOS 15八位组名称限制。
This specification defines IP multicast. Parts of the document are IPv4 dependent.
本规范定义了IP多播。文档的某些部分依赖于IPv4。
3.18. RFC 1132 Standard for the transmission of 802.2 packets over IPX networks
3.18. 通过IPX网络传输802.2数据包的RFC 1132标准
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
The major concerns of this specification with respect to IPv4 addresses occur in the resolution of ARCnet 8bit addresses to IPv4 addresses in an "ARPlike" method. This is incompatible with IPv6.
本规范关于IPv4地址的主要关注点在于以“类似ARP”的方法将ARCnet 8位地址解析为IPv4地址。这与IPv6不兼容。
This specification defines running IPv4 and ARP over SMDS. The methods described could easily be extended to support IPv6 packets.
本规范定义了在SMD上运行IPv4和ARP。所描述的方法可以很容易地扩展到支持IPv6数据包。
This specification defines the use of IPv4 address on FDDI networks. There are numerous IPv4 dependencies in the specification.
本规范定义了在FDDI网络上使用IPv4地址。规范中有许多IPv4依赖项。
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.
尤其需要创建协议类型代码（IPv4为2048）的值和相应的协议地址长度（IPv4为4字节）。还包括对广播和多播寻址技术的讨论，同样，必须针对IPv6网络进行更新。定义的4096个八位字节数据的MTU限制（保留256个八位字节的报头空间）应足以支持IPv6。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Draft Standards represent the penultimate standard level in the IETF. A protocol can only achieve draft standard when there are multiple, independent, interoperable implementations. Draft Standards are usually quite mature and widely used.
标准草案代表IETF中倒数第二个标准级别。只有当存在多个独立的、可互操作的实现时，协议才能实现标准草案。标准草案通常是相当成熟和广泛使用的。
This protocol is designed specifically for use with IPv4, for example:
此协议专门设计用于IPv4，例如：
Section 3. Packet Format
第3节。数据包格式
All numbers shown are decimal, unless indicated otherwise. The BOOTP packet is enclosed in a standard IP UDP datagram. For simplicity it is assumed that the BOOTP packet is never fragmented. Any numeric fields shown are packed in 'standard network byte order', i.e., high order bits are sent first.
除非另有说明，否则显示的所有数字均为十进制。BOOTP数据包包含在标准IP UDP数据报中。为简单起见，假定BOOTP数据包从不分段。显示的任何数字字段均按“标准网络字节顺序”打包，即先发送高阶位。
In the IP header of a bootrequest, the client fills in its own IP source address if known, otherwise zero. When the server address is unknown, the IP destination address will be the 'broadcast address' 255.255.255.255. This address means 'broadcast on the local cable, (I don't know my net number)'.
在bootrequest的IP头中，客户机填写自己的IP源地址（如果已知），否则为零。当服务器地址未知时，IP目标地址将是“广播地址”255.255.255.255。这个地址的意思是“在本地有线电视上广播，（我不知道我的网络号码）”。
FIELD BYTES DESCRIPTION
----- ----- ---
FIELD BYTES DESCRIPTION
----- ----- ---
[...] ciaddr 4 client IP address; filled in by client in bootrequest if known.
[…]ciaddr 4客户端IP地址；由客户端在bootrequest中填写（如果已知）。
yiaddr 4 'your' (client) IP address; filled by server if client doesn't know its own address (ciaddr was 0).
yiaddr 4“您的”（客户）IP地址；如果客户端不知道自己的地址，则由服务器填写（ciaddr为0）。
siaddr 4 server IP address; returned in bootreply by server.
siaddr 4服务器IP地址；服务器在引导应答中返回。
giaddr 4 gateway IP address, used in optional cross-gateway booting.
giaddr 4网关IP地址，用于可选的跨网关引导。
Since the packet format is a fixed 300 bytes in length, an updated version of the specification could easily accommodate an additional 48 bytes (4 IPv6 fields of 16 bytes to replace the existing 4 IPv4 fields of 4 bytes).
由于数据包格式的长度是固定的300字节，因此该规范的更新版本可以轻松容纳额外的48字节（4个16字节的IPv6字段替换现有的4个4字节的IPv4字段）。
4.2. RFC 1188 Proposed Standard for the Transmission of IP Datagrams over FDDI Networks
4.2. RFC 1188通过FDDI网络传输IP数据报的拟定标准
This document is clearly informally superseded 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.
本文件显然非正式地被RFC 1390“通过FDDI网络传输IP和ARP”取代，尽管没有正式的反对意见。因此，本备忘录不进一步考虑本规范。
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.
PMTU发现的整个过程取决于IPv4报头中DF位的使用、ICMP消息（也依赖于IPv4）和TCP MSS选项。这与IPv6不兼容。
Section 3.2 defines an NLPID for IP as follows:
第3.2节对IP的NLPID定义如下：
The value hex CC (binary 11001100, decimal 204) is IP. Conformance with this specification requires that IP be supported.
十六进制CC（二进制11001100，十进制204）的值为IP。与本规范的一致性要求支持IP。
See section 5.1 for a diagram of the packet formats.
数据包格式图见第5.1节。
Clearly a new NLPID would need to be defined for IPv6 packets.
显然，需要为IPv6数据包定义一个新的NLPID。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no new issues other than those presented in Section 4.1.
除第4.1节中提出的问题外，没有其他新问题。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Section 5.1.3, "Endpoint Discriminator Option", defines a Class header field:
第5.1.3节“端点鉴别器选项”定义了类标题字段：
Class The Class field is one octet and indicates the identifier address space. The most up-to-date values of the LCP Endpoint Discriminator Class field are specified in the most recent "Assigned Numbers" RFC. Current values are assigned as follows:
类类字段是一个八位字节，表示标识符地址空间。LCP端点鉴别器类字段的最新值在最近的“已分配编号”RFC中指定。当前值分配如下：
0 Null Class
0空类
1 Locally Assigned Address
1本地分配的地址
2 Internet Protocol (IP) Address
2互联网协议（IP）地址
3 IEEE 802.1 Globally Assigned MAC Address
3 IEEE 802.1全局分配的MAC地址
4 PPP Magic-Number Block
4 PPP幻数块
5 Public Switched Network Directory Number
5公共交换网络目录号
A new class field needs to be defined by the IANA for IPv6 addresses.
IANA需要为IPv6地址定义一个新的类字段。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Section 5.1, "Packet Formats", contains the following excerpt:
第5.1节“数据包格式”包含以下摘录：
EtherType (16 bits) SHALL be set as defined in Assigned Numbers: IP = 2048 ('0800'h), ARP = 2054 ('0806'h), RARP = 32,821 ('8035'h).
EtherType（16位）应按照指定的编号进行设置：IP=2048（'0800'h），ARP=2054（'0806'h），RARP=32821（'8035'h）。
Section 5.5, "MTU", has the following definition:
第5.5节“MTU”的定义如下：
The MTU for HIPPI-SC LANs is 65280 bytes.
HIPPI-SC LAN的MTU为65280字节。
This value was selected because it allows the IP packet to fit in one 64K byte buffer with up to 256 bytes of overhead. The overhead is 40 bytes at the present time; there are 216 bytes of room for expansion.
之所以选择此值，是因为它允许IP数据包以高达256字节的开销装入一个64K字节的缓冲区。目前开销为40字节；有216字节的扩展空间。
HIPPI-FP Header 8 bytes
HIPPI-LE Header 24 bytes
IEEE 802.2 LLC/SNAP Headers 8 bytes
Maximum IP packet size (MTU) 65280 bytes
------------
Total 65320 bytes (64K - 216)
HIPPI-FP Header 8 bytes
HIPPI-LE Header 24 bytes
IEEE 802.2 LLC/SNAP Headers 8 bytes
Maximum IP packet size (MTU) 65280 bytes
------------
Total 65320 bytes (64K - 216)
This definition is not applicable for IPv6 packets since packets can be larger than the IPv4 limitation of 65280 bytes.
此定义不适用于IPv6数据包，因为数据包可能大于IPv4的65280字节限制。
This version of DHCP is highly predicated of IPv4. It is not compatible with IPv6.
此版本的DHCP高度依赖于IPv4。它与IPv6不兼容。
This is an extension to an IPv4-only specification.
这是对仅IPv4规范的扩展。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This document defines IPv6 and has no IPv4 issues.
本文档定义了IPv6，没有IPv4问题。
This document defines an IPv6 related specification and has no IPv4 issues.
本文档定义了与IPv6相关的规范，没有IPv4问题。
This document defines an IPv6 related specification and has no IPv4 issues.
本文档定义了与IPv6相关的规范，没有IPv4问题。
4.19. RFC 2463 Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
4.19. 互联网协议版本6（IPv6）规范的RFC 2463互联网控制消息协议（ICMPv6）
This document defines an IPv6 related specification and has no IPv4 issues.
本文档定义了与IPv6相关的规范，没有IPv4问题。
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.
本规范定义了IPv6的AAAA记录以及使用ip6.arpa域的PTR记录，因此没有IPv6问题。
Proposed Standards are introductory level documents. There are no requirements for even a single implementation. In many cases, Proposed are never implemented or advanced in the IETF standards process. They, therefore, are often just proposed ideas that are presented to the Internet community. Sometimes flaws are exposed or they are one of many competing solutions to problems. In these later cases, no discussion is presented as it would not serve the purpose of this discussion.
拟议标准是介绍性文件。即使是单个实现也没有要求。在许多情况下，在IETF标准过程中从未实施或推进提议的标准。因此，它们通常只是向互联网社区提出的想法。有时缺陷会暴露出来，或者是许多相互竞争的问题解决方案之一。在后一种情况下，不进行讨论，因为这不符合本次讨论的目的。
The section "Unicast Address Mappings" has the following text:
“单播地址映射”部分包含以下文本：
For implementations of this memo, the first two octets of the host number will always be zero and the last four octets will be the node's four octet IP address. This makes address mapping trivial for unicast transmissions: the first two octets of the host number are discarded, leaving the normal four octet IP address. The encapsulation code should use this IP address as the destination address of the UDP/IP tunnel packet.
对于此备忘录的实现，主机号的前两个八位字节将始终为零，最后四个八位字节将是节点的四个八位字节IP地址。这使得单播传输的地址映射变得微不足道：主机号的前两个八位字节被丢弃，剩下正常的四个八位字节的IP地址。封装代码应使用此IP地址作为UDP/IP隧道数据包的目标地址。
This mapping will not be able to work with IPv6 addresses.
此映射将无法使用IPv6地址。
There are also numerous discussions on systems keeping a "peer list" to map between IP and IPX addresses. The specifics are not discussed in the document and are left to the individual implementation.
还有许多关于系统保持“对等列表”以在IP和IPX地址之间映射的讨论。具体细节未在本文件中讨论，由个人实施。
The section "Maximum Transmission Unit" also has some implications on IP addressing:
“最大传输单元”一节对IP寻址也有一些影响：
Although larger IPX packets are possible, the standard maximum transmission unit for IPX is 576 octets. Consequently, 576 octets is the recommended default maximum transmission unit for IPX packets being sent with this encapsulation technique. With the eight octet UDP header and the 20 octet IP header, the resulting IP packets will be 604 octets long. Note that this is larger than the 576 octet maximum size IP implementations are required to accept. Any IP implementation supporting this encapsulation technique must be capable of receiving 604 octet IP packets.
虽然可以使用更大的IPX数据包，但IPX的标准最大传输单元是576个八位字节。因此，对于使用此封装技术发送的IPX数据包，建议使用576个八位字节作为默认最大传输单元。使用8个八位组的UDP报头和20个八位组的IP报头，生成的IP数据包长度将为604个八位组。请注意，这比需要接受的最大大小为576个八位字节的IP实现要大。任何支持这种封装技术的IP实现都必须能够接收604个八位组的IP数据包。
As improvements in protocols and hardware allow for larger, unfragmented IP transmission units, the 576 octet maximum IPX packet size may become a liability. For this reason, it is recommended that the IPX maximum transmission unit size be configurable in implementations of this memo.
由于协议和硬件的改进允许更大、不分段的IP传输单元，576八位字节的最大IPX数据包大小可能成为一种负担。因此，建议在本备忘录的实施中配置IPX最大传输单元大小。
This specification defines a mechanism very specific to IPv4.
该规范定义了一种非常特定于IPv4的机制。
5.3. RFC 1277 Encoding Network Addresses to Support Operation over Non-OSI Lower Layers
5.3. RFC 1277编码网络地址以支持非OSI较低层上的操作
Section 4.5, "TCP/IP (RFC 1006) Network Specific Format" describes a structure that reserves 12 digits for the textual representation of an IP address.
第4.5节“TCP/IP（RFC 1006）网络特定格式”描述了一种保留12位数字的结构，用于IP地址的文本表示。
This 12 octet field for decimal versions of IP addresses is insufficient for a decimal version of IPv6 addresses. It is possible to define a new encoding using the 20 digit long IP Address + Port + Transport Set fields in order to accommodate a binary version of an IPv6 address, port number and Transport Set. There are several schemes that could be envisioned.
十进制版本的IP地址的12个八位字节字段不足以表示十进制版本的IPv6地址。可以使用20位长的IP地址+端口+传输集字段定义新编码，以适应IPv6地址、端口号和传输集的二进制版本。有几个方案是可以设想的。
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.
本规范定义了一种机制，用于设备在PPP协商完成后将IPv4地址分配给PPP客户端。第3节“IPCP配置选项”定义了将IP地址嵌入4字节长字段的IPCP选项类型。对于IPv6来说，这显然是不够的。
However, the specification is clearly designed to allow new Option Types to be added and Should offer no problems for use with IPv6 once appropriate options have been defined.
但是，该规范明确设计为允许添加新的选项类型，并且一旦定义了合适的选项，就应该不会给IPv6带来任何问题。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This document defines the usage of IPv4 multicast over IEEE 802.5 Token Ring networks. This is not compatible with IPv6.
本文档定义了在IEEE 802.5令牌环网上使用IPv4多播。这与IPv6不兼容。
5.8. RFC 1552 The PPP Internetworking Packet Exchange Control Protocol (IPXCP)
5.8. RFC 1552 PPP网络间分组交换控制协议（IPXCP）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This document defines a road map for IPv6 development and is not relevant to this discussion.
本文档定义了IPv6开发的路线图，与本次讨论无关。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This specification describes an IPv6 related specification and is not discussed in this document.
本规范描述了与IPv6相关的规范，本文档中不讨论。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Although the examples used in this document use IPv4 addresses, (i.e., A records) there is nothing in the specification to preclude full and proper functionality using IPv6.
尽管本文档中使用的示例使用IPv4地址（即A记录），但规范中没有任何内容阻止使用IPv6实现完整和正确的功能。
5.21. RFC 1996 A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
5.21. RFC 1996区域更改提示通知机制（DNS通知）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
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.
本文档旨在用于IPv4网络。有许多对指定的IP版本号（4位和32位地址）的引用。这与IPv6不兼容。
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.
本文档旨在用于IPv4网络。有许多对指定的IP版本号（4位和32位地址）的引用。这与IPv6不兼容。
This specification documents the interoperation of IPv4 Mobility Support; this is not relevant to this discussion.
本规范记录了IPv4移动支持的互操作性；这与本次讨论无关。
5.25. RFC 2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks
5.25. RFC 2022支持基于UNI 3.0/3.1的ATM网络上的多播
This specification specifically maps IPv4 multicast in UNI based ATM networks. This is incompatible with IPv6.
本规范专门映射基于UNI的ATM网络中的IPv4多播。这与IPv6不兼容。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This document provides a new mechanism for IPv4. This is incompatible with IPv6.
本文档为IPv4提供了一种新机制。这与IPv6不兼容。
5.29. RFC 2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP)
5.29. RFC 2125 PPP带宽分配协议（BAP）/PPP带宽分配控制协议（BACP）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification. The only reference to IP addresses discuss the use of an anycast address, so but one can assume that these techniques are IPv6 operable.
此规范中不存在IPv4依赖项。对IP地址的唯一引用讨论了选播地址的使用，因此可以假设这些技术是IPv6可操作的。
From the many references in this document, it is clear that this document is designed for IPv4 only. It is only later in the document that it is implicitly stated, as in:
从本文档中的许多参考资料中可以清楚地看出，本文档仅设计用于IPv4。只有在文件的后面，才隐式说明，如：
ar$spln - length in octets of the source protocol address. Value range is 0 or 4 (decimal). For IPv4 ar$spln is 4.
ar$spln—源协议地址的八位字节长度。值范围为0或4（十进制）。对于IPv4，ar$spln为4。
ar$tpln - length in octets of the target protocol address. Value range is 0 or 4 (decimal). For IPv4 ar$tpln is 4.
ar$tpln—目标协议地址的八位字节长度。值范围为0或4（十进制）。对于IPv4 ar，$tpln是4。
and:
以及：
For backward compatibility with previous implementations, a null IPv4 protocol address may be received with length = 4 and an allocated address in storage set to the value 0.0.0.0. Receiving stations must be liberal in accepting this format of a null IPv4 address. However, on transmitting an ATMARP or InATMARP packet, a null IPv4 address must only be indicated by the length set to zero and must have no storage allocated.
为了与以前的实现向后兼容，可以接收长度为4的空IPv4协议地址，并将存储中的分配地址设置为值0.0.0.0。接收站必须自由地接受这种空IPv4地址格式。但是，在传输ATMARP或InATMARP数据包时，空IPv4地址必须仅由设置为零的长度指示，并且不得分配任何存储。
This document is limited to IPv4 multicasting. This is incompatible with IPv6.
本文档仅限于IPv4多播。这与IPv6不兼容。
This is an extension to an IPv4-only specification.
这是对仅IPv4规范的扩展。
This is an extension to an IPv4-only specification, for example:
这是对仅IPv4规范的扩展，例如：
PREFERRED_DSS (code 6)
首选决策支持系统（代码6）
Length is (n * 4) and the value is an array of n IP addresses, each four bytes in length. The maximum number of addresses is 5 and therefore the maximum length value is 20. The list contains the addresses of n NetWare Domain SAP/RIP Server (DSS).
长度为（n*4），值为n个IP地址的数组，每个IP地址的长度为4个字节。地址的最大数量为5，因此最大长度值为20。该列表包含n NetWare域SAP/RIP服务器（DSS）的地址。
NEAREST_NWIP_SERVER (code 7)
最近的服务器（代码7）
Length is (n * 4) and the value is an array of n IP addresses, each four bytes in length. The maximum number of addresses is 5 and therefore the maximum length value is 20. The list contains the addresses of n Nearest NetWare/IP servers.
长度为（n*4），值为n个IP地址的数组，每个IP地址的长度为4个字节。地址的最大数量为5，因此最大长度值为20。该列表包含n个最近的NetWare/IP服务器的地址。
PRIMARY_DSS (code 11)
主要决策支持系统（代码11）
Length of 4, and the value is a single IP address. This field identifies the Primary Domain SAP/RIP Service server (DSS) for this NetWare/IP domain. NetWare/IP administration utility uses this value as Primary DSS server when configuring a secondary DSS server.
长度为4，值为单个IP地址。此字段标识此NetWare/IP域的主域SAP/RIP服务服务器（DSS）。NetWare/IP管理实用程序在配置辅助DSS服务器时将此值用作主DSS服务器。
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.
本文档设计用于移动IPv4。有许多参考其他IP“支持”机制（即ICMP路由器发现消息），具体参考ICMP的IPv4。
Although there are numerous examples in this document that use IPv4 "A" records, there is nothing in the specification that limits its effectiveness to IPv4.
尽管本文档中有许多使用IPv4“A”记录的示例，但规范中没有任何内容限制其对IPv4的有效性。
5.38. RFC 2331 ATM Signaling Support for IP over ATM - UNI Signaling 4.0 Update
5.38. RFC 2331 ATM信令支持IP over ATM-UNI信令4.0更新
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
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.
本文档在设计上非常通用，似乎能够支持许多第3层寻址方案，并且应该包括IPv4和IPv6。
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.
本文档在设计上非常通用，似乎能够支持许多第3层寻址方案，并且应该包括IPv4和IPv6。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This document states:
该文件规定：
TIP transaction manager addresses take the form:
TIP事务管理器地址采用以下形式：
<hostport><path>
<hostport><path>
The <hostport> component comprises:
<hostport>组件包括：
<host>[:<port>]
<host>[:<port>]
where <host> is either a <dns name> or an <ip address>; and <port> is a decimal number specifying the port at which the transaction manager (or proxy) is listening for requests to establish TIP connections. If the port number is omitted, the standard TIP port number (3372) is used.
其中<host>是<dns name>或<ip地址>；<port>是一个十进制数，指定事务管理器（或代理）侦听建立TIP连接请求的端口。如果省略端口号，则使用标准TIP端口号（3372）。
A <dns name> is a standard name, acceptable to the domain name service. It must be sufficiently qualified to be useful to the receiver of the command.
<dns名称>是域名服务可接受的标准名称。它必须足够合格，以便对命令接收者有用。
An <ip address> is an IP address, in the usual form: four decimal numbers separated by period characters.
<ip地址>是一个ip地址，通常的形式是：四个十进制数字，由句点字符分隔。
And further along it states:
进一步说：
A TIP URL takes the form:
提示URL的形式如下：
tip://<transaction manager address>?<transaction string>
tip://<transaction manager address>?<transaction string>
where <transaction manager address> identifies the TIP transaction manager (as defined in Section 7 above); and <transaction string> specifies a transaction identifier, which may take one of two forms (standard or non-standard):
其中，<transaction manager address>标识TIP交易经理（定义见上文第7节）；和<transaction string>指定一个事务标识符，它可以采用两种形式之一（标准或非标准）：
i. "urn:" <NID> ":" <NSS>
i. "urn:" <NID> ":" <NSS>
A standard transaction identifier, conforming to the proposed Internet Standard for Uniform Resource Names (URNs), as specified by RFC2141; where <NID> is the Namespace Identifier, and <NSS> is the Namespace Specific String. The Namespace ID determines the syntactic interpretation of the Namespace Specific String. The Namespace Specific String is a sequence of characters representing a transaction identifier (as defined by <NID>). The rules for the contents of these fields are specified by RFC2141 (valid characters, encoding, etc.).
标准事务标识符，符合RFC2141规定的统一资源名称（URN）的拟议互联网标准；其中<NID>是名称空间标识符，<NSS>是特定于名称空间的字符串。命名空间ID确定命名空间特定字符串的语法解释。命名空间特定的字符串是表示事务标识符的字符序列（由<NID>定义）。这些字段内容的规则由RFC2141指定（有效字符、编码等）。
This format of <transaction string> may be used to express global transaction identifiers in terms of standard representations. Examples for <NID> might be <iso> or <xopen>, e.g.,
<transaction string>的这种格式可用于以标准表示形式表示全局事务标识符。<NID>的示例可能是<iso>或<xopen>，例如。，
tip://123.123.123.123/?urn:xopen:xid
tip://123.123.123.123/?urn:xopen:xid
Note that Namespace Ids require registration.
请注意，命名空间ID需要注册。
ii. <transaction identifier>
二,<事务标识符>
A sequence of printable ASCII characters (octets with values in the range 32 through 126 inclusive (excluding ":") representing a transaction identifier. In this non-standard case, it is the combination of <transaction manager address> and <transaction identifier> which ensures global uniqueness, e.g.,
表示事务标识符的可打印ASCII字符序列（八位字节，其值范围为32到126（不包括“：”），在这种非标准情况下，是<transaction manager address>和<transaction identifier>的组合，可确保全局唯一性，例如。，
tip://123.123.123.123/?transid1
tip://123.123.123.123/?transid1
These are incompatible with IPv6.
这些与IPv6不兼容。
This specification documents a method for transmitting IPv6 packets over Ethernet and is not considered in this discussion.
本规范记录了一种通过以太网传输IPv6数据包的方法，在本讨论中不予以考虑。
This specification documents a method for transmitting IPv6 packets over FDDI and is not considered in this discussion.
本规范记录了通过FDDI传输IPv6数据包的方法，本讨论中不考虑该方法。
This specification documents a method for transmitting IPv6 packets over Token Ring and is not considered in this discussion.
本规范记录了一种通过令牌环传输IPv6数据包的方法，本讨论不考虑该方法。
This specification documents a method for transmitting IPv6 packets over PPP and is not considered in this discussion.
本规范记录了通过PPP传输IPv6数据包的方法，本讨论中不考虑该方法。
This specification documents an IPv6 aware specification and is not considered in this discussion.
本规范记录了一个支持IPv6的规范，在此讨论中不予以考虑。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.51. RFC 2485 DHCP Option for The Open Group's User Authentication Protocol
5.51. 开放组用户身份验证协议的RFC 2485 DHCP选项
This is an extension to an IPv4-only specification.
这是对仅IPv4规范的扩展。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This specification documents a method for transmitting IPv6 packets over NBMA networks and is not considered in this discussion.
本规范记录了通过NBMA网络传输IPv6数据包的方法，本讨论中不考虑该方法。
This specification documents a method for transmitting IPv6 packets over ATM networks and is not considered in this discussion.
本规范记录了一种通过ATM网络传输IPv6数据包的方法，在本讨论中不予以考虑。
This specification documents a method for transmitting IPv6 packets over ARCnet networks and is not considered in this discussion.
本规范记录了通过ARCnet网络传输IPv6数据包的方法，本讨论不考虑此方法。
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
This specification documents IPv6 addressing and is not discussed in this document.
本规范记录了IPv6寻址，本文档中未讨论。
5.58. RFC 2529 Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
5.58. RFC 2529在IPv4域上无显式隧道传输IPv6
This specification documents IPv6 transmission methods and is not discussed in this document.
本规范记录了IPv6传输方法，本文档中未讨论。
5.59. RFC 2563 DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients
5.59. RFC 2563 DHCP选项，用于禁用IPv4客户端中的无状态自动配置
This is an extension to an IPv4-only specification.
这是对仅IPv4规范的扩展。
5.60. RFC 2590 Transmission of IPv6 Packets over Frame Relay Networks Specification
5.60. RFC 2590通过帧中继网络传输IPv6数据包规范
This specification documents IPv6 transmission method over Frame Relay and is not discussed in this document.
本规范记录了通过帧中继的IPv6传输方法，本文档中未讨论。
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
This specification is both IPv4 and IPv6 aware.
此规范支持IPv4和IPv6。
This is an extension to an IPv4-only specification.
这是对仅IPv4规范的扩展。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This document states:
该文件规定：
Objective and Scope:
目标和范围：
The major objective of this specification is to promote interoperable implementations of IPv4 over FC. This specification describes a method for encapsulating IPv4 and Address Resolution Protocol (ARP) packets over FC.
本规范的主要目标是促进IPv4在FC上的互操作实现。本规范描述了通过FC封装IPv4和地址解析协议（ARP）数据包的方法。
This is incompatible with IPv6.
这与IPv6不兼容。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This document is only defined for IPv4 addresses. An IPv6 specification may be needed.
此文档仅为IPv4地址定义。可能需要IPv6规范。
This document is only defined for IPv4 addresses. An IPv6 specification may be needed.
此文档仅为IPv4地址定义。可能需要IPv6规范。
This document defines a IPv6 packet format and is therefore not discussed in this document.
本文档定义了IPv6数据包格式，因此不在本文档中讨论。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This document defines an IPv6 specific specification and is not discussed in this document.
本文档定义了特定于IPv6的规范，在本文档中不作讨论。
This document defines an IPv6 specific specification and is not discussed in this document.
本文档定义了特定于IPv6的规范，在本文档中不作讨论。
5.79. RFC 2728 The Transmission of IP Over the Vertical Blanking Interval of a Television Signal
5.79. RFC2728在电视信号的垂直消隐间隔上的IP传输
The following data format is defined:
定义了以下数据格式：
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| group | uncompressed IP header (20 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
: .... :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | uncompressed UDP header (8 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | payload (<1472 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
: .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| group | uncompressed IP header (20 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
: .... :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | uncompressed UDP header (8 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | payload (<1472 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
: .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is incompatible with IPv6.
这与IPv6不兼容。
This specification is IPv4 only.
此规范仅适用于IPv4。
This specification implies only IPv4 operations, but does not seem to present any reason that it would not function for IPv6.
此规范仅表示IPv4操作，但似乎没有任何理由表明它不适用于IPv6。
This specification defines a method for IPv6 transition and is not discussed in this document.
本规范定义了IPv6转换的方法，本文档中不进行讨论。
5.83. RFC 2766 Network Address Translation - Protocol Translation (NAT-PT)
5.83. RFC 2766网络地址转换-协议转换（NAT-PT）
This specification defines a method for IPv6 transition and is not discussed in this document.
本规范定义了IPv6转换的方法，本文档中不进行讨论。
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This is an extension to an IPv4-only specification.
这是对仅IPv4规范的扩展。
This document uses the generic term "IP Address" in the text but it also contains the text:
本文件在文本中使用了通用术语“IP地址”，但也包含以下文本：
The HARP message has several fields that have the following format and values:
HARP消息有几个字段，其格式和值如下：
Data sizes and field meaning: ar$hrd 16 bits Hardware type ar$pro 16 bits Protocol type of the protocol fields below ar$op 16 bits Operation code (request, reply, or NAK) ar$pln 8 bits byte length of each protocol address ar$rhl 8 bits requester's HIPPI hardware address length (q) ar$thl 8 bits target's HIPPI hardware address length (x) ar$rpa 32 bits requester's protocol address ar$tpa 32 bits target's protocol address ar$rha qbytes requester's HIPPI Hardware address ar$tha xbytes target's HIPPI Hardware address
数据大小和字段含义：ar$hrd 16位硬件类型ar$pro 16位以下协议字段的协议类型ar$op 16位操作码（请求、应答或NAK）ar$pln每个协议地址的8位字节长度ar$rhl 8位请求者的HIPI硬件地址长度（q）ar$thl 8位目标的HIPI硬件地址长度（x）ar$rpa 32位请求者的协议地址ar$tpa 32位目标的协议地址ar$rha qbytes请求者的HIPI硬件地址ar$tha xbytes目标的HIPI硬件地址
Where: ar$hrd - SHALL contain 28. (HIPARP)
式中：ar$hrd-应包含28。（HIPARP）
ar$pro - SHALL contain the IP protocol code 2048 (decimal).
ar$pro-应包含IP协议代码2048（十进制）。
ar$op - SHALL contain the operational value (decimal): 1 for HARP_REQUESTs 2 for HARP_REPLYs 8 for InHARP_REQUESTs 9 for InHARP_REPLYs 10 for HARP_NAK ar$pln - SHALL contain 4.
ar$op-应包含操作值（十进制）：1用于HARP_请求2用于HARP_回复8用于InHARP_请求9用于InHARP_回复10用于HARP_NAK ar$pln-应包含4。
And later:
后来：
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | 45 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W|MsgT= 0| 000 | Dest. Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | 2 | 2 | 000 | Source Switch Addr |
+---------------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Destination ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Source ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | Ethertype (2054) |
+---------------+---------------+-------------------------------+
10 | hrd (28) | pro (2048) |
+---------------+---------------+---------------+---------------+
11 | op (ar$op) | pln (6) | rhl (q) |
+---------------+---------------+---------------+---------------+
12 | thl = (x) | Requester IP Address upper (24 bits) |
+---------------------------------------------------------------+
13 | Req. IP lower | Target IP Address upper (24 bits) |
+---------------+-----------------------------------------------+
14 | Tgt. IP lower | Requester HIPPI Hardware Address bytes 0 - 2 |
+---------------+-----------------------------------------------+
15 | Requester HIPPI Hardware Address bytes 3 - 6 |
+-----------------------------------------------+---------------+
16 | Requester HW Address bytes 7 - q | Tgt HW byte 0 |
+---------------+---------------+---------------+---------------+
17 | Target HIPPI Hardware Address bytes 1 - 4 |
+---------------------------------------------------------------+
18 | Target HIPPI Hardware Address bytes 5 - 8 |
+---------------+---------------+---------------+---------------+
19 |Tgt HW byte 9-x| FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
HARP - InHARP Message
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | 45 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W|MsgT= 0| 000 | Dest. Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | 2 | 2 | 000 | Source Switch Addr |
+---------------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Destination ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Source ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | Ethertype (2054) |
+---------------+---------------+-------------------------------+
10 | hrd (28) | pro (2048) |
+---------------+---------------+---------------+---------------+
11 | op (ar$op) | pln (6) | rhl (q) |
+---------------+---------------+---------------+---------------+
12 | thl = (x) | Requester IP Address upper (24 bits) |
+---------------------------------------------------------------+
13 | Req. IP lower | Target IP Address upper (24 bits) |
+---------------+-----------------------------------------------+
14 | Tgt. IP lower | Requester HIPPI Hardware Address bytes 0 - 2 |
+---------------+-----------------------------------------------+
15 | Requester HIPPI Hardware Address bytes 3 - 6 |
+-----------------------------------------------+---------------+
16 | Requester HW Address bytes 7 - q | Tgt HW byte 0 |
+---------------+---------------+---------------+---------------+
17 | Target HIPPI Hardware Address bytes 1 - 4 |
+---------------------------------------------------------------+
18 | Target HIPPI Hardware Address bytes 5 - 8 |
+---------------+---------------+---------------+---------------+
19 |Tgt HW byte 9-x| FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
HARP - InHARP Message
This is incompatible with IPv6.
这与IPv6不兼容。
This document states:
该文件规定：
The Ethertype value SHALL be set as defined in Assigned Numbers:
Ethertype值应按照指定的编号进行设置：
IP 0x0800 2048 (16 bits)
IP 0x0800 2048（16位）
This is limited to IPv4, and similar to the previous section, incompatible with IPv6. There are numerous other points in the documents that confirm this assumption.
这仅限于IPv4，与上一节类似，与IPv6不兼容。文件中还有许多其他观点证实了这一假设。
This is an extension to an IPv4-only specification.
这是对仅IPv4规范的扩展。
5.90. RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and Renumbering
5.90. RFC 2874 DNS扩展支持IPv6地址聚合和重新编号
This document defines a specification to interact with IPv6 and is not considered in this document.
本文档定义了一个与IPv6交互的规范，本文档不考虑此规范。
This document defines a transition mechanism for IPv6 and is not considered in this document.
本文档定义了IPv6的转换机制，不在本文档中考虑。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This is an extension to an IPv4-only specification.
这是对仅IPv4规范的扩展。
This is an extension to an IPv4-only specification.
这是对仅IPv4规范的扩展。
This is an extension to an IPv4-only specification.
这是对仅IPv4规范的扩展。
This specification is specific to IPv4 address architecture, where a modification is needed to use both addresses of a 31-bit prefix. This is possible by IPv6 address architecture, but in most cases not
此规范特定于IPv4地址体系结构，其中需要修改以使用31位前缀的两个地址。通过IPv6地址体系结构，这是可能的，但在大多数情况下并非如此
recommended; see RFC 3627, Use of /127 Prefix Length Between Routers Considered Harmful.
推荐；参见RFC 3627，路由器之间使用/127前缀长度被认为是有害的。
This is an extension to an IPv4-only specification.
这是对仅IPv4规范的扩展。
This is an extension to an IPv4-only specification.
这是对仅IPv4规范的扩展。
This is an IPv6 related document and is not discussed in this document.
这是一份与IPv6相关的文档，本文档中没有讨论。
5.100. RFC 3068 An Anycast Prefix for 6to4 Relay Routers
5.100. RFC 3068用于6to4中继路由器的选播前缀
This is an IPv6 related document and is not discussed in this document.
这是一份与IPv6相关的文档，本文档中没有讨论。
5.101. RFC 3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay
5.101. RFC 3070帧中继上的第二层隧道协议（L2TP）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.102. RFC 3074 DHC Load Balancing Algorithm
5.102. RFC3074 DHC负载平衡算法
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.103. RFC 3077 A Link-Layer Tunneling Mechanism for Unidirectional Links
5.103. RFC 3077单向链路的链路层隧道机制
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
5.104. RFC 3115 Mobile IP Vendor/Organization-Specific Extensions
5.104. RFC 3115移动IP供应商/组织特定扩展
This is an extension to an IPv4-only specification.
这是对仅IPv4规范的扩展。
5.105. RFC 3145 L2TP Disconnect Cause Information
5.105. RFC 3145 L2TP断开原因信息
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.106. RFC 3344 IP Mobility Support for IPv4
5.106. RFC 3344对IPv4的IP移动支持
There are IPv4 dependencies in this specification.
此规范中存在IPv4依赖项。
5.107. RFC 3376 Internet Group Management Protocol, Version 3
5.107. RFC 3376 Internet组管理协议，版本3
This document describes of version of IGMP used for IPv4 multicast. This is not compatible with IPv6.
本文档介绍用于IPv4多播的IGMP版本。这与IPv6不兼容。
5.108. RFC 3402 Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm
5.108. RFC3402动态委托发现系统（DDDS）第二部分：算法
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.109. RFC 3403 Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database
5.109. RFC3403动态委托发现系统（DDDS）第三部分：域名系统（DNS）数据库
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
5.110. RFC 3513 IP Version 6 Addressing Architecture
5.110. RFC 3513 IP版本6寻址体系结构
This specification documents IPv6 addressing and is not discussed in this document.
本规范记录了IPv6寻址，本文档中未讨论。
5.111. RFC 3518 Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)
5.111. RFC 3518点对点协议（PPP）桥接控制协议（BCP）
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
Experimental RFCs typically define protocols that do not have wide scale 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.
实验性RFC通常定义在Internet上没有广泛实施或使用的协议。它们通常在性质上是恰当的，或者在有限的领域中使用。为了允许潜在的互操作性或其他一些潜在的有用场景，它们被记录到互联网社区中。在少数情况下，它们被作为主流解决方案的替代方案来解决一个公认的问题。
6.1. RFC 1149 Standard for the transmission of IP datagrams on avian carriers
6.1. RFC 1149在鸟类载体上传输IP数据报的标准
There are no IPv4 dependencies in this specification. In fact the 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.
此规范中不存在IPv4依赖项。事实上，该规范的灵活性是，所有版本的IP都应该在其边界内工作，假定数据包仍然足够小，可以在256毫克重量限制下传输。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This specification defines a specification that assumes IPv4 but does not actually have any limitations which would limit its operation in an IPv6 environment.
此规范定义了一个假定为IPv4的规范，但实际上没有任何限制其在IPv6环境中的操作的限制。
This specification is IPv4 dependent, for example:
此规范依赖于IPv4，例如：
3.1 Control Message Format
3.1 控制消息格式
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Total length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Function | Event Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Body |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Identifier | Total length |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Function | Event Status |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint 1 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Endpoint 2 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Message |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Body |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Endpoint addresses: 32 bits each
端点地址：每个32位
The internet addresses of the two communicating parties for which the link is being prepared.
为其准备链接的两个通信方的internet地址。
This document uses an IPv4 option. It is therefore limited to IPv4 networks, and is incompatible with IPv6.
此文档使用IPv4选项。因此，它仅限于IPv4网络，并且与IPv6不兼容。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.8. RFC 1464 Using the Domain Name System To Store Arbitrary String Attributes
6.8. RFC 1464使用域名系统存储任意字符串属性
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This document defines IPv7 and has been abandoned by the IETF as a feasible design. It is not considered in this document.
本文件定义了IPv7，已被IETF作为可行设计放弃。本文件不考虑这一点。
This document defines the use of NSAP addressing and does not use any version of IP, so there are no IPv4 dependencies in this specification.
本文档定义了NSAP寻址的使用，并且没有使用任何版本的IP，因此本规范中没有IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This document defines a specification that is IPv4 specific, for example:
本文档定义了特定于IPv4的规范，例如：
4. Packet Formats
4. 包格式
NARP requests and replies are carried in IP packets as protocol type 54. This section describes the packet formats of NARP requests and replies:
NARP请求和应答作为协议类型54在IP数据包中进行。本节介绍NARP请求和回复的数据包格式：
NARP Request
NARP请求
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Hop Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBMA length | NBMA address |
+-+-+-+-+-+-+-+-+ |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Hop Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBMA length | NBMA address |
+-+-+-+-+-+-+-+-+ |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source and Destination IP Addresses Respectively, these are the IP addresses of the NARP requester and the target terminal for which the NBMA address is desired.
源IP地址和目标IP地址分别为NARP请求者和目标终端（需要NBMA地址）的IP地址。
And:
以及：
NARP Reply
NARP答复
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Hop Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBMA length | NBMA address |
+-+-+-+-+-+-+-+-+ |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Hop Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBMA length | NBMA address |
+-+-+-+-+-+-+-+-+ |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Source and Destination IP Address Respectively, these are the IP addresses of the NARP requester and the target terminal for which the NBMA address is desired.
源IP地址和目标IP地址分别是NARP请求者的IP地址和需要NBMA地址的目标终端的IP地址。
This is incompatible with IPv6.
这与IPv6不兼容。
This specification defines multicasting for CLNP, which is not an IP protocol, and therefore has no IPv4 dependencies.
该规范定义了CLNP的多播，CLNP不是IP协议，因此没有IPv4依赖项。
This specification is used for updates to the in-addr.arpa reverse DNS maps, and is limited to IPv4.
此规范用于更新in-addr.arpa反向DNS映射，仅限于IPv4。
This document is specific to IPv4 address architecture, and as such, has no IPv6 dependencies.
本文档特定于IPv4地址体系结构，因此没有IPv6依赖项。
6.16. RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+
6.16. RFC 1819 Internet流协议版本2（ST2）协议规范-版本ST2+
This specification is IPv4 limited. In fact it is the definition of IPv5. It has been abandoned by the IETF as feasible design, and is not considered in this discussion.
此规范受IPv4限制。事实上，这是IPv5的定义。IETF已将其视为可行设计而放弃，本次讨论不考虑。
This specification defines an extension to IPv4 ARP to delete entries from ARP caches on a link.
本规范定义了IPv4 ARP的扩展，用于从链路上的ARP缓存中删除条目。
6.18. RFC 1876 A Means for Expressing Location Information in the Domain Name System
6.18. RFC 1876在域名系统中表示位置信息的方法
This document defines a methodology for applying this technology which is IPv4 dependent. The specification itself has no IPv4 dependencies.
本文档定义了应用此技术的方法，此技术依赖于IPv4。规范本身没有IPv4依赖项。
This is an IPv6 related document and is not discussed in this document.
这是一份与IPv6相关的文档，本文档中没有讨论。
The document states:
该文件指出：
The future version of IP (IP v6) will certainly have a sufficient number of bits in its addressing space to provide an address for even smaller GPS addressable units. In this proposal, however, we assume the current version of IP (IP v4) and we make sure that we manage the addressing space more economically than that. We will call the smallest GPS addressable unit a GPS-square.
IP的未来版本（IPV6）的寻址空间中肯定会有足够数量的位，以便为更小的GPS可寻址单元提供地址。然而，在本提案中，我们假设IP的当前版本（IP v4），并确保我们管理寻址空间的经济性高于此。我们将最小的GPS可寻址单元称为GPS正方形。
This specification does not seem to have real IPv4 dependencies.
此规范似乎没有真正的IPv4依赖关系。
This specification will only operate using IPv4. As stated in the document:
此规范将仅使用IPv4进行操作。如文件所述：
It was decided that the ten byte header offers the greatest flexibility for encapsulating version 4 IP datagrams for the following reasons: [...]
由于以下原因，决定使用十字节报头封装版本4的IP数据报具有最大的灵活性：[……]
This is incompatible with IPv6.
这与IPv6不兼容。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
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.
本文档提供了在IPv4网络上使用的默认值，但其设计是可扩展的，因此它将使用具有适当IANA定义的IPv6。
This is an IPv6 related document and is not discussed in this document.
这是一份与IPv6相关的文档，本文档中没有讨论。
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
6.28. RFC 2823 PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing
6.28. 使用SONET/SDH和类似ATM帧的简单数据链路（SDL）上的RFC 2823 PPP
There are no IPv4 dependencies in this specification.
此规范中不存在IPv4依赖项。
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
6.30. RFC 3168 The Addition of Explicit Congestion Notification (ECN) to IP
6.30. RFC 3168将显式拥塞通知（ECN）添加到IP
This specification is both IPv4 and IPv6 aware and needs no changes.
此规范支持IPv4和IPv6，无需更改。
This document is specific to IPv4 multicast addressing.
本文档特定于IPv4多播寻址。
In the initial survey of RFCs 52 positives were identified out of a total of 186, broken down as follows:
在对RFC的初步调查中，在总共186个样本中发现了52个阳性样本，细分如下：
Standards: 17 out of 24 or 70.83% Draft Standards: 6 out of 20 or 30.00% Proposed Standards: 22 out of 111 or 19.91% Experimental RFCs: 7 out of 31 or 22.58%
标准：24项标准中的17项或70.83%标准草案：20项标准中的6项或30.00%拟定标准：111项标准中的22项或19.91%实验性RFC：31项标准中的7项或22.58%
Of those identified many require no action because they document outdated and unused protocols, while others are document protocols that are actively being updated by the appropriate working groups. Additionally there are many instances of standards that should be updated but do not cause any operational impact if they are not updated.
在已确定的协议中，许多协议不需要采取行动，因为它们记录了过时和未使用的协议，而其他协议则记录了相关工作组正在积极更新的协议。此外，还有许多应更新的标准实例，但如果不更新，则不会造成任何运营影响。
RFC 791 has been updated in the definition of IPv6 in RFC 2460.
RFC 2460中的IPv6定义已更新RFC 791。
RFC 792 has been updated in the definition of ICMPv6 in RFC 2463.
RFC 2463中ICMPv6的定义已更新RFC 792。
DCN has long since been ceased to be used, so this specification is no longer relevant.
DCN早已停止使用，因此本规范不再适用。
This problem has been fixed by RFC 2464, A Method for the Transmission of IPv6 Packets over Ethernet Networks.
RFC2464（一种通过以太网传输IPv6数据包的方法）已修复了此问题。
It is believed that experimental Ethernet networks are not being used anymore, so the specification is no longer relevant.
据信，实验性以太网已不再使用，因此该规范不再适用。
7.1.6. RFC 922 Broadcasting Internet Datagrams in the Presence of Subnets
7.1.6. RFC 922在存在子网的情况下广播互联网数据报
Broadcasting is not used in IPv6, but similar functionality has been included in RFC 3513, IPv6 Addressing Architecture.
IPv6中未使用广播，但RFC 3513（IPv6寻址体系结构）中包含了类似的功能。
Broadcasting is not used in IPv6, but similar functionality has been included in RFC 3513, IPv6 Addressing Architecture.
IPv6中未使用广播，但RFC 3513（IPv6寻址体系结构）中包含了类似的功能。
The problems have been fixed by defining new resource records for IPv6 addresses.
通过为IPv6地址定义新的资源记录，这些问题已得到修复。
The problems have been fixed by defining new resource records for IPv6 addresses.
通过为IPv6地址定义新的资源记录，这些问题已得到修复。
This problem has been fixed by RFC 2470, Transmission of IPv6 Packets over Token Ring Networks.
RFC 2470（通过令牌环网传输IPv6数据包）解决了此问题。
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
The IPv4-specific parts of RFC 1112 have been updated in RFC 2710, Multicast Listener Discovery for IPv6.
RFC 1112的IPv4特定部分已在RFC 2710“IPv6多播侦听器发现”中更新。
RFC 1122 is essentially a requirements document for IPv4 hosts. Similar work is in progress [2].
RFC1122本质上是IPv4主机的需求文档。类似的工作正在进行[2]。
This problem has been fixed by RFC 2497, A Method for the Transmission of IPv6 Packets over ARCnet Networks.
RFC 2497（一种通过ARCnet网络传输IPv6数据包的方法）已修复了此问题。
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
This problem has been fixed by RFC 2467, Transmission of IPv6 Packets over FDDI Networks.
RFC2467（通过FDDI网络传输IPv6数据包）解决了此问题。
This problem has been fixed by RFC 2462, IPv6 Stateless Address Autoconfiguration, and RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
此问题已由RFC 2462（IPv6无状态地址自动配置）和RFC 3315（IPv6动态主机配置协议（DHCPv6））修复。
This problem has been fixed in RFC 1981, Path MTU Discovery for IP version 6.
此问题已在RFC 1981《IP版本6的路径MTU发现》中修复。
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.
通过为IPv6定义新的NLPID，可以解决此问题。注意，在RFC2427《多协议帧间互连继电器》中已经定义了NLPID。
A new class identifier ("6") for IPv6 packets has been registered with the IANA by the original author, fixing this problem.
原作者已向IANA注册了IPv6数据包的新类标识符（“6”），解决了此问题。
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
This problem has been fixed in RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
RFC 3315，IPv6的动态主机配置协议（DHCPv6）中已修复了此问题。
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.
此外，DHC工作组的共识是，为DHCPv4定义的选项不会自动“结转”到DHCPv6。因此，本备忘录中省略了对额外指定的DHCPv4选项的任何进一步分析。
No updated document exists for this specification. In practice, the similar effect can be achieved by the use of a layer 2 tunneling protocol. It is unclear whether an updated document is needed.
此规范不存在更新的文档。在实践中，通过使用第2层隧道协议可以实现类似的效果。目前尚不清楚是否需要更新文件。
This problem has been resolved in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).
此问题已在RFC 2461《IP版本6（IPv6）的邻居发现》中得到解决。
7.3.3. RFC 1277 Encoding Net Addresses to Support Operation Over Non OSI Lower Layers
7.3.3. RFC 1277编码网络地址以支持非OSI较低层上的操作
No updated document exists for this specification; the problem might be resolved by the creation of a new encoding scheme if necessary. It is unclear whether an update is needed.
本规范无更新文件；如有必要，可通过创建新的编码方案来解决此问题。目前尚不清楚是否需要更新。
This problem has been resolved in RFC 2472, IP Version 6 over PPP.
该问题已在RFC 2472，IP版本6 over PPP中得到解决。
The functionality of this specification has been essentially covered in RFC 2470, Transmission of IPv6 Packets over Token Ring Networks.
RFC 2470《通过令牌环网传输IPv6数据包》基本上涵盖了本规范的功能。
This problem has been fixed by defining different IP-in-IP encapsulation, for example, RFC 2473, Generic Packet Tunneling in IPv6 Specification.
通过在IP封装中定义不同的IP，例如RFC 2473，IPv6规范中的通用数据包隧道，解决了这个问题。
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
7.3.8. RFC 2022 Support for Multicast over UNI 3.0/3.1 based ATM Networks
7.3.8. RFC 2022支持基于UNI 3.0/3.1的ATM网络上的多播
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
This problem has been fixed in RFC 2711, IPv6 Router Alert Option.
此问题已在RFC 2711，IPv6路由器警报选项中修复。
The problems have been addressed in RFC 3111, Service Location Protocol Modifications for IPv6.
这些问题已在RFC3111《IPv6服务位置协议修改》中得到解决。
The problems have been resolved in RFC 2492, IPv6 over ATM Networks.
这些问题已在RFC2492、IPv6 over ATM网络中得到解决。
The problems have been resolved in RFC 2492, IPv6 over ATM Networks.
这些问题已在RFC2492、IPv6 over ATM网络中得到解决。
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
There is work in progress to fix these problems
目前正在进行修复这些问题的工作
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
This problem has been fixed by RFC 3146, Transmission of IPv6 Packets Over IEEE 1394 Networks.
RFC 3146（通过IEEE 1394网络传输IPv6数据包）解决了此问题。
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
The problems have been resolved by RFC 3775 and RFC 3776 [3, 4].
RFC 3775和RFC 3776已经解决了这些问题[3,4]。
Since the first Mobile IPv4 specification in RFC 2002, a number of extensions to it have been specified. As all of these depend on MIPv4, they have been omitted from further analysis in this memo.
自2002年RFC推出第一个移动IPv4规范以来，已经指定了许多扩展。由于所有这些都依赖于MIPv4，因此在本备忘录的进一步分析中省略了它们。
This problem is being fixed by MLDv2 specification [5].
MLDv2规范[5]正在修复此问题。
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
This specification relies on the use of an IPv4 option. No replacement document exists, and it is unclear whether one is needed.
此规范依赖于IPv4选项的使用。没有替代文件，也不清楚是否需要。
This functionality has been defined in RFC 2491, IPv6 over Non-Broadcast Multiple Access (NBMA) networks and RFC 2332, NBMA Next Hop Resolution Protocol (NHRP).
该功能已在RFC 2491、非广播多址（NBMA）网络上的IPv6和RFC 2332、NBMA下一跳解析协议（NHRP）中定义。
No updated document exists for this specification. However, DNS Dynamic Updates should provide similar functionality, so an update does not seem necessary.
此规范不存在更新的文档。但是，DNS动态更新应该提供类似的功能，因此更新似乎没有必要。
This mechanism defined a mechanism to purge ARP caches on a link. That functionality already exists in RFC 2461, Neighbor Discovery for IPv6.
此机制定义了清除链接上ARP缓存的机制。该功能已经存在于RFC 2461中，即IPv6的邻居发现。
No updated document exists for this specification. It is unclear whether one is needed.
此规范不存在更新的文档。目前尚不清楚是否需要一个。
Similar functionality is provided by RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses, and no action is necessary.
RFC3306（基于单播前缀的IPv6多播地址）提供了类似的功能，无需执行任何操作。
This memo examines the IPv6-readiness of specifications; this does not have security considerations in itself.
本备忘录审查了规范的IPv6准备情况；这本身没有安全考虑。
The author would like to acknowledge the support of the Internet Society in the research and production of this document. Additionally the author would like to thanks his partner in all ways, Wendy M. Nesser.
作者感谢互联网协会在本文件的研究和制作过程中给予的支持。此外，作者还要感谢他的合作伙伴Wendy M.Nesser。
The editor, Cleveland Mickles, would like to thank Steve Bellovin and Russ Housley for their comments and Pekka Savola for his comments and guidance during the editing of this document. Additionally, he would like to thank his wife, Lesia, for her patient support.
编辑克利夫兰·米克尔斯（Cleveland Mickles）感谢史蒂夫·贝洛文（Steve Bellovin）和罗斯·霍斯利（Russ Housley）的评论，并感谢佩卡·萨沃拉（Pekka Savola）在编辑本文件期间的评论和指导。此外，他还要感谢他的妻子莱西亚对他的耐心支持。
Pekka Savola helped in editing the latest versions of the document.
佩卡·萨沃拉帮助编辑了该文件的最新版本。
[1] Nesser II, P. and A. Bergstrom, Editor, "Introduction to the Survey of IPv4 Addresses in Currently Deployed IETF Standards", RFC 3789, June 2004.
[1] Nesser II，P.和A.Bergstrom，编辑，“当前部署的IETF标准中IPv4地址调查简介”，RFC 3789，2004年6月。
[2] Loughney, J., Ed., "IPv6 Node Requirements", Work in Progress, January 2004.
[2] Loughney，J.，编辑，“IPv6节点要求”，正在进行的工作，2004年1月。
[3] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in IPv6", RFC 3775, June 2004.
[3] Johnson，D.，Perkins，C.和J.Arkko，“IPv6中的移动支持”，RFC 37752004年6月。
[4] Arkko, J., Devarapalli, V. and F. Dupont, "Using IPsec to Protect Mobile IPv6 Signaling Between Mobile Nodes and Home Agents", RFC 3776, June 2004.
[4] Arkko，J.，Devarapalli，V.和F.Dupont，“使用IPsec保护移动节点和家庭代理之间的移动IPv6信令”，RFC 37762004年6月。
[5] Vida, R. and L. Costa, Eds., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[5] Vida，R.和L.Costa，编辑，“IPv6多播侦听器发现版本2（MLDv2）”，RFC 3810，2004年6月。
Cleveland Mickles, Editor Reston, VA 20191 USA
克利夫兰·米克尔斯，编辑雷斯顿，弗吉尼亚州，美国
EMail: cmickles.ee88@gtalumni.org
EMail: cmickles.ee88@gtalumni.org
Philip J. Nesser II Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034 USA
Philip J.Nesser II Nesser&Nesser Consulting美国华盛顿州柯克兰市第100大道13501号，邮编：98034
EMail: phil@nesser.com
EMail: phil@nesser.com
Copyright (C) The Internet Society (2004). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights.
版权所有（C）互联网协会（2004年）。本文件受BCP 78中包含的权利、许可和限制的约束，除其中规定外，作者保留其所有权利。
This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM 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.
本文件及其包含的信息是按“原样”提供的，贡献者、他/她所代表或赞助的组织（如有）、互联网协会和互联网工程任务组不承担任何明示或暗示的担保，包括但不限于任何保证，即使用本文中的信息不会侵犯任何权利，或对适销性或特定用途适用性的任何默示保证。
Intellectual Property
知识产权
The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79.
IETF对可能声称与本文件所述技术的实施或使用有关的任何知识产权或其他权利的有效性或范围，或此类权利下的任何许可可能或可能不可用的程度，不采取任何立场；它也不表示它已作出任何独立努力来确定任何此类权利。有关RFC文件中权利的程序信息，请参见BCP 78和BCP 79。
Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr.
向IETF秘书处披露的知识产权副本和任何许可证保证，或本规范实施者或用户试图获得使用此类专有权利的一般许可证或许可的结果，可从IETF在线知识产权存储库获取，网址为http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org.
IETF邀请任何相关方提请其注意任何版权、专利或专利申请，或其他可能涵盖实施本标准所需技术的专有权利。请将信息发送至IETF的IETF-ipr@ietf.org.
Acknowledgement
确认
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC编辑功能的资金目前由互联网协会提供。