IETF117 2日目

 

v6ops

Using DHCP-PD to Allocate A Unique Prefix per Device

https://datatracker.ietf.org/meeting/117/materials/slides-117-v6ops-using-dhcp-pd-to-allocate-a-unique-prefix-per-device

あとでまとめる。
WGLCへの投票はNoだった。

 

Use of the IPv6 Flow Label for WLCG Packet Marking

https://datatracker.ietf.org/meeting/117/materials/slides-117-v6ops-use-of-the-ipv6-flow-label-for-wlcg-packet-marking

いいかんじに情報使ってますよみたいな話。discussionはいい雰囲気で結構人が前にいってた。あまりよ

あまりよくわかってないけど、ハッキーで面白そうだからあとで読んでみよう。

IPv6-only resolver

もらったコメント

Lorenzoさん

On 464xlat, I wrote an implementation of it. Right? But and 464xlatt is intended as a compatibility measure for things that need to talk to IP before and where you can't modify the apps. Okay? I I would disagree with folks who say that 464XLAT is a better solution. If all you need to do on this thing is to run a v6-only name server, then you don't need 464XLAT. You can just do this. I'm sure there are strong opinions on the other side as well, but, you know, don't necessarily thinks that that's the prevailing opinion.

The other thing is that, yeah, for 3901, I think, you should probably also say that every recursive server should have access to the IPv4 Internet. Right? It doesn't have to have a IPv4 address but it should be able to connect to the IPv4 Internet.

Warren Kumari さん

Warren Kumari, Google. Just a quick note that regardless of where this document ends up being discussed now, you know, DNS software, v6ops. the other working group will be cc'd on the working group last calls, etcetera. So everybody will get to see them. 

Thank you.

終わったあとにLorenzoさんに、464XLATを使いたくないってユースケースは十分理解できる。464XLATを好む人をうかがって書きたいことを書く必要はないって言われた。けっこうメーリスでいろいろ意見を言われて弱気になってしまっていた部分があったからこれを言われたのは凄いありがたかった。

I don't want to put CLAT in my linux って感じるのに同意(理解?)してもらえた。

きっと自分が自覚してる以上に弱気になっていたから、強気に、464XLATを使いたくないからソフトウェアでやりたいんだって主張をしていきたい。

QUIC

IETF-117 QUIC WG Agenda - HedgeDoc

v6opsと被ってて追えてない。
QUIC-enabled Service Differentiation for Traffic Engineering がプライバシーの問題で結構問題視されているのをログで確認した。たしかに、Traffic Engineeringなんてサーバ側のチューニング話にクライアントがわざわざ付き合う必要はないって感じるそう。プライバシー問題があるなら尚更。

ただ単純に一対のエンドポイントでのマルチパスQUICだけど定義でできないのかな。そうするしかなさそう。

https://datatracker.ietf.org/meeting/117/materials/slides-117-quic-quic-enabled-service-differentiation-for-traffic-engineering

IABopen

初めてくる。


W3C Liaison Report

liaison はIETFと他の標準化団体との橋渡しをする人。

ccwg

wgになってから始めてのIETFミーティング。

https://notes.ietf.org/notes-ietf-117-tsvwg

https://datatracker.ietf.org/meeting/117/materials/slides-117-quic-quic-enabled-service-differentiation-for-traffic-engineering

西田さんの現状についてのドキュメントとか、

GoogleからBBRv3とか

https://datatracker.ietf.org/meeting/117/materials/slides-117-ccwg-bbrv3-algorithm-bug-fixes-and-public-internet-deployment