From: "Török Edwin" <edwin+ml-cerowrt@etorok.net>
To: cerowrt-devel@lists.bufferbloat.net
Subject: Re: [Cerowrt-devel] Current state of ipv6 in openwrt barrier breaker
Date: Wed, 12 Dec 2012 11:05:26 +0200 [thread overview]
Message-ID: <50C848D6.90007@etorok.net> (raw)
In-Reply-To: <CBD7CF84-57AC-4FE1-A5C8-5D1EEA58AD11@employees.org>
On 12/11/2012 11:31 PM, Ole Trøan wrote:
>
> there is an argument to be made, that if we are so clever that we make CPEs function well with a /64, then that will encourage ISPs to be parsimonious with address space. what are they doing next, a /80?
>
> one of the reasons we have the 64 bit boundary in IPv6 is to make it very difficult to give anything less than 2^64 addresses to a site.
> we should keep trying to make it very difficult to provide less than a /56-/60 to a site also.
> I'd be happier if no CPE could do handle it (and certainly not on by default).
Don't forget about virtualization.
Correct me if I'm wrong, but even if the router gets more than a /64 a host would only request a /64 automatically, which is not
enough to automatically route between the virtual network interfaces (each would want a /64 again).
Unless the virtual network runs in bridged mode so that the VMs can get their IPv6 address directly from the router, or you use
AHCP to assign addresses.
And in general there are even more problems, for example in a datacenter you might need to proxy NDP requests otherwise the VMs get no IPv6 traffic
(either manually for each host, or with a userspace daemon). So you'd probably need both ndppd and ahcpd to have things working.
It'd certainly be easier if one could use less than a /64, at least for virtual networks, and have automatic IPv6 address assignment and
automatic ndp proxying working without the need for any user-space daemons.
--Edwin
next prev parent reply other threads:[~2012-12-12 9:05 UTC|newest]
Thread overview: 20+ messages / expand[flat|nested] mbox.gz Atom feed top
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 [this message]
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
-- strict thread matches above, loose matches on Subject: below --
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
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=50C848D6.90007@etorok.net \
--to=edwin+ml-cerowrt@etorok.net \
--cc=cerowrt-devel@lists.bufferbloat.net \
/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