<div dir="ltr"><div>Gracias Fernando.</div><div>Se trata del segundo escenario.<br></div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">El mié, 12 ene 2022 a las 18:54, <<a href="mailto:lacnog-request@lacnic.net">lacnog-request@lacnic.net</a>> escribió:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Envíe los mensajes para la lista LACNOG a<br>
<a href="mailto:lacnog@lacnic.net" target="_blank">lacnog@lacnic.net</a><br>
<br>
Para subscribirse o anular su subscripción a través de la WEB<br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
<br>
O por correo electrónico, enviando un mensaje con el texto "help" en<br>
el asunto (subject) o en el cuerpo a:<br>
<a href="mailto:lacnog-request@lacnic.net" target="_blank">lacnog-request@lacnic.net</a><br>
<br>
Puede contactar con el responsable de la lista escribiendo a:<br>
<a href="mailto:lacnog-owner@lacnic.net" target="_blank">lacnog-owner@lacnic.net</a><br>
<br>
Si responde a algún contenido de este mensaje, por favor, edite la<br>
linea del asunto (subject) para que el texto sea mas especifico que:<br>
"Re: Contents of LACNOG digest...". Además, por favor, incluya en la<br>
respuesta sólo aquellas partes del mensaje a las que está<br>
respondiendo.<br>
<br>
<br>
Asuntos del día:<br>
<br>
1. Re: Resumen de LACNOG, Vol 169, Envío 12 (Fernando Frediani)<br>
<br>
<br>
----------------------------------------------------------------------<br>
<br>
Message: 1<br>
Date: Wed, 12 Jan 2022 18:54:00 -0300<br>
From: Fernando Frediani <<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a>><br>
To: <a href="mailto:lacnog@lacnic.net" target="_blank">lacnog@lacnic.net</a><br>
Subject: Re: [lacnog] Resumen de LACNOG, Vol 169, Envío 12<br>
Message-ID: <<a href="mailto:7d6282fc-edaf-0360-45e3-39bdf55bfb5b@gmail.com" target="_blank">7d6282fc-edaf-0360-45e3-39bdf55bfb5b@gmail.com</a>><br>
Content-Type: text/plain; charset="utf-8"; Format="flowed"<br>
<br>
Hola Gabriel<br>
Que bueno que hayas enviado más detalles del escenario para que podamos <br>
ser más asertivos en las manifestaciones.<br>
<br>
En este caso, que está citando por lo que entiendo, la razón por la cual <br>
el bloque /24 está siendo sub-asignado de ISP1 a ISP2 es porque ISP2 (la <br>
suya) se quedó sin direcciones disponibles .<br>
Entonces, las direcciones de este bloque /24 bajo responsabilidad del <br>
ISP1 que anunciará el ISP2 también se usarán para atender a otros <br>
clientes de ISP2 además del ISP1, que entiendo es uno de sus clientes ?<br>
<br>
Si esto es cierto, es el escenario que estaba citando en mis <br>
publicaciones anteriores. Si un día el RIR le pide al ISP1 que <br>
justifique lo que se está haciendo con ese bloque /24, no puede <br>
simplemente decir que cedió al ISP2 para que pueda usarlo para servir a <br>
sus otros clientes ya que no sería un uso para el que se justificaba ese <br>
bloque. Ahora bien, si por alguna otra razón el ISP2 está originando <br>
estos anuncios (por ejemplo, porque el ISP1 no quiere administrar su <br>
propio BGP), pero estas direcciones son utilizadas al final por completo <br>
por el ISP1, no veo ningún problema.<br>
<br>
Saludos<br>
Fernando<br>
<br>
On 12/01/2022 17:47, Gabriel Zárate wrote:<br>
> Gracias a todos por las respuestas, muy agradecido.<br>
> Creo que ya le daremos fin a esto, veo algunos criterios diferentes y <br>
> cada uno parece tener razón, nuestro caso es bastante simple y tenemos <br>
> la necesidad de sumar un nuevo bloque porque lo que teníamos ya nos <br>
> quedó chico.<br>
> Aclaro que si tenemos ASN y bloques propios.<br>
> El escenario de interconexión es el siguiente: <br>
> ISP1-----ISP2----ISPmayorista.<br>
> Yo sería ISP2, tengo escasez de direcciones y necesito otro bloque, <br>
> luego ISP1 sub-asigna un bloque /24 a ISP2, entonces debo poder <br>
> publicar ese bloque con mi ASN hacia arriba(ISPmayorista), ya que ISP2 <br>
> es quien va a ser el responsable del uso de ese bloque, ISPmayorista <br>
> era quien decia que ISP2 debía publicar el bloque con el ASN de ISP1.<br>
> Ya me quedó claro que está permitido hacerlo siempre y cuando estén <br>
> realizadas formalmente las sub-asignaciones en la plataforma de LACNIC <br>
> y tengamos justificaciones reales de esto, si alguien las solicita las <br>
> daremos con gusto.<br>
> Hasta luego!!!.<br>
><br>
> El mié, 12 ene 2022 a las 13:10, <<a href="mailto:lacnog-request@lacnic.net" target="_blank">lacnog-request@lacnic.net</a>> escribió:<br>
><br>
> Envíe los mensajes para la lista LACNOG a<br>
> <a href="mailto:lacnog@lacnic.net" target="_blank">lacnog@lacnic.net</a><br>
><br>
> Para subscribirse o anular su subscripción a través de la WEB<br>
> <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
><br>
> O por correo electrónico, enviando un mensaje con el texto "help" en<br>
> el asunto (subject) o en el cuerpo a:<br>
> <a href="mailto:lacnog-request@lacnic.net" target="_blank">lacnog-request@lacnic.net</a><br>
><br>
> Puede contactar con el responsable de la lista escribiendo a:<br>
> <a href="mailto:lacnog-owner@lacnic.net" target="_blank">lacnog-owner@lacnic.net</a><br>
><br>
> Si responde a algún contenido de este mensaje, por favor, edite la<br>
> linea del asunto (subject) para que el texto sea mas especifico que:<br>
> "Re: Contents of LACNOG digest...". Además, por favor, incluya en la<br>
> respuesta sólo aquellas partes del mensaje a las que está<br>
> respondiendo.<br>
><br>
><br>
> Asuntos del día:<br>
><br>
> 1. Re: Consulta peer BGP con bloque sub-asignado<br>
> (Nicolas Antoniello)<br>
> 2. Fwd: Call for Participation -- ICANN DNSSEC and Security<br>
> Workshop for ICANN73 Community Forum (Nicolas Antoniello)<br>
><br>
><br>
> ----------------------------------------------------------------------<br>
><br>
> Message: 1<br>
> Date: Wed, 12 Jan 2022 12:58:29 -0300<br>
> From: Nicolas Antoniello <<a href="mailto:nantoniello@gmail.com" target="_blank">nantoniello@gmail.com</a>><br>
> To: Latin America and Caribbean Region Network Operators Group<br>
> <<a href="mailto:lacnog@lacnic.net" target="_blank">lacnog@lacnic.net</a>><br>
> Subject: Re: [lacnog] Consulta peer BGP con bloque sub-asignado<br>
> Message-ID:<br>
> <br>
> <CADHEbK-g=<a href="mailto:e2R_ZtYQDuc6P1sF00v5d0EYWGsGBw0NsXQCSGT1Q@mail.gmail.com" target="_blank">e2R_ZtYQDuc6P1sF00v5d0EYWGsGBw0NsXQCSGT1Q@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> Fernando,<br>
><br>
> Si lees nuevamente lo que escribí notarás que indiqué:<br>
><br>
> "entiendo que las sub-asignaciones de bloques IP (IPv4 e IPv6),<br>
> siempre que<br>
> mantengan alguna relación más allá de la mera sub-asignación (por<br>
> ejemplo<br>
> ser cliente BGP) son totalmente válidas"<br>
><br>
> Allí claramente expongo el motivo de la sub-asignación, que es el de<br>
> brindar un servicio de conectividad a internet (usando BGP) por<br>
> parte del<br>
> proveedor (ISP en este caso) al cliente... no veo ningún problema ni<br>
> técnico ni de violación de políticas, a priori, en esto.<br>
> No se está solamente cediendo bloques sino que se está presentando un<br>
> servicio de conectividad (ese es el motivo, no la asignación de<br>
> IPs). No me<br>
> gustaría que por "supuestas intenciones" se confunda la comunidad<br>
> técnica<br>
> sobre que cosas se pueden y cuales no hacer.<br>
><br>
> No constituye un "regalo" en esos casos como tu dices sino que<br>
> claramente<br>
> (al menos para mi) es un servicio de conectividad (lo de los<br>
> bloques IP es<br>
> anecdótico y es la forma de implementarlo)... ya se indicaron<br>
> varios casos<br>
> más de esos usos entre los que yo mencioné y los que otros han<br>
> mencionado.<br>
><br>
> Saludos,<br>
> Nico<br>
><br>
><br>
><br>
> El mié, 12 ene 2022 a la(s) 12:40, Fernando Frediani<br>
> (<a href="mailto:fhfrediani@gmail.com" target="_blank">fhfrediani@gmail.com</a>)<br>
> escribió:<br>
><br>
> > Em 12/01/2022 12:22, Nicolas Antoniello escreveu:<br>
> ><br>
> > <clip><br>
> > Entonces, entiendo que las sub-asignaciones de bloques IP (IPv4<br>
> e IPv6),<br>
> > siempre que mantengan alguna relación más allá de la mera<br>
> sub-asignación<br>
> > (por ejemplo ser cliente BGP) son totalmente válidas. Y claro,<br>
> eso también<br>
> > permitiría al cliente publicar esos bloques por otros proveedores de<br>
> > transporte (es parte de la idea detrás de usar BGP para el<br>
> servicio).<br>
> ><br>
> > Aquí empieza el problema.<br>
> > Si la organización propietaria del bloque lo regala para que lo<br>
> use un<br>
> > cliente, no debería poder usarlo de esta manera como si fuera<br>
> una cesión<br>
> > de bloque hecha directamente por el RIR , de lo contrario,<br>
> comienza a<br>
> > parecerse más a un préstamo en bloque que a un titular de bloque<br>
> que lo<br>
> > subasigna para que lo use el cliente en la forma que se justificó<br>
> > inicialmente.<br>
> ><br>
> > Los motivos por los que el cliente hace esto pueden ser varios y<br>
> son un<br>
> > tema de cada cliente... Algunos incluso ni manejan su BGP sino<br>
> que lo<br>
> > administra el mismo proveedor de transporte (porque no quieren<br>
> > hacerlo; porque no tienen la gente para eso; o por cualquier<br>
> otro motivo).<br>
> > Claro que para esto, es necesario que quien provee la<br>
> sub-asignación la<br>
> > registre adecuadamente en el sistema del RIR (o delegue la misma al<br>
> > cliente)... para que quede claro quien es el que administra y<br>
> "posee" los<br>
> > derechos de publicación y gestión del bloque de IPs. Y también<br>
> que el<br>
> > cliente tenga un ASN en el caso en que la/las sesiones BGP sean<br>
> con un ASN<br>
> > público.<br>
> ><br>
> > Lo que técnicamente no se debería hacer, pues si puede generar<br>
> problemas,<br>
> > es por un lado mantener bloques de un proveedor de transporte<br>
> con quien no<br>
> > tengo sesión BGP y al mismo tiempo publicar esos bloques por BGP<br>
> a un<br>
> > proveedor diferente (porque en ese caso el registro de los<br>
> bloques en los<br>
> > sistemas de información no va a figurar con el origen correcto).<br>
> Es decir,<br>
> > si quiero multihoming-multiproveedor, lo correcto sería hablar<br>
> BGP con<br>
> > ambos desde mi propio ASN público (pero entiendo que los bloques<br>
> de IPs<br>
> > pueden ser sub-asignados por cualquiera de esos proveedores) o<br>
> ser propios<br>
> > es decir asignados directamente al cliente por el RIR.<br>
> ><br>
> > Como dato anecdótico histórico, muchos de los IPS de la región<br>
> de LAC,<br>
> > antes de la creación de LACNIC, publicaban con su propio ASN bloques<br>
> > sub-asignados por proveedores de transporte de la región de ARIN en<br>
> > exactamente la misma modalidad que describí anteriormente (con<br>
> el añadido<br>
> > de que entonces, esos si que eran ISP que tenían a su vez sus<br>
> propios<br>
> > clientes). Y no había ningún problema en tanto todo estuviese<br>
> correctamente<br>
> > registrado en el Whois y en los IRR (en ese entonces no teníamos<br>
> RPKI). Y<br>
> > de hecho, los ASN públicos eran asignados por ARIN... que fueron<br>
> > transferidos a LACNIC luego de su creación si mal no recuerdo.<br>
> ><br>
> > Como otro ejemplo de independencia del titular el ASN con el de los<br>
> > bloques de IPs, están los proveedores de CDNs en los que muchos<br>
> de ellos<br>
> > publican bloques de IPs propios, desde el ASN que los aloja, o<br>
> viceversa<br>
> > (lo que importa es que todo esté correctamente registrado).<br>
> ><br>
> > Para satisfacer alguna necesidad, la organización titular de<br>
> recursos del<br>
> > bloque.<br>
> ><br>
> ><br>
> > Saludos,<br>
> > Nico<br>
> ><br>
> > En resumen: *El punto principal no es qué ASN origina el<br>
> anuncio* mas,<br>
> > ¿cuál es la justificación para que ese bloque se use de esa manera?<br>
> > Independientemente del ASN que originará el anuncio.<br>
> > No siempre se puede suponer que debido a que una organización tiene<br>
> > derechos sobre ese bloque, puede hacer lo que quiera. El uso del<br>
> bloque, ya<br>
> > sea por la propia organización o por sus clientes, debe seguir<br>
> siendo<br>
> > válido de acuerdo con lo que se justificó cuando se solicitó<br>
> originalmente<br>
> > al RIR. Y los casos que aun configurando involuntariamente un<br>
> préstamo o<br>
> > leasing en bloque no pueden considerarse válidos solo porque se<br>
> emitió una<br>
> > LOA o algo por el estilo.<br>
> ><br>
> > Fernando<br>
> ><br>
> ><br>
> ><br>
> > _______________________________________________<br>
> > LACNOG mailing<br>
> listLACNOG@lacnic.nethttps://<a href="http://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">mail.lacnic.net/mailman/listinfo/lacnog</a><br>
> <<a href="http://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">http://mail.lacnic.net/mailman/listinfo/lacnog</a>><br>
> > Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
> ><br>
> > _______________________________________________<br>
> > LACNOG mailing list<br>
> > <a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
> > <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
> > Cancelar suscripcion: <a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
> ><br>
> ------------ próxima parte ------------<br>
> Se ha borrado un adjunto en formato HTML...<br>
> URL:<br>
> <<a href="https://mail.lacnic.net/pipermail/lacnog/attachments/20220112/183282d6/attachment-0001.htm" rel="noreferrer" target="_blank">https://mail.lacnic.net/pipermail/lacnog/attachments/20220112/183282d6/attachment-0001.htm</a>><br>
><br>
> ------------------------------<br>
><br>
> Message: 2<br>
> Date: Wed, 12 Jan 2022 13:10:32 -0300<br>
> From: Nicolas Antoniello <<a href="mailto:nantoniello@gmail.com" target="_blank">nantoniello@gmail.com</a>><br>
> To: Latin America and Caribbean Region Network Operators Group<br>
> <<a href="mailto:lacnog@lacnog.net" target="_blank">lacnog@lacnog.net</a>><br>
> Subject: [lacnog] Fwd: Call for Participation -- ICANN DNSSEC and<br>
> Security Workshop for ICANN73 Community Forum<br>
> Message-ID:<br>
> <br>
> <CADHEbK9QKjs_8fEjp39FSefUzce-ohg=<a href="mailto:iO3my6_6p56RTwiiFA@mail.gmail.com" target="_blank">iO3my6_6p56RTwiiFA@mail.gmail.com</a>><br>
> Content-Type: text/plain; charset="utf-8"<br>
><br>
> En caso que alguien desee presentar algo...<br>
><br>
> ---------- Forwarded message ---------<br>
><br>
><br>
><br>
> *Call for Participation -- ICANN DNSSEC and Security Workshop for<br>
> ICANN73<br>
> Community Forum*<br>
><br>
><br>
><br>
> In cooperation with the ICANN Security and Stability Advisory<br>
> Committee<br>
> (SSAC), we are planning a DNSSEC and Security Workshop for the ICANN73<br>
> Community Forum being held virtually from 05-10 March 2022 in the<br>
> Atlantic<br>
> Standard Time Zone (UTC -4). This workshop date will be<br>
> determined once<br>
> ICANN creates a block schedule for us to follow; then we will be<br>
> able to<br>
> request a day and time. The DNSSEC and Security Workshop has been<br>
> a part of<br>
> ICANN meetings for several years and has provided a forum for both<br>
> experienced and new people to meet, present and discuss current<br>
> and future<br>
> DNSSEC deployments. For reference, the most recent session was<br>
> held at the<br>
> ICANN72 Annual General Meeting on Wednesday 27 October 2021. The<br>
> presentations and transcripts are available at<br>
> <a href="https://72.schedule.icann.org/meetings/M24SJN375N2rcupnS" rel="noreferrer" target="_blank">https://72.schedule.icann.org/meetings/M24SJN375N2rcupnS</a>,<br>
> <a href="https://72.schedule.icann.org/meetings/NQMcvSwdLbpdGPaz6" rel="noreferrer" target="_blank">https://72.schedule.icann.org/meetings/NQMcvSwdLbpdGPaz6</a>, and<br>
> <a href="https://72.schedule.icann.org/meetings/9g4P3ceRA8FGS34Ei" rel="noreferrer" target="_blank">https://72.schedule.icann.org/meetings/9g4P3ceRA8FGS34Ei</a>.<br>
><br>
><br>
><br>
> The DNSSEC Workshop Program Committee is developing a program. <br>
> Proposals<br>
> will be considered for the following topic areas and included if space<br>
> permits. In addition, we welcome suggestions for additional<br>
> topics either<br>
> for inclusion in the ICANN72 workshop, or for consideration for future<br>
> workshops.<br>
><br>
><br>
><br>
> *1. **Global DNSSEC Activities Panel*<br>
><br>
> For this panel, we are seeking participation from those who have been<br>
> involved in DNSSEC deployment as well as from those who have not<br>
> deployed<br>
> DNSSEC but who have a keen interest in the challenges and benefits of<br>
> deployment, including Root Key Signing Key (KSK) Rollover<br>
> activities and<br>
> plans.<br>
><br>
><br>
><br>
> *2. DNSSEC Best Practice*<br>
><br>
> Now that DNSSEC has become an operational norm for many registries,<br>
> registrars, and ISPs, what have we learned about how we manage DNSSEC?<br>
><br>
><br>
><br>
> - Do you still submit/accept DS records with Digest Type 1?<br>
> - What is the best practice around key roll-overs?<br>
> - What about Algorithm roll-overs?<br>
> - Do you use and support DNSKEY Algorithms 13-16?<br>
> - How often do you review your disaster recovery procedures?<br>
> - Is there operational familiarity within your customer support<br>
> teams?<br>
> - What operational statistics have we gathered about DNSSEC?<br>
> - Are there experiences being documented in the form of best<br>
> practices,<br>
> or something similar, for transfer of signed zones?<br>
><br>
><br>
><br>
> Activities and issues related to DNSSEC in the DNS Root Zone are also<br>
> desired.<br>
><br>
><br>
><br>
> *3. DNSSEC Deployment Challenges*<br>
><br>
> The program committee is seeking input from those that are<br>
> interested in<br>
> implementation of DNSSEC but have general or particular concerns with<br>
> DNSSEC. In particular, we are seeking input from individuals that<br>
> would be<br>
> willing to participate in a panel that would discuss questions of the<br>
> following nature:<br>
><br>
><br>
><br>
> - Are there any policies directly or indirectly impeding your<br>
> DNSSEC<br>
> deployment? (RRR model, CDS/CDNSKEY automation)<br>
> - What are your most significant concerns with DNSSEC, e.g.,<br>
> complexity,<br>
> training, implementation, operation or something else?<br>
> - What do you expect DNSSEC to do for you and what doesn't it do?<br>
> - What do you see as the most important trade-offs with respect<br>
> to doing<br>
> or not doing DNSSEC?<br>
><br>
><br>
><br>
> *4. Security Panel*<br>
><br>
> The program committee is looking for presentations on DNS, DNSSEC and<br>
> Routing topics that could impact the security and/or stability of the<br>
> internet.<br>
><br>
><br>
><br>
> We are looking for presentations that cover implementation issues,<br>
> challenges, opportunities and best practices for:<br>
><br>
><br>
><br>
> - Emerging threats that could impact the security and/or<br>
> stability of<br>
> the internet<br>
> - DoH and DoT<br>
> - RPKI (Resource Public Key Infrastructure)<br>
> - BGP routing & secure implementations<br>
> - MANRS ( Mutually Agreed Norms for Routing Security)<br>
> - Browser security ? DNS, DNSSEC, DoH<br>
> - EMAIL & DNS related security ? DMARC, DKIM, TLSA, etc?<br>
><br>
><br>
><br>
> If you are interested in participating, please send a brief (1-2<br>
> sentence)<br>
> description of your proposed presentation to<br>
> <a href="mailto:dnssec-security-workshop@icann.org" target="_blank">dnssec-security-workshop@icann.org</a> *by COB Friday, January 21 2022*<br>
><br>
><br>
><br>
> Thank you,<br>
><br>
><br>
><br>
> Kathy and Andrew<br>
><br>
> On behalf of the DNSSEC Workshop Program Committee:<br>
><br>
> Steve Crocker, Shinkuro<br>
><br>
> Mark Elkins, DNS/ZACR<br>
><br>
> Jacques Latour, .CA<br>
><br>
> Russ Mundy, Parsons<br>
><br>
> Ondrej Filip, CZ.NIC<br>
><br>
> Yoshiro Yoneya, JPRS<br>
><br>
> Fred Baker, ISC<br>
><br>
> Dan York, Internet Society<br>
> ------------ próxima parte ------------<br>
> Se ha borrado un adjunto en formato HTML...<br>
> URL:<br>
> <<a href="https://mail.lacnic.net/pipermail/lacnog/attachments/20220112/f2ebeb30/attachment.htm" rel="noreferrer" target="_blank">https://mail.lacnic.net/pipermail/lacnog/attachments/20220112/f2ebeb30/attachment.htm</a>><br>
><br>
> ------------------------------<br>
><br>
> Subject: Pié de página del digest<br>
><br>
> _______________________________________________<br>
> LACNOG mailing list<br>
> <a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
> <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
> Cancelar suscripcion: <a href="mailto:lacnog-unsubscribe@lacnic.net" target="_blank">lacnog-unsubscribe@lacnic.net</a><br>
><br>
><br>
> ------------------------------<br>
><br>
> Fin de Resumen de LACNOG, Vol 169, Envío 12<br>
> *******************************************<br>
><br>
><br>
><br>
> -- <br>
> /Saludos!/<br>
> /Gabriel Gonzalo Zárate./<br>
> /Administrador De Redes Informáticas, Soporte Técnico./<br>
> /CCNA4, MTCNA, MTCRE, MTCTCE. MTCWE/<br>
> /Skype: gabigon.01/<br>
><br>
><br>
> _______________________________________________<br>
> LACNOG mailing list<br>
> <a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
> <a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
> Cancelar suscripcion:<a href="https://mail.lacnic.net/mailman/options/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/options/lacnog</a><br>
------------ próxima parte ------------<br>
Se ha borrado un adjunto en formato HTML...<br>
URL: <<a href="https://mail.lacnic.net/pipermail/lacnog/attachments/20220112/798ec0bd/attachment.htm" rel="noreferrer" target="_blank">https://mail.lacnic.net/pipermail/lacnog/attachments/20220112/798ec0bd/attachment.htm</a>><br>
<br>
------------------------------<br>
<br>
Subject: Pié de página del digest<br>
<br>
_______________________________________________<br>
LACNOG mailing list<br>
<a href="mailto:LACNOG@lacnic.net" target="_blank">LACNOG@lacnic.net</a><br>
<a href="https://mail.lacnic.net/mailman/listinfo/lacnog" rel="noreferrer" target="_blank">https://mail.lacnic.net/mailman/listinfo/lacnog</a><br>
Cancelar suscripcion: <a href="mailto:lacnog-unsubscribe@lacnic.net" target="_blank">lacnog-unsubscribe@lacnic.net</a><br>
<br>
<br>
------------------------------<br>
<br>
Fin de Resumen de LACNOG, Vol 169, Envío 14<br>
*******************************************<br>
</blockquote></div><br clear="all"><br>-- <br><div dir="ltr" class="gmail_signature"><div dir="ltr"><div><div dir="ltr"><div><div dir="ltr"><i><font size="4">Saludos!</font></i><div><i><font size="4">Gabriel Gonzalo Zárate.</font></i></div><div><i><font size="4">Administrador De Redes Informáticas, Soporte Técnico.</font></i></div><div><i><font size="4">CCNA4, MTCNA, MTCRE, MTCTCE. MTCWE</font></i></div><div><i><font size="4">Skype: gabigon.01</font></i></div><div><br></div></div></div></div></div></div></div>