draft-ietf-v6ops-security-overview-01.txt		draft-ietf-v6ops-security-overview-02.txt
	IPv6 Operations E. Davies		IPv6 Operations E. Davies
	Internet-Draft Consultant		Internet-Draft Consultant
	Expires: January 6, 2006 S. Krishnan		Expires: January 19, 2006 S. Krishnan
	Ericsson		Ericsson
	P. Savola		P. Savola
	CSC/Funet		CSC/Funet
	July 5, 2005		July 18, 2005
	IPv6 Transition/Co-existence Security Considerations		IPv6 Transition/Co-existence Security Considerations
	draft-ietf-v6ops-security-overview-01.txt		draft-ietf-v6ops-security-overview-02.txt
	Status of this Memo		Status of this Memo
	By submitting this Internet-Draft, each author represents that any		By submitting this Internet-Draft, each author represents that any
	applicable patent or other IPR claims of which he or she is aware		applicable patent or other IPR claims of which he or she is aware
	have been or will be disclosed, and any of which he or she becomes		have been or will be disclosed, and any of which he or she becomes
	aware will be disclosed, in accordance with Section 6 of BCP 79.		aware will be disclosed, in accordance with Section 6 of BCP 79.
	Internet-Drafts are working documents of the Internet Engineering		Internet-Drafts are working documents of the Internet Engineering
	Task Force (IETF), its areas, and its working groups. Note that		Task Force (IETF), its areas, and its working groups. Note that
	skipping to change at page 1, line 37		skipping to change at page 1, line 37
	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."
	The list of current Internet-Drafts can be accessed at		The list of current Internet-Drafts can be accessed at
	http://www.ietf.org/ietf/1id-abstracts.txt.		http://www.ietf.org/ietf/1id-abstracts.txt.
	The list of Internet-Draft Shadow Directories can be accessed at		The list of Internet-Draft Shadow Directories can be accessed at
	http://www.ietf.org/shadow.html.		http://www.ietf.org/shadow.html.
	This Internet-Draft will expire on January 6, 2006.		This Internet-Draft will expire on January 19, 2006.
	Copyright Notice		Copyright Notice
	Copyright (C) The Internet Society (2005).		Copyright (C) The Internet Society (2005).
	Abstract		Abstract
	The transition from a pure IPv4 network to a network where IPv4 and		The transition from a pure IPv4 network to a network where IPv4 and
	IPv6 co-exist brings a number of extra security considerations that		IPv6 co-exist brings a number of extra security considerations that
	need to be taken into account when deploying IPv6 and operating the		need to be taken into account when deploying IPv6 and operating the
	skipping to change at page 2, line 36		skipping to change at page 2, line 36
	2.1.11 Link-Local Addresses and Securing Neighbor		2.1.11 Link-Local Addresses and Securing Neighbor
	Discovery . . . . . . . . . . . . . . . . . . . . . 12		Discovery . . . . . . . . . . . . . . . . . . . . . 12
	2.1.12 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . 13		2.1.12 Mobile IPv6 . . . . . . . . . . . . . . . . . . . . 13
	2.2 IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 14		2.2 IPv4-mapped IPv6 Addresses . . . . . . . . . . . . . . . . 14
	2.3 Increased End-to-End Transparency . . . . . . . . . . . . 15		2.3 Increased End-to-End Transparency . . . . . . . . . . . . 15
	2.3.1 IPv6 Networks without NATs . . . . . . . . . . . . . . 15		2.3.1 IPv6 Networks without NATs . . . . . . . . . . . . . . 15
	2.3.2 Enterprise Network Security Model for IPv6 . . . . . . 15		2.3.2 Enterprise Network Security Model for IPv6 . . . . . . 15
	3. Issues Due to Transition Mechanisms . . . . . . . . . . . . 17		3. Issues Due to Transition Mechanisms . . . . . . . . . . . . 17
	3.1 IPv6 Transition/Co-existence Mechanism-specific Issues . . 17		3.1 IPv6 Transition/Co-existence Mechanism-specific Issues . . 17
	3.2 Automatic Tunneling and Relays . . . . . . . . . . . . . . 17		3.2 Automatic Tunneling and Relays . . . . . . . . . . . . . . 17
	3.3 Tunneling May Break Security Assumptions . . . . . . . . . 18		3.3 Tunneling IPv6 Through IPv4 Networks may Break IPv4
			Network Security Assumptions . . . . . . . . . . . . . . . 18
	4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . 19		4. Issues Due to IPv6 Deployment . . . . . . . . . . . . . . . 19
	4.1 IPv6 Service Piloting Done Insecurely . . . . . . . . . . 19		4.1 IPv6 Service Piloting Done Insecurely . . . . . . . . . . 19
	4.2 Enabling IPv6 by Default Reduces Usability . . . . . . . . 20		4.2 DNS Server Problems . . . . . . . . . . . . . . . . . . . 21
	4.3 Addressing Schemes and Securing Routers . . . . . . . . . 21		4.3 Addressing Schemes and Securing Routers . . . . . . . . . 21
	4.4 Consequences of Multiple Addresses in IPv6 . . . . . . . . 21		4.4 Consequences of Multiple Addresses in IPv6 . . . . . . . . 21
	4.5 Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 22		4.5 Deploying ICMPv6 . . . . . . . . . . . . . . . . . . . . . 22
	4.5.1 Problems Resulting from ICMPv6 Transparency . . . . . 23		4.5.1 Problems Resulting from ICMPv6 Transparency . . . . . 22
	4.6 IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 23		4.6 IPsec Transport Mode . . . . . . . . . . . . . . . . . . . 23
	4.7 Reduced Functionality Devices . . . . . . . . . . . . . . 23		4.7 Reduced Functionality Devices . . . . . . . . . . . . . . 23
	4.8 Operational Factors when Enabling IPv6 in the Network . . 24		4.8 Operational Factors when Enabling IPv6 in the Network . . 23
	4.9 Ingress Filtering Issues Due to Privacy Addresses . . . . 25		4.9 Ingress Filtering Issues Due to Privacy Addresses . . . . 24
	4.10 Security Issues Due to ND Proxies . . . . . . . . . . . 25		4.10 Security Issues Due to ND Proxies . . . . . . . . . . . 25
	5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25		5. IANA Considerations . . . . . . . . . . . . . . . . . . . . 25
	6. Security Considerations . . . . . . . . . . . . . . . . . . 25		6. Security Considerations . . . . . . . . . . . . . . . . . . 25
	7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25		7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 25
	8. References . . . . . . . . . . . . . . . . . . . . . . . . . 26		8. References . . . . . . . . . . . . . . . . . . . . . . . . . 25
	8.1 Normative References . . . . . . . . . . . . . . . . . . . 26		8.1 Normative References . . . . . . . . . . . . . . . . . . . 25
	8.2 Informative References . . . . . . . . . . . . . . . . . . 27		8.2 Informative References . . . . . . . . . . . . . . . . . . 27
	Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30		Authors' Addresses . . . . . . . . . . . . . . . . . . . . . 30
	A. IPv6 Probing/Mapping Considerations . . . . . . . . . . . . 30		A. IPv6 Probing/Mapping Considerations . . . . . . . . . . . . 30
	B. IPv6 Privacy Considerations . . . . . . . . . . . . . . . . 31		B. IPv6 Privacy Considerations . . . . . . . . . . . . . . . . 31
	B.1 Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 32		B.1 Exposing MAC Addresses . . . . . . . . . . . . . . . . . . 31
	B.2 Exposing Multiple Devices . . . . . . . . . . . . . . . . 32		B.2 Exposing Multiple Devices . . . . . . . . . . . . . . . . 32
	B.3 Exposing the Site by a Stable Prefix . . . . . . . . . . . 32		B.3 Exposing the Site by a Stable Prefix . . . . . . . . . . . 32
	Intellectual Property and Copyright Statements . . . . . . . 34		Intellectual Property and Copyright Statements . . . . . . . 33
	1. Introduction		1. Introduction
	The transition from a pure IPv4 network to a network where IPv4 and		The transition from a pure IPv4 network to a network where IPv4 and
	IPv6 co-exist brings a number of extra security considerations that		IPv6 co-exist brings a number of extra security considerations that
	need to be taken into account when deploying IPv6 and operating the		need to be taken into account when deploying IPv6 and operating the
	dual-protocol network with its associated transition mechanisms.		dual-protocol network with its associated transition mechanisms.
	This document attempts to give an overview of the various issues		This document attempts to give an overview of the various issues
	grouped into three categories:		grouped into three categories:
	o issues due to the IPv6 protocol itself,		o issues due to the IPv6 protocol itself,
	skipping to change at page 18, line 29		skipping to change at page 18, line 29
	As authentication of such a relay service is very difficult to		As authentication of such a relay service is very difficult to
	achieve, and particularly so in some of the possible deployment		achieve, and particularly so in some of the possible deployment
	models, relays provide a potential vehicle for address spoofing,		models, relays provide a potential vehicle for address spoofing,
	(reflected) Denial-of-Service attacks, and other threats.		(reflected) Denial-of-Service attacks, and other threats.
	Threats related to 6to4 and measures to combat them are discussed in		Threats related to 6to4 and measures to combat them are discussed in
	[RFC3964]. [I-D.huitema-v6ops-teredo] incorporates extensive		[RFC3964]. [I-D.huitema-v6ops-teredo] incorporates extensive
	discussion of the threats to Teredo and measures to combat them.		discussion of the threats to Teredo and measures to combat them.
	3.3 Tunneling May Break Security Assumptions		3.3 Tunneling IPv6 Through IPv4 Networks May Break IPv4 Network
			Security Assumptions
	NATs and firewalls have been deployed extensively in the IPv4		NATs and firewalls have been deployed extensively in the IPv4
	Internet, as discussed in Section 2.3. Operators who deploy them		Internet, as discussed in Section 2.3. Operators who deploy them
	typically have some security/operational requirements in mind (e.g. a		typically have some security/operational requirements in mind (e.g. a
	desire to block inbound connection attempts), which may or may not be		desire to block inbound connection attempts), which may or may not be
	misguided.		misguided.
	The addition of tunneling can change the security model which such		The addition of tunneling can change the security model which such
	deployments are seeking to enforce. IPv6-over-IPv4 tunneling using		deployments are seeking to enforce. IPv6-over-IPv4 tunneling using
	protocol 41 is typically either explicitly allowed, or disallowed		protocol 41 is typically either explicitly allowed, or disallowed
	skipping to change at page 19, line 43		skipping to change at page 19, line 44
	tunneling transition mechanisms.		tunneling transition mechanisms.
	4. Issues Due to IPv6 Deployment		4. Issues Due to IPv6 Deployment
	4.1 IPv6 Service Piloting Done Insecurely		4.1 IPv6 Service Piloting Done Insecurely
	In many cases, IPv6 service piloting is done in a manner which is		In many cases, IPv6 service piloting is done in a manner which is
	less secure than can be achieved for an IPv4 production service. For		less secure than can be achieved for an IPv4 production service. For
	example, hosts and routers might not be protected by IPv6 firewalls,		example, hosts and routers might not be protected by IPv6 firewalls,
	even if the corresponding IPv4 service is fully protected by		even if the corresponding IPv4 service is fully protected by
	firewalls.		firewalls as described in [I-D.ietf-v6ops-v6onbydefault]. This is
			particularly critical where IPv6 capabilities are turned on by
			default in new equipment or new releases of operating systems:
			network managers may not be fully aware of the security exposure that
			this creates.
	The other possible alternative, in some instances, is that no service		The other possible alternative, in some instances, is that no service
	piloting is permitted because IPv6 firewalls and other security		piloting is permitted because IPv6 firewalls and other security
	capabilities, such as intrusion detection systems may not be widely		capabilities, such as intrusion detection systems may not be widely
	available. Consequently, IPv6 deployment suffers and expertise		available. Consequently, IPv6 deployment suffers and expertise
	accumulates less rapidly.		accumulates less rapidly.
	These problems may be partly due to the relatively slow development		These problems may be partly due to the relatively slow development
	and deployment of IPv6-capable firewall equipment, but there is also		and deployment of IPv6-capable firewall equipment, but there is also
	a lack of information: actually, there are quite a few IPv6 packet		a lack of information: actually, there are quite a few IPv6 packet
	skipping to change at page 20, line 34		skipping to change at page 20, line 39
	protocol make it more difficult for firewalls to be implemented and		protocol make it more difficult for firewalls to be implemented and
	work in all cases and to be fully future proof (e.g. when new		work in all cases and to be fully future proof (e.g. when new
	extension headers are used) as discussed in Section 2.1.8: it is		extension headers are used) as discussed in Section 2.1.8: it is
	significantly more difficult for intermediate nodes to process the		significantly more difficult for intermediate nodes to process the
	IPv6 header chains than IPv4 packets.		IPv6 header chains than IPv4 packets.
	A similar argument, which is often quoted as hindering IPv6		A similar argument, which is often quoted as hindering IPv6
	deployment, has been the lack of Intrusion Detection Systems (IDS).		deployment, has been the lack of Intrusion Detection Systems (IDS).
	It is not clear whether this is more of an excuse than a real reason.		It is not clear whether this is more of an excuse than a real reason.
	4.2 Enabling IPv6 by Default Reduces Usability		An additional problem is the limited implementation of high
			availability capabilities supporting IPv6. In particular,
	A practical disadvantage of enabling IPv6 at the time of writing is		development of the IPv6 version of the Virtual Router Redundancy
	that it typically reduces the observed service level by a small		Protocol (VRRP) [I-D.ietf-vrrp-ipv6-spec] has lagged the development
	fraction; that is, the usability suffers.		of the main IPv6 protocol although alternatives may be available for
			some environments.
	There are at least three factors contributing to this effect:
	o global IPv6 routing is still rather unstable, leading to packet
	loss, lower throughput, and higher delay (this was discussed with
	respect to the experimental 6Bone network in [I-D.savola-v6ops-
	6bone-mess])
	o some applications cannot properly handle both IPv4 and IPv6 or may
	have problems handling all the fallbacks and failure modes (and in
	some cases, e.g. if the TCP timeout kicks in, this may result in
	very poor performance)
	o some DNS server implementations have flaws that severely affect
	DNS queries for IPv6 addresses as discussed in [I-D.ietf-dnsop-
	misbehavior-against-aaaa]
	Actually, some providers are fully ready to offer IPv6 services (e.g.		Actually, some providers are fully ready to offer IPv6 services (e.g.
	web) today, but because that would (or, at least, might) result in		web) today, but because that would (or, at least, might) result in
	problems for many of their customers or users who are, by default,		problems for many of their customers or users who are, by default,
	using active dual-stack systems the services are not turned on: as a		using active dual-stack systems the services are not turned on: as a
	compromise, the services are often published under a separate domain		compromise, the services are often published under a separate domain
	or subdomain, and are, in practice, not much used as a consequence.		or subdomain, and are, in practice, not much used as a consequence.
	These issues are also described at some length in [I-D.ietf-v6ops-		4.2 DNS Server Problems
	v6onbydefault].
	An additional problem is the limited implementation of high		Some DNS server implementations have flaws that severely affect DNS
	availability capabilities supporting IPv6. In particular,		queries for IPv6 addresses as discussed in [RFC4074]. These flaws
	development of the IPv6 version of the Virtual Router Redundancy		can be used for DoS attacks affecting both IPv4 and IPv6 by inducing
	Protocol (VRRP) [I-D.ietf-vrrp-ipv6-spec] has lagged the development		caching DNS servers to believe that a domain is broken and causing
	of the main IPv6 protocol although alternatives may be available for		the server to block access to all requests for the domain for a
	some environments.		precautionary period.
	4.3 Addressing Schemes and Securing Routers		4.3 Addressing Schemes and Securing Routers
	Whilst in general terms brute force scanning of IPv6 subnets is		Whilst in general terms brute force scanning of IPv6 subnets is
	essentially impossible due to the enormously larger address space of		essentially impossible due to the enormously larger address space of
	IPv6 and the 64 bit interface identifiers (see Appendix A), this will		IPv6 and the 64 bit interface identifiers (see Appendix A), this will
	be obviated if administrators do not take advantage of the large		be obviated if administrators do not take advantage of the large
	space to use unguessable interface identifiers.		space to use unguessable interface identifiers.
	Because the unmemorability of complete IPv6 addresses there is a		Because the unmemorability of complete IPv6 addresses there is a
	skipping to change at page 25, line 43		skipping to change at page 25, line 29
	To resolve the security issues introduced by NDProxies, SEND needs to		To resolve the security issues introduced by NDProxies, SEND needs to
	be extended to be NDProxy aware.		be extended to be NDProxy aware.
	5. IANA Considerations		5. IANA Considerations
	This memo does not contain any actions for IANA.		This memo does not contain any actions for IANA.
	6. Security Considerations		6. Security Considerations
	This memo attempts to give an overview of security considerations of		This memo attempts to give an overview of security considerations of
	the different aspects of IPv6.		the different aspects of IPv6, particularly as they relate to the
			transition to a network in which IPv4- and IPv6-based communications
			need to coexist.
	7. Acknowledgements		7. Acknowledgements
	Alain Durand, Alain Baudot, Luc Beloeil, Andras Kis-Szabo, Alvaro		Alain Durand, Alain Baudot, Luc Beloeil, Andras Kis-Szabo, Alvaro
	Vives, Janos Mohacsi and Mark Smith provided feedback to improve this		Vives, Janos Mohacsi and Mark Smith provided feedback to improve this
	memo. SUSZUKI Shinsuke provided a number of additional issues in		memo. Satoshi Kondo, Shinsuke Suzuki and Alvaro Vives provided
	cooperation with the Deployment Working Group of the Japanese IPv6		additional inputs in cooperation with the Deployment Working Group of
	Promotion Council. Michael Wittsend and Michael Cole discussed		the Japanese IPv6 Promotion Council and the Euro6IX IST co-funded
	issues relating to probing/mapping and privacy.		project, together with inputs from Jordi Palet, Brian Carpenter, and
			Peter Bieringer. Michael Wittsend and Michael Cole discussed issues
			relating to probing/mapping and privacy.
	8. References		8. References
	8.1 Normative References		8.1 Normative References
	[I-D.huitema-v6ops-teredo]		[I-D.huitema-v6ops-teredo]
	Huitema, C., "Teredo: Tunneling IPv6 over UDP through		Huitema, C., "Teredo: Tunneling IPv6 over UDP through
	NATs", draft-huitema-v6ops-teredo-05 (work in progress),		NATs", draft-huitema-v6ops-teredo-05 (work in progress),
	April 2005.		April 2005.
	[I-D.ietf-ipv6-privacy-addrs-v2]		[I-D.ietf-ipv6-privacy-addrs-v2]
	Narten, T., "Privacy Extensions for Stateless Address		Narten, T., "Privacy Extensions for Stateless Address
	Autoconfiguration in IPv6",		Autoconfiguration in IPv6",
	draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress),		draft-ietf-ipv6-privacy-addrs-v2-04 (work in progress),
	May 2005.		May 2005.
	[I-D.ietf-v6ops-natpt-to-exprmntl]		[I-D.ietf-v6ops-natpt-to-exprmntl]
	Aoun, C. and E. Davies, "Reasons to Move NAT-PT to		Aoun, C. and E. Davies, "Reasons to Move NAT-PT to
	Experimental", draft-ietf-v6ops-natpt-to-exprmntl-00 (work		Experimental", draft-ietf-v6ops-natpt-to-exprmntl-01 (work
	in progress), February 2005.		in progress), July 2005.
	[I-D.ietf-vrrp-ipv6-spec]		[I-D.ietf-vrrp-ipv6-spec]
	Hinden, R., "Virtual Router Redundancy Protocol for IPv6",		Hinden, R., "Virtual Router Redundancy Protocol for IPv6",
	draft-ietf-vrrp-ipv6-spec-07 (work in progress),		draft-ietf-vrrp-ipv6-spec-07 (work in progress),
	October 2004.		October 2004.
	[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address		[RFC2375] Hinden, R. and S. Deering, "IPv6 Multicast Address
	Assignments", RFC 2375, July 1998.		Assignments", RFC 2375, July 1998.
	[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6		[RFC2460] Deering, S. and R. Hinden, "Internet Protocol, Version 6
	skipping to change at page 27, line 42		skipping to change at page 27, line 30
	draft-chown-v6ops-port-scanning-implications-01 (work in		draft-chown-v6ops-port-scanning-implications-01 (work in
	progress), July 2004.		progress), July 2004.
	[I-D.cmetz-v6ops-v4mapped-api-harmful]		[I-D.cmetz-v6ops-v4mapped-api-harmful]
	Metz, C. and J. Hagino, "IPv4-Mapped Address API		Metz, C. and J. Hagino, "IPv4-Mapped Address API
	Considered Harmful",		Considered Harmful",
	draft-cmetz-v6ops-v4mapped-api-harmful-01 (work in		draft-cmetz-v6ops-v4mapped-api-harmful-01 (work in
	progress), October 2003.		progress), October 2003.
	[I-D.davies-v6ops-icmpv6-filtering-bcp]		[I-D.davies-v6ops-icmpv6-filtering-bcp]
	Davies, E., "Best Current Practice for Filtering ICMPv6		Davies, E. and J. Mohacsi, "Best Current Practice for
	Messages in Firewalls",		Filtering ICMPv6 Messages in Firewalls",
	draft-davies-v6ops-icmpv6-filtering-bcp-00 (work in		draft-davies-v6ops-icmpv6-filtering-bcp-00 (work in
	progress), July 2005.		progress), July 2005.
	[I-D.dupont-ipv6-rfc3041harmful]		[I-D.dupont-ipv6-rfc3041harmful]
	Dupont, F. and P. Savola, "RFC 3041 Considered Harmful",		Dupont, F. and P. Savola, "RFC 3041 Considered Harmful",
	draft-dupont-ipv6-rfc3041harmful-05 (work in progress),		draft-dupont-ipv6-rfc3041harmful-05 (work in progress),
	June 2004.		June 2004.
	[I-D.ietf-dnsop-ipv6-dns-issues]		[I-D.ietf-dnsop-ipv6-dns-issues]
	Durand, A., Ihren, J., and P. Savola, "Operational		Durand, A., Ihren, J., and P. Savola, "Operational
	Considerations and Issues with IPv6 DNS",		Considerations and Issues with IPv6 DNS",
	draft-ietf-dnsop-ipv6-dns-issues-10 (work in progress),		draft-ietf-dnsop-ipv6-dns-issues-10 (work in progress),
	October 2004.		October 2004.
	[I-D.ietf-dnsop-misbehavior-against-aaaa]
	Morishita, Y. and T. Jinmei, "Common Misbehavior against
	DNS Queries for IPv6 Addresses",
	draft-ietf-dnsop-misbehavior-against-aaaa-02 (work in
	progress), October 2004.
	[I-D.ietf-ipv6-ndproxy]		[I-D.ietf-ipv6-ndproxy]
	Thaler, D., "Bridge-like Neighbor Discovery Proxies (ND		Thaler, D., "Neighbor Discovery Proxies (ND Proxy)",
	Proxy)", draft-ietf-ipv6-ndproxy-02 (work in progress),		draft-ietf-ipv6-ndproxy-03 (work in progress), July 2005.
	May 2005.
	[I-D.ietf-mip6-ro-sec]		[I-D.ietf-mip6-ro-sec]
	Nikander, P., "Mobile IP version 6 Route Optimization		Nikander, P., "Mobile IP version 6 Route Optimization
	Security Design Background", draft-ietf-mip6-ro-sec-03		Security Design Background", draft-ietf-mip6-ro-sec-03
	(work in progress), May 2005.		(work in progress), May 2005.
	[I-D.ietf-v6ops-nap]		[I-D.ietf-v6ops-nap]
	Velde, G., "IPv6 Network Architecture Protection",		Velde, G., "IPv6 Network Architecture Protection",
	draft-ietf-v6ops-nap-01 (work in progress), June 2005.		draft-ietf-v6ops-nap-01 (work in progress), June 2005.
	skipping to change at page 29, line 12		skipping to change at page 28, line 42
	[I-D.savola-ipv6-rh-ha-security]		[I-D.savola-ipv6-rh-ha-security]
	Savola, P., "Security of IPv6 Routing Header and Home		Savola, P., "Security of IPv6 Routing Header and Home
	Address Options", draft-savola-ipv6-rh-ha-security-02		Address Options", draft-savola-ipv6-rh-ha-security-02
	(work in progress), March 2002.		(work in progress), March 2002.
	[I-D.savola-ipv6-rh-hosts]		[I-D.savola-ipv6-rh-hosts]
	Savola, P., "Note about Routing Header Processing on IPv6		Savola, P., "Note about Routing Header Processing on IPv6
	Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress),		Hosts", draft-savola-ipv6-rh-hosts-00 (work in progress),
	February 2002.		February 2002.
	[I-D.savola-v6ops-6bone-mess]
	Savola, P., "Moving from 6bone to IPv6 Internet",
	draft-savola-v6ops-6bone-mess-01 (work in progress),
	November 2002.
	[I-D.savola-v6ops-firewalling]		[I-D.savola-v6ops-firewalling]
	Savola, P., "Firewalling Considerations for IPv6",		Savola, P., "Firewalling Considerations for IPv6",
	draft-savola-v6ops-firewalling-02 (work in progress),		draft-savola-v6ops-firewalling-02 (work in progress),
	October 2003.		October 2003.
	[I-D.savola-v6ops-transarch]		[I-D.savola-v6ops-transarch]
	Savola, P., "A View on IPv6 Transition Architecture",		Savola, P., "A View on IPv6 Transition Architecture",
	draft-savola-v6ops-transarch-03 (work in progress),		draft-savola-v6ops-transarch-03 (work in progress),
	January 2004.		January 2004.
	skipping to change at page 30, line 16		skipping to change at page 29, line 42
	Neighbor Discovery (SEND)", RFC 3971, March 2005.		Neighbor Discovery (SEND)", RFC 3971, March 2005.
	[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.		[RFC4029] Lind, M., Ksinant, V., Park, S., Baudot, A., and P.
	Savola, "Scenarios and Analysis for Introducing IPv6 into		Savola, "Scenarios and Analysis for Introducing IPv6 into
	ISP Networks", RFC 4029, March 2005.		ISP Networks", RFC 4029, March 2005.
	[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.		[RFC4038] Shin, M-K., Hong, Y-G., Hagino, J., Savola, P., and E.
	Castro, "Application Aspects of IPv6 Transition",		Castro, "Application Aspects of IPv6 Transition",
	RFC 4038, March 2005.		RFC 4038, March 2005.
			[RFC4074] Morishita, Y. and T. Jinmei, "Common Misbehavior Against
			DNS Queries for IPv6 Addresses", RFC 4074, May 2005.
	Authors' Addresses		Authors' Addresses
	Elwyn B. Davies		Elwyn B. Davies
	Consultant		Consultant
	Soham, Cambs		Soham, Cambs
	UK		UK
	Phone: +44 7889 488 335		Phone: +44 7889 488 335
	Email: elwynd@dial.pipex.com		Email: elwynd@dial.pipex.com
End of changes.
This html diff was produced by rfcdiff 1.25, available from http://www.levkowetz.com/ietf/tools/rfcdiff/