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

[KurianOfBorg]

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.

 

[mgcarley]

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.

 

[KurianOfBorg]

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.

 

[Daddycool]

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.

 

[mgcarley]

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.

 

[Suraj4u]

Hey can anyone answer this: Difference between Ipv6 local & Ipv6 limited.

I asked this question yesterday, but no response, so once again i ask. Which is better??

 

---

[mhsabir]

Ah.. I Think that might be too much effort - we already have a lot of such merged threads - where headings vary based on the original thread 😕

 

[KurianOfBorg]

It's actually the other way around. The thread takes the title of the first post. For normal users, the first post's title will propagate to the thread title for 30 minutes after the thread is created.

 

[mgcarley]

Hey can anyone answer this: Difference between Ipv6 local & Ipv6 limited.

I asked this question yesterday, but no response, so once again i ask. Which is better??

If memory serves, limited usually means it's trying but failing to establish IPv6 connectivity, local usually means that on your own network you can use IPv6 but not to other networks (such as the Internet).

 

[Suraj4u]

Oh ok, this is what i get here in INDIA Ipv6 limited.But when i went abroad i got Ipv6 local.Thanx mg

 

[mgcarley]

Oh ok, this is what i get here in INDIA Ipv6 limited.
But when i went abroad i got Ipv6 local.

Thanx mg

It may be that your CPE/modem abroad supports IPv6 and your CPE/modem in India does not. No biggie.

 

[devx101]

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.

So one of the GE ports can also work for iptv if u launch the services at a later time.
By the way what technology are u planning to use to transport the channels from broadcaster to your node(satellite or some nationwide fiber transport).

Any discussions with vendors on STB's.....

 

[mgcarley]

So one of the GE ports can also work for iptv if u launch the services at a later time.

Correct.

By the way what technology are u planning to use to transport the channels from broadcaster to your node(satellite or some nationwide fiber transport).

What else other than Fiber?

Any discussions with vendors on STB's.....

Yes, but no specific details at the moment.

 

[devx101]

What else other than Fiber?


well some operators use HITS as well at city level offices.

 

[mgcarley]

well some operators use HITS as well at city level offices.

Since it's just another part of the data stream, that would be unnecessary. We should be able to rebroadcast on a state or metro level in most cases (allowing for local advertising on certain channels, in particular FTA channels).