Development issues regarding the cerowrt test router project
 help / color / mirror / Atom feed
From: Steven Barth <cyrus@openwrt.org>
To: Dave Taht <dave.taht@gmail.com>
Cc: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Current state of ipv6 in openwrt barrier breaker
Date: Mon, 10 Dec 2012 12:53:46 +0100	[thread overview]
Message-ID: <50C5CD4A.8070303@openwrt.org> (raw)
In-Reply-To: <CAA93jw7c4azi4btBGjrhpDsUY_iMeXNH5Py8BFqe3B8yb_QFyg@mail.gmail.com>

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)




  reply	other threads:[~2012-12-10 11:53 UTC|newest]

Thread overview: 20+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2012-12-10  8:41 Dave Taht
2012-12-10  9:15 ` Dave Taht
2012-12-10 11:27   ` Steven Barth
2012-12-10 11:40     ` Dave Taht
2012-12-10 11:53       ` Steven Barth [this message]
2012-12-11 19:56 Ole Trøan
2012-12-11 20:25 ` Dave Taht
2012-12-11 21:31   ` Ole Trøan
2012-12-12  8:19     ` Dave Taht
2012-12-12  9:08       ` Ole Trøan
2012-12-12  9:19         ` Steven Barth
2012-12-12  9:28           ` Ole Trøan
2012-12-12  9:47             ` Steven Barth
2012-12-12 10:11               ` Dave Taht
2012-12-12 18:56       ` Michael Richardson
2012-12-12  9:05     ` Török Edwin
2012-12-11 20:46 ` Steven Barth
2012-12-11 21:02   ` Ole Trøan
2012-12-12  8:23     ` Steven Barth
2012-12-12  8:43       ` Ole Trøan

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

  List information: https://lists.bufferbloat.net/postorius/lists/cerowrt-devel.lists.bufferbloat.net/

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=50C5CD4A.8070303@openwrt.org \
    --to=cyrus@openwrt.org \
    --cc=cerowrt-devel@lists.bufferbloat.net \
    --cc=dave.taht@gmail.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox