Cidr

Supernetting and Classless Interdomain Routing

With the recent growth of the Internet, it became clear to the Internet authorities that the class B network IDs would soon be depleted. For most organizations, a class C network ID does not contain enough host IDs and a class B network ID has enough bits to provide a flexible subnetting scheme within the organization. The Internet authorities devised a new method of assigning network IDs to prevent the depletion of class B network IDs. Rather than assigning a class B network ID, InterNIC assigns a range of class C network IDs that contain enough network and host IDs for the organization's needs. This is known as supernetting . For example, rather than allocating a class B network ID to an organization that has up to 2,000 hosts, the InterNIC allocates a range of eight class C network IDs. Each class C network ID accommodates 254 hosts, for a total of 2,032 host IDs. Although this technique helps conserve class B network IDs, it creates a new problem. Using conventional routing techniques, the routers on the Internet now must have eight class C network ID entries in their routing tables to route IP packets to the organization. To prevent Internet routers from becoming overwhelmed with routes, a technique calledClassless Interdomain Routing (CIDR) is used to collapse multiple network ID entries into a single entry corresponding to all of the class C network IDs allocated to that organization. Conceptually, CIDR creates the routing table entry: [Starting Network ID, count], where Starting Network ID is the first class C network ID and the count is the number of class C network IDs allocated. In practice, a supernetted subnet mask is used to convey the same information. To express the situation where eight class C network IDs are allocated starting with network ID [Link]: Starting Network ID Ending Network ID [Link] [Link] 11011100 01001110 10101 000 00000000 11011100 01001110 10101 111 00000000

Note that the first 21 bits (underlined) of all the above Class C network IDs are the same. The last three bits of the third octet vary from 000 to 111. The CIDR entry in the routing tables of the Internet routers becomes: Network ID [Link] Subnet Mask [Link] Subnet Mask (binary) 11111111 11111111 11111000 0000000

In network prefix or CIDR notation, the CIDR entry is [Link]/21. A block of addresses using CIDR is known as a CIDR block .

Note Because subnet masks are used to express the count, class-based network IDs must be allocated in groups corresponding to powers of 2. In order to support CIDR, routers must be able to exchange routing information in the form of [Network ID, Network Mask] pairs. RIP for IP version 2, OSPF and BGPv4 are routing protocols that support CIDR. RIP for IP version 1 does not support CIDR.

Address Space Perspective

The use of CIDR to allocate addresses promotes a new perspective on IP network IDs. In the above example, the CIDR block [[Link], [Link]] can be thought of in two ways:

A block of eight class C network IDs. An address space in which 21 bits are fixed and 11 bits are assignable.

In the latter perspective, IP network IDs lose their class-based heritage and become separate IP address spaces, subsets of the original IP address space defined by the 32-bit IP address. Each IP network ID (class-based, subnetted, CIDR block), is an address space in which certain bits are fixed (the network ID bits) and certain bits are variable (the host bits). The host bits are assignable as host IDs or, using subnetting techniques, can be used in whatever manner best suits the needs of the organization.

Fuller & Li Mejores Prcticas actuales [Pgina 2]

RFC 4632 CIDR Direccin estrategia de agosto 2006

1 . Introduccin

Esta nota se analiza la estrategia para abordar la cesin de la existentes de 32-bit del espacio de direcciones IPv4, con miras a la conservacin espacio de direcciones y la limitacin de la tasa de crecimiento de enrutamiento de estado global. En este documento se vuelve obsoleta la especificacin original CIDR [ RFC1519 ], con los cambios realizados tanto para aclarar los conceptos que introdujo y, despus de ms de doce aos, para actualizar la comunidad de Internet en el resultados de la implementacin de la tecnologa descrita.

2 . Historia y Descripcin del problema

Lo que hoy conocemos como Internet empez como un proyecto de investigacin en la dcada de 1970 para disear y desarrollar un conjunto de protocolos que podran ser utilizados con muchas diferentes tecnologas de red para proporcionar un final sin problemas, a fin de instalacin para la interconexin de un conjunto diverso de sistemas finales. Cuando se determin la forma del espacio de direcciones de 32 bits se utilizan, Se tomaron varios supuestos sobre el nmero de organizaciones que se conectados, el nmero de sistemas de final por la organizacin, y el total de nmero de sistemas de servidor en la red. El resultado final fue la establecimiento (ver [ RFC791 ]) de las tres clases de redes: Clase A (Ms significativo bits de la direccin '00 '), con 128 posibles redes de cada 16777216 y los sistemas de extremo (menos los valores de bit especiales reservadas a los red / direcciones de difusin), Clase B (MSB '10 '), con posibles 16384 las redes de cada uno con 65.536 sistemas finales (los valores menos reservado), y Clase C (MSB '110 '), y 2.097.152 redes posibles y al final de cada 254

sistemas (256 combinaciones de bits menos los ceros de todos los reservados y todos los los patrones). El conjunto de direcciones con el MSB '111 'se reserv para uso en el futuro, las partes de este se define el tiempo (MSB '1110 ') para utilizar con IPv4 multicast y partes todava estn reservados a partir de la redaccin de este documento.

A finales de 1980, la expansin y la comercializacin de la antigua red de investigacin dio lugar a la conexin de muchas nuevas organizaciones a Internet en rpido crecimiento, y cada nueva organizacin requiere una asignacin de direccin de acuerdo con la clase A / B / C plan de direccionamiento. Como la demanda de nmeros de red (sobre todo en el espacio de la Clase B) tom lo que pareca ser una tasa de crecimiento exponencial, algunos miembros de las operaciones y la comunidad de ingenieros comenz a tener problemas sobre las propiedades de escala a largo plazo de la clase A / B / C y del sistema comenz a pensar acerca de cmo modificar el nmero de red poltica de asignacin de y los protocolos de enrutamiento para acomodar el crecimiento. En noviembre de 1991, la Internet Engineering Task Force (IETF) cre el ROAD (Routing y direccionamiento) del grupo para examinar la situacin. Este grupo se reuni en Enero de 1992 y se identificaron tres problemas principales:

