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

Status
Not open for further replies.
K

KurianOfBorg

Messages
258
Location
NA
Most of these things might be fine, providing it's personal use and you're not making malware of pirated material publically available (safe havens, indemnification and all that) - it might be something where we will have to review in your case.

I assume this refers mainly to HTTP/FTP. The web server requires authentication globally (only on the external NIC, not LAN since Windows Update is cached and served from here to 5 or 6 home PCs to prevent multiple downloads of the same updates. More on this later.) so the public will only see a login prompt.

TS Gateway I understand - I used to run such a thing myself although I've moved away from that now to Teamviewer so that it's less complicated.

I'm pretty satisfied with TS Gateway as it allows me to directly connect to any PC in my LAN from a public location with the intranet FQDN of the PC. E.g. cerebro.intranet.earth-616.com, where earth-616.com points to my public IP with DynDNS and my home PCs are all in *.intranet.earth-616.com.

Allowing other users to tunnel from another ISP for the purpose of using your connection as a proxy is probably not allowed

This would make me legally liable too, thus SSH/VPN access would be only for myself. Any access granted to others would probably be only for a subfolder or something via HTTP and for a very short duration as and when required.

From your end it shouldn't matter how you connect - the CPE handles all the connections, there's no bridging or dialing up from your PC involved, so using a combination of PPPoE and 802.1x won't affect any port bindings, especially since (I presume) you'll be running some kind of DynDNS client and all you'll have to do is forward the ports in the router.

I'll explain in detail why I want a public IP address directly on my NIC. I don't think our broken conversation on Twitter made anything sufficiently understandable.

I don't intend to use a CPE; only a media converter or a fiber NIC if I can find an affordable one. NAT is unsuitable for me as there are three heavy downloaders at home and the line will choke and latencies will spike.

I bought a cheap dedicated box as a router/download rig which I leave on 24x7. I run all my servers on it including intranet DNS, DHCP, VPN etc. and also use it as the internet gateway for the entire LAN.

I don't use NAT for the LAN PCs; there is no default gateway defined on them. There's only the firewall client installed on each PC that apparently hooks the network stack & transparently routes all connections through the gateway and internet access is granted based on the client's current Windows username/password by automatically authenticating with the gateway (someone technically sound might abhor this draconian method but at home no one will know the difference...so). Thus QoS, maximum simultaneous connections and any other restrictions are applied on a per-user basis and will carry over to any PC in the house where the user logs in. Everything is configured on the gateway.

From what I can tell this is not insecure like a captive portal and cannot be bypassed by any means. All traffic between firewall clients and the gateway also happens to be encrypted so there can be no sniffing of internet destined traffic.

I've got two vlans: vlan1 & vlan2 (yes they are isolated and not simply a different subnet). The gateway has an NIC on each vlan. Most wired PCs and all WiFi access points are in vlan2. vlan2 has no NAT access. Windows PCs in vlan2 must use the firewall client for internet access. My WiFi uses 802.1x so instead of a WPA key users must enter their Windows username/password which is authenticated against the RADIUS server on the gateway. Once connected to the WiFi, they are put in vlan2 and must use the firewall client and have a valid internet-enabled Windows username/password to gain internet access.

Linux PCs/mobile phones etc. which can't run the firewall client must first connect to vlan2 (physically wired/WiFi), and then PPP or VPN into the gateway. VPN requires logging in with a valid Windows username/password and the gateway recognizes them as that user and their same internet access policy applies as if they had used the firewall client directly from vlan2. Due to the nature of VPNs, no spoofing/sniffing can be done and the internet access policy cannot be bypassed.

vlan1 has NAT access (through another NIC on the same gateway box). Other devices like the PSP, PS3 etc. which can only connect via NAT must be physically plugged into vlan1 switch ports or connect to a non-broadcasting WPA protected access point that is plugged into vlan1 who's existence is known only to me.

Correct addresses for each vlan are assigned via the same DHCP server depending on the incoming NIC. The gateway also does LAN routing beween the two vlans and an appropriate static route for the two subnets is distributed along with the DHCP response.

The ADSL modem is plugged into vlan1 (to prevent vlan2 users messing with it) and is only configured as an EoA bridge to expose the ISP side ethernet to the local network. The gateway then connects via PPPoE since it can now see the PPP server on the ISP. Ideally I think I should be using a separate NIC on the gateway to connect the modem since now the ISP can potentially access vlan1, but I don't really care about my PS3 traffic and since vlan1 is physically under my control no one is going to secretly dial a PPPoE connection to the ISP either and bypass the firewall.

