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 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.
