[{"author": "Tobias Fiebig", "text": "

<topic create>

", "time": "2023-07-25T22:02:41Z"}, {"author": "Antoine Fressancourt", "text": "

No slides are shared, is it normal ?

", "time": "2023-07-25T22:11:09Z"}, {"author": "\u00c9ric Vyncke", "text": "

no slide indeed for now

", "time": "2023-07-25T22:11:26Z"}, {"author": "Antoine Fressancourt", "text": "

ok

", "time": "2023-07-25T22:11:30Z"}, {"author": "Anthony Somerset", "text": "

remote audio is quiet - can we turn it up or ask waldemar to speak up?

", "time": "2023-07-25T22:12:55Z"}, {"author": "Lorenzo Miniero", "text": "

Better now?

", "time": "2023-07-25T22:13:19Z"}, {"author": "Antoine Fressancourt", "text": "

Too close now

", "time": "2023-07-25T22:13:44Z"}, {"author": "Ole Tr\u00f8an", "text": "

Too close

", "time": "2023-07-25T22:13:59Z"}, {"author": "Antoine Fressancourt", "text": "

The sound is saturated

", "time": "2023-07-25T22:14:03Z"}, {"author": "Ole Tr\u00f8an", "text": "

Not too loud... just garbled... ;-)

", "time": "2023-07-25T22:14:34Z"}, {"author": "Anthony Somerset", "text": "

it will have to do better now

", "time": "2023-07-25T22:14:45Z"}, {"author": "Antoine Fressancourt", "text": "

it is ok now

", "time": "2023-07-25T22:14:49Z"}, {"author": "Juan-Carlos Z\u00fa\u00f1iga", "text": "

good, thanks

", "time": "2023-07-25T22:14:59Z"}, {"author": "Mohamed Boucadair", "text": "

No sure how this will speed up IPv6 adoption

", "time": "2023-07-25T22:17:24Z"}, {"author": "Eduard V", "text": "

+1

", "time": "2023-07-25T22:18:20Z"}, {"author": "\u00c9ric Vyncke", "text": "

You can always ask the Q

", "time": "2023-07-25T22:18:42Z"}, {"author": "Anthony Somerset", "text": "

i am strongly against any protocol or standard that proposes to attempt to extend the lifespan of IPv4 with more NAT type workarounds

", "time": "2023-07-25T22:20:34Z"}, {"author": "Eduard V", "text": "

Up to now looks like IPv10

", "time": "2023-07-25T22:22:46Z"}, {"author": "Dan Voyer", "text": "

Agree with Anthony S. on that

", "time": "2023-07-25T22:24:17Z"}, {"author": "Tobias Fiebig", "text": "

So, what my head wraps around this does not sound tooooo useless (besides its use in Anthony's point).

\n

But even in a v6 only environment, it would be a way to indicate paths for a) unrouted or b) firewalled addresses;

\n

It somewhat makes sense esp. if paired with rdns.

\n

So, for example, you have a /48 for an endsite, and want to redirect inbound connectivity through a LB (possibly different per, e.g., /64)

", "time": "2023-07-25T22:27:04Z"}, {"author": "Tobias Fiebig", "text": "

a bit like srv-for-stun. :thinking:

", "time": "2023-07-25T22:27:29Z"}, {"author": "Tobias Fiebig", "text": "

not sure though if that is the intention of the draft

", "time": "2023-07-25T22:27:41Z"}, {"author": "Tom Herbert", "text": "

Embedding parts of the address in UDP tunnels seems to be layering issue and not scalable. This information really needs to be at network later, hence extension headers

", "time": "2023-07-25T22:28:46Z"}, {"author": "Antoine Fressancourt", "text": "

I get the fact that it is useful for users locked behind a proxy, my concern is that most proxies are not as collaborative as in Masque use case

", "time": "2023-07-25T22:40:26Z"}, {"author": "Josh Cohen", "text": "

Which list is that?

", "time": "2023-07-25T22:45:17Z"}, {"author": "Antoine Fressancourt", "text": "

I wonder what is the compared complexity of introducing a new ether type Vs. filtering SRv6 EH on outbound ports

", "time": "2023-07-25T22:53:08Z"}, {"author": "Eduard V", "text": "

New ethertype would break interoperability with IPv6

", "time": "2023-07-25T22:53:25Z"}, {"author": "Antoine Fressancourt", "text": "

That answers my question :-)

", "time": "2023-07-25T22:54:02Z"}, {"author": "Tony Li", "text": "

That's the point.

", "time": "2023-07-25T22:54:03Z"}, {"author": "Juliusz Chroboczek", "text": "

Perhaps RFC 3514 would be more interoperable?

", "time": "2023-07-25T22:55:22Z"}, {"author": "Eduard V", "text": "

Mybe better to return SRH as a requirement for SRv6, not to break interoperability with Ipv6

", "time": "2023-07-25T22:56:45Z"}, {"author": "Darren Dukes", "text": "

Still not sold on why filtering on the prefix that SRv6 SIDs are allocated from, which is a single Prefix match (not a longest prefix match) is difficult to verify in deployments vs enabling/disabling an ethertype on an interface.

", "time": "2023-07-25T22:59:52Z"}, {"author": "Antoine Fressancourt", "text": "

If we follow this thread, what would prevent an operator from using a set of ethertypes to signal a given filtering policy in its domain ?

", "time": "2023-07-25T23:08:55Z"}, {"author": "Juliusz Chroboczek", "text": "

Naive question (not for mic): why is that more convenient than setting the I bit and obtaining the info over DHCPv6 INFORM?

", "time": "2023-07-25T23:22:39Z"}]