The reason I need a public IP directly on my NIC is I want some servers and services to bind only to the public IP. This is not possible with PPPoE since it doesn't quality as an NIC. For example I need the web server to require NTLM authentication on the public interface, but not on the lan interface. If you had 802.1x authentication, I would directly enter my Hayai username/password in the network adapter properties and it would authenticate against the same RADIUS servers that you use for PPPoE. There would be no dialing or other nonsense. The internet would register as a proper network, as it SHOULD. It's also so much easier to release/renew IP with a script and automate the process in jDownloader for link-removed etc. I pay for DynDNS pro and for Custom DNS servers so I would also be able to instantly update my A records using TSIG instead of having that stupid 10 minute delay of the official client because PPPoE disconnections can't be monitored properly.

AFAIK you will already need to provide this kind of connection method to corporate clients, either allowing them to authenticate via 802.1x or by using some kind of intermediate device running wpa_supplicant that automatically performs authentication and then bridges the pre-authenticated network to their switch. I presume any mid-range linux based CPE will have wpa_supplicant. Why do you want an additional tunnel inside your ethernet connection anyway? It's not like it's ATM and you need to tunnel EoA. When the WAN port on the CPE is ethernet, I take it the preferred method of authentication must be one from the ethernet protocol suite.

You must think I'm insane to have this setup at home 😀
After administering the above, would you go back to a NAT CPE?
 
I assume this refers mainly to HTTP/FTP. The web server requires authentication globally (only on the external NIC, not LAN since Windows Update is cached and served from here to 5 or 6 home PCs to prevent multiple downloads of the same updates. More on this later.) so the public will only see a login prompt.


Fair enough.

I'm pretty satisfied with TS Gateway as it allows me to directly connect to any PC in my LAN from a public location with the intranet FQDN of the PC. E.g. cerebro.intranet.earth-616.com, where earth-616.com points to my public IP with DynDNS and my home PCs are all in *.intranet.earth-616.com.

I still find TeamViewer easier these days - I can log in with my username and password on any machine and any client I've saved the details of will "just work".

This would make me legally liable too, thus SSH/VPN access would be only for myself. Any access granted to others would probably be only for a subfolder or something via HTTP and for a very short duration as and when required.

You may have to sign an indemnity form for the SSH/VPN stuff, but other than that.

I don't intend to use a CPE; only a media converter or a fiber NIC if I can find an affordable one.

It would be nice if it were so simple, but the nature of FTTH is that it's not as straightforward as copper, where you can plug in almost any new device to the network - it has to be a compatible device - if it doesn't play nicely with the OLT, you're just not even going to see a connection. Then there's also the inbuilt encryption to take in to consideration.

A straight-up media convertor is unlikely to work - partially because a PON network isn't like an Ethernet network - most media convertors are Ethernet extenders and not much more, and have relatively short operating distances... basically the best comparison I can think of here would be using a standard GigE switch and plugging it in to your ADSL connection.

NAT is unsuitable for me as there are three heavy downloaders at home and the line will choke and latencies will spike.

Because downloads will totally take ages? You're only talking a couple minutes per GB here, max.

I bought a cheap dedicated box as a router/download rig which I leave on 24x7. I run all my servers on it including intranet DNS, DHCP, VPN etc. and also use it as the internet gateway for the entire LAN.

I don't use NAT for the LAN PCs; there is no default gateway defined on them. There's only the firewall client installed on each PC that apparently hooks the network stack & transparently routes all connections through the gateway and internet access is granted based on the client's current Windows username/password by automatically authenticating with the gateway (someone technically sound might abhor this draconian method but at home no one will know the difference...so). Thus QoS and any other restrictions are applied on a per-user basis and will carry over to any PC in the house where the user logs in. Everything is configured on the gateway.

From what I can tell this is not insecure like a captive portal and cannot be bypassed by any means. All traffic between firewall clients and the gateway also happens to be encrypted so there can be no sniffing of internet destined traffic.

