[{"author": "Joel Halpern", "text": "

The IPR rules paraphrase was little misleading.

", "time": "2025-03-19T06:01:54Z"}, {"author": "George Michaelson", "text": "

Also unneccessary: \"I assume you can all read\" covers this

", "time": "2025-03-19T06:03:40Z"}, {"author": "Tommy Jensen", "text": "

Declined attendance is probably due to IPv6 related problems basically all being solved. Happily Ever After.

", "time": "2025-03-19T06:04:11Z"}, {"author": "Joel Halpern", "text": "

@George Michaelson - personally I like a quick list of the topics, but not a paraphrase of the content. So \"Code of Conduct, IPR, ....\" in one sentence.

", "time": "2025-03-19T06:04:58Z"}, {"author": "Martin Horneffer", "text": "

+1 to Tommy, IPv6 is just running (well enough)

", "time": "2025-03-19T06:05:25Z"}, {"author": "\u00c9ric Vyncke", "text": "

+1 to Jen, let's wait Madrid IPv6-mostly on the default SSID ;-)

", "time": "2025-03-19T06:05:50Z"}, {"author": "Mark Andrews", "text": "

@meetecho the gain on the chairs mike is too high and we are getting clipping

", "time": "2025-03-19T06:06:55Z"}, {"author": "Lorenzo Miniero", "text": "

@Mark Andrews do you mean in the room or for remote attendees?

", "time": "2025-03-19T06:07:33Z"}, {"author": "Mark Andrews", "text": "

the room.

", "time": "2025-03-19T06:07:51Z"}, {"author": "Lorenzo Miniero", "text": "

Is it better now?

", "time": "2025-03-19T06:08:16Z"}, {"author": "Mark Andrews", "text": "

A bit

", "time": "2025-03-19T06:08:24Z"}, {"author": "George Michaelson", "text": "

I am uncomfortable with passing over the duties of being a highly paid subject matter expert in IPv6 to a machine. We need a union.

", "time": "2025-03-19T06:08:25Z"}, {"author": "\u00c9ric Vyncke", "text": "

Curious about the set of Q asked to LLM... If about which RFC defines this bit, then I will have 0%

", "time": "2025-03-19T06:08:34Z"}, {"author": "Mark Andrews", "text": "

room mike is fine

", "time": "2025-03-19T06:08:52Z"}, {"author": "Lorenzo Miniero", "text": "

We decreased the global gain a bit: we'll monitor and in case further tweaking is needed we'll notify the AV team

", "time": "2025-03-19T06:09:49Z"}, {"author": "Mark Andrews", "text": "

thanks

", "time": "2025-03-19T06:10:01Z"}, {"author": "George Michaelson", "text": "

You cannot spell \"co pilot\" in V6 address HEX

", "time": "2025-03-19T06:11:02Z"}, {"author": "Tommy Jensen", "text": "

Don't worry George, I'll tell Satya we can shove AI into the IETF and our marketing will cook something up

", "time": "2025-03-19T06:13:14Z"}, {"author": "Tommy Jensen", "text": "

Serious expansion on my point: questions LLMs can't answer that humans can are apparently under-documented, and the other way around can identify \"common myths\"

", "time": "2025-03-19T06:14:20Z"}, {"author": "Tobias Fiebig", "text": "

I partially agree with the chairs last statement. Which goes directly to my point. The issue are the nuances going subtly wrong which can then only be discovered by a _very_ experienced engineer.

", "time": "2025-03-19T06:15:46Z"}, {"author": "Joel Halpern", "text": "

I can see the value in findign the common errors on both sides of that.

", "time": "2025-03-19T06:16:02Z"}, {"author": "Tobias Fiebig", "text": "

maybe it might make sense to consider evaluating an RG focused on investigating uses of LLMs in this context.

", "time": "2025-03-19T06:17:48Z"}, {"author": "Tom Hill", "text": "

My initial thoughts about this LLM vs. Human's topic (when I spoke to XiPeng previously) were along the lines of 'we should not be configuring things in live networks, no matter if we use humans or LLMs'. The industry has known for some time that we should have configuration built, tested, and treated as code; changes tracked, automation for testing and deployment, monitoring for faults and automated rollbacks. If you can fit LLMs in there as an advisory tool, or a reference, great. But I think it's a mistake to think of the ideal situation being one where speed is important. I think we're doing something wrong if that's the problem we need to solve.

", "time": "2025-03-19T06:32:35Z"}, {"author": "Mark Andrews", "text": "

Dual stack lite works with a single address. Just saying.

", "time": "2025-03-19T06:32:44Z"}, {"author": "\u00c9ric Vyncke", "text": "

@Lorenzo, after 2Nd thinking, PS is better indeed than BCP

", "time": "2025-03-19T06:33:41Z"}, {"author": "Tommy Jensen", "text": "

I was confused at first (the link to this draft in the agenda is to a different draft): https://datatracker.ietf.org/doc/draft-ietf-v6ops-framework-md-ipv6only-underlay/

", "time": "2025-03-19T06:43:20Z"}, {"author": "Philipp Tiesel", "text": "

@Jen / @Tommy / @Lorenzo \u2013 on the CLAT single /128 issue, we should definitely have a fireside chat wit Nick and some friends from the IPv6 consulting community \u2013 from my own experience, this is a real organizational deployment obstacle, but I would really love to hear from people who have more clients how large they see it.

", "time": "2025-03-19T06:45:19Z"}, {"author": "\u00c9ric Vyncke", "text": "

@tommy, I fell in the same trap ;-)

", "time": "2025-03-19T06:47:08Z"}, {"author": "Tommy Jensen", "text": "

@Philipp: in my day job (Microsoft) I see this as well, but we actively push our customers to move off of 1 x /128 deployments for this and other reasons as well as to avoid having stateful CLAT in upcoming versions of Windows.

", "time": "2025-03-19T06:47:27Z"}, {"author": "Tommy Jensen", "text": "

@\u00c9ric :)

