I need someone to back me up, or prove me wrong, in regard to the comments I've made some time ago. Here is the original thread:
dual-stack ipv6/ipv4 on localhost
Basically, I'd like to know if we can have 2 different kinds of IP addresses (IPv4 and IPv6) running on the same network segment WITHOUT any address translation.
Thanks in advance!
Without any problems: IPv4 and IPv6 can share a transport layer such as Ethernet without causing problems. Furthermore, there are many systems that can support both v4 and v6 protocol stacks concurrently.
Of course, to get any communications going between IPv4 and IPv6 nodes, one must go through a gateway (e.g. 4to6).
Related
I am sorry if its basics, but I did not find the appealing answer for it over the Internet.
Why only MAC is used to transfer the packet to a device ? MAC address is only obtained by ARP for a specific IP address. So, why not just let the routers maintain IP addresses of the neighbouring routers and route packets using IP addresses of routers instead of MAC addresses ?
Why not redesign the architecture, to only use IP address for routing as well as moving the packet in the data link layer too ?
Why do we need MAC addresses?" Why can't network devices such as the routers just send the packet to the next router using the router's IP address?
Note : I know that MAC address is used to identify the system in a network. But you see the source never knew the MAC address of receiver. All it knew was its IP address and MAC address of next hop.
I'm reading Data Comm and Networking by Forouzan ( Ed 5) and it says that even routers have an IP address. So why use the mac address at all. The router can store the IP address of the source and route it to the next router .
EDIT : The question that I was getting as suggestion to this one does not answer my query. There are multiple counter points and proof that I have presented here which could have been done which is not answered by the one which is suggested. So please read my question before making any assumptions.
What do you think makes more sense: Having one protocol like Ethernet handle all the layer 2 details so that its layer 3 payload doesn't have to care, or force IP, ARP, WoL, IPX, MPLS, SLPP, and dozens more implement it on their own? The whole purpose of OSI layers is that upper layers need not know all the lower layer's details and lower layers need need not support the upper layer's features.
MAC addresses are used for the layer 2 protocol which encapsulates a layer 3 protocol. If all the necessary features were embedded into IP, then you'd be leaving other protocols to re-implement layer 2 routing on their own. This would be wildly inefficient.
I've been told that it is bad practice to have two interfaces on the same device on the same subnet. i.e. two Ethernet ports on a switch should be on different subnets. Could somebody explain why this is the case? (preferably simply as possible as I'm new to networking)
Because routing in your OS normally sets one of Ethernet card as out gate to specified subnet and all traffic to this subnet will have only 1 output. Second route to same subnet will have bigger Metrik value and will use to send some data if first interface is down. Even if somebody will send request to second interface answer can have first Ip as sender.
If you try to increase throughput to subnet you must use aggregation of Ethernet link. you`ll have 2 physically link and 1 IP.
subnet is the logical division of the IP network based on the subnet-mask/netmask. So unless you plan to have two different separate networks, you need not to have two different subnets. This link explains most of the possible cases to explain what it means by subnetworks on a switch.
Whether two interfaces on the same subnet is good or bad depends entirely of what you're trying to accomplish.
If you need link redundancy or a simple way of load sharing (L2 or L3) it may the right way to go.
If you need network/uplink redundancy or a more complex way of load sharing (L3 only) you connect to two different networks (multi-homing). This is also the setup for a router connecting the two networks.
I'm new to ROS, wish someone can answer my stupid question.
I have a static IP 140.113.xxx.xxx, and a 4G dongle with floating IP 192.168.8.100. I want to use ROS to transmit data between them. Can ROS do that? Because I found some website said ROS can only transmit data in the same Internet domain, but I think this must have some trick to solve this problem.
this has nothing to do with ROS.Theses are IPs in two different networks, you either create a propper routing or you give a second device an IP in the same net. However 192.168.x.x should not be used in the internet or any other non private networks
Hello Networking Gurus,
I have a question about IP duplication and how this impact the associated switches (layer 2). Sorry, I don't have any resources available to test this. It would be great if someone can shed some lights of their experience on this.
If I have two servers (Linux), say A & B, serving exactly same contents and for some reason they both are assigned same IP address. To be more specific, if A already has an address IP.100 and B has another address IP.200. Now at this point everything seems working and the switch has proper MAC addresses stored. If, later, B also gets the address IP.100, how would this affect the switch's ARP cache? When B gets the new address I assume it broadcasts ARP? to inform the associated switch.
So the question is, Does the switch stores both machines' entries? or overwrites the existing with new? Is there any standard behaviour or proprietary switches reacts differently?
If a client, with no ARP cache, tries to connect to IP.100, which machine would it be forwarded to? A or B or none? If A OR B, can I say from client point-of-view, that there's no outage? (Assume this is a static website, with no login sessions etc)
Feel free to point any relevant documentation.
Thank you in advance.
In theory, you shouldn’t have two hosts talking on the same IP, unless they are participating in routing. Eg any-cast. As things will break.
Each host will have its own MAC address. If the switch is only doing layer two forwarding, then the switch only keeps track of MAC addresses. It is the end hosts or routers that track ARP entries.
If you move IP 100 to B, then the hosts will update their own ARP table.
But if A and B have 100 at the same time, this will cause issues.
Switch will not see any IP's and do not have arp cache for forwarding packets , it will had only mac address table map macs to ports and macs in your case will be unique
I actually think this is how multicast works.
Hosts obtain a multicast address and all of the devices share that same multicast address.
A switch will gather collections of Mac addresses to that same multicast in it's mac table.
I could be wrong though....Still learning.
2 computers are in different subnets.
Both are Windows machines.
There are 2-5 IGMP-ready routers between them.
They can connect each other over multicast protocol (they have joined the same multicast group and they know about each other's existance).
How to establish a reliable TCP connection between them without any public server?
Programming language: C++, WinAPI
(I need a TCP connection to send some big critical data, which I can not entrust to UDP)
You haven't specified a programming language, so this whole question may be off-topic.
Subnets are not the problem. Routability is the problem. Either there is routing set up or there isn't. If they are, for example, both behind NAT boxes, then you're at the mercy of the configuration of the nat boxes. If they are merely on two different subnets of a routed network, it's the job of the network admin to have set up routing. So, each has an IP address, and either can address the other.
On one machine, you are going to create a socket, bind it to some port of your choice, and listen. On the other, you will connect to the first machine's IP + the selected port.
edit
I'm going to try again, but I feel like there's a giant conceptual gap here.
Once upon a time, the TCP/IP was invented. In the original conception, every item on the network has an IPV4 address, and every machine could reach every other machine, via routing, except for machines in the 'private' address space (10.x, etc).
In the very early days, the only 'subnets' were 'class A, class B, class C'. Later the idea of subdividing a network via bitmasks was added. The concept of 'subnet' is just a way of describing a piece of network in which all the hosts can deliver packets to each other by one hop over some transport or another. In a properly configured network, this is only of concern to operating system drivers. Ordinary programs just address packets over the network and they arrive.
The implementation of this connectivity was always via routing protocol. If you have a (physical) ethernet A over here, and a (physical) ethernet B over there, connected by some sort of point-to-point link, the machines on A need to know where to send packets for B. Or, to be exact, they need to know where to send 'not-A' packets, and whatever they send them needs to know where to send 'B' packets. In simple cases, this is arranged via explicit configuration: routing rules stuffed into router boxes or even computers with multiple physical interfaces. In more complex cases, routing boxes intercommunicate via protocols like EGP or BGP or IGMP to learn the network topology.
If you use the Windows 'route' command, you will see the 'default route' that the system uses to send packets that need to leave the local subnet. It is generally the address of the router box responsible for moving information from the local subnet to everywhere else.
The whole goal of this routing is to arrange that a packet sent from a.b.c.d to e.f.g.h will get there. TCP is no different than UDP, except that you can't get there by multicast or broadcast: you need to know the exact address of your correspondent.
DNS was invented to allow hosts to learn each other's IP addresses without having human being send them around in email messages.
All this stops working when people start using NAT and firewalls to turn off routing. The whole idea of NAT is that the computers behind the NAT box are not addressable at all. They all appear to have one IP address. They can send stuff out, but they can only receive stuff if the NAT box has gone to extra trouble to map them a port.
From your original message, I sort of doubt that NAT is in use here. I just don't understand your comment 'I don't have access to the network.' You say that you've sent UDP packets here and there. So how did you do that? What addresses did you use?