[{"author": "Bob Hinden", "text": "

Welcome to 6MAN

", "time": "2023-11-08T13:30:03Z"}, {"author": "Dhruv Dhody", "text": "

The draft name draft-ietf-6man would always give an impression that it is a wg document! I think marking them dead is important

", "time": "2023-11-08T13:40:52Z"}, {"author": "Jen Linkova", "text": "

Yes, we'll take care of un-adopting and marking them as dead ;)

", "time": "2023-11-08T13:42:02Z"}, {"author": "Erik Kline", "text": "

if we bikeshed \"64\" into inaction we'll be left with zero

\n

(not to say that 128 wouldn't be nicer, ...)

", "time": "2023-11-08T13:50:00Z"}, {"author": "\u00c9ric Vyncke", "text": "

If we set any number, then this will be the limit for a foreseeable future :-(

", "time": "2023-11-08T13:50:46Z"}, {"author": "\u00c9ric Vyncke", "text": "

And I am afraid that any BCP won't change the HW of deployed routers/devices in the Internet. (If only...)

", "time": "2023-11-08T13:51:47Z"}, {"author": "Anthony Somerset", "text": "

if its a minimum limit then i see thats OK - i mean its not like minimums are going to reduce, only get larger

", "time": "2023-11-08T13:52:00Z"}, {"author": "Eduard V", "text": "

Agree to Tim: better to call 64B as the minimum not maximum.

", "time": "2023-11-08T13:53:54Z"}, {"author": "\u00c9ric Vyncke", "text": "

+1 to Tim (both of them)

", "time": "2023-11-08T13:53:59Z"}, {"author": "Fernando Gont", "text": "

Is there evidence that 128-byte parsing buffer works now? Or is that more of a \"call for action\"?

", "time": "2023-11-08T13:56:57Z"}, {"author": "Bob Hinden", "text": "

Both, I thnk

", "time": "2023-11-08T13:57:18Z"}, {"author": "Fernando Gont", "text": "

URLs/links with supporting evidence? :-)

", "time": "2023-11-08T13:58:07Z"}, {"author": "Jen Linkova", "text": "

well, I know that routers which were not able to see \"TCP SYN\" in MPLS packets 15 years ago (because of 64 bytes lookup depth - can do much more now

", "time": "2023-11-08T13:58:13Z"}, {"author": "Stefan Ubbink", "text": "

would it be helpful to start with 64B and create an update RFC when more is needed?

", "time": "2023-11-08T14:00:37Z"}, {"author": "Fernando Gont", "text": "

Key is to spell out whether the requirement reflects current operational reality, or whether that's a call for action. If the former, please provide supporting evidence, if the latter... would a requirement really cause vendors to put money on it?

", "time": "2023-11-08T14:02:48Z"}, {"author": "Tom Herbert", "text": "

@fernando the APIC data suggests that 128 byte parsing buffer is supported. I will show some data in the EH removal presentation

", "time": "2023-11-08T14:03:40Z"}, {"author": "Eduard V", "text": "

for many year I did believe that 128B is the minimum buffer for headers processing. Would like to see evidence that 64B routers still exist.

", "time": "2023-11-08T14:04:15Z"}, {"author": "Jen Linkova", "text": "

If it's teh former, it might be really v6ops doc. If the latter - and it's a guidance for implementers, then I'm afraid they would read it as \"that's all I need to support\". In that casde publishing -bis later wouldn't help for a few years.

", "time": "2023-11-08T14:04:37Z"}, {"author": "Jen Linkova", "text": "
\n

Would like to see evidence that 64B routers still exist.

\n
\n

There is always an old hardware somewhere...As I've said, my home CPE which costs < $50 is a router as well

", "time": "2023-11-08T14:05:29Z"}, {"author": "\u00c9ric Vyncke", "text": "

@Jen +1

", "time": "2023-11-08T14:05:42Z"}, {"author": "Ole Tr\u00f8an", "text": "

9268 is 8 bytes. It's a long way to 64. IPv4 has a limit upper and lower at 40

", "time": "2023-11-08T14:05:53Z"}, {"author": "Eduard V", "text": "

I am sure that at least 3 primary vendors promise 384Bytes on real products for many years (5+).

", "time": "2023-11-08T14:06:34Z"}, {"author": "Tom Herbert", "text": "

@jen I'm not sure that vendors will automatically jump to the conclusion that a minimum limit is also the maximum. 1280 bytes is the minimum MTU for IPv6, but I don;t believe that's commonly viewed as the maximum MTU needed to be implemented

", "time": "2023-11-08T14:07:08Z"}, {"author": "\u00c9ric Vyncke", "text": "

@Tom this is where we disagree ;-)

", "time": "2023-11-08T14:08:19Z"}, {"author": "Ole Tr\u00f8an", "text": "

Vendors will implement parsing buffers as deep as are required for use cases. Having a minimum limit is useful to provide in RFQs

", "time": "2023-11-08T14:08:50Z"}, {"author": "\u00c9ric Vyncke", "text": "

@Ole, then RFQ will put 64 bytes and will draw the market to the bottom bar

", "time": "2023-11-08T14:09:44Z"}, {"author": "Fernando Gont", "text": "

+1 to what Ole said.

", "time": "2023-11-08T14:10:04Z"}, {"author": "Jen Linkova", "text": "

@Tom all cases I've come across where \"we can look X bytes deep, and can do Y lookups\" - X and Y is hw dependant and have nothing to do with RFCs - and in a few years those numbers changed. Back in 2010 they can not look past the first header anyway, now they can..

", "time": "2023-11-08T14:10:19Z"}, {"author": "Tom Herbert", "text": "

@ole the use cases currently motivating larger parsing buffers is more likely to be encapasulation headers (far more deployed than EH, SRH might be changing that)

", "time": "2023-11-08T14:10:25Z"}, {"author": "Tom Herbert", "text": "

@jen I agree. Router capabalities have been implemented without regard to RFCs. Part of the reason is because IETF never provided guidance in this area

", "time": "2023-11-08T14:12:17Z"}, {"author": "Jen Linkova", "text": "

whatever we say in RFCs - if someone want to use EHs they would need to have a HE-like fallback.

", "time": "2023-11-08T14:13:30Z"}, {"author": "Fernando Gont", "text": "

@tom: I'm keen to the idea of settilng to some minium if the other options is getting nothing. However, I'm really curious if even suggesting x value would make a difference without a supporting use case..

", "time": "2023-11-08T14:14:24Z"}, {"author": "Erik Kline", "text": "

has anyone implemented this or unittested a policy table parser to verify behaviour?

", "time": "2023-11-08T14:15:09Z"}, {"author": "Tom Herbert", "text": "

@fernando If the APNIC data is correct, this would be specifying a limit that's already common supported in the Internet. The outliers could then be addressed

", "time": "2023-11-08T14:15:55Z"}, {"author": "Fernando Gont", "text": "

If that's not already linked in the doc, please do!

", "time": "2023-11-08T14:16:46Z"}, {"author": "Bob Hinden", "text": "

There are some newer measurements in the references in the HBH processing draft.

", "time": "2023-11-08T14:17:44Z"}, {"author": "Bob Hinden", "text": "

cus23a and cus23b

", "time": "2023-11-08T14:18:17Z"}, {"author": "Fernando Gont", "text": "

Isn't MUST the way to go when otherwhise stuff would break? -- if so, it seems this is the case...

", "time": "2023-11-08T14:29:09Z"}, {"author": "Fernando Gont", "text": "

thanks bob! (will read!)

", "time": "2023-11-08T14:29:57Z"}, {"author": "Anthony Somerset", "text": "

i think its high time to start moving this stuff towards MUST - we really need to make it easier to make IPv4 go away and agree this is one way to help it

", "time": "2023-11-08T14:33:25Z"}, {"author": "Jen Linkova", "text": "

@fernando - I think that's why this requirement is a borderline: things will break w/o that MUST - but there is a scenario (like, I don't know, a server in DC). -where the subnet never changes unexpectedly, so in those cases it's not required

", "time": "2023-11-08T14:33:54Z"}, {"author": "Jeremy Duncan", "text": "

as I did as well with Windows

", "time": "2023-11-08T14:34:33Z"}, {"author": "Nick Buraglio", "text": "

I agree with Lorenzo that if we don't do it, when would we? I am also not opposed to authoring a second document, which was the original idea of making this draft much more simple in order top pass quickly

", "time": "2023-11-08T14:35:23Z"}, {"author": "Fernando Gont", "text": "

We pretend that ipv6 supports multihoming. Without RFC8028, multihoming is super broken. --I believe this is what this boils down to. -- maybe argues to be moved into a separate document, or keep it here. But needs to be done.

", "time": "2023-11-08T14:35:30Z"}, {"author": "Erik Nygren", "text": "

I'd strongly encourage some extensive testing on a range of OSes on home networks with a range of Matter/Thread gateways on-net. I suspect is rapidly changing the profile for how many home networks are seeing ULA advertisements on-link.

", "time": "2023-11-08T14:35:48Z"}, {"author": "Nick Buraglio", "text": "

That is a great idea. I wonder if we can conscript Tim W. in to help =)

