IESGがIP over MIMEの標準化をもうすぐ採択 48
ストーリー by Oliver
レイヤがパイ生地 部門より
レイヤがパイ生地 部門より
kappie曰く、"5/23付けのIESGからのメールによると、「IP over MIME」の標準化提案（Proposed Standard）のLast Call（RFCとして採択するか、2、3週間以内に結論を出す直前にみんなの意見を求める段階）があった。
IP over MIMEの仕様書によれば、この規格はSMTPやHTTPを使ってIPパケットをカプセル化するというもの。MIMEメディアタイプは「application/ip」で、パケットの分析やアプリケーションレベルでのIPトンネル構築に便利だ、とのこと。5月なのでジョークRFCではない。
現在のファイアウォールをバイパスできるのはもちろんだが、トンネルを使って違法なファイル交換でも大活躍しそうだ。ストリーミングの映像をパケットごとキャプチャして、メールで転送なんてことも可能になるかもしれない。
ただ、かなりの反感をかっており、インターネットウィザードのみなさんが激論中。"
TCP over TCP はマズー (スコア:4, 参考になる)
この規格では、dilationというパラメータで遅延の情報を伝えるようになっているみたいだけど、これを見て上位のTCPはtimeoutを調整するのかな？
理論的にはNFSも可能ですか (スコア:2, 興味深い)
とか考えました。遅そう…
職場のPOPサーバに1秒ごとのポーリングかけたら怒られるだろうなぁ。
love && peace && free_software
t-nissie
Re:理論的にはNFSも可能ですか (スコア:1)
# マジで ftp over http してくれようかという煩悩が。
Re:理論的にはNFSも可能ですか (スコア:1, 参考になる)
これにより、自宅のPCへ職場からSSHにて接続し、SSHでのPortFowardingにより好き勝手つないだ記憶あります。
これはhttp proxy越えできるので、非常に重宝しましたが、Air H" の登場により使わなくなりました。
Re:理論的にはNFSも可能ですか (スコア:0)
そのようなこまったちゃんは1%ぐらいすでにいます。
Re:理論的にはNFSも可能ですか (スコア:1)
自宅で802.11bにIPsecでトンネル掘ってNFSマウントし, FreeBSDのソースをcvs updateかけてみたら一晩たっても終わりませんでした. pingのレイテンシが10～100ms程度有ったのでこれが効いたみたいです. やっぱり細かいパケットをやりとりするにはLANじゃないと駄目みたいですね.
Re:理論的にはNFSも可能ですか (スコア:0)
って、uucpのポーリング間隔にもよりますが、セッションの確立にまる一日かかりそう…
あ、IP over NNTP すれば、どこにいてもパケットが届くのでルーティング不要でモバイルIPが簡単に実現できるかも
Re:理論的にはNFSも可能ですか (スコア:0)
http://www.spc.gr.jp/sho/tunnel/?DigByStone
# もっとも私なら、不安定なトンネルでNFS / smbdを走らせたりは
# しないけど…………………
4月1日 (スコア:2, 参考になる)
でもReferenceにRFC 1149 [ietf.org]があるんですけど。
Re:4月1日 (スコア:0)
# 嘘から出た真？
Re:4月1日 (スコア:0)
References Joke (スコア:0)
などといった大御所RFCがずらずらと並んでいる中に、
1149と3093が平然な顔をして同じように並んでいるという
References部分が最終的には一番笑えた。
Re:4月1日 (スコア:0)
「5月なのでジョークRFCではない。」
という論理展開はどうかとも思いますね
このdraft古すぎ (スコア:0)
IP over MIMEなんて今やレトロ化しようとしてただただ懐かしい。
今となってはコンピューターもネットインフラも高速化して
妙な現実味を帯びてきましたが、
draft出た当初は鳥と横並びのjokeだったような。
もういいかげんexpireさせるのかと思わせて裏切ってしまうのもシュール。
妙に現実味を帯びさせてしまってるのもシュール。
Joke RFCにしては引っ張り過ぎかなと思うのですが
おかげで他の追い越し組のRFCから
Eastlake, D., "IP over MIME", Work in Progress.
として参照され続けられて知名度あげてますので
それもま
Re:このdraft古すぎ (スコア:1)
> IPが鳥を運ぶ時代
物質電送のプロトコルもやはり TCP/IP の上に構築されるということなのでしょうか?
Re:このdraft古すぎ (スコア:1)
もしあれば物質電送のプロトコルもTCP/IP上に構築される
可能性があります.
(ウソかもしれない...)
Re:このdraft古すぎ (スコア:1)
http://www.ietf.org/rfc/rfc1437.txt
1993年の joke RFC だそうです。
(参考 よっち＠ほ～む [imasy.or.jp])
無知、かつ不勉強なのでナンなんですが… (スコア:1)
つか、全く同様なレイヤーが何回繰り返すことに??
-+- 想像力を超え｢創造力｣をも凌駕する、それが『妄想力』!! -+-
Re:無知、かつ不勉強なのでナンなんですが… (スコア:0)
これでファイルを転送したりすれば
FTP/TCP/IP/SMTP(HTTP)/TCP/IP?
すっごい無駄そう…でも面白そう。
Re:無知、かつ不勉強なのでナンなんですが… (スコア:0)
と再帰させたりして。
# まぜっかえしなのでACで
Re:無知、かつ不勉強なのでナンなんですが… (スコア:4, おもしろおかしい)
25番のポートは、DMZの館のsendmailの君に
23番は、死すべき運命のtelnetの子に
80番は、暗き御座の冥王のため
影横たわるHTTPの国に
80番ポートは全てを統べ
80番ポートは全てを見つけ
80番ポートは全てを捕らえて
暗闇の中につなぎとめる
影横たわるHTTPの国に
元ネタはここの>>477 [2ch.net]
# 本当に冗談じゃなくなったのでAP
MTUとかさ (スコア:1)
肝心なところが見えないんだけど、
MTUはどうなるの？TTLは？v6はOK？などなど。
ほかレ [srad.jp] ス [srad.jp]にあるようなhttpでの
トンネリングのデファクトなhttptunnel [nocrew.org]とかstone [osdn.jp]
(sourceforgeJPに移ったのね)などとは実装が違いそう。
MIME形式にapplication/ipを実装して、httpやsmtpなどの
MIMEでの転送が出来るプロトコルに後は任せるといった
実装なんじゃないかな？要するに双方向の通信がしたければ
それぞれにwebなり、smtpサーバが立ってる必要があると
感じた。
………つーか速攻で思いついたのはアタック用のパケットを
webサーバなどに送り込んでフィルタリングされてると
思い込んでるLANに対して直接攻撃をするとかいう用法……。
webサーバがデコードしてプライベートアドレス向けの
パケットをLAN上のPCに送出してくれたらしめたもの。
やなぎ
字面じゃなく論旨を読もう。モデレートはそれからだ
Re:MTUとかさ (スコア:0)
> MTUはどうなるの？TTLは？v6はOK？などなど。
MTUもTTLも特別なことはないし、v6は
address="1080:0:0:0:8:800:200C:4171"
ってExampleが書いてありますよ？ 1080::ってなんだよ、というのは別として。
まぁ、読めば長くも
Re:MTUとかさ (スコア:1)
スペルはあっています。 (スコア:1)
dilatation
どちらのスペルでも正しいです。
同じ意味で、辞書にも両方載っているはずです。
Re:MTUとかさ (スコア:0)
ちゃんと読んだのか? 「draftだから」じゃないだろ。
これは MIME メッセージに任意の IP パケットを埋め込むための書式
Application/IP Media Type を定義するだけのモノであって、具体的な
ゲートウェイの動作について述べる文書ではないのだから。
ちなみに v6 に関しては "version" というパラメータが用意され
Re:MTUとかさ (スコア:0)
> 肝心なところが見えないんだけど、
「draftは雑記だけど、これがRFCに変わるととたんに
詳細な記述になる」と勘違いしてませんか？
反対じゃ (スコア:0)
つか、こんなのが普及しちゃうと、またフィルタ用のミドルか何かで金がかかると…。
マジで勘弁。
# つーか、こんなのアングラツールで良いだろみたいな。
# 何で RFC よみたいな。
Re:反対じゃ (スコア:1, 参考になる)
Re:反対じゃ (スコア:1)
over HTTPSでやられた日にゃ…
#企業とかのproxyではHTTPSが全面禁止になったり
Re:反対じゃ (スコア:1)
偽証明書を返す https プロキシとか導入するのかな。
実はサーバ～プロキシ間のSSLとプロキシ～クライアント間で
別々のセッションを張っているとか。
証明書/鍵はプロキシが偽造し、そのCAは自社専用。
証明書の妥当性チェックはクライアントでなくてプロキシがやってくれる。
# mishimaは本田透先生を熱烈に応援しています
Re:反対じゃ (スコア:0)
接続できなきゃ何もできませんから
認証機能がPORT単位で付いているProxyなら単純に認証DB/許容IPを分ければ良いだけです
使えなくするんだからこれで十分
無論全員が使うためにHTTPSも
Re:反対じゃ (スコア:0)
と言うかhttpsが業務で必要になる事は特定の人以外稀なのでそうなったら許可制でしょうね
1.http/https共に不許可
2.httpのみ許可
3.http/httpsを許可
の3種類に増えるだけかと
無論httpレベルではトンネル系の処理をされないように解析&遮断が必要になると.
実は (スコア:0)
Re:反対じゃ (スコア:0)
クライアント作る側は
常に疑ってかからないとセキュリティホールになる。
MIMEリストつくるのも馬鹿馬鹿しくなってるし、
もう無くなってくんないかな。。
それは MIME の問題？ (スコア:1)
RFC（や他の標準化規格）にすべきでないっていう意味？
# mishimaは本田透先生を熱烈に応援しています
Re:それは MIME の問題？ (スコア:0)
そうではなくて、過去を参考にもっと有効な方法を模索しましょうって話。
#MIMEはOSなどに任せたいです。
Re:反対じゃ (スコア:0)
それこそフィルタしやすくするためでは？
httptunnelみたいな、独自形式の実装がたくさん増えるより、
RFCで定められた規格のツールが普及した方が、フィルタしや
すいと思いますが。
# まぁ、フィルタしやすいようじゃ普及しないかもしれません
# が。（ぉ
Re:反対じゃ (スコア:0)
Re:反対じゃ (スコア:0)
まずはこれ: Not All RFCs are Standards [ietf.org]
そしてこれ: The Internet Standards Process [ietf.org]
さて、
がどうして
になるのだ?
Keith タンを始めとする連中は 「Standards Track にするのはどうかと」
という点で議論していると思うのだが。
実際、 「(No [ietf.org]
Re:反対じゃ (スコア:0)
"つーか"と書きましたが、"つーかそれ以前に"位にとって貰えれば。
HTTPU/HTTPMU (スコア:0, 参考になる)
Re:HTTPU/HTTPMU (スコア:0)
最後の余計なものモデの対象となったと思われる数語以外は参考になりました。
ネットや携帯のなかった20-30年ぐらい前と今と。どれだけ違うんだろう。
スラドらしく (スコア:0)
これとは議論の流れが全く違いますな
Re:スラドらしく (スコア:0)
以前の記事は、まず、MSの人が「HTTPは、Webサービスなどの大きなトランザクションに不向きだ」と発言したというお話。で、MSだというので、アンチがうごめいただけ。
今回の記事は、HTTPの上に載せ過ぎるのは、良くない、というお話。
やっぱり、全然違う。
Re:スラドらしく (スコア:0)
今回はMSが絡んでないから違うよと。
IPv6 (スコア:0)
まぁそれはともかく、レイヤーを跨ぐのはどうかと思うなぁ。