[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: proposed text for charter
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
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
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.
dcrocker a t ...
WE'VE MOVED to: www.bbiw.net