debian/0000755000000000000000000000000011731402365007170 5ustar debian/.keepdir0000644000000000000000000000010211731401603010577 0ustar This file is just there to keep this directory around. Ignore it. debian/README.Debian0000644000000000000000000000146511731401603011231 0ustar doc-rfc for Debian ------------------ Finding a RFC: /usr/share/doc/RFC/rfc-status.txt.gz has a list of all RFCs, the package they are in, and their current status. There are a few other indices in the same directory that you might want to look at. The RFCs are currently split in multiple packages: - doc-rfc-std: the current standard and draft standards - doc-rfc-std-proposed: the current proposed standards - doc-rfc-old-std: old standards (all flavours) - doc-rfc-fyi-bcp: the current for-your-information and best practices - doc-rfc-experimental: the current experimental RFCs - doc-rfc-misc: historic RFCs and current drafts - doc-rfc-informational: current informational RFCs - doc-rfc-others: old experimental RFCs and unclassified RFCs -- Iustin Pop , Tue, 3 Aug 2010 14:47:13 -0400 debian/README.source0000644000000000000000000000206711731401603011346 0ustar doc-rfc for Debian ------------------ This package has multiple upstream sources: - the actual tarball of all non-draft RFCs - many draft RFCs, downloaded from upstream rsync - html files showing each RFC's status, download from upstream website Creating a new version: The script debian/update-package.sh works on a local subdirectory tmp/ to retrieve the various materials used to create this package. (This directory should *not* go into either source or binary package!) The RFC-all.tar.gz should be used as doc-rfc_.orig.tar.gz (the touch command creates a flag file that shows the date). The other files (*.txt, *.html, rfc-index.xml) which are put under tmp/extra go into debian/extra. -- Iustin Pop , Mon, 2 Aug 2010 16:02:47 -0400 If you run git-import-orig make sure your /tmp partition is large enough. Otherwise pristine-tar may fail. See also bug #600724. My tmpfs was ~600MB and still too small. So I ran pristine tar manually: mkdir -p ~/tmp && TMPDIR=~/tmp \ pristine-tar debian/tmp/doc-rfc_20111105.orig.tar.gz upstream debian/TODO0000644000000000000000000000022011731401603007644 0ustar Bugs still open: 31383 74385 116567 172742 : lookup/search utilities 111218 111788 114754 115021 141149 163824 181884 : trouble with dhelp debian/changelog0000644000000000000000000001740111731401603011037 0ustar doc-rfc (20120225-2) unstable; urgency=low * Update dependencies (replaces/breaks) to fix upgrade problems (Closes: #661590). * Re-add "special-naming-scheme" rfc 17a (Closes: #591886). * Remove all mentions of old numeric packages in relationships, in order to simplify the dependencies. -- Iustin Pop Sun, 18 Mar 2012 16:45:41 +0100 doc-rfc (20120225-1) unstable; urgency=low [ Thomas Koch ] * Imported Upstream version 20111105 * update debhelper compat and policy standard * use debian/clean file * modernize debian/rules [ Iustin Pop ] * Imported Upstream version 20120225 * Update debian/extra files for upstream 20120225 * Standards version 3.9.3 (updated section of the metapackage) -- Iustin Pop Mon, 27 Feb 2012 23:00:36 +0100 doc-rfc (20100731-1) unstable; urgency=low * Adopt the package (Closes: #543883). * New upstream version (Closes: #287224, #366673, #377602). * Redo the way doc-base documents are registered (Closes: #200828, #215068, #201618) and their contents (Closes: #210587, #380689, #366118). * Change packaging scheme to eliminate the numeric packages and the confusion regarding where to find a given RFC (Closes: #223504, #223504). * Update/enhance the long description of packages (Closes: #209456, #209471, #209491, #209631), thanks Clément Stenac. -- Iustin Pop Wed, 04 Aug 2010 11:40:16 -0400 doc-rfc (20030621-3) unstable; urgency=low * Orphaning package. -- Daniel Baumann Thu, 27 Aug 2009 11:01:36 +0200 doc-rfc (20030621-2) unstable; urgency=low * New maintainer (Closes: #357591). -- Daniel Baumann Sat, 16 Feb 2008 11:25:00 +0100 doc-rfc (20030621-1) unstable; urgency=low * New docs (closes: #119589, #133124, #134524, #172857, #172857). * Spelling fix (closes: #124559). * Closed by NMU below (closes: #133563). * Switched to non-free/doc. I do believe that the arguments against it being free enough are bogus, but I'm tired of this fight. If someone else wants to clear this up, be my guest. Also adjusted copyright file (closes: #92810). * Bump Standard-Version. * resynced rules with a current dh-make * redesigned doc-base handling via /usr/lib/doc-rfc/register-doc-rfc-docs script (closes: #111218, #111788, #114754, #115021, #141149, #163824, #181884) * various small tweaks, such as allowing for RFC 17a -- Kai Henningsen Sun, 22 Jun 2003 19:50:11 +0200 doc-rfc (20010829-1.1) unstable; urgency=low * NMU * Make sure all scripts are executable before they're called (closes: #133563). -- Steve Langasek Wed, 2 Apr 2003 22:52:37 -0600 doc-rfc (20010829-1) unstable; urgency=low * New docs (closes:Bug#100185,Bug#109216) * moved from /usr/share/RFC to /usr/share/doc/RFC to accommodate dwww and dhelp (closes:Bug#97781) * Bug about antique package versions: (closes:Bug#104002) * Bogus report: Copyright is clearly DFSG-free: "This document and translations of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction of any kind, provided that the above copyright notice and this paragraph are included on all such copies and derivative works." (closes:Bug#92810) Don't waste my time with nonsense, Branden! * new /usr/share/doc/RFC/links directory (closes:Bug#92910,Bug#93723) -- Kai Henningsen Sun, 2 Sep 2001 15:29:59 +0200 doc-rfc (20010331-1) unstable; urgency=HIGH * Package split into various subpackages (closes:Bug#42668,Bug#67277) * Now including _all_ available RFCs (closes:Bug#42671,Bug#62585,Bug#74340,Bug#75013,Bug#75055,Bug#84483) Specific remarks: 62585: 1094,1813 in doc-rfc-1000-1999; 2339 in doc-rfc-2000-2999; 2664 in doc-rfc-fyi-bcp Other NFS RFCs: 2054, 2055, 2224, 2623, 2624, 2755, 3010 74340: 2033 in doc-rfc-2000-2999 75013: 2795 in doc-rfc-2000-2999 75055: 783 in doc-rfc-0001-0999 Current TFTP RFC: 1350, updates: 1785, 2347-2349 84483: 2104 in doc-rfc-2000-2999 (For those other RFCs, see /usr/share/RFC/rfc-status.txt.gz in doc-rfc-std to find out which package they are in) * Now using pristine source * Completely new Debianization (closes:Bug#70623,Bug#72279,Bug#75849,Bug#75850,Bug#75851,Bug#75852,Bug#75854) * RFCs moved to /usr/share/RFC (closes: Bug#62378) -- Kai Henningsen Sat, 31 Mar 2001 15:50:30 +0200 doc-rfc (2001.01-1) unstable; urgency=low * docs as of 2001-01-13 -- Kai Henningsen Sat, 13 Jan 2001 20:27:39 +0100 doc-rfc (2000.08-1) unstable; urgency=low * docs as of 2000-08-20 (closes:Bug# * added RFCs 1459 2810 2811 2812 2813 (closes:Bug#53944,Bug#54522) * change to debhelper (closes:Bug#56061) * eliminated some temporary files (closes:Bug#58183) -- Kai Henningsen Sun, 20 Aug 2000 12:34:57 +0200 doc-rfc (1999.08-1) unstable; urgency=low * docs as of 1999-08-02 * all-rfcs renamed all-included-rfcs to keep people from thinking this should really be all rfcs that exist (closes:Bug#32297,Bug#39142) - incidentally, there is no all-rfcs.txt.gz as mentioned in #39142 * include RFC 1153 (closes:Bug#34546) * include RFC 1321 (closes:Bug#40023) -- Kai Henningsen Mon, 26 Jul 1999 20:11:35 +0200 doc-rfc (1999.01-2) unstable; urgency=low * docs as of 1999-04-11 * include RFC 2139 -- Kai Henningsen Sun, 11 Apr 1999 16:08:36 +0200 doc-rfc (1999.01-1) frozen unstable; urgency=low * include draft standards (fixes:Bug#28547) * include RFC 2468 (fixes:Bug#28276) * Docs as of 1999-01-02 -- Kai Henningsen Sat, 5 Dec 1998 14:20:03 +0100 doc-rfc (1998.09-1) unstable; urgency=low * Docs as of 1998-09-17 * getst rewritten in perl, to get rid of shell errors, and also to get dramatic build speedups (fixes:Bug#21081,Bug#25742) * slight tweaks to makefile (fixes:Bug#25045) * Added several RFCs to other_rfcs.txt (fixes:Bug#23148,Bug#24945,Bug#26298) -- Kai Henningsen Sat, 11 Apr 1998 23:05:14 +0200 doc-rfc (1998.03-1) unstable; urgency=low * Docs as of 1998-03-14 * slight tweaks to scripts (fixes:Bug#15438,Bug#18137,Bug#19292) -- Kai Henningsen Fri, 13 Mar 1998 21:32:33 +0100 doc-rfc (1998.01-1) unstable; urgency=low * Docs as of 1998-01-10 * README added. Generator revamped. -- Kai Henningsen Mon, 5 Jan 1998 13:30:28 +0100 doc-rfc (1997.12-2) unstable; urgency=low * repaired bad ownership (a libc5 dpkg doesn't work with fakeroot) -- Kai Henningsen Mon, 22 Dec 1997 17:20:47 +0100 doc-rfc (1997.12-1) unstable; urgency=low * Added fixperms.sh (fixes:Bug#15357) * Docs as of 1997-12-11 * Docs as of 1997-11-28 -- Kai Henningsen Sun, 30 Nov 1997 20:50:13 +0100 doc-rfc (1997.10-1) unstable; urgency=low * Docs as of 1997-10-04 * Better RFC selection (fixes bug #11077) -- Kai Henningsen Sat, 4 Oct 1997 15:38:15 +0200 doc-rfc (1997.05-1) frozen unstable; urgency=low * Docs as of 1997-05-05 -- Kai Henningsen Mon, 5 May 1997 00:44:37 +0200 doc-rfc (1997.04-2) unstable; urgency=low * Architecture: should be all, not any -- Kai Henningsen Sat, 5 Apr 1997 22:26:46 +0200 doc-rfc (1997.04-1) unstable; urgency=low * Initial release. Docs as of 1997-03-30. -- Kai Henningsen Mon, 31 Mar 1997 22:40:49 +0200 debian/clean0000644000000000000000000000022211731401603010163 0ustar debian/rfc-status.txt debian/rfc-queue.txt debian/unused-files debian/files-to-compress debian/ln-failed.log debian/extra/update-package.include debian/compat0000644000000000000000000000000211731401603010360 0ustar 8 debian/control0000644000000000000000000002372011731401603010571 0ustar Source: doc-rfc Section: non-free/doc Priority: optional Maintainer: Iustin Pop Build-Depends: debhelper (>= 8), libhtml-parser-perl (>= 3), libxml-parser-perl Standards-Version: 3.9.3 Homepage: http://www.rfc-editor.org/ Vcs-Browser: http://git.debian.org/?p=collab-maint/doc-rfc.git Vcs-Git: git://git.debian.org/git/collab-maint/doc-rfc.git Package: doc-rfc Section: non-free/metapackages Architecture: all Depends: ${misc:Depends}, doc-rfc-std, doc-rfc-std-proposed, doc-rfc-fyi-bcp, doc-rfc-misc, doc-rfc-old-std, doc-rfc-others, doc-rfc-informational Description: RFC documents metapackage RFC (Request for Comments) documents are a series of technical and organizational notes about the Internet. They are edited by the Internet Engineering Task Force (IETF). . This is a metapackage that pulls in the new doc-rfc-xxx packages (those that most closely correspond to the old doc-rfc package). . It can be removed if users want just a subset of the RFCs. Package: doc-rfc-std Architecture: all Depends: ${misc:Depends} Replaces: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Breaks: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Description: Standard RFCs RFC (Request for Comments) documents are a series of technical and organizational notes about the Internet. They are edited by the Internet Engineering Task Force (IETF). . This package includes the following categories: . * Standard * Draft Standard Package: doc-rfc-std-proposed Architecture: all Depends: ${misc:Depends} Replaces: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), Breaks: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), Description: Proposed Standard RFCs RFC (Request for Comments) documents are a series of technical and organizational notes about the Internet. They are edited by the Internet Engineering Task Force (IETF). . This package includes the following categories: . * Proposed Standard Package: doc-rfc-old-std Architecture: all Depends: ${misc:Depends} Replaces: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Breaks: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Description: Old Standard RFCs RFC (Request for Comments) documents are a series of technical and organizational notes about the Internet. They are edited by the Internet Engineering Task Force (IETF). . This package includes the following categories: . * Obsoleted Standards * Obsoleted Draft Standards * Obsoleted Proposed Standards Package: doc-rfc-fyi-bcp Architecture: all Depends: ${misc:Depends} Replaces: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Breaks: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Description: FYI and BCP RFCs RFC (Request for Comments) documents are a series of technical and organizational notes about the Internet. They are edited by the Internet Engineering Task Force (IETF). . This package includes the following categories: . * For Your Information (FYI) subseries * Best Current Practice (BCP) subseries Package: doc-rfc-experimental Architecture: all Depends: ${misc:Depends} Replaces: doc-rfc (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Breaks: doc-rfc (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Description: Experimental RFCs RFC (Request for Comments) documents are a series of technical and organizational notes about the Internet. They are edited by the Internet Engineering Task Force (IETF). . This package includes the following categories: . * Experimental Package: doc-rfc-misc Architecture: all Depends: ${misc:Depends} Replaces: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Breaks: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Description: Historic and draft RFCs RFC (Request for Comments) documents are a series of technical and organizational notes about the Internet. They are edited by the Internet Engineering Task Force (IETF). . This package includes the following categories: . * Historic * drafts currently in the RFC Editor's publishing queue Package: doc-rfc-informational Architecture: all Depends: ${misc:Depends} Replaces: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Breaks: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-others (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Description: Informational RFCs RFC (Request for Comments) documents are a series of technical and organizational notes about the Internet. They are edited by the Internet Engineering Task Force (IETF). . This package includes the following categories: . * Informational RFCs Package: doc-rfc-others Architecture: all Depends: ${misc:Depends} Replaces: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Breaks: doc-rfc (<< ${source:Version}), doc-rfc-experimental (<< ${source:Version}), doc-rfc-fyi-bcp (<< ${source:Version}), doc-rfc-informational (<< ${source:Version}), doc-rfc-misc (<< ${source:Version}), doc-rfc-old-std (<< ${source:Version}), doc-rfc-std (<< ${source:Version}), doc-rfc-std-proposed (<< ${source:Version}), Description: Old experimental and unclassified RFCs RFC (Request for Comments) documents are a series of technical and organizational notes about the Internet. They are edited by the Internet Engineering Task Force (IETF). . This package includes the following categories: . * Obsoleted Experimental RFCs * Unclassified RFCs debian/copyright0000644000000000000000000002106011731401603011114 0ustar This package was debianized by Kai Henningsen on Sat, 31 Mar 2001 15:50:30 +0200. It was downloaded from (also contains web pages from and drafts from ) except the non-web files were actually downloaded with rsync. Upstream Authors: see the individual files; contact the RFC Editor at: , or see his homepage above. In general, as long as an individual RFC is kept intact, it can be copied freely. In detail: All newer RFCs carry individual copyright/license notices. Also, says the following: COPYRIGHTS AND PATENT RIGHTS IN RFCs 21 August 2007 _________________________________________________________________ This page summarizes the current rules governing RFC copyrights and dislaimers on patent ("Intellectual Property") rights. It is coordinated with the IETF documents "IETF Rights in Contributions", BCP 78/RFC 3978, "RFC 3978 Update to Recognize the IETF Trust", BCP 78/RFC 4748, and "Intellectual Property Rights in IETF Technology", BCP 79/RFC 3979. These documents are the result of a recent effort by the IPR Working Group of the IETF working group of the IETF, replacing earlier versions BCP 78/RFC 3667 and BCP 79/RFC 3668. An HTML version of this text is available at: http://www.rfc-editor.org/copyright.html. Earlier versions of this document: * copyright.1Mar05.txt * copyright.17Feb04.txt * copyright.23Jan01.txt (and earlier) _________________________________________________________________ BCP 78 (RFC 3978) specifies the copyright rules applicable to RFCs, aligning these rules with modern copyright law. The rules are generally intended to safeguard the integrity, future availability, and usefulness of published RFCs but continue the historical policy of free and open distribution and reuse of RFCs, to the extent possible. BCP 78 (RFC 4748) transfers ownership to the IETF Trust. As explained in BCP 78, there are two classes of RFCs: IETF submissions and RFC Editor ("independent") submissions. The rules for copyrights on IETF submissions are fully defined in BCP 78, but some aspects of these rules are left for the RFC Editor to define for independent submissions. There is really only one essential difference: the freedom to create derivative works; see below. Topics: o Reproduction Rules o Derivative Works o Intellectual Property Rights (IPR) on RFC Content o Boilerplate within I-Ds and RFCs _________________________________________________________________ Reproduction Rules The following rules control the reproduction of RFCs by third parties: 1. Copying and distributing an entire RFC [1] without changes: 1a. Copying for free redistribution is allowed and encouraged. [2] 1b. Inclusion of RFC copies within other documents or collections that are distributed for a fee is allowed. [3] Note: In case (1b), it is a courtesy to ask the RFC author(s) and to provide a copy of the final document or collection. 2. Translating RFCs into other languages: Translation and publication of an entire RFC into another language is allowed. It is courtesy to inform the RFC author(s) of such translation. 3. Copying and distributing an entire RFC with changes in format, font, etc.: Changing format, font, etc. is allowed only with permission of the author(s). With this permission, rule 1. applies. 4. Copying and distributing portions of an RFC: This is what the lawyers call "preparation of derivative works". The rules are shown below. NOTES: [1] "Entire" includes all the copyright and IPR boilerplate. [2] This case permits the present mirroring of RFCs on many web sites. [3] Anyone can take some RFCs, put them in a book, copyright the book, and sell it. This in no way inhibits anyone else from doing the same thing, or inhibits any other distribution of the RFCs. _____________________________________________________________ Derivative Works + Permissions for Derivative Works Section 3.3 of BCP 78 specifies a restricted allowance for derivative works from RFCs that were IETF submissions. An author of one of these RFCs is required only to permit derivative works for use within the IETF standards process (although an author is free to permit more general usage). This means, for example, that it may not be permissible for a third party to extract text from an IETF submission RFC for use in a "man" page or other system documentation, even if credit is given. For independent RFC submissions, however, the RFC Editor requires that authors grant unlimited permission for derivative works, with appropriate credits and citations. In summary: o 4a. Preparation of derivative works from an RFC that was an IETF contribution is allowed, but only for use within the IETF standards process. Proper credit and citations must be provided [BCP 78 Section 3.3.a(c)]. o 4b. Preparation of derivative works from an RFC that was an RFC Editor contribution is allowed. [BCP 78 Section 4.2a(C)] Credit and citations must be given. + No Derivative Works (NDW) Since many Internet Drafts (I-Ds) represent work in progress, I-D authors sometimes want to prevent all preparation of derivative works based on their documents. Although Section 5.2a of BCP 78 specifies "no derivative works" (NDW) boilerplate that may be included in an I-D, IETF rules generally do not allow NDW boilerplate in documents used in the Internet Standards process (see Section 7.3 of BCP 78). Use of NDW boilerplate in an independent submission must be approved by the RFC Editor. The RFC Editor will generally allow use of NDW boilerplate only for publication of proprietary protocols or the publication of specifications developed by other standards organizations, as discussed in Section 7.3 of BCP 78. _____________________________________________________________ Intellectual Property Rights (IPR) BCP 79 governs issues concerning possible intellectual property described in RFCs. An IETF submission will include a "Disclaimer of validity" [BCP 79 Section 5] boilerplate. For RFC Editor submissions, BCP 79 requires this boilerplate if IPR has previously been disclosed for this RFC; however, the RFC Editor's policy is to always include this boilerplate. It may be omitted from a independent submission only when it is clear from the nature of the RFC contents that no intellectual property rights could be claimed. Note also that an RFC should not contain a notice of the existence of specific relevant intellectual property (patents, etc.). (This point is unclear in BCP 79, but the RFC Editor has been informed that the IPR Working Group is quite clear about it.) _____________________________________________________________ Boilerplate Within I-Ds and RFCs The normal last-page boilerplate in an RFC is shown for [10]IETF submissions and for [11]RFC Editor (independent) submissions. This boilerplate should appear in every Internet Draft. This boilerplate has the following components: + Copyright Statement [BCP 78 Section 5.4]. Note that there is a very small difference between the Copyright statements for IETF submissions [BCP 78 Section 5.4] and RFC Editor submissions. + Disclaimer [BCP 78 Section 5.5] + Disclaimer of Validity (of IPR claims) [BCP 79 Section 5] _________________________________________________________________ _________________________________________________________________ debian/create-links.pl0000755000000000000000000000061111731401603012101 0ustar #! /usr/bin/perl -w use strict; my $dirs = `ls -d */usr/share/doc/RFC`; for my $dir (split /\s+/, $dirs) { print "$dir ...\n"; mkdir "$dir/links"; my $files = `ls $dir/*/rfc[0-9]* $dir/*/*/rfc[0-9]* 2>/dev/null`; for my $file (split /\s+/, $files) { $file =~ s[^.*/RFC/][../]; my $file2 = $file; $file2 =~ s[^.*/][]; symlink $file, "$dir/links/$file2" or die "$file: $!"; } } debian/distribute.sh0000755000000000000000000000172611731401603011705 0ustar #! /bin/bash TMP=tmp RFC=$TMP/usr/share/doc/RFC rm -rf $RFC mkdir -p $RFC/queue mkdir -p $RFC/links ln -i $( sed -e 's,^,extra/,' rfc-queue.txt | grep -v '\[missing]' ) \ $RFC/queue 2>ln-failed.log #ln -i .keepdir $TMP 2>>ln-failed.log mkdir -p $TMP/usr/lib/doc-rfc ln -i register-doc-rfc-docs $TMP/usr/lib/doc-rfc 2>>ln-failed.log ln -i doc-rfc-docs $TMP/usr/lib/doc-rfc 2>>ln-failed.log echo "- $(date) linking RFCs" perl makelinks.pl $RFC # what were they smoking?! ln -i ../rfc17a.* $RFC/unclassified 2>>ln-failed.log echo "- $(date) linking extra files" ln -i extra/{rfc-*.html,queue.html,rfcxx00.*} rfc-*.txt ../rfc-index.txt \ $RFC 2>>ln-failed.log find .. -links 1 > unused-files echo "- $(date) compressing..." find $RFC -type f -size +4k -print0 > files-to-compress # don't work on a dir find is running on cat files-to-compress | xargs -0 gzip --best -N -r -f echo "- $(date) finished compressing" chmod -R a-wx,a+rX,u+w $RFC debian/doc-rfc-experimental.doc-base.experimental0000644000000000000000000000044011731401603017263 0ustar Document: rfc-experimental Title: Experimental RFCs Abstract: Experimental RFCs Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/experimental/*.txt.gz Format: PostScript Files: /usr/share/doc/RFC/experimental/*.ps.gz Format: PDF Files: /usr/share/doc/RFC/experimental/*.pdf.gz debian/doc-rfc-experimental.install0000644000000000000000000000003711731401603014562 0ustar usr/share/doc/RFC/experimental debian/doc-rfc-experimental.lintian-overrides0000644000000000000000000000027111731401603016552 0ustar # special case: each RFC has it's own copyright years, so we don't put the # years in debian/copyright, so lintian fails doc-rfc-experimental binary: copyright-without-copyright-notice debian/doc-rfc-fyi-bcp.doc-base.best-current-practice0000644000000000000000000000033211731401603017627 0ustar Document: rfc-best-current-practice Title: Best Current Practice (BCP) subseries Abstract: Best Current Practice (BCP) subseries Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/best-current-practice/*.txt.gz debian/doc-rfc-fyi-bcp.doc-base.for-your-information0000644000000000000000000000054611731401603017536 0ustar Document: rfc-for-your-information Title: For Your Information (FYI) subseries Abstract: For Your Information (FYI) subseries Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/for-your-information/*.txt.gz Format: PostScript Files: /usr/share/doc/RFC/for-your-information/*.ps.gz Format: PDF Files: /usr/share/doc/RFC/for-your-information/*.pdf.gz debian/doc-rfc-fyi-bcp.install0000644000000000000000000000011711731401603013415 0ustar usr/share/doc/RFC/best-current-practice usr/share/doc/RFC/for-your-information debian/doc-rfc-fyi-bcp.lintian-overrides0000644000000000000000000000026411731401603015410 0ustar # special case: each RFC has it's own copyright years, so we don't put the # years in debian/copyright, so lintian fails doc-rfc-fyi-bcp binary: copyright-without-copyright-notice debian/doc-rfc-informational.doc-base.informational0000644000000000000000000000044611731401603017603 0ustar Document: rfc-informational Title: Informational RFCs Abstract: Informational RFCs Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/informational/*.txt.gz Format: PostScript Files: /usr/share/doc/RFC/informational/*.ps.gz Format: PDF Files: /usr/share/doc/RFC/informational/*.pdf.gz debian/doc-rfc-informational.install0000644000000000000000000000004011731401603014721 0ustar usr/share/doc/RFC/informational debian/doc-rfc-informational.lintian-overrides0000644000000000000000000000027211731401603016720 0ustar # special case: each RFC has it's own copyright years, so we don't put the # years in debian/copyright, so lintian fails doc-rfc-informational binary: copyright-without-copyright-notice debian/doc-rfc-misc.doc-base.drafts0000644000000000000000000000042211731401603014307 0ustar Document: rfc-drafts Title: RFC Editor Queue Abstract: These RFC drafts are in the RFC Editor posting queue. That means they will be published as a RFC soon (depending on the RFC Editor's workload). Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/queue/*.txt.gz debian/doc-rfc-misc.doc-base.historic0000644000000000000000000000041011731401603014645 0ustar Document: rfc-historic Title: Historic RFCs Abstract: Historic RFCs Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/historic/*.txt.gz Format: PostScript Files: /usr/share/doc/RFC/historic/*.ps.gz Format: PDF Files: /usr/share/doc/RFC/historic/*.pdf.gz debian/doc-rfc-misc.doc-base.old-historic0000644000000000000000000000023311731401603015424 0ustar Document: rfc-old-historic Title: Obsoleted Historical RFCs Abstract: RFCs Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/old/historic/*.txt.gz debian/doc-rfc-misc.install0000644000000000000000000000012211731401603013013 0ustar usr/share/doc/RFC/historic usr/share/doc/RFC/queue usr/share/doc/RFC/old/historic debian/doc-rfc-misc.lintian-overrides0000644000000000000000000000026111731401603015007 0ustar # special case: each RFC has it's own copyright years, so we don't put the # years in debian/copyright, so lintian fails doc-rfc-misc binary: copyright-without-copyright-notice debian/doc-rfc-old-std.doc-base.old-draft-standard0000644000000000000000000000052011731401603017110 0ustar Document: rfc-old-draft-standard Title: Obsoleted Draft Standard RFCs Abstract: Obsoleted Draft Standard RFCs Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/old/draft-standard/*.txt.gz Format: PostScript Files: /usr/share/doc/RFC/old/draft-standard/*.ps.gz Format: PDF Files: /usr/share/doc/RFC/old/draft-standard/*.pdf.gz debian/doc-rfc-old-std.doc-base.old-proposed-standard0000644000000000000000000000054211731401603017647 0ustar Document: rfc-old-proposed-standard Title: Obsoleted Proposed Standard RFCs Abstract: Obsoleted Proposed Standard RFCs Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/old/proposed-standard/*.txt.gz Format: PostScript Files: /usr/share/doc/RFC/old/proposed-standard/*.ps.gz Format: PDF Files: /usr/share/doc/RFC/old/proposed-standard/*.pdf.gz debian/doc-rfc-old-std.doc-base.old-standard0000644000000000000000000000045411731401603016020 0ustar Document: rfc-old-standard Title: Obsoleted Standard RFCs Abstract: Obsoleted Standard RFCs Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/old/standard/*.txt.gz Format: PostScript Files: /usr/share/doc/RFC/old/standard/*.ps.gz Format: PDF Files: /usr/share/doc/RFC/old/standard/*.pdf.gz debian/doc-rfc-old-std.install0000644000000000000000000000015411731401603013433 0ustar usr/share/doc/RFC/old/draft-standard usr/share/doc/RFC/old/proposed-standard usr/share/doc/RFC/old/standard debian/doc-rfc-old-std.lintian-overrides0000644000000000000000000000026411731401603015425 0ustar # special case: each RFC has it's own copyright years, so we don't put the # years in debian/copyright, so lintian fails doc-rfc-old-std binary: copyright-without-copyright-notice debian/doc-rfc-others.doc-base.old-experimental0000644000000000000000000000050411731401603016647 0ustar Document: rfc-old-experimental Title: Obsoleted Experimental RFCs Abstract: Obsoleted Experimental RFCs Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/old/experimental/*.txt.gz Format: PostScript Files: /usr/share/doc/RFC/old/experimental/*.ps.gz Format: PDF Files: /usr/share/doc/RFC/old/experimental/*.pdf.gz debian/doc-rfc-others.doc-base.unclassified0000644000000000000000000000046011731401603016050 0ustar Document: rfc-unclassified Title: Various Unclassified RFCs Abstract: Various Unclassified RFCs Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/unclassified/*.txt.gz Format: PostScript Files: /usr/share/doc/RFC/unclassified/*.ps.gz Format: PDF Files: /usr/share/doc/RFC/unclassified/*.pdf.gz debian/doc-rfc-others.install0000644000000000000000000000026511731401603013374 0ustar usr/share/doc/RFC/unclassified usr/share/doc/RFC/old/best-current-practice usr/share/doc/RFC/old/experimental usr/share/doc/RFC/old/informational usr/share/doc/RFC/old/unclassified debian/doc-rfc-others.lintian-overrides0000644000000000000000000000026311731401603015362 0ustar # special case: each RFC has it's own copyright years, so we don't put the # years in debian/copyright, so lintian fails doc-rfc-others binary: copyright-without-copyright-notice debian/doc-rfc-std-proposed.doc-base.proposed-standard0000644000000000000000000000047611731401603020156 0ustar Document: rfc-proposed-standard Title: Proposed Standard RFCs Abstract: Proposed Standard RFCs Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/proposed-standard/*.txt.gz Format: PostScript Files: /usr/share/doc/RFC/proposed-standard/*.ps.gz Format: PDF Files: /usr/share/doc/RFC/proposed-standard/*.pdf.gz debian/doc-rfc-std-proposed.install0000644000000000000000000000004411731401603014506 0ustar usr/share/doc/RFC/proposed-standard debian/doc-rfc-std-proposed.lintian-overrides0000644000000000000000000000027111731401603016500 0ustar # special case: each RFC has it's own copyright years, so we don't put the # years in debian/copyright, so lintian fails doc-rfc-std-proposed binary: copyright-without-copyright-notice debian/doc-rfc-std.dirs0000644000000000000000000000002011731401603012142 0ustar usr/lib/doc-rfc debian/doc-rfc-std.doc-base.draft-standard0000644000000000000000000000045411731401603015566 0ustar Document: rfc-draft-standard Title: Draft Standard RFCs Abstract: Draft Standard RFCs Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/draft-standard/*.txt.gz Format: PostScript Files: /usr/share/doc/RFC/draft-standard/*.ps.gz Format: PDF Files: /usr/share/doc/RFC/draft-standard/*.pdf.gz debian/doc-rfc-std.doc-base.global0000644000000000000000000000031611731401603014125 0ustar Document: rfc-0index Title: RFC indices Abstract: RFC indices Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/*.txt.gz Format: HTML Files: /usr/share/doc/RFC/*.html.gz Index: /usr/share/doc/RFC/ debian/doc-rfc-std.doc-base.standard0000644000000000000000000000041011731401603014460 0ustar Document: rfc-standard Title: Standard RFCs Abstract: Standard RFCs Section: Help/RFC Format: Text Files: /usr/share/doc/RFC/standard/*.txt.gz Format: PostScript Files: /usr/share/doc/RFC/standard/*.ps.gz Format: PDF Files: /usr/share/doc/RFC/standard/*.pdf.gz debian/doc-rfc-std.install0000644000000000000000000000114411731401603012657 0ustar usr/share/doc/RFC/draft-standard usr/share/doc/RFC/queue.html.gz usr/share/doc/RFC/rfc-best.html.gz usr/share/doc/RFC/rfc-draft.html.gz usr/share/doc/RFC/rfc-experimental.html.gz usr/share/doc/RFC/rfc-fyi.html.gz usr/share/doc/RFC/rfc-historic.html.gz usr/share/doc/RFC/rfc-index.txt.gz usr/share/doc/RFC/rfc-informational.html.gz usr/share/doc/RFC/rfc-proposed.html.gz usr/share/doc/RFC/rfc-queue.txt.gz usr/share/doc/RFC/rfc-standard.html.gz usr/share/doc/RFC/rfc-status.txt.gz usr/share/doc/RFC/rfc-unknown.html.gz usr/share/doc/RFC/rfcxx00.html.gz usr/share/doc/RFC/rfcxx00.txt.gz usr/share/doc/RFC/standard debian/doc-rfc-std.links0000644000000000000000000000005711731401603012333 0ustar bin/true usr/lib/doc-rfc/register-doc-rfc-docs debian/doc-rfc-std.lintian-overrides0000644000000000000000000000026011731401603014645 0ustar # special case: each RFC has it's own copyright years, so we don't put the # years in debian/copyright, so lintian fails doc-rfc-std binary: copyright-without-copyright-notice debian/doc-rfc.lintian-overrides0000644000000000000000000000025411731401603014060 0ustar # special case: each RFC has it's own copyright years, so we don't put the # years in debian/copyright, so lintian fails doc-rfc binary: copyright-without-copyright-notice debian/extra/0000755000000000000000000000000011731401603010305 5ustar debian/extra/draft-accilent-at-sign-00.txt0000644000000000000000000002664711731401603015522 0ustar Internet Engineering Task Force R. Simpson Internet-Draft Accilent Corp. Intended status: Informational July 31, 2010 Expires: February 1, 2011 Clarification of Proper Use of "@" (at sign) in URI-style Components draft-accilent-at-sign-00 Abstract Defacto standards have evolved that conflict with existing standards, specifically RFC 3986. This document clarifies the use of the "@" (at sign) in URIs and partial URI-like addresses. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 1, 2011. Copyright Notice Copyright (c) 2010 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Simpson Expires February 1, 2011 [Page 1] Internet-Draft Proper Use of "@" July 2010 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Requirements Language . . . . . . . . . . . . . . . . . . . 3 2. Issues . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3 3. Conclusions . . . . . . . . . . . . . . . . . . . . . . . . . . 3 4. Valid Syntax . . . . . . . . . . . . . . . . . . . . . . . . . 4 5. Invalid Syntax . . . . . . . . . . . . . . . . . . . . . . . . 5 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . . 6 8. Security Considerations . . . . . . . . . . . . . . . . . . . . 6 9. Normative References . . . . . . . . . . . . . . . . . . . . . 6 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 6 Simpson Expires February 1, 2011 [Page 2] Internet-Draft Proper Use of "@" July 2010 1. Introduction The original specification of the URI format is in RFC 3986 [RFC3986]. 1.1. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 2. Issues o Microblogging systems on social networks have introduced a shortcut feature where short replies with tokens containing an "@" and userinfo are automatically converted to HTML links. On systems where the host component is assumed to be the same as the host that is currently loaded into the user's browser, the defacto standard syntax that has evolved for these auto-generated links is for the "@" (at sign) to precede the userinfo. o Allowing the "@" to be placed in a non-standard location, especially in HTML links, results in confusion about which component follows the "@". For example, in "@its.me", is "its.me" the userinfo or the host component? o How would the "@userinfo" syntax currently being used be extended to support multiple networks? For example, in a mobile application that allows posting updates to multiple social networks, should it conform to the defacto standard and use "ExampleOnly.com@userinfo" or go against the current common usage and try to conform to the standards for URIs instead? Either option introduces potentially harmful confusion for users and automated systems. 3. Conclusions o It should be allowable to omit the host component of the authority syntax when the host component is known, such as when referencing another user on the same host or relative to a base URI. o Placing the "@" prior to the userinfo instead of following it should be explicitly prohibited due to the confusion it introduces and the security concerns due to possibly misinterpreting the userinfo and as a result of allowing users to become comfortable with misplacing the "@". Simpson Expires February 1, 2011 [Page 3] Internet-Draft Proper Use of "@" July 2010 4. Valid Syntax In RFC 3986 [RFC3986], the syntax of the authority component in a URI is defined as: authority = [ userinfo "@" ] host [ ":" port ] In addition, when the user is on a known host, on the same social network for example, the host and port components MAY be omitted: authority = [ userinfo "@" ] [ host [ ":" port ] ] When the host component is omitted, the userinfo component will be interpreted to be relative to the base URI of the current resource. For example: +--------------------------------------------------+ | http://ExampleOnly.com/JaneSmith | |--------------------------------------------------| | JohnDoe@ I will meet you there in a short while. | |__________________________________________________| will be interpreted as: +-----------------------------------------------------------------+ | http://ExampleOnly.com/JaneSmith | |-----------------------------------------------------------------| | JohnDoe@ExampleOnly.com I will meet you there in a short while. | |_________________________________________________________________| and (in HTML code): +----------------------------------+ | http://ExampleOnly.com/JaneSmith | |----------------------------------| | JohnDoe@ | |__________________________________| will be interpreted as: +------------------------------------------------------------------+ | http://ExampleOnly.com/JaneSmith | |------------------------------------------------------------------| | JohnDoe@ExampleOnly | |__________________________________________________________________| Simpson Expires February 1, 2011 [Page 4] Internet-Draft Proper Use of "@" July 2010 5. Invalid Syntax In a component that may at some time be interpreted to be a URI by some system the "@" MUST NOT be placed prior to the userinfo component: WRONG! [ "@" userinfo ] The "@" SHOULD not be placed prior to the userinfo component even in areas of plain text due to the potential for altering users' perception of the correct placement of the "@" separator. The "@" SHOULD NOT appear in an improper location in an HTML link: WRONG! @JohnDoe ExampleOnly.com@JohnDoe 6. Examples Improper usage when user being replied to is on the same social network +--------------------------------------------------+ | @JohnDoe I will meet you there in a short while. | |__________________________________________________| WRONG! How would the host component be appended if the user was on a different network? Figure 1 Standalone userinfo component when user being replied to is on the same social network +--------------------------------------------------+ | JohnDoe@ I will meet you there in a short while. | |__________________________________________________| This follows the current standard use of "@" in the authority component. Figure 2 Simpson Expires February 1, 2011 [Page 5] Internet-Draft Proper Use of "@" July 2010 Fully-qualified authority component when the user being replied to can be on a different host +-----------------------------------------------------------------+ | JohnDoe@ExampleOnly.com I will meet you there in a short while. | |_________________________________________________________________| Appending the host component after the "@" results in syntax that conforms to the RFC 3986. Figure 3 7. IANA Considerations This memo includes no request to IANA. 8. Security Considerations A URI does not in itself pose a security threat. However, as URIs are often used to provide a compact set of instructions for access to network resources, care must be taken to properly interpret the data within a URI, to prevent that data from causing unintended access, and to avoid including data that should not be revealed in plain text. However, placing an "@" in the wrong position, such as prior to the userinfo rather than following it, can introduce security risks, since the userinfo may be incorrectly interpreted or supplied to unauthorized systems. A defacto standard that places the "@" in the wrong location introduces additional security risks due to the increased likelihood that users will misplace the "@" as a result of the confusion. 9. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. Simpson Expires February 1, 2011 [Page 6] Internet-Draft Proper Use of "@" July 2010 Author's Address Robert Simpson Accilent Corp. P.O. Box 601 Lawrence, PA 15055 US Phone: +1-412 337-3113 Email: RobS.rfc5@MailScreen.com Simpson Expires February 1, 2011 [Page 7] debian/extra/draft-amundsen-item-and-collection-link-relations-05.txt0000644000000000000000000001727311731401603022770 0ustar Network Working Group M. Amundsen Internet-Draft February 5, 2012 Intended status: Informational Expires: August 8, 2012 The Item and Collection Link Relations draft-amundsen-item-and-collection-link-relations-05 Abstract RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members. Editorial Note (To be removed by RFC Editor) Distribution of this document is unlimited. Comments should be sent to the IETF Apps-Discuss mailing list (see ). Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 8, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents Amundsen Expires August 8, 2012 [Page 1] Internet-Draft The Item and Collection Link Relations February 2012 carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. 1. Introduction RFC 5988 standardized a means of indicating the relationships between resources on the Web. This specification defines a pair of reciprocal link relation types that may be used to express the relationship between a collection and its members. These link relation types can be applied to a wide range of use cases across multiple media types. For example, the 'collection' and 'item' link relation types are used in these media types: 1. OpenSearch 1.1: see Section 4.5.4.1 of [OpenSearch] 2. Maze+XML: see Section 3 of [Maze] 3. Collection+JSON: see Section 5 of [CollectionJSON] 2. Link Relations The following link relations are defined. 2.1. 'item' When included in a resource which represents a collection, the 'item' link relation identifies a target resource that represents a member of that collection. For example, if a resource represents a catalog of products, that same representation may include one or more links to resources which represent members of that catalog. ...

Product Group X Listing

... View Product X001 View Product X002 ... or, in the case of a Link Header field Amundsen Expires August 8, 2012 [Page 2] Internet-Draft The Item and Collection Link Relations February 2012 Link: <...>; rel="item"; title="View Product X001" Link: <...>; rel="item"; title="View Product X002" 2.2. 'collection' When included in a resource which represents a member of a collection, the 'collection' link relation identifies a target resource that represents a collection of which the context resource is a member. For example, if a resource represents a single product in a catalog, that same representation may include a link to a resource which represents a product group to which this single product belongs: Return to Product Group X or, in the case of a Link Header field Link: <...>; rel="collection"; title="Return to Product Group X" Since it is possible that a resource could be a member of multiple collections, multiple 'collection' link relations may appear within the same representation: View other widgets View all discontinued items The target resource representation need not be restricted to representing a list. It may simply be a document that provides details on the collection of which the context resource is a member: Link: <...>; rel="collection"; title="Shakespeare's Collected Works - A History" It should also be noted that that same link might represent an 'item' in one collection as well as a 'collection' itself. In this case both Link Relation values can be applied to the same link: Link: <...>; rel="collection item"; title="A Review of Issac Asimov's Collected Works - Vol. I" 3. IANA Considerations IANA is asked to register the 'collection' and 'item' Link Relations below as per [RFC5988]. Amundsen Expires August 8, 2012 [Page 3] Internet-Draft The Item and Collection Link Relations February 2012 3.1. 'item' Link Relation Registration Relation Name: item Description: The target IRI points to a resource that is a member of the collection represented by the context IRI. Reference: See Section 2 3.2. 'collection' Link Relation Registration Relation Name: collection Description: The target IRI points to a resource which represents a collection of which the context IRI is a member. Reference: See Section 2 4. Security Considerations The two link relation types defined in this document do not introduce any new security issues to those which are discussed in Section 7 of RFC5988 [RFC5988]. 5. Internationalisation Considerations The 'item' and 'collection' link relation types do not have any internationalization considerations other than those which are discussed in Section 8 of RFC5988 [RFC5988]. 6. References 6.1. Normative References [RFC5988] Nottingham, M., "Web Linking", RFC 5988, October 2010. Amundsen Expires August 8, 2012 [Page 4] Internet-Draft The Item and Collection Link Relations February 2012 6.2. Informative References [OpenSearch] Clinton, D., "Open Search 1.1", Work in Progress , March 2011, . [Maze] Amundsen, M., "Maze+XML - Format", Web Page , December 2010, . [CollectionJSON] Amundsen, M., "Collection+JSON - Document Format", Web Page , July 2011, . Appendix A. Acknowledgements The author gratefully acknowledges the contributions of Julian Reschke and Mykyta Yevstifeyev. Author's Address Mike Amundsen EMail: mca@amundsen.com URI: http://amundsen.com Amundsen Expires August 8, 2012 [Page 5] debian/extra/draft-arkko-ipv6-only-experience-05.txt0000644000000000000000000014501411731401603017470 0ustar Network Working Group J. Arkko Internet-Draft A. Keranen Intended status: Informational Ericsson Expires: August 10, 2012 February 7, 2012 Experiences from an IPv6-Only Network draft-arkko-ipv6-only-experience-05 Abstract This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. The document covers practical experiences as well as road blocks and opportunities for this type of a network setup. The document also makes some recommendations about where such networks are applicable and what should be taken into account in the network design. The document also discusses further work that is needed to make IPv6-only networking applicable in all environments. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on August 10, 2012. Copyright Notice Copyright (c) 2012 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect Arkko & Keranen Expires August 10, 2012 [Page 1] Internet-Draft IPv6-Only Experiences February 2012 to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Technology and Terminology . . . . . . . . . . . . . . . . . . 4 3. Network Setup . . . . . . . . . . . . . . . . . . . . . . . . 4 3.1. The IPv6-Only Network . . . . . . . . . . . . . . . . . . 5 3.2. DNS Operation . . . . . . . . . . . . . . . . . . . . . . 6 4. General Experiences . . . . . . . . . . . . . . . . . . . . . 7 5. Experiences with IPv6-Only Networking . . . . . . . . . . . . 9 5.1. Operating Systems . . . . . . . . . . . . . . . . . . . . 9 5.2. Programming Languages and APIs . . . . . . . . . . . . . . 10 5.3. Instant Messaging and VoIP . . . . . . . . . . . . . . . . 11 5.4. Gaming . . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5. Music Services . . . . . . . . . . . . . . . . . . . . . . 13 5.6. Appliances . . . . . . . . . . . . . . . . . . . . . . . . 13 5.7. Other Differences . . . . . . . . . . . . . . . . . . . . 13 6. Experiences with NAT64 . . . . . . . . . . . . . . . . . . . . 13 6.1. IPv4 Address Literals . . . . . . . . . . . . . . . . . . 14 6.2. Comparison of Web Access via NAT64 to Other Methods . . . 15 7. Future Work . . . . . . . . . . . . . . . . . . . . . . . . . 15 8. Conclusions and Recommendations . . . . . . . . . . . . . . . 16 9. Security Considerations . . . . . . . . . . . . . . . . . . . 18 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 18 11.1. Normative References . . . . . . . . . . . . . . . . . . . 18 11.2. Informative References . . . . . . . . . . . . . . . . . . 19 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Arkko & Keranen Expires August 10, 2012 [Page 2] Internet-Draft IPv6-Only Experiences February 2012 1. Introduction This document discusses our experiences from moving a small number of users to an IPv6-only network, with access to the IPv4-only parts of the Internet via a NAT64 device. This arrangement has been done with a permanent change in mind rather than as a temporary experiment, involves both office and home users, heterogeneous computing equipment, and varied applications. We have learned both practical details, road blocks and opportunities, as well as more general understanding of when such a configuration can be recommended and what should be taken into account in the network design. The networks involved in this setup have been in dual-stack mode for considerable amount of time, in one case for over ten years. Our IPv6 connectivity is stable and in constant use with no significant problems. Given that the IETF is working on technology such as NAT64 [RFC6144] and several network providers are discussing the possibility of employing IPv6-only networking, we decided to take our network beyond the "comfort zone" and make sure that we understand the implications of having no IPv4 connectivity at all. This also allowed us to test a NAT64 device that is being developed by Ericsson. The main conclusion is that it is possible to employ IPv6-only networking, though there are a number of issues such as lack of IPv6 support in some applications and bugs in untested parts of code. As a result, dual-stack [RFC4213] remains as our recommended model for general purpose networking at this time, but IPv6-only networking can be employed by early adopters or highly controlled networks. The document also suggests actions to make IPv6-only networking applicable in all environments. In particular, resolving problems with a few key applications would have a significant impact for enabling IPv6-only networking for large classes of users and networks. It is important that the Internet community understands these deployment barriers and works to remove them. The rest of this document is organized as follows. Section 2 introduces some relevant technology and terms, Section 3 describes the network setup, Section 4 discusses our general experiences, Section 5 discusses experiences related to having only IPv6 networking available, and Section 6 discusses experiences related to NAT64 use. Finally, Section 7 presents some of our ideas for future work, Section 8 draws conclusions and makes recommendations on when and how one should employ IPv6-only networks, and Section 9 discusses relevant security considerations. Arkko & Keranen Expires August 10, 2012 [Page 3] Internet-Draft IPv6-Only Experiences February 2012 2. Technology and Terminology In this document, the following terms are used. "NAT44" refers to any IPv4-to-IPv4 network address translation algorithm, both "Basic NAT" and "Network Address/Port Translator (NAPT)", as defined by [RFC2663]. "Dual-Stack" refers to a technique for providing complete support for both Internet protocols -- IPv4 and IPv6 -- in hosts and routers [RFC4213]. "NAT64" refers to a Network Address Translator - Protocol Translator defined in [RFC6144], [RFC6145], [RFC6146], [RFC6052], [RFC6147], and [RFC6384]. 3. Network Setup We have tested IPv6-only networking in two different network environments: office and home. In both environments all hosts had normal dual-stack native IPv4 and IPv6 Internet access already in place. The networks were also already employing IPv6 in their servers and DNS records. Similarly, the network was a part of whitelisting arrangement to ensure that IPv6-capable content providers would be able to serve their content to the network over IPv6. The office environment has heterogeneous hardware with PCs, laptops, and routers running Linux, BSD, Mac OS X, and Microsoft Windows operating systems. Common uses of the network include e-mail, Secure Shell (SSH), web browsing, and various instant messaging and Voice over IP (VoIP) applications. The hardware in the home environment consists of PCs, laptops and a number of server, camera, and sensor appliances. The primary operating systems in this environment are Linux and Microsoft Windows operating systems. Common applications include web browsing, streaming, instant messaging and VoIP applications, gaming, file storage, and various home control applications. Both environments employ extensive firewalling practices, and filtering is applied for both IPv4 and IPv6 traffic. However, firewall capabilities, especially with older versions of firewall software, dictate some differences between the filtering applied for IPv4 and IPv6 since some features commonly supported for IPv4 were not yet implemented for IPv6. In addition, in the home environment the individual devices are directly accessible from the Internet on IPv6 (on select protocols such as SSH) but not on IPv4 due to lack of available public IPv4 addresses. In both environments, volunteers had the possibility to opt-in for Arkko & Keranen Expires August 10, 2012 [Page 4] Internet-Draft IPv6-Only Experiences February 2012 the IPv6-only network. The number of users is small: there are roughly five permanent users and a dozen users who have been in the network at least for some amount of time. Each user had to connect to the IPv6-only wired or wireless network, and depending on their software, possibly configure their computer by indicating that there is no IPv4 and/or setting DNS server addresses. The users were also asked to report their experiences back to the organizers. 3.1. The IPv6-Only Network The IPv6-only network was provided as a parallel network on the side of the already existing dual-stack network. It was important to retain the dual-stack network for the benefit of those users who did not decide to opt-in and also because we knew that there were some IPv4-only devices in the network. A separate wired access network was created using Virtual Local Area Networks (VLANs). This network had its own IPv6 prefix. A separate wireless network, bridged to the wired network, was also created. In our case, the new wireless network required additional access point hardware in order to accommodate advertising multiple wireless networks. The simple access point model that we employed in these networks did not allow this on a single device, although many other access points support this. All the secondary infrastructure resulted in some additional management burden and cost, however. An added complexity was that the home network already employed two types of infrastructure, one for family members and another one for visitors. In order to duplicate this model for the IPv6-only network there are now four separate networks, with several access points on each. A stateful NAT64 [RFC6146] with integrated DNS64 was installed on the edge of the IPv6-only networks. No IPv4 routing or Dynamic Host Configuration Protocol (DHCP) was offered on these networks. The NAT64 device sends Router Advertisements (RAs) [RFC4861] from which the hosts learn the IPv6 prefix and can automatically configure IPv6 addresses for them. Each new IPv6-only network needed one new /64 prefix to be used in these advertisements. In addition, each NAT64 device needed another /64 prefix to be used for the representation of IPv4 destinations in the IPv6-only network. As a result, one IPv6- only network requires /63 of address space. This space was easily available in our networks, as IPv6 allocations are on purpose made in sufficiently large blocks. Additional address space needs can be accommodated from the existing block without registry involvement. Another option would have been to use the Well-Known Prefix [RFC6052] for the representation of IPv4 destinations in the IPv6-only network. In any case, the prefixes have to be listed in the intra-domain routing system so that they can be reached. In one case the increase from one block to multiple also made it necessary to employ an improved routing configuration. In addition to routing, the new Arkko & Keranen Expires August 10, 2012 [Page 5] Internet-Draft IPv6-Only Experiences February 2012 prefixes have to be listed in the appropriate firewall rules. Setting up NAT64 and DNS64 by itself is easy and can be done quickly by experienced network manager. However, when duplicate infrastructure is needed for dual-stack and IPv6-only networks, the additional switches, cables, access points, etc., will take some amount of installation effort. In addition, if whitelisting agreements or IPv6 ISP connectivity is needed, setting these up requires negotiations with external partners. 3.2. DNS Operation Router Advertisements are used to carry DNS Configuration options [RFC6106], listing the DNS64 as the DNS server the hosts should use. In addition, aliases were added to the DNS64 device to allow it to receive packets on the well-known DNS server addresses that Windows operating systems use (fec0:0:0:ffff::1, fec0:0:0:ffff::2, and fec0: 0:0:ffff::3). At a later stage support for stateless DHCPv6 [RFC3736] was added. We do recommend enabling RFC 6106, well-known addresses, and stateless DHCPv6 in order to maximize the likelihood of different types of IPv6-only hosts being able to use DNS without manual configuration. DNS server discovery was never a problem in dual-stack networks, because DNS servers on the IPv4 side can easily provide IPv6 information (AAAA records) as well. With IPv6-only networking, it becomes crucial that the local DNS server can be reached via IPv6 as well. This is in principle exactly same as needing IPv4-based DNS and DNS discovery in IPv4-only networks. However, in IPv6 the discovery mechanisms are somewhat more complicated because there are several alternative techniques. When a host served by the DNS64 asks for a domain name that does not have an AAAA (IPv6 address) record, but has an A (IPv4 address) record, an AAAA record is synthesized from the A record (as defined for DNS64 in [RFC6147]) and sent in the DNS response to the host. IP packets sent to this synthesized address are routed via the NAT64, translated to IPv4 by the NAT64, and forwarded to the queried host's IPv4 address; return traffic is translated back from IPv4 to IPv6 and forwarded to the host behind the NAT64 (as described in [RFC6144]). This allows the hosts in the IPv6-only network to contact any host in the IPv4 Internet as long as the hosts in the IPv4 Internet have DNS address records. The NAT64 devices have standard dual-stack connectivity and their DNS64 function can use both IPv4 and IPv6 when requesting information from DNS. A destination that has both an A and AAAA records is not treated in any special manner, because the hosts in the IPv6-only network can contact the destination over IPv6. Destinations with only an A record will be given a synthesized AAAA record as explained Arkko & Keranen Expires August 10, 2012 [Page 6] Internet-Draft IPv6-Only Experiences February 2012 above. However, in one of our open visitor networks that is sharing the infrastructure with the home network we needed a special arrangement. Currently, the home network obtains its IPv6 connectivity through a tunnel via the office network, and it is undesirable to allow outsiders using the visitor network to generate traffic through the office network, even if the traffic is just passing by and forwarded to the IPv6 Internet. As a result, in the visitor network there is a special IPv6-only to IPv4-only configuration where the DNS64 never asks for AAAA records and always generates synthesized records. Therefore no traffic from the visitor network, even if it is destined to the IPv6 Internet, is routed via the office network but traffic from the home network can still use the IPv6 connectivity provided by the office network. Note: This configuration may also be useful for other purposes. For instance, one drawback of standard behavior is that if a destination publishes AAAA records but has bad IPv6 connectivity, the hosts in the IPv6-only network have no fallback. In the dual- stack model a host can always try IPv4 if the IPv6 connection fails. In the special configuration IPv6 is only used internally at the site but never across the Internet, eliminating this problem. This is not a recommended mode of operation, but it is interesting to note that it may solve some issues. Note that in NAT64 (unlike in its older variant [RFC4966]) it is possible to decouple the packet translation, IPv6 routing, and DNS64 functions. Since clients are configured to use a DNS64 as their DNS server, there is no need for having an Application Layer Gateway (ALG) on the path sniffing and spoofing DNS packets. This decoupling possibility was used by one of our users, as he is outside of our physical network and wants to communicate directly on IPv6 where it is possible without having to go through our central network equipment. His DNS queries go to our DNS64 and to establish communications to an IPv4 destination our central NAT64 is used. If there is a need to translate some packets, these packets find the translator device through normal IPv6 routing means since the synthesized addresses have our NAT64's prefix. However, for non- synthesized IPv6 addresses the packets are routed directly to the destination. 4. General Experiences Based on our experiences, it is possible to live (and work) with an IPv6-only network. For instance, at the time of this writing, one of the authors has been in an IPv6-only network for about a year and a half and has had no major problems. Most things work well in the new environment; for example, we have been unable to spot any practical Arkko & Keranen Expires August 10, 2012 [Page 7] Internet-Draft IPv6-Only Experiences February 2012 difference in the web browsing (HTTP and HTTPS) experience. Also e-mail, software upgrades, operating system services, many chat systems and media streaming work well. On certain Symbian mobile handsets that we tried all applications work even on an IPv6-only network. In another case with Android operating system, all the basic applications worked without problems. In order to make the latter handset architecture support IPv6-only networks, however, a small change was needed in the operating system so that it could discover IPv6-only DNS servers. However, in general there is some pain involved and thus IPv6-only networking is not suitable for everyone just yet. Switching IPv4 off does break many things as well. Some of the users in our environment left due to these issues, as they missed some key feature that they needed from their computing environment. These issues fall in several categories: Bugs We saw many issues that can be classified as bugs, likely related to so few people having tried the software in question in an IPv6- only network. For instance, some operating system facilities support IPv6 but have annoying problems that are only uncovered in IPv6-only networking. Lack of IPv6 Support We also saw many applications that do not support IPv6 at all. These range from minor, old tools (such as the Unix dict(1) command) to major applications that are important to our users (such as Skype) and even to entire classes of applications (many games have issues). As our experiment continued, we have seen improvements in some areas, such as gaming. Protocol, Format, and Content Problems There are many protocols that carry IP addresses in them, and using these protocols through a translator can lead to problems. In our current network setup we did not employ any ALGs except for FTP [RFC6384]. However, we have observed a number of protocol issues with IPv4 addresses. For instance, some instant messaging services do not work due to this. Finally, content on some web pages may refer to IPv4 address literals (i.e., plain IP addresses instead of host and domain names). This renders some links inaccessible in an IPv6-only network. While this problem is easily quantifiable in measurements, the authors have run into it only a couple of times during real-life web browsing. Arkko & Keranen Expires August 10, 2012 [Page 8] Internet-Draft IPv6-Only Experiences February 2012 Firewall Issues We also saw a number of issues related to lack of features in IPv6 support in firewalls. In particular, while we did not experience any Maximum Transmission Unit (MTU) and fragmentation problems in our networks, there is potential for generating problems, as the support for IPv6 fragment headers is not complete in all firewalls and the NAT64 specifications call for use of the fragment header (even in situations where fragmentation has not yet occurred, e.g., if an IPv4 packet that is not a fragment does not have the Don't Fragment (DF) bit set). In general, most of the issues relate to poor testing and lack of IPv6 support in some applications. IPv6 itself and NAT64 did not cause any major issues for us, once our setup and NAT64 software was stable. In general, the authors feel that with the exception of some applications, our experience with translation to reach the IPv4 Internet has been equal to our past experiences with NAT44-based Internet access. While translation implies loss of end-to-end connectivity, in practice direct connectivity has not been available to the authors in the IPv4 Internet either for a number of years. It should be noted that the experience with a properly configured set of ALGs and work-arounds such as proxies may be different. Some of the problems we encountered can be solved through these means. For instance, a problematic application can be configured to use a proxy that in turn has both IPv4 and IPv6 access. 5. Experiences with IPv6-Only Networking The overall experience was as explained above. The remainder of this section discusses specific issues with different operating systems, programming languages, applications, and appliances. 5.1. Operating Systems Even operating systems have some minor problems with IPv6. For example, in Linux Router Advertisement (RA) information was not automatically updated when the network changes while the computer is on and required an unnecessary suspend/resume cycle to restore its proper state. We have also had issues with the rdnssd daemon, which first does not come as a default feature in Ubuntu and does not always appear to work reliably. To resolve these issues we had to configure the network manager to use a specific server address. Later, a new version of the Linux distribution that we used solved these problems, even if some problems still remained. For instance, in the latest Ubuntu Long Term Support release (10.04) we have Arkko & Keranen Expires August 10, 2012 [Page 9] Internet-Draft IPv6-Only Experiences February 2012 experienced that the network manager by default returns to an available IPv4 wireless network even if there is a previously used IPv6-only network available and the IPv4 network has no global connectivity before a web-based login is completed. In Mac OS X (Snow Leopard) the network manager needed to be explicitly told to not expect IPv4. A more annoying issue was that in order to switch between an IPv6-only and IPv4-only networks, these settings had to be manually changed, making it undesirable for Mac OS X users to employ IPv6-only networks. Also on Microsoft Windows 7 we experienced problems when relying on default, well-known DNS server addresses: without manual configuration, the host was unable to use the DNS addresses, even though the system displays them as current DNS server addresses. Latest versions of the Android operating system support IPv6 on its wireless LAN interface, but due to lack of DNS discovery mechanisms, this does not work in IPv6-only networks. We corrected this, however, and prototype phones in our networks work now well even in an IPv6-only environment. This change, DNS Discovery Daemon (DDD) now exists as open source software. Interestingly, all applications that we have tried so far seem to work without problems with IPv6- only connectivity, though no exhaustive testing was done, nor did we try known troublesome applications. While all these operating systems (or their predecessors) have supported IPv6 already for a number of years, these kind of small glitches seem to imply that they have not been thoroughly tested in networks lacking IPv4 connectivity. At the very least their usability leaves something to be desired. 5.2. Programming Languages and APIs For applications to be able to support IPv6, they need access to the necessary APIs. Luckily, IPv6 seems to be well supported by majority of the commonly used APIs. The Perl programming language used to be an exception with only partial IPv6 support up to the version 5.14 (released May 14th 2011). This version finally includes full IPv6 support also in the core libraries and older modules are being updated as well. With previous versions of Perl, while IPv6 socket support is available as an extension module, it may not be possible to install this module without administrative rights. This has also resulted in other networking core libraries (such as FTP and SMTP) not being able to fully support IPv6 and thus many existing Perl programs using network functionality may not work properly in an IPv6-only environment. Arkko & Keranen Expires August 10, 2012 [Page 10] Internet-Draft IPv6-Only Experiences February 2012 5.3. Instant Messaging and VoIP By far the biggest complaint from our group of users was that Skype stopped working. In some environments even Skype can be made to work through a proxy configuration, and this was verified in our setting but not used as a permanent solution. More generally, we tested a number of instance messaging applications in an IPv6-only network with NAT64 and the test results can be found from Table 1. The versions used in the tests were the latest versions available on summer 2010. SYSTEM STATUS Facebook on the web (http) OK Facebook via a client (xmpp) OK Jabber.org chat service (xmpp) OK Gmail chat on the web (http) OK Gmail chat via a client (xmpp) OK Google Talk client NOT OK AIM (AOL) NOT OK ICQ (AOL) NOT OK Skype NOT OK MSN NOT OK Webex NOT OK Sametime OK (NOW) Table 1. Instant Messaging Applications in an IPv6-Only Network Packet tracing revealed that the issues in AIM, ICQ, and MSN appear to be related to passing literal IPv4 addresses in the protocol. It remains to be determined whether this can be solved through configuration, proxies, or ALGs. The problem with the Google Talk client is that the software does not support IPv6 connections at this moment. We are continuing our tests with additional applications, and we have also seen changes over time. For instance, a new version of Sametime suddenly started working with IPv6-only networks, presumably due to the new version being more careful with the use of DNS names as opposed to IPv4 addresses. One problem in running these tests is to ensure that we can distinguish IPv6 and NAT64 issues from other issues, such as a generic issue on a given operating system platform. Some of these problems are solvable, however. For instance, we used localhost as a proxy for Skype, and then used SSH to tunnel to an external web proxy, bypassing Skype's limitations with regards to connecting to IPv6 destinations or even IPv6 proxies. Arkko & Keranen Expires August 10, 2012 [Page 11] Internet-Draft IPv6-Only Experiences February 2012 5.4. Gaming Another class of applications that we tried was games. We tried both web-based gaming and standalone gaming applications that have a "network" / "Internet" or "LAN" gaming modes. The results are shown in Table 2. SYSTEM STATUS Web-based (e.g. armorgames) OK Runescape (on the web) NOT OK Flat out 2 NOT OK Battlefield NOT OK Secondlife NOT OK Guild Wars NOT OK Age of Empires NOT OK Star Wars: Empire at War NOT OK Crysis NOT OK Lord of the Rings: Conquest NOT OK Rome Total War NOT OK Lord of the Rings: Battle for Middle Earth 2 NOT OK Table 2. Gaming Applications in an IPv6-Only Network Most web-based games worked well, as expected from our earlier good general web experience. However, we were also able to find one web- based game that failed to work (Runescape). This particular game is a Java application that fails on an attempt to perform a HTTP GET request. The reason remains unclear, but a likely theory is the use of an IPv4-literal in the application itself. The experience with standalone games was far more discouraging. Without exception all games failed to enable either connections to ongoing games in the Internet or even LAN-based connections to other computers in the same IPv6-only LAN segment. This is somewhat surprising, and the results require further verification. Unfortunately, the games provide no diagnostics about their operation, so it is hard to guess what is going on. It is possible that their networking code employs older APIs that cannot use IPv6 addresses [RFC4038]. The inability to provide any LAN-based connectivity is even more surprising, as this must mean that they are unable to use IPv4 link local connectivity, which should have been available to the devices (IPv4 was not blocked; just that no DHCP answers were provided on IPv4). While none of the standalone games we tested on summer 2010 were IPv6-capable, the situation has improved during the experiment. For instance, a popular on-line game, World of Warcraft, now has IPv6 Arkko & Keranen Expires August 10, 2012 [Page 12] Internet-Draft IPv6-Only Experiences February 2012 support in its latest version and some of the older games that have been re-released as open source (e.g., Quake) have been patched IPv6- capable by the open source community. 5.5. Music Services Most of the web-based music services appear to work fine, presumably because they employ TCP and HTTP as a transport. One notable exception is Spotify, which requires communication to specific IPv4 addresses. A proxy configuration similar to the one we used for Skype makes it possible to use Spotify as well. 5.6. Appliances There are also problems with different appliances such as webcams. Many of them do not support IPv6 and hence will not work in an IPv6- only network. Also not all firewalls support IPv6. Or even if they do, they may still experience issues with some aspects of IPv6 such as fragments. Some of these issues are easily solved when the appliance works as a server, such as what most webcams and our sensor gateway devices do. We placed the appliance in the IPv4 part of the network (in this case, in private address space), added its name to the local DNS, and simply allowed devices from the IPv6-only network reach it through NAT64. 5.7. Other Differences One thing that becomes simplified in an IPv6-only network is source address selection [RFC3484]. As there is no IPv4 connectivity, the host only needs to consider its IPv6 source address. For global communications there is typically just one possible source address. Some networks that advertise IPv6 addresses in their DNS records have in reality some problems. For instance, a popular short URL forwarding service has advertised a deprecated IPv4-compatible IPv6 address [RFC4291] in its AAAA record, making it impossible for this site to be reached unless either IPv4 or NAT64 translation to an IPv4 destination is used. 6. Experiences with NAT64 After correcting some initial bugs and stability issues, the NAT64 operation itself has been relatively problem free. There have been no unexplained DNS problems or lost sessions. With the exception of the specific applications mentioned above and IPv4 literals, the user Arkko & Keranen Expires August 10, 2012 [Page 13] Internet-Draft IPv6-Only Experiences February 2012 experience has been in line with using IPv4 Internet through a NAT44 device. These failures with the specific applications are clearly very different from the IPv4 experience, however. The rest of this section discusses our measurements on specific issues. These tests and measurements were performed during year 2011 and present a snapshot of the situation on that time. More up-to- date measurement information can be found from various on-line tools such as [HE-IPv6]. 6.1. IPv4 Address Literals While browsing in general works, IPv4 literals embedded in the HTML code may break some parts of the web pages when using IPv6-only access. This happens because the DNS64 can not synthesize AAAA records for the literals since the addresses are not queried from the DNS. Luckily, the IPv4 literals seem to be fairly rarely encountered, at least so that they would be noticed, with regular web surfing. The authors have run into this issue only few times during the entire experiment. Only two of those cases had a practical impact (in YouTube, some of the third-party applications for downloading content did not work and one hotel's web page had a literal link to its reservation system). We have attempted to measure the likelihood of running into an IPv4 literal in the web. To do this, we took the top 1,000 and 10,000 web sites from the Alexa popular web site list. With 1,000 top sites, 0.2% needed an IPv4 literal to render all components in their top page (e.g., images, videos, JavaScript, and Cascading Style Sheet (CSS) files). With 10,000 top sites, this number increases to 2%. However, it is not clear what conclusions can be made about this. It is often the case that there are unresolvable or inaccessible components on a web page anyway for various reasons, and to understand the true impact we would have to know how "important" a given page component was. Also, we did not measure the number of links with IPv4 literals on these pages, nor did we attempt to search the site in any thorough manner for these literals. As noted, personal anecdotal evidence says that IPv4 literals are not a big problem. But clearly, cleaning the most important parts of the web from IPv4 literals would be useful. With tools such as the popular web site list, some user pressure, and co-operation from the content providers the most urgent part of the problem could hopefully be solved as a one-time effort. While IPv4 literals still exist in the web, using a suitable HTTP proxy (e.g., [I-D.wing-behave-http-ip-address-literals]) can help to cope with them. Arkko & Keranen Expires August 10, 2012 [Page 14] Internet-Draft IPv6-Only Experiences February 2012 6.2. Comparison of Web Access via NAT64 to Other Methods We also compared how well the web works behind a NAT64 compared to IPv4-only and native IPv6 access. For this purpose, we used wget to go through the same top web site lists as described in Section 6.1, again downloading everything needed to render their front page. The tests were repeated and average failure rate was calculated over all of the runs. Separate tests were conducted with an IPv4-only network, an IPv6-only network, and an IPv6-only network with NAT64. When accessed with the IPv4-only network, our tests show that 1.9% of the sites experienced some sort of error or failure. The failure could be that the whole site was not accessible, or just that a single image (e.g., an advertisement banner) was not loaded properly. It should also be noted that access through wget is somewhat different from a regular browser: some web sites refuse to serve content to wget, browsers typically have DNS heuristics to fill in "www." in front of a domain name where needed, and so on. In addition to missing advertisement banners, temporary routing glitches and other mistakes, these differences also help to explain the reason for the high baseline error rate in this test. It should also be noted that variations in wget configuration options produced highly different results, but we believe that the options we settled on bear closest resemblance to real world browsing. When we tried to access the same sites with native IPv6 (without NAT64), 96% of the sites failed to load correctly. This was as expected, given that most of the Internet content is not available on IPv6. The few exceptions included, for instance, sites managed by Google. When the sites were accessed from the IPv6-only network via a NAT64 device, the failure rate increased to 2.1%. Most of these failures appear to be due to IPv4 address literals, and the increased failure rate matches that of IPv4 literal occurrence in the same set of top web sites. With the top 10,000 sites the failure rate with NAT64 increases similarly to our test on IPv4 address literals. 7. Future Work One important set of measurements remains for future work. It would be useful to understand the effect of DNS64 and NAT64 to response time and end-to-end communication delays. Some users have anecdotal reports of slow web browsing response times, but we have been unable to determine if this was due to the IPv6-only network mechanisms or for some other reason. Measurements on pure DNS response times and packet round-trip delays does not show a significant difference to a Arkko & Keranen Expires August 10, 2012 [Page 15] Internet-Draft IPv6-Only Experiences February 2012 NAT44 environment. It would be particularly interesting to measure delays in the context of dual-stack vs. NAT64-based IPv6-only networking. When using dual-stack, broken IPv6 connectivity can be repaired by falling back to IPv4 use. With NAT64, this is not always possible as discussed in Section 3.2. Also more programs, especially VoIP and Peer-to-Peer (P2P) applications should be tested with NAT64. In addition, tunneling and mobility protocols should be tested and especially Virtual Private Network (VPN) protocols and applications would deserve more thorough investigation. 8. Conclusions and Recommendations The main conclusion is that it is possible to employ IPv6-only networking. For large classes of applications there are no downsides or the downsides are negligible. We have been unable to spot any practical difference in the web browsing experience, for instance. And IPv6 usage -- be it in dual-stack or IPv6-only form -- comes with inherent advantages, such as enabling direct end-to-end connectivity. In our case, we employed this by enabling direct connectivity to devices in a home network from anywhere in the (IPv6) Internet. There are, however, a number of issues as well, such as lack of IPv6 support in some applications or bugs in untested parts of the code. Our experience with IPv6-only networking confirms that dual stack should still be our recommended model for general purpose networking at this point of time. However, IPv6-only networking can be employed by early adopters or highly controlled networks. One example of such controlled network is a mobile network with operator-driven selection of handsets. For instance, on some handsets that we tested, we were unable to see any functional difference between IPv4 and IPv6, today. Our recommendations apply at the present time. With effort and time, deployment barriers can be removed and IPv6-only networking becomes applicable in all networking situations. Some of the improvements are already in process in the form of new products and additional IPv6 support. For instance, we expect that the handset market will have a much higher number of IPv6-capable devices in the near future. But some of the changes do not come without the community spending additional effort. We have identified a number of actions that should be taken to improve the state of IPv6-only networking. These include: Arkko & Keranen Expires August 10, 2012 [Page 16] Internet-Draft IPv6-Only Experiences February 2012 DNS Discovery The state of DNS discovery continues to be one of the main barriers for easy adoption of IPv6-only networking. Since DNS discovery is not a problem in dual-stack networking, there has been too little effort in testing and deploying the necessary components. For instance, it would be useful if RA-based DNS discovery came as a standard feature and not as an option in Linux distributions. Our hope is that recent standardization of the RA- based DNS discovery at the IETF will help this happen. Similar issues face other operating systems. The authors believe that at this time, prudent operational practices call for maximizing the number of offered automatic configuration mechanisms on the network side. It might be useful for an IETF document to provide guidance on operating DNS in IPv6-only networks. Network Managers Other key software components are the various network management and attachment tools in operating systems. These tools generally have the required functionality, but do not always appear to have been tested very extensively on IPv6, or let alone IPv6-only networks. Further work is required here. Firewalls More work is needed to ensure that IPv6 is supported in equal manner in various firewall products. Application Support But by far the most important action, for at least our group of users, would be to bring some key applications (e.g., instant messaging and VoIP applications and also games) to a state where they can be easily run on IPv6-only networks and behind a NAT64. To facilitate this, application programmers should use IP version agnostic APIs so that applications automatically use IPv4 or IPv6 depending on what is available. In some cases, it may also be necessary to add support for new types of ALGs. IPv4 Literals The web should be cleaned of IPv4 literals. Also IPv4 literals should be avoided in application protocol signaling messages. Arkko & Keranen Expires August 10, 2012 [Page 17] Internet-Draft IPv6-Only Experiences February 2012 Measurements and Analysis It is also important to continue with testing, measurements, and analysis of what Internet technology works in IPv6-only networks, to what extent, at what speed, and where the remaining problems are. Guidelines It is also useful to provide guidance for network administrators and users on how to turn on IPv6-only networking. As can be seen from the above list, there are only minor things that can be done through standardization. Most of the effort is practical and centers around improving various implementations. 9. Security Considerations The use of IPv6 instead of IPv4 by itself does not make a big security difference. The main security requirement is that, naturally, network security devices need to be able to deal with IPv6 in these networks. This is though already required in all dual-stack networks. As noted, it is important, e.g., to ensure firewall capabilities. Security considerations for NAT64 and DNS64 are discussed in [RFC6146] and [RFC6147]. In our experience many of the critical security functions in a network end up being on the dual-stack part of the network anyway. For instance, our mail servers obviously still have to be able to communicate with both the IPv4 and IPv6 Internet, and as a result they and the associated spam & filtering components are not in the IPv6-only part of the network. 10. IANA Considerations This document has no IANA implications. 11. References 11.1. Normative References [RFC2663] Srisuresh, P. and M. Holdrege, "IP Network Address Translator (NAT) Terminology and Considerations", RFC 2663, August 1999. Arkko & Keranen Expires August 10, 2012 [Page 18] Internet-Draft IPv6-Only Experiences February 2012 [RFC3484] Draves, R., "Default Address Selection for Internet Protocol version 6 (IPv6)", RFC 3484, February 2003. [RFC3736] Droms, R., "Stateless Dynamic Host Configuration Protocol (DHCP) Service for IPv6", RFC 3736, April 2004. [RFC4213] Nordmark, E. and R. Gilligan, "Basic Transition Mechanisms for IPv6 Hosts and Routers", RFC 4213, October 2005. [RFC6106] Jeong, J., Park, S., Beloeil, L., and S. Madanapalli, "IPv6 Router Advertisement Options for DNS Configuration", RFC 6106, November 2010. 11.2. Informative References [RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E. Castro, "Application Aspects of IPv6 Transition", RFC 4038, March 2005. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC4861] Narten, T., Nordmark, E., Simpson, W., and H. Soliman, "Neighbor Discovery for IP version 6 (IPv6)", RFC 4861, September 2007. [RFC4966] Aoun, C. and E. Davies, "Reasons to Move the Network Address Translator - Protocol Translator (NAT-PT) to Historic Status", RFC 4966, July 2007. [RFC6052] Bao, C., Huitema, C., Bagnulo, M., Boucadair, M., and X. Li, "IPv6 Addressing of IPv4/IPv6 Translators", RFC 6052, October 2010. [RFC6144] Baker, F., Li, X., Bao, C., and K. Yin, "Framework for IPv4/IPv6 Translation", RFC 6144, April 2011. [RFC6145] Li, X., Bao, C., and F. Baker, "IP/ICMP Translation Algorithm", RFC 6145, April 2011. [RFC6146] Bagnulo, M., Matthews, P., and I. van Beijnum, "Stateful NAT64: Network Address and Protocol Translation from IPv6 Clients to IPv4 Servers", RFC 6146, April 2011. [RFC6147] Bagnulo, M., Sullivan, A., Matthews, P., and I. van Beijnum, "DNS64: DNS Extensions for Network Address Translation from IPv6 Clients to IPv4 Servers", RFC 6147, April 2011. Arkko & Keranen Expires August 10, 2012 [Page 19] Internet-Draft IPv6-Only Experiences February 2012 [RFC6384] van Beijnum, I., "An FTP Application Layer Gateway (ALG) for IPv6-to-IPv4 Translation", RFC 6384, October 2011. [I-D.wing-behave-http-ip-address-literals] Wing, D., "Coping with IP Address Literals in HTTP URIs with IPv6/IPv4 Translators", draft-wing-behave-http-ip-address-literals-02 (work in progress), March 2010. [HE-IPv6] Hurricane Electric, "Global IPv6 Deployment Progress Report", February 2012, . Appendix A. Acknowledgments The authors would like to thank the many people who have engaged in discussions around this topic, and particularly the people who were involved in building some of the new tools used in our network, our users who were interested in going where only few had dared to venture before, or people who helped us in this effort. In particular, we would like to thank Martti Kuparinen, Tero Kauppinen, Heikki Mahkonen, Jan Melen, Fredrik Garneij, Christian Gotare, Teemu Rinta-Aho, Petri Jokela, Mikko Sarela, Olli Arkko, Lasse Arkko, and Cameron Byrne. Also Marcelo Braun, Iljitsch van Beijnum, Miika Komu, and Jouni Korhonen have provided useful discussion and comments on the document. Authors' Addresses Jari Arkko Ericsson Jorvas 02420 Finland Email: jari.arkko@piuha.net Ari Keranen Ericsson Jorvas 02420 Finland Email: ari.keranen@ericsson.com Arkko & Keranen Expires August 10, 2012 [Page 20] debian/extra/draft-baker-bmwg-testing-eyeball-happiness-05.txt0000644000000000000000000006047711731401603021500 0ustar Benchmarking Methodology F. Baker Internet-Draft Cisco Systems Intended status: Informational August 15, 2011 Expires: February 16, 2012 Testing Eyeball Happiness draft-baker-bmwg-testing-eyeball-happiness-05 Abstract The amount of time it takes to establish a session using common transport APIs in dual stack networks and networks with filtering such as proposed in BCP 38 is a barrier to IPv6 deployment. This note describes a test that can be used to determine whether an application can reliably establish sessions quickly in a complex environment such as dual stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering. This test is not a test of a specific algorithm, but of the external behavior of the system as a black box. Any algorithm that has the intended external behavior will be accepted by it. Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in [RFC2119]. Status of this Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on February 16, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the Baker Expires February 16, 2012 [Page 1] Internet-Draft Testing Eyeball Happiness August 2011 document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Measuring Eyeball Happiness . . . . . . . . . . . . . . . . . 4 2.1. Happy Eyeballs test bed configuration . . . . . . . . . . 4 2.2. Happy Eyeballs test procedure . . . . . . . . . . . . . . 6 2.3. Happy Eyeballs metrics . . . . . . . . . . . . . . . . . . 7 2.3.1. Metric: Session Setup Interval . . . . . . . . . . . . 7 2.3.2. Metric: Maximum Session Setup Interval . . . . . . . . 8 2.3.3. Metric: Minimum Session Setup Interval . . . . . . . . 9 2.3.4. Descriptive Metric: Attempt pattern . . . . . . . . . 9 3. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 10 4. Security Considerations . . . . . . . . . . . . . . . . . . . 10 5. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 10 6. Change Log . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10 7.2. Informative References . . . . . . . . . . . . . . . . . . 11 Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 11 Baker Expires February 16, 2012 [Page 2] Internet-Draft Testing Eyeball Happiness August 2011 1. Introduction The Happy Eyeballs [I-D.ietf-v6ops-happy-eyeballs] specification notes an issue in deployed multi-prefix IPv6-only and dual stack networks, and proposes a correction. [RFC5461] similarly looks at TCP's response to so-called "soft errors" (ICMP host and network unreachable messages), pointing out an issue and a set of possible solutions. In a dual stack network (i.e., one that contains both IPv4 [RFC0791] and IPv6 [RFC2460] prefixes and routes), or in an IPv6-only network that uses multiple prefixes allocated by upstream providers that implement BCP 38 Ingress Filtering [RFC2827], the fact that two hosts that need to communicate have addresses using the same architecture does not imply that the network has usable routes connecting them, or that those addresses are useful to the applications in question. In addition, the process of establishing a session using the Sockets API [RFC3493] is generally described in terms of obtaining a list of possible addresses for a peer (which will normally include both IPv4 and IPv6 addresses) using getaddrinfo() and trying them in sequence until one succeeds or all have failed. This naive algorithm, if implemented as described, has the side-effect of making the worst case delay in establishing a session far longer than human patience normally allows. This has the effect of discouraging users from enabling IPv6 in their equipment, or content providers from offering AAAA records for their services. This note describes a test to determine how quickly an application can reliably open sessions in a complex environment, such as dual stack (IPv4+IPv6) deployment or IPv6 deployment with multiple prefixes and upstream ingress filtering. This is not a test of a specific algorithm, but a measurement of the external behavior of the application and its host system as a black box. The "happy eyeballs" question is this: how long does it take an application to open a session with a server or peer, under best case and worst case conditions? The methods defined here make the assumption that the initial communication set-up of many applications can be summarized by the measuring the DNS query/response and transport layer handshaking, because no application-layer communication takes place without these steps. The methods and metrics defined in this note are ideally suited for Laboratory operation, as this affords the greatest degree of control to modify configurations quickly and produce consistent results. Baker Expires February 16, 2012 [Page 3] Internet-Draft Testing Eyeball Happiness August 2011 However, if the device under test is operated as a single user with limited query and stream generation, then there's no concern about overloading production network devices with a single "set of eyeballs". Therefore, these procedures and metrics MAY be applicable to production network application, as long as the injected traffic represents a single user's typical traffic load, and the testers adhere to the precautions of the relevant network with respect to re- configuration of devices in production. 2. Measuring Eyeball Happiness This measurement determines the amount of time it takes an application to establish a session with a peer in the presence of at least one IPv4 and multiple IPv6 prefixes and a variety of network behaviors. ISPs are reporting that a host (MacOSX, Windows, Linux, FreeBSD, etc) that has more than one address (an IPv4 and an IPv6 address, two global IPv6 addresses, etc) may serially try addresses, allowing each TCP setup to expire, taking several seconds for each attempt. There have been reports of lengthy session setup times - in various application and OS combinations anywhere from multi-second to half an hour - as a result. The amount of time necessary to establish communication between two entities should be approximately the same regardless of the type of address chosen or the viability of routing in the specific network; users will expect this time to be consistent with their current experience (else, happiness is at risk). 2.1. Happy Eyeballs test bed configuration The configuration of equipment and applications is as shown in Figure 1. +--------+ | |198.51.100.0/24 |Protocol| |192.0.2.0/24 |2001:DB8:0:2::/64 |Analyzer+-+2001:DB8:1:0::/64 |2001:DB8:1:4::/64 +--------+ |2001:DB8:0:1::/64 |2001:DB8:2:4::/64 | | +-----+ | | +-----+ |Alice+-+ +-+ Bob | +-----+ | +-------+ +-------+ | +-----+ +-+Router1| |Router2+-+ +-----+ | +-----+-+ +-+-----+ | | DNS +-+ | | | +-----+ | -+------+- | | 203.0.113.0/24 | | 2001:DB8:0:3::/64 | Baker Expires February 16, 2012 [Page 4] Internet-Draft Testing Eyeball Happiness August 2011 Figure 1: Generic Test Environment Alice is the unit being measured, the computer running the process that will establish a session with Bob for the application in question. DNS is represented in the diagram as a separate system, as is the protocol analyzer that will watch Alice's traffic. This is not absolutely necessary; If one computer can run tcpdump and a DNS server process - and for that matter subsume the routers - that is acceptable. The units are separated in the test for purposes of clarity. On each test run, configuration is performed in Router 1 to permit only one route to work. There are various ways this can be accomplished, including but not limited to installing o a filter that drops datagrams to Bob resulting in an ICMP "administratively prohibited", o a filter that silently drops datagrams to Bob, o a null route or removing the route to one of Bob's prefixes, resulting in an ICMP "destination unreachable", and o a middleware program that responds with a TCP RST. o Path MTU issues The Path MTU Discovery [RFC1191][RFC1981] matter requires some explanation. With IPv6, and with IPv4 when "Do Not Fragment" is set, a router with a message too large for an interface discards it and replies with an ICMPv4 "Destination Unreachable: Datagram Too Big" or ICMPv6 "Packet Too Big". If this packet is lost, the source doesn't know what size to fragment to and has no indication that fragmentation is required. A configuration for this scenario would set the MTU on 203.0.113.0/24 or 2001:DB8:0:3::/64 to the smallest allowed by the address family (576 or 1280) and disable generation of the indicated ICMP message. Note that [RFC4821] is intended to address these issues. The tester should try different methods to determine whether differences in this configuration make a difference in the test. For example, one might find that the application under test responds differently to a TCP RST than to a silent packet loss. Each of these scenarios should be tested; if doing so is too difficult, the most important is the silent packet loss case, as it is the worst case. Baker Expires February 16, 2012 [Page 5] Internet-Draft Testing Eyeball Happiness August 2011 2.2. Happy Eyeballs test procedure Consider a network as described in Section 2.1. Alice and Bob each have a set of one or more IPv4 and two or more IPv6 addresses. Bob's are in DNS, where Alice can find them; Alice's and others may be there as well, but are not relevant to the test. Routers 1 and 2 are configured to route the relevant prefixes. Different measurement trials revise an access list or null route in Router 1 that would prevent traffic Alice->Bob using each of Bob's addresses. If Bob has a total of N addresses, we run the measurement at least N times, permitting exactly one of the addresses to enjoy end to end communication each time. If the DNS service randomizes the order of the addresses, this may not result in a test requiring establishment of a connection to all of the addresses; in this case, the test will have to be run repeatedly until in at least one instance a TCP SYN or its equivalent is seen for each relevant address. The tester should either flush the resolver cache between iterations, to force repeated DNS resolution, or should wait for at least the DNS RR TTL on each resource record. In the latter case, the tester should also observe DNS re-resolving; if not, the application is not correctly using DNS. This specification assumes common LAN technology with no competing traffic and nominal propagation delays, so that they are not a factor in the measurement. The objective is to measure the amount of time required to establish a session. This includes the time from Alice's initial DNS request through one or more attempts to establish a session to the session being established, as seen in the LAN trace. The simplest way to measure this will be to put a traffic analyzer on Alice's point of attachment and capture the messages exchanged by Alice. DNS Server Alice Bob | | | 1. |<--www.example.com A------| | 2. |<--www.example.com AAAA---| | 3. |---198.51.100.1---------->| | 4. |---2001:DB8:0:2::1------->| | 5. | | | 6. | |--TCP SYN, IPv6--->X |<*********** 7. | |--TCP SYN, IPv6--->X | | 8. | |--TCP SYN, IPv6--->X | TCP 3wHS 9. | | | Time 10. | |--TCP SYN, IPv4------->|(any family) 11. | |<-TCP SYN+ACK, IPv4----| | 12. | |--TCP ACK, IPv4------->|<*********** Figure 2: Message flow using TCP Baker Expires February 16, 2012 [Page 6] Internet-Draft Testing Eyeball Happiness August 2011 In a TCP-based application (Figure 2), that would be from the DNS request on line 1 through the first completion of a TCP three-way handshake, the transmission on line 12. DNS Server Alice Bob | | | 1. |<--www.example.com A------| | 2. |<--www.example.com AAAA---| | 3. |---198.51.100.1---------->| | 4. |---2001:DB8:0:2::1------->| | 5. | | | 6. | |--UDP Request, IPv6-->X|<--------- 7. | |--UDP Request, IPv6-->X| first 8. | |--UDP Request, IPv6-->X| request/ 9. | | | response 10. | |--UDP Request, IPv4--->| success 11. | |<-UDP Response, IPv4---|<--------- Figure 3: Message flow using UDP In a UDP-based application (Figure 3), that would be from the DNS request (line 1) through one or more UDP Requests (lines 6-10) until a UDP Response is seen (line 11). When using other transports, the methodology will have to be specified in context; it should measure the same event. 2.3. Happy Eyeballs metrics The measurements taken are the duration of the interval from the initial DNS request until the session is seen to have been established, as described in Section 2.2. We are interested in the shortest and longest durations (which will most likely be those that send one SYN and succeed and those that send a SYN to each possible address before succeeding in one of the attempts), and the pattern of attempts sent to different addresses. The pattern may be to simply send an attempt every