Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6 routing messages

[Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>]

The following reply was made to PR kern/57037; it has been noted by GNATS.

From: Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>
To: gnats-bugs%netbsd.org@localhost, kern-bug-people%netbsd.org@localhost, gnats-admin%netbsd.org@localhost,
        netbsd-bugs%netbsd.org@localhost, kardel%netbsd.org@localhost
Cc: 
Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
 routing messages
Date: Mon, 17 Oct 2022 19:17:22 +0900

 Hi,
 
 On 2022/10/12 18:35, Frank Kardel wrote:
 > The following reply was made to PR kern/57037; it has been noted by GNATS.
 > 
 > From: Frank Kardel <kardel%netbsd.org@localhost>
 > To: gnats-bugs%netbsd.org@localhost
 > Cc:
 > Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
 >   routing messages
 > Date: Wed, 12 Oct 2022 11:33:53 +0200
 > 
 >   Hi,
 >   
 >   yes. It follows the principle of least astonishment. So that is now fine.
 >   
 >   I was wondering whether parameter changes should be announced via
 >   
 >   #define RTM_CHGADDR     0x18    /* address properties changed */
 >   
 >   but I currently have no idea how widely the interface is defined/used
 >   and what the
 >   breakage would be.
 >   RTM_CHGADDR sounds in the comment the this could be right for parameter
 >   changes, but
 >   I am no up to date on the semantics of that. Maybe someone (tm) could
 >   shed more light on that.
 
 I have considered about RTM_CHGADDR idea, however I cannot come up with
 a good design.  So, I change net.inet6.ip6.param_rt_msg value type from
 bool to int for future expandability, and the values are consisted of
      - 0 : don't send parameter changing routing message
      - 1(default) : send parameter changing routing message by RTM_NEWADDR
                     (same as before)
 Maybe someone (tm) will implement
      - 2 : send parameter changing routing message by RTM_CHGADDR (or better way?)
 
 Here is the updated patch
      https://www.netbsd.org/~knakahara/20221017-param-rt-msg.patch
 
 If there is no objection, I will commit this patch.
 
 
 Thanks,
 
 >   Best regards,
 >      Frank
 >   
 >   On 10/11/22 09:40, Kengo NAKAHARA wrote:
 >   > The following reply was made to PR kern/57037; it has been noted by GNATS.
 >   >
 >   > From: Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>
 >   > To: Frank Kardel <kardel%netbsd.org@localhost>, gnats-bugs <gnats-bugs%NetBSD.org@localhost>
 >   > Cc:
 >   > Subject: Re: kern/57037: unncessary and unwarranted RTM_NEWADDR for IPv6
 >   >   routing messages
 >   > Date: Tue, 11 Oct 2022 16:05:54 +0900
 >   >
 >   >   Hi,
 >   >
 >   >   Thank you for your fixing!
 >   >
 >   >   Is the behavior is  what you want?
 >   >
 >   >
 >   >   Thanks,
 >   >
 >   >   On 2022/10/07 23:19, Frank Kardel wrote:
 >   >   > Hi,
 >   >   >
 >   >   > I debugged the patch and the issue was the the comparison was with dst6 and dst addrs. Instead the actual addresses needed to be compared.
 >   >   >
 >   >   > The corrected patch is attached.
 >   >   >
 >   >   > Best regards,
 >   >   >
 >   >   >  Ã?  Frank
 >   >   >
 >   >   >
 >   >   > On 10/06/22 08:46, Kengo NAKAHARA wrote:
 >   >   >> Hi,
 >   >   >>
 >   >   >> Thank you for your testing!
 >   >   >>
 >   >   >> Sorry I can't help you.Ã?  Hmm, the patch may be old, I will review
 >   >   >> and test it again.
 >   >   >>
 >   >   >>
 >   >   >> Thanks,
 >   >   >>
 >   >   >> On 2022/10/06 15:34, Frank Kardel wrote:
 >   >   >>> Hi!
 >   >   >>>
 >   >   >>> Thanks for the patch.
 >   >   >>>
 >   >   >>> Unfortunately I still see RTM_NEWADDRs after setting net.inet6.ip6.param_rt_msg=0
 >   >   >>>
 >   >   >>> This needs a bit more debugging - maybe I get to that after may $DAYJOB.
 >   >   >>>
 >   >   >>> Best regards,
 >   >   >>>
 >   >   >>> Ã? Ã?  Frank
 >   >   >>>
 >   >   >>>
 >   >   >>> On 10/06/22 01:51, Kengo NAKAHARA wrote:
 >   >   >>>> sysctl -w net.inet6.ip6.param_rt_msg=0
 >   >   >>>
 >   >   >>
 >   >   >
 >   >
 >   >   --
 >   >   //////////////////////////////////////////////////////////////////////
 >   >   Internet Initiative Japan Inc.
 >   >
 >   >   Device Engineering Section,
 >   >   Product Division,
 >   >   Technology Unit
 >   >
 >   >   Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>
 >   >
 >   >
 >   
 
 -- 
 //////////////////////////////////////////////////////////////////////
 Internet Initiative Japan Inc.
 
 Device Engineering Section,
 Product Division,
 Technology Unit
 
 Kengo NAKAHARA <k-nakahara%iij.ad.jp@localhost>