Últimos Cambios
Blog personal: El hilo del laberinto
|
|
|
Últimos Cambios |
|
Blog personal: El hilo del laberinto
|
|
|
Última Actualización:
30 de Junio de 1.996 - Domingo
IP "next generation" ha sido el nombre con el que se ha bautizado a la versión seis del protocolo Internet (IP). Se trata de la definición de un nuevo protocolo de red destinado a sustituir a la actual versión IP, la cuatro.
¿Por qué se necesita un nuevo protocolo de red?. La respuesta es muy simple. Cuando IPv4 fue estandarizado, hace unos quince años, nadie podía imaginar que se convertiría en lo que es hoy: una arquitectura de amplitud mundial, con un número de usuarios superior al centenar de millones y que crece de forma exponencial. Aquella primera "Internet" fundada, sobre todo, con fines experimentales, científico-técnicos y, por supuesto, con objetivos militares, no se parece en nada a la actual. Cada día se advierte una mayor tendencia hacia su comercialización, ya sea por el propio acceso en sí a la red (empresas proveedoras) o por servicios accesibles desde ella.
Estos cambios de escala y orientación suponen varios problemas para IPv4 [RFC1287] [RFC1338] [RFC1917]:
Cada máquina presente en la red dispone de una dirección IP de 32 bits. Ello supone más de cuatro mil millones de máquinas diferentes. Esa cifra, no obstante, es muy engañosa. El número asignado a un ordenador no es arbitrario, sino que depende de una estructura más o menos jerárquica (en especial, pertenece a una red), lo cual ocasiona que se desperdicie una enorme cantidad de direcciones. La cuestión es que en 1.993 fue claro que con el ritmo de crecimiento sostenido de Internet hasta aquel momento (exponencial), el agotamiento del espacio de direcciones era casi inminente.
Otro de los grandes problemas del crecimiento de Internet es la capacidad de almacenamiento necesaria en la pasarelas (routers) y el tráfico de gestión preciso para mantener sus tablas de encaminamiento. Existe un límite tecnológico al número de rutas que un nodo puede manejar, y como dado que Internet crece mucho más rápidamente que la tecnología que la mantiene, se vió que las pasarelas pronto alcanzarían su capacidad máxima y empezarían a desechar rutas, con lo que la red comenzaría a fragmentarse en subredes sin acceso entre sí.
Dado lo grave de la situación se definió el CIDR (Classless Inter-Domain Routing) [RFC1481] [RFC1517..1519], con el que las pasarelas reducían el tamaño de sus tablas colapsando juntas varias subredes con el mismo prefijo. Gracias a ello se ha ganado un tiempo muy valioso, pero tan sólo se ha postergado lo inevitable.
En [RFC1797] y [RFC1879] se realiza el experimento de dividir una red A (la red 39) en multitud de pequeñas subredes. Los resultados fueron alentadores, por lo que dicha técnica podría utilizarse para ampliar de nuevo el tiempo de vida de IPv4.
Cada vez resulta más necesaria la convivencia de diversas familias de protocolos: IP, OSI, IPX... Se necesitan mecanismos que permitan abstraer al usuario de la tecnología subyacente para permitir que concentre su atención en los aspectos realmente importantes de su trabajo. Se tiende, pues, hacia una red orientada a aplicaciones, que es con lo que el usuario interacciona, más que a una red orientada a protocolos (como hasta el momento) [RFC1560].
El mundo IPv4 es el mundo académico, científico, técnico y de investigación. Un ambiente, en general, que podría calificarse como "amigable", desde el punto de vista de la gestión y la seguridad en la red. Con la aparición de servicios comerciales y la conexión de numerosísimas empresas, el enorme incremento en el número de usuarios y su distribución por todo el planeta, y la cantidad, cada vez mayor, de sistemas que necesitan de Internet para su correcto funcionamiento, etc., es urgente definir unos mecanismos de seguridad a nivel de red. Son necesarios esquemas de autentificación y privacidad, tanto para proteger a los usuarios en sí como la misma integridad de la red ante ataques malintencionados o errores [RFC1281] [RFC1636] [RFC1828..1829].
IPv4 define una red pura orientada a datagramas y, como tal, no existe el concepto de reserva de recursos. Cada datagrama debe competir con los demás y el tiempo de tránsito en la red es muy variable y sujeto a congestión. A pesar de que en la cabecera IP hay un campo destinado a fijar, entre otras cosas, la prioridad del datagrama [RFC1349] [RFC1455], en la práctica ello no supone ninguna garantía. Se necesita una extensión que posibilite el envío de tráfico de tiempo real, y así poder hacer frente a las nuevas demandas en este campo [RFC1667].
Con una red cada día más orientada hacia el mundo comercial hace falta dotar al sistema de mecanismos que posibiliten el análisis detallado del tráfico, tanto por motivos de facturación como para poder dimensionar los recursos de forma apropiada [RFC1272] [RFC1672].
El campo de las comunicaciones móviles está en auge, y aún lo estará más en un futuro inmediato. Se necesita una nueva arquitectura con mayor flexibilidad topológica, capaz de afrontar el reto que supone la movilidad de sus usuarios. La seguridad de las comunicaciones, en este tipo de sistemas, se ve, además, especialmente comprometida [RFC1674] [RFC1688].
Con el volumen actual de usuarios y su crecimiento estimado, resulta más que obvio que la gestión de la red va a ser una tarea ardua. Es preciso que la nueva arquitectura facilite al máximo esta tarea. Un ejemplo de ello sería la autoconfiguración de los equipos al conectarlos a la red [RFC1541].
Tradicionalmente los datagramas se han encaminado atendiendo a criterios técnicos tales como el minimizar el número de saltos a efectuar, el tiempo de permanencia en la red, etc. Cuando la red pertenece a una única organización eso es lo ideal, pero en el nuevo entorno económico en el que diferentes proveedores compiten por el mercado las cosas no son tan simples. Es imprescindible que la fuente pueda definir por qué redes desea que pasen sus datagramas, atendiendo a criterios de fiabilidad, coste, retardo, privacidad, etc. [RFC1674..1675].
A lo largo de los años se han propuesto varios protocolos como sustitutos al IPv4. Los tres más importantes han sido PIP ('P' Internet Protocol) [RFC1621] [RFC1622], TUBA (TCP/UDP With Bigger Addresses) [RFC1347] [RFC1526] y SIP/SIPP (Simple Internet Protocol/Simple Internet Protocol Plus) [RFC1710]. En [RFC1454] se realiza una buena comparativa entre ellos.
En 1.993 se decidió solicitar opiniones sobre "cómo debería ser" el IP del futuro (IPng) a través de [RFC1550]. Las respuestas recibidas fueron numerosas y provenientes de fuentes muy diversas. En general todas coincidían en los puntos básicos mencionados previamente. Tal vez los más interesantes hayan sido los que mostraban el punto de vista de varias multinacionales [RFC1669] [RFC1684].
Por fin se propuso un estándar en 1.995 [RFC1752], refinado a principios de 1.996 en [RFC1883]. Como puede verse se trata de un tema de máxima actualidad. De hecho todavía faltan por publicar, al menos, dos funciones adicionales: configuración dinámica y búsqueda de máquinas vecinas. Los datos de que dispongo son de finales de Abril de 1.996 así que es muy posible que ahora, Junio, se hayan publicado algunos documentos adicionales.
Las principales características del nuevo IPv6, como diferencias respecto a IPv4, son [RFC1883]:
Las nuevas direcciones IP, como ya se ha dicho, constan de 128 bits. Ello hace que la notación "punto" común de IPv4 sea poco práctica. IPv6 utiliza notación hexadecimal en grupos de 16 bits, separándolos por el carácter de dos puntos (":") [RFC1884]. En [RFC1920] se propone una codificación más compacta.
En [RFC1884] se realiza una asignación preliminar de direcciones, muy agresiva. Se reserva una enorme cantidad de valores para determinados grupos de direcciones (por ejemplo, multicasting, NSAP (OSI), etc.), pero aún así el espacio disponible para usos todavía no especificados es del 85%. Las propias direcciones IPv4 están incluidas aquí. Hay varias novedades interesantes, como el hecho de definir direcciones especificamente locales a nivel de capa de enlace (MAC) u organización.
En definitiva, el IPv6 ya está aquí. Todavía queda un largo trecho
hasta que se implante de forma mayoritaria, pero sin duda
incorpora numerosas características que lo hacen atractivo, como
el soporte de comunicaciones en tiempo real, la autoconfiguración
de sistemas, seguridad, etc. La mayoría de los detalles todavía se
están ultimando y, hasta donde sabe el autor, no se han propuesto
aún plazos de implantación.
Bibliografía
[RFC791] RFC 791: "Internet Protocol"
Jon Postel
Septiembre 1.981
[RFC792] RFC 792: "Internet Control Message Protocol"
Jon Postel
Septiembre 1.981
[RFC801] RFC801: "NCP/TCP TRANSITION PLAN"
Jon Postel
Noviembre 1.981
[RFC907] RFC907: "INTERNET SUBNETS"
Jeffrey Mogul
Octubre 1.984
[RFC919] RFC919: "BROADCASTING INTERNET DATAGRAMS"
Jeffrey Mogul
Octubre 1.994
[RFC922] RFC922: "BROADCASTING INTERNET DATAGRAMS IN THE
PRESENCE OF SUBNETS"
Jeffrey Mogul
Octubre 1.984
[RFC925] RFC925: "Multi-LAN Address Resolution"
Jon Postel
Octubre 1.984
[RFC932] RFC932: "A SUBNETWORK ADDRESSING SCHEME"
David D. Clark
Enero 1.985
[RFC936] RFC936: "Another Internet Subnet Addressing Scheme"
Michael J. Karels
Febrero 1.985
[RFC940] RFC940: "Toward an Internet Standard Scheme for
Subnetting"
Gateway Algorithms and Data Structures (GADS) Task
Force
Abril 1.985
[RFC947] RFC947: "Multi-network Broadcasting within the
Internet"
Ken Lebowitz
David Mankins
Junio 1.985
[RFC950] RFC950: "Internet Standard Subnetting Procedure"
J. Mogul
Jon Postel
Agosto 1.985
[RFC966] RFC966: "Host Groups: A Multicast Extension to the
Internet Protocol"
S. E. Deering
D. R. Cheriton
Diciembre 1.985
[RFC988] RFC988: "Host Extensions for IP Multicasting"
S. E. Deering
Julio 1.986
[RFC1108] RFC1108: "U.S. Department of Defense Security Options
for the Internet Protocol"
Stephen Kent
Noviembre 1.991
[RFC1112] RFC1112: "Host Extensions for IP Multicasting"
Steve Deering
Agosto 1.989
[RFC1191] RFC1191: "Path MTU Discovery"
Jeffrey Mogul
Steve Deering
Noviembre 1.990
[RFC1234] RFC1234: "Tunneling IPX Traffic through IP Networks"
Don Provan
Junio 1.991
[RFC1241] RFC1241: "A Scheme for an Internet Encapsulation
Protocol: Version 1"
Robert A. Woodburn
David L. Mills
Julio 1.991
[RFC1272] RFC1272: "INTERNET ACCOUNTING: BACKGROUND"
Cyndi Mills
Donald Hirsh
Gregory Ruth
Noviembre 1.991
[RFC1281] RFC1281: "Guidelines for the Secure Operation of the
Internet"
Richard D. Pethia
Stephen D. Crocker
Barbara Y. Fraser
Noviembre 1.991
[RFC1287] RFC1287: "Towards the Future Internet Architecture"
David D. Clark
Vinton G. Cerf
Lyman A. Chapin
Robert Braden
Russell Hobby
Diciembre 1.991
[RFC1335] RFC1335: "A Two-Tier Address Structure for the
Internet: A Solution to the Problem of Address Space
Exhaustion"
Zheng Wang
Jon Crowcroft
Mayo 1.992
[RFC1338] RFC1338: "Supernetting: an Address Assignment and
Aggregation Strategy"
Vince Fuller
Tony Li
Jessica (Jie Yun) Yu
Kannan Varadhan
Junio 1.992
[RFC1347] RFC1347: "TCP and UDP with Bigger Addresses (TUBA), A
Simple Proposal for Internet Addressing and Routing"
Ross Callon
Junio 1.992
[RFC1349] RFC1349: "Type of Service in the Internet Protocol
Suite"
Philip Almquist
Julio 1.992
[RFC1380] RFC1380: "IESG Deliberations on Routing and
Addressing"
Phillip Gross
Philip Almquist
Noviembre 1.992
[RFC1393] RFC1393: "Traceroute Using an IP Option"
Gary Scott Malkin
Enero 1.993
[RFC1435] RFC1435: "IESG Advice from Experience with Path MTU
Discovery"
Stev Knowles
Marzo 1.993
[RFC1454] RFC1454: "Comparison of Proposals for Next Version of
IP"
Tim Dixon
Mayo 1.993
[RFC1455] RFC1455: "Physical Link Security Type of Service"
Donald E. Eastlake, III
Mayo 1.993
[RFC1466] RFC1466: "Guidelines for Management of IP Address
Space"
Elise Gerich
Mayo 1.993
[RFC1467] RFC1467: "Status of CIDR Deployment in the Internet"
Claudio Topolcic
Agosto 1.993
[RFC1475] RFC1475: "TP/IX: The Next Internet"
Robert Ullmann
Junio 1.993
[RFC1481] RFC1481: "IAB Recommendation for an Intermediate
Strategy to Address the Issue of Scaling"
Christian Huitema
Julio 1.993
[RFC1517] RFC1517: "Applicability Statement for the
Implementation of Classless Inter-Domain Routing
(CIDR)"
Robert M. Hinden
Septiembre 1.993
[RFC1518] RFC1518: "An Architecture for IP Address Allocation
with CIDR"
Yakov Rekhter
Tony Li
Septiembre 1.993
[RFC1519] RFC1519: "Classless Inter-Domain Routing (CIDR): an
Address Assignment and Aggregation Strategy"
Vince Fuller
Tony Li
Septiembre 1.993
[RFC1520] RFC1520: "Exchanging Routing Information Across
Provider Boundaries in the CIDR Environment"
Yakov Rekhter
Claudio Topolcic
Septiembre 1.993
[RFC1526] RFC1526: "Assignment of System Identifiers for
TUBA/CLNP Hosts"
David M. Piscitello
Septiembre 1.993
[RFC1541] RFC1541: "Dynamic Host Configuration Protocol"
R. Droms
Octubre 1993
[RFC1546] RFC1546: "Host Anycasting Service"
Walter Milliken
Trevor Mendez
Craig Partridge
Noviembre 1.993
[RFC1550] RFC1550: "IP: Next Generation (IPng) White Paper
Solicitation"
Scott Bradner
Allison Mankin
Diciembre 1.993
[RFC1560] RFC1560: "The MultiProtocol Internet"
Dr. Barry M. Leiner
Yakov Rekhter
Diciembre 1.993
[RFC1597] RFC1597: "Address Allocation for Private Internets"
Yakov Rekhter
Robert G Moskowitz
Daniel Karrenberg
Geert Jan de Groot
Marzo 1.994
[RFC1621] RFC1621: "Pip Near-term Architecture"
Paul Francis
Mayo 1.994
[RFC1622] RFC1622: "Pip Header Processing"
Paul Francis
Mayo 1.994
[RFC1636] RFC1636: "Report of IAB Workshop on Security in the
Internet Architecture. February 8-10, 1994"
Bob Braden
David Clark
Steve Crocker
Christian Huitema
Junio 1.994
[RFC1639] RFC1639: "FTP Operation Over Big Address Records
(FOOBAR)"
David M. Piscitello
Junio 1.994
[RFC1667] RFC1667: "Modeling and Simulation Requirements for
IPng"
Susan Symington
David Wood
J. Mark Pullen
Agosto 1.994
[RFC1668] RFC1668: "Unified Routing Requirements for IPng"
Deborah Estrin
Tony Li
Yakov Rekhter
Agosto 1.994
[RFC1669] RFC1669: "Market Viability as a IPng Criteria"
John Curran
Agosto 1.994
[RFC1670] RFC1670: "Input to IPng Engineering Considerations"
Denise Heagerty
Agosto 1.994
[RFC1671] RFC1671: "IPng White Paper on Transition and Other
Considerations"
Brian E. Carpenter
Agosto 1.994
[RFC1672] RFC1672: "Accounting Requirements for IPng"
Nevil Brownlee
Agosto 1.994
[RFC1673] RFC1673: "Electric Power Research Institute Comments
on IPng"
Ron Skelton
Agosto 1.994
[RFC1674] RFC1674: "A Cellular Industry View of IPng"
Mark S. Taylor
Agosto 1.994
[RFC1675] RFC1675: "Security Concerns for IPng"
Steven M. Bellovin
Agosto 1.994
[RFC1676] RFC1676: "INFN Requirements for an IPng"
Davide Salomoni
Cristina Vistoli
Antonia Ghiselli
Agosto 1.994
[RFC1677] RFC1677: "Tactical Radio Frequency Communication
Requirments for IPng"
R. Brian Adamson
Agosto 1.994
[RFC1678] RFC1678: "IPng Requirements of Large Corporate
Networks"
Edward Britton
John Tavs
Agosto 1.994
[RFC1679] RFC1679: "HPN Working Group Input to the IPng
Requirements Solicitation"
Dan Green
Phil Irey
Dave Marlow
Karen O'Donoghue
Agosto 1.994
[RFC1680] RFC1680: "IPng Support for ATM Services"
Christina Brazdziunas
Agosto 1.994
[RFC1681] RFC1681: "On Many Addresses per Host"
Steven M. Bellovin
Agosto 1.994
[RFC1682] RFC1682: "IPng BSD Host Implementation Analysis"
Jim Bound
Agosto 1.994
[RFC1683] RFC1683: "Multiprotocol Interoperability In IPng"
Russell J. Clark
Mostafa H. Ammar
Kenneth L. Calvert
Agosto 1.994
[RFC1686] RFC1686: "IPng Requirements: A Cable Television
Industry Viewpoint"
Mario P. Vecchi
Agosto 1.994
[RFC1687] RFC1687: "A Large Corporate User's View of IPng"
Eric Fleischman
Agosto 1.994
[RFC1688] RFC1688: "IPng Mobility Considerations"
William Allen Simpson
Agosto 1.994
[RFC1701] RFC1701: "Generic Routing Encapsulation (GRE)"
Stan Hanks
Tony Li
Dino Farinacci
Paul Traina
Octubre 1.994
[RFC1705] RFC1705: "Six Virtual Inches to the Left: The Problem
with IPng"
Richard Carlson
Domenic Ficarella
Octubre 1.994
[RFC1707] RFC1707: "CATNIP: Common Architecture for the
Internet"
Michael McGovern
Robert Ullmann
Octubre 1.994
[RFC1710] RFC1710: "Simple Internet Protocol Plus White Paper"
Robert M. Hinden
Octubre 1.994
[RFC1719] RFC1719: "A Direction for IPng"
Phill Gross
Diciembre 1.994
[RFC1726] RFC1726: "Technical Criteria for Choosing IP The Next
Generation (IPng)"
Craig Partridge
Frank Kastenholz
Diciembre 1.994
[RFC1750] RFC1750: "Randomness Recommendations for Security"
Donald E. Eastlake 3rd
Stephen D. Crocker
Jeffrey I. Schiller
Diciembre 1.994
[RFC1752] RFC1752: "The Recommendation for the IP Next
Generation Protocol"
Scott Bradner
Allison Mankin
Enero 1.995
[RFC1753] RFC1753: "IPng Technical Requirements Of the Nimrod
Routing and Addressing Architecture"
J. Noel Chiappa
Enero 1.995
[RFC1797] RFC1797: "Class A Subnet Experiment"
Internet Assigned Numbers Authority (IANA)
Abril 1.995
[RFC1809] RFC1809: "Using the Flow Label Field in IPv6"
Craig Partridge
Junio 1.995
[RFC1817] RFC1817: "CIDR and Classful Routing"
Yakov Rekhter
Agosto 1.995
[RFC1825] RFC1825: "Security Architecture for the Internet
Protocol"
Randall Atkinson
Agosto 1.995
[RFC1826] RFC1826: "IP Authentication Header"
Randall Atkinson
Agosto 1.995
[RFC1827] RFC1827: "IP Encapsulating Security Payload (ESP)"
Randall Atkinson
Agosto 1.995
[RFC1828] RFC1828: "IP Authentication using Keyed MD5"
Perry Metzger
William Allen Simpson
Agosto 1.995
[RFC1829] RFC1829: "The ESP DES-CBC Transform"
Perry Metzger
William Allen Simpson
Agosto 1.995
[RFC1852] RFC1852: "IP Authentication using Keyed SHA"
Perry Metzger
William Allen Simpson
Septiembre 1.995
[RFC1853] RFC1853: "IP in IP Tunneling"
William Allen Simpson
Octubre 1.995
[RFC1878] RFC1878: "Variable Length Subnet Table For IPv4"
Troy T. Pummill
Bill Manning
Diciembre 1.995
[RFC1879] RFC1879: "Class A Subnet Experiment Results and
Recommendations"
Bill Manning
Enero 1.996
[RFC1881] RFC1881: "IPv6 Address Allocation Management"
Internet Architecture Board
Internet Engineering Steering Group
Diciembre 1.995
[RFC1883] RFC1883: "Internet Protocol, Version 6 (IPv6)
Specification"
Stephen E. Deering
Robert M. Hinden
Diciembre 1.995
[RFC1884] RFC1884: "IP Version 6 Addressing Architecture"
Robert M. Hinden
Stephen E. Deering
Diciembre 1.995
[RFC1885] RFC1885: "Internet Control Message Protocol (ICMPv6)
for the Internet Protocol Version 6 (IPv6)
Specification"
Stephen Deering
Alex Conta
Diciembre 1.995
[RFC1886] RFC1886: "DNS Extensions to support IP version 6"
Susan Thomson
Christian Huitema
Diciembre 1.995
[RFC1887] RFC1887: "An Architecture for IPv6 Unicast Address
Allocation"
Yakov Rekhter
Tony Li
Diciembre 1.995
[RFC1897] RFC1897: "IPv6 Testing Address Allocation"
Robert M. Hinden
Jon Postel
Enero 1.996
[RFC1917] RFC1917: "An Appeal to the Internet Community to
Return Unused IP Networks (Prefixes) to the IANA"
Philip J. Nesser II
Febrero 1.996
[RFC1924] RFC1924: "A Compact Representation of IPv6 Addresses"
Robert Elz
Abril 1.996
[RFC1933] RFC1933: "Transition Mechanisms for IPv6 Hosts and
Routers"
Robert E. Gilligan
Erik Nordmark
Abril 1.996
Más información sobre los OpenBadges
Donación BitCoin: 19niBN42ac2pqDQFx6GJZxry2JQSFvwAfS
