Hello all, and thanks for all the well-wishes.
", "time": "2024-07-25T16:31:21Z"}, {"author": "\u00c9ric Vyncke", "text": "I have doubts that a RFC would influence the CPE router vendors
", "time": "2024-07-25T17:00:30Z"}, {"author": "Nick Buraglio", "text": "my experience has been that it does not
", "time": "2024-07-25T17:04:32Z"}, {"author": "Nick Buraglio", "text": "at least at that level of kit
", "time": "2024-07-25T17:08:23Z"}, {"author": "Timothy Winters", "text": "There are several operators who require 7084 before purchaseing
", "time": "2024-07-25T17:11:02Z"}, {"author": "Timothy Winters", "text": "It's not wide spread, but it has some impact
", "time": "2024-07-25T17:11:34Z"}, {"author": "Nick Buraglio", "text": "that's refreshing to hear
", "time": "2024-07-25T17:11:58Z"}, {"author": "\u00c9ric Vyncke", "text": "+1
", "time": "2024-07-25T17:18:05Z"}, {"author": "Masanobu Kawashima", "text": "As one of CE router vendor, we refer RFC 7084 and Broadband Forum TR-124. :-)
", "time": "2024-07-25T17:21:00Z"}, {"author": "Ole Tr\u00f8an", "text": "Back t5o RFC1884
", "time": "2024-07-25T17:38:06Z"}, {"author": "Warren Kumari", "text": "@Billo: I mean, it does help with Neigbor cache exhaustion -- instead of 4PB of RAM for neighbor cache I'll only need 1PB of RAM...
", "time": "2024-07-25T17:44:50Z"}, {"author": "Nick Buraglio", "text": "Just a data point - no hat: I have run an open perimeter network (i.e. no middle boxes, public addressing) for 20+ years and I have only seen ND exhaustion as a problem once, and it was a vendor bug that simply did not time out the ND cache
", "time": "2024-07-25T17:47:22Z"}, {"author": "Nick Buraglio", "text": "We also built the original IPv6 backbone as /64 everywhere, all PTP links, etc. because that was all the vendors supported when we did it.
", "time": "2024-07-25T17:48:35Z"}, {"author": "\u00c9ric Vyncke", "text": "The /64 for P2P can also reduce the consumption of TCAM entries on some platforms (not those of my employers BTW)
", "time": "2024-07-25T17:49:27Z"}, {"author": "Nick Buraglio", "text": "LOL, I was just getting ready to type that
", "time": "2024-07-25T17:49:40Z"}, {"author": "\u00c9ric Vyncke", "text": ";-)
", "time": "2024-07-25T17:50:16Z"}, {"author": "Nick Buraglio", "text": "I've long said that ND cache issues feel more like a symptom of a problem rather than a problem in and of itself. Personally I would suggest that, if ND exhaustion is an issue that we address that as a problem rather than changing a core protocol behavior.
", "time": "2024-07-25T17:52:14Z"}, {"author": "Gyan Mishra", "text": "having a smaller subnet would that reduce the chance of ND cache exhaustion as an attack vector. I have not seen the ND cache exhaustion myself however it is discussed in RFC 3756 referenced in the /127 rfc 6164
", "time": "2024-07-25T17:54:38Z"}, {"author": "Gyan Mishra", "text": "@Nick I agree its a symptom of a problem and the problem is possible security issue from ddos attack
", "time": "2024-07-25T17:55:30Z"}, {"author": "Gyan Mishra", "text": "See RFC 6164 section 5.2 on ND cache exhaustion it explain the problem that could happen with /64
", "time": "2024-07-25T17:57:55Z"}, {"author": "Nick Buraglio", "text": "I will re-read
", "time": "2024-07-25T18:00:45Z"}, {"author": "Gyan Mishra", "text": "@Bob thank you for mentioning the error on my take that slaac rfc 4862 is variable but its RFC 4291 that fixes the boundary to /64. I will fix that in the draft.
", "time": "2024-07-25T18:02:49Z"}]