Skip to content

Latest commit

 

History

History
160 lines (134 loc) · 11.9 KB

02_ipv6_nibble.md

File metadata and controls

160 lines (134 loc) · 11.9 KB

IPv6 ポイントつまみ食い

0. 目的

  • IPv4 との違いをおさえる
  • AWS で IPv6 を使うときの制約や独自のルールをおさえる

1. IPv6 アドレス

アドレスの構成

  • 全 128 ビット
    • 16 ビットごとに「:」で区切る
    • 4 ビットごとに十六進表記
    • 一部の例外を除いて、ユニキャスト／エニーキャストアドレスの前半 64 ビットをサブネットプレフィックス、後半 64 ビットをインターフェース識別子（IID）と呼ぶ
      • IPv4 の呼び方と異なるのは（当初から）IPv6 アドレスはホストに対して割り振るのではなくホストのインターフェースに対して割り振る思想で設計されたため

アドレスの表記

  • 長いので、省略形の表記ルールがある
    • RFC 4291
      • 16 ビット区切りのフィールドの先頭で連続する「0」は省略可
        • 例 : 2001:0db8:11aa:22bb:33cc:44ee:55ff:0006 → 2001:db8:11aa:22bb:33cc:44ee:55ff:6
      • 複数の 16 ビットフィールドで「0」が連続する場合は「::」で省略可
        • ただし「::」で省略できるのは 1 箇所のみ
        • 例 : 2001:0db8:0000:0000:0000:0002:0000:0001 → 2001:db8::2:0:1（または 2001:db8:0:0:0:2::1）
      • IPv4 アドレスが埋め込まれた特殊な IPv6 アドレスは、上位 6 個の 16 ビットフィールドを「:」区切り十六進表記、下位 32 ビットを「.」区切り十進表記
        • 例 : 0:0:0:0:FFFF:129.144.52.38
        • この場合も ::FFFF:129.144.52.38 という圧縮表記が可能
    • RFC 5952 : 一意な表記にする方法
      • RFC 4291 では同じアドレスを表記するのに複数の表記方法が可能になりうるため、一意な表記にする方法が RFC 5952 で規定されている
        • 「::」短縮時には可能な限り短く表記する
          • 例 : 2001:db8::0:2:1 のような表記をしない
        • 16 ビットフィールドの「0」が 1 つだけの場合は「::」を使わない
          • 例 : 2001:db8:0:1:1:1:1:1 を 2001:db8::1:1:1:1:1 と表記しない
        • 最も短縮できる箇所で「::」を使う
          • RFC 4291 で示した例では 2001:db8::2:0:1 のほうを採用する
        • 同じ長さの「16 ビットの 0」がある場合は、最初の箇所で「::」を使う
        • アルファベットは lower case で
        • IPv4 アドレスが埋め込まれた特殊な IPv6 アドレスは、先頭部分の「0」の連続を「::」で短縮する
          • 例 : RFC 4291 で例示したアドレスは ::ffff:192.0.2.1
        • ポート番号との表記で区切りに「:」を使うときは IPv6 アドレス部分を「[]」で括る（推奨）
          • 例 : [2001:db8::1]:80
          • RFC 3986 で示された表記

アドレスの種類

  • リンクローカルユニキャストアドレス : 直接やり取り可能な範囲（リンクローカル）との間で通信を行うアドレス
    • fe80::/10
    • AWS の VPC では IPv4 の VPC と同様 IMDS や DNS のリゾルバなどに使用されている
  • マルチキャストアドレス : 単一のホストではなく複数のホストに同時に送信するためのアドレス
    • ff00::/8
    • IPv6 では IPv4 のブロードキャストアドレスの代わりに使われる
      • ルータは ff02::1
  • ループバックアドレス
    • ::1/128
    • 1 個だけになった
  • 未定義アドレス
    • ::/128
    • アドレスが割り当てられていない状態
  • グローバルユニキャストアドレス : インターネット通信用アドレス（パブリックアドレス）
    • 上記以外のアドレス範囲
      • 実際には組織に割り当てずに特定目的用に予約されているアドレス範囲もある
  • ユニークローカルユニキャストアドレス（ULA）: 組織内のみで通信するためのアドレス（ルータ越え可能）
    • fc00::/7
      • うち、fc00::/8 は未定義（将来のために予約）なので fd00::/8 を使う
        • 8 ～ 47 ビット目はグローバル ID と呼び、ランダムに割り当てる
        • 48 ～ 63 ビット目はサブネット ID
    • グローバルユニキャストアドレスの一部だが、インターネットへのルーティングを前提としていない
    • インターネットへの接続を行う場合は NAT / NAPT でグローバルユニキャストアドレスに変換するのではなく、別のグローバルユニキャストアドレスを同一ホストに割り当ててそちらでインターネットへ通信する
    • AWS の VPC では使えない

