Re: Homenet

[Tore Anderson <tore fud no>]

* Xen

> Here is a guy with experience with ULAs: 
> https://github.com/sbyx/ohybridproxy/issues/4
>
> The person who responds says it's just a bug and it will get fixed. But 
> then the guy says: I do not want any dependence on my ISP whatsoever for 
> my homenet routing.
>
> Meaning, he wants his router to generate an ULA and use that for all 
> hostname resolution within the network.

Correct. When looking up «somedevice.home», I'd want IPv6 ULAs to be
returned (assuming ULAs are enabled in the first place) as well as IPv4
RFC1918 addresses (again, assuming IPv4 is enabled).

Note that fixing this issue is just an implementation tweak in the
OpenWrt Homenet code. It's defintively not a fundamental flaw in any
protocol like HNCP or IPv6 itself.
 
> That also seems to imply that any addressing from the outside (the
> mobile device moving across borders) is not going to work when it
> uses a hostname.

No, you've misunderstaood. The «.home» hostnames only have in-home
significance, they do not work from the outside. This has nothing do do
with IPv4, IPv6, ULAs, Homenet, or anything like that. You'll find lots
of variations on this - most CPE vendors has their own in-home domain
suffix used in this manner, e.g., «.lan», «.fritz.box», or whatever.

> It's not the fault of Homenet, it is the fault of IPv6.
>
> It's just that local independence from an ISP prefix should be 
> MANDATORY. Your prefix should give access to your HOME but not to the 
> devices within it.
>
> This is the flawed method of addressing I was discussing:
>
> - the external address of your network, and
> - the internal address of your sub-network
>
> should be different and independent numbers.
>
> But both are expected to sit in the same 128 bit field, which is clearly 
> impossible unless you forget about the 64-bit prefix and use your own 64 
> bits to create your own subnet prefixes as required.

Huh? This does not reflect reality, or I misunderstand you completely.
From my laptop, sitting in an Homenet topology using NM-1.2, I see:

$ ip address list dev wlo1 scope global
4: wlo1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc mq state UP group default qlen 1000
    link/ether b4:b6:76:17:2e:83 brd ff:ff:ff:ff:ff:ff
    inet 10.0.72.155/24 brd 10.0.72.255 scope global dynamic wlo1
       valid_lft 26681sec preferred_lft 26681sec
    inet6 2a02:fe0:c420:57e1::c68/128 scope global dynamic
       valid_lft 1005367sec preferred_lft 400567sec
    inet6 fd65:557c:6f31:2d:483f:37b7:98ea:1036/64 scope global noprefixroute dynamic
       valid_lft 485sec preferred_lft 185sec
    inet6 2a02:fe0:c420:57e1:30f:919e:64d9:138f/64 scope global noprefixroute dynamic
       valid_lft 7179sec preferred_lft 1779sec

There are two sets of stable internal addresses, IPv4 RFC1918 (from
10.0.0.0/8) and IPv6 ULA (fc00::/7).

In addition there are the ISP-assigned addresses from 2a02:fe0::/32,
which change from time to time.

These addresses do not «sit in the same 128 bit field», they are
completely independent from each other.

Tore