Warren has COID and so is quarantined in his room. :-(
", "time": "2023-03-27T00:30:29Z"}, {"author": "Warren Kumari", "text": "Its happening...
", "time": "2023-03-27T00:30:54Z"}, {"author": "Anthony Somerset", "text": "we started already @Ron Bonica :D
", "time": "2023-03-27T00:31:08Z"}, {"author": "Warren Kumari", "text": "Perhaps your speakers are muted?
", "time": "2023-03-27T00:31:17Z"}, {"author": "\u00c9ric Vyncke", "text": "ROn meeting has started
", "time": "2023-03-27T00:32:00Z"}, {"author": "\u00c9ric Vyncke", "text": "Do you get audio ?
", "time": "2023-03-27T00:32:07Z"}, {"author": "David Lamparter", "text": "Room audio is working, is it not streaming out?
", "time": "2023-03-27T00:32:30Z"}, {"author": "Toerless Eckert", "text": "So, how does one get counted for participating in any meetings these days. just log into onsite or remote tool sufficient ? Sorry - monday morning question.
", "time": "2023-03-27T00:32:43Z"}, {"author": "\u00c9ric Vyncke", "text": "worse case, Ron, use the closed caption feature
", "time": "2023-03-27T00:33:04Z"}, {"author": "Lorenzo Miniero", "text": "Toerless: yes, bluesheets are automatically built out of that
", "time": "2023-03-27T00:33:09Z"}, {"author": "Toerless Eckert", "text": "Thanks, Lorenzo!
", "time": "2023-03-27T00:33:21Z"}, {"author": "Ron Bonica", "text": "i can hea now
", "time": "2023-03-27T00:37:28Z"}, {"author": "\u00c9ric Vyncke", "text": "Please join the queue even if you are in the room
", "time": "2023-03-27T00:40:03Z"}, {"author": "Warren Kumari", "text": "Sec. Is there someone taking minutes?!
", "time": "2023-03-27T00:42:11Z"}, {"author": "Warren Kumari", "text": "I'm not sure that I heard that at the start of the meeting?
", "time": "2023-03-27T00:42:27Z"}, {"author": "Warren Kumari", "text": "Thank you, Eric!
", "time": "2023-03-27T00:44:26Z"}, {"author": "\u00c9ric Vyncke", "text": ";-)
", "time": "2023-03-27T00:44:33Z"}, {"author": "Mark Andrews", "text": "Jordi's voice is distorting. move back from mic a little
", "time": "2023-03-27T00:45:31Z"}, {"author": "\u00c9ric Vyncke", "text": "@meetecho see above, audio in the room is OK though
", "time": "2023-03-27T00:45:54Z"}, {"author": "Lorenzo Miniero", "text": "Is it better now?
", "time": "2023-03-27T00:46:44Z"}, {"author": "Mark Andrews", "text": "a bit
", "time": "2023-03-27T00:46:54Z"}, {"author": "Juliusz Chroboczek", "text": "(Not for mic) I'm a little confused. In the previous slide, why did the translated traffic not reach the CDN?
", "time": "2023-03-27T00:47:33Z"}, {"author": "\u00c9ric Vyncke", "text": "I would probably need to re-read this I-D in the view of DOH and applications selecting their own resolvers
", "time": "2023-03-27T00:51:14Z"}, {"author": "Warren Kumari", "text": "@meetecho: One of the mics in v6ops seems dead. Unclear if just off, or dead battery...
", "time": "2023-03-27T00:51:30Z"}, {"author": "Anthony Somerset", "text": "the mics have switches on them and it appears that they get switched off overnight so have to be initially switched on
", "time": "2023-03-27T00:52:29Z"}, {"author": "Lorenzo Miniero", "text": "Warren: which one? they seem to be working from what we can hear now
", "time": "2023-03-27T00:52:44Z"}, {"author": "Anthony Somerset", "text": "even though they are wired - sound engineers worst nightmare!
", "time": "2023-03-27T00:52:50Z"}, {"author": "Warren Kumari", "text": "There are 2 floor mics -- the front one (I think)
", "time": "2023-03-27T00:53:10Z"}, {"author": "\u00c9ric Vyncke", "text": "the front mike was indeed off, I turned it in just in case
", "time": "2023-03-27T00:53:18Z"}, {"author": "\u00c9ric Vyncke", "text": "s/in/on/
", "time": "2023-03-27T00:53:29Z"}, {"author": "Warren Kumari", "text": "Ah, fixed! Thank you Eirc. (I'm not in the room)
", "time": "2023-03-27T00:54:32Z"}, {"author": "Anthony Somerset", "text": "confirmed, thanks Eric
", "time": "2023-03-27T00:56:02Z"}, {"author": "Erik Nygren", "text": "CDN / content provider support will also suffer, since this CPE bugs will be really hard to chase down.
", "time": "2023-03-27T00:57:03Z"}, {"author": "Erik Nygren", "text": "I wonder if this should be Experimental rather than Proposed Standard, regardless? and/or is this something where we should keep as a draft until we can get CPE implementations and experience there?
", "time": "2023-03-27T00:58:05Z"}, {"author": "Anthony Somerset", "text": "i would concur, CPE vendors are remarkably slow in this space... i mean look how long it took for CPE's to have reliable native IPv6 support....
", "time": "2023-03-27T00:59:04Z"}, {"author": "\u00c9ric Vyncke", "text": "Without any hat, this seems experimental indeed and should then include a metric/test to check whether the experiment was a success
", "time": "2023-03-27T00:59:26Z"}, {"author": "Warren Kumari", "text": "Yes, Ron.
", "time": "2023-03-27T01:00:58Z"}, {"author": "Warren Kumari", "text": "Thats spounds like a great idea.
", "time": "2023-03-27T01:01:10Z"}, {"author": "\u00c9ric Vyncke", "text": "Ron, your audio is pretty low level
", "time": "2023-03-27T01:01:18Z"}, {"author": "Michael Richardson", "text": "Also desktops with VMs/containers!!!!
", "time": "2023-03-27T01:06:09Z"}, {"author": "\u00c9ric Vyncke", "text": "True
", "time": "2023-03-27T01:06:48Z"}, {"author": "Anthony Somerset", "text": "would it be more fair to call this sub prefix delegation?
", "time": "2023-03-27T01:07:51Z"}, {"author": "\u00c9ric Vyncke", "text": "I guess on slide 8, it is not about \"DHCPv6 Server\" in the WAN but the part of CPE
", "time": "2023-03-27T01:07:53Z"}, {"author": "Michael Richardson", "text": "how many prefixes do the submarines really need?
", "time": "2023-03-27T01:08:33Z"}, {"author": "Michael Richardson", "text": ":-)
", "time": "2023-03-27T01:08:40Z"}, {"author": "Darren Dukes", "text": "Multihoming?
", "time": "2023-03-27T01:08:45Z"}, {"author": "Michael Richardson", "text": "No, Darren, don't say that word. It hurts us.
", "time": "2023-03-27T01:08:58Z"}, {"author": "Anthony Somerset", "text": "where the CPE tracks which prefixes its assigned on ports then allows sub PD allocations from whatever left
", "time": "2023-03-27T01:09:11Z"}, {"author": "\u00c9ric Vyncke", "text": "@Darren out of scope (but could be extended at the expense of wasting prefixes)
", "time": "2023-03-27T01:09:14Z"}, {"author": "Michael Richardson", "text": "PLEASE adopt.
", "time": "2023-03-27T01:09:27Z"}, {"author": "Michael Richardson", "text": "I'd rather do a few more updates to 7084, before we do a -bis.
", "time": "2023-03-27T01:11:38Z"}, {"author": "Darren Dukes", "text": "If I have a network with provider assigned addresses there should be some statement for link redundancy, maybe worth some thoughts
", "time": "2023-03-27T01:12:27Z"}, {"author": "Anthony Somerset", "text": "i agree with adopt status
", "time": "2023-03-27T01:12:37Z"}, {"author": "Juliusz Chroboczek", "text": "Chairs, could you please ask the speaker to lower their microphone gain?
", "time": "2023-03-27T01:14:53Z"}, {"author": "\u00c9ric Vyncke", "text": "Audio in room is also a little too loud / clipping
", "time": "2023-03-27T01:15:26Z"}, {"author": "Lorenzo Miniero", "text": "Eric: unfortunately it's Nalini's mic that's too loud
", "time": "2023-03-27T01:15:49Z"}, {"author": "Lorenzo Miniero", "text": "You could try asking here to speak further from the mic
", "time": "2023-03-27T01:16:04Z"}, {"author": "Lorenzo Miniero", "text": "*her
", "time": "2023-03-27T01:16:08Z"}, {"author": "Anthony Somerset", "text": "@Nalini Elkins can you move your mic slightly further away
", "time": "2023-03-27T01:16:12Z"}, {"author": "\u00c9ric Vyncke", "text": "A similar case is when using load balancers / TLS accelerators
", "time": "2023-03-27T01:22:29Z"}, {"author": "Anthony Somerset", "text": "yes - CDN's work fundamentally the same as a Load Balancer at the end of the day
", "time": "2023-03-27T01:23:29Z"}, {"author": "\u00c9ric Vyncke", "text": "Good old proxies like in early 90's
", "time": "2023-03-27T01:24:12Z"}, {"author": "Mark Andrews", "text": "@meetecho a vu meter would be useful for remote speakers.
", "time": "2023-03-27T01:24:15Z"}, {"author": "Lorenzo Miniero", "text": "Mark: remote speakers do have it, it's under their name in the top left corner
", "time": "2023-03-27T01:25:06Z"}, {"author": "Lorenzo Miniero", "text": "A moving waveform that moves when they talk
", "time": "2023-03-27T01:25:27Z"}, {"author": "Erik Nygren", "text": "on \"should CDNs be encouraged to do IPv6 to Origin Server\", at least at Akamai we finally have configurable support for this (and do prefer IPv6 to Origin when its enabled). I'm happy to provide details offline. But CDNs tend to operate as \"surrogate origins\" above L3 and it is often a feature to isolate the origin from clients from a security/etc perspective. Most of our customers likely wouldn't want EH to be passed through blindly --- although making this visible in customer configuration does make sense if there's a demand / use-case.
", "time": "2023-03-27T01:26:04Z"}, {"author": "Anthony Somerset", "text": "i think CDN's could do a feature where they could be configured to do specific EH's such as PDMv2 to the origin when making requests to origin, they would have to work out capturing the response data and presenting to the customer
", "time": "2023-03-27T01:29:19Z"}, {"author": "Anthony Somerset", "text": "my only question on host delegation becomes a case of provider assigning a big enough delegation... a minimum of a /56 really which is 256 /64's
", "time": "2023-03-27T01:34:37Z"}, {"author": "\u00c9ric Vyncke", "text": "I guess Jen's point is targeted for DC or web scalers not for residential
", "time": "2023-03-27T01:35:10Z"}, {"author": "Anthony Somerset", "text": "i 100% agree with the scaling/performance/management aspects though
\nbut the slides do talk to end users/residential use cases where the scaling issues become present
Just curious about the host to host connection, i.e., from one /64 to another one... ICMP redirect the router ? or hair pining ?
", "time": "2023-03-27T01:36:48Z"}, {"author": "Anthony Somerset", "text": "ah this is new slide since last time - helps to frame the discussion
", "time": "2023-03-27T01:38:59Z"}, {"author": "Mohamed Boucadair", "text": "You should start with slide 13 @Jen ;-)
", "time": "2023-03-27T01:39:04Z"}, {"author": "Daniel Bernier", "text": ";-)
", "time": "2023-03-27T01:39:08Z"}, {"author": "Daniel Bernier", "text": "agree on useful for DCs and/or large consumers of IP addresses (think PodCIDR)
", "time": "2023-03-27T01:39:51Z"}, {"author": "Michael Richardson", "text": "I love how brilliant the orange masks are.
", "time": "2023-03-27T01:41:20Z"}, {"author": "Michael Richardson", "text": "(Is that Marc?)
", "time": "2023-03-27T01:41:27Z"}, {"author": "Michael Richardson", "text": "But, it's kinda the anti-P flag.
", "time": "2023-03-27T01:41:52Z"}, {"author": "Michael Richardson", "text": "P-bar.
", "time": "2023-03-27T01:42:01Z"}, {"author": "\u67f3\u7530 \u6dbc", "text": "Maybe useful to get /64 at my DO box...?
", "time": "2023-03-27T01:42:55Z"}, {"author": "Michael Richardson", "text": "Jerold, I had a draft that had not progressed, about the CPE and the ISP agreeing on how to do allocations.
", "time": "2023-03-27T01:43:02Z"}, {"author": "Erik Nygren", "text": "This would be useful for hosting providers. Giving a /64 per VM/host as a default seems like a cleaner default world.
", "time": "2023-03-27T01:43:24Z"}, {"author": "Paolo Nero", "text": "P for Pretty Autonomous
", "time": "2023-03-27T01:43:36Z"}, {"author": "Erik Nygren", "text": "But for home networks this has some odd interactions with multi-homed networks (not that that is easy --- see the other draft/talk coming up).
", "time": "2023-03-27T01:44:11Z"}, {"author": "Philipp Tiesel", "text": "I did the calculations for our K8 infrastructure and /64 per host will hurt me by limiting the aggregation levels above (though I have no problems with using a /80 from software)
", "time": "2023-03-27T01:44:26Z"}, {"author": "Michael Richardson", "text": "that's broken... privacy address should never go away if a socket is open!!!
", "time": "2023-03-27T01:44:39Z"}, {"author": "Lorenzo Colitti", "text": "We should really just think of this as a replacement for IA_NA that gives the host as many addresses as it needs
", "time": "2023-03-27T01:44:52Z"}, {"author": "Juliusz Chroboczek", "text": "Who's the person at the microphone?
", "time": "2023-03-27T01:44:56Z"}, {"author": "Lorenzo Colitti", "text": "Jared Mauch is at the mic
", "time": "2023-03-27T01:45:05Z"}, {"author": "\u00c9ric Vyncke", "text": "Jared
", "time": "2023-03-27T01:45:08Z"}, {"author": "Juliusz Chroboczek", "text": "ty
", "time": "2023-03-27T01:45:10Z"}, {"author": "\u67f3\u7530 \u6dbc", "text": "Yup, definitely super tricky with multihomed network, but multihomed network on its own is already a rabbit hole...
", "time": "2023-03-27T01:45:16Z"}, {"author": "Juliusz Chroboczek", "text": "I like him :-)
", "time": "2023-03-27T01:45:48Z"}, {"author": "Michael Richardson", "text": "Jared is not wrong, but maybe out of order for this document.
", "time": "2023-03-27T01:45:52Z"}, {"author": "Juliusz Chroboczek", "text": "Perhaps, but I find his intervention refreshing.
", "time": "2023-03-27T01:46:22Z"}, {"author": "\u00c9ric Vyncke", "text": "indeed, it is even more for 6MAN
", "time": "2023-03-27T01:46:22Z"}, {"author": "Yasunobu Toyota", "text": "Basically support this draft, but some hosts require several separate L2 segments; you may need to run both docker containers and VMs.
\nIs there any solution for hosts that need multiple /64s
challenge is expecting that Home CPE, ISP assignment can be necessarily aligned with how massive scale IPv6 data centers
", "time": "2023-03-27T01:47:08Z"}, {"author": "Paolo Nero", "text": "SNAC vs DHCP :satisfied:
", "time": "2023-03-27T01:47:24Z"}, {"author": "Michael Richardson", "text": "Yanunobu, DHCP PD delegation already allows for multiple allocations.
", "time": "2023-03-27T01:47:31Z"}, {"author": "Daniel Bernier", "text": "good thing
", "time": "2023-03-27T01:47:42Z"}, {"author": "Michael Richardson", "text": "but, the truth is that it all goes up the \"router\" because ethernet is a fiction.
", "time": "2023-03-27T01:48:40Z"}, {"author": "Anthony Somerset", "text": "@Jen Linkova slide 13 should be \"first\" next time to save taking up mic time my other comment about host to host routing was also made
", "time": "2023-03-27T01:49:27Z"}, {"author": "Daniel Bernier", "text": "challenge would be ensuring that upstream router implementation allows for it. Exemple cloud providers allowing for it
", "time": "2023-03-27T01:52:59Z"}, {"author": "Daniel Bernier", "text": "which is currently not the case.
", "time": "2023-03-27T01:53:09Z"}, {"author": "\u67f3\u7530 \u6dbc", "text": "Presumably, this would be done by a provider who has the whole AS to themselves; therefore, any 'new' mechanism can be deployed
", "time": "2023-03-27T01:54:48Z"}, {"author": "Juliusz Chroboczek", "text": "NPT?
", "time": "2023-03-27T01:56:21Z"}, {"author": "Michael Richardson", "text": "NAT66
", "time": "2023-03-27T01:56:34Z"}, {"author": "Juliusz Chroboczek", "text": "ty
", "time": "2023-03-27T01:56:39Z"}, {"author": "Michael Richardson", "text": "Network and Port Translation.
", "time": "2023-03-27T01:56:42Z"}, {"author": "\u00c9ric Vyncke", "text": "Network prefix translation a 1:1
", "time": "2023-03-27T01:56:50Z"}, {"author": "Erik Nygren", "text": "rfc6296, I assume
", "time": "2023-03-27T01:56:59Z"}, {"author": "\u00c9ric Vyncke", "text": "Alas NPT is experimental (if not mistaken)
", "time": "2023-03-27T01:57:14Z"}, {"author": "Juliusz Chroboczek", "text": "So NPT is stateless and NAT is stateful? Is that the distinction?
", "time": "2023-03-27T01:57:28Z"}, {"author": "\u00c9ric Vyncke", "text": "correct
", "time": "2023-03-27T01:57:37Z"}, {"author": "Mohamed Boucadair", "text": "the main distinct is that this is not about address translation
", "time": "2023-03-27T01:58:17Z"}, {"author": "Mohamed Boucadair", "text": "but prefix translation
", "time": "2023-03-27T01:58:32Z"}, {"author": "Jen Linkova", "text": "Daniel Bernier said:
\n\n\nchallenge would be ensuring that upstream router implementation allows for it. Exemple cloud providers allowing for it
\n
It's up to the network operator to do this or not, so as an operator I either allow this (if I want) or not.
", "time": "2023-03-27T01:58:54Z"}, {"author": "Erik Nygren", "text": "I'm very supportive of us having a draft here. (I got backup connectivity at home, and I have yet to figure out a good way to support IPv6 well with it that allows for fast and transparent failver)
", "time": "2023-03-27T01:59:06Z"}, {"author": "Jen Linkova", "text": "Ah it was about another draft :)) sorry
", "time": "2023-03-27T01:59:31Z"}, {"author": "Paolo Nero", "text": "PvD is mentioned in the PA section
", "time": "2023-03-27T01:59:39Z"}, {"author": "Daniel Bernier", "text": "@jen agreed and strong supporter of it ;-)
", "time": "2023-03-27T01:59:54Z"}, {"author": "XiPeng Xiao", "text": "hi all, if you are on site, please run the meetecho mobile client so that you will be on the bluesheet, especially if you want to get into the queue
", "time": "2023-03-27T02:01:25Z"}, {"author": "Erik Nygren", "text": "Could we revise and bring NPTv6 out of Experimental to Proposed Standard?
", "time": "2023-03-27T02:02:22Z"}, {"author": "Fernando Gont", "text": "I support the document. I would say that the documentshould analyze the topic from an operational and pragmatic perspective, and not exclusively based on how IETF would like things to be.
", "time": "2023-03-27T02:02:54Z"}, {"author": "Juliusz Chroboczek", "text": "Erik, is that the hill you want to die on?
", "time": "2023-03-27T02:04:08Z"}, {"author": "\u00c9ric Vyncke", "text": "@Erik did I read that you just volunteered ?
", "time": "2023-03-27T02:04:17Z"}, {"author": "Fernando Gont", "text": "@erik -- aside from working NPT to PS, its document status doesn't mean that the thing is not used in the operational world. i.e., this document should consider that as an option -- no matter whether \"we\" like it or not..
", "time": "2023-03-27T02:05:52Z"}, {"author": "Yasunobu Toyota", "text": "This is the latest draft. We are looking for co-authors :)
\nhttps://datatracker.ietf.org/doc/draft-momoka-v6ops-ipv6-only-resolver/
Better might be to focus first on \"draft-fbnvv-v6ops-site-multihoming\" which seems like a good start comparing the options. PI isn't an option for residential, so then it becomes a question of which the other options is least bad. If PA with failover can be made robust enough and handle various scaling and failover issues, great. But if not then perhaps NPTv6 is the next least bad option.
", "time": "2023-03-27T02:06:55Z"}, {"author": "Michael Richardson", "text": "Adopt. This NAT64 for DNS64 resolver, while obvious once said, is also not obvious to many.
", "time": "2023-03-27T02:07:32Z"}, {"author": "Anthony Somerset", "text": "agreed
", "time": "2023-03-27T02:07:53Z"}, {"author": "Jared Mauch", "text": "if the Internet is for end-users, then that v6ops-site-multihoming and giving ULA equal v6 access for a NAT66/NAT-PT behavior would be of good value for the end-user networks that have the option to multi home.
", "time": "2023-03-27T02:08:01Z"}, {"author": "Anthony Somerset", "text": "the use case for this is any ISP network that wants or needs to go v6 only
", "time": "2023-03-27T02:10:54Z"}, {"author": "Mark Andrews", "text": "Operating with IPv4AAS is not realistic.
", "time": "2023-03-27T02:11:40Z"}, {"author": "Juliusz Chroboczek", "text": "Jared, I humbly beg to disagree. If we want to empower end-users, we need to give them a PD prefix per provider, so the host, not the network, can make routing decisions.
", "time": "2023-03-27T02:12:19Z"}, {"author": "Juliusz Chroboczek", "text": "It is tricky, but we should not aim for less.
", "time": "2023-03-27T02:12:44Z"}, {"author": "Jared Mauch", "text": "Yes, they can do NAT-PAT or PD within that, but with varying providers and capabilities, if you don't want the traffic to degrade to v4, ULA should likely get an upgrade.
", "time": "2023-03-27T02:13:37Z"}, {"author": "Michael Richardson", "text": "what document is this about?
", "time": "2023-03-27T02:14:57Z"}, {"author": "Jared Mauch", "text": "If we do what @Jen Linkova and @Lorenzo Colitti suggested and let each host get /64-PD and one provider offers /56 and another offers /60 and you detect a fail-over event, the end-host needs to know to ask for a /64 from each pool which introduces a lot more state downstream.
", "time": "2023-03-27T02:15:02Z"}, {"author": "Brian Carpenter", "text": "Thought we didn't have ad breaks at the IETF
", "time": "2023-03-27T02:16:21Z"}, {"author": "Jared Mauch", "text": "Hence my comment, we need to look at how these varying proposals may interoperate with each other, and how many variants need to be tested by host and network operators.
", "time": "2023-03-27T02:16:33Z"}, {"author": "Juliusz Chroboczek", "text": "Michael, the multihoming document. I'm claiming that address translation (whether stateful or stateless) is user-hostile, and that we need to develop better host behaviours for dealing with multiple prefixes being announced on the local link.
", "time": "2023-03-27T02:17:07Z"}, {"author": "Michael Richardson", "text": "this Verda/Line presentation has no document, but I think RFC 7755 ?
", "time": "2023-03-27T02:18:00Z"}, {"author": "Brian Carpenter", "text": "@Juliusz, much agreement but it truly isn't easy
", "time": "2023-03-27T02:18:22Z"}, {"author": "\u00c9ric Vyncke", "text": "It is common for V6OPS to have operational presentations w/o any draft
", "time": "2023-03-27T02:18:24Z"}, {"author": "Erik Nygren", "text": "I wonder whether using a combination of PA+ULA is an option for primary/fallback? That's what I've been meaning to try at home. (ie, in steady state have both, but when the primary fails then its PA gets withdrawn and the ULA remains and is stable when using the backup.) But we do need to focus on what actually works for users --- at least some of the backup provider options (eg, T-Mobile Home Internet which I have) only give a single /64 so I likely need to use NAT regardless during failover since I have multiple /64 subnets.
", "time": "2023-03-27T02:18:30Z"}, {"author": "Erik Nygren", "text": "(will send something to the list on this tomorrow)
", "time": "2023-03-27T02:18:58Z"}, {"author": "Juliusz Chroboczek", "text": "Erik, if you're not afraid of unclean hacks, Proxy-ND might be your friend. And if you're not afraid of the IETF's wrath, subnet longer than /64 and use DHCPv6.
", "time": "2023-03-27T02:20:34Z"}, {"author": "Jared Mauch", "text": "or the tiered DHCPv6-relay as well, with required SLAAC at each level, presumably with mandatory router-adverts, then with the the new P flag, is that required to pass through? Might be better to make the devices just pass their data through an upstream QUIC proxy based in the router and just be v6-only internal and let that QUIC proxy perform the behavior, but this would complete the kill of e2e, so is unlikely to be seen as acceptable
", "time": "2023-03-27T02:23:12Z"}, {"author": "Jared Mauch", "text": "@Juliusz Chroboczek but if we do the multihoming, and we also do the /64 per-device, one will see the PD become easily exhausted
", "time": "2023-03-27T02:23:12Z"}, {"author": "Lorenzo Colitti", "text": "The problem with ULA is that it dumps the cost on app developers, and the consequences (brittle connectivity, bad battery life) end up being borne by users
", "time": "2023-03-27T02:23:30Z"}, {"author": "Jared Mauch", "text": "and with some android devices using their own hard-coded application based DNS services, it's unclear if you could force them to do DoH unless we update the host RFCs to require passing data through the proxies and provide some trust method for your router.
", "time": "2023-03-27T02:23:33Z"}, {"author": "Michael Richardson", "text": "PLPMTUD is just always better... :-)
", "time": "2023-03-27T02:25:24Z"}, {"author": "Jared Mauch", "text": "@Lorenzo Colitti I live in an environment where our large software developer team continues to try to make their problems a network problem due to the lack of scale in their software architecture. :-)
\nIPv6 has an interesting situation where there's so many ways to do something, we can do them all, leading to the 2^n scale problem of testing
", "time": "2023-03-27T02:25:46Z"}, {"author": "Jared Mauch", "text": "Michael Richardson said:
\n\n\nPLPMTUD is just always better... :-)
\n
but if we make the application (or host) require passing through a upstream ALG aware proxy you can outsource the provider selection and honor the received MTU in NDP
", "time": "2023-03-27T02:27:22Z"}, {"author": "Michael Richardson", "text": "Seems like a success story. Thank you for sharing it!
", "time": "2023-03-27T02:30:25Z"}, {"author": "Jared Mauch", "text": "/64 is hardware optimized, so I understand the reluctance for any changes here, but it's also unclear what we should expect the global routing table size to scale to, so treating ULA equal to any other PA space has value.
", "time": "2023-03-27T02:30:32Z"}]