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