For radius scenarioYes there are two separate parameters for ppp secrets
remote-address - this is for ipv4 address
remote-ipv6-prefix - this one is for ipv6 prefix
TABLE radcheck id username attribute op value 1 alex Password == test TABLE radusergroup username groupname priority alex ppp 1 TABLE radgroupreply (common attributes which we give every ppp-user) id groupname attribute op value 1 ppp Framed-Protocol = PPP 2 ppp Service-Type = Framed-User TABLE radreply (user-specific attributes, IPv4 and IPv6 addresses) id username attribute op value 6 alex Framed-IPv6-Prefix = 2001:470:9de7:11::/64 3 alex Framed-IP-Address = 10.9.1.11 4 alex Framed-IP-Netmask = 255.255.255.255
0 DL fe80::20c:42ff:fe0d:e5b/64 bridge1_local no 1 DL fe80::20c:42ff:fe0d:e5f/64 bridge2_wan no 2 DL fe80::a/64 pppoe-out1 no
0 ADS ::/0 pppoe-out1 1 1 ADS fe80::50/128 pppoe-out1 1
0 A S ::/0 xx:xx:1:3e8::1 1 1 ADS xx:xx:1:2710::/64 1 2 ADS fe80::a/128 1
[admin@MikroTik] > /ipv6 route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable # DST-ADDRESS GATEWAY DISTANCE 0 A S ::/0 2001:470:1f0a:1b4e::1 1 1 ADC 2001:470:1f0a:1b4e::/64 he-ipv6 0 2 ADC 2001:470:1f0b:1b4e::/64 ether1-gateway 0 3 A S 2001:470:9de7:1::/64 2001:470:1f0b:1b4e::10 1 4 ADS 2001:470:9de7:11::/64 1 5 ADS fe80::b/128 1 [admin@MikroTik] > ping 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 HOST SIZE TTL TIME STATUS 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 56 64 0ms echo reply 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 56 64 0ms echo reply 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 56 64 0ms echo reply sent=3 received=3 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=0ms [admin@MikroTik] >
[admin@MikroTik] > /ipv6 route print Flags: X - disabled, A - active, D - dynamic, C - connect, S - static, r - rip, o - ospf, b - bgp, U - unreachable # DST-ADDRESS GATEWAY DISTANCE 0 ADS ::/0 pptp-out1 1 1 X S ::/0 2001:470:1f0b:1b4e::1 1 2 ADS fe80::4e/128 pptp-out1 1 [admin@MikroTik] > ping 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 HOST SIZE TTL TIME STATUS fe80::4e 104 64 1ms destination unreachable fe80::4e 104 64 0ms destination unreachable fe80::4e 104 64 1ms destination unreachable sent=3 received=0 packet-loss=100% [admin@MikroTik] >
[admin@MikroTik] > /ipv6 address add address=2001:470:9de7:11::10/64 interface=pptp-out1 [admin@MikroTik] > ping 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 HOST SIZE TTL TIME STATUS 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 56 63 1ms echo reply 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 56 63 1ms echo reply 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 56 63 1ms echo reply 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 56 63 1ms echo reply sent=4 received=4 packet-loss=0% min-rtt=1ms avg-rtt=1ms max-rtt=1ms [admin@MikroTik] > /ipv6 address print Flags: X - disabled, I - invalid, D - dynamic, G - global, L - link-local # ADDRESS INTERFACE ADVERTISE 0 XG 2001:470:1f0b:1b4e::10/64 ether1-gateway no 1 XG 2001:470:9de7:1::1/64 ether2-local-master yes 2 DL fe80::20c:42ff:fe80:b2c6/64 ether2-local-master no 3 DL fe80::20c:42ff:fe80:b2c8/64 ether4-local-slave no 4 DL fe80::20c:42ff:fe80:b2c9/64 ether5-local-slave no 5 DL fe80::20c:42ff:fe80:b2c5/64 vlan3 no 6 DL fe80::20c:42ff:fe80:b2c5/64 vlan10 no 7 DL fe80::20c:42ff:fe80:b2c5/64 vlan1 no 8 DL fe80::20c:42ff:fe80:b2c5/64 ether1-gateway no 9 DL fe80::20c:42ff:fe80:b2c5/64 br0 no 10 DL fe80::b/64 pptp-out1 no 11 G 2001:470:9de7:11::10/64 pptp-out1 yes [admin@MikroTik] > /ipv6 address disable numbers=11 [admin@MikroTik] > /ipv6 address enable numbers=11 [admin@MikroTik] > ping 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 HOST SIZE TTL TIME STATUS 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 56 63 1ms echo reply 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 56 63 1ms echo reply 2001:470:1f0b:1b4e:4a5b:39ff:fe06:72a1 56 63 0ms echo reply sent=3 received=3 packet-loss=0% min-rtt=0ms avg-rtt=0ms max-rtt=1ms [admin@MikroTik] >
"not yet" means "still in progress" or could we take it as a final feature? Thank you shade and janisk.RouterOS PPPoE client is not yet capable to get IPv6 prefix from PPPoE-server.
It gets link local address and that is it.
What about NAT 1:1?Is anyone doing this? Is there a HOW-TO or anything on WIKI? Anyone share a sample config?
I do not see where the IP 'pools' supports IPv6? I imagine you assign every user a single IPv6 IP and also route them an entire subnet of IPv6?
I have spent some time thinking about it. Client RouterOS can´t know which of interfaces on the router is local and that´s why RouterOS can´t add the IPv6 address to right (local) interface or bridge. We can do it by hand, that´s no problem here of course. But it could be handy to know, what IPv6 prefix is waiting for client, so we have not to ask the ISP. Client RouterOS PPPoE should add (disabled) IPv6 address to (for example pppoe) interface and next step admin of the client router will decide which interface of the router is local and change (and enable) IPv6 adress to this interface.RouterOS PPPoE client is not yet capable to get IPv6 prefix from PPPoE-server.
It gets link local address and that is it.
And we just need to wait
My client is windows 7and i have same problem . with mikrotiks own remote-ipv6-prefix everything works fine but with radius framed-ipv6-prefix the router ignores it .rigt? So in my case, framed-ipv6-prefix reply attribute is ignored by NAS. PPPoE session set fe80::x/64 route entry only. On both sides (NAS and client). I didnt have time to check what is going wrong, but if you have any ideas please let me know, thanks.
Framed-IPv6-Prefix: ['2001:470:9de7:11::/64']
Jun/26/2011 16:18:31 radius,debug,packet Framed-IPv6-Prefix = 0x326130303a316365303a303a31303a3a Jun/26/2011 16:18:31 radius,debug,packet 2f3634
could you provide some example please?RouterOS expects string that contains ipv6 prefix in form/
What is "PPPv6 with PD"?Now RouterOS 5.8 supports IPv6 pools.
Any chances for PPPv6 with PD on next release?
Hi, i have the same problem currently. Did you manage to get that fixed?My client is windows 7and i have same problem . with mikrotiks own remote-ipv6-prefix everything works fine but with radius framed-ipv6-prefix the router ignores it .rigt? So in my case, framed-ipv6-prefix reply attribute is ignored by NAS. PPPoE session set fe80::x/64 route entry only. On both sides (NAS and client). I didnt have time to check what is going wrong, but if you have any ideas please let me know, thanks.
radius server log showsmikrotik log showsCode:Select allFramed-IPv6-Prefix: ['2001:470:9de7:11::/64']
routeros version 5.4 . any trick ?!Code:Select allJun/26/2011 16:18:31 radius,debug,packet Framed-IPv6-Prefix = 0x326130303a316365303a303a31303a3a Jun/26/2011 16:18:31 radius,debug,packet 2f3634
Can you predict when? We are testing IPv6 over pppoe for our ISP and having DHCPv6 client with PD is great, but we need PD assignment to interfaces in order to render your device usefulassignment of acquired address on one of the interfaces with /64 and advertise is coming.
No way, /64 PD is a very wrong thing to do for ISP.if client is receiving /64 prefix, you could get the value and assign this address using script
因为没有testing-build可用this feature automated in dhcp-client.
We actually put global IPv6 addresses on eth interfaces, just for later troubleshooting purposes. Problem is, that PD currently changes everytime you connect and our ISP is fixing that (as this is not a good practice). Would be too much of a hassle to script all that probably (or not?)you do not need addresses for intermediate network stuff, just the end equipment of users should get the address. There you give out addresses with /64
Anyway, nothing that script cannot do.
I would think that /64 for residential and /48 for business would be fine. Not sure why home users would need to subnet?No way, /64 PD is a very wrong thing to do for ISP.if client is receiving /64 prefix, you could get the value and assign this address using script
因为没有testing-build可用this feature automated in dhcp-client.
They do /56 for residential user and /48 for business - as it is supposed to be.
Dude. V6 is introduced to give everyone enough addresses. There are enough addresses available and no reason to conserve.I would think that /64 for residential and /48 for business would be fine. Not sure why home users would need to subnet?
完全正确。请避免/ 64 PD给最终用户would like to avoid users inventing disgusting mechanisms used for splitting /64 in more subnets. Users will use more subnets, as already mentioned, for guest wifi, private wifi, sensors, local net, media devices etc etc. It's up to vendors, what they'll recommend, but currently IPv6 subnetting looks good. At least /56 for residential users is advisable, if not /48.Dude. V6 is introduced to give everyone enough addresses. There are enough addresses available and no reason to conserve.I would think that /64 for residential and /48 for business would be fine. Not sure why home users would need to subnet?
It's not difficult to imagine that users would like one subnet for private stuff, guest hotspot, gaming devices etc.
How about the /48 IPv6 PI assignments - with ~200 customers in a rural area I'm still a bit too small to become a LIR (for cost reasons), so can't get a /32 but only a /48 IPv6 PI (currently have /23 IPv4 PI for BGP with two uplinks, and just starting to look into IPv6) - is there a chance to propose something to allow making them a little larger, like /44 or /40? As it is now, I can get a /48 and at best give customers something like /60 (for up to sixteen /64 subnets per customer, looks like a reasonable compromise) to have some room for growth (with /56, there are only 256 of them in a /48). The RIPE IPv6 policy is probably still in flux, at least that's the impression I got when asked my sponsoring LIR for IPv6 PI space.For this reason Mark Townsley and I also proposed a RIPE IPv6 policy change to RIPE community - extending initial allocation size (/32) to /29 without additional documentation. Why? Because small ISPs that would like to implement 6RD with one 6RD domain will be able to give out just /64 with /32 initial allocation (32bits+32bits). So, this is so wrong that we proposed a policy change.
http://www.ripe.net/ripe/policies/proposals/2011-04
Please don't use /64 as PD for users. Fullstop
Cheers, Jan Zorz
According to RIPE policy, you *MUST NOT* use IPv6 PI space for assignments to *any* customers. IPv6 PI space is only for your infrastructure, meant for enterprise companies that are multihomed.How about the /48 IPv6 PI assignments - with ~200 customers in a rural area I'm still a bit too small to become a LIR (for cost reasons), so can't get a /32 but only a /48 IPv6 PI (currently have /23 IPv4 PI for BGP with two uplinks, and just starting to look into IPv6) - is there a chance to propose something to allow making them a little larger, like /44 or /40? As it is now, I can get a /48 and at best give customers something like /60 (for up to sixteen /64 subnets per customer, looks like a reasonable compromise) to have some room for growth (with /56, there are only 256 of them in a /48). The RIPE IPv6 policy is probably still in flux, at least that's the impression I got when asked my sponsoring LIR for IPv6 PI space.