Fuller & Li Mejores Prcticas actuales [Pgina 3]

RFC 4632 CIDR Direccin estrategia de agosto 2006

1. Agotamiento del espacio de direccin de red Clase B. Fundamental de un causa de este problema es la falta de una clase de red de un tamao que sea apropiado para la mediana empresa. Clase C, con una mximo de 254 direcciones de host, es demasiado pequeo, mientras que la Clase B, que permite hasta 65.534 direcciones de host, es demasiado grande para la mayora de organizaciones, sino que era la mejor opcin disponible para su uso con

subredes.

2. Crecimiento de las tablas de enrutamiento en los routers de Internet ms all de la capacidad de software actual, hardware, y las personas a gestionar de forma eficaz.

3. Eventual agotamiento del espacio de direcciones IPv4 de 32 bits.

Estaba claro que en ese momento las tasas de crecimiento de Internet se causa de los dos primeros problemas para convertirse en crtico en algn momento entre 1993 y 1995. Trabajo en curso sobre topolgica asignacin de direccionamiento para el servicio de red sin conexin (CLNS), que fue presentado a la comunidad en la IETF Boulder en diciembre de 1990, dio lugar a reflexiones sobre cmo volver a la estructura de la De 32 bits de direcciones IPv4 para aumentar su vida til. El trabajo en el CARRETERA grupo sigui y dio lugar finalmente a la publicacin de [ RFC1338 ], y ms tarde, [ RFC1519 ].

El diseo y el despliegue de CIDR fue pensado para resolver estos problemas al proporcionar un mecanismo para reducir el crecimiento global las tablas de enrutamiento y para reducir la tasa de consumo de las direcciones IPv4 espacio de direcciones. No y no tratar de resolver el El tercer problema, que es de naturaleza ms largo plazo, sino que esfuerzos para facilitar suficiente a corto y medio plazo las dificultades para permitir que Internet siga funcionando de manera eficiente, mientras que se avanza en una solucin a largo plazo.

Ms de fondo histrico en este esfuerzo y en el grupo ROAD se puede encontrar en [ RFC1380 ] y en [ LWRD ].

3 . Abordar sin clases como una solucin

La solucin que la comunidad se cre para desaprobar la clase A / B / C de direcciones de red del sistema de asignacin en favor del uso de "Sin clases", bloques jerrquicos de las direcciones IP (en adelante, prefijos). La asignacin de prefijos es la intencin de seguir ms o menos la topologa de Internet subyacente de manera que la agregacin se puede utilizar para

facilitar la ampliacin del sistema global de rutas. Una de las consecuencias de esta estrategia es que la asignacin de prefijos y de agregacin es por lo general realiza de acuerdo con las relaciones de abonados del proveedor, ya que es cmo la topologa de Internet se determina.

Fuller & Li Mejores Prcticas actuales [Pgina 4]

RFC 4632 CIDR Direccin estrategia de agosto 2006

Cuando se propuso originalmente en [ RFC1338 ] y [ RFC1519 ], frente a este el plan estaba destinado a ser una respuesta relativamente a corto plazo, con una duracin aproximadamente de tres a cinco aos, durante el cual un carcter ms permanente direccionamiento y enrutamiento de la arquitectura se dise y implementado. Como se puede inferir a partir de la fecha en el original documentos, CIDR ha sobrevivido a mucho de su vida til prevista, y ha convertido en la solucin a medio plazo para los problemas descritos anteriormente.

Tenga en cuenta que en el siguiente texto se describen las polticas actuales y procedimientos que se han puesto en marcha para implementar la asignacin arquitectura discutido aqu. Esta descripcin no pretende ser interpretado como la direccin de IANA.

Junto con las estrategias de gestin implementadas por la direccin Registros Regionales de Internet (ver [ NRO ] para ms detalles), el despliegue de hacer frente a CIDR-estilo tambin ha reducido la velocidad a la que IPv4 espacio de direcciones se ha consumido, proporcionando as a corto y mediano plazo alivio al problema # 3, se ha descrito anteriormente.

Tenga en cuenta que, tal como se define, este plan no requiere ni supone el reasignacin de las partes de la herencia "Clase C", espacio que se no susceptibles de agregacin (a veces llamado "el pantano"). Si lo hace,

algo que reducira de enrutamiento tamao de la mesa (la estimacin actual es que "El pantano", contiene aproximadamente 15.000 entradas), aunque a un significativos en los costos de renumeracin. Del mismo modo, no hay duros requisito de que cualquier sitio de numeracin final cuando se cambia el servicio de trnsito los sitios del proveedor, pero al final se anima hacerlo para eliminar la necesidad para el anuncio explcito de sus prefijos en el global de enrutamiento del sistema.

3.1 . Concepto bsico y notacin de prefijo

En el sentido ms simple, el cambio de la clase A / B / C para los nmeros de red prefijos sin clases es hacer explcito que los bits en IPv4 de 32 bits la direccin se interpreta como el nmero de red (o prefijo) asociados con un sitio y que son los utilizados para los sistemas de numeracin final individual dentro del sitio. En la notacin CIDR, un prefijo se muestra como una de 4 octetos cantidad, al igual que la tradicional direccin IPv4 o el nmero de red, seguido por el "/" (barra) de carcter, seguido por un valor decimal entre 0 y 32 que describe el nmero de bits significativos.

Fuller & Li Mejores Prcticas actuales [Pgina 5]

RFC 4632 CIDR Direccin estrategia de agosto 2006

Por ejemplo, el legado de "Clase B" de la red [Link], con una implcita mscara de red [Link], se define como el prefijo [Link]/16,

