On Sun, Jun 24, 2018 at 07:54:48PM +0200, Jeremie Courreges-Anglas wrote:
> 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 don't understand why it's equivalent.

prefixlen() seems to operate on so_mask while the only caller of
inet6_makenetandmask() passes in so_dst.

Assuming it is equivalent, inet6_makenetandmask() is now missnamed and
I think we should just get rid of it. We can just call prefixlen()
directly, the diff turns inet6_makenetandmask() into a weird wrapper
around prefixlen(). Note that sep can't be NULL, so plen can't be
NULL.

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

-- 
I'm not entirely sure you are real.

Reply via email to