<?xml version="1.0" encoding="utf-8"?><!DOCTYPE article  PUBLIC '-//OASIS//DTD DocBook XML V4.4//EN'  'http://www.docbook.org/xml/4.4/docbookx.dtd'><article><articleinfo><title>p016-03</title><revhistory><revision><revnumber>2</revnumber><date>2016-10-21 06:35:01</date><authorinitials>proxy-v4.nic.ad.jp</authorinitials></revision><revision><revnumber>1</revnumber><date>2016-10-20 07:16:57</date><authorinitials>proxy-v4.nic.ad.jp</authorinitials></revision></revhistory></articleinfo><section><title>016-03: エンドツーエンドNATを前提としたアドレス分配</title><section><title>概要</title><para>[提案ID] </para><itemizedlist><listitem override="none"><para>016-03 </para></listitem></itemizedlist><para>[提案タイトル] </para><itemizedlist><listitem override="none"><para>エンドツーエンドNATを前提としたアドレス分配 </para></listitem></itemizedlist><para>[提案内容] </para><itemizedlist><listitem><para>提案内容の概略 </para><itemizedlist><listitem override="none"><para>NATの存在とアドレスポート割当・変換の様態をプライベート網内のエンドに知らせるエンドツーエンドNATの導入により、エンドはアドレスポートを逆変換しエンドツーエンド透過性を回復できる（実は、ポート変換は不要）。また、NATの状態維持を、エンドにより正確に行える。マルチキャストにも対応。</para><para>各ユーザが使えるポート番号は制約されるが、URLにより自分のポート番号を指定できる場合、問題ではない。また、DNS、SMTP、HTTP等のプロトコルは、アプリケーション層リレーにより、デフォールトポートをNAT背後のユーザが共有できる。DNSクライアントのリレーで、ポート番号をランダム化してセキュリティを高めることも可能。</para><para>そこで、エンドへのエンドツーエンドNATの実装を推奨し、エンドツーエンドNATを前提としてアドレス分配量を減らすことで、IPv4アドレス空間を長持ちさせる。エンドツーエンドNATの実装と共にクラスEアドレスもユニキャストアドレスとして使えるようにすることとすれば、IPv4アドレス空間はさらに長く使える。プロトコルの詳細は、<ulink url="ftp://chacha.hpcl.titech.ac.jp/e2enat.txt"/> にある。</para><para>エンドツーエンドNATに対応するには端末の改造が必要であるが、同時にクラスEアドレスをユニキャストに使えるように端末を改造することとすれば、エンドツーエンドNATが普及してしまえば、当分の間エンドツーエンド透過性を維持しつつもIPv4アドレスが枯渇することはなく、マルチホーミングによる帯域経路表サイズの爆発を抑える新たなIP方式をじっくり検討できる。</para></listitem></itemizedlist></listitem><listitem><para>提案理由 </para><itemizedlist><listitem><para>現状の問題点 </para><itemizedlist><listitem override="none"><para>IPv4アドレスが足りないが、NATは醜いし、IPv4とIPv6の同時運用は大変。 </para></listitem></itemizedlist></listitem><listitem><para>改善したいポイント </para><itemizedlist><listitem override="none"><para>NATを美しくすることで、IPv4アドレスを長持ちさせる。 </para></listitem></itemizedlist></listitem><listitem><para>想定されるメリット、デメリット </para><itemizedlist><listitem><para>メリット </para><itemizedlist><listitem><para>メリットは、IPv4の生アドレスとポート番号なら人間が記憶できること、IPv6の運用が不要になること、DNSのセキュリティの改善。 </para></listitem></itemizedlist></listitem><listitem><para>デメリット </para><itemizedlist><listitem><para>エンドの改造が前提であることは一応のデメリットであるが、移行措置としてエンドツーエンドNAT装置に通常のNAT装置としての機能ももたせることで、改造されてないエンドも、現在のNAT背後のエンドより悪くなることはない。 </para></listitem></itemizedlist></listitem></itemizedlist></listitem></itemizedlist></listitem><listitem><para>提案が採択された場合の影響範囲（指定事業者、JPNIC、ユーザなど） </para><itemizedlist><listitem><para>指定事業者 </para><itemizedlist><listitem><para>新たなアドレスの分配を受けるなら（エンドツーエンド）NAT装置が必要となる。 </para></listitem><listitem><para>アドレス分配量が減る。 </para></listitem><listitem><para>IPv6の運用が不要になる。 </para></listitem></itemizedlist></listitem><listitem><para>JPNIC </para><itemizedlist><listitem><para>アドレス分配量が減る。 </para></listitem><listitem><para>IPv6の運用が不要になる。 </para></listitem></itemizedlist></listitem><listitem><para>ユーザ </para><itemizedlist><listitem><para>エンドツーエンドNAT前提のアドレスを持つユーザは、エンドをエンドツーエンドNAT装置に対応させ、ISPがエンドツーエンドNAT装置を用意しないと、既存のNAT装置の背後に廻ることとなる。 </para></listitem><listitem><para>エンドツーエンドNAT装置は、ネストさせてもよい。 </para></listitem><listitem><para>IPv6の運用が不要になる。 </para></listitem></itemizedlist></listitem></itemizedlist></listitem><listitem><para>コミュニティに対し，合意を得たいポイント </para><itemizedlist><listitem><para>将来的（遅くとも、最終ブロックを使い始める時点）に、エンドツーエンドNATもしくは類似技術によるエンドツーエンド透過性を維持したアドレス節約を前提とし、利用者数に対するアドレス割当量を削減すること </para></listitem><listitem><para>クラスEアドレスの将来的（エンドツーエンドNATもしくは類似技術が普及した後）なユニキャストでの利用 </para></listitem></itemizedlist></listitem></itemizedlist><para>[提案者] </para><itemizedlist><listitem override="none"><para>太田　昌孝（東京工業大学） </para></listitem></itemizedlist></section><section><title>提案の履歴</title><informaltable><tgroup cols="4"><colspec colname="col_0" colwidth="20*"/><colspec colname="col_1" colwidth="17*"/><colspec colname="col_2" colwidth="43*"/><colspec colname="col_3" colwidth="20*"/><tbody><row rowsep="1"><entry colsep="1" rowsep="1"><para>アクティビティ</para></entry><entry colsep="1" rowsep="1"><para>日付</para></entry><entry colsep="1" rowsep="1"><para>状態</para></entry><entry colsep="1" rowsep="1"><para>参照 </para></entry></row><row rowsep="1"><entry colsep="1" rowsep="1"><para>MLへの投稿</para></entry><entry colsep="1" rowsep="1"><para>2009年6月5日</para></entry><entry colsep="1" rowsep="1"><para>JPNIC-IP-USERS 1709 </para></entry><entry colsep="1" rowsep="1"/></row><row rowsep="1"><entry colsep="1" rowsep="1"><para>JPOPM16での発表</para></entry><entry colsep="1" rowsep="1"><para>2009年7月1日</para></entry><entry colsep="1" rowsep="1"><para><ulink url="http://jpopf.net/opf-jp/opm16/">JPOPM16</ulink>にて議論され、コンセンサス内容を見直し、必要に応じ、再提案となりました。</para></entry><entry colsep="1" rowsep="1"><para><ulink url="http://jpopf.net/opf-jp/opm16/jpopm16-p3-v2.pdf">発表資料(PDF)</ulink>／<ulink url="http://jpopf.net/opf-jp/opm16/opm16-minutes.html#070">議事録</ulink></para></entry></row></tbody></tgroup></informaltable></section></section></article>