el "/ 16", indicando que la mscara para extraer la parte de la red de el prefijo es un valor de 32 bits donde los 16 bits ms significativos son las y los 16 bits menos significativos son ceros. Del mismo modo, el legado "Clase C" nmero de red [Link] se define como el prefijo [Link]/24, los ms significativos son los de 24 bits y los menos importantes de 8 bits son ceros.

Utilizar los prefijos de clases con longitudes de prefijo explcito permite mucho juego ms flexible de bloques de espacio de direcciones de acuerdo a la actual necesitan. Donde antes slo tres tamaos de red disponibles, prefijos se puede definir para describir cualquier potencia de dos del tamao de bloque de entre uno y 2 ^ 32 direcciones del sistema final. En la prctica, la Piscina sin asignar direcciones es administrado por el Internet Assigned Numbers Authority ([ IANA ]). La IANA asignaciones este grupo a los Registros Regionales de Internet, segn sea necesario. Estos las asignaciones se hacen en el contiguo bloques alineados bits de 2 ^ 24 direcciones (aka / 8 prefijos). Los Registros Regionales de Internet (RIR), a su vez, asignar o asignar bloques ms pequeos frente a locales Registros de Internet (LIR) o Internet Service Providers (ISPs). Estas entidades podrn hacer uso directo de la asignacin (al igual que comnmente es el caso de un ISP) o puede hacer ms sub-asignaciones de las direcciones de sus clientes. Estas asignaciones de direcciones varan RIR de acuerdo a las necesidades de cada ISP o LIR. Por ejemplo, un gran proveedor de Internet podra ser asignado un bloque de direcciones de 2 ^ 17 direcciones (a / 15 prefijo), mientras que un pequeo ISP puede asignar un bloque de direcciones de 2 ^ 11 direcciones (a / 21 prefijo).

Tenga en cuenta que los trminos "asignar" y "asignar" tienen un significado especfico en la direccin de Internet del Registro del sistema, "asignar" se refiere a la delegacin de un bloque de espacio de direcciones a una organizacin que se espera llevar a cabo nuevas sub-delegaciones, y "asignar" se utiliza para sitios que utilizan directamente (es decir, los ejrcitos nmero individual), el bloque de direcciones recibidas.

La siguiente tabla proporciona un atajo conveniente para todos los CIDR de tamaos de prefijos, que muestra el nmero de direcciones posibles en cada prefijo

y el nmero de prefijos de ese tamao que pueden ser numeradas en el De 32 bits de direcciones IPv4:

Fuller & Li Mejores Prcticas actuales [Pgina 6] RFC 4632 CIDR Direccin estrategia agosto 2006 addrs notacin / bloque # bloques -------- ---------- ---------- nnnn/32 1 4294967296 "ruta de host "nnnx/31 2 2147483648" enlace p2p "nnnx/30 4 1073741824 nnnx/29 8 536 870 912 268 435 456 16 nnnx/28 nnnx/27 32 134217728 nnnx/26 64 67108864 nnnx/25 128 33554432 256 16777216 nnn0/24 legado" Clase C " nnx0/23 512 8388608 nnx0/22 1024 4.194.304 2048 2.097.152 nnx0/21 nnx0/20 4096 1048576 nnx0/19 8192 524.288 16.384 262.144 nnx0/18 nnx0/17 32.768 131.072 65.536 65.536 nn0.0/16 legado "Clase B" nx0.0 / 15 131072 32768 262144 16384 nx0.0/14 nx0.0/13 524.288 8192 1.048.576 4096 nx0.0/12 nx0.0/11 2.097.152 2048 4.194.304 1024 nx0.0/10 nx0.0 / 9 8388608 512 n.0.0. 0 / 8 256 16777216 legado de "Clase A" x.0.0.0 / 7 33554432 128 x.0.0.0 / 6 67108864 64 x.0.0.0 / 5 134 217 728 32 x.0.0.0 / 4 268 435 456 16 x.0.0. 0 / 3 536 870 912 8 x.0.0.0 / 2 1073741824 x.0.0.0 4 / 1 2147483648 2 [Link] / 0 4294967296 1 "ruta por defecto" n es un valor decimal de 8 bits octeto. Punto-a-punto se analizan con ms detalle en [ RFC3021 ]. x es un 1 - a un valor de 7-bit, basado en la longitud del prefijo, cambi a los bits ms significativos del octeto y se convierte en forma decimal, los bits menos significativos del octeto son cero Fuller & Li Mejores Prcticas actuales [Pgina. 7]

RFC 4632 CIDR Direccin estrategia de agosto 2006

En la prctica, los prefijos de longitud inferior a 8 no han sido asignado o asignado hasta la fecha, aunque las rutas de tales prefijos cortos pueden existir en las tablas de enrutamiento si o cuando la agregacin agresivo realizado. A partir de la redaccin de este documento, no esas rutas son visto en el sistema global de rutas, pero errores de los operadores y otros acontecimientos han hecho que algunos de ellos (es decir, [Link] / 1 y [Link] / 2) que se observa en algunas redes en algunas ocasiones en el pasado.

4 . Asignacin de direcciones y enrutamiento de agregacin

Direccionamiento y enrutamiento sin clases fue inicialmente desarrollado principalmente para mejorar las propiedades de escalamiento de enrutamiento de la Internet global. Debido a la ampliacin de la ruta es muy estrechamente unida a la forma que se usan las direcciones, el despliegue de CIDR tiene consecuencias para la forma en que las direcciones se les asign.

4.1 . Agregacin de eficacia y limitaciones

El nico mtodo que se entiende comnmente para reducir el estado de enrutamiento en un de conmutacin de paquetes de red mediante la agregacin de informacin. Para CIDR para tener xito en la reduccin del tamao y la tasa de crecimiento del mundo sistema de enrutamiento, el proceso de asignacin de direcciones IPv4 necesario cambiado para hacer posible la agregacin de informacin de enrutamiento a lo largo de lneas topolgicas. Dado que, en general, la topologa de la red es determinado por los proveedores de servicios que lo han construido, topolgicamente asignaciones significativas direccin son necesariamente proveedor de servicios de orientado.

