As in the subject, my request is for an IPv6 enabled hotspot, either dual stacked or IPv6 only.

Best solution would be to allow both IPv4 and IPv6 enabled users to access however one hotspot for each would be a good start.

I've previously emailed this request to Mikrotik who have indicated they are working on this, but I'm reposting here to get a feel from others as to who is interested in this becoming a reality for v5 and to indicate that I would be more than willing to test any Alpha or Beta releases of an IPv6-hotspot package soon as it becomes available.

You may want to add at least two zeroes at the end of that figure, else I suppose nobody at mikrotik will be interested.

I was figuring I wouldn't be the only one wanting this so other people could chip in also.

Since this is a feature we need I have been giving this some consideration.

I have developed the back end software / client hotspot website, radius servers etc that run our hotspots. So I am keen to see how we can support IPv6 clients on our hotspot networks.

Since I don't now the internal workings of RouterOS code I am making quite a few assumptions here. Perhaps someone from Mikrotik can set me straight where I get it wrong.

I assume that the easiest thing for Mikrotik to do is to copy the IPv4 Hotspot and make an IPv6 copy of the same thing that works on the IPv6 Protocol with the IPv6 Firewall.

There are three ways that the hotspot could be setup.
1. IPv4 Only
2. Ipv6 Only
3. Ipv4 + Ipv6 Dual Stack.

If the software is pretty much copied from IPv4 to IPv6 for the hotspot that will take care of the single stack (Option 2 above) senario.

For Option 3 the question becomes,
a) how does the dual stack client login to both IPv4 and IPv6 Hotspots
b) do the two hotspots have independant radius / user stats sessions or combined

For 3a) currently (on our system anyway) client initally hits the mikrotik login.html which redirects to our hotspot website where the client must purchase time&data the when they click the connect button to continue we redirect them back to the mikrotik alogin.html with radius credentials so that the client can be logged in via radius. At this point the status.html pops up in a new window and the main window redirects to the initial page the client requested. I invisige that another redirect happen here that also make a call to a mikrotik blogin.html to do an IPv6 radius or whatever login. This second redirect would be to an IPv6 Address to the the mikrotik could discover the IPv6 Address Associated with the client in addition to the IPv4 Address. A session token could be passed to both the IPv4 alogin.htm and the IPv6 blogin.html, so the router can know which IPv4 belongs with which IPv6.

For 3b) To have combined sessions the IPv4 counters would have to be combined with the IPv6 counters to create a single radius session. ie instead of IPv6 creating it's own radius session, it would simply add itself to the existing IPv4 session. I have a feeling that this might be tricky to achieve without some effort. The main problem I see with this is that it creates the idea of a master and slave protocol. Let's suppose that a client first starts his session with a call to an IPv6 web site such as http://ipv6.google.com, but the IPv4 is the master protocol, then the hotspot will have to redirect the browser to the IPv4 hotspot and login from there. I'm not really sure how much of a problem this is, or if it even is one.

Naturally I am happy to assist with testing this new feature.

The current Hotspot solution relies heavily on NAT.

The problem: There's no such thing for IPv6.

Not really, most of the rules are simply catch-all redirects..

Eg: if dst-port=80 and protocol=tcp and user=no-auth then redirect to 65XXX (whatever port it is the hotspot runs on)
same with dns, redirect any port 53 udp requests to the mikrotiks IP address itself.

These could remain the same on an IPv6 hotspot.

Those redirects are NAT. The destination IP address of the packet is rewritten to an IP address local to the router. From the iptables man page:

REDIRECT

This target is only valid in the nat table, in the PREROUTING and OUTPUT chains, and user-defined chains which are only called from those chains. It redirects the packet to the machine itself by changing the destination IP to the primary address of the incoming interface (locally-generated packets are mapped to the 127.0.0.1 address). It takes one option:
--to-ports port[-port]
This specifies a destination port or range of ports to use: without this, the destination port is never altered. This is only valid if the rule also specifies -p tcp or -p udp.

Derp sorry. I stand corrected.

This might help....

see
http://www.suse.de/~krahmer/ip6nat/

This might help....

see
http://www.suse.de/~krahmer/ip6nat/

what is that?

This might help....

see
http://www.suse.de/~krahmer/ip6nat/

what is that?

It's been suggested that the lack of a NAT capability for IPv6 is a roadblock for IPv6 Hotspot. Here is an implementation of NAT allowing IPv6 Redirect.

ip6nat
======

Requires libnefnetlink (libnfnetlink-0.0.39 tested) and
libnetfilter_queue (libnetfilter_queue-0.0.16 tested), both
available on http://netfilter.org.
Should also be available on most dists via libnfnetlink,
libnfnetlink-devel, libnetfilter_queue and libnetfilter_queue-devel
RPMs.

I know, I know! IPv6 was designed for end-to-end use-case and there
is no need for NAT etc. Thats exactly why theres no ip6nat
inside netfitler. However, in some cases, especially transparent
proxying for example to setup on-the-fly virus scanning, SPAM traps
or pentesting SSL applications, it is very useful.

Even though ip6nat could NAT whole network ranges from private address
ranges (link local) to public ones, the intended use is as
described above.

There is a sample.conf file describing how to use the rules, then
basically just start ip6nat as root with your conf-file,
redirect the traffic you need to translate via ip6table QUEUE target
into ip6nat, and you are done.

tp-test shows how you can use ip6nat API to find out where
original connections should go if you write a transparent
proxy.

If using -R, make sure you have a /dev/log device inside.

#
# ip6nat config file
#
# generic template:
# <proto> <table> <addr1> <port1>-><addr2> <port2>
#
# where: proto is one of {icmp, udp, tcp}
# table is one of {dnat, snat} for destinantion NAT or source NAT
# addr1 the address or address-range that the packet must match
# if table is dnat, the destination of packet must match
# and respectively for snat the source must match
# port1 if proto is udp or tcp, this port must match too;
# source-port if snat is used, destination port if dnat is used
# a port of 0 matches any port
# addr2 this is the address to which the packet is translated if addr1/port1
# rule matches
# port2 ditto. if port2 is 0, then the port is not translated

# Please also see setup.sh. 2001::1 was a local address, 2002, 3001 and 4000
# were remote machines with apropriate routing entries set.
#
# For every proto and table, only the first matching rule is taken,
# so write the more specific rules first (e.g. single address before network
# address). As a general rule, do not try to be too clever with the rules,
# like SNATing and DNATing packets so that they all equal or alike,
# this will confuse the translator.
# Also, use carefull chosen ip6table rules to only QUEUE the packets
# you want to translate. This speeds up NAT and helps to avoid
# misconfigs. See setup.sh how to QUEUE packets.

# all tcp to 3001::1.22 is translated to 2001::1.22
tcp dnat 3001::1 22->2001::1 0

tcp dnat 3001::1 1234->2001::1 8080

# all tcp from 2001::1.x is translated to src port 7890 (singleton connection)
#tcp snat 2001::1 0->2001::1 7890

# all tcp to 2002::1.22 is translated to 2001::1.1234
tcp dnat 2002::1 22->2001::1 1234

# icmp has no ports, set it to 0
icmp dnat 3001::1 0->2001::1 0

# all tcp to network 4000::/16 port 22 is translated to 2002::1.22
tcp dnat 4000::1/16 22->2002::1 0

Pepperspot (the IPv6 version of chillispot) also has a hotspot implementation running now.

I believe this is the relevant IPTABLES file https://pepperspot.svn.sourceforge.net/ ... .ip6tables
however the whole source code is available http://pepperspot.sourceforge.net/

Those are non standard hacks. We will only use approved standards in our ipv6 implementation

Those are non standard hacks. We will only use approved standards in our ipv6 implementation

So it's official then, Mikrotik is getting out of the hotspot with captive portal business?

maybe it's possible to achieve this in another way, we are still researching possibilities

The Pepperspot solution was kinda neat in a way. They appear to be routing all IP traffic (v6 and v4) across a TUN interface so that it is consumed in userland by their Hotpot process. That process then puts packets out on the physical interface for authenticated clients. No NAT required. On the other hand, the process always consumes all packets so I would think performance is fairly bad.

At least that is how I think it works. Didn't have too much time to go through their code, and I'm a very bad programmer to boot.

There isn't an RFC for an IPv4 captive portal implementation let alone IPv6

There isn't an RFC for an IPv4 captive portal implementation let alone IPv6

what do you mean, of course there is. NAT is a documented technology standard. All the mechanism that make hotspot work are.

To bevhost: Code you provided link to captures all IPv6 traffic to user space for processing and that will mean massive performance penalty.

To omega-00: we could not find any NAT or redirects in pepperspot code neither in IPv4 nor IPv6.

To bevhost: Code you provided link to captures all IPv6 traffic to user space for processing and that will mean massive performance penalty.

Actually it only captures IPv6 traffic that is directed to the QUEUE target in iptables, so it's not all traffic.

And that is the one reason why it is better than the pepperspot solution.
The other reason is that pepperspot will only work on the direct LAN so hotpsot users can't be behind another router.
The Juniper Junos Captive Portal has a similar problem.

You would not actually have to use the nat software I provided, you could just process the QUEUE traffic in userspace in your own code.

Let's forget the captive portal (ip6nat) problem for a moment and let us assume that the client begins with a request to an IPv4 web page.
Our clients are already trained to visit a web page before attempting to use outlook, it wouldn't be too much of a stretch to ask them use an IPv4 home page.

