draft-ietf-dnsop-nxdomain-cut-01.txt		draft-ietf-dnsop-nxdomain-cut-02.txt
	Domain Name System Operations (dnsop) Working Group S. Bortzmeyer		Domain Name System Operations (dnsop) Working Group S. Bortzmeyer
	Internet-Draft AFNIC		Internet-Draft AFNIC
	Updates: 1034,2308 (if approved) S. Huque		Updates: 1034,2308 (if approved) S. Huque
	Intended status: Standards Track Verisign Labs		Intended status: Standards Track Verisign Labs
	Expires: September 11, 2016 March 10, 2016		Expires: October 9, 2016 April 7, 2016
	NXDOMAIN really means there is nothing underneath		NXDOMAIN really means there is nothing underneath
	draft-ietf-dnsop-nxdomain-cut-01		draft-ietf-dnsop-nxdomain-cut-02
	Abstract		Abstract
	This document states clearly that when a DNS resolver receives a		This document states clearly that when a DNS resolver receives a
	response with response code of NXDOMAIN, it means that the domain		response with response code of NXDOMAIN, it means that the domain
	name which is thus denied AND ALL THE NAMES UNDER IT do not exist.		name which is thus denied AND ALL THE NAMES UNDER IT do not exist.
	REMOVE BEFORE PUBLICATION: this document should be discussed in the		REMOVE BEFORE PUBLICATION: this document should be discussed in the
	IETF DNSOP (DNS Operations) group, through its mailing list. The		IETF DNSOP (DNS Operations) group, through its mailing list. The
	source of the document, as well as a list of open issues, is		source of the document, as well as a list of open issues, is
	skipping to change at page 1, line 41 ¶		skipping to change at page 1, line 41 ¶
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF). Note that other groups may also distribute		Task Force (IETF). Note that other groups may also distribute
	working documents as Internet-Drafts. The list of current Internet-		working documents as Internet-Drafts. The list of current Internet-
	Drafts is at http://datatracker.ietf.org/drafts/current/.		Drafts is at http://datatracker.ietf.org/drafts/current/.
	Internet-Drafts are draft documents valid for a maximum of six months		Internet-Drafts are draft documents valid for a maximum of six months
	and may be updated, replaced, or obsoleted by other documents at any		and may be updated, replaced, or obsoleted by other documents at any
	time. It is inappropriate to use Internet-Drafts as reference		time. It is inappropriate to use Internet-Drafts as reference
	material or to cite them other than as "work in progress."		material or to cite them other than as "work in progress."
	This Internet-Draft will expire on September 11, 2016.		This Internet-Draft will expire on October 9, 2016.
	Copyright Notice		Copyright Notice
	Copyright (c) 2016 IETF Trust and the persons identified as the		Copyright (c) 2016 IETF Trust and the persons identified as the
	document authors. All rights reserved.		document authors. All rights reserved.
	This document is subject to BCP 78 and the IETF Trust's Legal		This document is subject to BCP 78 and the IETF Trust's Legal
	Provisions Relating to IETF Documents		Provisions Relating to IETF Documents
	(http://trustee.ietf.org/license-info) in effect on the date of		(http://trustee.ietf.org/license-info) in effect on the date of
	publication of this document. Please review these documents		publication of this document. Please review these documents
	skipping to change at page 2, line 17 ¶		skipping to change at page 2, line 17 ¶
	to this document. Code Components extracted from this document must		to this document. Code Components extracted from this document must
	include Simplified BSD License text as described in Section 4.e of		include Simplified BSD License text as described in Section 4.e of
	the Trust Legal Provisions and are provided without warranty as		the Trust Legal Provisions and are provided without warranty as
	described in the Simplified BSD License.		described in the Simplified BSD License.
	Table of Contents		Table of Contents
	1. Introduction and background . . . . . . . . . . . . . . . . . 2		1. Introduction and background . . . . . . . . . . . . . . . . . 2
	1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3		1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3
	2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3		2. Rules . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
	3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 4		3. Benefits . . . . . . . . . . . . . . . . . . . . . . . . . . 5
	4. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 5		4. Possible issues . . . . . . . . . . . . . . . . . . . . . . . 5
	5. Implementation considerations . . . . . . . . . . . . . . . . 5		5. Implementation considerations . . . . . . . . . . . . . . . . 6
	6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6		6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
	7. Security Considerations . . . . . . . . . . . . . . . . . . . 6		7. Security Considerations . . . . . . . . . . . . . . . . . . . 6
	8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 6		8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION 7
	9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7		9. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 7
	10. References . . . . . . . . . . . . . . . . . . . . . . . . . 7		10. References . . . . . . . . . . . . . . . . . . . . . . . . . 8
	10.1. Normative References . . . . . . . . . . . . . . . . . . 7		10.1. Normative References . . . . . . . . . . . . . . . . . . 8
	10.2. Informative References . . . . . . . . . . . . . . . . . 8		10.2. Informative References . . . . . . . . . . . . . . . . . 8
	10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 8		10.3. URIs . . . . . . . . . . . . . . . . . . . . . . . . . . 9
	Appendix A. Why can't we just use the owner name of the returned		Appendix A. Why can't we just use the owner name of the returned
	SOA? . . . . . . . . . . . . . . . . . . . . . . . . 9		SOA? . . . . . . . . . . . . . . . . . . . . . . . . 9
	Appendix B. Related approaches . . . . . . . . . . . . . . . . . 9		Appendix B. Related approaches . . . . . . . . . . . . . . . . . 10
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 9		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
	1. Introduction and background		1. Introduction and background
	The DNS protocol [RFC1035] defines response code 3 as "Name Error",		The DNS protocol [RFC1035] defines response code 3 as "Name Error",
	or "NXDOMAIN" [RFC2308], which means that the queried domain name		or "NXDOMAIN" [RFC2308], which means that the queried domain name
	does not exist in the DNS. Since domain names are represented as a		does not exist in the DNS. Since domain names are represented as a
	tree of labels ([RFC1034], Section 3.1), non-existence of a node		tree of labels ([RFC1034], Section 3.1), non-existence of a node
	implies non-existence of the entire sub-tree rooted at this node.		implies non-existence of the entire sub-tree rooted at this node.
	The DNS iterative resolution algorithm precisely interprets the		The DNS iterative resolution algorithm precisely interprets the
	skipping to change at page 3, line 30 ¶		skipping to change at page 3, line 30 ¶
	"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this		"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
	document are to be interpreted as described in [RFC2119].		document are to be interpreted as described in [RFC2119].
	"Denied name": the domain name whose existence has been denied by a		"Denied name": the domain name whose existence has been denied by a
	response of rcode NXDOMAIN. In most cases, it is the QNAME but,		response of rcode NXDOMAIN. In most cases, it is the QNAME but,
	because of [RFC6604], it is not always the case.		because of [RFC6604], it is not always the case.
	Other terms are defined in [RFC1034] or [RFC1035] or (like NXDOMAIN		Other terms are defined in [RFC1034] or [RFC1035] or (like NXDOMAIN
	itself) in the more recent [RFC7719].		itself) in the more recent [RFC7719].
			The domain name space is conceptually defined in terms of a tree
			structure. The implementation of a DNS resolver/cache MAY use a tree
			or other data structures. The cache being a subset of the data in
			the domain name space, it is much easier to reason about it in terms
			of that tree structure and to describe things in those terms (names
			under/above, descendent names, subtrees etc). In fact, the DNS
			algorithm description in [RFC1034] even states an assumption that the
			cache is a tree structure, so the precedent is already well
			established: see its section 4.3.2 which says "The following
			algorithm assumes that the RRs are organized in several tree
			structures, one for each zone, and another for the cache..." So, in
			this document, each time we talk of a tree or tree operations, it
			refers to the model, not to the actual implementation.
	2. Rules		2. Rules
	When an iterative caching DNS resolver receives a response NXDOMAIN,		When an iterative caching DNS resolver receives a response NXDOMAIN,
	it SHOULD store it in its cache and all names and RRsets at or below		it SHOULD store it in its cache and all names and RRsets at or below
	that node SHOULD then be considered to be unreachable. Subsequent		that node SHOULD then be considered to be unreachable. Subsequent
	queries for such names SHOULD elicit an NXDOMAIN response.		queries for such names SHOULD elicit an NXDOMAIN response.
	[TODO: currently under discussion, some people find it dangerous.		But if a resolver has cached data under the NXDOMAIN cut, it MAY
	Only if the NXDOMAIN is DNSSEC-validated? Perhaps the resolver could		continue to send it as a reply. (Until the TTL of this cached data
	be configured to not apply this rule to TLDs (or root). See		expires.)
	Section 7.]
	For example, consider two successive queries to a resolver, with a		Another exception is that a validating resolver MAY decide to
	non-existing domain 'foo.example': the first is for 'foo.example'		implement this behaviour only when the NXDOMAIN response has been
	(which results in an NXDOMAIN) and the second for 'bar.foo.example'		validated with DNSSEC. See Section 7 for the rationale.
	(which also results in an NXDOMAIN). Many resolvers today will
	forward both queries, as noticed in Section 8. However, following		As an example of the consequence of these rules, consider two
	the rules in this document ("NXDOMAIN cut"), a resolver would cache		successive queries to a resolver, with a non-existing domain
	the first NXDOMAIN response, as a sign of non-existence, and then		'foo.example': the first is for 'foo.example' (which results in an
	immediately return an NXDOMAIN response for the second query, without		NXDOMAIN) and the second for 'bar.foo.example' (which also results in
	transmitting it to an authoritative server.		an NXDOMAIN). Many resolvers today will forward both queries, as
			noticed in Section 8. However, following the rules in this document
			("NXDOMAIN cut"), a resolver would cache the first NXDOMAIN response,
			as a sign of non-existence, and then immediately return an NXDOMAIN
			response for the second query, without transmitting it to an
			authoritative server.
	If the first request is for 'bar.foo.example' and the second for		If the first request is for 'bar.foo.example' and the second for
	'baz.foo.example', the first NXDOMAIN response won't tell anything		'baz.foo.example', the first NXDOMAIN response won't tell anything
	about 'baz.foo.example' and therefore the second query will be		about 'baz.foo.example' and therefore the second query will be
	transmitted as it was before "NXDOMAIN cut" (see Appendix A).		transmitted as it was before "NXDOMAIN cut" (see Appendix A).
	These rules replace the second paragraph of section 5 of [RFC2308].		These rules replace the second paragraph of section 5 of [RFC2308].
	Otherwise, this document does not update any other parts of		Otherwise, this document does not update any other parts of
	[RFC2308]. The fact that a subtree does not exist is not forever:		[RFC2308]. The fact that a subtree does not exist is not forever:
	[RFC2308], section 3, already describes the amount of time that an		[RFC2308], section 3, already describes the amount of time that an
	skipping to change at page 4, line 34 ¶		skipping to change at page 5, line 9 ¶
	Warning: if there is a chain of CNAME (or DNAME), the name which does		Warning: if there is a chain of CNAME (or DNAME), the name which does
	not exist is the last of the chain ([RFC6604]) and not the QNAME.		not exist is the last of the chain ([RFC6604]) and not the QNAME.
	The NXDOMAIN stored in the cache is for the denied name, not always		The NXDOMAIN stored in the cache is for the denied name, not always
	for the QNAME.		for the QNAME.
	3. Benefits		3. Benefits
	The main benefit is a better efficiency of the caches. In the		The main benefit is a better efficiency of the caches. In the
	example above, the resolver send only one query instead of two, the		example above, the resolver send only one query instead of two, the
	second one being answered from the cache.		second one being answered from the cache. This will benefit the
			entire DNS ecosystem, since the authoritative name servers will have
			less unnecessary traffic to process.
	The correct behavior (in [RFC1034] and made clearer in this document)		The correct behavior (in [RFC1034] and made clearer in this document)
	is specially useful when combined with QNAME minimisation		is specially useful when combined with QNAME minimisation [RFC7816]
	[I-D.ietf-dnsop-qname-minimisation] since it will allow a resolver to		since it will allow a resolver to stop searching as soon as an
	stop searching as soon as an NXDOMAIN is encountered.		NXDOMAIN is encountered.
	NXDOMAIN cut may also help mitigate certain types of random QNAME		NXDOMAIN cut may also help mitigate certain types of random QNAME
	attacks [joost-dnsterror] [balakrichenan-dafa888], where there is a		attacks [joost-dnsterror] [balakrichenan-dafa888], where there is a
	fixed suffix which does not exist. In these attacks against the		fixed suffix which does not exist. In these attacks against the
	authoritative name server, queries are sent to resolvers for a QNAME		authoritative name server, queries are sent to resolvers for a QNAME
	composed of a fixed suffix ("dafa888.wf" in one of the articles		composed of a fixed suffix ("dafa888.wf" in one of the articles
	above), which is typically nonexistent, and a random prefix,		above), which is typically nonexistent, and a random prefix,
	different for each request. A resolver receiving these requests have		different for each request. A resolver receiving these requests have
	to forward them to the authoritative servers. With NXDOMAIN cut, a		to forward them to the authoritative servers. With NXDOMAIN cut, a
	system administrator would just have to send to the resolver a query		system administrator would just have to send to the resolver a query
	skipping to change at page 6, line 16 ¶		skipping to change at page 6, line 40 ¶
	for instance, as a dictionary) and therefore have a reason to ignore		for instance, as a dictionary) and therefore have a reason to ignore
	the rules of Section 2. So these rules are a SHOULD and not a MUST.		the rules of Section 2. So these rules are a SHOULD and not a MUST.
	6. IANA Considerations		6. IANA Considerations
	This document has no actions for IANA.		This document has no actions for IANA.
	7. Security Considerations		7. Security Considerations
	The technique described here may help against a denial-of-service		The technique described here may help against a denial-of-service
	attack named "random qnames" and described in Section 3. Apart from		attack named "random qnames" and described in Section 3.
	that, it is believed to have no security consequences.
	If a resolver does not validate the answers with DNSSEC, or if the		If a resolver does not validate the answers with DNSSEC, or if the
	zone is not signed, the resolver can of course be poisoned with a		zone is not signed, the resolver can of course be poisoned with a
	false NXDOMAIN, thus "deleting" a part of the domain name tree. This		false NXDOMAIN, thus "deleting" a part of the domain name tree. This
	denial-of-service attack is already possible without the rules of		denial-of-service attack is already possible without the rules of
	this document (but "NXDOMAIN cut" may increase its effects). The		this document (but "NXDOMAIN cut" may increase its effects). The
	only solution is to use DNSSEC.		only solution is to use DNSSEC.
	8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION		8. Implementation status - RFC EDITOR: REMOVE BEFORE PUBLICATION
	skipping to change at page 7, line 37 ¶		skipping to change at page 8, line 18 ¶
	[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",		[RFC1034] Mockapetris, P., "Domain names - concepts and facilities",
	STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,		STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987,
	<http://www.rfc-editor.org/info/rfc1034>.		<http://www.rfc-editor.org/info/rfc1034>.
	[RFC1035] Mockapetris, P., "Domain names - implementation and		[RFC1035] Mockapetris, P., "Domain names - implementation and
	specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,		specification", STD 13, RFC 1035, DOI 10.17487/RFC1035,
	November 1987, <http://www.rfc-editor.org/info/rfc1035>.		November 1987, <http://www.rfc-editor.org/info/rfc1035>.
	[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate		[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
	Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/		Requirement Levels", BCP 14, RFC 2119,
	RFC2119, March 1997,		DOI 10.17487/RFC2119, March 1997,
	<http://www.rfc-editor.org/info/rfc2119>.		<http://www.rfc-editor.org/info/rfc2119>.
	[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS		[RFC2308] Andrews, M., "Negative Caching of DNS Queries (DNS
	NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,		NCACHE)", RFC 2308, DOI 10.17487/RFC2308, March 1998,
	<http://www.rfc-editor.org/info/rfc2308>.		<http://www.rfc-editor.org/info/rfc2308>.
	[RFC6604] Eastlake 3rd, D., "xNAME RCODE and Status Bits		[RFC6604] Eastlake 3rd, D., "xNAME RCODE and Status Bits
	Clarification", RFC 6604, DOI 10.17487/RFC6604, April		Clarification", RFC 6604, DOI 10.17487/RFC6604, April
	2012, <http://www.rfc-editor.org/info/rfc6604>.		2012, <http://www.rfc-editor.org/info/rfc6604>.
	10.2. Informative References		10.2. Informative References
	[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.		[RFC4035] Arends, R., Austein, R., Larson, M., Massey, D., and S.
	Rose, "Protocol Modifications for the DNS Security		Rose, "Protocol Modifications for the DNS Security
	Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,		Extensions", RFC 4035, DOI 10.17487/RFC4035, March 2005,
	<http://www.rfc-editor.org/info/rfc4035>.		<http://www.rfc-editor.org/info/rfc4035>.
	[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running		[RFC6982] Sheffer, Y. and A. Farrel, "Improving Awareness of Running
	Code: The Implementation Status Section", RFC 6982, DOI		Code: The Implementation Status Section", RFC 6982,
	10.17487/RFC6982, July 2013,		DOI 10.17487/RFC6982, July 2013,
	<http://www.rfc-editor.org/info/rfc6982>.		<http://www.rfc-editor.org/info/rfc6982>.
	[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS		[RFC7719] Hoffman, P., Sullivan, A., and K. Fujiwara, "DNS
	Terminology", RFC 7719, DOI 10.17487/RFC7719, December		Terminology", RFC 7719, DOI 10.17487/RFC7719, December
	2015, <http://www.rfc-editor.org/info/rfc7719>.		2015, <http://www.rfc-editor.org/info/rfc7719>.
			[RFC7816] Bortzmeyer, S., "DNS Query Name Minimisation to Improve
			Privacy", RFC 7816, DOI 10.17487/RFC7816, March 2016,
			<http://www.rfc-editor.org/info/rfc7816>.
	[I-D.vixie-dnsext-resimprove]		[I-D.vixie-dnsext-resimprove]
	Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS		Vixie, P., Joffe, R., and F. Neves, "Improvements to DNS
	Resolvers for Resiliency, Robustness, and Responsiveness",		Resolvers for Resiliency, Robustness, and Responsiveness",
	draft-vixie-dnsext-resimprove-00 (work in progress), June		draft-vixie-dnsext-resimprove-00 (work in progress), June
	2010.		2010.
	[I-D.ietf-dnsop-qname-minimisation]
	Bortzmeyer, S., "DNS query name minimisation to improve
	privacy", draft-ietf-dnsop-qname-minimisation-09 (work in
	progress), January 2016.
	[I-D.fujiwara-dnsop-nsec-aggressiveuse]		[I-D.fujiwara-dnsop-nsec-aggressiveuse]
	Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3",		Fujiwara, K. and A. Kato, "Aggressive use of NSEC/NSEC3",
	draft-fujiwara-dnsop-nsec-aggressiveuse-02 (work in		draft-fujiwara-dnsop-nsec-aggressiveuse-03 (work in
	progress), October 2015.		progress), March 2016.
	[joost-dnsterror]		[joost-dnsterror]
	Joost, M., "About DNS Attacks and ICMP Destination		Joost, M., "About DNS Attacks and ICMP Destination
	Unreachable Reports", December 2014,		Unreachable Reports", December 2014,
	<http://www.michael-joost.de/dnsterror.html>.		<http://www.michael-joost.de/dnsterror.html>.
	[balakrichenan-dafa888]		[balakrichenan-dafa888]
	Balakrichenan, S., "Disturbance in the DNS - "Random		Balakrichenan, S., "Disturbance in the DNS - "Random
	qnames", the dafa888 DoS attack"", October 2014,		qnames", the dafa888 DoS attack"", October 2014,
	<https://indico.dns-oarc.net/event/20/session/3/		<https://indico.dns-oarc.net/event/20/session/3/
	contribution/37>.		contribution/37>.
	10.3. URIs		10.3. URIs
	[1] https://www.unbound.net/documentation/unbound.conf.html		[1] https://github.com/bortzmeyer/ietf-dnsop-nxdomain
	[2] https://doc.powerdns.com/md/recursor/settings/#root-nx-trust		[2] https://www.unbound.net/documentation/unbound.conf.html
			[3] https://doc.powerdns.com/md/recursor/settings/#root-nx-trust
	Appendix A. Why can't we just use the owner name of the returned SOA?		Appendix A. Why can't we just use the owner name of the returned SOA?
	In this document, we deduce the non-existence of a domain only for		In this document, we deduce the non-existence of a domain only for
	NXDOMAIN answers where the denied name was this exact domain. If a		NXDOMAIN answers where the denied name was this exact domain. If a
	resolver sends a query to the name servers of the TLD example, and		resolver sends a query to the name servers of the TLD example, and
	asks the MX record for www.foobar.example, and receives a NXDOMAIN,		asks the MX record for www.foobar.example, and receives a NXDOMAIN,
	it can only register the fact that www.foobar.example (and everything		it can only register the fact that www.foobar.example (and everything
	underneath) does not exist. Even if the accompanying SOA record is		underneath) does not exist. Even if the accompanying SOA record is
	for example only, one cannot infer that foobar.example is		for example only, one cannot infer that foobar.example is
	skipping to change at page 9, line 38 ¶		skipping to change at page 10, line 20 ¶
	than one label up in the tree, to send requests for the domains which		than one label up in the tree, to send requests for the domains which
	are between the QNAME and the owner name of the SOA. (A resolver		are between the QNAME and the owner name of the SOA. (A resolver
	which does DNSSEC validation or QNAME minimisation will need to do		which does DNSSEC validation or QNAME minimisation will need to do
	it, anyway.)		it, anyway.)
	Appendix B. Related approaches		Appendix B. Related approaches
	The document [I-D.fujiwara-dnsop-nsec-aggressiveuse] describes		The document [I-D.fujiwara-dnsop-nsec-aggressiveuse] describes
	another way to address some of the same concerns (decreasing the		another way to address some of the same concerns (decreasing the
	traffic for non-existing domain names). Unlike NXDOMAIN cut, it		traffic for non-existing domain names). Unlike NXDOMAIN cut, it
	requires DNSSEC but it is more powerful since it can synthetize		requires DNSSEC but it is more powerful since it can synthesize
	NXDOMAINs for domains that were not queried.		NXDOMAINs for domains that were not queried.
	Authors' Addresses		Authors' Addresses
	Stephane Bortzmeyer		Stephane Bortzmeyer
	AFNIC		AFNIC
	1, rue Stephenson		1, rue Stephenson
	Montigny-le-Bretonneux 78180		Montigny-le-Bretonneux 78180
	France		France
End of changes. 23 change blocks.
	44 lines changed or deleted		64 lines changed or added
This html diff was produced by rfcdiff 1.45. The latest version is available from http://tools.ietf.org/tools/rfcdiff/