<HTML>
<HEAD>
<TITLE>FW: Creating an IPv6 addressing plan for end users (RIPE)</TITLE>
</HEAD>
<BODY>
<FONT SIZE="2"><FONT FACE="Consolas, Courier New, Courier"><SPAN STYLE='font-size:10pt'>Les comparto un buen documento (abajo descrito en URL) que a muchos de nosotros (directa o indirectamente) será de utilidad. <BR>
<BR>
Saludos,<BR>
Harold.<BR>
</SPAN></FONT></FONT><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>------ Mensaje reenviado<BR>
<B>De: </B>Ray Soucy <<a href="rps@maine.edu">rps@maine.edu</a>><BR>
<B>Fecha: </B>Tue, 15 Mar 2011 14:56:51 -0400<BR>
<B>Para: </B>Brent Sweeny <<a href="sweeny@indiana.edu">sweeny@indiana.edu</a>><BR>
<B>CC: </B>i2 ipv6 wg <<a href="wg-ipv6@internet2.edu">wg-ipv6@internet2.edu</a>><BR>
<B>Asunto: </B>Re: Creating an IPv6 addressing plan for end users (RIPE)<BR>
<BR>
It's a nice document.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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).<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
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. <BR>
<BR>
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.<BR>
<BR>
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.<BR>
<BR>
On Tue, Mar 15, 2011 at 8:39 AM, Brent Sweeny <<a href="sweeny@indiana.edu">sweeny@indiana.edu</a>> wrote:<BR>
</SPAN></FONT><BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'>RIPE sent this to v6-ops, but I expect there's interest in this group too:<BR>
-------------------------------<BR>
Date: Tue, 15 Mar 2011 10:01:17 +0100<BR>
From: Nathalie Trenaman <<a href="nathalie@ripe.net">nathalie@ripe.net</a>><BR>
Subject: Creating an IPv6 addressing plan for end users<BR>
To: <a href="ipv6-ops@lists.cluenet.de">ipv6-ops@lists.cluenet.de</a><BR>
<BR>
Hi all,<BR>
<BR>
In our IPv6 courses, we often get the question: I give my customers a<BR>
/48 (or a /56 or a /52) but they have no idea how to distribute that<BR>
space in their network.<BR>
In December Sander Steffann and Surfnet wrote a manual explaining<BR>
exactly that, in clear language with nice graphics. A very useful<BR>
document but it was in Dutch,<BR>
so RIPE NCC decided to translate that document to English.<BR>
<BR>
Today, we have published that document on our website and we hope this<BR>
document is able to take away some of the fear that end users seem to<BR>
have for these huge blocks.<BR>
You can find this document here:<BR>
<BR>
<a href="http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf">http://www.ripe.net/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf</a><BR>
(PDF)<BR>
<BR>
short URL:<BR>
<a href="http://bit.ly/IPv6addrplan">http://bit.ly/IPv6addrplan</a><BR>
<BR>
We look forward to your feedback, tips and comments.<BR>
<BR>
With kind regards,<BR>
<BR>
Nathalie Trenaman<BR>
RIPE NCC Trainer<BR>
</SPAN></FONT></BLOCKQUOTE><FONT FACE="Calibri, Verdana, Helvetica, Arial"><SPAN STYLE='font-size:11pt'><BR>
<BR>
<BR>
-- <BR>
Ray Soucy<BR>
<BR>
Epic Communications Specialist<BR>
<BR>
Phone: +1 (207) 561-3526<BR>
<BR>
Networkmaine, a Unit of the University of Maine System<BR>
<a href="http://www.networkmaine.net/">http://www.networkmaine.net/</a><BR>
<BR>
<BR>
------ Fin del mensaje reenviado<BR>
</SPAN></FONT>
</BODY>
</HTML>