That said, the remainder of the IPv6 hotspot code could still be done as far as I can see as per my much earlier post quoted in part here.

For 3a) currently (on our system anyway) client initally hits the mikrotik login.html which redirects to our hotspot website where the client must purchase time&data the when they click the connect button to continue we redirect them back to the mikrotik alogin.html with radius credentials so that the client can be logged in via radius. At this point the status.html pops up in a new window and the main window redirects to the initial page the client requested. I invisige that another redirect happen here that also make a call to a mikrotik blogin.html to do an IPv6 radius or whatever login. This second redirect would be to an IPv6 Address so that the mikrotik could discover the IPv6 Address Associated with the client in addition to the IPv4 Address. A session token could be passed to both the IPv4 alogin.htm and the IPv6 blogin.html, so the router can know which IPv4 belongs with which IPv6.

For 3b) To have combined sessions the IPv4 counters would have to be combined with the IPv6 counters to create a single radius session. ie instead of IPv6 creating it's own radius session, it would simply add itself to the existing IPv4 session. I have a feeling that this might be tricky to achieve without some effort.

If it is possible to add the IPv4 data and the IPv6 data in the same radius session, I would like my own extra piece of functionality and that is to have traffic to the walled garden not count towards the radius totals. (Since that is free traffic that they can use without logging in)

If you're going to add the IPv6 functionality by logging in clients via IPv4 on both protocols you're assuming a dual stack.

Dual stacks prefer IPv6. The moment at least a good portion of the web is available via IPv6 and people actually publish quad A record you have a problem: it might be a while for anyone to see a login page in a browser as you have to wait until they try to access an IPv4 only site. What you're suggesting might help in the interim (and I'm not at all saying Mikrotik shouldn't consider it) but as IPv6 usage increases it becomes less valuable as a solution.

What you're suggesting might help in the interim (and I'm not at all saying Mikrotik shouldn't consider it) but as IPv6 usage increases it becomes less valuable as a solution.

I am well aware of that, but it's still better than no solution at all.

Absolutely.

Yes

Bring on v6 support for hotspot and PPPoE server.

Yes

Bring on v6 support for hotspot and PPPoE server.

did you read the discussion at all?

So just a quick first thing in the morning idea, What about routing all v6 traffic to a webserver that will answer any and all requests with the login info via route marking, once cleared and paid route normally, when it expires route it back to that webserver?

Seems a hell of alot better than trying to shoe-horn NAT into v6

Yes

Bring on v6 support for hotspot and PPPoE server.

did you read the discussion at all?

From reading the discussion I deduced that there is not currently IPv6 support for the hotspot. I then decided that adding IPv6 support for the hotspot would be a good thing and posted my support for the proposal in addition to IPv6 support for PPPoE server.

I don't know if you're aware but IANA is very low on unallocated IPv4 /8 blocks and predict they will run out very soon. From memory the RIR burn rate ranges between 1 and 6 /8 per year depending on location so I don't think the RIRs will be able to extend the buffer for a huge amount of time either.

So if it was unclear by my previous post: I hereby voice my support of this thread and the request to add IPv6 support to the hotspot.

So if it was unclear by my previous post: I hereby voice my support of this thread and the request to add IPv6 support to the hotspot.

There's a few things that need to be v6'ed before hotspot can run , Simple queues off the top of my head

So if it was unclear by my previous post: I hereby voice my support of this thread and the request to add IPv6 support to the hotspot.

There's a few things that need to be v6'ed before hotspot can run , Simple queues off the top of my head

I never said I was opposed to this...

14 /8's remain, Current consumption rate puts that at May 2011 followed by 6 months for the RIR's to hand it out. Then its off to the v4 market place or reclaim some of that multicast space which will be horrible

I know the queue trees are working with IPv6 at the moment as I've tested it.
Simple queues are really just a dumbed down version of the Queue tree system anyway, so you should be able to use PCQ queues to handle ranges, per user and/or IP specific queues might be a bit tricky.

If there was full radius support for IPv6 when a user auth'd you could throw their prefix into a tagged range or hand across a filter-id as is achievable in the current RouterOS versions.

14 /8's remain, Current consumption rate puts that at May 2011 followed by 6 months for the RIR's to hand it out. Then its off to the v4 market place or reclaim some of that multicast space which will be horrible

I have heard this kind of prediction every year for the last 5 years already

From reading the discussion I deduced that there is not currently IPv6 support for the hotspot. I then decided that adding IPv6 support for the hotspot would be a good thing and posted my support for the proposal in addition to IPv6 support for PPPoE server.

so, you didn't understand the main point of this discussion. it's not possible to make ipv6 hotspot because there is no NAT.

we are currently thinking of other options, but they all will impact performance in a very big way

