...the IPv6/Authentication/NAT/Routing discussion...

Status
Not open for further replies.
This again raises doubts in my mind as to how exactly the CPE obtains the public IPv6 address since you mentioned PPPoE as part of a possible authentication mechanishm...

Does the CPE directly send a DHCPv6 request over the "Internet" vlan interface?
If this is the case, then in bridged mode a gateway PC can directly obtain an IPv6 address on the external NIC, which is ideal. But where will the username & password be sent from and by what protocol?

OR

Does it make a PPPoE IPv6 connection over the "Internet" vlan interface?
PPP itself implies that an IP address HAS to be assigned at the client side PPP endpoint (the CPE). I don't believe that the CPE can establish a PPP link just for authentication (or for whatever other reason PPP is required) and then NOT obtain an IP address, and then simply bridge the data port and act as a DHCPv6 relay so that a gateway PC can obtain the public IP. From what I can tell PPP doesn't work like that and the IP address must be assigned to wherever the PPP connection was made. Thus in bridged mode, the entire PPP connection would have to be made from the gateway PC.

I think you're getting even more confused now - there is more than one way to make the connection.

The default is to simply set up all the authentication in the CPE, it'll get an IPv6 address, and have it perform NAT to devices on your network.

The alternative is to bridge the connection so that the NIC on your gateway machine gets the IPv6 address as you request.

HOWEVER

IN THIS MODE (BRIDGING) if you plug multiple devices in to the CPE, they will each need their own username and password to connect because we are not allowed to allow the same username/password to authenticate more than once.

This is irrespective of whether 802.1x or PPPoE is used.

How will these multiple usernames & passwords be provided to the ISP to obtain additional IPv6 address unless PPP is used? If PPP is not used then I presume multiple DHCPv6 requests will be sent over the "Internet" vlan interface, and each must originate from a different MAC address. This again brings up the question of how the corresponding username/password will be sent...


This would only work if each of your machines was plugged directly in to the CPE, but assuming for a moment that 802.1x authentication is used, then yes.

DynDNS does support IPv6. If the updater client is from an IPv6 network then presumably the AAAA record will be updated to the public IPv6 address. But what about the A record??

For now ignore DNS altogether, how will I do something as simple as connecting via Telnet to my public IP? If I am outside on an IPv4 network, which will definitely be the case for the next decade, how can I Telnet to my IP?

Software tunnel. This might be of interest: gogo6 | IPv6 products, community and services - IPv6 Telnet clients are available, I think Windows' telnet client supports IPv6 natively.

---------- Post added at 02:57 AM ---------- Previous post was at 02:26 AM ----------

^^^ any photographs of the new CPE's by alcatel...and what abt set top boxes if u want to provide IPTV

I only have some really shoddy images at the moment (GIF... who the hell uses GIF anymore?)

I think I gave the model numbers in the hardware thread, but they are:
I-120W-P (2 port with Wifi)
I-240W-P (4 port with Wifi)
I-120G-P (2 port without Wifi)
I-240G-P (4 port without Wifi)

I think this seems to resemble the device I've been sent an image of:
Basic specs:
GPON I-series ONT, version P, 2 POTS and GigE Ethernet interfaces. Includes ac/dc power cord with European (EU) variant plug.
 
I think you're getting even more confused now - there is more than one way to make the connection.
I'm not confused. You're not stating what exactly you are going to use... unless that is not decided yet.

The default is to simply set up all the authentication in the CPE, it'll get an IPv6 address, and have it perform NAT to devices on your network. The alternative is to bridge the connection so that the NIC on your gateway machine gets the IPv6 address as you request. IN THIS MODE (BRIDGING) if you plug multiple devices in to the CPE, they will each need their own username and password to connect because we are not allowed to allow the same username/password to authenticate more than once. This is irrespective of whether 802.1x or PPPoE is used.
All this is fine, provided you use an authentication mechanism that both the CPE and a PC can support so that either bridged mode or NAT mode can be used with minimal configuration changes, and with no changes required from the ISP side.

