Re: proposed text for charter

[Dave Crocker <dhc2@dcrocker.net>]

Tidbits...

On Fri, 25 Mar 2005 07:26:14 +1100, Geoff Huston wrote:
>  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. The current Internet routing infrastructure
>  permits multihoming using provider-in dependant addressing, and adapts to
                                      ------------
                                      independant

>  changes in the availability of these connections. However if the site uses
>  multiple provider-assigned address prefixes for every host within the site,
>  host application associations cannot use alternate paths, such as for
>  surviving the changes or for creating new associations, when one or more of

[[ yes.  nice clarification. ]]


>  the site's address prefixes 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 enable hosts on multihomed sites to use a set of provider-assigned IP
>  address prefixes 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.
>
>  o  The solution should assume ingress filtering may be applied at network
>  boundaries.
>
>  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 when using Shim6 simultaneously.
>  However, any optimizations or advanced configurations are out of scope
>  for shim6.
>
>  o  The approach is to provide 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.
>
>  The background documents to be considered by the WG include:
>
>  RFC 3582
>  draft-ietf-multi6-architecture-04.txt
>  draft-ietf-multi6-things-to-think-about-01.txt
>  draft-ietf-multi6-multihoming-threats-03.txt
>
>  The input documents that the WG will use as the basis for its design are:
>
>  draft-huston-l3shim-arch-00.txt
>  draft-ietf-multi6-functional-dec-00.txt
>  draft-ietf-multi6-l3shim-00.txt
>  draft-ietf-multi6-failure-detection-00.txt
>  draft-ietf-multi6-hba-00.txt
>  draft-ietf-multi6-app-refer-00.txt
>
>  In addition to the network layer shim solution, the shim6 WG is
>  specifically chartered to work on:
>
>  o Solutions for site exit router selection that works when each ISP
                                                   -----
                                                   work

>  uses ingress filtering, i.e. when the chosen site exit needs to be
>  related to the source address chosen by the host. This solution
>  should work whether or not the peer site supports the shim6
>  protocol.

[[ is the last sentence really a separate bullet?  if not, i don't understand
how only the ingress issue can work without the other side supporting shim6.
if yes, i STILL don't understand how it can work. offhand, it seems
impossible. ]]


>  o Solutions to establish new communications after an outage has
>  occurred that does not requires shim support from the non-multihomed
                 ----
                 do

>  end of the communication. The wg will explore if such solutions are
                                 --              --
                                 working group   whether

>  also useful when both ends support the shim.
>
>  o Congestion control and explore how this and other QoS and
                           ^to

>  traffic engineering issues may interact with the use of multiple
>  locators at both ends.
           ^(topology-specific addresses)

>  o The relationships between Upper Layer Identifiers (ULIDs)
>  and Unique Local Addresses.

[[ "Unique Local Addresses" is in caps, so presumably it is a term of art, but
it is not defined here.  It should be.  However I'm not 100% certain I know
what it means. ]]


>  o ICMP error demuxing for locator failure discovery.

[[ sounds interesting.  what is it? ]]


>  o If necessary, develop and specify formats and structure for:
>
>  - Cryptographically protected locators
>
>  - Carrying the flow label across the shim layer
>  defined in the multi6 architecture.
>
>  The shim6 WG is to publish, as standards track RFCs, specifications with
                                                  xxxxx

>  enough details to allow fully interoperable implementations.
>
>  The specifications must specifically refer to all applicable threats and
>  describe how they are handled,  with the requirement being that the
>  resulting solution not introduce any threats that make the security any
>  less than in today's Internet.
>
>  Milestones
>
>  MAY 05    First draft of architectural document
>  MAY 05    First draft of protocol document
>  MAY 05    First draft on cryptographic locators, if required
>  MAY 05    First draft on multihoming triggers description
>  MAY 05    First draft on applicability statement document
>
>  SEP 05    WG last-call on architectural document
>  SEP 05    WG last-call on applicability statement document
>
>  NOV 05    WG last-call on protocol document
>  NOV 05    WG last-call on cryptographic locators, if required
>  NOV 05    Submit completed architectural document to IESG
>  NOV 05    Submit applicability statement document to IESG
>
>  JAN 06    WG last-call on multihoming triggers description
>  JAN 06    Submit document on cryptographic locators to the IESG, if
>  required
>  JAN 06    Submit protocol document to the IESG
>
>  MAR 06    Submit draft on multihoming triggers description to the IESG




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