add migration

1 files changed, 71 insertions, 5 deletions

diff --git a/draft-schanzen-gns.xml b/draft-schanzen-gns.xml
index 9901932..df8976a 100644
--- a/draft-schanzen-gns.xml
+++ b/draft-schanzen-gns.xml
@@ -2,6 +2,7 @@
 <!DOCTYPE rfc [
 <!ENTITY RFC1034 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1034.xml">
 <!ENTITY RFC1035 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1035.xml">
+<!ENTITY RFC1928 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.1928.xml">
 <!ENTITY RFC2119 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml">
 <!--<!ENTITY RFC2693 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2693.xml">-->
 <!ENTITY RFC2782 PUBLIC '' "http://xml.resource.org/public/rfc/bibxml/reference.RFC.2782.xml">
@@ -2963,6 +2964,7 @@ Purpose | Name            | References | Comment
      </references>
      <references>
        <name>Informative References</name>
+         &RFC1928;
          &RFC4033;
          &RFC6066;
          &RFC7363;
@@ -3144,9 +3146,14 @@ Purpose | Name            | References | Comment
         </front>
        </reference>
 
-
-
-
+       <reference anchor="nsswitch" target="https://www.gnu.org/software/libc/manual/html_node/Name-Service-Switch.html">
+         <front>
+           <title>System Databases and Name Service Switch</title>
+           <author>
+             <organization>GNU Project</organization>
+           </author>
+        </front>
+       </reference>
 
      </references>
      <section>
@@ -3309,7 +3316,7 @@ Value       Symbol            Symbol
             specification.
          </t>
        </section>
-       <section>
+       <section anchor="uc_virthost">
          <name>Virtual Hosting</name>
          <t>
            HTTP virtual hosting and TLS Server Name Indication are common
@@ -3382,7 +3389,66 @@ Host: 000G0037FH3QTBCK15Y8BCCNRVWPV17ZC7TSGB1C9ZG2TPGHZVFV1GMG3W
             For example, the name in the URL bar may remain as "www.example.gnu"
             even if the used unique name differs.
           </t>
-       </section>
+        </section>
+        <section>
+          <name>Migration Paths</name>
+          <t>
+            DNS resolution is built into a variety of existing software
+            components.
+            Most significantly operating systems and HTTP clients.
+            This section illustrates possible migration paths for both in order
+            to enable "legacy" applications to resolve GNS names.
+          </t>
+          <t>
+            One way to efficiently facilitate the resolution of GNS names
+            are GNS-enabled DNS server implementations.
+            Local DNS queries are thereby either rerouted or explicitly configured
+            to be resolved by a "DNS-to-GNS" server that runs locally.
+            This DNS server tries to interpret any incoming query for a name
+            as a GNS resolution request.
+            If no start zone can be found for the name and it does not end in
+            a zTLD, the server tries to resolve the name in DNS.
+            Otherwise, the name is resolved in GNS.
+            In the latter case, the resulting record set is converted to a DNS
+            answer packet and is returned accordingly.
+            An implementation of a DNS-to-GNS server can be found in
+            <xref target="GNUnet"/>.
+          </t>
+          <t>
+            A similar approach is to use operating systems extensions such as
+            the name service switch (<xref target="nsswitch"/>).
+            It allows the system administrator to configure plugins
+            which are used for hostname resolution.
+            A GNS name service switch plugin can be used in a similar fashion as
+            the "DNS-to-GNS" server.
+            An implementation of a glibc-compatible nsswitch plugin for GNS
+            can be found in <xref target="GNUnet"/>.
+          </t>
+          <t>
+            The methods above are usually also effective for HTTP client
+            software.
+            However, HTTP clients are commonly used in combination with
+            TLS.
+            TLS certificate validation and in particular server name indication
+            (SNI) requires additional logic in HTTP clients when GNS names are
+            in play (<xref target="uc_virthost"/>).
+            In order to transparently enable this functionality for migration
+            purposes, a local GNS-aware SOCKS5 proxy <xref target="RFC1928"/>
+            can be configured to resolve domain names.
+            The SOCKS5 proxy, similar to the DNS-to-GNS server, is capable
+            of resolving both GNS and DNS names.
+            In the event of a TLS connection request with a GNS name, the SOCKS5
+            proxy can act as a man-in-the-middle, terminating the TLS connection
+            and establishing a secure connection against the requested host.
+            In order to establish a secure connection, the proxy may use LEHO
+            and TLSA records stored in the record set under the GNS name.
+            The proxy must provide a locally trusted certificate for the GNS
+            name to the HTTP client which usually requires the generation and
+            configuration of a local trust anchor in the browser.
+            An implementation of this SOCKS5 proxy can be found in
+            <xref target="GNUnet"/>.
+          </t>
+        </section>
      </section>
      <section>
        <name>Example flows</name>