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:27:01 +0100	[thread overview]
Message-ID: <50C5C705.3060108@openwrt.org> (raw)
In-Reply-To: <CAA93jw7_+kjyuaRteNDfagzy-vcvghAyPbzgALVMqPQr+_SdkA@mail.gmail.com>

On 10.12.2012 10:15, Dave Taht wrote:
>> * Prefixes are automatically split up and distributed over
>> downstream-interfaces OR by choice mapped to an ULA-address (NPT66).
>
> Hmm. The homenet folk have a prefix assignment and router discovery
> process defined in their PD over ospf (somewhat crazy)
> implementation...
>
> My expectation here is that ISPs are going to be parsimonious in
> handing out anything bigger than a /64, certainly anything bigger than
> a /56 is going to be scarce. So I'd hope that address assignment using
> NPT66 would start with the bottom addresses and work up.

cerowrt would run into problems if the ISPs would only assign a single 
/64. Even NPT would not help here as two distinct ULA /64 could not be 
mapped to the same public /64 without the possibility of collisions. So 
it might be necessary to relay between the downstream interfaces in this 
case so that they share a /64 or did you have something else in mind?

However I guess and from what I have seen most ISP will probably assign 
a /56 or at least a /60. For OpenWrt a /64 would not so problematic as 
there is - by default - only 1 (bridged) lan-interface so a single /64 
is sufficient for most users.



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.

* For ULA fd00::/48, the first /64 would be fd00::/64, the 2nd 
fd00:0:0:1::/64 etc.
* 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).


In the current implementation the NPT will map the public prefix to the 
lower part of the ULA, meaning a public /56-prefix will be mapped onto
fd00::/56 if the ULA is fd00::/48 and everything outside this /56 would 
not be mapped so care has to be taken. This is a bit unpredictable - I 
know - but in the end we cannot know what size the public prefix from 
the ISP will be and I guess if there are only a few /64-downstream 
interfaces it is unlikely to clash for a majority of users.


>
> Somewhat related to that, is the concept of actually USING ipv6 for a
> few things that it's good at. For example, a much greater randomized
> port space can be gained if the dns server is the only daemon
> listening on a dedicated ipv6 address (like a ::3)

I'm currently wondering if it would make sense to implement a 
randomization strategy in case we have e.g. a /56 prefix and only want 
to assign one or two /64 so that the /64 would not always be ...1::/64 
and 2::/64 but it would be a bit complicated with the dynamic prefix 
assignment of downstream-interfaces and especially when it comes to ULA 
and us not knowing before-hand what length the public prefix will be.

  reply	other threads:[~2012-12-10 11:27 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 [this message]
2012-12-10 11:40     ` Dave Taht
2012-12-10 11:53       ` Steven Barth
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=50C5C705.3060108@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