draft-ietf-sunset4-gapanalysis-04.txt   draft-ietf-sunset4-gapanalysis-05.txt 
Network Working Group S. Perreault Network Working Group S. Perreault
Internet-Draft Viagenie Internet-Draft Jive Communications
Intended status: Informational T. Tsou Intended status: Informational T. Tsou
Expires: July 20, 2014 Huawei Technologies (USA) Expires: July 30, 2015 Huawei Technologies (USA)
C. Zhou C. Zhou
Huawei Technologies Huawei Technologies
January 16, 2014 P. Fan
China Mobile
January 26, 2015
Gap Analysis for IPv4 Sunset Gap Analysis for IPv4 Sunset
draft-ietf-sunset4-gapanalysis-04 draft-ietf-sunset4-gapanalysis-05
Abstract Abstract
Sunsetting IPv4 refers to the process of turning off IPv4 Sunsetting IPv4 refers to the process of turning off IPv4
definitively. It can be seen as the final phase of the migration to definitively. It can be seen as the final phase of the migration to
IPv6. This memo enumerates difficulties arising when sunsetting IPv6. This memo enumerates difficulties arising when sunsetting
IPv4, and identifies the gaps requiring additional work. IPv4, and identifies the gaps requiring additional work.
Status of This Memo Status of This Memo
skipping to change at page 1, line 36 skipping to change at page 1, line 38
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 July 20, 2014. This Internet-Draft will expire on July 30, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2015 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
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 . . . . . . . . . . . . . . . . . . . . . . . . 2 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 2
2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 2 2. Related Work . . . . . . . . . . . . . . . . . . . . . . . . 3
3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . 3 3. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . . . 3
3.1. Indicating that IPv4 connectivity is unavailable . . . . 3 3.1. Indicating that IPv4 connectivity is unavailable . . . . 3
3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . 3 3.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . . . 3
4. Client Connection Establishment Behavior . . . . . . . . . . 3 4. Client Connection Establishment Behavior . . . . . . . . . . 4
5. Disabling IPv4 in Operating System and Applications . . . . . 4 5. Disabling IPv4 in Operating System and Applications . . . . . 4
6. On-Demand Provisioning of IPv4 Addresses . . . . . . . . . . 4 6. On-Demand Provisioning of IPv4 Addresses . . . . . . . . . . 4
7. IPv4 Address Literals . . . . . . . . . . . . . . . . . . . . 5 7. IPv4 Address Literals . . . . . . . . . . . . . . . . . . . . 5
8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 5 8. Managing Router Identifiers . . . . . . . . . . . . . . . . . 5
9. Security Considerations . . . . . . . . . . . . . . . . . . . 5 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 6
10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 5 10. Security Considerations . . . . . . . . . . . . . . . . . . . 6
11. Informative References . . . . . . . . . . . . . . . . . . . 5 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 6
Appendix A. Solution Ideas . . . . . . . . . . . . . . . . . . . 7 12. Informative References . . . . . . . . . . . . . . . . . . . 6
A.1. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . 7 Appendix A. Solution Ideas . . . . . . . . . . . . . . . . . . . 8
A.1.1. Indicating that IPv4 connectivity is unavailable . . 7 A.1. Remotely Disabling IPv4 . . . . . . . . . . . . . . . . . 8
A.1.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . 7 A.1.1. Indicating that IPv4 connectivity is unavailable . . 8
A.2. Client Connection Establishment Behavior . . . . . . . . 8 A.1.2. Disabling IPv4 in the LAN . . . . . . . . . . . . . . 8
A.3. Disabling IPv4 in Operating System and Applications . . . 8 A.2. Client Connection Establishment Behavior . . . . . . . . 9
A.4. On-Demand Provisioning of IPv4 Addresses . . . . . . . . 8 A.3. Disabling IPv4 in Operating System and Applications . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 8 A.4. On-Demand Provisioning of IPv4 Addresses . . . . . . . . 9
A.5. Managing Router Identifiers . . . . . . . . . . . . . . . 9
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 10
1. Introduction 1. Introduction
The final phase of the migration to IPv6 is the sunset of IPv4, that The final phase of the migration to IPv6 is the sunset of IPv4, that
is turning off IPv4 definitively on the attached networks and on the is turning off IPv4 definitively on the attached networks and on the
upstream networks. upstream networks.
Some current implementation behavior makes it hard to sunset IPv4. Some current implementation behavior makes it hard to sunset IPv4.
Additionally, some new features could be added to IPv4 to make its Additionally, some new features could be added to IPv4 to make its
sunsetting easier. This document analyzes the current situation and sunsetting easier. This document analyzes the current situation and
skipping to change at page 3, line 10 skipping to change at page 3, line 16
[RFC3789], [RFC3790],[RFC3791], [RFC3792], [RFC3793], [RFC3794], [RFC3789], [RFC3790],[RFC3791], [RFC3792], [RFC3793], [RFC3794],
[RFC3795] and [RFC3796] contain surveys of IETF protocols with their [RFC3795] and [RFC3796] contain surveys of IETF protocols with their
IPv4 dependencies. IPv4 dependencies.
3. Remotely Disabling IPv4 3. Remotely Disabling IPv4
3.1. Indicating that IPv4 connectivity is unavailable 3.1. Indicating that IPv4 connectivity is unavailable
PROBLEM 1: When an IPv4 node boots and requests an IPv4 address PROBLEM 1: When an IPv4 node boots and requests an IPv4 address
(e.g., using DHCP), it typically interprets the absence of a (e.g., using DHCP), it typically interprets the absence
response as a failure condition even when it is not. of a response as a failure condition even when it is not.
PROBLEM 2: Home router devices often identify themselves as default PROBLEM 2: Home router devices often identify themselves as default
routers in DHCP responses that they send to requests coming from routers in DHCP responses that they send to requests
the LAN, even in the absence of IPv4 connectivity on the WAN. coming from the LAN, even in the absence of IPv4
connectivity on the WAN.
3.2. Disabling IPv4 in the LAN 3.2. Disabling IPv4 in the LAN
PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto- PROBLEM 3: IPv4-enabled hosts inside an IPv6-only LAN can auto-
configure IPv4 addresses [RFC3927] and enable various protocols configure IPv4 addresses [RFC3927] and enable various
over IPv4 such as mDNS [I-D.cheshire-dnsext-multicastdns] and protocols over IPv4 such as mDNS
LLMNR [RFC4795]. This can be undesirable for operational or [I-D.cheshire-dnsext-multicastdns] and LLMNR [RFC4795].
security reasons, since in the absence of IPv4, no monitoring or This can be undesirable for operational or security
logging of IPv4 will be in place. reasons, since in the absence of IPv4, no monitoring or
logging of IPv4 will be in place.
PROBLEM 4: IPv4 can be completely disabled on a link by filtering it PROBLEM 4: IPv4 can be completely disabled on a link by filtering it
on the L2 switching device. However, this may not be possible in on the L2 switching device. However, this may not be
all cases or may be too complex to deploy. For example, an ISP is possible in all cases or may be too complex to deploy.
often not able to control the L2 switching device in the For example, an ISP is often not able to control the L2
subscriber home network. switching device in the subscriber home network.
PROBLEM 5: A host with only Link-Local IPv4 addresses will "ARP for PROBLEM 5: A host with only Link-Local IPv4 addresses will "ARP for
everything", as described in Section 2.6.2 of [RFC3927]. everything", as described in Section 2.6.2 of [RFC3927].
Applications running on such a host connected to an IPv6-only Applications running on such a host connected to an
network will believe that IPv4 connectivity is available, IPv6-only network will believe that IPv4 connectivity is
resulting in various bad or sub-optimal behavior patterns. See available, resulting in various bad or sub-optimal
[I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] for further analysis. behavior patterns. See
[I-D.yourtchenko-ipv6-disable-ipv4-proxyarp] for further
analysis.
Some of these problems were described in [RFC2563], which Some of these problems were described in [RFC2563], which
standardized a DHCP option to disable IPv4 address auto- standardized a DHCP option to disable IPv4 address auto-
configuration. However, using this option requires running an IPv4 configuration. However, using this option requires running an IPv4
DHCP server, which is contrary to the goal of IPv4 sunsetting. DHCP server, which is contrary to the goal of IPv4 sunsetting.
4. Client Connection Establishment Behavior 4. Client Connection Establishment Behavior
PROBLEM 6: Happy Eyeballs [RFC6555] refers to multiple approaches to PROBLEM 6: Happy Eyeballs [RFC6555] refers to multiple approaches to
dual-stack client implementations that try to reduce connection dual-stack client implementations that try to reduce
setup delays by trying both IPv4 and IPv6 paths simultaneously. connection setup delays by trying both IPv4 and IPv6
Some implementations introduce delays which provide an advantage paths simultaneously. Some implementations introduce
to IPv6, while others do not [Huston2012]. The latter will pick delays which provide an advantage to IPv6, while others
the fastest path, no matter whether it is over IPv4 or IPv6, do not [Huston2012]. The latter will pick the fastest
directing more traffic over IPv4 than the other kind of path, no matter whether it is over IPv4 or IPv6,
implementations. This can prove problematic in the context of directing more traffic over IPv4 than the other kind of
IPv4 sunsetting, especially for Carrier-Grade NAT phasing out implementations. This can prove problematic in the
because CGN does not add significant latency that would make the context of IPv4 sunsetting, especially for Carrier-Grade
IPv6 path more preferable. Traffic will therefore continue using NAT phasing out because CGN does not add significant
the CGN path unless other network conditions change. latency that would make the IPv6 path more preferable.
Traffic will therefore continue using the CGN path unless
other network conditions change.
PROBLEM 7: getaddrinfo() [RFC3493] sends DNS queries for both A and PROBLEM 7: getaddrinfo() [RFC3493] sends DNS queries for both A and
AAAA records regardless of the state of IPv4 or IPv6 availability. AAAA records regardless of the state of IPv4 or IPv6
The AI_ADDRCONFIG flag can be used to change this behavior, but it availability. The AI_ADDRCONFIG flag can be used to
relies on programmers using the getaddrinfo() function to always change this behavior, but it relies on programmers using
pass this flag to the function. The current situation is that in the getaddrinfo() function to always pass this flag to
an IPv6-only environment, many useless A queries are made. the function. The current situation is that in an
IPv6-only environment, many useless A queries are made.
5. Disabling IPv4 in Operating System and Applications 5. Disabling IPv4 in Operating System and Applications
It is possible to completely remove IPv4 support from an operating It is possible to completely remove IPv4 support from an operating
system as has been shown by the work of Bjoern Zeeb on FreeBSD. system as has been shown by the work of Bjoern Zeeb on FreeBSD.
[Zeeb] Removing IPv4 support in the kernel revealed many IPv4 [Zeeb] Removing IPv4 support in the kernel revealed many IPv4
dependencies in libraries and applications. dependencies in libraries and applications.
PROBLEM 8: Completely disabling IPv4 at runtime often reveals PROBLEM 8: Completely disabling IPv4 at runtime often reveals
implementation bugs. Hard-coded dependencies on IPv4 abound, such implementation bugs. Hard-coded dependencies on IPv4
as on the 127.0.0.1 address assigned to the loopback interface. abound, such as on the 127.0.0.1 address assigned to the
It is therefore often operationally impossible to completely loopback interface. It is therefore often operationally
disable IPv4 on individual nodes. impossible to completely disable IPv4 on individual
nodes.
PROBLEM 9: In an IPv6-only world, legacy IPv4 code in operating PROBLEM 9: In an IPv6-only world, legacy IPv4 code in operating
systems and applications incurs a maintenance overhead and can systems and applications incurs a maintenance overhead
present security risks. and can present security risks.
6. On-Demand Provisioning of IPv4 Addresses 6. On-Demand Provisioning of IPv4 Addresses
As IPv6 usage climbs, the usefulness of IPv4 addresses to subscribers As IPv6 usage climbs, the usefulness of IPv4 addresses to subscribers
will become smaller. This could be exploited by an ISP to save IPv4 will become smaller. This could be exploited by an ISP to save IPv4
addresses by provisioning them on-demand to subscribers and addresses by provisioning them on-demand to subscribers and
reclaiming them when they are no longer used. This idea is described reclaiming them when they are no longer used. This idea is described
in [I-D.fleischhauer-ipv4-addr-saving] and [BBF.TR242] for the in [I-D.fleischhauer-ipv4-addr-saving] and [BBF.TR242] for the
context of PPP sessions. In these scenarios, the home router is context of PPP sessions. In these scenarios, the home router is
responsible for requesting and releasing IPv4 addresses, based on responsible for requesting and releasing IPv4 addresses, based on
snooping the traffic generated by the hosts in the LAN, which are snooping the traffic generated by the hosts in the LAN, which are
still dual-stack and unaware that their traffic is being snooped. still dual-stack and unaware that their traffic is being snooped.
PROBLEM 10: Dual-stack hosts that implement Happy-Eyeballs [RFC6555] PROBLEM 10: Dual-stack hosts that implement Happy-Eyeballs [RFC6555]
will generate both IPv4 and IPv6 traffic even if the algorithm end will generate both IPv4 and IPv6 traffic even if the
up chooosing IPv6. This means that an IPv4 address will always be algorithm end up chooosing IPv6. This means that an IPv4
requested by the home router, which defeats the purpose of on- address will always be requested by the home router,
demand provisioning. which defeats the purpose of on-demand provisioning.
PROBLEM 11: Many operating systems periodically perform some kind of PROBLEM 11: Many operating systems periodically perform some kind of
network connectivity check as long as an interface is up. network connectivity check as long as an interface is up.
Similarly, applications often send keep-alive traffic Similarly, applications often send keep-alive traffic
continuously. This permanent "background noise" will prevent an continuously. This permanent "background noise" will
IPv4 address from being released by the home router. prevent an IPv4 address from being released by the home
router.
PROBLEM 12: Hosts in the LAN have no knowledge that IPv4 is available PROBLEM 12: Hosts in the LAN have no knowledge that IPv4 is available
to them on-demand only. If they had explicit knowledge of this to them on-demand only. If they had explicit knowledge
fact, they could tune their behaviour so as to be more of this fact, they could tune their behaviour so as to be
conservative in their use of IPv4. more conservative in their use of IPv4.
PROBLEM 13: This mechanism is only being proposed for PPP even though PROBLEM 13: This mechanism is only being proposed for PPP even though
it could apply to other provisioning protocols (e.g., DHCP). it could apply to other provisioning protocols (e.g.,
DHCP).
7. IPv4 Address Literals 7. IPv4 Address Literals
IPv4 addresses are often used as resource locators. For example, it IPv4 addresses are often used as resource locators. For example, it
is common to encounter URLs containing IPv4 address literals on web is common to encounter URLs containing IPv4 address literals on web
sites [I-D.wing-behave-http-ip-address-literals]. IPv4 address sites [I-D.wing-behave-http-ip-address-literals]. IPv4 address
literals may be published on media other than web sites, and may literals may be published on media other than web sites, and may
appear in various forms other than URLs. For the operating systems appear in various forms other than URLs. For the operating systems
which exhibit the behavior described in which exhibit the behavior described in
[I-D.yourtchenko-ipv6-disable-ipv4-proxyarp], this also means an [I-D.yourtchenko-ipv6-disable-ipv4-proxyarp], this also means an
increase in the broadcast ARP traffic, which may be undesirable. increase in the broadcast ARP traffic, which may be undesirable.
PROBLEM 14: IPv6-only hosts are unable to access resources identified PROBLEM 14: IPv6-only hosts are unable to access resources identified
by IPv4 address literals. by IPv4 address literals.
8. IANA Considerations 8. Managing Router Identifiers
IPv4 addresses are often conventionally chosen to number a router ID,
which is used to identify a system running a specific protocol. The
common practice of tying an ID to an IPv4 address gives much
operational convenience. A human-readable ID is easy for network
operators to deal with, and it can be auto-configured, saving the
work of planning and assignment. It is also helpful to quickly
perform diagnosis and troubleshooting, and easy to identify the
availability and location of the identified router.
PROBLEM 15: In an IPv6 only network, there is no IP address that can
be directly used to number a router ID. IDs have to be
planned individually to meet the uniqueness requirement.
Tying the ID directly to an IP address which yields
human-friendly, auto-configured ID that helps with
troubleshooting is not possible.
9. IANA Considerations
None. None.
9. Security Considerations 10. Security Considerations
It is believed that none of the problems identified in this draft are It is believed that none of the problems identified in this draft are
security issues. security issues.
10. Acknowledgements 11. Acknowledgements
Thanks in particular to Andrew Yourtchenko, Lee Howard, Nejc Thanks in particular to Andrew Yourtchenko, Lee Howard, Nejc
Skoberne, and Wes George for their thorough reviews and comments. Skoberne, and Wes George for their thorough reviews and comments.
Special thanks to Marc Blanchet who was the driving force behind this Special thanks to Marc Blanchet who was the driving force behind this
work and to Jean-Philippe Dionne who helped with the initial version work and to Jean-Philippe Dionne who helped with the initial version
of this document. of this document.
11. Informative References 12. Informative References
[BBF.TR242] [BBF.TR242]
Broadband Forum, "TR-242: IPv6 Transition Mechanisms for Broadband Forum, "TR-242: IPv6 Transition Mechanisms for
Broadband Networks", August 2012. Broadband Networks", August 2012.
[Huston2012] [Huston2012]
Huston, G. and G. Michaelson, "RIPE 64: Analysing Dual Huston, G. and G. Michaelson, "RIPE 64: Analysing Dual
Stack Behaviour and IPv6 Quality", April 2012. Stack Behaviour and IPv6 Quality", April 2012.
[I-D.cheshire-dnsext-multicastdns] [I-D.cheshire-dnsext-multicastdns]
skipping to change at page 7, line 37 skipping to change at page 8, line 25
Configuration of IPv4 Link-Local Addresses", RFC 3927, May Configuration of IPv4 Link-Local Addresses", RFC 3927, May
2005. 2005.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795, January Multicast Name Resolution (LLMNR)", RFC 4795, January
2007. 2007.
[RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with [RFC6555] Wing, D. and A. Yourtchenko, "Happy Eyeballs: Success with
Dual-Stack Hosts", RFC 6555, April 2012. Dual-Stack Hosts", RFC 6555, April 2012.
[Zeeb] , "FreeBSD Snapshots without IPv4 support", , [Zeeb] "FreeBSD Snapshots without IPv4 support",
<http://wiki.freebsd.org/IPv6Only>. <http://wiki.freebsd.org/IPv6Only>.
Appendix A. Solution Ideas Appendix A. Solution Ideas
A.1. Remotely Disabling IPv4 A.1. Remotely Disabling IPv4
A.1.1. Indicating that IPv4 connectivity is unavailable A.1.1. Indicating that IPv4 connectivity is unavailable
One way to address these issues is to send a signal to a dual-stack One way to address these issues is to send a signal to a dual-stack
node that IPv4 connectivity is unavailable. Given that IPv4 shall be node that IPv4 connectivity is unavailable. Given that IPv4 shall be
skipping to change at page 8, line 36 skipping to change at page 9, line 25
It would be useful for the IETF to provide guidelines to programmers It would be useful for the IETF to provide guidelines to programmers
on how to avoid creating dependencies on IPv4, how to discover on how to avoid creating dependencies on IPv4, how to discover
existing dependencies, and how to eliminate them. Having programs existing dependencies, and how to eliminate them. Having programs
and operating systems that behave well in an IPv6-only environment is and operating systems that behave well in an IPv6-only environment is
a prerequisite for IPv4 sunsetting. a prerequisite for IPv4 sunsetting.
A.4. On-Demand Provisioning of IPv4 Addresses A.4. On-Demand Provisioning of IPv4 Addresses
No idea. No idea.
A.5. Managing Router Identifiers
Router IDs can be manually planned, possibly with some hierarchy or
design rule, or can be created automatically. A simple way of
automatic creation is to generate pseudo-random numbers, and one can
use another source of data such as the clock time at boot or
configuration time to provide additional entropy during the
generation of unique IDs. Another way is to hash an IPv6 address
down to a value as ID. The hash algorithm is supposed to be known
and the same across the domain. Since typically the number of
routers in a domain is far smaller than the value range of IDs, the
hashed IDs are hardly likely to conflict with each other, as long as
the hash algorithm is not designed too badly. It is necessary to be
able to override the automatically created value, and desirable if
the mechanism is provided by the system implementation.
If the ID is created from IPv6 address, e.g. by hashing from an IPv6
address, then naturally it has relationship with the address. If the
ID is created regardless of IP address, one way to build association
with IPv6 address is to embed the ID into an IPv6 address that is to
be configured on the router, e.g. use a /96 IPv6 prefix and append it
with a 32-bit long ID. One can also use some record keeping
mechanisms, e.g. text file, DNS or other provisioning system like
network management system to manage the IDs and mapping relations
with IPv6 addresses, though extra record keeping does introduce
additional work.
Authors' Addresses Authors' Addresses
Simon Perreault Simon Perreault
Viagenie Jive Communications
246 Aberdeen Quebec, QC
Quebec, QC G1R 2E1
Canada Canada
Phone: +1 418 656 9254 Email: sperreault@jive.com
Email: simon.perreault@viagenie.ca
URI: http://viagenie.ca
Tina Tsou Tina Tsou
Huawei Technologies (USA) Huawei Technologies (USA)
2330 Central Expressway 2330 Central Expressway
Santa Clara, CA 95050 Santa Clara, CA 95050
USA USA
Phone: +1 408 330 4424 Phone: +1 408 330 4424
Email: tina.tsou.zouting@huawei.com Email: tina.tsou.zouting@huawei.com
Cathy Zhou Cathy Zhou
Huawei Technologies Huawei Technologies
Huawei Industrial Base Huawei Industrial Base
Bantian, Shenzhen Bantian, Shenzhen
China China
Email: cathy.zhou@huawei.com Email: cathy.zhou@huawei.com
Peng Fan
China Mobile
32 Xuanwumen West Street
Beijing, Beijing
China
Email: fanp08@gmail.com
 End of changes. 32 change blocks. 
84 lines changed or deleted 141 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/