[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: 00 01 02

Network Working Group                                     Christian Vogt
Internet-Draft                                                  Ericsson
Expires: April 29, 2010                                 October 26, 2009


         Six/One: A Solution for Routing and Addressing in IPv6
                       draft-vogt-rrg-six-one-02

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.  This document may contain material
   from IETF Documents or IETF Contributions published or made publicly
   available before November 10, 2008.  The person(s) controlling the
   copyright in some of this material may not have granted the IETF
   Trust the right to allow modifications of such material outside the
   IETF Standards Process.  Without obtaining an adequate license from
   the person(s) controlling the copyright in such materials, this
   document may not be modified outside the IETF Standards Process, and
   derivative works of it may not be created outside the IETF Standards
   Process, except to format it for publication as an RFC or to
   translate it into languages other than English.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on April 29, 2010.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of



Vogt                     Expires April 29, 2010                 [Page 1]

Internet-Draft                   Six/One                    October 2009


   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.
















































Vogt                     Expires April 29, 2010                 [Page 2]

Internet-Draft                   Six/One                    October 2009


Abstract

   There is heightened concern about the growth of the global routing
   table and the increased frequency of routing table updates.  Both is
   due to the use of provider-independent addressing space in edge
   networks, which accommodates operators' desire to move traffic
   quickly and easily from one provider to another.  The main recent
   proposals attempt to solve this problem by hiding provider-
   independent addressing space through a level of indirection.
   Unfortunately, indirection requires a non-trivial distribution of
   address translation information across the Internet.  This is either
   slow, or costly in terms of signaling overhead, or both.  Security
   and transitionability are further issues.  This document proposes an
   alternative solution, which is based on a single, provider-dependent
   addressing space and hence avoids the problems of indirection.  The
   solution meets the objectives of edge network operators while
   limiting the size of the routing table and its update frequency.


































Vogt                     Expires April 29, 2010                 [Page 3]

Internet-Draft                   Six/One                    October 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  6

   2.  Conceptual Overview  . . . . . . . . . . . . . . . . . . . . . 11

   3.  Protocol Operation . . . . . . . . . . . . . . . . . . . . . . 13
     3.1.  IP Address Configuration . . . . . . . . . . . . . . . . . 13
     3.2.  Source Address Selection . . . . . . . . . . . . . . . . . 13
     3.3.  Initiating a Session . . . . . . . . . . . . . . . . . . . 14
     3.4.  Protecting Address Bunches . . . . . . . . . . . . . . . . 16
     3.5.  Responding to a Session Initiation . . . . . . . . . . . . 18
     3.6.  Completing a Session Initiation  . . . . . . . . . . . . . 19
     3.7.  Handling Outgoing Packets  . . . . . . . . . . . . . . . . 20
     3.8.  Handling Incoming Packets  . . . . . . . . . . . . . . . . 20
     3.9.  Network-Side Provider Selection and Address Rewriting  . . 21
     3.10. Session Shutdown . . . . . . . . . . . . . . . . . . . . . 22

   4.  Recommended Access Network Practices . . . . . . . . . . . . . 23
     4.1.  Subnet Prefix Assignment . . . . . . . . . . . . . . . . . 23
     4.2.  Router Configuration . . . . . . . . . . . . . . . . . . . 23
     4.3.  Host Configuration . . . . . . . . . . . . . . . . . . . . 24
     4.4.  Configuration of Traffic Control and Analysis Equipment  . 25

   5.  Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 28
     5.1.  Incentives for Deployment  . . . . . . . . . . . . . . . . 28
     5.2.  Transition . . . . . . . . . . . . . . . . . . . . . . . . 29
     5.3.  Easing Universal Source Address Validation . . . . . . . . 30

   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 31

   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 32

   8.  Acknowledgment . . . . . . . . . . . . . . . . . . . . . . . . 33

   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 34
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 34
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 34

   Appendix A.  Change Log  . . . . . . . . . . . . . . . . . . . . . 36

   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 37









Vogt                     Expires April 29, 2010                 [Page 4]

Internet-Draft                   Six/One                    October 2009


   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in
   [rfc2119-rfc-keywords].















































Vogt                     Expires April 29, 2010                 [Page 5]

Internet-Draft                   Six/One                    October 2009


1.  Introduction

   The Internet traditionally consists of three classes of players:
   users, edge network operators, and providers.  Users operate hosts
   for which they desire efficient, available, and reliable Internet
   connectivity.  Edge network operators provide the infrastructure that
   hosts needs to communicate, collectively called the "edge domain".
   An edge network can indepently route packets between two attached
   hosts, but for global Internet connectivity, it must connect to a
   provider.  Providers jointly form a "transit domain" via which
   packets can be exchanged between edge networks.

   Edge network operators are naturally eager to meet the expectations
   of users because they have a direct business relationship with the
   users.  An important tool edge network operators employ to accomplish
   this is traffic engineering, which helps them to utilize available
   edge network capacities in an optimum way.  Edge network operators
   further desire the ability to select providers in a dynamic manner
   because the quality of a host's Internet connectivity depends on the
   provider just as well as on the edge network.  Technology should
   permit flexible transition from one provider to another, so-called
   "rehoming".  Technology should also allow an edge network operator to
   connect to multiple providers, so-called "multi-homing", and to
   extend traffic engineering to dynamically reroute traffic between
   those connections.

   The crux with the new desire for flexible provider selection is that
   the Internet was not designed to support it.  For scalability
   reasons, the preferred strategy for allocating Internet addressing
   space is to hand out contiguous address blocks to providers, which in
   turn delegate parts of their block to the edge networks they serve.
   The address that a host uses to describe a point of Internet
   attachment consequently identifies the provider via which the host is
   reachable.  The benefit of this is more efficient routing inside the
   transit domain because the global "routing table", the routing state
   that needs to be maintained and consulted on a per-packet basis, can
   be limited to one entry per provider.  The routes connecting transit
   and edge domains can then be maintained locally by the respective
   providers and the edge networks they serve.  A smaller routing table
   furthermore reduces the number of updates it is subject to.

   On the other hand, provider-dependent addressing brings about grave
   limitations for edge domain operators.  An edge network operator that
   wishes to rehome must reconfigure networking equipment for traffic
   control and analysis as well as applications with preconfigured
   addresses on hosts.  This affects routers just as well as middleboxes
   that store addresses, such as firewalls and intrusion detection
   systems.  Rehoming is therefore expensive and disruptive.  A multi-



Vogt                     Expires April 29, 2010                 [Page 6]

Internet-Draft                   Six/One                    October 2009


   homed edge network is limited in its ability to pursue traffic
   engineering because provider-dependent addresses effectively move the
   priviledge of provider selection to the hosts: A host obtains an
   address from each provider, and to ensure bidirectionality and
   topological correctness, packets that the host sends must go via the
   provider that is identified by the packet's source address.

   A natural desire of edge network operators is therefore to gain
   provider-independent addressing space.  This would facilitate
   rehoming without reconfiguration costs, as well as flexible provider
   selection during multi-homing.  The drawback of provider-independent
   addressing space for edge networks is that it would require an entry
   per edge network in the global routing table.  The routing table size
   would thus increase to a substantial extent and effectively slow down
   the routing process.  Moreover, the only way for an edge network to
   select the provider through which it was to be reached would be an
   update to its entry in the global routing table.  This would take
   effect slowly, and it would have the undesired consequence of more
   frequent updates to the global routing table.

   The conflict of interests between the transit domain and the edge
   domain calls for a new approach to routing and addressing that
   satisfies the following primary objectives:

   1.  Routing table size.  The size of the global routing table must be
       kept linear in the number of providers rather than linear in the
       number of edge networks.

   2.  Routing table robustness.  Traffic engineering in edge networks
       or edge network rehoming must not require updates to the global
       routing table.

   3.  Egress provider selection.  A multi-homed edge network must be
       able to select a provider for egress packets.  Such selection
       must take effect quickly.

   4.  Ingress provider selection.  A multi-homed edge network must be
       able to select a provider for ingress packets.  The mechanism
       that this requires for packet rerouting across the transit domain
       must be responsive.

   5.  Rehoming.  An edge network must be able to smoothly change the
       set of providers it connects to, without incurring costly
       reconfiguration of applications and networking equipment for
       traffic control and analysis.






Vogt                     Expires April 29, 2010                 [Page 7]

Internet-Draft                   Six/One                    October 2009


   6.  Transition.  There must be a transition path for incremental
       deployment of a routing and addressing solution, which allows
       upgraded parts of the Internet to communicate with legacy parts.

   Beside these primary objectives, there are a number of secondary
   objectives.  A routing and addressing solution that satisfies some or
   all of these objectives would be of additional value for host, edge
   network operators, or providers:

   7.   Host preferences.  A host should have a means to suggest to the
        edge network which provider it would prefer its packets to pass
        through.

   8.   Routing performance.  Traffic characteristics such as packet
        propagation latencies, packet loss probabilities, or jitter
        should not change.

   9.   Deployment incentives.  Deployment of a routing and addressing
        solution should yield direct benefits to those entities
        investing in the deployment.

   10.  Integrability on hosts.  A host-based routing and addressing
        solution should be integrable with protocols for host mobility
        and host multi-homing.

   11.  Integrability in the network.  A network-based routing and
        addressing solution should be integrable with source address
        validation technology.

   The main existing routing and addressing proposals are based on a
   level of indirection between addressing space for use inside the edge
   domain, and addressing space for efficient packet routing across the
   transit domain.  Two indirection functions perform forward and
   reverse translations between edge domain addresses and transit domain
   addresses.  Specific proposals differ with respect to whether this
   translation occurs through address rewriting or tunneling, and, more
   importantly, with respect to where the indirection functions are
   located.  While one indirection function always borders the edge
   network which address space is being translated, the other
   indirection function may be located at the border of a remote edge
   network, or inside the transit domain.  A consequence of locating an
   indirection function inside the transit domain is that edge network
   addressing space must be provider-dependent.  And to avoid a
   dependency on a single provider, the edge network addressing space
   should be shared as anycast addressing space by multiple providers,
   each with its own indirection function.

   The strength of indirection is that it requires special support only



Vogt                     Expires April 29, 2010                 [Page 8]

Internet-Draft                   Six/One                    October 2009


   in the form of indirection functions.  It can thus be kept
   transparent to hosts, and to the edge network except for the entity
   providing an indirection function.  Like provider-independent
   addressing space in general, indirection thereby eliminates the
   costly reconfiguration overhead that edge network rehoming normally
   entails.  It also allows a multi-homed edge network to select a
   provider for egress packets and -- to the extent a remote indirection
   functions can be altered quickly enough -- for ingress packets as
   well.  Indirection finally preserves the size of the global routing
   table or the frequency by which this is updated.

   A significant drawback of indirection is the need for a mechanism
   that can distribute address translation information for an edge
   network to indirection functions at other edge networks or inside the
   transit domain.  A suitable distribution mechanism needs to affect a
   difficult trade-off between update latency and signaling overhead,
   while still remaining responsive to urgent rerouting decisions of
   edge network operators, such as for the purpose of provider fail-
   over.  A suitable distribution mechanism must also be robust to
   impersonation and denial-of-service attacks.  Both can be provided
   through authentication.  For scalability reasons, this is likely to
   require public-key-based authentication, and hence notable processing
   overhead and periodic inquiries about subverted and changed public
   keys.

   Indirection techniques that use provider-independent addressing space
   inside the edge domain furthermore fail to provide a smooth
   transition path.  From the perspective of a correspondent host, the
   address of a host behind an indirection function depends on whether
   the edge network of the correspondent host already supports the
   indirection.  While it is feasible to modify DNS to tailor address
   resolution to the resolving host, means of address resolution aside
   from DNS, such as via SIP signaling or peer-to-peer protocols, might
   not be fixable and become completely defunct
   [nikander-ram-generix-proxying].  Another undesired consequence is
   that, in case the edge network of the correspondent host is legacy,
   but address resolution succeeds nonetheless, the indirection function
   at the host would have to translate addresses also in the payloads of
   the correspondent host's packets, thus behave as a classic network
   address translator.

   The routing and addressing solution proposed in this document, Six/
   One, avoids the problems of indirection by maintaining a single
   addressing space of IPv6 addresses for both the edge domain and the
   transit domain.  Six/One borrows from Shim6 [ietf-shim6-proto] the
   concept that multi-homed edge networks use provider-dependent
   addressing space from each of their providers, and hosts use
   addresses from all addressing spaces interchangeably without breaking



Vogt                     Expires April 29, 2010                 [Page 9]

Internet-Draft                   Six/One                    October 2009


   active communication sessions.  The novel concept of Six/One is that
   a host's addresses differ only in their high-order bits, which
   enables an edge network or a provider to change the address in a
   packet on the fly depending on the provider to with the packet is
   routed.  The address from which a host contacts a correspondent host
   serves as a suggestion to the edge network which provider the host's
   packets should be routed through.  The edge network may follow this
   suggestion, or rewrite the high-order bits of the address in
   accordance with a provider of its own choice.  Different than in
   Shim6, edge networks thus retain the ability to select a particular
   provider for ingress and egress packets.  Hosts adapt to address
   rewrites in that they modify subsequent packets accordingly before
   injecting them into the network.  Like other protocols that enable a
   host to change its address during an active communication session --
   including, besides Shim6, also Mobile IPv6 and the Host Identitity
   Protocol --, Six/One adds to packets a small piece of information
   that enables the receiving hosts to reverse address rewrites.  The
   novel concept in Six/One is that this information can also be used
   inside an edge network to identify a remote host despite address
   changes.  Moreover, the high-order bits in addresses from local
   addressing space can be masked when stored in applications or
   networking equipment for traffic control and analysis, so as to spare
   costly reconfiguration overhead in the event of rehoming.  This
   resembles the concept of 8+8 [odell-8+8], with the main difference
   that hosts remain to be aware of their full addresses, including the
   high-order bits, and that they can suggest to the edge network a
   provider for their packets as explained above.

   Through the use of provider-dependent addressing space in both the
   edge domain and the transit domain, Six/One preserves both the size
   of the global routing table as well as the frequency at which the
   routing table is updated.  For the same reason, Six/One precludes
   degradations in routing performance.  A three-phase transition path
   will smoothly lead towards a universal deployment of Six/One.
   Deployment will be accelerated by the right incentives, since even
   partial deployment will provide advantages for the pioneers.  The
   host support that is needed for Six/One integrates well with host
   mobility and host multi-homing procotols.  The required network
   support facilitates source address validation at no extra costs for
   the edge network operator or provider.  In summary, Six/One satisfies
   all of the aforementioned primary and secondary objectives.










Vogt                     Expires April 29, 2010                [Page 10]

Internet-Draft                   Six/One                    October 2009


2.  Conceptual Overview

   This section gives a conceptual overview of the Six/One protocol, and
   it provides rationale for the design decisions made.

   The refrainment from introducing separate addressing spaces for the
   edge domain and the transit domain implies that the IPv6 addressing
   architecture (RFC 4291) and the preferred policy of allocating
   provider-dependent addressing space to edge networks remain as is.
   From a host's perspective, an IPv6 address is still split into a 64-
   bit "subnet prefix" and a 64-bit "interface identifier", as shown in
   Figure 1.  A subnet prefix is advertised by an access router, and the
   host extends this with an interface identifier to form a full
   address.  From an edge network's perspective, a subnet prefix can
   further be decomposed into a "routing prefix", which identifies the
   provider from which the addressing space was obtained, and a "subnet
   ID", which is used by the edge network to identify internal links.
   The length of the routing prefix determines the size of the
   addressing space, which is up to the contract between the edge
   network and the provider.  The length of the subnet ID is such that,
   together with the routing prefix, it adds up to 64 bit.


    |<----------- 64 bit ----------->|<----------- 64 bit ----------->|

    +--------------------------------+--------------------------------+
    |         subnet prefix          |      interface identifier      |
    +--------------------------------+--------------------------------+

    |   routing prefix   | subnet ID |

                     Figure 1: IPv6 address structure

   What Six/One adds to IPv6 is an ability for hosts to configure sets
   of addresses, so-called "address bunches", that differ only in the
   routing prefixes, and to use these addresses interchangeably without
   breaking active communication sessions.  An instance of Six/One at
   the host's IPv6 layer ensures that switches between addresses from
   the same bunch are kept transparent to protocols above.

   The concept of address bunches enables a host sending a packet, or a
   router on the packet's path, to change the routing prefix in an
   address of the packet without destroying the relationship between the
   address and the host to which it belongs.  (A host generally does not
   know the length of a routing prefix, so technically, it rewrites an
   entire 64-bit subnet prefix.  But since all addresses in a bunch have
   the same subnet ID, only the routing prefix can change during this
   operation.)  As the routing prefixes in the addresses of a packet



Vogt                     Expires April 29, 2010                [Page 11]

Internet-Draft                   Six/One                    October 2009


   define the providers through which the packet enters or leaves the
   transit domain, routing prefix rewriting can force the packet to go
   via a different provider pair than the one corresponding to the
   original addresses.  The correspondent host receiving the packet
   recognizes and reverses routing prefix rewrites so that packets are
   handed to protocols above Six/One as they were generated initially.
   The correspondent host further memorizes a routing prefix rewrite and
   adapts in that it directly rewrites the addresses in packets that it
   generates itself before injecting the packets into the network.  This
   not only relieves the network from the burden of continued routing
   prefix rewriting, it also ensures that packets exchanged in either
   direction pass the same pair of providers.  The result is a quick,
   bidirectional adoption of a new provider, which is essential in
   particular during provider fail-over.

   To support the new interchangeability of addresses, a host must be
   aware of its own address bunch as well as of the address bunch of the
   "correspondent host" it communicates with.  The host must further
   remember which address from each bunch it is to use at protocols
   above Six/One. The host maintains all of this information as a per-
   communication-session "context".  A context is securely created on
   both sides of a connection during session establishment.  Each
   context is assigned a "context identifier", which is carried in all
   packets of the session to aid the retrieval of the right context at
   the receiving host.

   Six/One itself handles edge network multi-homing, but it is not a
   solution for host mobility, host multi-homing, or host identity
   management.  These latter challenges must be addressed by a separate
   protocol such as Mobile IPv6 or the Host Identity Protocol.  However,
   it is possible to integrate Six/One with host mobility, host multi-
   homing, or host identity protocols so as to reduce network protocol
   stack complexity and signaling overhead.  For example, all of these
   protocols include information for context retrieval in packets, such
   as a Six/One context identifier, a Mobile IPv6 home address, or an
   IPsec security parameter index in the case of the Host Identity
   Protocol.  This information could be shared amongst the protocols.
   The new paradigm of address bunches and address rewriting in routers
   may furthermore be incorporated into future-Internet architectures.
   One example is the Node ID architecture [schuetz-nid-arch], which
   builds on the Host Identity Protocol and augments the Internet by a
   mechanism for identity-based overlay routing to help hosts discover
   their mutual IP addresses.








Vogt                     Expires April 29, 2010                [Page 12]

Internet-Draft                   Six/One                    October 2009


3.  Protocol Operation

   This section describes the operation of Six/One in detail.


3.1.  IP Address Configuration

   To allow the routing prefix of an address to be rewritten without
   changing the address owner, addresses must be configured in bunches.
   This may happen through manual preconfiguration, or through stateless
   or stateful auto-configuration.  A host that uses stateless address
   auto-configuration can configure an address bunch through successive
   execution of the protocol for each address in the bunch.  In the
   unlikely event of a collision, the host discards the incomplete
   address bunch and tries anew with a different interface identifier.

   The signaling overhead in the above application of stateless address
   auto-configuration does not differ from the standard use if no
   collision occurs, or if a collision occurs already during the
   configuration of the first address in the bunch.  Some extra
   signaling overhead is spent in case a collision occurs after the
   first address has been configured because every previous address
   configuration was then in vain.  However, if all neighbor hosts on
   the same link use address bunches as well, a collision can only occur
   during the configuration of the first address in a bunch.

   [To be done: Stateful address auto-configuration with DHCPv6.]

   Six/One ensures that routing prefix rewrites are transparent to
   protocols above Six/One, so that they do not cause communication
   sessions to abort.  In the following it will be assumed that the host
   configures a single address bunch.  This assumption goes without loss
   of generality.


3.2.  Source Address Selection

   All addresses in a bunch are visible to protocols above Six/One, and
   all may be advertised in DNS.  An application may select any of these
   addresses as a local address for a new communication session, and any
   address that DNS advertises for the correspondent host may be used as
   a remote address.  The local and remote addresses used by protocols
   above Six/One are called "primary addresses".  Primary addresses
   never change throughout a communication session.  The local and
   remote addresses into which Six/One translates a packet's source and
   destination addresses are called "active addresses".  Figure 2
   illustrates which values a packet's source and destination addresses
   take before and after processing by Six/One.



Vogt                     Expires April 29, 2010                [Page 13]

Internet-Draft                   Six/One                    October 2009


             +----------------------------------------------+
             | source address      = primary local address  |
             | destination address = primary remote address |
             |                                              |
             :                                              :
                             /\            |  |
                            /  \           |  |
                            |  |  Six/One  |  |
                            |  |           \  /
                            |  |            \/

             +----------------------------------------------+
             | source address      = active local address   |
             | destination address = active remote address  |
             |                                              |
             :                                              :

      Figure 2: Packet addresses before and after Six/One processing


   A host is in general agnostic with respect to the topological meaning
   of a subnet prefix, and it simply considers the subnet prefix an
   opaque 64-bit value.  The host then selects a source address for a
   new communication session without preference.  However, if a host is
   able to map routing prefixes onto the corresponding providers, the
   host can express a preference for a particular provider by picking a
   source address with that provider's routing prefix.  Unless the
   suggestion gets overwritten by the edge network, this allows the host
   to have its packets routed via a provider of its own choice.


3.3.  Initiating a Session

   To be able to pursue, verify, and reverse routing prefix rewrites in
   the addresses of ingress and egress packets, a host must be aware of
   the local and remote addresses that are legitimate for a particular
   communication session as well as which of these addresses are
   primary.  The host maintains this information in "contexts".  The
   "local context" for a communication session comprises the primary
   local address used in the session, the address bunch from which the
   primary local address was taken, and a context ID that is unique for
   all local contexts of the host.  The host further maintains a "remote
   context" for each communication session, which equals the local
   context of the respective correspondent host.  The remote context is
   retrieved during session establishment.  A remote context is
   identified by the combination of the context ID chosen by the
   correspondent host, and any address in the correspondent host's
   address bunch.



Vogt                     Expires April 29, 2010                [Page 14]

Internet-Draft                   Six/One                    October 2009


   A host that wishes to initiate a communication session with a
   correspondent host first allocates a local context based on the
   primary local and remote addresses chosen by the application as well
   as the address bunch to which the local address belongs.  The host
   assigns the local context a context ID that has not been assigned to
   another local contexts.  In case the host already has a local context
   for the same primary local and remote addresses, then this may be
   reused for the new communication session.  The local context is
   finally bound to the session in an implementation-specific manner.

   The host further allocates a remote context for the communication
   session.  If a remote context already exists for the same primary
   local and remote addresses, then it may be reused for the new
   communication session.  Otherwise, the host creates a preliminary
   remote context at this stage, which contains only the primary local
   and remote addresses.  The missing parts of the remote context will
   be retrieved subsequently during session establishment.  The remote
   context, too, is bound to the session in an implementation-specific
   manner.

   Figure 3 shows an example of the host's local and preliminary remote
   contexts at the time the correspondent host is contacted.  The host
   has elected to use the local address RP1a:SID1::IID1 as a primary
   local address in the communication session, where "RP1a" denotes the
   routing prefix, "SID1" the subnet ID, and "IID1" the interface
   identifier.  The host's address bunch also contains a second address
   with routing prefix "RP1b".  The correspondent host's address RP2a:
   SID2::IID2 is used as the primary address in the preliminary remote
   context, where the routing prefix, subnet ID, and interface
   identifier are "RP2a", "SID2", and "IID2", respectively.  The context
   ID of the host's local context is CID1, whereas the context ID of the
   remote context is yet unknown.


          host             |  local context   |  remote context
         ------------------+------------------+-----------------
          context ID       |  CID1            |  (unknown)
                           |                  |
          primary address  |  RP1a:SID1:IID1  |  RP2a:SID2:IID2
          active address   |  RP1a:SID1:IID1  |  RP2a:SID2:IID2
                           |                  |
          address bunch    |  RP1a:SID1:IID1  |  RP2a:SID2:IID2
                           |  RP1b:SID1:IID1  |  (rest unknown)

            Figure 3: Host's contexts on session establishment


   The primary local and remote addresses are used as the source and



Vogt                     Expires April 29, 2010                [Page 15]

Internet-Draft                   Six/One                    October 2009


   destination addresses, respectively, in the first packet that the
   host sends to the correspondent host.  This first packet carries an
   IPv6 Destination Options extension header with a new "Context Setup
   option" that includes the parameters of the host's local context.


3.4.  Protecting Address Bunches

   The ability to send and receive packets via an active address that
   differs from the primary address visible for protocols above Six/One
   must be protected against misuse.  Failure to provide appropriate
   security measures would enable a malicious host to communicate with a
   correspondent host on behalf of a victim host.  Such an
   "impersonation attack" calls for the malicious host to register with
   the correspondent host an address bunch that includes the victim
   host's address as primary, and an address at which the malicious node
   itself is reachable as active.  The malicious host could then
   exchange packets with the correspondent host via the active address,
   whereas protocols above Six/One on the correspondent host would see
   the primary address and hence assume to be communicating with the
   victim host.  The interface identifier of the active address would
   have to be the same as that of the primary, that is, the victim
   host's address.  But a malicious host can easily configure an
   appropriate active address if the malicious host resides on an access
   link that permits stateless address auto-configuration.  Even with
   other address configuration means, it may still be possible for the
   malicious host to send packets from a spoofed address with the
   desired interface identifier, and to overhear packets delivered to
   that same address.

   To prevent impersonation attacks, Six/One requires a host to prove to
   its correspondent host that it is the legitimate owner of its primary
   address.  This address ownership proof is provided through a
   cryptographic binding between the subnet prefixes of the addresses in
   the host's bunch and the common interface identifier of these
   addresses.  The host creates the cryptographic binding when it
   generates an address bunch, and the correspondent host verifies the
   binding during context establishment.  This makes it infeasible for a
   malicious host to create an address bunch that contains both a victim
   host's address and an address at which it is reachable itself.

   The technique Six/One uses to create the cryptographic binding
   between the different subnet prefixes and the common interface
   identifier in an address bunch is based on the generation and
   verification algorithms for Cryptographically Generated Addresses
   [rfc3972-cga] and Hash-Based Addresses [ietf-shim6-hba].  The
   technique differs, however, in that it yields a single interface
   identifier for all addresses in a bunch, although these addresses



Vogt                     Expires April 29, 2010                [Page 16]

Internet-Draft                   Six/One                    October 2009


   have different subnet prefixes.  A host generates an address bunch
   according to Section 6 in [ietf-shim6-hba] with the exception of
   steps 6.1 and 6.5, which are modified such that the CGA parameters no
   longer emphasize a particular subnet prefix:

   6.1.  Concatenate from left to right the final Modifier value, 64
         zero bits, the collision count, the encoded public key or the
         encoded Extended Modifier (if no public key was provided) and
         the Multi-Prefix extension.  Execute the SHA-1 algorithm on the
         concatenation.  Take the 64 leftmost bits of the SHA-1 hash
         value.  The result is Hash1[i].

   6.5.  Form the CGA Parameters data structure that corresponds to
         HBA[i] by concatenating from left to right the final modifier
         value, Prefix[i], the final collision count value, the encoded
         public key or the encoded Extended Modifier and the Multi-
         Prefix extension.

   Six/One further requires a correspondent host to verify the
   cryptographic binding between the different subnet prefixes and the
   common interface identifier in an address bunch according to Section
   7 in [ietf-shim6-hba] with the exceptions that step 2.2 is omitted,
   and that step 1 is modified to no longer emphasize a particular
   subnet prefix:

   1.    Verify that the 64-bit HBA prefix is included in the prefix set
         of the Multi-Prefix extension.  If it is not included, the
         verification fails.  Otherwise, fill the Subnet Prefix field of
         the CGA Parameter data structure with 64 zero bits.

   It should be emphasized that, although the above modifications
   effectively eliminate the Subnet Prefix field in a CGA Parameters
   data structure, the Multi-Prefix extension of the data structure
   still lists the set of subnet prefixes of an address bunch.  This
   upholds the cryptographic binding between the subnet prefix and the
   interface identifier for each address in the bunch.

   The described cryptographic binding between the subnet prefixes and
   the interface identifier in an address bunch is the default address
   ownership proof if Six/One is used without a host mobility, host
   multi-homing, or host identity protocol, such as Mobile IPv6 or the
   Host Identity Protocol.  However, if Six/One is combined with one of
   these protocols, that protocol effectively provides the primary
   address, and the address ownership proof performed by that protocol
   can replace the default address ownership proof of Six/One. For
   example, if Six/One is combined with the Host Identity Protocol, a
   host's primary address becomes a host identity tag, and the proof of
   ownership of the host identity tag is accomplished through IPsec-



Vogt                     Expires April 29, 2010                [Page 17]

Internet-Draft                   Six/One                    October 2009


   based authentication.


3.5.  Responding to a Session Initiation

   When a correspondent host receives from a host a packet that includes
   an IPv6 Destination Options extension header with a Context Setup
   option, the correspondent host allocates a remote context for the
   host based on the parameters in the Context Setup option.  This may
   be a new context or a reused one.  The active local and remote
   addresses in the context are set to the source and destination
   addresses in the received packet.  Since the subnet prefixes of the
   addresses in this first packet may already have been rewritten --
   either by Six/One on the host prior to packet transmission, or later
   on in the network --, the active local and remote addresses may
   differ from the corresponding primary addresses.

   The correspondent host further allocates a local context for the
   communication session based on the address bunch that includes the
   destination address of the incoming packet.  The local context may
   again be new or reused, and it uses the same active addresses as the
   remote context for this session.

   Figure 4 continues the example of Figure 3 with an illustration of
   the contexts that the correspondent host has at this point.  The
   figures differ in that the roles of the local and remote contexts are
   reversed, and in that both contexts are now complete.  The
   correspondent host's local context has context ID "CID2".  And
   besides the primary address RP2a:SID2:IID2, its address bunch
   includes two more addresses, RP2b:SID2:IID2 and RP2c:SID2:IID2, where
   "RP2b" and "RP2c" are additional routing prefixes.  In this example,
   the routing prefix of the packet's source address was rewritten in
   the network because the active address in the correspondent host's
   remote context is RP1b:SID1:IID1, whereas the active address on the
   host's local context used to be RP1a:SID1:IID1 at the time the packet
   was sent.















Vogt                     Expires April 29, 2010                [Page 18]

Internet-Draft                   Six/One                    October 2009


         correspondent host  |  local context   |  remote context
        ---------------------+------------------+-----------------
         context ID          |  CID2            |  CID1
                             |                  |
         primary address     |  RP2a:SID2:IID2  |  RP1a:SID1:IID1
         active address      |  RP2a:SID2:IID2  |  RP1b:SID1:IID1
                             |                  |
         address bunch       |  RP2a:SID2:IID2  |  RP1a:SID1:IID1
                             |  RP2b:SID2:IID2  |  RP1b:SID1:IID1
                             |  RP2c:SID2:IID2  |

     Figure 4: Correspondent host's contexts on session establishment


   The correspondent host typically returns a packet to the host as a
   response to the packet received.  This packet is used to communicate
   the parameters of the peer's local context back to the host, again
   with a Context Setup option in an IPv6 Destination Options extension
   header.


3.6.  Completing a Session Initiation

   The host completes the preliminary remote context for the
   correspondent host when it receives the first packet from the
   correspondent host that includes an IPv6 Destination Options
   extension header with a Context Setup option.  Both the host and the
   correspondent host have then complete local and remote contexts for
   the communication session.  As with all subsequent packets received
   from the correspondent host, the host also resets the active
   addresses in its local and remote contexts to the received packet's
   destination and source addresses, respectively, so as to adapt to any
   address rewrites.

   Figure 5 illustrates the local and remote contexts at the host at
   this point, concluding the example from the previous figures.  Since
   the correspondent host has sent the packet to the active address in
   its remote context, which is RP1b:SID1:IID1, the host has changed the
   active address in its local context to RP1b:SID1:IID1 accordingly.












Vogt                     Expires April 29, 2010                [Page 19]

Internet-Draft                   Six/One                    October 2009


          host             |  local context   |  remote context
         ------------------+------------------+-----------------
          context ID       |  CID1            |  CID2
                           |                  |
          primary address  |  RP1a:SID1:IID1  |  RP2a:SID2:IID2
          active address   |  RP1b:SID1:IID1  |  RP2a:SID2:IID2
                           |                  |
          address bunch    |  RP1a:SID1:IID1  |  RP2a:SID2:IID2
                           |  RP1b:SID1:IID1  |  RP2b:SID2:IID2
                           |                  |  RP2c:SID2:IID2

             Figure 5: Host's contexts for established session


3.7.  Handling Outgoing Packets

   When a host has a packet to send that was delivered by a protocol
   above Six/One, the host may have to rewrite the routing prefixes of
   the packet's source and destination addresses so as to direct the
   packet via a provider that was recently chosen by the network.  The
   host must further include sufficient information in the packet to
   enable the correspondent host to reverse these address changes before
   handing the packet to protocols above Six/One at the receiving side.

   The source and destination addresses that the host is supposed to use
   when sending a packet are, respectively, recorded in the active
   addresses of the local and remote contexts of the communication
   session.  As delivered by the protocol above Six/One, the source
   address in the packet contains the primary local address.  The host
   replaces this with the active address from the local context.
   Moreover, the packet's destination address contains the primary
   remote address when the packet is received from the protocol above
   Six/One. This is replaced with the active address from the remote
   context.

   To enable the correspondent host to map the packet onto the correct
   local and remote contexts, all packets except the first in a new
   communication session are endowed with the sending host's local and
   remote context IDs for the session.  This information is carried in a
   "Context ID option" of an IPv6 Destination Options extension header.


3.8.  Handling Incoming Packets

   A correspondent host that receives a packet from the network uses the
   Context ID option in the packet's IPv6 Destination Options extension
   header to retrieve the correct local and remote contexts.  The local
   context is obtained based on only the local context ID given in the



Vogt                     Expires April 29, 2010                [Page 20]

Internet-Draft                   Six/One                    October 2009


   option.  It is used to replace the destination address in the
   received packet with the primary local address.  The remote context
   is obtained based on the combination of the remote context ID given
   in the option and the packet's source address.  It is used to replace
   the packet's source address with the primary remote address.

   The correspondent host must further memorize which source and
   destination addresses the packet arrived with, so that the same local
   and remote addresses can be used for packets that it sends
   subsequently in the same communication session.  This is accomplished
   by resetting the active addresses in the local and remote contexts to
   the packet's destination address and source address, respectively.


3.9.  Network-Side Provider Selection and Address Rewriting

   It is up to the edge network to decide via which provider an egress
   packet shall be routed.  One possibility is for the edge network to
   accept the provider that is indicated by the routing prefix of the
   egress packet's source address.  The provider is then effectively
   selected by the host sending the packet.  On the other hand, traffic
   engineering strategies or other local policies may require the edge
   network to route packets via a different provider than implied by
   their source addresses.  The edge network can then preempt the
   provider selection of a sending host.

   In case an egress packet is routed via a different provider than the
   one implied by the packet's source address, the subnet prefix of the
   source address must be rewritten to one with a routing prefix from
   the provider chosen by the edge network.  Besides ensuring
   topological correctness, this makes egress and ingress packets of a
   particular communication session go via the same provider, which is
   important to support efficient provider fail-over.  Network-side
   address rewrites do not effect a packet's destination address, nor
   any addresses that appear outside the packet's IPv6 header.  Like
   address rewrites that are pursued by Six/One on a sending host,
   network-side address rewrites are reversed by Six/One on the
   receiving host.

   Without loss of generality, it can be assumed that provider selection
   and address rewrites be accomplished by routers.  Both can happen
   anywhere in the edge network, like directly on a first-hop router,
   somewhere inside the edge network, or at the border to the edge
   network's providers.  Address rewriting may furthermore be delegated
   to a provider.

   In rewriting the subnet prefix of an address, a router must ensure
   that the old and the new address belong to the same host.  The router



Vogt                     Expires April 29, 2010                [Page 21]

Internet-Draft                   Six/One                    October 2009


   must hence in general know the set of subnet prefixes that are valid
   on the link from which a packet originates.  This requirement can be
   eliminated through a wise assignment of subnet prefixes to individual
   links, as described in Section 4.1 and Section 4.2.


3.10.  Session Shutdown

   Contexts are soft-state and do not explicitly need to be revoked.
   Hosts keep both remote and local contexts as long as there are
   protocols above Six/One that use these contexts.  A context is kept
   for a while also after all protocols above Six/One have stopped using
   it since the context might be picked up by a new communciation
   session shortly thereafter.  Contexts are finally disposed after a
   predefined idle time, where the idle time for local contexts should
   be a bit longer than the idle time for remote contexts.  A remote
   context reused by a host is therefore very likely to still exist as a
   local context at the correspondent host even after a communication
   pause.
































Vogt                     Expires April 29, 2010                [Page 22]

Internet-Draft                   Six/One                    October 2009


4.  Recommended Access Network Practices

   Since hosts configure and select addresses without considering the
   structure of a subnet prefix, edge network operators have the freedom
   to constuct subnet prefixes in arbitrary manner.  On the other hand,
   a clean separation between routing prefixes and subnet IDs can reduce
   the cost of edge network rehoming substantially, as explained in this
   section.


4.1.  Subnet Prefix Assignment

   The recommended practice for assigning subnet prefixes to links in an
   edge network is to give each link a single subnet ID that is unique
   across the edge network.  A link's subnet ID is combined with a each
   of the edge network's routing prefixes to form the set of subnet
   prefixes for the link.  Within the scope of the edge network, a link
   can then be identified based on its subnet ID alone, and the routing
   prefix attached to the subnet ID does not have to be considered.


4.2.  Router Configuration

   For a router to inform hosts and other routers about the subnet
   prefixes that are valid on a link it attaches to, the router must
   learn these subnet prefixes up front.  Nowadays, routers are
   typically configured with entire subnet prefixes.  This practice
   requires costly reconfiguration of subnet prefixes in each individual
   router when the edge network rehomes.  The reconfiguration overhead
   can be reduced substantially if edge network operators follow the
   recommended practice for subnet prefix assignment described in
   Section 4.1, and configure routers with the subnet ID of each link
   they attach to and, separately, a list of the routing prefixes shared
   by all links in the edge network.  A router then builds the set of
   subnet prefixes for a link automatically by concatenating each of the
   routing prefixes with the subnet ID for this link.

   In the event of edge network rehoming, the list of routing prefixes
   gets updated, but the subnet ID of each link remains unchanged.  It
   is then sufficient to distribute a new list of routing prefixes
   across all routers in the edge network.  Since this list is the same
   for all links in the edge network, router reconfiguration becomes
   simpler than it would be if entire subnet prefixes were to be
   replaced.  Once a router has automatically reconstructed the subnet
   prefixes of a link that it attaches to, it starts advertising the new
   subnet prefixes to hosts on the link, and announces them via the
   edge-network-internal routing protocol.  This causes hosts to
   automatically reconfigure their network protocol stacks and updates



Vogt                     Expires April 29, 2010                [Page 23]

Internet-Draft                   Six/One                    October 2009


   the routing table in other routers.

   The reconfiguration process during rehoming can be further simplified
   by using only the link-local subnet prefix, or unique local
   [rfc4193-unique-local-ip6] subnet prefixes on links to which no hosts
   attach.  These subnet prefixes include provider-independent routing
   prefixes that do not change during edge network rehoming.

   The recommended subnet prefix assignment practice also reduces the
   cost of configuration and rehoming-related reconfiguration of routers
   that are responsible for rewriting the addresses in packets.  These
   routers must generally know the set of subnet prefixes that are valid
   on the link from which a packet was sent, so as to ensure that a
   rewritten address belongs to the same address bunch (and hence to the
   same host) as the original address.  Replacing the routing prefix
   alone may in general not be sufficient since subnet prefixes of the
   same link may differ also in their subnet IDs.  (The IPv6 addressing
   architecture [rfc4191-ip6-architecture] leaves edge network operators
   the freedom to assign subnet prefixes of arbitrary structure to their
   links.)  On the other hand, if edge network operators follow the
   recommended subnet prefix assignment practice, all subnet prefixes on
   a link use the same subnet ID.  Address rewriting then does affect
   only a routing prefix, and it can be accomplished without knowledge
   of the subnet prefixes in use on the link from which a packet
   originates.


4.3.  Host Configuration

   It is in some cases desired to manually preconfigure a host with an
   address for itself or for certain correspondent hosts.  As an
   example, a simple application might hard-code the address of a server
   that it needs to contact, or a network management script may included
   hard-coded addresses for test or debugging purposes.  Such address
   preconfiguration increases the costs of edge network rehoming because
   each of the preconfigured addresses must then be changed.  This is
   oftentimes a cumbersome manual process.

   With Six/One, host reconfiguration due to rehoming can be eliminated
   by using unique local addresses for address preconfiguration.  Unique
   local addresses have a randomized, provider-independent routing
   prefix that the edge network operator chooses autonomously.  Hosts in
   the same edge network can use unique local addresses -- as both
   source and destination addresses -- to communicate with each other.
   Applications on the host can furthermore use the unique local address
   as a primary local address when communicating with a correspondent
   host in a different edge network.  The unique local address then
   always gets rewritten to an address in the host's address bunch,



Vogt                     Expires April 29, 2010                [Page 24]

Internet-Draft                   Six/One                    October 2009


   which the host has automatically configured based on the subnet
   prefixes of the link it attaches to.  To enable the correspondent
   host to verify that the unique local address and the address bunch
   belong together, the preconfigured address can be included in the
   computation of the interface identifier.

   By definition, two hosts in the same edge network never use the same
   unique local address.  Chances that the unique local addresses of
   hosts in different edge networks collide are negligible given the
   randomized selection of routing prefixes for these addresses.

   It would theoretically be possible to preconfigure a host also with
   the unique local address of a correspondent host in a different edge
   network.  The unique local subnet prefix of the other edge network
   would then have to be known in the host's edge network, and a router
   on the path of the host's packets would have to rewrite the
   correspondent host's unique local address to an address with the
   other edge network's provider-dependent routing prefixes.  However,
   for simplicity, it is recommended here that hosts obtain the
   addresses of correspondent hosts in other edge networks through DNS.


4.4.  Configuration of Traffic Control and Analysis Equipment

   Networking equipment for traffic control and analysis, such as a
   firewall or an intrusion detection system, generally uses the
   addresses in intercepted packets to identify the sending and
   receiving hosts.  This is based on the assumption that a host's
   address remains stable throughout the duration of a communication
   session.  For the networking equipment to function correctly in the
   presence of Six/One, hosts must be identified in a way that allows
   the subnet prefixes in a host's address to change during a session.

   Unique identification of hosts that reside in the same edge network
   as the piece of networking equipment under consideration is
   straightforward if edge network operators follow the recommended
   practice for subnet prefix assignment described in Section 4.1.  All
   subnet prefixes of a particular link then have the same subnet ID,
   and the addresses in a host's address bunch differ only in their
   routing prefixes.  Networking equipment can thus uniquely identify a
   host in the local edge network based on only the subnet ID and the
   interface identifier of the host's addresses.

   In practice, networking equipment may be preconfigured with a
   "routing mask", indicating the common length of the routing prefixes
   that the edge network has obtained from its different providers.
   Assuming the routing prefix length is L, the routing mask can be
   thought of as a string of 128 bits of which the first L bits are "1"



Vogt                     Expires April 29, 2010                [Page 25]

Internet-Draft                   Six/One                    October 2009


   and the last 128-L bits are "0".  A bit-wise And operation between a
   host's address and the inverted routing mask then yields a bit string
   that uniquely identifies the host across Six/One-related address
   changes.

   Since networking equipment in one edge network has in general no
   knowledge on the structure of subnet prefixes used in remote edge
   networks, it must identify correspondent hosts in remote edge
   networks differently than hosts in the local edge network.  Even if
   the operator of a remote edge network also followed the subnet prefix
   assignment practice described in Section 4.1, there could still be a
   link in a third edge network with the same subnet ID and a different
   routing prefix.  Networking equipment could hence confuse
   correspondent hosts in different remote edge networks if it
   identified those correspondent hosts based on only their subnet IDs
   and interface identifiers.  On the other hand, since a host in the
   local edge network selects a separate context identifier for each
   correspondent host it communicates with, a correspondent host can be
   uniquely identified based on this context identifier in combination
   with the subnet ID and interface identifier in the address of the
   host in the local edge network.

   Figure 6 illustrates the operation of a firewall that identifies
   hosts as described above.  The figure shows an edge network that
   multi-homes with two providers.  Based on an estimated need to
   address hosts on up to 2^16 links, the edge network operator has
   requested one 48-bit routing prefix from each provider.  Provider P1
   has assigned routing prefix PP1::/48 to the edge network, and
   provider P2 has assigned PP2::/48.  Accordingly, the edge network's
   routing mask amounts to FF:FF:FF:FF:FF:FF::/48.  The remaining 16
   bits inside 64-bit subnet prefixes are then used to form subnet IDs.
   The single link visible in Figure 6 is assigned subnet ID SID.  This
   in combination with the two routing prefixes obtained by the edge
   network yields two subnet prefixes, PP1:SID::/64 and PP2:SID::/64,
   that are to be advertised by the router shown in the figure.
   Figure 6 furthermore shows two hosts, X and Y, that attach to the
   same link as the router.  The interface identifiers that the hosts
   use to configure address bunches are IIDx and IIDy, respectively.
   Since the interface identifier is the same for all addresses in a
   bunch, and so is the subnet ID, hosts X and Y can be identified by
   the address postfixes ::SID:IIDx and ::SID:IIDy, respectively.  This
   is exactly what the firewall inside the edge network does for host X,
   which at that point is communicating with correspondent host Z. The
   firewall furthermore identifies correspondent host Z based on the
   context identifier CIDx, which host X uses for the communication
   session with host Z, and host X's address postfix ::SID:IIDx.  The
   firewall hence continues to function correctly when Six/One causes
   either of the hosts to switch to a different address in its



Vogt                     Expires April 29, 2010                [Page 26]

Internet-Draft                   Six/One                    October 2009


   respective bunch.  There is also no need to reconfigure the firewall
   when the edge network rehomes.

                                              +------------------+
                                              |                  |
                                              |      host Z      |
                                              |                  |
                                              +------------------+
                                                        |
       _________________________________________________|___________
      (                                                             )
     (                                                               )
     (                         Internet core                         )
     (                                                               )
      (_____________________________________________________________)
                   |                                   |
       ____________|____________           ____________|____________
      (                         )         (                         )
     (       ISP P1 assigns      )       (       ISP P2 assigns      )
     ( IP address block PP1::/48 )       ( IP address block PP2::/48 )
      (_________________________)         (_________________________)
                   |                                   |
        ___________|___________________________________|___________
       (           |                                               )
      (            |                                                )
     (             |                  edge network using           )
     (             |           routing mask FF:FF:FF:FF:FF:FF::/48   )
     (             |                                                 )
     (             |                                                 )
     (      ===============            firewall associates           )
     (       |___|___|___|      "from host X" = "from ::SID:IIDx"    )
     (       |_|___|___|_|        "to host X" = "to ::SID:IIDx"      )
     (       |___|___|___|    "from host Z" = "to ::SID:IIDx, CIDx"  )
     (       |_|___|___|_|    "to host Z" = "from ::SID:IIDx, CIDx"  )
      (            |                                                )
       (___________|_______________________________________________)
                   |
     --------+-----+---------------+------access link------+----------
             |                     |                       |
     +---------------+    +------------------+    +------------------+
     | access router |    |   host X using   |    |   host Y using   |
     |  advertises   |    | IP address bunch |    | IP address bunch |
     | PP1:SID::/64  |    |   PP1:SID:IIDx   |    |   PP1:SID:IIDy   |
     | PP2:SID::/64  |    |   PP2:SID:IIDx   |    |   PP2:SID:IIDy   |
     |               |    | +context ID CIDx |    | +context ID CIDy |
     +---------------+    +------------------+    +------------------+

       Figure 6: Operation of a firewall in the presence of Six/One



Vogt                     Expires April 29, 2010                [Page 27]

Internet-Draft                   Six/One                    October 2009


5.  Discussion

   This section attends to the feasibility of Six/One as a universal
   solution for the routing and addressing problem.  It discusses the
   incentives Internet players have to deploy and use Six/One, and it
   describes a transition plan for moving the current Internet towards a
   Six/One-capable Internet.  The section furthermore explains how Six/
   One could help bringing forward a universal solution for source
   address validation.


5.1.  Incentives for Deployment

   The success of a solution for the routing and addressing problem
   hinges on its acceptance by the three Internet players -- end users,
   edge network operators, and providers.  Acceptance, in turn, depends
   on the degree to which a solution satisfies the objectives of a
   player relative to the costs that a deployment entails for the
   player.

   In the case of Six/One, the main hurdle for universal deployment is a
   widespread support in hosts.  At first glance, it may seem difficult
   to enforce such widespread support, in particular since a significant
   part of Six/One's functionality is for the benefit of edge network
   operators and does not directly benefit the hosts themselves.  On the
   other hand, end users are oftentimes not directly involved in host
   upgrades.  Mobile phones or Internet-ready entertainment equipment
   typically have a rather short lifetime, which makes a medium-term
   introduction of new networking protocols well feasible.  Major
   operating systems for personal computers incorporate highly automated
   upgrade routines, which allows for even short-term introduction of
   new software.  The introduction of new host-based networking
   technology may hence turn out to be more facile than the introduction
   of technology that requires technical, and oftentimes also
   administrative, co-operation of edge network operators or providers.

   Edge network operators are likely to benefit most from Six/One. It is
   therefore legitimate to expect them to willingly adopt the practices
   recommended in Section 4.

   Providers are expected to embrace the introduction of Six/One because
   the sole use of provider-dependent addressing space inside the
   transit domain will facilitate a smaller routing table size and less
   frequent routing table updates.  This benefit is considered
   paramount, and therefore likely to compensate for the small cost of
   slightly higher packet sizes, which Six/One incurs due to in-band
   signaling for context setup and identification.  Barring the
   increased packet size, providers remain unaffected by an introduction



Vogt                     Expires April 29, 2010                [Page 28]

Internet-Draft                   Six/One                    October 2009


   of Six/One. A provider may at most agree to perform address rewriting
   on behalf of an edge network.  Such a co-operation would take place
   as part of a business relationship between the provider and the edge
   network, and would hence be driven by economic objectives.


5.2.  Transition

   Transition towards a widespread deployment of Six/One could proceed
   in two phases.

   1.  In the first phase, support for Six/One will be introduced into
       hosts, and edge network operators will gradually adopt the
       practices recommended in Section 4.  To avoid disruptions of
       communication sessions with legacy correspondent hosts, hosts
       with support for Six/One rewrite an address only after a received
       Context Setup option in an IPv6 Destination Options extension
       header indicates that also the correspondent host supports Six/
       One. For the same reason, routers refrain from rewriting an
       address in packets that do not contain a Context ID option in an
       IPv6 Destination Options extension header.  The Context ID
       option, too, indicates bilateral Six/One support since it is used
       only by Six/One hosts that have received a Context Setup option
       from the correspondent host.

   2.  The second phase begins when there is reasonably widespread Six/
       One support in hosts.  Both host and edge networks can now begin
       to initiate address rewrites.

   To aid transition, two operational modes should be differentiated for
   Six/One software on hosts.  In "conservative mode", Six/One will only
   adapt to address rewrites that were performed in the network or by
   the instance of Six/One on a correspondent host.  Six/One software
   running in conservative mode should also provide support for legacy
   correspondent hosts, which do not understand Context Setup and
   Context ID options in an IPv6 Destination Options extension header.

   More sophisticated Six/One software may further support a
   "progressive mode", in which address rewrites may also be initiated
   by the Six/One instance on the host itself.  While conservative mode
   provides the necessary functionality to adapt to network-side address
   rewrites, progressive mode additionally enables a host to replace the
   source address selected by an application with another address that
   corresponds to a different provider.  Progressive mode is useful when
   a Six/One instance is aware of alternative providers and the quality
   of service these providers deliver.  For example, if a provider
   selected at application level has recently performed poorly or become
   defunct, Six/One may autonomously rewrite the source address in



Vogt                     Expires April 29, 2010                [Page 29]

Internet-Draft                   Six/One                    October 2009


   packets received from the application in order to suggest to the edge
   network that the packets be routed via a different provider.  During
   the first transition phase, Six/One software on hosts should operate
   in conservative mode only, since Six/One support on a correspondent
   host can then not necessarily be expected.  Six/One software that
   supports progressive mode may be switched to that mode when the
   second transition phase begins.

   End users benefit from Six/One in that the protocol enables their
   hosts to suggest packets to be routed via a preferred provider.  End
   users can hence be expected not to hinder Six/One-related host
   upgrades.  Host upgrades will furthermore occur mostly transparently
   to the end users, either through replacement of old networking
   equipment, or through automated software upgrades.  The introduction
   of Six/One software in the first transition phase will hence occur
   rather smoothly.  Adoption of the recommended practices in edge
   networks will be driven by the prospects of reduced network
   reconfiguration costs during rehoming, which apply independently of
   Six/One support on hosts or the practices of other edge network
   operators.  Multi-homed edge network will further be motivated by the
   prospective ability to rewrite addresses as of the second transition
   phase, since this ability will accommodate their traffic engineering
   strategies.


5.3.  Easing Universal Source Address Validation

   Protection against IP spoofing has until today never become
   universal.  The reason for this is that available source address
   validation techniques such as ingress filtering are missing
   deployment incentives for edge network operators or providers.  Six/
   One can help in this regard because it enables routers to rewrite
   subnet prefixes in packets' source addresses, thus automatically
   fixing subnet prefixes that are topologically incorrect.

   In a typical deployment of Six/One, border routers -- either inside
   the edge network or in the providers's network -- ensure that the
   source addresses in packets leaving the edge network have the routing
   prefix of the provider they are going through.  (Failure to do so
   would prevent return traffic to go via the same provider and hence
   defeat efficient provider fail-over.)  An efficient way of
   implementing a routing prefix check would be for a border router to
   simply overwrite the routing prefix in the source address of every
   packet leaving the edge network.  Access routers then only need to
   verify the subnet ID in the packets they forward.  This is a simple
   task given that there is only a single, stable subnet ID per link.
   In contrast to ingress filtering today, this task would not require
   reconfiguration when the edge network rehomes.



Vogt                     Expires April 29, 2010                [Page 30]

Internet-Draft                   Six/One                    October 2009


6.  Security Considerations

   This section addresses potential security threats for Six/One, and it
   describes how Six/One protects against these threats.

   o  Impersonation.  The default address bunch protection mechanism
      described in Section 3.4 mitigates the threat of impersonation
      attacks.  Alternatively, if Six/One is combined with a host
      mobility, host multi-homing, or host identity protocol, such as
      Mobile IPv6 or the Host Identity Protocol, the address ownership
      proof performed by that protocol can replace the default address
      ownership proof of Six/One, as described in Section 3.4.

   o  Inverse impersonation.  In an inverse impersonation attack, an
      attacker tricks a correspondent host into believing that it is
      communicating with the attacker, while in fact it communicates
      with a victim host.  This attack would require the attacker to
      build an address bunch that includes the victim host's address.
      Such fraud that is prevented by the default address bunch
      protection mechanism described in Section 3.4.

   o  Redirection-based flooding.  The protection against impersonation
      described in Section 3.4 mitigates attacks against a specific
      victim host because an attacker cannot easily construct an address
      bunch that includes the victim host's address.  Redirection-based
      flooding attacks against networks could be protected against
      through reachability verification -- as it is done in Shim6 or
      Mobile IPv6, for example.  On the other hand, redirection-based
      flooding attacks require IP spoofing.  So given the fact that Six/
      One eases universal source address validation (see Section 5.3),
      extra signaling for flooding prevention might actually no longer
      be necessary.



















Vogt                     Expires April 29, 2010                [Page 31]

Internet-Draft                   Six/One                    October 2009


7.  IANA Considerations

   This document has no actions for IANA.
















































Vogt                     Expires April 29, 2010                [Page 32]

Internet-Draft                   Six/One                    October 2009


8.  Acknowledgment

   The author would like to thank Jari Arkko, Pekka Nikander, Steven
   Blake, Lars Westberg, Mikko Sarela, Mark Doll, Lixia Zhang, Tony Li,
   Geoff Huston, Brian E. Carpenter, Marcelo Bagnulo, Erik Nordmark,
   Lars Eggert, Pekka Savola, Magnus Westerlund, Jonne Soininen, Loa
   Andersson, David Ward, John Scudder, Gert Doering, Olaf Kolkman, Stig
   Venaas, Thomas C. Schmidt, Kotikalapudi Sriram, Jordi Palet, Andras
   Csaszar, Jan M. Melen, Petri Jokela, Patrik Salmela, Borje Ohlman,
   Anders Eriksson, and Attila Mihaly for valuable feedback on the
   solution to the routing and addressing problem presented in this
   document, and for interesting discussions on the routing and
   addressing problem as such.

   This document was generated using the XML2RFC tool.




































Vogt                     Expires April 29, 2010                [Page 33]

Internet-Draft                   Six/One                    October 2009


9.  References

9.1.  Normative References

   [ietf-shim6-hba]
              Bagnulo, M., "Hash Based Addresses (HBA)", IETF Internet
              draft draft-ietf-shim6-hba-03.txt (work in progress),
              June 2007.

   [rfc2119-rfc-keywords]
              Bradner, S., "Key Words for Use in RFCs to Indicate
              Requirement Levels", IETF BCP 14, RFC 2119, March 1997.

   [rfc3972-cga]
              Aura, T., "Cryptographically Generated Addresses (CGA)",
              IETF Request for Comments 3972, March 2005.



9.2.  Informative References

   [ietf-shim6-proto]
              Nordmark, E. and M. Bagnulo, "Shim6: Level 3 Multihoming
              Shim Protocol for IPv6", IETF Internet draft
              draft-ietf-shim6-proto-08.txt (work in progress),
              May 2007.

   [nikander-ram-generix-proxying]
              Nikander, P., "Generic Proxying as a Deployment Tool
              (GEPROD)", IETF Internet draft
              draft-nikander-ram-generix-proxying-00.txt (work in
              progress), January 2007.

   [odell-8+8]
              O'Dell, M., "8+8 - An Alternate Addressing Architecture
              for IPv6", IETF Internet draft draft-odell-8+8-00.txt
              (work in progress), October 1996.

   [rfc4191-ip6-architecture]
              Hinden, R. and S. Deering, "IP Version 6 Addressing
              Architecture", IETF RFC 4191, February 2006.

   [rfc4193-unique-local-ip6]
              Hinden, R. and B. Haberman, "Unique Local IPv6 Unicast
              Addresses", IETF RFC 4193, October 2005.

   [schuetz-nid-arch]
              Schuetz, S., Winter, R., Burness, L., Eardley, P., and B.



Vogt                     Expires April 29, 2010                [Page 34]

Internet-Draft                   Six/One                    October 2009


              Ahlgren, "Node Identity Internetworking Architecture",
              IETF Internet draft draft-schuetz-nid-arch-00.txt (work in
              progress), September 2007.
















































Vogt                     Expires April 29, 2010                [Page 35]

Internet-Draft                   Six/One                    October 2009


Appendix A.  Change Log

   The following is a list of technical changes that were made from
   version 00 to version 01 of the document.  Editorial revisions are
   not explicitly mentioned.

   o  Section 4.3 -- Clarified support for preconfigured addresses in
      applications.

   o  Section 5.2 -- Enhanced backward-compatibility: Hosts and routers
      rewrite addresses only after both end hosts are known to support
      Six/One.







































Vogt                     Expires April 29, 2010                [Page 36]

Internet-Draft                   Six/One                    October 2009


Author's Address

   Christian Vogt
   Ericsson Research, NomadicLab
   Hirsalantie 11
   02420 Jorvas
   Finland

   Email: christian.vogt@ericsson.com










































Vogt                     Expires April 29, 2010                [Page 37]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/