cost of provider independence in p-shim6

[marcelo bagnulo braun <marcelo@it.uc3m.es>]

Motivated by the different questions i have wrote the following text 
that i will include in the next version, since i think it would clarify 
some aspects of the p-shim6


   The presented approach provides a set of features and relies on a set
   of components.  However, it should be noted that it is possible to
   provide a subset of the features using a subset of the components and
   that some of the components can be sustituted by alternative ones.
   In this section we describe which components are needed for which
   features and we also describe which other options could be used to
   replace some of the selected componenets.
   We will start by identifying which components are required for which
   feature.

   Centrally Managed Unique Local Addresses

   Centrally Managed Unique Local Addresses are used to provide provider
   independence i.e. avoid provider lock-in.  Using CMULAs allows the
   multihomed site to have provider independent identifiers and in the
   presented approach, the hosts within the multihomed site are only
   configured with CMULAs, greatly reducing the cost of a renumbering
   event.  PA addresses are only configured in the P-Shim6 boxes, so in
   case of a change in one of the ISPs, only the P-Shim6 boxes need to
   be reconfigured.  It should be noted that it is perfectly possible to
   use the P-Shim6 approach presented in this document with regular PA
   addresses as identifiers.  In this case, the hosts would be
   configured with PA addresses and the cost of a renumbering event
   would increase increasing also the provider lock-in.  In addition it
   should be noted that alternative provider independent identifiers
   could be used, such a regular PI address space.

   DNS Reverse tree

   The DNS reverse tree is used in this approach to restore ULID to
   locator mapping information in backup P-Shim6 boxes for ongoing
   communications in case that the primary shim6 fails.  In case that a
   single P-Shim6 box is used in a site, there is no need to populate
   the reverse DNS tree.  In case that alternative fault tolerance
   measures are in place (like mirrored P-Shim boxes) there reverse DNS
   population is not required.  In addition, alternative mechanisms to
   distribute ULID to locator mapping information among P-Shim6 boxes
   can be used instead of the reverse DNS (more in this below)

   ULID RR

   ULID RR is used to store information about addresses that are not
   globally routable and that are only meant to be used as ULID for
   shim6 context and not as locators.  Again, this is only needed to
   support non routable ULIDs, which are required to provide provider
   independence.  In the case that routable addresses (PA addresses for
   isntance) are used as ULIDs, this new ULID RR would be no longer
   needed.

   DNS Aplication level Gateway

   DNS Application Gateway is used to translate information ontained in
   the newly defined ULID RR and presented to legacy hosts in a AAAA
   record.  This is needed to support unmodified legacy hosts and
   provider independence through PI identifiers.  In the case that no
   provider independence is needed, and routable addresses are used as
   ULIDs, the DNS ALG would be no longer needed.  Similarly, if it can
   be asumed that the hosts in the multihomed site can understand the
   new ULID RR the DNS ALG would be no longer needed.

   Dual faced DNS

   The current proposal asumes that the DNS server in the multihomed
   site will return ULIDs in AAAA RR to internal queries and ULIDs in
   ULID RRs to external queries.  Again this is needed when non routable
   provider independent ULIDs are used.  If routable addresses are used
   as ULIDs (and no provider independence is required, there would be no
   need to dual faced DNS.

   Direct DNS population

   Direct DNS is used in the same way that it is currently used in non
   shim6 setups.  It is used in order to allow eternal hosts to initiate
   communications with a FQDN.  So DNS population is only required for
   hosts behaving as servers (i.e. they receive externally initiated
   communications).  Clients do no need DNS entries.

   NATv6

   NATv6 is required as a mechanism to comunicate with legacy hosts
   outside the multihomed site in the case that non routable ULIDs are
   being used i.e. in case provider independence is required.  If
   provider independence is not required, then is is posible to use the
   alternative choice described in the document, which relies in
   configurating multiple PA addresses per host, increasing provider
   lock in.

   Firewall component

   Having a firewall component in the P-Shim6 boxes is also required to
   provide provider independence.  This is so, because in order to
   facilitate renumbering we require that firewall rules will be
   configured using PI ULIDs rather than PA addresses.  If provider
   independence is no required and routable addresses can be used as
   ULIDs, the regular firewalls can be used unmodified.

   CGAs and HBAs

   ULIDs must be either CGAs or part of an HBA set.  In casethat
   provider independence is required, CGA are the only option, since a
   modification in one of the acialble prefixes in the site would result
   in a change in the ULIDs.  So, again, the usage of only CGAs is
   required by the provider independence requirement.


   Summarizing

   Tools imposed by the Provider Independence requirement

   CMULAs or similar

   DNS ALG

   New ULID RR

   NATv6

   Firewall component

   CGAs and not HBAs

   It would be perfectly possible to use the proposed approach wihtout
   the aforementioned components if provider independence is not
   required