Those are too busy playing chess :-)
", "time": "2023-07-27T20:01:48Z"}, {"author": "Kyle Rose", "text": "Multi-pass?
", "time": "2023-07-27T20:28:20Z"}, {"author": "Erik Nygren", "text": "Are L3-only cloud provider networks in-scope / a use-case for this NBA draft? That seems to be a very common case for the public IPv6 networking in many cloud hosting providers as they don't actually want to expose L2 broadcast domains and/or are using networking models with an underlay and again no broadcast domain.
", "time": "2023-07-27T20:31:11Z"}, {"author": "Kyle Rose", "text": "Time check: there is only about 1 minute more allocated for this before we're running late
", "time": "2023-07-27T20:43:42Z"}, {"author": "Jen Linkova", "text": "yep.
", "time": "2023-07-27T20:43:57Z"}, {"author": "\u00c9ric Vyncke", "text": "Said Mr. Pecha Kucha ;-)
", "time": "2023-07-27T20:44:02Z"}, {"author": "Erik Nygren", "text": "Do we need an IPv6 equivalent of rfc8499. (ie, a terminology doc that summarizes) ?
", "time": "2023-07-27T20:44:06Z"}, {"author": "Kyle Rose", "text": "\u00c9ric Vyncke said:
\n\n\nSaid Mr. Pecha Kucha ;-)
\n
We finished like 3 minutes early ;-)
", "time": "2023-07-27T20:44:40Z"}, {"author": "Jen Linkova", "text": "It was because one presenter didn't say a word and was only waiving hands!
", "time": "2023-07-27T20:45:11Z"}, {"author": "Jen Linkova", "text": ";)
", "time": "2023-07-27T20:45:22Z"}, {"author": "Kyle Rose", "text": "LET THAT BE A LESSON to all IETF presenters
", "time": "2023-07-27T20:45:26Z"}, {"author": "\u00c9ric Vyncke", "text": ";)
", "time": "2023-07-27T20:45:27Z"}, {"author": "Jen Linkova", "text": "for the record: I did make some suggestions re: the presentation format yesterday ;)
", "time": "2023-07-27T20:46:36Z"}, {"author": "Kyle Rose", "text": "If I am ever IETF chair, I will mandate that all WG presentations be in PK form
", "time": "2023-07-27T20:47:40Z"}, {"author": "Jen Linkova", "text": "That's good to know, when are you getting nominated?
", "time": "2023-07-27T20:48:13Z"}, {"author": "Kyle Rose", "text": "I'm on nomcom, and even I wouldn't select me for IETF chair ;-)
", "time": "2023-07-27T20:48:41Z"}, {"author": "Kyle Rose", "text": "As the world's foremost authority on my own positions... I would know better
", "time": "2023-07-27T20:49:13Z"}, {"author": "\u00c9ric Vyncke", "text": "And Lars' term is until 2025 ;-)
", "time": "2023-07-27T20:49:27Z"}, {"author": "Kyle Rose", "text": "details, details...
", "time": "2023-07-27T20:50:11Z"}, {"author": "\u00c9ric Vyncke", "text": "Unsure whether \"update\" is really correct
", "time": "2023-07-27T20:53:16Z"}, {"author": "\u00c9ric Vyncke", "text": "All that is needed is update https://www.iana.org/assignments/icmpv6-parameters/icmpv6-parameters.xhtml#icmpv6-parameters-codes-17 with \"specification required\", informational would be enough
", "time": "2023-07-27T20:54:07Z"}, {"author": "Antoine Fressancourt", "text": "IMHO, the security excuse is, well, an excuse
", "time": "2023-07-27T21:01:31Z"}, {"author": "\u00c9ric Vyncke", "text": "Relaxing the semantic of the first 2 bits of \"option type\" will also expand the amount of options
", "time": "2023-07-27T21:05:20Z"}, {"author": "Kyle Rose", "text": "2m left to stay on schedule
", "time": "2023-07-27T21:13:02Z"}, {"author": "Dave Thaler", "text": "yeah how would a constrained node support this MUST? I don't see how that can work.
", "time": "2023-07-27T21:20:08Z"}, {"author": "Dave Thaler", "text": "similar on #3, possibly too burden some for a constrained node
", "time": "2023-07-27T21:20:55Z"}, {"author": "Dave Thaler", "text": "#1: yes. #2:no. #2:no.
", "time": "2023-07-27T21:23:12Z"}, {"author": "\u00c9ric Vyncke", "text": "RFC 1918 and global IPv4 are vastly different beasts
", "time": "2023-07-27T21:24:29Z"}, {"author": "\u00c9ric Vyncke", "text": "Unsure whether using a PIO flag is ideal rather than a RA flag as the PD prefix may or may not be linked to a prefix.
", "time": "2023-07-27T21:38:38Z"}, {"author": "Ole Tr\u00f8an", "text": "Yes, this does not have anything to do with the PIO...
", "time": "2023-07-27T21:38:59Z"}, {"author": "Ole Tr\u00f8an", "text": "Not sure why you can't just do SLAAC and PD, just like all 6204 routers do.
", "time": "2023-07-27T21:39:25Z"}, {"author": "Jen Linkova", "text": "It does. It basically \"turn off A flag w/o affecting legacy devices\"
", "time": "2023-07-27T21:39:44Z"}, {"author": "Jen Linkova", "text": "\n", "time": "2023-07-27T21:40:29Z"}, {"author": "Ole Tr\u00f8an", "text": "Not sure why you can't just do SLAAC and PD, just like all 6204 routers do.
\n
\nBecause I do not want devices to have SLAAC addresses from that PIO, if they are capable of PD - otherwise I'm not solving scalability problem
Putting a PD address on the upstream interface is violating a MUST in PD spec.
", "time": "2023-07-27T21:41:40Z"}, {"author": "Kyle Rose", "text": "I thought so too. Turns out that language was removed looooooong ago
", "time": "2023-07-27T21:42:11Z"}, {"author": "Kyle Rose", "text": "Check the errata for 3633 (https://www.rfc-editor.org/errata_search.php?rfc=3633)
", "time": "2023-07-27T21:42:45Z"}, {"author": "Ole Tr\u00f8an", "text": "Still applies though... wouldn't be a connected prefix on the upstream interface, but node would install a glean entry for it.
", "time": "2023-07-27T21:42:56Z"}, {"author": "Ole Tr\u00f8an", "text": "Which errata would that be?
", "time": "2023-07-27T21:44:03Z"}, {"author": "Kyle Rose", "text": "From an email to Jen yesterday:
\n\n", "time": "2023-07-27T21:44:16Z"}, {"author": "\u00c9ric Vyncke", "text": "\n\nUpon the receipt of a valid Reply message, for each IA_PD the
\n
\n requesting router assigns a subnet from each of the delegated
\n prefixes to each of the links to which the associated interfaces are
\n attached, with the following exception: the requesting router MUST
\n NOT assign any delegated prefixes or subnets from the delegated
\n prefix(es) to the link through which it received the DHCP message
\n from the delegating router.It turns out this language was removed in an errata long ago (https://www.rfc-editor.org/errata_search.php?rfc=3633), and the entire RFC was obsoleted by 8415, with that restriction nowhere in sight. So my understanding is just outdated! Apologies for the noise.
\n
Also wondering whether one SLAAC host generates one address A, then the delegated prefix to another node includes this address A :-(
", "time": "2023-07-27T21:45:24Z"}, {"author": "Jen Linkova", "text": "Eric: how would it be possible? The SLAAC /64 is not delegated...or did I misread your message?
", "time": "2023-07-27T21:48:37Z"}, {"author": "\u00c9ric Vyncke", "text": "If the same /64 is used for SLAAC & your PD (assuming that PD delegates prefix out of the PIO prefix), there is a risk that one node uses one address of this prefix and latter a prefix is delegated (including this address).
", "time": "2023-07-27T21:51:06Z"}, {"author": "\u00c9ric Vyncke", "text": "Possibly easier to talk than over chat
", "time": "2023-07-27T21:51:15Z"}, {"author": "Jen Linkova", "text": "\n", "time": "2023-07-27T21:52:28Z"}, {"author": "\u00c9ric Vyncke", "text": "(assuming that PD delegates prefix out of the PIO prefix),
\n
\nBasically that's not the assumption...We are not delegating anything longer that can be used for SLAAC, and on-link PIO is exactly $SLAAC_LENGTH (== 64 currently), so it's just not possible
I obviously need to read the I-D ;-)
", "time": "2023-07-27T21:53:06Z"}, {"author": "Jen Linkova", "text": "Read the v6ops one first
", "time": "2023-07-27T21:53:31Z"}, {"author": "Jen Linkova", "text": "it would describe the deployment scenario, this one just defines a mechanism to optimize what we describe in v6ops one
", "time": "2023-07-27T21:54:15Z"}]