RFC3790 日本語訳
3790 Survey of IPv4 Addresses in Currently Deployed IETF Internet AreaStandards Track and Experimental Documents. C. Mickles, Ed., P.Nesser, II. June 2004. (Format: TXT=102694 bytes) (Status: INFORMATIONAL)
プログラムでの自動翻訳です。
英語原文
Network Working Group C. Mickles, Ed.
Request for Comments: 3790
Category: Informational P. Nesser, II
Nesser & Nesser Consulting
June 2004
ワーキンググループC.Mickles、エドをネットワークでつないでください。コメントのために以下を要求してください。 3790年のカテゴリ: 情報のP.Nesser、II Nesser、および2004年6月に相談するNesser
Survey of IPv4 Addresses in Currently Deployed
IETF Internet Area Standards Track and Experimental Documents
IPv4の調査は現在配備されたIETFにインターネット領域標準化過程と実験ドキュメントを記述します。
Status of this Memo
この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).
Copyright(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インターネットAreaに記述するドキュメントに探すこれは規格を記録しました。 首尾よくすべてのIPv4インターネットからすべてのIPv6インターネットに移行するために、多くの中間の段階を取るでしょう。 これらのステップの1つはIPv4の依存を持っている現在のプロトコルの発展です。 これらのプロトコル(そして、彼らの実現)がネットワーク・アドレス独立者であることが再設計されることが望まれていますが、それに失敗するのは二元的にIPv4とIPv6を少なくとも支持するでしょう。 このために、Experimental RFCsと同様にすべてのStandards(完全、Draft、およびProposed)が調査されるでしょう、そして、どんな依存も記録されるでしょう。
Table of Contents
目次
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 9
2. Document Organization. . . . . . . . . . . . . . . . . . . . 9
3. Full Standards . . . . . . . . . . . . . . . . . . . . . . . 9
3.1. RFC 791 Internet Protocol . . . . . . . . . . . . . . 9
3.2. RFC 792 Internet Control Message Protocol . . . . . . 9
3.3. RFC 826 Ethernet Address Resolution Protocol. . . . . 9
3.4. RFC 891 DCN Local-Network Protocols . . . . . . . . . 10
3.5. RFC 894 Standard for the transmission of IP datagrams
over Ethernet networks. . . . . . . . . . . . . . . . 10
3.6. RFC 895 Standard for the transmission of IP datagrams
over experimental Ethernet networks . . . . . . . . . 10
3.7. RFC 903 Reverse Address Resolution Protocol . . . . . 10
3.8. RFC 919 Broadcasting Internet Datagrams . . . . . . . 10
1. 序論. . . . . . . . . . . . . . . . . . . . . . . . 9 2。 組織を記録してください。 . . . . . . . . . . . . . . . . . . . 9 3. 完全な規格. . . . . . . . . . . . . . . . . . . . . . . 9 3.1。 RFC791インターネットプロトコル. . . . . . . . . . . . . . 9 3.2。 RFC792インターネット・コントロール・メッセージ・プロトコル. . . . . . 9 3.3。 RFC826イーサネットは解決プロトコルを記述します。 . . . . 9 3.4. RFC891DCN企業内情報通信網プロトコル. . . . . . . . . 10 3.5。 イーサネットネットワークの上のIPデータグラムのトランスミッションのためのRFC894Standard。 . . . . . . . . . . . . . . . 10 3.6. 実験的なイーサネットの上のIPデータグラムのトランスミッションのためのRFC895Standardは.103.7をネットワークでつなぎます。 RFC903はアドレス解決プロトコル. . . . . 10 3.8を覆します。 インターネットデータグラム. . . . . . . 10を放送するRFC919
Mickles & Nesser II Informational [Page 1] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[1ページ]のRFC3790IPv4は領域2004年6月にIETFにインターネットを記述します。
3.9. RFC 922 Broadcasting Internet datagrams in the
presence of subnets . . . . . . . . . . . . . . . . . 10
3.10. RFC 950 Internet Standard Subnetting Procedure. . . . 10
3.11. RFC 1034 Domain Names: Concepts and Facilities. . . . 10
3.12. RFC 1035 Domain Names: Implementation and
Specification . . . . . . . . . . . . . . . . . . . . 11
3.13. RFC 1042 Standard for the transmission of IP datagrams
over IEEE 802 networks . . . . . . . . . . . . . . . 13
3.14. RFC 1044 Internet Protocol on Network System's
HYPERchannel: Protocol Specification . . . . . . . . 13
3.15. RFC 1055 Nonstandard for transmission of IP datagrams
over serial lines: SLIP . . . . . . . . . . . . . . . 13
3.16. RFC 1088 Standard for the transmission of IP
datagrams over NetBIOS networks . . . . . . . . . . . 13
3.17. RFC 1112 Host Extensions for IP Multicasting. . . . . 13
3.18. RFC 1132 Standard for the transmission of 802.2
packets over IPX networks . . . . . . . . . . . . . . 13
3.19. RFC 1201 Transmitting IP traffic over ARCNET
networks. . . . . . . . . . . . . . . . . . . . . . . 13
3.20. RFC 1209 The Transmission of IP Datagrams over the
SMDS Service. . . . . . . . . . . . . . . . . . . . . 14
3.21. RFC 1390 Transmission of IP and ARP over FDDI
Networks. . . . . . . . . . . . . . . . . . . . . . . 14
3.22. RFC 1661 The Point-to-Point Protocol (PPP). . . . . . 14
3.23. RFC 1662 PPP in HDLC-like Framing . . . . . . . . . . 14
3.24. RFC 2427 Multiprotocol Interconnect over Frame Relay. 14
4. Draft Standards . . . . . . . . . . . . . . . . . . . . . . 14
4.1. RFC 951 Bootstrap Protocol (BOOTP). . . . . . . . . . 14
4.2. RFC 1188 Proposed Standard for the Transmission of IP
Datagrams over FDDI Networks. . . . . . . . . . . . . 15
4.3. RFC 1191 Path MTU discovery . . . . . . . . . . . . . 15
4.4. RFC 1356 Multiprotocol Interconnect on X.25 and ISDN. 15
4.5. RFC 1534 Interoperation Between DHCP and BOOTP. . . . 16
4.6. RFC 1542 Clarifications and Extensions for the
Bootstrap Protocol. . . . . . . . . . . . . . . . . . 16
4.7. RFC 1629 Guidelines for OSI NSAP Allocation in the
Internet. . . . . . . . . . . . . . . . . . . . . . . 16
4.8. RFC 1762 The PPP DECnet Phase IV Control Protocol
(DNCP). . . . . . . . . . . . . . . . . . . . . . . . 16
4.9. RFC 1989 PPP Link Quality Monitoring. . . . . . . . . 16
4.10. RFC 1990 The PPP Multilink Protocol (MP). . . . . . . 16
4.11. RFC 1994 PPP Challenge Handshake Authentication
Protocol (CHAP) . . . . . . . . . . . . . . . . . . . 17
4.12. RFC 2067 IP over HIPPI. . . . . . . . . . . . . . . . 17
4.13. RFC 2131 Dynamic Host Configuration Protocol. . . . . 17
4.14. RFC 2132 DHCP Options and BOOTP Vendor Extensions . . 17
4.15. RFC 2390 Inverse Address Resolution Protocol. . . . . 17
3.9. サブネット. . . . . . . . . . . . . . . . . 10 3.10があるときRFC922Broadcastingインターネットデータグラム。 RFC950のインターネットの標準のサブネッティング手順。 . . . 10 3.11. RFC1034ドメイン名: 概念と施設。 . . . 10 3.12. RFC1035ドメイン名: 実現と仕様. . . . . . . . . . . . . . . . . . . . 11 3.13。 IEEE802の上のIPデータグラムのトランスミッションのためのRFC1042Standardは.13 3.14をネットワークでつなぎます。 ネットワーク・システムのHYPERchannelの上のRFC1044インターネットプロトコル: 仕様. . . . . . . . 13 3.15を議定書の中で述べてください。 シリアル・ラインでのIPデータグラムのトランスミッションのためのRFC1055Nonstandard: .13 3.16を滑らせてください。 NetBIOSの上のIPデータグラムのトランスミッションのためのRFC1088Standardは.13 3.17をネットワークでつなぎます。 RFC1112はIPマルチキャスティングのための拡大を主催します。 . . . . 13 3.18. IPXの上の802.2のパケットのトランスミッションのためのRFC1132Standardは.13 3.19をネットワークでつなぎます。 ARCNETネットワークの上のRFC1201Transmitting IP交通。 . . . . . . . . . . . . . . . . . . . . . . 13 3.20. SMDSサービスの上のIPデータグラムのRFC1209送信。 . . . . . . . . . . . . . . . . . . . . 14 3.21. FDDIネットワークの上のIPとARPのRFC1390トランスミッション。 . . . . . . . . . . . . . . . . . . . . . . 14 3.22. RFC1661の二地点間プロトコル(ppp)。 . . . . . 14 3.23. HDLCのような縁ど. . . . . . . . . . 14 3.24りにおけるRFC1662ppp。 RFC2427Multiprotocolはフレームリレーの上で内部連絡します。 14 4. 規格. . . . . . . . . . . . . . . . . . . . . . 14 4.1を作成してください。 RFC951はプロトコル(BOOTP)を独力で進みます。 . . . . . . . . . 14 4.2. RFC1188はFDDIネットワークの上でIPデータグラムの送信の規格を提案しました。 . . . . . . . . . . . . 15 4.3. RFC1191Path MTU発見. . . . . . . . . . . . . 15 4.4。 RFC1356MultiprotocolはX.25とISDNで内部連絡します。 15 4.5. DHCPとBOOTPの間のRFC1534Interoperation。 . . . 16 4.6. RFC1542明確化と拡大、プロトコルを独力で進んでください。 . . . . . . . . . . . . . . . . . 16 4.7. インターネットのオウシNSAP AllocationのためのRFC1629ガイドライン。 . . . . . . . . . . . . . . . . . . . . . . 16 4.8. RFC1762ppp DECnetフェーズIVコントロールは(DNCP)について議定書の中で述べます。 . . . . . . . . . . . . . . . . . . . . . . . 16 4.9. RFC1989pppは上質のモニターをリンクします。 . . . . . . . . 16 4.10. RFC1990pppマルチリンクは(MP)について議定書の中で述べます。 . . . . . . 16 4.11. RFC1994pppは握手認証プロトコル(やつ). . . . . . . . . . . . . . . . . . . 17 4.12に挑戦します。 HIPPIの上のRFC2067IP。 . . . . . . . . . . . . . . . 17 4.13. RFC2131Dynamic Host Configuration Protocol。 . . . . 17 4.14. RFC2132DHCPオプションとBOOTP業者拡張子. . 17 4.15。 RFC2390の逆さのアドレス解決プロトコル。 . . . . 17
Mickles & Nesser II Informational [Page 2] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[2ページ]のRFC3790IPv4は領域2004年6月にIETFにインターネットを記述します。
4.16. RFC 2460 Internet Protocol, Version 6 (IPv6)
Specification . . . . . . . . . . . . . . . . . . . . 17
4.17. RFC 2461 Neighbor Discovery for IP Version 6 (IPv6) . 18
4.18. RFC 2462 IPv6 Stateless Address Autoconfiguration . . 18
4.19. RFC 2463 Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6)
Specification. . . . . . . . . . . . . . . . . . . . 18
4.20. RFC 3596 DNS Extensions to support IP version 6 . . . 18
5. Proposed Standards . . . . . . . . . . . . . . . . . . . . . 18
5.1. RFC 1234 Tunneling IPX traffic through IP networks. . 18
5.2. RFC 1256 ICMP Router Discovery Messages . . . . . . . 19
5.3. RFC 1277 Encoding Network Addresses to Support
Operation over Non-OSI Lower Layers . . . . . . . . . 19
5.4. RFC 1332 The PPP Internet Protocol Control Protocol
(IPCP). . . . . . . . . . . . . . . . . . . . . . . . 19
5.5. RFC 1377 The PPP OSI Network Layer Control Protocol
(OSINLCP) . . . . . . . . . . . . . . . . . . . . . . 20
5.6. RFC 1378 The PPP AppleTalk Control Protocol (ATCP). . 20
5.7. RFC 1469 IP Multicast over Token-Ring Local Area
Networks. . . . . . . . . . . . . . . . . . . . . . . 20
5.8. RFC 1552 The PPP Internetworking Packet Exchange
Control Protocol (IPXCP). . . . . . . . . . . . . . . 20
5.9. RFC 1570 PPP LCP Extensions . . . . . . . . . . . . . 20
5.10. RFC 1598 PPP in X.25 PPP-X25. . . . . . . . . . . . . 20
5.11. RFC 1618 PPP over ISDN. . . . . . . . . . . . . . . . 20
5.12. RFC 1663 PPP Reliable Transmission. . . . . . . . . . 20
5.13. RFC 1752 The Recommendation for the IP Next
Generation Protocol . . . . . . . . . . . . . . . . . 20
5.14. RFC 1755 ATM Signaling Support for IP over ATM. . . . 20
5.15. RFC 1763 The PPP Banyan Vines Control Protocol (BVCP) 21
5.16. RFC 1764 The PPP XNS IDP Control Protocol (XNSCP) . . 21
5.17. RFC 1973 PPP in Frame Relay . . . . . . . . . . . . . 21
5.18. RFC 1981 Path MTU Discovery for IP version 6. . . . . 21
5.19. RFC 1982 Serial Number Arithmetic . . . . . . . . . . 21
5.20. 5.21 RFC 1995 Incremental Zone Transfer in DNS. . . . 21
5.21. RFC 1996 A Mechanism for Prompt Notification of Zone
Changes (DNS NOTIFY). . . . . . . . . . . . . . . . . 21
5.22. RFC 2003 IP Encapsulation within IP . . . . . . . . . 21
5.23. RFC 2004 Minimal Encapsulation within IP. . . . . . . 21
5.24. RFC 2005 Applicability Statement for IP Mobility
Support . . . . . . . . . . . . . . . . . . . . . . . 21
5.25. RFC 2022 Support for Multicast over UNI 3.0/3.1 based
ATM Networks. . . . . . . . . . . . . . . . . . . . . 22
5.26. RFC 2043 The PPP SNA Control Protocol (SNACP) . . . . 22
5.27. RFC 2097 The PPP NetBIOS Frames Control Protocol
(NBFCP) . . . . . . . . . . . . . . . . . . . . . . . 22
5.28. RFC 2113 IP Router Alert Option . . . . . . . . . . . 22
4.16. RFC2460インターネットプロトコル(バージョン6(IPv6)仕様. . . . . . . . . . . . . . . . . . . . 17 4.17)。 IPバージョン6(IPv6). 18 4.18のためのRFC2461隣人発見。 RFC2462のIPv6の国がないアドレス自動構成. . 18 4.19。 インターネットへのRFC2463インターネット・コントロール・メッセージ・プロトコル(ICMPv6)はバージョン6(IPv6)仕様を議定書の中で述べます。 . . . . . . . . . . . . . . . . . . . 18 4.20. IPバージョン6.185を支持するRFC3596DNS Extensions。 提案された標準. . . . . . . . . . . . . . . . . . . . . 18 5.1。 IPネットワークを通したRFC1234Tunneling IPX交通。 . 18 5.2. RFC1256ICMPルータ発見メッセージ. . . . . . . 19 5.3。 ネットワークをコード化するRFC1277が非OSIの低級層. . . . . . . . . 19 5.4の上の操作をサポートに記述します。 RFC1332pppインターネットは制御プロトコル(IPCP)について議定書の中で述べます。 . . . . . . . . . . . . . . . . . . . . . . . 19 5.5. RFC1377ppp OSIネットワーク層コントロールは(OSINLCP). . . . . . . . . . . . . . . . . . . . . . 20 5.6について議定書の中で述べます。 RFC1378ppp AppleTalkコントロールは(ATCP)について議定書の中で述べます。 . 20 5.7. トークンリングの上のRFC1469IPマルチキャストローカル・エリア・ネットワーク。 . . . . . . . . . . . . . . . . . . . . . . 20 5.8. pppインターネットワーキングパケットが交換するRFC1552はプロトコル(IPXCP)を制御します。 . . . . . . . . . . . . . . 20 5.9. RFC1570ppp LCP拡張子. . . . . . . . . . . . . 20 5.10。 X.25ppp-X25のRFC1598ppp。 . . . . . . . . . . . . 20 5.11. ISDNの上のRFC1618ppp。 . . . . . . . . . . . . . . . 20 5.12. RFC1663のpppの信頼できる送信。 . . . . . . . . . 20 5.13. IP次世代プロトコル. . . . . . . . . . . . . . . . . 20 5.14のためのRFC1752推薦。 気圧でIPのサポートを示すRFC1755気圧。 . . . 20 5.15. RFC1763pppバニヤンつる植物はプロトコル(BVCP)21 5.16を制御します。 RFC1764ppp XNS IDPコントロールは(XNSCP). . 21 5.17について議定書の中で述べます。 RFC1973pppは船体の骨組を組み立て終えて.21 5.18をリレーします。 IPバージョン6のためのRFC1981Path MTUディスカバリー。 . . . . 21 5.19. RFC1982通し番号演算. . . . . . . . . . 21 5.20。 5.21 DNSのRFC1995の増加のゾーン転送。 . . . 21 5.21. ゾーン変化(DNSは通知する)の迅速な通知のための1メカニズムあたりRFC1996。 . . . . . . . . . . . . . . . . 21 5.22. IP. . . . . . . . . 21 5.23の中のRFC2003IPカプセル化。 IPの中のRFC2004の最小量のカプセル化。 . . . . . . 21 5.24. IP移動性サポート. . . . . . . . . . . . . . . . . . . . . . . 21 5.25のためのRFC2005適用性証明。 UNI3.0/3.1の上のMulticastのためのRFC2022SupportはATM Networksを基礎づけました。 . . . . . . . . . . . . . . . . . . . . 22 5.26. RFC2043ppp SNAコントロールは(SNACP). . . . 22 5.27について議定書の中で述べます。 ppp NetBIOSが縁どるRFC2097はプロトコル(NBFCP). . . . . . . . . . . . . . . . . . . . . . . 22 5.28を制御します。 RFC2113IPルータ警戒オプション. . . . . . . . . . . 22
Mickles & Nesser II Informational [Page 3] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[3ページ]のRFC3790IPv4は領域2004年6月にIETFにインターネットを記述します。
5.29. RFC 2125 The PPP Bandwidth Allocation Protocol (BAP)
/ The PPP Bandwidth Allocation Control Protocol
(BACP) . . . . . . . . . . . . . . . . . . . . . . . . 22
5.30. RFC 2136 Dynamic Updates in the Domain Name System
(DNS UPDATE). . . . . . . . . . . . . . . . . . . . . 22
5.31. RFC 2181 Clarifications to the DNS Specification. . . 22
5.32. RFC 2225 Classical IP and ARP over ATM. . . . . . . . 22
5.33. RFC 2226 IP Broadcast over ATM Networks . . . . . . . 23
5.34. RFC 2241 DHCP Options for Novell Directory Services . 23
5.35. RFC 2242 NetWare/IP Domain Name and Information . . . 23
5.36. RFC 2290 Mobile-IPv4 Configuration Option for PPP
IPCP. . . . . . . . . . . . . . . . . . . . . . . . . 24
5.37. RFC 2308 Negative Caching of DNS Queries (DNS NCACHE) 24
5.38. RFC 2331 ATM Signaling Support for IP over ATM - UNI
Signaling 4.0 Update. . . . . . . . . . . . . . . . . 24
5.39. RFC 2332 NBMA Next Hop Resolution Protocol (NHRP) . . 24
5.40. RFC 2333 NHRP Protocol Applicability. . . . . . . . . 24
5.41. RFC 2335 A Distributed NHRP Service Using SCSP. . . . 24
5.42. RFC 2363 PPP Over FUNI. . . . . . . . . . . . . . . . 24
5.43. RFC 2364 PPP Over AAL5. . . . . . . . . . . . . . . . 24
5.44. RFC 2371 Transaction Internet Protocol Version 3.0
(TIPV3) . . . . . . . . . . . . . . . . . . . . . . . 25
5.45. RFC 2464 Transmission of IPv6 Packets over Ethernet
Networks. . . . . . . . . . . . . . . . . . . . . . . 26
5.46. RFC 2467 Transmission of IPv6 Packets over FDDI
Networks. . . . . . . . . . . . . . . . . . . . . . . 26
5.47. RFC 2470 Transmission of IPv6 Packets over Token Ring
Networks. . . . . . . . . . . . . . . . . . . . . . . 26
5.48. RFC 2472 IP Version 6 over PPP. . . . . . . . . . . . 26
5.49. RFC 2473 Generic Packet Tunneling in IPv6
Specification . . . . . . . . . . . . . . . . . . . . 26
5.50. RFC 2484 PPP LCP Internationalization Configuration
Option. . . . . . . . . . . . . . . . . . . . . . . . 26
5.51. RFC 2485 DHCP Option for The Open Group's User
Authentication Protocol . . . . . . . . . . . . . . . 27
5.52. RFC 2486 The Network Access Identifier. . . . . . . . 27
5.53. RFC 2491 IPv6 over Non-Broadcast Multiple Access
(NBMA) Networks . . . . . . . . . . . . . . . . . . . 27
5.54. RFC 2492 IPv6 over ATM Networks . . . . . . . . . . . 27
5.55. RFC 2497 Transmission of IPv6 Packets over ARCnet
Networks. . . . . . . . . . . . . . . . . . . . . . . 27
5.56. RFC 2507 IP Header Compression. . . . . . . . . . . . 27
5.57. RFC 2526 Reserved IPv6 Subnet Anycast Addresses . . . 27
5.58. RFC 2529 Transmission of IPv6 over IPv4 Domains
without Explicit Tunnels. . . . . . . . . . . . . . . 27
5.59. RFC 2563 DHCP Option to Disable Stateless
Auto-Configuration in IPv4 Clients. . . . . . . . . . 27
5.29. RFC2125ppp帯域幅配分は.22 5.30に、(BAP)/ppp帯域幅調節プロトコル(BACP)について議定書の中で述べます。 ドメインネームシステム(DNSアップデート)におけるRFC2136のダイナミックなアップデート。 . . . . . . . . . . . . . . . . . . . . 22 5.31. DNS仕様へのRFC2181明確化。 . . 22 5.32. 気圧でのRFC2225の古典的なIPとARP。 . . . . . . . 22 5.33. RFC2226IPは気圧ネットワーク. . . . . . . 23 5.34の上で放送されました。 ノベルディレクトリサービス. 23 5.35のためのRFC2241DHCPオプション。 RFC2242NetWare/IPドメイン名と情報. . . 23 5.36。 ppp IPCPのためのRFC2290モバイルIPv4設定オプション。 . . . . . . . . . . . . . . . . . . . . . . . . 24 5.37. DNSのRFC2308の否定的キャッシュは(DNS NCACHE)24 5.38について質問します。 気圧でIPのサポートを示すRFC2331気圧--UNIシグナリング4.0アップデート。 . . . . . . . . . . . . . . . . 24 5.39. 次のRFC2332NBMAは解決プロトコル(NHRP). . 24 5.40を飛び越します。 RFC2333NHRPは適用性について議定書の中で述べます。 . . . . . . . . 24 5.41. 分配されたNHRPあたりRFC2335は使用SCSPを調整します。 . . . 24 5.42. FUNIの上のRFC2363ppp。 . . . . . . . . . . . . . . . 24 5.43. AAL5の上のRFC2364ppp。 . . . . . . . . . . . . . . . 24 5.44. RFC2371取引インターネットプロトコルバージョン3.0(TIPV3。). . . . . . . . . . . . . . . . . . . . . . . 25 5.45 イーサネットネットワークの上のIPv6パケットのRFC2464トランスミッション。 . . . . . . . . . . . . . . . . . . . . . . 26 5.46. FDDIネットワークの上のIPv6パケットのRFC2467トランスミッション。 . . . . . . . . . . . . . . . . . . . . . . 26 5.47. トークンリングネットワークの上のIPv6パケットのRFC2470トランスミッション。 . . . . . . . . . . . . . . . . . . . . . . 26 5.48. pppの上のRFC2472IPバージョン6。 . . . . . . . . . . . 26 5.49. IPv6仕様. . . . . . . . . . . . . . . . . . . . 26 5.50でトンネルを堀るRFC2473の一般的なパケット。 RFC2484ppp LCP国際化設定オプション。 . . . . . . . . . . . . . . . . . . . . . . . 26 5.51. TheOpenGroupのユーザー認証プロトコル. . . . . . . . . . . . . . . 27 5.52のためのRFC2485DHCPオプション。 RFC2486ネットワークアクセス識別子。 . . . . . . . 27 5.53. 非放送倍数の上のRFC2491IPv6は(NBMA)ネットワーク. . . . . . . . . . . . . . . . . . . 27 5.54にアクセスします。 気圧ネットワーク. . . . . . . . . . . 27 5.55の上のRFC2492IPv6。 ARCnetネットワークの上のIPv6パケットのRFC2497トランスミッション。 . . . . . . . . . . . . . . . . . . . . . . 27 5.56. RFC2507IPヘッダー圧縮。 . . . . . . . . . . . 27 5.57. RFC2526はIPv6サブネットAnycastアドレス. . . 27 5.58を予約しました。 明白なTunnelsのいないIPv4ドメインの上のIPv6のRFC2529トランスミッション。 . . . . . . . . . . . . . . 27 5.59. IPv4クライアントで国がない自動構成を無効にするRFC2563DHCPオプション。 . . . . . . . . . 27
Mickles & Nesser II Informational [Page 4] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[4ページ]のRFC3790IPv4は領域2004年6月にIETFにインターネットを記述します。
5.60. RFC 2590 Transmission of IPv6 Packets over Frame
Relay Networks Specification. . . . . . . . . . . . . 28
5.61. RFC 2601 ILMI-Based Server Discovery for ATMARP . . . 28
5.62. RFC 2602 ILMI-Based Server Discovery for MARS . . . . 28
5.63. RFC 2603 ILMI-Based Server Discovery for NHRP . . . . 28
5.64. RFC 2610 DHCP Options for Service Location Protocol . 28
5.65. RFC 2615 PPP over SONET/SDH . . . . . . . . . . . . . 28
5.66. RFC 2625 IP and ARP over Fibre Channel. . . . . . . . 28
5.67. RFC 2661 Layer Two Tunneling Protocol (L2TP). . . . . 28
5.68. RFC 2671 Extension Mechanisms for DNS (EDNS0) . . . . 28
5.69. RFC 2672 Non-Terminal DNS Name Redirection. . . . . . 29
5.70. RFC 2673 Binary Labels in the Domain Name System. . . 29
5.71. RFC 2675 IPv6 Jumbograms. . . . . . . . . . . . . . . 29
5.72. RFC 2684 Multiprotocol Encapsulation over ATM
Adaptation Layer 5. . . . . . . . . . . . . . . . . . 29
5.73. RFC 2685 Virtual Private Networks Identifier. . . . . 29
5.74. RFC 2686 The Multi-Class Extension to Multi-Link PPP. 29
5.75. RFC 2687 PPP in a Real-time Oriented HDLC-like
Framing . . . . . . . . . . . . . . . . . . . . . . . 29
5.76. RFC 2688 Integrated Services Mappings for Low Speed
Networks. . . . . . . . . . . . . . . . . . . . . . . 29
5.77. RFC 2710 Multicast Listener Discovery (MLD) for IPv6. 29
5.78. RFC 2711 IPv6 Router Alert Option . . . . . . . . . . 29
5.79. RFC 2728 The Transmission of IP Over the Vertical
Blanking Interval of a Television Signal. . . . . . . 30
5.80. RFC 2734 IPv4 over IEEE 1394. . . . . . . . . . . . . 30
5.81. RFC 2735 NHRP Support for Virtual Private Networks. . 30
5.82. RFC 2765 Stateless IP/ICMP Translation Algorithm
(SIIT). . . . . . . . . . . . . . . . . . . . . . . . 30
5.83. RFC 2766 Network Address Translation - Protocol
Translation (NAT-PT). . . . . . . . . . . . . . . . . 30
5.84. RFC 2776 Multicast-Scope Zone Announcement Protocol
(MZAP). . . . . . . . . . . . . . . . . . . . . . . . 31
5.85. RFC 2782 A DNS RR for specifying the location of
services. . . . . . . . . . . . . . . . . . . . . . . 31
5.86. RFC 2794 Mobile IP Network Access Identifier
Extension for IPv4. . . . . . . . . . . . . . . . . . 31
5.87. RFC 2834 ARP and IP Broadcast over HIPPI-800. . . . . 31
5.88. RFC 2835 IP and ARP over HIPPI-6400 . . . . . . . . . 33
5.89. RFC 2855 DHCP for IEEE 1394 . . . . . . . . . . . . . 33
5.90. RFC 2874 DNS Extensions to Support IPv6 Address
Aggregation and Renumbering . . . . . . . . . . . . . 33
5.91. RFC 2893 Transition Mechanisms for IPv6 Hosts and
Routers . . . . . . . . . . . . . . . . . . . . . . . 33
5.92. RFC 2916 E.164 number and DNS . . . . . . . . . . . . 33
5.93. RFC 2937 The Name Service Search Option for DHCP. . . 33
5.94. RFC 3004 The User Class Option for DHCP . . . . . . . 33
5.95. RFC 3011 The IPv4 Subnet Selection Option for DHCP. . 33
5.60. フレームリレーの上のIPv6パケットのRFC2590トランスミッションは仕様をネットワークでつなぎます。 . . . . . . . . . . . . 28 5.61. ATMARP. . . 28 5.62のためのRFC2601のILMIベースのサーバ発見。 火星. . . . 28 5.63のためのRFC2602のILMIベースのサーバ発見。 NHRP. . . . 28 5.64のためのRFC2603のILMIベースのサーバ発見。 サービス位置のためのRFC2610DHCPオプションは.28 5.65について議定書の中で述べます。 Sonet/SDH. . . . . . . . . . . . . 28 5.66の上のRFC2615ppp。 繊維の上のRFC2625IPとARPは精神を集中します。 . . . . . . . 28 5.67. RFC2661は2トンネリングプロトコル(L2TP)を層にします。 . . . . 28 5.68. DNS(EDNS0). . . . 28 5.69のためのRFC2671拡大メカニズム。 RFC2672非端末DNSはリダイレクションを命名します。 . . . . . 29 5.70. ドメインネームシステムにおけるRFC2673の2進のラベル。 . . 29 5.71. RFC2675IPv6 Jumbograms29 5.72……………。 気圧適合層5の上のRFC2684Multiprotocolカプセル化。 . . . . . . . . . . . . . . . . . 29 5.73. RFC2685仮想私設網識別子。 . . . . 29 5.74. マルチリンクpppへのRFC2686マルチのクラス拡張子。 29 5.75. リアルタイムの指向のHDLCのような縁ど. . . . . . . . . . . . . . . . . . . . . . . 29 5.76りにおけるRFC2687ppp。 RFC2688は低速ネットワークのためのサービスマッピングを統合しました。 . . . . . . . . . . . . . . . . . . . . . . 29 5.77. IPv6のためのRFC2710マルチキャストリスナー発見(MLD)。 29 5.78. RFC2711IPv6ルータ警戒オプション. . . . . . . . . . 29 5.79。 テレビジョン信号の垂直な空白間隔の間のIPのRFC2728トランスミッション。 . . . . . . 30 5.80. IEEE1394の上のRFC2734IPv4。 . . . . . . . . . . . . 30 5.81. 仮想私設網のRFC2735NHRPサポート。 . 30 5.82. RFC2765国がないIP/ICMP変換アルゴリズム(SIIT)。 . . . . . . . . . . . . . . . . . . . . . . . 30 5.83. RFC2766ネットワークアドレス変換--翻訳(太平洋標準時のNAT)について議定書の中で述べてください。 . . . . . . . . . . . . . . . . 30 5.84. RFC2776マルチキャスト範囲ゾーン発表プロトコル(MZAP)。 . . . . . . . . . . . . . . . . . . . . . . . 31 5.85. サービスの位置を指定するためのRFC2782A DNS RR。 . . . . . . . . . . . . . . . . . . . . . . 31 5.86. IPv4のためのRFC2794のモバイルIPネットワークアクセス識別子拡張子。 . . . . . . . . . . . . . . . . . 31 5.87. RFC2834ARPとIPはHIPPI-800の上で放送されます。 . . . . 31 5.88. HIPPI-6400. . . . . . . . . 33 5.89の上のRFC2835IPとARP。 IEEE1394.33 5.90のためのRFC2855DHCP。 IPv6を支持するRFC2874DNS拡張子は集合と番号を付け替え. . . . . . . . . . . . . 33 5.91ることを記述します。 IPv6ホストとルータ. . . . . . . . . . . . . . . . . . . . . . . 33 5.92のためのRFC2893変遷メカニズム。 RFC2916E.164番号とDNS. . . . . . . . . . . . 33 5.93。 DHCPのためのRFC2937名前サービス検索オプション。 . . 33 5.94. DHCP. . . . . . . 33 5.95のためのRFC3004ユーザ・クラスオプション。 DHCPのためのRFC3011IPv4サブネット選択オプション。 . 33
Mickles & Nesser II Informational [Page 5] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[5ページ]のRFC3790IPv4は領域2004年6月にIETFにインターネットを記述します。
5.96. RFC 3021 Using 31-Bit Prefixes for IPv4 P2P Links . . 33
5.97. RFC 3024 Reverse Tunneling for Mobile IP, revised . . 34
5.98. RFC 3046 DHCP Relay Agent Information Option. . . . . 34
5.99. RFC 3056 Connection of IPv6 Domains via IPv4 Clouds . 34
5.100. RFC 3068 An Anycast Prefix for 6to4 Relay Routers . . 34
5.101. RFC 3070 Layer Two Tunneling Protocol (L2TP) over
Frame Relay . . . . . . . . . . . . . . . . . . . . . 34
5.102. RFC 3074 DHC Load Balancing Algorithm . . . . . . . . 34
5.103. RFC 3077 A Link-Layer Tunneling Mechanism for
Unidirectional Links. . . . . . . . . . . . . . . . . 34
5.104. RFC 3115 Mobile IP Vendor/Organization-Specific
Extensions. . . . . . . . . . . . . . . . . . . . . . 34
5.105. RFC 3145 L2TP Disconnect Cause Information. . . . . . 34
5.106. RFC 3344 IP Mobility Support for IPv4 . . . . . . . . 34
5.107. RFC 3376 Internet Group Management Protocol,
Version 3 . . . . . . . . . . . . . . . . . . . . . . 35
5.108. RFC 3402 Dynamic Delegation Discovery System (DDDS)
Part Two: The Algorithm . . . . . . . . . . . . . . . 35
5.109. RFC 3403 Dynamic Delegation Discovery System (DDDS)
Part Three: The Domain Name System (DNS) Database. . 35
5.110. RFC 3513 IP Version 6 Addressing Architecture . . . . 35
5.111. RFC 3518 Point-to-Point Protocol (PPP) Bridging
Control Protocol (BCP). . . . . . . . . . . . . . . . 35
6. Experimental RFCs. . . . . . . . . . . . . . . . . . . . . . 35
6.1. RFC 1149 Standard for the transmission of IP
datagrams on avian carriers . . . . . . . . . . . . . 35
6.2. RFC 1183 New DNS RR Definitions . . . . . . . . . . . 35
6.3. RFC 1226 Internet protocol encapsulation of AX.25
frames. . . . . . . . . . . . . . . . . . . . . . . . 36
6.4. RFC 1241 Scheme for an internet encapsulation
protocol: Version 1 . . . . . . . . . . . . . . . . . 36
6.5. RFC 1307 Dynamically Switched Link Control Protocol . 36
6.6. RFC 1393 Traceroute Using an IP Option. . . . . . . . 36
6.7. RFC 1433 Directed ARP . . . . . . . . . . . . . . . . 36
6.8. RFC 1464 Using the Domain Name System To Store
Arbitrary String Attributes . . . . . . . . . . . . . 37
6.9. RFC 1475 TP/IX: The Next Internet . . . . . . . . . . 37
6.10. RFC 1561 Use of ISO CLNP in TUBA Environments . . . . 37
6.11. RFC 1712 DNS Encoding of Geographical Location. . . . 37
6.12. RFC 1735 NBMA Address Resolution Protocol (NARP). . . 37
6.13. RFC 1768 Host Group Extensions for CLNP Multicasting. 38
6.14. RFC 1788 ICMP Domain Name Messages. . . . . . . . . . 38
6.15. RFC 1797 Class A Subnet Experiment. . . . . . . . . . 38
6.16. RFC 1819 Internet Stream Protocol Version 2 (ST2)
Protocol Specification - Version ST2+ . . . . . . . . 39
6.17. RFC 1868 ARP Extension - UNARP. . . . . . . . . . . . 39
6.18. RFC 1876 A Means for Expressing Location Information
in the Domain Name System . . . . . . . . . . . . . . 39
5.96. IPv4 P2Pに31ビットの接頭語を使用するRFC3021が.33 5.97をリンクします。 .34 5.98に改訂されたモバイルIPのためのRFC3024Reverse Tunneling。 RFC3046DHCPはエージェント情報オプションをリレーします。 . . . . 34 5.99. IPv4 Clouds. 34 5.100を通したIPv6 DomainsのRFC3056Connection。 6to4のためのAnycast接頭語あたりRFC3068はルータ. . 34 5.101をリレーします。 RFC3070はフレームリレー. . . . . . . . . . . . . . . . . . . . . 34 5.102の上で2トンネリングプロトコル(L2TP)を層にします。 RFC3074DHCロードバランシングアルゴリズム. . . . . . . . 34 5.103。 単方向のリンクへのリンクレイヤトンネリングメカニズムあたりRFC3077。 . . . . . . . . . . . . . . . . 34 5.104. RFC3115の組織モバイルIP業者/特有の拡張子。 . . . . . . . . . . . . . . . . . . . . . 34 5.105. RFC3145L2TPは原因情報を外します。 . . . . . 34 5.106. IPv4. . . . . . . . 34 5.107のRFC3344IP移動性サポート。 RFC3376インターネット集団経営は議定書を作ります、バージョン3.35 5.108。 RFC3402のダイナミックな代表団発見システム(DDDS)パートTwo: アルゴリズム. . . . . . . . . . . . . . . 35 5.109。 RFC3403のダイナミックな代表団発見システム(DDDS)パートThree: ドメインネームシステム(DNS)データベース。 . 35 5.110. RFC3513IPバージョン6アドレッシング体系. . . . 35 5.111。 RFC3518の二地点間プロトコル(ppp)橋を架ける制御プロトコル(BCP)。 . . . . . . . . . . . . . . . 35 6. 実験的なRFCs。 . . . . . . . . . . . . . . . . . . . . . 35 6.1. 鳥のキャリヤー. . . . . . . . . . . . . 35 6.2におけるIPデータグラムのトランスミッションのためのRFC1149Standard。 RFC1183の新しいDNS RR定義. . . . . . . . . . . 35 6.3。 AX.25フレームのRFC1226インターネットプロトコルカプセル化。 . . . . . . . . . . . . . . . . . . . . . . . 36 6.4. インターネットカプセル化のためのRFC1241Schemeは議定書を作ります: バージョン1.366.5。 RFC1307はダイナミックにリンク制御プロトコル. 36 6.6を切り換えました。 IPオプションを使用するRFC1393トレースルート。 . . . . . . . 36 6.7. RFC1433はARP. . . . . . . . . . . . . . . . 36 6.8を指示しました。 任意のストリング属性. . . . . . . . . . . . . 37 6.9を格納するのにドメインネームシステムを使用するRFC1464。 RFC1475TP/IX: 次のインターネット. . . . . . . . . . 37 6.10。 チューバ環境. . . . 37 6.11におけるISO CLNPのRFC1561使用。 地理的な位置のRFC1712DNSコード化。 . . . 37 6.12. RFC1735NBMAは解決プロトコル(NARP)を記述します。 . . 37 6.13. RFC1768はCLNPマルチキャスティングのための群拡大を主催します。 38 6.14. RFC1788ICMPドメイン名メッセージ。 . . . . . . . . . 38 6.15. サブネットが実験するRFC1797のクラス。 . . . . . . . . . 38 6.16. RFC1819インターネット流れのプロトコルバージョン2(ST2)は仕様を議定書の中で述べます--バージョンST2+. . . . . . . . 39 6.17。 RFC1868ARP拡張子--UNARP。 . . . . . . . . . . . 39 6.18. ドメインネームシステム. . . . . . . . . . . . . . 39における位置情報を言い表すための1手段あたりRFC1876
Mickles & Nesser II Informational [Page 6] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[6ページ]のRFC3790IPv4は領域2004年6月にIETFにインターネットを記述します。
6.19. RFC 1888 OSI NSAPs and IPv6 . . . . . . . . . . . . . 39
6.20. RFC 2009 GPS-Based Addressin and Routing. . . . . . . 39
6.21. RFC 2143 Encapsulating IP with the SCSI . . . . . . . 39
6.22. RFC 2345 Domain Names and Company Name Retrieval. . . 40
6.23. RFC 2443 A Distributed MARS Service Using SCSP. . . . 40
6.24. RFC 2471 IPv6 Testing Address Allocation. . . . . . . 40
6.25. RFC 2520 NHRP with Mobile NHCs. . . . . . . . . . . . 40
6.26. RFC 2521 ICMP Security Failures Messages. . . . . . . 40
6.27. RFC 2540 Detached Domain Name System (DNS)
Information . . . . . . . . . . . . . . . . . . . . . 40
6.28. RFC 2823 PPP over Simple Data Link (SDL) using
SONET/SDH with ATM-like framing . . . . . . . . . . . 40
6.29. RFC 3123 A DNS RR Type for Lists of Address Prefixes. 40
6.30. RFC 3168 The Addition of Explicit Congestion
Notification (ECN) to IP . . . . . . . . . . . . . . 40
6.31. RFC 3180 GLOP Addressing in 233/8 . . . . . . . . . . 40
7. Summary of the Results . . . . . . . . . . . . . . . . . . . 41
7.1. Standards . . . . . . . . . . . . . . . . . . . . . . 41
7.1.1. RFC 791 Internet Protocol . . . . . . . . . . 41
7.1.2. RFC 792 Internet Control Message Protocol . . 41
7.1.3. RFC 891 DCN Networks. . . . . . . . . . . . . 41
7.1.4. RFC 894 IP over Ethernet. . . . . . . . . . . 41
7.1.5. RFC 895 IP over experimental Ethernets. . . . 41
7.1.6. RFC 922 Broadcasting Internet Datagrams in
the Presence of Subnets . . . . . . . . . . . 41
7.1.7. RFC 950 Internet Standard Subnetting
Procedure. . . . . . . . . . . . . . . . . . 42
7.1.8. RFC 1034 Domain Names: Concepts and
Facilities. . . . . . . . . . . . . . . . . . 42
7.1.9. RFC 1035 Domain Names: Implementation and
Specification . . . . . . . . . . . . . . . . 42
7.1.10. RFC 1042 IP over IEEE 802 . . . . . . . . . . 42
7.1.11. RFC 1044 IP over HyperChannel . . . . . . . . 42
7.1.12. RFC 1088 IP over NetBIOS. . . . . . . . . . . 42
7.1.13. RFC 1112 Host Extensions for IP Multicast . . 42
7.1.14. RFC 1122 Requirements for Internet Hosts. . . 42
7.1.15. RFC 1201 IP over ARCNET . . . . . . . . . . . 42
7.1.16. RFC 1209 IP over SMDS . . . . . . . . . . . . 43
7.1.17. RFC 1390 Transmission of IP and ARP over FDDI
Networks. . . . . . . . . . . . . . . . . . . 43
7.2. Draft Standards . . . . . . . . . . . . . . . . . . . 43
7.2.1. RFC 951 Bootstrap Protocol (BOOTP). . . . . . 43
7.2.2. RFC 1191 Path MTU Discovery . . . . . . . . . 43
7.2.3. RFC 1356 Multiprotocol Interconnect on X.25
and ISDN. . . . . . . . . . . . . . . . . . . 43
7.2.4. RFC 1990 The PPP Multilink Protocol (MP). . . 43
7.2.5. RFC 2067 IP over HIPPI. . . . . . . . . . . . 43
7.2.6. RFC 2131 DHCP . . . . . . . . . . . . . . . . 43
6.19. RFC1888OSI NSAPsとIPv6. . . . . . . . . . . . . 39 6.20。 RFC2009のGPSベースのAddressinとルート設定。 . . . . . . 39 6.21. SCSI. . . . . . . 39 6.22と共にIPを要約するRFC2143。 RFC2345ドメイン名と会社は検索を命名します。 . . 40 6.23. 分配された火星あたりRFC2443は使用SCSPを調整します。 . . . 40 6.24. RFC2471IPv6テストアドレス配分。 . . . . . . 40 6.25. モバイルNHCsとRFC2520NHRP。 . . . . . . . . . . . 40 6.26. RFC2521ICMPセキュリティ失敗メッセージ。 . . . . . . 40 6.27. RFC2540はドメインネームシステム(DNS)情報. . . . . . . . . . . . . . . . . . . . . 40 6.28を取り外しました。 ATMのような縁ど. . . . . . . . . . . 40 6.29りがあるSonet/SDHを使用するSimple Data Link(SDL)の上のRFC2823PPP。 1DNS RRあたりRFC3123はアドレス接頭語に関する繰返し要素の並びをタイプします。 40 6.30. 明白な混雑通知(電子証券取引ネットワーク)のIP. . . . . . . . . . . . . . 40 6.31へのRFC3168追加。 233/8 . . . . . . . . . . 40 7におけるRFC3180GLOPアドレシング。 結果. . . . . . . . . . . . . . . . . . . 41 7.1の概要。 規格. . . . . . . . . . . . . . . . . . . . . . 41 7.1.1。 RFC791インターネットプロトコル. . . . . . . . . . 41 7.1.2。 RFC792インターネット・コントロール・メッセージ・プロトコル. . 41 7.1.3。 RFC891DCNネットワーク。 . . . . . . . . . . . . 41 7.1.4. イーサネットの上のRFC894IP。 . . . . . . . . . . 41 7.1.5. 実験的なEthernetsの上のRFC895IP。 . . . 41 7.1.6. サブネット. . . . . . . . . . . 41 7.1.7があるときインターネットデータグラムを放送するRFC922。 RFC950のインターネットの標準のサブネッティング手順。 . . . . . . . . . . . . . . . . . 42 7.1.8. RFC1034ドメイン名: 概念と施設。 . . . . . . . . . . . . . . . . . 42 7.1.9. RFC1035ドメイン名: 実現と仕様. . . . . . . . . . . . . . . . 42 7.1.10。 IEEE802の上のRFC1042IP、.427.1 .11。 HyperChannel. . . . . . . . 42 7.1.12の上のRFC1044IP NetBIOSの上のRFC1088IP。 . . . . . . . . . . 42 7.1.13. RFC1112はIPマルチキャスト. . 42 7.1.14のための拡大を主催します。 インターネットホストのためのRFC1122要件。 . . 42 7.1.15. ARCNET. . . . . . . . . . . 42 7.1.16の上のRFC1201IP SMDS. . . . . . . . . . . . 43 7.1.17の上のRFC1209IP FDDIネットワークの上のIPとARPのRFC1390トランスミッション。 . . . . . . . . . . . . . . . . . . 43 7.2. 規格. . . . . . . . . . . . . . . . . . . 43 7.2.1を作成してください。 RFC951はプロトコル(BOOTP)を独力で進みます。 . . . . . 43 7.2.2. RFC1191経路MTU発見. . . . . . . . . 43 7.2.3。 RFC1356MultiprotocolはX.25とISDNで内部連絡します。 . . . . . . . . . . . . . . . . . . 43 7.2.4. RFC1990pppマルチリンクは(MP)について議定書の中で述べます。 . . 43 7.2.5. HIPPIの上のRFC2067IP。 . . . . . . . . . . . 43 7.2.6. RFC2131DHCP. . . . . . . . . . . . . . . . 43
Mickles & Nesser II Informational [Page 7] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[7ページ]のRFC3790IPv4は領域2004年6月にIETFにインターネットを記述します。
7.3. Proposed Standards. . . . . . . . . . . . . . . . . . 44
7.3.1. RFC 1234 Tunneling IPX over IP. . . . . . . . 44
7.3.2. RFC 1256 ICMP Router Discovery. . . . . . . . 44
7.3.3. RFC 1277 Encoding Net Addresses to Support
Operation Over Non OSI Lower Layers . . . . . 44
7.3.4. RFC 1332 PPP Internet Protocol Control
Protocol (IPCP) . . . . . . . . . . . . . . . 44
7.3.5. RFC 1469 IP Multicast over Token Ring . . . . 44
7.3.6. RFC 2003 IP Encapsulation within IP . . . . . 44
7.3.7. RFC 2004 Minimal Encapsulation within IP. . . 44
7.3.8. RFC 2022 Support for Multicast over UNI
3.0/3.1 based ATM Networks. . . . . . . . . . 44
7.3.9. RFC 2113 IP Router Alert Option . . . . . . . 45
7.3.10. RFC 2165 SLP. . . . . . . . . . . . . . . . . 45
7.3.11. RFC 2225 Classical IP & ARP over ATM. . . . . 45
7.3.12. RFC 2226 IP Broadcast over ATM. . . . . . . . 45
7.3.13. RFC 2371 Transaction IPv3 . . . . . . . . . . 45
7.3.14. RFC 2625 IP and ARP over Fibre Channel. . . . 45
7.3.15. RFC 2672 Non-Terminal DNS Redirection . . . . 45
7.3.16. RFC 2673 Binary Labels in DNS . . . . . . . . 45
7.3.17. IP over Vertical Blanking Interval of a TV
Signal (RFC 2728) . . . . . . . . . . . . . . 45
7.3.18. RFC 2734 IPv4 over IEEE 1394. . . . . . . . . 45
7.3.19. RFC 2834 ARP & IP Broadcasts Over HIPPI 800 . 46
7.3.20. RFC 2835 ARP & IP Broadcasts Over HIPPI 6400. 46
7.3.21. RFC 3344 Mobility Support for IPv4. . . . . . 46
7.3.22. RFC 3376 Internet Group Management Protocol,
Version 3 . . . . . . . . . . . . . . . . . . 46
7.4. Experimental RFCs . . . . . . . . . . . . . . . . . . 46
7.4.1. RFC 1307 Dynamically Switched Link Control
Protocol. . . . . . . . . . . . . . . . . . . 46
7.4.2. RFC 1393 Traceroute using an IP Option. . . . 46
7.4.3. RFC 1735 NBMA Address Resolution Protocol
(NARP). . . . . . . . . . . . . . . . . . . . 46
7.4.4. RFC 1788 ICMP Domain Name Messages. . . . . . 46
7.4.5. RFC 1868 ARP Extension - UNARP. . . . . . . . 47
7.4.6. RFC 2143 IP Over SCSI . . . . . . . . . . . . 47
7.4.7. RFC 3180 GLOP Addressing in 233/8 . . . . . . 47
8. Security Considerations . . . . . . . . . . . . . . . . . . 47
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 47
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 47
10.1. Normative References. . . . . . . . . . . . . . . . . 47
10.2. Informative References . . . . . . . . . . . . . . . 48
11. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 48
12. Full Copyright Statement . . . . . . . . . . . . . . . . . . 49
7.3. 提案された標準。 . . . . . . . . . . . . . . . . . 44 7.3.1. IPの上でIPXにトンネルを堀るRFC1234。 . . . . . . . 44 7.3.2. RFC1256ICMPルータ発見。 . . . . . . . 44 7.3.3. ネットをコード化するRFC1277は、より非OSIの低級より多くの層. . . . . 44 7.3が.4であるとサポート操作に扱います。 RFC1332pppインターネットは制御プロトコル(IPCP). . . . . . . . . . . . . . . 44 7.3.5について議定書の中で述べます。 トークンリング. . . . 44 7.3.6の上のRFC1469IPマルチキャスト IP. . . . . 44 7.3.7の中のRFC2003IPカプセル化。 IPの中のRFC2004の最小量のカプセル化。 . . 44 7.3.8. UNI3.0/3.1の上のMulticastのためのRFC2022SupportはATM Networksを基礎づけました。 . . . . . . . . . 44 7.3.9. RFC2113IPルータ警戒オプション. . . . . . . 45 7.3.10。 RFC2165SLP。 . . . . . . . . . . . . . . . . 45 7.3.11. 気圧でのRFC2225の古典的なIPとARP。 . . . . 45 7.3.12. RFC2226IPは気圧で放送されました。 . . . . . . . 45 7.3.13. RFC2371トランザクションIPv3. . . . . . . . . . 45 7.3.14。 繊維の上のRFC2625IPとARPは精神を集中します。 . . . 45 7.3.15. RFC2672非端末DNSリダイレクション. . . . 45 7.3.16。 DNS. . . . . . . . 45 7.3.17におけるRFC2673の2進のラベル。 テレビの信号(RFC2728).457.3.18の垂直な空白間隔の間のIP。 IEEE1394の上のRFC2734IPv4。 . . . . . . . . 45 7.3.19. RFC2834ARPとIPはHIPPI800の上で.467.3に.20に放送します。 RFC2835ARPとIPはHIPPI6400の上で放送します。 46 7.3.21. IPv4のRFC3344移動性サポート。 . . . . . 46 7.3.22. RFC3376インターネット集団経営は議定書を作ります、バージョン3.467.4。 実験的なRFCs. . . . . . . . . . . . . . . . . . 46 7.4.1。 RFC1307はダイナミックにリンク制御プロトコルを切り換えました。 . . . . . . . . . . . . . . . . . . 46 7.4.2. IPオプションを使用するRFC1393トレースルート。 . . . 46 7.4.3. RFC1735NBMAは解決プロトコル(NARP)を扱います。 . . . . . . . . . . . . . . . . . . . 46 7.4.4. RFC1788ICMPドメイン名メッセージ。 . . . . . 46 7.4.5. RFC1868ARP拡張子--UNARP。 . . . . . . . 47 7.4.6. SCSI. . . . . . . . . . . . 47 7.4.7の上のRFC2143IP 233/8 . . . . . . 47 8におけるRFC3180GLOPアドレシング。 セキュリティ問題. . . . . . . . . . . . . . . . . . 47 9。 承認. . . . . . . . . . . . . . . . . . . . . . 47 10。 参照. . . . . . . . . . . . . . . . . . . . . . . . . 47 10.1。 引用規格。 . . . . . . . . . . . . . . . . 47 10.2. 有益な参照. . . . . . . . . . . . . . . 48 11。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . 48 12。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . 49
Mickles & Nesser II Informational [Page 8] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[8ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
1. Introduction
1. 序論
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アドレスのすべての用法を記録することを目指す1人の文献集合の一部です。 処理しやすいフォームに情報を持つ取り組みでは、現在のIETF領域(アプリケーション、インターネット、Management&Operations、ルート設定、Security、Sub-IP、およびTransport)に一致している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]ドキュメントを見てください。
2. Document Organization
2. ドキュメント組織
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はそれぞれFull、Draft、Proposed Standards、およびExperimental RFCsの生の分析について説明します。 RFC1と(about) RFC3100に終わることをきっかけに順番に各RFCについて議論します。 各RFCのためのコメントは現実に「生です」。 真空ですなわち各RFCについて議論して、問題か議論した問題が、提起された問題について何かが既に修理されたかどうか確認するために「前を見る。」ではありません。
Section 7 is an analysis of the data presented in Sections 3, 4, 5, and 6. It is here that all of the results are considered as a whole and the problems that have been resolved in later RFCs are correlated.
セクション7はセクション3、4、5、および6に提示されたデータの分析です。 結果のすべてが全体で考えられて、後のRFCsで解決された問題が関連されているのが、ここにそれがあります。
3. Full Standards
3. 完全な規格
Full Internet Standards (most commonly simply referred to as "Standards") are fully mature protocol specification that are widely implemented and used throughout the Internet.
完全なインターネットStandards(最も一般的に単に「規格」と呼ばれる)は広く履行されて、インターネット中で使用される完全に熟しているプロトコル仕様です。
3.1. RFC 791 Internet Protocol
3.1. RFC791インターネットプロトコル
This specification defines IPv4; IPv6 has been specified in separate documents.
この仕様はIPv4を定義します。 IPv6は別々のドキュメントで指定されました。
3.2. RFC 792 Internet Control Message Protocol
3.2. RFC792インターネット・コントロール・メッセージ・プロトコル
This specification defines ICMP, and is inherently IPv4 dependent.
この仕様は、ICMPを定義して、本来IPv4扶養家族です。
3.3. RFC 826 Ethernet Address Resolution Protocol
3.3. RFC826イーサネットアドレス解決プロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Mickles & Nesser II Informational [Page 9] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[9ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
3.4. RFC 891 DCN Local-Network Protocols
3.4. RFC891DCN企業内情報通信網プロトコル
There are many implicit assumptions about the use of IPv4 addresses in this document.
IPv4アドレスの使用に関する多くの暗黙の仮定が本書ではあります。
3.5. RFC 894 Standard for the transmission of IP datagrams over
Ethernet networks
3.5. イーサネットネットワークの上のIPデータグラムのトランスミッションのためのRFC894Standard
This specification specifically deals with the transmission of IPv4 packets over Ethernet.
この仕様はイーサネットの上で明確にIPv4パケットのトランスミッションに対処します。
3.6. RFC 895 Standard for the transmission of IP datagrams over
experimental Ethernet networks
3.6. 実験イーサネットネットワークの上のIPデータグラムのトランスミッションのためのRFC895Standard
This specification specifically deals with the transmission of IPv4 packets over experimental Ethernet.
この仕様は実験的なイーサネットの上で明確にIPv4パケットのトランスミッションに対処します。
3.7. RFC 903 Reverse Address Resolution Protocol
3.7. RFC903逆アドレス解決プロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.8. RFC 919 Broadcasting Internet Datagrams
3.8. RFC919放送インターネットデータグラム
This specification defines broadcasting for IPv4; IPv6 uses multicast so this is not applicable.
この仕様はIPv4のために放送を定義します。 IPv6がマルチキャストを使用するので、これは適切ではありません。
3.9. RFC 922 Broadcasting Internet datagrams in the presence of subnets
3.9. サブネットがあるときRFC922Broadcastingインターネットデータグラム
This specification defines how broadcasts should be treated in the presence of subnets. IPv6 uses multicast so this is not applicable.
この仕様は放送がサブネットがあるときどう扱われるべきであるかを定義します。 IPv6がマルチキャストを使用するので、これは適切ではありません。
3.10. RFC 950 Internet Standard Subnetting Procedure
3.10. RFC950のインターネットの標準のサブネッティング手順
This specification defines IPv4 subnetting; similar functionality is part of IPv6 addressing architecture to begin with.
この仕様はIPv4サブネッティングを定義します。 初めに、同様の機能性はIPv6アドレッシング体系の一部です。
3.11. RFC 1034 Domain Names: Concepts and Facilities
3.11. RFC1034ドメイン名: 概念と施設
In Section 3.6, "Resource Records", the definition of A record is:
セクション3.6、「リソース記録」では、A記録の定義は以下の通りです。
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
ForはINのクラス、32ビットのIPアドレスです。
Mickles & Nesser II Informational [Page 10] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[10ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
And Section 5.2.1, "Typical functions" defines:
そして、セクション5.2.1、「典型的な機能」は以下を定義します。
1. Host name to host address translation.
1. ホストアドレス変換に名前をホスティングしてください。
This function is often defined to mimic a previous HOSTS.TXT based
function. Given a character string, the caller wants one or more
32 bit IP addresses. Under the DNS, it translates into a request
for type A RRs. Since the DNS does not preserve the order of RRs,
this function may choose to sort the returned addresses or select
the "best" address if the service returns only one choice to the
client. Note that a multiple address return is recommended, but a
single address may be the only way to emulate prior HOSTS.TXT
services.
この機能は、前のHOSTS.TXTのベースの機能をまねるためにしばしば定義されます。 文字列を考えて、より訪問者より多くの必需品1 32はIPアドレスに噛み付きました。 DNSの下では、それはタイプA RRsを求める要求に翻訳されます。 DNSがRRsの注文を保存しないので、サービスが1つの選択だけをクライアントに返すなら、この機能は、返されたアドレスを分類するか、または「最も良い」アドレスを選択するのを選ぶかもしれません。 倍数がリターンを扱うというメモはお勧めですが、ただ一つのアドレスは先のHOSTS.TXTサービスを見習う唯一の方法であるかもしれません。
2. Host address to host name translation
2. ホスト名翻訳へのホスト・アドレス
This function will often follow the form of previous functions.
Given a 32 bit IP address, the caller wants a character string.
The octets of the IP address are reversed, used as name
components, and suffixed with "IN-ADDR.ARPA". A type PTR query is
used to get the RR with the primary name of the host. For
example, a request for the host name corresponding to IP address
1.2.3.4 looks for PTR RRs for domain name "4.3.2.1.IN-ADDR.ARPA".
この機能はしばしば前の機能のフォームに続くでしょう。 32ビットのIPアドレス、訪問者必需品に文字列を与えます。 IPアドレスの八重奏は、逆にされて、名前コンポーネントとして使用されて、「ADDR.ARPA」でsuffixedされます。 タイプPTR質問は、ホストのプライマリ名前があるRRを手に入れるのに使用されます。 例えば、IPアドレス1.2.3.4に対応するホスト名を求める要求はドメイン名"4.3.2.1.IN-ADDR.ARPA"のためにPTR RRsを探します。
There are, of course, numerous examples of IPv4 addresses scattered throughout the document.
もちろん、ドキュメント中に点在するIPv4アドレスの多数の例があります。
3.12. RFC 1035 Domain Names: Implementation and Specification
3.12. RFC1035ドメイン名: 実装と仕様
Section 3.4.1, "A RDATA format", defines the format for A records:
セクション3.4 .1 「RDATA形式」はA記録のためにフォーマットを定義します:
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
| ADDRESS |
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+ | アドレス| +--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+--+
where:
どこ:
ADDRESS A 32 bit Internet address.
ADDRESS A32はインターネット・アドレスに噛み付きました。
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").
記録はどんな追加セクション処理も引き起こしません。 または、基本ファイルのA系列のRDATA部がドットによって少しも埋め込まれた空間なしで切り離された4つの10進数として表されたインターネット・アドレスである、(例えば、「10.2、.0、0.52インチ、「192.0 .5 0.6インチ)、」
Mickles & Nesser II Informational [Page 11] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[11ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
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
ADDRESS An32はインターネット・アドレスに噛み付きました。
PROTOCOL An 8 bit IP protocol number
8ビットのプロトコルAn IPプロトコル番号
<BIT MAP> A variable length bit map. The bit map
must be a multiple of 8 bits long.
<BIT MAP>A可変長ビットマップ。 長い間、ビットマップは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つに噛み付きます。 最初のビットは、0、1などを移植する2番目を移植するために対応しています。 ビットマップがしばらくを興味があるプロトコルのために含んでいないなら、そのビットはゼロであると思われます。 ポートとプロトコルのための適切な値とニーモニックはRFC1010で指定されます。
For example, if PROTOCOL=TCP (6), the 26th bit corresponds to TCP
port 25 (SMTP). If this bit is set, a SMTP server should be
listening on TCP port 25; if zero, SMTP service is not supported on
the specified address.
例えば、プロトコルがTCP(6)と等しいなら、26番目のビットはTCPポート25(SMTP)に対応しています。 このビットが設定されるなら、SMTPサーバーはTCPポート25の上で聴かれるべきです。 ゼロであるなら、SMTPサービスは指定されたアドレスでサポートされません。
The purpose of WKS RRs is to provide availability information for
servers for TCP and UDP. If a server supports both TCP and UDP, or
has multiple Internet addresses, then multiple WKS RRs are used.
WKS RRsの目的はサーバのための有用性情報をTCPとUDPに供給することです。 サーバに、TCPとUDPの両方をサポートするか、または複数のインターネット・アドレスがあるなら、複数のWKS RRsが使用されています。
WKS RRs cause no additional section processing.
WKS RRsはどんな追加セクション処理も引き起こしません。
Section 3.5, "IN-ADDR.ARPA domain", describes reverse DNS lookups and is clearly IPv4 dependent.
「IN-ADDR.ARPAドメイン」というセクション3.5は、逆のDNSルックアップについて説明して、明確にIPv4扶養家族です。
There are, of course, numerous examples of IPv4 addresses scattered throughout the document.
もちろん、ドキュメント中に点在するIPv4アドレスの多数の例があります。
Mickles & Nesser II Informational [Page 12] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[12ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
3.13. RFC 1042 Standard for the transmission of IP datagrams over IEEE
802 networks
3.13. IEEE802ネットワークの上のIPデータグラムのトランスミッションのためのRFC1042Standard
This specification specifically deals with the transmission of IPv4 packets over IEEE 802 networks.
この仕様はIEEE802ネットワークの上で明確にIPv4パケットのトランスミッションに対処します。
3.14. RFC 1044 Internet Protocol on Network System's HYPERchannel:
Protocol Specification
3.14. ネットワーク・システムのHYPERchannelの上のRFC1044インターネットプロトコル: プロトコル仕様
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. RFC 1055 Nonstandard for transmission of IP datagrams over serial
lines: SLIP
3.15. シリアル・ラインでのIPデータグラムのトランスミッションのためのRFC1055Nonstandard: メモ用紙
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. RFC 1088 Standard for the transmission of IP datagrams over
NetBIOS networks
3.16. NetBIOSネットワークの上のIPデータグラムのトランスミッションのためのRFC1088Standard
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アドレスの長さが制限というNetBIOS15八重奏名の中で合わないので、NetBIOS名(フォームIP.XX.XX.XX.XX)を使用するのについて提示されたテクニックはIPv6アドレスのために利かないでしょう。
3.17. RFC 1112 Host Extensions for IP Multicasting
3.17. IPマルチキャスティングのためのRFC1112ホスト拡張子
This specification defines IP multicast. Parts of the document are IPv4 dependent.
この仕様はIPマルチキャストを定義します。 ドキュメントの部分はIPv4扶養家族です。
3.18. RFC 1132 Standard for the transmission of 802.2 packets over IPX
networks
3.18. IPXネットワークの上の802.2のパケットのトランスミッションのためのRFC1132Standard
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.19. RFC 1201 Transmitting IP traffic over ARCNET networks
3.19. ARCNETネットワークの上のRFC1201Transmitting IPトラフィック
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アドレスに関するこの仕様の主要な関心事はARCnet 8bit addressesの解決でIPv4アドレスに"ARPlike"メソッドで起こります。 これはIPv6と非互換です。
Mickles & Nesser II Informational [Page 13] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[13ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
3.20. RFC 1209 The Transmission of IP Datagrams over the SMDS Service
3.20. SMDSサービスの上のIPデータグラムのRFC1209送信
This specification defines running IPv4 and ARP over SMDS. The methods described could easily be extended to support IPv6 packets.
この仕様はSMDSの上で実行しているIPv4とARPを定義します。 IPv6にパケットをサポートするために容易に説明されたメソッドは広げることができました。
3.21. RFC 1390 Transmission of IP and ARP over FDDI Networks
3.21. FDDIネットワークの上のIPとARPのRFC1390トランスミッション
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.
特に、プロトコルType Code(IPv4のための2048)と対応するプロトコルAddressの長さ(IPv4のための4バイト)の値は、作成される必要があります。 放送とマルチキャストアドレシングのテクニックの議論をまた、含んで、IPv6ネットワークのために同様にアップデートしなければなりません。 データ(256で、八重奏はヘッダースペースを予約した)の4096の八重奏の定義されたMTU制限はIPv6に十分なままで残るべきです。
3.22. RFC 1661 The Point-to-Point Protocol (PPP)
3.22. RFC1661の二地点間プロトコル(ppp)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.23. RFC 1662 PPP in HDLC-like Framing
3.23. HDLCのような縁どりにおけるRFC1662ppp
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
3.24. RFC 2427 Multiprotocol Interconnect over Frame Relay
3.24. RFC2427Multiprotocolはフレームリレーの上で内部連絡します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4. Draft Standards
4. 草稿規格
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.
草稿StandardsはIETFに終わりから二番目の標準のレベルを表します。 複数の、そして、独立していて、共同利用できる実装があるときだけ、プロトコルは草稿規格を実現できます。 草稿Standardsは通常、かなり熟して広く使用されています。
4.1. RFC 951 Bootstrap Protocol (BOOTP)
4.1. RFC951はプロトコルを独力で進みます。(BOOTP)
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.
別の方法で示されない場合、示されたすべての数が10進です。 BOOTPパケットは標準のIP UDPデータグラムに同封されます。 簡単さにおいて、BOOTPパケットが決して断片化されないと思われます。 '標準のネットワークバイトオーダー'で示されたどんな数字フィールドも梱包します、すなわち、最初に、高位のビットを送ります。
Mickles & Nesser II Informational [Page 14] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[14ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
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)'.
aのIPヘッダーでは、最もbootrequestに、クライアントは知られているならそれ自身のIPソースが扱うコネ、そうでなければゼロをいっぱいにします。 サーバアドレスが未知であるときに、受信者IPアドレスは'放送演説'255.255.255が.255であったなら未知になるでしょう。 このアドレスが、'地方のケーブルの上で放送するように意味する、(私はネットの番号を知りません)、'
FIELD BYTES DESCRIPTION
----- ----- ---
分野バイト記述----- ----- ---
[...]
ciaddr 4 client IP address;
filled in by client in bootrequest if known.
[…] ciaddr4クライアントIPアドレス。 知られているなら、最もbootrequestであるのはクライアントによって記入されます。
yiaddr 4 'your' (client) IP address;
filled by server if client doesn't
know its own address (ciaddr was 0).
'your'の(クライアント)IPが扱うyiaddr4。 サーバで、クライアントがそれ自身のアドレスを知らないなら(ciaddrは0でした)、いっぱいにされます。
siaddr 4 server IP address;
returned in bootreply by server.
siaddr4サーバIPアドレス。 bootreplyでは、サーバで、戻りました。
giaddr 4 gateway IP address,
used in optional cross-gateway booting.
任意の交差しているゲートウェイ穂ばらみに使用されるgiaddr4ゲートウェイ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. RFC 1188 Proposed Standard for the Transmission of IP Datagrams
over FDDI Networks
4.2. FDDIネットワークの上のIPデータグラムの送信のRFC1188提案された標準
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.
RFC1390、「FDDIネットワークの上のIPとARPのトランスミッション」でこのドキュメントは非公式に明確に取って代わられます、どんな正式な不賛成も完了していませんでしたが。 したがって、この仕様はこのメモで、より遠くに考えられません。
4.3. RFC 1191 Path MTU discovery
4.3. RFC1191Path MTU発見
The entire process of PMTU discovery is predicated on the use of the DF bit in the IPv4 header, an ICMP message (also IPv4 dependent) and TCP MSS option. This is not compatible with IPv6.
PMTU発見の全体のプロセスはIPv4ヘッダーにおけるDFビットの使用、ICMPメッセージ(IPv4扶養家族も)、およびTCP MSSオプションに叙述されます。 これはIPv6と互換性がありません。
4.4. RFC 1356 Multiprotocol Interconnect on X.25 and ISDN
4.4. RFC1356MultiprotocolはX.25とISDNで内部連絡します。
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(2進の11001100、10進204)はIPです。 この仕様がある順応は、IPがサポートされるのを必要とします。
Mickles & Nesser II Informational [Page 15] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[15ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
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パケットのために定義される必要があるでしょう。
4.5. RFC 1534 Interoperation Between DHCP and BOOTP
4.5. DHCPとBOOTPの間のRFC1534Interoperation
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.6. RFC 1542 Clarifications and Extensions for the Bootstrap Protocol
4.6. RFC1542明確化と拡大、プロトコルを独力で進んでください。
There are no new issues other than those presented in Section 4.1.
セクション4.1に提示されたもの以外の新規発行が全くありません。
4.7. RFC 1629 Guidelines for OSI NSAP Allocation in the Internet
4.7. インターネットのオウシNSAP AllocationのためのRFC1629ガイドライン
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.8. RFC 1762 The PPP DECnet Phase IV Control Protocol (DNCP)
4.8. RFC1762ppp DECnetフェーズIV制御プロトコル(DNCP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.9. RFC 1989 PPP Link Quality Monitoring
4.9. RFC1989のpppのリンクの上質のモニター
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.10. RFC 1990 The PPP Multilink Protocol (MP)
4.10. RFC1990pppマルチリンクプロトコル(MP)
Section 5.1.3, "Endpoint Discriminator Option", defines a Class header field:
セクション5.1 .3 「終点弁別器オプション」はClassヘッダーフィールドを定義します:
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:
Classがさばくクラスは、1つの八重奏であり、識別子アドレス空間を示します。 LCP Endpoint Discriminator 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 マックーアドレスがグローバルに割り当てられたIEEE802.1
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によって定義される必要があります。
Mickles & Nesser II Informational [Page 16] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[16ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
4.11. RFC 1994 PPP Challenge Handshake Authentication Protocol (CHAP)
4.11. RFC1994pppチャレンジハンドシェイク式認証プロトコル(やつ)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.12. RFC 2067 IP over HIPPI
4.12. HIPPIの上のRFC2067IP
Section 5.1, "Packet Formats", contains the following excerpt:
「パケット・フォーマット」というセクション5.1は以下の抜粋を含みます:
EtherType (16 bits) SHALL be set as defined in Assigned Numbers: IP
= 2048 ('0800'h), ARP = 2054 ('0806'h), RARP = 32,821 ('8035'h).
EtherType(16ビット)SHALL、Assigned民数記で定義されるように、設定されてください: IP=2048('0800'h)、ARP=2054('0806'h)、RARP=3万2821('8035'h)。
Section 5.5, "MTU", has the following definition:
セクション5.5"MTU"には、以下の定義があります:
The MTU for HIPPI-SC LANs is 65280 bytes.
HIPPI-サウスカロライナ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つ64のKバイトバッファをうまくはめ込むことができるので、この値は選択されました。 オーバーヘッドは現在で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)
8バイトのHIPPI-FP HeaderのHIPPI-LE Headerの24バイトのIEEE802.2LLC/SNAP Headers8バイトMaximum IPパケットサイズ(MTU)65280バイト------------ 総65320バイト(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パケットには、この定義は適切ではありません。
4.13. RFC 2131 Dynamic Host Configuration Protocol
4.13. RFC2131Dynamic Host Configuration Protocol
This version of DHCP is highly predicated of IPv4. It is not compatible with IPv6.
DHCPのこのバージョンはIPv4について非常に叙述されます。 それはIPv6と互換性がありません。
4.14. RFC 2132 DHCP Options and BOOTP Vendor Extensions
4.14. RFC2132DHCPオプションとBOOTPベンダー拡張子
This is an extension to an IPv4-only specification.
これはIPv4だけ仕様への拡大です。
4.15. RFC 2390 Inverse Address Resolution Protocol
4.15. RFC2390の逆さのアドレス解決プロトコル
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
4.16. RFC 2460 Internet Protocol, Version 6 (IPv6) Specification
4.16. RFC2460インターネットプロトコル、バージョン6(IPv6)仕様
This document defines IPv6 and has no IPv4 issues.
このドキュメントは、IPv6を定義して、IPv4問題を全く持っていません。
Mickles & Nesser II Informational [Page 17] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[17ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
4.17. RFC 2461 Neighbor Discovery for IP Version 6 (IPv6)
4.17. IPバージョン6のためのRFC2461隣人発見(IPv6)
This document defines an IPv6 related specification and has no IPv4 issues.
このドキュメントは、IPv6の関連する仕様を定義して、IPv4問題を全く持っていません。
4.18. RFC 2462 IPv6 Stateless Address Autoconfiguration
4.18. RFC2462のIPv6の状態がないアドレス自動構成
This document defines an IPv6 related specification and has no IPv4 issues.
このドキュメントは、IPv6の関連する仕様を定義して、IPv4問題を全く持っていません。
4.19. RFC 2463 Internet Control Message Protocol (ICMPv6) for the
Internet Protocol Version 6 (IPv6) Specification
4.19. インターネットプロトコルバージョン6(IPv6)仕様のためのRFC2463インターネット・コントロール・メッセージ・プロトコル(ICMPv6)
This document defines an IPv6 related specification and has no IPv4 issues.
このドキュメントは、IPv6の関連する仕様を定義して、IPv4問題を全く持っていません。
4.20. RFC 3596 DNS Extensions to support IP version 6
4.20. IPバージョン6をサポートするRFC3596DNS Extensions
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.
この仕様は、ip6.arpaドメインを使用することでPTR記録と同様にIPv6のためのAAAA記録を定義して、そういうものとしてIPv6問題を全く持っていません。
5. Proposed Standards
5. 提案された標準
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.
提案されたStandardsは紹介している平らなドキュメントです。 ただ一つの実装さえのための要件が全くありません。 多くの場合、ProposedはIETF標準化過程で実装されるか、または決して進められません。 したがって、それらはインターネットコミュニティに提示されるしばしばただ提案された考えです。 時々、欠点は暴露されるか、彼らが問題への多くの競争している解決の1つです。これらの後の場合では、この議論の目的に役立たないように議論は全く提示されません。
5.1. RFC 1234 Tunneling IPX traffic through IP networks
5.1. IPネットワークを通したRFC1234Tunneling IPXトラフィック
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アドレスになるでしょうノードの。 これで、アドレス・マッピングはユニキャスト送信に些細になります: 正常な4八重奏IPアドレスを出て、ホスト番号の最初の2つの八重奏が捨てられます。 カプセル化コードはUDP/IPトンネルパケットの送付先アドレスとしてこのIPアドレスを使用するべきです。
This mapping will not be able to work with IPv6 addresses.
このマッピングはIPv6アドレスで働くことができないでしょう。
Mickles & Nesser II Informational [Page 18] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[18ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
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の八重奏になるでしょう。 これが576の八重奏最大サイズIP実装が受け入れるのに必要であるというよりも大きいことに注意してください。 このカプセル化がテクニックであるとサポートするどんなIP実装も604の八重奏IPパケットを受けることができなければなりません。
As improvements in protocols and hardware allow for larger,
unfragmented IP transmission units, the 576 octet maximum IPX packet
size may become a liability. For this reason, it is recommended
that the IPX maximum transmission unit size be configurable in
implementations of this memo.
プロトコルとハードウェアにおける改良が、より大きくて、非断片化しているIPトランスミッション単位を考慮するとき、576の八重奏の最大のIPXパケットサイズは責任になるかもしれません。 この理由で、IPXマキシマム・トランスミッション・ユニットサイズがこのメモの実装で構成可能であることは、お勧めです。
5.2. RFC 1256 ICMP Router Discovery Messages
5.2. RFC1256ICMPルータ発見メッセージ
This specification defines a mechanism very specific to IPv4.
この仕様はIPv4に非常に特定のメカニズムを定義します。
5.3. RFC 1277 Encoding Network Addresses to Support Operation over
Non-OSI Lower Layers
5.3. 非OSIの低級層の上の操作をサポートするためにネットワーク・アドレスをコード化するRFC1277
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(RFC1006)のネットワークの特定の形式」は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.
IPv6アドレスの10進バージョンに、IPアドレスの10進バージョンのためのこの12八重奏分野は不十分です。 新しいコード化を定義するのは、IPv6アドレス、ポートナンバー、およびTransport Setのバイナリ・バージョンを収容するのに20のケタの長いIP Address+ポート+輸送Set分野を使用することで可能です。 思い描くことができたいくつかの体系があります。
5.4. RFC 1332 The PPP Internet Protocol Control Protocol (IPCP)
5.4. RFC1332pppインターネットプロトコル制御プロトコル(IPCP)
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に割り当てるように、この仕様はメカニズムを定義します。 「IPCP設定オプション」というセクション3は4バイトのロング・フィールドにIPアドレスを埋め込むIPCPオプションタイプを定義します。 IPv6には、これは明確に十分ではありません。
Mickles & Nesser II Informational [Page 19] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[19ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
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.
しかしながら、仕様は新しいOption Typesが加えられるのを許容するように明確に設計されています、そして、適切なオプションがいったん定義されると、ShouldはIPv6との使用のために問題を全く提供しません。
5.5. RFC 1377 The PPP OSI Network Layer Control Protocol (OSINLCP)
5.5. RFC1377ppp OSIネットワーク層制御プロトコル(OSINLCP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.6. RFC 1378 The PPP AppleTalk Control Protocol (ATCP)
5.6. RFC1378ppp AppleTalk制御プロトコル(ATCP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.7. RFC 1469 IP Multicast over Token-Ring Local Area Networks
5.7. トークンリングの上のRFC1469IPマルチキャストローカル・エリア・ネットワーク
This document defines the usage of IPv4 multicast over IEEE 802.5 Token Ring networks. This is not compatible with IPv6.
このドキュメントは、よりIEEEより802.5より多くのToken RingがネットワークでつなぐIPv4マルチキャストの用法を定義します。 これはIPv6と互換性がありません。
5.8. RFC 1552 The PPP Internetworking Packet Exchange Control Protocol
(IPXCP)
5.8. pppインターネットワーキングパケットが交換するRFC1552はプロトコルを制御します。(IPXCP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.9. RFC 1570 PPP LCP Extensions
5.9. RFC1570ppp LCP拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.10. RFC 1598 PPP in X.25 PPP-X25
5.10. X.25ppp-X25のRFC1598ppp
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.11. RFC 1618 PPP over ISDN
5.11. ISDNの上のRFC1618ppp
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.12. RFC 1663 PPP Reliable Transmission
5.12. RFC1663のpppの信頼できる送信
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.13. RFC 1752 The Recommendation for the IP Next Generation Protocol
5.13. IP次世代プロトコルのためのRFC1752推薦
This document defines a road map for IPv6 development and is not relevant to this discussion.
このドキュメントは、IPv6開発のためにロードマップを定義して、この議論に関連していません。
5.14. RFC 1755 ATM Signaling Support for IP over ATM
5.14. 気圧でIPのサポートを示すRFC1755気圧
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Mickles & Nesser II Informational [Page 20] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[20ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
5.15. RFC 1763 The PPP Banyan Vines Control Protocol (BVCP)
5.15. RFC1763pppバニヤンつる植物はプロトコルを制御します。(BVCP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.16. RFC 1764 The PPP XNS IDP Control Protocol (XNSCP)
5.16. RFC1764ppp XNS IDP制御プロトコル(XNSCP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.17. RFC 1973 PPP in Frame Relay
5.17. フレームリレーにおけるRFC1973ppp
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.18. RFC 1981 Path MTU Discovery for IP version 6
5.18. IPバージョン6のためのRFC1981Path MTUディスカバリー
This specification describes an IPv6 related specification and is not discussed in this document.
この仕様について、IPv6の関連する仕様を説明して、本書では議論しません。
5.19. RFC 1982 Serial Number Arithmetic
5.19. RFC1982通し番号演算
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.20. RFC 1995 Incremental Zone Transfer in DNS
5.20. DNSのRFC1995の増加のゾーン転送
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を使用することで完全で適切な機能性を排除するために、仕様には何もありません(すなわち、A記録)。
5.21. RFC 1996 A Mechanism for Prompt Notification of Zone Changes (DNS
NOTIFY)
5.21. ゾーン変化の迅速な通知のための1メカニズムあたりRFC1996(DNSは通知します)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.22. RFC 2003 IP Encapsulation within IP
5.22. IPの中のRFC2003IPカプセル化
This document is designed for use in IPv4 networks. There are many references to a specified IP version number of 4 and 32-bit addresses. This is incompatible with IPv6.
このドキュメントはIPv4ネットワークにおける使用のために設計されています。 指定されたIPバージョン番号の4と32ビットのアドレスの多くの参照があります。 これはIPv6と非互換です。
5.23. RFC 2004 Minimal Encapsulation within IP
5.23. IPの中のRFC2004の最小量のカプセル化
This document is designed for use in IPv4 networks. There are many references to a specified IP version number of 4 and 32-bit addresses. This is incompatible with IPv6.
このドキュメントはIPv4ネットワークにおける使用のために設計されています。 指定されたIPバージョン番号の4と32ビットのアドレスの多くの参照があります。 これはIPv6と非互換です。
5.24. RFC 2005 Applicability Statement for IP Mobility Support
5.24. IP移動性サポートのためのRFC2005適用性証明
This specification documents the interoperation of IPv4 Mobility Support; this is not relevant to this discussion.
この仕様はIPv4 Mobility Supportのinteroperationを記録します。 これはこの議論に関連していません。
Mickles & Nesser II Informational [Page 21] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[21ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
5.25. RFC 2022 Support for Multicast over UNI 3.0/3.1 based ATM
Networks
5.25. UNI3.0/3.1の上のMulticastのためのRFC2022SupportはATM Networksを基礎づけました。
This specification specifically maps IPv4 multicast in UNI based ATM networks. This is incompatible with IPv6.
この仕様はUNIのベースのATMネットワークでIPv4マルチキャストを明確に写像します。 これはIPv6と非互換です。
5.26. RFC 2043 The PPP SNA Control Protocol (SNACP)
5.26. RFC2043ppp SNA制御プロトコル(SNACP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.27. RFC 2097 The PPP NetBIOS Frames Control Protocol (NBFCP)
5.27. ppp NetBIOSが縁どるRFC2097はプロトコルを制御します。(NBFCP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.28. RFC 2113 IP Router Alert Option
5.28. RFC2113IPルータ警戒オプション
This document provides a new mechanism for IPv4. This is incompatible with IPv6.
このドキュメントは新しいメカニズムをIPv4に供給します。 これはIPv6と非互換です。
5.29. RFC 2125 The PPP Bandwidth Allocation Protocol (BAP) / The PPP
Bandwidth Allocation Control Protocol (BACP)
5.29. RFC2125ppp帯域幅配分プロトコル(BAP)/ppp帯域幅調節プロトコル(BACP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.30. RFC 2136 Dynamic Updates in the Domain Name System (DNS UPDATE)
5.30. ドメインネームシステムにおけるRFC2136のダイナミックなアップデート(DNSアップデート)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.31. RFC 2181 Clarifications to the DNS Specification
5.31. DNS仕様へのRFC2181明確化
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アドレスの唯一の参照がanycastアドレスの使用について議論しますが、人は、これらのテクニックが操作できるIPv6であると仮定できます。
5.32. RFC 2225 Classical IP and ARP over ATM
5.32. 気圧でのRFC2225の古典的なIPとARP
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:
そして、:
Mickles & Nesser II Informational [Page 22] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[22ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
For backward compatibility with previous implementations, a null
IPv4 protocol address may be received with length = 4 and an
allocated address in storage set to the value 0.0.0.0. Receiving
stations must be liberal in accepting this format of a null IPv4
address. However, on transmitting an ATMARP or InATMARP packet, a
null IPv4 address must only be indicated by the length set to zero
and must have no storage allocated.
前の実装との後方の互換性において、長さ=4でヌルIPv4プロトコルアドレスを受け取ったかもしれなくて、ストレージにおける割り当てられたアドレスが値にセットした、0.0、.0、.0 受入れステーションはヌルIPv4アドレスのこの形式を受け入れるのにおいて寛容であるに違いありません。 しかしながら、ATMARPかInATMARPパケットを伝えるとき、ヌルIPv4アドレスで、ゼロに設定された長さで示すだけでよくて、ストレージを全く割り当ててはいけません。
5.33. RFC 2226 IP Broadcast over ATM Networks
5.33. 気圧ネットワークの上のRFC2226IP放送
This document is limited to IPv4 multicasting. This is incompatible with IPv6.
このドキュメントはIPv4マルチキャスティングに制限されます。 これはIPv6と非互換です。
5.34. RFC 2241 DHCP Options for Novell Directory Services
5.34. ノベルディレクトリサービスのためのRFC2241DHCPオプション
This is an extension to an IPv4-only specification.
これはIPv4だけ仕様への拡大です。
5.35. RFC 2242 NetWare/IP Domain Name and Information
5.35. RFC2242NetWare/IPドメイン名と情報
This is an extension to an IPv4-only specification, for example:
例えば、これはIPv4だけ仕様への拡大です:
PREFERRED_DSS (code 6)
都合のよい_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 Domain SAP/RIP Server(DSS)のアドレスを含んでいます。
NEAREST_NWIP_SERVER (code 7)
_ほぼ最もNWIP_サーバで(コード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 Nearest NetWare/IPサーバのアドレスを含んでいます。
PRIMARY_DSS (code 11)
プライマリ_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アドレス。 この分野はPrimary Domain SAP/RIP Serviceサーバ(DSS)をこのNetWare/IPドメインに特定します。 セカンダリDSSサーバを構成するとき、NetWare/IP管理ユーティリティはPrimary DSSサーバとしてこの値を使用します。
Mickles & Nesser II Informational [Page 23] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[23ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
5.36. RFC 2290 Mobile-IPv4 Configuration Option for PPP IPCP
5.36. ppp IPCPのためのRFC2290モバイルIPv4設定オプション
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 Router Discover Messages)への頻繁な紹介があります。
5.37. RFC 2308 Negative Caching of DNS Queries (DNS NCACHE)
5.37. DNS質問のRFC2308の否定的キャッシュ(DNS NCACHE)
Although there are numerous examples in this document that use IPv4 "A" records, there is nothing in the specification that limits its effectiveness to IPv4.
このドキュメントのIPv4「A」記録を使用する多数の例がありますが、有効性をIPv4に制限する仕様には何もありません。
5.38. RFC 2331 ATM Signaling Support for IP over ATM - UNI Signaling
4.0 Update
5.38. 気圧でIPのサポートを示すRFC2331気圧--UNIシグナリング4.0アップデート
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.39. RFC 2332 NBMA Next Hop Resolution Protocol (NHRP)
5.39. 次のRFC2332NBMAは解決プロトコルを飛び越します。(NHRP)
This document is very generic in its design and seems to be able to support numerous layer 3 addressing schemes and should include both IPv4 and IPv6.
このドキュメントは、デザインにおけるまさしくそのジェネリックであり、多数の層3のアドレシングが体系であるとサポートすることができるように思えて、IPv4とIPv6の両方を含んでいるはずです。
5.40. RFC 2333 NHRP Protocol Applicability
5.40. RFC2333NHRPプロトコルの適用性
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の両方を含んでいるはずです。
5.41. RFC 2335 A Distributed NHRP Service Using SCSP
5.41. SCSPを使用する分配されたNHRPサービスあたりRFC2335
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.42. RFC 2363 PPP Over FUNI
5.42. FUNIの上のRFC2363ppp
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.43. RFC 2364 PPP Over AAL5
5.43. AAL5の上のRFC2364ppp
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Mickles & Nesser II Informational [Page 24] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[24ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
5.44. RFC 2371 Transaction Internet Protocol Version 3.0 (TIPV3)
5.44. RFC2371トランザクションインターネットプロトコルバージョン3.0(TIPV3)
This document states:
このドキュメントは以下を述べます。
TIP transaction manager addresses take the form:
TIPトランザクションマネージャアドレスは形を取ります:
<hostport><path>
<hostport><経路>。
The <hostport> component comprises:
<hostport>の部品は以下を包括します。
<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のどちらかであるところでは、>を扱ってください。 そして、<ポート>はトランザクションマネージャ(または、プロキシ)が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.
<ipアドレス>は普通のフォームでのIPアドレスです: 期間のキャラクタによって切り離された4つの10進数。
And further along it states:
そして、さらにずっと、それは以下を述べます。
A TIP URL takes the form:
TIP URLは形を取ります:
tip://<transaction manager address>?<transaction string>
チップ://<トランザクションマネージャアドレス>?<トランザクションストリング>。
where <transaction manager address> identifies the TIP transaction
manager (as defined in Section 7 above); and <transaction string>
specifies a transaction identifier, which may take one of two
forms (standard or non-standard):
<トランザクションマネージャアドレス>がTIPトランザクションマネージャを特定する(上のセクション7で定義されるように)ところ。 そして、<トランザクションストリング>はトランザクション識別子を指定します:(識別子は2つのフォーム(標準の、または、標準的でない)の1つを取るかもしれません)。
i. "urn:" <NID> ":" <NSS>
i。 「つぼ:」 「<NID>」:、」 <NSS>。
A standard transaction identifier, conforming to the proposed
Internet Standard for Uniform Resource Names (URNs), as specified
by RFC2141; where <NID> is the Namespace Identifier, and <NSS> is
the Namespace Specific String. The Namespace ID determines the
syntactic interpretation of the Namespace Specific String. The
Namespace Specific String is a sequence of characters representing
a transaction identifier (as defined by <NID>). The rules for
the contents of these fields are specified by RFC2141 (valid
characters, encoding, etc.).
RFC2141によって指定されるようにUniform Resource Names(URNs)のための提案されたインターネットStandardに従う標準のトランザクション識別子。 <NID>がNamespace Identifierであり、<NSS>がNamespace Specific Stringであるところ。 Namespace IDはNamespace Specific Stringの統語的解釈を決定します。 Namespace Specific Stringはトランザクション識別子を表すキャラクタの系列(<NID>によって定義されるように)です。 これらの分野のコンテンツのための規則はRFC2141(有効なキャラクタ、コード化など)によって指定されます。
Mickles & Nesser II Informational [Page 25] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[25ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
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/?つぼ:xopen:xid
Note that Namespace Ids require registration.
Namespace 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にある八重奏、包括的である、(」、:、」、)、aトランザクション識別子コネを表して、この標準的でないケースでありそれは<トランザクションマネージャアドレス>と例えばグローバルなユニークさを確実にする<トランザクション識別子>の組み合わせです。
tip://123.123.123.123/?transid1
チップ://123.123.123.123/?transid1
These are incompatible with IPv6.
これらはIPv6と非互換です。
5.45. RFC 2464 Transmission of IPv6 Packets over Ethernet Networks
5.45. イーサネットネットワークの上のIPv6パケットのRFC2464トランスミッション
This specification documents a method for transmitting IPv6 packets over Ethernet and is not considered in this discussion.
この仕様は、IPv6パケットをイーサネットの上に伝えるためにメソッドを記録して、この議論で考えられません。
5.46. RFC 2467 Transmission of IPv6 Packets over FDDI Networks
5.46. FDDIネットワークの上のIPv6パケットのRFC2467トランスミッション
This specification documents a method for transmitting IPv6 packets over FDDI and is not considered in this discussion.
この仕様は、IPv6パケットをFDDIの上に伝えるためにメソッドを記録して、この議論で考えられません。
5.47. RFC 2470 Transmission of IPv6 Packets over Token Ring Networks
5.47. トークンリングネットワークの上のIPv6パケットのRFC2470トランスミッション
This specification documents a method for transmitting IPv6 packets over Token Ring and is not considered in this discussion.
この仕様は、IPv6パケットをToken Ringの上に伝えるためにメソッドを記録して、この議論で考えられません。
5.48. RFC 2472 IP Version 6 over PPP
5.48. pppの上のRFC2472IPバージョン6
This specification documents a method for transmitting IPv6 packets over PPP and is not considered in this discussion.
この仕様は、IPv6パケットをPPPの上に伝えるためにメソッドを記録して、この議論で考えられません。
5.49. RFC 2473 Generic Packet Tunneling in IPv6 Specification
5.49. IPv6仕様でトンネルを堀るRFC2473ジェネリックパケット
This specification documents an IPv6 aware specification and is not considered in this discussion.
この仕様は、IPv6の意識している仕様を記録して、この議論で考えられません。
5.50. RFC 2484 PPP LCP Internationalization Configuration Option
5.50. RFC2484ppp LCP国際化設定オプション
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Mickles & Nesser II Informational [Page 26] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[26ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
5.51. RFC 2485 DHCP Option for The Open Group's User Authentication
Protocol
5.51. TheOpenGroupのユーザー認証プロトコルのためのRFC2485DHCPオプション
This is an extension to an IPv4-only specification.
これはIPv4だけ仕様への拡大です。
5.52. RFC 2486 The Network Access Identifier
5.52. RFC2486ネットワークアクセス識別子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.53. RFC 2491 IPv6 over Non-Broadcast Multiple Access (NBMA) Networks
5.53. 非放送複数のアクセス(NBMA)ネットワークの上のRFC2491IPv6
This specification documents a method for transmitting IPv6 packets over NBMA networks and is not considered in this discussion.
この仕様は、NBMAネットワークの上にIPv6パケットを伝えるためにメソッドを記録して、この議論で考えられません。
5.54. RFC 2492 IPv6 over ATM Networks
5.54. 気圧ネットワークの上のRFC2492IPv6
This specification documents a method for transmitting IPv6 packets over ATM networks and is not considered in this discussion.
この仕様は、ATMネットワークの上にIPv6パケットを伝えるためにメソッドを記録して、この議論で考えられません。
5.55. RFC 2497 Transmission of IPv6 Packets over ARCnet Networks
5.55. ARCnetネットワークの上のIPv6パケットのRFC2497トランスミッション
This specification documents a method for transmitting IPv6 packets over ARCnet networks and is not considered in this discussion.
この仕様は、ARCnetネットワークの上にIPv6パケットを伝えるためにメソッドを記録して、この議論で考えられません。
5.56. RFC 2507 IP Header Compression
5.56. RFC2507IPヘッダー圧縮
This specification is both IPv4 and IPv6 aware.
この仕様はIPv4とIPv6ともに意識しています。
5.57. RFC 2526 Reserved IPv6 Subnet Anycast Addresses
5.57. RFC2526はIPv6サブネットAnycastアドレスを予約しました。
This specification documents IPv6 addressing and is not discussed in this document.
この仕様について、IPv6アドレシングを記録して、本書では議論しません。
5.58. RFC 2529 Transmission of IPv6 over IPv4 Domains without Explicit
Tunnels
5.58. 明白なTunnelsのいないIPv4ドメインの上のIPv6のRFC2529トランスミッション
This specification documents IPv6 transmission methods and is not discussed in this document.
この仕様について、IPv6透過法を記録して、本書では議論しません。
5.59. RFC 2563 DHCP Option to Disable Stateless Auto-Configuration in
IPv4 Clients
5.59. IPv4クライアントで状態がない自動構成を無効にするRFC2563DHCPオプション
This is an extension to an IPv4-only specification.
これはIPv4だけ仕様への拡大です。
Mickles & Nesser II Informational [Page 27] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[27ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
5.60. RFC 2590 Transmission of IPv6 Packets over Frame Relay Networks
Specification
5.60. フレームリレーの上のIPv6パケットのRFC2590トランスミッションは仕様をネットワークでつなぎます。
This specification documents IPv6 transmission method over Frame Relay and is not discussed in this document.
この仕様について、Frame Relayの上にIPv6透過法を記録して、本書では議論しません。
5.61. RFC 2601 ILMI-Based Server Discovery for ATMARP
5.61. ATMARPのためのRFC2601のILMIベースのサーバ発見
This specification is both IPv4 and IPv6 aware.
この仕様はIPv4とIPv6ともに意識しています。
5.62. RFC 2602 ILMI-Based Server Discovery for MARS
5.62. 火星のためのRFC2602のILMIベースのサーバ発見
This specification is both IPv4 and IPv6 aware.
この仕様はIPv4とIPv6ともに意識しています。
5.63. RFC 2603 ILMI-Based Server Discovery for NHRP
5.63. NHRPのためのRFC2603のILMIベースのサーバ発見
This specification is both IPv4 and IPv6 aware.
この仕様はIPv4とIPv6ともに意識しています。
5.64. RFC 2610 DHCP Options for Service Location Protocol
5.64. サービス位置のプロトコルのためのRFC2610DHCPオプション
This is an extension to an IPv4-only specification.
これはIPv4だけ仕様への拡大です。
5.65. RFC 2615 PPP over SONET/SDH
5.65. Sonet/SDHの上のRFC2615ppp
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.66. RFC 2625 IP and ARP over Fibre Channel
5.66. 繊維チャンネルの上のRFC2625IPとARP
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とAddress Resolutionがプロトコル(ARP)パケットであるとカプセル化するためのメソッドを説明します。
This is incompatible with IPv6.
これはIPv6と非互換です。
5.67. RFC 2661 Layer Two Tunneling Protocol (L2TP)
5.67. RFC2661層Twoのトンネリングプロトコル(L2TP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.68. RFC 2671 Extension Mechanisms for DNS (EDNS0)
5.68. DNSのためのRFC2671拡張機能(EDNS0)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Mickles & Nesser II Informational [Page 28] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[28ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
5.69. RFC 2672 Non-Terminal DNS Name Redirection
5.69. RFC2672非端末DNS名前リダイレクション
This document is only defined for IPv4 addresses. An IPv6 specification may be needed.
このドキュメントはIPv4アドレスのために定義されるだけです。 IPv6仕様が必要であるかもしれません。
5.70. RFC 2673 Binary Labels in the Domain Name System
5.70. ドメインネームシステムにおけるRFC2673の2進のラベル
This document is only defined for IPv4 addresses. An IPv6 specification may be needed.
このドキュメントはIPv4アドレスのために定義されるだけです。 IPv6仕様が必要であるかもしれません。
5.71. RFC 2675 IPv6 Jumbograms
5.71. RFC2675IPv6 Jumbograms
This document defines a IPv6 packet format and is therefore not discussed in this document.
このドキュメントについて、IPv6パケット・フォーマットを定義して、したがって、本書では議論しません。
5.72. RFC 2684 Multiprotocol Encapsulation over ATM Adaptation Layer 5
5.72. 気圧適合層5の上のRFC2684Multiprotocolカプセル化
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.73. RFC 2685 Virtual Private Networks Identifier
5.73. RFC2685仮想私設網識別子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.74. RFC 2686 The Multi-Class Extension to Multi-Link PPP
5.74. マルチリンクpppへのRFC2686マルチのクラス拡張子
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.75. RFC 2687 PPP in a Real-time Oriented HDLC-like Framing
5.75. リアルタイムの指向のHDLCのような縁どりにおけるRFC2687ppp
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.76. RFC 2688 Integrated Services Mappings for Low Speed Networks
5.76. RFC2688は低速ネットワークのためのサービスマッピングを統合しました。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.77. RFC 2710 Multicast Listener Discovery (MLD) for IPv6
5.77. IPv6のためのRFC2710マルチキャストリスナー発見(MLD)
This document defines an IPv6 specific specification and is not discussed in this document.
このドキュメントについて、IPv6の特定の仕様を定義して、本書では議論しません。
5.78. RFC 2711 IPv6 Router Alert Option
5.78. RFC2711IPv6ルータ警戒オプション
This document defines an IPv6 specific specification and is not discussed in this document.
このドキュメントについて、IPv6の特定の仕様を定義して、本書では議論しません。
Mickles & Nesser II Informational [Page 29] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[29ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
5.79. RFC 2728 The Transmission of IP Over the Vertical Blanking
Interval of a Television Signal
5.79. テレビジョン信号の垂直な空白間隔の間のIPのRFC2728トランスミッション
The following data format is defined:
以下のデータの形式は定義されます:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|0| group | uncompressed IP header (20 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
: .... :
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | uncompressed UDP header (8 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
+ +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| | payload (<1472 bytes) |
+-+-+-+-+-+-+-+-+ +
| |
: .... :
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| CRC |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ |0| グループ| 解凍されたIPヘッダー(20バイト)| +-+-+-+-+-+-+-+-+ + | | : .... : + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | 解凍されたUDPヘッダー(8バイト)| +-+-+-+-+-+-+-+-+ + | | + +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | ペイロード(<1472バイト)| +-+-+-+-+-+-+-+-+ + | | : .... : +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | CRC| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
This is incompatible with IPv6.
これはIPv6と非互換です。
5.80. RFC 2734 IPv4 over IEEE 1394
5.80. IEEE1394の上のRFC2734IPv4
This specification is IPv4 only.
この仕様はIPv4専用です。
5.81. RFC 2735 NHRP Support for Virtual Private Networks
5.81. 仮想私設網のRFC2735NHRPサポート
This specification implies only IPv4 operations, but does not seem to present any reason that it would not function for IPv6.
この仕様は、IPv4操作だけを含意しますが、IPv6のために機能しないだろうどんな理由も提示するように思えません。
5.82. RFC 2765 Stateless IP/ICMP Translation Algorithm (SIIT)
5.82. RFC2765状態がないIP/ICMP変換アルゴリズム(SIIT)
This specification defines a method for IPv6 transition and is not discussed in this document.
この仕様について、IPv6変遷のためのメソッドを定義して、本書では議論しません。
5.83. RFC 2766 Network Address Translation - Protocol Translation
(NAT-PT)
5.83. RFC2766ネットワークアドレス変換--プロトコル変換(太平洋標準時のNAT)
This specification defines a method for IPv6 transition and is not discussed in this document.
この仕様について、IPv6変遷のためのメソッドを定義して、本書では議論しません。
Mickles & Nesser II Informational [Page 30] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[30ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
5.84. RFC 2776 Multicast-Scope Zone Announcement Protocol (MZAP)
5.84. RFC2776マルチキャスト範囲ゾーン発表プロトコル(MZAP)
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
5.85. RFC 2782 A DNS RR for specifying the location of services
5.85. サービスの位置を指定するためのRFC2782A DNS RR
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.86. RFC 2794 Mobile IP Network Access Identifier Extension for IPv4
5.86. IPv4のためのRFC2794のモバイルIPネットワークアクセス識別子拡張子
This is an extension to an IPv4-only specification.
これはIPv4だけ仕様への拡大です。
5.87. RFC 2834 ARP and IP Broadcast over HIPPI-800
5.87. RFC2834ARPとHIPPI-800の上で放送されたIP
This document uses the generic term "IP Address" in the text but it also contains the text:
このドキュメントはテキストで総称「IPアドレス」を使用しますが、また、テキストを含んでいます:
The HARP message has several fields that have the following format
and values:
HARPメッセージには、以下の形式と値を持っているいくつかの分野があります:
Data sizes and field meaning:
ar$hrd 16 bits Hardware type
ar$pro 16 bits Protocol type of the protocol fields below
ar$op 16 bits Operation code (request, reply, or NAK)
ar$pln 8 bits byte length of each protocol address
ar$rhl 8 bits requester's HIPPI hardware address length (q)
ar$thl 8 bits target's HIPPI hardware address length (x)
ar$rpa 32 bits requester's protocol address
ar$tpa 32 bits target's protocol address
ar$rha qbytes requester's HIPPI Hardware address
ar$tha xbytes target's HIPPI Hardware address
データサイズと分野意味: ar$のhrdの16ビットのHardwareはtha xbytes目標のrhlの8ビットのリクエスタのHIPPIハードウェア・アドレス長さ(q)ar$thlの8ビットの目標のHIPPIハードウェア・アドレス長さ(x)ar$rpaの32ビットのリクエスタのプロトコルアドレスar$tpaの32ビットの目標のプロトコルアドレスar$rha qbytesリクエスタのHIPPI Hardwareアドレスar$HIPPI Hardwareが扱うそれぞれのプロトコルアドレスar$の8ビットの16ビットのar$オプアートOperationコード(要求、回答、またはNAK)ar$plnバイトの長さの下のプロトコル分野の16ビットのar$プロプロトコルタイプをタイプします。
Where:
ar$hrd - SHALL contain 28. (HIPARP)
どこ: ar$hrd--SHALLは28を含んでいます。 (HIPARP)
ar$pro - SHALL contain the IP protocol code 2048 (decimal).
ar$プロ--SHALLはIPプロトコルコード2048(小数)を含んでいます。
ar$op - SHALL contain the operational value (decimal):
1 for HARP_REQUESTs
2 for HARP_REPLYs
8 for InHARP_REQUESTs
9 for InHARP_REPLYs
10 for HARP_NAK
ar$pln - SHALL contain 4.
ar$オプアート--SHALLは操作上の値(小数)を含んでいます: HARP_NAK ar$plnのInHARP_REPLYs10のためのInHARP_REQUESTs9のためのHARP_REPLYs8のためのHARP_REQUESTs2のための1--SHALLは4を含んでいます。
Mickles & Nesser II Informational [Page 31] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[31ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
And later:
より遅れています:
31 28 23 21 15 10 7 2 0
+-----+---------+-+-+-----------+---------+-----+---------+-----+
0 | 04 |1|0| 000 | 03 | 0 |
+---------------+-+-+---------------------+---------------+-----+
1 | 45 |
+-----+-+-------+-----------------------+-----------------------+
2 |[LA] |W|MsgT= 0| 000 | Dest. Switch Addr |
+-----+-+-------+-----------------------+-----------------------+
3 | 2 | 2 | 000 | Source Switch Addr |
+---------------+---------------+-------+-----------------------+
4 | 00 00 | |
+-------------------------------+ |
5 | Destination ULA |
+-------------------------------+-------------------------------+
6 | [LA] | |
+-------------------------------+ |
7 | Source ULA |
+===============+===============+===============+===============+
8 | AA | AA | 03 | 00 |
+---------------+---------------+---------------+---------------+
9 | 00 | 00 | Ethertype (2054) |
+---------------+---------------+-------------------------------+
10 | hrd (28) | pro (2048) |
+---------------+---------------+---------------+---------------+
11 | op (ar$op) | pln (6) | rhl (q) |
+---------------+---------------+---------------+---------------+
12 | thl = (x) | Requester IP Address upper (24 bits) |
+---------------------------------------------------------------+
13 | Req. IP lower | Target IP Address upper (24 bits) |
+---------------+-----------------------------------------------+
14 | Tgt. IP lower | Requester HIPPI Hardware Address bytes 0 - 2 |
+---------------+-----------------------------------------------+
15 | Requester HIPPI Hardware Address bytes 3 - 6 |
+-----------------------------------------------+---------------+
16 | Requester HW Address bytes 7 - q | Tgt HW byte 0 |
+---------------+---------------+---------------+---------------+
17 | Target HIPPI Hardware Address bytes 1 - 4 |
+---------------------------------------------------------------+
18 | Target HIPPI Hardware Address bytes 5 - 8 |
+---------------+---------------+---------------+---------------+
19 |Tgt HW byte 9-x| FILL | FILL | FILL |
+---------------+---------------+---------------+---------------+
HARP - InHARP Message
31 28 23 21 15 10 7 2 0 +-----+---------+-+-+-----------+---------+-----+---------+-----+ 0 | 04 |1|0| 000 | 03 | 0 | +---------------+-+-+---------------------+---------------+-----+ 1 | 45 | +-----+-+-------+-----------------------+-----------------------+ 2 |[LA]|W|MsgT=0| 000 | Dest。 スイッチAddr| +-----+-+-------+-----------------------+-----------------------+ 3 | 2 | 2 | 000 | ソーススイッチAddr| +---------------+---------------+-------+-----------------------+ 4 | 00 00 | | +-------------------------------+ | 5 | 目的地ULA| +-------------------------------+-------------------------------+ 6 | [LA]| | +-------------------------------+ | 7 | ソースULA| +===============+===============+===============+===============+ 8 | AA| AA| 03 | 00 | +---------------+---------------+---------------+---------------+ 9 | 00 | 00 | Ethertype(2054)| +---------------+---------------+-------------------------------+ 10 | hrd(28)| プロ(2048)| +---------------+---------------+---------------+---------------+ 11 | オプアート(ar$オプアート)| pln(6)| rhl(q)| +---------------+---------------+---------------+---------------+ 12 | thlは(x)と等しいです。| リクエスタIP Address覚醒剤(24ビット)| +---------------------------------------------------------------+ 13 | Req。 IPは下ろされます。| 上側で(24ビット)IP Addressを狙ってください。| +---------------+-----------------------------------------------+ 14 | Tgt。 IPは下ろされます。| リクエスタHIPPI Hardware Addressバイト0--2| +---------------+-----------------------------------------------+ 15 | リクエスタHIPPI Hardware Addressバイト3--6| +-----------------------------------------------+---------------+ 16 | リクエスタHW Addressバイト7--q| Tgt HWバイト0| +---------------+---------------+---------------+---------------+ 17 | 目標HIPPI Hardware Addressバイト1--4| +---------------------------------------------------------------+ 18 | 目標HIPPI Hardware Addressバイト5--8| +---------------+---------------+---------------+---------------+ 19 |Tgt HWバイト9-x| 中詰め| 中詰め| 中詰め| +---------------+---------------+---------------+---------------+ ハープ--InHARPメッセージ
This is incompatible with IPv6.
これはIPv6と非互換です。
Mickles & Nesser II Informational [Page 32] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[32ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
5.88. RFC 2835 IP and ARP over HIPPI-6400
5.88. HIPPI-6400の上のRFC2835IPとARP
This document states:
このドキュメントは以下を述べます。
The Ethertype value SHALL be set as defined in Assigned Numbers:
EthertypeはAssignedで定義されるセットが民数記であったならSHALLを評価します:
IP 0x0800 2048 (16 bits)
IP0x0800 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.
これは、IPv6と両立しない前項とIPv4に限られていて、同様です。 この仮定を確認するドキュメントには他の多数のポイントがあります。
5.89. RFC 2855 DHCP for IEEE 1394
5.89. IEEE1394のためのRFC2855DHCP
This is an extension to an IPv4-only specification.
これはIPv4だけ仕様への拡大です。
5.90. RFC 2874 DNS Extensions to Support IPv6 Address Aggregation and
Renumbering
5.90. IPv6がアドレス集合であるとサポートするRFC2874DNS拡張子と番号を付け替えること
This document defines a specification to interact with IPv6 and is not considered in this document.
このドキュメントは、IPv6と対話するために仕様を定義して、本書では考えられません。
5.91. RFC 2893 Transition Mechanisms for IPv6 Hosts and Routers
5.91. IPv6ホストとルータのためのRFC2893変遷メカニズム
This document defines a transition mechanism for IPv6 and is not considered in this document.
このドキュメントは、IPv6のために変遷メカニズムを定義して、本書では考えられません。
5.92. RFC 2916 E.164 number and DNS
5.92. RFC2916E.164番号とDNS
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.93. RFC 2937 The Name Service Search Option for DHCP
5.93. DHCPのためのRFC2937名前サービス検索オプション
This is an extension to an IPv4-only specification.
これはIPv4だけ仕様への拡大です。
5.94. RFC 3004 The User Class Option for DHCP
5.94. DHCPのためのRFC3004ユーザ・クラスオプション
This is an extension to an IPv4-only specification.
これはIPv4だけ仕様への拡大です。
5.95. RFC 3011 The IPv4 Subnet Selection Option for DHCP
5.95. DHCPのためのRFC3011IPv4サブネット選択オプション
This is an extension to an IPv4-only specification.
これはIPv4だけ仕様への拡大です。
5.96. RFC 3021 Using 31-Bit Prefixes for IPv4 P2P Links
5.96. IPv4 P2Pリンクに31ビットの接頭語を使用するRFC3021
This specification is specific to IPv4 address architecture, where a modification is needed to use both addresses of a 31-bit prefix. This is possible by IPv6 address architecture, but in most cases not
この仕様はIPv4アドレス体系に特定です。そこでは、変更が、31ビットの接頭語の両方のアドレスを使用するのに必要です。 これは、IPv6アドレス体系で可能ですが、多くの場合、可能ではありません。
Mickles & Nesser II Informational [Page 33] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[33ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
recommended; see RFC 3627, Use of /127 Prefix Length Between Routers Considered Harmful.
お勧め。 RFC3627、/127Prefix Length Between Routers Considered HarmfulのUseを見てください。
5.97. RFC 3024 Reverse Tunneling for Mobile IP, revised
5.97. モバイルIPのためのRFC3024Reverse Tunneling改訂されて、
This is an extension to an IPv4-only specification.
これはIPv4だけ仕様への拡大です。
5.98. RFC 3046 DHCP Relay Agent Information Option
5.98. RFC3046DHCP中継エージェント情報オプション
This is an extension to an IPv4-only specification.
これはIPv4だけ仕様への拡大です。
5.99. RFC 3056 Connection of IPv6 Domains via IPv4 Clouds
5.99. IPv4 Cloudsを通したIPv6 DomainsのRFC3056Connection
This is an IPv6 related document and is not discussed in this document.
これについて、IPv6の関連するドキュメントであり、本書では議論しません。
5.100. RFC 3068 An Anycast Prefix for 6to4 Relay Routers
5.100. 6to4リレールータのためのAnycast接頭語あたりRFC3068
This is an IPv6 related document and is not discussed in this document.
これについて、IPv6の関連するドキュメントであり、本書では議論しません。
5.101. RFC 3070 Layer Two Tunneling Protocol (L2TP) over Frame Relay
5.101. フレームリレーの上でプロトコル(L2TP)にトンネルを堀るRFC3070層Two
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.102. RFC 3074 DHC Load Balancing Algorithm
5.102. RFC3074DHCロードバランシングアルゴリズム
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.103. RFC 3077 A Link-Layer Tunneling Mechanism for Unidirectional
Links
5.103. 単方向のリンクへのリンクレイヤトンネリングメカニズムあたりRFC3077
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
5.104. RFC 3115 Mobile IP Vendor/Organization-Specific Extensions
5.104. 組織RFC3115のモバイルIPベンダー/特有の拡大
This is an extension to an IPv4-only specification.
これはIPv4だけ仕様への拡大です。
5.105. RFC 3145 L2TP Disconnect Cause Information
5.105. RFC3145L2TPは、原因が情報であると切断します。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.106. RFC 3344 IP Mobility Support for IPv4
5.106. IPv4のRFC3344IP移動性サポート
There are IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存があります。
Mickles & Nesser II Informational [Page 34] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[34ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
5.107. RFC 3376 Internet Group Management Protocol, Version 3
5.107. RFC3376インターネットグループ管理プロトコル、バージョン3
This document describes of version of IGMP used for IPv4 multicast. This is not compatible with IPv6.
このドキュメントが説明する、IPv4マルチキャストに使用されるIGMPのバージョンについて。 これはIPv6と互換性がありません。
5.108. RFC 3402 Dynamic Delegation Discovery System (DDDS) Part Two:
The Algorithm
5.108. RFC3402のダイナミックな委譲発見システム(DDDS)パートTwo: アルゴリズム
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.109. RFC 3403 Dynamic Delegation Discovery System (DDDS) Part Three:
The Domain Name System (DNS) Database
5.109. RFC3403のダイナミックな委譲発見システム(DDDS)パートThree: ドメインネームシステム(DNS)データベース
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
5.110. RFC 3513 IP Version 6 Addressing Architecture
5.110. RFC3513IPバージョン6アドレッシング体系
This specification documents IPv6 addressing and is not discussed in this document.
この仕様について、IPv6アドレシングを記録して、本書では議論しません。
5.111. RFC 3518 Point-to-Point Protocol (PPP) Bridging Control
Protocol (BCP)
5.111. コントロールがプロトコルであるとブリッジするRFC3518の二地点間プロトコル(ppp)(BCP)
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6. Experimental RFCs
6. 実験的なRFCs
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.
実験的なRFCsはインターネットに広いスケール実装か用法を持っていないプロトコルを通常定義します。 しばしばそれらは限られたアリーナで自然か中古の正当です。 それらは、潜在的相互運用性かある他の潜在的役に立つシナリオを許容するためにインターネットコミュニティに記録されます。 いくつかの場合では、それらは主流のソリューションへの代替手段として承認された問題に提示されます。
6.1. RFC 1149 Standard for the transmission of IP datagrams on avian
carriers
6.1. 鳥のキャリヤーにおけるIPデータグラムのトランスミッションのためのRFC1149Standard
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で伝えることができるくらい小さく残っているのでミリグラムが制限に重みを加えると推定して。
6.2. RFC 1183 New DNS RR Definitions
6.2. RFC1183の新しいDNS RR定義
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Mickles & Nesser II Informational [Page 35] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[35ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
6.3. RFC 1226 Internet protocol encapsulation of AX.25 frames
6.3. AX.25フレームのRFC1226インターネットプロトコルカプセル化
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.4. RFC 1241 Scheme for an internet encapsulation protocol: Version 1
6.4. インターネットカプセル化のためのRFC1241Schemeは議定書を作ります: バージョン1
This specification defines a specification that assumes IPv4 but does not actually have any limitations which would limit its operation in an IPv6 environment.
この仕様はIPv6環境でIPv4を仮定しますが、実際に操作を制限する少しの制限も持っていない仕様を定義します。
6.5. RFC 1307 Dynamically Switched Link Control Protocol
6.5. RFC1307はダイナミックにリンク制御プロトコルを切り換えました。
This specification is IPv4 dependent, for example:
例えば、この仕様はIPv4扶養家族です:
3.1 Control Message Format
3.1 コントロールメッセージ・フォーマット
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Identifier | Total length | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Function | Event Status | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint 1 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Endpoint 2 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Message | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Body | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 識別子| 全長| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 機能| イベント状態| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 終点1| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 終点2| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | メッセージ| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ボディー| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Endpoint addresses: 32 bits each
終点アドレス: それぞれ32ビット
The internet addresses of the two communicating parties for which the link is being prepared.
リンクが準備されているパーティーを伝える2つのもののインターネットアドレス。
6.6. RFC 1393 Traceroute Using an IP Option
6.6. IPオプションを使用するRFC1393トレースルート
This document uses an IPv4 option. It is therefore limited to IPv4 networks, and is incompatible with IPv6.
このドキュメントはIPv4オプションを使用します。 それは、したがって、IPv4ネットワークに制限されて、IPv6と非互換です。
6.7. RFC 1433 Directed ARP
6.7. RFC1433はARPを指示しました。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
Mickles & Nesser II Informational [Page 36] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[36ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
6.8. RFC 1464 Using the Domain Name System To Store Arbitrary String
Attributes
6.8. 任意のストリング属性を保存するのにドメインネームシステムを使用するRFC1464
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.9. RFC 1475 TP/IX: The Next Internet
6.9. RFC1475TP/IX: 次のインターネット
This document defines IPv7 and has been abandoned by the IETF as a feasible design. It is not considered in this document.
このドキュメントは、IPv7を定義して、可能なデザインとしてIETFによって捨てられました。 それは本書では考えられません。
6.10. RFC 1561 Use of ISO CLNP in TUBA Environments
6.10. チューバ環境におけるISO CLNPのRFC1561使用
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の依存が全くありません。
6.11. RFC 1712 DNS Encoding of Geographical Location
6.11. 地理的な位置のRFC1712DNSコード化
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.12. RFC 1735 NBMA Address Resolution Protocol (NARP)
6.12. RFC1735NBMAアドレス解決プロトコル(NARP)
This document defines a specification that is IPv4 specific, for example:
このドキュメントは例えばIPv4特有の仕様を定義します:
4. Packet Formats
4. パケット・フォーマット
NARP requests and replies are carried in IP packets as protocol type 54. This section describes the packet formats of NARP requests and replies:
NARP要求と回答はプロトコルタイプ54としてIPパケットで運ばれます。 このセクションはNARP要求と回答のパケット・フォーマットについて説明します:
NARP Request
NARP要求
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Hop Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBMA length | NBMA address |
+-+-+-+-+-+-+-+-+ |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| ホップカウント| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付先IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NBMAの長さ| NBMAアドレス| +-+-+-+-+-+-+-+-+ | | (可変長) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Mickles & Nesser II Informational [Page 37] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[37ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
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.
ソースとDestination IP Addresses Respectively、これらはNBMAアドレスが望まれているNARPリクエスタと目標端末のIPアドレスです。
And:
そして、:
NARP Reply
NARP回答
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Hop Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBMA length | NBMA address |
+-+-+-+-+-+-+-+-+ |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | バージョン| ホップカウント| チェックサム| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| コード| 未使用| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | 送付先IPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | ソースIPアドレス| +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | NBMAの長さ| NBMAアドレス| +-+-+-+-+-+-+-+-+ | | (可変長) | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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.
ソースとDestination IP Address Respectively、これらはNBMAアドレスが望まれているNARPリクエスタと目標端末のIPアドレスです。
This is incompatible with IPv6.
これはIPv6と非互換です。
6.13. RFC 1768 Host Group Extensions for CLNP Multicasting
6.13. CLNPマルチキャスティングのためのRFC1768ホスト群拡大
This specification defines multicasting for CLNP, which is not an IP protocol, and therefore has no IPv4 dependencies.
この仕様は、CLNPのためにマルチキャスティングを定義して、したがって、IPv4の依存を全く持っていません。(CLNPはIPプロトコルではありません)。
6.14. RFC 1788 ICMP Domain Name Messages
6.14. RFC1788ICMPドメイン名メッセージ
This specification is used for updates to the in-addr.arpa reverse DNS maps, and is limited to IPv4.
この仕様は、アップデートにaddr.arpaの逆のDNS地図に使用されて、IPv4に制限されます。
6.15. RFC 1797 Class A Subnet Experiment
6.15. サブネットが実験するRFC1797のクラス
This document is specific to IPv4 address architecture, and as such, has no IPv6 dependencies.
このドキュメントは、IPv4アドレス体系と、そのようなものとして特定であり、IPv6の依存を全く持っていません。
Mickles & Nesser II Informational [Page 38] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[38ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
6.16. RFC 1819 Internet Stream Protocol Version 2 (ST2) Protocol
Specification - Version ST2+
6.16. RFC1819インターネットストリームプロトコルバージョン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によって捨てられて、この議論で考えられません。
6.17. RFC 1868 ARP Extension - UNARP
6.17. RFC1868ARP拡張子--UNARP
This specification defines an extension to IPv4 ARP to delete entries from ARP caches on a link.
この仕様は、リンクでARPキャッシュからエントリーを削除するために拡大をIPv4 ARPと定義します。
6.18. RFC 1876 A Means for Expressing Location Information in the
Domain Name System
6.18. ドメインネームシステムにおける位置情報を言い表すための1手段あたりRFC1876
This document defines a methodology for applying this technology which is IPv4 dependent. The specification itself has no IPv4 dependencies.
このドキュメントは、IPv4扶養家族であるこの技術を適用するために方法論を定義します。 仕様自体には、IPv4の依存が全くありません。
6.19. RFC 1888 OSI NSAPs and IPv6
6.19. RFC1888OSI NSAPsとIPv6
This is an IPv6 related document and is not discussed in this document.
これについて、IPv6の関連するドキュメントであり、本書では議論しません。
6.20. RFC 2009 GPS-Based Addressing and Routing
6.20. RFC2009のGPSベースのアドレシングとルート設定
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.
確かに、それがさらに小さいGPSアドレス可能単位アドレスを提供するためにスペースを扱う際にIP(IP v6)の将来のバージョンは十分な数のビットを持つでしょう。 しかしながら、この提案では、私たちはIP(IP v4)の最新版を思います、そして、アドレシングスペースをそれより経済的に管理するのを確実にします。 私たちは、最も小さいGPSアドレス可能単位をGPS-正方形と呼ぶつもりです。
This specification does not seem to have real IPv4 dependencies.
この仕様は本当のIPv4の依存を持っているように思えません。
6.21. RFC 2143 Encapsulating IP with the SCSI
6.21. SCSIと共にIPをカプセル化するRFC2143
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と非互換です。
Mickles & Nesser II Informational [Page 39] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[39ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
6.22. RFC 2345 Domain Names and Company Name Retrieval
6.22. RFC2345ドメイン名と会社名検索
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.23. RFC 2443 A Distributed MARS Service Using SCSP
6.23. SCSPを使用する分配された火星サービスあたりRFC2443
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ネットワークにおける使用のためにデフォルト値を与えますが、広げることができるように設計されているので、それはIPv6と共に適切なIANA定義で働くでしょう。
6.24. RFC 2471 IPv6 Testing Address Allocation
6.24. RFC2471IPv6テストアドレス配分
This is an IPv6 related document and is not discussed in this document.
これについて、IPv6の関連するドキュメントであり、本書では議論しません。
6.25. RFC 2520 NHRP with Mobile NHCs
6.25. モバイルNHCsとRFC2520NHRP
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
6.26. RFC 2521 ICMP Security Failures Messages
6.26. RFC2521ICMPセキュリティ失敗メッセージ
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.27. RFC 2540 Detached Domain Name System (DNS) Information
6.27. RFC2540はドメインネームシステム(DNS)情報を取り外しました。
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.28. RFC 2823 PPP over Simple Data Link (SDL) using SONET/SDH with
ATM-like framing
6.28. ATMのような縁どりがあるSonet/SDHを使用するSimple Data Link(SDL)の上のRFC2823PPP
There are no IPv4 dependencies in this specification.
この仕様に基づくIPv4の依存が全くありません。
6.29. RFC 3123 A DNS RR Type for Lists of Address Prefixes
6.29. 1DNS RRあたりRFC3123はアドレス接頭語に関する繰返し要素の並びをタイプします。
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
6.30. RFC 3168 The Addition of Explicit Congestion Notification (ECN)
to IP
6.30. IPへの明白な混雑通知(電子証券取引ネットワーク)のRFC3168追加
This specification is both IPv4 and IPv6 aware and needs no changes.
この仕様は、IPv4とIPv6ともに意識していて、変化を全く必要としません。
6.31. RFC 3180 GLOP Addressing in 233/8
6.31. 233/8におけるRFC3180GLOPアドレシング
This document is specific to IPv4 multicast addressing.
このドキュメントはIPv4マルチキャストアドレシングに特定です。
Mickles & Nesser II Informational [Page 40] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[40ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
7. Summary of the Results
7. 結果の概要
In the initial survey of RFCs 52 positives were identified out of a total of 186, broken down as follows:
RFCs52の初期の調査では、正数は合計以下の通り破壊された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%
規格: 24%か70.83%のうちの17は規格を作成します: 20%か30.00%のうちの6は規格を提案しました: 111のうちの22か19.91%の実験的なRFCs: 7 31%か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.
多く特定されたものでは、彼らが時代遅れの、そして、未使用のプロトコルを記録するので、動作を全く必要としないでください、他のものは適切なワーキンググループによって活発にアップデートされているドキュメントプロトコルですが。 さらに、それらをアップデートしないなら、アップデートするべきですが、どんな操作上の影響も引き起こさない規格の多くのインスタンスがあります。
7.1. Standards
7.1. 規格
7.1.1. RFC 791 Internet Protocol
7.1.1. RFC791インターネットプロトコル
RFC 791 has been updated in the definition of IPv6 in RFC 2460.
RFC2460とのIPv6の定義でRFC791をアップデートしました。
7.1.2. RFC 792 Internet Control Message Protocol
7.1.2. RFC792インターネット・コントロール・メッセージ・プロトコル
RFC 792 has been updated in the definition of ICMPv6 in RFC 2463.
RFC2463とのICMPv6の定義でRFC792をアップデートしました。
7.1.3. RFC 891 DCN Networks
7.1.3. RFC891DCNネットワーク
DCN has long since been ceased to be used, so this specification is no longer relevant.
DCNが以来使用されるために長い間やめられているので、この仕様はもう関連していません。
7.1.4. RFC 894 IP over Ethernet
7.1.4. イーサネットの上のRFC894IP
This problem has been fixed by RFC 2464, A Method for the Transmission of IPv6 Packets over Ethernet Networks.
この問題はRFC2464、イーサネットNetworksの上のIPv6 PacketsのTransmissionのためのA Methodによって修正されました。
7.1.5. RFC 895 IP over experimental Ethernets
7.1.5. 実験的なEthernetsの上のRFC895IP
It is believed that experimental Ethernet networks are not being used anymore, so the specification is no longer relevant.
仕様がもう関連していなくて、実験イーサネットネットワークがそれ以上使用される予定でないと信じられています。
7.1.6. RFC 922 Broadcasting Internet Datagrams in the Presence of
Subnets
7.1.6. サブネットがあるときRFC922放送インターネットデータグラム
Broadcasting is not used in IPv6, but similar functionality has been included in RFC 3513, IPv6 Addressing Architecture.
IPv6 Addressing Architecture、放送はIPv6で使用されませんが、同様の機能性はRFC3513に含まれています。
Mickles & Nesser II Informational [Page 41] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[41ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
7.1.7. RFC 950 Internet Standard Subnetting Procedure
7.1.7. RFC950のインターネットの標準のサブネッティング手順
Broadcasting is not used in IPv6, but similar functionality has been included in RFC 3513, IPv6 Addressing Architecture.
IPv6 Addressing Architecture、放送はIPv6で使用されませんが、同様の機能性はRFC3513に含まれています。
7.1.8. RFC 1034 Domain Names: Concepts and Facilities
7.1.8. RFC1034ドメイン名: 概念と施設
The problems have been fixed by defining new resource records for IPv6 addresses.
IPv6アドレスのための新しいリソース記録を定義することによって、問題を修正してあります。
7.1.9. RFC 1035 Domain Names: Implementation and Specification
7.1.9. RFC1035ドメイン名: 実装と仕様
The problems have been fixed by defining new resource records for IPv6 addresses.
IPv6アドレスのための新しいリソース記録を定義することによって、問題を修正してあります。
7.1.10. RFC 1042 IP over IEEE 802
7.1.10. IEEE802の上のRFC1042IP
This problem has been fixed by RFC 2470, Transmission of IPv6 Packets over Token Ring Networks.
この問題はRFC2470、Token Ring Networksの上のIPv6 PacketsのTransmissionによって修正されました。
7.1.11. RFC 1044 IP over HyperChannel
7.1.11. HyperChannelの上のRFC1044IP
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
7.1.12. RFC 1088 IP over NetBIOS
7.1.12. NetBIOSの上のRFC1088IP
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
7.1.13. RFC 1112 Host Extensions for IP Multicast
7.1.13. IPマルチキャストのためのRFC1112ホスト拡張子
The IPv4-specific parts of RFC 1112 have been updated in RFC 2710, Multicast Listener Discovery for IPv6.
RFC2710、IPv6のためのMulticast ListenerディスカバリーでRFC1112のIPv4特有の部分をアップデートしました。
7.1.14. RFC 1122 Requirements for Internet Hosts
7.1.14. インターネットホストのためのRFC1122要件
RFC 1122 is essentially a requirements document for IPv4 hosts. Similar work is in progress [2].
RFC1122は本質的にはIPv4ホストへの要件ドキュメントです。 同様の仕事は進行中の[2]です。
7.1.15. RFC 1201 IP over ARCNET
7.1.15. ARCNETの上のRFC1201IP
This problem has been fixed by RFC 2497, A Method for the Transmission of IPv6 Packets over ARCnet Networks.
この問題はRFC2497、ARCnet Networksの上のIPv6 PacketsのTransmissionのためのA Methodによって修正されました。
Mickles & Nesser II Informational [Page 42] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[42ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
7.1.16. RFC 1209 IP over SMDS
7.1.16. SMDSの上のRFC1209IP
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
7.1.17. RFC 1390 Transmission of IP and ARP over FDDI Networks
7.1.17. FDDIネットワークの上のIPとARPのRFC1390トランスミッション
This problem has been fixed by RFC 2467, Transmission of IPv6 Packets over FDDI Networks.
この問題はRFC2467、FDDI Networksの上のIPv6 PacketsのTransmissionによって修正されました。
7.2. Draft Standards
7.2. 草稿規格
7.2.1. RFC 951 Bootstrap Protocol (BOOTP)
7.2.1. RFC951はプロトコルを独力で進みます。(BOOTP)
This problem has been fixed by RFC 2462, IPv6 Stateless Address Autoconfiguration, and RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
この問題はRFC2462、IPv6 Stateless Address Autoconfiguration、およびRFC3315(IPv6(DHCPv6)のためのDynamic Host Configuration Protocol)によって修正されました。
7.2.2. RFC 1191 Path MTU Discovery
7.2.2. RFC1191経路MTU発見
This problem has been fixed in RFC 1981, Path MTU Discovery for IP version 6.
RFC1981、IPバージョン6のためのPath MTUディスカバリーでこの問題を修正してあります。
7.2.3. RFC 1356 Multiprotocol Interconnect on X.25 and ISDN
7.2.3. RFC1356MultiprotocolはX.25とISDNで内部連絡します。
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がRFC2427、Frame Relayの上のMultiprotocol Interconnectで既に定義されたことに注意してください。
7.2.4. RFC 1990 The PPP Multilink Protocol (MP)
7.2.4. RFC1990pppマルチリンクプロトコル(MP)
A new class identifier ("6") for IPv6 packets has been registered
with the IANA by the original author, fixing this problem.
識別子を分類してください。A新しい、(「6インチ) IPv6に関して、パケットは原作者によってIANAに登録されました、この問題を修正して」。
7.2.5. RFC 2067 IP over HIPPI
7.2.5. HIPPIの上のRFC2067IP
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
7.2.6. RFC 2131 DHCP
7.2.6. RFC2131DHCP
This problem has been fixed in RFC 3315, Dynamic Host Configuration Protocol for IPv6 (DHCPv6).
RFC3315、IPv6のためのDynamic Host Configuration Protocol(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 Optionsのどんなさらなる分析もこのメモから省略されました。
Mickles & Nesser II Informational [Page 43] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[43ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
7.3. Proposed Standards
7.3. 提案された標準
7.3.1. RFC 1234 Tunneling IPX over IP
7.3.1. IPの上でIPXにトンネルを堀るRFC1234
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のトンネリングプロトコルの使用で同様の効果を達成できます。 アップデートされたドキュメントが必要であるかどうかが、不明瞭です。
7.3.2. RFC 1256 ICMP Router Discovery
7.3.2. RFC1256ICMPルータ発見
This problem has been resolved in RFC 2461, Neighbor Discovery for IP Version 6 (IPv6).
この問題はRFC2461、IPバージョン6(IPv6)のためのNeighborディスカバリーで解決されました。
7.3.3. RFC 1277 Encoding Net Addresses to Support Operation Over Non
OSI Lower Layers
7.3.3. 非OSIの低級層の上の操作をサポートするためにネットのアドレスをコード化するRFC1277
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.
アップデートされたドキュメントは全くこの仕様のために存在していません。 必要なら、問題は新しいコード化体系の作成によって解決されるかもしれません。 アップデートが必要であるかどうかが、不明瞭です。
7.3.4. RFC 1332 PPP Internet Protocol Control Protocol (IPCP)
7.3.4. RFC1332pppインターネットプロトコル制御プロトコル(IPCP)
This problem has been resolved in RFC 2472, IP Version 6 over PPP.
この問題はRFC2472、PPPの上のIPバージョン6で解決されました。
7.3.5. RFC 1469 IP Multicast over Token Ring
7.3.5. トークンリングの上のRFC1469IPマルチキャスト
The functionality of this specification has been essentially covered in RFC 2470, Transmission of IPv6 Packets over Token Ring Networks.
RFC2470、Token Ring Networksの上のIPv6 PacketsのTransmissionで本質的にはこの仕様の機能性をカバーしています。
7.3.6. RFC 2003 IP Encapsulation within IP
7.3.6. IPの中のRFC2003IPカプセル化
This problem has been fixed by defining different IP-in-IP encapsulation, for example, RFC 2473, Generic Packet Tunneling in IPv6 Specification.
IPv6 Specificationで異なったIPにおけるIPカプセル化、RFC2473、例えばGeneric Packet Tunnelingを定義することによって、この問題を修正してあります。
7.3.7. RFC 2004 Minimal Encapsulation within IP
7.3.7. IPの中のRFC2004の最小量のカプセル化
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
7.3.8. RFC 2022 Support for Multicast over UNI 3.0/3.1 based ATM
Networks
7.3.8. UNI3.0/3.1の上のMulticastのためのRFC2022SupportはATM Networksを基礎づけました。
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
Mickles & Nesser II Informational [Page 44] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[44ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
7.3.9. RFC 2113 IP Router Alert Option
7.3.9. RFC2113IPルータ警戒オプション
This problem has been fixed in RFC 2711, IPv6 Router Alert Option.
IPv6 Router Alert Option、RFC2711でこの問題を修正してあります。
7.3.10. RFC 2165 SLP
7.3.10. RFC2165SLP
The problems have been addressed in RFC 3111, Service Location Protocol Modifications for IPv6.
問題はRFC3111、IPv6のためのService LocationプロトコルModificationsで扱われました。
7.3.11. RFC 2225 Classical IP & ARP over ATM
7.3.11. 気圧でのRFC2225の古典的なIPとARP
The problems have been resolved in RFC 2492, IPv6 over ATM Networks.
問題はRFC2492、ATM Networksの上のIPv6で解決されました。
7.3.12. RFC 2226 IP Broadcast over ATM
7.3.12. 気圧でのRFC2226IP放送
The problems have been resolved in RFC 2492, IPv6 over ATM Networks.
問題はRFC2492、ATM Networksの上のIPv6で解決されました。
7.3.13. RFC 2371 Transaction IPv3
7.3.13. RFC2371トランザクションIPv3
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
7.3.14. RFC 2625 IP and ARP over Fibre Channel
7.3.14. 繊維チャンネルの上のRFC2625IPとARP
There is work in progress to fix these problems
これらの問題を修正するために、処理中の作業があります。
7.3.15. RFC 2672 Non-Terminal DNS Redirection
7.3.15. RFC2672非端末DNSリダイレクション
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
7.3.16. RFC 2673 Binary Labels in DNS
7.3.16. DNSのRFC2673の2進のラベル
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
7.3.17. IP over Vertical Blanking Interval of a TV Signal (RFC 2728)
7.3.17. テレビの信号の垂直な空白間隔の間のIP(RFC2728)
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
7.3.18. RFC 2734 IPv4 over IEEE 1394
7.3.18. IEEE1394の上のRFC2734IPv4
This problem has been fixed by RFC 3146, Transmission of IPv6 Packets Over IEEE 1394 Networks.
この問題はRFC3146、IPv6 Packets Over IEEE1394NetworksのTransmissionによって修正されました。
Mickles & Nesser II Informational [Page 45] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[45ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
7.3.19. RFC 2834 ARP & IP Broadcasts Over HIPPI 800
7.3.19. HIPPI800の上のRFC2834ARPとIP放送
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
7.3.20. RFC 2835 ARP & IP Broadcasts Over HIPPI 6400
7.3.20. HIPPI6400の上のRFC2835ARPとIP放送
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
7.3.21. RFC 3344 Mobility Support for IPv4
7.3.21. IPv4のRFC3344移動性サポート
The problems have been resolved by RFC 3775 and RFC 3776 [3, 4].
問題はRFC3775とRFC3776[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.
RFC2002における最初のモバイルIPv4仕様以来、それへの多くの拡大が指定されています。 これらがすべて、MIPv4によるとき、それらはこのメモにおけるさらなる分析から省略されました。
7.3.22. RFC 3376 Internet Group Management Protocol, Version 3
7.3.22. RFC3376インターネットグループ管理プロトコル、バージョン3
This problem is being fixed by MLDv2 specification [5].
この問題はMLDv2仕様[5]で修正されています。
7.4. Experimental RFCs
7.4. 実験的なRFCs
7.4.1. RFC 1307 Dynamically Switched Link Control Protocol
7.4.1. RFC1307はダイナミックにリンク制御プロトコルを切り換えました。
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
7.4.2. RFC 1393 Traceroute using an IP Option
7.4.2. IPオプションを使用するRFC1393トレースルート
This specification relies on the use of an IPv4 option. No replacement document exists, and it is unclear whether one is needed.
この仕様はIPv4オプションの使用に依存します。 差し替え書類は全く存在していません、そして、1が必要であるかどうかが、不明瞭です。
7.4.3. RFC 1735 NBMA Address Resolution Protocol (NARP)
7.4.3. RFC1735NBMAアドレス解決プロトコル(NARP)
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).
この機能性はRFC2491とNonの上のIPv6放送Multiple Access(NBMA)ネットワークとRFC2332(NBMA Next Hop Resolutionプロトコル(NHRP))で定義されました。
7.4.4. RFC 1788 ICMP Domain Name Messages
7.4.4. RFC1788ICMPドメイン名メッセージ
No updated document exists for this specification. However, DNS Dynamic Updates should provide similar functionality, so an update does not seem necessary.
アップデートされたドキュメントは全くこの仕様のために存在していません。 しかしながら、DNS Dynamic Updatesが同様の機能性を提供するはずであるので、アップデートは必要に見えません。
Mickles & Nesser II Informational [Page 46] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[46ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
7.4.5. RFC 1868 ARP Extension - UNARP
7.4.5. RFC1868ARP拡張子--UNARP
This mechanism defined a mechanism to purge ARP caches on a link. That functionality already exists in RFC 2461, Neighbor Discovery for IPv6.
このメカニズムは、リンクの上にARPキャッシュを掃除するためにメカニズムを定義しました。 その機能性はRFC2461、IPv6のためのNeighborディスカバリーに既に存在しています。
7.4.6. RFC 2143 IP Over SCSI
7.4.6. SCSIの上のRFC2143IP
No updated document exists for this specification. It is unclear whether one is needed.
アップデートされたドキュメントは全くこの仕様のために存在していません。 1が必要であるかどうかが、不明瞭です。
7.4.7. RFC 3180 GLOP Addressing in 233/8
7.4.7. 233/8におけるRFC3180GLOPアドレシング
Similar functionality is provided by RFC 3306, Unicast-Prefix-based IPv6 Multicast Addresses, and no action is necessary.
同様の機能性はRFC3306、Unicast接頭語ベースのIPv6 Multicast Addressesによって提供されます、そして、どんな動作も必要ではありません。
8. Security Considerations
8. セキュリティ問題
This memo examines the IPv6-readiness of specifications; this does not have security considerations in itself.
このメモは仕様のIPv6-準備を調べます。 これには、本来、セキュリティ問題がありません。
9. Acknowledgements
9. 承認
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は、ドキュメントの最新版を編集するのを手伝いました。
10. References
10. 参照
10.1. Normative References
10.1. 引用規格
[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.ベルイストローム、エディタ、「IPv4の調査への紹介は現在配布しているIETFで規格を扱います」、RFC3789、2004年6月。
Mickles & Nesser II Informational [Page 47] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[47ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
10.2 Informative References
10.2 有益な参照
[2] Loughney, J., Ed., "IPv6 Node Requirements", Work in Progress,
January 2004.
[2]Loughney、J.、エド、1月2004、「IPv6ノード要件」は進行中で働いています。
[3] Johnson, D., Perkins, C. and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.
[3] ジョンソンとD.とパーキンスとC.とJ.Arkko、「IPv6"、RFC3775、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を使用します」、RFC3776、2004年6月。
[5] Vida, R. and L. Costa, Eds., "Multicast Listener Discovery
Version 2 (MLDv2) for IPv6", RFC 3810, June 2004.
[5] ビーダとR.とL.コスタ、Eds、「IPv6"、RFC3810、2004年6月のためのマルチキャストリスナー発見バージョン2(MLDv2)。」
11. Authors' Addresses
11. 作者のアドレス
Cleveland Mickles, Editor Reston, VA 20191 USA
クリーブランドMickles、エディタレストン、ヴァージニア20191米国
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第100Ave Ne、#5202カークランド、ワシントン98034米国
EMail: phil@nesser.com
メール: phil@nesser.com
Mickles & Nesser II Informational [Page 48] RFC 3790 IPv4 Addresses in the IETF Internet Area June 2004
Mickles&NesserのIIの情報[48ページ]のRFC3790IPv4は、2004年6月にIETFでインターネットが領域であると扱います。
12. Full Copyright Statement
12. 完全な著作権宣言文
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.
Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。
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.
このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。
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はどんなIntellectual Property Rightsの正当性か範囲、実装に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するどんな独立している取り組みも作りました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。
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倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。
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機能のための基金は現在、インターネット協会によって提供されます。
Mickles & Nesser II Informational [Page 49]
Mickles&Nesser II情報です。[49ページ]
一覧
スポンサーリンク
