[LACNIC/Politicas] resolucion inversa

Thu Jan 26 14:27:01 BRST 2006

Francisco gracias por tus comentarios.

Paola.

On Sat, 14 Jan 2006 politicas-request at lacnic.net wrote:

> Send Politicas mailing list submissions to
> 	politicas at lacnic.net
>
> To subscribe or unsubscribe via the World Wide Web, visit
> 	http://www.lacnic.net/mailman/listinfo/politicas
> or, via email, send a message with subject or body 'help' to
> 	politicas-request at lacnic.net
>
> You can reach the person managing the list at
> 	politicas-owner at lacnic.net
>
> When replying, please edit your Subject line so it is more specific
> than "Re: Contents of Politicas digest..."
>
>
> Today's Topics:
>
>    1. resolucion inversa (Paola Garfias)
>    2. Re: Politicas Digest, Vol 33, Issue 2 (Paola Garfias)
>    3. Re: resolucion inversa (Francisco Obispo)
>
>
> ----------------------------------------------------------------------
>
> Message: 1
> Date: Fri, 13 Jan 2006 20:12:33 -0600 (CST)
> From: Paola Garfias <paola at redes.unam.mx>
> Subject: [LACNIC/Politicas] resolucion inversa
> To: politicas at lacnic.net
> Message-ID: <Pine.BSO.4.58.0601132009350.15135 at necti.redes.unam.mx>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>
> Hola! Buen dia,
>
> Animada porque en ocasiones anteriores se discutio en la lista el tema de
> lame delegation, me acerco a ustedes para preguntar sobre la importancia
> de la resolucion inversa, ahora mismo estoy en una confusion y seguro que
> alguno de ustedes podra orientarme en este tema.
>
> Resulta que estamos en el proceso de solicitud de direcciones y me enfreto
> a la parte de la politica de asignacion que se refiere a resolucion
> inversa, entonces en el intento de justificar el 80% de uso, pasa que no
> tengo ese 80% con su reverso, es decir la idea que tengo es de solo
> registrar en DNS aquellas IPs a las cuales es necesario asociar un nombre
> lo cual no significaria que el resto no esta en uso.
>
> Ok entonces seria buenisimo leer el porque de la resolucion inversa.
>
> saludos!
> Paola Garfias
> UNAM - Mexico
>
> **Mensaje sin ACENTOS**
>
>
>
> ------------------------------
>
> Message: 2
> Date: Fri, 13 Jan 2006 20:12:59 -0600 (CST)
> From: Paola Garfias <paola at redes.unam.mx>
> Subject: Re: [LACNIC/Politicas] Politicas Digest, Vol 33, Issue 2
> To: politicas at lacnic.net
> Message-ID: <Pine.BSO.4.58.0601132012560.15135 at necti.redes.unam.mx>
> Content-Type: TEXT/PLAIN; charset=US-ASCII
>
>
>
> On Fri, 13 Jan 2006 politicas-request at lacnic.net wrote:
>
> > Send Politicas mailing list submissions to
> > 	politicas at lacnic.net
> >
> > To subscribe or unsubscribe via the World Wide Web, visit
> > 	http://www.lacnic.net/mailman/listinfo/politicas
> > or, via email, send a message with subject or body 'help' to
> > 	politicas-request at lacnic.net
> >
> > You can reach the person managing the list at
> > 	politicas-owner at lacnic.net
> >
> > When replying, please edit your Subject line so it is more specific
> > than "Re: Contents of Politicas digest..."
> >
> >
> > Today's Topics:
> >
> >    1. IPv4 HD-ratio (ARG-O'FLAHERTY, CHRISTIAN)
> >
> >
> > ----------------------------------------------------------------------
> >
> > Message: 1
> > Date: Thu, 12 Jan 2006 17:05:54 -0300
> > From: "ARG-O'FLAHERTY, CHRISTIAN" <COFLAHERTY at IMPSAT.COM>
> > Subject: [LACNIC/Politicas] IPv4 HD-ratio
> > To: <politicas at lacnic.net>
> > Message-ID:
> > 	<F5FBC6FCDC119E4AAA7F8356EC51C54BAA447C at arg-ex2k3.IMPSAT.COM>
> > Content-Type: text/plain;	charset="iso-8859-1"
> >
> >
> > Hola, Feliz 2006!
> >
> > Empezamos el a?o con una noticia de RIPE. Recientemente se present? una pol?tica que puede ser ?til para nuestra regi?n. Proponen utilizar HD-ratio (http://www.ietf.org/rfc/rfc3194.txt) para las asignaciones adicionales en IPv4. Hasta ahora ten?an una pol?tica como la nuestra donde ped?an el 80% de uso en los bloques asignados para que la entidad pudiera pedir otro bloque al registro.
> >
> > El problema de utilizar un % en lugar de HD-ratio es que no existe un valor que sea apropiado para todos los tama?os de proveedor. Si utilizamos % bajos puede haber mala utilizaci?n, si utilizamos % grandes ser? imposible para los proveedores con redes complejas lograr esa eficiencia.
> >
> > Una explicaci?n simplificada del HD-ratio seria: en lugar de contar el % de IPs utilizados contamos el % de utilizaci?n de los "bits" asignados. Es decir, si me dieron 10 bits (un /22) y me piden un HD ratio del 90% (0.9) entonces tengo que tener usados 9 bits (un /23) antes de pedir el siguiente bloque.
> >
> > La pol?tica de RIPE pide un HD-ratio del 95% (HD-ratio=0.95) y pueden encontrarla en: http://www.ripe.net/ripe/policies/proposals/2005-1.html. En esa misma p?gina con el t?tulo de Rationale: ver?n la justificaci?n y mas abajo unas tablas donde pueden ver la aplicaci?n del HD-ratio a diferentes tama?os de bloque.
> >
> > Adjunto el mail donde nos comunican esta novedad y nos invitan a participar del debate en la lista de pol?ticas de Ripe.
> >
> > Christian
> >
> >
> > | Hi,
> > |
> > | I'm not sure if you're all aware that Alain Bidron's HD-ratio for IPv4
> > | allocations proposal has been published as a draft RIPE document. The
> > | draft is available on the web site at:
> > |
> > | http://www.ripe.net/ripe/draft-documents/ipv4-policies-draft.html
> > |
> > | The review period is open until 27 January. However, there has been
> > | almost no comment on the proposal itself, and no-one has commented on
> > | the draft document.
> > |
> > | This could represent a significant change in the way that the RIPE NCC
> > | has to evaluate IPv4 allocation requests. For that reason, I think the
> > | proposal might be of interest to all your communities. I would be very
> > | grateful if you could forward the announcement we sent to
> > | policy-announce at ripe.net in December, as there has been no comment on
> > | the issue so far in our region.
> > |
> > | https://www.ripe.net/ripe/maillists/archives/policy-announce/2005/msg00022.html
> > |
> > | There shouldn't be any problem with non-subscribers posting to the
> > | address-policy-wg at ripe.net list. Their mails will be held for approval
> > | and moderated through, but they will get through.
> > |
> > | Many thanks,
> > |
> > | --
> > | leo vegoda
> > | RIPE NCC
> > | Registration Services Manager
> >
> >
> > Esta comunicaci?n es confidencial y puede contener informaci?n cuya divulgaci?n est? restringida por la ley o en virtud de obligaciones de confidencialidad asumidas por acuerdos escritos. Si usted no es su destinatario, por favor advierta que cualquier divulgaci?n, distribuci?n o copia de esta comunicaci?n le est? estrictamente prohibida. Si usted recibi? este mail por error, agradeceremos tenga a bien informar esa circunstancia al remitente mediante comunicaci?n a la direcci?n de e-mail o al n?mero telef?nico : (5411) 5170-0000, y le solicitamos asimismo que por favor proceda a borrarlo de su computadora. Por favor no copie ni use la informaci?n contenida en este mail para ning?n prop?sito y no divulgue su contenido a ninguna otra persona.
> >
> >
> > This communication is confidential and may contain information that is exempt from disclosure by law or pursuant to confidentiality obligations assumed by written agreement. If you are not the intended recipient, please note that any dissemination, distribution, or copying of this communication is strictly prohibited. If you receive this e-mail in error, please notify the sender immediately at the electronic mail address or phone number : (5411) 5170-0000  and delete the information from your computer. Please do not copy or use it for any purpose nor disclose its contents to any other person.
> >
> >
> >
> >
> >
> > ------------------------------
> >
> > _______________________________________________
> > Politicas mailing list
> > Politicas at lacnic.net
> > http://www.lacnic.net/mailman/listinfo/politicas
> >
> >
> > End of Politicas Digest, Vol 33, Issue 2
> > ****************************************
> >
>
>
> ------------------------------
>
> Message: 3
> Date: Sat, 14 Jan 2006 00:09:57 -0400
> From: Francisco Obispo <fobispo at nic.ve>
> Subject: Re: [LACNIC/Politicas] resolucion inversa
> To: Paola Garfias <paola at redes.unam.mx>
> Cc: politicas at lacnic.net
> Message-ID: <43C87995.2090406 at nic.ve>
> Content-Type: text/plain; charset=ISO-8859-1
>
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
>
> Estimada Paola,
>
> Creo que podr?amos entrar en la eterna discusi?n de "como" verificar
> (desde el punto de vista de LACNIC), la utilizaci?n de los recursos.
>
> Definitivamente la forma m?s adecuada ser?a que se registraran todas
> las subnets que son delegadas, en la base de datos de LACNIC (whois),
> de manera tal, que ya se pudiera justificar autom?ticamente la
> utilizaci?n, sin tener que hacer mas nada, sin embargo, la realidad
> prueba que mantener actualizada esta base de datos, desde el punto de
> vista del proveedor es muy tedioso, por lo cual discutimos en alg?n
> momento en Per?, la sistematizaci?n del mecanismo de actualizaci?n etc.
>
> La resoluci?n inversa es utilizada por muchos sistemas para verificar
> la "autenticidad" de peticiones, por ejemplo, si recibo una conexi?n
> de un servidor que dice que se llama "correo.midominio.org" que tiene
> ip "1.2.3.4", y le pregunto al DNS quien es 4.3.2.1.in-addr.arpa y
> retorna "correo.midominio.org", entonces tengo certeza que es una
> petici?n v?lida y que proviene de donde espero que venga.
>
> Configurar el reverso de DNS para los IPs es muy sencillo, y con
> BIND8+ te tomar? un par de lineas definir todo tu rango, por lo cual
> no es conveniente utilizar esto como medida de utilizaci?n de los IPs.
>
> Los problemas de Lame delegation fueron resueltos en el momento que
> LACNIC comenz? aplicar la "politica de Lame delegation" [1], la cual
> consiste en revisar la autoridad de los servidores a los que se le
> delegan zonas, de esta forma, aquellos servidores que las desconocen,
> son eliminados de la lista de delegaci?n.
>
> El problema de Lame Delegation, viene por el hecho de que el proceso
> de DNS es un proceso iterativo (recursivo), que iterar? tantas veces
> como sea necesario, para conseguir un resultado, si existe un servidor
> que desconoce una zona a la que deber?a tener autoridad (lame),
> entonces todo el esfuerzo y tr?fico generado para realizar esa
> petici?n se perdi? sin ning?n resultado postivo, generando retardos en
> el proceso de resoluci?n, y utilzando ancho de banda injustificadamente.
>
> Ahora bien volviendo a tu duda, buscando en la politica de resoluci?n
> inversa[2] consegu? lo siguiente:
>
> "LACNIC podr? utilizar informaci?n producto de la resoluci?n inversa
> como indicador de la utilizaci?n del bloque de direcciones IP asignado. "
>
> Lo que indica "podr?", seg?n mi entendimiento, considero que no es
> obligatorio, solo obliga, a que se debe utilizar un servidor de DNS
> para hacer las resoluciones por cada bloque delegado:
>
> "Todo el espacio de direcciones IP asignado debe tener un servidor DNS
> asociado que ser? responsable por la resoluci?n inversa. En el caso de
> la regi?n de cobertura de LACNIC[anexo 1], esos servidores deben ser
> registrados en LACNIC, quien a su vez es el responsable de la
> resoluci?n inversa de los bloques administrados por esta organizaci?n."
>
> Como comentario final, si pudieramos revisar la pol?tica, cambiar?a
> "... debe tener un servidor .." por "... debe tener al menos un
> servidor ...", si no es que establecemos dos (2) servidores como
> m?nimo lo hacen algunos TLDs. y en el cuarto p?rrafo de la pol?tica de
> resoluci?n inversa [2] dice: "Para que el proceso de resoluci?n
> inversa sea posible es necesario que se utilice un dominio ficticio
> "in.addr-arpa", una abreviaci?n hist?rica para Arpanet Inverse
> Address", deber?a leerse "IN-ADDR.ARPA".
>
> Saludos y espero haber ayudado.
>
>
> [1] http://lacnic.net/sp/politicas/lame.html
> [2] http://lacnic.net/sp/politicas/2002-11-res_inv.html
>
> Paola Garfias wrote:
>
> > Hola! Buen dia,
> >
> > Animada porque en ocasiones anteriores se discutio en la lista el
> > tema de lame delegation, me acerco a ustedes para preguntar sobre
> > la importancia de la resolucion inversa, ahora mismo estoy en una
> > confusion y seguro que alguno de ustedes podra orientarme en este
> > tema.
> >
> > Resulta que estamos en el proceso de solicitud de direcciones y me
> > enfreto a la parte de la politica de asignacion que se refiere a
> > resolucion inversa, entonces en el intento de justificar el 80% de
> > uso, pasa que no tengo ese 80% con su reverso, es decir la idea que
> > tengo es de solo registrar en DNS aquellas IPs a las cuales es
> > necesario asociar un nombre lo cual no significaria que el resto no
> > esta en uso.
> >
> > Ok entonces seria buenisimo leer el porque de la resolucion
> > inversa.
> >
> > saludos! Paola Garfias UNAM - Mexico
> >
> > **Mensaje sin ACENTOS**
> >
> > _______________________________________________ Politicas mailing
> > list Politicas at lacnic.net
> > http://www.lacnic.net/mailman/listinfo/politicas
> >
> >
>
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.2 (GNU/Linux)
> Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org
>
> iD8DBQFDyHmVGs0zZ5KMmSMRAgZzAKCVgVxiTIgWzs0/B5GlkyH9U6IpvACfa7Sv
> CIYjJswvD3YHGOQ6c8eTOyk=
> =6Rxe
> -----END PGP SIGNATURE-----
>
>
>
> ------------------------------
>
> _______________________________________________
> Politicas mailing list
> Politicas at lacnic.net
> http://www.lacnic.net/mailman/listinfo/politicas
>
>
> End of Politicas Digest, Vol 33, Issue 3
> ****************************************
>