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/