Reliable Router Solicitations(信頼性のあるルータ要請メッセージ)
draft-krishnan-6man-resilient-rs-01.txt

現在の仕様では、RS (Router Solicitation)メッセージは、ネットワークインタフェースの初期化時に規定回数送信するのみとなっています。これらのパケットが到達しなかった場合、または到達してもその応答のRA (Router Advertisement)がホストに到達しなかった場合には、ホストはルータが不在であると見なし、それ以降RSメッセージの送信は行わないようになっています。しかし、パケットがロストした場合に備えて、信頼性を向上させるため、RSを送信し続けるべきであるとの提案がなされました。この提案は賛成者多数で、WGアイテムとして採択される見込みとなっています。

Optimal Transmission Window Configuration Option for ICMPv6 Router Advertisement(ICMPv6ルータ広告の最適転送ウィンドウ設定オプション)
draft-savolainen-6man-optimal-transmission-window-00.txt

テザリング機能を持ったスマートフォンなど、バッテリーの制約が厳しい装置がゲートウェイとして動作する場合、その装置の配下にある複数端末から定期的にパケットが送信され、またそれらの端末が非同期的にパケットを送信する場合に、3Gリンクのアップダウンが頻繁に繰り返され、バッテリーの消費が激しくなることが問題として提起されました。その解決策として、RAを拡張し、これらの定期的なパケットの送信タイミングを合わせるような送信ウィンドウ情報を、端末に配布する提案がなされました。しかし、「こういった下位レイヤの情報を、RAというIPレイヤのパケットで配布するべきではない」といった意見や、「送信間隔を合わせるためにゲートウェイ装置においてキャッシュ機能が必要となり、アプリケーションへの影響が懸念される」などの慎重意見が出され、WGアイテムとしての採択には至りませんで した。

Security Implications of Predictable Fragment Identification Values(予測可能なフラグメントID値のセキュリティ問題)
draft-gont-6man-predictable-fragment-id-02.txt

IPv6でパケットを断片化する際、断片の識別子に予測可能な値を用いていると、攻撃に利用される可能性があり、これを乱数化するべきであるとの提案です。実際にいくつかの実装における対応状況の紹介もあり、既に修正が施されている実装もあるものの、今後新規に出てくる実装などのために、RFCの修正という形で対応すべきである、との提案がなされました。これを受けての議論は「この問題を一般化し、IETF全体としてこのような予測可能な値を初期値として利用することに対して、警鐘を鳴らすような技術文書を発行すべきではないか」といった話題が中心となりました。この問題に対するIAB(Internet Architecture Board)による一般的な勧告文書の発行と、プロトコル個別の対応が、並行して進められる見込みとなっています。

Current issues with DNS Configuration Options for SLAAC(DNS設定オプションの現在の問題点)
draft-gont-6man-slaac-dns-config-issues-00.txt

RFC6106において、RAを用いてDNSサーバ情報を配布するオプションが規定されていますが、この方式の問題点が指摘されました。複数のルータが存在する場合に、使用するDNSサーバがフラッピングしてしまうこと、またこのオプションの有効期間が短いため、RAがロストした場合に、ホストが利用できるDNSサーバ情報が無くなってしまい、通信ができなくなってしまう、という問題点が指摘されました。その解決策として、受信側で対処する方法なども含め、いくつかの方法が提示されましたが、「仕様上のバグである」という認識が大勢を占め、「既存の仕様を修正する」という方向で進められることになりました。

464XLAT: Combination of Stateful and Stateless Translation(ステートフルとステートレスプロトコル変換の組み合わせ)
draft-ietf-v6ops-464xlat

IPv4からIPv6、そしてIPv6から再度IPv4へのプロトコル変換を行うことにより、IPv6 onlyのバックボーンを経由して、IPv4の接続性を実現する方式の提案です。既存の技術を組み合わせた方式であり、新たなプロトコルの策定は不要であることが特徴です。後述するsoftwire WGのスコープと一部重複しているとの意見があり、標準化を進めるWGをどこにするべきか、などについて議論がありましたが、今回のセッションではv6opsでBCP(Best Current Practice)として標準化を進めるという方向が示されました。ただ、Informationalではなく、BCPということで、どういった環境・適用先(Applicability)において“Best”なのか、について明示することを求められ、それを盛り込んだ改版文書をもって、WGLC(WG Last Call)を開始することになりました。

Semantic IPv6 Prefix(意味を持たせたIPv6プリフィクス)
draft-jiang-semantic-prefix

「これは悪いアイデアである」と断った上で提案されたのが、IPv6 PrefixにSemantics(意味付け)情報を埋め込む、という方式です。「IPv6のアドレス空間を浪費することになり、短所があることは認めるが、ただ多くのサイトにおいて意味を持たせたアドレッシングを行われることが予想されるため、それをよりうまくする方法を考えよう」という趣旨の提案でした。しかし会場からは、「そもそものモチベーションが理解できない」、「現状で問題無い」また「意味を持たせていることがサイト外に知られた場合にセキュリティ脅威となる」などの否定的な意見が大勢を占める結果となりました。