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

From: Mikael Abrahamsson <[email-masked]>
Date: Fri, 11 Dec 2020 11:58:27 +0100 (CET)

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

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?

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.

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? 
However, I don't know how the HGW would figure out what addresses are 
which from temporary privacy addresses, stable RFC7217 etc.

Thoughts?

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Fernando Gont <[email-masked]>
Date: Fri, 11 Dec 2020 09:05:06 -0300

On 11/12/20 07:58, Mikael Abrahamsson wrote:
> 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.
> 
> 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.
> 
> 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.

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

> handling these firewall rules, perhaps based on MAC address or 

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: [email-masked]
PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492

---

From: Ted Lemon <[email-masked]>
Date: Fri, 11 Dec 2020 09:07:20 -0500

Mikael, it sounds like you want to be able to reliably find devices by IPv6 address. I think there’s general agreement that this isn’t a sustainable model. There are a couple of solutions that may work better than this, that you might consider.

1. Use multicast DNS. If you have an ssh host key, this should work pretty well.
2. Use DNS Update: track IP address changes in an appropriate way, and when the IP address changes, do a DNS update.
3. Use Service Registration Protocol. If you’re interested, I have an SRP client that I think will do the job; what’s nice about SRP is that once a name has been claimed, as long as the client continues to renew, the name can’t be taken by a competing client, as is possible with multicast DNS. I also have an SRP proxy that will take well-formed SRP updates, validate them, and then use them to update your DNS server. Works well with BIND, should work with other name servers that support DNS update.

That’s the guidance I would give.

> On Dec 11, 2020, at 5:58 AM, Mikael Abrahamsson <swmike=[email-masked]> wrote:
> 
> 
> Hi,
> 
> 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. 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.
> 
> 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?
> 
> 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.
> 
> 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? However, I don't know how the HGW would figure out what addresses are which from temporary privacy addresses, stable RFC7217 etc.
> 
> Thoughts?
> 
> -- 
> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops

---

From: Simon Hobson <[email-masked]>
Date: Sun, 13 Dec 2020 19:53:01 +0000

Fernando Gont <[email-masked]> wrote:

> So it should be the host talking to the firewall and telling what to do with which address.  -- with e.g. something like UPnP.

So we're back to each host deciding on the security policy for the network - not a network admin (as a proxy for the owners of the site/network).

I make a point of disabling upnp as one of the first steps when setting up a network. Who wants ${random device which may or may not be "friendly"} to be able to determine what traffic is allowed into the network - it's not like there is anyone out there in the wild west of the internet who'd have any hostile intent :-/

Simon

---

From: Fernando Gont <[email-masked]>
Date: Mon, 14 Dec 2020 01:32:43 -0300

Hi, Simon,

> So we're back to each host deciding on the security policy for the network - not a network admin (as a proxy for the owners of the site/network).

For the home scenarios case, we're not "back", because we never went 
away from there.

The number of people manually configuring home firewalls is not 
statistically significant.

OTOH, if you want to manually configure rules based on addresses that 
are not guaranteed to remain stable... you know what you are going to 
get. In such scenarios, you probably should use RADIUS or something else.

> I make a point of disabling upnp as one of the first steps when setting up a network. Who wants ${random device which may or may not be "friendly"} to be able to determine what traffic is allowed i…

Who wants a network with a random device?  :-)

If the device is evil enough to use UPnP to open wholes in the FW, it 
could also be evil to act as a proxy and tunnel everything into the 
internal network.

Thanks,