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

Wed Mar 16 17:35:48 BRT 2011

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.p
df

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 < <x-msg://1067/nathalie@ripe.net> MailScanner ha
detectado un posible intento de fraude desde "x-msg:" nathalie at 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_add
r_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

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mail.lacnic.net/pipermail/lactf/attachments/20110316/cf4155af/attachment.html>