アドレスの割り当て方法

  • リンクローカルユニキャストアドレス
    • MAC アドレスなどをもとに自動生成される
    • マルチキャストの ICMPv6 によって近隣のルータの MAC アドレスを確認するとともに、IPv6 アドレスの衝突がないかチェックする（DAD : Duplicate Address Detection）
      • 詳細は省略
  • グローバルユニキャストアドレス
    • 固定アドレス割り当て : ホスト側で固定的に指定
      • IPv4 と同様だが、基本的にはサーバー用途でなければ固定割り当ては使われない
    • 動的な生成 : 複数の方法があるうちの代表的なものを挙げる
      • SLAAC
        • ルータからサブネットプレフィックスと（デフォルト）ゲートウェイの情報を受け取り、MAC アドレスから Modified EUI-64 形式（詳細は省略）の IID を生成
        • RDNSS（Recursive DNS Server）対応ならルータから DNS リゾルバ情報も受け取る
        • IPv6 アドレスを MAC アドレスから固定的に生成するのはプライバシーの問題を生じる恐れがあるので、Temporary IPv6 アドレスなど別の方法も提示されている
      • ステートレス DHCPv6
        • DNS リゾルバ情報のみ DHCPv6 サーバーから受け取り、IPv6 アドレスとゲートウェイ情報は SLAAC で生成
      • ステートフル DHCPv6
        • すべてを DHCPv6 サーバーから受け取る
          • 以前はゲートウェイ情報だけはルータから受け取る必要があった
  • ルータとのやり取りにはリンクローカルユニキャストアドレス（送信元）とマルチキャストアドレス（宛先）が使われる
    • ICMPv6 RS（Router Solicitation）メッセージ・RA（Router Advertisement）メッセージなど
  • （省略できるケースを除いて）DAD で IPv6 アドレスの衝突チェックを行う
    • ICMPv6 NS（Neighbor Solicitation）メッセージ・NA（Neighbor Advertisement）メッセージなど
  • アドレスとサブネット以外に「スコープ」「ゾーン」という概念がある
    • 小さいスコープに対応するゾーンがより大きなスコープに対応する複数のゾーンにまたがることはない、など
    • 表記はアドレスの後ろに「%」とゾーン ID を続ける形
    • マルチキャスト以外ではあまり気にする必要が無いので詳細は省略

2. ホスト間通信の方法

  • 基本的には IPv4 と同じ流れ（なので個別説明は省略）だが、ARP の代わりに ICMPv6 による近隣探索プロトコルで MAC アドレス解決を行う点が異なる

IPv6 フラグメント

  • エンドのホスト（ノード）同士がフラグメントの扱いを決める
    • 経路の途中でルータが勝手にパケットを分割することはできない
    • 当然 DF ビットもない
  • Path MTU Discovery については、DF ビットが無いため経路中のルータの MTU が足りない場合は常に送り直しを要求することになる
    • ICMPv6 Packet Too Big メッセージを送る
      • 送信可能なパケット長をこのメッセージで知ることが可能
    • ICMPv6 をいたずらに遮断すると通信できないのは IPv4 と同じ

IPv4 アドレス空間にアクセスする方法

  • IPv6 しか持たないホストから IPv4 しか持たない Web サイトなどにアクセスする場合、DNS64（後述）と NAT64 を組み合わせて IPv6 → IPv4 アドレス変換する
  • DNS を使わず IPv4 アドレスを直接指定してアクセスしたい場合（主に社内サーバーへのアクセスなど）は端末自身でのアドレス合成が必要になる
    • その場合のプレフィックス提供機能として Pref64::/n Discovery がある

IPv4・IPv6 共存技術

  • インターネット接続のゲートウェイをデュアルスタック化して IPv4・IPv6 の両方のアドレスを割り当てることで、IPv4・IPv6 のいずれのホスト（クライアント）からも接続可能にできる
    • ゲートウェイの内側は IPv4・IPv6 の片方だけ対応したネットワークでも OK
      • 既存が IPv4 で構成されている場合は、内側は IPv4 で構成したままゲートウェイをデュアルスタック化する
    • ただし、Web アプリケーションでは X-Forwarded-For ヘッダーなどに IPv4・IPv6 のどちらのアドレスが含まれていても正しく処理できるようにしておく必要がある
      • アドレスを比較するロジックが存在する場合は、たとえば文字列ではなくバイナリ形式にする、lower case で省略のない形の統一フォーマットに正規化して比較するなどの配慮が必要
        • Java ならInet6Addressを使う etc.
    • AWS の場合は ALB / NLB がデュアルスタック対応
  • その他トンネル技術については省略

3. DNS

IPv6 専用レコード

  • AAAA（Quad A）レコード : 正引き用レコード
    • 役割は IPv4 における A レコードと同じ
  • 逆引きなど、ほかのレコードは IPv4 と同じ

DNS64（NAT64 と併用）

  • 前述のとおり、NAT64 と組み合わせて使う
  • 正引き時、A レコードしか取得できなかった（≒問い合わせた FQDN が IPv4 にしか対応していない）ときは、応答としてプレフィックス（64:ff9b::/96）と A レコードで示された IPv4 アドレス（下位 32 ビット）を合成した IPv6 アドレスを返す

4. AWS の IPv6 VPC における制約・特殊機能など

  • 複数のネットワークやグローバル（パブリック）アドレスを重ねて 1 つの VPC サブネットに割り当てることはできない
    • VPC サブネット内のルータは（論理的には）1 台だけ
    • ULA を使うことはできない
  • 通常のインターネットゲートウェイを使うと、NACL・セキュリティグループの設定次第では IPv6 アドレスを持つホスト宛てに外部からアクセスが可能だが、Egress-Only インターネットゲートウェイを使うことで外部からのアクセスを禁止することが可能
    • IPv4 通信における NAT ゲートウェイと同じような状態に
      • VPC 内→インターネット方向の通信は許可
      • インターネット→ VPC 内方向の通信は（応答以外）遮断
      • ただしアドレス変換は行われない