IPv4アドレスの枯渇[1] がいよいよ目前にせまり、IPv6への移行が急務となっている。これまでに多くの技術課題が克服され、実装の普及も現実的な段階となっている。しかし、その運用については十分に検討されているとはいえない。
 　IPv6はバックボーンネットワークへの導入が進んできており専門家の間では運用ノウハウの蓄積も進んでいる。一般の企業や家庭では、広く利用されているサーバおよび端末の多くでIPv6の利用が可能となっており、デフォルトでIPv6機能がONになっているケースも増えている。そのためネットワーク内で気が付かないうちにIPv6通信が発生していることも多い。しかし、企業や家庭で現在のIPv4と同等以上のセキュリティ、内部ネットワークの独立性／一貫性などをIPv6でどのように確保するかといった具体的な運用ノウハウの蓄積は十分ではない。
 　本稿では、企業や家庭でのIPv6利用を想定して、IPv4で一般化しているNAT/NAPT（Network Address Translation/Network Address Port Translation）との関連をベースに、IETF（Internet Engineering Task Force）での議論を紹介する。インターネットはEnd-to-Endの接続性を確保することを基本原則として設計され、それが飛躍的な発展の基盤となったため、IPv4で導入せざるを得なくなったNATは当初から大きな議論を呼んだ。IPv6ではNATを不要にすることが大きな設計目標のひとつであったため、IPv6でもなおNATが必要であるかどうかは重大な論点になっている。なお本稿では特に断りなくNATと記述する際にはNAT/NAPTの両者を含むものとする。

 　IPv6におけるローカルネットワークの保護はそのセキュリティおよび運用の完全性（Integrity）を含めて2007年に発行されたRFC 4864[2] で基本的な議論がなされており、その後の標準化の議論の基盤として繰り返し参照されている。
 　RFC 4864ではローカルネットワークの保護のために達成すべき項目と方法をIPv4＋NATとの対比で議論しており、IPv6では原則としてNATなしでそれらを達成できると結論付けている。しかし、その後の議論によって特にアドレス変更、マルチホーム対応、さらには設定情報の一元化を現実的に解決するためには依然としてNATも有効であることが指摘され、これまでの「誤解に基づく」セキュリティ上の必要性からIPv6でもNATの利用がなし崩し的に広がることが懸念された。その結果、標準化されない技術が広がることを防ぐという目的も含めてIPv6でのNATであるNAT66[3] が提案されるなどの議論が続いた。
 　2010年７月、IAB（Internet Architecture Board）¹はそれらの議論を踏まえて「End-to-Endの原則」[4] に照らしてNATおよびIPv6の関係を整理しその見解をRFC 5902[5] として発行した。以降では、RFC 4864およびRFC 5902で述べられている広く信じられているが実際にはNATでは解決できないセキュリティ上の課題とその対策、一方でRFC 4864でIPv6ではNATなしで解決できるとされているが現実的にはNATも有効な解決策となりえる課題について概説する。

2.1 NATでは解決できない課題

 　NATは本来IPv4グローバルアドレスを節約するための方法として策定され利用されてきた。しかし、その本来の機能以外に副次的にもたらされる効果が、技術的には不十分であり、かつそれらを利用することによる副作用があるにもかかわらず、NATの導入によって自動的に得られる便利な機能であるかのように認知されてしまっている。特に大きな影響があるのは以下の機能である。

(1)　ネットワーク出入り口でのフィルタリング
(2)　トポロジの隠蔽とプライバシ

(1) ネットワーク出入り口でのフィルタリング

 　NATは内部からの通信の必要性に応じて動的に外部とのアクセスを確保するために、外部から内部への通信に対するステートフルフィルタリング機能を提供しているかのように思われている。しかし、これはアドレスを動的に共有するため、言い換えればアクセスを確保するために行われているものであり、遮断するためのものではない。
 　例えば、ネットワーク境界に設置したNATが特定のホストに対するスタティックNATとして設定されているケースでは、特定のポートと特定の内部ホストが関連付けられているため、フィルタリングはまったくなされていない。また、NAPTの配下に多くのホストがある場合は、ポートへの無差別攻撃であっても多くの内部ホストに影響を与える可能性がある。
 　つまりNATのフィルタとしての動作は、アドレス変換の関係が固定ではなく、かつ事前にわかっていない場合でのみ意味を持ち、運用方法や状況に大きく依存するため「導入すれば自動的に確保される」セキュリティとしてはまったく信頼できない。
 　RFC 4864およびRFC 5902では、上記のような理由によって、このようなフィルタリングのためにNATを利用することは不適切であり、フィルタリングにはそのためにファイアウォールの機能として設計されたステートフルフィルタリングを利用すべきであることを述べている。

