On Sun, Jun 24 2018, Klemens Nanni <k...@openbsd.org> wrote: > On Sun, Jun 24, 2018 at 04:34:01PM +0200, Jeremie Courreges-Anglas wrote: >> So if I understand correctly, this diff does three things: >> 1. shorten the code (remove the explicit mask handling from this >> function) >> 2. stop considering 2000::/3 as special per RFC3587 >> 3. stop considering 2001:db8:: as a /64 prefix by default, but consider >> it as a host (/128) >> >> 1. might be desirable, even though I find it hard to follow the code >> flow. Perhaps the code should be more explicit and stop abusing >> globals... >> >> 2. fine, but... >> >> 3. ... why should we stop assuming that the user really means to >> configure a route for a /64 if the host id part is all-zeroes? Is >> this really part of what has been deprecated by RFC3587? > Without context there's no point in guessing, what makes you think /64 > is the appropiate choice? There should be no assumptions being made at > all since there's nothing backing up /64 any more than whatever bigger > prefix you can think of.
I would also prefer if this code didn't exist in the first place, but it does. So, playing the devil's advocate: what would prevent people from making such assumptions? /64 is the most common prefix length configured on interfaces (at least in my experience). IPv6 is heavily geared towards this assumption, there are even studies about it[0]. I would argue that the current behavior tries to be helpful. On the other hand, how often do you configure routes to a Subnet-Router anycast address[1]? I really think your diff goes in the right direction, so if no one shows up with strong objections I'd suggest that you commit your diff soon with my ok. But please do not justify item 3 with RFC3587. So... anyone else with strong feelings regarding this change? >> I can understand that having the same behavior (host address is no >> prefix length is specified) with v4 and v6 is desirable, but as benno >> pointed out, some people might be relying on the current default >> behavior. That's not a strong objection, but I'd like to know what's >> the exact rationale behind this change. > It removes the guess-work. Installing a route for 2001:db8:: should > use /128 simply because that's what it is. Benno's -blackhole example > demonstrates how dangerous implicit meanings and/or assumptions can be. Assumptions may not be good, but unless I missed something benno's example[2] is a different issue and this diff doesn't address it, the resulting route is still not what the user expects. [0] https://tools.ietf.org/html/rfc7421 "Analysis of the 64-bit Boundary in IPv6 Addressing" [1] https://tools.ietf.org/html/rfc4291#section-2.6.1 "Required Anycast Address" [2] https://marc.info/?l=openbsd-misc&m=152719815704699&w=2 -- jca | PGP : 0x1524E7EE / 5135 92C1 AD36 5293 2BDF DDCC 0DFA 74AE 1524 E7EE