Considering the multi-factored authentication that you mentioned earlier the only possibility that comes to mind is to use MAC binding and IP binding on the CPE's external Fiber NIC. This would be purely on the the outer layer outside the vlans. Then a PC & CPE compatible username/password authentication mechanism should be used on the "Internet" vlan interface. What are the possibilities here? I'm having a hard time thinking of anything other than PPPoE, 802.1x or some kind of VPN-esque system. What are the other "inner" authentication methods that would allow a DHCP assigned IP address directly on the PC's physical NIC?

Software tunnel.
I'll PM you about this. Then basically, shouldn't you have your installation engineers setup IPv6 tunneling on ALL the user's NATed PCs? That way there will be no problem in connecting to other Hayai users (Torrent peers & other servers etc.). And shouldn't you run your own tunnel broker so that if the destination address is also in the Hayai Zone, then only Hayai Zone bandwidth is used, instead of going to an external tunnel broken and back?

---------- Post added at 11:49 AM ---------- Previous post was at 10:41 AM ----------

I have another concern. If I use bridged mode, how will traffic destined for IPv4 addresses leave my network? Does it automatically go to your CGN for NAT64 via the IPv6 default gateway assigned to me? Is the IPv6 default gateway itself the NAT64 server? Or will I need to manually configure the gateway PC to somehow forward IPv4 packets to your CGN? What does the CPE do normally?

Ah... I see this has been formally addressed and is called "Dual-Stack Lite". The CPE must be a DS-Lite client. Unless my gateway PC can do DS-Lite, I won't be able to access the IPv4 internet. Looks like I might be forced to use the CPE in NAT mode and DMZ to my gateway PC's local IPv4 address.
 
I'm not confused. You're not stating what exactly you are going to use... unless that is not decided yet.

It's a little bit of both - there are some details which I can only touch on - as some of the questions are also slightly beyond even my depth (my technical knowledge in this area is limited to what I already know or am told; this is why I hire experts and a CTO who knows far more than I do). I'll try to answer as best I can otherwise I may have to get back to you if I'm wrong about anything, which is entirely likely.

All this is fine, provided you use an authentication mechanism that both the CPE and a PC can support so that either bridged mode or NAT mode can be used with minimal configuration changes, and with no changes required from the ISP side.

802.1x with username/password authentication should fit that bill quite nicely then.

Considering the multi-factored authentication that you mentioned earlier the only possibility that comes to mind is to use MAC binding and IP binding on the CPE's external Fiber NIC. This would be purely on the the outer layer outside the vlans. Then a PC & CPE compatible username/password authentication mechanism should be used on the "Internet" vlan interface. What are the possibilities here? I'm having a hard time thinking of anything other than PPPoE, 802.1x or some kind of VPN-esque system. What are the other "inner" authentication methods that would allow a DHCP assigned IP address directly on the PC's physical NIC?


MAC binding is less than satisfactory as a solution unless it's combined with some other form of authentication too. In Finland I used to plug my device in to the network, turn it on and it would automatically download the firmware from the ISP which would be auto-configured for my address - the ISP knew the MAC ID of my CPE and my address, so I'm guessing that all they had to do was plug in the correct numbers and send that to the OLT. Based on my looking through the Web Access Manager of the OLTs we're using, I think we will be able to have the same thing.

What would happen is, when I turned it on, the CPE would be available as a LAN device for about 30 seconds, then it would disappear as my NIC would be assigned a public IP. I'm guessing there was some kind of network booting ROM involved but I never really thought to find out how it worked at the time, but it was completely 100% zero configuration on my part, and I don't seem to recall there being any MAC binding to the computer I was using - my girlfriend and I could exchange cables from one laptop to the next or plug both in to a simple switch. My recollection is that the ISP would provide up to 5 public IP addresses per subscriber, as I did later encounter this limitation on a misconfigured public facility.

CPEs generally support far more VLANs than there are ports - a run-of-the-mill consumer device normally supports 8 VLANs, even if it has just 4 ports - or even 1 port. If a separate VLAN is created for each device that connects to the CPE then that works perfectly for authentication BUT does not allow the PCs to communicate with each other without first going out to the Hayai Zone which creates unnecessary bandwidth utilization, HOWEVER, this would work perfectly well for a public WiFi point.

