- DNSOP
- dispatch SADCDN
- BPF
- madinas MAC Address Device Identification for Network and Application Services
- dhc Dynamic Host Configuration
DNSOP
Chair update でももの話がされた。
明日v6opsで話すらしいよっていうのと、RFC3901 bis 必要だよねって話。
Jen さんが後ろみてこっちみてにっこりしてきた。応援しているってことだと思う。
きっと。そうだととても嬉しい。
dispatch SADCDN
Matt Joras META
slides:
https://datatracker.ietf.org/meeting/117/materials/slides-117-dispatch-sadcdn
logs:
Side meeting wiki: https://wiki.ietf.org/en/meeting/117/sidemeetingsTuesday 18:00-19:00 Continental 2-3 SADCDN side meetinguse case: adaptive video traffic shaping (throttling, policing)
existing work (e.g. HLS, DASH)inband signals: CN, DSCP, etc.
out-of-band signals: CAMARA, custom network feedbackTed Hardie: needs a BoF for the large-scale concern about how explicit signals leak other information. directly consider the privacy concerns.Alissa Cooper: we had issues with CAMARA, what would make it possible to get to consensus.Matt: Engagement services. Many operators. We need consensus between Content and OEM.Richard Barnes: can we have signals that go from the network toward the endpoint? seems like better privacy properties. We might be able to progress more if we just pick one direction of communication.Matt: We see it goes both way. An opportunity to create a single tunnel for both ways. I can see how we might get more consensus if we pick only one direction, though.Harald Alvestrand: The problem is more complicated than you described. The network needs to which services are using the network. If not done careful, a lot of information will be exposed. Very complicated problem.Matt: Yes, it is very complicated. Regarding the leaking problem, it has been done. Video is already being targeted and shaped.Dan Druta: Yes to all the questions on slide 17. good opportunity to look at the problem from different perspectives. The proposal is too vague right now, but we can start from it. Maybe a BoF?Dispatch outcome: ART area BoF?
BPF
どのようにlinux kernel側とIETF側でドラフトを書くか。
現在のドラフト作成手順。左側がlinux kernel。
githubの方はミラーだから本文にgithub経由でPRして入れることはできない。
githubが使われることに抵抗感を持つひともいる。（linux community側の意見かな)
linux communityはgithub使わないし、IETF全体としては使わない方が多いのになぜ使うの？って意見。
chair: 便利なissue tracker が欲しいだけ。一番便利なのがgithubってだけ。
どのような形式で定義しようかとかの話も。
madinas MAC Address Device Identification for Network and Application Services
Experimental results from OpenRoaming tests, Warren Kumari
IETFでOpenRoamingを
OpenRoaming で実験してみたけど、ちょっとこれmadinasが目標としてることと逆行してそうだよっというないよう。
The group will generate a Best Current Practices (BCP) document recommending means to reduce the impact of RCM on the documented use cases while ensuring that the privacy achieved with RCM is not compromised.Ref: https://datatracker.ietf.org/wg/madinas/about/
スライド
なんかログ確認すると、個人を識別できそうな気がする？？
意図的にOpenRoamingに参加しようとしてない人たちが近くを通っただけでログに乗るのも観測した。
dhc Dynamic Host Configuration
Abstract
This document defines a method to inform a DHCPv6 server that a device has a self-generated or statically configured address.
This document provides a mechanism for a device to inform the DHCPv6 server that it has a self-configured IPv6 address (or has a statically configured address), and thus provides parity with IPv4 in this aspect.
andriod が DHCPv6 を使わないのは有名な話。DHCPv6によってアドレスは所得は
RA Guard が機能してなくて変なアドレスが付いてしまった例とかに便利。
wg LCの前にrunning code大事だけど、 実装はあるの？
Lorenzo: クライアント実装は簡単に作れるけど、DHCPv6サーバ側は用意できないかな。べつにサーバ側はDHCPv6サーバである必要はなくて、ただ、今回定義するパケットをまつサーバが存在すれば良いだけだから簡単。すぐ（プラハ前）実装はできる。
DNSは？
（昔DNSのはなしもあったっぽい）
This document borrows heavily from a previous document, draft-ietf-dhc-addr-registration, which defined "a mechanism to register self-generated and statically configured addresses in DNS through a DHCPv6 server". That document was written Sheng Jiang, Gang Chen, Suresh Krishnan, and Rajiv Asati.
ログ。
- Bernie brought up (in relation to transaction IDs) that they are useful for the client in some situations
- Matching up reply that comes for a given request
- Jen said draft does clarify how client handles replies (matching transaction IDs)
- Bernie brought up that it’s not terribly useful for Servers, but will examine draft and give further comments later
- Tim asked if there were any known implementations
- Lorenzo said they plan to put a client implementation together for this, will update the list when something is available
- Eric brought up the topic of a hackathon for this
- Lorenzo said they can definitely come up with a basic proof of concept before next meeting
- Some further discussion on security considerations
- Jen says spoofing clients might be tricky, so that might not be a path to go down now
- Also security implications of including DNS information in these messages (verifying client’s hostname in registration?)
- Lorenzo clarifies that the direction was “people could do this”, but not a recommendation/requirement one way or another
- More discussion on MAY/SHOULD language for accepting(?) DNS info from clients
- Bernie brought up using ISC Kea as a baseline implementation that could be extended for a proof of concept
結構便利そうな気がする。
過去の遍歴とドラフトを読んで勉強していきたい。
これが今回のドラフトの-00の時の発表スライドかな。
(今と状況変わってるかもしれないけど、わかりやすいスライド。）
とても疲れた。
