Estou confuso sobre o funcionamento de um roteador doméstico comum: os endereços MAC não deveriam ser suficientes para encaminhar as informações ao destino correto?

2. No roteador, eu encaminho a porta 80 (externa) para a porta 80 (interna) do (ao invés do IP local) o endereço MAC do PC.

Eu sei que não é assim que funciona, a questão é por que não foi implementado assim em primeiro lugar? E sim, um quadro não é um pacote de qualquer maneira. Eu apenas quero dizer isso para fins de identificação.

O que você descreveu é realmente muito próximo de como o roteamento IP funciona nos bastidores - quando NAT ou "encaminhamento de porta" não está envolvido, um roteador encaminha pacotes alterando apenas seu MAC de destino e tecnicamente não precisa saber o endereço IP do dispositivo.

Por exemplo, na tabela de roteamento (não me refiro às regras de "encaminhamento de porta") você tem um campo "gateway" ou "próximo salto" que é tradicionalmente um endereço IP, mas seu único objetivo é ser resolvido para alguns tipo de endereço de camada inferior, de modo que a tabela de roteamento poderia perfeitamente aceitar um endereço MAC diretamente.

Mas, apesar disso, as entradas da tabela de roteamento exigem um endereço IP por vários motivos. Por um lado, usar um endereço IP é uma abstração útil , graças ao uso de ARP (ou NDP) para resolver dinamicamente os endereços MAC: o gateway real pode alterar suas interfaces Ethernet, mas desde que assuma o mesmo endereço IP, o a mesma configuração de roteamento antiga permanece válida.

Outra razão é que é mais simples aceitar apenas um tipo de endereço em vez de vários. Mesmo um gateway doméstico típico não é construído apenas com a Ethernet em mente: um modem ADSL já precisa lidar com duas camadas MAC totalmente diferentes, portanto, sua tabela de roteamento precisaria aceitar dois tipos diferentes de endereço de próximo salto.

Portanto, é realmente mais simples aceitar endereços IP e contar com os mecanismos existentes para traduzi-los – mecanismos como ARP que precisam estar presentes de qualquer maneira. Além disso, apesar da tradução adicional, simplifica as coisas porque significa que todos os pacotes são tratados da mesma forma, sejam entregues ao host final ou a outro gateway, em vez de haver dois casos diferentes.

(Mas algumas redes realmente usam endereços IPv6 nexthop para rotas de rede IPv4. O sistema operacional do gateway de origem simplesmente usa NDP em vez de ARP para resolver o endereço MAC do gateway nexthop, sem nenhuma alteração no pacote IPv4 real que está sendo encaminhado.)

Para "encaminhamento de porta", alguns dos mesmos motivos se aplicam, como a capacidade de separar um endereço IP do host físico. Mas a razão mais importante é porque o "encaminhamento de porta" foi uma adição muito posterior à rede IP, por isso é implementado de forma que o host final não precise estar ciente disso: ao contrário do roteamento simples, uma "porta -forwarded" endereço IP de destino real do pacote (aquele no cabeçalho IP) é traduzido do endereço WAN do roteador para o endereço interno que você especificar.

Em outras palavras, o endereço IP precisa ser fornecido porque todo o objetivo do "encaminhamento de porta" em oposição ao roteamento simples é colocar o endereço IP do dispositivo de destino no pacote. O resultado é que o dispositivo de destino pensa que é de fato o destino da conexão "encaminhada" e não se confunde ao receber um pacote com o IP do roteador (que normalmente descartaria - ou pior, encaminharia de volta ao roteador).

