Subject: draft-yhb-6man-ra-privacy-flag-01

From: huabing yu <[email-masked]>
Date: Thu, 3 Mar 2011 09:35:22 +0800

Hi

I updated the draft "DisablePrivacy Flag of Prefix-information Option in the
Router Advertisement". The flag's name changed from
Privacy to DisablePrivacy.The link is
http://datatracker.ietf.org/doc/draft-yhb-6man-ra-privacy-flag/?include_text=1
.

Do you have some advice?

Yu Hua bing

---

From: james woodyatt <[email-masked]>
Date: Wed, 02 Mar 2011 18:39:07 -0800

> Do you have some advice?

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.

I think some wordsmithing is still required here.  I have no useful advice for how to do that because I'm not entirely sure I understand what this draft is hoping to accomplish, much less how it hopes to do it.

--
james woodyatt <[email-masked]>
member of technical staff, core os networking

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Mar 2011 03:57:53 +0100 (CET)

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: [email-masked]

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 3 Mar 2011 05:07:27 +0100 (CET)

On Thu, 3 Mar 2011, Mikael Abrahamsson wrote:

> 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?

I have received help off-list for this, evidently there is a Cisco option 
called "no-autoconf" that sets the A bit to 0 on the on-link prefix 
announcement, that does what I was asking for.

Thanks!

---

From: Suresh Krishnan <[email-masked]>
Date: Thu, 3 Mar 2011 13:28:21 -0500

Hi Mike,

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On 
> Behalf Of Mikael Abrahamsson
> Sent: Wednesday, March 02, 2011 6:58 PM
> To: james woodyatt
> Cc: 6MAN
> Subject: Re: draft-yhb-6man-ra-privacy-flag-01
> 
> > 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.
> 
> 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.

No. This is not the case. We can have on-link prefixes that are not used for SLAAC. All you have to do is set the L flag to 1 and the A flag to 0 in the PIO. This means that the host will not use this prefix to do SLAAC.

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

This is possible using the link-local addresses.

> 
> 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?

This is perfectly doable within the current specs. This is what I would advise. 

Let's say the DHCPv6 addresses are formed using the prefix P1::/64. All you need to do is to advertise the prefix P1 in a PIO of an RA with L=1 and A=0. This will let hosts communicate directly without going through the router and it will also disable SLAAC.

Thanks
Suresh