I've got two vlans: vlan1 & vlan2 (yes they are isolated and not simply a different subnet). The gateway has an NIC on each vlan. Most wired PCs and all WiFi access points are in vlan2. vlan2 has no NAT access. Windows PCs in vlan2 must use the firewall client for internet access. My WiFi uses 802.1x so instead of a WPA key users must enter their Windows username/password which is authenticated against the RADIUS server on the gateway. Once connected to the WiFi, they are put in vlan2 and must use the firewall client and have a valid internet-enabled Windows username/password to gain internet access.

Linux PCs/mobile phones etc. which can't run the firewall client must first connect to vlan2 (physically wired/WiFi), and then PPP or VPN into the gateway. VPN requires logging in with a valid Windows username/password and the gateway recognizes them as that user and their same internet access policy applies. Due to the nature of VPNs, no spoofing/sniffing can be done and the internet access policy cannot be bypassed.

vlan1 has NAT access (through another NIC on the same gateway box). Other devices like the PSP, PS3 etc. which can only connect via NAT must be physically plugged into vlan1 switch ports or connect to a non-broadcasting WPA protected access point that is plugged into vlan1 who's existence is only known to me.

Correct addresses for each vlan are assigned via the same DHCP server depending on the incoming NIC. The gateway also does LAN routing beween the two vlans and an appropriate static route for the two subnets is distributed along with the DHCP response.

The ADSL modem is plugged into vlan1 (to prevent vlan2 users messing with it) and is only configured as an EoA bridge to expose the ISP side ethernet to the local network. The gateway then connects via PPPoE since it can now see the PPP server on the ISP. Ideally I think I should be using a separate NIC on the gateway to connect the modem since now the ISP can potentially access vlan1, but I don't really care about my PS3 traffic and since vlan1 is physically under my control no one is going to secretly dial a PPPoE connection to the ISP either and bypass the firewall.

The reason I need a public IP directly on my NIC is I want some servers and services to bind only to the public IP. This is not possible with PPPoE since it doesn't quality as an NIC. For example I need the web server to require NTLM authentication on the public interface, but not on the lan interface. If you had 802.1x authentication, I would directly enter my Hayai username/password in the network adapter properties and it would authenticate against the same RADIUS servers that you use for PPPoE. There would be no dialing or other nonsense. The internet would register as a proper network, as it SHOULD. It's also so much easier to release/renew IP with a script and automate the process in jDownloader for link-removed etc.

I'm relatively sure that your configuration should continue to work as it is - all you should need to do is swap out the ADSL connection for the Fiber connection - it's probable that our CPE can be used to create a bridged connection for your dedicated router PC, and in that case I think that the only thing that will change for you is that you'll move from an ADSL modem to an FTTH one. Naturally, that's a best guess - there might be some other configuratory tweaks required maybe but otherwise I think it should basically work.
 
I pay for DynDNS pro and for Custom DNS servers so I would also be able to instantly update my A records using TSIG instead of having that stupid 10 minute delay of the official client because PPPoE disconnections can't be monitored properly.

AFAIK you will already need to provide this kind of connection method to corporate clients, either allowing them to authenticate via 802.1x or by using some kind of intermediate device running wpa_supplicant that automatically performs authentication and then bridges the pre-authenticated network to their switch.

Corporate clients get a completely different setup, but they also pay a lot more. If you're willing to pay for the equipment I'd be happy to give it to you.

I presume any mid-range linux based CPE will have wpa_supplicant. Why do you want an additional tunnel inside your ethernet connection anyway? It's not like it's ATM and you need to tunnel EoA. When the WAN port on the CPE is ethernet, I take it the preferred method of authentication must be one from the ethernet protocol suite.

GPON networks are more closely related to DSL than Ethernet.

You must think I'm insane to have this setup at home 😀
After administering the above, would you go back to a NAT CPE?

I had such elaborate setups years ago, but now I move around too much, and mobility is more important to me than having copious amounts of gear. I keep my living spaces quite... zen.

CPE doesn't have to equal NAT, but there's also our VLANs to take in to account as well - this won't work with a bridged connection.
 
You may have to sign an indemnity form for the SSH/VPN stuff, but other than that.
There are going to be a LOT of people who have these things running either without their knowledge or without telling you, unless you block the default ports by default, which I now presume is what you will be doing.

