On Wed, 2 Mar 2011, james woodyatt wrote:
The current revision of the draft contains a normative reference to RFC
4941 but it doesn't seem to have any language in section 2.3 specifying
host behavior that would prevent it from using any other sort of
statelessly autoconfigured addresses that would pose the same problem
for network administrators that privacy addresses do, i.e. make it
difficult to identify authoritatively which host is the originator of
any particular traffic given only the source addresses in the captured
IPv6 headers. It just says, hosts MUST have a conceptual variable that
controls whether they generate temporary addresses. That doesn't
prevent them from generating persistent ones that pose the same problem
for network administrators as RFC 4941 privacy addresses.
In our testing, the only way we found to achieve this was to not announce
any on-net prefix and using the M-flag to make the client ask for DHCPv6
address.
I've asked this before in different fora because I have not been able to
find any RFC text.
Wen an on-link prefix is present and the M-flag is set, RFC4861 says:
M 1-bit "Managed address configuration" flag. When
set, it indicates that addresses are available via
Dynamic Host Configuration Protocol [DHCPv6].
It doesn't say "don't do SLAAC and only get addresses from IPv6". So my
interpretation is that as soon as there is an on-link prefix, hosts will
do SLAAC regardless of M flag 0 or 1.
So let's say I want to disallow SLAAC, I want to hand out addresses using
DHCPv6, but I still want the hosts to be able to talk L2 directly to each
other within the subnet.
How should I configure things when it comes to information in RA and
DHCPv6? If this isn't possible, was this intentional behaviour from the
beginning, that DHCPv6 hosts without SLAAC can't get an on-link prefix but
they must go through the router to talk to each other?
--
Mikael Abrahamsson email: swm...@swm.pp.se
--------------------------------------------------------------------
IETF IPv6 working group mailing list
ipv6@ietf.org
Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
--------------------------------------------------------------------
