Hi, every member of the 6man working group,good day!
I want to describe clearly what this draft is hoping to accomplish.
Please give me a chance.
In some sites, the network administrators want to deploy SLAAC, and just
permit the EUI-64 addresses to communicate with the Internet.They will
do as
On Mon, 2011-03-07 at 19:07 +0800, huabing yu wrote:
(2)Disable the privacy addresses on each host.Why?Because the privacy
addresses is preferred as the source of the outbound IPv6 traffic.
My reading of RFC3484 is that privacy addresses are NOT preferred, but
that it should be possible on a
On Mon, 07 Mar 2011 22:40:45 +1100, Karl Auer wrote：
My reading of RFC3484 is that privacy addresses are NOT preferred, but
that it should be possible on a host to change that preference. See Rule 7
in Section 5 (on page 11):
Rule 7: Prefer public addresses. If SA is a public address and SB is a
On Fri, 04 Mar 2011 15:03:09 -0800
james woodyatt j...@apple.com wrote:
On Mar 4, 2011, at 10:55 AM, RJ Atkinson wrote:
As with audits of financial records, perfection is not required,
but a certain confidence interval IS desired/required/needed.
It seems to me that proper accounting
On Mar 7, 2011, at 6:08 AM, RJ Atkinson wrote:
Again, it is only audit, not full blown accounting or access control
or what not. Perfection is not a requirement here.
On Fri, 04 Mar 2011 15:03:09 -0800, james woodyatt j...@apple.com wrote:
is probably better achieved by enhancing routers
On Mar 7, 2011, at 4:13 AM, huabing yu wrote:
Implementations for which privacy considerations outweigh these application
compatibility concerns MAY reverse the sense of this rule and by default
prefer temporary addresses over public addresses.
This. Application compatibility concerns
On Mar 7, 2011, at 11:44 AM, james woodyatt wrote:
On Mar 7, 2011, at 4:13 AM, huabing yu wrote:
Implementations for which privacy considerations outweigh these application
compatibility concerns MAY reverse the sense of this rule and by default
prefer temporary addresses over public
From: TJ
Sent: Thursday, March 03, 2011 9:59 AM
To: huabing yu
Subject: Re: draft-yhb-6man-ra-privacy-flag-01
Questions:
* 2.3(3.1) - Concern over an attacker forcing a host to drop it's active
privacy addresses?
Reply: It is possible, but the threat is not so serious, so don't worry about
Some of my clients operate pretty large enterprise networks.
Within those networks, they want to avoid using the so-called
privacy IPv6 addresses because of requirements (e.g. the US
HIPAA law) to be able to audit their network, including
auditing precisely which devices are present.
IPv6 SLAAC
On Fri, 4 Mar 2011, Sander Steffann wrote:
Hi,
And on that note, let me hereby register my opposition to the adoption of this
draft as a working group item on the grounds that this change is not
sufficiently useful to justify such a late change to the core protocol
specification.
On 04 Mar 2011, at 11:01 , Sander Steffann wrote:
And existing hosts/implementations will ignore the new flag anyway,
so how can an enterprise 'guarantee' that privacy extensions
will not be used?
As with any proposed change/addition to existing IPv6 specs,
implementation support appears
Mikael Abrahamsson wrote:
% The proposed solution doesn't solve the problem described.
Hmm.
IPv6 addresses formed using any MAC address belonging to a given
node (i.e. in modified EUI-64 form per the RFCs) does entirely
meet the user audit needs for the users I am aware of (and
previously
On Fri, 4 Mar 2011, RJ Atkinson wrote:
IPv6 addresses formed using any MAC address belonging to a given node
(i.e. in modified EUI-64 form per the RFCs) does entirely meet the user
audit needs for the users I am aware of (and previously summarised).
And how do you know the host didn't make
- Original Message -
From: Mikael Abrahamsson swm...@swm.pp.se
To: 6MAN ipv6@ietf.org
Sent: Friday, March 04, 2011 5:23 PM
On Fri, 4 Mar 2011, Sander Steffann wrote:
Hi,
And on that note, let me hereby register my opposition to the adoption of
this draft as a working group item on
On 04 Mar 2011, at 13:10 , Mikael Abrahamsson wrote:
SLAAC is by definion host-controlled.
Existing RA flags control whether SLAAC is allowed
or DHCP is required, so this proposal is not a significant
architectural change either to IPv6 or to RA flag use.
Any proposal to the WG might or
On Fri, 4 Mar 2011, RJ Atkinson wrote:
I hope the situation is more clear now. Thanks for your follow-up
questions and comments.
Well, I still oppose it. Either we have SLAAC and then the host is allowed
to choose any address it sees fit, or we don't.
If an organisation wants to disallow
On Fri, 2011-03-04 at 10:32 -0500, RJ Atkinson wrote:
So at least some of my enterprise network clients would be
very interested in seeing a SLAAC flag be created to inform
end systems that the so-called IPv6 privacy addresses
are NOT to be used with a given routing-prefix advertised
via
On Fri, 2011-03-04 at 17:23 +0100, Mikael Abrahamsson wrote:
I also agree. Let's not change RA more than is absolutely needed. The
problem description sounds exactly like what DHCPv6 was designed to solve.
If you need to track what IPs are used at a given time and by whom, SLAAC
is not the
On Fri, 2011-03-04 at 13:55 -0500, RJ Atkinson wrote:
Existing RA flags control whether SLAAC is allowed
or DHCP is required
I don't think they do. They inform the host about whether SLAAC *should*
be done, or whether DHCP *could* be done, but do not *control* the host
in any way.
If a
On Mar 4, 2011, at 10:55 AM, RJ Atkinson wrote:
As with audits of financial records, perfection is not required,
but a certain confidence interval IS desired/required/needed.
It seems to me that proper accounting of which hosts are using what IPv6
addresses is probably better achieved by
On Mar 4, 2011, at 6:03 PM, james woodyatt wrote:
On Mar 4, 2011, at 10:55 AM, RJ Atkinson wrote:
As with audits of financial records, perfection is not required,
but a certain confidence interval IS desired/required/needed.
It seems to me that proper accounting of which hosts are using
RJ Atkinson wrote:
I'm told that some users already are using implementation-specific
configuration mechanisms (e.g. apparently a MS-Windows Registry
setting) that allow SLAAC, but disallow the privacy extension.
I'm further told that when configured to disable privacy-mode,
such hosts then
Date: Fri, 4 Mar 2011 19:10:36 +0100 (CET)
From: Mikael Abrahamsson swm...@swm.pp.se
SLAAC is by definion host-controlled. You use the term audit in a way I
don't really understand (though I am not a native english speaker so I
could very well be wrong).
If you want to be sure who did what
On Sat, 5 Mar 2011, Yu Hua bing wrote:
IPv6 address hand-out (DHCPv6 is the only one I am aware of for IPv6) plus
something that makes sure user can't source any other traffic, such as the
SAVI-WG functionality IP/MAC address verification schemes.
Hi Mike,
-Original Message-
From: ipv6-boun...@ietf.org [mailto:ipv6-boun...@ietf.org] 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
On Wed, 2 Mar 2011, james woodyatt wrote
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
On Mar 2, 2011, at 5:35 PM, huabing yu wrote:
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
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
On Thu, 3 Mar 2011, Mikael Abrahamsson wrote:
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
29 matches
Mail list logo
