[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: proposed text for charter



Folks,

Erik's draft is quite thorough.  I've done some wordsmithing, especially to
make the first paragraph fully make the case for the working group effort,
since the first paragraph is circulated independently as a summary.

I've also re-ordered requirements a bit, trying to move from basics, to
operations, to derivative issues

So...


For the purposes of redundancy, load sharing, operational policy or cost, a
site may be multihomed, with the site's network having connections to
multiple IP service providers. Although the current Internet routing
infrastructure permits multihoming, and adapts to changes in the availability
of these connections, host application associations cannot use these
alternate paths, such as for surviving the changes or for creating new
associations when one or more of the site's addresses becomes unreachable.
This working group will produce specifications for an IPv6-based site
multihoming solution that inserts a new sub-layer (shim) into the IP stack of
end-system hosts. It will permit hosts on multihomed sites to use different
provider-assigned IP addresses and switch between them without upsetting
transport protocols or applications.

The work will be based on the architecture developed by the IETF multi6
working group. The shim6 working group is to complete the required protocol
developments and the architecture and security analysis of the required
protocols.

Requirements for the solution are:

o  The approach must handle rehoming both existing communication and
   being able to establish new communication when one or more of the
   addresses is unreachable.

o  IPv6 NAT devices are assumed not to exist, or not to present an
   obstacle about which the shim6 solution needs to be concerned.

o  Only IPv6 is considered.

o  Changes in the addresses that are used below the shim will be invisible to
   the upper layers, which will see a fixed address (called Upper Layer
   Identifier or ULID).

o  ULIDs will be actual IP addresses, permitting existing applications to
   continue to work unchanged, and permitting application referrals to work,
   as long as the IP Addresses are available. Applications that do referrals
   and want to fully exploit the alternate communication paths, such as for
   handling path failures, either need to use domain names, or to pass lists
   of destination IP addresses when doing referrals.

o  The solution should assume ingress filtering may be applied.

o  The solution must allow the global routing system to scale even if there
   is a very large number of multihomed sites. This implies that re-homing
   not be visible to the routing system.

o  Compatibility will remain for existing mobility mechanisms. It will be
   possible to continue using Mobile IPv6 even when using Shim6
   simultaneously. However, any optimizations or advanced configurations are
   out of scope for shim6.

o  The approach provides an optimized way to handle a static set of
   addresses, while also providing a way to securely handle dynamic
   changes in the set of addresses. The dynamic changes might be useful
   for future combinations of multihoming and IP mobility, but the working
   group will not take on such mobility capabilities directly.



  d/
  ---
  Dave Crocker
  Brandenburg InternetWorking
  +1.408.246.8253
  dcrocker  a t ...
  WE'VE MOVED to:  www.bbiw.net