", "time": "2025-03-19T06:47:44Z"}, {"author": "\u00c9ric Vyncke", "text": "

RFC 7050 was from BEHAVE WG in Transport Area ;-)

", "time": "2025-03-19T06:48:23Z"}, {"author": "Tommy Jensen", "text": "

Which complicated my life finding an audience for the draft, definitely. Just IETF things

", "time": "2025-03-19T06:48:58Z"}, {"author": "Philipp Tiesel", "text": "

@Tommy: perhaps we need another document explaining why single /128 is a bad to motivate shaking up corporate security departments and de-silo dhcp and routing teams.

", "time": "2025-03-19T06:52:02Z"}, {"author": "Philipp Tiesel", "text": "

@Tommy: Does windows request multiple IN_NAs via DHCPv6?

", "time": "2025-03-19T06:52:11Z"}, {"author": "\u00c9ric Vyncke", "text": "

Nothing prevent a host to request 2 DHCPv6 addresses though (of course, the checksum will have to be recomputed)

", "time": "2025-03-19T06:52:45Z"}, {"author": "Tommy Jensen", "text": "

@Lorenzo: what was the BCP for \"thou shalt not 1 x /128\" again? I'm guessing that's the doc you are looking for Philipp, but admittedly I have not read it yet

", "time": "2025-03-19T06:53:19Z"}, {"author": "Tommy Jensen", "text": "

I don't recall if Windows does this now, I'm too focused on what is upcoming and am worried I will misspeak

", "time": "2025-03-19T06:53:49Z"}, {"author": "Tommy Jensen", "text": "

@\u00c9ric exactly, hence requesting multiple /128s really isn't ideal (though better than overloading one address)

", "time": "2025-03-19T06:54:41Z"}, {"author": "\u00c9ric Vyncke", "text": "

192.0.0.8 coming from RFC 7600 \"IPv4 Residual Deployment via IPv6 - A Stateless Solution (4rd)\"

", "time": "2025-03-19T07:04:30Z"}, {"author": "\u00c9ric Vyncke", "text": "

And there will soon be a \"Dummy IPv6 Prefix\" for similar cases per draft-ietf-mpls-p2mp-bfd ;-)

", "time": "2025-03-19T07:08:47Z"}, {"author": "Tommy Jensen", "text": "

\"Misunderstanding Enthusiast\" better be in the ribbon basket in Madrid

", "time": "2025-03-19T07:12:32Z"}, {"author": "Mark Andrews", "text": "

0.0.0.0 would work as the source address

", "time": "2025-03-19T07:12:58Z"}, {"author": "\u00c9ric Vyncke", "text": "

@Mark how many routers will drop this 0/0 address as source ?

", "time": "2025-03-19T07:13:39Z"}, {"author": "Mark Andrews", "text": "

They shouldn't if they are RFC compliant.

", "time": "2025-03-19T07:14:23Z"}, {"author": "Mark Andrews", "text": "

0.0.0.0 is a valid source address if you are not expecting a reply

", "time": "2025-03-19T07:15:01Z"}, {"author": "Mark Andrews", "text": "

This was specified when IPv4 was specified.

", "time": "2025-03-19T07:15:58Z"}, {"author": "\u00c9ric Vyncke", "text": "

So, it seems that my knowledge of IP is mainly about IPv6 ;-)
\nAnd indeed RFC 5735 section section 3 says that 0/8 can be used as a source to destination on THIS network, i.e., cannot be routed

", "time": "2025-03-19T07:18:19Z"}, {"author": "Jen Linkova", "text": "

Imho 192.0.0.8 is better than 0.0.0.0: the former is clearly defined as a dummy address, so people who do not even know about that can find out what is happening. If your traveroute shows you 0.0.0.0 is would be very confusing, imho