(2) トポロジの隠蔽とプライバシ

 　トポロジの隠蔽の目的は、伝統的なセキュリティ管理の第一歩として、ネットワーク外部の者に対して内部ネットワーク上のデバイスの存在およびそれらの構成（設定）を知られることを防ぐことにある。
 　NATを利用していればインターネット上ではNATの配下にあるホストからの通信は、すべてNATから、原則的には同じIPアドレスからの通信に見えるため、観測されるIPアドレスから単純に端末の存在が知られることを防ぐことができる。
 　しかし、古くから指摘されている通り、IP-IDフィールドなどのアドレス以外のパケットヘッダの値が予測可能な方法で選ばれている場合はそれらを関連付けることでNAT配下の特定のホストからの通信であることを判断できる[6] ため、結果としてNAT配下のホスト数の推定が可能であることが知られている。
 　この問題に対してはNAPTを利用し、複数のアドレスをコネクション毎にランダムに割りあてるなどの複雑な構成をとればNAT技術でもさらなる防御が可能であるが、そうすればSIP（Session Initiation Protocol）やSCTP（Stream Control Transmission Protocol）などの複雑なコネクションを利用する通信がNATを通過できなくなる可能性が高まる。さらにOSやそのバージョン、利用されているアプリケーションなどのホストのより詳細な構成を分析するHost finger printingについては上述したようなアドレスのランダム化等のNAT構成の複雑化では防ぐことができない。Host finger printingはホストの要求-応答の対応関係からその構成を推定するため、通信路上でパケットを観測するだけで十分な情報を得られる。動的なアドレス利用、アドレス対応の短い周期での変更などは推定のための情報を得られにくくはするが、本質的な対策にはならない。
 　また、サブネット構成などのトポロジ情報についてもパケットの到着タイミング、遅延の計測、パケットヘッダのHop Limitフィールドの値などから相対的な位置関係が特定可能であり、Host finger printingによって特定されたホストがあれば、そこからさらなる推定が可能となる。
 　IPv6ではこれらの問題に対して、RFC 4941で規定しているpseudo-random privacy address [7] およびRFC 4193で規定しているULA（Unique Local Address）[8] が用意されている。RFC 4941ではSLAAC（Stateless Address Auto Configuration）で自動的に設定されるインターフェースIDにMACアドレスを元にしたEUI-64（Extended Unique Identifier-64）ではなくランダムな数字を用い、それらの有効期間を短くする（デフォルトでは1日）ことでアドレスから特定のホストを特定される危険性を減らし、RFC 4193ではIPv4におけるプライベートアドレスと同様に内部だけで利用できるアドレスを利用することでネットワークアドレスから内部のアドレスを推定される危険性を減らしている。
 　しかし、これらの方法ではNATと同程度の隠蔽は実現できないため、RFC 4864では、グローバルアクセスが必要な内部ノードに対して、実際のトポロジに対するアドレスの他に外部アクセス用の論理アドレスを割り当て、外部接続ルータによってその論理アドレスへのホストルートを管理する方式が提案されている。またそれを自動化し、よりNATに近い形で運用するために経路最適化をしないMobile IPの利用が提案されている。しかしこれらについては、内部で管理する経路が複雑化するため運用のスケーラビリティがすぐに問題になるほか、Mobile IPについては外部への経路通知機能（Binding update）の制御についても検討する必要があり、現状では現実的な運用に耐えうるかどうかの検証が不十分である。
 　RFC 5902では、これらの問題にNATで対応するには上記のように技術的に不十分であるばかりか、End-to-Endの通信を確保するというインターネットの大前提に大きな影響をもたらすことを指摘しているが、一方でIPv6によるソリューションが十分であるかどうかは議論していない。

2.2 NATが有効な解決策となりえる課題

 　一方で、RFC 4864 で指摘されている以下の課題については、NAT66[3]、RFC 5902等で実際にはNATを現実的な解として検討できることが議論されている。

(1)　アドレス変更（Avoiding renumbering）
(2)　マルチホーム対応（Facilitating multi-homing）
(3)　設定情報の統一（Making edge consumer network configurations homogenous）

(1) アドレス変更

 　IPv4はホストが複数のアドレス、特に複数のCIDR（Class-less Inter Domain Routing）アドレスを扱えるようには設計されていなかったため、ISPを変更する場合などはプロバイダから割り当てられているアドレスを一斉に切り替える必要がある。このときNATを利用していればNAT配下のアドレスはその影響をうけないため、アドレス変更のコストは大幅に削減できる。
 　IPv6ではホストが複数の異なるCIDRアドレスを同時に利用できるように設計されており、DHCP-PD[9] によってアドレスPrefixを動的に配信するプロトコルも整備されたため、原理的には切り替える前後のアドレスを同時に利用できる期間を設けることで切り替えをスムーズに進めることができるとされている。しかし、実際にはIPアドレスは端末が直接通信に利用しているだけではなく、様々な設定に記述されているため、移行にはDNSやDHCP、ファイアウォールなどのフィルタリング、さらにはIDSや資産管理システムなど多岐にわたるシステムを考慮する必要がある。
 　エンドユーザとしての利用のみであればアドレスを手動で管理する局面はほとんどないため、現在のメカニズムでも大きな問題にはならないが、一定以上の規模を持ち固定アドレスのサーバなどを有する管理されたネットワークでは依然として大きな問題となる。このような場合、IPv6ネットワークであってもNATは有力なソリューションになる。
 　PI（Provider Independent）アドレスを取得し、独自のアドレス空間を所有していればNATに頼らずにスムーズなアドレス変更が可能となるが、すべての組織がPIアドレスを利用すれば経路制御の拡張性に重大な影響を及ぼすため、十分な解決にはならない。

