This is really just for "Interface IDs". It's basically saying that if you're going to use Interface IDs and Stateless Address Autoconfiguration (SLAAC) and all that stuff you need to be using 64bit IIDs. That's it.<br>
<br>IIDs != IPv6 addresses, just one way to form them.<br><br>You can statically assign dead:beef, 1337:cafe, ... and put then in DNS all you want. You can have /80s, /112s, whatever.<br><br>Also: 3513 was obsoleted by <a href="http://tools.ietf.org/html/rfc4291">http://tools.ietf.org/html/rfc4291</a> (one reason I prefer the <a href="http://tools.ietf.org">tools.ietf.org</a> links).<br>
<br><div class="gmail_quote">2009/6/2 Ryan Harden <span dir="ltr"><<a href="mailto:hardenrm@uiuc.edu">hardenrm@uiuc.edu</a>></span><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
-----BEGIN PGP SIGNED MESSAGE-----<br>
Hash: SHA1<br>
<br>
In a conversation with my DNS admin, he brought up the fact that RFC3513<br>
seems to forbid using a subnet size other than /64 AS WELL as using<br>
anything other than EUI-64 to determine the host ID of an address.<br>
<br>
In RFC3513: <a href="http://www.ietf.org/rfc/rfc3513.txt" target="_blank">http://www.ietf.org/rfc/rfc3513.txt</a><br>
Section 2.5.4 Paragraph 2:<br>
<br>
"All global unicast addresses other than those that start with binary<br>
000 have a 64-bit interface ID field (i.e., n + m = 64), formatted as<br>
described in section 2.5.1. Global unicast addresses that start with<br>
binary 000 have no such constraint on the size or structure of the<br>
interface ID field."<br>
<br>
Given 2001::/8 and 2620::/8 fit this criteria, it seems that the<br>
interface ID or HOST portion of an IPv6 address must be 64-bits long and<br>
formatted in accordance to section 2.5.1.<br>
<br>
Section 2.5.1 Paragraph 3:<br>
"For all unicast addresses, except those that start with binary value<br>
000, Interface IDs are required to be 64 bits long and to be<br>
constructed in Modified EUI-64 format."<br>
<br>
The way I read it seems to imply staticly assigned IPv6 addresses are<br>
forbidden. Which puts a damper on securing the coveted DEAD:BEEF address<br>
for my workstation.<br>
<br>
I have not understood this to be true and have experienced practice<br>
where this is absolutely not met. I see /126s for p-t-p links, static<br>
DNS servers, static web servers, etc, etc.<br>
<br>
Am I reading this wrong? Is this RFC out of date? What is the intent of<br>
these sections in the RFC? At the very least they are unclear and/or<br>
misleading.<br>
<br>
RFC3587 Section 3, Paragraph 2 seems to confirm this:<br>
"[ARCH] also requires that all unicast addresses, except those that<br>
start with binary value 000, have Interface IDs that are 64 bits long<br>
and to be constructed in Modified EUI-64 format."<br>
<br>
/Ryan<br>
- --<br>
Ryan M. Harden, BS, KC9IHX Office: 217-265-5192<br>
CITES - Network Engineering Cell: 630-363-0365<br>
2130 Digital Computer Lab Fax: 217-244-7089<br>
1304 W. Springfield email: <a href="mailto:hardenrm@illinois.edu">hardenrm@illinois.edu</a><br>
Urbana, IL 61801<br>
<br>
University of Illinois at Urbana/Champaign<br>
University of Illinois - ICCN<br>
-----BEGIN PGP SIGNATURE-----<br>
Version: GnuPG v1.4.9 (GNU/Linux)<br>
Comment: Using GnuPG with Fedora - <a href="http://enigmail.mozdev.org" target="_blank">http://enigmail.mozdev.org</a><br>
<br>
iEYEARECAAYFAkoldhEACgkQtuPckBBbXbqycACgu7wfR1jM9c9VyzZU4b2rUhp7<br>
5FAAoME1yBwmRm/DuZ8jeZuSGluWc+da<br>
=9mMt<br>
-----END PGP SIGNATURE-----<br>
</blockquote></div><br>