Re: [mif-arch-dt] Text for PvD considerations in configuration sources

[Dmitry Anipko <[e-mail]>]

Hi Suresh, Jouni, Shwetha, 

thank you for revising the text. Unless there are other comments from the design team, I will include this into the next draft update.

-Dmitry
________________________________________
From: Suresh Krishnan <[e-mail]>
Sent: Monday, October 21, 2013 6:53 AM
To: Dmitry Anipko
Cc: [e-mail]
Subject: Text for PvD considerations in configuration sources

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.