<?xml version="1.0" encoding="US-ASCII"?>
<!-- This template is for creating an Internet Draft using xml2rfc,
     which is available here: http://xml.resource.org. -->
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!-- One method to get references from the online citation libraries.
     There has to be one entity for each item to be referenced. 
     An alternate method (rfc include) is described in the references. -->
<!ENTITY RFC2644 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2644.xml">
<!ENTITY RFC5970 SYSTEM "http://xml.resource.org/public/rfc/bibxml/reference.RFC.5970.xml">
]>
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<!-- used by XSLT processors -->
<!-- For a complete list and description of processing instructions (PIs), 
     please see http://xml.resource.org/authoring/README.html. -->
<!-- Below are generally applicable Processing Instructions (PIs) that most I-Ds might want to use.
     (Here they are set differently than their defaults in xml2rfc v1.32) -->
<?rfc strict="yes" ?>
<!-- give errors regarding ID-nits and DTD validation -->
<!-- control the table of contents (ToC) -->
<?rfc toc="yes"?>
<!-- generate a ToC -->
<?rfc tocdepth="3"?>
<!-- the number of levels of subsections in ToC. default: 3 -->
<!-- control references -->
<?rfc symrefs="yes"?>
<!-- use symbolic references tags, i.e, [RFC2119] instead of [1] -->
<?rfc sortrefs="yes" ?>
<!-- sort the reference entries alphabetically -->
<!-- control vertical white space 
     (using these PIs as follows is recommended by the RFC Editor) -->
