Jeremie Courreges-Anglas(j...@wxcvbn.org) on 2018.06.24 19:54:48 +0200: > 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.
me too! > 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. it is this issue. i think it can be commited, but please add something to current.html. And i think that route add -inet6 -prefixlen 56 2001:db10:: 2001:db9::5 should be an error (because right now it configures a 2001:db10::/64 route, and with your diff a /128). > [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 >