(2) マルチホーム対応

 　アドレス変更に関連の深いもうひとつの問題はマルチホームである。企業ネットワークなどでは冗長性や負荷分散のためにも複数のISPに接続するマルチホームが必要とされるが、IPv4では原則として複数のネットワークアドレスを必要に応じて切り替えて使うことができないためそもそも困難な課題となっている。NATを利用すればそれらの課題がNAT装置だけの課題となり解決が容易になる。
 　NATを利用したマルチホームは経路制御面で大きな利点がある。NATを利用することでネットワークをひとつのIPアドレスで代表するため、ネットワークへの経路を新たに広告する必要がなく、マルチホーム化が経路制御に影響を与えない。
 　IPv6ではホストは同時に複数のネットワークに所属できるため特別な装置に頼ることなくマルチホーム化が可能であるが、そのためにはそれらのネットワークアドレスを経路情報として広告する必要があるため、経路制御へのインパクトが懸念される。
 　実際これまで経路制御に影響を与えないマルチホームを実現するには異なるISPから割り当てられた複数のIPv4アドレスを外部アドレスとして割り当てられたNATに頼るしかなかった。そのためIPv6でもIPv4と同様のNATを利用したマルチホーム化は自然な流れともいえる。
 　ただし、NATを利用するとEnd-to-Endの通信が阻害される問題も同時に持ち越されることになる。一方、IPv6で容易に実現できる複数の経路を広告する形のマルチホームではEnd-to-Endの原則が確保でき、かつ様々なトラフィックエンジニアリングや負荷分散を可能とできる利点がある。

(3) 設定情報の統一

 　ISPの立場からみれば、NATによってすべての顧客のアドレス空間が同じになっていることをサポートコストの削減に積極的に利用しているため、この方面の利点も無視できない。IPv6ではリンクローカルアドレスの概念によって複数のリンクに同じアドレスを割り当てることができるため、NATなしでも同じサポート体制が構築できる可能性があるが、それが十分であるかどうかはまだ検証されておらず、このこともIPv6でNATを必要とする要素となっている。

 　RFC 5902で述べられているIABの見解は、「IPv4で広く普及し、しばしばセキュリティ的な意味もあると思われているNATは、実際にはセキュリティ装置として利用できるとはいえず、その観点からはIPv6でNATは不要である」としている。一方で、現状ではアドレス変更、マルチホーム対応、設定情報の統一という課題に対してはNATの有効性を否定できないことも述べている。
 　RFC 5902では、これらの課題を考えるにあたっては、NATの有効性を考えるのではなく、あるサイトがNATを利用することによって、NATを利用しない残りのインターネットがどんな影響を受けるかが重要なポイントであることを指摘している。
NATの有無が大きく影響する「End-to-Endの原則」は、これまでインターネットの発展を支えてきた重要なコンセプトであり、これを保持できるかどうかは上記の課題の解決と両立できるかどうかにかかっていることから、IABではRFC 5902を通して「End-to-Endの原則」を確保できる提案を強く求めている。
 　一方で、目前にせまったIPv4アドレスの枯渇に対応するためにはIPv6の普及が不可欠であり、企業や家庭のネットワークでの実用的で安全なIPv6の構築と運用には、RFC 4864でも指摘されているIPv6で導入できるようになるプライバシアドレスやULA、複数アドレスの積極的な利用についての実用的なノウハウの蓄積が求められている。

[1]	IPv4アドレス枯渇対策タスクフォース，「IPv4アドレス枯渇について」， http://www.kokatsu.jp/blog/ipv4/
[2]	G. Van de Velde, T. Hain, R. Droms, B. Carpenter, E. Klein, “Local Network Protection“, RFC 4864, May 2007
[3]	M. Wasserman, F. Baker, “IPv6-to-IPv6 Network Address Translation (NAT66)”, Internet-Draft, http://tools.ietf.org/id/draft-mrw-behave-nat66-02.txt, Nov. 2008
[4]	Aboba, B. and E. Davies, “Reflections on Internet Transparency”, RFC 4924, July 2007
[5]	D. Thaler, G. Lebovitz, “IAB Thoughts on IPv6 Network Address Translation”, RFC 5902, July 2010
[6]	Bellovin, S., “A Technique for Counting NATed Hosts”, Proc. Second Internet Measurement Workshop, November 2002
[7]	Narten, T. , R.Draves, and S. Krishnan, “Privacy Exensions for Stateless Address Autoconfiguration in IPv6”, RFC 4941, September 2007.
[8]	Hinden, R. and B. Haberman, “Unique Local IPv6 Unicast Addresses”, RFC 4193, October 2005.,
[9]	Troan, O. And R. Drms, “IPv6 Prefix Options for Dynamic Host Configuration Protocol (DHCP) Version 6”, RFC 3633, December 2003.