randy/draft-classless6
1
0
Fork 0
Code Issues Pull requests Projects Releases Packages Wiki Activity Actions

Augment security considerations

Browse source
This commit is contained in:
Fernando Gont 2017-05-06 09:59:02 +02:00
parent 51a9061ad4
commit 01518674f0
1 changed files with 19 additions and 10 deletions
Download patch file Download diff file Expand all files Collapse all files

29
draft-nbourbaki-6man-classless-ipv6.xml
View file

@ -134,17 +134,17 @@ don't een need /64 for SLAAC, except for backward compatibility. (*)
-->
</section>
<section anchor="notes" title="Notes and Recommendations">
<section anchor="notes" title="Recommendations">
<t>For historical reasons, when a prefix is needed on a link,
barring other considerations, a /64 is traditional <xref
<t>For backwards compatibility, when a prefix is needed on a link,
barring other considerations, a /64 is RECOMENDED <xref
target="RFC7136"/>.</t>
<t>The length of the prefix identifier in Stateless Address
AutoConfiguration, <xref target="RFC4862"/> is a parameter; its
<t>The length of the Interface Identifier in Stateless Address
AutoConfiguration <xref target="RFC4862"/> is a parameter; its
length needs to be sufficient for effective randomization for
privacy reasons. For example, a /48 might be sufficient. But
operationally we recommend, barring strong considerations to the
operationally we RECOMMEND, barring strong considerations to the
contrary, using 64-bits for SLAAC in order not to discover bugs
where 64-bits was hard-coded, and to favor portability of devices
and operating systems.</t>
@ -153,7 +153,9 @@ don't een need /64 for SLAAC, except for backward compatibility. (*)
should not operate with different interface identfier lengths on
different physical interfaces. Thus a correct implementation of
SLAAC must in fact allow for any length of prefix, with the value
being parameterised per interface.</t>
being parameterised per interface. For instance, the Interface Identifier length in the recommended
(see <xref target="RFC8064"/>) algorithm for selecting stable
interface identifiers <xref target="RFC7217"/> is a parameter, rather than a hardcoded value.</t>
<t>NOTE: should we comment on the fact that at least Linux and
Windows seem to assume that the default prefix is /64 in the
@ -163,10 +165,16 @@ don't een need /64 for SLAAC, except for backward compatibility. (*)
<section anchor="security" title="Security Considerations">
<t>This document has no known security impact, assuming that
user devices use an unpredictable interface identifier
<xref target="RFC7721"/> for privacy.</t>
<t>Assumming that nodes employ unpredictable interface identifiers <xref target="RFC7721"/>, the subnet size may have an
impact on some security and privacy properties of a network. Namely, the smaller the subnet size, the more feasible it
becomes to perform IPv6 address scans <xref target="RFC7707"/> <xref target="RFC7721"/>.
However, that for some specific subnets (such as point to point links), this may be less of an issue.</t>
<t>On the other hand, we assume that a number of IPv6 implementations fail to enforce limits on the size of some of the data
structures they employ for communicating with neighboring nodes, such as the Neighbor Cache. In such cases, the use of smaller
subnets essentially enforces an operational limit on such data structures, thus helping mitigate some pathological behaviors
(such as Neighbor Cache Exhaustion attacks).</t>
<!-- [fgont] Still need to add references here... e.g. to Joel's RFC -->
</section>
<section anchor="iana" title="IANA Considerations">
@ -210,6 +218,7 @@ don't een need /64 for SLAAC, except for backward compatibility. (*)
<?rfc include="reference.RFC.6164"?>
<?rfc include="reference.RFC.3587"?>
<?rfc include="reference.RFC.4632"?>
<?rfc include="reference.RFC.7707"?>
<?rfc include="reference.RFC.7136"?>
<?rfc include="reference.RFC.7721"?>
<?rfc include="reference.I-D.hinden-6man-rfc2464bis"?>