14 /8's remain, Current consumption rate puts that at May 2011 followed by 6 months for the RIR's to hand it out. Then its off to the v4 market place or reclaim some of that multicast space which will be horrible

I have heard this kind of prediction every year for the last 5 years already

You've heard alarmist reports based on shaky data, Look at the numbers, look at consumption, Look at how many /8's are handed out each year and to what RIR's


As you can see ARIN,APNIC and RIPE picks up atleast 5 /8 per year since 2007, It will only speed up the closer we get to D-Dat

Read, Think and then shove some of your dev team into v6, Dont bury head in the sand which is all we've heard from MT regarding v6. When the last /8 is handed out from IANA people are going to be expecting a stable and well rounded v6 implementation which currently MT lacks

14 /8's remain, Current consumption rate puts that at May 2011 followed by 6 months for the RIR's to hand it out. Then its off to the v4 market place or reclaim some of that multicast space which will be horrible

I have heard this kind of prediction every year for the last 5 years already

IANA has given RIRs 12 /8 so far this year, 6 of which went to APNIC who has China and India in their area of responsibility. How much more time do you think 14 /8 is going to last when two of the most populous nations on Earth are experiencing an explosion of uptake in Internet use?

we are currently thinking of other options, but they all will impact performance in a very big way

Well just as long as the matter is being taken seriously...

I don't post on here much but have been reading on and off for over a year now and too many times I have seen people put a really good idea on here only to have it dismissed or suggest a way to shoehorn their idea into the current way of doing things.

which of the mentioned alternatives do you mean in this case?

From reading the discussion I deduced that there is not currently IPv6 support for the hotspot. I then decided that adding IPv6 support for the hotspot would be a good thing and posted my support for the proposal in addition to IPv6 support for PPPoE server.

so, you didn't understand the main point of this discussion. it's not possible to make ipv6 hotspot because there is no NAT.

we are currently thinking of other options, but they all will impact performance in a very big way

Maybe it is you that is not reading the posts.

I believe that it is possible and that it does not impact performance in a big way.

ip6tables provides a simple way to selectively route ipv6 traffic into userspace code. See QUEUE target in ip6tables.

