Re: ndp(1) and arp(1) enhancements for easier scripting of IPv6 prefix delegation

[Greg Troxel <gdt%lexort.com@localhost>]

Martin Husemann <martin%duskware.de@localhost> writes:

> I have a "dynamic" IPv6 prefix delegated to my internal network and
> I need to automatically update firewall rules and DNS entries when
> the prefix changes.

That is assuming that v6 addresses are stable except for the prefix
change.  That's not true with stateless autoconfiguration and privacy
extensions, which I view as the default address.

> This is relatively straight forward, but slightly more complex than 
> I think it should be - and adding a few simple options to arp(1) and
> ndp(1) could help.
>
> I have a list of hosts (IPv4 or DNS A record) that I need to find the
> new IPv6 for after the prefix changed.
>
> What my script currently does:
>
>   for host in .....
>   do
>      mac=$( arp $host | awk '{ print $4 }' )
>      laddr=$( ndp -an | \
> 	awk "/^fe80::/ { if (\$2=="'"'"${mac}"'"'") print \$1; }" )
>      new_public_addr="${new_prefix}${laddr%%\%*}"
>      # update FW ruleset and DNS entry for $host with $new_public_addr
>   done
>
> that is: get the mac address of the host from arp(1), then search for this
> mac address in the "ndp -an" output for a link local address, then replace
> the fe80:: prefix with the new public prefix.

I see this approach as problematic:

  you're not doing configuration management on hosts and MAC addresses.

  hosts that are not up will not be in the ARP table

  you're using it to configure firewall, but arp/ndp is not
  authenticated

  you're assuming not using privacy extensions

> This alogrithm is not quite stable. It assumes building public
> addresses from IPv6 prefix via mac (in dhcpcd terms: slaac hwaddr) --
> which is OK in my case as I only do it for NetBSD hosts under my
> controll; but (far worse) it assumes the host has already updated the
> public address after the RA told it about the new prefix.

agreed

> So what I am looking for is:
>
>  1) suggestions how to make this process more fool proof
>  2) if the updated process still involves arp(1) and ndp(1), some
>     options to make them more script-friendly.

I would suggest having a configuration file with

  host | low-64-bits-of-v6 | mac

and just use that to update.  You'll update it for hosts that aren't up,
and not believe random arp entries.  If you're doing firewall by v6
addr, rather than by mac addr, you can perhaps leave out the mac addr
entirely.

I would also say that if you are setting up per-host firewall entries
(presumably, to allow external access to certain services on internal
hosts that have a global v6 but not v4), then you should seriously
consider DHCP6 instead of SLAAC for them.