cancel
Showing results for 
Search instead for 
Did you mean: 

IPv6 support on Virgin media

dgcarter
Dialled in

Does anyone know whether (and if so when) Virgin plan to implement IPv6 on its network?

1,493 REPLIES 1,493

That's what I was attempting to get at: yes, that should be possible.

"Should" because the SuperHub is locked down and out of our control, and I'm sure VM can find some way to break it... but in lieu of that.

legacy1
Alessandro Volta

@Dagger wrote:

That's what I was attempting to get at: yes, that should be possible.

"Should" because the SuperHub is locked down and out of our control, and I'm sure VM can find some way to break it... but in lieu of that.


But modem mode gives you the control for that anyway with your own hardware its only a question of if VM will let us have modem mode when IPv6 is out.

---------------------------------------------------------------

http://www.ietf.org/rfc/rfc3177.txt

 

You can't allocate a longer prefix than /64 to a link, unless it is PPP which can be /128 or inter-router links.

 

 

TonyJr

legacy1
Alessandro Volta

I just had a thought....what if VM want a IPv4 & IPv6 setup where by all IPv6 devices each with their own IP needs to come out of one MAC which is a bit like NAT but not because each device has its own WAN IPv6 so it only changes the MAC with no need to keep state and routes it back by ARP IP lookup table to change the MAC to what device has that IP....if thats the case VM just need to tell router makers to implement that so their router is supported and we get to keep modem mode.

 

Now if this was not done then the modem would need to allow more MAC so that every device with its own MAC connects to the UBR to get a IPv6 and I think thats what VM don't want to happen they only want to see one MAC and you can have many WAN IPv6 address.  

---------------------------------------------------------------

Or alternately we could use "routing", where your router is the only machine connected to the ISP and the only one they ever directly talk to, and your ISP routes your IP allocation to your router. Your router then takes care of delivering the packets after that point. You don't connect all your client machines directly to your ISP's network. This is how networks normally work.

 

(Unless your ISP screws up and doesn't route you your allocation. Then you're stuffed, and have to either connect all your client machines directly without a router or mess around with proxy NDP, which is "NAT for MACs" -- what you've just invented -- and is a workaround for broken network design.)

 

Notably, when routing, the ISP(/modem) doesn't ever see the MAC addresses of your computers, but only the upstream-facing MAC of your router. MACs are only used to send packets between two hosts on the same L2 broadcast domain ("network"), and your private LAN is a separate network to the one which links your router to the ISP. Your client devices don't need to talk to the UBR to get an IP; they get that from your router.

 

(Note that the situation is exactly the same even when NAT is involved, the only difference being a step where the IPs are rewritten. NAT never touches MAC addresses at all.)

legacy1
Alessandro Volta

@Dagger wrote:

 

Notably, when routing, the ISP(/modem) doesn't ever see the MAC addresses of your computers


Your wrong about that because when I had a EPC2000R2 modem and logged in to it...it not only displayed the MAC of the computer I had connected to (without a router) it but also the WAN IP. So I know that’s possible its just that the hub doesn’t display this info to you.  

 


@Dagger wrote:

NAT never touches MAC addresses at all.)


NAT does touch MAC fact and IP from local to WAN.

 

In order to not break IPSec you must not change the IP. 

---------------------------------------------------------------

I think IPSec is one of those odditys where there has to be a nat transversal with no (or highly specific) alterations.

 

Bit like SIP devices and other VPN connection methods.

 

A router could easily cope with both a Ipv4 NAT layer AND and ipv6 transversed layer.

----
I do not work for VM, but I would. It is just a Job.
Most things I say I make up and sometimes it's useful, don't be mean if it's wrong.
I would also make websites for them, because the job never seems to require the website to work.

A router can do that yes by passing through WAN IPv6 and even the one IPv4 IP so you don't use NAT for IPv4 but the question is this do VM want to see many MAC's of allocated WAN IPv6 at their end from one modem?
---------------------------------------------------------------


@legacy1 wrote:
Your wrong about that because when I had a EPC2000R2 modem and logged in to it...it not only displayed the MAC of the computer I had connected to (without a router) it but also the WAN IP. So I know that’s possible its just that the hub doesn’t display this info to you.

By "computers" I meant the client machines behind the router. It's expected for the modem to see the MAC address of the router itself. (If you're not doing any routing and just have the one machine hooked up to the modem, then it'll show the MAC address of that one machine.)

 

I wasn't basing my above post on what the hub does or doesn't display for me. I made it based on a knowledge of how routing and NAT work.


@legacy1 wrote:
NAT does touch MAC fact

It doesn't. It just doesn't work like that. You can see this yourself easily enough on a machine routing between two networks with no NAT:

 

$ ifconfig br0; ifconfig br1
br0       Link encap:Ethernet  HWaddr 3‍a:ec:23:a1:53:a3
          inet addr:192.168.1.83  Bcast:192.168.1.255  Mask:255.255.255.0
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:43549835 errors:0 dropped:0 overruns:0 frame:0
          TX packets:55667960 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:16829936925 (15.6 GiB)  TX bytes:24343765008 (22.6 GiB)

