Re: Confirmation to advance: draft-ietf-6man-ipv6only-flag-05

["Bjoern A. Zeeb" <[e-mail]>]

On 10 May 2019, at 10:23, Nick Hilliard wrote:

> Bjoern A. Zeeb wrote on 10/05/2019 11:06:
>> Yes there is and the last *two* versions of the draft (-04 and -05) 
>> have stated that:
>> A.1.  FreeBSD Implementation  . . . . . . . . . . . . . . . . .  
>> 13
>
> Bjoern,
>
> the freebsd implementation doesn't really implement what's specified 
> in -05, in particular the interaction with dhcpv4 and interface 
> startup discipline.

Similarly phrased twice in the draft it only says:

    Dual stack hosts that have IPv4 active configuration obtained from
    the network (e.g., via DHCP), can ignore the flag and continue to 
use
    IPv4.

If there is IPv4 configuration on the interface the FreeBSD 
implementation will ignore the RA flag.


It also says:

    A host MAY delay all IPv4 operations at start-up or reconnection
    until a reasonable time has elapsed for RA messages to arrive.  If
    all RAs received have the flag set to 1, a host SHOULD NOT attempt
    IPv4 operations.

And the implementation will do an RS, and briefly wait, before trying to 
do DHCPv4.  No DCHPv4 or ARP requests or IPv4 link-local packet will 
ever end up on the air or the wire with the current implementation 
should the flag be active saving all other devices from “being woken 
up” by receiving the broadcasts.


As to when it comes to having more local savings by not running software 
locally.. how I’ll handle and add infrastructure for any kinds of 
third party software sending any other kind of IPv4 broad-/multicast 
noise will highly depend on what the consensus here will be.  Adding the 
extra 10 lines of code for the infrastructure for this is not the issue. 
  Touching 3rd party software is, as compared to most other OSes the 
general audience here might thinking off (Windows, OSX, iOS, Android 
mostly) FreeBSD like most Linux distributions is not a “blob” 
shipping with all that under one control.  And even on these 
aforementioned OSes any third party software could possibly send raw 
packets unless you take the “socket interface” for IPv4 away (and 
even then there are ways), and that is not what this draft asks for.  
Hence the lower-layer filtering is almost implied even for software 
(unless the consensus will be that IPv4 operation should be continue to 
try acquire configuration, in which case the implementation will become 
complicated, KISS will go, and savings of all this will suffer).  I am 
currently not yet willing to impose the cost of adjusting 3rd party 
software on a lot of maintainers while people are still discussing 
acceptance here.


To re-iterate, the savings that I can see can come from two parts:
(a) the IPv4-related packets not having to be seen and processed by 
everyone else (1 packet send, 1..100s..1000s nodes “woken up”; 
it’s very much like every email re-iterating here what has been said 
before is 1 email sent, read by many)
(b) local software optimising itself to save the world (by consuming 
less resources)

and
(b) is something everyone can do all the time and should do and maybe 
there need to be other changes in the future to other protocols as well
(a) is what takes the noise away that really costs.  How you do that is 
a different story and the draft to my best memory and search skills does 
not say how to achieve it (as others have pointed out before) due to the 
different nature of the different operating systems.


/bz