La agregacin es sencillo para un sitio de extremo que se conecta a un proveedor de servicios: se utiliza el espacio de direcciones asignado por su servicio proveedor, y que el espacio de direcciones es una pequea pieza de un bloque asignada al proveedor de servicios. No hay una ruta explcita es necesaria para el sitio final, el proveedor de servicios de publicidad de un solo agregado ruta para el bloque ms grande. Este anuncio ofrece accesibilidad ruteabilidad y para todos los clientes numerados en el bloque.

Hay dos, ms complejos, situaciones que reducen la eficacia de agregacin:

o Una organizacin que es multi-homed. Debido a que una multitarjeta organizacin debe ser objeto de publicidad en el sistema por cada uno de sus proveedores de servicios, a menudo no es factible agregar sus informacin de enrutamiento en el espacio de direcciones de cualquiera de los proveedores. Tenga en cuenta que la organizacin todava puede recibir su asignacin de direcciones de espacio de direcciones del proveedor de servicios (Que tiene otras ventajas), pero que una ruta a la

prefijo de la organizacin es, en el caso ms general, de forma explcita anunciado por todos sus proveedores de servicio. Por esta razn, la

Prctica Fuller & Li Mejores Actual [Pgina 8]

RFC 4632 CIDR Direccin estrategia de agosto 2006

coste global de enrutamiento de una organizacin multi-homed es en general la misma que antes de la adopcin de CIDR. Un anlisis ms detallado consideracin de multi-homing prcticas se pueden encontrar en [ RFC4116 ].

o Una organizacin que cambia el proveedor de servicios, pero no numerar. Esto tiene el efecto de "la perforacin de un agujero" en uno de los anuncios agregados proveedor de servicios de la ruta original. CIDR controla esta situacin, al exigir que el servicio ms reciente proveedor para anunciar un anuncio especfico para la re-homed organizacin, este anuncio es preferible a proveedor agregados, ya que es un partido ms. Para mantener la eficiencia de agregacin, se recomienda que una organizacin que cambia de proveedor de servicio del plan con el tiempo para migrar su red en el prefijo asignado un espacio de direcciones de su proveedor de nuevo. Con este fin, se recomienda que los mecanismos para facilitar dicha la migracin, tales como la asignacin dinmica de direcciones de host que utiliza [ RFC2131 ]), se desplegar siempre que sea posible, y que otros protocolo de trabajo por hacer para desarrollar una mejor tecnologa para renumeracin.

Tenga en cuenta que algunos de agregacin ganancia de eficiencia an se puede tener para multi-homed sitios (y, en general, para cualquier sitio compone de mltiples, las redes IPv4 lgica), mediante la asignacin de un Estado palestino contiguo de energa de dos bloques del espacio de direcciones en el sitio (a diferencia de varios, prefijos independientes), la informacin de enrutamiento del sitio puede ser agrupados en un nico prefijo. Adems, dado que el costo de enrutamiento

asociados con la asignacin de un sitio multihomed de un servicio el espacio de direcciones del proveedor no es mayor que el viejo mtodo de asignacin de nmeros secuenciales por una autoridad central, tiene sentido para asignar espacio de direcciones de todas las finales in situ de los bloques asignados a proveedores de servicios.

Tambin vale la pena mencionar que desde que la agregacin puede ocurrir en mltiples niveles en el sistema, todava puede ser posible agregar estas vas anmalas en los niveles superiores de cualquier jerarqua puede ser presentes. Por ejemplo, si un sitio es multi-homed a dos relativamente los pequeos proveedores que ambos obtienen la conectividad y el espacio de direcciones de el mismo proveedor grande, entonces la agregacin por el gran proveedor de las rutas de las redes ms pequeas se incluyen todas las rutas a la multitarjeta sitio. La viabilidad de este tipo de segundo nivel agregacin depende de si la jerarqua topolgica existe entre un sitio, de sus proveedores directamente relacionados y otros proveedores a los que estn conectados, ya que puede ser prctico en algunas regiones del mundo Internet pero no en otros.

Fuller & Li Mejores Prcticas actuales [Pgina 9]

RFC 4632 CIDR Direccin estrategia de agosto 2006

Nota: En la discusin y los ejemplos que siguen, la notacin de prefijo es utiliza para representar los destinos de enrutamiento. Esto se utiliza para ilustracin y no requiere que los protocolos de enrutamiento utilizan esta representacin en sus actualizaciones.

4.2 . Asignacin distribuida de espacio de direcciones

En los primeros das de Internet, IPv4 asignacin de espacio de direcciones se realizado por el centro de Network Information Center (NIC). Clase A / B / C nmeros de red se asignan bsicamente en orden arbitrario, ms o menos de acuerdo con el tamao de las organizaciones que solicitaron ellos. Todas las asignaciones se registran de forma centralizada, y se hizo ningn intento posible para asignar nmeros de red de una manera que permita enrutamiento agregacin.

Cuando CIDR se despleg inicialmente, la autoridad de asignacin centrales sigue existiendo, pero cambi sus procedimientos para asignar grandes bloques de "Clase C", los nmeros de red de cada proveedor de servicios. Cada servicio proveedor, a su vez, asigna mscara de bits orientado a subconjuntos de la proveedor de espacio de direcciones para cada cliente. Esto ha funcionado razonablemente as, siempre y cuando el nmero de proveedores de servicios es relativamente pequeo y relativamente constante, pero no escala bien, como el nmero de proveedores de servicios creci a un ritmo rpido.

