Re: Privacy Bit in the policy table Re: rfc3484-bis issue 2: privacy addresses

Arifumi Matsumoto <arifumi@nttv6.net> Tue, 26 July 2011 20:47 UTC

Return-Path: <arifumi@nttv6.net>
X-Original-To: ipv6@ietfa.amsl.com
Delivered-To: ipv6@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id E725D11E80B7 for <ipv6@ietfa.amsl.com>; Tue, 26 Jul 2011 13:47:07 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.599
X-Spam-Level:
X-Spam-Status: No, score=-102.599 tagged_above=-999 required=5 tests=[AWL=-0.001, BAYES_00=-2.599, HTML_MESSAGE=0.001, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id w4dV+rAFGlvJ for <ipv6@ietfa.amsl.com>; Tue, 26 Jul 2011 13:47:06 -0700 (PDT)
Received: from leo.nttv6.net (leo.nttv6.net [192.47.162.93]) by ietfa.amsl.com (Postfix) with ESMTP id 16C5911E80AF for <ipv6@ietf.org>; Tue, 26 Jul 2011 13:47:00 -0700 (PDT)
Received: from [127.0.0.1] (localhost.nttv6.net [127.0.0.1]) by leo.nttv6.net (8.14.4/8.14.4) with ESMTP id p6QKjhOM058266 for <ipv6@ietf.org>; Wed, 27 Jul 2011 05:45:44 +0900 (JST) (envelope-from arifumi@nttv6.net)
From: Arifumi Matsumoto <arifumi@nttv6.net>
Mime-Version: 1.0 (Apple Message framework v1084)
Content-Type: multipart/alternative; boundary="Apple-Mail-13-545977957"
Subject: Re: Privacy Bit in the policy table Re: rfc3484-bis issue 2: privacy addresses
Date: Wed, 27 Jul 2011 05:45:43 +0900
In-Reply-To: <8CCFAD4E-E1C8-4B23-80C0-4177AA9E227C@nttv6.net>
To: ipv6@ietf.org
References: <5440EBA2-DDA9-46B9-B417-68148C6382CD@ecs.soton.ac.uk>, <EMEW3|8207aa7a90ea092ae95b4c4699c1b73an5RFcn03tjc|ecs.soton.ac.uk|5440EBA2-DDA9-46B9-B417-68148C6382CD@ecs.soton.ac.uk> <4FD1E7CD248BF84F86BD4814EDDDBCC1513D42BE0C@EUSAACMS0703.eamcs.ericsson.se> <971D6F0B-9109-42EC-ABE0-1A5E3AB99741@nttv6.net> <8CCFAD4E-E1C8-4B23-80C0-4177AA9E227C@nttv6.net>
Message-Id: <BA2950AF-8A83-400B-808B-F18F87DF4B96@nttv6.net>
X-Mailer: Apple Mail (2.1084)
X-BeenThere: ipv6@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: "IPv6 Maintenance Working Group \(6man\)" <ipv6.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/ipv6>, <mailto:ipv6-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/ipv6>
List-Post: <mailto:ipv6@ietf.org>
List-Help: <mailto:ipv6-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/ipv6>, <mailto:ipv6-request@ietf.org?subject=subscribe>
X-List-Received-Date: Tue, 26 Jul 2011 20:47:08 -0000

And the corresponding distributing protocol format was already there in the previous version. :)

http://tools.ietf.org/html/draft-ietf-6man-addr-select-opt-00

We just dropped this bit in the latest -01 version.

Best regards,

On 2011/07/27, at 5:37, Arifumi Matsumoto wrote:

> All,
> 
> let me re-post the candidate extended policy table format below.
> 
>> For example, if we extend the policy table to have Privacy column like below,
>> 
>>        Prefix        Precedence Label  Privacy
>>        ::1/128               60     0      OFF
>>        fc00::/7              50     1      OFF
>>        ::/0                  40     2       ON
>>        ::ffff:0:0/96         30     3      OFF
>>        2002::/16             20     4      OFF
>>        2001::/32             10     5      OFF
>>        ::/96                  1    10      OFF
>>        fec0::/10              1    11      OFF
>> 
>> a temporary address will be used only when a destination address longest matches ::/0 entry in this table.
> 
> This is rather simple form of privacy extension control.
> Only the destination prefix determines whether the privacy extension for the source prefix should be used or not.
> In this case, even if a host has multiple prefixes, the source prefix does not have effect on it.
> 
> It seems to me that this satisfies the needs we discussed just now.
> 
> 
> If we want to use both destination and source prefixes to control the usage of privacy extension,
> we need additional mechanisms like Label.
> 
> 
> Or, any other implementation form ?
> 
> 
> On 2011/06/29, at 14:28, Arifumi Matsumoto wrote:
> 
>> Hi Suresh,
>> 
>> On 2011/06/29, at 4:32, Suresh Krishnan wrote:
>> 
>>> Hi Tim,
>>> There is already a programmatic switch for this in RFC5014 (IPV6_PREFER_SRC_TMP/IPV6_PREFER_SRC_PUBLIC). Applications wishing to override system policy may do so by using this API.
>> 
>> Yes. An application can control which kind of address to choose by that API.
>> 
>> Our question is whether we should have a way to configure host-wide policy about when to use temporary address or not.
>> 
>> For example, if we extend the policy table to have Privacy column like below,
>> 
>>        Prefix        Precedence Label  Privacy
>>        ::1/128               60     0      OFF
>>        fc00::/7              50     1      OFF
>>        ::/0                  40     2       ON
>>        ::ffff:0:0/96         30     3      OFF
>>        2002::/16             20     4      OFF
>>        2001::/32             10     5      OFF
>>        ::/96                  1    10      OFF
>>        fec0::/10              1    11      OFF
>> 
>> a temporary address will be used only when a destination address longest matches ::/0 entry in this table.
>> 
>> Please note that this is about address selection and not about whether a host should generate temporary address for a received RA prefix.
>> 
>> As Tim mentioned, if we agree to have this kind of new tool, after that, we should discuss about policy distribution of this added column.
>> 
>> Best regards,
>> 
>>> 
>>> Cheers
>>> Suresh
>>> 
>>> ________________________________________
>>> From: ipv6-bounces@ietf.org [ipv6-bounces@ietf.org] On Behalf Of Tim Chown [tjc@ecs.soton.ac.uk]
>>> Sent: Tuesday, June 28, 2011 10:38 AM
>>> To: ipv6@ietf.org
>>> Subject: rfc3484-bis issue 2: privacy addresses
>>> 
>>> The second issue is surrounding IPv6 privacy addresses (RFC4941).
>>> 
>>> Section 3.1 of RFC4941 states:
>>> "this document assumes that when a node initiates outgoing
>>> 
>>> communication, temporary addresses can be given preference over
>>> public addresses when the device is configured to do so.
>>> [ADDR_SELECT<http://tools.ietf.org/html/rfc4941#ref-ADDR_SELECT>] mandates implementations to provide a mechanism, which
>>> allows an application to configure its preference for temporary
>>> addresses over public addresses.  It also allows for an
>>> implementation to prefer temporary addresses by default, so that the
>>> connections initiated by the node can use temporary addresses without
>>> requiring application-specific enablement."
>>> 
>>> 
>>> This suggests there should be a mechanism for a host to choose whether to use temporary or public addresses.  RFC3484 talks about preferring temporary or public addresses in Rule 7.  In practice, implementations seem to prefer privacy addresses (to initiate connections) when they are enabled.  At the moment, RFC3484-bis says nothing different or new for privacy addresses.
>>> 
>>> 
>>> Should there be a configuration switch for privacy extensions somewhere, and if so how is this controlled - locally or via a policy distribution mechanism?
>>> 
>>> 
>>> In IETF80, the suggestion to 'tell' a host whether it should use privacy addresses by using an RA flag was not well received. There was at least one comment at IETF80 that the privilege to carry the traffic and the privilege to turn on/off the privacy extension should be different.
>>> 
>>> 
>>> Comments please.
>>> 
>>> 
>>> Tim
>>> 
>>> --------------------------------------------------------------------
>>> IETF IPv6 working group mailing list
>>> ipv6@ietf.org
>>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>>> --------------------------------------------------------------------
>> 
>> 
>> --
>> Arifumi Matsumoto
>> NGN System Architecture Project
>> NTT Service Integration Laboratories
>> E-mail: arifumi@nttv6.net
>> TEL +81-422-59-3334 FAX +81-422-59-6364
>> 
>> --------------------------------------------------------------------
>> IETF IPv6 working group mailing list
>> ipv6@ietf.org
>> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
>> --------------------------------------------------------------------
> 
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> ipv6@ietf.org
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------