I'm relatively sure that your configuration should continue to work as it is - all you should need to do is swap out the ADSL connection for the Fiber connection - it's probable that our CPE can be used to create a bridged connection for your dedicated router PC, and in that case I think that the only thing that will change for you is that you'll move from an ADSL modem to an FTTH one. Naturally, that's a best guess - there might be some other configuratory tweaks required maybe but otherwise I think it should basically work.
Yes I'm sure it will work as is without modification if bridging or PPPoE relay is enabled (bridging and PPPoE relay are different but for the above case they are functionally the same; see below). But I'd like it to be more advanced than that.

It would be nice if it were so simple, but the nature of FTTH is that it's not as straightforward as copper, where you can plug in almost any new device to the network - it has to be a compatible device - if it doesn't play nicely with the OLT, you're just not even going to see a connection. Then there's also the inbuilt encryption to take in to consideration.

Yes, I just read about it. Fiber NICs/media converters are only for SOHO fiber LANs. However, when using a compatible CPE the network interface that the CPE's OS sees, and what your routers/DHCP servers see will still be ethernet. The PON stuff will be abstracted at the link layer, presenting only ethernet to the higher layers.

That means the CPE can still technically be an "Ethernet over PON" bridge, but now that you've mentioned vlans on your side, it looks like I will NOT be able to get a public IP via DHCP over ethernet without PPP. This would make the 802.1x auth pointless, or unsuable in this case.

At the very least I must have a public IP directly on the gateway atleast via PPPoE relaying, or it will break everything. Atleast now the gateway is sensible enough to identify "External" as everything except Internal (which is identified by giving it a list of the local subnets). If it had to NAT to the CPE even that wouldn't work.
 
Yes I'm sure it will work as is without modification if bridging or PPPoE relay is enabled (bridging and PPPoE relay are different but for the above case they are functionally the same; see below). But I'd like it to be more advanced than that.

So which type of authentication do you think you need?

Yes, I just read about it. Fiber NICs/media converters are only for SOHO fiber LANs. However, when using a compatible CPE the network interface that the CPE's OS sees, and what your routers/DHCP servers see will still be ethernet. The PON stuff will be abstracted at the link layer, presenting only ethernet to the higher layers.

That means the CPE can still technically be an "Ethernet over PON" bridge, but now that you've mentioned vlans on your side, it looks like I will NOT be able to get a public IP via DHCP over ethernet without PPP. This would make the 802.1x auth pointless, or unsuable in this case.

VLANs are a side-effect of having a triple-play service, in your case unfortunately, but this is done on a per-port basis by the CPE, so whatever is plugged in to the data ports shouldn't notice how the connection to the internet is made - it's literally plug in and play, and your machine(s) should simply see that it (they) can connect to the internet.

At the very least I must have a public IP directly on the gateway atleast via PPPoE relaying, or it will break everything. Atleast now the gateway is sensible enough to identify "External" as everything except Internal (which is identified by giving it a list of the local subnets). If it had to NAT to the CPE even that wouldn't work.

That doesn't sound right to me... the gateway should be identifying internal/external by which card it's sending traffic to, that is eth0 or eth1, not because of it's IP address.

Perhaps all you need is DCHP relaying, not necessarily PPPoE relaying. If DCHP relay can be enabled your public interface could receive a public IP and all of this becomes completely moot.

You'll also need to make sure your system is happy with not receiving an IPv4 address, because we're not delegating any. At all.
 
So which type of authentication do you think you need?
The current configuration is considerably different from what you implied a few months ago about being able to use a media converter etc. so I honestly don't know what can & can't be done anymore. Since you said regulations require everyone to authenticate, 802.1x was a suggestion assuming it would be possible to plug an ethernet cable into my gateway PC and get a public IPv4 address on the interface without any sort of dialer, while on your side reusing the same RADIUS server & user database as PPP clients instead of doing something like MAC binding to the CPE/gateway PC's NIC.

Since that's not possible, forget whatever I've said so far and lets start from scratch.

VLANs are a side-effect of having a triple-play service, in your case unfortunately, but this is done on a per-port basis by the CPE, so whatever is plugged in to the data ports shouldn't notice how the connection to the internet is made - it's literally plug in and play, and your machine(s) should simply see that it (they) can connect to the internet.
For a normal customer, what exactly happens here? I assume the CPE will internally have several virtual interfaces assigned to each vlan after the PON layer is abstracted. Then on the "Internet" vlan interface it will proceed to dial a PPPoE connection with username/password and once connected a ppp0 interface will come up with a public IPv4 address. The interface attached to the output data port/switch will then be NATed to ppp0. So as far as internet is concerned, it would work exactly like any existing Ethernet ADSL modem-router.

