Re: [v6ops] RFC7217 and flash renumbering and IID change

[Fernando Gont <[e-mail]>]

On 11/12/20 07:58, Mikael Abrahamsson wrote:
> 
> Hi,
> 
> just wanted to share my experience.
> 
> My home has a /56 PD from my ISP. For some (unknown to me) reason my 
> home was flash renumbered little over 24 hours ago.

FWIW, same happens at home, albeit for the /64 I get delegated from my 
ISP.  -- still trying to debug the reason with my ISP.



> I didn't notice, 
> generally everything worked. What made me discover that this happened 
> was when I tried to access something that had a static entry in my 
> /etc/hosts file. This is understandable, and has happened to me before 
> in my 10+ years of running IPv6 in my home.
> 
> I proceeded to change the first 64 bits of the address in /etc/hosts, 
> and tried again. Still nothing. Investigated further, and then I 
> discovered that the last 64 bits had changed as well.
> 
> This seems to be because ubuntu 20.04 machines (and others) are using 
> RFC7217 to generate the last 64 bits, and reading RFC7217 in the light 
> of this, it says to generate a unique IID when it "moves". Now, my 
> machine certainly didn't "move" (for some definition of move), its NIC 
> always had link, default gateway was the same etc, but RFC7217 says to 
> generate unique IID per Prefix, so that's what it did.

If the prefix changed, the your node changed it's location in the 
network topology. -- note that while the default router didn't change, 
that could simply be the result of connecting the same router to a 
different ISP/upstream. So the behavior you got is a feature, indeed. :-)




> There are HGWs where the firewall allows you to configure rules that 
> take the PIO Prefix first 64 bits and then a static IID, so that if the 
> Prefix changes, the firewall rule but not IID changes, it'll still be 
> correct.
> 
> With the current behavior of IID change when PIO Prefix changes, above 
> functionality doesn't work.
> 
> So I guess my question is, how do we want these things to work? What's 
> the guidance we want to give? I'd like people to be able to configure 
> their HGW with firewall rules that keep working across renumbering, so 
> what should these firewall rules be based on?

What I'd say is: Any of:

1) Manually configure the address -- e.g., IIRC some systems allow you 
to use a "token" that will be employed along the prefix. Similar to what 
you mention for the HGW. (i.e., override RFC7217)

2) Filter based on the MAC address (may or may not be of use depending 
on the set up)

3) Use something ala UPnP -- although unfortunately many HGWs do not 
include the relevant support for the IPv6 case.

4) Have the node update its e.g. DNS record, and have the FW build the 
rules from the domain -> IPv6 addresses


Note: I assume that your HGW FW rules are for incoming connections -- 
since otherwise for outgoing connections you'd run into the same problem 
due to IPv6 temporary addresses.



> If we augment RFC7217 and say that new IID should not be generated in a 
> flash renumbering event (for instance, if default gw is the same, a new 
> Prefix being announced, keep the IID) that would work.

The problem here is that when a prefix changes, that means the system 
has moved. Think, e.g. a user that employs a portable 4G router -- the 
default gw will always be the same, but you certainly want the IID to 
change as the user travels around.



> Another way might be to suggest some more advanced logic for the HGW in 
> handling these firewall rules, perhaps based on MAC address or 
> something?

Yep, that's one of the possibilities.


> However, I don't know how the HGW would figure out what 
> addresses are which from temporary privacy addresses, stable RFC7217 etc.

It certainly can't (both temporary and stable addresses look the same). 
So it should be the host talking to the firewall and telling what to do 
with which address.  -- with e.g. something like UPnP.

Thanks!

Regards,
-- 
Fernando Gont
SI6 Networks
e-mail: [e-mail]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492