QUEUE means to pass the packet to userspace. (How the packet can be received by a userspace process differs by the particular queue handler. 2.4.x and 2.6.x kernels up to 2.6.13 include the ip_queue queue handler. Kernels 2.6.14 and later additionally include the nfnetlink_queue queue handler. Packets with a target of QUEUE will be sent to queue number 0 in this case.

NFQUEUE
This target is an extension of the QUEUE target. As opposed to QUEUE, it allows you to put a packet into any specific queue, identified by its 16-bit queue number.

--queue-num value
This specifies the QUEUE number to use. Valud queue numbers are 0 to 65535. The default value is 0.

It can only be used with Kernel versions 2.6.14 or later, since it requires
the nfnetlink_queue kernel support.


http://netfilter.org/projects/libnetfilter_queue/

I already said above, we know about the userspace method, but it impacts performance too much

Not to ask a blatently stupid question, but given that the current HotSpot code runs IPv4, why would you *need* it to support IPv6 (on the client-facing side) in your own lifetime ?

IPv4 NATing, IPv4->IPv6 translation on the HotSpot router sorts it doesn't it ?

'Legacy' IPv4 support will be around for quite a few years, and as the code is free and stable, and Flash memory gets cheaper and bigger, it's not likely to disappear in a *poof* of smoke.

There are no mainstream Linux developers (that i know of) working on IPv6 NATting because it ruins the fundamental beauty of IPv6 - no need for NAT.

Of course it can be done, and will eventually be part of the stock linux Kernel v9.12.34, but there is no perceived need, so it makes no progress - currently.

Not to ask a blatently stupid question, but given that the current HotSpot code runs IPv4, why would you *need* it to support IPv6 (on the client-facing side) in your own lifetime ?

IPv4 NATing, IPv4->IPv6 translation on the HotSpot router sorts it doesn't it ?

'Legacy' IPv4 support will be around for quite a few years, and as the code is free and stable, and Flash memory gets cheaper and bigger, it's not likely to disappear in a *poof* of smoke.

Can you point to a working method of doing Ipv4->Ipv6 Translation that works both ways? Clients want IP addresses that are reachable from he Internet, I don't see how NAT can solve this problem.
The closest thing I've seen is described here http://en.wikipedia.org/wiki/6rd

Clients want IP addresses that are reachable from he Internet

Right now we already have to use PPPoE client instead of Hotspot login for clients that want a public IP address. It requires a lot more helpdesk time to get it setup.

I can Google !

Can i get MTCG now ?

http://www.kernel.org/doc/ols/2003/ols2 ... -34-43.pdf

Clients want IP addresses that are reachable from he Internet

Right now we already have to use PPPoE client instead of Hotspot login for clients that want a public IP address. It requires a lot more helpdesk time to get it setup.

And some sites have downstream routers with more clients behind them. These require L2TP tunnels. Even more hassles.

I can Google !

Can i get MTCG now ?

http://www.kernel.org/doc/ols/2003/ols2 ... -34-43.pdf

This looks like a whitepaper, not an actual implementation?

Also, it only appears to allow access to IPv4 hosts from IPv6 where the IPv4 address is a public one AND the host is registered in DNS.

Downstreaming from a Client-facing hotspot isn't a brilliant idea.

I have did that a few times because it is cheaper/easier than putting up another antenna.

To save cost/hassle/security error why not just make a VAP on the same interface ?

Not to ask a blatently stupid question, but given that the current HotSpot code runs IPv4, why would you *need* it to support IPv6 (on the client-facing side) in your own lifetime ?

IPv4 NATing, IPv4->IPv6 translation on the HotSpot router sorts it doesn't it ?

'Legacy' IPv4 support will be around for quite a few years, and as the code is free and stable, and Flash memory gets cheaper and bigger, it's not likely to disappear in a *poof* of smoke.

Can you point to a working method of doing Ipv4->Ipv6 Translation that works both ways? Clients want IP addresses that are reachable from he Internet, I don't see how NAT can solve this problem.
The closest thing I've seen is described here http://en.wikipedia.org/wiki/6rd

NAT64 in Cisco CGv6 can use stateful mapping both ways, But the reality if that soon clients will have to get used to the idea of not having v4 space back to them, Unless they pay for it.

Counter to What Normis and MT believe and refuse to talk about there is little v4 space left, One thing that will occur for those who have the need for v6 dumped on them at the last minute will be v4 space marketplace where you can buy and sell ranges, The problem with that idea is that if you have a /16 and want to sell a couple of /24's you can no longer announce your /16 but rather a whole bunch of smaller subnets, Which will explode the size of a full route table and so on, One Cisco specialist thinks that if this occurs we could see a global full route table in the area of 700k+ routes (Not good for MT since it struggles a little right now with 350k routes)

Start planning on not being able to give 1 v4 IP to a user anymore, Its not going to be able to happen soon. Best case your clients access v4 land behind a single IP or a couple of IP's, If they need servers or things behind their connection tell them to use their v6 address's

I thought most Implementations came from whitepapers (RFC springs to mind) ?

Are you asking *if* it will be done, or *how do i do it now* ?

not being able to give 1 v4 IP to a user anymore

If you have just 1 public v4 (with enough speed attached), you can have plenty of IPv4 private space to make a Mint.

Hmm. That's what we do isn't it ?

IPv6 is Coming Soon, but don't bother suggesting IPv4 will get turned off like analogue TV.

IPv6 was designed to accomodate the entire IPv4 range from it's inception.

The 'running out of IPs' is a serious thing - we are (did ages ago actually).

IPv6 (i forget where i read this) has enough to give 1500 addresses to each square foot of the surface of the earth.

DOH!

The designers forgot that we want to address each self-replicating Nanite individually.

I'm not happy with IPv6 because the notation is horrible. To me a : isn't as nice as a .

Probably Young people designed it. Nothing good ever comes of Youth

Of course v4's not going to be turned off any time soon but client are going to have to get used to the idea that their Internet connection isnt going to have a static v4 globally routed address to use

Dual-Stacking will be here for a long time, The first set's of dual-stack ISP's with v6 public and v4 public are here already, soon that will be dual-stack v6 public v4 RFC space at which point your SBS server e-mail and MX records will need to point to a v4 address somewhere.

v4 wont be turned off but there will be a burst v6 content sometime next year, Hosting your e-mail on your net connection with your own server will be extremely tricky to get v4 inbound e-mail at which point the first clear path will be your v6 address. There will be a sharp transition to using v6 for inbound (to user) connections for servers and the like since your ISP will be natting the RFC address on your router to a single/small bunch of v4 globally routed address

And yeah, working with v6 address is going to be a PITA atleast that worked in some things into the RFC like :: etc

IPv6 (i forget where i read this) has enough to give 1500 addresses to each square foot of the surface of the earth.

The norm is to hand a /64 to a client, a /96 has the same number of IP's as the entire v4 space including RFC etc

get used to the idea that their Internet connection isnt going to have a static v4 globally routed address to use

You mean like what most users have already ?

I have never sold a public IPv4. Never will.

get used to the idea that their Internet connection isnt going to have a static v4 globally routed address to use

You mean like what most users have already ?

I have never sold a public IPv4. Never will.

Would hate to have a net connection like that, double nat is yuck. Over in my section of the world users get very annoyed when they dont have STATIC v4 public, Same for the AU and alot of Asia aswell

Most of the countries that are grabbing v4 space are handing out public v4 to their clients, alot of the EU, USA, China, Japan, southeast Asia, AU, NZ etc

If you have just 1 public v4 (with enough speed attached), you can have plenty of IPv4 private space to make a Mint.

We're doing this now, but clients want a public Internet reachable address. Stateful NAT doesn't do this. Perhaps we should implement Stateless IVI on the MT instead.

I have never sold a public IPv4. Never will.

So you're not an Internet Service Provider then.

I've heard the whole double-nat thing is popular in LANIC area due to the fees

Downstreaming from a Client-facing hotspot isn't a brilliant idea.

I have did that a few times because it is cheaper/easier than putting up another antenna.

To save cost/hassle/security error why not just make a VAP on the same interface ?

What about those of us using the hotspot as an Ethernet authentication method. Adding PPPoE provides a public address for the user (so no double nat) while Hotspot provides private addresses NAT'd behind publics.

IPv6 (i forget where i read this) has enough to give 1500 addresses to each square foot of the surface of the earth.

The norm is to hand a /64 to a client, a /96 has the same number of IP's as the entire v4 space including RFC etc

I believe the norm is actually now to hand a /48 (or a /56 if you're stingy) to the client so they can break it up, given that people can have separate router / wireless AP.

I've heard the whole double-nat thing is popular in LANIC area due to the fees

I see a lot of "how to setup hotspot" guides that include forwarding a single Port per private IP so the users get at least one service, however IPv6 has no need for this sort of address hoarding.

The way I see it currently we end up with one of the following deployments.

1. Dual Stacked IPv4/IPv6 hotspot (seems unlikely at this point)
2. IPv6 Only hotspot.
3. IPv4 hotspot with 4-to-6 NAT of some sort.
4. IPv6 hotspot with 6-to-4 NAT of some sort.

1 would be great, 2 would be acceptable to roll out provided the upstream provider has some 6-to-4 gateway somewhere.
3 and 4 require additional components that RouterOS doesn't have yet.

Alternatively, we (speaking for my company) could roll out dual stack IPv6/IPv4 just to PPPoE users for the time being, but for the fact we still don't have access to Prefix Delegation (receiving or sending) on RouterOS currently so no way to tell users what assignment they've been allocated other than to tell each one manually.

We actually recommend the users who do PPPoE use an RB750(G) for it but that's no use right now as even if we had something other then RouterOS to do the delegation, none of those devices can receive the advertised prefixes anyway

Bit of a pickle.

The norm is to hand a /64 to a client, a /96 has the same number of IP's as the entire v4 space including RFC etc

I believe the norm is actually now to hand a /48 (or a /56 if you're stingy) to the client so they can break it up, given that people can have separate router / wireless AP.

True, No need to be wastful from the start tho, Residential's have no need for multiple subnets yet so handing out /64's is fine, /48's for Business clients

True, No need to be wastful from the start tho, Residential's have no need for multiple subnets yet so handing out /64's is fine, /48's for Business clients

If you want to be really stingy just allocate a /60, I have a residential internet service and I use more than one LAN.
I have two SSID's on wireless and that allocate different subnets. One uses Hotspot and one doesn't. I don't normally allow guest wireless users in my house onto my LAN. I don't see why other home users would never want to do this.

Perhaps you have a seperate router for controlling access to the kids bedrooms.

It's not like there is a lack of address space, that's why we want IPv6 to start with.

Do you separated layer 2 between your "Hotspot" and Normal lan? If not having 2 subnets is a complete waste of time since v6 local link address would be able to be used between then

Do you separated layer 2 between your "Hotspot" and Normal lan? If not having 2 subnets is a complete waste of time since v6 local link address would be able to be used between then

of course, how silly do you think I am?

an interesting article today: http://arstechnica.com/business/news/20 ... e-ugly.ars

So you're not an Internet Service Provider then.

Please forgive my presumptiousness.

I've only been in internet since about 1990, so i still have a lot to learn.

It's was a real help to have gotten into electronics 11 years earlier, and programming a year after that, but i only started business on my own 17 years ago, so how could i possibly know anything ?

What about those of us using the hotspot as an Ethernet authentication method

So do I in most cases on the WLAN side, but the temptation to just stick a Downstream HotSpot on it and add a binding on the Upstream HotSpot is tooo easy to *not* do.

Cheers for the link to the great article normis.

Basically IPv4 is fine.

It's just that like every resource available on this Planet, the Greedy Bastards Want More.

So, once again, we'll skip over making the very very best out of a proven, understood and workng technology in favour of some new s'hit that will probably be obsolete before it is fully implemented.

And what for ?

Faster videos, porn, games, music and other related useless garbage that actually enhances our lives by about -0.5%. I Forgot Facebook. And Twitter. Maybe MT forum (blush).

Personally i've used the Internet to make Money, and have recently used it to find out how Food is made. Apparently you need seeds, soil, sunshine and water, None of these have an IP address, so i'll just have to experiment. What is PPTP ? Plant To Plant Trowel Protocol.

Ranted out.

an interesting article today: http://arstechnica.com/business/news/20 ... e-ugly.ars

I find it slightly ironic that you've posted this when MT has said v6 isnt being really worked on due to demand and the article states that 1/2 the reason why the transition will be painful if because IT services and manufactures are ignoring it or not putting the resources needed on it. MT's v6 features need work, There are large holes in whats there that is needed for transition and getting traction is slow, The article you point to states v4 will run out in 2-3 years, It's looking like its closer to 2 and thats inline with what the numbers point to, 9 months till IANA runs out and 6-12 months till RIR's run out.

v6 will be painful, v4 life support will be more painful, There is growing demand that IANA steal back space from things like Multicast space which will be hell and require ALOT of work by everyone, Selling and Buy v4 space will result in a global route table blowout, NAT444 will introduce a support nightmare.

So once again I implore MT to focus more of its dev team on filling in the gaps with v6 and to do it in v5 so that by the time we hit v5.10+ we will have a stable feature rich ROS version that if needed wont need any v4 address to do anything.

So you're not an Internet Service Provider then.

Please forgive my presumptiousness.

I've only been in internet since about 1990, so i still have a lot to learn.

It's was a real help to have gotten into electronics 11 years earlier, and programming a year after that, but i only started business on my own 17 years ago, so how could i possibly know anything ?

Small ISP's have gotten away with this in the past but with where tech is heading they wont be able to much longer, I have no doubt that you know what your doing but the standard is most parts of the real world hand out public v4 to their clients

MT has said v6 isnt being really worked on due to demand

what? where did I say that?
http://forum.mikrotik.com/viewtopic.php ... 12#p229412

> Hello,
>
> There are some principles we use when we are choosing what features to
> implement next. No matter if it is IPv6 feature, new wireless feature,
> hardware support feature or any other feature.
>
> 1) are there standards available that describe how feature should be implemented?
> 2) number of clients asking for specific feature.
> 3) number of clients willing to try out and debug new feature if necessary.
>
> We have resources to implement only few new features at the same time.
> And situation at the moment is simple - new wireless protocols and
> features / proper multi-cpu support and load balancing over cores are
> features that are far more demanded by customers than IPv6 features.
>
> Also only few customers have actual feature requests - most of others
> just ask "all IPv6".
>
> Sorry, bur at this point i can't give you any time frame.
>
>
> Regards,
> Janis Megis


