Almost End to End NAT          太田昌孝東京工業大学情報理工学研究科mohta@necom830.hpcl.titech.ac.jp                                   1
研究の背景• IPv4アドレスが足りない• IPv6は、使い物にならない – PMTUDが動かない、等• 一つのIPv4アドレスを、ポート番号で分けて  複数のホストで共有するしかない – Large Scale NAT?   • End to...
旧来のNAT (LSN)は、何故、  不完全で不正確なのか?• IPヘッダを書き換えるのだから、当然? – 何がどう当然なのか、わからない• 原論文に立ち返って考えてみると、、、                        3
The End to End Argument• The function in question can completely and correctly be  implemented only with the knowledge and...
旧来のNAT (LSN)は、何故、   不完全で不正確なのか?• IPヘッダを書き換えるのだから、当然? – 何がどう当然なのか、わからない• 原論文に立ち返って考えてみると、、、 – NAT can completely and correc...
旧来のNATのレイヤ構造                                                                    NAT                                       ...
End to End NAT• NATの機能をなるべく端末に負わせる – NATゲートウェイではほとんど何もしない  • ポート番号により受信者アドレスを変換するだけ    – ポート番号やトランスポートチェックサムはそのまま – 端末では、受...
エンドツーエンドNATの                レイヤ構造            インターネットからのパケットの受信者アドレス逆変換              送信パケットの送信者ポート番号制限                     ...
End to End NATの特長と問題点• 全てのトランスポート層プロトコルが動作 – ポート番号さえあれば(ICMP EchoのIDやSeq.   No、IPSECのSPI等もポート番号とみなせる)• 普及させるのは容易ではない – NAT...
UPnP (Universal Plug and Play)• 端末の自動構成のためのシステム – 端末がNAT越えするために、ポートマッピング情   報を得るプロトコルを含む   • WANIPConnectionサービスについての規定 – ...
旧来のNATのレイヤ構造                                                                    NAT                                       ...
UPnPの想定する                   レイヤ構造                                           UPnP                                          ...
UPnPと        End to End Argument• UPnPは文字通り – with the knowledge and help of the application   standing at the end points ...
Almost End to End NAT• UPnPゲートウェイを利用したEnd to End NAT• UPnPゲートウェイでのポートマッピング(双方  向)を、端末のトランスポート層で逆変換 – アプリケーションに見えるパケットの自分のア...
Almost End to End NATの                   レイヤ構造               双方向のアドレス,ポート,チェックサム逆変換                                       ...
Almost End to End NATの特長• UPnP対応の既存NATゲートウェイがそのま  ま使える• ゲートウェイ構成情報は、UPnPにより取得可 – グローバルアドレス:GetExternalIPAddress() – ポート変換情...
NATによるポート番号不足?• サーバが受けるポートは一つでいいが、クラ  イアントがサーバに多数の要求を出すポート  は多数必要? – 実際、Google Mapはポート番号を大量消費する – 適切な実装により、回避可能  • 実装が、ポート...
結論• Almost End to End NATにより:  – 既存のUPnP対応NATゲートウェイ背後の端末上    で、UPnP非対応のTCP/UDP上のアプリケーショ    ンが、End to End透過性を保ちつつ動作可  – IPv...
Upcoming SlideShare
Loading in …5
×

Ia20120118 ohta

1,335 views

Published on