Assume the CPE is being used in all cases, configured appropriately.

Worst case: The above will be the only way to use it.

Equivalent to what I have now:
PPPoE relay or Half-Bridged mode:
If this is enabled then a PPPoE relay server will run on the CPE's interface attached to the output data port. The gateway PC can dial a PPP connection and PPP packets will be forwarded by the CPE to the "Internet" vlan interface and a PPP connection will be established with a public IPv4 address on a new ppp0 interface on the gateway PC, NOT on the physical NIC's interface (which need not even have a LAN IP address since PPPoE is established via MAC addresses at the Ethernet layer). It has the added security of not allowing other non-PPP traffic between the "Internet" vlan and the gateway PC.

That doesn't sound right to me... the gateway should be identifying internal/external by which card it's sending traffic to, that is eth0 or eth1, not because of it's IP address.
That only works for physical NICs and if the gateway PC is connected via NAT. I'd have to buy a THIRD NIC and dedicate it to be NATed to the CPE, which seems like a waste, and I don't want the CPE to handle the load of 3 people's uncontrolled P2P connections.

On Windows Server a PPP connection is NOT considered a standard network interface. You cannot select it in any interface selection screen. It doesn't even have a fixed name like ppp0 on Linux. Selecting the physical NIC over which PPP was dialed also doesn't work as it will only consider the address of the physical NIC. The PPP connection simply becomes the default gateway with the lowest metric and thus all traffic with no other route goes there. Such traffic gets classified as "External" in ISA/TMG. So when binding listeners to External, they happen to get bound only to the PPP IP address. Additionally I cannot tell other servers to bind exclusively to the public IP since no other software has an "External" interface and only lists the physical NICs (like requiring SSL & authentication only on the public interface). I have to do nasty loopback connections to alternate ports.

Bridged Mode (But ISP only accepts PPP connectivity):
The "Internet" vlan interface will be bridged to the CPE's data port and the gateway PC will hence dial PPPoE directly to your PPP server and the rest works like the previous case.

Ideal:
Bridged Mode:
Perhaps all you need is DCHP relaying, not necessarily PPPoE relaying. If DCHP relay can be enabled your public interface could receive a public IP and all of this becomes completely moot.
I presume this would require full bridging between the "Internet" vlan interface and the CPE's data port so that all IP packets from the gateway PC's NIC (which would now directly have a public IPv4 address via DHCP) can be routed to the default gateway speficied in the DHCP response.

How would authentication be done here? I presume you'd MAC bind to the CPE's fiber port or something.

Unless there is some other magic where some kind of partial PPP tunnel (authentication performed here) is setup on the CPE and then the DHCP relay forwards DHCP requests from the gateway PC to your DHCP server (which is actually meant for PPP clients). Similar to VTun.

Though I think the former is most likely the case.

You'll also need to make sure your system is happy with not receiving an IPv4 address, because we're not delegating any. At all.
I don't understand. I'd only want one DHCP assigned IPv4 address for the external NIC on the gateway PC, like everyone has right now. No other systems would be connected to the data port switch so there is no chance of it being accidently assigned elsewhere.

Though if you can have some kind of paid addon plan like Comcast (yes for residential) where in addition to one dynamic IP, a second static IP can also be provided (only for the same physical location due to regulations which you mentioned earlier), that would be awesome.
 

The current configuration is considerably different from what you implied a few months ago about being able to use a media converter etc. so I honestly don't know what can & can't be done anymore.

Previously it was going to be the case that it might have worked, but the architecture of the network had to change.

Since you said regulations require everyone to authenticate, 802.1x was a suggestion assuming it would be possible to plug an ethernet cable into my gateway PC and get a public IPv4 address on the interface without any sort of dialer, while on your side reusing the same RADIUS server & user database as PPP clients instead of doing something like MAC binding to the CPE/gateway PC's NIC.

I understand - we don't want anybody to have to use a dialer, that's why the CPE is to take care of everything. I think it would be possible to provide a public IPv6 address to your gateway PC, but we're not doing IPv4 at all. Not even buying more than a couple of /23s.

