REPUBLIC OF RWANDA
RWANDA UTILITIES REGULATORY AGENCY
Tel: + (250) 0252584562
Fax: + (250) 0252584563
E-mail: arms@rwanda1.com
Website: www.rura.gov.rw
P.O. BOX: 7289
OUTCOMES OF THE
CONSULTATION HELD ON THE TRANSITION
FROM IPV4 TO IPV6 IN RWANDA
AND THE RECOMMENDATIONS THEREON
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 1
Table of Contents
List of Abbreviations ................................................................................................................................... 4
1.
2.
Executive Summary ............................................................................................................................ 6
1.1
Setting up of a National IPv6 Task Force ............................................................................... 7
1.2
Leadership role of Government for IPv6 migration ............................................................... 7
1.3
Regulatory issues related to transition from IPv4 to IPv6.................................................... 8
1.4
The deployment strategy for Rwanda ..................................................................................... 8
Public Consultation Paper on Issues Pertaining to Transition from IPv4 to IPv6 in Rwanda.. 8
2.1.
Analysis of Stakeholders’ comments and RURA’s observations and recommendations .. 8
2.1.1. Should the regulator play a regulatory role in the transition from IPv4 to IPv6 for
the country or do you think the industry has the capability to handle it on its own?.............. 8
2.1.1.1.
2.1.2.
Recommendations .................................................................................................... 10
If yes, what regulatory steps and policy initiatives, you believe are required? ...... 12
2.1.2.1.
Recommendations .................................................................................................... 12
2.1.3. Which transition mechanism/strategy do you consider is best suited for migration
from IPv4 to IPv6? ........................................................................................................................... 14
2.1.3.1.
Dual-stack Hosts and Routers ................................................................................. 14
2.1.3.2.
Tunneling ................................................................................................................... 15
2.1.3.3.
Recommendations .................................................................................................... 15
2.1.4. Do you consider that the allocation of permanent IP addresses to a broadband
user is a must or not? ...................................................................................................................... 16
2.1.4.1.
Recommendations .................................................................................................... 16
2.1.5. Do you believe that the present mandate of the regulator regarding numbering
administration is by extension applicable to IPv6? ...................................................................... 17
2.1.5.1.
Recommendations .................................................................................................... 18
2.1.6. Do you find or have you ever encountered any problem with the existing system
of IP address allocation in Rwanda? .............................................................................................. 18
2.1.7. Are Rwandan ISPs presently involved in any experimentation programme with
IPv6 in an effort to move towards commercial IPv6 based services? ...................................... 18
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 2
2.1.7.1.
Recommendations .................................................................................................... 19
2.1.8. Is there any other issue/comment pertaining to transition to IPv6 in Rwanda that
you may wish to flag out? ............................................................................................................... 19
2.1.8.1.
3.
Compiled responses to technical questionnaire sent to Rwandan ISPs ................................... 20
3.1.
Introduction ............................................................................................................................... 21
3.2.
Executive Summary on the Survey of ISP's Experience, Plans, and Requirements ....... 21
3.2.1.
General Questions about IP based Service ................................................................... 21
3.2.2.
Requirements for IPv6 ..................................................................................................... 21
3.2.3.
Status and Plans for IPv6 Service .................................................................................. 22
3.2.4.
IPv6 Technologies ............................................................................................................ 22
3.3.
4.
Recommendations .................................................................................................... 20
Gap Analysis .............................................................................................................................. 23
3.3.1.
Product Issues ................................................................................................................... 23
3.3.2.
Security Considerations.................................................................................................... 23
3.3.3.
Acknowledgements ........................................................................................................... 24
Responsibility matrix ........................................................................................................................ 24
APPENDIX I................................................................................................................................................ 26
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 3
List of Abbreviations
ADSL - Asymmetric Digital Subscriber Line
CIDR - Classless Inter-Domain Routing
CPE - Customer-premises equipment
DHCPv6 - Dynamic Host Configuration Protocol for IPv6
DNS - Domain Name System
HTTP - Hypertext Transfer Protocol
IANA - Internet Assigned Numbers Authority
ICANN - Internet Corporation for Assigned Names and Numbers
IETF - Internet Engineering Task Force
IMAP - Internet message application protocol
IP - Internet Protocol
IPng - IP next generation
ISP - Internet service providers
NAT- Network Address Translation
NAT-PT - Network Address Translation/Protocol Translation
Nemo - Network Mobility
PDA - Personal digital assistant
PI - Provider Independent
POP - Post Office Protocol
PPPoE - Point-to-Point Protocol over Ethernet
RADIUS - Remote Authentication Dial In User Service
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 4
RDB-IT - Rwanda Development Board –IT department
RIRs - Regional Internet Registries
RURA- Rwanda Utilities Regulatory Agency
PSF – Private Sector Federation
SMTP - Simple Mail Transfer Protocol
xDSL - Digital Subscriber Line (collectively to the various types of digital subscriber
Technologies, such as ADSL, SDSL and HDSL)
xDSL – Digital Subscriber Line (collectively to the various types of digital subscriber
technologies, such as ADSL, SDSL and HDSL).
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 5
1.
Executive Summary
The Internet is in transition. All the IPv4 addresses have already been allocated by
IANA to the Regional Internet Registries; the Internet is in the progress of migrating to
the new IPv6 address space.
The exhaustion of IPv4 addresses and the transition to IPv6 could result in significant,
but not insurmountable, problems for Internet services. In the short term, to allow the
network to continue to grow, engineers have developed a series of kludges. These
kludges include more efficient use of the IPv4 address resource, conservation, and the
sharing of IPv4 addresses through the use of Network Address Translation (NAT). While
these provide partial mitigation for IPv4 exhaustion they are not a long-term solution,
they increase network costs, and merely postpone some of the consequences of
address exhaustion without solving the underlying problem.
The short term solutions are nevertheless necessary because there is not enough time
to completely migrate the entire public Internet to "native IPv6" where end users can
communicate entirely via IPv6. Network protocol transitions require significant work and
investment, and with the exhaustion of IPv4 addresses looming, there is insufficient
time to complete the full IPv6 transition.
But the short-term solutions become problematic in the long run. The "solution to the
solution" as it is called, is to complete the transition to a native IPv6 network. A native
IPv6 network will restore end-to-end connectivity with a vastly expanded address
space, improve network performance, and should decrease costs. Completing the
transition of the public Internet to IPv6 will take time.
To crystallize Government’s efforts in sustaining the effective operation of the Internet
in Rwanda, the Regulatory Authority issued a consultation paper on “Issues pertaining
to Transition from IPv4 to IPv6 in Rwanda” from 05th October to 31st December 2011
highlighting the need for migration to IPv6.
Concurrently, the Regulatory Authority carried out a survey with all local ISPs to assess
their state of readiness to offer IPv6 services to the public in Rwanda. Out of the 7 ISPs
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 6
surveyed, 6 replies were received. Out of these 7 ISPs, only 6 ISPs offer Internet
services to the general public.
The Regulatory Authority has also come out with recommendations, which are based on
the written responses received from 05th October to 31st December 2011 and the
awareness meeting held between regulator and the stakeholders that take place at
RURA headquarters on 09th August 2012. It has been concluded that migration to IPv6
should not be mandated but facilitated by the Regulatory Authority and Government.
The major recommendations are as follows:
1.1 Setting up of a National IPv6 Task Force
The IPv4-to-IPv6 transition is encountering multiple challenges. These challenges
impact on public policy considerations in different ways. These issues require
effective monitoring in order to positively influence the course of the transition. In
order to chart out an effective way forward, there is a need to set up a National
IPv6 Task Force in order to look into key IPv6 issues.
1.2 Leadership role of Government for IPv6 migration
1.2.1.
It is proposed that Government sets the example to the operational
deployment and use of IPv6 through the designation of an IPv6
Transition Taskforce with a time lined Action Plan.
1.2.2.
Upgrade public/external facing servers and services (e.g. web, email,
DNS, ISP services, etc) to operationally use native IPv6;
1.2.3.
Upgrade internal client applications that communicate with public
Internet servers and supporting enterprise networks to operationally
use native IPv6 ;
1.2.4.
Usage of IPv6 in the platforms/applications pertaining to government
could be mandated. The Government could also mandate IPv6
compatibility in its own procurement of ICT systems and networks;
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 7
1.2.5.
Hold workshops and seminars, to bring awareness about IPv6 among
service providers and end-users community to be conducted through
governmental agencies.
1.3 Regulatory issues related to transition from IPv4 to IPv6
Issuance of appropriate directives to monitor the assignment of IP addresses from local
ISPs to Rwandan end users when required.
1.3.1. Amendment to the definition of IP address mentioned in ISP license to enable
128 bits to be used as needed for IPv6 based addressing.
1.3.2. The Authority will also look into the possibility of ensuring that all imported
communication network and customer premises equipment is either IPv6
compatible or that the vendor can prove that there is a clear upgrade roadmap
to support IPv6.
1.3.3. Investigate in the possibility to make the roadmap for the deployment of
experimentation programme with IPv6 and migration plan.
1.4 The deployment strategy for Rwanda
This topic will be discussed in depth at the level of the National IPv6 Task force to
assess the policy, legal and practical implications therein.
2.
Public consultation paper on issues pertaining to transition
from IPv4 to IPv6 in Rwanda
2.1.1.
Analysis of Stakeholders’ comments and RURA’s
observations and recommendations
The questions set out in the Consultation Paper as well as RURA’s observations
and recommendations have been listed below:-
2.1.2. Should the regulator play a regulatory role in the transition from
IPv4 to IPv6 for the country or do you think the industry has the
capability to handle it on its own?
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 8
ISPs responded that the industry has the capability to handle the transition from IPv4 to
IPv6 on its own. However, it would be good that ISPs mainly share with RURA their
roadmap regarding IPv6 implementation and RURA may just facilitate a smooth
transition.
To facilitate the transition to IPv6, it is also necessary that the regulator and public
agencies are involved in awareness and education programmes about IPv6. Moreover, it
is felt that in terms of the facilitation and awareness, the different stakeholders involved
should have an important role to play also in terms of disseminating the relevant
information to the different target groups. It is the considered view that, in terms of the
foregoing discussions, an IPv6 sensitization campaign involving the different
stakeholders within the Rwandan context will need to be carefully constituted to ensure
optimized results.
For example, based on the results of the survey carried out with the ISPs, it is found
that there is no consumer demand for IPv6. Public Internet services are generally
reachable today via IPv4, so there is no perceived need by consumers to run IPv6.
Moreover, consumers have “Customer Premises Equipment” (CPE) that may only be
IPv4 enabled. If the Internet service provider migrates to IPv6, the service provider
risks upsetting consumers whose equipment may no longer work properly and therefore
consumers need to be aware of this risk.
On the other hand, according to results of the same survey carried out with ISPs, the
implementation of the transition solution does not seem to be the priority of any of the
local ISPs presently. One potential reason for this situation is that without a clear
return-on-investment to the ISP, other than being able to offer IPv6 connectivity,
making the investment may appear to be problematic. In fact, ISPs will have to bear an
additional cost as the result of the transition without an improvement of service to
customers. ISPs who deploy transition solutions might then incur increased costs while
offering inferior service.
The cost of transitioning to IPv6 could also be problematic. Costs involved in the IPv6
transition include renumbering networks, running two separate networks (IPv4 and
IPv6) simultaneously, upgrading relevant software and hardware, training staff, and
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 9
testing implementations. The cost of IPv6 will involve capital investment and ongoing
operational costs that will have to be diverted from other business goals. Some
networks operators may be reluctant to spending financial resources to make the
transition until absolutely required. Conversely, early IPv6 movers in other countries
who were able to incorporate IPv6 into the regular lifecycle of their networks, indicate
that they were able to migrate their networks to IPv6 with little additional money set
aside for the IPv6 transition, suggesting that, with planning, anticipated expenses could
be mitigated.
The above examples give an indication of the different types of awareness campaign to
be undertaken for the different targeted groups.
2.1.2.1.
Recommendations
1. In order, to facilitate the transition to IPv6 for future, it is necessary
that the regulatory authority, public agencies and the government
provides an initial form of catalyst by creating awareness and
providing education about IPv6. Workshops and seminars, to bring
awareness about IPv6 among service providers and end-users
community could be conducted.
2. In the short term, private sector organizations should be sensitized to
undertake a careful analysis of their business cases for IPv6 adoption
and plan for the forthcoming emergence of IPv6 traffic on both internal
and external networks. Today, everyone should be impressed upon
that this is an urgent issue which can be successfully handled only with
good planning. Companies should be encouraged to share best
practices on IPv6 uptake for all businesses to benefit, particularly for
small- and medium-sized enterprises. Even if businesses do not have
immediate plans to implement IPv6, preparing for the unavoidable
transition now as opposed to later will only decrease the burden on IT
administrators. This process doesn't have to be daunting if a thoughtful
approach is taken. Plans should accommodate an implementation
spanning a maximum of three to five years. When IPv6 gains
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 10
momentum, migration to the new protocol will be swift, and those who
haven't planned ahead risk finding themselves at a disadvantage.
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 11
2.1.3. If yes, what regulatory steps and policy initiatives, you believe
are required?
There are minimal steps that RURA should be involved in from IPv4-to-IPv6 transition.
These challenges impact on public policy considerations in different ways. These issues
require effective monitoring in order to positively influence the course of the transition.
Government should create a task force or working group to closely monitor the
involvement of IPv6 worldwide, develop a realistic plan with operators and high interest
consumers, and monitor its implementation. If customers are well aware of the
migration and the advantages it offers, it would be a guaranty for ISPs to have an IPv6
running backbone.
2.1.3.1.
Recommendations
1. In order to chart out an effective way forward, we recommend the
setting up of a National IPv6 Task Force (Cluster) in order to look into
key IPv6 issues with the mandate of developing strategies for the
eventual nationwide deployment of IPv6 by focusing on key areas such
as:
a. Awareness creation,
b. Capacity building,
c. Research and development.
2. It is also proposed that Government leads the way by example; in this
regard it is suggested that Government and public institutions be
required to commit to the operational deployment and use of IPv6. For
instance, usage of IPv6 in the platforms/applications pertaining to
government could be mandated. The Government could also mandate
IPv6 compatibility in its own procurement of IT systems and networks.
3. The Action Plan proposed below describes specific steps that may be
adopted by governmental agencies to expedite the operational
deployment and use of IPv6:
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 12
a. Governmental agencies will need transition to IPv6 in order to:
1. Reduce complexity and increase transparency of Internet services
by eliminating the architectural need to rely on Network Address
Translation (NAT) technologies;
2. Enable
ubiquitous
security
services
for
end-to-end
network
communications that will serve as the foundation for securing future
governmental IT systems; and
3. Enable the Internet to continue to operate efficiently through an
integrated, well-architected networking platform and accommodate
the future expansion of Internet- based services.
b. In order to facilitate timely and effective IPv6 adoption,
governmental agencies shall:
1. Participate in an IPv6 Transition taskforce that will be the lead
for IPv6 transition activities;
2. Upgrade public/external facing servers and services (e.g. web,
email, DNS, ISP services, etc) to operationally use native IPv6
within the specified time frame;
3. Upgrade internal client applications that communicate with
public Internet servers and supporting enterprise networks to
operationally use native IPv6 within the specified time frame.
4. In terms of regulatory issues related to transition from IPv4 to
IPv6, there is a need to amend the definition of IP address
mentioned in ISP license to enable 128 bits to be used as
needed for IPv6 based addressing.
5. The regulatory Authority will also look into the possibility of
ensuring that all imported communication network and
customer premises equipment are either IPv6 compatible or
that the vendor can prove that there is a clear upgrade
roadmap to support IPv6.
6. The regulator will also be prepared to consider and introduce
regulatory measures to ensure that consumers’ interests are
met such as the Internet access services provided to
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 13
consumers in Rwanda should be capable of allowing end users
on either address type (IPv4 or IPv6) to access content
regardless of its address type
2.1.4. Which transition mechanism/strategy do you consider is best
suited for migration from IPv4 to IPv6?
Transition mechanisms allow organizations that currently depend on IPv4 networks
to become IPv6 enabled also. These generic mechanisms may be classified as:
1. Test IPv6 in university lab
2. Test IPv6 through RINEX
3. Test IPv6 through transit providers (by operators)
4. Advise the industry to buy IPv6 supported hardware for new upgrade
5. Dual-stack hosts and routers
6. Tunneling
7. IPv6 should first be deployed in the core of the network and then towards
servers that are hosted on the network. The following step would be to
establish native IPv6 connectivity with all the external partners (providers,
RINEX) only then can one deploy it to the end users. Here the challenge of
customer devices that are fully compliant with IPv6 still exists.
2.1.4.1.
Dual-stack Hosts and Routers
Initially, IPv6 users will require ongoing interaction with existing IPv4 nodes. This can be
achieved by using a dual-stack IPv4–IPv6 approach. With this transition mechanism, a
host has access to both IPv4 and IPv6 resources. Routers running either of the two
protocols can forward traffic for both IPv4 and IPv6 end nodes. In addition, dual-stack
machines can use IPv4 when communicating with native IPv4 hosts, or IPv6 when
communicating with IPv6 hosts.
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 14
2.1.4.2.
Tunneling
Transition mechanisms that allow IPv6 hosts to communicate via intervening IPv4
networks are based on a technique known as tunneling, which ensures there is no
disruption to the end-to-end IP communications model. With IPv6-over-IPv4 tunneling,
IPv6 packets are carried within IPv4 packets. Tunneling is a solution utilized when there
is no native IPv6 connectivity between different points on the network. IPv6 packets are
encapsulated within IPv4 packets, carried across an IPv4 network to the other side
where the IPv4 packet is removed and the IPv6 packets continue on their way.
Conversely, IPv4 packets can also be tunneled across IPv6 networks. Because the nodes
support both protocols, IPv6/IPv4 nodes may be configured with both IPv4 and IPv6
addresses. IPv6/IPv4 nodes use IPv4 mechanisms (e.g., DHCP) to acquire their IPv4
addresses, and IPv6 protocol mechanisms (e.g., stateless address auto-configuration
[RFC2462] and/or DHCPv6) to acquire their IPv6 addresses.
Tunnel brokers (TBs), which have been commercially available for some time, relieve
some of the burden associated with setting up tunnels manually. A TB is a dual-stack
server that facilitates tunneling through an IPv4 network to which the server client must
be connected in small, isolated IPv6 sites.
For example, a client may request tunneling through a web server. To enable this
request, the client receives the configuration information needed to establish a pseudoautomatic tunnel whenever the client triggers tunnel set-up. At the same time, the TB
automatically establishes the side of the tunnel bordering the IPv6 network. In this way,
users can access their web sites and connect to native IPv6 networks and services.
2.1.4.3.
Recommendations
1. Firstly, ISPs should acquire, deploy the IPv6 in their core network
because some software and equipments for customers in Rwanda are
IPv6 compliant
2. To organize a complain awareness to IT mangers of public and private
institutions
3. To conduct the technical training in University laboratories that is IPv6
compliant and organizes the capacity building with the help of Afrinic.
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 15
4. Information technology officers, ISPs should do their IT strategy that
include migration strategy from IPv4 to IPv6 and analyze the status of
their networks and known the equipments and software that are not
able to work on IPv6.
5. The transition to IPv6 from IPv4 will be a gradual process, during which
the two protocols are expected to coexist for years. This evolution
requires communication between IPv6 nodes across IPv4 zone. It also
requires transition mechanisms for IPv6 hosts and routers to enable
IPv6–IPv4 communications.
6. To plan the roadmap for migration from IPv4 to IPv6 in consultation
with stakeholders
2.1.5. Do you consider that the allocation of permanent IP addresses to
a broadband user is a must or not?
For Broadband connections, permanent IP address is not a `must’ requirement though it
is desirable for some applications. On the other hand, a permanent IP address allocation
may lead to increased privacy risk for the users as once its address is intercepted it will
remain exposed. As per most of the stakeholders the choice of IP address should be left
to the end users who can opt for the same in accordance with their applications needs.
Moreover, the assignment of static or dynamic IP addresses to end users is an
operational decision based on issues such as overhead incurred when assigning static
addresses, customer requirements, and many technical concerns based on the network
infrastructure and applications being used. Therefore, it would be inappropriate for a
regulator to mandate a single solution i.e. static IP address, when that solution may not
necessarily technically feasible for all, and may not be the best solution.
2.1.5.1.
Recommendations
There is no need of mandating allocation of a permanent IP address to a
broadband subscriber and this option is to be left to the user.
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 16
2.1.6. Do you believe that the present mandate of the regulator regarding
numbering administration is by extension applicable to IPv6?
IP addresses are managed regionally and in a hierarchical manner. ICANN, as part of its
IANA functions, allocates IP address space from the pools of unallocated address space
to the RIRs according to their needs as described by its global policy. Each RIR currently
obtains IPv4 address space and IPv6 address space from the IANA pool. RIRs allocate IP
address space to their memberships such as Local Internet Registries (LIRs) or National
Internet Registries (NIRs) according to their needs as described by each regional policy.
The minimum IPv4 allocation sizes from RIRs depend on each regional policy, which
vary from /22 to /20, while the minimum IPv6 allocation size from RIRs is generally fixed
as /32. These delegated address spaces are allocated or assigned to their members such
as ISPs or end-users.
In terms of the addressing structure is concerned, IPv6 still carries a network and a host
portion as for IPv4, but is organized differently.
Differing points of view have been expressed with respect to IP address allocation. Some
take the view that the current IP address management has been worked well and there
is no need to change it; on the other hand, others have argued for the need to review
the current system because of the rapid increase of demand and use of the Internet, in
order to ensure equitable distribution of resources and access for all into the future. In
response to that position, some have argued that any changes in the allocation
mechanism would result in technical risks such as disruption of the current routing
aggregation. In fact, it is also believed that the current regional allocation scheme is the
maximum (and optimum) level of decentralization: any further decentralization would
have negative effects, in particular with respect to routing. They also said that the
telephone number and IP address are two different thinks because the telephone
numbers are locally managed based on the country code whereas there is no limit for
the IP address.
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 17
2.1.6.1.
Recommendations
The Regulatory Authority will not at the moment act as an intermediary entity
between AfriNIC and its Rwandan members to allocate IP addresses at the
national level. However, there is a need for the Regulator to monitor
assignment of IP addresses by ISPs to Rwandan end users. Rwandan
operators that meet the defined criteria obtain their resources based on the
same process as used for all the other from the 54 countries covered by
AfriNIC. However the policy used by LIRs (Local Internet registries – The
AfriNIC members) are decided only by them and could be monitored by the
Regulator to ensure that they also follow the same principle as the global and
regional one and that there is no abuse in the way IP addresses are assigned
down to end user or enterprise’s networks. On this score, the Regulatory
Authority will do due diligence to this measure through the issuance of
appropriate guidelines to monitor the assignment of IP addresses from local
ISPs to Rwandan end users based on international best practices as and when
required.
2.1.7. Do you find or have you ever encountered any problem with the
existing system of IP address allocation in Rwanda?
No problem has been flagged out in the allocation of IP addresses from AfriNIC to its
Rwandan members. However, as previously indicated by AfriNIC and reiterated by ISOC,
monitoring of assignment of IP addresses from Rwandan ISPs to end users is required.
Therefore, the same analysis made in 5) above applies here also.
2.1.8. Are Rwandan ISPs presently involved in any experimentation
programme with IPv6 in an effort to move towards commercial
IPv6 based services?
According to the survey carried out on ISPs, none of them is involved in IPv6
experimentation but some of them are planning to launch the test plan by 2012.
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 18
There is no flag date by which the transition must be achieved. There is no hard and fast
deadline creating urgency, which has been the key to previous successful transitions.
Some experts predict that the transition will be protracted. However others project that
there will be a network effect whereby, when sufficient amounts of online assets have
migrated to IPv6, networks will tip to IPv6 and IPv4 will fade. At this point the transition
could accelerate.
IPv6 is a new network protocol which will require new training, experience, and
implementations. During the transition, new vulnerabilities could be introduced, and IPv4
security devices and software may be of limited use. As network operators have done
when introducing anything new into networks, operators will have to work with and test
IPv6 implementations in order to ensure security.
If precautions aren't taken, the transition from IPv4 to IPv6 could be the cause of
network security concerns. Without proper perimeter security, hackers could use IPv6 to
gain access to a LAN, which could compromise both IPv6 and IPv4 network assets.
Therefore, the same care taken to write and implement an IPv4 security policy should be
taken with IPv6, even with all its benefits. Introducing IPv6 into a network, like any
other new protocol, requires that firewalls and other security measures be well thoughtout and tested.
2.1.8.1.
Recommendations
ISPs should set up the experimentation programme with IPv6 in an effort to
move towards commercial IPv6 based services.
2.1.9. Is there any other issue/comment pertaining to transition to IPv6
in Rwanda that you may wish to flag out?
One of the more passionate points of discussion surrounding IPv6 is that IPv6 transit
traffic will require certain degree of knowledge on managing IPv6 routing and dual
IPv4/v6 since IPv6 is different than IPv4. Regulator is advised to invest on capacity
building to universities and ISP sectors. Afrinic offers free training on IPv6, if required by
a community of a country. The other concerns are that the real problem are not the
ISP'S, the real problem is that every server/service must be present in IPv4 and IPv6
either natively on the server/service or through nating. This is a much bigger job that
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 19
the jobs the ISPs have to run IPv6 on their networks. Though IPv6 was considered as of
not yet much of a big concern for Rwanda and Africa, we believe we ought to start
taking serious steps towards it. I mean not yet much of a big concern because the pool
of available IP with AfriNIC is still huge and should be able to take care of all the growth
at least for the coming years if we keep consuming them at the same pace. However,
since it is an international concern, we ought to immediately start not to be again late
compared to the world while this just depends on a decision to fast track it. ISPs also
believe that dual stack networks are going to last for a few additional years so IPv4
based services will continue to be available.
2.1.9.1.
Recommendations
This topic can be discussed in depth at the level of the National IPv6 Task
force (IPv6) to assess the policy, legal and practical implications therein.
3.
Compiled responses to technical questionnaire sent to
Rwandan ISPs
The purpose of this survey was to obtain a view of the IPv6 experience, plans, and
requirements of Rwandan ISPs. This questionnaire is based on RFC 6036 Emerging Service Provider Scenarios for IPv6 Deployment. As already stipulated
to the ISPs, replies to this questionnaire will be kept strictly confidential and only
combined results will be published without identifying information about individual ISPs
in any published results.
A detailed summary of the replies has been produced and the raw technical questions
have been listed below. The general comments are a compilation of the responses
received from seven ISPs who replied for this analysis.
This document describes practices and plans that are emerging among Internet Service
Providers for the deployment of IPv6 services. They are based on practical experience so
far, as well as current plans and requirements, reported in a survey of a number of ISPs
carried out from 05th October 2011 to 31st December 2011.
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 20
3.1. Introduction
This document describes IPv6 deployment scenarios already adopted or currently
planned by a set of ISPs who responded to a technical questionnaire. It is, therefore, a
factual record of the responses from those ISPs. It makes no recommendations; the best
choice of scenarios will depend on the circumstances of individual ISPs.
We consider various aspects of IPv6 deployment: addressing, routing, DNS,
management, and IPv4-IPv6 coexistence and interworking. Out of these 7 ISPs, only 6
ISPs offer Internet services to the general public. Only one ISP has requested the IPv6
bloc from AfriNIC.
3.2. Executive Summary on the Survey of ISP's Experience, Plans,
and Requirements
3.2.1. General Questions about IP based Service
Out of the 10 ISPs in Rwanda, only 8 of them offer services to the public. ISPs offer
origin-only IP service; some respondent offers both, origin-only and transit service.
The following access technologies are used: WiMAX, Wibro, fiber, xDSL, Wimax, WiFi,
ADSL, WBB, FIBER, ISDN, LEASED LINE, Wireless broadband, and VSAT.
Most ISPs provide Customer Premises Equipment (CPE) to some or all of their
customers, but these CPE are often unable to support IPv6 except for two ISPs.
Estimates of when ISPs will run out of public IPv4 address space for internal use vary
widely, between two to four years that is between 2012 and 2015. Public IPv4 address
space for customers is mainly expected to run out between 2012 and 2016 that is 5
years.
3.2.2. Requirements for IPv6
Out of 7 ISPs responded, reported to have never received request from customers for
IPv6. Predictions for when 10% of customers will require IPv6 range from 2012 to 2016,
and for 50% from 2015 to 2020. These ISPs require IPv6 to be a standard service
between 2012 and 2014.
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 21
3.2.3. Status and Plans for IPv6 Service
To date, 7 ISPs do not offer IPv6 as a regular service. Planned dates for regular service
are between end 2012 and 2015. This plan shall be achieved between 2012 and 2015
for 3 ISPs and one ISP shall achieve this plan after getting IPv6 compatible devices.
3.2.4. IPv6 Technologies
Turning to technology choices, the choice of approach is a dual-stack routing backbone,
and the reason given is the simplicity to manage in the core of the network. 5 out of the
7 ISPs don't see IPv6 as an opportunity to restructure their network topology. When
asked which types of equipment are unable to support IPv6, three ISPs responded that
the Customer and equipment on WiMAX, cisco 6509, routers are unable to support IPv6
and one ISP responded that none of their equipment is unable to support IPv6.
When asked if such devices can be field-upgraded to support IPv6, three ISPs can
upgrade others two ISPs need to ask the vendors if they are upgradable and one ISP is
planning to purchase IPv6 compatible equipments. Three ISPs responded that there is
no need of the new topology whereas two ISPs said that it is the time to restructure but
with no immediate effect others will restructure the topology before implementing the
IPv6.
Six ISPs out of seven responded that they will include support for DNS AAAA queries
over IPv6 once adopted. The ISPs surveyed have been allocated prefixes of /32. Only
One ISP said that IPv6 is not yet applicable but devices on which they run are IPv6
ready while two ISPs are having SMTP, POP3 and IMAP services dual-stack and two
ISPs are not yet dual-stack. Considering IPv4-IPv6 interworking, Two ISPs out seven
ISPs said that IPv6-IPv4 interworking at the IP layer is needed for some time until all
customers and network elements are IPv6 enable while one ISP said that it is not yet,
one ISP need to check and one ISP said that there is no need. On the other hand, only
two run or plan to run NAT-PT (Protocol Translation) which includes DNS translation.
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 22
Four ISPs out seven ISPs said those NAT-PT IPv6/IPv4 translators are not used while
one ISP said that it is used, one need to check. Among those who do not plan a
translator, when asked how they plan to connect IPv6-only customers to IPv4-only
services, only one respondent replied out seven said that it will cross the bridge of
connecting IPv6-only customers to IPv4-only services when it reach there while one ISP
said that it does not have this yet, one need to check and there is one ISP that is ready.
Although most ISPs see a need for IPv4-IPv6 interworking at the network layer, many of
them do not see a need for an ISP to operate the resulting translator. Yet, their
customers will be the first to suffer when IPv6-only clients cannot reach IPv4-only
services.
When asked about plans for Mobile IPv6 (or Nemo mobile networks), two ISPs out seven
ISPs said that they plan for Mobile IPv6 (or Nemo mobile networks) while one ISP said
that it is not applicable for them, one need to check and one ISP does not need this yet.
3.3. Gap Analysis
The survey has shown a certain number of desirable features to be missing, either in
relevant specifications, or in many products. This section summarizes those gaps.
3.3.1. Product Issues
As noted above, numerous models of various types of product still do not support IPv6:
a. CPE devices
b. Handsets
c. Routers
d. Cisco
e. Firewalls
f. Intrusion detection systems
g. Accounting and billing systems
3.3.2. Security Considerations
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 23
ISPs did not register any general concerns about IPv6 security. However, we note that
most of firewall and intrusion detection products for ISPs are still reported not to support
IPv6.
3.3.3. Acknowledgements
We are grateful to all the ISPs and academia who answered the questionnaire.
4.
Responsibility matrix
Tasks
GoV
RURA
MYICT
Setting up a National
RDB-
ISPs
ICT
ACADEM
IA

IPv6 Task Force
Awareness
providing
and







education
about IPv6 ,capacity
building
Experimentation
programme with IPv6
Monitor
assignment

of IP addresses by
ISPs
Ensuring
that
all

imported
communication
equipment are IPv6
compatible
To
commit
to
the


operational deployment
and use of IPv6
To
sensitize
the
private sector
to




Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 24
undertake a careful
analysis
of
their
business
cases
for
migrating to IPv6
Develop the roadmap



for migration to IPv6
Develop
the
guidelines
for

migration from IPv4
to
IPv6
and
compliance test
Government and public


institutions be required
to
commit
to
the
operational deployment
and use of IPv6
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 25
APPENDIX I
Questionnaire sent to all ISPs
This appendix reproduces the technical body of the questionnaire that was made
available for ISPs to express their requirements, plans, and experience. It also
outlines all comments gathered from all ISPs during the consultation process.
I. General questions about IP based service
1. Do you offer origin-only (stub, end-user) IP service, transit IP service, or both?
Response: Two out of seven ISPs provide both, three ISPs provide origin only,
and 1 provides both origin-only
2. Approximate number of private/small office customers (one IPv4 address)
Response: five ISPs out of seven have 2491 SMEs and corporate customers at
the time of consultation
3. Approximate number of corporate customers (block of IPv4addresses, not included in
Q2)
Response: five ISPs out of seven have 1683 corporate customers
4. Do you offer IP multicast service?
Response: Five ISPs do not offer IP multicast services whereas 2 do offer IP
multicast
5. Do any of your customers require multihoming to multiple ISPs?
Response: Six ISPs out of seven are requested the multi homing by customers
6. Access technologies used (ADSL, etc.)
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 26
Response: WiMAX, Wibro, fiber, xDSL, Wimax, WiFi, ADSL, WBB, FIBER,ISDN,
LEASED LINE , Wireless broadband, VSAT
7. Do your customers use CPE that you supply?
Response: Customers of Five out of seven ISPs use CPE supplied by ISPs
whereas one ISP does not always supply the CPE and another one has not yet
started the services.
7.1. What % of customers?
Response: The percentage of customers is between 98 and 100%
7.2. Does the CPE that you provide support native IPv6?
Response: No, the CPE does not support the native IPv6 for 3 ISPs and the
CPE does support the native IPv6 for 2 ISPs
8. When do you expect to run out of public IPv4 address space inside your own
network?
Response: Most of ISPs plan to run out of the IPv4 between 2 years and 4
years i.e. in 2015.
8.1. Do you run private (RFC1918) addresses and NAT within your network (i.e., a
second layer of NAT in the case of customers with their own NAT)?
Response: there is one ISP that uses public IP to broadband users and Endusers of Mobile Internet and hotspot use private addresses and is NATed. Four
ISPs out of seven use some NAT currently but there are upgrading the
network currently to avoid such case. One ISP is using NAT only in internal
networks.
8.2. What % of your IPv4 space is needed for your own use (not for customers)?
Response: This percentage varies between 6 and 8 %
9. When do you expect to run out of public IPv4 address space for customers?
Response: Some ISP plans to run out the IPv4 between 2 to 5 years
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 27
9.1.
Do you offer private (RFC1918) addresses to your customers?
Response: four ISPs out of seven provide public IP to customers whereas one
ISP provides private IPs and one ISP is in process to stop this as expressed
earlier are planning to shift to public IPs.
II. Questions about requirements for IPv6 service
10.
Are some big customers requesting IPv6?
Response: big customers are not yet requesting the IPv6
11.
When do you predict 10% and 50% of your customers to require IPv6
service?
Response: One ISP is predicting between 2015 and 2020 whereas four ISPs
are predicting between 2 to 3 years and one ISP can’t predict.
12.
When do you require IPv6 to be a standard service available to all
customers?
Response: Five ISP are predicting to have corporate customers by 2013-2014
and one ISP plan to have available IPv6 if requested in 2012
13.
When do you predict IPv6 traffic to reach 50% of total traffic?
Response: 3 ISPs are predicting 50% IPv6 traffic between 2013 and mid 2015 and 1 ISP is predicting 1 year after IPv6 is required and available to
end-users.
III. Questions about status and plans for IPv6 service
14.
Do you currently offer IPv6 as a regular service?
Response: six out of seven ISPs do not provide internet over IPv6 and IPv6 is
not a service.
14.1. What % of your customers currently uses IPv6?
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 28
Response: None customer is using the IPv6
14.2. When do you plan to start IPv6 deployment?
Response: Six ISPs out seven will start between 2012 and 2013
14.3. When do you plan to offer IPv6 as a special or beta-test service to customers?
Response: 5 ISPs predict to provide test bed to customer between 2012 and
2013
15.
When do you plan to offer IPv6 as a regular service to all customers?
Response: This plan shall be achieved between 2012 and 2015 for 3 ISPs and
one ISP shall achieve this plan after getting IPv6 compatible devices
IV. Questions about IPv6 technologies
16. Which basic IPv6 access method(s) apply?
16.1. Dual stacks routing backbone?
Response: Four ISPs prefer dual stack routing while one ISP prefer tunnel
broker, the hurricane electric IPv6
16.2. Separate IPv4 and IPv6 backbones?
Response: NO
16.3. 6 to 4 relay?
Response: NO
16.4. Teredo server?
Response: NO
16.5. Tunnel broker? If so, which one?
Response: NO
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 29
16.6. Something else? Please briefly describe your method:
Response: there is no any ISP that responded to the question
16.7. If possible, please briefly explain the main reasons issues behind your choice.
Response: three ISPs do not provide the motif of their choice while one ISP
said that it is simpler to manage in the core of the network and another one
ISP said that it is a free service that they are used for testing purpose and no
issues encountered during implementation
17. Which types of equipment in your network are unable to support IPv6?
Response: Three ISPs responded that the Customer and equipment on
WiMAX, cisco 6509, routers are unable to support IPv6 and one ISP
responded that none of their equipment is unable to support IPv6.
17.1. Can they be field-upgraded to support IPv6?
Response: Three ISPs can upgrade others two ISPs need to ask the vendors if
they are upgradable and one ISP is planning to purchase IPv6 compatible
equipments
17.2. Is any equipment 100% dedicated to IPv6?
Response: five ISP responded that there is no equipment dedicated 100% to
IPv6
18. Is IPv6 an opportunity to restructure your whole topology?
Response: Three ISPs responded that there is no need of the new topology
whereas two ISPs said that it is the time to restructure but with no immediate
effect, others will restructure the topology before implementing the IPv6
19. Do you include support for DNS AAAA queries over IPv6?
Response: Six ISPs will include support for DNS AAAA queries once adopted
20. Do you include support for reverse DNS for IPv6 addresses?
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 30
Response: one ISP responded that they include support for reverse DNS for
IPv6 addresses and 5 ISPs said that they will include support for reverse DNS
AAAA queries once adopted
21. What length(s) of IPv6 prefix do you have or need from the registry?
Response: three ISPs responded that the length of IPv6 prefix they have or
need from the registry is /32, One ISP did not yet test.
22. What length(s) of IPv6 prefix are offered to customers?
Response: Six ISPs responded that length(s) of IPv6 prefix that are offered to
customers are not yet applicable.
22.1. Do any customers share their IPv6 prefix among multiple hosts?
Response: Five ISPs responded that their customers sharing the IPv6 prefix
among multiple hosts is not yet applicable.
23. Do any of your customers prefer to use PI IPv6 prefixes instead of a prefix from
you?
Response: Five ISPs responded that the customer’s preference to use PI IPv6
prefixes instead of a prefix from ISPs is not yet applicable.
24. How are IPv6 prefixes delegated to CPEs? (Manual, PPPoE, RADIUS, DHCPv6,
stateless auto configuration/RA, etc...)
Response: Six ISPs responded that IPv6 prefixes delegated to CPEs (Manual,
PPPoE, RADIUS, DHCPv6, stateless auto configuration/RA, etc...) are not yet
now applicable.
25. Are your SMTP, POP3 and IMAP services dual-stack?
Response: One ISP said that it is not yet applicable but devices on which they
run are IPv6 ready while two ISPs are having dual SMTP, POP3 and IMAP
services dual-stack and
SMTP, POP3 and IMAP services dual-stack of two
ISPs are not yet dual-stack.
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 31
26. Are your HTTP services, including caching and webmail, dual-stack?
Response: One ISP said that it is not yet applicable but devices on which they
run are IPv6 ready, while two ISPs are having dual stack HTTP services,
including caching and webmail and one ISP is having dual stack caching and
one ISP is not yet dual-stack whereas one ISP need to test.
27. Are any other services dual-stack?
Response: four ISPs said that the services to be dual-stack are not yet
applicable and one ISP needs to test.
28. Is each of the following dual-stack?
28.1. Firewalls
Response: Four ISPs said that routers are not having dual stack and one ISP
is having dual stack router and one ISP whereas one ISP need to test.
28.2. Intrusion detection
Response: Four ISPs said that the intrusion detection is not dual stack and
one ISP whereas one ISP needs to test.
28.3. Address management software
Response: Four ISPs said that the Address management software is not dual
stack and one ISP whereas one ISP needs to test.
28.4. Accounting software
Response: Three ISPs said that the accounting software is not dual stack and
one ISP said that its Accounting software is dual stack whereas one ISP needs
to test.
28.5. Monitoring software
Response: Three ISPs said that the monitoring software is not dual stack and
one ISP said that its monitoring software is dual stack whereas one ISP needs
to test.
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 32
28.6. Network management tools
Response: Three ISPs said that the Network management tools are not dual
stack and two ISPs said that its Network management tools are dual stack
whereas one ISP needs to test.
29. Do you or will you have IPv6-only customers?
Response: Three ISPs said that they will not have IPv6-only customers and
two ISPs said that they will have IPv6-only customers whereas one ISP needs
to test.
30. Do you have customers who have explicitly refused to consider IPv6?
Response: Six ISP out seven ISPs said that they do not have customers who
have explicitly refused to consider IPv6
31. How many years do you expect customers to run any IPv4-only applications?
Response: One ISP out seven ISPs said that they will run IPv4 applications as
long as IPv4 is available and four ISPs said that it is hard to predict whereas
one ISP is predicting in 2015.
32. Is IPv6-IPv4 interworking at the IP layer needed?
Response: Two ISPs out seven ISPs said that IPv6-IPv4 interworking at the
IP layer needed for some time until all customers and network elements are
IPv6 enable while one ISP said that it is not yet, one need to check and one
said that there is no need.
33. Do you include a NAT-PT IPv6/IPv4 translator?
Response: Four ISPs out seven ISPs said that NAT-PT IPv6/IPv4 translator
are not used while one ISP said that it is used, one need to check.
33.1. If yes, does that include DNS translation?
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 33
Response: Four ISPs out seven ISPs said that NAT-PT IPv6/IPv4 translator
are not used while one ISP said that it includes DNS translation, one need to
check.
33.2. If not, do you plan to operate an IPv6/IPv4 translator?
Response: Three ISPs out seven ISPs said that they plan to include IPv6/IPv4
while one ISP said that it does not have this yet, one need to check.
33.3. If not, how do you plan to connect IPv6-only customers to IPv4-only services?
Response: One
ISP out seven ISPs said that it will cross the bridge of
connecting IPv6-only customers to IPv4-only services when it reach there
while one ISP said that it does not have this yet, one need to check and there
is one ISP that is ready.
33.4. If you offer IP multicast, will that need to be translated too?
Response: One ISP out seven ISPs said that it will cross the bridge of IP
multicast translation when it reach there while one ISP said that it does not
have this yet, one need to check and there is one ISP that is ready.
34. Any plans for Mobile IPv6 (or Nemo mobile networks)?
Response: Two ISPs out seven ISPs said that they plan for Mobile IPv6 (or
Nemo mobile networks) while one ISP said that it is not applicable for them,
one need to check and one ISP does not need this yet.
35. What features and tools are missing today for IPv6 deployment and operations?
Response: Four ISPs out seven ISPs said that the assessment is ongoing and
there is lack of smooth planning and IPv6 compatible equipment.
36. Any other comments about your IPv6 experience or plans? What went well, what
was difficult, etc.
Response:
One ISP out seven ISPs said that it will share once fully
implemented in its network and four ISPs said that this is not applicable at
the moment.
Outcomes of the consultation held on the transition from IPv4 to IPv6 in Rwanda and the recommendations thereon © RURASEPTEMBER, 2012
Page 34