On 10.12.2012 12:40, Dave Taht wrote:
Well, I abhor bridging 2.4 and 5 ghz wireless together, and then there
is the ever more popular concept of a "guest" network...

Yes I'm talking about the default setup of OpenWrt here which does not have a guest-interface etc. though I agree in general we will all have the problem.

Though we might not want to do bridging by default we might want to think about a solution using relaying (NDP-Proxying etc.) if the /64-problem becomes critical.


This is how the prefix distribution works either for the ULA or the public
prefixes. I've implemented this straight forward not looking at any
specification as the local prefix distribution should not be mandated imo by
any RFC.

Heh.


* For ULA fd00::/48, the first /64 would be fd00::/64, the 2nd
fd00:0:0:1::/64 etc.

It would be my hope to not standardize on fd00::whatever, but to
actually generate random ones. Doing vpns between your standardized
192.168.0.1 addresses is painful.... and with better naming, the pain
of having to remember these large numbers goes away (a bit.)
Yes we do generate random ones. The first time any interfaces comes up a random ula address is generated. I just used fd00:: in this example because its the shortest one to write to demonstrate the splitting of prefixes.



* Padding (unused adress-space) is added if the alignment cannot be
satisfied (e.g. one interface wants a /64, the second a /62, then there will
be a padding or 1 /64 and 1 /63 in between).
* If a downstream-interface goes down, its assigned prefix is preserved in
case it later comes up again.
* Assignments for a public prefixes are forgotten once the prefix is removed
(e.g. wan goes down).

My understanding is that public prefixes can be kept until the wan comes up.
That said, I'd argue in favor of expiring them as fast as possible if
ula's already exist.
Sorry I don't get what you mean, maybe a misunderstanding. What I was talking about is when you have an ULA or a public prefix, lets use 2001:DB80::/48 here than e.g. your ethernet-lan gets 2001:DB80:0:1/64, wifi gets 2001:DB80:0:2/64 etc. If you then do an ifdown lan and ifup lan, the ethernet interface still still get 2001:DB80:0:1/64 and not 2001:DB80:0:3/64 etc. This apply also when other interfaces were brought up or down in between, except when the interface that provided the prefix (e.g. wan) goes down. In this case all current assignments an the prefix itself will be forgotten.

In the NPT-scenario these rules will apply to the ULA-addresses, so once an interface got a part of the ULA-prefix, it will keep that prefix even if it goes down and up again.



I think randomizing would help against attacks, yes.

Somewhat related, you could do something SLAAC-like on the inner
interface's /64. In prior versions of linux using a dhcp-like address
assignment strategy hashed badly.

(I note that I'm more of a fan of slaac than dhcpv6)



_______________________________________________
Cerowrt-devel mailing list
Cerowrt-devel@lists.bufferbloat.net
https://lists.bufferbloat.net/listinfo/cerowrt-devel

Reply via email to