For a normal customer, what exactly happens here? I assume the CPE will internally have several virtual interfaces assigned to each vlan after the PON layer is abstracted. Then on the "Internet" vlan interface it will proceed to dial a PPPoE connection with username/password and once connected a ppp0 interface will come up with a public IPv4 address. The interface attached to the output data port/switch will then be NATed to ppp0. So as far as internet is concerned, it would work exactly like any existing Ethernet ADSL modem-router.

Firstly, IPv6. IPv6. IPv6.

Secondly, Yes and no. There was an authentication mechanism I've come across in Ukraine and Finland which seemed to work relatively well - it consists of PPPoE combined a static IP assignment and MAC authentication to an approved device which is managed remotely - change 1 of those 3 things (IP address, different device or the username & password) and the connection stops working.

On our device, the connection stuff and all the important bits would be managed by us, but the CPE will still have some user configurable settings - I have a Linksys VOIP device which has 2 lines - one is managed by the ISP for my VOIP service and is hidden when I log in to the device, the other one is available for user use - I've configured it with my own phone number.

Assume the CPE is being used in all cases, configured appropriately.

Worst case: The above will be the only way to use it.

Equivalent to what I have now:
PPPoE relay or Half-Bridged mode:
If this is enabled then a PPPoE relay server will run on the CPE's interface attached to the output data port. The gateway PC can dial a PPP connection and PPP packets will be forwarded by the CPE to the "Internet" vlan interface and a PPP connection will be established with a public IPv4 address on a new ppp0 interface on the gateway PC, NOT on the physical NIC's interface (which need not even have a LAN IP address since PPPoE is established via MAC addresses at the Ethernet layer). It has the added security of not allowing other non-PPP traffic between the "Internet" vlan and the gateway PC.

That only works for physical NICs and if the gateway PC is connected via NAT. I'd have to buy a THIRD NIC and dedicate it to be NATed to the CPE, which seems like a waste, and I don't want the CPE to handle the load of 3 people's uncontrolled P2P connections.

IPv6. IPv6. IPv6.

Your way doesn't suit most users - most users have an ADSL modem and switch and/or wireless router or a device which combines these 3 functions. You are putting the switch behind a gateway PC for whatever reason - that's not important.

You shouldn't need a third NIC at all. All you should need to do is replace existing DSL modem with our CPE.

Dialling up a broadband connection via the PC is a bad idea, especially on Windows server. If you're going to see performance degradation anywhere, it'll be there. The connection should be always on and the CPE should be the device to do that job, no matter the authentication mechanism. If our CPE can assign your NIC a public IP address and be little more than a dummy device handing out packets, then you will have no issues with your current setup.

On Windows Server a PPP connection is NOT considered a standard network interface. You cannot select it in any interface selection screen. It doesn't even have a fixed name like ppp0 on Linux. Selecting the physical NIC over which PPP was dialed also doesn't work as it will only consider the address of the physical NIC. The PPP connection simply becomes the default gateway with the lowest metric and thus all traffic with no other route goes there. Such traffic gets classified as "External" in ISA/TMG. So when binding listeners to External, they happen to get bound only to the PPP IP address. Additionally I cannot tell other servers to bind exclusively to the public IP since no other software has an "External" interface and only lists the physical NICs (like requiring SSL & authentication only on the public interface). I have to do nasty loopback connections to alternate ports.

Bridged Mode (But ISP only accepts PPP connectivity):
The "Internet" vlan interface will be bridged to the CPE's data port and the gateway PC will hence dial PPPoE directly to your PPP server and the rest works like the previous case.


Again, there will ne no dialing up from the users PC. I will double check with engineers at Welho in Finland how they do it, but I know that plugging in to one of their devices gives a public IP address. As it does with HOASNet (by Sonera). If we take the same approach and assign an IPv6 addresses to any device connected to the ethernet port on the CPE then all you will need to do is plug in the ethernet cable to your external ethernet card and you can reasonably expect your existing setup to work as it does already.

Ideal:
Bridged Mode:

I presume this would require full bridging between the "Internet" vlan interface and the CPE's data port so that all IP packets from the gateway PC's NIC (which would now directly have a public IPv4 address via DHCP) can be routed to the default gateway speficied in the DHCP response.

How would authentication be done here? I presume you'd MAC bind to the CPE's fiber port or something.

Unless there is some other magic where some kind of partial PPP tunnel (authentication performed here) is setup on the CPE and then the DHCP relay forwards DHCP requests from the gateway PC to your DHCP server (which is actually meant for PPP clients). Similar to VTun.

