<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-softwire-stateless-4v6-motivation-05"
     ipr="trust200902">
  <front>
    <title abbrev="Solution Motivations">Motivations for Carrier-side
    Stateless IPv4 over IPv6 Migration Solutions</title>

    <author fullname="Mohamed Boucadair" initials="M." role="editor"
            surname="Boucadair">
      <organization>France Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Rennes</city>

          <region></region>

          <code>35000</code>

          <country>France</country>
        </postal>

        <email>mohamed.boucadair@orange.com</email>
      </address>
    </author>

    <author fullname="Satoru Matsushima" initials="S." surname="Matsushima">
      <organization>Softbank Telecom</organization>

      <address>
        <postal>
          <street></street>

          <city>Tokyo</city>

          <country>Japan</country>
        </postal>

        <email>satoru.matsushima@tm.softbank.co.jp</email>
      </address>
    </author>

    <author fullname="Yiu Lee" initials="Y." surname="Lee">
      <organization>Comcast</organization>

      <address>
        <postal>
          <street></street>

          <country>US</country>
        </postal>

        <email>Yiu_Lee@Cable.Comcast.com</email>
      </address>
    </author>

    <author fullname="Olaf Bonness" initials="O." surname="Bonness">
      <organization>Deutsche Telekom</organization>

      <address>
        <postal>
          <street></street>

          <country>Germany</country>
        </postal>

        <email>Olaf.Bonness@telekom.de</email>
      </address>
    </author>

    <author fullname="Isabel Borges" initials="I." surname="Borges">
      <organization>Portugal Telecom</organization>

      <address>
        <postal>
          <street></street>

          <country>Portugal</country>
        </postal>

        <email>Isabel@ptinovacao.pt</email>
      </address>
    </author>

    <author fullname="Gang Chen" initials="G." surname="Chen">
      <organization>China Mobile</organization>

      <address>
        <postal>
          <street>53A,Xibianmennei Ave.</street>

          <city>Beijing</city>

          <region>Xuanwu District</region>

          <code>100053</code>

          <country>China</country>
        </postal>

        <email>chengang@chinamobile.com</email>
      </address>
    </author>

    <date day="13" month="November" year="2012" />

    <workgroup>Softwires Working Group</workgroup>

    <abstract>
      <t>IPv4 service continuity is one of the most pressing problems that
      must be resolved by Service Providers during the IPv6 transition period
      &ndash; especially after the exhaustion of the public IPv4 address
      space. Current standardization effort that addresses IPv4 service
      continuity focuses on stateful mechanisms. This document elaborates on
      the motivations for the need to undertake a companion effort to specify
      stateless IPv4 over IPv6 approaches.</t>

      <!---->

      <t></t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>When the global IPv4 address space is exhausted, Service Providers
      will be left with an address pool that cannot be increased anymore. Many
      services and network scenarios will be impacted by the lack of IPv4
      public addresses. Providing access to the (still limited) IPv6 Internet
      only won't be sufficient to address the needs of customers, as most of
      them will continue to access legacy IPv4-only services. Service
      Providers must guarantee their customers that they can still access IPv4
      contents although they will not be provisioned with a global IPv4
      address anymore. Means to share IPv4 public addresses are unavoidable
      <xref target="RFC6269"></xref>.</t>

      <t>Identifying the most appropriate solution(s) to the IPv4 address
      exhaustion as well as IPv4 service continuity problems and deploying
      them in a real network with real customers is a very challenging and
      complex process for all Service Providers. There is no one size fits all
      solution. Each Service Provider has to take into account its own context
      (e.g., service infrastructures), policies and marketing strategy (a
      document that informs Service Providers about the impact of the IPv4
      address shortage, and provides some recommendations and guidelines, is
      available at <xref target="EURESCOM"></xref>).</t>

      <t>Current standardization efforts to address the IPv4 service
      continuity issue focuses on stateful mechanisms that share global IPv4
      addresses between customers with NAT (Network Address Translation)
      capabilities in the network. Because of some caveats of such stateful
      approaches, the Service Provider community feels that a companion effort
      is required to specify stateless IPv4 over IPv6 approaches. In the
      context of address sharing, states should be maintained in other
      equipments, e.g. customer premises equipment or host.</t>

      <t>This document focuses on carrier-side stateless IPv4 over IPv6.</t>

      <t>More discussions about stateless vs. stateful can be found at <xref
      target="RFC6144"></xref>.</t>
    </section>

    <section title="Terminology">
      <t>This document makes use of the following terms:</t>

      <t><list hangIndent="5" style="hanging">
          <t hangText="State:"><xref target="RFC1958">as used in </xref>.</t>

          <t hangText="Session state:">refers to an information state as
          defined in Section 2.3 of <xref target="RFC2663"></xref>. In
          particular, it refers to the state maintained by the NAT so that
          datagrams pertaining to a session are routed to the right node.
          Note, TCP/UDP sessions are uniquely identified by the tuple of
          (source IP address, source TCP/UDP port, target IP address, target
          TCP/UDP port) while ICMP query sessions are identified by the tuple
          of (source IP address, ICMP query ID, target IP address).</t>

          <t hangText="User-session state:">refers to session state belonging
          to a given user.</t>

          <t hangText="Stateful 4/6 solution">(or stateful solution in short):
          denotes a solution where a NAT in the Service Provider's network
          maintains user-session states <xref
          target="I-D.ietf-behave-lsn-requirements"></xref>. The NAT function
          is responsible for sharing the same IPv4 address among several
          subscribers and for maintaining user-session state. </t>

          <t hangText="Stateless  4/6 solution">(or stateless solution in
          short): denotes a solution which does not require any per-user state
          (see Section 2.3 of <xref target="RFC1958"></xref>) to be maintained
          by any IP address sharing function in the Service Provider's
          network. A dependency between an IPv6 prefix and IPv4 address is
          assumed. In an IPv4 address sharing context, dedicated functions are
          enabled in the CPE router to restrict the source IPv4 port numbers.
          Within this document, "port set" and "port range" terms are used
          interchangeably. </t>
        </list></t>
    </section>

    <section anchor="motivations"
             title="Why Stateless IPv4 over IPv6 Solutions are Needed?">
      <t><!----></t>

      <t><?rfc subcompact="no"?></t>

      <t>The following sub-sections discuss different aspects that motivate
      this effort.</t>

      <section anchor="simplification"
               title="Network Architecture Simplification">
        <t>The activation of the stateless function in the Service Provider's
        network does not introduce any major constraint on the network
        architecture and its engineering. The following sub-sections elaborate
        on these aspects.</t>

        <section anchor="network_dim" title="Network Dimensioning">
          <t>Because no per-user state <xref target="RFC1958"></xref> is
          required, a stateless solution does not need to take into account
          the maximum number of simultaneous user-sessions and the maximum
          number of new user-sessions per second to dimension its networking
          equipment. Like current network dimensioning practices, only
          considerations related to the customers number, traffic trends and
          the bandwidth usage need be taken into account.</t>
        </section>

        <section anchor="no_intra" title="No Intra-domain Constraint">
          <t>Stateless IPv4/IPv6 interconnection functions can be ideally
          located at the boundaries of an Autonomous System (e.g., Autonomous
          System Border Routers (ASBRs) that peer with external IPv4 domains);
          in such case intra-domain paths are not altered: there is no need to
          force IP packets to cross a given node for instance; intra-domain
          routing processes are not tweaked to direct the traffic to dedicated
          nodes. Stateless solutions optimize CPE-to-CPE communication in that
          packets don't go through the interconnection function.</t>
        </section>

        <section anchor="log"
                 title="Logging - No Need for Dynamic Binding Notifications">
          <t>Network abuse reporting requires traceability <xref
          target="RFC6269"></xref>. To provide such traceability, prior to
          IPv4 address sharing, logging the IPv4 address assigned to a user
          was sufficient and generates relatively small logs. The advent of
          stateful IPv4 address allows dynamic port assignment, which then
          requires port assignment logging. This logging of port assignments
          can be considerable.</t>

          <t>In contrast, static port assignments do not require such
          considerable logging. The volume of the logging file may not be seen
          as an important criterion for privileging a stateless approach
          because stateful approaches can also be configured (or designed) to
          assign port ranges and therefore lead to acceptable log volumes.</t>

          <t>If a dynamic port assignment mode is used, dedicated interfaces
          and protocols must be supported to forward binding data records
          towards dedicated platforms. The activation of these dynamic
          notifications may impact the performance of the dedicated device.
          For stateless solutions, there is no need for dynamic procedures
          (e.g., using SYSLOG) to notify a mediation platform about assigned
          bindings.</t>

          <t>Some Service Providers have a requirement to use only existing
          logging systems and to avoid introducing new ones (mainly because of
          Capital Expenditure (CAPEX) considerations). This requirement is
          easily met with stateless solutions.</t>
        </section>

        <section anchor="proto"
                 title="No Additional Protocol for Port Control is Required">
          <t>Stateless solutions do not require activating a new dynamic
          signaling protocol in the end-user CPE in addition to those already
          used. In particular, existing protocols (e.g., UPnP IGD:2 <xref
          target="UPnP-IGD"></xref>) can be used to control the NAT mappings
          in the CPE.<list style="empty">
              <t>Note: To overcome some security concerns, IGD:2 authorization
              framework <xref target="UPnP-IGD"></xref> should be used and
              security considerations elaborated in <xref
              target="Sec_DCP"></xref> should be taken into account.</t>
            </list></t>
        </section>
      </section>

      <section title="Operational Tasks and Network Maintenance Efficiency">
        <t></t>

        <section anchor="current" title="Preserve Current Practices">
          <t>If stateless solutions are deployed, common practices are
          preserved. In particular, the maintenance and operation of the
          network do not require any additional constraints such as: path
          optimization practices, enforcing traffic engineering policies,
          issues related to traffic oscillation between stateful devices,
          load-balancing the traffic or load sharing the traffic among
          egress/ingress points can be used, etc. Particularly, <list
              style="symbols">
              <t>anycast-based schemes can be used for load-balancing and
              redundancy purposes between nodes embedding the Stateless
              IPv4/IPv6 interconnection function.</t>

              <t>asymmetric routing to/from the IPv4 Internet is natively
              supported and no path-pinning mechanisms have to be additionally
              implemented.</t>
            </list></t>
        </section>

        <section anchor="planned" title="Planned Maintenance Operations">
          <t>Since no state is maintained by stateless IPv4/IPv6
          interconnection nodes, no additional constraint needs to be taken
          into account when upgrading these nodes (e.g., adding a new service
          card, upgrading hardware, periodic reboot of the devices, etc.). In
          particular, current practices that are enforced to (gracefully)
          reboot or to shutdown routers can be maintained.</t>
        </section>

        <section anchor="reliability" title="Reliability and Robustness">
          <t>Compared to current practices (i.e., without a Carrier Grade NAT
          (CGN) in place), no additional capabilities are required to ensure
          reliability and robustness in the context of stateless solutions.
          Since no state is maintained in the Service Provider's network,
          state synchronization procedures are not required.</t>

          <t>High availability (including failure recovery) is ensured owing
          to best current practices in the field.</t>
        </section>

        <section anchor="multi" title="Support of Multi-Vendor Redundancy">
          <t>Deploying stateful techniques, especially when used in the
          Service Providers networks, constrains severely deploying
          multi-vendor redundancy since very often proprietary vendor-specific
          protocols are used to synchronize state. This is not an issue for
          the stateless case. Concretely, the activation of the stateless
          IPv4/IPv6 interconnection function does not prevent nor complicate
          deploying devices from different vendors.</t>

          <t>This criterion is very important for Service Providers because
          they want to avoid being locked into one vendor for their entire
          network and they want to operate multi-vendor-supplied networks.</t>
        </section>

        <section anchor="qualification"
                 title="Simplification of Qualification Procedures">
          <t>The introduction of new functions and nodes into operational
          networks follows strict procedures elaborated by Service Providers.
          These procedures include in-lab testing and field trials. Because of
          their nature, stateless implementations optimize testing time and
          procedures:</t>

          <t><list style="symbols">
              <t>The specification of test suites to be conducted should be
              shorter;</t>

              <t>The required testing resources (in terms of manpower) are
              likely to be less solicited that they are for stateful
              approaches.</t>
            </list>One of the privileged approaches to integrate stateless
          IPv4/IPv6 interconnection function consists in embedding stateless
          capabilities in existing operational nodes (e.g., IP router). In
          this case, any software or hardware update would require to execute
          non-regression testing activities. In the context of the stateless
          solutions, the non-regression testing load due to an update of the
          stateless code is expected to be minimal.</t>

          <t>For the stateless case, testing effort and non-regression testing
          are to be taken into account for the CPE side. This effort is likely
          to be lightweight compared to the testing effort, including the
          non-regression testing, of a stateful function which is co-located
          with other routing functions for instance.</t>
        </section>
      </section>

      <section title="Facilitating Service Evolution">
        <t></t>

        <section anchor="identification" title="Implicit Host Identification">
          <t>Service Providers do not offer only IP connectivity services but
          also added value services (a.k.a., internal services). Upgrading
          these services to be IPv6-enabled is not sufficient because of
          legacy devices. In some deployments, the delivery of these
          added-value services relies on implicit identification mechanism
          based on the source IPv4 address. Due to address sharing, implicit
          identification will fail <xref target="RFC6269"></xref>; replacing
          implicit identification with explicit authentication will be seen as
          a non acceptable service regression by the end users (less Quality
          of Experience (QoE); refer to <xref target="RFC6462">Section 4.2
          </xref>).</t>

          <t>When a stateless solution is deployed, implicit identification
          for internal services is likely to be easier to implement: the
          implicit identification should be updated to take into account the
          port range and the IPv4 address. Techniques as those analyzed in
          <xref target="I-D.ietf-intarea-nat-reveal-analysis"></xref> are not
          required for the delivery of these internal services if a stateless
          solution is deployed.</t>

          <t>Note stateful approaches configured to assign port ranges allow
          also to support implicit host identification.</t>
        </section>

        <section anchor="organisation" title="No Organizational Impact">
          <t>Stateless solutions adopt a clear separation between the
          IP/transport layers and the service layers; no service interference
          is to be observed when a stateless solution is deployed. This clear
          separation:</t>

          <t><list style="hanging">
              <t hangText="Facilitates service evolution:">Stateless solutions
              admit applications which can be deployed without enabling any
              application-specific function (e.g., Application Level Gateway
              (ALG)) in the Service Provider's network. Avoiding ALGs is
              highly desirable.</t>

              <t hangText="Limits vendor dependency:">The upgrade of
              value-added services does not involve any particular action from
              vendors that provide devices embedding the stateless IPv4/IPv6
              interconnection function.</t>

              <t
              hangText="No service-related skills are required for network operators who    manage devices that embed the IPv4/IPv6 interconnection function:">IP
              teams can be in charge of these devices; there is a priori no
              need to create a dedicated team to manage and to operate devices
              embedding the stateless IPv4/IPv6 interconnection function. The
              introduction of stateless capabilities in the network are
              unlikely to degrade management costs.</t>
            </list></t>
        </section>
      </section>

      <section title="Cost Minimization Opportunities">
        <t>To make decision for which solution is to be adopted, Service
        Providers usually undertake comparative studies about viable technical
        solutions. It is not only about technical aspects but also economical
        optimization (both CAPEX and Operational Expenditure (OPEX)
        considerations). From a Service Provider perspective, stateless
        solutions may be more attractive because it impacts the current
        network operations and maintenance model less than stateful solutions.
        <xref target="cost"></xref> shows the general correspondence between
        technical benefits and potential economic reduction opportunities.</t>

        <t>While not all Service Providers environments are the same, a
        detailed case study from one Service Provider <xref
        target="I-D.matsushima-v6ops-transition-experience"></xref> reports
        that stateless transition solutions can be considerably less expensive
        than stateful transition solutions.</t>

        <t><?rfc subcompact="yes" ?></t>

        <texttable anchor="cost" style="all"
                   title="Cost minimization considerations">
          <ttcol align="center">Section</ttcol>

          <ttcol align="center">Technical and Operation Benefit</ttcol>

          <ttcol align="center">Cost Area</ttcol>

          <c><xref target="network_dim"></xref></c>

          <c>Network dimensioning</c>

          <c>Network</c>

          <c><xref target="no_intra"></xref></c>

          <c>No Intra-domain constraint</c>

          <c>Network</c>

          <c><xref target="log"></xref></c>

          <c>Logging</c>

          <c>Network &amp; Ops</c>

          <c><xref target="proto"></xref></c>

          <c>No additional control protocol</c>

          <c>Network</c>

          <c><xref target="current"></xref></c>

          <c>Preserve current practices</c>

          <c>Ops</c>

          <c><xref target="planned"></xref></c>

          <c>Planned maintenance</c>

          <c>Ops</c>

          <c><xref target="reliability"></xref></c>

          <c>Reliability and robustness</c>

          <c>Network &amp; Ops</c>

          <c><xref target="multi"></xref></c>

          <c>Multi-Vendor Redundancy</c>

          <c>Network</c>

          <c><xref target="qualification"></xref></c>

          <c>Simple qualification</c>

          <c>Ops</c>

          <c><xref target="identification"></xref></c>

          <c>Implicit Host Identification for internal services</c>

          <c>Ops</c>

          <c><xref target="organisation"></xref></c>

          <c>Organizational Impact</c>

          <c>Ops</c>
        </texttable>

        <t><?rfc subcompact="no" ?></t>
      </section>
    </section>

    <section title="Discussion">
      <t>Issues common to all address sharing solutions are documented in
      <xref target="RFC6269"></xref>. The following sub-sections enumerate
      some open questions for a CPE-based stateless solution. There are no
      universal answers to these open questions since each Service Provider
      has its own constraints (e.g., available address pool, address sharing
      ratio, etc.).</t>

      <section anchor="dependency"
               title="Dependency Between IPv4 and IPv6 Address Assignments">
        <t>Complete stateless mapping implies that the IPv4 address and the
        significant bits that are used to encode the set of assigned ports can
        be retrieved from the IPv6 prefix assigned to the CPE. This
        requirement can be addressed by either using the IPv6 prefix also used
        to forward IPv6 traffic natively, or allocating two prefixes to the
        CPE (one that will be used to forward IPv6 traffic natively, and the
        other one to forward IPv4 traffic).</t>

        <t><list style="symbols">
            <t>Providing two IPv6 prefixes avoids the complexity that may be
            related to the adaptation of the IPv6 addressing scheme to the
            IPv4 addressing scheme. The drawback is the need to allocate two
            prefixes instead of one to each CPE and to announce them
            accordingly, possibly at the cost of jeopardizing the routing and
            forwarding efficiencies.</t>

            <t>The use of a single prefix to cover both the forwarding of IPv6
            and IPv4-in-IPv6 traffic avoids the need to maintain a double
            information (e.g., for customer identification and management
            purposes and for forwarding table maintenance purposes). This
            scheme somewhat links strongly the IPv4 addressing scheme to the
            allocated IPv6 prefixes. For Service Providers requiring to apply
            specific policies on per Address-Family (e.g., IPv4, IPv6), some
            provisioning tools (e.g., DHCPv6 option) may be required to derive
            in a deterministic way the IPv6 address to be used for the IPv4
            traffic based on the IPv6 prefix delegated to the home
            network.</t>
          </list></t>
      </section>

      <section anchor="efficiency" title="IPv4 Port Utilisation Efficiency">
        <t>CGN-based solutions, because they can dynamically assign ports,
        provide better IPv4 address sharing ratio than stateless solutions
        (i.e., can share the same IP address among a larger number of
        customers). For Service Providers who desire an aggressive IPv4
        address sharing, a CGN-based solution is more suitable than the
        stateless. However<list style="format %d:">
            <t>When port overloading is used, some applications are likely to
            be broken.</t>

            <t>in case a CGN pre-allocates port ranges, e.g.- to alleviate
            traceability complexity (see <xref target="log"></xref>), it also
            reduces its port utilization efficiency.</t>
          </list></t>
      </section>

      <section anchor="randomization" title="IPv4 Port Randomization">
        <t>Preserving port randomization <xref target="RFC6056"></xref> may be
        more or less difficult depending on the address sharing ratio (i.e.,
        the size of the port space assigned to a CPE). The CPE can only
        randomize the ports inside a fixed port range.</t>

        <t>More discussion to improve the robustness of TCP against Blind
        In-Window Attacks can be found at <xref target="RFC5961"></xref>.
        Other means than the (IPv4) source port randomization to provide
        protection against attacks should be used (e.g., use <xref
        target="I-D.vixie-dnsext-dns0x20"></xref> to protect against DNS
        attacks, <xref target="RFC5961"></xref> to improve the robustness of
        TCP against Blind In-Window Attacks, use IPv6).</t>
      </section>
    </section>

    <section title="Conclusion">
      <t>As discussed in <xref target="motivations"></xref>, stateless
      solutions provide several interesting features. Trade-off between the
      positive vs. negative aspects of stateless solutions is left to Service
      Providers. Each Service Provider will have to select the appropriate
      solution (stateless, stateful or even both) meeting its
      requirements.</t>

      <t>This document recommends to undertake as soon as possible the
      appropriate standardization effort to specify a stateless IPv4 over IPv6
      solution.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>No action is required from IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">
      <t>Except for the less efficient port randomization of and routing loops
      <xref target="RFC6324"></xref>, stateless 4/6 solutions are expected to
      introduce no more security vulnerabilities than stateful ones. Because
      of their stateless nature, they may in addition reduce denial of service
      opportunities.</t>
    </section>

    <section title="Contributors">
      <t>The following individuals have contributed to this document:</t>

      <figure>
        <artwork type="text/plain"><![CDATA[
      Christian Jacquenet
      France Telecom
      Email: christian.jacquenet@orange.com

      Pierre Levis
      France Telecom
      Email: pierre.levis@orange.com
      
      Masato Yamanishi
      SoftBank BB
      Email: myamanis@bb.softbank.co.jp
      
      Yuji Yamazaki
      Softbank Mobile
      Email: yuyamaza@bb.softbank.co.jp

      Hui Deng
      China Mobile
      Email: denghui02@gmail.com
      
]]></artwork>
      </figure>

      <t></t>
    </section>

    <section title="Acknowledgments">
      <t>Many thanks to the following individuals who provided valuable
      comments:</t>

      <figure align="center">
        <artwork><![CDATA[+---------------+---------------+---------------+---------------+
| X. Deng       | W. Dec        | D. Wing       | A. Baudot     |
| E. Burgey     | L. Cittadini  | R. Despres    | J. Zorz       |
| M. Townsley   | L. Meillarec  | R. Maglione   | J. Queiroz    |
| C. Xie        | X. Li         | O. Troan      | J. Qin        |
| B. Sarikaya   | N. Skoberne   | J. Arkko      | D. Lui        |
+---------------+---------------+---------------+---------------+

]]></artwork>
      </figure>

      <t></t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <?rfc include='reference.RFC.6144'?>

      <?rfc include='reference.RFC.1958'?>

      <?rfc include='reference.RFC.2663'?>

      <?rfc include='reference.RFC.6056'?>

      <reference anchor="EURESCOM"
                 target="http://archive.eurescom.eu/~pub/deliverables/documents/P1900-series/P1952/D2bis/P1952-D2bis.pdf">
        <front>
          <title>IPv4 address exhaustion: Issues and Solutions for Service
          Providers</title>

          <author fullname="Levis, P., Borges, I., Bonness, O. and L. Dillon L."
                  surname="Levis, P., Borges, I., Bonness, O. and L. Dillon L.">
            <organization></organization>
          </author>

          <date month="March" year="2010" />
        </front>
      </reference>

      <reference anchor="UPnP-IGD" target="http://upnp.org/specs/gw/igd2/">
        <front>
          <title>Universal Plug and Play (UPnP) Internet Gateway Device (IGD)
          V 2.0</title>

          <author fullname="UPnP Forum" surname="UPnP Forum">
            <organization></organization>
          </author>

          <date month="December" year="2010" />
        </front>
      </reference>

      <reference anchor="Sec_DCP" target="">
        <front>
          <title>Device Protection:1</title>

          <author fullname="UPnP Forum" surname="UPnP Forum">
            <organization>UPnP Forum</organization>
          </author>

          <date day="17" month="November" year="2009" />
        </front>
      </reference>

      <?rfc include='reference.RFC.6269'?>

      <?rfc include='reference.I-D.ietf-behave-lsn-requirements'?>

      <?rfc include='reference.I-D.vixie-dnsext-dns0x20'?>

      <?rfc include='reference.RFC.5961'?>

      <?rfc include='reference.RFC.6462'?>

      <?rfc include='reference.RFC.6324'?>

      <?rfc include='reference.I-D.matsushima-v6ops-transition-experience'?>

      <?rfc include='reference.I-D.ietf-intarea-nat-reveal-analysis'?>
    </references>
  </back>
</rfc>
