[LAC-TF] FW: Creating an IPv6 addressing plan for end users(RIPE)

JORDI PALET MARTINEZ jordi.palet at consulintel.es
Wed Mar 16 18:50:27 BRT 2011


En general me parece un buen documento, pero he detectado, en una lectura
rapida, varias inconsistencias/errores con los estandares de IPv6.

De todos modos hay que tener en cuenta que solo son ideas. Un buen plan de
direccionamiento requiere el conocimiento muy exhaustivo de la red, de sus
expectativas de crecimiento, etc. El documento no debe entenderse como un
modelo. De hecho, soy de la opinion que, dado que los planes de
direccionamiento de IPv4, muchas veces son deficientes por la agregacion,
falta de direcciones, etc., utilizar como punto de partida el plan de
IPv4, VLANs, etc., no siempre es oportuno, sino que puede ser importante
pensar que el plan de direcccionamiento de IPv6 es la oportunidad para
hacerlo "desde cero" pero muy bien hecho.

De hecho en muchas ocasiones esta es una de las partes mas importantes del
trabajo de un consultor.

Saludos,
Jordi






-----Mensaje original-----
De: Roberto feijoo <rfeijoo at gigared.com.ar>
Responder a: <lactf at lac.ipv6tf.org>
Fecha: Wed, 16 Mar 2011 17:35:48 -0300
Para: <lactf at lac.ipv6tf.org>
Asunto: Re: [LAC-TF] FW: Creating an IPv6 addressing plan for end
users(RIPE)