br1       Link encap:Ethernet  HWaddr 5‍2:43:a3:f9:6c:0c
          inet addr:192.168.2.1  Bcast:192.168.2.255  Mask:255.255.255.0
          UP BROADCAST RUNNING PROMISC MULTICAST  MTU:1500  Metric:1
          RX packets:73288801 errors:0 dropped:0 overruns:0 frame:0
          TX packets:34626373 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0
          RX bytes:21083428646 (19.6 GiB)  TX bytes:16340986892 (15.2 GiB)

$ iptables -vnL -t nat
Chain PREROUTING (policy ACCEPT 37M packets, 3768M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain POSTROUTING (policy ACCEPT 1696K packets, 101M bytes)
 pkts bytes target     prot opt in     out     source               destination

Chain OUTPUT (policy ACCEPT 592K packets, 46M bytes)
 pkts bytes target     prot opt in     out     source               destination

# I'm running `ping 192.168.1.64` on 192.168.2.2, which is a machine connected via br1.
#
# eth0      Link encap:Ethernet  HWaddr 0‍0:08:54:15:cd:69
#           inet addr:192.168.2.2  Bcast:192.168.2.255  Mask:255.255.255.0
#

$ tcpdump -eni br1 host 192.168.2.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br1, link-type EN10MB (Ethernet), capture size 65535 bytes
01:43:22.079511 0‍0:08:54:15:cd:69 > 5‍2:43:a3:f9:6c:0c, 
  ethertype IPv4 (0x0800), length 98: 192.168.2.2 > 192.168.1.64: 
  ICMP echo request, id 60246, seq 2048, length 64
01:43:23.079494 0‍0:08:54:15:cd:69 > 5‍2:43:a3:f9:6c:0c, 
  ethertype IPv4 (0x0800), length 98: 192.168.2.2 > 192.168.1.64: 
  ICMP echo request, id 60246, seq 2304, length 64
01:43:24.079506 0‍0:08:54:15:cd:69 > 5‍2:43:a3:f9:6c:0c, 
  ethertype IPv4 (0x0800), length 98: 192.168.2.2 > 192.168.1.64: 
  ICMP echo request, id 60246, seq 2560, length 64

$ tcpdump -eni br0 host 192.168.2.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on br0, link-type EN10MB (Ethernet), capture size 65535 bytes

01:35:49.795009 3‍a:ec:23:a1:53:a3 > 0‍0:26:e3:41:e1:9c, 
  ethertype IPv4 (0x0800), length 98: 192.168.2.2  > 192.168.1.64: 
  ICMP echo request, id 47190, seq 8960, length 64
01:35:50.795005 3‍a:ec:23:a1:53:a3 > 0‍0:26:e3:41:e1:9c, 
  ethertype IPv4 (0x0800), length 98: 192.168.2.2  > 192.168.1.64: 
  ICMP echo request, id 47190, seq 9216, length 64
01:35:51.794979 3‍a:ec:23:a1:53:a3 > 0‍0:26:e3:41:e1:9c, 
  ethertype IPv4 (0x0800), length 98: 192.168.2.2  > 192.168.1.64: 
  ICMP echo request, id 47190, seq 9472, length 64

 

See how the packets on the br0 link come from 3‍a:ec:23:a1:53:a3 (the MAC address of br0 on the router), not from 0‍0:08:54:15:cd:69 (the MAC address of eth0 on 192.168.2.2)? The packets have a source MAC of 0‍0:08:54:15:cd:69 when they're sent from the original machine to the router over br1, as you can see, but when they're being sent from the router to 192.168.1.64 the source MAC is the router itself. You can see I have no NAT rules, so it's not due to NAT: this is just how routing works.

 

The same applies to the destination MAC address: note how the original packets from 192.168.2.2 have a destination MAC of 5‍2:43:a3:f9:6c:0c, which is the router's MAC address (on br1), not 192.168.1.64's. Likewise I could have pinged the IP of a machine somewhere out on the internet, and the packets coming out of 192.168.2.2 would still have the same destination MAC for 192.168.2.1, since 192.168.2.1 is 192.168.2.2's default router. You don't ever know the MAC address of a machine you're talking to unless that machine is on the same link (specifically the same L2 broadcast domain) as yourself, because MACs are only used for sending packets between two machines on a single link.


@VMCopperUser wrote:
I think IPSec is one of those odditys where there has to be a nat transversal with no (or highly specific) alterations.

This is true. Any attempt to alter the protected packet looks like an MITM attack and causes the packet to be rejected. It's a bit different to the situation with SIP (which breaks with NAT because SIP announces the IP and port that the remote side needs to use, but NAT changes the IP/port) and with some VPNs (e.g. p41 6in4 tunnels, which can break because p41 has no port numbers and it is thus impossible to distinguish two tunnels to the same remote IP.)

 

These are all problems that just go away when you're not dealing with NAT. None of this has any relevance to MAC addresses though, since those are at L2 and are irrelevant when you start dealing with IPs...


@legacy1 wrote:
the question is this do VM want to see many MAC's of allocated WAN IPv6 at their end from one modem?

And again: they won't see the MACs of machines on your local network provided they do things properly and use routing everywhere, which I sincerely hope they will. (It would be really nice if VM could comment on their plans.)

VMCopperUser
Wise 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.

----
I do not work for VM, but I would. It is just a Job.
Most things I say I make up and sometimes it's useful, don't be mean if it's wrong.
I would also make websites for them, because the job never seems to require the website to work.