on 27-03-2010 18:11
on 10-02-2012 01:47
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.
on 10-02-2012 13:35
@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.
on 10-03-2012 23:16
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.
on 11-03-2012 01:02
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.
on 11-03-2012 02:01
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.)
11-03-2012 14:38 - edited 11-03-2012 14:46
@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.
on 11-03-2012 19:49
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.
on 11-03-2012 21:57
on 12-03-2012 05:06
@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 3a: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 52: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 00: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 00:08:54:15:cd:69 > 52: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 00:08:54:15:cd:69 > 52: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 00:08:54:15:cd:69 > 52: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 3a:ec:23:a1:53:a3 > 00: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 3a:ec:23:a1:53:a3 > 00: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 3a:ec:23:a1:53:a3 > 00: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 3a:ec:23:a1:53:a3 (the MAC address of br0 on the router), not from 00:08:54:15:cd:69 (the MAC address of eth0 on 192.168.2.2)? The packets have a source MAC of 00: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 52: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.)
on 12-03-2012 10:19
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.