I've seen you post, I see it often with suppliers trying to dodge things, Can you settle this once and for all and list what v6 features you plan on adding in v5? Something I dont see listed anywhere

too late, see above

You said soon in your posts for API/Winbox/BTest (Does torch work???) can we take that to mean in v5?

If it does then great but very said its taken the better part of 2 months and a number of threads to nail MT down to putting out some kind of a roadmap

All of that means this year in v5

Thank you! I've got a nice bottle of wine here waiting to opened when MT put some kind of a roadmap on this even as basic as it is. That wasnt that hard for you to release was it?

most parts of the real world hand out public v4

Maybe i have always inhabited parts of the Unreal world. Maybe a Virtual world.

Still seems to make money

Does nobody else find it interesting how Sales and Marketing can influence the Minds of people ?

There is no *need* for IPv6. It is simply a logical Upgrade to IPv4.

However, it is now Urgent for what reason ?

Sales. Lots and lots of Sales - by transit providers and reg authorities.

It is unlikely that IPv6 wil be truly *needed* before more Food is needed, or Ammo come to think of it.

Certainly things Run Out - cos as a Species we cannot 'make do'.
We want More, and Consume all that there is available. Just like Bacteria and other Mindless species.

My bet is on Global wars over Fuel, Food or Water before IP addresses.