", "time": "2025-03-19T07:18:39Z"}, {"author": "\u00c9ric Vyncke", "text": "

@Jen +1

", "time": "2025-03-19T07:18:51Z"}, {"author": "Dave Plonka", "text": "

@jen +1

", "time": "2025-03-19T07:19:12Z"}, {"author": "\u00c9ric Vyncke", "text": "

Tim & David are your questions for now ?

", "time": "2025-03-19T07:22:21Z"}, {"author": "Timothy Winters", "text": "

Mine is a comment on this scenario

", "time": "2025-03-19T07:22:39Z"}, {"author": "XiPeng Xiao", "text": "

do you want to ask it now?

", "time": "2025-03-19T07:22:50Z"}, {"author": "Timothy Winters", "text": "

Maybe before he goes to the next slide?

", "time": "2025-03-19T07:22:56Z"}, {"author": "XiPeng Xiao", "text": "

ok

", "time": "2025-03-19T07:23:04Z"}, {"author": "Erik Kline", "text": "

Isn't this basically what PVDs are for?

", "time": "2025-03-19T07:23:22Z"}, {"author": "\u00c9ric Vyncke", "text": "

@Erik I think so ;-)

", "time": "2025-03-19T07:23:35Z"}, {"author": "Erik Kline", "text": "

What, then, is new?

", "time": "2025-03-19T07:24:14Z"}, {"author": "Jen Linkova", "text": "

Yes, I think so

", "time": "2025-03-19T07:24:16Z"}, {"author": "Philipp Tiesel", "text": "

PvDs are there to spell out the details / preferences. This is the default case when these do not match

", "time": "2025-03-19T07:24:30Z"}, {"author": "Tom Hill", "text": "

They're mentioned in the spec document, @Timothy Winters https://datatracker.ietf.org/doc/draft-gont-6man-multi-ipv6-spec/

", "time": "2025-03-19T07:25:17Z"}, {"author": "\u00c9ric Vyncke", "text": "

For people, like me, bad with RF numbers... RFC 8028 = \"First-Hop Router Selection by Hosts in a Multi-Prefix Network\"

", "time": "2025-03-19T07:26:35Z"}, {"author": "Timothy Winters", "text": "

Thanks Tom, I was thinking about the v6ops draft that doesn't mention if RIO are present in some these scenarios

", "time": "2025-03-19T07:26:43Z"}, {"author": "Erik Kline", "text": "

We had implicit PVDs for things like this

", "time": "2025-03-19T07:28:45Z"}, {"author": "Geoff Huston", "text": "

I'm struggling to understand why this is different from the site multi-homing work from 2005 or so, leading to RFC5533, RFC5534 and RFC5535

", "time": "2025-03-19T07:33:11Z"}, {"author": "Philipp Tiesel", "text": "

@Geoff: there are some semantic holes in RFC5533, RFC5534 and RFC5535 \u2013 this work tries to fill them

", "time": "2025-03-19T07:35:54Z"}, {"author": "Geoff Huston", "text": "

Like I said, I'm struggling to get context here, and, yes, I am struggling to understsand what the \"semantic holes\" where in SHIM6

", "time": "2025-03-19T07:37:37Z"}, {"author": "Philipp Tiesel", "text": "

Just because it was painful 15 years ago and did not take off back then, this does not mean it will not take off now. Some ideas need time to find adoption or mindsets to change. Most probably, the work back then was not useless, but definitely will need updating to the current terminology and slightly changed needs.

", "time": "2025-03-19T07:45:51Z"}, {"author": "Fernando Gont", "text": "

@geoff: as per https://datatracker.ietf.org/doc/html/rfc5533#page-23 , SHIM6 does specify a new wireprotocol and message format, if i understand correctly. As noted, my idea is not to follow that path...

", "time": "2025-03-19T07:47:31Z"}, {"author": "\u00c9ric Vyncke", "text": "

Slide 9: Home traffic, I do not agree most CPE / phones do support IPv6

", "time": "2025-03-19T07:49:00Z"}, {"author": "Fernando Gont", "text": "

@Erik: PvD does way more than this, and it really focuses on explicit PvDs. Section 2.3 of RFC7556 says: By default, implicit PvDs are limited to the network configuration
\n information received on a single interface, and by default, one such
\n PvD is formed for each interface. If additional information is
\n available to the host (through mechanisms out of scope of this
\n document), the host may form implicit PvDs with different
\n granularity.

", "time": "2025-03-19T07:50:55Z"}, {"author": "Philipp Tiesel", "text": "

Everything Fernando suggests is fixable in host or SME router behavior by separating information and doing src-dst-routing in that limited domain.

", "time": "2025-03-19T07:50:57Z"}, {"author": "XiPeng Xiao", "text": "

overall, in a home environment, the CPEs' support for IPv6 is worse than the mobile phones'

", "time": "2025-03-19T07:51:40Z"}]