[lacnog] [LAC-TF] IPv6, el principio E2E, e IPv6 EH insertion

[Rogerio Mariano]

Tomás, Mira este draft:  draft-previdi-6man-segment-routing-header-05 Yo creo que SR esta dentro de RFC 2460 y SRH y SR6-Label-Prefix se identifican dentro de un segmento, sin la necesidad de una signañizaton, la función de la realización, es como si fueran un LDPv6!  Un abrazo,Rogerio Mariano    

---Sent from Boxer | http://getboxer.com

On 7 de novembro de 2016 12:40:16 BRST, Tomas Lynch <tomas.lynch en gmail.com> wrote:2016-11-07 9:26 GMT-05:00 Christian O'Flaherty <christian.oflaherty en gmail.com>:> I like source routing and I think it's a good idea, but it only makes > sense to me on the MPLS domain. I'd like to see a killer application > for SR on IPv6. >  Coincido con Luis... lo que se se usa para traffic engineering en MPLS (MPLS-TE) no escala y no es cómodo. SR parece una muy buena solución a ese problema... No se en que caso se usaría con EH en IPv6... Alguien sabe cual es la utilidad?  Christian   Según tengo entendido Segment Routing para IPv4 agrega en el ingreso la pila de etiquetas MPLS que serán utilizadas en el camino de ingreso hacia el ingreso. Entonces con IPv6, y debido a que no existe un "LDPv6", quieren utilizar los Extension Headers. ¿Cómo está la estandarización de "LDPv6"? ¿No es más fácil concentrarse en eso que armar a Frankenstein?     > Luis > > 2016-11-07 0:05 GMT-02:00 Fernando Gont <fgont en si6networks.com>: >> Estimados, >> >> Cuestiones interesantes: >> >> En mas de una oportunidad deben haber escuchado aseveraciones varias >> referidas al principio End-To-End (E2E) e IPv6. De manera simple, en las >> redes IPv4 se modifica constantemente los paquetes IPv4, principalmente >> debido al uso de NATs. En principio, tales modificaciones "en vuelo" a >> los paquetes pueden resultar en problemas dificiles de detectar y >> solucionar (ya que el paquete que vemos en un punto de la red es puede >> ser muy distinto al que se ve en otro punto de la red). >> >> Uno de los argumentos en favor de IPv6 tradicionalmente ha sido que >> justamente nos iba a librar de dicha cuestion, ya que, en principio no >> iba a exitir NAT con IPv6 (esto en la practica ya no es así, pero eso es >> otra historia). >> >> Lo curioso del caso es algo que ha venido aconteciendo recientemente en >> el ambito de IETF (precisamente en el 6man wg, grupo encargado de la >> estandarización de IPv6): En dicho grupo actualmente se esta proponiendo >> la implementacion de una tecnologia (segment routing), que se desea que >> *inserte* encabezados de extension (EHs) en el punto de ingreso a la >> red, y se los remueva en el punto de ingreso. (Si te preguntas de que se >> trata la tecnologia, es algo asi como permitir "source routing", con la >> diferencia que en este caso el "camino" lo elige la red en el punto de >> ingreso). >> >> Esa cuestión de insertar encabezados va en contra de IPv6 tal como se lo >> conoce, y puede generar una cantidad de problemas (romper IPsec, >> Path-MTU Discovery), y otras tantas. Asi y y todo, el tema se esta >> dscutiendo en el grupo. Peor aun, pareciera como que se buscara generar >> una ambiguedad en esta materia (donde no la hay), basicamente abriendo >> el camino para que luego cosas tales como la insercion de EHs pueda >> estandarizarse. (El motivador de esta cuestión es este documento: >> https://datatracker.ietf.org/ipr/2421/) >> >> P.S.: <https://youtu.be/By83GP_tIJE?t=16s> >> >> Saludos, >> -- >> Fernando Gont >> SI6 Networks >> e-mail: fgont en si6networks.com >> PGP Fingerprint: 6666 31C6 D484 63B2 8FB1 E3C4 AE25 0D55 1D4E 7492 >> >> >> >> >> _______________________________________________ >> LACNOG mailing list >> LACNOG en lacnic.net >> https://mail.lacnic.net/mailman/listinfo/lacnog >> Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog > _______________________________________________ > LACNOG mailing list > LACNOG en lacnic.net > https://mail.lacnic.net/mailman/listinfo/lacnog > Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog   _______________________________________________ LACTF mailing list LACTF en lacnic.net https://mail.lacnic.net/mailman/listinfo/lactf Cancelar suscripcion: lactf-unsubscribe en lacnic.net        _______________________________________________ LACNOG mailing list LACNOG en lacnic.net https://mail.lacnic.net/mailman/listinfo/lacnog Cancelar suscripcion: https://mail.lacnic.net/mailman/options/lacnog     
------------ próxima parte ------------
Se ha borrado un adjunto en formato HTML...
URL: <https://mail.lacnic.net/pipermail/lacnog/attachments/20161107/c2d08121/attachment.html>