I'll bet you a potato. Two even.

You should really change your picture to "Dont Feed The Trolls"

There is no *need* for IPv6. It is simply a logical Upgrade to IPv4.

However, it is now Urgent for what reason ?

This is not a debate about the need or lack thereof for IPv6.

This is a discussion and request for support for certain IPv6 features.

You seem to believe you have no need for it in your own network, therefore why do you feel this discussion is even relevant to you?

For those wanting IPv6 Hotspot now, see
http://www.4ipnet.com/en/aboutus_news.p ... ases&no=47

IPv6 quadruples the number of network address bits from 32 bits in IPv4 to 128 bits, which provides more than enough globally unique IP addresses for every networked device on the planet.

Sigh.

http://www.nro.net/media/remaining-ipv4 ... low-5.html

why do you feel this discussion is even relevant to you?

Good point.

I'll stop sticking my furry nose in then.

pepperspot.sourceforge.net seems to support IPv6

pepperspot.sourceforge.net seems to support IPv6

Correct:
http://forum.mikrotik.com/viewtopic.php ... 90#p227890

Pepperspot (the IPv6 version of chillispot) also has a hotspot implementation running now.
...
the whole source code is available http://pepperspot.sourceforge.net/

sorry - i missed your post on the other topic.

i was only really looking at a coova-chill alternative cos of what you lot said, and found pepperspot.