In your case, you're best off having your existing configuration, a single PC which uses the CPE as a bridge, authenticates with 802.1x and receives an IP address to it's external NIC - all the NAT will be done by your gateway (I assume it's running with a modern version of Windows or Linux so it should work automatically). Otherwise, in most people's cases it is easier for them to just plug their PCs in to the CPE (or use the wireless function if it's available) and let the CPE get the IP address and perform the NAT.

I'll PM you about this. Then basically, shouldn't you have your installation engineers setup IPv6 tunneling on ALL the user's NATed PCs? That way there will be no problem in connecting to other Hayai users (Torrent peers & other servers etc.). And shouldn't you run your own tunnel broker so that if the destination address is also in the Hayai Zone, then only Hayai Zone bandwidth is used, instead of going to an external tunnel broken and back?

IPv6 to IPv4 is easy. The other way around, not so much. You would only need to set up a tunnel if the PC is on an IPv4 network and you wanted to access your machine which would be on an IPv6 network. Yes we could (would) run our own tunnel broker for this purpose. Torrent peers within the Hayai Zone and such could see each other natively, there should be no tunneling required at all. The CPE should do all the work of converting from an address like 2001:::::FE1D:6C3B:BD9E:7EBB to 10.1.1.10 or whatever the client's computer has taken as an IP (assuming the user continues to run his LAN on IPv4).

I have another concern. If I use bridged mode, how will traffic destined for IPv4 addresses leave my network? Does it automatically go to your CGN for NAT64 via the IPv6 default gateway assigned to me? Is the IPv6 default gateway itself the NAT64 server?

1. It works the same as if we had a transparent proxy. In fact that's basically what it would be. The NAT server would be different to your default gateway, but it would be on the same network, as these are only needed at points where our network meets the rest of the Internet (the same as our billing servers), whereas the default gateway will most likely be the machine that is responsible for controlling connections in your area.

If a website can be accessed via IPv6 then it will NOT go through any of the NAT servers, but if it is on an IPv4-only network, then only it will have to go through the NAT64 or equivalent server.

Or will I need to manually configure the gateway PC to somehow forward IPv4 packets to your CGN? What does the CPE do normally?

You shouldn't need to manually configure anything. IPv4 packets are easy to forward through IPv6 - some networks also can do addressing like 2001::::::123:234:210:123 or 2001::::::7BEA: D27B - or something along those lines.

Ah... I see this has been formally addressed and is called "Dual-Stack Lite". The CPE must be a DS-Lite client. Unless my gateway PC can do DS-Lite, I won't be able to access the IPv4 internet. Looks like I might be forced to use the CPE in NAT mode and DMZ to my gateway PC's local IPv4 address.

We have gateway servers of our own take care of any necessary IPv6 to IPv4 traversal for going out to the IPv4-only internet. A little bit less efficient than running a dual-stack network however most of the larger sites are at least on IPv6 networks now anyway.

It's only the other way around that it's a pain in the ass and would require the aforementioned software tunnel.
 
Torrent peers within the Hayai Zone and such could see each other natively, there should be no tunneling required at all. The CPE should do all the work of converting from an address like 2001:::::FE1D:6C3B:BD9E:7EBB to 10.1.1.10 or whatever the client's computer has taken as an IP (assuming the user continues to run his LAN on IPv4).
Only if the tracker is IPv6. If it's not then it will record your NAT64 gateway's public IPv4 address, but the same incoming torrent port that is used on the CPE's public IPv6 interface will not be forwarded to that user from the NAT64's public IPv4 interface (unless there is some UPnP propagation magic).

1. It works the same as if we had a transparent proxy. In fact that's basically what it would be. The NAT server would be different to your default gateway, but it would be on the same network, as these are only needed at points where our network meets the rest of the Internet (the same as our billing servers), whereas the default gateway will most likely be the machine that is responsible for controlling connections in your area.
After reading some more, I believe this is incorrect. Dual-Stack Lite is not Dual-Stack. In DS-Lite, the CPE only has a public IPv6 address. The CPE receives a special routing table from the ISP that indicates an alternate gateway (the IPv6 address of the NAT64 gateway) to be used for IPv4 network destinations. This requires a special DS-Lite network driver (supported in newer Linux kernels) on the CPE in order to work.

There is no question of using only IPv6 on the LAN. The LAN PCs must have IPv4 addresses, and use the CPE's IPv4 local address as the default gateway. When a LAN PC tries to communicate to a remote IPv4 host, the DS-Lite driver on the CPE intercepts this, packs it into IPv6 packets, and forwards it to the NAT64 gateway, through it's IPv6 public interface.

If bridged mode is used and a PC is directly assigned an IPv6 public address, then it would not even be able to ping an IPv4 address. It would just result in a general failure in the local network stack. It would not even try to contact the default IPv6 gateway. Any gateway PC which is bridged must have a DS-Lite compatible network driver, and be provided with the additional routing table entries to forward IPv4 packets, and any other PCs which are NATed to it must have IPv4 addresses.

You could optionally have secondary local IPv6 addresses for the LAN PCs, but that's pointless given the sizes of people's home networks, and the fact that they must also use IPv4 addressing anyway. Not to mention all the networking logic in peoples' brains fail the instant they see an IPv6 address. I am still unable to figure out what is an appropriate IPv6 address range to use in place of 10.0.0.0/8 or 192.168.0.0/16.

You shouldn't need to manually configure anything. IPv4 packets are easy to forward through IPv6 - some networks also can do addressing like 2001::::::123:234:210:123 or 2001::::::7BEA: D27B - or something along those lines.
Special routing table for IPv4 pointing to NAT64 gateway and compatible network drivers are required for any PC that is bridged, in order to access IPv4. There is close to zero support for this outside of ISP grade hardware routers/CPEs. The is also no standard for the packaging format. Every ISP hardware vendor impements a proprietary format, but the principle is the same i.e. giving only a public IPv6 address to the CPE with shared NAT64 servers. This makes it very difficult to run your own box as a gateway, or to even use a router with custom firmware like DD-WRT.

Think about it, if simple bridging is done so a PC gets an IPv6 address, then simply pinging an IPv4 remote host will cause a general failure. There will be no entries in the routing table for any IPv4 traffic other than 127.0.0.1.

However overall I fell this is a needed step forward which will force everyone's hand.
 
Only if the tracker is IPv6. If it's not then it will record your CGN's public IPv4 address, but the same incoming torrent port that is used on the CPE's public IPv6 interface will not be forwarded to that user from the CGN's public IPv4 address (unless there is some UPnP propagation magic).

I suspect there is some voodoo involved, as I have no issues connecting to IPv6 peers from an IPv4 network (see the image in your PM). I am not using any special tunnels or configurations, and I am not on a dual-stacked network - it just works.

After reading some more, I believe this is incorrect. Dual-Stack Lite is not Dual-Stack. In DS-Lite, the CPE only has a public IPv6 address. The CPE receives a special routing table from the ISP that indicates an alternate gateway (the NAT64 gateway which has an IPv6 address) to be used for IPv4 network destinations. This requires a special DS-Lite network driver (supported in newer Linux kernels) on the CPE in order to work.

That would be a question for Alcatel, but routing to IPv4 networks from our network should be transparent and require zero configuration on your part. The solutions to these problems do not have to be as elegant as you seem to think, but as I've mentioned, routing from an IPv6 network to an IPv4 network is easy by comparison to doing the same in the opposite direction. I do not personally know exactly how it will work, however I'm trying to make a simile (acting like a proxy) for the purpose of keeping an explanation simple.

There is no question of using only IPv6 on the LAN. The LAN PCs must have IPv4 addresses, and use the CPE's IPv4 local address as the default gateway.

Why MUST the LAN PC's have IPv4 addresses? As far as I'm concerned, it's up to the user how his LAN is configured - it's not our job to maintain the user's LAN.

If I felt so inclined I could turn off IPv4 on my network, but for the ISP I'm on and with the equipment I'm using, that would be pointless. If I was using different equipment and was on my ISP's IPv6 trial, then I would have turned IPv4 off already.

When a LAN PC tries to communicate to a remote IPv4 host, the DS-Lite driver on the CPE intercepts this, packs it into IPv6 packets, and forwards it to the NAT64 gateway, through it's IPv6 public interface.


Yes, so which part of this suggests that the NAT64 gateway is not acting like a proxy?

If bridged mode is used an a PC is directly assigned an IPv6 public address, then it would not even be able to ping an IPv4 address. It would just result in a general failure in the local network stack. It would not even try to contact the default IPv6 gateway. Any gateway PC which is bridged must have a DS-Lite compatible network driver, and be provided with the additional routing table entries to forward IPv4 packets, and any other PCs which are NATed to it must have IPv4 addresses.

Not true. IPv6 specifications state that IPv6 hosts must be able to read IPv4.

My impression is that basically, to reach an address on an IPv4 network, then it's up to our equipment to route the request properly - IPv6 NAT,IPv4,AAISP,UKNOF,bbc.co.uk | trefor.net

It may be such that in this example. BBC.co.uk does have an IPv6 address as well, and I expect by now at least it does, but the point here is still that when routing from an exclusively IPv6 network to an IPv4 network, the main requirement was that this ISP had a NAT server at their network's border.

You could optionally have secondary local IPv6 addresses for the LAN PCs, but that's pointless given the sizes of people's home networks, and the fact that they must also use IPv4 addressing anyway. Not to mention all the networking logic in peoples' brains fail the instant they see an IPv6 address.

Special routing table for IPv4 pointing to NAT64 gateway and compatible network drivers are required for any PC that is bridged, in order to access IPv4. There is close to zero support for this outside of ISP grade hardware routers/CPEs. The is also no standard for the packaging format. Every ISP hardware vendor impements a proprietary format, but the principle is the same i.e. giving only a public IPv6 address to the CPE with shared NAT64 servers. This makes it very difficult to run your own box as a gateway, or to even use a router with custom firmware like DD-WRT.

Again, this would be a question I will have to pose to Alcatel next time I speak with them, but my understanding would be that a request to an IPv4 address (made with the IPv6 stack in the form of ::1.2.3.4) would be passed on to the NAT server, so considering that in bridging mode the information passed on to you via DHCP would be from an ISP-grade router, then support should not be an issue.
 
Again, this would be a question I will have to pose to Alcatel next time I speak with them, but my understanding would be that a request to an IPv4 address (made with the IPv6 stack in the form of ::1.2.3.4) would be passed on to the NAT server
It's unclear at which stage the IPv4 requests must be routed to the NAT64 server: By the CPE/Gateway PC's routing table, or at the ISP side default gateway (in which case it's truly transparent and bridging will work perfectly).

In the example you posted it looks like the CPE is simply routing IPv6 stack IPv4 requests to the ISP default gateway, and the default gateway (or something after that) is taking care of rerouting to the NAT64 server.

But in all the other examples I've found online, it's done by the CPE using various implementations of DS-Lite. The CPE's network driver must be capable of communicating with the NAT64 server and packaging & forwarding IPv4 requests to it. However all these examples assume IPv4 LAN clients. I wonder if in your setup IPv6 stack initiated IPv4 requests can be directly rerouted by the ISP default gateway itself without the CPE getting involved.

so considering that in bridging mode the information passed on to you via DHCP would be from an ISP-grade router, then support should not be an issue.
Only the special network driver can understand and use this information to package pure IPv4 requests. Hopefully this won't be required at all for IPv6 stack IPv4 requests.

Why MUST the LAN PC's have IPv4 addresses? As far as I'm concerned, it's up to the user how his LAN is configured - it's not our job to maintain the user's LAN.
They won't if the CPE/Gateway/ISP default gateway reroute IPv6 stack IPv4 requests.

Yes, so which part of this suggests that the NAT64 gateway is not acting like a proxy?
Its more like an additional hop to a different router.

However there will unavoidably be IPv4 only clients like game consoles, so even if the IPv6 stack IPv4 request rerouting is done at the ISP default gateway, the LAN gateway must also have transparent packaging ability. Hopefully this packaging will be something as simple as repackaging pure IPv4 into IPv6 embedded IPv4 and everything would simply be handled by the ISP side default gateway as usual.
 

It's unclear at which stage the IPv4 requests must be routed to the NAT64 server: By the CPE/Gateway PC's routing table, or at the ISP side default gateway (in which case it's truly transparent and bridging will work perfectly).


I expect that it would be the latter, otherwise we would have to be running a dual-stack network.

In the example you posted it looks like the CPE is simply routing IPv6 stack IPv4 requests to the ISP default gateway, and the default gateway (or something after that) is taking care of rerouting to the NAT64 server.


Yes, and?

But in all the other examples I've found online, it's done by the CPE using various implementations of DS-Lite. The CPE's network driver must be capable of communicating with the NAT64 server and packaging & forwarding IPv4 requests to it. However all these examples assume IPv4 LAN clients. I wonder if in your setup IPv6 stack initiated IPv4 requests can be directly rerouted by the ISP default gateway itself without the CPE getting involved.


Given that I didn't package the software for the CPE it's not really a question I can answer with 100% accuracy, but if I understand the question, then yes, I expect so.

Only the special network driver can understand and use this information to package pure IPv4 requests. Hopefully this won't be required at all for IPv6 stack IPv4 requests.


As mentioned, IPv6 is designed to also be able to handle IPv4 requests. It was an early specification.

They won't if the CPE/Gateway/ISP default gateway reroute IPv6 stack IPv4 requests.


That's exactly what I've been trying to convey - in a standard network, NAT will be enabled. Even in your network, your gateway server is performing NAT of some description.

Its more like an additional hop to a different router.


Of course. Even if it were only proxying an IPv4 connection it would still introduce another hop. But the NAT server is still acting like a proxy when it turns the traffic over to an IPv4 network.

However there will unavoidably be IPv4 only clients like game consoles, so even if the IPv6 stack IPv4 request rerouting is done at the ISP default gateway, the LAN gateway must also have transparent packaging ability. Hopefully this packaging will be something as simple as repackaging pure IPv4 into IPv6 embedded IPv4 and everything would simply be handled by the ISP side default gateway as usual.

Yes, so that would be the CPE's job with it's NAT function and all. You could have the CPE (or in your case, your gateway server) distribute both IPv4 and IPv6 addresses if you wanted to, however the subscribers network isn't our concern.
 
I expect that it would be the latter, otherwise we would have to be running a dual-stack network.
Given that I didn't package the software for the CPE it's not really a question I can answer with 100% accuracy, but if I understand the question, then yes, I expect so.
The two are mutually exclusive. You could implement either. Both don't need a dual-stack network.

As mentioned, IPv6 is designed to also be able to handle IPv4 requests. It was an early specification.
If the rerouting is done by the LAN gateway, an ordinary gateway may be able to understand incoming IPv4 requests, but only the DS-Lite driver can make it forward those packets to the NAT64 gateway. Without the driver it would simply send everything to the IPv6 default gateway, as embedded IPv4 packets. The NAT64 gateway is still reached via an IPv6 address, so the service is still single stack IPv6.

It's just the question of which. I'm asking becase Google shows that CPE side rerouting is much more prevalent.
 
Good work in separating this thread. Don't know who to thank - Torch or MGC.
Only one small issue remains; while the main heading reflects the new thread title, the individual posts still show the old Hayai Broadband FAQs title. Wonder if that can be changed too. I'm sure even if there is no simple way, Sushubh will have access to modify the html or database to make the necessary correction.
 
Good work in separating this thread. Don't know who to thank - Torch or MGC.
Only one small issue remains; while the main heading reflects the new thread title, the individual posts still show the old Hayai Broadband FAQs title. Wonder if that can be changed too. I'm sure even if there is no simple way, Sushubh will have access to modify the html or database to make the necessary correction.

I did it as requested by yourself, CST1992 and others.

I think it would be technically innaccurate and unnecessary to change the title - some of the posts do actually reference other posts which are still in the FAQ's thread.
 
Status
Not open for further replies.

Back