Pode ter havido outras maneiras de obter tipos semelhantes de "compartilhar" um endereço IP entre vários dispositivos, mas elas exigiriam alterações nos próprios dispositivos. Por exemplo, se você apenas atribuiu diretamente o mesmo endereço IP público a todos os hosts da LAN, bem como ao roteador – fazendo-os aceitar pacotes não modificados, com o endereço IP público – os dispositivos não poderiam mais se comunicar, devido a todos os tendo o mesmo endereço. (Lembre-se de que muitas pilhas IPv4 não permitem vários endereços IP por interface, portanto, atribuir os endereços público e local não seria uma opção.) Em contraste, a tradução feita

(Um método alternativo que funciona é atribuir a cada dispositivo um endereço IP público, tornando desnecessárias as regras de "encaminhamento de porta" e confiando apenas no roteamento padrão.)

Outro pensamento relacionado é que as portas não são um conceito universal, mas pertencem especificamente ao TCP – que por sua vez depende do IP – portanto, embora seja tecnicamente possível ter uma regra "se a porta 80, encaminhar para o MAC x:y:z", logicamente faz muito mais sentido ter uma porta TCP associada a um endereço IP específico (isto é, a próxima camada inferior imediata) do que a um endereço de hardware.

Resposta anterior:

Por que a necessidade de associar endereços IP privados a cada um dos endereços conectados? Os endereços MAC não deveriam ser suficientes para encaminhar as informações para o destino correto?

Se seria "suficiente" não é a pergunta certa. Sim, fundamentalmente isso seria possível, mas não é realmente desejável – isso traria muito mais complexidade nova do que você espera que removeria.

1. Já existem muitas maneiras pelas quais uma rede pode ser construída sobre Ethernet, mas sem IP (algumas das quais costumavam ser muito mais populares do que o IP), por exemplo, NetBIOS, DECnet, IPX, VINES, X.25, AppleTalk são apenas algumas protocolos que foram usados ​​em LANs e WANs no passado. Eventualmente, porém, praticamente todas essas redes migraram para IP ou desapareceram. (WANs baseadas em X.25 ou "Public Data Networks" costumavam ser grandes, até serem substituídas por redes baseadas em IP.)

   Embora você ainda possa construir uma LAN sem depender de IP, hoje em dia qualquer LAN inevitavelmente precisa se comunicar com uma rede principal baseada em IP (a Internet). os programas ainda precisariam entender os endereços IP da Internet , além dos endereços MAC locais.

   Isso significaria que programas e sistemas operacionais precisariam lidar com dois tipos de rede diferentes – endereços MAC para alcançar outro host se estiver dentro da LAN e endereços IP se esse host estiver fora. Isso é muito semelhante a um problema atual de usar um endereço IP privado para hosts localmente e um endereço público ao passar pelo "encaminhamento de porta", mas estritamente pior.

   (Para ser justo, seria um pouco como a atual coexistência de IPv4 e IPv6 nas redes modernas, com programas precisando dar suporte a ambos – mas o IPv6 tem uma necessidade prática de existir e sua existência visa unificar as redes, enquanto o hipotético MAC -rede somente de endereço apenas os separaria mais sem nenhuma vantagem prática.)

2. Embora os hosts dentro da mesma rede possam usar apenas seus endereços MAC para se comunicar, assim que um host interno precisar enviar alguns pacotes para a Internet, você ainda precisará de um cabeçalho extra que possa conter pelo menos o endereço IP de destino e o roteador precisaria traduzir entre os dois tipos de pacote – IP regular de um lado, o protocolo LAN hipotético "não-IP, mas por favor entregar a um endereço IP" do outro. Isso é factível, mas muito mais complexo do que apenas usar o mesmo tipo de IP em ambos os lados.

   Um ponto importante é que os endereços IP "privados" são uma adição muito, muito posterior às redes IP - a tradução atual entre endereços IP privados e públicos não é uma parte natural de como o IP funciona, mas foi amplamente trazida pelo "roteador doméstico comum " anos depois. Antes disso, os hosts em uma LAN (se a LAN usasse IP) costumavam ter apenas endereços IP públicos como em qualquer outro lugar na Internet – servidores em datacenters ainda têm – e não havia necessidade de "encaminhamento de porta", pois você poderia acessar qualquer host por endereço próprio.