i looked to see which hotspot solution to include in my firmware ....

Vint Cerf, vice-president of Google who is known to many as one of the ‘fathers of the Internet’, declared at a 6UK launch event held in London recently that the UK will run out of IPv4 addresses well before the end of 2011. He said “There’s no question we’re going to be out of address space by springtime of 2011 [and], with more devices than ever set to join the Internet, such as mobile devices and the ‘Internet of things’, IPv6 will be critical to the future of the Internet.”


Steve Lalonde, Chief Technical Officer
» ISPReview.co.uk: Vint Cerf Predicts UK ISP Internet Trauma When IPv4 Addresses Run Out in 2011
Internet Protocol version six (IPv6) is an Internet Protocol that was developed back in the 1990’s and is the next generation of Internet Protocol version four (IPv4). Whilst IPv4 uses a 32-bit system, IPv6 uses a 128-bit hexadecimal address that has the potential to make available 2128 individual addresses, which is roughly 340 trillion, trillion, trillion. It is thought that by the middle of next year, only 5% of unallocated IPv4 addresses will remain, at which point the Internet Assigned Numbers Authority (IANA) will distribute the remaining addresses to the five Regional Internet Registries (RIRs).

Cerf continued by sharing his beliefs that the UK has run out of time to address the problem: “it continues to boggle my mind that the UK hasn’t taken this up as an issue. People will ask why their new smart devices don’t work. All the promise and potential of these devices will fail if the ISPs don’t grasp this.”

more...
http://opinion.enta.net/2010/11/25/ipv6-do-or-die/

E-mail support, Keep asking. Make sure they know that you want v6 worked on. RIPE (Europe RIR) chews through a /8 every 3-5 months so it looks like RIPE is out sometime between June 2011 and Jan 2012

E-mail support, Keep asking. Make sure they know that you want v6 worked on. RIPE (Europe RIR) chews through a /8 every 3-5 months so it looks like RIPE is out sometime between June 2011 and Jan 2012

Its every 2-3 months for APNIC who have China and India churning through them. APNIC will run out well before end of 2011.

http://www.potaroo.net/tools/ipv4/fig09.png

APNIC have had 6 this year iirc, RIPE has had 4

And just like that overnight the IANA allocation list was updated for the allocations, 4 went out leaving us with 7 /8's left

Doesn't this solve the problem you were talking about?

netfilter: IPv6 NAT
http://lwn.net/Articles/468671/

Looks like other router vendors are supporting this feature

http://www.cisco.com/c/en/us/td/docs/io ... direct.pdf
https://www.juniper.net/techpubs/en_US/ ... write.html

As a networker and developer I dare say that IPv6 hotspot should be easy to implement.

I think hotspot feature doesn't require full NAT implementation. It's just how Mikrotik did it. It however requires destination address/port rewriting in order to be able to redirect user to authentication web page, but nothing more than that. The web page replies to original client address. After user is authenticated, then her traffic should just be routed through to Internet. If not authenticated, and if the address is not in walled garden list, she should be redirected to authentication page. Otherwise route packet. Simple as that. Protocols which are not NAT aware will not work anyway before authentication, so no problem here. The feature to map user's "artificial" address to a hotspot address (which requires 1:1 NAT) is not needed anymore.

So Mikrotik - use this simple design, no excuses anymore

I have similar request with this, but I proposed another approach which in my opinion should be doable in Mikrotik.

Since IPv6 NAT is not possible and there's already an IPv6 firewall filter, why don't you make it so it would block all IPv6 traffic in a hotspot interface, until the user log in via IPv4. Off course this make it only possible in dual stack and not IPv6 only, but this will prevent IPv6 traffic to be leaked in a dual stack hotspot configuration the way it is now, and the users have to log in via IPv4 captive portal before they can use internet.

I am with you. There is a way to implement a hotspot service in IPv6.
Yes, it is correct that there is free IPv4 pools, but we have to find a IPv6 solution quickly.

In my networks and user managers are only MT.

+1 IPv6 Hotspot support.

Feature request post:

viewtopic.php?t=184581

+1 IPv6 Hotspot support.
It is really needed!