Your SlideShare is downloading. ×
0
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Ia20120118 ohta
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Ia20120118 ohta

985

Published on

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

  • Be the first to like this

No Downloads
Views
Total Views
985
On Slideshare
0
From Embeds
0
Number of Embeds
1
Actions
Shares
0
Downloads
1
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 1. Almost End to End NAT 太田昌孝東京工業大学情報理工学研究科mohta@necom830.hpcl.titech.ac.jp 1
  • 2. 研究の背景• IPv4アドレスが足りない• IPv6は、使い物にならない – PMTUDが動かない、等• 一つのIPv4アドレスを、ポート番号で分けて 複数のホストで共有するしかない – Large Scale NAT? • End to end透過性がない – End to End NAT? • 新たなゲートウェイや自動端末構成プロトコルが必要 2
  • 3. 旧来のNAT (LSN)は、何故、 不完全で不正確なのか?• IPヘッダを書き換えるのだから、当然? – 何がどう当然なのか、わからない• 原論文に立ち返って考えてみると、、、 3
  • 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. 旧来の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. 旧来の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. End to End NAT• NATの機能をなるべく端末に負わせる – NATゲートウェイではほとんど何もしない • ポート番号により受信者アドレスを変換するだけ – ポート番号やトランスポートチェックサムはそのまま – 端末では、受信者アドレスを元に戻す • トランスポートチェックサムは、自動的に正しくなる – 端末が送信するパケットの送信者アドレスは、グ ローバルアドレス、送信者ポート番号はその端末 に割り当てられたポート番号に限定 • ポート番号の衝突はなく、ポート変換の必要なし 7
  • 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. End to End NATの特長と問題点• 全てのトランスポート層プロトコルが動作 – ポート番号さえあれば(ICMP EchoのIDやSeq. No、IPSECのSPI等もポート番号とみなせる)• 普及させるのは容易ではない – NATゲートウェイの改造が必要 • 旧来のNATゲートウェイとの両立も可能だが、、、 – 端末の構成情報(グローバルアドレス、割り当て られたポート)をどう与えるか? • 新たなプロトコルが必要?IETFのPCP? 9
  • 10. UPnP (Universal Plug and Play)• 端末の自動構成のためのシステム – 端末がNAT越えするために、ポートマッピング情 報を得るプロトコルを含む • WANIPConnectionサービスについての規定 – 端末上のアプリケーションを、UPnPに対応したも のに改造することを想定• 多くのNATゲートウェイで実装されている• トランスポート層としては、TCPとUDP(と ICMP)にのみ対応 10
  • 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. 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. 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. Almost End to End NAT• UPnPゲートウェイを利用したEnd to End NAT• UPnPゲートウェイでのポートマッピング(双方 向)を、端末のトランスポート層で逆変換 – アプリケーションに見えるパケットの自分のアドレ スはグローバルアドレス、送信者ポート番号はそ の端末に割り当てられたポート番号に限定 • アプリケーションの改造は、一切不要 – アプリケーションが使えるポート番号と数は制約されるが – TCPとUDP(とICMP)しか使えないので、Almost 14
  • 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. Almost End to End NATの特長• UPnP対応の既存NATゲートウェイがそのま ま使える• ゲートウェイ構成情報は、UPnPにより取得可 – グローバルアドレス:GetExternalIPAddress() – ポート変換情報:GetListOfPortMappings() • UPnP第一版では、GetGenericPortMappingEntry()• 端末側の実装は、NetBSD5.1上のEnd to End NATの実装を手直しすれば、容易 – ゲートウェイ上でポート番号を変換しなければ 16
  • 17. NATによるポート番号不足?• サーバが受けるポートは一つでいいが、クラ イアントがサーバに多数の要求を出すポート は多数必要? – 実際、Google Mapはポート番号を大量消費する – 適切な実装により、回避可能 • 実装が、ポート番号の一時的な不足(旧来のNATでは 不可知だが、(Almost) End to End NATではEAGAIN のエラーに)に適切に対処していればよい • クライアントの送信者ポートは、実はsetsockoptでREU SEPORTを設定すれば、多数のconnectでの共有が可 – ソケットを共有ポートにbindしてから、connect 17
  • 18. 結論• Almost End to End NATにより: – 既存のUPnP対応NATゲートウェイ背後の端末上 で、UPnP非対応のTCP/UDP上のアプリケーショ ンが、End to End透過性を保ちつつ動作可 – IPv4アドレスの金銭取引で価格が高騰すれば、 このような技術への追い風となる• IPv4アドレス空間は、当分保つ – その間にクラスEを解放すれば、さらに長く保つ• 今後の課題は、URL全般へのSRVの導入 18

×