No geral, isso seria um pouco contrário à existência do IP em primeiro lugar – todo o objetivo de um protocolo de camada de rede é unificar diferentes tipos de redes. Atualmente, o IP em sua LAN doméstica funciona exatamente da mesma maneira que o IP em seu escritório ou universidade ou em várias redes públicas ou no restante da Internet.

(De maneira semelhante, IP sobre Ethernet funciona como IP sobre cabo funciona como IP sobre ADSL funciona como IP sobre 3G/4G, embora cada um desses tipos de rede tenha uma camada MAC completamente diferente às vezes sem nem mesmo o conceito de um "MAC endereço".)

Na verdade, o objetivo do "próximo" IPv6 é o oposto do que você está pensando - em particular, a capacidade de atribuir endereços públicos a todos os dispositivos leva à unificação das redes ainda mais, removendo o NAT "endereços privados começam aqui" limite com o qual as LANs IPv4 atualmente precisam lidar.

(Da mesma forma, há esforços contínuos para estender o uso do IP a redes que ainda não o usavam, como o Thread em IoT.)

Observação sobre os comentários sobre endereços MAC não roteáveis: Já existem várias maneiras de construir redes roteadas que usam apenas endereços MAC; eles simplesmente não são usados ​​em LANs típicas baseadas em IP porque o roteamento da camada IP é suficiente.

Por exemplo, HWMP e BATMAN são padrão para redes mesh Wi-Fi, enquanto SPB e TRILL em redes corporativas aplicam o mesmo protocolo de roteamento IS-IS para endereços L2, pois é amplamente usado para roteamento IP.

(Os protocolos de redes IPX e XNS também usavam endereços Ethernet MAC diretamente para identificar hosts, mas obtiveram o roteamento por meio de um "endereço de rede" adicional prefixado ao endereço de host baseado em MAC, evitando a necessidade de rotear cada MAC individualmente. Se você apertar os olhos, O IPv6 funcionou da mesma maneira no início.)

O motivo é realmente muito simples: para que os hosts não precisem saber ou se preocupar se estão atrás de uma camada NAT.

Considere um aluno com um laptop. Quando ele o leva para a universidade, esse laptop precisa lidar com endereços IP públicos e executar um software que identifica conexões por endereço IP e porta (não há "roteador doméstico" para traduzir). Quando ele leva o laptop para casa, é desejável que o mesmo software funcione. Se as redes domésticas identificassem conexões por endereço MAC e porta em vez de endereço IP e porta, você precisaria de um conjunto totalmente diferente de software de rede para uso doméstico. Imagine a dor de manter seus favoritos e cookies sincronizados entre o programa de navegador World-Wide-Web-on-the-school-school e o programa World-Wide-Web-on-the-home-network.

Ao fazer com que um roteador doméstico fale o mesmo "protocolo de Internet" no lado não-Internet, os computadores não precisam de dois tipos separados de rede.

O TCP/IP usa o IP para rotear o tráfego. Está lá no nome.

Se você usasse endereços MAC, não usaria TCP / IP e, nesse ponto, o roteador precisaria fazer ainda mais trabalho para aceitar qualquer protocolo baseado em MAC usado e encaminhar as solicitações.

Seria muito mais trabalhoso do que a modificação/adição de cabeçalho mais simples que é feita pelo Network Address Translation (NAT).

Usar o TCP/IP para rede interna e externa significa uma rede muito mais simples em geral, pois o mesmo protocolo é usado entre máquinas na mesma rede da Internet e não precisa de pontes mais inteligentes com servidores e outros conversores de protocolo.

The internet wasn't really designed to have "private addresses" in the first place. A device that's connected to the internet is expected to have an internet address (i.e. a public IP address). Other devices on the internet talk to it using its internet address. MAC addresses are a local-network/hop-by-hop detail that isn't available to the device on the other end of the connection.