", "time": "2023-11-08T14:38:11Z"}, {"author": "Timothy Winters", "text": "

I think between myself and my friends at the UNH-IOL we could represent on this.

", "time": "2023-11-08T14:50:40Z"}, {"author": "Anthony Somerset", "text": "

thanks for clarifying the differences!

", "time": "2023-11-08T14:52:10Z"}, {"author": "Bob Hinden", "text": "

Thanks Tim

", "time": "2023-11-08T14:52:16Z"}, {"author": "Tom Herbert", "text": "

Thankyou for the NAT terminolgy slide!

", "time": "2023-11-08T14:52:22Z"}, {"author": "Erik Nygren", "text": "

Do we need a better term (and perhaps draft) for 6:6 NAT that is stateful address translation for handling cases where there is a prefix length mismatch?

", "time": "2023-11-08T14:53:01Z"}, {"author": "\u00c9ric Vyncke", "text": "

@Erik something like NAPT66 ?

", "time": "2023-11-08T14:54:12Z"}, {"author": "Erik Nygren", "text": "

But without port translation.

", "time": "2023-11-08T14:54:44Z"}, {"author": "Erik Nygren", "text": "

NAAT66? NAAAAT66?

", "time": "2023-11-08T14:55:22Z"}, {"author": "Jen Linkova", "text": "

