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

Re: proposed text for charter



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.