Dividing the Indivisible

Вы находитесь здесь: version6.ru » Welcome! » Dividing the Indivisible

Эта страница — только для чтения. Вы можете посмотреть исходный текст, но не можете его изменить. Сообщите администратору, если считаете, что это неправильно.

====== Dividing the indivisible ======

===== How to live with a /64, if that's all they gave you? =====
The "proper" approach would be to call up the provider and ask for more; there is no reason to limit IPv6 assignments to end-users to just a single /64, and in fact the current RFC on the best practices ([[http://www.rfc-editor.org/rfc/rfc6177.txt|6177]]) recommends "**giving home sites significantly more than a single /64**".

But what if changing the ways of your provider does not look to be a feasible option, and you still want to have at least a semi-comfortable experience (i.e. not being forced to bridge everything into one L2 LAN)?

This simple HOWTO explains how you can have one "primary" network with functional SLAAC, and an arbitrary number of "secondary" networks, where only DHCPv6 will be available. Full two-way routing between all these networks will work without any issues.

===== Network configuration =====
Let's assume we have the following.

| IPv6 routed subnet from the provider: |  ''2001:db8:abcd:cdef::/64''  |
| One primary interface, where we want SLAAC to function:  |  ''eth0''  |
| Three (or more) secondary interfaces, which also need IPv6, \\ but they will have to go without SLAAC:  |  ''eth1'', ''eth2'', ''eth3''  |

What we do is...

**Carve out a /108 out of the /64, and split it into up to sixteen /112 networks.**

Let's say this network will be ''2001:db8:abcd:cdef:ffff:ffff:fff0::/108''.

But if hosts on the main LAN will assume they have the /64 directly accessible, how will they reach other networks, that are behind the router's eth1/2/3?

The answer is: with a more-specific route from RAs!

===== On the router =====
==== /etc/dibbler/server.conf ====
(the rest of the config file is omitted)
<file>
iface "eth1" {
 class {
   pool 2001:db8:abcd:cdef:ffff:ffff:fff1::/112
 }
}

iface "eth2" {
 class {
   pool 2001:db8:abcd:cdef:ffff:ffff:fff2::/112
 }
}

iface "eth3" {
 class {
   pool 2001:db8:abcd:cdef:ffff:ffff:fff3::/112
 }
}
</file>

==== /etc/radvd.conf ====
<file>
interface eth0 {
    AdvSendAdvert on;
    prefix ::/64 { };
    route 2001:db8:abcd:cdef:ffff:ffff:fff0::/108 { };  # <- the main secret sauce in this whole recipe
};

interface eth1 {
    AdvSendAdvert on;
    AdvManagedFlag on;
    prefix ::/112 { };
};

interface eth2 {
    AdvSendAdvert on;
    AdvManagedFlag on;
    prefix ::/112 { };
};

interface eth3 {
    AdvSendAdvert on;
    AdvManagedFlag on;
    prefix ::/112 { };
};
</file>

==== IPs on the router interfaces ====
Simple.
  * ''eth0: 2001:db8:abcd:cdef::1/64''
  * ''eth1: 2001:db8:abcd:cdef:ffff:ffff:fff1::1/112''
  * ''eth2: 2001:db8:abcd:cdef:ffff:ffff:fff2::1/112''
  * ''eth3: 2001:db8:abcd:cdef:ffff:ffff:fff3::1/112''

===== Downsides =====
The clients on eth1/2/3 will constantly complain into 'dmesg' about "IPv6 addrconf: prefix with wrong length 112". This is harmless and can be ignored.

===== Address collisions? =====
Hosts from your primary LAN assume that the whole /64 is their own personal playground, and that they can pick any address they want. In theory this can lead to address collisions with some hosts on your secondary networks. But in practice chances of this is astronomically low.

  - We ruled out possibility of collision with a EUI-64 address by using ''...ff:ff...'' in the middle of our /108 (those will always have ''ff:fe'');
  - The probability of "Privacy Extensions" address suddenly having ''....ffff:ffff:fff...'' in it, is... well, calculate yourself, seems pretty low too.

en/dividing-the-indivisible.1364811863.txt.gz · Последние изменения: 2013-04-01 10:24 UTC От rm

	Новости
	Сообщество
	Twitter
	IRC

Views

Навигация

Personal Tools

Поиск

Инструменты

Ссылки