Though I think the former is most likely the case.


If I understand you correctly, this is kind of what I've been talking about.

I don't understand. I'd only want one DHCP assigned IPv4 address for the external NIC on the gateway PC, like everyone has right now. No other systems would be connected to the data port switch so there is no chance of it being accidently assigned elsewhere.

We're not doing IPv4 at all. I'm buying only IPv6 addresses, and a couple of /23s of v4 addresses for internal use and NAT translation and all that stuff (for the parts of the web that are not IPv6 compliant.

The problem doesn't lie with devices on your network potentially "stealing" your public IP address(es), but more the possibility of MAC/IP spoofing happening. It's a long-shot (considering it's fiber, not copper), but still something I have to think about.
 
Oh I had no idea you were doing only IPv6 and thanks to IPv6 every device connected to the CPE's data switch will get an IPv6 public address via DHCP. So there is absolutely no NAT at all on the customer's side (if all their devices are IPv6 capable). If they have IPv4 only devices such as some mobile phones, then I presume the CPE will internally allocate one IPv6 address to itself and NAT it to a local IPv4 address with local DHCP for those devices. Hopefully, IPv6 capable devices will prefer the IPv6 DHCP server on the ISP side by default. Everything correct?

If so, this changes everything. Simply plugging my gateway PC into a stock configuration CPE would automatically make my network work as I've described in "Ideal" with a public IP on the physical NIC. I needn't even remotely care about authentication or anything at all. There won't even be a reason to open the CPE's configuration interface. I'd practically have a GigE socket directly attached to the Internet, with which I can do whatever I please. This seems technically better than even....practically every existing corporate connection in the country.

You should have specifically mentioned this before. This should be an important point in the FAQ as it would answer a LOT of questions from technically inclined customers.

Can you specifically confirm the following:

1) For the average user all their (modern) PCs will only get public IPv6 addresses.

2) Users will get potentially unlimited IPv6 addresses for every one of their devices.

3) Port Forwarding is a thing of the past for the IPv6 devices.

4) For IPv4 only devices, the CPE would perform NAT with a public IPv6 address. Or since IPv6 address are plentiful, it could simply DMZ a separate IPv6 address for every IPv4 device.

5) For the average user:
(a) What will be the subnet mask of IPv6 address allocated to each PC. Will they even be in a subnet or just individual host addresses?

(b) If they're not in a subnet won't this break existing home networks if people connect everything to the CPE since Windows won't put them in the same Workgroup or allow them to use SMB? LAN PCs will not even be able to broadcast to each other. I assume that to resolve this, IPv6 devices should also obtain IPv4 address from the CPE's DHCP server that it uses for the IPv4 NAT clients and those addresses would be in a local subnet, but the IPv6 default gateway will have a lower metric for internet access on IPv6 devices.

6) What will my DynDNS A record be when the device running the updater client is IPv6? One of your ISP side NATed IPv4 addresses? In this case how would I receive incoming connections from a remote IPv4 address if it's NATed? Will I have to specifically request you to forward ports to me from your end? I'll probably want all the ports for the services I mentioned earlier...

I assume the AAAA record will naturally be the IPv6 public address of the updater client. What exactly happens when I try to connect to my host name from an external IPv4 network?
 
Oh I had no idea you were doing only IPv6 and thanks to IPv6 every device connected to the CPE's data switch will get an IPv6 public address via DHCP. So there is absolutely no NAT at all on the customer's side (if all their devices are IPv6 capable). If they have IPv4 only devices such as some mobile phones, then I presume the CPE will internally allocate one IPv6 address to itself and NAT it to a local IPv4 address with local DHCP for those devices. Hopefully, IPv6 capable devices will prefer the IPv6 DHCP server on the ISP side by default. Everything correct?

If so, this changes everything. Simply plugging my gateway PC into a stock configuration CPE would automatically make my network work as I've described in "Ideal" with a public IP on the physical NIC. I needn't even remotely care about authentication or anything at all. There won't even be a reason to open the CPE's configuration interface. I'd practically have a GigE socket directly attached to the Internet, with which I can do whatever I please. This seems technically better than even....practically every existing corporate connection in the country.


Yes and no. Because it's plug and play and marginally more secure, NAT is the default option, so the CPE would provide IPv4 addresses to devices within the customer's network - a public IPv6 address is assigned to the CPE, and private IPv4 addresses (such as 10.1.1.x) are assigned to the devices on the network - but it's up to the user what they want by default.