A medida que Internet comenz a expandirse rpidamente en la dcada de 1990, se convirti en claro que una autoridad nica y centralizada de la asignacin de direcciones se problemtica. Esta funcin comenz a ser descentralizado, cuando la direccin asignacin de espacio para los sitios de Internet en Europa se deleg en el bitbloques alineados de 16777216 direcciones (lo que CIDR ms tarde definira como a / 8) en el RIPE NCC ([ RIPE ]), efectivamente, haciendo el primero de los RIR. Desde entonces, la asignacin de direcciones ha sido formalmente distribuidos en funcin jerrquica con IANA, RIR, y el proveedores de servicios. La eliminacin de los cuellos de botella de una sola organizacin tienen la responsabilidad de espacio de direcciones de Internet mundial en gran medida mejora de la eficiencia y tiempo de respuesta para las nuevas asignaciones.

Delegacin jerrquica de las direcciones de esta manera implica que sitios con direcciones asignadas por un proveedor de servicios estn debidamente fundamentados, para el encaminamiento de los efectos, parte de ese proveedor de servicios y ser enrutan a travs de su infraestructura. Esto implica que la informacin de enrutamiento acerca de multitarjeta organizaciones (es decir, las organizaciones vinculadas a ms de un proveedor de servicio de red) an tendr que ser conocido

por niveles ms altos en la jerarqua.

Una perspectiva histrica sobre estos temas se describe en [ RFC1518 ]. Discusin adicional tambin se puede encontrar en [ RFC3221 ].

Fuller & Li Mejores Prcticas actuales [Pgina 10]

RFC 4632 CIDR Direccin estrategia de agosto 2006

5 . Consideraciones sobre la implementacin de enrutamiento

Con el cambio de los nmeros de red con clase a los prefijos de clases, no es posible deducir la mscara de red desde el bit inicial patrn de una direccin IPv4. Esto tiene implicaciones para la forma de enrutamiento informacin se almacena y se propaga. Las mscaras de red o el prefijo longitudes deben ser explcitamente realizado en los protocolos de enrutamiento. Interior protocolos de enrutamiento, como OSPF [ RFC2328 ], Sistema Intermedio a Sistema Intermedio (IS-IS) [ RFC1195 ], RIPv2 [ RFC2453 ], y Cisco Enhanced Interior Gateway Routing Protocol (EIGRP) y la BGP4 protocolo de enrutamiento exterior [ RFC4271 ], todo el apoyo a esta funcin, que se han desarrollado o modificado, como parte de la implementacin de sin clases entre dominios de enrutamiento durante la dcada de 1990.

Mayores protocolos de enrutamiento interior, tales como RIP [ RFC1058 ], Hola, y Cisco Interior Gateway Routing Protocol (IGRP), y mayores exterior protocolos de enrutamiento, como Exterior Gateway Protocol (EGP) [ RFC904 ], no son compatibles con el transporte expreso de la longitud de prefijo / mscara y por lo tanto no pueden ser efectivamente utilizado en Internet, salvo en muy limitadas configuraciones trozo. Aunque su uso puede ser apropiado en simples legado del sitio final de configuraciones, que se consideran obsoletas y no se deben usar en las redes de trnsito relacionados con el mundial

Internet.

Del mismo modo, las tablas de enrutamiento y el reenvo de la capa-3 equipos de red debe estar organizada para almacenar prefijo y la longitud del prefijo o mscara. El equipo que organiza su enrutamiento / envo de informacin de acuerdo para sistemas heredados A / B / C de la red / subred convenciones no se puede esperar para que funcione correctamente en las redes conectadas a la Internet global, el uso de estos equipos no es recomendable. Afortunadamente, es muy poco como equipo est en uso hoy en da.

5.1 . Normas para Publicidad Ruta

1. Reenvo en Internet se realiza sobre una base ms al partido. Esto implica que los destinos que son multi-homed en relacin con un dominio de enrutamiento debe ser siempre de forma explcita en que anunci enrutamiento de dominio (es decir, que no puede ser resumida). Si una red es multi-homed, todos sus caminos en un dominio de enrutamiento que se "Superior" en la jerarqua de las redes debe ser conocido por el "Superiores" de la red).

2. Un router que genera una ruta agregada para varios msrutas especficas deben descartar los paquetes que coinciden con el agregado ruta, pero no cualquiera de las rutas ms especficas. En otras palabras, el "siguiente salto" para la ruta agregada debe ser nula destino. Esto es necesario para evitar el reenvo de bucles cuando algunas direcciones cubiertos por el conjunto, no son accesibles.

Fuller & Li Mejores Prcticas actuales [Pgina 11]

RFC 4632 CIDR Direccin estrategia de agosto 2006

Tenga en cuenta que durante las fallas, enrutamiento parcial de trfico a un sitio que toma su espacio de direcciones de un proveedor de servicios, pero es que

en realidad slo se puede acceder a travs de otro, es decir (el caso de un sitio que ha cambiado los proveedores de servicios) puede ocurrir porque el trfico de tales ser enviada a lo largo de la ruta anunciada por la ruta agregada. Regla # 2 impedir error en la entrega de paquetes, causando trfico, que se descartados por el anunciante de la ruta agregada, pero la salida de "traceroute" y otras herramientas similares sugieren que un problema exists within that network rather than in the network that is no longer advertising the more-specific prefix. This may be confusing to those trying to diagnose connectivity problems; see the example in Section 6.2 for details. A solution to this perceived "problem" is beyond the scope of this document; it lies with better education of the user/operator community, not in routing technology.

An implementation following these rules should also be generalized, so that an arbitrary network number and mask are accepted for all routing destinations. The only outstanding constraint is that the mask must be left contiguous. Note that the degenerate route to prefix [Link]/0 is used as a default route and MUST be accepted by all implementations. Further, to protect against accidental advertisements of this route via the inter-domain protocol, this route should only be advertised to another routing domain when a router is explicitly configured to do so, never as a non-configured, "default" option.

5.2 . How the Rules Work

