IPv4アドレスの枯渇すると言われ続けております。 「The IPv4 unicast extensions project」では、予約されているIPアドレスなどをユニキャストアドレスとして利用可能にし、4億1900万ものIPアドレスを追加することを謳っています。 実際、IETFで予約済みアドレスをユニキャストアドレスとして使用できるようにする提案を提出しています。 240.0.0.0/4 を利用可能にする提案 (draft-schoen-intarea-unicast-240) 0.0.0.0/8を利用可能にする提案 (0.0.0.0は除く) (draft-schoen-intarea-unicast-0) 127.1.0.0 ~ 127.255.255.255を利用可能にする提案 (draft-schoen-intarea-unicast-127) IPアドレスのホスト部が0のものを利

WebSocketに変わる、Webの新しい双方向通信仕様 WebTransportの標準化・実装が進められています。 このWebTransportではHTTP/3の特徴を活かし、パケットの順番が入れ替わったり、パケットロスがあったとしても受け取った順番に処理を行うことが出来ます。DATAGRAM拡張を使えば、パケットロスしたデータも再送不要にできます。 前回紹介した通り、WebTransportは「WebTransportover QUIC」や「WebTransportover HTTP/3」がありましたが、HTTP/3を使う方向で議論が進んでいます。 asnokaze.hatenablog.com Chromeの開発者メーリングリストでは、この「WebTransport over HTTP/3」実装が進められている事が書かれています。 groups.google.com そこで、今回はプ

「QUIC-based UDP Transport for SSH」という提案が提出されています。 トランスポートプロトコルとしてQUICを利用することで、様々な恩恵を受けることが出来ます。 ユーザランドでコネクションが管理されるため、TCPとは異なりOSレイヤのでコネクション切断の影響をうけない IPアドレスが変わっても接続を維持できる(コネクションマイグレーション) 経路上の第三者による切断に耐性がある(QUICでは通信の切断にも鍵が必要) 個人的にも、SSHがQUIC上で動作することで切断しづらくなることを期待しております。 それでは、この仕様についてざっと見ていくことにしましょう。 ただ、まだまだこれから議論がされる提案仕様ですので、設計は大きく変わるでしょう。 QUIC-based UDP Transport for SSH の概要 QUICは内部的にTLSハンドシェイクを行って

TLS1.3の仕様を書いたEric Rescorla氏らより「Compact TLS 1.3」という提案仕様が提案されており、すでにWG Draftとなっています。 このCompact TLS (cTLS)は、よりコンパクトなTLSを定義しデータの通信量を削減しています（リソースなどが制限されたデバイスでも利用できるようにというモチベーションもあります）。TLS1.3自体とisomorphic(同型)でありやり取りされるメッセージの意味自体は同じですがメッセージのフォーマットは異なっており、cTLSとTLS1.3自体と相互通信はできません。 しかし、cTLS, TLS1.3両方に対応することはできるので、将来的にそういうサーバが出てくれば問題なく通信できるようになりそうです。 アプローチ 主なアプローチは TLS1.3の冗長なフィールド、廃止されたフィールドを取り除きます (TLS1.2と