Bridging as you have described would be an option, BUT, just like any existing bridged connection, you can only authenticate one machine at a time, as we are not allowed to have multiple machines authenticate with the same username/password. We are, however, allowed to assign multiple usernames and passwords to a single account, which would be an additional option.

You should have specifically mentioned this before. This should be an important point in the FAQ as it would answer a LOT of questions from technically inclined customers.

Can you specifically confirm the following:

1) For the average user all their (modern) PCs will only get public IPv6 addresses.

I think I may have confused you (and myself in the process) - it's either 1 PC with a bridged connection OR multiple PCs with NAT, unless we assign your account multiple usernames/passwords.

2) Users will get potentially unlimited IPv6 addresses for every one of their devices.


No. If you choose to bridge your connection, effectively you will render the other port(s) on the CPE useless as we can only authenticate one device at a time. To get individual IPv6 addresses for each device on the network we need to assign your account multiple usernames/passwords. Otherwise, IP addressing within the subscriber's LAN is up to the individual and none of our business.

3) Port Forwarding is a thing of the past for the IPv6 devices.

If the user has NAT, port-forwarding will be needed.

If the user opts for a bridged connection, then it won't be needed.

4) For IPv4 only devices, the CPE would perform NAT with a public IPv6 address. Or since IPv6 address are plentiful, it could simply DMZ a separate IPv6 address for every IPv4 device.


Yes for part 1, no for part 2.

5) (a) What will be the subnet mask of IPv6 address allocated to each PC. Will they even be in a subnet or just individual host addresses?


That depends on the pool from which the IP address is assigned.

(b) If they're not in a subnet won't this break existing home networks if people connect everything to the CPE since Windows won't put them in the same Workgroup or allow them to use SMB? LAN PCs will not even be able to broadcast to each other. I assume that to resolve this, IPv6 devices should also obtain IPv4 address from the CPE's DHCP server that it uses for the IPv4 NAT clients and those addresses would be in a local subnet, but the IPv6 default gateway will have a lower metric for internet access on IPv6 devices.


Chances are that most people will continue to use IPv4 within their LAN. Only those with a gateway machine (such as yourself) should opt for a bridged connection. You are more the exception than the rule.

6) What will my DynDNS A record be when the device running the updater client is IPv6? One of your ISP side NATed IPv4 addresses? In this case how would I receive incoming connections from a remote IPv4 address if it's NATed?

I assume the AAAA record will naturally by my devices IPv6 public address. What exactly happens when I try to connect to my host name from an outside IPv4 network?

That's a DynDNS issue - our small pool of IPv4 addresses would be so that users could access the non-IPv6 compliant parts of the Internet. If you opt for a bridged connection, then assuming that DynDNS supports IPv6, I think it'll work basically the same way as it does now, and it would be up to your gateway server to decide how it should direct any given request, whether HTTP, RDP, SSH or otherwise.

For the record, Alcatel are offering us 4 different types of CPE for residential and SME users - 2 without WiFi, 2 with WiFi. 2 have 2 ports, 2 have 4 ports.

[*]Most residential users will get either 2 port non-Wifi or 2 port WiFi.
[*]Most SMEs will get 4 port non-WiFi or 4-port WiFi as they require.
[*]2 port devices (assuming residential) can be either 1 data + 1 IPTV (default) or 2 data.
[*]4 port devices (assuming SME) can be either 4 data (default) or 3 data + 1 IPTV.
[*]All CPEs have 2 VOIP ports - 1 is reserved for Hayai's VOIP service, other can be used with any generic SIP account.
[/list]
 
I think I may have confused you (and myself in the process) - it's either 1 PC with a bridged connection OR multiple PCs with NAT, unless we assign your account multiple usernames/passwords.

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.

To get individual IPv6 addresses for each device on the network we need to assign your account multiple usernames/passwords.
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...

That's a DynDNS issue - our small pool of IPv4 addresses would be so that users could access the non-IPv6 compliant parts of the Internet. If you opt for a bridged connection, then assuming that DynDNS supports IPv6, I think it'll work basically the same way as it does now, and it would be up to your gateway server to decide how it should direct any given request, whether HTTP, RDP, SSH or otherwise.

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?
 
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.
 
Status
Not open for further replies.

Top