Forum Discussion
- Benjamin_TForum Team (Retired)
Hi All,
Quoting Mark's last post - Whilst we already have enough IPv4 address space for our current network needs, as part of ongoing network upgrades, we have been looking at making our network ready for IPv6 connectivity. There are many factors which need to be worked through to ensure a seamless experience for our customers but we anticipate we will progress with initial stages of IPv6 deployment at some point during 2012.
- TonyJrUp to speedExcellent - the ball has started rolling. I still hope that we can request a prefix higher than the /64 minimum e.g. /56 or /48.
- legacy1Alessandro Volta
TonyJr wrote:
Excellent - the ball has started rolling. I still hope that we can request a prefix higher than the /64 minimum e.g. /56 or /48.Do we really want to run out of IP's again? What you going to do with 18,446,744,073,709,551,616 addresses?
A Prefix length of /120 for 256 addresses (or less) of native IPv6 is enough.
- VMCopperUserWise owl
I think they would still be able to see the mac if you dont enable privacy addressing. It's just that the way ipv6 assigments happen local resources should not be available to the wider public. I may have a misunderstanding of how some of the IPV6 system works. For example I dont understand what will dictate the local link IP range and keep it from going global (if you were to connect straight to modem). If the traffic is blocked by the layer of switch or if this is something the modem/gateway device should do. I know it will be dictated, just not sure at what level.
What I do know is that the transition from v4 to v6 will need to be done with a focus towards the non-tech users.
Nat devices have added a huge layer of security (through their firewall and lack of network discovery) that users have really been able to enjoy. It will be important for users to get a gateway device that will still act as a typical "router" but without the NAT layer in it. It is just like a group of public IPV4 addresses that's behind a firewall. Data does know where to go, but when it gets to the firewall (Router) the traffic stops unless there is a rule set up. In a way this is really sad, the world was running out of ipv4 addys and NAT was brought in as a temp solution. Now we need to re-train users to go back to software firewalls or add in hardware firewalls, permissions will become more important for some things, but redudant for others. VoIP, VPN, hosting games or web servers - all become much easier. ISP's must be afraid of it a little, imagine what might happen when the nat layer is gone and devices can be un-restricted.
In one way, this removal of the nat layer and extra routers could be a logical reason for VM getting rid of a "modem" and getting an all-in-one unit. Knowing how they normally forward plan I doubt it ever crossed their mind (but I am sure if Alex reads this he'll say he had it marked from the start).
Granted I may be wrong in assuming that if we had a stand alone modem connected to a switch, that that all devices connected to that switch would be public facing. This is how I imagine it working so if I am wrong drop me a line ;P.
- DaggerTuning in
VMCopperUser wrote:I think they would still be able to see the mac if you dont enable privacy addressing. ... For example I dont understand what will dictate the local link IP range and keep it from going global (if you were to connect straight to modem).
Ah, yeah, there is the whole "your MAC address ends up in your IP" thing -- but even there it's not the MAC address that's leaking per se, but rather the IP address (which might just happen to contain your MAC).
Routers don't route link-locals, so you can reach any machine that doesn't require going through a router.
VMCopperUser wrote:
Granted I may be wrong in assuming that if we had a stand alone modem connected to a switch, that that all devices connected to that switch would be public facing.It's possible to remove the router and hook multiple devices up to the modem via a switch, yeah. (In this case the ISP will be seeing the MACs of all your devices, which will all be connected directly to the ISP's network.) This setup is the one I called broken above, and has a number of problems.
The right way to do it is to have a single router, which is in the same position and works the same as our current NAT boxes (except it has an IPv6 netblock routed to it, unlike in the v4 case where it doesn't), but just doesn't rewrite addresses. (And then you put a stateful firewall on this router, which gives you all the security that people often think you need NAT for.) We need this router anyway if we don't want to rely on VM doing NAT for v4 for us.
... OK, I'm not quite sure what more to say to that. My previous post provided a great big demonstration of why it isn't true; if you want to continue declaring it is then it would be nice if you could explain how that viewpoint is compatible with my previous post.
legacy1 wrote:Does work like that again fact OK.
NAT changes your client MAC to the WAN IP with a MAC for doing NAT from local LAN IP's to a WAN IP thats how home routers work fact end of.
- legacy1Alessandro Volta
Dagger wrote:There is no point in thinking your right when your wrong NAT changes the MAC because VM limits us to one MAC what your saying can't happen even if it changes the IP from local to your one WAN IPv4 it will not work unless it changes the MAC. And the problem for you not understanding this is your not seeing what happens after the NAT your only seeing what happens up to the NAT.
ftp://bridgemode.bounceme.net/nat%20101.png
Edit:corrected mistakes
- VMCopperUserWise owl
Well, the MAC can transit the nat. But usually (for most uses) your correct that the router wll be the actual endpoint for the pc. Then the router will be the endpoint for the server that's on the wibble, so usually no MAC is passed over the NAT layer. I think this depends on the packet type but dont care to look up what kind of packets use the MAC in a way that it's not allowed to be changed. VPN comes to mind tho.
The joyus thing that I see is that (with firmware upgrades) a lot of low-end routers (that have ipv6 chipsets) will function as high-end ipv6 routers because there will be a lot less load once NAT is gone. Anyhow, I am not gonna get into the MAC debate, I know that "discovery" is not an option, but I do think that internal data sometimes encapsulates it on the outward journey, I'll just stop with that as I dont want to do reading to support my view ;P....
All of this discussion is a bit moot however, as our ISP doesnt support IPV6!
- DaggerTuning in
legacy1 wrote:
There is no point in thinking your right when your wrong NAT changes the MAC because VM limits us to one MAC what your saying can't happen even if it changes the IP from local to your one WAN IPv4 it will not work unless it changes the MAC.What you've missed is that the MACs are changed regardless of whether you're using NAT or not, meaning that the MAC changing isn't due to NAT. (In fact the MACs aren't really "changed" -- they're in the L2 header, and a new L2 header is generated for each hop of the packet's journey.)
Your diagram looks right, but the MACs in it would look the same even if there was no NAT taking place on the router.
(This is all only valid for a routed network, of course. If your machines are bridged or, equivalently, connected to the modem via a switch, then of course this doesn't apply.)
VMCopperUser wrote:
but I do think that internal data sometimes encapsulates it on the outward journeyI guess you can always make that claim, in the sense that I could make forum posts mentioning my MAC address and my router isn't going to change the MAC inside the forum post text. Likewise, VPNs might encapsulate an entire L2 packet inside an L3 one. These cases are not really interesting and only serve to confuse matters.
VMCopperUser wrote:
But usually (for most uses) your correct that the router wll be the actual endpoint for the pc. Then the router will be the endpoint for the server that's on the wibble, so usually no MAC is passed over the NAT layer.Assuming that the wibble is the internet at large, then this isn't quite how it works either. For instance, take this traceroute:
1. 1 ms 184.105.213.66 MACs: c8:7b:59:ce:0c:48 (facing 2)
2. 3 ms 198.32.176.31 MACs: 12:80:4d:3e:6d:dd (facing 1), aa:e1:a5:c3:99:7d (facing 3)
3. 1 ms 216.239.49.250 MACs: cc:63:ef:f8:c5:ad (facing 2), c1:53:ce:1b:b8:0c (facing 4)
4. 2 ms 64.233.174.119 MACs: f7:dc:17:31:78:a4 (facing 3), 16:c4:91:54:3f:17 (facing 5)
5. 1 ms 74.125.224.132 MACs: 67:e7:c6:93:07:5e (facing 4)(I've invented some MAC addresses for each network card involved.)
The IP packet is generated on 184.105.213.66 with source and destination IPs "184.105.213.66 > 74.125.224.132". It's then stuck inside an ethernet frame which is sent from c8:7b:59:ce:0c:48 to 12:80:4d:3e:6d:dd. When 198.32.176.31 receives the ethernet frame, it extracts the IP packet (which is still "from 184.105.213.66 to 74.125.224.132"), figures out where to send it, and then puts it inside a new ethernet frame, which is sent from aa:e1:a5:c3:99:7d to cc:63:ef:f8:c5:ad. This is repeated at each hop, until eventually an ethernet frame is sent from 16:c4:91:54:3f:17 to 67:e7:c6:93:07:5e containing the original IP packet.
In each case, the IP packet is passed through unscathed -- but the IP packet doesn't have any MAC addresses in it. This IP packet is passed between each hop using ethernet frames, and it's the ethernet frames that have MACs as their source and destinations. However, the ethernet frames can't be sent through routers -- that doesn't even make sense, because a router is a concept at the L3 (IP) layer, and ethernet is at L2.
What are the "endpoints" here? At L3, they're 184.105.213.66 and 74.125.224.132. But at L2, where MACs are used as the source and destination addresses of packets, there's four separate pairs of endpoints (c8:7b:59:ce:0c:48 & 12:80:4d:3e:6d:dd, aa:e1:a5:c3:99:7d & cc:63:ef:f8:c5:ad, etc), one for each of the four ethernet networks joining the five hops in the traceroute.
Introducing NAT doesn't affect the picture much. It rewrites the addresses inside the IP packet, but it doesn't affect the ethernet frames in any way. (Nitpicker's corner: of course if you rewrite the destination IP to somewhere else, and the packet ends up taking a different path to get there, then the ethernet frames will be affected. That's not important.) The apparent IP endpoints will change, for instance one end will see a source IP of 192.168.1.2 and the other will see a source IP of 198.32.176.31. Both will see a destination IP of 74.125.224.132. This doesn't actually affect the MACs used for each hop at all.
(I appreciate that this probably isn't the clearest explanation in existence; sorry about that. I hope it gets across the point that the concept of MACs going "through" routers doesn't make any sense.)
VMCopperUser wrote:
The joyus thing that I see is that (with firmware upgrades) a lot of low-end routers (that have ipv6 chipsets) will function as high-end ipv6 routers because there will be a lot less load once NAT is gone.It's not really a load issue, but a config issue; half the embedded routers out there are running Linux and support IPv6 perfectly fine, they just don't have any way to configure it. These routers are also stuck doing NAT anyway since we still need v4 access.
Unfortunately "firmware upgrades" usually means "time to buy a new router"... this is one actual advantage of the SuperHub: it's possible for VM to make the firmware upgrade, and they're able to foist it on everyone too.
- legacy1Alessandro Volta
Dagger wrote:
legacy1 wrote:
There is no point in thinking your right when your wrong NAT changes the MAC because VM limits us to one MAC what your saying can't happen even if it changes the IP from local to your one WAN IPv4 it will not work unless it changes the MAC.What you've missed is that the MACs are changed regardless of whether you're using NAT or not, meaning that the MAC changing isn't due to NAT. (In fact the MACs aren't really "changed" -- they're in the L2 header, and a new L2 header is generated for each hop of the packet's journey.)
Your diagram looks right, but the MACs in it would look the same even if there was no NAT taking place on the router.
(This is all only valid for a routed network, of course. If your machines are bridged or, equivalently, connected to the modem via a switch, then of course this doesn't apply.)
MAC is changed at the router from LAN to WAN on any router you get right now in order to sent/receive packets thats how its got to be thats how NAT works.
- TonyJrUp to speedWith regard to MAC addresses and Privacy addresses - and how to configure your OS to use them, the following page has detailed information. http://superuser.com/questions/243669/how-to-avoid-exposing-my-mac-address-when-using-ipv6
Tony - francisandrosieDialled in
Sorry to bring this up but im gonna hate all this IPv6 as all my lifes been IPv4 lol
When virgin media do go to IPv6 then there should be a choice if they wonna go IPv6, Google will still have an IPv4 option not all the worlds gonna go IPv6
And whats gonna happen when IPv6 get full? They gonna bring out IPv9 :D then all of use jumping from IPv4 to IPv6 then to IPv9 :)
Just saying....
- legacy1Alessandro VoltaWe are going to have both one IPv4 and some IPv6 its not going to be one or the other.
This will be the idea in the long run the world moves to both IPv4 and IPv6 then web sites free up IPv4 to only be IPv6 which is fine because the world moved to both IPv4 and IPv6 at this point.
Things that need IPv4 will still be around and for the longest part we will still have one IPv4 until its no longer needed by anything. - horsemanAlessandro Volta
francisandrosie wrote:.....
And whats gonna happen when IPv6 get full? ......
Be a while before that happens?:
- Martin_DKnows their stuffAny Update to when Virgin plan to implement IPv6 on its network?
- Dagger2Superfast
craigj2k11 wrote:Was in a meeting with a cisco rep last month who said that Cisco cannot see IPv6 being deployed any time soon. It just isnt needed
That seems like a somewhat head-in-the-sand position to take, considering that it is needed and is being deployed. It's also not the position that Cisco's own website takes.
legacy1 wrote:If we was to get a /32 and used 20 address out of it the rest are unused and not need (unless you add more devices) now the rest that are not in use out of /32 could any traffic like DDOS affect the users speed and data usage?
I covered that above. Adding extra details doesn't change anything. If you send data to a VM customer, then the data will go to the VM customer. Obviously that traffic is going to go over their internet connection and contribute towards their caps. None of that is new to IPv6 -- it works the same way in IPv4 -- so I'm not sure why you're bringing it up as an IPv6 problem.
craigj2k11 wrote:NAT isnt used in IPv6 so there is no security in that sense
If you want security, use a firewall. Firewalls still work in IPv6, and give you any security you got as a side-effect of NAT.
Nutty667 wrote:I'm not sure why you'd want every internet capable device exposed directly to the internet. Having everything behind a NAT makes things much safer from a security point of view. Its not that much work setting up port forwarding anyway.
No, it doesn't. Having them behind a firewall gives that. Nobody is forcing you to run without a firewall, we just want to make it possible to do so, and at the same time fix all of the addressability issues that arise from rewriting src/dst addresses.
And port forwarding is a bigger pain than you realize. How do you set up port forwarding for two DNS servers behind the same NAT?
- legacy1Alessandro Volta
Still not getting the piont I'm making....how does DHCP-PD IPv6 work again by one MAC to the gateway so one IPv4 and many IPv6 address yes?
When VM allocates you a IPv4 address its to that MAC along with a allocation of many IPv6 addresses. If you use 20 address out of IPv6 the rest are not used as of yet now if incoming traffic even with no reply to a not in use IPv6 address this will still route to you and will eat into ones speed and usage should it be a DDOS yes?
Their is a difference to a DDOS being aimed to a IPv6 address your using then a IPv6 address that’s allocated to you but not in use and still receives incoming traffic even with no reply from the gateway.In IPv4 terms think of it like this VM have a gateway with many IPv4 addresses not all (for the time being) are in use so when incoming wants to send to an IP not in use it does not have to send it it can drop it but of course if a IPv4 is in use then you have to send it to that IP regardless. Like I said there is a difference the question is how will IPv6 work to not send traffic to your allocation of a address you are not using in the same way as a IPv4 WAN IP in use to a IPv4 WAN IP not in use.
- craigj2k11Rising star
legacy1 wrote:
When VM allocates you a IPv4 address its to that MAC along with a allocation of many IPv6 addresses. If you use 20 address out of IPv6 the rest are not used as of yet now if incoming traffic even with no reply to a not in use IPv6 address this will still route to you and will eat into ones speed and usage should it be a DDOS yes?thats news to me
- craigj2k11Rising star
Dagger2 wrote:No, it doesn't. Having them behind a firewall gives that. Nobody is forcing you to run without a firewall, we just want to make it possible to do so, and at the same time fix all of the addressability issues that arise from rewriting src/dst addresses.
And port forwarding is a bigger pain than you realize. How do you set up port forwarding for two DNS servers behind the same NAT?
Under IPv4 you would be using a firewall and network address translation
And why would you have 2 DNS servers on the same IP?
- VMCopperUserWise owl
Multiple IP's can be difficult to cope with. In essence, I have two IP4s and then the IPv6 block, but routing tables is where it can get tricky... I do it so I can watch American TV, but I would love to make it so typing in www.hulu.com would let the family watch hulu, while typing in iplayer.bbc.co.uk lets people go view iplayer. Due to the way IP detction works these days (and so many domain names are resolved) it becomes a headache to try and edit routing tables and dns entrys.
IPv6 will be a headache I think... But that's one great reason to switch now.
When 1% of the net is IPv6 only then the users who will have complaints is small... When 40% of traffic is priority for IPv6 then nearly every user can suffer. Deal with it now I say, while techies want it, and hopefully you'll have it all fixed by the time it is mainstream.
- Dagger2Superfast
Its seems everyone has forgotten how do networking because of NATI read your entire post, legacy1, and this is the only line that made sense.
IPv6 on DOCSIS cable networks is a solved problem. IPv6 on Ethernet and Wifi is a solved problem. All VM need to do is implement.
Also, dual stack (by itself) doesn't produce complicated routing setups. It's actually incredibly simple to roll out dual stack on your home network. (Source: my home network, where it was indeed simple.)
- legacy1Alessandro VoltaSay hello to the new ARP for IPv6.
http://keepingitclassless.net/2011/10/neighbor-solicitation-ipv6s-replacement-for-arp/
- MorgaineSuperfast
VMCopperUser wrote:
>
> IPv6 will be a headache I think... But that's one great reason to switch now. [my highlighting]
I suspect that you used the word "switch" loosely, and didn't really mean that. To avoid any misconceptions though, it had better be pointed out that IPv6 is added alongside IPv4 to run dual-stack (the best method), so access to both IPv4 and IPv6 are available simultaneously. Switching off of IPv4 is not being discussed, and is not relevant here. Likewise, "switching from IPv4 to IPv6" is not being discussed, nor relevant here.
It has to be this way, both running together, because IPv4 and IPv6 will coexist for decades as traffic slowly migrates to IPv6. The transition cannot be done by sudden switchover as the Internet is too vast and contains too much legacy equipment which will remain on IPv4 until it dies and is replaced.
So, avoid referring to "switching over" to IPv6, because that's not what this is about and it conveys the wrong message. IPv6 just needs to be "enabled", nothing more. IPv4 isn't affected.
Morgaine.
- VMCopperUserWise owl
Morgaine wrote:VMCopperUser wrote:
>
> IPv6 will be a headache I think... But that's one great reason to switch now. [my highlighting]
I suspect that you used the word "switch" loosely, and didn't really mean that. To avoid any ..*snip*..
So, avoid referring to "switching over" to IPv6, because that's not what this is about and it conveys the wrong message. IPv6 just needs to be "enabled", nothing more. IPv4 isn't affected.
Morgaine.
Switch On...Vs, Switched Off...
Switch to Dual-Stack vs Single-Stack...
When Ipv6 is enabled, it should be the primary connection method, Ipv6 SHOULD take priority over Ipv4 once enabled.
- VMCopperUserWise owl
I am not saying IPv4 is embeded in IPv6.
Just saying that at the OS level, If your pc looks up say Microsoft.com and it has two records (one for 6 and one for 4) that v6 should take priority.
So to me, IPv6 SHOULD take priority over IPv4, I dont find that statement confusing to myself, but others seem to read into it, so perhaps It is not clear :/...
Older versions of AppleOS gave priority to IPv4.
I am gonna go play some games on http://loopsofzen.co.uk/ while I ponder this thread ;P....
- legacy1Alessandro Volta
VMCopperUser wrote:Just saying that at the OS level, If your pc looks up say Microsoft.com and it has two records (one for 6 and one for 4) that v6 should take priority.
So to me, IPv6 SHOULD take priority over IPv4, I dont find that statement confusing to myself, but others seem to read into it, so perhaps It is not clear :/...
But thats DNS which has nothing to do with the IP layer.
- VMCopperUserWise owl
True..
But IPv4 and IPv6 are nothing more than endpoints, without DNS then those endpoints would be virtually useless to the masses. Other than QoS no packet should ever have priority over another, and only transition mechanisms should ever alter endpoints/transit data.
So I can see where you have an objection with me saying the IPv6 should take priority.
Strictly speaking, they are both different so neither should have priority.
But when I visit a website, I expect it to happen over IPv6 first if it can, and then try IPv4 if that fails. (are you happy with that statement?) :P...
- legacy1Alessandro Volta
VMCopperUser wrote:But when I visit a website, I expect it to happen over IPv6 first if it can, and then try IPv4 if that fails.
Doesn’t work too well if you don't have native IPv6 and it really shouldn’t work for 6to4 which is why it should only try if the device has a native IPv6 for it to connect out to IPv6.
- Dagger2Superfast
tl;dr OSs should follow the default RFC 3484 policy table for sorting DNS responses, which fortunately they all do. This is another non-problem, move along please.
(The default table is, roughly, IPv6 > IPv4 > 6to4 for native dual stack clients, and IPv4 > IPv6 > 6to4 for single-stack v4-only clients. Programs are supposed to retry going down the list if there's a connection failure.)
- legacy1Alessandro Volta
VMCopperUser wrote:So I can see where you have an objection with me saying the IPv6 should take priority.
Strictly speaking, they are both different so neither should have priority.
But when I visit a website, I expect it to happen over IPv6 first if it can, and then try IPv4 if that fails. (are you happy with that statement?) :P...
Thinking about this more... even that don't work to well if you connect to a DNS server by IPv4 you can get IPv4 and IPv6 addresses but if you don't have IPv6 then its goning to fail so the only way DNS with IPv4 and IPv6 can work well is if you have IPv6 and you connect to a IPv6 DNS server so that IPv6 is first to try and then tries IPv4 since you can connect to DNS by IPv6 and get IPv4 and IPv6 addresses. If you only connect to a DNS server by IPv4 then I think it should only give you IPv4.
- MorgaineSuperfast
Both IPv4 and IPv6 nameservers can return IPv6 records, there is no distinction. Here's an example of it in action:
$ dig @8.8.8.8 google.com aaaa | grep -i aaaa
; <<>> DiG 9.8.0 <<>> @8.8.8.8 google.com aaaa
;google.com. IN AAAA
google.com. 300 IN AAAA 2a00:1450:4009:804::1000Here I've requested Google's IPv6 AAAA record from their public IPv4 nameserver on 8.8.8.8, and it is returned as expected.
The general idea is that every website offering service on IPv6 should provide its IPv6 DNS records through nameservers on both IPv4 and IPv6, and the choice of which to use is made by the user's browser. That choice doesn't depend only on whether the user's machine is on IPv6, but also on whether the user's machine currently has IPv6 connectivity to the destination host and whether the destination host's webserver is currently answering on IPv6.
This gives you two bites at the cherry, since despite normally offering service on both, the webserver may be currently up on one network but down on the other because of problems or for maintenance. In addition to this automatic selection, you can install a Firefox add-on that allows you to enable or disable the IPv6 attempt manually in case you find a reason to do so. Other browsers probably offer something similar.
Morgaine.
- VMCopperUserWise owl
I dont want 6to4, I want dual stack...
I would do "for now" with 6to4/4to6 from VM IF it was provided in key spots on the core network, to keep latency down.
Related Content
- 28 days ago
- 3 months ago
- 4 months ago