NOOOO66 ;)

", "time": "2023-11-08T14:55:34Z"}, {"author": "Bob Hinden", "text": "

NONAT66 :-)

", "time": "2023-11-08T14:56:59Z"}, {"author": "\u00c9ric Vyncke", "text": "

I love the 6MAN chairs !

", "time": "2023-11-08T14:58:41Z"}, {"author": "Jen Linkova", "text": "

I'm in this chat on my personal capacity! WWE need a hat on/hat-off emoji

", "time": "2023-11-08T15:00:13Z"}, {"author": "Jen Linkova", "text": "

:cowboy: so this is hat-on

", "time": "2023-11-08T15:00:33Z"}, {"author": "Tom Herbert", "text": "

@jen that's a good idea. It would also be nice if lables for the chairs and ADs were added next to their name. That way I'd know which messages to pay attention to :-)

", "time": "2023-11-08T15:03:39Z"}, {"author": "Fernando Gont", "text": "

Would not make it std prevent people from doing this?

", "time": "2023-11-08T15:04:09Z"}, {"author": "Eduard V", "text": "

Would \"experimental\" really affect implementations? They would probably proliferate anyway.

", "time": "2023-11-08T15:04:34Z"}, {"author": "Nick Buraglio", "text": "

The implementations are already there, that is kinda the point.

", "time": "2023-11-08T15:04:57Z"}, {"author": "Anthony Somerset", "text": "

Fernando Gont said:

\n
\n

Would not make it std prevent people from doing this?

\n
\n

no its already experimental so people are free to implement it (or not)

", "time": "2023-11-08T15:04:59Z"}, {"author": "Jen Linkova", "text": "

The status does send some message

", "time": "2023-11-08T15:05:19Z"}, {"author": "Fernando Gont", "text": "

Exactly. why do we keep calling it experimental, if it's largely employed in production?

", "time": "2023-11-08T15:05:29Z"}, {"author": "Anthony Somerset", "text": "

i don't object on the basis that it is whether we like it or not - implemented by some (many?) vendors

", "time": "2023-11-08T15:05:35Z"}, {"author": "Jen Linkova", "text": "

there is a difference between how std vs experimental are perceived

", "time": "2023-11-08T15:05:59Z"}, {"author": "Nick Buraglio", "text": "

Those requirement lists are already there.

", "time": "2023-11-08T15:06:08Z"}, {"author": "Anthony Somerset", "text": "

we need a standards document that deprecates all types of NAT in V6 :)

", "time": "2023-11-08T15:06:26Z"}, {"author": "Jen Linkova", "text": "

if they are already there, then we do not need a std, right?

