[mif-arch-dt] Text for PvD considerations in configuration sources
Suresh Krishnan <suresh.krishnan@ericsson.com> Mon, 21 October 2013 13:59 UTC
Return-Path: <suresh.krishnan@ericsson.com>
X-Original-To: mif-arch-dt@ietfa.amsl.com
Delivered-To: mif-arch-dt@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id A2FA811E856A for <mif-arch-dt@ietfa.amsl.com>; Mon, 21 Oct 2013 06:59:50 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: -102.407
X-Spam-Level:
X-Spam-Status: No, score=-102.407 tagged_above=-999 required=5 tests=[AWL=0.193, BAYES_00=-2.599, USER_IN_WHITELIST=-100]
Received: from mail.ietf.org ([12.22.58.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id uuqIAe27tTzV for <mif-arch-dt@ietfa.amsl.com>; Mon, 21 Oct 2013 06:59:43 -0700 (PDT)
Received: from usevmg21.ericsson.net (usevmg21.ericsson.net [198.24.6.65]) by ietfa.amsl.com (Postfix) with ESMTP id 6C13B11E8520 for <mif-arch-dt@ietf.org>; Mon, 21 Oct 2013 06:56:57 -0700 (PDT)
X-AuditID: c6180641-b7fe28e000000d82-e9-526532a87388
Received: from EUSAAHC002.ericsson.se (Unknown_Domain [147.117.188.78]) by usevmg21.ericsson.net (Symantec Mail Security) with SMTP id 91.06.03458.8A235625; Mon, 21 Oct 2013 15:56:57 +0200 (CEST)
Received: from [142.133.113.185] (147.117.188.135) by smtps-am.internal.ericsson.com (147.117.188.78) with Microsoft SMTP Server (TLS) id 14.2.328.9; Mon, 21 Oct 2013 09:56:56 -0400
Message-ID: <526531F3.8020105@ericsson.com>
Date: Mon, 21 Oct 2013 09:53:55 -0400
From: Suresh Krishnan <suresh.krishnan@ericsson.com>
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:17.0) Gecko/20130803 Thunderbird/17.0.8
MIME-Version: 1.0
To: Dmitry Anipko <Dmitry.Anipko@microsoft.com>
X-Enigmail-Version: 1.5.2
Content-Type: text/plain; charset="ISO-8859-1"
Content-Transfer-Encoding: 7bit
X-Originating-IP: [147.117.188.135]
X-Brightmail-Tracker: H4sIAAAAAAAAA+NgFmphluLIzCtJLcpLzFFi42KZXLrHT3elUWqQwYv/nBYHVzQzWbSe7GB1 YPJYsuQnk0frjr/sAUxRXDYpqTmZZalF+nYJXBlvLv1nKThgVtH2yb6B8aVOFyMnh4SAiUTX yxMsELaYxIV769m6GLk4hASOMkoc/nOSCcLZyShx8MFWJpAqXgFtiVWHb4N1sAioSkz+uI4V xGYDmrRh52ewGlGBMIn75w5B1QtKnJz5BKxeREBfonvVPHYQm1nAUGL79ddgvcICthKP589g hbhCUmLbomNQNXoSU662MELY8hLb385hBrGFBDQltq75DlTPAVSvLLFjRuIERsFZSLbNQtI9 C0n3AkbmVYwcpcWpZbnpRoabGIEheUyCzXEH44JPlocYpTlYlMR5v7x1DhISSE8sSc1OTS1I LYovKs1JLT7EyMTBKdXAmBF3UET8oKTze5mfYaWO25dXpt/xrrO1jjHz1Vp0Ryk7clX5I1+2 X7zNjTfTfY+G3vHxzC19c8CpJ0J/WrNKY8edy0tuzd35pSl7fum/RL3p7q1N7Qv7mf5b5HZO WbvvSuwCwchrk/OLdmW0PvvWpJOUzhBd9sfi59x9j8pmyW9f/fXwx53blFiKMxINtZiLihMB uPoUTxcCAAA=
Cc: "mif-arch-dt@ietf.org" <mif-arch-dt@ietf.org>
Subject: [mif-arch-dt] Text for PvD considerations in configuration sources
X-BeenThere: mif-arch-dt@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: MIF Architecture Design Team mailing list <mif-arch-dt.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/mif-arch-dt>
List-Post: <mailto:mif-arch-dt@ietf.org>
List-Help: <mailto:mif-arch-dt-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/mif-arch-dt>, <mailto:mif-arch-dt-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 21 Oct 2013 13:59:50 -0000
Hi Dmitry, Here is the revised text based on our last meeting. We would also like to propose a change to Section 2.1 (at the end of this message). Thanks Suresh, Jouni and Shwetha Conveying PVD information using DHCPv6 and Router Advertisements DHCPv6 and Router Advertisements are the two most common methods of configuring hosts and they would need to be extended to convey explicit PVD information. There are several things that need to be considered before finalizing a mechanism to augment DHCPv6 and RAs with PvD information. * Separate Messages or One Message When information from several PVDs is available at the same configuration source, there are two possibilities regarding how to send these out. One way is to send information from different provisioning domains in separate messages. The other is to combine information from several PVDs onto one message. The latter method has the advantage of being more efficient but could have issues due to authentication and authorization issues as well as potential issues with accommodating common information and information not tagged with any PVD information. * Securing the PVD information DHCPv6 and RAs both provide some form of authentication that ensures the identity of the source as well as the integrity of the contents that have been secured. While this is useful, the authenticity of the information provides no information whether the configuration source is actually allowed to provide information from a given PVD. In order to do be able to do this, there must be a mechanism for the owner of the PVD to attach some form of authorization token to the configuration information that is delivered. * Backward compatibility The extensions to RAs and DHCPv6 should be defined in such a manner than unmodified hosts (i.e. hosts not aware of PvDs) will continue to function as well as they did before the PvD information got added. This could imply that some information may need to be duplicated in order to be conveyed to legacy hosts. Similarly PvD aware hosts need to be able to handle legacy configuration sources which do not provide PvD information. There are also several initiatives ongoing that are aimed at adding some form of additional information to prefixes [refs to draft-bhandari and draft-korhonen] and any new mechanism should try to consider co-existence with these existing mechanisms. * Selective propagation When a configuration source has information regarding several PvDs it is not clear whether it should provide information about all of them to any host that requests info from it. While it may be reasonable in some cases, this might become an unreasonable burden once the number of PvDs starts increasing. One way to restrict the propagation of useless information is for the host to select the PvD information they desire in their request to the configuration source. One way this could be accomplished is by using an ORO with the PvDs that are of interest. The configuration source can then respond with only the requested information. By default, a configuration source SHOULD provide information related to all provisioning domains without expecting the client to select the PvD(s) it requires. This is necessary to ensure that hosts that do not support requesting selective PvD information will continue to work. Also note that IPv6 neighbor discovery does not provide any functionality analogous to the DHCPv6 ORO. In this case, when a host receives PvD information it does not require, the information can simply be discarded. Also, in constrained networks such as LLNs, the amount of configuration information needs to be restricted to ensure that the load on the hosts is bearable while keeping the information identical across all the hosts. In case selective propogation is required, some form of PvD discovery mechanism needs to be specified so that hosts/applications can be pre-provisioned to request a specific PvD. Alternately, the set of PvDs that the network can provide to the host can be propogated to the host using RAs or stateless DHCPv6. The discovery mechanism may potentially support the discovery of available PvDs on a per-host basis. * Retracting/updating PvD information After the PvD information is provided to the host it may be outdated or updated with newer information before the hosts would normally request updates. Thos would require the mchanism to be able to update and/or withdraw all (or some subset) of information related to a given PvD. For efficiency reasons, there should be a way to specify that all the information from the PvD needs to be reconfigured instead of individually updating each item associated with the PvD. Conveying configuration information using IKEv2 Internet Key Exchange protocol version 2 (IKEv2) [RFC5996][RFC5739] is another widely used and a popular method of configuring IP information in a host. In the case of IKEv2 the provisioning domain could actually be implicitly learnt from the Identification - Responder (IDr) payloads the IKEv2 initiator and the responder inject during the IKEv2 exchange. The IP configuration may depend on the named IDr. Another possibility could be adding specific provisioning domain identifying payload extensions to IKEv2. All of the considerations listed above for DHCPv6 and RAs potentialy apply to IKEv2 as well. Change to Section 2.1 ===================== OLD: Link-specific and/or vendor-proprietary mechanisms for discovery of PVD information, different from the IETF-defined mechanisms, can be used by the nodes separately from or together with IETF-defined mechanisms, as long as they allow to discover necessary elements of the PVD(s). In all cases, by default nodes must ensure that the lifetime of all dynamically discovered PVD configuration is appropriately limited by the relevant events - for example, if an interface media state change was indicated, the previously discovered information may no longer be valid and needs to be re-discovered or confirmed. NEW: Link-specific and/or vendor-proprietary mechanisms for discovery of PVD information, such as the technologies used in cellular networks, different from the IETF-defined mechanisms, can be used by the nodes separately from or together with IETF-defined mechanisms, as long as they allow to discover necessary elements of the PVD(s). Another example of a delivery mechanism for PVDs are key exchange ortunneling protocols, such as IKEv2 [RFC5996] that allow transporting host configuration information In all cases, by default nodes must ensure that the lifetime of all dynamically discovered PVD configuration is appropriately limited by the relevant events - for example, if an interface media state change was indicated, the previously discovered information may no longer be valid and needs to be re-discovered or confirmed.
- [mif-arch-dt] Text for PvD considerations in conf… Suresh Krishnan
- [mif-arch-dt] Text for PvD considerations in conf… Suresh Krishnan
- Re: [mif-arch-dt] Text for PvD considerations in … Dmitry Anipko