Re: proposed text for charter

[Erik Nordmark <erik.nordmark@sun.com>]

Jari Arkko wrote:

Some suggested edits on your proposed text.
First I list the suggested result, followed by the changes:

The shim6 WG is to produce specifications for an IPv6 site-multihoming
solution based on the architecture developed by the IETF multi6
WG. An earlier multi6 WG was tasked with investigating solutions to the
site multihoming problem. The outcome of the multi6 WG was a specific
network-layer shim architecture for addressing and address handling of
sites and nodes.

The multihoming problem consists of the ability of sites or nodes to
be connected to multiple IP service providers for the purposes of
redundancy, load sharing, policy or cost reasons.

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 not be visible to the routing system. As a result, the necessary 
approach is to be able to use different provider assigned IP addresses 
and switch between them without upsetting transport protocols or 
applications.

The attributes of the approach that was developped in multi6, which map 
to requirements for the shim6 solution, are:

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

o  ULIDs are actual IP addresses such that existing applications can
   continue to work unchanged, and that application referrals work.
	Applications that do referrels and want to fully exploit the
	communication paths e.g., to handle failures, either need to
	operate on domain names, or pass lists of IP addresses when
	doing referrals.

o  The solution must not cause problems for mobility. That is, it
   should 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 WG
  will not take on the full mobility problem.

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  The solution should assume ingress filtering may be applied.

o  Only IPv6 is considered.

o  Assume that IPv6 NAT devices wither will not exist, or will not be an
   obstacle that shim6 needs to be concerned with.

The shim6 WG is to complete the required protocol developments and the
architecture and security analysis of the required protocols.

   Erik


"Diffs":

> The shim6 WG is to produce specifications for an IPv6 site-multihoming
> solution based on the architecture developed by the IETF multi6
> WG. An earlier multi6 WG was tasked with investigating solutions to the 
> site
> multihoming problem. The outcome of the multi6 WG was a specific
> network-layer shim architecture for addressing and address handling of
> sites and nodes.

ok

> The multihoming problem consists of the ability of sites or nodes to
> be connected to multiple IP service providers for the purposes of
> redundancy, load sharing, policy or cost reasons. 

Here I'd add the top level issue about using multiple PA addresses:
The solution must allow the global routing system to scale even if there 
is a very large number of multihome sites. This implies that re-homing 
not not be visible to the routing system. As a result, the necessary 
approach is to be able to use different provider assigned IP addresses 
and switch between them without upsetting transport protocols or 
applications.

The attributes of the approach that was developped in multi6, which map 
to requirements
for the shim6 solution, are:

> o Changes in the locator addresses will be invisible to upper layers,
>   which see a fixed Upper Layer Identifier address (ULID).

Makes sense to reword so that charter doesn't have to introduce the 
terms "locator address" and "ULID address".

> o  ULIDs are actual IP addresses such that existing applications can
>   continue to work unchanged, and that application referrals work.

Add:
	Applications that do referrels and want to fully exploit the
	communication paths e.g., to handle failures, either need to
	operate on domain names, or pass lists of IP addresses when
	doing referrals.

> o  The solution does not cause problems for mobility. That is, it
s/does not/must not/
>   should be possible to continue using Mobile IPv6 even when using
>   shim6 simultaneously. However, any optimizations or advanced
>   configurations are out of scope for shim6.

ok

>    Similarly, while it is desirable that the basic building blocks of
>    shim6 be able to handle dynamic changes in the addresses,
>    the focus of the group is not in the development of a new
>    mobility solution.

Reword as:
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 WG will not take on 
the full mobility problem.

I think we also need a bullet about existing communication and 
establishing new communication.

> o  The solution should assume ingress filtering may be applied.
>
> o  Only IPv6 is considered.
>
> o  No address translation is considered.

I think this means "IPv6 NAT" (as opposed to the "translation" the shim 
does at both ends) so it makes sense to say that explicitly.

> The shim6 WG is to complete the required protocol developments and the
> architecture and security analysis of the required protocols.