0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total views
1,335
On SlideShare
0
From Embeds
0
Number of Embeds
5
Actions
Shares
0
Downloads
3
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Ia20120118 ohta

  1. 1. Almost End to End NAT 太田昌孝東京工業大学情報理工学研究科mohta@necom830.hpcl.titech.ac.jp 1
  2. 2. 研究の背景• IPv4アドレスが足りない• IPv6は、使い物にならない – PMTUDが動かない、等• 一つのIPv4アドレスを、ポート番号で分けて 複数のホストで共有するしかない – Large Scale NAT? • End to end透過性がない – End to End NAT? • 新たなゲートウェイや自動端末構成プロトコルが必要 2
  3. 3. 旧来のNAT (LSN)は、何故、 不完全で不正確なのか?• IPヘッダを書き換えるのだから、当然? – 何がどう当然なのか、わからない• 原論文に立ち返って考えてみると、、、 3
  4. 4. The End to End Argument• The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. (Sometimes an incomplete version of the function provided by the communication system may be useful as a performance enhancement.) – NAT can completely and correctly be implemented only with the knowledge and help of the end points – providing NAT function as a feature of the communication system itself is not possible 4
  5. 5. 旧来のNAT (LSN)は、何故、 不完全で不正確なのか?• IPヘッダを書き換えるのだから、当然? – 何がどう当然なのか、わからない• 原論文に立ち返って考えてみると、、、 – NAT can completely and correctly be implemented only with the knowledge and help of the end points – providing NAT function as a feature of the communication system itself is not possible• NATが端末の助けを受けないのが、原因 – それどころか、旧来のNATは自らの存在を端末から隠し ている 5
  6. 6. 旧来のNATのレイヤ構造 NAT unaware 双方向のアドレス,ポート,チェックサム変換 public application public private private transport transport transportpublic IP private IP private IP private IP private IP datalink datalink : public Internet : private IP network 6
  7. 7. End to End NAT• NATの機能をなるべく端末に負わせる – NATゲートウェイではほとんど何もしない • ポート番号により受信者アドレスを変換するだけ – ポート番号やトランスポートチェックサムはそのまま – 端末では、受信者アドレスを元に戻す • トランスポートチェックサムは、自動的に正しくなる – 端末が送信するパケットの送信者アドレスは、グ ローバルアドレス、送信者ポート番号はその端末 に割り当てられたポート番号に限定 • ポート番号の衝突はなく、ポート変換の必要なし 7
  8. 8. エンドツーエンドNATの レイヤ構造 インターネットからのパケットの受信者アドレス逆変換 送信パケットの送信者ポート番号制限 public インターネットからのパケットの,送信者 application ポート番号に応じた受信者アドレス変換 public transport public privatetransport transport public IPpublic IP private IP private IP private IP private IP datalink datalink : public Internet : private IP network 8
  9. 9. End to End NATの特長と問題点• 全てのトランスポート層プロトコルが動作 – ポート番号さえあれば(ICMP EchoのIDやSeq. No、IPSECのSPI等もポート番号とみなせる)• 普及させるのは容易ではない – NATゲートウェイの改造が必要 • 旧来のNATゲートウェイとの両立も可能だが、、、 – 端末の構成情報(グローバルアドレス、割り当て られたポート)をどう与えるか? • 新たなプロトコルが必要?IETFのPCP? 9
  10. 10. UPnP (Universal Plug and Play)• 端末の自動構成のためのシステム – 端末がNAT越えするために、ポートマッピング情 報を得るプロトコルを含む • WANIPConnectionサービスについての規定 – 端末上のアプリケーションを、UPnPに対応したも のに改造することを想定• 多くのNATゲートウェイで実装されている• トランスポート層としては、TCPとUDP(と ICMP)にのみ対応 10
  11. 11. 旧来のNATのレイヤ構造 NAT unaware 双方向のアドレス,ポート,チェックサム変換 public application public private private transport transport transportpublic IP private IP private IP private IP private IP datalink datalink : public Internet : private IP network 11
  12. 12. UPnPの想定する レイヤ構造 UPnP aware 双方向のアドレス,ポート,チェックサム変換 private UPnP application public private NAT越えのためのやりとり private transport transport transportpublic IP private IP private IP private IP private IP datalink datalink : public Internet : private IP network 12
  13. 13. UPnPと End to End Argument• UPnPは文字通り – with the knowledge and help of the application standing at the end points of the communicationではあるが、、、アプリケーションで対応すると、アプリケーションの変更が必要で、ださい• End to End Argument当時のスタックは未分 化で、今でいうアプリケーションでなくてもよい – もっと下の層でなんとかしてもいい 13
  14. 14. Almost End to End NAT• UPnPゲートウェイを利用したEnd to End NAT• UPnPゲートウェイでのポートマッピング(双方 向)を、端末のトランスポート層で逆変換 – アプリケーションに見えるパケットの自分のアドレ スはグローバルアドレス、送信者ポート番号はそ の端末に割り当てられたポート番号に限定 • アプリケーションの改造は、一切不要 – アプリケーションが使えるポート番号と数は制約されるが – TCPとUDP(とICMP)しか使えないので、Almost 14
  15. 15. Almost End to End NATの レイヤ構造 双方向のアドレス,ポート,チェックサム逆変換 public 送信パケットの送信者ポート番号制限 application 双方向のアドレス,ポート,チェックサム変換 public transport UPnP public private privatetransport transport 構成情報の提供 transportpublic IP private IP private IP private IP private IP datalink datalink : public Internet : private IP network 15
  16. 16. Almost End to End NATの特長• UPnP対応の既存NATゲートウェイがそのま ま使える• ゲートウェイ構成情報は、UPnPにより取得可 – グローバルアドレス:GetExternalIPAddress() – ポート変換情報:GetListOfPortMappings() • UPnP第一版では、GetGenericPortMappingEntry()• 端末側の実装は、NetBSD5.1上のEnd to End NATの実装を手直しすれば、容易 – ゲートウェイ上でポート番号を変換しなければ 16
  17. 17. NATによるポート番号不足?• サーバが受けるポートは一つでいいが、クラ イアントがサーバに多数の要求を出すポート は多数必要? – 実際、Google Mapはポート番号を大量消費する – 適切な実装により、回避可能 • 実装が、ポート番号の一時的な不足(旧来のNATでは 不可知だが、(Almost) End to End NATではEAGAIN のエラーに)に適切に対処していればよい • クライアントの送信者ポートは、実はsetsockoptでREU SEPORTを設定すれば、多数のconnectでの共有が可 – ソケットを共有ポートにbindしてから、connect 17
  18. 18. 結論• Almost End to End NATにより: – 既存のUPnP対応NATゲートウェイ背後の端末上 で、UPnP非対応のTCP/UDP上のアプリケーショ ンが、End to End透過性を保ちつつ動作可 – IPv4アドレスの金銭取引で価格が高騰すれば、 このような技術への追い風となる• IPv4アドレス空間は、当分保つ – その間にクラスEを解放すれば、さらに長く保つ• 今後の課題は、URL全般へのSRVの導入 18

×