Community discussions

MikroTik App
 
User avatar
docmarius
Forum Guru
Forum Guru
Topic Author
Posts: 1226
Joined: Sat Nov 06, 2010 12:04 pm
Location: Timisoara, Romania
Contact:

IPv6 DHCP/pool issue

Sun May 13, 2012 1:24 pm

I found a strange error in the log, related to DHCPv6. As i remember saw it also in older firmwares:
assigned prefix len: 64 is bigger than configured: 64 using:72
Now mathematically this is an incorrect statement since they are equal. And the assigned /64 pool has in fact prefix length /64 - as given by the providers DHCP server.

A similar logic error is also there if i try to add a pool of /64 with prefix length 64:
Couldn't add New IPv6 Pool - prefix length must be bigger than prefix.
Here an equality should also be acceptable.

Use case for first issue:
- I get a /64 address delegation from my provider via DHCPv6 and want to add it to a dynamic pool (here first error occurs - this actually should be a warning since the usage of /72 solves this from functional point of view - but it's still wrong)
- I want to assign those addresses to my network via RA and just forward it to my upstream provider. But i have only a /72 subnet and RA needs a /64 (this is solved by declaring a interface address from the pool with mask /64 but still just a workaround)

Use case for second issue:
- Got a /48 assignement from my provider and want to set up multiple /64 address pools for subnets and use /64 address pools to use for RA. This means prefix /64 and prefix length /64 - which is not possible because of the second issue.

Maybe this should undergo a revision...
Torturing CCR1009-7G-1C-1S+, RB450G, RB750GL, RB951G-2HnD, RB960PGS, RB260GSP, OmniTIK 5HnD and NetMetal 922UAGS-5HPacD + R11e-5HnD in my home network.
 
jadu
Frequent Visitor
Frequent Visitor
Posts: 83
Joined: Sat Feb 05, 2011 9:22 am
Location: Bucharest - Constanta

Re: IPv6 DHCP/pool issue

Mon May 14, 2012 12:18 pm

I receive the same error log.
------------------------
Don't give thanks, give karma instead!
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 6335
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: IPv6 DHCP/pool issue

Mon May 14, 2012 1:51 pm

You get this error because delegated prefix should be larger than /64 if you want to give out /64 prefixes from that received prefix. You can't get /64 prefixes from /64 pool.
 
User avatar
docmarius
Forum Guru
Forum Guru
Topic Author
Posts: 1226
Joined: Sat Nov 06, 2010 12:04 pm
Location: Timisoara, Romania
Contact:

Re: IPv6 DHCP/pool issue

Mon May 14, 2012 9:01 pm

First of all i don't want to give out /64 prefixes from it. I just need to RA it on an internal interface.
I would say that situation is legit and functional for a 1 WAN/1LAN setup, and no bigger prefix is needed as long as that prefix is delegated to one single interface.

And to receive a prefix bigger than /64 is "best practice". It SHOULD be but it MUST not be. It is not the case of my provider which gives out 1 single /64 prefix (and is sadly probably not the only one).
So if i assign that prefix to a pool and RA it on an internal interface and just forward IPv6 traffic from internal to external (gateway being the interface name) everything is in order and working. I don't need a assigned IP on the external interface. Just pass-trough so that IPv6 traffic will emerge from the external MAC, nothing else.

So
You can't get /64 prefixes from /64 pool.
is not a correct statement. You can get 1 /64 prefix from 1 /64 pool and use it. Nothing speaks against it.

IMHO prefix /64 == prefix length /64 seems correct and should be acceptable. Generally, prefix == prefix length should be acceptable.

Note that taking in account that it works even if the pool gets restricted to /72 and than used to assign an IP of /64 out of the pool to the internal interface and RA a /64 prefix from that pool - with stripped 8 bits of course - really works. Just to make about 1.8*10^19 addresses unusable because of "best practices".

Restricting the usage of the pool concept without real technical reasons does not bring anything useful to no one except error messages in a log.
Torturing CCR1009-7G-1C-1S+, RB450G, RB750GL, RB951G-2HnD, RB960PGS, RB260GSP, OmniTIK 5HnD and NetMetal 922UAGS-5HPacD + R11e-5HnD in my home network.
 
User avatar
nickshore
Long time Member
Long time Member
Posts: 501
Joined: Thu Mar 03, 2005 4:14 pm
Location: Suffolk, UK.
Contact:

Re: IPv6 DHCP/pool issue

Wed May 16, 2012 1:49 pm

As far as I understand it they only intend you to use the DHCPv6 server to serve prefix delegations, so they expect you to have a pool of them to hand out.

They haven't planned/implemented the RA use yet.

Nick.
Nick Shore MTCNA MTCWE MTCRE MTCINE MTCTCE
LinITX.com - MultiThread Consultants
Get your MikroTik RBs and Training: http://linitx.com/brand/mikrotik
Official UK MikroTik Distributor
IRC chan: #routerboard on irc.z.je (IPv4 and IPv6)
 
User avatar
docmarius
Forum Guru
Forum Guru
Topic Author
Posts: 1226
Joined: Sat Nov 06, 2010 12:04 pm
Location: Timisoara, Romania
Contact:

Re: IPv6 DHCP/pool issue

Thu May 17, 2012 8:32 am

RA is implemented since ages. Prefix delegation works since 5.11 as i remember.
And everyone tries to find excuses for putting "<" instead of "<=" in the code (even the error message is correct, but not the check).
A prefix is valid with a length equal to the prefix. This is what you get from your DHCPv6 server. And this is what every ISP hands out. A prefix which you can fully use, to the last IP in that prefix. And that means prefix equal length, not less.

And it is about DHCPv6 CLIENTS with PD, not about DHCPv6 servers.

You get a prefix from the server via DHCP. Its length equals the prefix (e.g. /64) and you have to create a dynamic pool to use that prefix (e.g. delegate is further). In this case you get an error in the log stating that the length is bigger than the prefix (which is not true, it is not bigger, it is EQUAL and not an error. The prefix length can not be bigger than the prefix, but it can be EQUAL or LESS).
I can not test prefixes other than /64 from my ISP, but this probably happens on any prefix length since prefix will be equal to prefix length when acquired by the DHCP client. (What would be the use e.g. to delegate a prefix of /48 and a length of /64 so you get only one /64 piece of it? Just to say you have /48?)

Everyone assumes I want to delegate prefixes or run a DHCP server from a pool.
No. I just want to assign the prefix to one internal interface and one single internal network so that individual computers can do autoconf via RA. Which i think is the ultimate goal of prefix delegation - to get an IP from the DHCP assigned to each computer in the network (and the simplest way is RA). And since DHCP allows a prefix to change, static assignment is not an option. So i need a dynamic pool populated by the DHCP client from which to advertise the prefix and here i get the error in the error log, error which is not a legitimate one.

IT WORKS nicely except those errors in the log during dynamic pool creation.
Torturing CCR1009-7G-1C-1S+, RB450G, RB750GL, RB951G-2HnD, RB960PGS, RB260GSP, OmniTIK 5HnD and NetMetal 922UAGS-5HPacD + R11e-5HnD in my home network.
 
User avatar
mrz
MikroTik Support
MikroTik Support
Posts: 6335
Joined: Wed Feb 07, 2007 12:45 pm
Location: Latvia
Contact:

Re: IPv6 DHCP/pool issue

Thu May 17, 2012 1:32 pm

We will change the code that it accepts /64 prefix without error messages, as you say it should be valid.
 
User avatar
docmarius
Forum Guru
Forum Guru
Topic Author
Posts: 1226
Joined: Sat Nov 06, 2010 12:04 pm
Location: Timisoara, Romania
Contact:

Re: IPv6 DHCP/pool issue

Thu May 17, 2012 7:48 pm

Thank you. Just a small comment:
The idea is to accept length == prefix for dynamic pools from DHCP clients.
This is how i see it:
ISP ----> DHCPv6 (pref == len) ----> dynamic pool (pref >= len) ----> prefix delegation (prefix >= len)
                                                                          ^
                                     static pool (pref >= len) -----------+
If this would hurt in any form other functionalities, keep the restriction on creating static pools (pref > len) and allow it only for dynamic pools (which would be sufficient for simple DHCPv6 clients & PD).
At the moment i can not imagine a situation in which prefix==length would do something wrong, but your developers know better.
Torturing CCR1009-7G-1C-1S+, RB450G, RB750GL, RB951G-2HnD, RB960PGS, RB260GSP, OmniTIK 5HnD and NetMetal 922UAGS-5HPacD + R11e-5HnD in my home network.
 
User avatar
docmarius
Forum Guru
Forum Guru
Topic Author
Posts: 1226
Joined: Sat Nov 06, 2010 12:04 pm
Location: Timisoara, Romania
Contact:

Re: IPv6 DHCP/pool issue

Thu May 31, 2012 12:07 am

Thank you!
Released and seems to work OK in 5.17 with no errors.
(PD setup with 1 PPPoE + DHCPv6 client -> pool /64 -> interface /64 + adv).
Torturing CCR1009-7G-1C-1S+, RB450G, RB750GL, RB951G-2HnD, RB960PGS, RB260GSP, OmniTIK 5HnD and NetMetal 922UAGS-5HPacD + R11e-5HnD in my home network.
 
User avatar
nickshore
Long time Member
Long time Member
Posts: 501
Joined: Thu Mar 03, 2005 4:14 pm
Location: Suffolk, UK.
Contact:

Re: IPv6 DHCP/pool issue

Thu May 31, 2012 3:37 pm

How did you assign from the pool to the interface ?

Nick.
Nick Shore MTCNA MTCWE MTCRE MTCINE MTCTCE
LinITX.com - MultiThread Consultants
Get your MikroTik RBs and Training: http://linitx.com/brand/mikrotik
Official UK MikroTik Distributor
IRC chan: #routerboard on irc.z.je (IPv4 and IPv6)
 
User avatar
docmarius
Forum Guru
Forum Guru
Topic Author
Posts: 1226
Joined: Sat Nov 06, 2010 12:04 pm
Location: Timisoara, Romania
Contact:

Re: IPv6 DHCP/pool issue

Thu May 31, 2012 11:18 pm

If address is set to something like ::1/64, if the pool is populated, it will get the proper IP automatically, using prefix from pool | (or) address as defined. In my case, prefix is 2a02:2f02:1022:b08b::/64 from DHCP assigned to pool, so resulting address is 2a02:2f02:1022:b08b::1 and the associated /64 prefix is advertized on the LAN.
Assignment to local machines in the LAN is done via RA, and addresses are generated automatically using prefix + suffix derived from mac address.
You do not have the required permissions to view the files attached to this post.
Torturing CCR1009-7G-1C-1S+, RB450G, RB750GL, RB951G-2HnD, RB960PGS, RB260GSP, OmniTIK 5HnD and NetMetal 922UAGS-5HPacD + R11e-5HnD in my home network.

Who is online

Users browsing this forum: Baidu [Spider] and 265 guests