One document matched: draft-vyncke-v6ops-ipv6-only-thin-clients-00.xml
<?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>
| PAFTECH AB 2003-2026 | 2026-04-24 05:55:32 |