>Muy buen material, de mucha utilidad.
> 
>Saludos.
> 
>De: lactf-bounces at lacnic.net [mailto:lactf-bounces at lacnic.net] En nombre
>de Arturo Servin
>Enviado el: martes, 15 de marzo de 2011 08:42 p.m.
>Para: lactf at lac.ipv6tf.org
>Asunto: Re: [LAC-TF] FW: Creating an IPv6 addressing plan for end
>users(RIPE)
>
>
> 
> 
>
>            De hecho tengo pensando un par de seminarios virtuales sobre
>direccionamiento, uno es como solicitar recursos a nosotros y el otro es
>sobre planes de direccionamiento. Así que si alguien se anima para el
>segundo (planes de direccionamiento IPv6) me puede enviar un correo y lo
>programamos.
>
> 
>
>Saludos,
>
>-as
>
> 
>On 15 Mar 2011, at 19:47, <alejandro.acosta at bt.com> wrote:
>
>
>
>
>Harold, Lista,
>  Muy bueno el documento. El modo de redacción del documento es
>excelente. Me agrada incluso para una charla.
> 
>Saludos,
> 
>Alejandro,
>
> 
>________________________________________
>
>De: lactf-bounces at lacnic.net [mailto:lactf-bounces at lacnic.net] En nombre
>de Jorge Villa
>Enviado el: Martes, 15 de Marzo de 2011 03:41 p.m.
>Para: lactf at lac.ipv6tf.org
>Asunto: Re: [LAC-TF] {Disarmed} Re: FW: Creating an IPv6 addressing plan
>for end users(RIPE)
>Harold, muy buen aporte. Creo que como complemento habria que agregar
>algunas herramientas para realizar el direccionamiento y gestion de
>direcciones IPv6, tales como:
>
> 
>
>IPplan (http://iptrack.sourceforge.net)
>
>IPv6 Optimal Address Paln and Allocation Tool [Marc Blanchet]
>(http://www.ipv6book.ca/allocation.html)
>
>Arturo, buena informacion complementaria de ese trabajo de Owen y tambien
>es interesante la del Wiki de ARIN
>(http://www.getipv6.info/index.php/IPv6_Addressing_Plans)
>
> 
>
>Saludos,
>
>Jorge
>
>
>----- Original Message -----
>
> 
>
>From: Arturo Servin <mailto:aservin at lacnic.net>
>
>To: lactf at lac.ipv6tf.org
>
>Sent: Tuesday, March 15, 2011 3:37 PM
>
>Subject: {Disarmed} Re: [LAC-TF] FW: Creating an IPv6 addressing plan for
>end users(RIPE)
>
> 
>
> 
>
>El documento es bastante interesante.
>
> 
>
>Aquí hay una presentación con otras recomendaciones de como hacer el plan
>de direccionamiento.
>
> 
>
>http://meetings.apnic.net/__data/assets/pdf_file/0008/23489/Half-Day-Intro
>.pdf
>
>http://meetings.apnic.net/30/program/ipv6
>
> 
>
>Sería interesante saber si la gente está usando (o interesada más) en
>asignaciones secuenciales o por bisección (no estoy seguro que esos sean
>los términos correctos en castellano).
>
> 
>
>Slds,
>
>as
>
> 
>
> 
>
> 
>On 15 Mar 2011, at 16:11, Harold de Dios T. wrote:
>
>
>
>
>Les comparto un buen documento (abajo descrito en URL) que a muchos de
>nosotros (directa o indirectamente) será de utilidad.
>
>Saludos,
>Harold.
>------ Mensaje reenviado
>De: Ray Soucy <rps at maine.edu <x-msg://1067/rps@maine.edu>>
>Fecha: Tue, 15 Mar 2011 14:56:51 -0400
>Para: Brent Sweeny <sweeny at indiana.edu <x-msg://1067/sweeny@indiana.edu>>
>CC: i2 ipv6 wg <wg-ipv6 at internet2.edu
><x-msg://1067/wg-ipv6@internet2.edu>>
>Asunto: Re: Creating an IPv6 addressing plan for end users (RIPE)
>
>It's a nice document.
>
>RFC 3627 is worth mentioning.  126-bit prefixes for point-to-point
>networks are just as easy to use, and with IPv6 there isn't really a
>concern to save space.
>
>In Maine we've been looking into the ability to exploit very large
>address space for subnets and neighbor discovery to perform denial of
>service attacks by causing enough ND solicitations to fill the neighbor
>table for a router (e.g. sweeping through every address in a 64-bit
>prefix) as briefly mentioned in RFC 3756.
>
>Initial results in the lab (if you can call a few routers and a laptop a
>lab) are showing this could be a major problem and become one of the most
>attractive denial of service attacks (I was actually working on this last
>night).
>
>Because of this, we're updating our message to not only encourage, but
>also recommend the use of 126-bit prefixes for any point-to-point network.
>
>We have also adjusted our recommendation for LAN addressing to allocate
>64-bit prefixes, but if possible (e.g. SLAAC is not being used), use a
>subset of the prefix with an appropriate size to limit the impact of such
>an attack until better security controls are available.
>
>For example, you could allocate 2001:db8:0:1234::/64 for a network, but
>only define it on the gateway as 2001:db8:0:1234::/120 (256).  This helps
>to mitigate the usefulness of the attack, but maintains the flexibility
>to migrate to a 64-bit prefix once better controls are in place.
>
>We also position SLAAC as a less desirable option for a corporate
>network. DHCPv6 was perceived to be "wrong" by much of the IPv6
>community, mainly due to lack of client implementation; but for the
>enterprise this level of control is highly desirable, especially for a
>phased deployment of IPv6.
>
>Thankfully, Windows (Vista), Mac OS X (Lion), and most Linux
>distributions now have mature DHCPv6 client implementations, making
>DHCPv6 a more than viable option for IPv6 deployment.  It also helps
>avoid IPv6 being used by hosts with less-than-complete implementations as
>most systems that include DHCPv6 have fairly stable and mature IPv6
>implementations.
>
>I don't think anyone has written an RFC to describe how routers should
>construct the neighbor table (would love to know if that is not the
>case), but it would be nice to see something along the lines of not
>expiring known entries if the table is full formalized as an
>implementation guideline, or perhaps added as a security feature.
>
>On Tue, Mar 15, 2011 at 8:39 AM, Brent Sweeny <sweeny at indiana.edu
><x-msg://1067/sweeny@indiana.edu>> wrote:
>
>
>RIPE sent this to v6-ops, but I expect there's interest in this group too:
>-------------------------------
>Date: Tue, 15 Mar 2011 10:01:17 +0100
>From: Nathalie Trenaman <MailScanner ha detectado un posible intento de
>fraude desde "x-msg:" nathalie at ripe.net <x-msg://1067/nathalie@ripe.net>>
>Subject: Creating an IPv6 addressing plan for end users
>To: ipv6-ops at lists.cluenet.de <x-msg://1067/ipv6-ops@lists.cluenet.de>
>
>Hi all,
>
>In our IPv6 courses, we often get the question: I give my customers a
>/48 (or a /56 or a /52) but they have no idea how to distribute that
>space in their network.
>In December Sander Steffann and Surfnet wrote a manual explaining
>exactly that, in clear language with nice graphics. A very useful
>document but it was in Dutch,
>so RIPE NCC decided to translate that document to English.
>
>Today, we have published that document on our website and we hope this
>document is able to take away some of the fear that end users seem to
>have for these huge blocks.
>You can find this document here:
>
>http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6_a
>ddr_plan4.pdf
>(PDF)
>
>short URL:
>http://bit.ly/IPv6addrplan
>
>We look forward to your feedback, tips and comments.
>
>With kind regards,
>
>Nathalie Trenaman
>RIPE NCC Trainer
>
>
>
>-- 
>Ray Soucy
>
>Epic Communications Specialist
>
>Phone: +1 (207) 561-3526
>
>Networkmaine, a Unit of the University of Maine System
>http://www.networkmaine.net/
>
>
>------ Fin del mensaje reenviado
>
>_______________________________________________
>LACTF mailing list
>LACTF at lacnic.net
>https://mail.lacnic.net/mailman/listinfo/lactf
>
>
>PREVENCIÓN ES SALUD. TODOS PODEMOS LOGRARLO.
> 
>
>________________________________________
>
> 
>
>_______________________________________________
>LACTF mailing list
>LACTF at lacnic.net
>https://mail.lacnic.net/mailman/listinfo/lactf
>
>
>PREVENCIÓN ES SALUD. TODOS PODEMOS LOGRARLO.
>
>
>_______________________________________________
>LACTF mailing list
>LACTF at lacnic.net
>https://mail.lacnic.net/mailman/listinfo/lactf
>
>
> 
>
>_______________________________________________
>LACTF mailing list
>LACTF at lacnic.net
>https://mail.lacnic.net/mailman/listinfo/lactf



**********************************************
IPv4 is over
Are you ready for the new Internet ?
http://www.consulintel.es
The IPv6 Company

This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited.






More information about the LACTF mailing list