前書き
前世紀の半ば、実存主義の哲学者で作家のアルベール・カミュは有名に次のように書いています。現代人にとっては一文で十分です。彼は…新聞を読んでいます。」[エド。注：これらの楕円は、文学業界で時々言われているように、「重要な仕事をしている」のですが、引用の残りの部分は、より勇敢な読者が発見できるようにしておきます。]
2017年の私たちに関しては、枯れ木の紙が急速にドードーの道を進んでいます。そのため、ブログやオンライン記事、特に誰もが好きまたは嫌いなサブジャンルであるリスティクルに、現代の注目の対象を変更する必要があります。
あなたの好みに応じて、私たちはIPv6 CoEブログにこれ以上のリストを含めないで、慈悲深いか怠慢のどちらかでした。ですから、IPv6 RFCのトップ10（およびそれらを読む必要がある理由）を探求するときは、喜ぶか、我慢してください。
ただし、リストを開始する前に、RFCとは何か（およびRFCの場所）について全員が同じページにいることを確認したいと思います。それがあなたにとって古い帽子であるならば、先にスキップするのを遠慮しなくしてください。
RFCとは何ですか？
データネットワークをかなりの時間ラングリングしている場合は、RFCとは何か、およびRFCがそのネットワークで果たす役割についてはすでによく知っているはずです。
しかし、知らない（または思い出させる必要がある）人にとって、RFC（「Requestfor Comment」の略）は、コンピュータネットワークの比較的特定の側面を扱ったドキュメントです。（初期のRFCは、初期のインターネットプロトコルのパイオニア間で共有された詳細なメモのようなもので、時間の経過とともにより正式なドキュメントになりました。）特定の側面は、インターネットプロトコルの元のRFC（バージョン4）、RFC791「インターネット」のようなプロトコルである可能性があります。または、1987年のドメインネームシステムのRFC（1034「ドメイン名-概念と機能」および1035「ドメイン名-実装と仕様」）。1981年と1987年？
ネットワーキングプロトコル（およびおそらくIPv6コミュニティの私たちの心に近いもの）をカバーする最近のRFCの例、今年の6月からのRFC8156「DHCPv6フェイルオーバープロトコル」。
RFCがカバーする可能性のあるネットワーキングのもう1つの側面は、ネットワーク操作です。たとえば、DNS操作は複数のRFCに含まれていますが、RFC 1033（「ドメイン管理者操作ガイド」）は初期のものです。
注意深い読者は、DNS操作RFCがプロトコル定義RFC 1034および1035よりもシーケンス番号が早いことに気付いたかもしれませんが、それらはすべて同時にリリースされました。
ネットワークアーキテクチャもRFCで詳細に説明されている主題です。たとえば、MPLSの展開者は、RFC7625「強化パイプを使用したIP / MPLSネットワークのアーキテクチャ」に精通している場合があります。
間違いなく、さまざまなタイプの中で、プロトコル定義RFCが最も読まれ、レビューされ、参照されています。たとえば、ベンダーは、ソフトウェアとハードウェアを設計し、それらのプロトコルを製品に展開するために、提供する定義に大きく依存しています。したがって、プロトコル仕様の精度の欠如は、バグやベンダーの相互運用性の欠如につながる可能性があります。
インターネットまでのすべてのコンピュータネットワークが、RFCによって提供される技術的DNAにその特性をさかのぼることができると言っても過言ではありません。
それで、彼らはどこから来たのですか？
RFCは、インターネット技術特別調査委員会の参加者によって共同で作成され、IETFの参加は、何か貢献できるものがあれば、誰でも、どこでも参加できます。IETF RFCプロセスには、コンピューターサイエンティスト、研究者、ソフトウェアエンジニア、ネットワークオペレーターとアーキテクト（サービスプロバイダーとエンタープライズの両方）、ベンダー製品マネージャー、大学院生、およびその他の多くの役割（世界中の男性と女性）が参加しています。実際、IETFは、この種のテクノ民主主義の理想をその文書「IETFのタオ：インターネットエンジニアリングタスクフォースの初心者向けガイド」に祀っています 。：「私たちは王、大統領、投票を拒否します。ラフコンセンサスと実行中のコードを信じています。」私は個人的に、インターネットのように大規模で革命的なものが、主にそのようなオープンで自由なコラボレーションの産物であることを非常に刺激しています。
上記のリンクには、RFC、およびBPC（つまり、「Best CurrentPractices」）やID（つまり、インターネットドラフト、多くの場合RFCの前身）などの関連するIETFドキュメントに関する詳細情報があります。また、1つ以上のワーキンググループにまだ参加していない（または少なくともフォローしている）場合は、それを検討することをお勧めします。「大まかなコンセンサスと実行中のコード」を求めて努力している人々にとって、退屈な瞬間はめったにありません。
しかし、今、私たちのトップIPv6 RFCと、それらを読む必要がある理由について説明します。（このエントリは最初の5つをカバーします。）
最近の（テレビの）偉大なDavid Lettermanの精神で、私は（おそらく）それほど重要ではないIPv6RFCからより重要なRFCへとカウントダウンを試みたかったのです。しかし、リストされているRFCの10のうち少なくとも8つは、「基礎的」と見なされるべきものです。つまり、IPv6がどのように設計され、ほとんどの展開でどのように動作するかを完全に理解するために重要です。したがって、（ほとんどの場合）元のRFCが表示された順序で進みます。
リンクをたどると、RFCの一部に「廃止」または「更新者」を示すフィールドが含まれていることに気付くでしょう。ご想像のとおり、RFCのガイダンスを採用しているベンダーとオープンソースコードが実際の展開と接触すると、技術的な問題が発生します。これらの問題のいくつかは、単に操作可能であるか、ソフトウェアのバグが原因です。他の人は、基礎となるRFCに問題があることを明らかにするかもしれません。たとえば、作成者やレビュー担当者が予測できなかったネットワークテクノロジの進歩により、RFCの更新（つまり、標準を新しいテクノロジドメインに拡張するのに役立つ追加のRFC）が必要になる場合があります。RFCのコンポーネントは、コードとその後の展開で完全に使用されず、元のRFCを廃止する新しいRFCでは省略されることがあります。
トップIPv6RFC
＃1：
RFC 2460：インターネットプロトコル、バージョン6（IPv6）仕様
IPv6が好きか嫌いか（そして嫌いなら、なぜこのブログを読んで自分を拷問しているのですか？）、これはIPv6革命を始めたRFCです 。まあ、技術的には、それはRFC 1883でしたが、これはこれによって廃止されました（上記を参照）。RFC 2460は、IPv6プロトコルの基本設計と結果のパケットをレイアウトした最初のドキュメントです。128ビットアドレス。IPv6パケット、固定（40バイト）ヘッダー、それぞれのさまざまな拡張ヘッダーと形式（認証とセキュリティ拡張を使用してIPv6をより安全にするための当初の取り組みを含む）。レイヤ3QoSのフローラベル。エンドノードへの断片化の制限。等
「更新者」RFCの長いリストは、主に拡張ヘッダーの実装（および実際の展開でのフラグメントの処理）における運用上の課題に関連しています。このRFCで最初に考案されたこれらのヘッダーによって約束された柔軟性と機能は、複数の理由でほとんど実現されていませんが、主な障害は、ルーター、スイッチ、セキュリティアプライアンス、およびミドルボックスによるこれらのヘッダーの安全な処理でした。その結果、たとえば、RFC 5095は、サービス拒否攻撃でのトラフィック増幅に悪用されることを回避するために、タイプ0ルーティングヘッダーを非推奨にします。
[著者のメモ：そして、このブログの最初のドラフトを終えてから文字通り数時間後に、IETFはRFC 8200：インターネットプロトコルバージョン6（IPv6）仕様を公開 し、IPv6を ドラフト標準 からインターネット標準に移行しました 。これは最高レベルの技術を示しています。プロトコルが達成できる成熟度。標準間の違いの詳細については、RFC2026を参照してください 。]
＃2
RFC 4443：インターネットプロトコルバージョン6（IPv6）仕様のインターネット制御メッセージプロトコル（ICMPv6）…
IPv6標準の大部分は、IPv4のゼロからの再設計です。言い換えると、IPv4の限られた供給を克服するために96個のアドレスビットを追加することはIPv6の最も重要な側面でしたが、初期のIETF IPv6の取り組みはそれを超えて、IPv4を強化または改善できる追加の方法に焦点を合わせました。「私はすでにICMPを知っているので、このRFCを読む必要はありません」と自分に言い聞かせたら、もう一度考えてみてください。ICMPv6は、IPv4のICMPとは大きく異なります。違いを理解しなければ、IPv6に深く入り込むことはできません。
この再設計の最も影響力のある部分の1つは、近隣探索（またはND —独自のRFCに表示されるものです。これについては以下で説明します）です。NDは、IPv4 ARP（アドレス解決プロトコル）を完全に再設計したものであり、正しく機能するためにICMPv6に依存しています。NDで使用されるICMPv6メッセージはRFC4443で説明されていませんが、一般的なメッセージ形式やメッセージタイプなど、含まれる仕様については理解しておく価値があります。
特に、新しいパケットが大きすぎるメッセージタイプは、パケットの断片化が中間ネットワークノードによって許可または実行されないことを考えると、IPv6にとって非常に重要です。
＃3
上記のように、近隣探索はIPv4ARPの完全な再設計です。初期のIETFIPv6の取り組みは、レイヤー2からレイヤー3へのマッピングを確立および維持するプロセスをより効率的にすることができる方法に焦点を合わせていました。IPv6での近隣探索は、これらの取り組みの結果です。RFC要約に要約されているように、IPv6「ノード（ホストとルーター）は近隣探索を使用して、接続されたリンク上に存在することがわかっている近隣のリンク層アドレスを決定し、無効になったキャッシュ値をすばやくパージします。また、ホストは近隣探索を使用して、ホストに代わってパケットを転送することをいとわない隣接ルーターを見つけます。最後に、ノードはプロトコルを使用して、到達可能なネイバーと到達できないネイバーをアクティブに追跡し、変更されたリンク層アドレスを検出します。ルーターまたはルーターへのパスに障害が発生した場合、
このRFCは（他の多くの場合と同様に）本当に重要なリファレンスドキュメントです。この場合、NDがどのように動作するか、および上記の機能を提供するためにNDが交換するメッセージについて説明します。RFCをさらに詳しく調べて、各ND機能（アドレス解決、ルーター、プレフィックス、パラメーターの検出、近隣到達不能、重複アドレス検出など）が定義され、動作することを理解することをお勧めします。
＃4
IPv6の設計者が非常に興味を持ったIPv4の再設計の別の側面は、ノードが独自のアドレスを構成する潜在的な機能でした（ローカルまたはグローバルスコープ）。DHCPの発明は、各ノードを直接手動で構成せずにノードをオンラインにする方法を望んでいたネットワークオペレーターによって推進されたIPv4のこの機能の欠如への対応でした。IPv6にはプロトコルレベルでこの機能を含めるべきであるということは、早い段階で首尾よく議論されました。その結果、IPv6ステートレスアドレス自動構成が実現します。
RFCは、近隣探索で定義されているルーター要請とルーターアドバタイズメントを使用したルーターとホストの相互作用、およびインターフェイス識別子とグローバルスコープのアドレスをもたらすプレフィックスを組み合わせたメカニズムを対象としています。RFCで重要な他の領域には、アドレスの有効期間（たとえば、有効および優先）がIPv6でどのように処理され、ノードの迅速な再番号付けが可能になるかが含まれます。
＃5
何度も証明されているように、最近ではグローバルDNSインフラストラクチャの要素に対する攻撃が増加しているため、DNSが適切に機能していないと、インターネットとすべてのコンピュータネットワークがほとんど役に立たなくなります。IPv4 DNSの既存の構造は、128ビットアドレスをサポートするのに十分ではなかったため、DNSを拡張する必要がありました。すべてのIPv6RFCの中で最も短いものの中で、これはドメイン名をIPv6アドレスに転送するためのAAAA（または「クアッドA」）レコードを定義します。また、IPv6アドレスからドメイン名への逆マッピングを処理するためにip6.arpaドメインを定義します。
今回は以上です！記事の2番目の部分を必ず確認してください 。これには、残りの5つの重要なIPv6RFCが含まれます。
https://blogs.infoblox.com/ipv6-coe/the-top-10-ipv6-rfcs-you-should-read-and-why-part-1-of-2/