So now suppose, for various reasons, you need to break that convention and share a public IP address among several devices, while having them function basically the same. Each device still needs/expects to have an IP address, so you give them private addresses, and you translate between the public address and private addresses on a connection-by-connection basis at the border of the network — that's NAT (network address translation).

So why can't we take your suggestion, and just take the incoming packet, look up which device its flow belongs to, slap the correct destination MAC address on it while keeping the IP address the same, and let the switch send it to the correct port? We sort of could, but that would mean that all of the internal devices would have to have their interfaces configured with the same external IP address. That's not impossible, strictly speaking, but it's enough of a pain in the butt that it doesn't gain you anything.

1. The devices on the local network wouldn't be able to talk to each other using the public address, since they all think they own the same address. If you wanted them to be able to talk to each other, you'd have to give them unique private addresses as well (and if you're doing that, why not just use the private addresses and do NAT?)

2. There will be times, in your scheme, where the router has to rewrite the port numbers on incoming/outgoing packets (for instance, to avoid a 4-tuple clash if two devices choose the same ephemeral source port for an outgoing connection to www.google.com:443, or because two devices have services listening on the same port, but you want to make them both accessible to the outside world on different ports). And even in the ordinary case it needs to be able to identify connection flows to send packets back to the correct local device. So it needs to be able to parse, track, and modify the headers of the next-level protocol (IP). These are the exact same requirements that we have with "regular" NAT routers, so again, if you're going to all that trouble, why not rewrite the address too?

3. Suppose your public IP address is dynamically assigned, as it is on most residential ISPs. Suppose your router's link goes down and comes back up, and you get a new address. You now have to reconfigure all of the devices behind the router. So you need to be able to disseminate that information to them using something like DHCP. Except DHCP as we know it is client-initiated; there isn't any way for the server to tell a client device "hey, the address you're holding a lease for isn't actually valid anymore, you'll have to get a new one". So we would need something new and different.

Basically, as icky as it may seem, the way we do things has been evolved to provide good results with the minimum of admin hassle, and it mostly succeeds at that.

2. No roteador, eu encaminho a porta 80 (externa) para a porta 80 (interna) do (ao invés do IP local) o endereço MAC do PC.

Eu sei que não é assim que funciona, a questão é por que não foi implementado assim em primeiro lugar? E sim, um quadro não é um pacote de qualquer maneira. Eu apenas quero dizer isso para fins de identificação.

A rede funciona em camadas que envolvem o conteúdo das camadas superiores e encaminham os dados pelo caminho para chegar aonde vão. A internet foi construída sobre roteamento via endereço IP, e o TPC é um protocolo em cima daquele que contém a porta 80. HTTP é outra camada em cima daquela que normalmente usa a porta 80 do TCP.

Ter equipamentos que operam em IP e controlar o roteamento dessa forma é como a internet foi construída. Os computadores hoje em dia têm o software embutido, o que nem sempre foi o caso. Para fazer isso de maneira diferente, você teria que criar seus próprios protocolos e software, o que apenas adicionaria mais complexidade e enfraqueceria a segurança. Acessar uma página da web envolve estabelecer uma conexão TCP que envolve pacotes IP enviados que nada têm a ver com HTTP. Na verdade, você não precisa tecnicamente de TCP ou mesmo IP para HTTP, você pode ter uma conexão serial e executar solicitações HTTP diretamente sobre ela, mas que graça isso teria? IP é o que permite a internet global.

Digamos que seu roteador apenas envie os dados para o seu computador pela Ethernet usando seu endereço MAC. O que seu computador deve fazer com esse monte de dados que acabou de receber? Seu sistema operacional terá que ter algo escutando esses dados que não sejam direcionados ao seu endereço IP. Então terá que interpretá-lo de forma a determinar o que fazer com ele. Isso deve corresponder à finalidade para a qual você designou esses dados em seu roteador em primeiro lugar. Você vai precisar de algum tipo de cabeçalho para os dados que o roteador pode enviar informando ao seu computador qual é a finalidade dos dados. Parabéns, você acabou de começar a desenvolver um novo protocolo que ninguém quer ou precisa!

Seu computador e roteador já usam seus endereços MAC na camada de enlace de dados para enviar dados um ao outro pela Ethernet. Apenas a maioria desses dados são datagramas IP encapsulados que permitem que você se conecte à Internet porque informam ao seu roteador para onde os dados devem ir.

Se você está perguntando por que não apenas permitir que você insira um endereço MAC para rotear apenas as solicitações recebidas, eu perguntaria por que você gostaria de fazer isso? O roteador já foi construído para roteamento de IP e associa endereços IP a endereços MAC automaticamente para rotear o tráfego IP para o local apropriado. Normalmente, uma rede é projetada em torno do IP e você simplesmente esquece o endereço MAC, a menos que queira restringir o acesso a uma peça específica de hardware. Usando o endereço IP, você pode reatribuir endereços sem alterar o hardware ou reconfigurar o roteador. Você pode obter uma nova placa de rede e configurá-la com o IP antigo para não precisar reconfigurar o roteador. Você não precisa se preocupar em ter dois métodos, pois o IP seria cerca de 10.000 vezes mais útil. E você tem que atribuir um endereço IP de qualquer maneira para colocar no pacote para o seu computador reconhecer como seu. Você pode ter vários IPs no seu PC. Você pode ter outro roteador com sua própria rede privada e apenas rotear para o IP desse roteador se estiver encaminhando ou para um computador específico do outro lado desse segundo roteador usando seu endereço IP individual.

MAC significa "Media Access Control" - o que significa que controla algo que gera sinais fisicamente em um meio (chamado PHY).

Exemplos de PHY: Ethernet com fio, rádios Wi-Fi em canais específicos, modem a cabo/DOCSIS, DSL, fibra óptica

Exemplos médios: cobre, ondas de rádio no ar, óptico

Quando você diz a um PHY para falar com outro MAC, o PHY só ​​pode olhar e ver outros dispositivos com PHYs conectados ou ouvindo no mesmo meio. Esta é a base do conceito de rede.

Portanto, seu rádio Wi-Fi só pode ver outros nós que estão ouvindo na mesma banda e canal. Sua placa Ethernet com fio só pode ver os nós que estão ouvindo no mesmo "fio" - que pode ser estendido usando switches. (Originalmente, os nós em redes com fio eram todos fisicamente conectados a um único fio).

IP--which stands for Internetworking Protocol--a global scheme that does not care about the medium and therefore sets on top of MAC addresses.

Thus ... devices need to exist that can forward traffic that one network wants to send to others - and it will need to be connected to at least 2 networks. Those devices are called routers - and nodes that want to talk to something that is not on the same network need to send traffic to the router. The subnet mask allows nodes to know which network they are "in" (and therefore don't have to send to the router).

ISPs work the same way - your router connects to the ISP network, and the ISP has carrier-grade routers that take traffic not destined for its network and route it to other ISPs (at places called IXPs).

Vou responder diretamente às duas subperguntas dadas:

Os endereços MAC não deveriam ser suficientes para encaminhar as informações para o destino correto?

Em uma rede pequena, sim. Como entre Host-1, Host-2 e Host-3 em seu exemplo, seria possível que todos os hosts conhecessem o MAC do host que desejam e enviassem dados para ele. Em outras redes com um Hub em vez de um Switch, você também pode enviar quadros Ethernet para todos os clientes em uma rede e configurá-los para apenas ignorar os dados que chegam e não são endereçados a eles. Muitas topologias Hub e Start usavam um sistema como este.

Observe que eu disse Data and Ethernet Frame, que leva à segunda parte e explica por que você está usando endereços de protocolo da Internet.

Por que a necessidade de associar endereços IP privados a cada um dos endereços conectados?

Você não deseja enviar dados de nível Ethernet entre clientes. Se você deseja enviar dados de protocolo IP entre dois clientes (local ou remoto), é necessário fornecer uma pilha de rede de nível IP, que inclui endereços IP. Como a Internet é construída sobre os padrões de protocolo da Internet, uma grande quantidade de nossos protocolos e ferramentas são construídas em torno dessa camada de rede. Se você deseja enviar dados TCP ou UDP, deve fazê-lo por IP (normalmente).

É a onipresença da rede IP e do software que torna necessário o uso de endereços IP em uma pequena rede. Isso exigiria que alguém desenvolvesse e oferecesse suporte a um protocolo e produto duplicados para fazer o mesmo trabalho em um nível de rede inferior.

Notas laterais sobre redes NAT e Ethernet. O NAT foi um hack adicionado para contornar a falta de endereços IP antes que o IPv6 fosse definido e adotado. Agora é um hack comum, tão comum que está atrasando a mudança para o IPv6. No conceito inicial, todos os clientes e servidores na Internet deveriam ter endereços IP verdadeiramente únicos publicamente.

Eu uso alguns sistemas que usam apenas tráfego Ethernet. Muitas vezes, eles são conectados apenas diretamente a outros sistemas ou em redes muito pequenas. Ele permite que você comece em um nível inferior na pilha de protocolos de rede, o que é mais simples para sistemas com computação limitada ou onde a velocidade é um requisito absoluto. A desvantagem é que todas as vantagens oferecidas a você pelas redes IP, UDP ou TCP não existem, muitas pessoas estão tão acostumadas com a presença delas.

Outro motivo que não vi mencionado nas outras respostas é a agregação de rota IP. As tabelas de roteamento são mantidas de acordo com blocos de endereços IP, em vez de endereços IP individuais. Caso contrário, as tabelas ficariam muito grandes, tanto para manter quanto para realmente usar. Portanto, as interfaces dentro da mesma rede usam endereços IP na mesma sub-rede e o bloco de endereço da sub-rede é anunciado para o mundo externo. Portanto, quando você muda de rede, normalmente também muda os endereços IP para que seu endereço possa ser agregado. (Isso funciona em vários níveis, começando na LAN, no ISP local e no ISP de nível superior.) Os endereços MAC, por outro lado, são estáticos. Se baseássemos o roteamento em endereços MAC, as tabelas de roteamento explodiriam em tamanho, além da necessidade de uma sobrecarga incrivelmente grande de mensagens do protocolo de roteamento para endereços individuais.

The MAC address is part of layer 2 of the OSI model, in this case Ethernet.

Ethernet is not a routable protocol, so there is no concept of "default route/gateway" at layer 2

IP at layer 3 does have the distinction between local traffic and "everything else via a specific IP"

All other answer are long enough, here is the TLDR:

• Back in ye ol' days, the internet isn't supposed to have a "private IP address", that came after when they realized that there wouldn't be enough IPv4 to go around if the internet continue to gain popularity like this. That is why home internet access nowadays will use private IPv4 but the main router (still on the customer's premises) will have a publicly allocated IPv4 (yes, I know CGNAT exists) which will NAT every packet that came from the private IP side and translated to the public IP side (and vice-versa). The original IPv4 design is to have every internet access device have its unique and publicly reachable IP, this is currently possible with IPv6 because of its very massive amount of addresses.

• Another important thing about the IP address is that it isolates every network segment and requires a router to forward a packet to the network that is unknown to the host (outside the range of the specified netmask).

If you try to get rid of all the IP routing stuff and just straight up use MAC address for routing, all hell broke loose because now everyone will receive everyone's frames because of the nature of L2 forwarding which will flood every unknown frame to everywhere possible.