Rule #1 guarantees that the forwarding algorithm used is consistent across routing protocols and implementations. Multi-homed networks are always explicitly advertised by every service provider through which they are routed, even if they are a specific subset of one service provider's aggregate (if they are not, they clearly must be explicitly advertised). It may seem as if the "primary" service provider could advertise the multi-homed site implicitly as part of its aggregate, but longest-match forwarding causes this not to work. More details are provided in [ RFC4116 ].

Rule #2 guarantees that no routing loops form due to aggregation. Consider a site that has been assigned 192.168.64/19 by its "parent" provider, which has [Link]/16. The "parent" network will advertise [Link]/16 to the "child" network. If the "child" network were to lose internal connectivity to [Link]/24 (which is part of its aggregate), traffic from the "parent" to the to the "child" destined for [Link] will follow the "child's" advertised route. When that traffic gets to the "child", however, the child *must not* follow the route [Link]/16 back up to the "parent", since that would result in a forwarding loop. Rule #2 says

Fuller & Li Best Current Practice [Page 12] RFC 4632 CIDR Address Strategy August 2006 that the "child" may not follow a less-specific route for a destination that matches one of its own aggregated routes (typically, this is implemented by installing a "discard" or "null" route for all aggregated prefixes that one network advertises to another). Note that handling of the "default" route ([Link]/0) is a special case of this rule; a network must not follow the default to destinations that are part of one of its aggregated advertisements. 5.3 . A Note on Prefix Filter Formats Systems that process route announcements must be able to verify that information that they receive is acceptable according to policy rules. Implementations that filter route advertisements must allow masks or prefix lengths in filter elements. Thus, filter elements that formerly were specified as accept [Link] accept [Link].0 accept [Link] deny [Link] accept [Link] now look something like this: accept [Link]/16 accept [Link]/16 accept [Link]/16 deny [Link]/16 accept [Link]/8 This is merely making explicit the network mask that was implied by the Class A/B/C classification of network numbers. It is also useful to enhance filtering capability to allow the match of a prefix and all more-specific prefixes with the same bit pattern; fortunately, this functionality has been implemented by most vendors of equipment used on the Internet. 5.4 . Responsibility for and Configuration of Aggregation Under normal circumstances, a routing domain (or "Autonomous System") that has been allocated or assigned a set of prefixes has sole responsibility for aggregation of those prefixes. In the usual case, the AS will install configuration in one or more of its routers to generate aggregate routes based on more-specific routes known to its internal routing system. These aggregate routes are advertised into the global routing system by the border routers for the routing domain. The more-specific internal routes that overlap with the aggregate routes should not be advertised globally. In some cases, Fuller & Li Best Current Practice [Page 13]

RFC 4632 CIDR Address Strategy August 2006

an AS may wish to delegate aggregation responsibility to another AS (for example, a customer may wish for its service provider to generate aggregated routing information on its behalf); in such cases, aggregation is performed by a router in the second AS according to the routes that it receives from the first, combined

with configured policy information describing how those routes should be aggregated.

Note that one provider may choose to perform aggregation on the routes it receives from another without explicit agreement; this is termed "proxy aggregation". This can be a useful tool for reducing the amount of routing state that an AS must carry and propagate to its customers and neighbors. However, proxy aggregation can also create unintended consequences in traffic engineering. Consider what happens if both AS 2 and 3 receive routes from AS 1 but AS 2 performs proxy aggregation while AS 3 does not. Other ASes that receive transit routing information from both AS 2 and AS 3 will see an inconsistent view of the routing information originated by AS 1. This may cause an unexpected shift of traffic toward AS 1 through AS 3 for AS 3's customers and any others receiving transit routes from AS 3. Because proxy aggregation can cause unanticipated consequences for parts of the Internet that have no relationship with either the source of the aggregated routes or the party providing aggregation, it should be used with extreme caution.

Configuration of the routes to be combined into aggregates is an implementation of routing policy and requires some manually maintained information. As an addition to the information that must be maintained for a set of routeable prefixes, aggregation configuration is typically just a line or two defining the range of the block of IPv4 addresses to be aggregated. A site performing its own aggregation is doing so for address blocks that it has been assigned; a site performing aggregation on behalf of another knows this information because of an agreement to delegate aggregation. Assuming that the best common practice for network administrators is to exchange lists of prefixes to accept from each other, configuration of aggregation information does not introduce significant additional administrative overhead.

Fuller & Li Best Current Practice [Page 14]

RFC 4632 CIDR Address Strategy August 2006

The generation of an aggregate route is usually specified either statically or in response to learning an active dynamic route for a prefix contained within the aggregate route. If such dynamic aggregate route advertisement is done, care should be taken that routes are not excessively added or withdrawn (known as "route flapping"). In general, a dynamic aggregate route advertisement is added when at least one component of the aggregate becomes reachable and it is withdrawn only when all components become unreachable. Properly configured, aggregated routes are more stable than nonaggregated routes and thus improve global routing stability.

Implementation note: Aggregation of the "Class D" (multicast) address space is beyond the scope of this document.

5.5 . Route Propagation and Routing Protocol Considerations

Prior to the original deployment of CIDR, common practice was to propagate routes learned via exterior routing protocols (ie, EGP or BGP) through a site's interior routing protocol (typically, OSPF, IS-IS, or RIP). This was done to ensure that consistent and correct exit points were chosen for traffic to be sent to a destination