", "time": "2023-11-08T15:06:47Z"}, {"author": "Behcet Sarikaya", "text": "

+1 to Anthony

", "time": "2023-11-08T15:07:11Z"}, {"author": "Erik Nygren", "text": "

Pragmatically this (NPTv6) won't help in multihoming scenarios where the prefix lengths differ (eg, for failing over from a primary-to-backup). That's the case where 6:6 NAT is still going to be needed, and that's also the scenario where other options (like conditional RA) don't help on their own.

", "time": "2023-11-08T15:08:01Z"}, {"author": "Markus Stenberg", "text": "

It is long ago implemented by existing stuff, but if it reduces odds of it winding up as configuration knob / implementation item in new implementations, I'm all for not making it standard.

\n

It is likely that someone somewhere considers 'experimental' less required than 'standard', and as the improvements proposed to the actual text are quite small I don't see it worth the pain of potentially more NAT action in the network.

", "time": "2023-11-08T15:09:44Z"}, {"author": "Nick Buraglio", "text": "

I think the real point is that the experiment was pretty demonstrably a success based on the commercially supported options and production deployments. Moving it to standards track codifies the end of the experiment, denotes the result.

", "time": "2023-11-08T15:12:10Z"}, {"author": "Ole Tr\u00f8an", "text": "

Erik: NPTv6 supports different prefix lengths for multi-homing, but inside network has to use the longest prefix length on inside.

", "time": "2023-11-08T15:13:20Z"}, {"author": "Nick Buraglio", "text": "

It doesn't really change how the implementations will proliferate, that was part of the experiment that is pretty measurably successful. The peole that want it will still ask, and receive it.

", "time": "2023-11-08T15:13:47Z"}, {"author": "Nick Buraglio", "text": "

yes, different prefix lengths are definitely doable, they're just operationally more complex to do. Netmap has some examples of how to do it.

", "time": "2023-11-08T15:15:04Z"}, {"author": "Bob Hinden", "text": "

More recent measurements show different conclusions from the APNIC measurements cited.

", "time": "2023-11-08T15:16:43Z"}, {"author": "Eduard V", "text": "

SPRING already deletes routing headers in transit. Not much different from deleting HbH.

", "time": "2023-11-08T15:16:49Z"}, {"author": "Ole Tr\u00f8an", "text": "

NAT does ICMP ALGs so that's not quite true

", "time": "2023-11-08T15:17:25Z"}, {"author": "\u00c9ric Vyncke", "text": "

@Jen you can still do HbH measurements over the public Internet if your probes do not traverse routers doing this function

", "time": "2023-11-08T15:19:06Z"}, {"author": "Erik Nygren", "text": "

Ole Tr\u00f8an said:

\n
\n

Erik: NPTv6 supports different prefix lengths for multi-homing, but inside network has to use the longest prefix length on inside.

\n
\n

Which doesn't help pragmatically if the longest prefix length is a /64 and there is a need for multiple subnets. (I lack the ability to write \"must support larger than /64 PD\" into an RFP for T-Mobile Home Internet which is what I've been told it would take in my case.)

", "time": "2023-11-08T15:19:32Z"}, {"author": "Ole Tr\u00f8an", "text": "

Erik: But then you have the same problem without NPTv6. You could of course only do NPTv6 on the backup path too.

", "time": "2023-11-08T15:20:24Z"}, {"author": "Tom Herbert", "text": "

Routing headers would only be dropped is segments left is zero

", "time": "2023-11-08T15:21:14Z"}, {"author": "Tom Herbert", "text": "

Removed that is

", "time": "2023-11-08T15:21:21Z"}, {"author": "Ole Tr\u00f8an", "text": "

Tom: Apart from ICMP errors, AH would break too, right? Can't think of anything else.

", "time": "2023-11-08T15:22:32Z"}, {"author": "Tom Herbert", "text": "

@ole yes, we can't remove HBH or RH if AH is present (in practice probably would matter since the outcome would be packet is dropped like they are already)

", "time": "2023-11-08T15:23:59Z"}, {"author": "Ole Tr\u00f8an", "text": "

Took me an iteration to recall that the payload length is not part of the pseudo header. Therefore no checksum update required.

", "time": "2023-11-08T15:25:49Z"}, {"author": "Tom Herbert", "text": "

Thanks WG chairs for another great session!

", "time": "2023-11-08T15:26:27Z"}]