<?rfc compact="yes" ?>
<!-- do not start each main section on a new page -->
<?rfc subcompact="no" ?>
<!-- keep one blank line between list items -->
<!-- end of list of popular I-D processing instructions -->
<rfc category="info" docName="draft-vyncke-v6ops-ipv6-only-thin-clients-00"
     ipr="trust200902">
  <!-- ***** FRONT MATTER ***** -->

  <front>
    <!-- The abbreviated title is used in the page header - it is only necessary if the 
         full title is longer than 39 characters -->

    <title abbrev="Pv6-Only for Wired Thin-Clients">IPv6-Only for Wired
    Thin-Clients</title>

    <!-- add 'role="editor"' below for the editors if appropriate -->

    <author fullname="Eric Vyncke" initials="E" surname="Vyncke">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>De Kleetlaan 6a</street>

          <city>Diegem</city>

          <country>Belgium</country>

          <code>1831</code>
        </postal>

        <phone>+32 2 778 4677</phone>

        <email>evyncke@cisco.com</email>
      </address>
    </author>

    <author fullname="Andrew Yourtchenko" initials="A" surname="Yourtchenko">
      <organization>Cisco</organization>

      <address>
        <postal>
          <street>De Kleetlaan 6a</street>

          <city>Diegem</city>

          <country>Belgium</country>

          <code>1831</code>
        </postal>

        <phone>+32478681281</phone>

        <email>ayourtch@cisco.com</email>
      </address>
    </author>

    <author fullname="Derk-Jan Valenkamp" initials="D" surname="Valenkamp">
      <organization>ETH Zurich</organization>

      <address>
        <postal>
          <street>Weinbergstrasse 43</street>

          <city>Zurich</city>

          <country>Switzerland</country>

          <code>8092</code>
        </postal>

        <phone>+41 44 632 50 86</phone>

        <email>derk-jan.valenkamp@id.ethz.ch</email>
      </address>
    </author>

    <date day="26" month="June" year="2015"/>

    <!-- If the month and year are both specified and are the current ones, xml2rfc will fill 
         in the current day for you. If only the current year is specified, xml2rfc will fill 
	 in the current day and month for you. If the year is not the current one, it is 
	 necessary to specify at least a month (xml2rfc assumes day="1" if not specified for the 
	 purpose of calculating the expiry date).  With drafts it is normally sufficient to 
	 specify just the year. -->

    <!-- Meta-data Declarations -->

    <area>Operations and Management</area>

    <workgroup>IPv6 Operations</workgroup>

    <!-- WG name at the upperleft corner of the doc,
         IETF is fine for individual submissions.  
	 If this element is not present, the default is "Network Working Group",
         which is used by the RFC Editor as a nod to the history of the IETF. -->

    <keyword>IPv6</keyword>

    <keyword>Boot</keyword>

    <keyword>Operational</keyword>

    <keyword>Wake on LAN</keyword>

    <keyword>PXE Boot</keyword>

    <!-- Keywords will be incorporated into HTML output
         files in a meta tag but they have no effect on text or nroff
         output. If you submit your draft to the RFC Editor, the
         keywords will be used for the search engine. -->

    <abstract>
      <t>While IPv6-only (no IPv4 at all) is becoming an objective, there are
      remaining issues on this road for the wired thin clients. This document
      enumerates of couple of them; each with a short description, followed by
      a description of the issue in IPv6-only networks then some
      solutions.</t>

      <t>It is expected that this document will grow by collecting other
      roadblocks and suggestions to remove them.</t>

      <!-- -->
    </abstract>
  </front>

  <middle>
    <section title="Wake-on-Lan">
      <t/>

      <section title="Description">
        <t>Wake-on-Lan also known as WOL is specified in <xref target="WOL"/>.
        It allows for a remote operator to wake a sleeping host in order to
        trigger software update while the host is sleeping (for example during
        the night of the week-end). It consists of sending a specially
        formatted frame for a specific host. This is called the magic packet:
        with the Ethernet payload having somewhere 6 bytes containing 0xFF
        followed by 16 times the network interface datalink-layer address.</t>
      </section>

      <section title="Issue">
        <t>As the host is sleeping, it does not transmit any packets and will
        not reply to neither ARP request nor Neighbor Solicitations. This
        means that the adjacent routers have lost the binding between datalink
        and network address and also that all layer-2 switches have lost the
        binding between the datalink-layer address and the port/interface. So,
        it is not possible to send a unicast IPv4 or IPv6 packet containing
        this magic packet as it will be dropped by the router (no adjacency
        information). In IPv4, a local configuration can allow the 'directed
        broadcast' (see <xref target="RFC2644">RFC2644</xref>)such that the
        magic packet can be sent to an IPv4 directed broadcast which will be
        sent to a datalink-layer broadcast, i.e. forwarded on all ports of all
        routers and switches in the same layer-2 domain. Therefore, the magic
        packet will reach all hosts including the sleeping one.</t>

        <t>In IPv6, there is no directed broadcast for good reason. Only a
        link-local multicast group such as ff02::1 for all link-local hosts.
        So, the magic packet for a single host could be sent to this multicast
        group, reaching all link-local hosts (as switches and routers will
        forward this packet to all ports/interfaces) and waking up the
        sleeping node. But, there is no solution for a remote operator to send
        this magic packet...</t>
      </section>

      <section title="Mitigation">
        <t>A trivial solution would be to hard code in the router
        configuration a specific global or ULA address to the broadcast
        data-link layer address. For example, to reach all nodes in
        2001:db8::/64, let's configure a static Neighbor Cache entry for
        2001:db8::cafe:c0:ffee as ff-ff-ff-ff-ff-ff. Then a remote operator
        can send the magic packet to this destination, it will be routed
        across the layer-3 network, will be addressed to the data-link layer
        broadcast address which will be flooded by all layer-2 switches on all
        their ports, finally reaching the sleeping host.</t>

        <t>This approach has two drawbacks:<list style="numbers">
            <t>provisioning of all those mappings in all routers</t>

            <t>opening a door to a denial of service attack: a remote hostile
            party could keep sending packets this is specific unicast address
            forcing all hosts to stay awake, hence wasting electrical energy.
            As this address is a unicast address which does not belong to any
            physical host on the layer-2 domain, then all nodes will silently
            discard this packet at the layer-3.</t>
          </list></t>

        <t>Another approach would be to have a management plane command (SNMP
        or Netconf) to send the magic packet directly to the Ethernet
        broadcast using any ethertype.</t>
      </section>
    </section>

    <section title="Preboot Execution Environment">
      <t/>

      <section title="Description">
        <t>Preboot Execution Environment also known as PXE is specified in
        <xref target="PXE21"/>. It allows for any host to boot a complete
        viable operating system and file system via the use of Dynamic Host
        Configuration Protocol and ancilliary protocols such as Trivial File
        Transfer Protocol and HyperText Transfer Protocol.</t>
      </section>

      <section title="Issue">
        <t>The specification has no mention of IPv6 and while DHCP and TFTP
        support IPv6, there are differences between DHCP for IPv4 and for
        IPV6. This lack of IPv6 support is addressed in <xref
        target="RFC5970">RFC5970</xref> but there are little to no
        implementation for this IPv6-enabled PXE. This makes impossible for a
        thin-client host to boot its complete operating system and file system
        over an IPv6-only network.</t>
      </section>

      <section title="Mitigation">
        <t>It is mainly an implementation issue in the boot PROM + DHCPv6
        servers. Some of the boot PROMS use flash technology so they could be
        reprogrammed to fully support <xref
        target="RFC5970">RFC5970</xref></t>

        <t>On the other hand, PXE boot over IPv6 is possible: see <xref
        target="Zimmer2013"/>, relying on Unified Extensible Firmware
        Interface <xref target="UEFI"/>.</t>
      </section>
    </section>

    <section title="3rd issue">
      <t>Placeholder for any further issue to be described later.</t>
    </section>

    <section title="IANA Considerations">
      <t>This document contains no IANA considerations.</t>
    </section>

    <section title="Security Considerations">
      <t>The security considerations are detailed in previous sections.</t>
    </section>

    <section title="Acknowledgements">
      <t>The author would like to thank Armin Wittman, Alain Fiocco, Steve
      Simlo, Stig Venaas for some discussions on this topic.</t>
    </section>
  </middle>

  <!--  *****BACK MATTER ***** -->

  <back>
    <references title="Normative References">
      &RFC5970;

      <reference anchor="WOL"
                 target="http://support.amd.com/TechDocs/20213.pdf">
        <front>
          <title>Magic Packet Technology</title>

          <author fullname="AMD" surname="AMD"/>

          <date year="1995"/>
        </front>
      </reference>

      <reference anchor="PXE21"
                 target="ftp://download.intel.com/design/archives/wfm/downloads/pxespec.pdf">
        <front>
          <title>Preboot Execution Environment (PXE) Specification</title>

          <author fullname="Intel" surname="Intel"/>

          <date year="1999"/>
        </front>
      </reference>

      <reference anchor="Zimmer2013"
                 target="http://vzimmer.blogspot.com/2013/10/configuring-ipv6-network-boot.html">
        <front>
          <title>Configuring an IPV6 network boot</title>

          <author fullname="Vincent" initials="V" surname="Zimmer">
            <organization/>
          </author>

          <date day="19" month="October" year="2013"/>
        </front>
      </reference>

      <reference anchor="UEFI"
                 target="http://www.uefi.org/sites/default/files/resources/UEFI%202_5.pdf">
        <front>
          <title>Unified Extensible Firmware Interface Specification</title>

          <author fullname="UEFI Forum">
            <organization/>
          </author>

          <date month="April" year="2015"/>
        </front>
      </reference>
    </references>

    <references title="Informative References">
      &RFC2644;
    </references>
  </back>
</rfc>