learned through those protocols. Four evolutionary effects -- the advent of CIDR, explosive growth of global routing state, widespread adoption of BGP4, and a requirement to propagate full path information -- have combined to deprecate that practice. A fin de garantizar proper path propagation and prevent inter-AS routing inconsistency (BGP4's loop detection/prevention mechanism requires full path propagation), transit networks must use internal BGP (iBGP) for carrying routes learned from other providers both within and through their networks.

6 . Example of New Address Assignments and Routing

6.1 . Address Delegation

Consider the block of 524288 (2^19) addresses, beginning with [Link] and ending with [Link], allocated to a single network provider, "PA". This is equivalent in size to a block of 2048 legacy "Class C" network numbers (or /24s). A classless route to this block would be described as [Link] with a mask of [Link] and the prefix [Link]/13.

Assume that this service provider connects six sites in the following order (significant because it demonstrates how temporary "holes" may form in the service provider's address space):

Fuller & Li Best Current Practice [Page 15]

RFC 4632 CIDR Address Strategy August 2006

o "C1", requiring fewer than 2048 addresses (/21 or 8 x /24)

o "C2", requiring fewer than 4096 addresses (/20 or 16 x /24)

o "C3", requiring fewer than 1024 addresses (/22 or 4 x /24)

o "C4", requiring fewer than 1024 addresses (/22 or 4 x /24)

o "C5", requiring fewer than 512 addresses (/23 or 2 x /24)

o "C6", requiring fewer than 512 addresses (/23 or 2 x /24)

In all cases, the number of IPv4 addresses "required" by each site is assumed to allow for significant growth. The service provider delegates its address space as follows:

o C1. assign 10.24.0 through 10.24.7. This block of networks is described by the route [Link]/21 (mask [Link]).

o C2. Assign 10.24.16 through 10.24.31. This block is described by the route [Link]/20 (mask [Link]).

o C3. Assign 10.24.8 through 10.24.11. This block is described by the route [Link]/22 (mask [Link]).

o C4. Assign 10.24.12 through 10.24.15. This block is described by the route [Link]/22 (mask [Link]).

o C5. Assign 10.24.32 and 10.24.33. This block is described by the route [Link]/23 (mask [Link]).

o C6. Assign 10.24.34 and 10.24.35. This block is described by the route [Link]/23 (mask [Link]).

These six sites should be represented as six prefixes of varying size within the provider's IGP. If, for some reason, the provider uses an obsolete IGP that doesn't support classless routing or variable-

length subnets, then explicit routes for all /24s will have to be carried.

To make this example more realistic, assume that C4 and C5 are multihomed through some other service provider, "PB". Further assume the existence of a site, "C7", that was originally connected to "RB" but that has moved to "PA". For this reason, it has a block of network numbers that are assigned out PB's block of (the next) 2048 x /24.

o C7. Assign 10.32.0 through 10.32.15. This block is described by the route [Link]/20 (mask [Link]).

Fuller & Li Best Current Practice [Page 16] RFC 4632 CIDR Direccin estrategia de agosto de 2006 para los sitios de multitarjeta, supongamos que C4 se anuncia como principal a travs de "RA" y secundaria a travs de "RB", y que el C5 es el principal medio de "RB" y secundaria a travs de "RA". Adems, asume que "RA" y "RB" estn conectadas al proveedor de servicio de trnsito mismo, "BB". Grficamente, esta topologa se ve algo como esto: [Link] - 10.24.7.0__ __10.32.0.0 - [Link] C1: [Link]/21 \ / C7: [Link]/20 \ / +---- + +----+ [Link] - 10.24.31.0_ | | | | C2: [Link]/20 \ | | _10.24.12.0 10.24.15.0__ | | \ | | / C4: [Link] / 20 \ | | | | / \ | | [Link] - 10.24.11.0___ / | PA | \ | PB | C3: [Link]/22 | | \ __10.24.32.0 - 10.24.33.0___ | | | | C5: [Link]/23 | | | | | | [Link] 10.24.35.0__ / | | | | C6: [Link]/23 | | | | +----+ +----+ | | | | anuncios de enrutamiento: | | | | | | | | [Link]/22 (C4) | | [Link]/22 (C4) | | [Link]/20 (C7) | | [Link]/23 (C5) | | [Link]/13 (PA) | | [Link]/13 (PB) | | | | | | VV VV +---------- red troncal BB ----- -----+ 6.2 . Anuncios de enrutamiento Para seguir la regla # 1, PA tendr que anunciar el bloque de direcciones que se le dio y C7. Desde el C4 es multitarjeta y primaria a travs de PA, sino que tambin debe ser objeto de publicidad. C5 es multitarjeta y primaria a travs de PB. En principio (y en el ejemplo anterior), no tiene por qu ser objeto de publicidad, ya que la coincidencia ms larga por PB seleccionar automticamente al PP como principal y el anuncio de la totalidad de PA se utilizar como secundario. En la prctica, C5 normalmente se anuncian a travs de los proveedores. Anuncios de "PA" a "BB" se [Link]/22 primaria (publicidad C4) [Link]/20 primaria (publicidad C7) [Link]/13 primaria (anuncia resto del PA) Fuller & Li Mejores Prcticas actuales [ Pgina 17]

RFC 4632 CIDR Direccin estrategia de agosto 2006

De PB, los anuncios tambin debe incluir C4 y C5, as como el bloque de direcciones.

Anuncios de "PB" a "BB" se

[Link]/22 secundaria (publicidad C4)

[Link]/23 primaria (publicidad C5) [Link]/13 primaria (anuncia resto de RB)

Para ilustrar el tema de diagnstico de los problemas mencionados en la seccin 5.1 , considerar lo que sucede si PA pierde conectividad con C7 (el sitio que se asigna fuera del espacio de PB). En un protocolo de estado, PA anunciar que BB [Link]/20 se ha convertido en inalcanzable. Ahora, cuando BB vuelca esta informacin de su tabla de enrutamiento, cualquier futuro de trfico han enviado a travs de l para este destino ser enviado a PB (En el que ser dado de baja de acuerdo a la Regla N 2) en virtud de la PB menos especfica partido, [Link]/13. Aunque esto no causa un problema de funcionamiento (C7 no se puede acceder en cualquier caso), se crea parte del trfico adicional a travs de "BB" (y tambin puede resultar confuso para los alguien que trata de depurar el corte con "traceroute"). Un mecanismo de para almacenar en cach el estado inalcanzable como podra ser bueno, pero es ms all de la alcance de este documento.

7 . Consideraciones de dominio Nombre del servicio

Uno de los aspectos de los servicios de Internet que se vio afectado principalmente por el movimiento de CIDR fue el mecanismo utilizado para la traduccin de direccin a nombre de: la [Link] zona del sistema de dominio. Debido a que esta zona es delegado en los lmites de octeto slo, el paso a una asignacin de direcciones plan que utilice mscara de bits orientado a hacer frente a causado un incremento en trabajo para aquellos que mantienen las partes de la zona de [Link].

Una descripcin de las tcnicas para poblar la zona [Link] cuando y la direccin de utilizar que los bloques que no se alinean a los lmites de octeto se describe en [ RFC2317 ].

8 . Transicin a una solucin a largo plazo

CIDR fue diseado para ser una solucin a corto plazo a los problemas de enrutamiento de estado de agotamiento y la direccin en la Internet IPv4. Lo hace No cambie la ruta fundamental de Internet o hacer frente a arquitecturas. No se espera que afecte a los planes para la transicin

a una solucin ms a largo plazo, excepto, quizs, al retrasar la urgencia de desarrollar una solucin.

Prctica Fuller & Li Mejores Actual [Pgina 18]

RFC 4632 CIDR Direccin estrategia de agosto 2006

9 . Anlisis del efecto de CIDR en global de enrutamiento del estado

Cuando CIDR fue propuesta por primera vez en la dcada de 1990, los autores originales hizo algunas observaciones sobre la tasa de crecimiento global de enrutamiento de estado y ofrece proyecciones sobre cmo sera el despliegue de CIDR, con suerte, reducir lo que pareca ser un crecimiento exponencial a un mundo ms sostenible tipo de cambio. Desde que el despliegue, un esfuerzo en curso, llamado "El CIDR Informe "[ CRPT ], ha intentado cuantificar y hacer un seguimiento de que la tasa de crecimiento. Lo que sigue es un breve resumen del informe de CIDR en marzo de 2005, con un intento de explicar los diferentes patrones de crecimiento y los cambios tasa que se han producido desde que las mediciones del tamao del mundo enrutamiento de estado se inici en 1988.

Cuando la grfica de "entradas de Active tabla BGP" [ CBGP ] se examina, parece que hay varias tendencias de crecimiento diferentes, con distintas los puntos de inflexin que refleja los cambios en la poltica y la prctica. La las tendencias y eventos que se cree que ellos fueron causados siguiente manera:

1. El crecimiento exponencial en el extremo izquierdo de la grfica. Esto representa el perodo de expansin y la comercializacin a principios de la antigua red de investigacin, a partir de la dcada de 1980 a travs de aproximadamente 1994.

El principal motor de este crecimiento fue la falta de agregacin capacidad de los proveedores de trnsito, y el uso generalizado de legado de la clase C asignaciones para usuarios finales. Cada vez que un nuevo sitio estaba conectado a la Internet global, una o ms rutas nuevas las entradas se han generado.

2. Aceleracin de la tendencia exponencial a fines de 1993 y principios de 1994 como CIDR "superred" bloques fueron asignados por primera vez por el NIC y el enruta de forma separada el legado de clase C-redes del proveedor de servicio.

3. Una fuerte cada en 1994 como BGP4 despliegue de los proveedores autorizados agregacin de la "superred" bloques. Tenga en cuenta que los perodos de mayores descensos en el nmero de entradas de la tabla de enrutamiento normalmente corresponden a las semanas despus de cada reunin de la IETF CIDR El despliegue del Grupo de Trabajo.

4. Crecimiento ms o menos lineal, desde mediados de 1994 y principios de 1999 como CIDR basada en asignacin de direcciones se hicieron agregados y aadi rutas toda la red.

5. Una nueva fase de crecimiento exponencial de nuevo desde principios de 1999 hasta 2001 como "burbuja de alta tecnologa" impulsado tanto la rpida expansin de la Internet, as como un gran aumento en ms especficos de la ruta

Tabla de conversin de CIDR

Mircoles 27 de Febrero de 2008 Consulte aqu la Tabla de conversin de CIDR.

CIDR Clases C Clases B Clases A /32 /31 1/256 1/128

Hosts*

Mscara 1 [Link] 2 [Link]

/30 /29 /28 /27 /26 /25 /24 /23 /22 /21 /20 /19 /18 /17 /16 /15 /14 /13 /12 /11 /10 /9

1/64 1/32 1/16 1/8 1/4 1/2 1 2 4 8 16 32 64 128 256 512 1024 2048 4096 8192 16384 32768 1 2 4 8 16 32 64 128

4 [Link] 8 [Link] 16 [Link] 32 [Link] 64 [Link] 128 [Link] 256 [Link] 512 [Link] 1024 [Link] 2048 [Link] 4096 [Link] 8192 [Link] 16384 [Link] 32768 [Link] 65536 [Link] 131072 [Link] 262144 [Link] 524288 [Link] 1048576 [Link] 2097152 [Link] 4194304 [Link] 8388608 [Link]

/8

65536

256 512 1024 2048 4096 8192 16384 32768

1 2 4

16777216 [Link] 33554432 [Link] 67108864 [Link]

/7 131072 /6 262144 /5 524288 /4 1048576 /3 2097152 /2 4194304 /1 8388608

8 134217728 [Link] 16 268435456 [Link] 32 536870912 [Link] 64 1073741824 [Link] 128 2147483648 [Link]

(*) En la prctica hay que restar 2 a este nmero. La direccin menor (ms baja - todos los bits de host a 0) del bloque se usa para identificar a la propia red (toda la red), y la direccin mayor (la ms alta - todos los bits de host a 1) se usa como direccin de broadcast. Por tanto, en un bloque CIDR /24 podramos disponer 8 de 2 2 = 254 direcciones IP para asignar a dispositivos. Tambin puede usar el siguiente link para hacer clculos de CIDR: [Link]