es pt es es es es es es es es es es es es es es es es es es es es es es gl es es es es es es es es es gl es es es es es es es es es gl es es ceb es es es es es es es es es es es es es es es es es es es es es es es es es es es cs es cs es en it es es es es es cs es es es cs es es es cs es es es es en es es en es pt en es
A pesar de lo flexible y adaptable que se ha mostrado la especificación IP a lo largo de los años, existe un aspecto que los diseñadores originales no fueron capaces de prever: el extraordinario crecimiento que ha sufrido Internet en el número de nodos conectados.
Aparte del problema que acarrea el crecimiento de las tablas de rutado de las pasarelas, provocando un esfuerzo de procesamiento adicional, el principal escollo es el agotamiento del espacio de direcciones. El esquema original de direcciones no puede incorporar el número de redes que actualmente hay en funcionamiento.
Por tanto, dentro del ámbito del protocolo IPv4 (el más usado) ha sido necesario crear nuevos mecanismos de rutado que permitan compartir direcciones de red entre varias redes físicas. Concretamente, la mayor escasez de direcciones está en las redes medianas de tipo B, las cuales han ido adoptando direcciones tipo C o A a base de compartir el espacio de tipo B con otras redes parecidas.
Por otra parte, existe una nueva forma de direccionamiento propio de la versión IPv6 que termina con esas limitaciones. Sin embargo, la compatibilidad con este protocolo se ha retrasado mucho. Incluso bastante entrado el siglo XXI todavía el uso de direcciones IPv6 sigue sin estar completamente implantado. Las razones de este retraso serían motivo de otro artículo.
El fundamento de la reorganización de direcciones IPv4 es el principio que establece que cada red tiene libertad de modificar las direcciones y rutas, siempre que dichas modificaciones permanezcan ocultas para las demás localidades. Esto ha dado lugar a una serie de técnicas de rutado independientes entre sí, que dan solución a la reutilización de direcciones de red.
TÉCNICAS PARA MINIMIZAR LAS DIRECCIONES DE RED
La técnica denominada traducción de direcciones o NAT (Network Address Translation) es la que nos permite, por ejemplo, conectar muchos dispositivos en casa, pero contratando solo una dirección IP con el proveedor de Internet. También se usa en redes corporativas de tamaño medio.
La forma en que esta técnica ahorra direcciones IP es parecida a la de una centralita de teléfonos, donde un mismo número externo da acceso a muchas extensiones internas.
El funcionamiento de NAT recuerda al de las centralitas telefónicas.
En una red de este tipo, los nodos dentro de la red tienen asignadas direcciones IP privadas, que están en unos rangos que por convención no son enrutables en la red de redes. Estas direcciones son:
- Todas las que empiezan por 10 (clase A).
- De 172.16 a 172.31 y 169.254 (clase B).
- Todas las que empiezan por 192.168 (clase C).
Cuando un paquete sale de la red, el router sustituye la dirección IP privada por otra externa, de manera que el paquete puede seguir su camino por Internet.
Pero surge un problema. Los paquetes que salen tienen vía libre, pero ¿y los que vienen de vuelta? Si muchas direcciones privadas usan la misma IP pública ¿cómo sabe el router colocar de nuevo la dirección correcta? Para ello necesita mantener una tabla donde lleva la cuenta de las conexiones y sus destinatarios, igual que haría una eficiente operadora en la centralita de teléfonos.
En routers baratos es común que el tamaño de la tabla de NAT sea pequeño, alguna vez pasará que se agote y tengamos que apagar y encender el router. Ya sabéis, la solución a todos los problemas.
Una limitación importante de la NAT es que solo funciona con transparencia cuando las conexiones se originan en el interior. Si un nodo de Internet intenta abrir conexión con un nodo interno, no va a poder porque su dirección es privada. La solución es abrir un puerto del router, asignando que todo el tráfico que venga por ese puerto vaya a un nodo específico. En las redes domésticas es común tener que abrir puertos para los juegos en red, incluso tener que configurarlos manualmente.
Esta solución se basa en ahorrar direcciones tipo B a base de integrar redes medianas en el espacio de direcciones de otras redes tipo A.
Se trata de una multiplexación de direcciones a través de nodos dedicados que despachan a toda una red local a partir de una red ámplia tipo A. La pasarela transparente se encarga de que los nodos de la red local puedan comunicarse con la WAN como si realmente estuvieran conectados a ella. De esta manera, la LAN funciona integrada en la red ámplia sin ocupar una dirección de red propia.
La pasarela se llama transparente porque ni los nodos de la LAN ni de la WAN se dan cuenta de su existencia. Estas pasarelas no ofrecen todos los servicios convencionales y, por ejemplo, no responden a las peticiones de eco ping.
El proxy ARP (también llamado ARP sustituto, ARP promiscuo y ARP hack) es una forma de que varias redes físicas medianas compartan la misma dirección de red. Además de ésta, tiene utilidad en otras situaciones.
Por ejemplo, es muy común que un determinado entorno físico se subdivida en subredes solo por conveniencia administrativa, sin que existan verdaderas separaciones físicas (p.e. cuando se usan bridges en vez de gateways) quedando la red en una estructura transparente.También puede pasar que los nodos no tengan capacidad para mantener sus tablas de rutas, o para responder adecuadamente a las redirecciones, o no soporten un sistema de subredes. En todos estos casos, se deben enviar los datagramas como si todo fuese una misma red.La forma de gestionar estas subredes "virtuales" es precisamente desmontando el sistema de ruteo de la red de redes. Los nodos no harán distinción alguna en las direcciones; todas serán consideradas como accesibles directamente.
Esto supone un problema: si se está considerando que cualquier dirección es accesible directamente en la red, ¿cómo comunicarse con las redes que están fuera de ésta? ¿Cómo diferenciar unas direcciones de otras? Para solucionar éste problema, las pasarelas deben soportar una versión del protocolo ARP llamada proxy ARP.
El proxy ARP se basa en un "truco" consistente en engañar a los nodos, haciéndoles creer que se trata de una sola red , mientras que las pasarelas sí conocen que la red está estructurada en redes físicas. Esto se consigue proporcionando una máscara ficticia a los nodos, y otra real a las pasarelas. Así, los datagramas dirigidos al exterior serán manejados correctamente por las pasarelas, mientras que los internos serán enviados directamente.
Para usar el proxy ARP debe tenerse en cuenta dos precauciones:
* Se debe desactivar los mensajes ICMP de petición de máscara. La existencia de dos máscaras distintas crearía confusión, pues ni los nodos ni las pasarelas deben conocer otra máscara además de la suya.
* Los nodos que tengan más de una interfaz (p.e. con otra red aparte) deben conocer la máscara real, pues tienen que saber qué interfaz usar en cada caso.
Por ejemplo, el ordenador A (128.6.4.2) quiere comunicarse con el B (128.6.3.12), pero no sabe que éste se encuentra en otra red, pues le engaña la máscara ficticia (255.255.0.0). Por tanto, en vez de buscar en la tabla de rutas la pasarela adecuado, envía un mensaje ARP: "¿podría el nodo 128.6.3.12 enviarme su dirección Ethernet?". Por supuesto, ese nodo nunca lo oirá, pues está en otra red. El único que lo sabe es la pasarela, que, al oír la pregunta, contesta haciéndose pasar por el destinatario: "Soy yo; mi dirección es 2:E0:0:CD:1". Esa dirección es en realidad la del propio gateway, que se encargará luego de reenviar el datagrama a su verdadero destino. Mientras tanto, el "engañado" nodo A dejará registrada en su tabla ARP la dirección de la pasarela como si fuese la del nodo B. A partir de ahora todo lo que mande allí pasará por la pasarela.
El efecto es el mismo que si el nodo ampliase su tabla de rutas. El control de rutado ha pasado a nivel de la tabla ARP. Los nodos que funcionan así se ven descargados del trabajo de mantener una tabla de rutas.
Los inconvenientes del Proxy ARP son principalmente dos:
* Solo se puede usar en instalaciones que usan ARP para la resolución de direcciones (normalmente las Ethernet).
* Tiene un agujero de seguridad, pues permite la técnica llamada spoofing, consistente en que un nodo indica ser otro para interceptar datagramas. El software de monitorización contra esta técnica no puede coexistir con el Proxy ARP, pues generaría alertas con gran frecuencia.
Direccionamiento de subred (subnetting)
Jon Postel, uno de los creadores de las subredes IP.
Esta técnica es una de las más extendidas, y se ha incluido como parte de los estándares TCP/IP.
Consiste en compartir una dirección de red tipo B entre varias redes, subdividiendo internamente el espacio como si fueran de tipo C. Esto se consigue subdividiendo la parte hostid de las direcciones tipo B de tal manera que parte de él identifique a las subredes.
Este cambio solo afecta ligeramente a la interpretación de las direcciones IP; es por ello que se ha extendido como un estándar.
Este tipo de direccionamiento jerárquico lleva también a un rutado jerárquico. El resto de Internet ve todo el conjunto como una sola red tipo B, sin fijarse en la subdivisión del campo hostid. De esta manera se cumple la norma de que el rutado desde el exterior no se debe ver afectado. Todo el tráfico externo se concentra en uno varios puntos desde donde se despacha según el campo de subred (segundo nivel de jerarquía).
Una gran ventaja de este tipo de direccionamiento es que la ruta no necesita saber muchos detalles sobre los destinos distantes. Un inconveniente es lo difícil que resulta cambiar a posteriori una jerarquía de este tipo ya establecida.
El algoritmo de rutado se ve modificado por el uso de direcciones de subred. El uso del rutado de subred ha de cumplir dos reglas:
1) Se debe usar el rutado de subred entre M y N, a no ser que exista un solo camino más corto entre M y cualquier red física que sea subred de N.
2) Todas las subredes bajo una misma dirección de red deben ser contiguas (estar conectadas físicamente entre ellas), las máscaras deben ser uniformes en todas ellas y todas las máquinas deben usar el rutado de subred.
En el algortimo estándar de rutado, se conoce siempre el formato de las direcciones, pues los primeros tres bits de cada dirección codifican el tipo de red (A, B, C o D). En el rutado de subred esto no es posible, por lo que es necesaria la presencia de un campo en las tablas de rutado con la máscara de subred. Por tanto, las tablas de rutas deben tener al menos tres campos: máscara, dirección de red y dirección de salto siguiente.
Una técnica totalmente diferente para evitar el agotamiento del espacio de direcciones es la llamada CIDR (Classless Inter-Domain Routing, rutado sin tipo entre dominios), donde se agrupan un conjunto de redes de tipo C contiguas en un registro de dos campos compuesto por la dirección más pequeña del grupo y un conteo del número de direcciones que lo componen.
P. ej. el registro {192.5.48.0, 3} identifica el grupo de direcciones 192.5.48.0, 192.5.49.0 y 192.5.50.0.
En la práctica, este sistema se modifica un poco, requiriendo que cada grupo de direcciones sea potencia de dos y usando una máscara de bits para identificar el tamaño del grupo, en lugar del conteo.
P. ej. el rango de direcciones entre 234.170.168.0 y 234.170.175.255 genera la máscara de bits 255.255.248.0, poniendo a 1 los bits que coinciden en todas las direcciones del grupo. Las pasarelas en las redes que usen este sistema han de tener un software de rutado especial para CIDR.
Publicado por Fórum Técnico en 20:54
Enviar por correo electrónicoEscribe un blogCompartir con TwitterCompartir con FacebookCompartir en Pinterest
Expresa tu opinión respetando a los demás y a unas mínimas reglas del lenguaje castellano.
Nota: solo los miembros de este blog pueden publicar comentarios.
Entrada más reciente Entrada antigua Inicio
Suscribirse a: Enviar comentarios (Atom)
TCP/IP Redes Programación Sistemas Software Libre Criptografía Matemáticas Pika Python RabbitMQ Seguridad Virtualización Bases de Datos Colas IPv6 Oracle VirtualBox Biografías Chrome Generación automática Google Historia Javascript Juegos Mapas Roma
TCP/IP (12): El deseado IPv6
TCP/IP (11): Agotamiento de direcciones IP
TCP/IP (10): Direccionamiento IP
Feedjit Live Blog Stats
© Fórum Técnico. Bajo licencia Creative Commons. Tema Sencillo. Imágenes del tema: enot-poloskun. Con la tecnología de Blogger.