<?xml version="1.0" encoding="UTF-8"?>
<?rfc toc="yes"?>
<?rfc compact="yes"?>
<?rfc tocdepth="6"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc autobreaks="no"?>
<?rfc subcompact="no"?>

<rfc category="info" submissionType="IETF" consensus="yes" ipr="trust200902" docName="draft-palet-v6ops-ipv6-only-07">
  <front>
  <title abbrev="IPv6-only Definition">IPv6-only Terminology Definition</title>

    <author fullname="Jordi Palet Martinez" initials="J" surname="Palet Martinez">
      <organization>The IPv6 Company</organization>

      <address>
        <postal>
          <street>Molino de la Navata, 75</street>

          <city>La Navata - Galapagar</city>

          <region>Madrid</region>

          <code>28420</code>

          <country>Spain</country>
        </postal>

        <email>jordi.palet@theipv6company.com</email>

        <uri>http://www.theipv6company.com/</uri>
      </address>
    </author>

    <date year="2024"/>

		<workgroup>v6ops</workgroup>


		<abstract>
			<t>This document defines the terminology regarding the usage of 
			expressions such as "IPv6-only", in order to avoid confusions when 
			using them in IETF and other documents. The goal is that the reference 
			to "IPv6-only" describes the actual native functionality being used, 
			not the actual protocol support.</t>
		</abstract>
	</front>

	<middle>
		<section title="Introduction">
			<t>Due to the nature of the Internet and the different types of 
			users, parts of a network, providers, flows, etc., there is not a single
			and easy way to categorically say something such as "IPv6-only".</t>

			<t>The goal of this document is to depict this situation and agree 
			in a common language to be used for IETF and other documents, in order 
			to facilitate ourselves and future readers, the correct understanding 
			of what we are talking about.</t>
			
			<t>The term IPv6-only is being used by many IETF documents, with a clear 
			definition of the scope or terminology, for example <xref target="RFC6877"/>, 
			<xref target="RFC8585"/> and <xref target="RFC8683"/>.</t>

			<t>Note that all the references in this document are regarding the actual 
			usage of IPv4/IPv6, not the support of those protocols by nodes. 
			For example, a device or access network may support both IPv4 and IPv6, 
			however actually is only "natively" forwarding IPv6, because the link used 
			for that communication is only natively configured for IPv6. IPv4 may be used 
			as well, but it is being encapsulated or translated by means of IPv6. 
			So, from this perspective, this device is attached to an IPv6-only link.</t>
			
			<t>As such, a network service is considered IPv6-only if it forwards IPv6, 
			not IPv4, even if IPv4 is still supported and enabled but not configured 
			neither used in the nodes participating in the service.</t>

		</section>

		<section title="Context">
			<t>The transition from IPv4 to IPv6 is not something that can be done, 
			in the large majority of the cases, overnight and in a single step. 
			Consequently, in general, we are unable to talk about a whole network having 
			a "single and uniform" status regarding the IPv6 support, at least not 
			in the early deployment stages of an operator network.</t>

			<t>Even if possible, it is not frequent to deploy new IPv6 networks 
			which have no IPv4 connectivity at all, because at the current phase of the 
			universal goal of the IPv6 deployment, almost every network still need to 
			provide some kind of "access" to IPv4 sites. It is not feasible for most of 
			the operators to tell their customers "I can provide you IPv6 service, but 
			you will not be able to access all Internet contents and apps, because some  
			of them still don't support IPv6, so you will miss every content that 
			it is IPv4-only".</t>
			
			<t>Some networks may have IPv6-only support for specific purposes or  
			services. For example, a DOCSIS provider may have decided 
			that is worth the effort to get rid of IPv4 for the management network 
			of the cable-modems. Or a network that provides connectivity only to 
			IoT devices, may be IPv6-only.</t>

			<t>However, the "end-networks", in general, need to continue supporting 
			IPv4, as there are many devices or apps, in both corporate and end-user 
			networks (smartTV, IP cameras, etc.), which are IPv4-only and it is not 
			always feasible to update or replace them. Also if customer devices in 
			a LAN are IPv4-only, they will not be able to access IPv6-only services, 
			so this means that IPv6-only services can't be deployed unless it is done 
			in such way that some transition mechanism solves that problem as well 
			(example an IPv6-only Data Center, requires SIIT-DC)</t>
			
			<t>In IPv6-only access networks, IPv4 support may be provided by 
			mechanisms that allow "IPv4-as-a-service" (IPv4aaS, for example 
			by means of encapsulation and/or translation on top of IPv6).</t>

		</section>

		<section title="IPv6-only">
			<t>Consequently, considering the context described in the section above, 
			if we want to be precise and avoid confusing others, 
			we can't use the terminology "IPv6-only" in a generic way, and we need 
			to define what part of the network we are referring to.</t>
			
			<t>From that perspective, we define the "IPv6-only" status in a given part(s) 
			of a network, depending on if there is actual native forwarding of IPv4, so 
			IPv4 is not configured neither managed.</t>

		</section>

		<section title="IPv4-only">
			<t>Similarly, we define the "IPv4-only" status in a given part(s) 
			of a network, depending on if there is actual native forwarding of IPv6, so 
			IPv6 is not configured neither managed.</t>

		</section>

		<section title="Dual-stack">
			<t>This can be applied to a host, router, link, network (part), etc. It means 
			that both, IPv4 and IPv6 are reachable, without specifying how.</t>

		</section>


		<section title="Native dual-stack">
			<t>This can be applied to a host, router, link, network (part), etc. It means 
			that both, IPv4 and IPv6 are configured/used natively (without 
			the need of transition mechanisms).</t>

		</section>
		
		<section title="IPv6-only network">
			<t>IPv6-only can be used only if, a complete network, end-to-end, 
			is actually not natively forwarding IPv4, which will mean that 
			no-IPv4 addresses are configured, neither used for management, neither 
			the network is providing transition/translation support, neither 
			there is IPv4 transit/peering.</t>

			<t>This is the end of the road of the IPv4-to-IPv6 transition, however we 
			aren't there yet, in general at the time of writing this document, unless 
			we are referring to special or disconnected (from IPv4) networks.</t>

		</section>

		<section title="IPv6-only WAN/access">
			<t>IPv6-only WAN or access can be used only if the WAN or access network 
			isn't actually natively forwarding IPv4.</t>

		</section>

		<section title="IPv6-only LAN">
			<t>IPv6-only LAN(s) can be used only if the LAN(s), isn't actually 
			natively forwarding IPv4.</t>

		</section>


		<section title="IPv6-only host/router">
			<t>IPv6-only host/router can be used only if the host/router, 
			isn't actually using/forwarding IPv4, so IPv4 is unconfigured 
			and/or disabled in the external facing interfaces.</t>

			<t>Internal interfaces, such as loopback, can still be 
			using IPv4 (internally).</t>

		</section>

		<section title="Transitional IPv6 host/router">
			<t>Transitional IPv6 host/router is a dual-stack host/router 
			with IPv6-only WAN where IPv4 service support is provided by means of 
			transition mechanism, IPv4aaS (IPv4-as-a-service).</t>

		</section>

		<section title="IPv6-Mostly">
			<t>In order to provide a more comprehesive view, we also cite here the 
			IPv6-Mostly definition extracted from <xref target="I-D.link-v6ops-6mops"/>.  
			An IPv6-Mostly network segment is very similar to a dual-stack one, with two 
			additional key elements: a NAT64 (<xref target="RFC6146"/>) and 
			DHCVv4 infrastructure supporting 
			Option 108 (<xref target="RFC8925"/>). This way it can support a mix of 
			IPv4-only, dual-stack or IPv6-only clients, depending on the client 
			capabilities or configuration.</t>

		</section>

		<section title="Other cases">
			<t>Similar other cases or parts of the network can be considered as 
			IPv6-only if there is no actual native forwarding of IPv4 
			and in that case, after "IPv6-only" some word/short text pointing 
			to the specific case or part of the network needs to be used. 
			For instance, we could talk about "IPv6-only core" if a core network 
			is only natively forwarding IPv6.</t>

		</section>

		<section title="IPv4 Exclusion">
			<t>If an IPv6-only network or part of it, has strict filtering rules 
			to avoid IPv4 to be transported on top of IPv6, this should be 
			explicitly cited. For example, and enterprise LAN, where 
			employees can't use VPNs, tunnels, or even translations, could 
			be named as "IPv6-only LAN with IPv4 Exclusion".</t>

		</section>


		<section title="Security Considerations">
			<t>This document does not have any specific security considerations.</t>
		</section>

		<section title="IANA Considerations">
			<t>This document does not have any IANA considerations.</t>
		</section>

		<section title="Acknowledgements">
			<t>The author would like to acknowledge the inputs from Tim Chown, 
			Noah Maina, Lee Howard, Azael Fernandez Alcantara, Marcos Sanz Grosson and 
			Robert M. Hinden.</t>
		</section>
	</middle>

  <back>

    <references title="Normative References">
		<?rfc include="reference.RFC.6146" ?>
	    <?rfc include="reference.RFC.6877" ?>
	    <?rfc include="reference.RFC.8585" ?>
	    <?rfc include="reference.RFC.8683" ?>
	    <?rfc include="reference.RFC.8925" ?>
    </references>

    <references title="Informative References">
    	<?rfc include="reference.I-D.link-v6ops-6mops.xml" ?>
    </references>


  </back>


</rfc>
