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
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.
この文書では、IPv4のすべての使用は、現在配備IETFインターネットエリア文書化基準に対処し文書化することを目指しています。正常にすべてのIPv6インターネットにすべてのIPv4インターネットから移行するために、多くの中間ステップが取られます。これらのステップの一つは、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
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
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.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
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.
この特定の文書には、インターネット領域内の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のコメントは、自然の中で「生」であり、RFC 1から始まり、RFC 3100（約）で終わる順番に議論されています。つまり、各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は、結果のすべてが全体としてみなされ、それ以降のRFCsで解決された問題が相関していることをここであり、セクション3に提示されたデータの分析である4、5、および6。
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. Standard for the transmission of IP datagrams over Ethernet networks
3.5. イーサネットネットワーク上でIPデータグラムの送信のための標準
This specification specifically deals with the transmission of IPv4 packets over Ethernet.
この仕様は、特にイーサネット経由でIPv4パケットの送信を扱っています。
3.6. Standard for the transmission of IP datagrams over experimental Ethernet networks
3.6. 実験的なイーサネットネットワーク上で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
INクラスの場合、32ビットのIPアドレス
And Section 5.2.1, "Typical functions" defines:
そして、5.2.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のRRの要求に変換します。 DNSは、RRの順序を保持しないので、この関数は、返されるアドレスをソートしたり、サービスがクライアントに一つだけの選択肢を返した場合、「最良の」アドレスを選択することもできます。複数のアドレスリターンが推奨されていますが、単一のアドレスは、前HOSTS.TXTサービスをエミュレートするための唯一の方法かもしれません。
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 RRを探します。
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 |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
どこ：
ADDRESS A 32 bit Internet address.
32ビットのインターネットアドレス。
Hosts that have multiple Internet addresses will have multiple A records.
複数のインターネットアドレスを持つホストは、複数の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").
レコードは追加のセクション処理を引き起こしません。マスタファイルの行のRDATA部は、インターネットアドレスは、任意の埋め込みスペースなしドットで区切られた4つの10進数として表現される（例えば、「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> /
/ /
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
どこ：
ADDRESS An 32 bit Internet address
32ビットのインターネットアドレスに対応
PROTOCOL An 8 bit IP protocol number
PROTOCOL 8ビットのIPプロトコル番号
<BIT MAP> A variable length bit map. The bit map must be a multiple of 8 bits long.
<ビットマップ>可変長ビットマップ。ビットマップは、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プロトコル番号を指定し、ビットマップは、指定されたプロトコルのポートごとに1ビットを有します。最初のビットは、ビットマップは、関心のプロトコルのためのビットを含まない場合、そのビットはゼロと仮定される等ポート1、第2、ポート0に対応します。ポートおよびプロトコルの適切な値とニーモニックは、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.
例えば、PROTOCOL = 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 RRの目的は、TCPとUDPのためのサーバーの可用性情報を提供することです。サーバーは、TCPとUDPの両方をサポートし、または複数のインターネットアドレスを持っている場合は、複数のWKS RRは使用されています。
WKS RRs cause no additional section processing.
WKSのRRは追加のセクション処理を引き起こしません。
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. Standard for the transmission of IP datagrams over IEEE 802 networks
3.13. IEEE 802ネットワーク上でIPデータグラムを送信するための標準
This specification specifically deals with the transmission of IPv4 packets over IEEE 802 networks.
この仕様は、特にIEEE 802ネットワーク上でIPv4パケットの送信を扱っています。
3.14. Internet Protocol on Network System's HYPERchannel: Protocol Specification
3.14. ネットワークシステムのHYPERchannel上のインターネット・プロトコル：プロトコル仕様
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.
HYPERchannelヘッダーの32ビット・フィールドにIPv4アドレスをマッピングするために、この規格で使用される様々な方法があります。この仕様はIPv6をサポートしていません。
3.15. Nonstandard for transmission of IP datagrams over serial lines: SLIP
3.15. SLIP：シリアル回線を介してIPデータグラムを送信するための非標準
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.
この仕様は驚くべきことではないSLIPの欠点の分析の詳細です。 SLIPの一般的な置換としてPPPの導入は、この明細書は、本質的に未使用となりました。更新は考慮される必要がありません。
3.16. Standard for the transmission of IP datagrams over NetBIOS networks
3.16. NetBIOSのネットワーク上でIPデータグラムの送信のための標準
This specification documents a technique to encapsulate IP packets inside NetBIOS packets.
この仕様は、NetBIOSパケット内のIPパケットをカプセル化するための手法を説明します。
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.
技術は、IPv6アドレスの長さは、NetBIOSの15オクテット名の制限内に収まらないのでIP.XX.XX.XX.XXがIPv6アドレスに対して機能しませんフォームのNetBIOS名を使用しての発表します。
This specification defines IP multicast. Parts of the document are IPv4 dependent.
この仕様は、IPマルチキャストを定義します。文書の一部が依存IPv4のです。
3.18. Standard for the transmission of 802.2 packets over IPX networks
3.18. IPXネットワーク上で802.2パケットを送信するための標準
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アドレスに対する本明細書の主要な関心事は、「ARPlike」方式でIPv4アドレスへのARCnet 8ビットアドレスの分解能で発生します。これは、IPv6と互換性がありません。
This specification defines running IPv4 and ARP over SMDS. The methods described could easily be extended to support IPv6 packets.
この仕様はSMDSの上に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ネットワークのために更新する必要があります。 （ヘッダスペースをリザーブ256個のオクテットで）データの4096オクテットの定義されたMTUの制限は、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
----- ----- ---
[...] 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).
siaddr 4 server IP address; returned in bootreply by server.
4サーバーのIPアドレスSIADDR。サーバがBOOTREPLYに戻りました。
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バイトの既存4つのIPv4フィールドを置き換えるために16バイトの4のIPv6フィールド）を収容できます。
4.2. Proposed Standard for the Transmission of IP Datagrams over FDDI Networks
4.2. 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ヘッダ、ICMPメッセージ（も依存IPv4）とTCP MSSオプションでDFビットの使用を前提としています。これは、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.
明らかに新しいNLPIDは、IPv6パケットのために定義する必要があろう。
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:
クラスザ・クラスフィールドは1つのオクテットで、識別子のアドレス空間を示します。 LCPエンドポイント識別子Classフィールドの最新の値は最新の「番号割り当て」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.
新しいクラスのフィールドは、IPv6アドレスのIANAによって定義する必要があります。
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).
割り当てられた番号で定義されているイーサタイプ（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バイトで1つの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)
This definition is not applicable for IPv6 packets since packets can be larger than the IPv4 limitation of 65280 bytes.
パケットが65280バイトのIPv4の制限よりも大きくすることができるので、この定義は、IPv6パケットには適用されません。
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. Internet Control Message Protocol (ICMPv6) for the Internet Protocol Version 6 (IPv6) Specification
4.19. インターネットプロトコルバージョン6（IPv6）の仕様のためのインターネット制御メッセージプロトコル（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.
このメモの実装では、ホスト番号の最初の2つのオクテットは常にゼロになり、最後の4つのオクテットは、ノードの4つのオクテットのIPアドレスになります。これは、ユニキャスト伝送のためのアドレスマッピングは些細ます：ホスト番号の最初の2つのオクテットは、通常の4つのオクテットのIPアドレスを残して、破棄されます。カプセル化コードは、UDP / IPトンネルパケットの宛先アドレスとして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オクテットです。その結果、576個のオクテットは、このカプセル化技術を用いて送信されるIPXパケットに推奨されるデフォルトの最大送信単位です。 8つのオクテットUDPヘッダおよび20オクテットのIPヘッダで、得られたIPパケットは、604オクテットの長さであろう。これはIPの実装を受け入れるために必要とされる576オクテットの最大サイズよりも大きいことに留意されたいです。このカプセル化技術をサポートしている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. Encoding Network Addresses to Support Operation over Non-OSI Lower Layers
5.3. ネットワークが非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）ネットワーク特定の形式は、」IPアドレスのテキスト表現のための12桁の数字を留保した構造を説明しています。
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アドレスの小数バージョンには不十分です。 IPv6アドレス、ポート番号およびトランスポート・セットのバイナリバージョンに対応するために20桁長いIPアドレス+ポート+トランスポート・セットのフィールドを使用して、新しいエンコードを定義することが可能です。想定することができ、いくつかの方式があります。
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ネゴシエーションが完了するとPPPクライアントにIPv4アドレスを割り当てるためのデバイスのためのメカニズムを定義します。第3節、「IPCP構成オプション」、4バイト長のフィールドにIPアドレスを埋め込む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. The PPP Internetworking Packet Exchange Control Protocol (IPXCP)
5.8. 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アドレスを使用するが、（即ち、レコード）IPv6を使用して完全かつ適切な機能を排除する仕様には何もありません。
5.21. A Mechanism for Prompt Notification of Zone Changes (DNS NOTIFY)
5.21. ゾーンの変更のプロンプトの通知のメカニズム（DNSがNOTIFY）
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ネットワークで使用するために設計されています。 4および32ビットのアドレスの指定されたIPバージョン番号への多くの参照があります。これは、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ネットワークで使用するために設計されています。 4および32ビットのアドレスの指定されたIPバージョン番号への多くの参照があります。これは、IPv6と互換性がありません。
This specification documents the interoperation of IPv4 Mobility Support; this is not relevant to this discussion.
この仕様は、IPv4モビリティサポートの相互運用を文書化します。これは、この議論には関係ありません。
5.25. Support for Multicast over UNI 3.0/3.1 based ATM Networks
5.25. 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. The PPP Bandwidth Allocation Protocol (BAP) / The PPP Bandwidth Allocation Control Protocol (BACP)
5.29. 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アドレスへの参照のみがエニーキャストアドレスの使用を議論するので、しかし、1つは、これらの技術は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（10進数）です。 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（10進数）です。 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.
以前の実装との後方互換性のために、ヌルIPv4プロトコルアドレスは、長さ= 4と値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)
PREFERRED_DSS（コード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アドレスの配列、長さの各4バイトです。アドレスの最大数は5であるため、最大長さ値は20であるリストがnのNetWareドメインSAP / RIPサーバ（DSS）のアドレスを含みます。
NEAREST_NWIP_SERVER (code 7)
NEAREST_NWIP_SERVER（コード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アドレスの配列、長さの各4バイトです。アドレスの最大数は5であるため、最大長さの値が20であるリストは、n最寄りのNetWare / IPサーバのアドレスを含みます。
PRIMARY_DSS (code 11)
PRIMARY_DSS（コード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）を識別します。セカンダリDSSサーバを設定する場合、NetWare / IP管理ユーティリティは、プライマリ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を使用するように設計されています。具体的にはICMPのIPv4のIPを参照する他の「サポート」のメカニズム（すなわち、ICMPルータ発見メッセージ）に多数の紹介があります。
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. ATM Signaling Support for IP over ATM - UNI Signaling 4.0 Update
5.38. ATM上のIPのための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>
<ホスト側> <パス>
The <hostport> component comprises:
<ホスト側>成分を含みます：
<host>[:<port>]
<ホスト> [：<ポート>]
where <host> is either a <dns name> or an <ip address>; and <port> is a decimal number specifying the port at which the transaction manager (or proxy) is listening for requests to establish TIP connections. If the port number is omitted, the standard TIP port number (3372) is used.
ここで、<ホスト> <DNS名>または<IPアドレス>のいずれかです。そして、<port>は、トランザクション・マネージャ（またはプロキシ）はTIP接続を確立するための要求をリスニングするポートを指定する10進数です。ポート番号が省略された場合、標準的な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.
ピリオド文字で区切られた4つの10進数：<IPアドレス>通常の形式のIPアドレスは、です。
And further along it states:
そして、それに沿ってさらに述べています：
A TIP URL takes the form:
TIPのURLは次の形式をとります。
tip://<transaction manager address>?<transaction string>
ヒント：？// <トランザクションマネージャーアドレス> <トランザクション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):
（第7上記で定義されるように）<トランザクション・マネージャ・アドレス>は、TIPトランザクションマネージャを識別する。そして、<トランザクションstring>は二つの形式（標準または非標準）のいずれかをとることができ、トランザクション識別子を指定します：
i. "urn:" <NID> ":" <NSS>
私は。 "URN：" <NOT> "：" <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.,
<トランザクションストリング>のこの形式は、標準的な表現でグローバルトランザクション識別子を発現するために使用されてもよいです。 <NID>の例は、例えば、<ISO>または<XOPEN>かもしれません
tip://123.123.123.123/?urn:xopen:xid
ヒント：？//123.123.123.123/のurn：XOPEN：XID
Note that Namespace Ids require registration.
名前空間Idsが登録を必要とすることに注意してください。
ii. <transaction identifier>
II。 <トランザクション識別子>
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包括的なとオクテット「：」トランザクション識別子を表す）は、この非標準の場合には、<トランザクション・マネージャ・アドレス>と<トランザクション識別子>の組み合わせでありますこれは例えば、グローバル一意性を保証し、
tip://123.123.123.123/?transid1
ヒント：？//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. DHCP Option for The Open Group's User Authentication Protocol
5.51. Open Groupのユーザー認証プロトコルのための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.
この仕様は、ARCネットネットワーク上で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. Transmission of IPv6 over IPv4 Domains without Explicit Tunnels
5.58. 明示的なトンネルなしのIPv4ドメイン上のIPv6の送信
This specification documents IPv6 transmission methods and is not discussed in this document.
この仕様書のIPv6伝送方法と、この文書で説明されていません。
5.59. DHCP Option to Disable Stateless Auto-Configuration in IPv4 Clients
5.59. DHCPオプションは、IPv4クライアントでステートレス自動設定を無効にします
This is an extension to an IPv4-only specification.
これは、IPv4のみの仕様を拡張したものです。
5.60. Transmission of IPv6 Packets over Frame Relay Networks Specification
5.60. フレームリレーネットワーク仕様の上の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.
この仕様の主な目的は、FC上でのIPv4の相互運用可能な実装を促進することです。この仕様は、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. The Transmission of IP Over the Vertical Blanking Interval of a Television Signal
5.79. テレビ信号の垂直ブランキング間隔で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 |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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. Network Address Translation - Protocol Translation (NAT-PT)
5.83. ネットワークアドレス変換 - プロトコル変換（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 $オペアンプ16ビットオペレーションコード下プロトコルフィールドの$ HRD 16ビット・ハードウェア・タイプのAr $プロ16ビットのプロトコルタイプAR（要求、応答、またはNAK）各プロトコルのAR $ PLN 8ビットバイト長アドレスARの$ RHL 8ビット・リクエスタのHIPPIハードウェアアドレス長（Q）AR $ THL 8ビットターゲットのHIPPIハードウェアアドレス長（X）のArの$ RPA 32ビット・リクエスタのプロトコルアドレスARする$ TPA 32ビットターゲットのプロトコルアドレスのAr $のRHAは、要求者のHIPPIハードウェアをQBYTESアドレスのar $股関節xbytesターゲットのHIPPIハードウェアアドレス
Where: ar$hrd - SHALL contain 28. (HIPARP)
どこ：$難しいです - SHELLは28（HIPARP）を含有します
ar$pro - SHALL contain the IP protocol code 2048 (decimal).
ARの$プロ - IPプロトコルコード2048（10進数）を含まなければなりません。
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 $オペアンプ - 演算値（10進数）を含まなければならない：1 HARP_NAK ARする$ PLNためInHARP_REPLYs 10用InHARP_REQUESTs 9ためHARP_REPLYs 8ためHARP_REQUESTs 2 - 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
This is incompatible with IPv6.
これは、IPv6と互換性がありません。
This document states:
このドキュメントの状態：
The Ethertype value SHALL be set as defined in Assigned Numbers:
割り当てられた番号で定義されているイーサタイプ値が設定されなければなりません。
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. DNS Extensions to Support IPv6 Address Aggregation and Renumbering
5.90. 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 recommended; see RFC 3627, Use of /127 Prefix Length Between Routers Considered Harmful.
この仕様は変更は31ビットのプレフィックスの両方のアドレスを使用するために必要とされるIPv4アドレスアーキテクチャ、に対して特異的です。これは、IPv6アドレスのアーキテクチャによって可能であるが、ほとんどの場合にはお勧めしません。有害と考えられルータ間の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関連の文書であり、この文書で説明されていません。
This is an IPv6 related document and is not discussed in this document.
これは、IPv6関連の文書であり、この文書で説明されていません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.103. A Link-Layer Tunneling Mechanism for Unidirectional Links
5.103。単方向リンクのリンク層トンネル機構
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6の両方を認識しており、何も変更を必要としません。
This is an extension to an IPv4-only specification.
これは、IPv4のみの仕様を拡張したものです。
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
There are IPv4 dependencies in this specification.
この仕様ではIPv4の依存関係があります。
This document describes of version of IGMP used for IPv4 multicast. This is not compatible with IPv6.
この文書では、IPv4マルチキャストに使用するIGMPのバージョンを記述します。これは、IPv6と互換性がありません。
5.108. Dynamic Delegation Discovery System (DDDS) Part Two: The Algorithm
5.108。ダイナミックな委譲発見システム（DDDS）パート2：アルゴリズム
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
5.109. Dynamic Delegation Discovery System (DDDS) Part Three: The Domain Name System (DNS) Database
5.109。ダイナミックな委譲発見システム（DDDS）パート3：ドメインネームシステム（DNS）データベース
There are no IPv4 dependencies in this specification.
この仕様にはIPv4の依存関係はありません。
This specification documents IPv6 addressing and is not discussed in this document.
この仕様書は、IPv6アドレス指定し、この文書で説明されていません。
5.111. Point-to-Point Protocol (PPP) Bridging Control Protocol (BCP)
5.111。ポイントツーポイントプロトコル（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は、通常、インターネット上の広いスケールの実装や使用していないプロトコルを定義します。彼らは多くの場合、自然の中で妥当または制限された競技場で使用されています。彼らは、潜在的な相互運用性またはいくつかの他の潜在的に有用なシナリオを可能にするためにインターネットコミュニティに文書化されています。いくつかのケースでは、彼らは認め問題の主流の解決策の代替として提示されています。
6.1. Standard for the transmission of IP datagrams on avian carriers
6.1. 鳥類のキャリア上の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には、例えば、依存しています：
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.
リンクが用意されているため、2人の通信当事者のインターネットアドレス。
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. Using the Domain Name System To Store Arbitrary String Attributes
6.8. 任意の文字列の属性を格納するためにドメインネームシステムを使用して
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の特異的である仕様を定義します。
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このセクションでは、NARP要求と応答のパケットフォーマットを説明し、プロトコルの種類としてIPパケットで運ばれています。
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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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アドレスは、それぞれ、これらは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) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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アドレスは、それぞれ、これらはNARPリクエスタと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.
この仕様は、IPプロトコルされていない、CLNPのためにマルチキャストを定義し、したがって何のIPv4依存性を有していません。
This specification is used for updates to the in-addr.arpa reverse DNS maps, and is limited to IPv4.
この仕様は、DNSマップを逆IN-ADDR.ARPAの更新のために使用されている、とIPv4に限定されています。
This document is specific to IPv4 address architecture, and as such, has no IPv6 dependencies.
この文書は、IPv4アドレスアーキテクチャに特有であり、そのようなものとして、何のIPv6依存性を有していません。
6.16. Internet Stream Protocol Version 2 (ST2) Protocol Specification - Version ST2+
6.16. インターネットストリームプロトコルバージョン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.
この仕様は、リンク上のARPキャッシュからエントリを削除するには、IPv4のARPに拡張子を定義します。
6.18. A Means for Expressing Location Information in the Domain Name System
6.18. ドメインネームシステムに位置情報を表現するための手段
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（IPバージョン6）の将来のバージョンは確かも小さい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: [...]
[...]：これは、10バイトのヘッダーは、次のような理由から、バージョン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. PPP over Simple Data Link (SDL) using SONET/SDH with ATM-like framing
6.28. 単純なデータリンク上でPPP（SDL）ATMのようなフレーミングで使用してSONET / SDH
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. The Addition of Explicit Congestion Notification (ECN) to IP
6.30. IPへの明示的輻輳通知（ECN）の追加
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の初期調査では52個の陽性は、次のように分解、186の合計のうち、同定されました。
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%
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 791は、RFC 2460でのIPv6の定義に更新されています。
RFC 792 has been updated in the definition of ICMPv6 in RFC 2463.
RFC 792は、RFC 2463でのICMPv6の定義に更新されています。
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.
この問題は、RFC 2464、イーサネット・ネットワーク上のIPv6パケットの伝送のための方法で固定されています。
It is believed that experimental Ethernet networks are not being used anymore, so the specification is no longer relevant.
実験的なイーサネットネットワークはもう使用されていないことを信じていないので、仕様はもはや適切であるされています。
7.1.6. Broadcasting Internet Datagrams in the Presence of Subnets
7.1.6. サブネットの存在下での放送、インターネットデータグラム
Broadcasting is not used in IPv6, but similar functionality has been included in RFC 3513, IPv6 Addressing Architecture.
放送は、IPv6で使用されていませんが、同様の機能は、IPv6のアーキテクチャをアドレス指定、RFC 3513に含まれています。
Broadcasting is not used in IPv6, but similar functionality has been included in RFC 3513, IPv6 Addressing Architecture.
放送は、IPv6で使用されていませんが、同様の機能は、IPv6のアーキテクチャをアドレス指定、RFC 3513に含まれています。
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.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
No updated document exists for this specification. It is unclear whether one is needed.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
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].
RFC 1122は、本質的にIPv4ホストのための要件ドキュメントです。同様の作業が進行中である[2]。
This problem has been fixed by RFC 2497, A Method for the Transmission of IPv6 Packets over ARCnet Networks.
この問題は、RFC 2497、ARCネットネットワークの上のIPv6パケットのトランスミッションのための方法で固定されています。
No updated document exists for this specification. It is unclear whether one is needed.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
This problem has been fixed by RFC 2467, Transmission of IPv6 Packets over FDDI Networks.
この問題は、RFC 2467、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を定義することによって固定することができます。 NLPIDが既にRFC 2427で定義されていることに注意してください、フレームリレー上のマルチインターコネクト。
A new class identifier ("6") for IPv6 packets has been registered with the IANA by the original author, fixing this problem.
IPv6パケットのための新しいクラス識別子（「6」）は、この問題を解決し、元の著者によってIANAに登録されています。
No updated document exists for this specification. It is unclear whether one is needed.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
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 WGのコンセンサスは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).
この問題は、IPバージョン6のための近隣探索（IPv6）の、RFC 2461で解決されました。
7.3.3. Encoding Net Addresses to Support Operation Over Non OSI Lower Layers
7.3.3. 操作より非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、PPP上でのIPバージョン6で解決されました。
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.
この問題は、IPv6仕様では、例えば、RFC 2473、汎用パケットトンネリングを異なるIP-in-IPカプセル化を定義することによって固定されています。
No updated document exists for this specification. It is unclear whether one is needed.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
7.3.8. Support for Multicast over UNI 3.0/3.1 based ATM Networks
7.3.8. UNI 3.0 / 3.1ベースのATMネットワーク経由のマルチキャストのサポート
No updated document exists for this specification. It is unclear whether one is needed.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
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.
問題は、サービスロケーションプロトコルの変更は、IPv6のために、RFC 3111で対処されています。
The problems have been resolved in RFC 2492, IPv6 over ATM Networks.
問題は、RFC 2492で、IPv6のATMネットワーク上で解決されています。
The problems have been resolved in RFC 2492, IPv6 over ATM Networks.
問題は、RFC 2492で、IPv6のATMネットワーク上で解決されています。
No updated document exists for this specification. It is unclear whether one is needed.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
There is work in progress to fix these problems
これらの問題を解決するために進行中の作業があります
No updated document exists for this specification. It is unclear whether one is needed.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
No updated document exists for this specification. It is unclear whether one is needed.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
No updated document exists for this specification. It is unclear whether one is needed.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
This problem has been fixed by RFC 3146, Transmission of IPv6 Packets Over IEEE 1394 Networks.
この問題は、IEEEの上のIPv6パケットのトランスミッション1394のネットワーク、RFC 3146で固定されています。
No updated document exists for this specification. It is unclear whether one is needed.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
No updated document exists for this specification. It is unclear whether one is needed.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
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.
RFC 2002で最初のモバイル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.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
This specification relies on the use of an IPv4 option. No replacement document exists, and it is unclear whether one is needed.
この仕様は、IPv4オプションの使用に依存しています。代替はありません。文書は存在しない、1が必要とされているかどうかは不明です。
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で定義されている、IPv6を介した非ブロードキャスト多重アクセス（NBMA）ネットワークと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.
いいえ更新された文書は、この仕様のために存在しません。 1つが必要とされているかどうかは不明です。
Similar functionality is provided by RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses, and no action is necessary.
同様の機能は、RFC 3306によって提供され、ユニキャストプレフィックスベースの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.
著者は、この文書の研究と生産におけるインターネット協会の支援を承認したいと思います。さらに著者は、すべての方法で彼のパートナー、ウェンディー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.
エディタ、クリーブランドMicklesは、このドキュメントの編集中に彼のコメントと指導のために彼らのコメントとペッカSavolaのためのスティーブBellovin氏とラスHousleyに感謝したいと思います。さらに、彼は彼女の患者支援のために、彼の妻、Lesiaに感謝したいと思います。
Pekka Savola helped in editing the latest versions of the document.
ペッカSavolaは、ドキュメントの最新バージョンを編集して助けました。
[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.ベルイストローム、エディタを、RFC 3789、2004年6月 "のIPv4の調査の概要は、現在展開IETF標準のアドレス"。
[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]ジョンソン、D.、パーキンス、C.とJ. Arkko、 "IPv6におけるモビリティサポート"、RFC 3775、2004年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.デュポンが、 "モバイルノードとホームエージェント間のモバイルIPv6シグナリングを保護するためにIPsecを使用する"、RFC 3776、2004年6月。
[5] Vida, R. and L. Costa, Eds., "Multicast Listener Discovery Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[5]ヴィーダ、R.とL.コスタ、編、 "マルチキャストリスナ発見バージョン2 IPv6用（MLDv2の）"、RFC 3810、2004年6月。
Cleveland Mickles, Editor Reston, VA 20191 USA
クリーブランドMickles、エディタレストン、VA 20191 USA
EMail: cmickles.ee88@gtalumni.org
メールアドレス：cmickles.ee88@gtalumni.org
Philip J. Nesser II Nesser & Nesser Consulting 13501 100th Ave NE, #5202 Kirkland, WA 98034 USA
フィリップJ. Nesser II Nesser＆Nesserコンサルティング13501第百アヴェNE、＃5202カークランド、WA 98034 USA
EMail: phil@nesser.com
メールアドレス：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.
この文書とここに含まれている情報は、基礎とCONTRIBUTOR「そのまま」、ORGANIZATION HE / SHEが表すまたはインターネットソサエティおよびインターネット・エンジニアリング・タスク・フォース放棄すべての保証、明示または、（もしあれば）後援ISに設けられています。黙示、情報の利用は、特定の目的に対する権利または商品性または適合性の黙示の保証を侵害しない任意の保証含むがこれらに限定されません。
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.
IPRの開示のコピーが利用できるようにIETF事務局とライセンスの保証に行われた、または本仕様の実装者または利用者がそのような所有権の使用のための一般的なライセンスまたは許可を取得するために作られた試みの結果を得ることができますhttp://www.ietf.org/iprのIETFのオンライン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-ipr@ietf.orgのIETFに情報を記述してください。
Acknowledgement
謝辞
Funding for the RFC Editor function is currently provided by the Internet Society.
RFC Editor機能のための基金は現在、インターネット協会によって提供されます。