Crosby-Signed Thesis - Alliance Digital Repository

Regis University 

College for Professional Studies Graduate Programs 

Final Project/Thesis 

Disclaimer 

Use of the materials available in the Regis University Thesis Collection 

(“Collection”) is limited and restricted to those users who agree to comply with 

the following terms of use. Regis University reserves the right to deny access to 

the Collection to any person who violates these terms of use or who seeks to or 

does alter, avoid or supersede the functional conditions, restrictions and 

limitations of the Collection. 

The site may be used only for lawful purposes. The user is solely responsible for 

knowing and adhering to any and all applicable laws, rules, and regulations 

relating or pertaining to use of the Collection. 

All content in this Collection is owned by and subject to the exclusive control of 

Regis University and the authors of the materials. It is available only for research 

purposes and may not be used in violation of copyright laws or for unlawful 

purposes. The materials may not be downloaded in whole or in part without 

permission of the copyright holder or as otherwise authorized in the “fair use” 

standards of the U.S. copyright laws and regulations.

IMPACT OF IPV6 TRANSITION MECHANISMS 

ON THE NETWORK FORENSICS PROCESS 

A THESIS 

SUBMITTED ON THE 18TH OF MARCH, 2011 

TO THE DEPARTMENT OF INFORMATION TECHNOLOGY 

OF THE SCHOOL OF COMPUTER & INFORMATION SCIENCES 

OF REGIS UNIVERSITY 

IN PARTIAL FULFILLMENT OF THE REQUIREMENTS OF MASTER OF SCIENCE IN 

INFORMATION ASSURANCE 

BY 

KRIS R. CROSBY 

Charles Thies, Thesis Advisor 

Daniel M. Likarish 

Douglas I. Hart

IMPACT OF IPV6 TRANSITION MECHANISMS ON THE NETWORK FORENSIC 

i 

Abstract 

IPv6 based attack vectors will become more common within traditional IPv4 networks as 

attackers recognize the opportunity to exploit an unmonitored path into the network. Previous 

research addressed IPv6 security, architecture, and implementations; however, only Nikkel 

(2007) has presented a basic investigation framework to address this gap. This study developed a 

methodology for investigating and analyzing transitional networks. The active research 

methodology was employed to evaluate the IPv6 transition mechanisms, operating systems, and 

attack vectors in a process structured around the reconnaissance, exploitation, reinforcement, 

consolidation and pillage phases of a typical network attack. The research environment consisted 

of local and remote virtual networks with Windows, Linux, FreeBSD, and Solaris UNIX nodes 

that were configured to communicate using the 6to4, Teredo, intra-site automatic tunnel 

addressing protocol (ISATAP), and Tunnel-Broker IPv6 transition mechanisms. Observations 

during the research process generated four primary conclusions. First, the addressing schemes 

and forensic properties of the transition mechanisms facilitated a methodological approach to 

investigating physical nodes, analyzing network traces, sourcing addresses, correlating events, 

and identifying threats. Second, IPv6 traffic existed when IPv6 packets were not observed in a 

network trace. Third, the transition mechanisms significantly increased the number of packet 

source addresses representing a single node. Finally, global IPv6 addresses were automatically 

configured that exposed a node to external attacks. While these contributions begin to address 

deficiencies in the research, there remains a need to unify the academic, practitioner, and legal 

communities under a common process that builds a scientific foundation for the network forensic 

discipline.


ii 

Acknowledgements 

I would like to thank my advisor, Charles Thies, for his support and guidance throughout 

the thesis process. I would also like to thank my wife Angela for her support and patience during 

the many hours of work that were required to complete this project.


iii 

Table of Contents 

CHAPTER 1 – INTRODUCTION.............................................................................................. 1 

THESIS STATEMENT ..................................................................................................................... 1 

PROBLEM STATEMENT ................................................................................................................. 1 

BACKGROUND AND SIGNIFICANCE OF THE STUDY ....................................................................... 2 

RESEARCH OBJECTIVE ................................................................................................................. 3 

DELIMITATIONS AND LIMITATIONS .............................................................................................. 4 

CHAPTER 2 – REVIEW OF LITERATURE AND RESEARCH .......................................... 5 

DIGITAL FORENSICS DISCIPLINE .................................................................................................. 5 

Digital forensic models. .......................................................................................................... 6 

Network data as evidence. .................................................................................................... 11 

Digital evidence handling. .................................................................................................... 13 

Digital investigations............................................................................................................ 17 

IPV6 FORENSIC ANALYSIS AND INVESTIGATION........................................................................ 21 

IPV6 TRANSITION MECHANISMS................................................................................................ 26 

Dual-stack. ............................................................................................................................ 27 

Tunneling. ............................................................................................................................. 29 

6to4. .................................................................................................................................. 30 

Tunnel-Brokers. ................................................................................................................ 31 

Intrasite automatic tunnel addressing protocol (ISATAP)................................................ 32 

Teredo. .............................................................................................................................. 33 

Protocol translation.............................................................................................................. 36 

Stateless IPv4/IPv6 translation algorithm (SIIT).............................................................. 36


iv 

Network address translation and protocol translation (NAT-PT)..................................... 38 

Bump-in-the-stack (BIS)................................................................................................... 39 

Bump-in-the-API (BIA).................................................................................................... 39 

SOCKS64.......................................................................................................................... 40 

Transport relay translator (TRT)....................................................................................... 41 

Other gateway based translation methods......................................................................... 41 

IPV6 OPERATING SYSTEM SUPPORT .......................................................................................... 42 

Windows operating systems. ................................................................................................. 42 

Linux, FreeBSD and UNIX operating systems. .................................................................... 48 

Ubuntu Linux.................................................................................................................... 48 

CentOS.............................................................................................................................. 49 

FreeBSD............................................................................................................................ 49 

Sun Solaris. ....................................................................................................................... 50 

Apple/MAC operating systems.............................................................................................. 51 

IPV6 VULNERABILITIES AND ATTACK VECTORS........................................................................ 52 

Reconnaissance..................................................................................................................... 55 

Denial of service attacks....................................................................................................... 55 

IPv6 protocol DoS attacks. ............................................................................................... 56 

Neighbor discovery DoS attacks....................................................................................... 57 

Man-in-the-middle attacks. ................................................................................................... 59 

IPv6 covert channels............................................................................................................. 60 

Security control bypass. ........................................................................................................ 63 

IPv6 worms. .......................................................................................................................... 63


v 

IPv6 transition mechanisms.................................................................................................. 64 

SUMMARY OF IPV6 FORENSIC RESEARCH AND IDENTIFIED GAPS .............................................. 67 

CHAPTER 3 – METHODOLOGY........................................................................................... 70 

CHARACTERISTICS OF ACTION RESEARCH ................................................................................. 70 

CLIENT/SYSTEM INFRASTRUCTURE............................................................................................ 71 

Environment.......................................................................................................................... 72 

Resources .............................................................................................................................. 73 

Participants........................................................................................................................... 76 

Boundaries ............................................................................................................................ 77 

Entry and Exit Points ............................................................................................................ 77 

Responsibilities ..................................................................................................................... 77 

PROCESS STEP 1: DIAGNOSING .................................................................................................. 78 

Research Problems ............................................................................................................... 78 

Assumptions .......................................................................................................................... 79 

PROCESS STEP 2: ACTION PLANNING ......................................................................................... 80 

Procedures ............................................................................................................................ 81 

Approach for Change............................................................................................................ 83 

PROCESS STEP 3: ACTION TAKING ............................................................................................. 83 

PROCESS STEP 4: EVALUATING .................................................................................................. 84 

Outcomes............................................................................................................................... 84 

Next Steps.............................................................................................................................. 85 

PROCESS STEP 5: SPECIFYING LEARNING................................................................................... 85 

CHAPTER 4 –ANALYSIS AND RESULTS............................................................................ 86


vi 

RECONNAISSANCE ..................................................................................................................... 86 

Node interface addresses. ..................................................................................................... 87 

Address enumeration. ........................................................................................................... 89 

Service and port discovery.................................................................................................... 96 

Lessons learned................................................................................................................... 100 

EXPLOITATION ......................................................................................................................... 101 

Rogue routers and relays. ................................................................................................... 102 

Rogue clients....................................................................................................................... 104 


REINFORCEMENT ..................................................................................................................... 105 

Source address obfuscation. ............................................................................................... 106 

Data obfuscation................................................................................................................. 108 

Destination address obfuscation......................................................................................... 109 


CONSOLIDATION ...................................................................................................................... 110 

PILLAGE................................................................................................................................... 111 

CHAPTER 5 – CONCLUSIONS............................................................................................. 113 

IMPLICATIONS OF IPV6 TRANSITION MECHANISMS IN DIGITAL FORENSICS............................. 113 

OPERATING SYSTEM BEHAVIOR IN A TRANSITIONAL NETWORK ............................................. 115 

Windows 2008, 7 and Vista................................................................................................. 116 

Windows 2003 and XP. ....................................................................................................... 116 

Ubuntu and CentOS Linux. ................................................................................................. 117 

FreeBSD and Solaris UNIX. ............................................................................................... 117


vii 

FORENSIC PROPERTIES OF IPV6 TRANSITION MECHANISMS .................................................... 118 

Link-local. ........................................................................................................................... 118 

6to4. .................................................................................................................................... 119 

Teredo. ................................................................................................................................ 120 

ISATAP................................................................................................................................ 122 

Tunnel-Broker. .................................................................................................................... 123 

PROPOSED METHODOLOGY FOR THE FORENSIC ANALYSIS OF IPV6 TRAFFIC IN A TRANSITIONAL 

NETWORK ................................................................................................................................ 124 

Physical node investigation. ............................................................................................... 124 

Network traces analysis. ..................................................................................................... 125 

Event Correlation................................................................................................................ 126 

Threat Identification. .......................................................................................................... 127 

Addresses sourcing. ............................................................................................................ 128 

LIMITATIONS AND FUTURE RESEARCH .................................................................................... 131 

REFERENCES.......................................................................................................................... 132 

APPENDIX A - DIGITAL FORENSIC FRAMEWORKS................................................... 152 

APPENDIX B - BASE OPERATING SYSTEM CONFIGURATIONS.............................. 155 

TARGET NODE 1: WINDOWS SERVER 2008 R2 DATACENTER EDITION V6.1 (64-BIT).............. 166 

TARGET NODE 2: WINDOWS SERVER 2003 R2 ENTERPRISE EDITION V5.2 SP2 (64-BIT) ......... 170 

TARGET NODE 3: MICROSOFT WINDOWS 7 ENTERPRISE V6.1 (64-BIT).................................... 172 

TARGET NODE 4: MICROSOFT WINDOWS VISTA ENTERPRISE V6.0 SP2 (64-BIT) .................... 177 

TARGET NODE 5: MICROSOFT WINDOWS XP PROFESSIONAL V5.1 SP3 (32-BIT)..................... 181 

TARGET NODE 6:. LINUX UBUNTU DESKTOP V10.10 (64-BIT KERNEL V2.6.35) ...................... 183


viii 

TARGET NODE 7: CENTOS V5.5 (64-BIT RED HAT BASE KERNEL V2.6.18)............................ 186 

TARGET NODE 8: FREEBSD V8.1 (64-BIT).............................................................................. 189 

TARGET NODE 9: ORACLE SOLARIS 11 EXPRESS V5.11 (64-BIT) ............................................ 191 

RESEARCH NODE 1: LINUX BACKTRACK V4 R2 (32-BIT UBUNTU BASE KERNEL V 2.6.35.8) .. 193 

RESEARCH NODE 2: LINUX UBUNTU DESKTOP V10.10 (32-BIT KERNEL V2.6.35).................... 194 

RESEARCH NODE 3: LINUX UBUNTU DESKTOP V10.10 (32-BIT KERNEL V2.6.32).................... 196 

ANNOTATED BIBLIOGRAPHY .......................................................................................... 198


ix 

List of Figures 

Figure 1. Dual-stack Architecture and Operation......................................................................... 28 

Figure 2. 6to4 Transition Mechanism Architecture and Operation .............................................. 31 

Figure 3. Tunnel-Broker Transition Mechanism Architecture and Operation ............................. 32 

Figure 4. ISATAP Transition Mechanism Architecture and Operation ....................................... 33 

Figure 5. Teredo Transition Mechanism Architecture and Operation.......................................... 35 

Figure 6. Active Research Process Model .................................................................................... 71 

Figure 7. Action Planning Process Tree ....................................................................................... 80 

Figure 8. IPv6 Transition Mechanism State Determination in Win, Linux, BSD, and UNIX ... 125 

Figure 9. IPv6 Transition Mechanism Detection in a Network Trace........................................ 126 

Figure 10. Physical Source Node Determination from a Link-Local Address........................... 129 

Figure 11. Physical Source Node Determination from a 6to4 Address...................................... 129 

Figure 12. Physical Source Node Determination from a Teredo Address.................................. 130 

Figure 13. Physical Source Node Determination from a ISATAP Address ............................... 130 

Figure 14. Physical Source Node Determination from a Tunnel-Broker Address ..................... 130


x 

List of Tables 

Table 1. Comparison of Digital Forensic Framework Processes.................................................. 10 

Table 2. IPv6 Scoped Architecture ............................................................................................... 24 

Table 3. Tunnel Header Encapsulation Scheme (Gilligan & Nordmark, 2000)........................... 30 

Table 4. Teredo Addressing Scheme ............................................................................................ 34 

Table 5. SIIT ICMP Message Translation .................................................................................... 37 

Table 6. SIIT ICMP Error Translation.......................................................................................... 37 

Table 7. SIIT IPv4 to IPv6 Header Translation ............................................................................ 38 

Table 8. SIIT IPv6 to IPv4 Header Translation ............................................................................ 38 

Table 9. 6to4 Relay Application Traffic Observed by Savola (2005) .......................................... 43 

Table 10. Covert Channels in IP Communications....................................................................... 61 

Table 11. Research Nodes, Target Nodes, and Tools Used in the Study ..................................... 74 

Table 12. Primary Research Problem and Sub-Problems............................................................. 78 

Table 13. Research Assumptions.................................................................................................. 79 

Table 14. Sample Data Matrix...................................................................................................... 84 

Table 15. Employed Reconnaissance Tools ................................................................................. 87 

Table 16. Properties of Assigned IPv6 Addresses........................................................................ 88 

Table 17. IPv6 Address Enumeration for the Base OS from Outside the Network...................... 90 

Table 18. IPv6 Address Enumeration for the Base OS from Inside the Network ........................ 91 

Table 19. IPv6 Address Enumeration for IPv6 Enabled OS from Outside the Network.............. 93 

Table 20. IPv6 Address Enumeration for IPv6 Enabled OS from Inside the Network ................ 94 

Table 21. IPv6 Service and Port Enumeration for the Base OS from Outside the Network ........ 96 

Table 22. IPv6 Service and Port Enumeration for Base OS from Inside the Network................. 97


xi 

Table 23. IPv6 Service and Port Enumeration for IPv6 OS from Outside the Network .............. 98 

Table 24. IPv6 Service and Port Enumeration for IPv6 Enabled OS from Inside the Network... 99 

Table 25. Employed Exploitation Tools and Techniques........................................................... 101 

Table 26. IPv6 Address Auto-Configuration from Outside the Network................................... 102 

Table 27. IPv6 Address Auto-Configuration from Inside the Network...................................... 103 

Table 28. IPv6 Communication with a Rogue Node from Outside the Network....................... 104 

Table 29. IPv6 Communication with a Rogue Node from Inside the Network.......................... 104 

Table 30. Employed Reinforcement Tools and Techniques....................................................... 106 

Table 31. Source Address Obfuscation using IPv6 Privacy Extensions..................................... 107 

Table 32. Source Address Obfuscation in a Two-Way Channel using IPv6 Router Redirects.. 108 

Table 33. Data Obfuscation in a Two-Way Channel using IPv6 Fragments.............................. 109 

Table 34. Destination Address Obfuscation in a Two-Way Channel using IPv6 Multicast....... 109 

Table 35. Employed Consolidation Tools and Techniques ........................................................ 111 

Table 36. Persistent IPv6 Backdoor............................................................................................ 111 

Table 37. IPv6 Transition Mechanism Address Correlation Elements....................................... 127 

Table 38. IPv6 Transition Mechanism Traffic Classification Scheme....................................... 128 

Table B1. Commands Used to Extract the Operating System Data ........................................... 155 

Table B2. Commands Used to Setup the IPv6 Tunnel Client..................................................... 155 

Table B3. Commands Used to Setup Teredo/Miredo................................................................. 156 

Table B4. Commands Used to Setup ISATAP ........................................................................... 158 

Table B5. Commands Used to Setup Privacy Extensions .......................................................... 160 

Table B6. Commands Used to Setup Netcat............................................................................... 161 

Table B7. Configured IPv6 Addresses........................................................................................ 161


1 

Chapter 1 – Introduction 

Thesis Statement 

Because the existence and nature of internet protocol version six (IPv6) traffic within 

traditional internet protocol version four (IPv4) networks has been overlooked by network 

forensic analysts, investigators, and researchers, covert IPv6 based attack vectors will become 

more common as attackers recognize the opportunity to exploit an unmonitored and unguarded 

path into the network. 

Problem Statement 

Network forensic analysts and investigators rely on a well defined methodology to 

determine the nature of IPv4 packet flows within a network; however, there is less understanding 

of IPv6 traffic that may also be traversing these networks. Security implications of the IPv6 

transition has been researched by Caicedo, Joshi, & Tuladhar (2009), Warfield (2003), Zagar, 

Grgic, & Rimac-Drlje (2007) and others; however, only Nikkel (2007) has presented a basic 

investigation framework for IPv6 networks and no academic research has been done to 

determine the nature of the traffic. The unfamiliar IPv6 domain combined with the fusion of the 

new protocol and common devices creates an opportunity for attackers to develop effective 

attacks that requires new techniques and considerations when analyzing network traffic in 

forensic investigations. This study developed a proposed methodology for properly analyzing 

and investigating IPv6 traffic within transitional networks to help forensic analysts and 

investigators recognize IPv6 based attack vectors. 

To accomplish this goal, the study addressed the question: What is the nature of IPv6 

traffic that may be traversing traditional IPv4 networks? In answering this questions, the


2 

following sub-questions were structured around the five phases of a network attack as outlined 

by Bejtlich (2004): 

Reconnaissance 

• What methods can be used to enumerate IPv6 addresses and services in a transitional 

network? 

• What is the context of IPv6 traffic produced by nodes in an IPv4 network? 

Exploitation 

• What methods can be used to attack the network topography in a transitional network? 

• What are the characteristics of malicious and suspicious traffic that traverse IPv4 

networks using the IPv6 protocol? 

Reinforcement 

• What methods can be used to obfuscate an attack in a transitional network and how 

could the true source be determined? 

Consolidation 

• What methods can be used to create a persistent commutations channel in a 

transitional network and how could that channel be detected? 

Pillage 

• What additional risks should be considered in a transitional network? 

Background and Significance of the Study 

IPv6 traffic will become more common over time and will coexist with IPv4 on the same 

networks. Most operating systems support IPv6 in their default states and solution providers have 

begun to roll out IPv6 based applications that are running on machines within traditional 

networks using transition methods to traverse the IPv4 networks.


3 

While the new protocol has quietly penetrated the network environment, the academic 

and business communities have neglected research and development in this area. Despite 

consumer device support, network security vendors have been slow to support IPv6 in their 

products because low utilization rates make it difficult to realize a return on investment. 

Researchers have addressed general security in IPv6; however, they have neglected a technical 

discussion of the context and nature of the traffic. Attackers will exploit attack vectors that offer 

the greatest chance of success with the least chance of being discovered. The IPv6 protocol is 

available and can covertly traverse the network which opens up an opportunity that will lead to 

growth in IPv6 based attacks. 

Research Objective 

The primary objective of this study was to develop a practical methodology for 

investigating and analyzing transitional networks. To accomplish this goal, the study employed a 

qualitative method based on the active research methodology to evaluate the IPv6 transition 

mechanisms, operating systems, and attack vectors. First, the literature review enumerated 

current research in digital forensics, IPv6 transition mechanisms, operating system support, and 

IPv6 vulnerabilities. Second, a virtual lab environment was created and testing procedures were 

designed to answer the research sub-problems. Third, the procedures were implemented while 

the researcher recorded operating system states, tool output, and other observations. Finally, the 

discoveries and results were analyzed and distilled into three outputs that supported the proposed 

investigative methodology. First, the implications of IPv6 transition mechanisms on the digital 

forensics discipline were outlined. Second, a summary of the behaviors of each transition 

mechanism and operating system in the study was presented from the perspective of a forensic


4 

investigator or investigator. Finally, a methodology was proposed for the forensic analysis of 

IPv6 traffic in a transitional network. 

Delimitations and Limitations 

This study did not address networks where the IPv6 protocol was a planned part of the 

infrastructure. Organizations that plan and implement IPv6 would likely implement security 

controls and have an enhanced understanding of the context of traffic within the network. 

Therefore, the study did not address hardware transition mechanisms and IPv6 hardware nodes 

that required a planned implementation. 

This study also did not serve as an analysis of IPv6 attacks or highlight new methods of 

exploiting IPv6 clients. In order for an investigator or analyst to identify suspicious or malicious 

traffic, they must first understand the context of normal traffic within the network. The study 

analyzed selected attacks to provide a better understanding of potential malicious packets; 

however, the focus of the study was on providing a basis for identifying unknown or suspicious 

traffic for further analysis. 

Additionally, this study was not an analysis of tools used in forensic analysis or the 

performance factors involved with network monitoring. Network monitoring tools provide 

common functions such as protocol analysis, packet captures and injections. Tools were selected 

for use in the study; however, the focus was on the context of the packets. 

Time and resource limitations controlled the scope of the study by limiting the transition 

mechanisms and source nodes that were analyzed. The study focused on the most common nodes 

and transition mechanisms that were freely available for use in the testing environment.


5 

Chapter 2 – Review of Literature and Research 

At the most basic level, forensics requires that investigators establish who, what, where, 

when, why, and how an event occurred and then analysts produce legally admissible evidence 

that proves to the jury that the required components of the statute has been violated. To 

accomplish the first goal, an investigator must understand the technology and methods used by 

the perpetrators to commit the crime. Current research into IPv6 technology and attack vectors is 

adequate to implement and operate the technology; however, it does not address the unique 

needs and considerations for investigating and analyzing criminal events in distributed 

environments and IPv6 networks. To accomplish the second goal, the forensic techniques used 

must be an established discipline formally founded in the academic research. Network forensics 

is a new science with basic procedural models focused on physical nodes; however, the research 

does not adequately address the complex evidence collection, analysis, and presentation 

requirements of IPv6 network investigations. The need to supplement this research will become 

more critical as IPv6 becomes more widely implemented and a common mechanism in criminal 

acts. 

Digital Forensics Discipline 

The word forensics originates from the Latin term forensis and is the “scientific test or 

technique used in the detection of crime” (Bishop, et al., 2008 p3). Digital forensics at a basic 

level comprises a sub-discipline of forensics that applies tests and techniques to devices that 

produce digital or binary data in order to detect and prosecute criminal offenses. Within this 

discipline, researches have focused on defining forensic models, evidence collection, handling 

procedures, and processes for digital investigations.


6 

Digital forensic models. 

A variety of research efforts have defined unique frameworks for use in the digital 

forensics discipline. Despite having similar objectives, many of the proposed frameworks 

presented the process from a legal, scientific, or practitioner perspective that inadequately 

addressed the other views. Developing a forensic framework for addressing digital crime will 

ultimately serve to create a comprehensive process to prosecute crime. 

Leong (2006) proposed that a digital forensic framework should be based on the 

principles of reconnaissance, reliability, and relevancy; however, the lack of a single unifying 

model negates these tenants in practice. In their research, Carr, Gunsch, and Reith (2002), 

Bishop, et al. (2008), Cohen (2009), Ciardhuáin (2004), and Leong found that the lack of 

unification is due to the ad-hoc application of research and practices by disconnected 

participants. Bishop, et al. illustrated the different procedural models that have been introduced 

by practitioners who focused on evidence collection, computer scientists who focused on tools 

and techniques, and the legal community who focused on analysis and presentation. The lack of 

communication between these groups has prevented a single unifying model from being 

developed. For example, a large percentage of digital cases handled by practitioners in the law 

enforcement community involved child pornography which does not require the sophisticated 

tools and analysis techniques that make up the research focus of many computer scientists 

(Littlefield, 2007, June as cited by Bishop, et al. 2008). 

Advancing the digital forensic sciences requires the creation of a unifying framework that 

integrates components from all views and consists of the best ideas from both computer science 

and the legal community. Carr, et al (2002) argued that frameworks are necessary to help 

investigators apply consistent and well defined procedures. Bishop, et al. (2008) added that a


7 

framework must defend the validity of the results and improve the accuracy of the data to a high 

standard that is representative of a scientific discipline. Currently, there are no standard tools and 

techniques that are used to prove digital cases in a court of law. Additionally, there is a gap 

between technology and the judicial process that makes decision making difficult for judges and 

juries who often do not understand the underlying technology involved in a case (Bishop, et al., 

2008; Leong, 2006). For example, in 2007, a Connecticut teacher was convicted of contributing 

to the delinquency of a minor after a spyware program displayed pornography to one of the 

students. The conviction was later overturned; however, this case highlights the knowledge 

issues faced in digital forensics (Cowan, 2007, Feb 14 as cited by Bishop, et al., 2008). 

A common set of six digital forensic frameworks are represented in the literature. The 

incident response framework focused on integrating the forensic process into digital defenses and 

is most relevant to organizations that have existing security monitoring procedures (Mandia & 

Prosise, 2001 as cited by Carr, et al. 2002). The Department of Justice (DOJ) defined a 

framework that is oriented towards practitioners and investigators; however, Shin (2008) argued 

that the analysis process is poorly defined ("Electronic crime scene investigation: A guide for 

first responders," 2001 as cited by Carr, et al. 2002). The Digital Forensics Research Workshop 

created a framework based on input from academia and the law enforcement community that 

created a reference for work for the field (Gary Palmer, 2001 as cited by Carr, et al. 2002). Lee, 

Palmbach, and Miller (as cited by Ciardhuáin, 2004) defined a scientific framework that utilized 

logic trees to create a systematic and methodological investigation model. Casey (as cited by 

Ciardhuáin, 2004) defined a model that can be applied to networks and is focused on 

practitioners. Carrier and Spafford (2003) developed a framework to link the physical


8 

investigative process to the digital world. The procedural steps and language used in each of 

these models is outlined in Appendix A, Digital Forensic Frameworks. 

Carr, et al. (2002), Cohen (2009), Ciardhuáin (2004), and Shin (2008) presented 

comprehensive digital forensic frameworks that built upon the prior research efforts. Carr, et al. 

developed a comprehensive framework that outlined the process from identification of the crime 

through the return of evidence to its owner after a case has concluded. Cohen focused on creating 

a cost effective forensic model that could be employed by prosecutors. Ciardhuáin added 

information flows to the framework that helped to establish the chain of custody in a case. Shin 

created a comprehensive and detailed framework that addressed the analysis process more 

thoroughly than in his prior work. The procedural steps and language used in each of these 

models is outlined in Appendix A, Digital Forensic Frameworks. 

The combination and comparison of these ten frameworks enumerated the strengths and 

weaknesses of each model and provided a unified research platform for forensic frameworks. 

This combined framework can be summarized with the following process steps: 

1. Identify the legal issues and develop an awareness of when a crime has been 

committed. 

2. Provide ongoing training and appropriate tools for identifying crime and conducting 

an investigation. 

3. Seek authorization from superiors for any targeted investigations. 

4. Create a hypothesis for what events lead up the crime identified. 

5. Plan an investigation that identifies steps that need to be taken to prove the 

hypothesis. 

6. Notify stakeholders and other users impacted by the investigation when possible.


9 

7. Search for evidence. 

8. Collect the evidence. 

9. Preserve, transport, copy, and store the evidence for analysis. 

10. Examine and verify the integrity and validity of the evidence in relation to the 

identified events and internal data relationships. 

11. Classify and separate the evidence into individual components. 

12. Prioritize the evidence by identifying the most compelling components. 

13. Reconstruct the events and link the physical data to the milestones in the event 

history. 

14. Consult experts and other specialists when necessary. 

15. Analyze and document the conclusions. 

16. Verify the availability of resources to advance the investigation or case. 

17. Verify if the schedule and event history is feasible given the facts of the case. 

18. Decide whether to move forward, look for more evidence, or drop the case. 

19. Profile and summon suspects. 

20. Present the evidence and case to the prosecutor and court. 

21. Prove the case and challenge any presented defenses. 

22. Return the evidence to the owner and restore affected systems to their previous states. 

23. Disseminate the knowledge and improve criminal profiles to aid in future cases. 

Table 1 illustrates which of the ten frameworks presented in the document explicitly contain 

elements of the twenty-three common processes.


10 

Table 1. Comparison of Digital Forensic Framework Processes 

Co- Ciard- Incident DFR- Carr- 

Process Carr hen huáin Shin Response DOJ WS ier Lee Casey 

Identify legal issue X X X X X 

Provide training and tools X X X X 

Seek authorization 

X 

Create hypothesis X X 

Plan investigation X X X 

Notify stakeholders 

X 

Search for evidence X X X X X 

Collect evidence X X X X X X X 

Preserve evidence X X X X X X X 

Examine and verify evidence X X X X X X X X 

Classify and individualize X X X 

Prioritize evidence 

X 

Reconstruct events X X X 

Consult external experts 

X 

Analyze and document X X X X X X X X 

Verify available resources 

X 

Determine schedule 

X 

Decide on course of action 

X 

Profile and summon suspects 

X 

Presentation and reporting X X X X X X X 

Proof and defense of case 

X 

Restore and recovery X X 

Dissemination of knowledge X X 

The available research presented a fractured and ad-hoc approach to forensic frameworks 

for digital investigations despite the importance of unifying under a single comprehensive model. 

By merging a number of frameworks into one procedural model, we begin to see an integration 

of ideas that could be used by both academia and the legal community. While these approaches 

serve forensics in general, they do not adequately address the complex nature and unique 

requirements of network forensic investigations. The processes that are most impacted by this


11 

complexity are in the search, collection, handling, analysis of evidence and the reconstruction of 

events. Additionally, the planning of the investigation, involvement of experts, training, and 

presentation will be impacted by the increase in resource requirements needed to support the 

case. 

Network data as evidence. 

Sommer (1999) conducted early research into the implications of using network data as 

evidence. This research presented an example case, the problems associated with using network 

data as evidence, the questions of admissibility and weight of network based evidence, and 

suggestions for successfully using network data as evidence in a case. Sommer concluded that 

the key to successful prosecution is to have streams of corroborating evidence from multiple 

sources. Evidence can be derived from network data, logs, direct testimony, and documentary 

evidence that supports the timeline and facts in a case. 

To illustrate this point, Sommer (1999) presented a criminal case where a hacker gained 

unauthorized access to classified United States Air Force (USAF) documents. To prove their 

case, the prosecution used intrusion detection system (IDS) network data, chat logs with other 

hackers, phone logs showing calls placed to servers, files discovered on the defendants seized 

hard drive, and logs from the targeted computers. This evidence was then tied together into an 

event timeline to present the series of events that predicated the crime. 

Sommer (1999) identified a number of problems that could arise with network based 

evidence that the defense could call into question. First, the data may not contain enough details 

to correlate with actual events. Second, the evidence may not exist for the specific time period in 

question or elements may be missing. Third, the data could have been compromised or altered 

during or after the crime. Finally, the analysis may lead to misleading results.


12 

These factors affect the admissibility and weight of the evidence that determine whether 

the prosecution can present the evidence to the court (Sommer, 1999). Evidence admissibility 

derives from the rules of the court. Although, each jurisdiction and court may have their own 

rules, the following types of evidence are generally allowed: real physical evidence, eyewitness 

testimony, documentary evidence, expert opinions, and derived evidence created from other 

sources (Sommer, 1999). Technical evidence admissibility is often based on the precedent set in 

Daubert v. Merrell Dow Pharmaceuticals Inc ("Daubert v. Merrell Dow Pharmaceuticals Inc.," 

1993 as cited by Sommer, 1999). This case defined four tests used to determine whether 

scientific evidence could be admissible in a court of law. First, the technique or theory must have 

been tested. Second, the error rate of the technique must be known. Third, the technique must 

have been published in a peer reviewed journal. Finally, the technique must have gained wide 

acceptance in the field. 

The weight derives from how understandable and convincing the evidence is when 

presented to the court. It is affected by the context and handling processes of the evidence. The 

evidence must be authentic and linked to the circumstances in question. It must be accurate and 

complete to tell a full and truthful story. The chain of custody must have been maintained and the 

evidence must be transferable to third parties as part of the discovery process. 

Sommer (1999) presented a number of best practices for network based evidence. 

Although network data is documentary evidence, Sommer recommended supporting that 

evidence with both expert testimony and derived evidence. Time stamps should be synchronized 

between different data sources to ensure timeline accuracy. If possible, evidence and live 

network data should be protected from compromise using hashes or other encryption techniques. 

Raw data should accompany the derived data and the chain of custody should be maintained.


13 

Sommer (1999) and Daubert v. Merrell Dow Pharmaceuticals Inc ("Daubert v. Merrell 

Dow Pharmaceuticals Inc.," 1993) both provided suggestions for effectively collecting and 

handling network based evidence. The prosecutor’s objective should be to present the data with 

the aid of expert testimony and derived presentations and then corroborate the facts with other 

evidence. This research presented some of the considerations for IPv6 evidence that could 

present a problem for investigators. The lack of research into IPv6 investigation techniques 

decreases the admissibility of the evidence under the Daubert standard which requires 

evidentiary techniques to be based on established academic disciplines. 

Digital evidence handling. 

The procedural standards and admissibility issues surrounding digital evidence collection, 

storage, analysis, and presentation are well represented in the literature. Although, the standards 

for processing digital evidence follows a fairly standard structure, jurisdictional differences in 

legal precedent and statutes create challenges in formulating a solid procedural framework for 

digital evidence processing. 

Digital evidence is relevant data used to prove that a crime or event has taken place (Lan, 

et al., 2005). The research by Lan, Lin, Lin, and Wu (2005) identified the characteristics of 

digital evidence as being technical, changeable, invisible, and flexible. It further identified three 

classifications of digital evidence. Document evidence is content that can be printed or viewed 

like document, text, and log files. Material evidence is content that can be read when executed by 

another application like executable (EXE) or Moving Picture Experts Group Layer-3 (MP3) 

files. Other evidence is content that cannot be printed or viewed like compressed (ZIP) and 

dynamic link library (DLL) files.


14 

Digital evidence collection and processing procedures do not follow an established 

standard; although, different applications often have similar components. Lan, et al. (2005) 

described the Federal Bureau of investigation’s (FBI) Regional Computer Forensics Laboratory 

digital evidence collection process to include surveying and maintain the site, search and seizure, 

and evidence packing and delivery. 

In their research, Lan, et al. (2005) proposed a similar operating procedure for digital 

evidence collection and processing. The objective was to maintain the legal admissibility of 

digital evidence by: maintaining the legal basis for actions leading up to the seizure, collecting 

evidence as soon as possible, maintaining the chain of custody, ensuring proper supervision in 

the process, and restricting access to the evidence. Three digital evidence handling process were 

proposed. First, evidence collection followed the FBI’s process and involved site survey and 

maintenance, search and seizure, and packing and delivery. Second the analysis process involved 

backup, inspection, and maintaining the chain of custody. Finally, the forensics process involved 

identification, recognition and reporting. 

Kerr’s (2005, Jan) expands the digital evidence handling process by adding a description 

of the courtroom processes used by a prosecutor. In a criminal case, the prosecutor will first call 

the victim to testify about the crime. Other parties will be called to establish their link in the 

crime if the suspect used other computers to access the victim’s machine. Then, the forensic 

analyst will present the evidence to link the crime to the suspect. Finally, the investigator will 

testify that the computer was recovered in the possession of the suspect. This process provides 

the necessary elements to establish that a crime has been committed, define the actions used to 

commit the crime, and link the suspect to the actions.


15 

The cyber tool on-line search for evidence (CTOS) project was a European Union funded 

research project designed to establish a common architecture, processes, and tools for digital 

investigations (Broucek & Turner, 2004). Broucek and Turner (2004) described the CTOS 

project in their research which follows similar processes to those outlined by Lan, et al. and Kerr. 

The digital evidence processing phases included preparation, running, assessment, investigation, 

and learning. The focus of the overall process was on collecting evidence that is legally 

admissible in a court of law. 

To produce legally admissible evidence, investigations involving digital evidence require 

a different approach than those involving only physical evidence. Kerr (2005, Jan) illustrated 

these differences in a comparison of a physical and virtual bank robbery. In a physical bank 

robbery, the investigator interviews eye witnesses, attempts to identify a suspect using these 

accounts and other physical evidence at the scene, and collects additional physical evidence from 

the premises to support the prosecution of the identified suspects. In a digital bank robbery there 

is no eye witness to the crime. The evidence that is available to lead the investigator to a suspect 

often involves a chain of innocent victims. It is possible that the suspect is a victim of a third 

party who launched the crime from their machine. 

The challenges of proving possession in cases involving digital evidence is analyzed in 

the research by Losavio (2005). United States case law has established that possession in a 

digital case can be established even if the data is stored on a remote machine that is not 

physically accessible to the suspect. To prove a case, the forensic analyst must establish 

possession, overcome possible defenses, and provide enough weight to meet the burden of proof 

in the case. Losavio described some of the defenses used by defense attorneys to create 

reasonable doubt by associating actions with other parties. For example, a suspect could claim


16 

that another perpetrator accessed their unsecure wireless access point to launch attacks without 

their knowledge. A suspect in a child pornography possession case could claim the files in 

question were stored on their computer without their knowledge because a peer-to-peer file 

sharing program was left open. The most common defense in digital cases involves claiming that 

a Trojan Horse or other malicious application perpetrated the offences without the suspects 

knowledge (Losavio, 2005). While these defenses present some problems for prosecutors, the 

extent of evidence required to establish possession often comes down to the openness of the 

systems involved. 

Losavio (2005) further expand some of the issues that may arise in digital cases. Losavio 

identified that the probability of access, alteration, or spoofing may cause a judge to require a 

greater foundation in the evidence to prove possession. The source internet protocol (IP) address 

or account used in the crime does not necessarily mean the owner in question committed the 

crime. The evidence necessary to link the suspect to the actions involving the IP or account may 

be substantial and, in the case of network evidence, may need to be recovered immediately after 

a crime to be considered valid. 

Kerr, (2005, Jan) addressed some of the legal implications of digital evidence in the 

search and seizure process. The Fourth Amendment of the constitution prohibits unreasonable 

searches and seizures. In physical cases a law enforcement officer cannot enter a private space 

without cause; however, this legal standard is not as clear in cases involving digital evidence. 

Kerr, questioned whether collecting digital evidence from third party source violates this legal 

standard as well as privacy laws. Additionally, Kerr suggested that seizing a computer to 

investigate the data contained inside may be deemed excessive. It parallels seizing an entire 

house to inspect the contents of one room for evidence. Traditional warrants for evidence


17 

collection requires an explicit declaration of the specific evidence that is being search for; 

however, this is not possible in a digital investigation. Digital evidence can exist in many forms 

and located in any digital storage location within the physical computer. It is often impossible to 

know what will be found until the analysis is complete. 

Digital evidence processes and issues identified in the literature by Broucek and Turner 

(2004), Kerr (2005, Jan), Lan, et al. (2005), and Losavio (2005) are focused on investigations 

where a computer is physically analyzed by a forensic examiner. Network based forensic 

investigations present unique challenges because the evidence may involve complex arrays of 

actions that take place on many disbursed machines. Additionally, network forensic data analysis 

is complex and new issues arise from its interpretation. Because it is a subset of digital evidence, 

network data analysis processes can follow the general procedural framework laid out in the 

current literature; however, further research is needed to develop handling procedures specific to 

its unique characteristics and challenges. 

Digital investigations. 

The digital forensic frameworks developed by practitioners and the law enforcement 

community are often applied to processes used in real investigations to verify their applicability. 

Three have been selected for presentation to describe the practical steps used by investigators in 

digital cases. The Fraud Examiners Manual ("Fraud Examiners Manual," 2008) provided 

characteristics, legal precedent, and investigation processes for practitioners investigating digital 

crime and fraud. Schroeder (2005) described the digital investigation that lead up to the case 

United States vs. Gorshkov that involved multiple computer intrusion and fraud violations. 

Carrier and Spafford (2003) applied their forensic model to a typical child pornography case.


18 

The Fraud Examiners Manual ("Fraud Examiners Manual," 2008) presented procedures 

and guidelines for a hypothetical computer seizure case to ensure evidentiary requirements are 

met in criminal cases. After obtaining warrants for specific computers and hardware, the 

investigator verified that adequate resources are available to help with the search and seizure, 

including support personnel that can identify the components listed in the warrant. After arriving 

on the scene, only the individuals involved in the investigation were allowed in the area where 

the computers were located. The image on the screen and the layout of the computer and all the 

cables were photographed. The computer was not moved and nothing was typed on the 

keyboard. The state of all computers, screen images, cables, and locations were documented. 

Devices were turned off and disconnected from the wall outlet before peripheral cables were 

labeled and removed. Media, documents, and manuals covered by the warrant were seized. The 

collected media, computers, peripherals, and other evidence was sealed and labeled in paper, 

cardboard, or static proof containers for transportation. Finally, all evidence was inventoried and 

transported to the evidence storage location. 

The Fraud Examiners Manual ("Fraud Examiners Manual," 2008) also outlined some 

basic considerations for the analysis of digital evidence. First, the proper handling and recording 

of digital evidence is critical to avoid liability and the exclusion of damaged evidence. Second, 

the examiner has a number of considerations when analyzing the digital evidence. Analysis 

should be performed on copies of the evidence to prevent source corruption. The drives should 

be scanned for viruses to avoid an accusation that the examiner corrupted the drive. A keyword 

search of the drive can help locate specific items and reduce the argument that the search was 

overly broad. Finally, the examiner should search for hidden and encrypted files and investigate 

the file slack space for any additional evidence.


19 

Schroeder (2005) outlined the events and investigative steps in the case United States vs. 

Gorshkov. Ivanov and Gorshkov were Russian citizens lured to the United States by the prospect 

of a job offer by the Seattle based company Invita. They described their hacking skills and 

previous exploits to an undercover FBI agent and demonstrated their skills on a honeypot setup 

at Invita. Gorshkov admitted to hacking servers at several banks and claimed he had a small team 

of programmers working for him in Russia and could modify programs in any language. After 

the meeting, Ivanov and Gorshkov were arrested and the FBI copied the contents of their 

computers in Russia to a server in the US using the passwords they exposed when demonstrating 

their hacking skills. A warrant was then obtained to view the evidence contained in the 

downloaded copies. 

The forensic analysis of the downloaded copies of Ivanov and Gorshkov computers lead 

to evidence of a number of illegal activities presented in the case (Schroeder, 2005). The 

investigators found a practical extraction and report language (PERL) program that automated 

the signup process for e-mail and PayPal accounts. With the help of administrators at PayPal, 

they discovered thousands of accounts created by the program. These were linked to the 

activities to two IP addresses that identified a number of illegal transfers and withdrawals that 

cost PayPal over $800,000 in charge backs. Ivanov and Gorshkov were able to transfer money 

from PayPal accounts held by legitimate customers to their fraudulently created accounts by 

sending e-mails to users that appeared to be from PayPal but directed the user to the spoofed site 

PayPai.com that was setup to capture user IDs and passwords. They also linked the IPs used in 

setting up the PayPal accounts to multiple computer intrusion and hacking attempts in the United 

States. Some of these attacks were followed by e-mails from Gorshkov offering to reveal his 

techniques for a fee which provided further evidence of extortion.


20 

Carrier and Spafford (2003) applied their proposed procedure model to the investigation 

of child pornography on a suspect’s computer. Prior to seizing the suspect’s computer, a warrant 

is obtained for the residence based on identifying information contained in a parallel 

investigation of a web server discovered to contain child pornography. This included any 

financial records of purchases made with the company that operated the server and logs that 

showed a particular IP that downloaded an illegal file. The physical address of the account that 

held that IP lease at the time of the download is obtained from the Internet Service Provider 

(ISP) and the warrant is requested for that location. 

The FBI executed the warrant to seize the computer in question. First, the suspect is 

separated from the computer and detained. Photos are taken of the scene including the layout of 

the computer, the connection of any cables, and anything displayed on the screen. The 

investigators search for other evidence like storage media and documents related to the case. The 

keyboard and mouse are dusted for fingerprints and the hard drives are removed from the seized 

machines. The hard drives are connected to a portable Linux machine where an MD5 hash value 

is calculated to prove integrity of the data and a then a forensic copy is created. The evidence is 

packaged, inventoried, and sent to the evidence storage while the forensic copies are sent to the 

forensic lab for analysis. 

In this case, the analysis of the forensic copies of the drive is narrowly focused on 

searching for illegal images. Forensic tools are used that search for images, analyze the web 

cache, and look for any encrypted files. Passwords were analyzed to determine if they were easy 

to guess and the analyst identified any evidence of a computer compromise that could indicate a 

3 rd party committed the offense. A detailed report is created that outlines the illegal images 

found, the creation and access dates of the files in question, the timeline of events, and the


21 

linkage to the logs contained on the web server that was previously seized. Finally, the case is 

presented to the court and the illegal images are added to the hash database to enhance future 

searches for illegal files. 

The computer seizure case described in the Fraud Examiners Manual (2008), the hacking 

case presented by Schroeder (2005), and the child pornography case presented by Carrier and 

Spafford (2003) follow similar overall processes that can be effectively represented in a 

universal digital forensic framework; however, their differences require unique approaches to 

meet the objectives of the case. While the previously discussed frameworks could be used as a 

general guide for the digital forensics discipline, specific applications necessary to create a 

scientific basis for individual situations is needed. The ideal framework would address the 

overall process in terms of the legal process while employing flexible components that adapt to 

the needs of each case. IPv6 forensic analysis would be one possible component that could be 

present in the collection and analysis stages of the overall digital forensic framework. 

IPv6 Forensic Analysis and Investigation 

There is limited research into the analysis and investigation of IPv6 traffic in a network. 

Nikkel (2007) presented a holistic and basic discussion of investigating IPv6 networks. Nikkel’s 

work provides a good introduction for investigators focused on addressing the gap in knowledge 

that exists when non-technical investigators are confronted with an IPv6 network investigation. 

Network security monitoring research that is used in intrusion detection and response systems is 

well defined for IPv4 traffic; however, there is little research for IPv6 traffic. Tseng, Chen, and 

Laih (2006), Lee, Shin, Choi, and Son (2007), and Huang, Zhang, and Yao (2009) proposed new 

intrusion detection engines for IPv6 traffic. Phang, Lee, and Lim (2008) proposed an improved 

IPv6 packet sniffer. While this research does identify possible considerations for IPv6 analysis, it


22 

does not present a detailed framework for determining the nature of IPv6 traffic in forensic 

investigations. 

The IPv6 protocol was defined in the 1990s to address the shortcomings of the IPv4 

protocol (Bruce J Nikkel, 2007 p2). Originally, IPv6 was designed to address the pending 

exhaustion of the public IPv4 address space, improve the quality of services within the network, 

and enhance security. Nikkel (2007) concluded that the introduction of network address 

translation (NAT), IPv4 application layer security, and high-speed internet access eliminated 

many IPv4 issues and slowed the implementation of IPv6. Nikkel predicted that mobile devices 

and operating system integration will renew interest in IPv6 and require forensic investigators to 

have a basic understanding of the protocol to successfully conduct investigations. 

Investigators and forensic analysts must be able to identify the characteristics of an IPv6 

address when conducting an investigation. Nikkel (2007), Conta and Deering (1998), and others 

provide descriptions of the IPv6 address structure. An IPv4 address that is used to identify nodes 

on a network is 32 bits while an IPv6 address is 128 bits. IPv4 addresses are represented by four 

groups of decimal numbers separated by a period that ranges from 0 to 255. For example, 

123.123.123.255 is an IPv4 address. IPv6 addresses are represented in eight groups of 

hexadecimal numbers separated by a colon that range from 0 to FFFF. For example, 

2001:0000:0000:0000:0000:0000:0000:ABCD is an IPv6 address. IPv6 addresses can also be 

compacted by replacing the internal zeros with a double colon character. For example, the 

previous address could be represented as 2001::ABCD. Additionally, Nikkel pointed out that 

Media Access Control (MAC) addresses and IPv4 addresses may also be represented within the 

IPv6 address in some implementations.


23 

Understanding the different IPv6 address types is important to identifying the source and 

flow of traffic. Nikkel (2007) and Conta and Deering (1998) identified three types of IPv6 

address destinations that defined how packets are processed by network devices. A packet sent to 

a unicast IP address will be delivered to a single destination. Anycast addresses allow a packet to 

be sent to a group of destinations and delivered to the one that is the closest to the source. 

Packets sent to multicast addresses are delivered to all destinations defined for the group. For 

example, sending a packet to the multicast address FF02::1 will send the packet to all nodes on 

the network and address FF02::2 will send the packets to all routers. The list of reserved unicast, 

anycast, and multicast addresses is maintained by the Internet Assigned Numbers Authority 

(IANA). 

Nikkel (2007) and Deering, Haberman, Jinmei, Nordmark, and Zill (2005) identified the 

IPv6 address scope as a method of controlling the routing of packets on a network. Each address 

is defined by IANA to have a link-local, site-local, or global scope except for the loopback 

address of 0::1 and the unspecified address of 0::0. These two special addresses do not have a 

scope and cannot be assigned to a device. A link-local scoped address begins with FE8 and is 

designed to pass packets from one physical device in a network to another. Packets that have 

link-local destination addresses do not get routed so there needs to be a direct path to the 

destination for the packets to be delivered. Site-local scoped addresses begin with FEC and are 

designed to be routed within a single internal network. Devices that are assigned site-local 

addresses can only communicate with other devices within the same site. Global-scoped 

addresses are publically available addresses that often begin with 2001 or 2002 and are routed on 

the Internet. If a device is assigned a globally-scoped address, it can communicate with any other


24 

global IPv6 node located on the Internet. Table 2 illustrates the different scopes defined by an 

IPv6 address. 

Table 2. IPv6 Scoped Architecture 

Scope Identifier Prefix Subnet ID Interface ID 

Link-local 

(10 bits) (54 bits) 

(64 bits) 

FE80::ABCD:ABCD:ABCD:ABCD 

FE8 0 

ABCD:ABCD:ABCD:ABCD 

Site-Local 

(10 bits) (38 bits) (16 bits) (64 bits) 

FEC0::DCBA:ABCD:ABCD:ABCD:ABCD 

Global 

2001:DCBA:ABCD:ABCD:ABCD:ABCD: 

ABCD:ABCD 

Loopback Address 

0:0:0:0:0:0:0:1 

FEC 0 

(x bits) 

2001 

DCBA 

(y bits) 

DCBA 

(127 bits) 

0 


(128-x-y bits) 


:ABCD:ABCD 

(1 bit) 

1 

Unspecified Address 

0:0:0:0:0:0:0:0 

(128 bits) 

0 

Techniques used by forensic analysts and investigators to determine the registrar of IPv4 

addresses will also work in IPv6 investigations. Nikkel (2007) identified IANA as the root 

registrar for all IP addresses, including IPv6. Under IANA, regional registrars assign IP address 

blocks to individual organizations. This includes; ARIN for North America, LACNIC for South 

America, APNIC for Asia and the Pacific, RIPE for Europe, the Middle East, and Central Asia, 

and AFRINIC for Africa. Standard whois lookup queries used with IPv4 addresses can identify 

IP registration information for IPv6 addresses using either the full or compact address notation. 

Additionally, IPv6 addresses may also be contained in standard DNS records with a record type 

of AAAA or as standard MX records for e-mail servers. 

Nikkel (2007) concluded that the forensic analysis of IPv6 traffic is similar to techniques 

used for IPv4; however, certain protocol differences require unique considerations. Forensic 

tools used to capture and analyze packet flows like TCPDUMP and Wireshark already support


25 

IPv6 and many tools are being developed specifically for IPv6 traffic. Nikkel identified log 

analysis as a forensic technique that remains unchanged under IPv6; however, the investigator 

will have to consider both IPv4 and IPv6 address notations in the search for evidence. IPv6 

addresses in the log may be represented in compressed notation or full-length notation. 

Additionally, Nikkel’s research discussed additional risks that should be considered when 

conducting an IPv6 investigation. For example, IPv6 traffic may affect the security of a network 

by bypassing the firewall through a tunneling mechanism and the source or destination of the 

tunnel may be difficult to determine. 

IPv6 forensic analysis is also represented in IDS research. Tseng, Chen, and Laih (2006), 

Lee, Shin, Choi, and Son (2007), and Huang, Zhang, and Yao (2009) contributed research that 

proposed new network intrusion systems for IPv6 traffic and Phang, et al. (2008) proposed a new 

IPv6 protocol analysis tool that provided better performance than the TCPDUMP tool. Lee, et al 

(2007) adapted the existing Internet Engineering Task Force (IETF) standard for IP flow 

information export (IPFIX), to support anomaly detection. IPFIX is a flow based reporting 

standard that is included on most routers and switches to provide summarized reports of network 

data. Lee’s research created new report templates that included source and destination addresses, 

ports, MAC addresses, protocol and internet control message protocol version six (ICMPv6) type 

code to identify possible IPv6 denial of service (DoS) attacks, covert channels, or IPv6 tunnels. 

Tseng, Chen, and Laih (2006) proposed an IPv6 IDS that adapted established Snort IDS 

signatures to create a new signature file. Huang, Zhang, and Yao (2009) proposed an IPv6 IDS 

that combines pattern detection and protocol anomaly detection to identify potential attacks. 

While IDS research may identify some of the analysis techniques needed for a forensic


26 

investigation, the research lacks the details needed to address the specific characteristics of IPv6 

in an investigation. 

The research presented by Nikkel (2007) provided a basic overview of conducting an 

investigation when IPv6 traffic is present in the network. Tseng, Chen, and Laih (2006), Lee, 

Shin, Choi, and Son (2007), and Huang, Zhang, and Yao (2009) began to define analysis 

techniques that can be used in the forensic investigation of an IPv6 network. This research lacks 

details that are necessary to successfully conduct an investigation. For example, Nikkel provided 

a definition of IPv6; however, there is only a cursory consideration for how an investigator or 

analyst should analyze, interpret, and present IPv6 network evidence. Additionally, there is a 

lack of discussion on IPv6 transition mechanisms, sources of traffic, security implications, and 

attack vectors that will impact the forensic analysis of IPv6 traffic in an investigation. 

IPv6 Transition Mechanisms 

Transition mechanisms facilitate communications between IPv4 and IPv6 endpoints. 

Tantayakul, Kamolphiwong, and Angchuan (2008) attributed the need for transition mechanisms 

to the difficulty of converting the wide variety of network architectures to the new protocol; the 

complexity of routing, the domain name system (DNS), and error handling; and the requirement 

that all applications must remain operational during the transition. Yan-ge, Shui-mu, and Junying 

(2009) classified transition methods into IPv4 to IPv6 interconnection, transparent 

interconnection, and IPv6 to IPv4 interconnection while other researchers classified transition 

techniques into dual-stack, tunneling, and protocol translation methods. Dual-stack is a transition 

method that requires a network interface card (NIC) to supports both protocols. Tunneling 

includes the 6to4, Tunnel-Broker, intra site automatic tunnel addressing protocol (ISATAP), and 

Teredo methods. It involves creating a temporary path through an IPv4 network to facilitate IPv6


27 

communications. Protocol translation includes the stateless IP/ICMP translation (SIIT), network 

address translation – protocol translation (NAT-PT), bump in the stack (BIS), bump in the API 

(BIA), Socks64, transport relay translator (TRT), and other gateway based methods. Although 

these transition mechanisms facilitate communications between IPv4 and IPv6 endpoints, their 

application is intended to be a temporary solution until IPv6 becomes the native protocol on the 

network. 

Dual-stack. 

The dual-stack transition mechanism requires that the NIC on the host supports both IPv4 

and IPv6. The network must also support both protocols on the link leading to the wide area 

network (WAN) (Jamhour & Storoz, 2002). According to Tantayakul, et al. (2008) and Mackay, 

Edwards, Dunmore, Chown, and Carvalho (2003, May-June), dual-stack is the simplest and most 

widely deployed transition mechanism. Afifi and Toutain (1999) added that applications running 

on the host chooses the correct protocol stack to use for communications in a dual-stack 

installation. Gilligan and Nordmark (2000) identified three possible modes of operation for the 

dual-stack host. This includes the IPv4 stack enabled and the IPv6 stack disabled; the IPv6 

enabled and IPv4 disabled; and both stacks enabled. 

The dual-stack packet handling process is best outlined in the research by Wei, Jiang-wei, 

& Guo-dong (2009). The decision to use IPv4 or IPv6 for outbound traffic is based on the 

destination address contained in a packet. If the address is an IPv4 or IPv6 address, packets are 

forwarded to the IPv4 or IPv6 networks respectively. If the destination address is an IPv6 address 

that is compatible with IPv4, packets are forwarded to the IPv4 network. If the destination 

address is a domain name, a request is sent to the DNS server on either the IPv4 or IPv6 

networks. Determining the correct protocol stack for inbound traffic requires the inspection of


28 

the version field contained in the IP header of the packet. If the version field is four, the packet 

should be processed up the IPv4 stack and if the version is six, the IPv6 stack should be used to 

process the packet. Figure 1 illustrates the architecture and operation of a dual-stack 

environment. 

IPv6 

Network 

IPv6 

Application 

IPv6 Host 

IPv4 

Application 

Dual Stack 

Host 

Key 

Dual Stack 

Switch 

IPv4/IPv6 

Router 

IPv4 

Network 

IPv4 Host 

IPv4 Traffic 

IPv6 Traffic 

IPv4/IPv6 Traffic 

Figure 1. Dual-stack Architecture and Operation 

Dual-stack methods were expanded in the research by Xie, Bi, and Wu (2007), who 

proposed the site multi-homing by IPv6 intermediation (SHIM6) redundancy approach. SHIM6 

allows hosts with multiple network cards to benefit from redundant network connections by 

inserting a new layer between the network and transport layers to mitigate connectivity 

problems. Xie, Bi, and Wu’s approach is to use SHIM6 with multiple transition mechanisms like 

Tunnel-Brokers and 6to4 to ensure full and reliable connectivity with IPv4 and IPv6 hosts. 

Dual-stack methods alone do not affect the IPv6 forensic processes for transitional 

networks. In a properly configured environment, dual-stack nodes will send both native IPv6 and 

IPv4 traffic and the routers, switches, and other network devices will act on these packets as 

designed. The nature of native IPv4 and IPv6 traffic is well defined in the research and not a 

subject for this study.


29 

Tunneling. 

Tunneling involves creating a temporary virtual path between two endpoints for the 

purpose of exchanging data. The research by Hsieh and Kao (2005), Jamhour and Storoz (2002), 

and Tantayakul, et al. (2008) illustrated the use of tunneling as an IPv6 transition mechanism. 

IPv6 tunnels utilize an existing IPv4 infrastructure and encapsulate or decapsulate IPv4 and IPv6 

packets between two endpoints. These endpoints can be either a host or a router; however, Yange, 

et al. (2009) pointed out that both endpoints must have implemented the same type of tunnel. 

The typography and types of tunnels for IPv6 transition are discussed by Gilligan and 

Nordmark (2000). Tunnels can be created between a router and host, host and router, host and 

host, or router and host. Additionally, Gilligan and Nordmark classified tunnels as either 

configured, semi-automatic, or automatic. Configured tunnels require prior setup to function and 

require the tunnel creator to specify the tunnel endpoint. Semi-automatic tunnels, like Tunnel- 

Brokers, require prior configuration but, operate independently after they are configured by the 

user. Automatic tunnels, like 6to4, ISATAP, and Teredo operate transparently and require little 

interaction from the user to configure the tunnel. 

Gilligan and Nordmark (2000) outlined the encapsulation and decapsulation process. 

During this process, the sending node encapsulates the IPv6 packet inside of an IPv4 header and 

sends the frame to the tunnel endpoint while fragmenting and maintaining the connection state if 

necessary. The tunnel endpoint decapsulates the packet by removing the IPv4 header and sending 

the packet through the IPv6 network. Encapsulated packets are identified by observing the 

protocol number 41 in the IP header protocol field. Gilligan and Nordmark recommended that 

packets bearing invalid source IPv4 or IPv6 addresses should be discarded and that virtual 

interfaces used by tunnels should be link-local addresses with the address scheme of


30 

FE80::a.b.c.d where a.b.c.d is the IPv4 address of the tunnel. Table 3 lists values for the IPv4 

header fields used to encapsulate a packet. 

Table 3. Tunnel Header Encapsulation Scheme (Gilligan & Nordmark, 2000) 

IPv4 Header Field 

Value in Encapsulated Header 

Version 4 

Header Length 5 

ToS 0 

Length 

Payload + IPv4 header + IPv6 header 

ID 

Dynamically Calculated 

Flags 

Used for fragmentation if needed 

Fragment Offset 

Used for fragmentation if needed 

TTL 

Selected Value 

Protocol 41 

Checksum 

Calculated 

Source Address 

IPv4 address of outgoing interface 

Destination Address 

IPv4 address of endpoint 

Data 

IPv6 Packet starting with IPv6 Header 

6to4. 

Mackay, et al. (2003, May-June) described the 6to4 transition mechanism as a unicast 

point-to-point link-layer tunnel. It allows IPv6 applications to communicate over IPv4 networks 

using a simplified encapsulation method without requiring an explicitly defined tunnel. Tunnels 

are automatically defined based on an addressing standards described in the research by Friacas, 

Baptista, Domingues, and Ferreira (2006), Jamhour and Storoz (2002), and Hsieh and Kao 

(2005). IANA assigned the 2002::/16 address block to be used for 6to4 packets. To address a 

specific host, the IPv4 address can be added to the prefix in HEX notation. For example, the host 

address of 208.112.13.12 can be represented in HEX as D070:0D0C and becomes a 6to4 IP


31 

address by adding the prefix resulting in 2002: D070:0D0C::/48. When a 6to4 compatible router 

or host receives a packet with this type of address, it encapsulates the IPv6 packet inside of an 

IPv4 header and sends it to the IPv4 destination specified in the 6to4 address. This process is 

illustrated in Figure 2. 

Figure 2. 6to4 Transition Mechanism Architecture and Operation 

Tunnel-Brokers. 

Mackay, et al. (2003, May-June), Yan-ge, et al. (2009), and Durand, Fasano, Guardini, 

and Lento (2001) defined a Tunnel-Broker as a client-to-server transition mechanism that 

automatically manages tunnel requests from clients. The tunnel server becomes a bridge for 

clients on both networks and allows individual IPv4 hosts to connect to the IPv6 network. 

Durand, et al. (2001) described the purpose of Tunnel-Brokers as an easy way for users to make 

the transition; however, Friacas, et al. (2006) argued that latency is a problem with this method 

that may limit its application. 

The architecture and operation of the Tunnel-Broker transition mechanism is outlined by 

Durand, et al. (2001) as a client-server model that provides virtual private network (VPN) like 

connectivity to the IPv6 network. Clients on the IPv4 network create an account with a Tunnel


32 

Broker service provider. The Tunnel-Broker provider operates a dual-stack tunnel server that 

manages client registration, authentication, and tunnel management. Before clients send IPv6 

packets from their machine, they authenticate with the tunnel server. The tunnel server verifies 

the client’s credentials and responds with connection setup parameters including the IPv6 

domain, assigned address, tunnel lifetime, and designated gateway for IPv6 communications. 

The tunnel server registers the client’s IPv6 address in the DNS and begins tunneling traffic 

between the client and IPv6 network. The process is reversed for response traffic as the Tunnel- 

Broker maintains state information to route the packets to the correct client. Figure 3 illustrates 

the architecture and operation of the Tunnel-Broker transition mechanism. 

IPv6 Network 

IPv4 Host 

Key 

IPv4 Router 

Dual Stack 

Tunnel Broker 

IPv6 Router 

IPv4 Traffic 

IPv6 Traffic 

Figure 3. Tunnel-Broker Transition Mechanism Architecture and Operation 

Intrasite automatic tunnel addressing protocol (ISATAP). 

Mackay, et al. (2003, May-June), and Templin, Gleeson, and Thaler (2008) defined 

ISATAP as an IPv6 transition mechanism that provides a link-layer tunnel through an IPv4 

network. It is best used to connect isolated dual-stack IPv6 hosts over IPv4 networks and is 

similar to the 6to4 transition mechanism. The addressing scheme is (prefix::0:5EFE:IPv4 

Address in Hex) and is defined in the research by Hsieh and Kao (2005), Templin, et al., and 

Visoottiviseth and Bureenok (2008). For example, an ISATAP host with the IPv4 address of


33 

208.112.13.12 (D070:0D0C Hex) can be assigned link-local IPv6 address FE80:: 0:5EFE: 

D070:0D0C. 

The ISATAP process flow is outlined in the research by Visoottiviseth and Bureenok 

(2008) and includes dual-stack routers and hosts that provide ISATAP support. Routers advertise 

prefixes for ISATAP clients to use and also forward the packets that they receive. To initiate a 

connection, the client sends a router solicitation message to the ISATAP router and receives a 

configuration information message that is used to create a virtual interface. This interface is used 

to send IPv6 packets to the router which encapsulates the packets and sends them over the IPv4 

network until it reaches the host or another ISATAP router to reverse the process. Figure 4 

illustrates the ISATAP process. 

Figure 4. ISATAP Transition Mechanism Architecture and Operation 

Teredo. 

Mackay, et al.(2003, May-June), Jamhour and Storoz (2002), and S. M. Huang, Wu, and 

Lin (2005) defined Teredo as a mechanism to tunnel IPv6 packets over the User Datagram 

Protocol (UDP) to support clients within NAT environments that have not been assigned a global 

IPv4 address. Huitema (2006) and Mackay, et al. added that Teredo is a service of last resort and


34 

should only be implemented in environments where other transition mechanisms are not possible 

because of an existing NAT infrastructure. Teredo clients communicate with a Teredo server to 

obtain configuration information and relay IPv6 packets using stateless connections to the 

Teredo relay servers. 

The architecture and operation of the Teredo mechanism is described by S. M. Huang, et 

al. (2005). The Teredo architecture consists of clients within an IPv4 network, dual-stack Teredo 

servers that provide IPv6 addresses to clients, and dual-stack Teredo relays that encapsulate and 

decapsulate packets between clients and IPv6 hosts. Clients initiate a connection by sending a 

request to the Teredo server. The server responds with an IPv6 addresses assignment based on 

the IPv4 information of the client. This address consists of: a prefix which is usually 

2001:0000::/32, 32 bit IPv4 address of the Teredo server, 16 bit flags, FFFF exclusive or (XOR) 

of the 16 bit assigned port number of the public NAT connection, and the FFFF:FFFF XOR of 

the 32 bit assigned IPv4 address of the public NAT connection. The XOR operation is necessary 

to avoid IP substitution from NAT devices that support application layer IP replacement. An 

example of the addressing scheme is displayed in Table 4. 

Table 4. Teredo Addressing Scheme 

IPv4 Address of NAT Outbound Port NAT Public Address for 

Prefix Teredo Server Flags for Client Connection Client Connection 

Decimal 208.112.13.12 0 2048 13.12.208.112 

Hex 2001:0000 D070:0D0C 0000 0800 0D0C:D070 

Operation 

FFFF X OR X FFFF:FFFF X OR X 

IPv6 2001:0000: D070:0D0C: 0000: F7FF: 

F2F3:2F8F 

After the IPv6 address is assigned, the client sends packets to the Teredo relay server 

closest to the destination node as outlined in research by Huitema (2006). Relay discovery occurs 

when an ICMPv6 echo request is sent to the destination through the assigned Teredo server. The


35 

closest relay will be the last hop listed in the reply before the destination. Once the relay is 

determined, the relay-to-destination association is stored in a buffer for future use and the client 

encapsulates the IPv6 packet in an IPv4 header and forwards it to the relay. The relay 

decapsulates the packet and forwards it to the IPv6 destination node. The return path reverses the 

process using the IP and port number embedded in the source address that the relay uses to route 

response packets to the client. There may also be periodic empty packets or bubbles sent from 

the client to the Teredo relay or server to keep the connection and NAT entries alive. This 

process is illustrated in Figure 5. 

Figure 5. Teredo Transition Mechanism Architecture and Operation 

Tunnel-Brokers, 6to4, and Teredo are the most common tunnel based IPv6 transition 

mechanisms; however, there has been other methods introduced in the research like 6over4, 

peer-to-peer (P2P), Cisco 6 Provider Edge (6PE), IPv6 over asynchronous transfer mode (ATM) 

and IPv6 over multiprotocol label switching (MPLS). The 6over4 method is very similar to 

ISATAP and 6to4. Leng, Bi, Zhang, and Wu (2007), Bi, Leng, and Wu (2007), Shengyang and 

Yanlei (2010), and Zhou and Renesse (2004) proposed a P2P based overlay network that 

forwards IPv6 encapsulated packets from node to node until an IPv6 connection is detected.


36 

Yan-ge, et al. (2009) discussed the 6PE method which uses MPLS from within edge routers to 

tunnel IPv6 packets between two sites. Mackay, et al. (2003, May-June) briefly outlined IPv6 

over ATM. 

Tunnel based IPv6 transition mechanisms impact forensic analysis. Investigators and 

forensic analysts must understand the characteristics of these mechanisms, how tunnels are 

created and maintained, and how to assess the nature of traffic that they contain. Additionally, 

the modification of header information and existence of traffic relays introduces concerns of 

spoofing and data integrity that impact evidence admissibility. While the standards for tunneling 

mechanisms are defined in the literature, there are no sources that address the possible 

implications on forensic analysis. 

Protocol translation. 

Protocol translation involves using an algorithm to convert an IPv4 packet into an IPv6 

packet and vice-versa. Carpenter and Jung (1999) and Mackay, et al. (2003, May-June) wrote 

that protocol translation allows IPv4 only nodes to communicate with IPv6 only nodes. Mackay, 

et al. and Tantayakul, et al. (2008) described a translation process that can occur in the network, 

transport, or application layers. 

Stateless IPv4/IPv6 translation algorithm (SIIT). 

Nordmark (2000), Mackay, et al. (2003, May-June), Yan-ge, et al. (2009), and Afifi and 

Toutain (1999) defined SIIT as a method of translating IPv4 headers into IPv6 headers and viceversa. 

The algorithm facilitates communications between IPv4 only hosts and IPv6 only hosts 

and is used as a basic model in other transition methods like NAT-PT. Nordmark, Afifi, and 

Toutain defined the addressing structure of a SIIT translation. The IPv4 SIIT host uses the last 32 

bits of the IPv6 address as a source IPv4 address. The IPv6 SIIT host uses an address of


37 

0::FFFF:0: during translation of IPv4 packets. For example, the address 

0::FFFF:0:D070:0D0C represents the host at IP 208.112.13.12. Packets are exchanged and 

translated by each client over a stateless connection. 

The details of the SIIT algorithms are outlined by Afifi and Toutain (1999) and involves 

translation between IPv4 headers to IPv6 header, ICMP to ICMPv6, and IPv6 headers to IPv4 

headers. Table 5 and Table 6 illustrate the translation scheme for ICMP messages and error 

codes, Table 7 displays the IPv4 to IPv6 translation, and Table 8 outlines the IPv6 to IPv4 

translation using the SIIT algorithm. 

Table 5. SIIT ICMP Message Translation 

IPv4 Type Action IPv6 Type 

Echo - 8 Translate 128 

Reply - 0 Translate 129 

Info request/reply, timestamp, address mask, router 

Drop 

advertisement, router solicitation, unknown types 

Table 6. SIIT ICMP Error Translation 

IPv4 Type Action IPv6 Type 

Unreachable/route failed – (0,1,4,5,6,7,8,11,12) Translate No route – (0) 

Protocol unreachable/prohibited (2,9,10) Translate Prohibited – (1) 

Port unreachable – (3) Translate Port unreachable – (4) 

Redirect, source quench, time exceeded, parameter problem Drop


38 

Table 7. SIIT IPv4 to IPv6 Header Translation 

Field 

Translated Value 

Version 6 

Traffic Class 0 

Flow Label 0 

Payload length 

Length from IPv4 header 

Next Header 

Protocol Field from IPv4 header 

Hop Limit 

TTL from IPv4 

Source Address 

0::FFFF:0: 

Destination Address 

0::FFFF:0: 

Table 8. SIIT IPv6 to IPv4 Header Translation 

Field 

Translated Value 

Version 4 

Length 5 

ID 0 

Flags 

1 (Don’t Fragment Flag) 

Fragment offset 0 

Time to Live 

Hop limit from IPv6 header 

Protocol 

Next header field from IPv6 

Checksum 

Calculated 

Source address 

Lower order 32 bits of IPv6 source address 

Destination address 

Lower order 32 bits of IPv6 destination address 

Network address translation and protocol translation (NAT-PT). 

Tsirtsis and Srisuresh (2000), Mackay, et al. (2003, May-June), Afifi and Toutain (1999), 

and Hsieh and Kao (2005) defined NAT-PT as a translation mechanism that combines NAT with 

the SIIT algorithm. The IPv6 hosts are assigned IPv4 addresses and the NAT device uses the 

SIIT algorithm to translate the packets between the IPv4 and IPv6 hosts.


39 

Bump-in-the-stack (BIS). 

Yan-ge, et al. (2009), Mackay, et al. (2003, May-June), and Jamhour and Storoz (2002) 

defined BIS as a tranlation method that converts headers in the protocol stack of the host. BIS 

requires translation software and a dual-stack host connected to either an IPv4 or IPv6 network. 

Tsuchiya, Higuchi, and Atarashi (2000) cautioned that BIS only works with unicast traffic, 

doesn’t work with header options, and can’t be used with embedded IP addresses. Mackay, et al. 

outlined the operation of BIS as an additional segment integrated into the host’s IP processing 

stack that performs functions similar to the operation of NAT-PT. 

BIS transparently translates packet header between IPv4 and IPv6 from within the 

network stack. The research by Tsuchiya, et al. (2000) provided a detailed account of the 

operation of BIS. Packet data is analyzed between the network card driver and TCP modules. 

When an application sends an outbound DNS request, the BIS module analyzes the response. If 

the DNS response specifies an IPv4 address, the response is forwarded up the stack to the 

application. If the DNS response is an IPv6 address, an internal IPv4 address is mapped to the 

session and the DNS response is forwarded to the application after being modified to include 

only this IPv4 address. When the local application sends subsequent packets to the internal IPv4 

address, the BIS module uses the SIIT algorithim to convert the packets and destination 

addresses to IPv6 before forwarding them down the IPv6 stack to the destination host. Return 

traffic from the IPv6 host is also intercepted by the BIS module, converted to IPv4 using the SIIT 

algorithm, and forwarded to the local application using the internal IPv4 address. 

Bump-in-the-API (BIA). 

The BIA IPv6 transition method is similar to the BIS method. S. Lee, Shin, Kim, 

Nordmark, and Durand (2002) and Mackay, et al. (2003, May-June) identified the remote


40 

location of the translation function outside of the transmission control protocol/Internet protocol 

(TCP/IP) protocol stack as the primary difference between the BIA and BIS mechanisms. BIA 

functions do not translate headers. Instead, application programming interface (API) calls from 

the application to the TCP/IP protocol stack are intercepted and converted to the equivalent API 

call from the other protocol. Jamhour and Storoz (2002) noted that, like BIS, BIA requires either 

an IPv4 or IPv6 network and BIA software. Additionally, the research by S. Lee, et al. identified 

limits on the internally assigned addresses and incompatable IPv4 and IPv6 API functions as the 

primary issues with this method. 

S. Lee, et al. (2002) and Jamhour and Storoz (2002) detailed the operation and 

components of the BIA IPv6 transition method. An application making a connection to a remote 

host using TCP or UDP first calls API functions designed to interface with the local network 

stack. The application uses different API functions for IPv4 and IPv6 communications. BIA 

monitors API calls and converts the input and function called to the corresponding API function 

when necessary using the same logic as in BIS. For example, if an IPv4 application sends a DNS 

request and receives an IPv6 address in response, BIA assigns an internal IPv4 address to the 

session and translates the IPv4 API call from the application to the IPv6 API call needed to 

communicate with the remote host. 

SOCKS64. 

Kitamura (2001), Yan-ge, et al. (2009), and Mackay, et al. (2003, May-June) summarized 

the SOCKS64 transition method and Jamhour and Storoz (2002) outlined its basic operation. 

SOCKS is a client-to-server proxy service designed to facilitate controlled access to external 

network resources when firewalls are employed. Clients that have the SOCKS applications 

installed use the SOCKS server as a gateway to communicate with remote hosts. SOCKS64


41 

functions the same as BIA, except the translation occurs in the SOCKS function calls with the 

proxy server instead of the API function calls within the host. 

Transport relay translator (TRT). 

Another gateway based transition mechanism is the Transport relay translator (TRT) 

method. Jamhour and Storoz (2002) defined TRT as a method that utilizes an intermediary 

device to act as a translator and gateway. Mackay, et al. (2003, May-June) added that TRT is a 

method to transport and relay TCP and UDP traffic at the border of the network. TRT allows 

clients in IPv4 networks to communicate with external IPv6 hosts and vice-versa. The addressing 

scheme to represent the IPv4 host in the IPv6 network is constructed from ::. For example, if the TRT gateway operates from FEC8:0:0:1::/64 and the IPv4 host is 

at 208.112.13.12 the IPv6 address of the IPv4 host would be FEC8:0:0:1:: D070:0D0C. 

The operation of TRT is outlined by Hagino and Yamamoto (2001). TRT requires a dualstack 

edge router and a device or host to provide translation. When an IPv4 client sends a packet 

to an external IPv6 host, the TRT gateway creates a connection with the internal IPv4 host and 

the external IPv6 host. As packets are exchanged, the TRT gateway translates the packets 

between the protocols using the SIIT protocol. 

Other gateway based translation methods. 

Other gateway based translation methods that are hybrids of standard methods have been 

proposed by researchers. AlJa'afreh, Mellor, Kamala, and Kasasbeh (2008) proposed a method 

that uses a network of IPv4, IPv6, and IPv4/6 DNS servers to manage virtual IP addresses and a 

dual-stack gateway to provide protocol translation. Hsieh and Kao (2005) proposed a gateway 

that supports all of the transition mechanisms to provide the most flexibility to devices on the 

network. A NAT-PT based gateway using SIIT is proposed by Seo and Kong (2005). A gateway


42 

that utilizes dual-stack transition mechanism (DSTM) to translate traffic between different 

protocols is proposed by Jamhour and Storoz (2002). Carpenter and Moore (2001) proposed a 

gateway based encapsulation method that requires only one routing entry and no host 

configuration to facilitate translation. 

Translation mechanisms modify the original packets and have implications on forensic 

analysis. Investigators and analysts must understand how to identify packets that have been 

modified by translation mechanisms and what elements have been changed to accurately 

determine the nature of network traffic. Although, the operation of these translation mechanisms 

have been defined in the research, the implications on forensic analysis and investigation have 

not been addressed. 

IPv6 Operating System Support 

IPv6 has been integrated into popular operating systems for many years. Windows 7, 

2008, 2003, XP, and Vista provide IPv6 functionality that is enabled in the default configuration 

or can be setup with minor configuration. Recent UNIX based kernels and the Apple Mac 

operating systems have IPv6 integrated; however, additional configuration or package 

installations may be necessary enable the protocol. 

Windows operating systems. 

Microsoft has supported IPv6 as a communications protocol in all versions of the 

Windows operating system beginning in 1998 (Tulloch, 2006). Microsoft released an optional 

package for Windows 95, 98, and 2000 that installed a limited version of the IPv6 stack. 

Windows XP service pack 1 and Windows 2003 included a full version of the IPv6 protocol 

stack and an optional package that included an IPv6 firewall. Transition methods were later 

included in XP service pack 2. Windows Vista, Windows 7, and Windows Server 2008 added


43 

improvements to IPv6 security and performance and established the protocol as an integrated 

component of the network operating system. 

A 2005 study by Savola provided information about IPv6 usage in the Windows 

operating system. The study used server logs to analyze 6to4 traffic passing through a small relay 

in Finland from October 2001 to April 2004. Traffic from Windows clients was identified by the 

way the IPv4 address was embedded into the 6to4 address as 2002:::. A significant number of probes were sent from clients to the relay server. These 

probes consisted of ICMP echo request with an IPv6 hop limit of 1 that were sent to discover and 

select the relay with the best response time. By default, these probes were sent every 24 hours or 

when the IPv4 routing or client address changes. Savola found a large increase from 100,000 to 2 

million unique IPv4 addresses per month in the first months of 2004. The study also noted that 

only 1 in 100 nodes utilized the relay to send traffic that was not a probe. The applications used 

by the clients based on the known port number are listed in Table 9. This study occurs during a 

time when most of the clients observed are likely to be Windows XP SP1. IPv6 support in SP1 

was an optional component and the traffic observed in the study would require IPv6 to be 

explicitly configured by the user. When Windows XP SP2, Vista, and Windows 7 were released, 

IPv6 with 6to4 was integrated, resulting in a likely surge in probe traffic. 

Table 9. 6to4 Relay Application Traffic Observed by Savola (2005) 

Application 

Internet Control Message Protocol (ICMP) 

Domain Name System (DNS) Query 

Secure Shell (SSH) 

Simple Mail Transfer Protocol (SMTP) 

Hypertext Transfer Protocol (HTTP) 

BitTorrent (BT) P2P File Sharing 

Traffic Volume 

High 

High 

Moderate 

Moderate 

Moderate 

Moderate


44 

Application 

Traceroute 

Peer Name Resolution Protocol (PNRP) 

IRC, FTP, IMAP, NNTP, POP3, IDENT, IPv6 Tunnels 

Traffic Volume 

Moderate 

Moderate 

Low 

IPv6 functional enhancements in the Windows 7, Vista, and 2008 operating systems was 

outlined by Tulloch, Northrup, Honeycutt, and Wilson (2010). IPv6 is installed and enabled by 

default in these releases and the IPv6 and IPv4 components are integrated into a single stack to 

improve communications performance. A new graphical user interface (GUI) for IPv6 

configuration was added and full internet protocol security (IPSec) functionality was added to 

the Windows firewall. The default operating status of the Teredo transition mechanism was 

changed to disabled and link-local multicast name resolution (LLMNR) using randomly 

generated interface IDs was added to allow directly connected peers to communicate. 

Additionally, Tulloch, et al. (2010) identified new IPv6 features that have been added from the 

standards defined in Request of Comment (RFC) documents. This includes support for; multicast 

listener discovery version 2 (MLDv2) that allows a host to register their interest or disinterest in 

specific multicast traffic; the IPv6 version of the dynamic host configuration protocol 

(DHCPv6); IPv6 control protocol (CP) to support remote connections using an IPv6 node 

configured on a point-to-point protocol (PPP) link; IP hypertext transfer protocol secure (IP 

HTTPS) that creates an alternative to 6to4 and Teredo when a proxy or firewall blocks the 

traffic; and Direct-Access that uses an IPSec tunnel to connect a client to a remote network 

without a VPN. 

Viewing the status of IPv6 in the Windows operating system is described by Tulloch, et 

al. (2010) and Davies (2008). The IPv6 interfaces are enabled by default and the interface ID 

used in IPv6 addressing is randomly generated. A user can use the command “NETSH


45 

INTERFACE IPV6 SHOW INTERFACE” or “IPCONFIG /ALL” to show the configured 

interfaces. The host routing table defines the handling of packets and both Windows Server 2008 

and Windows 7 can be configured to act as an ISATAP router for other hosts. The command to 

display the host routing table is “NETSH INTERFACE IPV6 SHOW ROUTE” 

Tulloch, et al. (2010) and Davies (2008) described the process to disable IPv6 for 

environments where the protocol will present security issues. The GUI local area network (LAN) 

properties dialog in the network adapter properties presents an option to disable the IPv6 

protocol for the adapter; however, the IPv6 loopback and tunnel interfaces will remain active. A 

bitmask vale can be added to the registry to disable IPv6; however, the IPv6 loopback adapter 

will still be enabled. Disabling the IP helper service will effectively disable all IPv6 transition 

technology on the host or the netsh command can be used to selectively disable individual 

components. If a client is operating behind a firewall, blocking protocol 41 will disable 6to4 and 

ISATAP, and blocking UPD port 3544 will disable Teredo. 

Tulloch, et al. (2010) indicated that IPv6 interface addresses can originate from a 

DHCPv6 server, router advertisements, or address auto-configuration. IPv6 addresses are 

automatically allocated and configured for the interface if a DHCPv6 server is available. A local 

router can advertise an IPv6 prefix that allows an address to be automatically allocated and 

configured for the interface. If router or DHCPv6 advertisements are not reaching the host, linklocal 

addresses are configured for the interface using the prefix FE80::/64. These addresses are 

not registered in the DNS and allow directly connected hosts to communicate after neighbor 

discovery occurs. The IPv6 address for each interface carries a status of either; tentative to 

indicate that the uniqueness of the address is being verified; valid or preferred to indicate a 

unique address that can be used in unicast communications; depreciated to indicate an expired


46 

address that can be used by existing sessions only, and invalid to indicate an expired address that 

cannot be used. To get more information about the addresses and neighbors, Tulloch, et al. 

suggested the command “NETSH INTERFACE IPV6 SHOW ADDRESSES” to show all IPv6 

interface addresses and “NETSH INTERFACE IPV6 SHOW NEIGHBORS” to list discovered 

IPv6 neighbors that can be contacted using the link-local address. 

The operation of DNS in an IPv6 transition is detailed by Tulloch, et al. (2010). Queries 

for AAAA records that contain IPv6 addresses are only requested when there is an interface that 

is assigned an address that is not a link-local or Teredo address and only after requesting and 

receiving a successful response for the domain’s A record. DNS servers will automatically 

register a client’s non link-local IPv6 addresses. Windows 2003 can be configured to listen for 

DNSv6 queries and Windows 7 and Windows Server 2008 listen by default. 

Davies (2008) details ISATAP support on Windows 7, Vista, and Windows 2008. The 

ISATAP interface is disabled by default unless there is an ISATAP router present or if the node 

is running Windows Vista with no service packs. Hosts can communicate with other IPv6 nodes 

by tunneling across an IPv4 network if there is an ISATAP router available. Additionally, any 

Windows 7, Vista, or Windows Server 2008 clients can act as an ISATAP router for other clients 

if both IPv6 and IPv4 links are available. 

Windows 7, Vista and Windows Server 2008 support for 6to4 is outlined by Davies 

(2008). 6to4 is enabled for any interface that has a public IPv4 address and can reach a 6to4 

relay. Windows clients configure the 6to4 interface by querying the domain 

6to4.ipv6.microsoft.com for the IPv4 address of a 6to4 relay, setting the address to 2002::::, and adding a route to the


47 

hosts table for 2002:::1. Like ISATAP, Windows 7, Vista, and 

Windows Server 2008 can be configured as a 6to4 router. 

Davies (2008) described Teredo support in Windows 7, Vista, and Windows Server 2008. 

Teredo is disabled by default and uses the address 2001:::: as described in the Teredo 

section on page 33. It is automatically enabled when an application sends a packet to another 

Teredo address or when the Windows firewall is configured to allow Teredo connections. Teredo 

can be manually enabled by setting the “Teredo Default Qualified” setting to enabled in the 

group policy module under computer configuration > administrative templates > network > 

TCPIP settings > IPv6 transition technologies. Teredo can be configured to function within an 

enterprise network using the command “NETSH INTERFACE TEREDO SET 

STATE TYPE=ENTERPRISECLIENT” and the port number used by Teredo can be set using 

the command “NETSH INTERFACE TEREDO SET STATE CLIENTPORT=”. 

Data traffic consists of encapsulated packets consisting of an IPv4 header, UDP header, IPv6 

header, and the IPv6 payload. Bubble packets may also be sent to keep the NAT port assignment 

active; however, Windows nodes do not use this information. Teredo packets are routed either 

directly to other clients when the destination has a Teredo address or to the relay closest to the 

destination when communicating with an IPv6 node. 

Microsoft Windows is the most common operating system on the market and the majority 

of forensic analysis and investigations will involve Windows nodes. As a result, investigators 

and analysts will need to understand the capability and operation of IPv6 in the Windows 

environment to determine the nature of traffic on transitional networks. The research presented a 

basic analysis of the types and characteristics of Windows IPv6 traffic; however, the implications


48 

to a forensic investigation are unclear. Microsoft publications present a detailed account of IPv6 

capabilities in their products; however, this information does not address the analysis or handling 

of network data. 

Linux, FreeBSD and UNIX operating systems. 

IPv6 is supported in the Linux, FreeBSD, and UNIX operating systems. Ubuntu, CentOS, 

FreeBSD, and Sun Solaris provide simple IPv6 configuration procedures in their administration 

guide to setup interfaces, 6to4, and tunneling. Unlike the Windows operating system, none of 

these operating systems natively support ISATAP or Teredo; however, third party packages are 

available that provide the functionality. 

Ubuntu Linux. 

Ercferret (2010) outlined Ubuntu Linux setup for native IPv6 and tunneling using 

FreeNet6, SixXS, Go6.net, and Miredo. To add a static IPv6 address to an interface, edit the file 

“/ETC/NETWORK/INTERFACES” and add the lines “IFACE INET6 STATIC“, 

“ADDRESS ”, and “NETMASK ”. To configure Ubuntu to act as an 

IPv6 router, enable forwarding by editing the file “/ETC/SYSCTL.CONF” and un-commenting 

the line “NET.IPV6.CONF.DEFAULT.FORWARDING=1”. Then install RADVD using the 

command “SUDO APTITUDE INSTALL RADVD” and edit the file “/ETC/RADVD.CONF” to 

add the IPv6 address prefix for routing advertisements. SixXS tunneling is setup by installing the 

aiccu client using the command “SUDO APTITUDE INSTALL AICCU”. Freenet6 is setup by 

installing the signaling protocol to negotiate tunnel setup parameters (TSPC) and editing the 

configuration file “/ETC/TSP/TSPC.CONF”. Both of these tunneling methods require 

registration on the applicable web sites to obtain setup information; however, freenet6 offers a 

limited anonymous account with the default installation. Miredo is a Teredo package that is


49 

installed with the command “SUDO APTITUDE INSTALL MIREDO”. It will create a new 

interface with the 2001 address prefix. 

CentOS. 

Faye (2008) defined CentOS IPv6 setup for native IPv6 and tunneling. IPv6 features must 

be installed and enabled manually. To determine if IPv6 is installed, verify the existence of 

“/ETC/SYSCONFIG/NETWORK-SCRIPTS/NETWORK-FUNCTIONS-IPV6” and run the 

command “MODPROBE -C | GREP IPV6” to verify that the response is “ALIAS NET-PF-10 

IPV6”. If this is not the response, edit the file “/ETC/SYSCONFIG/NETWORK 

SCRIPTS/IFCFG-” and add or edit the lines “IPV6INIT=YES”,” 

IPV6_AUTOCONF=NO”, and “IPV6ADDR=”. Then add a route for the default 

IPv6 gateway with the command “ROUTE -A INET6 ADD DEFAULT GW ”. Connectivity can be tested using IPv6 commands ping6, traceroute6, ip6tables, 

and tracepath6. Tunnels are setup by creating an interface “SIT” and editing 

the file “/ETC/SYSCONFIG/NETWORK-SCRIPTS/IFCFG-SIT” with the 

lines “DEVICE="SIT"”, “BOOTPROTO="NONE"”, “ONBOOT="YES"”, 

“IPV6INIT="YES"”, and “IPV6TUNNELIPV4=""”. 

FreeBSD. 

The FreeBSD online manual ("Chapter 31 advanced networking," 2010) indicated that 

the operating system utilizes the KAME IPv6 reference implementation and supports native, 

SixXS, 6to4, and freenet6 connections. Auto-configuration of IPv6 on each interface can be 

setup by running the command “IPV6_ENABLE="YES"”. To assign a static IPv6 address to an 

interface, run the command “IPV6_IFCONFIG_>=""”. To assign a 

default router, run the command “IPV6_DEFAULTROUTER=""”. A tunnel is


50 

configured by adding a “GIF” interface and then running the commands 

“GIFCONFIG_GIF=" "”,” 

IPV6_IFCONFIG_GIF=""”, and 

“IPV6_DEFAULTROUTER=""”. To configure the system to 

operate as an IPv6 router, run the commands, “IPV6_GATEWAY_ENABLE="YES"” to enable 

the gateway, “RTADVD_ENABLE="YES"” to enable router advertisements, 

“RTADVD_INTERFACES=""” to set the router interface, and edit the file 

“/ETC/RTADVD.CONF” with the lines “:\”, and 

“:ADDRS#1:ADDR="::":PREFIXLEN#:TC=ETHER:”. 

Sun Solaris. 

The Sun Solaris administration guide for IP services ("System administration guide: IP 

services," 2009) provided a detailed description of the IPv6 protocol and configuration in the 

Solaris UNIX environment. Solaris Sendmail, Network File System (NFS), HTTP, DNS, 

Lightweight Directory Access Protocol (LDAP), Network Information Service (NIS), IPSec, 

Internet Key Exchange (IKE), IP Quality of Service (IPQoS), and IP Network Multipathing 

(IPMP) support IPv6 communications. The Solaris Kernel automatically adds IPv6 nodes to the 

all nodes, all routers, and solicited nodes multicast groups. Solaris does not support the 

configuration of anycast groups; however, outbound traffic can be sent to anycast addresses. 

Interfaces are assigned an IPv6 address through auto or manual configuration that is 

defined in the System administration guide for IP services (2009). Solaris automatically assigns a 

link-local address to the interface with the lowest interface number. Additionally, an interface 

will be automatically configured if router advertisements are received. To manually configure an 

interface for IPv6, the commands “IFCONFIG INET6 PLUMB UP” enables IPv6


51 

on the interface, and “/USR/LIB/INET/IN.NDPD” starts the NDPD service. To verify the 

connection, run the command “IFCONFIG -A6” and create the file 

“/ETC/HOSTNAME6.” to make IPv6 enabled by default. To setup a Solaris node as 

an IPv6 router, run the commands “ROUTEADM -E IPV6-FORWARDING -U” to enable 

forwarding, “ROUTEADM -E IPV6-ROUTING -U” to enable routing, create the file 

“/ETC/INET/NDPD.CONF” and add the advertised prefix in lines “IF DMFE0 

ADVSENDADVERTISEMENTS 1” and “PREFIX / DMFE0”. 

Solaris also supports manual IPv6 tunnels or 6to4 dynamically configured tunnels that are 

defined in ("System administration guide: IP services," 2009). A manual tunnel allows 

communications from two IPv6 nodes over an IPv4 network. It is configured by creating the file 

“/ETC/HOSTNAME6.IP.TUN” and adding the line “SRC TDST UP”. The 6to4 method requires a 6to4 router 

and is setup by creating the file “/ETC/HOSTNAME6.IP.6TO4TUN0” and adding the line 

“TSRC UP” for auto address assignment, or TSRC :/64 up to specify a static address. 

Setup can be confirmed by running the command “IFCONFIG IP.6TO4TUN0 INET6”. To use a 

6to4 relay as an endpoint for the tunnel instead of the 6to4 router, run the command 

“/USR/SBIN/6TO4RELAY –E” or edit the file “/ETC/DEFAULT/INETINIT” and change the 

line “ACCEPT6TO4RELAY=YES” to make 6to4 relays the default setting. 

Apple/MAC operating systems. 

The Apple online help ("Mac OS X 10.5 Help," 2010) manual provided simplified 

instructions to enable and configure IPv6 for Mac OS X v10 clients. Apple applications that 

support IPv6 communication include DNS, firewall, Mail (POP/IMAP/SMTP), Windows


52 

(SMB/CIFS), Web (Apache 2), Ping6, and Traceroute6. IPv6 is automatically configured; 

however, the IPv6 address, gateway, and prefix length can be manually configured by navigating 

to the Apple > system preferences > Network > and advanced TCP/IP for the IPv6 interface. If 

the client has a public IPv4 address, the 6to4 interface can be added by navigating to the Apple > 

system preferences > Network > (+) and then choose the 6to4 interface. The Apple firewall 

blocks all IPv6 traffic by default. To enable IPv6 traffic through the firewall, use 

SERVERADMIN to set a key by adding lines for “IPV6MODE”, 

“”, “IPV6CONTROL”, and 

“”. The can be “DENYALL”, “DENYALLEXCEPTLOCAL”, or 

“NORULES” which will allow the user to manually configure IPv6 firewall using a script. 

Although the Windows operating system dominates the client market, Linux, FreeBSD, 

and UNIX are common and often the operating systems of choice for attackers and malicious 

users. Investigators and analysts must understand how IPv6 is configured and recognize common 

IPv6 methods used in these environments to determine the possible source and nature of traffic 

in a transitional network. There was only one outdated study found that classified 6to4 traffic at a 

basic level and operating system documentation does not provide the details necessary to 

conduct a forensic investigation. Understanding the capabilities defined in this research provides 

a basis to investigate the nature of this traffic. 

IPv6 Vulnerabilities and Attack Vectors 

The IPv6 protocols and transition mechanisms introduce a new network surface area 

available for attackers to exploit. Zagar, Grgic, and Rimac-Drlje (2007) pointed out that the 

designers of the original IP protocol did not address security because it was assumed that 

security would be integrated at the application level. They also did not anticipate that the IP


53 

networks would grow from a few hundred nodes used primarily by researches, to a global 

network used by 1.58 billion users in 2008 ("Internet Users," 2009). IPv6 was created to address 

these issues; however, new threats emerged and some IPv4 issues were not resolved. 

The research into IPv6 vulnerabilities and attack vectors is comprehensive and 

theoretical; however, very little data or statistics are presented to outline actual IPv6 attacks that 

have occurred. Vives and Palet (2005) noted the difficulty of securing an IPv6 infrastructure that 

is fundamentally designed to facilitate end-to-end communications and allows nodes to be 

reachable from anywhere. Zagar, et al. (2007), Radhakrishnan, Majid, Shabana, and Moinuddin 

(2007), Caicedo, Joshi, and Tuladhar (2009), and Emre and Ali (2010) identified rogue nodes, 

man-in-the-middle, DoS, and application layer attacks as threats in IPv6. Convery and Miller 

(2004) listed layer three and four spoofing, unauthorized access, header manipulation, 

fragmentation, broadcast amplification, routing attacks, viruses, worms, and transition 

mechanisms as the key threats to IPv6 networks. 

It is unclear if attackers will exploit the identified IPv6 vulnerabilities in practice; 

however, some researchers have established that the exploitation is possible by identifying the 

tools and techniques necessary to conduct the attack. Warfield (2003) listed several IPv6 tools 

that are freely available and can be used to conduct attacks on IPv6 networks. This included 

protocol bouncers used to relay traffic like Relay6, NetCat6, 6Tunnel, and Iinetd; IPv6 scanners 

for conduction network reconnaissance like HalfScan6 and Nmap; and DoS tools used to 

conduct 6to4 attacks like 6to4DDoS. Caicedo, et al. (2009) added a suite of IPv6 attack tools 

called THC-IPv6; packet generators like MGEN, SendIP, Scapy6, and IPv6PacketGen; and tools 

to detect IPv6 neighbor discovery attacks like NDPmon and Ddaddos.


54 

According to Caicedo, et al. (2009), the most effective method of mitigating the threats 

introduced by IPv6 is to apply a defense in depth strategy. This included applying existing 

network security best practices like establishing security policies, deploying and properly 

configuring firewalls, using encryption, and monitoring the network using IDS devices. These 

techniques must be adapted to the unique requirements of the IPv6 protocol. For example, Zagar, 

et al. (2007) proposed unique IDS rules for IPv6 monitoring including: identifying packets 

without a next header value, irregular or duplicate option headers, and fragments that are less 

than the maximum transmission unit (MTU) of 1280 octets but not the last packet in the flow. 

IPv6 security can also be enhanced by using IPSec. IPSec is a required component of IPv6 and 

researchers believe that it can mitigate many of the vulnerabilities introduced by the protocol. 

Zagar, et al. and Radhakrishnan, et al. (2007) conclude that IPSec can mitigate the impact of 

DoS, spoofing, and data interception by providing point-to-point access control, connection 

integrity, data authentication, and confidentiality using hashes and other encryption algorithms. 

Szigeti and Risztics (2004), Caicedo, et al., and Dobrucki (1999) conclude that IPSec will not be 

widely deployed because of the difficulties of key management and integration with existing 

security methods already built into applications. Sotillo (2006), Szigeti and Risztics, and 

Dobrucki argued that the most common threat is the human factor which highlighted the point 

made by Caicedo, et al. about the importance of employing a defense in depth strategy to 

mitigate threats in an IPv6 network. 

Despite new vulnerabilities and attack tools, IPv6 threat classifications and mitigation 

strategies have not changed. Researchers have identified new considerations and strategies for 

addressing specific IPv6 threats. These considerations and strategies can be categorized by their


55 

underlying threat as reconnaissance, denial of service attacks, man-in-the-Middle attacks, IPv6 

covert channels, security control bypass, IPv6 Worms, and IPv6 transition mechanisms. 

Reconnaissance. 

Network scanning remains a viable IPv6 pre-attack technique using modified methods. 

Zagar, et al. (2007) and Convery and Miller (2004) identified the difficulty of brute-force 

scanning due to the large number of address possibilities in an IPv6 network. Sotillo (2006) 

extended this view by calculating that it would take 584 billion years to scan every address in the 

default 64 bit IPv6 subnet. Szigeti and Risztics (2004) and Caicedo, et al. (2009) acknowledged 

that this large address space created security through obscurity; however, it can also make the 

detection of rogue hosts more difficult. Additionally, attackers have new methods at their 

disposal to make IPv6 scanning more successful. Vives and Palet (2005), Caicedo, et al., E. 

Davies, Krishnan, and Savola (2007), and Emre and Ali (2010) described a method where an 

attacker identifies a network topography by first analyzing multicast addresses like the all routers 

address (FF05::5). Convery and Miller suggested using DNS queries to gain preliminary IPv6 

addresses assigned to hosts. Because most network designers seek simplified IP address 

assignments, the range of addresses to be scanned can be reduced once a few legitimate 

addresses are know by the attacker. 

Denial of service attacks. 

The IPv6 protocol and neighbor discovery functions have introduced a number of new 

DoS attack vectors. E. Davies, et al. (2007) identified link-local auto-configuration as the largest 

opportunity for an attacker. Using local-links, a directly connected attacker can launch an attack 

without intervention or monitoring from security devices in an enterprise network. Yang, Ma, 

and Shi (2007) argued that this feature enables DoS attacks that interrupt normal


56 

communications between hosts; however, traditional DoS attacks that waste a victim’s resources 

like TCP floods are still possible in IPv6 networks. 

IPv6 protocol DoS attacks. 

The IPv6 protocol enables denial of service attacks that use traffic floods, broadcast 

amplification, fragmentation, and option headers to disrupt normal communications between 

victims and other hosts. 

Flood attacks attempt to overwhelm the resources of a victim to prevent interactions with 

legitimate hosts. Yang, et al. (2007) identified that traditional TCP floods using unacknowledged 

SYN/ACK packets, UDP floods using CHARGEN/ECHO services, and ICMPv6 floods remain 

an effective DoS techniques in IPv6 networks. Kempf, Nordmark, and Nikander (2004), and 

Convery and Miller (2004) identified that a host routing table flood would overwrite existing 

entries after reaching the end of the cache. Kempf, et al. introduced a potential router DoS attack 

that is initiated by flooding a subnet with requests to random invalid addresses that invoked a 

neighbor solicitation message never received a reply. 

Broadcast amplification or smurf attacks employ a number of innocent hosts to 

overwhelm a single victim using methods that multiply traffic. For example, if an ICMP ping 

with the spoofed source address of the victim is sent to an all-nodes broadcast address, every 

node on the network would receive the ping request and send the response to the victim at the 

same time. Yang, et al. (2007) identified RFC 2463 which prohibits an ICMP response to 

multicast addresses; however, Zagar, et al. (2007) and Sotillo (2006) argued that not all operating 

systems they tested followed this rule and error notifications may bypass this test. According to 

their research, a smurf attack could be successful if an ICMPv6 packet that generates an error is 

sent to a broadcast address resulting in a flood of error response packets being sent to the victim.


57 

DoS attacks using fragmentation attempt to overwhelm a host by making them unable to 

maintain the packet reconstruction process. Zagar, et al. (2007) and Emre and Ali (2010) 

theorized that sending a large number of fragments to a host can crash the reconstruction buffer 

and lead to a DoS situation. E. Davies, et al. (2007) added that sending a large number of small 

fragments without terminating the last one will increase the effectiveness of the attack. 

IPv6 option headers can also be used to conduct DoS attacks against routers and other 

nodes. Szigeti and Risztics (2004), Sotillo (2006), and E. Davies, et al. (2007) identified the 

effects of flooding the network with hop-by-hop option headers. This type of header must be 

evaluated at each node in the route; however, the node can ignore the option if it is not 

recognized. E. Davies, et al. identified another technique where the router alert option is selected 

that causes the router to inspect the contents of the packet. An attacker who sends a large number 

of options headers forces every node in the route to evaluate each header individually before 

moving on to the next one. This has the potential to prevent the router from addressing legitimate 

traffic while it evaluates the headers from the attack. 

Neighbor discovery DoS attacks. 

Yang, et al. (2007) and other researchers identified several vulnerabilities in the neighbor 

discovery protocol that allowed an attacker to conduct DoS attacks on IPv6 network nodes. This 

includes attacks that exploit flaws in the duplicate address detection, neighbor solicitation and 

advertisement, router solicitation and advertisement, and redirect features. 

Duplicate address detection attacks prevent the victim from obtaining an IPv6 address on 

the network. The techniques used in these attacks are described by Yang, et al. (2007), Szigeti 

and Risztics (2004), Caicedo, et al. (2009), Lindqvist (2006), and Kempf, et al. (2004). A 

duplicate address detection probe is sent when a host assigns a new IPv6 address to an interface.


58 

Any other node already using that IP address will respond and the host will try a different 

address. If an attacker responds to every duplicate address detection probe, the victim will 

eventually believe that all IP addresses are assigned and terminate the address selection process. 

Neighbor solicitation and advertisement attacks either reroute traffic for legitimate hosts 

or cause victims to send traffic to non-existent nodes. The Technique used in the first situation is 

described by Yang, et al. (2007), Vives and Palet (2005), Szigeti and Risztics (2004), and 

Kempf, et al. (2004). In this attack, a neighbor solicitation message is sent with a different source 

address that announces a link-layer address change. Packets for the victim will be sent to the new 

address that is controlled by the attacker. Yang, et al. and Kempf, et al. identified a flaw in the 

neighbor detection feature where an attacker caused a victim to attempt communications with an 

invalid link by responding to neighbor solicitation messages. Additionally, Wu, Hai-xin, Tao, 

Xing, and Jian-ping (2009) and Kim et al. (2007) determined that if an attacker sent spoofed 

ICMPv6 destination unreachable responses to a victim with a spoofed source address, the victim 

would terminate connections with the host at that source address. 

Router solicitation and advertisement attacks can also lead to DoS situations in IPv6 

networks. Yang, et al. (2007), Zagar, et al. (2007), Caicedo, et al. (2009), E. Davies, et al. 

(2007), and Vives and Palet (2005) described an attack to kill the router by sending spoofed 

router advertisements from the router with a zero lifetime. This caused a rewrite of the host’s 

routing table that removed the router from the cache and prevented traffic from reaching the 

router. Yang, et al. and Kempf, et al. (2004) described a different type of attack that sent a 

spoofed router advertisement for a specific IPv6 prefix. The bogus router and prefix was added 

to the host’s routing table and any traffic that meets the rules was sent to the bogus router.


59 

Redirect messages create a DoS situation in an IPv6 network if an attacker initiates a 

spoofed redirect to a non-existent address. The redirect message attack, described by Yang, et al. 

(2007), Wu, et al. (2009), and Kim, et al. (2007), involves an attacker sending a spoofed redirect 

message to a node that originates from the first hop router. Because the redirect originates from a 

trusted router, it is accepted by the host and all traffic destined for the victim is redirected to the 

new address specified by the attacker. 

Man-in-the-middle attacks. 

Man-in-the-middle attacks allow an attacker to intercept or alter communications by 

acting as a gateway or intermediary between two points. The IPv6 protocol is susceptible to the 

same key exchange attacks as in IPv4 networks and there are new attack vectors that exploit IPv6 

router redirects and the neighbor cache. 

Router redirects uses the same technique the router solicitation and advertisement DoS 

attack mentioned on page 58 except the attacker assumes the role of a relay router. Szigeti and 

Risztics (2004), Kim, et al. (2007), Convery and Miller (2004), Kim, et al. (2007), and Kempf, et 

al. (2004) presented techniques used in this attack. An attacker launches a DoS attack against the 

legitimate router using the kill or flood technique. Then, the attacker sends a router 

advertisement to all nodes specifying a router at an address controlled by the attacker. A host 

sends traffic to the new router and the attacker relays the traffic between the two nodes with the 

ability to modify or read the communications. If the attack goes unnoticed, the attacker can 

easily return the legitimate relay to operating status and erase evidence that the network has been 

compromised. 

The host’s neighbor cache stores link-local addresses for neighbors that are available on 

the local-link. Kempf, et al. (2004) and Caicedo, et al. (2009) identified the potential for a


60 

spoofed neighbor cache entry to cause an attacker to intercept traffic destined for another host. 

The attacker sends a link-local neighbor solicitation redirect to an address controlled by the 

attacker. Hosts on the network update their neighbor cache with the new address. When a host 

communicates with the victim, the traffic is sent to a node controlled by the attacker and relayed 

to the legitimate host. 

IPv6 covert channels. 

Covert channels provide a method for malicious users or programs to hide 

communications. The Department of Defense defined covert channels as “communication that 

can be exploited by a process to violate security policy” (Zander, et al., 2007). Covert channels 

may be used by a user to send confidential information to a point outside the security parameter 

of the network or create a hidden command and control channel for botnets or backdoors. 

Warfield (2003) presented a simple example of an IPv6 covert channel that would bypass IPv4 

IDS and firewall devices. The implementation called for installing sshd on the victim, 

configuring a listening address of 2002::, adding the new 

address to the 6to4 interface, and then adding a SSH key to encrypt the traffic. The attacker 

would then be able to communicate covertly using the 6to4 address that was selected. 

Researchers have identified several methods of creating covert channels in IPv6 

communications. Generally, hidden communications are embedded in an unused header field 

that can be one bit or several bits in length. Zander, et al. (2007) identified the IPv4 type of 

service (TOS), do not fragment (DF), TCP urgent pointer, reset segment, or ICMP code fields as 

possible locations to store hidden data in packet flows. 

Graf (as cited by Zander, et al., 2007) Lucena, Lewandowski, and Chapin (as cited by 

Zander, et al., 2007) proposed methods of embedding covert channels into IPv6 extension


61 

headers. For example, Graf suggested that the covert data be encoded in an option header with a 

double zero as the high order bits to specify that the header should be skipped if it is not 

recognized by the host. The option header containing the hidden data would be ignored by 

legitimate nodes; however, the other party in the covert channel could decode the hidden data. 

Trabelsi suggested using the routing header, Graf suggested using the destination options header, 

and Lucena, et al. suggested the use of the hop-by-hop options, authentication, fragment, and 

encapsulating security payload (ESP) headers. 

Covert channels can also use IPv6 for secrete communications. Lindqvist (2006) and 

Girling (as cited by Zander, et al., 2007) proposed methods of modulating the IP address or port 

numbers to hide data. Lindqvist suggested using IPv6 stateless auto-configuration to embed data 

in the 64 bit interface ID. The recipient of the packet will decode the IPv6 source address from 

the received packet and the sender could easily change the interface again to send additional 

secrete information. Girling proposed a similar method using the source and destination port 

numbers. Table 10 lists other possible fields and methods attackers could use to embed covert 

channels in IP communication. 

Table 10. Covert Channels in IP Communications 

Field 

Padding 

TCP Sequence 

Number 

Packet length 

IP ID Number 

Description 

Padding to multiples of 8 octets required for options headers. Encode hidden 

data in padding (E. Davies, et al., 2007). 

Encode hidden data in TCP initial sequence number. Traffic can be bounced 

off a third party using a spoofed source address that generates an error reply 

containing the TCP sequence number (Zander, et al., 2007). 

Modulate the length of a packet to hide data (Girling, 1987, Feb as cited by 

Zander, et al., 2007). 

Encode hidden data in the IP ID number (Rowland, 1997, July as cited by


62 

Field 

Description 


Fragment Offset Encode hidden data in the fragment offset (Rowland, 1997, July as cited by 


TCP Checksum Modulate the checksum and add random data to the packet to correct the 

checksum calculation (Abad, 2001 as cited by Zander, et al., 2007). 

UDP Checksum Encode hidden data in optional UDP checksum (Fisk, 2002, Oct as cited by 


TTL/Hop Limit Encode hidden data in TTL or hop limit field (Lucena, Lewandowski, & 

Chapin, 2005, May as cited by Zander, et al., 2007). 

Timestamp Modulate the lower order bit of the timestamp field by delaying transmissions 

until reaching a specific unit (Giffin, 2002, Apr as cited by Zander, et al., 

2007). 

Packet Timing Modulate the time intervals between sent packets (Padlipsky, Snow, & 

Karger, 1978, Aug as cited by Zander, et al., 2007). 

Packet Loss Artificially losing packets to modulate a hidden data stream (Servetto & 

Vetterli, 2001, June). 

HTTP URL Encode hidden data in URL parameter requests sent by HTTP (Feamster, 

2002, Aug as cited by Zander, et al., 2007). 

HTTP Cookies Encode hidden data in an HTTP cookie (Castro, 2006, May as cited by 


DNS 

Encode hidden data in a DNS server requests to a server controlled by the 

other party (Gil, 2005 as cited by Zander, et al., 2007). 

VoIP 

Modulate the low order bit of the VoIP RTCP protocol (Mazurczyk & 

Kotulski, 2006, Sept as cited by Zander, et al., 2007). 

ICMP 

Encode data in the ICMP payload (daemon9, 1997, Sept as cited by Zander, et 

al., 2007). 

SSH 

Use SSH over HTTP to encode hidden data (Padgett, 2001 as cited by Zander, 

et al., 2007).


63 

Security control bypass. 

IPv6 traffic can bypass security controls like firewalls and IDS devices by exploiting 

vulnerabilities in the protocol. When this occurs, malicious traffic that would have been blocked 

at the security perimeter enters the network and compromises internal systems. Warfield (2003) 

identified possible scenarios that included; IPv4 security devices that are unable to inspect TCP 

and UDP packets in SIIT, IPv6 security devices that are unable to inspect IPv4 and protocol 41 

packets, and Teredo traffic that bypasses firewalls by design. Szigeti and Risztics (2004) 

identified IPv6 stateless auto-configuration as a threat that allowed internal attackers to control 

the address space. Zagar, et al. (2007) and Kim, et al. (2007) identified a method of hiding port 

numbers from security devices using fragmentation. Port numbers are not read by security 

devices if option headers move the TCP or UDP header to a fragmented packet because 

intermediate nodes do not reassemble the fragments in IPv6. Convery and Miller (2004) 

described a method to overlap fragments so that the second fragmented packet overwrites the 

data in the first at the destination node. Zagar, et al., Caicedo, et al. (2009), E. Davies, et al. 

(2007), and Convery and Miller described a method of sending a packet to a restricted internal 

node by including a routing header that specifies an unrestricted internal node as a stop on the 

route. This would establish a path that relays traffic from the unrestricted node to a restricted 

node on the same network. 

IPv6 worms. 

The large address space was expected to limit worm propagation in IPv6 networks; 

however, researchers have identified techniques that increase the success of worm attacks. 

Yangui, Xiangchun, Jiachun, and Huanyan (2009) outlined traditional worm propagation 

techniques that included DNS and search engine queries for valid IP addresses, scans for


64 

vulnerable internal nodes, and random internal network scans after an internal node has been 

compromised. Yangui, et al. suggested that an IPv6 worm attempting to locate vulnerable 

addresses would use traditional techniques to discover external addresses and then employ new 

methods to limit the address range after compromising an internal node. 

Embedded functionality combined with the end-to-end nature of the IPv6 protocol can 

increase the success of worms in an IPv6 network. Zheng, Liu, Guan, Qu, and Wang (2007) and 

J. Yang (n.d.) described how the potential address space of 2 64 possible addresses can be reduced 

down to a manageable population by listening for Windows service announcements, neighbor 

and router discovery packets, initiating multicast pings, and relying on the tendency for 

administrators to assign other addresses using a similar schema. Additionally, worm propigation 

techniqes can be further enhanced by increasing the number of vulnerable nodes or increasing 

bandwidth to increase the rate of scanning activtiy. Zheng, et al. presented a simulation where all 

live addresses on a small IPv6 network were captured within three seconds using the neignbor 

discovery protocol. J. Yang presented a detailed simulation with a 75,000 population size that 

compared different worm propigation techniques using the enhanced methods. In the study, all 

nodes in an IPv4 network were infected using traditional techniques in five seconds. If the same 

techniques were used in an IPv6 network, it would take 22,000 years to infect all nodes; 

however, a gigabit network connection reduced this to 40 years, dense address assignments 

reduced this rate to seven days, using DNS reduced this to one day, and using the local cache and 

neighbor discovery protocol resulted in full infection within six hours. 

IPv6 transition mechanisms. 

The implementation of IPv6 transition mechanisms has security implications for IPv6 

networks. Further research into transition mechanism vulnerabilities is needed; however, limited


65 

discussions are available from a small number of sources. Convery and Miller (2004) argued that 

transition mechanisms may allow unauthorized traffic to traverse the internal network, forge 

packets to hide the origin of the traffic, and launch DoS attacks on internal targets. Szigeti and 

Risztics (2004) and Zagar, et al. (2007) noted that dual-stack hosts are susceptible to both IPv6 

and IPv4 attack. S. Lee, et al. (2002) discussed the risk of DoS attacks with BIA and BIS address 

pooling. Hagino and Yamamoto (2001) found that TRT could act as an open relay for attackers 

that bypasses traffic filtering controls. A slightly more detailed discussion of vulnerabilities was 

available for the 6to4 and Teredo transition mechanisms. 

Teredo and 6to4 are tunneling mechanisms that are generally susceptible to DoS and 

packet injection attacks. Zagar, et al. (2007), Szigeti and Risztics (2004), and Gilligan and 

Nordmark (2000) found that packets sent through a tunnel can bypass filters and lead to DoS 

attacks on both IPv4 and IPv6 nodes. Durand, et al. (2001) described a DoS attack that was 

launched against a Tunnel-Broker by requesting a large number of tunnels. Szigeti and Risztics 

and Caicedo, et al. (2009) outlined a packet injection attack that allowed an external user to send 

traffic to an internal address through a tunnel. 

The 6to4 transition mechanism tunnels IPv6 traffic over traditional networks using a 

network of 6to4 relays and routers that encapsulate and decapsulate packets into the appropriate 

protocol. Savola and Patel (2004) and E. Davies, et al. (2007) concluded that attack vectors result 

from the implied trust between hosts, 6to4 routers, and relays. IPv6 data contained within the 

encapsulated 6to4 packets is not controlled by the security devices operating in the traditional 

network. Savola and Patel found that this could lead to DoS and spoofing attacks, traffic 

laundering, and service theft. Additionally, Savola and Patel and Cooper and Yen (2005) 

outlined methods of sending malicious packets into a network using the 6to4 mechanism. A 6to4


66 

packet can be sent to a link-local IPv6 address using a valid IPv4 destination and spoofed, but 

valid IPv4 and IPv6 source. An internal user could broadcast to all nodes on a network by 

sending packets to the 6to4 router using an IPv4 broadcast address like 8.0.0.255 with IPv6 

destination 2002:0800:00FF::AAAA. An external user could also broadcast ICPM error 

messages to all internal nodes by sending packets to a valid but non-existant IPv6 address on a 

network with an IPv6 broadacst address as the source. 

Teredo vulnerabilities are identified in the research by Huitema (2006) and included DoS, 

man-in-the middle, and spoofing risks. First, the open firewall port and protocol requirements of 

the protocol decrease the effectiveness of security controls overall. Second, an attacker can send 

routing advertisements for a Teredo relay that they control and intercept traffic from hosts using 

the relay. Third, spoofed source addresses allow the attacker anonymity. Finally, several methods 

of Teredo based DoS attack methods are identified by Huitema and Kim, et al. (2007). This 

includes setting up a dead-end Teredo relay or server, flooding hosts with Teredo peer cache 

entries, flooding Teredo servers with traffic, and reflection using Teredo to relay attacks between 

the protocols. 

IPv6 vulnerabilities and attack vectors are critical elements of the digital forensic process. 

Analysts and investigators must understand the methods and techniques used by attackers in 

order to determine how an event occurred. IPv6 protocol vulnerabilities and exploits are similar 

to IPv4 and are well represented in the available research. Information about vulnerabilities in 

transition mechanisms is limited and it is likely to be the area that provides the highest exposure 

to risk. No research was located that discussed how the vulnerabilities discovered in IPv6 would 

be investigated using forensic analysis.


67 

Summary of IPv6 Forensic Research and Identified Gaps 

The technical research into IPv6 covers the protocol, transition mechanisms, operating 

system support, security vulnerabilities, and attack vectors. Nikkel (2007) and other researchers 

defined the IPv6 protocol and provided a basic guide to investigators. General IPv6 transition 

mechanisms were described by Jamhour and Storoz (2002), Tantayakul, et al. (2008), Mackay, et 

al. (2003, May-June), Afifi and Toutain (1999), and Gilligan and Nordmark (2000) while Wei, et 

al. (2009) focused on dual-stack; Durand, et al. (2001), Visoottiviseth and Bureenok (2008),and 

S. M. Huang, et al. (2005) focused on 6to4, Tunnel-Broker, ISATAP, or Teredo tunneling 

mechanisms; and Carpenter and Jung (1999), Nordmark (2000), Tsuchiya, et al. (2000), S. Lee, 

et al. (2002), Kitamura (2001), Hagino and Yamamoto (2001),and AlJa'afreh, et al. (2008) 

focused on SIIT, NAT-PT, BIS, BIA, SOCKS64, TRT, or gateway based protocol translation 

mechanisms. Windows IPv6 support is defined by Tulloch, et al. (2010), and J. Davies (2008) to 

include support for Teredo, ISATAP, 6to4, and dual-stack. Linux, FreeBSD, UNIX, and Apple 

MAC operating systems provide IPv6 support for 6to4, dual-stack, and tunnels that is explained 

in various online vendor manuals. IPv6 vulnerabilities and attack vectors including 

reconnaissance, DoS, man-in-the-middle, covert channel, security control bypass, worm, and 

transition mechanism attacks are described by Zagar, et al. (2007), Convery and Miller (2004), 

E. Davies, et al. (2007), X. Yang, et al. (2007), Kempf, et al. (2004), Zander, et al. (2007), J. 

Yang (n.d.), Savola and Patel (2004), and Huitema (2006). Overall, the available research 

provides adequate information for the implementation and operation of an IPv6 network. There 

is a need for research that addresses the technical implications and considerations for an IPv6 

network investigation, provides examples of IPv6 attacks and investigations to be used as a guide


68 

for creating an applicable procedural model, and develops new information about the security 

factors in transition mechanisms that could be utilized in criminal acts. 

The research into forensic investigation addresses evidence admissibility that is based on 

the collection, analysis, and presentation processes. General forensic models have been proposed 

by Shin (2008), Cohen (2009), Ciardhuáin (2004), Carrier and Spafford (2003), Carr, et al. 

(2002), Electronic crime scene investigation: A guide for first responders (2001), H. C. Lee, 

Palmbach, and Miller (2001), Casey (2000), Palmer (2001), and Mandia and Prosise (2001). 

Sommer (1999) proposed methods of collecting and handling network based evidence. Digital 

evidence handling, processing and analysis techniques are proposed by Broucek and Turner 

(2004), Kerr (2005, Jan), Lan, et al. (2005), and Losavio (2005) while Schroeder (2005), the 

Fraud Examiners Manual (2008), and Carrier and Spafford (2003) proposed process models for 

the physical investigation of digital crimes. Nikkel (2007) presented a basic procedural guide for 

conducting IPv6 investigations while Tseng, et al. (2006), Y. Lee, et al. (2007), and S. Q. Huang, 

et al. (2009) addressed IPv6 IDS devices. The discovered research establishes ad-hoc processes 

that must be combined to address the needs of investigators, analysts, and prosecutors. There is a 

need for defining the details of a process that supports the complex needs of an IPv6 

investigation, establishing a model that helps establish IPv6 network forensics as a formal 

scientific discipline, and developing a method to distil complex network analysis into 

information that non-technical judges and juries can understand. 

The IPv6 protocol creates unique considerations for forensic analysts and investigators 

that have not been adequately addressed in the research. Investigators must understand the 

technology as it relates to their specific needs; however, the available research is focused on 

implementers and operators. Prosecutors are required to present evidence that is founded in a


69 

formal scientific discipline; however, IPv6 network forensics remains a new science that lacks 

the necessary components to address the complexity of investigating distributed network 

environments. As IPv6 networks become more common, it will be important to address the 

unique needs of IPv6 investigations in formal academic research.


70 

Chapter 3 – Methodology 

This study employed the qualitative method based on the active research (AR) 

methodology defined by Baskerville (1999). Additionally, the process consultation form was 

selected that utilized a reflective process model, fluid structure, and expert involvement to 

develop scientific knowledge within the IPv6 discipline (Baskerville, 1999, p. 10). The AR 

methodology complemented the interpretivist epistemology of the researcher and provided an 

effective framework to study complex transitional networks where little prior research has be 

conducted. 

Characteristics of Action Research 

Action research methods advance the perspective that complex information systems can 

only be understood as an entire system and the best research studies observe the effects of the 

changes within a system (Baskerville, 1999, pp. 3-4). IPv6 transition networks are affected by a 

variety of hardware and software systems; therefore, AR provided a useful framework for 

addressing the core research problem in the study. Action research includes the researcher as an 

active participant in the process and involves an interaction between the participants in the study 

and the client system (Byrne, 2005, p. 10; Järvinen, 2007, pp. 1,15; Susman & Evered, 1978, pp. 

1,8). It allows the researcher to experiment with different theories applied to real situations 

(Avison, Lau, Myers, & Nielsen, 1999, p. 2; Susman & Evered, 1978, p. 18). This approach 

produced actionable and useful results for forensic investigators and analysts in the field because 

the participatory process utilized the expertise of the researcher to address the root cause of the 

research problem. Action research is problem centric; designed to holistically create knowledge 

to guide future practices; and involves action, data creation, analysis, and modification in an 

evolving research process (Baskerville, 1999, p. 9; Järvinen, 2007, p. 15; Susman & Evered,


71 

1978, p. 9). This facilitated a deep and relevant analysis of IPv6 transition networks that were 

affected by a diverse set of unknown variables in practical settings. 

The active research framework consists of five iterative process steps centered around the 

client/system infrastructure. The client/system infrastructure is the research environment where 

the actions will occur (Baskerville, 1999, p. 14). The process steps are diagnosing, action 

planning, action taking, evaluating, and specifying learning (Baskerville, 1999, p. 15; Susman & 

Evered, 1978, p. 7). Figure 6 illustrates the active research process. 

Figure 6. Active Research Process Model (Baskerville, 1999, pp. 14-16) 

Client/System Infrastructure 

The client/system infrastructure defines the environment where the research process takes 

place and includes the resources utilized, information about the participants in the study,


72 

boundaries and constraints, entry and exit points, and responsibilities (Baskerville, 1999, pp. 14 

15). This study required an environment where IPv6 transitional mechanisms could be 

configured, various nodes running different operating systems were able to communicate, and 

network traffic could be captured and analyzed. 

Environment 

The primary research environment consisted of a virtual network of nodes running on 

Oracle Virtualbox Version 4.0.2 Release 69518 virtualization software ("Virtualbox", n.d.). This 

software was running on a Lenovo T410 laptop with the 64 bit edition of Microsoft Windows 7 

Ultimate Edition. Oracle Virtualbox provided a virtual environment for 32 or 64 bit operating 

system nodes, local console access, and network interconnection. Nodes in the virtual network 

could be configured for local communications to simulate a LAN, local with a public gateway 

that simulated a NAT environment, and pass thought mode to simulate a direct connection to the 

Internet. Public IPv4 Internet connectivity on the host was provided by an AT&T 3G wireless 

card build into the Lenovo Laptop and was shared with the virtual nodes when needed. 

Additionally, snapshots of the virtual hard drives were taken at regular intervals so that the base 

operating system configurations could be restored easily. 

The secondary research environment consisted of a single 32 bit Ubuntu Linux node 

running on a virtual private server (VPS) hosted by Linode ("Linode", n.d.). This VPS node has 

access to 512MB of RAM and 16GB of hard drive space. The network environment provided a 

dedicated IPv4 address to the Internet for remote testing of the nodes in the primary research 

environment.


73 

Resources 

This study utilized Windows, Linux, FreeBSD, and UNIX operating system nodes. The 

target nodes observed in the study consisted of the Microsoft Windows 2003 and 2008 server 

editions, Windows 7, Vista, and XP workstation editions, the Ubuntu and CentOS Linux 

distributions, FreeBSD, and Solaris UNIX ("CentOS", n.d.; FreeBSD", n.d.; Oracle Solaris", 

n.d.; Ubuntu", n.d.),. These operating systems were selected for use in the study because they 

represented a large share of the total installs in the market ("DistroWatch.com", n.d.). Each node 

was configured with a base installation of the operating system using the default options and all 

required and optional updates and patches applied through January 4, 2011. The research nodes 

were used to run the tools in the study and consisted of a 32 bit version of the Ubuntu and 

Backtrack Linux distributions ("BackTrack Linux", n.d.). Backtrack was selected because many 

of the tools were preconfigured in the default installation and Ubuntu provided an environment 

to run any other security tools that were not available on the Backtrack distribution. Appendix B 

provides a detailed listing of the operating system versions, network interface card details, and 

the Virtualbox configuration settings that defined the simulated environment where the operating 

systems were running during the study. 

Tools were selected to generate, capture, and analyze IPv6 traffic at each node. Packet 

captures for use in the traffic analysis was performed using TCPdump on Linux and FreeBSD 

nodes, Winpcap that is included as part of the Wireshark installation on Microsoft Windows 

nodes, and the Snoop tool that is a native install on the Solaris node ("TCPdump", n.d.; 

Winpcap", n.d.). Traffic analysis was performed using the Wireshark tool running on the 

Backtrack Linux research node ("Wireshark", n.d.). Packet generation tools were used to conduct 

network scanning, launch exploits, and forge packets for analysis. Nmap and Halfscan6 were


74 

used to scan the IPv6 network. Metasploit, THC-IPv6, and the Netcat version that is part of the 

Nmap installation were used to launch IPv6 exploits against the target nodes in the study 

("Halfscan6", n.d.; Metasploit", n.d.; Nmap", n.d.; THC-IPv6", n.d.). Netdude, TCPReplay, 

Ostinato, and Scapy were used to forge IPv6 packets to launch exploits that could not be 

generated by other tools ("Netdude", n.d.; Ostinato", n.d.; Scapy", n.d.; TCPReplay", n.d.). Table 

11 lists the nodes and tools that were used in the study. 

Table 11. Research Nodes, Target Nodes, and Tools Used in the Study 

Node Tool Version Source 

Target Node 1: Microsoft Windows Server 2008 R2 Datacenter Edition v6.1 (64-bit) 

Target Node 2: Microsoft Windows Server 2003 R2 Enterprise Edition v5.2 SP2 (64-bit) 

Target Node 3: Microsoft Windows 7 Enterprise v6.1 (64-bit) 

Target Node 4: Microsoft Windows Vista Enterprise v6.0 SP2 (64-bit) 

Target Node 5: Microsoft Windows XP Professional v5.1 SP3 (32-bit) 

Wireshark 1.4.3 ("Wireshark", n.d.) 

Winpcap 4.1.2 ("Winpcap", n.d.) 

Netcat 5.21 ("Netcat", n.d.) 

Gogoc 1.2 ("gogoCLIENT", n.d.) 

Target Node 6: Linux Ubuntu Desktop v10.10 (64-bit Kernel v2.6.35) ("Ubuntu", n.d.) 


Tcpdump 4.1.1 ("TCPdump", n.d.) 

Miredo 1.2.3 ("Miredo", n.d.) 



Target Node 7: CentOS v5.5 (64-bit Red Hat Base Kernel v2.6.18) ("CentOS", n.d.) 



Miredo 1.2.3 ("Miredo", n.d.) 

Gogoc 1.2 ("gogoCLIENT", n.d.)


75 

Node Tool Version Source 


Target Node 8: FreeBSD v8.1 (64-bit) ("FreeBSD", n.d.) 


Gateway6 6.0 /usr/ports/net/gateway6 

Miredo 1.2.2 /usr/ports/net/miredo 


Target Node 9: Oracle Solaris 11 Express v5.11 (64-bit) ("Oracle Solaris", n.d.) 

Snoop N/A Native 

Research Node 1: Linux Backtrack v4 R2 (32-bit Kernel v 2.6.35.8) ("BackTrack Linux", n.d.) 

Scapy 2.1-bt1 ("Scapy", n.d.) 

Metasploit 3.5.1 svn 11780 ("Metasploit", n.d.) 

THC-IPv6 1.2-bt0 ("THC-IPv6", n.d.) 

Nmap 5.35-bt0 ("Nmap", n.d.) 



Netdude 0.3.3 ("Netdude", n.d.) 

TCPreplay 3.3.1 ("TCPReplay", n.d.) 

Netcat 5.35DC1 ("Netcat", n.d.) 

Research Node 2: Linux Ubuntu Desktop v10.10 (32-bit Kernel v2.6.35) ("Ubuntu", n.d.) 

Ostinato 0.3 ("Ostinato", n.d.) 


Halfscan6 0.2 ("Halfscan6", n.d.) 


Research Node 3: Linux Ubuntu VPS v10.10 (32-bit Kernel v2.6.32) ("Linode", n.d.) 


Nmap 5.21 ("Nmap", n.d.) 

THC-IPv6 1.2 ("THC-IPv6", n.d.) 

Halfscan6 0.2 ("Halfscan6", n.d.) 

Scapy 2.1.1 ("Scapy", n.d.) 

Gogoc 1.2 ("gogoCLIENT", n.d.)


76 

Native IPv6 transition mechanisms were used when they were provided as part of the 

operating system. The Teredo, ISATAP, and 6to4 mechanisms are integrated into the Windows 

operating system. The Linux, FreeBSD, and Solaris nodes support dual-stack and 6to4 

mechanisms in their native configurations and require third-party components for Teredo and 

ISATAP. Miredo was used on the Linux and FreeBSD nodes to support Teredo; however, 

Teredo support for the Solaris node was not located at the time of this study ("Miredo", n.d.). 

ISATAP support for the Ubuntu Linux node was provided by the isatapd client. The researcher 

was unable to install ISATAP functionality on the CentOS, FreeBSD, or Solaris nodes. IPv6 

tunneling support for all nodes was setup using an anonymous account on Freenet6 with the IPv6 

client provided by gogoNet ("gogoCLIENT", n.d.). Appendix B lists the installation and 

configuration commands used to install the clients. 

Participants 

The researcher worked from the interpretivist epistemology and was also the participant 

in the study. Interpretivist thinking allows for more than one solution to a problem and is 

appropriate for complex IPv6 traffic analysis where there may be multiple solutions to a 

problem. The researcher has twelve years of experience administering and using the Microsoft 

Windows operating system, three years of experience creating and managing virtual networks, 

and one year of experience administering and using the Linux, FreeBSD, and Solaris operating 

systems. Additionally, the researcher has completed the course requirements for a Master’s 

degree in information assurance focused in network forensics which provides the foundation for 

the traffic analysis and tools used in the study.


77 

Boundaries 

This study is limited by the resources available to the researcher. Academic and open 

source licensing allowed the selected operating systems to be included in the study; however, the 

Apple operating system could not be included because the researcher did not have access to a 

machine running the operating system. Additionally, time limitations for the study did not permit 

the testing of every available operating system that supported IPv6. The size of the network and 

the number of nodes running at the same time was limited by the available four gigabits of RAM. 

Finally, the transition mechanisms and tools that were included in the study had to support IPv6 

and either be native to the operating system or available as third-party installations. 

The scope of the research problem was narrowly defined around likely IPv6 network 

vulnerabilities. The study focused on network protocol based exploits and not on vulnerabilities 

in network services running on physical nodes. Additionally, the study did not address denial of 

service attacks. 

Entry and Exit Points 

Virtual desktops and shared network drives were the primary entry and exit points in the 

study. The Oracle Virtualbox hypervisor provided a virtual desktop for each running node where 

the researcher could interact with the operating system and tools. Additionally, Virtualbox 

supported access to shared folders on the host to facilitate the sharing of information between the 

nodes. 

Responsibilities 

The researcher had a responsibility to protect third-party networks that were utilized in 

the study. This included the Linode VPS network, the AARNet IPv6 tunneling network, the 

public Teredo, ISATAP, and 6to4 relays, and the AT&T 3G network used to provide Internet


78 

access for the host. The exploits and traffic in the study were designed to be low flow and target 

the virtual nodes running on the researcher’s laptop to minimize the risks to these networks. 

Process Step 1: Diagnosing 

The diagnosing process step identifies the holistic research problems and underlying 

assumptions that guide the process actions (Baskerville, 1999, p. 15). 

Research Problems 

The primary research problem in the study was: what is the nature of IPv6 traffic that 

may be traversing traditional IPv4 networks? The research sub-problems were structured around 

the five phases of a network attack outlined by Bejtlich (2004) and were designed to present a 

framework for analyzing or investigating IPv6 traffic in transitional networks. Table 12 outlines 

the primary research problem and sub-problems for the study. 

Table 12. Primary Research Problem and Sub-Problems 

What is the nature of IPv6 traffic that may be traversing traditional IPv4 networks? 

1. Reconnaissance • What methods can be used to enumerate IPv6 addresses and services 

in a transitional network? 

• What is the context of IPv6 traffic produced by nodes in an IPv4 

network? 

2. Exploitation • What methods can be used to attack the network topography in a 

transitional network? 

• What are the characteristics of malicious and suspicious traffic that 

traverse IPv4 networks using the IPv6 protocol? 

3. Reinforcement What methods can be used to obfuscate an attack in a transitional network 

and how could the true source be determined? 

4. Consolidation What methods can be used to create a persistent commutations channel in 

a transitional network and how could that channel be detected? 

5. Pillage What additional risks should be considered in a transitional network?


79 

Assumptions 

The interpretivist epistemology assumed that there is more than one way to solve the 

research problems. For example, the researcher attempted to enumerate the IPv6 address and 

services within the network using the available tools; however, there is likely other ways to 

gather the same information. Additionally, an unsuccessful exploit or enumeration of a node 

within the study did not imply that another method could not yield a positive result. Table 13 

lists the research assumptions for each of the five sub-problem categories. 

Table 13. Research Assumptions 

What is the nature of IPv6 traffic that may be traversing traditional IPv4 networks? 

1. Reconnaissance – Network Enumeration and Context 

• Nodes behind a NAT will be protected from network scanners. 

• Operating systems with IPv6 enabled by default will have exposed services and 

emanate IPv6 packets into the IPv4 network. 

• Nodes with public IPv6 addresses using transitional networks will have publically 

exposed services. 

2. Exploitation – Topography Attacks and Context 

IPv6 traffic flows and addressing can be modified remotely using protocol attacks. 

3. Reinforcement – Obfuscation and Sourcing 

• Privacy extensions, redirects, and address auto-configuration can be used to obfuscate 

traffic from an attacker and it will not be possible to determine the true source. 

• Fragmentation can be used to obfuscate the port or source address for a traffic flow. 

• Multicast or anycast can be used to obfuscate the source or destination node in an 

attack. 

4. Consolidation - Persistent Channels and Detection 

a. A remote command shell can be created through a transitional network over IPv6 

using common tools. 

5. Pillage – Additional Risks 

a. Undetected covert channels will be the primary additional risk.


80 

Process Step 2: Action Planning 

The action planning process step outlines the procedures necessary to address the 

research problems in light of the underlying assumptions and are designed to lead to the future 

state in the study (Baskerville, 1999, p. 15). Additionally, this step identifies the approach for 

addressing changes to the procedures as observations are made. The procedures used in the study 

were designed to facilitate an iterative framework to address the full context of the research 

problems within the five phases of a network attack. Figure 7 illustrates this framework. 

Reconnaissance Exploitation Reinforcement Consolidati Pillage 

on 

Behind NAT Exposed IPs Behind NAT Exposed IPs 

Network 

Mapping 

Rogue Devices 

Obfuscation Backdoors Covert 

Channels 

Addresses Services/ Routers/ Nodes/ Privacy Redirects Fragments Multicast 

Ports Relays Clients Extensions 

Base/ Base/ Base 6 Enabled 6 Enabled 6 Enabled 6 Enabled 6 Enabled 

6 Enabled 6 Enabled Win 28K Win 28K Win 28K Win 28K Win 28K Win 28K 

Win 28K Win 28K Win 23K Win 23K Win 23K Win 23K Win 23K Win 23K 

Win 23K Win 23K Win 7 Win 7 Win 7 Win 7 Win 7 Win 7 

Win 7 Win 7 Win Vista Win Vista Win Vista Win Vista Win Vista Win Vista 

Win Vista Win Vista Win XP Win XP Win XP Win XP Win XP Win XP 

Win XP Win XP Lin Ubuntu Lin Ubuntu Lin Ubuntu Lin Ubuntu Lin Ubuntu Lin Ubuntu 

Lin Ubuntu Lin Ubuntu Lin CentOS Lin CentOS Lin CentOS Lin CentOS Lin CentOS Lin CentOS 

Lin CentOS Lin CentOS FreeBSD FreeBSD FreeBSD FreeBSD FreeBSD FreeBSD 

FreeBSD FreeBSD Solaris Solaris Solaris Solaris Solaris Solaris 

Solaris Solaris 

Local Local Teredo Local Local Local Local Local 

Teredo Teredo ISATAP Teredo Teredo ISATAP Teredo 

ISATAP ISATAP 6to4 ISATAP ISATAP 6to4 ISATAP 

T-Broker T-Broker T-Broker T-Broker T-Broker 

6to4 6to4 6to4 6to4 6to4 

Wireshark Nmap Miredo OS OS THC-IP6 Netdude OS Netcat 

Nmap Halfscan6 Netdude Scapy OS 

Metasploit OS TCPreplay 

THC-IP6 

OS 

Halfscan6 

OS 

Figure 7. Action Planning Process Tree


81 

Procedures 

The reconnaissance phase of an attack may occur from inside and outside the network; 

therefore, the research procedures were defined to mirror tests for victim nodes that are 

publically exposed and protected by a NAT device. The tests were designed to identify network 

mapping techniques that attackers may use to identify addresses and services to target in the next 

stage of the attack. The same tests and procedures were duplicated for each operating system and 

transition method covered in the scope of the study. Additionally, each operating system was 

tested in its base configuration and a state configured with a full installation of IPv6 services. 

The testing procedures for the reconnaissance phase were: 

• Enumerate IPv6 addresses from outside the network for all operating systems in the base 

configuration and all transition mechanisms. 

• Enumerate IPv6 addresses from inside the network for all operating systems in the base 

configuration and all transition mechanisms. 

• Enumerate IPv6 addresses from outside the network for all operating systems in the fully 

configured configuration and all transition mechanisms. 

• Enumerate IPv6 addresses from inside the network for all operating systems in the fully 

configured configuration and all transition mechanisms. 

• Enumerate IPv6 services and ports from outside the network for all operating systems in 

the base configuration and all transition mechanisms. 

• Enumerate IPv6 services and ports from inside the network for all operating systems in 

the base configuration and all transition mechanisms. 

• Enumerate IPv6 services and ports from outside the network for all operating systems in 

the fully configured configuration and all transition mechanisms.


82 

• Enumerate IPv6 services and ports from inside the network for all operating systems in 

the fully configured configuration and all transition mechanisms. 

The exploitation phase testing procedures were duplicated for exposed nodes, NAT 

protected nodes, each operating system and transition mechanism defined in the scope of the 

study. This phase focused on network exploits that established rogue relays, routers, or client 

nodes. Each operating system was tested in its base state and with IPv6 services fully configured. 

The testing procedures for the exploitation phase were: 

• Assign an address to a node running any of the operating systems with IPv6 services 

configured using a Teredo, ISATAP, or 6to4 router from outside the network. 

• Assign an address to a node running any of the operating systems with IPv6 services 

configured using a Teredo, ISATAP, or 6to4 router from inside the network. 

• Communicate with a node running any of the IPv6 configured operating systems over 

any of the transition mechanisms from a rogue node operating outside the network. 

• Communicate with a node running any of the IPv6 configured operating systems over 

any of the transition mechanisms from a rogue node operating inside the network. 

The reinforcement phase of the testing procedures attempted to obfuscate the traffic using 

privacy extensions, redirects, fragments, and multicast. Each operating system was tested will 

IPv6 services fully configured for each possible transition mechanism. The testing procedures for 

the reinforcement phase were: 

• Obfuscate the source address in a two-way communication channel using IPv6 privacy 

extensions for all of the IPv6 configured operating systems and transition mechanisms.


83 

• Obfuscate the source address in a two-way communication channel using IPv6 redirects 

to redirect traffic for all of the IPv6 configured operating systems and transition 

mechanisms. 

• Obfuscate the payload in a two-way communication channel using IPv6 fragments for all 

of the IPv6 configured operating systems and transition mechanisms. 

• Obfuscate the destination address in a two-way communication channel using IPv6 

multicast or anycast addressing for all of the IPv6 configured operating systems. 

The consolidation and pillage phases focused on establishing backdoors and covert 

channels. At this stage of the exploitation, the attacker has control of the victim node; therefore, 

the operating systems and transition mechanisms becomes irrelevant. The testing procedures in 

these phases focused on sampling possible techniques used by attackers. The testing procedures 

for the consolidation and pillage phases are: 

• Establish a persistent backdoor to a node over IPv6. 

• Send data from the victim node using a covert channel. 

Approach for Change 

Procedures were defined around a single tool or technique and subsequent iterations 

changed the tool or technique until a positive result was reached. For example, if the Nmap tool 

was unable to map the address of the Solaris target node during the reconnaissance test phase, 

another testing iteration was performed using the Metasploit tool. 

Process Step 3: Action Taking 

The action taking process step involved the implementation of the action planning 

procedures and the recording of observations (Baskerville, 1999, pp. 15-16). The observations


84 

were collected and reported in chapter 4 of the study using matrixes similar to the sample 

displayed in Table 14. 

Table 14. Sample Data Matrix 

OS Local Teredo ISATAP TBroker 6to4 

28K 

23K 

7 

Vista 

XP 

Ubuntu 

CentOS 

FreeBSD 

Solaris 

Process Step 4: Evaluating 

The evaluating process step analyzes the outcomes of the actions taken in light of the 

assumptions and outlines the next steps in the study (Baskerville, 1999, p. 16). The iterative 

process step for each procedure was complete if a favorable outcome was reached. The 

assumptions were adjusted to reflect the new knowledge and an additional iteration occurred if 

necessary. 

Outcomes 

Observations and outcomes in the study were determined based on the output from the 

packet captures and the commands run from the research or target nodes. The reconnaissance 

testing phase collected the output of the tools run against the target nodes to determine if the 

IPv6 addresses and services were successfully mapped. The rogue router testing measured the 

output of the ipconfig or ifconfig commands to determine if the router successfully configured an


85 

IPv6 address. The rogue node testing procedures captured packet level details on the target node 

to determine if the victim accepted the unsolicited traffic. The reinforcement, consolidation, and 

pillage phases captured and analyzed packet level details received by the research and target 

nodes to determine a successful outcome. 

Next Steps 

Each testing procedure was performed using a tool or technique selected by the 

researcher. The procedure was repeated using a different tool or technique when the first test did 

not yield a successful outcome. The procedure iterations were terminated when a successful 

outcome for a test was not reached and the researcher was unaware of any additional techniques 

to generate the expected results. 

Process Step 5: Specifying Learning 

The specifying learning process step detailed the lessons learned in the current iteration 

and identified additional knowledge that was needed to fully address the research problem 

(Baskerville, 1999, p. 16). An observation summary statement was constructed at the conclusion 

of each testing procedure. These statements were used to address the specific research subproblems. 

Finally, the core research problem was addressed by listing the types of IPv6 traffic 

that may be traversing a transition network and techniques that may be used to identify the nature 

of that traffic.


86 

Chapter 4 –Analysis and Results 

Observations derived from the research were recorded to address the nature of IPv6 

traffic that may be traversing transitional networks. The observed results and lessons learned 

were structured around the five phases of a network attack that included address and service 

enumeration in the reconnaissance phase, rogue nodes in the exploitation phase, obfuscation in 

the reinforcement phase, backdoors in the consolidation phase, and covert channels in the pillage 

phase (Bejtlich, 2004). These sections were further delineated into individual procedures 

designed to address each of the research sub-problems with results that indicated the tool or 

technique that was used to produce a positive result. 

Reconnaissance 

The reconnaissance phase of this study addressed tools and techniques that could be used 

to enumerate IPv6 addresses and services in a transitional network. Very few tools were found 

that supported IPv6 address and service scanning and none of the tools supported address sweeps 

to discover unknown addresses on a remote network. Address and service enumeration was 

attempted from outside the network using Nmap, Ping6, the THC-IPv6 implementation6 

function, and Halfscan6. The Nmap tool performed a port scan of an address using TCP or UDP 

connection requests while the other tools utilized ICMPv6. Additional tools and techniques were 

discovered to scan nodes from inside the network on the local-link. This included sniffing the 

network traffic using Wireshark; neighbor discovery tools like IP neigh, the THC-IPv6 detectnew-ip6 

function, the Metasploit module ipv6_neighbor and 

ipv6_neighbor_router_advertisement; and multicast ping tools like ping6, the THC-IPv6 alive6 

function, and the Metasploit module ipv6_multicast_ping. Table 15 lists the tools employed in


87 

the reconnaissance phase, the function names that are referenced in the results tables, and the 

command sequences employed in the tests. 

Table 15. Employed Reconnaissance Tools 

Tool Function Commands 

Native Ping6(A) 

Ping6(MC) 

IP neigh 

>ping6 

>ping6 -I ff02::1 

>ip neigh 

Sniffing a Sniffing >wireshark 

Nmap Nmap(A) >nmap -6 

>nmap -6 -Pn 

>nmap -6 -PA 

>nmap -6 -PS 

THC-IPv6 a DetNew6 >./detect-new-ip6 

Alive6 >./alive6 

Imp6(A) >./implementation6 

Metasploit a 6Neigh Module= auxiliary/scanner/discovery/ipv6_neighbor 

6MCPing 

6RA 

Module=auxiliary/scanner/discovery/ipv6_multicast_ping 

Module= auxiliary/scanner/discovery/ipv6_ 

neighbor_router_advertisement 

Halfscan6 b Halfscan6 >./halfscan6 

Note. a The tool provides functionality that is designed only for local-links. 

b 

The tool did not function properly for any of the tests for unknown reasons. 

Node interface addresses. 

The assigned interface addresses were recorded for each node at various points in time 

during the study. Detailed IP address and MAC assignments for the local-link, 6to4, Teredo, 

Tunnel-Broker, and ISATAP interfaces were recorded in Appendix B. Table 16 lists a summary 

of the details that includes a sample address for each node and transition mechanism, whether the


88 

address assignment was static or dynamic, and if the interface portion of the address was based 

on the MAC address assigned to the interface. 

Table 16. Properties of Assigned IPv6 Addresses 

OS Protocol Static MAC Based 

Sample Addresses 

28K 6to4 Yes - 

fe80::bcb6:88ca:6a61:e2d8 

Win 7 - - 2002:a6cb:5cb6:35:bcb6:88ca:6a61:e2d8 

Vista Teredo - - fe80::280a:c40:5934:a349 

- - 2001:0:4137:9e76:280a:c40:5934:a349 

T-Broker - - fe80::edc2:969:1155:f9a6 

- - 2001:5c0:1400:a::11b 

ISATAP Yes - fe80::5efe:10.1.1.11 

Yes - 3ffe:ffff:1234:5678:0:5efe:10.1.1.11 

23K 6to4 Yes Yes fe80::a00:27ff:fe2f:fd98 

XP - Yes 2002:a6d9:4c6d:34:a00:27ff:fe2f:fd98 

Teredo - Yes 2001:0:4137:9e76:0:1a61:5926:b392 

T-Broker - - fe80::50:f2ff:fe00:1 

- - 2001:5c0:1000:b::8dff 

ISATAP Yes - fe80::5efe:10.1.1.12 

Yes - 3ffe:ffff:1234:5678:0:5efe:10.1.1.12 

Ubuntu 6to4 Yes Yes fe80::a00:27ff:fe8a:e479 

CentOS - Yes 2002:20b2:fee8:34:a00:27ff:fe8a:e479 

Teredo - - 2001:0:53aa:64c:3c6f:80b:df4d:117 

T-Broker - - 2001:5c0:1000:b::8e61 

ISATAP Yes - fe80::5efe:a01:110 

Yes - 3ffe:ffff:1234:5678:0:5efe:0a01:0110 

FreeBSD 6to4 - Yes fe80::a00:27ff:fea8:9f8e 

- Yes 2002:20b2:fee8:34:a00:27ff:fea8:9f8e 

Teredo - - 2001:0:53aa:64c:1c29:a6c:df4d:117 

T-Broker Yes - fe80::a00:27ff:fea8:9f8e 

- - 2001:5c0:1000:b::8dd5


89 

OS Protocol Static MAC Based Sample Addresses 

Solaris 6to4 Yes Yes fe80::a00:27ff:fe9a:f546 

- Yes 2002:20b2:fee8:34:a00:27ff:fe9a:f546 

IPv6 Addresses were dynamically assigned in most cases and were rarely based on the 

MAC address of the interface. The Teredo addresses were always dynamically assigned; 

however, there are operating system settings that would have established a static address. 

Additionally, the Tunnel-Broker addresses were always dynamically assigned; however, signing 

up for a service account with the provider would have created a static address. The ISATAP 

address was static based on the prefix in the router advertisement and could be set to a public 

address. Overall, there were a significant number of different IPv6 addresses to manage with few 

methods that could be used to link a physical node to a particular address assignment. 

Address enumeration. 

The tools and techniques listed in Table 15 were run against each node and transition 

mechanism to enumeration the IPv6 addresses. There were two types of results from the address 

enumeration tools. Tools that required an explicit address were only able to verify that an active 

node was assigned to the address. Other tools could detect unknown addresses of nodes on the 

local network. 

The first attempt to enumerate addresses was performed against the base installation of 

the nodes from outside the network. A base installation included the operating system configured 

at the point immediately after the default installation without additional configuration or 

application installations. The details of each base installation are listed in Appendix B. Only the 

Teredo and 6to4 mechanisms were tested because local-link packets are not routed across the 

WAN and the ISATAP and Tunnel-Broker mechanisms were not configured in the base


90 

installations of the nodes. The tools that successfully enumerated addresses from outside the 

network in a base installation are listed in Table 17. 

Table 17. IPv6 Address Enumeration for the Base OS from Outside the Network 

OS Teredo 6to4 

28K None Nmap a b 

23K / XP 

- c - c 

7 

None 

Nmap 

Vista None None 

Ubuntu 

c 

- Ping6 b Nmap b 

CentOS 

c 

- Ping6 b 

FreeBSD 

c 

- Ping6 b Nmap 

Solaris - c Ping6 Nmap Imp6 

Note. ISATAP and Tunnel-Brokers were not part of the base installation and Local-link 

addresses are not routed. 

a 

Used Nmap with the PA or PS options, explicit address, and ports 135 or 445. 

b 

Successful enumeration only when the victim was communicating using the 6to4 interface. 

c 

Not configured as part of the base installation. 

The 6to4 addresses were enumerated on the majority of the nodes and there were no 

methods found to enumerate the Teredo addresses from outside the network. All of the target 

nodes were able to ping6 other IPv6 address assigned to the research nodes. The research node 

was able to ping6 the Linux and FreeBSD targets using the 6to4 addresses only when the target 

node was using or recently used the 6to4 interface. The research node was able to verify the 6to4 

address on the Solaris node using any of the tools employed. 

The second attempt to enumerate addresses was performed on the base installation from 

inside the network. Operating from a local-link expanded the number of available tools to 

include neighbor and router advertisement functionality. Tests were run on the local-link, 

Teredo, and 6to4 addresses because the ISATAP and Tunnel-Broker mechanism were not


91 

configured in the base installations. The tools that successfully enumerated addresses on the base 

installation from inside the network are listed in Table 18. 

Table 18. IPv6 Address Enumeration for the Base OS from Inside the Network 

OS Local Teredo 6to4 

28K Sniffing DetNew6 None 

Sniffing 

Nmap a Imp6 

IP neigh 

6RA 

23K / XP - c - c - c 

7 Sniffing DetNew6 None 

Sniffing 

6RA Imp6 

DetNew6 

Vista Sniffing None 

Sniffing 

6RA 

DetNew6 

Ubuntu 

CentOS 

FreeBSD 

DetNew6 

Imp6 

Sniffing b 6MCPing - c 

Ping6(A) 6RA 

Ping6(MC) Alive6 Nmap 

IP neigh DetNew6 

Alive6 

Nmap Imp6 

DetNew6 

6Neigh 

Imp6 

Sniffing b 6MCPing - c Sniffing b 

Ping6(A) 6RA 

Ping6(A) 


IP neigh DetNew6 

Alive6 

6Neigh Imp6 

DetNew6 

Sniffing b 6MCPing - c 

Sniffing b 

Ping6(A) 6RA 

Ping6(A) 


IP neigh 

Nmap 

DetNew6 

Imp6 

Sniffing b 

Ping6(A) 

Alive6 

DetNew6 

Nmap a 

DetNew6 

Imp6


92 


6Neigh 

c 

Solaris Sniffing b 6MCPing - Sniffing b Imp6 

Ping6(A) 6RA Ping6(A) 


Nmap Imp6 Alive6 

6Neigh 

DetNew6 

Note. ISATAP and Tunnel-Brokers were not part of the base installation. 

a 

Used Nmap with the PA or PS options, explicit address, and ports 135 or 445. 

b 

While Windows nodes broadcast solicitation messages regularly, these nodes were quiet. 

c 

Not installed as part of the base installation. 

All of the targets, except for the Windows XP and 2003 nodes, received auto-configured 

local-link addresses in the default state. All of the Windows targets with local-link addresses 

received an auto-configured Teredo address when the node also had WAN connectivity. All the 

targets, except for the Windows XP and 2003 nodes, received auto-configured 6to4 addresses in 

the default state when the node also had WAN connectivity. 

Sniffing the local-link and detecting duplicate address detection (DAD) packets using the 

THC-IPv6 detect-new-ip6 function when the victim boots was the most reliable method for 

enumerating 6to4 and local-link addresses. No methods were discovered to enumerate the 

Teredo addresses. The target’s 6to4 and local-link addresses were contained in the last 128 bits 

of the IMCPv6 neighbor solicitation (type 135) packets sent to the local-link multicast address 

during the boot process. The 6to4 and local-link addresses were linked to the target’s IPv4 

address by locating other IPv4 packets from the same MAC address. The Windows firewall 

blocked most of the ICMPv6 based scanning tools; however, a Metasploit module that sent 

router advertisements to all local-links (FF02::1) enumerated the local-link addresses. 

Additionally, when the Windows network was set to “public” instead of “private,” the firewall


93 

blocked the Nmap scans. The Linux, FreeBSD, and UNIX targets were not protected by software 

firewalls and most of the ICMPv6 tools were able to enumerate the local-link addresses. 

The third attempt to enumerate addresses was performed from outside the network on 

target nodes that were configured to communicate using the IPv6 transition mechanisms. This 

included installing or configuring the Teredo and the Tunnel-Broker mechanisms on the 

Windows, Linux, and FreeBSD nodes. Additionally, the 6to4 mechanism was configured on the 

Windows 2003 and XP nodes. Testing was not performed on the Solaris node because the 

researcher was unable to install Teredo and Tunnel-Broker applications. The tools that 

enumerated the IPv6 addresses from outside the network are listed in Table 19. 

Table 19. IPv6 Address Enumeration for IPv6 Enabled OS from Outside the Network 

OS Teredo TBroker 6to4 

28K Nmap(A) None See Table 17 

23K Nmap(A) Nmap(A) Nmap(A) 

Ping6(A) 

Ping6(A) 

Imp6(A) 

7 / Vista None None See Table 17 

XP Ping6(A) Ping6(A) None 

Ubuntu / CentOS / Nmap(A) Nmap(A) See Table 17 

FreeBSD Ping6(A) Ping6(A) 

Solaris - - See Table 17 

Note. The ISATAP and local-link addresses were not global. 

There were no tools or techniques discovered to enumerate a range of addresses from 

outside the network. Teredo addresses were easily enumerated using Nmap and ping6 in all 

operating systems except Window 7 and Vista. The Tunnel-Broker addresses were enumerated 

using Nmap and ping6 on the Linux and FreeBSD nodes; however, the Windows firewall 

blocked the Nmap and ping6 probes when it was enabled.


94 

The fourth attempt to enumerate addresses was performed from inside the network 

against target nodes with the IPv6 transition mechanisms configured. The tools and techniques 

that successfully enumerated the addresses for each node and transition mechanism are listed in 

Table 20. 

Table 20. IPv6 Address Enumeration for IPv6 Enabled OS from Inside the Network 


28K See Table 18 Sniffing a Nmap(A) Sniffing b See Table 18 

Ubuntu See Table 18 Nmap(A) Nmap(A) Sniffing b See Table 18 

23K Sniffing 

Nmap(A) 

Ping6(A) 

Ping6(M) 

6Neigh 

6MCPing 

6RA 

DetNew6 

Imp6(A) 

Nmap(A) 

Sniffing c 

Nmap(A) 

Ping6(A) 

Ping6(A) 

Nmap(A) 

Ping6(A) 

Sniffing b 

Nmap(A) 

Ping6(A) 

Imp6(A) 

Sniffing 

Nmap(A) 

Ping6(A) 

DetNew6 

Alive6 

Imp6(A) 

7 See Table 18 Sniffing Nmap(A) Sniffing b See Table 18 

Vista See Table 18 

Nmap(A) 

Imp6(A) 

None 

Ping6(A) 

None 

Imp6(A) 

Sniffing b See Table 18 

XP 

Sniffing 

Ping6(A) 

Ping6(M) 

6Neigh 

6RA 

DetNew6 

Imp6(A) 

Sniffing 

Ping6(A) 

Ping6(A) Sniffing b 

Ping6(A) 

Imp6(A) 

Sniffing 

Ping6(A) 

DetNew6 

Imp6(A)


95 


Ping6(A) Ping6(A) Nmap(A) 

Imp6(A) 

Ping6(A) 

Imp6(A) 

CentOS / See Table 18 Nmap(A) - Sniffing b See Table 18 

FreeBSD Ping6(A) Nmap(A) 

Imp6(A) 

Ping6(A) 

Imp6(A) 

Solaris See Table 18 - - - See Table 18 

Note. 

a 

Wireshark filter for “Teredo” revealed local-link and public Teredo addresses. 

b 

The TBroker IPv6 address was contained in a UDP packet to 64.86.88.116 

(montreal.freenet6.net). The address starts in the ninth octet of the UDP payload and began with 

HEX 2001. 

c 

Detectable only after the host communicated over the Teredo interface. There is an initial 

packet containing the Teredo address that Wireshark identified as Teredo and then the remainder 

of the conversations were encapsulated in a UDP packet. 

Nmap was the most effective tool at enumerating the Teredo, ISATAP, and Tunnel- 

Broker addresses; however, it was not effective against the Windows Vista and XP nodes. The 

Teredo addresses were enumerated by capturing the boot traffic of the Windows nodes; however, 

the Linux, FreeBSD, and Vista nodes did not send Teredo traffic during the boot process. The 

Teredo conversations began with a packet that Wireshark identified as the Teredo protocol and 

then continued with a series of encapsulated UDP packets. The Teredo UDP stream always had 

the source or destination IPv4 address of the Teredo relay. The Tunnel-Broker addresses were 

enumerated by sniffing the node boot process and looking for the UDP tunnel initiation packets 

that contained the IPv6 addresses. The Tunnel-Broker traffic was always a UDP stream to or 

from the tunnel endpoint and was initiated with a packet that negotiated the IPv6 addresses used 

by the host. The ISATAP address could not be explicitly determined from the boot process trace;


96 

however, it could be inferred using the router advertisements containing the address prefix and 

the IPv4 address of the hosts. 

Service and port discovery. 

The first attempt to enumerate services and ports on the target nodes was attempted from 

outside the network against the base installation of the operating systems. Nmap was the only 

tools found that supported port enumeration on IPv6 nodes. The results of the external port scan 

of the 6to4 and Teredo addresses assigned to each node in the base configurations are listed in 

Table 21. 

Table 21. IPv6 Service and Port Enumeration for the Base OS from Outside the Network 

OS Teredo 6to4 

28K None Nmap a 

23K / XP - f - f 

7 None Nmap b 

Vista None None 

Ubuntu - f Nmap c 

CentOS - f None 

FreeBSD - f Nmap d 

Solaris - f Nmap e 

Note. ISATAP and Tunnel-Brokers were not part of the base installation. Local-link addresses 

are not global. 

a 

Enumerated TCP ports 135/msrpc, 445/msds, and 49155/unknown using PA or PS options 

while the target is communicating over the 6to4 interface. 

b 

Enumerated TCP ports 135/msrpc, 445/microsoftds, and unknown ports 5357, 49152, 49153, 

49154, 49155, 49156, 49157 using the Pn option 

c 

Enumerated TCP ports 119 /nntp and 32782/unknown while target is communicating over the 

6to4 interface. 

d 

Default scan enumerated TCP ports 22/ssh, 111/rpc bind, 119/nntp, and 2049/nfs. 

e 

Default scan enumerated TCP ports 22/ssh, 111/ rpc bind, and 119//nntp. 

f 

Not installed as part of the base installation. 

Ports bound to 6to4 addresses could be enumerated using the Nmap scanning tool for the 

Windows 2008, Windows 7, Ubuntu, FreeBSD, and Solaris targets. The Windows firewall


97 

blocked the Nmap scans in all targets except the Windows 2008 and 7 nodes which allowed a 

scan only using the PA (TCP ACK) or PS (TCP SYN) options on ports 135 or 445. The scans of 

the Windows systems revealed that the node was listening on ports for the remote procedure call 

service (MSRPC: TCP port 135), the Microsoft domain service port (MSDS: TCP port 445) that 

is used by Active Directory, and a few unknown ports. The base configurations of the Ubuntu 

Linux target allowed the default Nmap scans and indicated open ports for the network news 

transfer protocol (NNTP: TCP port 119) and an unknown port. The FreeBSD target was listening 

on the secure shell (SSH: TCP port 22), remote procedure call (RPC: TCP port 111), and NNTP 

(TCP port 119) ports. The FreeBSD node was listening on the same ports as the Solaris node 

with the addition of the port used by the NFS (TCP port 2049). 

The second attempt to enumerate services and ports was performed from inside the 

network on the base installation of each node. Nmap was the only tool that supported port scans 

on IPv6 addresses. The results of these scans from inside the network are listed in Table 22. 

Table 22. IPv6 Service and Port Enumeration for Base OS from Inside the Network 


28K Nmap a None Nmap a 

23K / XP - - - 

7 / Vista None None None 

Ubuntu None - None 

CentOS 

FreeBSD 

Solaris 

None 

Nmap c 

Nmap d - 

- 

- 

Nmap b 

Nmap c 

Nmap d 

Note. ISATAP and Tunnel-Brokers were not part of the base installation. 

a 

Nmap scan with -PA135 option enumerated ports 135/msrpc, 445/msds, and 49155/ unknown. 

b 

Enumerated TCP ports 22/ssh and 631/ipp using the Pn option. 

c 

Default scan enumerated TCP ports 22/ssh, 111/rpcbind, 772/unknown, and 2049/nfs open. 

d 

Default scan enumerated TCP ports 22/ssh, 111/rpcbind, and 50932/unknown.


98 

Service and ports bound to 6to4 and local-link addresses were enumerated using the 

Nmap scanning tool for the Linux, FreeBSD, UNIX, and Windows 2008 targets. The Windows 

firewall configured with the private network setting blocked the Nmap scans in all targets except 

Windows 2008 which allowed a scan only using the PA (TCP ACK) or PS (TCP SYN) options 

on port 135 or 445. The scans of this node revealed listening services on the ports associated 

with MSRPC (TCP port 135), MSDS (TCP port 445) that is used by Active Directory, and one 

unknown port. The base configuration of the Ubuntu Linux target allowed the default Nmap 

scan; however, there were no ports open in the IPv6 address space. The CentOS target was 

listening on the SSH (TCP port 22) and the Internet printing protocol (IPP: TCP 631). The base 

configurations of the FreeBSD and UNIX targets were listening on the SSH (TCP port 22), RPC 

(TCP port 111), NFS (TCP port 2049), and two unknown ports (TCP ports 772 and 50932) 

The third attempt to enumerate services and ports was performed from outside the 

network on nodes that were configured for IPv6 services. Nmap was the only tool found that 

supported port and service enumeration on IPv6 addresses. The results of the scans on each node 

from outside the network are listed in Table 23. 

Table 23. IPv6 Service and Port Enumeration for IPv6 OS from Outside the Network 

OS Teredo TBroker 6to4 

28K None Nmap b See Table 21 

23K Nmap a Nmap c None 

7 / Vista None None See Table 21 

XP None None None 

Ubuntu Nmap d Nmap d See Table 21 

CentOS Nmap e Nmap e See Table 21 

FreeBSD Nmap f Nmap f See Table 21 

Solaris - - See Table 21 

Note. The ISATAP and link-local addresses are not global.


99 

a 

Enumerated TCP ports 106/ pop3pw,119/ nntp, 1310/ unknown, and 19780/ unknown on one 

scan, no open ports on a second scan, and 119/ nntp on a third scan using –Pn option. The tool 

provided inconsistent results. 

b 

Enumerated TCP ports 135/ msrpc, 445/ microsoftds, 49155/ unknown using the –Pn option. 

c 

Enumerated TCP ports 135/msrpc, and 1026/LSAornterm. 

d 

Enumerated TCP port 119/nntp 

e 

Enumerated TCP ports 22/ssh and 631/ipp using –Pn option. 

f 

Enumerated TCP ports 22/ssh, 111/rpcbind, 119/nntp, and 2049/nfs 

The Windows firewall blocked the external Nmap scans on the Teredo and Tunnel- 

Broker addresses; however, the Linux and FreeBSD nodes were successfully scanned. The 

Windows nodes that could be scanned were listening on ports for RPC (TCP port 135), MSDS 

(TCP port 445), and the remote login (NTERM: TCP port 1026). The Linux and FreeBSD nodes 

had the SSH (TCP port 22), RPC (TCP port 111), and NNTP (TCP port 119), IPP (TCP port 

632), and the NFS (TCP port 2049) services bound to IPv6 addresses. 

The fourth attempt at enumerating services and ports was performed from inside the 

network on nodes that were configured for IPv6 communications. Nmap was the only tool that 

supported port scans of IPv6 addresses. The results of these scans are listed in Table 24. 

Table 24. IPv6 Service and Port Enumeration for IPv6 Enabled OS from Inside the Network 


28K 

23K 

7 

See Table 22 

Nmap d 

See Table 22 

None 

Nmap b 

Nmap f 

Nmap a 

Nmap e 

Nmap f 

Nmap c 

Nmap d 

None 

See Table 22 

Nmap d 

See Table 22 

Vista See Table 22 None None None See Table 22 

XP None None None None See Table 22 

Ubuntu 

CentOS 

FreeBSD 

See Table 22 

See Table 22 

See Table 22 

Nmap g 

Nmap h 

Nmap i 

None 

- 

- 

None 

Nmap h 

Nmap i See Table 22 

See Table 22 

See Table 22 

Solaris See Table 22 - - - See Table 22 

Note. 

a 

Nmap scan with PA135 option enumerated ports 135/msrpc, 445/msds, and 49155/unknown.


100 

b 

Enumerated TCP ports: 1218/aeroflightads, 17938/lgtomapper, and unknwn ports 122, 5718, 

5907, 49159, 50389. Subsequent scans were not consistent and netstat on the victim did not 

indicate that these ports were open. This is likely a false positive. 

c 

Enumerated TCP ports 135/ msrpc, 445/msds, 49155/unknown using the Pn option. 

d 

Enumerated TCP ports 135/msrpc, 445/msds, and 1026/LSA or nterm. 

e 

Enumerated TCP ports 135/msrpc, and 1026/LSA or nterm. 

f 

Enumerated TCP ports 135/msrpc, 445/msds, and unknown ports 5357, 49152, 49153, 49154, 

49155, 49156, 49157. 

g 

Enumerated TCP port 119/nntp 

h 

Enumerated TCP ports 22/ssh and 631/ipp using the Pn option. 

i 

Enumerated TCP ports 22/ssh, 111/rpcbind, 119/nntp, and 2049/nfs 

Services were enumerated on the Windows 7, 2003, 2008, Linux and FreeBSD nodes. 

The Windows 7 services were enumerated on the Teredo and ISATAP addresses. The Windows 

2008 services were enumerated on the ISATAP and Tunnel-Broker addresses. The Ubuntu 

services were enumerated on the Teredo address and the CentOS and FreeBSD services were 

enumerated on the Teredo and Tunnel-Broker addresses. The ports and services that were 

enumerated for each node are listed in the notes of Table 24. 

Lessons learned. 

Address and port enumeration of the target nodes in the study were possible from inside 

and outside the network. Tools that utilized router and neighbor advertisement messages were 

able to detect addresses configured on the local-link; however, TCP connection based tools like 

Nmap required the address to be known before a scan could be performed. The software 

firewalls configured by default on the Windows and CentOS nodes prevented many of the tools 

from generating positive results. 

The assumptions identified for this phase of the study included: (1) nodes behind a NAT 

will be protected from network scanners; (2) operating systems with IPv6 enabled by default will 

have exposed services and emanate IPv6 packets into the IPv4 network; (3) and nodes with 

public IPv6 addresses using transitional networks will have publically exposed services. The first


101 

assumption was proven false because the IPv6 addresses assigned to each node established a 

publically accessible IP address that was not restricted by private address assignments. The other 

two assumptions were validated in this study by the presence of IPv6 traffic in the network traces 

during the boot process and the successful enumeration of ports bound to IPv6 services. 

Exploitation 

The exploitation phase of the study identified tools and techniques that attacked the 

network topography in a transitional network. Tools and techniques were tested from inside and 

outside the network on nodes configured with default installations or IPv6 configured 

installations. This included attempts to establish rogue routers in the network and to 

communicate with rogue nodes. Native ICMPv6 ping6 requests were employed to establish and 

verify that a node was able to communicate with the rogue nodes. Router advertisements were 

generated using the THC-IPv6 fake_router6 function and the Netdude tool that allowed the 

researcher to generate and send custom packets. Additionally, DNS and network name spoofing 

was tested or proposed to direct the nodes to a rogue router. The tools and techniques employed 

in the exploitation phase of the testing are listed in Table 25. 

Table 25. Employed Exploitation Tools and Techniques 


Native RA Set the hostname for the local ISATAP router to “isatap” 

Native Ping >ping -6 -S 

>ping6 -I 

DNS DNS DNS injection for Teredo.ipv6.microsoft.com that pointed to attacker 

controlled Teredo server. 

THC- F_Router > ./fake_router6 / 

IPv6 

 

Netdude Netdude Craft and send a router advertisement packet with a global address.


102 

Rogue routers and relays. 

A rogue router or relay alters the flow of network traffic through a point controlled by an 

attacker and establishes an address to attack the victim or other nodes on the network. Teredo 

and Tunnel-Broker addresses are configured by the Teredo or Tunnel-Broker servers during the 

initial communications channel negotiation; therefore, a successful result would redirect the 

initial negotiations to a rogue router. The ISATAP and 6to4 addresses are established using 

router advertisements. 

The first test established rogue Teredo, ISATAP, and 6to4 routers and then prompted the 

victim nodes to auto-configure an address from outside the network. Netdude was used to craft a 

custom router advertisement packet and TCPReplay was used to send the packet to the target. 

The results of attempting to establish a rogue router from outside the network are listed in Table 

26. 

Table 26. IPv6 Address Auto-Configuration from Outside the Network 

OS Teredo ISATAP 6to4 

28K / 7 / Vista None None None 

23K / XP - - - 

Ubuntu / CentOS / FreeBSD / Solaris - - None 

Note: Test performed using the Netdude tool. 

There were no methods discovered that configured an address on a victim node using a 

router advertisement from outside of the network. The Teredo and Tunnel-Broker relay 

addresses default to explicit domain aliases and it may be possible to spoof a DNS reply from the 

domains to redirect the relay server to an attacker controlled node. The ISATAP and 6to4 

address auto-configuration functions relied upon router advertisements and name lookup services


103 

that only operated at the local-link level. None of the nodes configured a 6to4 address when the 

destination of the router advertisement packet was changed to a global scope IPv6 address. 

The second test established rogue routers and then prompted a node to auto-configure an 

address from inside the network. DNS, hostname spoofing, and the THC-IPv6 fake_router6 

function were employed in this process. The results of attempting to establish a rogue router or 

relay from inside the network are listed in Table 27. 

Table 27. IPv6 Address Auto-Configuration from Inside the Network 

OS Teredo ISATAP 6to4 

28K / 7 / Vista DNS b RA a F_Router 

23K / XP - - - 

Ubuntu / centos / FreeBSD / Solaris - - F_Router 

Note. 

a 

Required the router host (ISATAP) to be a Windows node to respond via local-link Multicast 

Name Resolution (LLNBS) (Vista, Win 7, 28K) or Netbios Name Service (NBNS). 

b 

Teredo is disabled in the base configuration. 

Configuring an IPv6 address on an internal victim node from inside the network was a 

simple process with the 6to4 mechanism and slightly more complex with the ISATAP and 

Teredo mechanisms. The IP address for the default Teredo relay could be redirected to an 

attacker controlled relay by intercepting and replying to the DNS queries for 

teredo.ipv6.microsoft.com on the local-link. The default Windows installations determined the 

address of the local ISATAP server by broadcasting a query using LLMNR (Vista, Win 7, 28K) 

or Netbios name service (NBNS). A Windows node hosting the ISATAP server that was 

configured with “isatap” as the computer name successfully configured an ISATAP address on 

the victim nodes. Additionally, router advertisements broadcast to the all nodes multicast address 

(FF01::1) caused a 6to4 address to be configured on the victim nodes.


104 

Rogue clients. 

The next stage of the exploitation phase attempted to establish a two-way 

communications channel between the victim and attacker nodes. Connectivity was verified using 

the native ICMPv6 ping6 tool. Table 28 lists the results of establishing a two-way 

communications channel with a rogue node that is located outside the network. Table 29 lists the 

results of establishing a two-way communications channel with a rogue node that is located 

inside the network. 

Table 28. IPv6 Communication with a Rogue Node from Outside the Network 

OS Teredo TBroker 

28K / 23K / 7 / Vista / XP Ping Ping 

Ubuntu / Solaris Ping Ping 

CentOS None Ping 

FreeBSD Ping a Ping a 

Note. The test used the 6to4 auto-configured address as the source by specifying the –S option in 

the ping6 command (Windows) or –I option in the Linux/BSD/Solaris nodes. The outside 

research node did not support the 6to4 transition mechanism. 

a 

The test was successful only when communicating over the Tunnel-Broker Interface. 

Table 29. IPv6 Communication with a Rogue Node from Inside the Network 

OS Local Teredo ISATAP b TBroker 6to4 

28K / 23K / XP Ping Ping Ping Ping Ping 

7 / Vista Ping Ping a Ping Ping Ping 

Ubuntu Ping None Ping Ping Ping 

CentOS Ping None - Ping Ping 

FreeBSD Ping Ping c - Ping c Ping 

Solaris Ping Ping - Ping Ping 

Note. The test used the 6to4 auto-configured address as the source by specifying the –S option in 

the ping6 command (Windows) or –I option in the Linux/BSD/Solaris nodes. 

a 

Was only able to communicate with the node using the Teredo interface. 

b 

The test was successful only when using the ISATAP interface. 

c 

The test was successful only when using the Tunnel-Broker Interface.


105 

The victim nodes were almost always able to initiate a two-way communications channel 

with a rogue node that was located inside or outside the network. The CentOS node was unable 

to communicate over the Teredo interface to a rogue node located inside or outside the network 

and the Ubuntu node could not communicate to an internal node over the Teredo interface. All 

other attempts to initiate a two-way communications channel were successful; however, this 

result often depended on communicating over an interface that operated using the same transition 

mechanism. 


Rogue routers were established inside the network and the victim nodes were able to 

initiate two-way communication channels with rogue nodes operating inside and outside the 

network. The assumption for this section of the study was that IPv6 traffic flows and addressing 

can be modified remotely using protocol attacks. This assumption has been proven partly true. 

Rogue routers operating inside the network successfully modified traffic and addressing on 

remote victim nodes using router advertisement attacks; however, success was not achieved from 

points outside the network. 

Reinforcement 

The reinforcement phase of the study identified tools and techniques that could be used to 

obfuscate an attack in a transitional network. This included methods to hide the source, context, 

or target of an attack. The THC-IPv6 redire6 function obfuscates the source of an attack by 

routing traffic through a rogue router that can modify the source details of a traffic flow. 

Fragmentation obfuscates the context of an attack by breaking up payloads into multiple packets 

and making contextual threat analysis difficult from intermediate nodes. The ability for a node to 

reassemble fragmented packets was tested with the ICMPv6 ping6 function. The target of an

IMPACT OF IPV6 TRANSITION MECHANISMS ON THE NETWORK FORENSIC 106 

attack is obfuscated by sending the same traffic to multiple nodes and this functionality was 

verified by sending ICMPv6 ping6 packets to the solicited nodes multicast address. The tools 

and techniques employed in the reinforcement phase of the study are listed in Table 30. 

Table 30. Employed Reinforcement Tools and Techniques 


Native FragPing >ping6 -I -s 1508 

Native Multicast Assigned the same IPv6 address to multiple nodes and then pinged the 

Solicited node multicast addresses FF02::1:FF 

("Multicast IPv6 addresses," 2005) 

THC- Redir >./redir6 

IPv6 

 

Redirect routing for a specific address to a new local-link address which 

appears as a neighbor discovery cache entry. 

Source address obfuscation. 

The first attempt to obfuscate the source address was performed by evaluating the 

correlation between the logical address assignments and the physical nodes. Address assignments 

that are random and change frequently can obfuscate the source of a packet. Two evaluations 

were performed on each node in the study. First, operating system support was determined for 

IPv6 privacy extensions that assigned temporary addresses to an interface. Second, operating 

system support was determined for assigning random interface identifiers during address autoconfiguration. 

A detailed address assignment listing is included in Appendix B and the results of 

the address evaluations are listed in Table 31.


107 

Table 31. Source Address Obfuscation using IPv6 Privacy Extensions 


28K / 7 / Vista R_Int T_Addr 

R_Int 

None T_Addr 

R_Int 

T_Addr 

R_Int 

23K / XP None T_Addr None T_Addr T_Addr 

R_Int 

R_Int 

Ubuntu None T_Addr None T_Addr T_Addr 

R_Int R_Int R_Int 

CentOS / FreeBSD None T_Addr 

R_Int 

- T_Addr 

R_Int 

T_Addr 

R_Int 

Solaris None - - - T_Addr 

R_Int 

Note: R_Int = Node supported random interface ids. T_Addr = Node supported temporary 

addresses. 

IPv6 address randomization is possible on all nodes, either because the interface portion 

is randomized by default or because the MAC addresses can be manually changed with registry 

settings or configuration files. Local-link addresses were linked to the interface MAC addresses 

on all nodes except for the Windows 7, 2008, and Vista nodes. Teredo, 6to4, and Tunnel-Broker 

addressing randomized the local portion of the address. Teredo and 6to4 addresses contained the 

public IPv4 address used by the interface; however, the true source could be obfuscated in a 

network that shares a public IPv4 address among more than one node. The Tunnel-Broker 

interface generated an anonymous interface ID that requires input from the service provider to 

determine the source IPv4 address. The service provider was determined using a whois query on 

the first four octets of the configured address. ISATAP provided a fixed address for an interface 

based on the router prefix; however, the attacker could obfuscate the address if they were in 

control of the router advertisement that was sent.


108 

The second attempt to obfuscate the source address utilized IPv6 router redirects that 

altered the flow of traffic through a rogue router for a particular destination address. The rogue 

router would forward the traffic and alter the source address to hide the true origin of the packets. 

The THC-IPv6 redirect6 function was used to redirect traffic from the target nodes to the 

specified address. The results of redirecting traffic using this tool are included in Table 32. The 

local-link, 6to4, and ISATAP addresses on a local network were redirected to a secondary router 

controlled by an attacker. The tool created neighbor cache records on the target node for the 

destination and the new router. The new forwarding router is obtained from the neighbor cache 

when the target sends packets to the rerouted destination address. 

Table 32. Source Address Obfuscation in a Two-Way Channel using IPv6 Router Redirects 


28K / 23K / 7 / Vista / XP Redir None Redir None Redir 

Ubuntu Redir None Redir None Redir 

CentOS / FreeBSD Redir None - None Redir 

FreeBSD Redir None - None Redir 

Solaris Redir - - - Redir 

Note. The results are based on observations of the neighbor cache after running the specified 

tool; however, successful two-way communications could not be verified because the simulated 

network did not support multiple routers operating in the same network. 

Data obfuscation. 

The attempt to obfuscate the data in a packet employed payload fragmentation that 

divided the context of a single commutations chain into multiple packets. First, the Netdude tool 

was used to construct and TCPReplay was used to send fragmented ICMPv6 ping6 packets 

containing a word that was divided over two packets. Second, the native ping6 function was 

utilized to construct and send fragmented ICMPv6 packets and verify that each node 

reassembled the fragments and responded to the request. The nodes that successfully responded


to the fragmented ping6 request are listed in Table 33. All nodes that responded to ICMPv6 

ping6 requests correctly handled fragmented packets. 

Table 33. Data Obfuscation in a Two-Way Channel using IPv6 Fragments 


28K / 7 / Vista FragPing None a FragPing FragPing FragPing 

23K / XP FragPing FragPing FragPing FragPing FragPing 

Ubuntu FragPing FragPing FragPing FragPing FragPing 

CentOS / FreeBSD FragPing FragPing - FragPing FragPing 

Solaris FragPing - - - FragPing 

Note. All nodes were tested with the firewall disabled. 

a 

The node did not respond to non-fragmented ping6 requests. 

Destination address obfuscation. 

The attempt to obfuscate the destination address of a source utilized the solicited node 

multicast address to create a two-way communications channel with multiple destination nodes. 

First, two nodes were assigned a 6to4 address where the last three octets of the interface 

identifier were equal. Second, communications with both nodes was verified when both nodes 

replied to a single ICMPv6 ping6 request sent to the solicited nodes multicast address. Table 34 

lists the nodes that responded to the ping6 request that was sent to the solicited node multicast 

address. 

Table 34. Destination Address Obfuscation in a Two-Way Channel using IPv6 Multicast 

OS 

28K / 7 / Vista / XP 

23K 

Ubuntu / CentOS / FreeBSD / Solaris 

Local 

None 

Multicast 

Multicast


110 


Tools and techniques were identified that obfuscated the source addresses, data, and 

destination addresses of an IPv6 traffic flow. The assumptions for this stage of the study were: 

(1) Privacy extensions, redirects, and address auto-configuration protocols can be used to 

obfuscate traffic from an attacker and it will not be possible to determine the true source. (2) 

Fragmentation can be used to obfuscate the port or source address for a traffic flow. (3) Multicast 

or anycast addressing can be used to obfuscate the source or destination node in an attack. The 

first assumption was validated for a multi-node internal network with a shared public IPv4 

address; however, the true source could be determined from the Teredo, ISATAP or 6to4 address 

in a network containing a single node. The study did not validate the second assumption because 

the researcher could not find a method to obfuscate the headers containing the addresses or port 

numbers. The third assumption was validated by establishing a two-way communications 

channel between two hosts using the solicited nodes multicast address. 

Consolidation 

The consolidation phase of the study identified methods to create a persistent backdoor 

into a transitional network using IPv6. The Netcat tool that is part of the Nmap installation 

included a version of Netcat that supports IPv6 addressing, secure socket layer (SSL) encryption, 

and remote shell execution. The command sequences that established a remote shell on the 

Linux, FreeBSD, and Windows nodes from the Linux research node are listed in Table 35. The 

results of attempting to establish a remote shell on each node are listed in Table 36.


111 

Table 35. Employed Consolidation Tools and Techniques 


Netcat Nc_Win Listening/Victim 

>ncat -l6p -ssl -e cmd.exe 

Connecting/Attacker (Linux) 

>ncat -6 -ssl 

Netcat Nc_Lin Listening/Victim 

>ncat -l6p -ssl -c /bin/bash 

Connecting/Attacker (Linux) 

>ncat -6 -ssl 

Table 36. Persistent IPv6 Backdoor 

OS 

Technique Used 

28K / 23K / 7 / Vista / XP 

Nc_Win 

Ubuntu / CentOS / FreeBSD 

Nc_Lin 

Solaris - 

Note. Firewalls were disabled on all nodes for the test. 

An encrypted remote shell was established between the target nodes and the research 

node using the Netcat tool and the 6to4 addresses. The assumption for this section of the study 

was: A remote command shell can be created through a transitional network over IPv6 using 

common tools. This assumption was validated because the Netcat tool is a common tool that 

successfully established a remote command prompt using IPv6. 

Pillage 

The pillage phase of the study addressed additional risks that should be considered in a 

transitional network. Covert channels were assumed to be the primary risk factor for this phase. 

Although, risk ratings for various scenarios may differ by environment, data leakage would 

normally be a major concern. The testing and analysis in this study revealed a few of the possible


techniques that could be used to create covert channels using IPv6 transition mechanisms. First, 

data can be hidden in extension headers. Second, invalid or unnecessary extension headers that 

would normally be discarded by the host can be used to carry covert data channels. Finally, 

unused fields that are part of the IPv6 or transition mechanism can use used for covert channels.


113 

Chapter 5 – Conclusions 

This study investigated the nature of IPv6 traffic in a transitional network to develop a 

new methodology for network forensic analysis. The results of this study have implications on 

two of the digital forensic process steps presented in chapter 2. First, a better understanding of 

the characteristics and behaviors of operating systems and transition mechanisms supplemented 

the process step, “provide training and tools,” that was defined by Carr, Gunsch, and Reith 

(2002), Ciardhuáin (2004), Shin (2008), and Mandia and Prosise (2001). Second, a new 

methodology was developed to address IPv6 traffic in a transitional network to support the 

process step, “analyze and document,” that was defined by Carr, et al. (2002), Cohen (2009), 

Shin (2008), the DOJ (2001), Mandia and Prosise (2001), Palmer (2001), Carrier and Spafford 

(2003), and Casey (2000). While these contributions begin to address deficiencies in digital 

forensic research, there remains a need to develop additional details in the discipline as well as a 

unification of forensic frameworks from which to base future efforts in the field. 

Implications of IPv6 Transition Mechanisms in Digital Forensics 

The IPv6 transition mechanisms have the most significance on the forensic pursuit of 

questioning who was involved in a particular event and how the event occurred. Analysts and 

investigators must understand how their processes will change when dealing with a transitional 

network. 

First, the addressing scheme changes from 32 bits to 128 bits when analyzing a 

transitional network and the lack of IPv6 addresses in a network trace does not imply the absence 

of IPv6 traffic. The 128 bit addressing scheme of various IPv6 transition mechanisms was 

adequately described by Nikkel (2007), Conta, and Deering (1998), Deering, Haberman, Jinmei, 

Nordmark, and Zill (2005); although, additional details were necessary for forensic analysis. For


114 

example, traffic sourcing often required converting a portion of a hexadecimal (base 16) IPv6 

address to a decimal (base 10) IPv4 address. Also, tunneling mechanisms like Teredo and 

Tunnel-Broker encapsulated IPv6 packets inside IPv4 traffic; therefore, IPv6 packets were 

observed traversing the network even when the network trace lacked packets with IPv6 

addresses. 

Second, the numbers of distinct packet source addresses representing a single node in a 

network are significantly higher in a transitional network than in an IPv4 network. Mechanisms 

like Teredo and Tunnel-Brokers generated new addresses as frequently as every few minutes. 

IPv6 address auto-configuration and privacy extensions produced new addresses approximately 

every 24 hours or at an interval selected by the user. This problem altered the methods used to 

correlate events and source traffic. Event correlation accuracy may be enhanced by linking 

packets to the IPv4 gateway address that is embedded in the IPv6 source address; however, this 

also may decrease accuracy when more than one node shares an IPv4 address. The public source 

IPv4 address embedded in the IPv6 address may lead to a physical network; although, node 

based address assignments lacked a centralized address logging mechanism that would allow an 

analyst or investigator to determine the physical source in a multi-node network. This 

characteristic may be used to support legal defense arguments and further strengthen Losavio’s 

(2005) argument that successful prosecution of digital cases requires streams of collaborating 

evidence. 

Third, IPv6 transition mechanisms establish a globally accessible address that exposes a 

node to external attacks that were previously mitigated through the use of NAT on an IPv4 

network. Nearly all of the operating systems automatically configured a global 6to4 address that 

was addressable from outside the NAT used in the study. Analysts and investigators should


115 

approach an investigation with the assumption that each node is globally addressable so that the 

full range of possible event sequences is considered. 

Finally, Vives and Palet (2005), Caicedo, Joshi, and Tuladhar (2009), Davies, Krishnan, 

and Savola (2007), Emre and Ali (2010)and Nikkel (2007) correctly stated that IPv6 support is 

already included in many standard forensic tools; however, the limitations of these tools prevents 

the types of analysis that is possible in an IPv4 network. For example, the researcher was unable 

to find a tool that scans a range of IPv6 addresses to solve the address enumeration problems 

discussed by Zagar, Grgic, and Rimac-Drlje (2007) and Convery and Miller (2004). 

Additionally, many of the tools and techniques discussed in the research were not designed to 

target external nodes. The most useful tools, like Metasploit and THC-IPv6 (Caicedo, et al., 

2009), provided functionality using local router advertisements and multicast traffic that can only 

be sent to other directly connected nodes. 

Operating System Behavior in a Transitional Network 

This study focused on the current distributions of the Windows, Ubuntu, CentOS, 

FreeBSD, and Solaris operating systems. All of these operating systems, except for Windows 

2003 and XP, configured global 6to4 and link-local IPv6 addresses after a default installation. 

This behavior required a 6to4 router to be present in the network; however, the researcher did not 

install or configure a device to provide this functionality. The Teredo, Tunnel-Broker and 

ISATAP mechanisms required additional configuration or third-party installations that are 

accurately described in instruction manuals for Oracle Solaris (2009) or FreeBSD (2010) and 

research by Tulloch (2006), Tulloch, Northrup, Honeycutt, and Wilson (2010), J. Davies (2008), 

Ercferret (2010), and Faye (2008). These sources provided configuration procedures; 

nevertheless, they lacked the details needed by forensic analysts and investigators.


116 

Windows 2008, 7 and Vista. 

Forensic analysts and investigators will observe IPv6 traffic from Windows 7, 2008 and 

Vista in network traces unless the protocol and transition mechanisms are disabled. The most 

recent versions of Windows natively supported the 6to4, Teredo, and ISATAP transition 

mechanisms and third-party support if available for the Tunnel-Broker mechanism. The 6to4 

mechanism was enabled in the default installations of these operating systems. The link-local and 

ISATAP addressing schemes were static while the other assigned addresses were randomly 

generated. The Nmap tool was able to enumerate addresses and services on the Windows 7 and 

2008 nodes from outside the network; although, the Windows Vista firewall blocked the inbound 

scans. Address and port enumeration was successful from inside the network using Nmap, 

sniffing, and other tools. Additionally, the Windows firewall protected the nodes from most 

uninitiated inbound IPv6 traffic; however, malicious router advertisements, fragments, and 

backdoor techniques were successfully employed against these nodes. 

Windows 2003 and XP. 

IPv6 traffic from Windows 2003 and XP will not be observed in network traces unless 

the protocol is installed by the user. The default installations of these older distributions were not 

configured with IPv6 support. After the user installed IPv6, MAC based link-local and 6to4 

addresses were automatically assigned to the interfaces with optional support for privacy 

extensions. The ISATAP, Teredo, and Tunnel-Broker mechanisms were easily installed and 

configured on these nodes. The Windows 2003 node was found to be vulnerable to Nmap and 

Ping scans from inside and outside the network because the Windows firewall was disabled in 

the default state. Windows XP was vulnerable to Ping scans from outside the network and 

sniffing, ping scans, and other tools from inside the network. Nmap was unable to scan the XP


117 

node from inside or outside the network because of the Windows firewall. Additionally, 

malicious router advertisements, fragments, and backdoor techniques were successfully 

employed against these nodes. 

Ubuntu and CentOS Linux. 

Forensic analysts and investigators will observe IPv6 traffic from Ubuntu and CentOS 

distributions of Linux in network traces when the protocol is installed during or after the 

installation process. These two distributions of Linux configured 6to4 and link-local addresses 

when the IPv6 option was selected during the installation process. The 6to4 and link-local 

addresses were based on the interface MAC address with optional support for privacy extensions 

that generated random addresses. Teredo, Tunnel-Broker, and ISATAP support required thirdparty 

packages to be installed that were available from the native package manager on the 

Ubuntu node or from source code on the CentOS node. The software firewall that was enabled 

by default in the CentOS distribution protected the 6to4 interface from uninitiated inbound IPv6 

traffic; however, the node was still vulnerable to Nmap scans from outside the network over the 

Teredo and Tunnel-Broker interfaces and to Nmap, ping, and other scans from inside the 

network. The Ubuntu distribution was not protected by a firewall; therefore, it was vulnerable to 

Nmap and ping scans from both inside and outside the network. Additionally, the Linux nodes 

were vulnerable to the malicious router advertisements, fragments, solicited node pings, and 

backdoor techniques that were employed during the study. 

FreeBSD and Solaris UNIX. 

IPv6 traffic from the FreeBSD and Solaris UNIX nodes will be observed in network 

traces if the protocol is installed during or after installation. Both distributions natively supported 

link-local and 6to4 addressing and Teredo, Tunnel-Broker, and ISATAP support required source


118 

code installations. The FreeBSD ports collection contained source code installations that 

provided support for Teredo and the Tunnel-Broker; however, the complexity of program 

dependencies and space limitations prevented the configuration of third-party transition 

mechanisms on the Solaris node. Both nodes configured MAC based 6to4 and link-local 

addresses with optional support for privacy extensions that provided randomly generated 

addresses. Both nodes were vulnerable to scans from Nmap, ping, and other tools from inside 

and outside the network. Additionally, the nodes were vulnerable to the malicious router 

advertisements, fragments, solicited node pings, and backdoor techniques that were employed 

during the study. 

Forensic Properties of IPv6 Transition Mechanisms 

This study evaluated network communications using local-link addresses and the 6to4, 

Teredo, ISATAP, and Tunnel-Broker transition mechanisms. Huang, Wu, and Lin (2005), 

Huitema (2006), Visoottiviseth and Bureenok (2008), Durand, Fasano, Guardini, and Lento 

(2001), and others have adequately discussed the implementations, architectures, and addressing 

schemes of these mechanisms; nevertheless, forensic analysts and investigators require 

additional details that are not contained in this research. 

Link-local. 

Link-local addresses are prefixed with FE8::/10 and are assigned to each interface on a 

node (Friacas, Baptista, Domingues, & Ferreira, 2006). The Windows 7, 2008, and Vista nodes 

assigned a random 64 bit interface identifier to the prefix and the Windows 2003, XP, Linux, 

FreeBSD, and Solaris nodes generated an interface address where the last three octets of the 

address matched the last three octets of the interface MAC address. The source of a local-link 

packet that is not spoofed can be determined by determining the MAC address contained in the


119 

Ethernet header and comparing the value to the interfaces installed on other nodes that have a 

direct network path to the host. 

Event correlation can be performed on either the link-local address or the source MAC 

address. Normal local-link traffic includes DHCPv6 (UDP), router solicitations (ICMPv6 type 

133), neighbor solicitations (ICMPv6 type 135), neighbor advertisements (ICMPv6 type 136), 

LLMNR queries or responses, multicast domain name system (MDNS UDP) queries or 

responses, and router advertisements (ICMPv6 type 134) that advertise legitimate router 

prefixes. Other traffic using local-link addresses would be considered suspicious unless a 

legitimate purpose for the communications was established. Malicious traffic includes router 

advertisements (ICMPv6 type 136) and redirects (ICMPv6 type 137) that originate from 

illegitimate sources. 

6to4. 

The 6to4 transition mechanism generates global addresses that are prefixed with 

2002::/16 and are assigned to the physical network card that possessed WAN connectivity 

(Friacas, et al., 2006). The address schema (2002:PPPP:PPPP:SSSS::IIII) consists of the prefix 

(2002), IPv4 address that is used as a gateway (P), a subnet identifier (S), and the interface 

identifier (I) (Friacas, et al., 2006; Hsieh & Kao, 2005; Jamhour & Storoz, 2002). The Windows 

7, 2008, and Vista nodes assigned a random 64 bit interface identifier to the prefix and the 

Windows 2003, XP, Linux, FreeBSD, and Solaris nodes generated an interface address where 

the last three octets of the address matched the last three octets of the interface MAC address. 

A definitive destination network can be determined from a 6to4 address that is not 

spoofed; however, the physical location of the source node may be ambiguous. The source 

network of the traffic was determined by converting the gateway IPv4 address (P)


120 

(PPPP:PPPP 16 =PP.PP.PP.PP 10 ) from hexadecimal to decimal notation and pursuing traditional 

forensic techniques to determine the physical source of the traffic. The physical source node can 

be determined if the node is assigned a static IPv4 address, is the only node on the network 

assigned to the public IP address, or is using a MAC based address scheme. When privacy 

extensions are enabled or the network node is running Windows 7, 2008 or Vista, the physical 

source node is determined by locating the node that is advertising the address prefix and then 

finding the local node that sent neighbor solicitations (ICMPv6 type 135) for that address. 

Unfortunately 6to4 addresses may change frequently; therefore, physical sourcing often depends 

on having packet capture capabilities in place during the events in question. 

Event correlation can be performed on the entire 6to4 address or the portion of the 

address that represents the gateway or subnet identifier. The 6to4 address may be used to 

communicate with external nodes. Normal 6to4 traffic includes neighbor solicitations (ICMPv6 

type 135), neighbor advertisements (ICMPv6 type 136), and router advertisements (ICMPv6 

type 134) that advertise legitimate router prefixes. Other traffic using 6to4 addresses would be 

considered suspicious unless a legitimate purpose for the communications was established. 

Malicious traffic includes router advertisements (ICMPv6 type 136) and redirects (ICMPv6 type 

137) that originate from illegitimate sources. 

Teredo. 

Teredo is a tunneling mechanism that generates global addresses with the 2001:0000::/32 

prefix (Huang, et al., 2005). Windows nodes established a Teredo interface and configured an 

address that was assigned by the Microsoft Teredo server when a node had internet connectivity; 

although, Teredo communications was disabled by the firewall in the default state. The Linux 

and FreeBSD nodes required the third-party application Miredo to be installed to communicate


121 

using the Teredo mechanism. The Teredo address 

(2001:0:TTTT:TTTT:XXXX:PPPP:NNNN:NNNN) consists of the prefix (2001:0), 32 bit IPv4 

address of the Teredo server (T), 16 bit flags (X), FFFF XOR of the 16 bit assigned port number 

of the public NAT connection (P), and the FFFF:FFFF XOR of the 32 bit assigned IPv4 address 

of the public NAT connection (N) (Huang, et al., 2005). 

A definitive destination network can be determined from a Teredo address that is not 

spoofed; however, the physical location of the source node may be ambiguous without log data 

that correlates internal nodes with outbound ports. The source IPv4 address of a Teredo packet 

can be determined by calculating the exclusive OR of the last four octets (N) of the Teredo 

address and FFFF:FFFF and then converting the result from hexadecimal to decimal 

(FFFF:FFFF XOR NNNN:NNNN = XXXX:XXXX 16 = XX.XX.XX.XX 10 ). For example, the 

source IPv4 network in the Teredo address 2001:0:53AA:64C:3C6F:80B:DF4D:0117 is 

determined using the formula: DF4D:0117 XOR FFFF:FFFF = 20B2:FEE8 = 20.B2.FE.E8 16 = 

32.178.254.232 10 . The port number that the internal node used to communicate using the Teredo 

interface can be determined by calculating the exclusive OR of the two octets preceding the 

source IPv4 address and FFFF and then converting to result from hexadecimal to a decimal. In 

the preceding example, the port number would be determined with the following formula: 080B 

XOR FFFF = F7F4 16 = 63,476 10 . The physical source of a packet would be definitive if the 

source’s IPv4 address was statically assigned or there was only one node on the network. Logs 

that capture port to node assignments or traffic captures that lead to MAC addresses would be 

needed to trace the physical source of the Teredo traffic if the node was part of a multi-node 

network that shared the public IPv4 address.


122 

Event correlation can be performed on the entire Teredo address or a portion of the 

address that represents the source’s public IPv4 address or port number. Teredo is used to 

communicate with external IPv6 hosts over an encapsulated IPv4 channel. Normal Teredo traffic 

includes router solicitations (ICMPv6 type 133), router advertisements (ICMPv6 type 134) that 

advertise the Teredo prefix, Teredo packets without a payload (Bubble packets), and DNS 

queries and responses that determine the IPv4 address of the Teredo server. Other IPv6 traffic 

from the Teredo addresses or IPv4 traffic between the host and the Teredo server would be 


ISATAP. 

The ISATAP mechanism assigns a custom prefix to a node with the last 32 bits of the 

address containing the IPv4 address of the node. The Windows and Linux nodes automatically 

configured an ISATAP address when they located an ISATAP router that answered LLMNR or 

NetBIOS (NBNS) name queries for “isatap”. 

A definitive destination node can be determined from an ISATAP address that is not 

spoofed if the IPv4 address can be traced back to a physical node. The prefix used in an ISATAP 

address can be based on a public IPv6 address, a local address, or another transition mechanism. 

A whois query of the public IPv6 address or an analysis of the transition mechanism address will 

lead to the location of the ISATAP router. The physical source node on the local network can be 

determined by tracing the IPv4 address contained in the last 32 bits of the ISATAP address to the 

physical nodes connected to the same network as the router. 

Event correlation can be performed on the ISATAP address. This transition mechanism 

facilitates local or remote communications with other IPv6 nodes. Normal traffic includes router 

advertisements (ICMPv6 type 134), NetBIOS name service (NBNS) queries and responses for


123 

“ISATAP” and LLMNR queries and responses for “ISATAP”. Other IPv6 traffic would be 


Malicious traffic includes router advertisements (ICMPv6 type 136) and redirects (ICMPv6 type 

137) that originate from illegitimate sources. 

Tunnel-Broker. 

The Tunnel-Broker mechanism configured a global address that was assigned by the 

service provider. The Windows, Linux, FreeBSD, and Solaris nodes required the installation of 

third-party applications to communicate using the Tunnel-Broker mechanism. The interface 

identifier on the assigned IPv6 addresses changed as frequently as every few minutes; although, 

a static address could be obtained after establishing a free account with the service provider. 

Traffic that originated from Tunnel-Broker clients had an IPv6 address that was registered to a 

Tunnel-Broker service provider. The physical source of the traffic can only be determined with 

cooperation from the service provider to trace the packets back to the IPv4 address of the source 

node. 

Event correlation can be based on a static Tunnel-Broker address; however, anonymous 

addressing schemes require correlating to the prefix assigned to the service provider. Normal 

Tunnel-Broker traffic includes IPv4 packets with a source or destination address assigned to the 

tunnel server endpoint. These packets include an initial conversation with payloads containing 

setup parameters and then subsequent communications that maintain the connection state. 

Suspicious traffic includes any other IPv4 traffic with the source or destination of the tunnelserver 

that contains encapsulated IPv6 packets.


124 

Proposed Methodology for the Forensic Analysis of IPv6 Traffic in a Transitional Network 

The purpose of this study was to present a methodology for properly analyzing and 

investigating IPv6 traffic within transitional networks to help forensic analysts and investigators 

recognize IPv6 based attack vectors. This methodology applies to five key network forensic 

process steps: investigating physical nodes, analyzing network traces, sourcing addresses, 

correlating events, and identifying threats. 

Physical node investigation. 

Understanding the state of IPv6 transition mechanisms installed on a physical node is an 

important consideration for network forensic analysis. Figure 8 illustrates the proposed process 

flow methodology for determining the state of IPv6 transition mechanism installed on a node 

running the Windows, Linux, FreeBSD, or UNIX operating systems. The flow is designed to be 

iterative and repeat from the beginning for every targeted interface and IPv6 address.


125 

Windows 

Linux/BSD/UNIX 

Run ipconfig 

Run ifconfig 

yes 

Multiple address 

yes 

6to4 with 

privacy extensions 

Interface 

has IPv4 Internet 

connectivity 

no 

yes 

Evaluate assigned 

addreses 

IPv6 

address with 

2002 

prefix 

no 

IPv6 

address with 

FE8 

prefix 

yes 

no 

6to4 

Link-local 

Run whois query on 

global IPv6 address 

no 

Other 

IPv6 prefixs 

yes 

Dual-stack IPv6 or 

another mechanism 

no 

IPv6 not Installed 

on the interface 

2001:0 

prefix and 

results indicate 

IANA Reserved 

Block 

no 

Result 

indicates known 

Tunnel-Broker 

provider 

yes 

yes 

Teredo 

Tunnel-Broker 

no 

Evaluate Installed 

programs 

Tunnel-Broker 

software created 

interface 

no 

yes 

Result = node 

IPv4 address 

no 

yes 

IPv6 

address with 

FE8 

prefix 

yes 

ISATAP 

Link-local 

Convert last 4 octets 

of IPv6 address to 

decimal (IPv4 address) 

no 

Dual-stack or 

another mechanism 

Figure 8. IPv6 Transition Mechanism State Determination in Win, Linux, BSD, and UNIX 

Network traces analysis. 

Accurate network trace analysis depends on understanding if traffic has flowed through 

an IPv6 transition mechanism. The proposed process flow methodology is illustrated in Figure 9.


126 

It is designed to follow an iterative analysis process that repeats for each group of conversations 

that has not been classified. 

Start 

Filter IPv6 packets 

ie.freenet6.net 

and sixxs.net 

Tunnel- 

Broker domains 

observed 

yes 

Endpoint 

is an ISATAP 

server 

ie.teredo.ipv6.microsoft.com and 

teredo.remlab.net 

yes 

Tunnel-Broker 

and ISATAP 

no 

no 

Tunnel-Broker 

IPv6 

packets 

observed 

no 

Resolve IPv4 

addresses 

yes 

Teredo 

domains 

observed 

yes 

Endpoint 

is an ISATAP 

server 

yes 

Teredo 

And ISATAP 

yes 

Filter Teredo 

packets 

yes 

2001 

address prefix 

observed 

no 

no 

Teredo 

No transition 

mechanisms 

Teredo 

packets 

observed 

no 

FE8 

address prefix 

observed 

yes 

Local-Link 

no 

List IPv6 endpoint 

addresses 

2002 

Endpoint 

no 

address prefix yes is an ISATAP yes 6to4 and ISATAP 

observed 

server 

no 

no 

6to4 

Resolve IPv6 

addresses 

Endpoint 

is an ISATAP 

server 

yes 

ISATAP 

no 

Native IPv6 or 

other mechanism 

Figure 9. IPv6 Transition Mechanism Detection in a Network Trace 

Event Correlation. 

Event correlation associates similar activities in a trace to better understand what is 

occurring and who is responsible. Correlation is often based on the source IP address; however, 

some of the IPv6 transition mechanisms in this study established dynamic addresses that changed


frequently. Table 37 presents the address schemas for each transition mechanism and possible 

traffic correlation elements that can be used to develop a better understanding of network events. 

Table 37. IPv6 Transition Mechanism Address Correlation Elements 

Transition 

Mechanism Address Schema Correlation Elements 

6to4 2002:PPPP:PPPP:SSSS::IIII Entire Address 

(P=node GW, S=subnet, I=interface ID) PPPP:PPPP 

PPPP:PPPP:SSSS 

Teredo 2001:0:TTTT:TTTT:FFFF:PPPP:NNNN:NNNN Entire Address 

(T=Teredo GW, F=flags, P=port, N=node GW) NNNN:NNNN 

PPPP:NNNN:NNNN 

ISATAP XXXX::XXXX:MMMM:MMMM Entire Address 

Tunnel 

(X=prefix, M=node IPv4 Address) 

XXXX::YYYY 

Entire Address 

Broker (X=Tbroker range, Y=node/client ID) XXXX 

Threat Identification. 

The classification of network events in a transitional network depends on understanding 

the nature of normal, suspicious, and malicious traffic. Table 38 presents a list of traffic 

classifications that were observed in this study to help the analyst or investigator understand the 

nature of the traffic observed in a network trace. Each environment has unique characteristics; 

therefore, this list is designed to establish a generic baseline from which to develop a 

classification scheme for a particular environment.


128 

Table 38. IPv6 Transition Mechanism Traffic Classification Scheme 

Transition 

Suspicious 

Mechanism Normal Traffic Traffic Malicious Traffic 

Link-Local DHCPv6 

LLMNR 

MDNS 

Router Solicit. (T133) 

Router Ads. (T134) 

Neighbor Solicit. (T135) 

Neighbor Ads. (T136) 

6to4 


Neighbor Solicit. (T135) 

Neighbor Ads. (T136) 

Teredo IPv4 DNS Query 

Teredo Bubble packets 

Router Solicit. (T133) 


ISATAP NBNS Queries for isatap 

LLMNR Queries for isatap 


Tunnel-Broker 

All other unknown Unknown Router Ads 

traffic 

Redirects (T137) 


traffic 


All other unknown 

traffic 


traffic 


All other unknown 

traffic 

Addresses sourcing. 

Issue resolution or criminal prosecution depends on tracing packets back to the physical 

machine from which it originated. Figure 10 to 14 illustrate a methodology for tracing a source 

address for each transition mechanism. The proposed process flow utilizes the sourcing 

techniques developed in this study; although, the result may lead to an inconclusive or inaccurate 

result if the results are not substantiated with information from other sources.


129 

Figure 10. Physical Source Node Determination from a Link-Local Address 

6to4 

Convert octet 3 to 6 of IPv6 

address to decimal to obtain 

gateway IPv4 address. 

i.e. Convert part P in address 

2002:PPPP:PPPP:SSSS::IIII where 

PPPP:PPPP 16 = PP.PP.PP.PP 10 

Trace IPv4 address of 

gateway to network node. 

Static 

IPv4 address or 

single-node 

network 

yes 

Physical source 

no 

Run address trace route 

to find final hop switch 

Node responded 

yes 

Locate node with 

configured address 


i.e. Part M in address 

2002::XXXX:XXMM:MMMM equals 

part A in the node MAC address 

where the interface MAC = 

XX:XX:XX:AA:AA:AA 

no 

Compare last 3 octets of 

address to last 3 octets of 

MAC on local nodes 

Match 

found and OS 

is Win 23K, XP, 

Linux, BSD, 

or UNIX 

yes 


no 

Obtain logs or 

network traces of 

switch traffic during 

the time period in 

question 

Filter for link-local 

addresses with same 

interface ID 

i.e. Locallink address calculated form 

portion E in 6to4 address 

2002:XXXX::EEEE:EEEE:EEEE:EEEE = 

FE80::EEEE:EEEE:EEEE:EEEE 

Traffic found 

yes 

Compare source 

MAC to local 

nodes 

Match found 

yes 


no 

Filter for traffic 

containing the same 

address 

Traffic found 

yes 

no 

Inconclusive: Node not 

found or MAC altered 

no 

Figure 11. Physical Source Node Determination from a 6to4 Address


130 

Figure 12. Physical Source Node Determination from a Teredo Address 

Figure 13. Physical Source Node Determination from a ISATAP Address 

Figure 14. Physical Source Node Determination from a Tunnel-Broker Address


131 

Limitations and Future Research 

This study was limited by resource availability and scope in four primary areas. First, the 

researcher did not have access to every operating system or the time to evaluate every transition 

mechanism that could have been investigated. Future research is needed to identify the behavior 

of other operating systems like the Apple Mac OS and other distributions of Linux. Additionally, 

future research could evaluate transition mechanisms that were not included in the study like 

SIIT, NAT-PT, BIA, BIS, SOCK64, and TRT. Second, the virtual network that was employed in 

the study simulated a network of nodes connected to a single switch; however, the availability of 

a single physical host prevented the testing of nodes on multiple subnets. Future research is 

needed to evaluate the behavior of transition mechanisms in a multi-layer enterprise network. 

Third, time limitations narrowed the scope of this study to include only two-way 

communications between network nodes. Future research is needed to profile IPv6 based 

application vulnerabilities and attack vectors. Finally, this study contributed a small piece of a 

disjointed and unorganized body of knowledge and there remains a significant need to unify the 

academic, practitioner, and legal communities under a common process that builds a scientific 

foundation for the network forensic discipline.


132 

References 

Abad, C. (2001). IP Checksum Covert Channels and Selected Hash Collision, Tech Republic, 

UCLA. from http://http://gray-world.net/papers/ipccc.pdf 

Afifi, H., & Toutain, L. (1999). Methods for IPv4-IPv6 transition. Paper presented at the IEEE 

Symposium on Computers and Communications. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ISCC.1999.780953 

AlJa'afreh, R. e..Mellor, J..Kamala, M., & Kasasbeh, B. (2008). Bi-directional mapping system 

as a new IPv4/IPv6 translation mechanism. Paper presented at the Tenth International 

Conference on Computer Modeling and Simulation. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/UKSIM.2008.90 

An, G., & Kim, K. (2008). Real-time IP checking and packet marking for preventing ND-DoS 

attack employing fake source IP in IPv6 LAN. Paper presented at the Proceedings of the 

5th international conference on Autonomic and Trusted Computing, Oslo, Norway. 

Anaya, E. A..Miyatake, M. N., & Meana, H. M. P. (2009). Network forensics with neurofuzzy 

techniques. Paper presented at the Midwest Symposium on Circuits and Systems. 

Retrieved from http://doi.ieeecomputersociety.org/10.1109/MWSCAS.2009.5235900 

Avison, D. E..Lau, F..Myers, M. D., & Nielsen, P. A. (1999). Action research. Communications 

of the ACM, 42(1), 94-97. doi: 10.1145/291469.291479 

Ayres, D. (2010). Need help setting up a teredo client, Windows Developer Center. Retrieved 

Feb 22, 2011, from 

http://social.msdn.microsoft.com/Forums/en/peertopeer/thread/4d1c1762-1e04-442c 

810e-82b44d88d460


133 

Backtrack IPv6 Configuration. (n.d.). Retrieved Feb 16, 2011, from 

http://zerohat.de/_shared_files/videos/BT4_IPv6_Quick/ 

BackTrack Linux. (n.d.). Retrieved Feb 9, 2011, from http://backtrack-linux.org 

Baryamureeba, V., & Tushabe, F. (2004). The enhanced digital investigation process model. 

Makerere University. 

Retrieved from 

Baskerville, R. L. (1999). Investigating information systems with action research. Commun. AIS, 

2(3es), 4. 

Beebe, N. L., & Clark, J. G. (2005). A hierarchical, objectives-based framework for the digital 

investigations process. Digital Investigation, 2(2), 147-167. doi: 

10.1016/j.diin.2005.04.002 

Bejtlich, R. (2004). The tao of network security monitoring: Beyond intrusion detection. New 

York: Addison-Wesley Publishing, Inc. 

Bi, J..Leng, X., & Wu, J. (2007). Scalable IPv4/IPv6 transition: a peer-to-peer based approach. 

Paper presented at the Proceedings of the 2005/2006 International Conference on 

Databases, Information Systems, and Peer-to-Peer Computing, Trondheim, Norway. 

Bishop, M..Marzullo, K., & Peisert, S. (2008). Computer forensics in forensis. SIGOPS 

Operating System Review, 42(3), 112-122. doi: 

http://doi.acm.org/10.1145/1368506.1368521 

Brenner, S. W. (2007). "AT LIGHT SPEED": ATTRIBUTION AND RESPONSE TO 

CYBERCRIME/TERRORISM/WARFARE. [Article]. Journal of Criminal Law & 

Criminology, 97(2), 379-475. 

Broadway, J..Turnbull, B., & Slay, J. (2008). Improving the Analysis of Lawfully Intercepted 

Network Packet Data Captured for Forensic Analysis. Paper presented at the The Third


134 

International Conference on Availability, Reliability and Security. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ARES.2008.122 doi:10.1109/ARES.2008.122 

Broucek, V., & Turner, P. (2004). Computer incident investigations: e-forensic insights on 

evidence acquisition. Paper presented at the European Institute for Computer Anti-Virus 

Research, Copenhagen. 

Byrne, E. (2005). Using action research in information systems design to address change: A 

South African health information systems case study. Paper presented at the Proceedings 

of the 2005 annual research conference of the South African institute of computer 

scientists and information technologists on IT research in developing countries, White 

River, South Africa. 

Caicedo, C. E..Joshi, J. B. D., & Tuladhar, S. R. (2009). IPv6 security challenges. Perspectives, 

42, 36-42. Retrieved from http://doi.ieeecomputersociety.org/10.1109/MC.2009.54 

Candolin, C., & Nikander, P. (2001). IPv6 source addresses considered harmful. Paper presented 

at the Sixth Nordic Workshop on Secure IT. 

Carpenter, B., & Jung, C. (1999). Transmission of IPv6 over IPv4 domains without explicit 

tunnels. RFC 2529: Internet Engineering Task Force (IETF). 

Carpenter, B., & Moore, K. (2001). Connection of IPv6 domains via IPv4 clouds. RFC 3056: 

Internet Engineering Task Force (IETF). 

Carr, C..Gunsch, G., & Reith, M. (2002). An examination of digital forensic models. 

International Journal of Digital Evidence, 1(2). 

Carrier, B., & Spafford, E. H. (2003). Getting physical with the digital investigation process. 


Casey, E. (2000). Digital evidence and computer crime. San Diego: Academic Press.


135 

Casey, E. (2004). Network traffic as a source of evidence: tool strengths, weaknesses, and future 

needs. Digital Investigation, 1(1), 28-43. doi: 10.1016/j.diin.2003.12.002 

Castro, S. (2006, May). Cooking Channels. hakin9 Magazine, 50-57. 

CentOS. (n.d.). Retrieved Feb 9, 2011, from http://centos.org/ 

Chapter 31 advanced networking. (2010). FreeBSD Handbook. Retrieved Aug 6, 2010, from 

http://www.freebsd.org/doc/en/books/handbook/network-ipv6.html 

Choi, D..Fischer, C..Lee, A. Y..Lou, E. L..Chung-Zin, L., & Hsien-Chuen, Y. (2006). Transition 

to IPv6 and support for IPv4/IPv6 interoperability in IMS. Bell Labs Technical Journal, 

10(4), 261-270. doi: 10.1002/bltj.20138 

Ciardhuáin, S. Ó. (2004). An extended model of cybercrime investigations. International Journal 

of Digital Evidence, 3(1). 

Cohen, F. (2009). Two models of digital forensic examination. Paper presented at the Fourth 

IEEE International Workshop on Systematic Approaches to Digital Forensic Engineering. 

Retrieved from http://doi.ieeecomputersociety.org/10.1109/SADFE.2009.8 

doi:10.1109/SADFE.2009.8 

Cohen, M. I. (2008a). PyFlag - An advanced network forensic framework. Digital Investigation, 

5(Supplement 1), S112-S120. doi: 10.1016/j.diin.2008.05.016 

Cohen, M. I. (2008b). Source attribution for network address translated forensic captures. Digital 

Investigation, 5(3-4), 138-145. doi: 10.1016/j.diin.2008.12.002 

Conta, A., & Deering, S. (1998). Internet control message protocol (ICMPv6) for the Internet 

protocol version 6 (IPv6) specification. RFC 2463: Internet Engineering Task Force 

(IETF).


136 

Convery, S., & Miller, D. (2004). IPv6 and IPv4 threat comparison and best-practice evaluation 

(v1.0): Cisco Systems. Retrieved from 

http://www.cisco.com/web/about/security/security_services/ciag/documents/v6-v4 

threats.pdf 

Cooper, M., & Yen, D. C. (2005). IPv6: business applications and implementation concerns. 

Computer Standards & Interfaces, 28(1), 27-41. doi: 10.1016/j.csi.2004.11.001 

Cowan, A. L. (2007, Feb 14). Teacher Faces Jail Over Pornography on Class Computer, New 

York Times. 

daemon9. (1997, Sept). LOKI2: The Implementation. Phrack Magazine, 7(51). 

Daubert v. Merrell Dow Pharmaceuticals Inc., 579 (U.S 1993). Retrieved from 

http://www.law.cornell.edu/supct/html/92-102.ZS.html 

Davies, E..Krishnan, S., & Savola, P. (2007). IPv6 transition/coexistence security 

considerations. RFC 4942: Internet Engineering Task Force (IETF). 

Davies, J. (2008). Understanding IPv6 (2nd ed.): Microsoft Press. 

Deering, S..Haberman, B..Jinmei, T..Nordmark, E., & Zill, B. (2005). IPv6 Scoped Address 

Architecture. RFC 4007: Internet Engineering Task Force (IETF). 

DistroWatch.com. (n.d.). Netsonic.com. Retrieved Dec 14, 2010, from http://distrowatch.com/ 

Dobrucki, M. (1999). The effects of the transition to IPv6 on Internet security. 

Durand, A..Fasano, P..Guardini, I., & Lento, D. (2001). IPv6 tunnel broker. RFC 3053: Internet 

Engineering Task Force (IETF). 

Electronic crime scene investigation: A guide for first responders. (2001). Technical Working 

Group for Electric Crime Scene Investigation.


137 

Elgoarany, K., & Eltoweissy, M. (2007). Security in mobile IPv6: A survey. Information 

Security Technical Report, 12, 32-43. doi: 10.1016/j.istr.2007.02.002 

Elmaghraby, A..Higgins, G..Keeling, D. W..Losavio, M., & Shutt, J. (2008). Implications of 

attorney experiences with digital forensics and electronic evidence in the United States. 

Paper presented at the Third International Workshop on Systematic Approaches to 

Digital Forensic Engineering. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/SADFE.2008.11 

doi:10.1109/SADFE.2008.11 

Emre, D., & Ali, B. (2010). IPV4/IPV6 security and threat comparisons. Procedia - Social and 

Behavioral Sciences, 2, 5285-5291. doi: 10.1016/j.sbspro.2010.03.862 

Enabling IPv6 Privacy Extensions on Ubuntu Linux. (2011). IPv6 Related Stuff. Retrieved Mar 

4, 2011, from http://ipv6-or-no-ipv6.blogspot.com/2011/02/enabling-ipv6-privacyextensions-on.html 

Ercferret18 (2010). IPv6 Retrieved Aud 6, 2010, from https://wiki.ubuntu.com/IPv6 

Faye, F. (2008). IPV6 configuration on REDHAT CENTOS FEDORA Retrieved Aug 6, 2010, 

from http://www.generationip.com/documentation/system-documentation/73-ipv6 

configuration-on-redhat-centos-fedora 

fdz. (2010). ISATAP client on Linux, The IPv6 Portal. Retrieved Feb 24, 2011, from 

http://www.ipv6 

portal.com/index.php?option=com_content&view=article&id=14:isatap-client-onlinux&catid=13:howto&Itemid=4&lang=en 

Feamster, N. (2002, Aug). Infranet: Circumventing Web Censorship and Surveillance. Paper 

presented at the 11th USENIX Security Symposium.


138 

Fisk, G. (2002, Oct). Eliminating Steganography in Internet Traffic with Active Wardens. Paper 

presented at the 5th International Workshop on Information Hiding. 

Fraud Examiners Manual. (2008). Association of Certified Fraud Examiners. 

FreeBSD. (n.d.). Retrieved Feb 9, 2011, from http://freebsd.org 

Friacas, C..Baptista, M..Domingues, M., & Ferreira, P. (2006). 6TO4 versus 

TUNNELBROKERS. Paper presented at the Proceedings of the International Multi- 

Conference on Computing in the Global Information Technology (ICCGI'06). Retrieved 

from http://doi.ieeecomputersociety.org/10.1109/ICCGI.2006.1 

Giffin, J. (2002, Apr). Covert Messaging Through TCP Timestamps. Paper presented at the 

Privacy Enhancing Technologies Workshop (PET). 

Gil, T. M. (2005). IP-over-DNS using NSTX, from http://thomer.com/howtos/nstx/ 

Gilligan, R., & Nordmark, E. (2000). Transition mechanisms for IPv6 hosts and routers. RFC 

2893: Internet Engineering Task Force (IETF). 

Girling, C. G. (1987, Feb). Covert Channels in LAN’s. IEEE Transactions in Software 

Engineering, SE-13(2), 292-296. 

gogoCLIENT. (n.d.). Retrieved Feb 9, 2011, from 

http://gogonet.gogo6.com/profile/gogoCLIENT 

GosevaPopstojanova, K..Miller, B..Pantev, R., & Dimitrijevikj, A. (2010). Empirical Analysis of 

Attackers Activity on Multi-tier Web Systems. Paper presented at the 24th IEEE 

International Conference on Advanced Information Networking and Applications. 

Retrieved from http://doi.ieeecomputersociety.org/10.1109/AINA.2010.138 

doi:10.1109/AINA.2010.138


139 

Graf, T. (2003). Messaging over IPv6 destination options. Swiss Unix User Group. Retrieved 

from http://grayworld.net/papers/messip6.txt 

Grobler, C. P..Louwrens, C. P., & Solms, S. H. V. (2010). A framework to guide the 

implementation of proactive digital forensics in organisations. Paper presented at the 



Hagino, J., & Yamamoto, K. (2001). An IPv6-to-IPv4 transport relay translator. RFC 3142: 


Halfscan6. (n.d.). Retrieved Feb 9, 2011, from http://freshmeat.net/projects/halfscan6 

Hogg, S. (2009). Windows 7 IPv6 Support, Network World. Retrieved 2011, Mar 4, from 

http://www.networkworld.com/community/node/37947 

Hsieh, I. P., & Kao, S. J. (2005). Managing the co-existing network of IPv6 and IPv4 under 

various transition mechanisms. Paper presented at the Proceedings of the Third 

International Conference on Information Technology and Applications (ICITA’05). 

Retrieved from http://doi.ieeecomputersociety.org/10.1109/ICITA.2005.175 

Huang, S. M..Wu, Q., & Lin, Y. B. (2005). Tunneling IPv6 through NAT with Teredo 

mechanism. Paper presented at the Proceedings of the 19th International Conference on 

Advanced Information Networking and Applications (AINA’05). Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/AINA.2005.333 

Huang, S. Q..Zhang, H. M., & Yao, G. X. (2009). Research of NIDS in IPV6 based on protocol 

analysis and pattern matching. Paper presented at the Second International Workshop on 

Knowledge Discovery and Data Mining. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/WKDD.2009.24


140 

Huitema, C. (2006). Teredo: tunneling IPv6 over UDP through network address translations 

(NATs). RFC 4380: Internet Engineering Task Force (IETF). 

Internet Users. (2009). World Bank. from http://databank.worldbank.org 

Jamhour, E., & Storoz, S. (2002). Global mobile IPv6 addressing using transition mechanisms. 

Paper presented at the Proceedings of the 27th Annual IEEE Conference on Local 

Computer Networks (LCN02). Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/LCN.2002.1181816 

Järvinen, P. (2007). Action research is similar to design science. Quality & Quantity, 41(1), 37 

54. doi: 10.1007/s11135-005-5427-1 

Jones, B. R. (2007). COMMENT: VIRTUAL NEIGHBORHOOD WATCH: OPEN SOURCE 

SOFTWARE AND COMMUNITY POLICING AGAINST CYBERCRIME. [Article]. 

Journal of Criminal Law & Criminology, 97(2), 601-629. 

Kammas, P..Komninos, T., & Stamatiou, Y. C. (2009). Modeling the co-evololution DNS worms 

and anti-worms in IPv6 networks. Paper presented at the Fifth International Conference 

on Information Assurance and Security. Retrieved from doi:10.1109/IAS.2009.334 

Kempf, J..Nordmark, E., & Nikander, P. (2004). IPv6 neighbor discovery (ND) trust models and 

threats. RFC 3756: Internet Engineering Task Force (IETF). 

Kerr, O. S. (2005, Jan). Digital evidence and the new criminal procedure. Columbia Law Review. 

Kim, J. W..Cho, H. H..Mun, G. J..Seo, J. H..Noh, B. N., & Kim, Y. M. (2007). Experiments and 

countermeasures of security vulnerabilities on next generation network. Paper presented 

at the Future Generation Communication and Networking. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/FGCN.2007.122


141 

Kitamura, H. (2001). A SOCKS-based IPv6/IPv4 gateway mechanism. RFC 3089: Internet 


Lan, T. H..Lin, A. C..Lin, I. L., & Wu, T. (2005). Establishment of the standard operating 

procedure (SOP) for gathering digital evidence. Paper presented at the First International 

Workshop on Systematic Approaches to Digital Forensic Engineering (SADFE’05). 


doi:10.1109/SADFE.2005.12 

Lee, H. C..Palmbach, T. M., & Miller, M. T. (2001). Henry Lee’s crime scene handbook. San 

Diego: Academic Press. 

Lee, S..Shin, M.-K..Kim, Y.-J..Nordmark, E., & Durand, A. (2002). Dual stack hosts using 

"bump-in-the-API" (BIA). RFC 3338: Internet Engineering Task Force (IETF). 

Lee, Y..Shin, S..Choi, S., & Son, H. g. (2007). IPv6 anomaly traffic monitoring with IPFIX. 

Paper presented at the Second International Conference on Internet Monitoring and 

Protection (ICIMP 2007). Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ICIMP.2007.23 

Leng, X..Bi, J..Zhang, M., & Wu, J. (2007). Connecting IPvX networks over IPvY with a P2P 

method. Journal of Network System Management, 15, 383-399. doi: 10.1007/s10922-007 

9071-z 

Leong, R. S. C. (2006). FORZA - Digital forensics investigation framework that incorporate 

legal issues. Digital Investigation, 3(Supplement 1), 29-36. doi: 

10.1016/j.diin.2006.06.004


142 

Lindqvist, J. (2006). IPv6 stateless address autoconfiguration considered harmful. Paper 

presented at the MILCOM. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/MILCOM.2006.302471 

Linode. (n.d.). Retrieved Feb 15, 2011, from http://www.linode.com/ 

Littlefield, M. (2007, June). Emerging legal and forensic issues for computer scientists teaching 

digital forensics and information assurance: The import of United States v. Garnier. 

Paper presented at the Digital Forensics Working Group Workshop. Retrieved from 

Losavio, M. M. (2005). The law of possession of digital objects: Dominion and control issues for 

digital forensics investigations and prosecutions. Paper presented at the First 

International Workshop on Systematic Approaches to Digital Forensic Engineering 

(SADFE’05). Retrieved from 


doi:10.1109/SADFE.2005.25 

Lucena, N. B..Lewandowski, G., & Chapin, S. J. (2005, May). Covert Channels in IPv6. Paper 

presented at the Privacy Enhancing Technologies (PET). 

Lutchann. (2002). Linux ISATAP setup. Retrieved Feb 23, 2011, from 

http://www.litech.org/isatap/ 

Mac OS X 10.5 Help. (2010). Apple Inc. Retrieved Aug 6, 2010, from http://docs.info.apple.com 

Mackay, M..Edwards, C..Dunmore, M..Chown, T., & Carvalho, G. (2003, May-June). A 

scenario-based review of IPv6 transition tools. IEEE Internet Computing, 27-35. 

Retrieved from http://doi.ieeecomputersociety.org/10.1109/MIC.2003.1200298 

Mandia, K., & Prosise, C. (2001). Incident response: Osborne/McGraw-Hill.


143 

Mazurczyk, W., & Kotulski, Z. (2006, Sept). New VoIP Traffic Security Scheme with Digital 

Watermarking. Paper presented at the International Conference on Computer Safety, 

Reliability, and Security (SafeComp). 

Metasploit. (n.d.). Retrieved Feb 9, 2011, from http://metasploit.com 

Miredo. (n.d.). Retrieved Feb 9, 2011, from http://remlab.net/miredo 

Multicast IPv6 addresses. (2005). Microsoft Technet. from http://technet.microsoft.com/enus/library/cc781068(WS.10).aspx 

Naqvi, S..Dallons, G., & Ponsard, C. (2010). Applying digital forensics in the future internet 

enterprise systems - European SME's perspective. Paper presented at the Fifth 

International Workshop on Systematic Approaches to Digital Forensic Engineering. 


doi:10.1109/SADFE.2010.28 

Netcat. (n.d.). Nmap. Retrieved Mar 6, 2011, from http://nmap.org/ncat/ 

Netdude. (n.d.). Retrieved Mar 3, 2011, from http://netdude.sourceforge.net/ 

Netsh Commands for Interface (IPv4 and IPv6). (2008). Microsoft. Retrieved Feb 23, 2011, from 

http://technet.microsoft.com/en-us/library/cc770948(WS.10).aspx 

Nikkel, B. J. (2005). Generalizing sources of live network evidence. Digital Investigation, 2(3), 

193-200. doi: 10.1016/j.diin.2005.08.001 

Nikkel, B. J. (2006). Improving evidence acquisition from live network sources. Digital 

Investigation, 3(2), 89-96. doi: 10.1016/j.diin.2006.05.002 

Nikkel, B. J. (2007). An introduction to investigating IPv6 networks. Digital Investigation, 4(2), 

59-67. doi: 10.1016/j.diin.2007.06.001 

Nmap. (n.d.). Retrieved Feb 9, 2011, from http://nmap.org


144 

Nordmark, E. (2000). Stateless IP/ICMP translation algorithm (SIIT). RFC 2765: Internet 


Nute, E. (2010). Installing gogoc in Ubuntu 10.10 Maverick Meerkat is easy except DNS. 

Retrieved Feb 1, 2011, from http://gogonet.gogo6.com/forum/topics/installing-gogoc-inubuntu?commentId=3731159:Comment:118717 

Oracle Solaris. (n.d.). Retrieved Feb 9, 2011, from http://oracle.com/solaris 

Ostinato. (n.d.). Retrieved Feb 9, 2011, from http://code.google.com/p/ostinato 

Padgett, P. (2001). Corkscrew. from http://www.agroman.net/corkscrew/ 

Padlipsky, M. A..Snow, D. W., & Karger, P. A. (1978, Aug). Limitations of End-to-End 

Encryption in Secure Computer Networks, Tech Republic, ESD-TR-78-158, Mitre 

Corporation. from http://stinet.dtic.mil/cgibin/GetTRDoc?AD=A059221&Location=U2&doc=GetTRDoc.pdf 

Palmer, G. (2001). A road map for digital forensics research. Utica, NY: First Digital Forensic 

Research Workshop (DFRWS). Retrieved from 

Palmer, G. (2001, Aug). A road map for digital forensic research. Paper presented at the First 

Digital Forensic Workshop, DFRWS Technical Report DTR-T001-01. 

Park, T. K., & Ra, I. (2008). Design and evaluation of a network forensic logging system. Paper 

presented at the Third International Conference on Convergence and Hybrid Information 

Technology. Retrieved from http://doi.ieeecomputersociety.org/10.1109/ICCIT.2008.28 

doi:10.1109/ICCIT.2008.28 

Phang, S. Y..Lee, H., & Lim, H. (2008). Design and implementation of V6SNIFF: An efficient 

IPv6 packet sniffer. Paper presented at the Third 2008 International Conference on


145 

Convergence and Hybrid Information Technology. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ICCIT.2008.279 

Ponec, M..Giura, P..Bronnimann, H., & Wein, J. (2007). Highly efficient techniques for network 

forensics. Paper presented at the Proceedings of the 14th ACM Conference on Computer 

and Communications Security, Alexandria, Virginia, USA. Retrieved from 

doi:10.1145/1315245.1315265 

Radhakrishnan, R..Majid, J..Shabana, M., & Moinuddin, M. (2007). Security issues in IPv6. 

Paper presented at the Third International Conference on Networking and 

Services(ICNS'07). Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ICNS.2007.106 

Rowland, C. H. (1997, July). Covert Channels in the TCP/IP Protocol Suite. First Monday. 

Savola, P. (2005). Observations of IPv6 traffic on a 6to4 relay. SIGCOMM Computer 

Communications Review, 35(1), 23-28. doi: http://doi.acm.org/10.1145/1052812.1052821 

Savola, P., & Patel, C. (2004). Security considerations for 6to4. RFC 3964: Internet Engineering 

Task Force (IETF). 

Scapy. (n.d.). Retrieved Feb 9, 2011, from http://www.secdev.org/projects/scapy 

Schroeder, S. C. (2005). How to be a digital forensic expert witness. Paper presented at the 

Proceedings of the First International Workshop on Systematic Approaches to Digital 

Forensic Engineering (SADFE’05). Retrieved from 


Seo, S. H., & Kong, I. Y. (2005). A performance analysis model of PC-based software router 

supporting IPv6-IPv4 translation for residential gateway. Paper presented at the 

Proceedings of the Fourth Annual ACIS International Conference on Computer and


146 

Information Science (ICIS’05). Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ICIS.2005.14 

Servetto, S. D., & Vetterli, M. (2001, June). Communication Using Phantoms: Covert Channels 

in the Internet. Paper presented at the IEEE International Symposium on Information 

Theory (ISIT). 

Shengyang, C., & Yanlei, S. (2010). P2P communication mechanism based on request 

forwarding in IPv4 and IPv6 coexistence network. Paper presented at the International 

Conference on e-Education, e-Business, e-Management and e-Learning. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/IC4E.2010.16 

Shin, Y. (2008). New digital forensics investigation procedure model. Paper presented at the 

Fourth International Conference on Networked Computing and Advanced Information 

Management. Retrieved from http://doi.ieeecomputersociety.org/10.1109/NCM.2008.116 

doi:10.1109/NCM.2008.116 

Sommer, P. (1999). Intrusion detection systems as evidence. Computer Networks, 31(23-24), 

2477-2487. doi: 10.1016/s1389-1286(99)00113-9 

Sotillo, S. (2006). IPv6 security issues. 

Susman, G. I., & Evered, R. D. (1978). An assessment of the scientific merits of action research. 

Administrative Science Quarterly, 23(4), 582-603. 

System administration guide: IP services. (2009). Sun Microsystems. Retrieved Aug 6, 2010, 

from http://docs.sun.com/app/docs/doc/816-4554/ipv6-ref-83?l=en&a=view 

Szigeti, S., & Risztics, P. (2004). Will IPv6 Bring Better Security? Paper presented at the The 

30th EUROMICRO Conference. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/EURMIC.2004.1333418


147 

Tadayoshi, K. (2005). Remote Physical Device Fingerprinting. IEEE Transactions on 

Dependable and Secure Computing, 2, 93-108. 

Tantayakul, K..Kamolphiwong, S., & Angchuan, T. (2008). IPv6@HOME. Paper presented at 

the Proceedings of the International Conference on Mobile Technology, Applications, 

and Systems, Yilan, Taiwan. Retrieved from 


TCPdump. (n.d.). Retrieved Feb 9, 2011, from http:/tcpdump.org 

TCPReplay. (n.d.). Retrieved Mar 3, 2011, from http://tcpreplay.synfin.net/ 

Templin, F..Gleeson, T., & Thaler, D. (2008). Intra-site automatic tunnel addressing protocol 

(ISATAP). RFC 5214: Internet Engineering Task Force (IETF). 

THC-IPv6. (n.d.). Retrieved Feb 9, 2011, from http://freeworld.thc.org/thc-ipv6 

Tseng, B..Chen, C. Y., & Laih, C. S. (2006). Design and implementation of an IPv6-enabled 

intrusion detection system (6IDS). Paper presented at the International Computer 

Symposium, Taipei, Taiwan. 

http://dspace.lib.fcu.edu.tw/dspace/bitstream/2377/1860/1/ce07ics002004000116.pdf 

Tsirtsis, G., & Srisuresh, P. (2000). Network address translation - protocol translation (NAT 

PT). RFC 2766: Internet Engineering Task Force (IETF). 

Tsuchiya, K..Higuchi, H., & Atarashi, Y. (2000). Dual stack hosts using the "bump-in-the-stack" 

technique (BIS). RFC 2767: Internet Engineering Task Force (IETF). 

Tulloch, M. (2006). IPv6 Support in Microsoft Windows Retrieved Sept 6, 2010, from 

http://www.windowsnetworking.com/articles_tutorials/IPv6-Support-Microsoft 

Windows.html


148 

Tulloch, M..Northrup, T..Honeycutt, J., & Wilson, E. (2010). Windows 7 Resource Kit: 

Microsoft Press. 

Tylbart. (2007). Teredo and the PNRP global cloud, Microsoft Peer-to-Peer Networking. 

Retrieved Feb 23, 2011, from http://blogs.msdn.com/b/p2p/archive/2007/03/22/teredoand-the-pnrp-global-cloud.aspx 

Ubuntu. (n.d.). Retrieved Feb 9, 2011, from http://www.ubuntu.com/ 

Using Teredo in Windows XP. (2010). MSDN. Retrieved Feb 23, 2011, from 

http://msdn.microsoft.com/en-us/library/bb968771(v=VS.85).aspx 

Virtualbox. (n.d.). Retrieved Feb 9, 2011, from http://www.virtualbox.org/ 

Visoottiviseth, V., & Bureenok, N. (2008). Performance comparison of ISATAP implementations 

on FreeBSD, RedHat, and Windows 2003. Paper presented at the 22nd International 

Conference on Advanced Information Networking and Applications - Workshops. 

http://doi.ieeecomputersociety.org/10.1109/WAINA.2008.79 

Vives, A., & Palet, J. (2005). IPv6 distributed security: problem statement. Paper presented at 

the The 2005 Symposium on Applications and the Internet Workshops (SAINT-W’05). 

Retrieved from http://doi.ieeecomputersociety.org/10.1109/SAINTW.2005.72 

Wagener, G..Dulaunoy, A., & Engel, T. (2008). Towards an estimation of the accuracy of TCP 

reassembly in network forensics. Paper presented at the Future Generation 

Communication and Networking. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/FGCN.2008.118 

doi:10.1109/FGCN.2008.118 

Wang, S. (2007). Measures of retaining digital evidence to prosecute computer-based cybercrimes. 

Computer Standards & Interfaces, 29(2), 216-223. doi: 10.1016/j.csi.2006.03.008


149 

Wang, W., & Daniels, T. E. (2007). Diffusion and graph spectral methods for network forensic 

analysis. Paper presented at the Proceedings of the 2006 Workshop on New Security 

Paradigms, Germany. 

Warfield, M. H. (2003). Security implications of IPv6. Internet Security Systems. Retrieved 

from http://www.blackhat.com/presentations/bh-federal-03/bh-federal-03-warfield/bhfed-03-warfield.pdf 

Wei, X..Jiang-wei, Z., & Guo-dong, Z. (2009). Application research on IPv4/IPv6 dual stack 

technology. Paper presented at the International Conference on Signal Processing 

Systems. Retrieved from http://doi.ieeecomputersociety.org/10.1109/ICSPS.2009.200 

Weissmann, P. (n.d.). FreeBSD IPv6. Retrieved Mar 4, 2011, from 

http://ipv6int.net/systems/freebsd-ipv6.html 

WenQi, W., & Weiguang, L. (2009). The research on forensic model based network. Paper 

presented at the Second International Workshop on Computer Science and Engineering. 

Retrieved from http://doi.ieeecomputersociety.org/10.1109/WCSE.2009.635 

doi:10.1109/WCSE.2009.345 

Windows Sysinternals: PsInfo. (n.d.). Retrieved Jan 9, 2011, from 

http://technet.microsoft.com/en-us/sysinternals/bb897550 

Winpcap. (n.d.). Retrieved Feb 9, 2011, from http://winpcap.org 

Wireshark. (n.d.). Retrieved Feb 9, 2011, from http://wireshark.org 

Wu, L..Hai-xin, D..Tao, L..Xing, L., & Jian-ping, W. (2009). H6Proxy: ICMPv6 weakness 

analysis and implementation of IPv6 attacking test proxy. Paper presented at the 

Symposia and Workshops on Ubiquitous, Autonomic and Trusted Computing. Retrieved


150 

from http://doi.ieeecomputersociety.org/10.1109/UIC-ATC.2009.78 doi:10.1109/UIC 

ATC.2009.78 

Xie, L..Bi, J., & Wu, J. (2007). A multihoming based IPv4/IPv6 transition approach. Paper 

presented at the Proceedings of the 6th international IFIP-TC6 conference on Ad Hoc and 

sensor networks, wireless networks, next generation internet, Atlanta, GA, USA. 

Yan-ge, C..Shui-mu, T., & Jun-ying, G. (2009). IPv4/IPv6 intercommunication technology 

research. Paper presented at the International Conference on Environmental Science and 

Information Application Technology. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ESIAT.2009.297 

Yang, J. (n.d.). Fast worm propagation in IPv6 networks. 

Yang, X., & Ma, T. (2007). A link signature based DDoS attacker tracing algorithm under IPv6. 

Paper presented at the Future Generation Communication and Networking. Retrieved 

from http://doi.ieeecomputersociety.org/10.1109/FGCN.2007.15 

Yang, X..Ma, T., & Shi, Y. (2007). Typical DoS/DDoS threats under IPv6. Paper presented at 

the Proceedings of the International Multi-Conference on Computing in the Global 

Information Technology (ICCGI'07). Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ICCGI.2007.61 

Yangui, X..Xiangchun, L..Jiachun, Z., & Huanyan, Q. (2009). Worm detection in an IPv6 

internet. Paper presented at the International Conference on Computational Intelligence 

and Security. Retrieved from doi:10.1109/CIS.2009.216 

Yao, G. x..Guan, Q. l..Lin, L. c..Huang, S. Q..Zhu, G. c..Zhang, H., et al. (2008). Research and 

Implementation of Next Generation Network Intrusion Detection System Based on 

Protocol Analysis. Paper presented at the ISECS International Colloquium on


151 

Computing, Communication, Control, and Management. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/CCCM.2008.30 doi:10.1109/CCCM.2008.30 

Zagar, D..Grgic, K., & Rimac-Drlje, S. (2007). Security aspects in IPv6 networks 

implementation and testing. Computers & Electrical Engineering, 33, 425-437. doi: 

10.1016/j.compeleceng.2007.05.008 

Zander, S..Armitage, G., & Branch, P. (2007). A survey of covert channels and coutermeasures 

in computer network protocols. IEEE Communications Surveys & Tutorials, 9(3). 

Zheng, Q..Liu, T..Guan, X..Qu, Y., & Wang, N. (2007). A new worm exploiting IPv4-IPv6 dualstack 

networks. Paper presented at the Proceedings of the 2007 ACM workshop on 

Recurring malcode, Alexandria, Virginia, USA. 

Zhou, L., & Renesse, R. v. (2004). P6P: A peer-to-peer approach to Internet infrastructure. 

Paper presented at the International workshop on Peer-To-Peer Systems.


152 

Appendix A - Digital Forensic Frameworks 

Framework 

Carr, et al.(2002) 

Cohen (2009) 

Ciardhuáin (2004) 

Process Steps 

1. Identification 

2. Preparation 

3. Approach strategy 

4. Preservation 

5. Examination 

6. Analysis 

7. Presentation 

8. Return evidence 

1. Identify legal context 

2. Hypothesize claim 

3. Hypothesize events 

4. Capture traces 

5. Confirm internal consistency of traces 

6. Demonstrate consistency of traces 

7. Initiate forensic procedures 

8. Verify available resources 

9. Determine schedule 

1. Awareness 

2. Authorization 

3. Planning 

4. Notification 

5. Search for evidence 

6. Collection of evidence 

7. Transport of evidence 

8. Storage of evidence 

9. Examination of evidence 

10. Hypothesis of what occurred 

11. Presentation of hypothesis to court


153 

Framework 

Shin (2008) 

Incident Response Strategy (Mandia 

& Prosise, 2001) 

Process Steps 

12. Proof/Defense of hypothesis 

13. Dissemination of information 

1. Preparation 

2. Classify crime 

3. Prioritizing 

4. Investigate 

5. Protect evidence 

6. Preserve volatile evidence 

7. Disk analysis 

8. Network forensics 

9. Consult external experts 

10. Seize other storage media 

11. Criminal profiling 

12. Track suspects 

13. Investigate the crime scene 

14. Summon suspects 

15. Conduct additional investigations 

16. Write criminal profile 

17. Writing report 

18. Submit case to court 

19. Pre incident preparation 

20. Detection 

21. Initial Response 

22. Response strategy formulation 

23. Duplication 

24. Investigation 

25. Security measure implementation 

26. Network monitoring 

27. Recovery 

28. Reporting and follow-up


154 

Framework 

Process Steps 

Department of Justice ("Electronic 1. Collection 

crime scene investigation: A guide 2. Examination 

for first responders," 2001) 

3. Analysis 

4. Reporting 

Digital Forensics Research 

1. Identification 

Workshop (DFRWS) (G Palmer, 2. Preservation 

2001, Aug) 3. Collection 

4. Examination 

5. Analysis 


7. Decision 

Carrier (Carrier & Spafford, 2003) 1. Preservation 

2. Survey 

3. Documentation 

4. Search 

5. Reconstruction 


Lee’s Scientific Model (H. C. Lee, et 1. Recognition of evidence 

al., 2001) 

2. Identification of evidence 

3. Individualize sources of evidence 

4. Reconstruction to depict events 

Casey (E Casey, 2000) 

1. Recognition 

2. Preservation, collection, documentation 

3. Classification, comparison, individualization 

4. Reconstruction


Appendix B - Base Operating System Configurations 

Table B1. Commands Used to Extract the Operating System Data 

Operating System 

Windows 

Ubuntu 

CentOS 

FreeBSD 

Solaris 

Information 

General 

Patches 

General 

Kernel 

Packages 

General 

Kernel 

Packages 

General 

Kernel 

Packages 

General 

Kernel 

Packages 

Command 

>Psinfo -s ("Windows Sysinternals: PsInfo", n.d.) 

>wmic 

> /output:z:\.txt QFE get 

>uname -a 

>lsmod 

>dpkg -get-selections 

>uname -a 

>lsmod 

>yum list installed 

>uname -a 

>ls /boot/kernel | grep -v kernel 

>pkg_info 

>uname -a 

>modinfo 

>pkginfo 

Table B2. Commands Used to Setup the IPv6 Tunnel Client 

Operating Command 

System 

Windows 1. Download the Windows Client 32/64 bit installer. ("gogoCLIENT", n.d.) 

2. Run Installer 

Ubuntu >apt-get install gogoc (Nute, 2010) 

Backtrack 1. Download the Linux/Unix/Mac Client Source. ("gogoCLIENT", n.d.) 

Linux 2. >tar xvf .gz 

3. >cd 

4. >make


156 


System 

5. >make installdir=/opt/freenet-ipv6 install 

6. >apt-get install radvd 

7. >update-rc.d -f radvd remove 

8. >cp /usr/share/doc/radvd/ecamples/radvd.conf.example /etc/radvd.conf 

9. Uncomment the line in /etc/sysctl.conf to enable packet forwarding 

10. >cd /opt/freenet-ipv6/bin/ 

11. >./gogoc 

("Backtrack IPv6 Configuration", n.d.) 

CentOS 1. >yum install gcc-c++ 

2. >yum install openssl-devel.x86_64 

3. Download and extract the gogoc Source ("gogoCLIENT", n.d.) 

4. >make 

5. > make installdir=/opt/freenet-ipv6 install 

FreeBSD 1. >cd /usr/ports/net/gateway6 

2. >make install clean 

3. Add gateway6_enable = "YES" to /etc/rc.conf 

4. > /Usr/local/etc/rc.d/gateway6 start 

Solaris Not Tested 

Table B3. Commands Used to Setup Teredo/Miredo 


System 

Windows 2008 

1. Open gpedit.msc (Goup Policy editor) 

2. Navigate to Comp Config->Admin Templa->Network->TCPIP->IPv6 Trn 

3. Change Teredo Default Qualified State to “Enabled” 

4. Restart Computer 

5. Verify with command “netsh interface teredo show state” (qualified=on)


157 

Operating 

System 

Ubuntu 

Backtrack 

Linux 

CentOS 

FreeBSD 

Solaris 

Command 

(Ayres, 2010) 

Win 7 

1. Repeat steps for Windows 2008 

2. >netsh interface teredo set state enterpriseclient a 

Vista 

Enabled by default; however, Windows firewall must be enabled. 

(Tylbart, 2007) 

XP/2003 

1. > netsh interface ipv6 install 

2. >netsh interface ipv6 set teredo client 

("Using Teredo in Windows XP", 2010) 

>apt-get install miredo 

Not needed 

1. Download and extract the Miredo Source ("Miredo", n.d.) 

2. >./configure --without-Judy 

3. > make 

4. > make install 

1. >cd /usr/ports/net/miredo 


3. >/usr/local/sbin/miredo 

Not supported on Solaris. 

Note. a For some reason Teredo was offline because it detected that it was in a domain when it 

was not.This is likely due to the Enterprise version of the operating system and would not be 

necessary in other versions.


158 

Table B4. Commands Used to Setup ISATAP 

Operating 

System 

Windows 

Ubuntu 

Command 

2008/7 Client 

>netsh interface isatap set router 

("Netsh Commands for Interface (IPv4 and IPv6)", 2008) 

-or 

1. Open gpedit.msc (Goup Policy editor) 

2. Navigate to Comp Config->Admin Templa->Network->TCPIP->IPv6 Trn 

3. Change Teredo Default State to “Enabled” 

(Ayres, 2010) 

Vista Client 

>netsh interface isatap set router 

XP/2003 

> netsh interface ipv6 isatap set router 

Router 

1. >ip tunnel add is0 mode isatap local ttl 64 

2. >ip link set is0 up 

3. >ip addr add ::5efe: /64 dev is0 

4. >apt-get install radvd 

5. Uncomment line net.ipv6.conf.all.forwarding=1 in /etc/sysctl.conf 

6. Add the following lines to /etc/radvd.conf 

interface is0 

{ 

AdvSendAdvert on; 

UnicastOnly on; 

AdvHomeAgentFlag off; 

prefix ::/64 

{


159 

Operating 

System 

Backtrack 

Linux 

CentOS 

FreeBSD 

Solaris 

Command 

AdvOnLink on; 

AdvAutonomous on; 

AdvRouterAddr off; 

}; 

}; 

7. >/etc/init.d/radvd start 

(Lutchann, 2002) 

Client 

8. >apt-get install isatapd 

9. Uncomment and add isatap router to key ISATAP_ROUTERS="" in 

/etc/default/isatapd 

(fdz, 2010) 

1. >apt-get install isatapd 

2. Uncomment and add isatap router to key ISATAP_ROUTERS="" in 

/etc/default/isatapd 

Not Tested 

Unable to find port/source for isatap 

Not Tested


160 

Table B5. Commands Used to Setup Privacy Extensions 


System 

Windows 2008 

1. >netsh interface ipv6 set global randomizeidentifiers=enabled 

(default) 

2. >netsh interface ipv6 set privacy state=enabled 

Vista/7 

1. >netsh interface ipv6 set global randomizeidentifiers=enabled 

(default) 

2. >netsh interface ipv6 set privacy state=enabled 

(default) 

(Hogg, 2009) 

XP 

1. >netsh interface ipv6 install 

2. >netsh interface ipv6 set privacy state=enable 

(default) 

2003 

1. >netsh interface ipv6 install 

2. > netsh interface ipv6 set privacy state=enable 

CentOS/Ubuntu Add lines “net.ipv6.conf.eth0.use_tempaddr = 2”, 

“net.ipv6.conf.all.use_tempaddr = 2”, and “net.ipv6.conf.default.use_tempaddr 

= 2” to /etc/sysctl.conf 

("Enabling IPv6 Privacy Extensions on Ubuntu Linux", 2011) 

FreeBSD Add lines “net.inet6.ip6.use_tempaddr=1”, and 

“net.inet6.ip6.prefer_tempaddr=1” to /etc/sysctl.conf 

(Weissmann, n.d.) 

Solaris Add line “ifdefault TmpAddrsEnabled true” to /etc/inet/ndpd.conf 

("System administration guide: IP services", 2009)


161 

Table B6. Commands Used to Setup Netcat 


System 

Windows 2008 

1. Install “Microsoft Visual C++ 2008 Redistributable Package (x86)” 

2. Extract ncat.exe, ssleay32.dll, and libeay32.dll from Windows nmap distr. 

3. Copy files to folder on target 

2003/7/Vista/XP 

1. Extract ncat.exe, ssleay32.dll, and libeay32.dll from Windows nmap distr. 

2. Copy files to folder on target 

Ubuntu >apt-get install nmap 

CentOS > rpm -vhU http://nmap.org/dist/ncat-5.51-1.x86_64.rpm 

FreeBSD 1. >cd /usr/ports/security/nmap 


Solaris Install netcat from source code 

Table B7. Configured IPv6 Addresses 

OS Interface MAC Protocol Addresses 

28K EthLan 08-00-27-19 6to4 10.1.1.11 

74-27 2002:a6cb:5cb6:35:bcb6:88ca:6a61:e2d8 

2002:20b2:ebe9:33:bcb6:88ca:6a61:e2d8 

2002:a6cb:e5ea:33:bcb6:88ca:6a61:e2d8 

2002:a6cb:e5ea:33:cc64:ca1d:dbc8:1bbd 

fe80::bcb6:88ca:6a61:e2d8 

Teredo 00-00-00-00 Teredo 2001:0:4137:9e76:280a:c40:5934:a349 

00-00-00-E0 

fe80::280a:c40:5934:a349 

2001:0:4137:9e76:c3b:c11:5934:a349 

fe80::c3b:c11:5934:a349 

2001:0:4137:9e76:301d:b21:5934:a349 

2001:0:4137:9e76:38b8:bdf:5934:a349


162 


2001:0:4137:9e76:14a4:be6:5934:a349 

2001:0:4137:9e76:3869:be9:5934:a349 

2001:0:4137:9e76:1898:bf2:5934:a349 

fe80::1898:bf2:5934:a349 

2001:0:4137:9e76:c74:c02:5934:a349 

fe80::c74:c02:5934:a349 

2001:0:4137:9e76:c74:c02:5934:a349 

Gogo6 02-50-F2-00- T-Broker 2001:5c0:1400:a::11b 

00-01 fe80::edc2:969:1155:f9a6 

2001:5c0:1000:b::8f5f 

2001:5c0:1400:a::11b 

2001:5c0:1400:a::e5 

ISATAP 00-00-00-00- ISATAP 3ffe:ffff:1234:5678:0:5efe:10.1.1.11 

00-00-00-E0 

fe80::5efe:10.1.1.11 

23K EthLan 08-00-27-2F- 6to4 10.0.3.15 

FD-98 

2002:a6d9:4c6d:34:a00:27ff:fe2f:fd98 

2002:20b2:ebe9:33:a00:27ff:fe2f:fd98 

2002:a6cb:e5ea:33:146b:74d2:bf15:e528 

fe80::a00:27ff:fe2f:fd98 

Teredo 00-00-1A-61- Teredo 2001:0:4137:9e76:0:1a61:5926:b392 

59-26-B3-92 

2001:0:4137:9e76:0:3fe8:5934:752c 

fe80::ffff:ffff:fffd 

Gogo6 02-50-F2-00- T-Broker 2001:5c0:1000:b::8dff 

00-01 fe80::50:f2ff:fe00:1 

2001:5c0:1000:b::8b29 

2001:5c0:1000:b::91fd 

ISATAP 0A-01-01-0C ISATAP 3ffe:ffff:1234:5678:0:5efe:10.1.1.12 

fe80::5efe:10.1.1.12 

7 EthLan 08-00-27-91- 6to4 10.1.1.13 

78-19 2002:a6d9:4c6d:34:b032:f37b:cb41:b3b7


163 

OS Interface MAC Protocol 

Teredo 00-00-00-00 Teredo 

00-00-00-E0 

Gogo6 02-50-F2-00 T-Broker 

00-01 

ISATAP 00-00-00-00 ISATAP 

00-00-00-E0 

Vista EthLan 08-00-27-15 6to4 

3E-5B 

Teredo 02-00-54-55 Teredo 

4E-01 

Gogo6 02-50-F2-00 T-Broker 

00-01 

ISATAP 00-00-00-00- ISATAP 

00-00-00-E0 

Addresses 

2002:20b2:ebe9:33:b032:f37b:cb41:b3b7 

2002:20b2:ebe9:33:cd40:166b:7c6b:4200 

2002:a6cb:e5ea:33:248b:e4d9:3e1f:5a65 

fe80::b032:f37b:cb41:b3b7 

2001:0:4137:9e76:42b:c4e:5926:b392 

fe80::42b:c4e:5926:b392 

2001:0:4137:9e76:cb7:c4e:5926:b392 

fe80::cb7:c4e:5926:b392 

2001:5c0:1000:b::8fef 

fe80::30b5:d30c:f85b:3f0c 

2001:5c0:1000:b::8fef 

fe80::30b5:d30c:f85b:3f0c 

2001:5c0:1400:a::1af 

fe80::30b5:d30c:f85b:3f0c 

3ffe:ffff:1234:5678:0:5efe:10.1.1.13 

fe80::5efe:10.1.1.13 

10.1.1.14 

2002:a6d9:4c6d:34:cd49:8083:a388:129c 

2002:20b2:ebe9:33:cd49:8083:a388:129c 

fe80::cd49:8083:a388:129c 

2002:20b2:ebe9:33:a91f:5f83:a917:ceb7 

2002:a6cb:e5ea:33:d0ae:a09b:e540:bdd9 

2001:0:4137:9e76:345b:c65:df4d:5a84 

fe80::345b:c65:df4d:5a84 

2001:5c0:1000:b::8a39 

fe80::b474:128f:befe:93c2 

2001:5c0:1000:b::8a84 

fe80::345b:c65:df4d:5a84 

3ffe:ffff:1234:5678:0:5efe:10.1.1.14 

fe80::5efe:10.1.1.14


164 


XP EthLan 08-00-27-33- 6to4 10.0.3.15 

39-F3 2002:a6cb:ae5c:34:a00:27ff:fe33:39f3 

2002:a6cb:ae5c:34:a061:8dca:a57f:29d 

2002:a6d9:4c6d:34:558b:584e:d30f:d53a 

2002:a6cb:e5ea:33:7dae:ba67:4c74:538d 

fe80::a00:27ff:fe33:39f3 

Teredo 80-00-31-BA- Teredo 2001:0:4137:9e76:8000:31ba:5926:b392 

59-26-B3-92 

fe80::ffff:ffff:fffd 

2001:0:4137:9e76:0:291b:5926:b392 

Gogo6 02-50-F2-00- T-Broker 2001:5c0:1000:b::933b 

00-01 fe80::50:f2ff:fe00:1 

2001:5c0:1000:b::7b63 

fe80::50:f2ff:fe00:1 

2001:5c0:1000:b::92c5 

2001:5c0:1000:b::92b1 

ISATAP 0A-01-01-0F ISATAP 3ffe:ffff:1234:5678:0:5efe:10.1.1.15 

fe80::5efe:10.1.1.15 

Ubuntu eth4 08:00:27:8a:e4 6to4 10.1.1.16 

:79 2002:20b2:fee8:34:a00:27ff:fe8a:e479 

2002:20b2:ebe9:33:a00:27ff:fe8a:e479 

2002:a6cb:e5ea:33:f811:761c:ac5c:739e 

fe80::a00:27ff:fe8a:e479 

iso 00-00 ISATAP 3ffe:ffff:1234:5678:0:5efe:0a01:0110 

fe80::5efe:a01:110 

teredo 00-00 Teredo 2001:0:53aa:64c:3c6f:80b:df4d:117 

fe80::ffff:ffff:ffff 

2001:0:53aa:64c:2428:c73:df4d:117 

2001:0:53aa:64c:3089:406:df4d:1416 

tun 00-00 TBroker 2001:5c0:1000:b::8e61 

2001:5c0:1000:b::8cc7


165 


CentOS eth0 08:00:27:D9:B 6to4 10.1.1.17 

C:FB 

fe80::a00:27ff:fed9:bcfb 

2002:20b2:fee8:34:a00:27ff:fed9:bcfb 

2002:20b2:ebe9:33:a00:27ff:fed9:bcfb 

2002:a6cb:e5ea:33:65a0:db78:80a6:2647 

Teredo 00-00-00-00 Teredo 2001:0:53aa:64c:c54:b67:df4d:117 

2001:0:53aa:64c:c90:338:df4d:1416 


tun 00-00-00-00 T-Broker 2001:5c0:1000:b::90bf 

2001:5c0:1000:b::889b 

FreeBSD em0 08:00:27:a8:9f: 6to4 10.1.1.18 

8e 

fe80::a00:27ff:fea8:9f8e 

fe80::a00:27ff:fed9:bcfb 

2002:20b2:fee8:34:a00:27ff:fea8:9f8e 

2002:20b2:ebe9:33:a00:27ff:fea8:9f8e 

2002:a6cb:e5ea:33:c505:6a57:6e19:9131 

tun0 00-00-00-00 T-Broker fe80::a00:27ff:fea8:9f8e 

2001:5c0:1000:b::8dd5 

2001:5c0:1000:b::8937 

2001:5c0:1000:b::87e5 

Teredo 00-00-00-00 Teredo 2001:0:53aa:64c:1c29:a6c:df4d:117 

2001:0:53aa:64c:1e35:a6c:df4d:117 


Solaris eg1000 6to4 10.1.1.19 

fe80::a00:27ff:fe9a:f546 

2002:20b2:fee8:34:a00:27ff:fe9a:f546 

2002:20b2:ebe9:33:a00:27ff:fe9a:f546 

2002:a6cb:e5ea:33:7092:c44f:d37e:b7d1


166 

Target Node 1: Windows Server 2008 R2 Datacenter Edition v6.1 (64-bit) 

System information for \\28K01X64-PC: 

Kernel version: Windows Server 2008 R2 Datacenter, Multiprocessor Free 

Product type: Server 

Product version: 6.1 

Service pack: 0 

Kernel build number: 7600 

IE version: 8.0000 

System root: C:\Windows 

Processors: 2 

Processor speed: 2.5 GHz 

Processor type: Intel(R) Core(TM) i5 CPU M 540 @ 

Physical memory: 0 MB 

Video driver: VirtualBox Graphics Adapter 

VirtualBox node configuration. 

Oracle VM VirtualBox Command Line Management Interface Version 4.0.2 

(C) 2005-2010 Oracle Corporation 

All rights reserved. 

Name: 1. 28K01x64 

Guest OS: Windows 2008 (64 bit) 

Memory size: 1024MB 

Page Fusion: off 

VRAM size: 64MB 

HPET: off 

Number of CPUs: 2 

Synthetic Cpu: off 

CPUID overrides: None 

Boot menu mode: message and menu 

Boot Device (1): DVD


167 

Boot Device (2): HardDisk 

ACPI: on 

IOAPIC: on 

PAE: off 

Time offset: 0 ms 

RTC: local time 

Hardw. virt.ext: on 

Hardw. virt.ext exclusive: off 

Nested Paging: on 

Large Pages: off 

VT-x VPID: on 

3D Acceleration: off 

2D Video Acceleration: off 

Teleporter Enabled: off 

Storage Controller Name (0): IDE Controller 

Storage Controller Type (0): PIIX4 

Storage Controller Instance Number (0): 0 

Storage Controller Max Port Count (0): 2 

Storage Controller Port Count (0): 2 

Storage Controller Name (1): SCSI Controller 

Storage Controller Type (1): LsiLogic 




NIC 1: MAC: 0800273FD422, Attachment: NAT, Cable connected: on, Trace: off 

(file: none), Type: 82540EM, Reported speed: 0 Mbps, Boot priority: 0 

NIC 1 Settings: MTU: 0, Socket( send: 64, receive: 64), TCP Window( send:64, receive: 

64) 

NIC 2: MAC: 080027A82758, Attachment: Host-only Interface 'VirtualBox Host- 

Only Ethernet Adapter', Cable connected: on, Trace: off (file: none), Type: 82540EM, 

Reported speed: 0 Mbps, Boot priority: 0


168 

Pointing Device: PS/2 Mouse 

Keyboard Device: PS/2 Keyboard 

UART 1: disabled 


Audio: enabled (Driver: DSOUND, Controller: AC97) 

Clipboard Mode: Bidirectional 

VRDP: disabled 

USB: enabled 

IPConfig. 

Windows IP Configuration 

Ethernet adapter Local Area Connection: 

Connection-specific DNS Suffix . : 

Link-local IPv6 Address . . . . . : fe80::bcb6:88ca:6a61:e2d8%11 

IPv4 Address. . . . . . . . . . . : 10.1.1.11 

Subnet Mask . . . . . . . . . . . : 255.255.255.0 

Default Gateway . . . . . . . . . : 10.1.1.1 

Tunnel adapter isatap.[6117A83C-3C3E-42A8-8672-0212768612B8]: 

Media State . . . . . . . . . . . : Media disconnected 


Tunnel adapter Local Area Connection* 12: 


Connection-specific DNS Suffix . :


169 

C:\Users\Administrator>ipconfig /all 


Host Name . . . . . . . . . . . . : 28K01x64-PC 

Primary Dns Suffix . . . . . . . : 

Node Type . . . . . . . . . . . . : Hybrid 

IP Routing Enabled. . . . . . . . : No 

WINS Proxy Enabled. . . . . . . . : No 



Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Desktop Adapter 

Physical Address. . . . . . . . . : 08-00-27-19-74-27 

DHCP Enabled. . . . . . . . . . . : No 

Autoconfiguration Enabled . . . . : Yes 

Link-local IPv6 Address . . . . . : fe80::bcb6:88ca:6a61:e2d8%11(Preferred) 

IPv4 Address. . . . . . . . . . . : 10.1.1.11(Preferred) 

Subnet Mask . . . . . . . . . . . : 255.255.255.0 

Default Gateway . . . . . . . . . : 10.1.1.1 

DHCPv6 IAID . . . . . . . . . . . : 235405351 

DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-7E-13-C2-08-00-27-3F-D4-22 

DNS Servers . . . . . . . . . . . : fec0:0:0:ffff::1%1 

fec0:0:0:ffff::2%1 

fec0:0:0:ffff::3%1 

NetBIOS over Tcpip. . . . . . . . : Enabled 

Tunnel adapter isatap.[6117A83C-3C3E-42A8-8672-0212768612B8]:


170 



Description . . . . . . . . . . . : Microsoft ISATAP Adapter 

Physical Address. . . . . . . . . : 00-00-00-00-00-00-00-E0 






Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface 




Target Node 2: Windows Server 2003 R2 Enterprise Edition v5.2 SP2 (64-bit) 

System information for \\23K01X64-PC: 

Kernel version: Microsoft Windows Server 2003, Multiprocessor Free 

Product type: Enterprise Edition 





System root: C:\WINDOWS 

Processors: 2 




Video driver: VirtualBox Graphics Adapter


171 





Name: 2. 23K01x64 

Guest OS: Windows 2003 (64 bit) 




HPET: off 





Boot Device (1): DVD 


ACPI: on 

IOAPIC: on 

PAE: off 







VT-x VPID: on 


2D Video Acceleration: on 

Teleporter Enabled: off


172 











NIC 1: MAC: 080027034D17, Attachment: NAT, Cable connected: on, Trace: off 



64) 

NIC 2: MAC: 0800277E313B, Attachment: Host-only Interface 'VirtualBox Host- 


Reported speed: 0 Mbps, Boot priority: 0 








USB: enabled 

Target Node 3: Microsoft Windows 7 Enterprise v6.1 (64-bit) 

System information for \\7X64-PC: 

Kernel version: Windows 7 Enterprise, Multiprocessor Free 

Product type: Professional


173 






Processors: 2 









Name: 3. Vista01x64 

Guest OS: Windows Vista (64 bit) 




HPET: off 







ACPI: on 

IOAPIC: on 

PAE: off


174 







VT-x VPID: on 









Storage Controller Name (1): SATA Controller 

Storage Controller Type (1): IntelAhci 




NIC 1: MAC: 080027E56409, Attachment: NAT, Cable connected: on, Trace: off 



64) 

NIC 2: MAC: 080027C60E69, Attachment: Host-only Interface 'VirtualBox Host- 






UART 2: disabled


175 




USB: enabled 

IPConfig. 

Microsoft Windows [Version 6.1.7600] 

Copyright (c) 2009 Microsoft Corporation. All rights reserved. 

C:\Users\sabreadmin>ipconfig /all 


Host Name . . . . . . . . . . . . : 3-7x64 





Ethernet adapter Local Area Connection 2: 


Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Desktop Adapter #2 

Physical Address. . . . . . . . . : 08-00-27-91-78-19 



IPv6 Address. . . . . . . . . . . : 2002:20b2:1b3c:36:b032:f37b:cb41:b3b7(Pre 

ferred) 

Site-local IPv6 Address . . . . . : fec0::36:b032:f37b:cb41:b3b7%1(Preferred) 

Temporary IPv6 Address. . . . . . : 2002:20b2:1b3c:36:8145:25d6:cea3:f4b4(Pre


176 

ferred) 

Link-local IPv6 Address . . . . . : fe80::b032:f37b:cb41:b3b7%14(Preferred) 


Subnet Mask . . . . . . . . . . . : 255.255.255.0 

Default Gateway . . . . . . . . . : fe80::a0a4:b5:662:bbe7%14 

10.1.1.1 

DHCPv6 IAID . . . . . . . . . . . : 285736999 

DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-EE-9A-20-08-00-27-1F-4F-A1 

DNS Servers . . . . . . . . . . . : 8.8.8.8 

8.8.4.4 


Tunnel adapter isatap.{5090D42E-2E3D-4F74-B5A3-8FFBFF0E1DF5}: 



Description . . . . . . . . . . . : Microsoft ISATAP Adapter 






Description . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface 




IPv6 Address. . . . . . . . . . . : 2001:0:4137:9e76:1c74:1242:f5fe:fef2(Pref 

erred)


177 

Link-local IPv6 Address . . . . . : fe80::1c74:1242:f5fe:fef2%13(Preferred) 

Default Gateway . . . . . . . . . : 

NetBIOS over Tcpip. . . . . . . . : Disabled 

Target Node 4: Microsoft Windows Vista Enterprise v6.0 SP2 (64-bit) 

System information for \\VIAST01X64-PC: 

Kernel version: Windows (TM) Vista Enterprise, Multiprocessor Free 

Product type: Professional 






Processors: 2 









Name: 4. Vista01x64 

Guest OS: Windows Vista (64 bit) 




HPET: off 

Number of CPUs: 2


178 






ACPI: on 

IOAPIC: on 

PAE: off 







VT-x VPID: on 















(file: none), Type: 82540EM, Reported speed: 0 Mbps, Boot priority: 0


179 


64) 

NIC 2: MAC: 080027C60E69, Attachment: Host-only Interface 'VirtualBox Host- 










USB: enabled 

IPConfig. 

Microsoft Windows [Version 6.0.6002] 

Copyright (c) 2006 Microsoft Corporation. All rights reserved. 

C:\Users\sabreadmin>ipconfig /all 


Host Name . . . . . . . . . . . . : viast01x64-PC 






Connection-specific DNS Suffix . :


180 

Description . . . . . . . . . . . : Intel(R) PRO/1000 MT Desktop Adapter 

Physical Address. . . . . . . . . : 08-00-27-15-3E-5B 



IPv6 Address. . . . . . . . . . . : 2002:20b2:1b3c:36:cd49:8083:a388:129c(Pre 

ferred) 

Site-local IPv6 Address . . . . . : fec0::36:cd49:8083:a388:129c%1(Preferred) 

Temporary IPv6 Address. . . . . . : 2002:20b2:1b3c:36:9cc5:58e9:f459:43c(Pref 

erred) 

Link-local IPv6 Address . . . . . : fe80::cd49:8083:a388:129c%10(Preferred) 


Subnet Mask . . . . . . . . . . . : 255.255.255.0 

Default Gateway . . . . . . . . . : fe80::a0a4:b5:662:bbe7%10 

10.1.1.1 

DHCPv6 IAID . . . . . . . . . . . : 252182567 

DHCPv6 Client DUID. . . . . . . . : 00-01-00-01-14-80-D6-C6-08-00-27-E5-64-09 

DNS Servers . . . . . . . . . . . : 8.8.8.8 

8.8.4.4 





Description . . . . . . . . . . . : isatap.{AE6E1630-7C91-43B0-860F-2C086B873 

61E} 



Autoconfiguration Enabled . . . . : Yes


181 



Description . . . . . . . . . . . : Microsoft Tun Miniport Adapter 

Physical Address. . . . . . . . . : 02-00-54-55-4E-01 



IPv6 Address. . . . . . . . . . . : 2001:0:4137:9e76:14f4:1f45:f5fe:fef1(Pref 

erred) 

Link-local IPv6 Address . . . . . : fe80::14f4:1f45:f5fe:fef1%17(Preferred) 

Default Gateway . . . . . . . . . : 

NetBIOS over Tcpip. . . . . . . . : Disabled 

Target Node 5: Microsoft Windows XP Professional v5.1 SP3 (32-bit) 

System information for \\XP01X86-PC: 

Kernel version: Microsoft Windows XP, Uniprocessor Free 

Product type: Professional 





System root: C:\WINDOWS 

Processors: 1 





VirtualBox node configuration.


182 




Name: 5. XP01x86 

Guest OS: Windows XP 




HPET: off 







ACPI: on 

IOAPIC: on 

PAE: off 







VT-x VPID: on 


2D Video Acceleration: on 



Storage Controller Type (0): PIIX4


183 




NIC 1: MAC: 080027D245AC, Attachment: NAT, Cable connected: on, Trace: off 

(file: none), Type: Am79C973, Reported speed: 0 Mbps, Boot priority: 0 


64) 

NIC 2: MAC: 0800278775E5, Attachment: Host-only Interface 'VirtualBox Host- 

Only Ethernet Adapter', Cable connected: on, Trace: off (file: none), Type: Am79C973, 









USB: enabled 

Target Node 6:. Linux Ubuntu Desktop v10.10 (64-bit Kernel v2.6.35) 

Linux Ubuntu Desktop v10.10 (64-bit Kernel v2.6.35 http://www.ubuntu.com 

Linux UB01x64-PC 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 02:41:37 UTC 2010 x86_64 

GNU/Linux 





Name: 

6. UB01x64


184 

Guest OS: Ubuntu (64 bit) 




HPET: off 







ACPI: on 

IOAPIC: on 

PAE: off 


RTC: UTC 





VT-x VPID: on 

3D Acceleration: on 









Storage Controller Type (1): LsiLogic


185 




NIC 1: MAC: 08002712F3B4, Attachment: NAT, Cable connected: on, Trace: off 



64) 

NIC 2: MAC: 0800275B3ABB, Attachment: Host-only Interface 'VirtualBox Host- 



NIC 3: MAC: 08002734649A, Attachment: Internal Network 'intnet', Cable 

connected: on, Trace: off (file: none), Type: 82540EM, Reported speed: 0 Mbps, Boot 

priority: 0 

Pointing Device: USB Tablet 







USB: enabled 

Ifconfig. 

kcrosby@UB01x64-PC:~$ ifconfig 

eth4 Link encap:Ethernet HWaddr 08:00:27:8a:e4:79 

inet addr:10.1.1.16 Bcast:10.1.1.255 Mask:255.255.255.0 

inet6 addr: fec0::36:a00:27ff:fe8a:e479/64 Scope:Site 

inet6 addr: 2002:20b2:1b3c:36:a00:27ff:fe8a:e479/64 Scope:Global 

inet6 addr: fe80::a00:27ff:fe8a:e479/64 Scope:Link 

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 

RX packets:3964 errors:0 dropped:0 overruns:0 frame:0


186 

TX packets:3503 errors:0 dropped:0 overruns:0 carrier:0 

collisions:0 txqueuelen:1000 

RX bytes:1117147 (1.1 MB) TX bytes:276219 (276.2 KB) 

lo Link encap:Local Loopback 

inet addr:127.0.0.1 Mask:255.0.0.0 

inet6 addr: ::1/128 Scope:Host 

UP LOOPBACK RUNNING MTU:16436 Metric:1 

RX packets:12 errors:0 dropped:0 overruns:0 frame:0 



RX bytes:720 (720.0 B) TX bytes:720 (720.0 B) 

Target Node 7: CentOS v5.5 (64-bit Red Hat Base Kernel v2.6.18) 

CentOS v5.5 (64-bit Red Hat Base) 

Kernel: Linux localhost.localdomain 2.6.18-194.32.1.el5 #1 SMP Wed Jan 5 17:52:25 EST 

2011 x86_64 x86_64 x86_64 GNU/Linux 

http://www.centos.org 





Name: 7. centOSx64 

Guest OS: Red Hat (64 bit) 




HPET: off 

Number of CPUs: 1


187 






Boot Device (3): Not Assigned 


ACPI: on 

IOAPIC: on 

PAE: on 


RTC: UTC 





VT-x VPID: on 













Storage Controller Port Count (1): 16


188 

NIC 1: MAC: 080027B5908E, Attachment: NAT, Cable connected: on, Trace: off 



64) 








USB: enabled 

Ifconfig. 

[root@localhost ~]# ifconfig 

eth0 Link encap:Ethernet HWaddr 08:00:27:D9:BC:FB 

inet addr:10.1.1.17 Bcast:10.1.1.255 Mask:255.255.255.0 

inet6 addr: fec0::36:a00:27ff:fed9:bcfb/64 Scope:Site 

inet6 addr: 2002:20b2:1b3c:36:a00:27ff:fed9:bcfb/64 Scope:Global 

inet6 addr: fe80::a00:27ff:fed9:bcfb/64 Scope:Link 

UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 

RX packets:81 errors:0 dropped:0 overruns:0 frame:0 



RX bytes:8402 (8.2 KiB) TX bytes:6856 (6.6 KiB) 

lo 

Link encap:Local Loopback 

inet addr:127.0.0.1 Mask:255.0.0.0 

inet6 addr: ::1/128 Scope:Host 

UP LOOPBACK RUNNING MTU:16436 Metric:1 

RX packets:8135 errors:0 dropped:0 overruns:0 frame:0


189 



RX bytes:3191000 (3.0 MiB) TX bytes:3191000 (3.0 MiB) 

Target Node 8: FreeBSD v8.1 (64-bit) 

FreeBSD freebsdx64 8.1-RELEASE FreeBSD 8.1-RELEASE #0: Mon Jul 19 02:36:49 UTC 

2010 root@mason.cse.buffalo.edu:/usr/obj/usr/src/sys/GENERIC amd64 





Name: 8. FreeBSDx64 

Guest OS: FreeBSD (64 bit) 




HPET: off 





Boot Device (1): Floppy 




ACPI: on 

IOAPIC: on 

PAE: off 

Time offset: 0 ms


190 






VT-x VPID: on 














IDE Controller (1, 0): Empty 


64) 

NIC 2: MAC: 080027ED4103, Attachment: Host-only Interface 'VirtualBox Host- 








Clipboard Mode: Bidirectional


191 

VRDP: 

USB: 

disabled 

enabled 

Target Node 9: Oracle Solaris 11 Express v5.11 (64-bit) 

SunOS sol01x64 5.11 snv_151a i86pc i386 i86pc 





Name: 9. sol01x64 

Guest OS: Solaris (64 bit) 




HPET: off 







ACPI: on 

IOAPIC: on 

PAE: off 





Nested Paging: on


192 


VT-x VPID: on 














NIC 1: MAC: 08002714A8CD, Attachment: NAT, Cable connected: on, Trace: off 



64) 

NIC 2: MAC: 0800276921C9, Attachment: Host-only Interface 'VirtualBox Host- 










USB: enabled


193 

Research Node 1: Linux Backtrack v4 R2 (32-bit Ubuntu Base Kernel v 2.6.35.8) 

Linux Backtrack v4 R2 (32-bit Debian/Ubuntu Base) 

Kernel: Linux bt 2.6.35.8 #1 SMP Sun Nov 14 06:32:36 EST 2010 i686 GNU/Linux 

http://www.backtrack-linux.org/downloads/ 





Name: BTx86 

Guest OS: Ubuntu 




HPET: off 







ACPI: on 

IOAPIC: on 

PAE: on 


RTC: UTC 




Large Pages: off


194 

VT-x VPID: on 

















64) 

NIC 2: MAC: 0800274D586D, Attachment: Host-only Interface 'VirtualBox Host- 








USB: enabled 

Research node 2: Linux Ubuntu Desktop v10.10 (32-bit Kernel v2.6.35) 

Linux UBx32 2.6.35-24-generic #42-Ubuntu SMP Thu Dec 2 01:41:57 UTC 2010 i686 

GNU/Linux


195 





Name: UBx32 

Guest OS: Ubuntu 




HPET: off 







ACPI: on 

IOAPIC: on 

PAE: on 


RTC: UTC 





VT-x VPID: on 



Teleporter Enabled: off


196 











NIC 1: MAC: 080027D6147A, Attachment: NAT, Cable connected: on, Trace: off 



64) 

NIC 2: MAC: 080027D08549, Attachment: Host-only Interface 'VirtualBox Host- 







Video mode: 800x600x32 


USB: enabled 

Configured memory balloon size: 0 MB 

Research node 3: Linux Ubuntu Desktop v10.10 (32-bit Kernel v2.6.32) 

Linux li247-95 2.6.32.16-linode28 #1 SMP Sun Jul 25 21:32:42 UTC 2010 i686 GNU/Linux 

Host settings. 

http://www.linode.com/


Plan Linode 512 

Ram: 512 

Storage: 16GB 

Transfer: 200GB 

Data Center: Newark, NJ


198 

Annotated Bibliography 

Afifi, H., & Toutain, L. (1999). Methods for IPv4-IPv6 transition. Paper presented at the IEEE 

Symposium on Computers and Communications. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ISCC.1999.780953 

This IEEE conference paper attempts to solve the transition problem with the IPV4 to 

IPv6 transition. It uses a qualitative methodology with descriptive techniques. It briefly 

describes dual stack, SIIT, NAT-PT, AIIH, and proposes a DNS/DNCP based static 

tunnel approach. The article is dated but provides come basic information on transition 

approaches. 

AlJa'afreh, R. e..Mellor, J..Kamala, M., & Kasasbeh, B. (2008). Bi-directional mapping system 

as a new IPv4/IPv6 translation mechanism. Paper presented at the Tenth International 

Conference on Computer Modeling and Simulation. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/UKSIM.2008.90 

This conference paper addresses the lack of a transparent and efficient transition 

mechanism between IPv4 and IPv6 networks. It is a mixed method study that includes 

quantitative analysis of performance and qualitative descriptions. The solution involves 

using a gateway that translates between IPv4 and IPv6 based on multiple host aware DNS 

servers. One DNS operates on the IPv6 network. One operates on the IPv4 network, and 

another hosts records from both and records a translation at the gateway when a request 

arrives for a host on a different network. The solution appears to be comprehensive and 

applicable for small networks; however, utilizing three different DNS servers seems 

excessive.


199 

An, G., & Kim, K. (2008). Real-time IP checking and packet marking for preventing ND-DoS 

attack employing fake source IP in IPv6 LAN. Paper presented at the Proceedings of the 

5th international conference on Autonomic and Trusted Computing, Oslo, Norway. 

This conference paper addresses the problem of spoofed source addresses in IPv6 DoS 

network attacks. It is a mixed method study with an experiment and performance data. 

The research proposes that packets be directed into a high or low priority queue 

depending on whether the source addresses is legitimate or not. The router overhead for 

this method seems to be high and it is likely this would produce unacceptable bottlenecks 

in network trafic. 

Anaya, E. A..Miyatake, M. N., & Meana, H. M. P. (2009). Network forensics with neurofuzzy 

techniques. Paper presented at the Midwest Symposium on Circuits and Systems. 

Retrieved from http://doi.ieeecomputersociety.org/10.1109/MWSCAS.2009.5235900 

This IEEE Conference paper addresses the problem of large data sources in network 

forensics. Prior research includes: NIST - digital forensics stages. The research proposes 

a new model for researches using a qualitative methodology. Further research is needed 

to test other types of attacks with the proposed model. There is no research here and no 

arguments that have been resolved. It is only another idea that may or may not work or 

provide benefits. 

Baryamureeba, V., & Tushabe, F. (2004). The enhanced digital investigation process model. 

Makerere University. 

Retrieved from 

This thesis addresses the poor conviction rates in digital investigations by proposing a 

new investigative process model. The paper uses a qualitative methodology to propose a 

model based on frameworks by the US department Justice, Carrier (2003) "Getting


200 

Physical with the Investigative Process", and Kruse (2002) "Computer Forensics: 

Incident Response Essentials" which are referenced in other similar research in this 

bibliography. The proposed model consists of five stages that parallel the model used 

successfully in physical investigations. The process is logical and there is an apparent 

benefit; however, the paper is not published in a peer reviewed source and it lacks a 

consideration of key literature like the DFRWS workshop. Despite these facts, the 

arguments and presentation of the research are well laid out and more convincing than 

many of the other peer reviewed sources. 

Beebe, N. L., & Clark, J. G. (2005). A hierarchical, objectives-based framework for the digital 

investigations process. Digital Investigation, 2(2), 147-167. doi: 

10.1016/j.diin.2005.04.002 

This journal article published by Elsevier Science addresses the need for a detailed digital 

forensics framework. The paper argues that previous frameworks are abstract and fail to 

support the level of detail needed to conduct actual investigations. The framework 

presented is based on abstract models presented in: Palmer (2001) "A Road Map for 

Digital Forensics Research", US Department of Justice, Reith et el. (2002) "An 

examination of digital forensic models", Carrier (2003) "Getting Physical with the 

Investigative Process", Mandia (2003) "Incident Response & Computer Forensics", 

Mohay (2003) "Computer and Intrusion Forensics", O Ciarduain (2004) "An Extended 

Model of Cybercrime Investigations", and Casey (2004) ''The investigative process". 

Many of these are detailed in this bibliography. The paper uses a qualitative and 

descriptive methodology through logical comparisons and two applications of the 

proposed framework in case study form. This model is the first attempt to address the


201 

level of complexity and diversity of digital investigations. The paper also proposes that 

there is a need to apply the framework to other platforms and add additional case study 

examples to verify applicability. The research is compelling and detailed in content and 

the case studies present an account that the model can be applied in practice. 

Bi, J..Leng, X., & Wu, J. (2007). Scalable IPv4/IPv6 transition: a peer-to-peer based approach. 

Paper presented at the Proceedings of the 2005/2006 International Conference on 

Databases, Information Systems, and Peer-to-Peer Computing, Trondheim, Norway. 

This Journal article addresses the problem of IPv6 relay bottlenecks when acting on local 

traffic. It is a qualitative study using description and a quantitative study using lab 

simulation to measure performance metrics. The proposal is an algorithm that allows 

local P2P traffic to bypass the IPv6 relay. This solution makes sense and would make 

more sense as a routing protocol as opposed to P2P. This is the summary version of the 

Leng journal article. 

Bishop, M..Marzullo, K., & Peisert, S. (2008). Computer forensics in forensis. SIGOPS 

Operating System Review, 42(3), 112-122. doi: 


This ACM publish journal article addresses the variability in application of computer 

forensics systems, models, and terminology. It identified shortcomings in the following 

models: Andrews' (2007) "Process Model for Forensic Analysis of Digital Devices and 

Storage Media" model linked computer forensic processes and the law but didn't define 

testing and measurement; Carrier (2003) "Getting Physical with the Digital Investigation 

Process" mapped physical investigation to digital world but doesn't address validity; 

Gross (1997) "Analyzing Computer Intrusions" addresses system events in forensics but


202 

didn't separate relevant info from the system; Buchholz (2004) "Providing process origin 

information to aid in computer forensic Investigations" tied forensic events back to its 

origin; Peisert (2005) "Principles-Driven Forensic Analysis" addressed problems and 

constraints in forensics tools. It presents a qualitative study to describe and explain the 

shortcomings of forensic research and theory using narrative and logical reasoning. It 

further identifies high-level solutions to elevate digital forensics to a science. 

Additionally, the paper mentioned the need for a more accurate method of using IDS data 

as the source of evidence. It was interesting that Carrier and Buchholz are referenced in 

other studies. The paper presented some research shortcomings in the field but didn't 

address an approach to solve the problems. 

Broadway, J..Turnbull, B., & Slay, J. (2008). Improving the Analysis of Lawfully Intercepted 

Network Packet Data Captured for Forensic Analysis. Paper presented at the The Third 



This IEEE conference paper address the problem of the usefulness of GNU and com 

packet sniffers for forensic uses. Prior research includes: Casey st tes "Network traffic as 

a source of evidence", Feldmann "BLT: Bi-Layer Tracking of HTTP and TCP/IP',". This 

is a qualitative studty. The research proposes a software model that is focused on 

forensics, information sharing, and low tech skills. Future research is needed to develop 

the software. This study is more focused on software than forensics and evidence. It is 

unknown if the tool was ever built.


203 

Broucek, V., & Turner, P. (2004). Computer incident investigations: e-forensic insights on 

evidence acquisition. Paper presented at the European Institute for Computer Anti-Virus 

Research, Copenhagen. 

This EICAR conference best paper identifies the legal and technical problems often 

associated with digital evidence collection and its admissibility in court. The paper 

utilizes a description methodology through the discussion of a case study with 

conclusions based on these findings. The authors rely heavily on their own prior research 

to make their arguments and an extensive list of case law. The problems with evidence 

collection identified in case provide an opportunity for future researchers to investigate 

solutions in their own work. In a slight tangent to the case study, the paper described the 

CTOSE project and identified it as an area that could be further developed by 

researchers. The problems identified are well grounded to the examples provided in the 

case. The CTOSE description should have been a separate paper; although, this was an 

interesting read because there are few sources that define this model in such detail. 

Caicedo, C. E..Joshi, J. B. D., & Tuladhar, S. R. (2009). IPv6 security challenges. Perspectives, 

42, 36-42. Retrieved from http://doi.ieeecomputersociety.org/10.1109/MC.2009.54 

This IEEE magazine article provides an overview of the security issues for IPv6 and 

proposes a possible solution. The qualitative method is employed using description. IPv6 

features and security issues are described including reconnaissance, host initialization, 

routing header, and multicast attacks. The study proposes a defense in depth strategy be 

employed to counteract these security issues including employing IPSec. The article 

presents a good argument; however, IPSec may not prove to be a feasible solution to the 

problems identified.


204 

Candolin, C., & Nikander, P. (2001). IPv6 source addresses considered harmful. Paper presented 

at the Sixth Nordic Workshop on Secure IT. 

This IEEE conference paper addresses the threat of source addresses being a part of 

packet transmissions. The research proposes that including source addresses in packet 

flows creates privacy issues and is not necessary. The extra processing required and 

deviation from standards doesn't make this a very applicable argument. 

Carpenter, B., & Jung, C. (1999). Transmission of IPv6 over IPv4 domains without explicit 

tunnels. RFC 2529: Internet Engineering Task Force (IETF). 

This RFC 2529 IETF document briefly describes IPv4 to IPv6 protocol translation in 

6to4 networks. It is a very simple process that involves inserting the IPv6 packet inside 

the IPv4 header. 

Carpenter, B., & Moore, K. (2001). Connection of IPv6 domains via IPv4 clouds. RFC 3056: 


This is a RFC 3056 document from the IETF that describes the 6to4 transition 

mechanism. This protocol is based heavily on routing and involves a relay that 

encapsulates IPv6 packets into IPv4 payloads to send over the traditional network. Its 

target is to allow isolated IPv6 sites to communicate with other IPv6 sites with minimal 

configuration. 

Carr, C..Gunsch, G., & Reith, M. (2002). An examination of digital forensic models. 


Like the Shin (2008) paper, this journal article proposes a new forensic procedural model 

to address the lack of adequate forensic procedures. The research is based on the U.S. 

Department of Justice forensic model and the first DFRWS workshop as in other


205 

research. The paper applies a qualitative methodology to address specific shortcomings 

and propose a new nine step model that parallels and improves the DFRWS framework. 

The general approach is logical and understandable in practice; however, it is unlikely to 

have practical applications. The approach of synthesizing existing models does not seem 

to be needed. It might be more beneficial to create a framework that is scalable and can 

be broken down to the level of detail required in digital investigations. 

Carrier, B., & Spafford, E. H. (2003). Getting physical with the digital investigation process. 


This journal article, which is heavily referenced as a basis for other research in this 

bibliography, addresses the lack of an adequate process model that links the digital world 

with the physical investigation process. The paper applies qualitative reasoning to 

develop the framework and a description methodology in the application of two case 

studies. The basis for the research presented originates from: the US Department of 

justice; the first DFRWS workshop, and Mandia (2001) "Incident Response: 

Investigating Computer Crime" which are also referenced in other research through this 

bibliography. The paper contributed significantly to the field because the proposed model 

has been expanded and used as a basis for research a number of times. The logic and 

arguments are well reasoned. This appears to be the first research that defines a model for 

digital investigations that parallels the physical investigation process so there is many 

areas of potential improvement. 

Casey, E. (2004). Network traffic as a source of evidence: tool strengths, weaknesses, and future 

needs. Digital Investigation, 1(1), 28-43. doi: 10.1016/j.diin.2003.12.002


206 

This journal article, published by Elsevier Science, addresses weaknesses in tools that 

capture packets on a network that are used as evidence. The research is based on tool 

analysis defined in Casey (2004) "The Investigative Process. Digital Evidence and 

Computer Crime". The paper analyzed a select group of open source and commercial 

tools used in network forensic investigations. It also related specific requirements in the 

investigative process to common tool processes and identified functionality problems in 

specific tools. The analysis presented is an excellent training tool for anyone in the digital 

forensics field and could be used by tool developers to improve their code. The author 

identifies tool verification and testing as an area for further research. I am especially 

interested the implications the research has on the tools that I current use. 

Chapter 31 advanced networking. (2010). FreeBSD Handbook. Retrieved Aug 6, 2010, from 

http://www.freebsd.org/doc/en/books/handbook/network-ipv6.html 

This administration guide for FreeBSD outlines the setup of IPv6 and tunnel setup. The 

guide outlines the setup an IPv6 interface and generic tunnels that could be used with 

SixXS, 6to4, or Freenet6. 

Ciardhuáin, S. Ó. (2004). An extended model of cybercrime investigations. International Journal 

of Digital Evidence, 3(1). 

Like Carr and Shin below, this journal article addresses the lack of a comprehensive 

forensic procedure model to be used in digital forensic investigations. The paper 

identifies the shortcomings of the models proposed by: Lee et al. (2001) "Henry Lee’s 

Crime Scene Handbook", Casey (2000) "Digital Evidence and Computer Crime", Reith, 

Carr and Gunsch (2002) "An Examination of Digital Forensic Models.", and the first 

DFRWS workshop which are all referenced in other works described in this bibliography.


207 

The paper uses a qualitative methodology with quantitative elements in the form of a 

survey to evaluate the model. The proposed model extends the DFRWS model and 

appears to be comprehensive as a high level framework to be used by investigators. The 

author also identifies the need for a framework that can be applied to organizations. 

While the logic of the argument is convincing, the survey was not conducted 

scientifically and the process flowcharts are meaningless. Additionally, this is another 

attempt to distill other research into a new idea although there is little new information 

presented. 

Cohen, F. (2009). Two models of digital forensic examination. Paper presented at the Fourth 

IEEE International Workshop on Systematic Approaches to Digital Forensic Engineering. 


doi:10.1109/SADFE.2009.8 

This IEEE conference paper attempts the extend the research of the digital forensic model 

presented by Chow (2009) "A Cost-Effective Forensic Investigation Model" in an effort 

to help create a discipline more rooted in scientific process. The paper applies a 

descriptive methodology that presents a case based on a bit torrent investigation and its 

links and implications to the forensics models presented. The proposed model further 

extends the applicability to the forensic process and introduces a change management 

process. The paper concluded that the current models are not sufficient to cover the 

diverse range of evidence and that error rates for various investigative techniques are 

non-existent. The paper failed to provide a significant addition to the field despite the 

conclusions and I question whether forensic investigations should be tied to ROI. It 

seemed better oriented towards high level management and less toward practice.


208 

Cohen, M. I. (2008). PyFlag - An advanced network forensic framework. Digital Investigation, 

5(Supplement 1), S112-S120. doi: 10.1016/j.diin.2008.05.016 

The journal article in Elsevier addresses the lack of integrated forensics packages that 

were on the market at the time. The article describes previous tools used in forensics like 

Wireshark, Verint’s data interception tools, and Eeye’s Iris. The conclusions are based on 

Kloet et al. 2007 "A library for support of the expert witness compression format". The 

research contributed a definition of a tool that integrates IO and eye witness evidence 

formats. The author's motives are unknown and may be profit based. There are no 

research based sources used in the journal and the research was for the Australian 

government which may have different requirements than the US. 

Cohen, M. I. (2008). Source attribution for network address translated forensic captures. Digital 

Investigation, 5(3-4), 138-145. doi: 10.1016/j.diin.2008.12.002 

This Journal in Elsevier addresses a way to determine source of traffic in a NAT 

environment. Prior research includes: (Carrier and Shields, 2004) "The session token 

protocol for forensics", (Casey, 2004) "Network traffic as a source of evidence", (Nikkel, 

2006) "Improving evidence acquisition". This is a qualitative study using simulation. The 

research proposes algorithms to identifying NAT source based on algorithms. Further 

research includes improving the accuracy of this work and expand to other types of 

NATs. The sample size was too small (two computers) and it may not work with 

thousands of nodes under single NAT using similar Oss. It also requires knowledge of 

internal network to determine the source which will probably not work in most 

environments.


209 

Convery, S., & Miller, D. (2004). IPv6 and IPv4 threat comparison and best-practice evaluation 

(v1.0): Cisco Systems. Retrieved from 

http://www.cisco.com/web/about/security/security_services/ciag/documents/v6-v4 

threats.pdf 

This Cisco whitepaper addresses the new threat model created by the IPv6 architecture. It 

is a qualitative study using description and an experiment that is detailed in the appendix. 

The study presents a comprehensive list of network vulnerabilities and describes the 

threats to IPv4 networks, implications, differences in IPv6 networks, and best practices 

for mitigation. The best practices are comprehensive and provide an excellent guide for 

network engineers. 

Cooper, M., & Yen, D. C. (2005). IPv6: business applications and implementation concerns. 


This journal article is a literature review of IPv6 implementation that leads to some 

implications for future consideration. It is a qualitative study using logical conclusions. 

The study defines IPv6, explains the state of current deployment, business use, and 

lessons learned. The author predicts the growth of the protocol due to VoIP and end-toend 

requirements; however, business may choose not to implement IPv6 if their NAT 

infrastructure is sufficient. The study is weak on security implications of IPv6 which 

would also be a consideration for deployment. 

Davies, E..Krishnan, S., & Savola, P. (2007). IPv6 transition/coexistence security 

considerations. RFC 4942: Internet Engineering Task Force (IETF).


210 

This RFC 4942 document addresses security implications of the IPv6 protocol. It 

highlights a number of security concerns for the protocol, transition mechanisms, and 

proposes mitigation strategies for most if the identified vulnerabilities. 

Davies, J. (2008). Understanding IPv6 (2nd ed.): Microsoft Press. 

This Microsoft publication explains IPv6 and deployment in the Windows operating 

system. In includes a compilation of other research and RFC publications that explain 

IPv6 standards. It also details configuration of IPv6 in Windows 7, Vista and 2008. This 

publication provides a significant amount of information and is an excellent resource for 

IPv6. 

Dobrucki, M. (1999). The effects of the transition to IPv6 on Internet security. 

This unpublished study presents a dated but relevant analysis of IPv6. A qualitative 

method using description is used in the study. The research describes the changes in the 

IPv6 protocol, current threats in IPv4, implications of these threats in IPv6 and possible 

solutions. The author believes that IPv6 can solve some of the current threats if IPSec is 

employed; however, not all of them. The paper is comprehensive and provides good 

descriptions that are relevant in today's environment. 

Durand, A..Fasano, P..Guardini, I., & Lento, D. (2001). IPv6 tunnel broker. RFC 3053: Internet 


This RFC 3053 IETF document discusses the tunnel broker IPv6 transition mechanism. 

Tunnel brokers are third party service providers that provide IPv6 network access for 

users with IPv4 only connections. The RFC addresses elements and operation of the 

tunnel broker and what occurs to setup the connection.


211 

Elgoarany, K., & Eltoweissy, M. (2007). Security in mobile IPv6: A survey. Information 

Security Technical Report, 12, 32-43. doi: 10.1016/j.istr.2007.02.002 

This journal article provides a comprehensive discussion of mobile IPv6 threats. It 

outlines the fundamental operation of mobile IPv6 and then presents the threats and 

vulnerabilities that may be faced in deployment. The research is highly technical. 

Elmaghraby, A..Higgins, G..Keeling, D. W..Losavio, M., & Shutt, J. (2008). Implications of 

attorney experiences with digital forensics and electronic evidence in the United States. 

Paper presented at the Third International Workshop on Systematic Approaches to 

Digital Forensic Engineering. Retrieved from 


doi:10.1109/SADFE.2008.11 

This IEEE conference paper attempts to define current and future challenges in digital 

evidence admissibility in court and find a basis for the use of digital forensic experts in 

court. The paper presents a qualitative methodology using a survey distributed to lawyers 

at a conference. The paper was not based on previous research and contributed an 

enhanced understanding of digital evidence trends in civil and criminal trials. Although 

the results are detailed and convincing, the survey seems ad-hoc and was not included as 

part of the paper. Additionally, there is not mention of how many people were given the 

survey; therefore, the sample may not be of sufficient size to reach accurate conclusions 

nationwide. 

Emre, D., & Ali, B. (2010). IPV4/IPV6 security and threat comparisons. Procedia - Social and 

Behavioral Sciences, 2, 5285-5291. doi: 10.1016/j.sbspro.2010.03.862


212 

This journal article addresses security threats in IPv6. It is a qualitative study using 

description. The research briefly compares the IPv6 protocol to IPv4 and then describes 

IPv6 security vulnerabilities that are the same and different than in IPv4. The study 

presents very basic information that is better represented in other research. 

Ercferret18 (2010). IPv6 Retrieved Aud 6, 2010, from https://wiki.ubuntu.com/IPv6 

This online Ubuntu Linux manual contains simple instruction for setting up IPv6. The 

description includes a summary of the IPv6 protocol, how to configure IPv6 in Ubuntu, 

and how to setup third party tunneling mechanisms including SixXS and Freenet6. 

Faye, F. (2008). IPV6 configuration on REDHAT CENTOS FEDORA Retrieved Aug 6, 2010, 

from http://www.generationip.com/documentation/system-documentation/73-ipv6 

configuration-on-redhat-centos-fedora 

This CentOS online administration manual provides the configuration steps necessary to 

enable IPv6 in CentOS. It provides detailed instructions to verify and enable IPv6 on the 

interfaces. The guide also explains how to setup a generic tunnel interface. 

Friacas, C..Baptista, M..Domingues, M., & Ferreira, P. (2006). 6TO4 versus 

TUNNELBROKERS. Paper presented at the Proceedings of the International Multi- 

Conference on Computing in the Global Information Technology (ICCGI'06). Retrieved 

from http://doi.ieeecomputersociety.org/10.1109/ICCGI.2006.1 

This IEEE conference paper compares the 6to4 verses Tunnel broker IPv6 transition 

mechanism. It is a qualitative study that uses description and simulation to illustrate the 

points. The study illustrates the latency problem with tunnel brokers and recommends 

6to4. Because the study was wart of a 6to4 project and little analysis was done on Tunnel


213 

Brokers, it is unlikely that the results were unbiased; however, the author has some good 

points about latency. 

Gilligan, R., & Nordmark, E. (2000). Transition mechanisms for IPv6 hosts and routers. RFC 

2893: Internet Engineering Task Force (IETF). 

The RFC 2896 from the IETF outlines tunneling and dual stack transition methods. It 

provides specific details on the different modes used by dual stack hosts and explains the 

operation and technical requirement of configured and automatic tunneling mechanisms. 

GosevaPopstojanova, K..Miller, B..Pantev, R., & Dimitrijevikj, A. (2010). Empirical Analysis of 

Attackers Activity on Multi-tier Web Systems. Paper presented at the 24th IEEE 

International Conference on Advanced Information Networking and Applications. 

Retrieved from http://doi.ieeecomputersociety.org/10.1109/AINA.2010.138 

doi:10.1109/AINA.2010.138 

This IEEE conference identifies that most attacks/vulnerabilities exist on web based 

systems. This is a qualitative study using honeynet statistics for attacks. Prior research 

includes: Honeynet Project, Leurre.com, R. Bloomfield, I. Gashi, A. Povyakalo, and V. 

Stankovic, “Comparison of empirical data from two honeynets and a distributed honeypot 

network,”, R. Berthier, “ On the comparison of network attack datasets: An empirical 

analysis, V. Yegneswaran, P. Barford, and J. Ullrich, “Internet intrusions: Global 

characteristics and prevalence,”. The research added an understanding of attack patterns 

for better creation of attack simulations. Possible future research includes the deployment 

of honeypots using different techniques. The research is good information but doesn't 

relate very much to forensics.


214 

Graf, T. (2003). Messaging over IPv6 destination options. Swiss Unix User Group. Retrieved 

from http://grayworld.net/papers/messip6.txt 

This unpublished work defines a method to embed a covert channel in an ICMPv6 packet 

using an invalid options header. It is a valid technique, however, it could easily be 

detected by IDS so why not just send the data inside the payload of a packet? 

Grobler, C. P..Louwrens, C. P., & Solms, S. H. V. (2010). A framework to guide the 

implementation of proactive digital forensics in organisations. Paper presented at the 



This IEEE conference paper proposes a holistic view for organizations to approach digital 

forensics to more effectively meet the needs of compliance and criminal investigations. It 

presents a qualitative methodology that draws conclusions from the research needs 

identified in the first DFRWS workshop and the lack of comprehensive models that 

address these needs. It also draws parallels from the CobiT forensic framework, ITIL 

framework, and the information security discipline. The paper presents a top-down view 

of forensic components that are characterized as proactive, active, and reactive processes 

linked to people, ethics, legal and technology dimensions to improve applicability of 

forensics in the organization. The proposed framework is comprehensive and has similar 

linkages to the Zachman enterprise architecture framework. It is not well suited for 

criminal investigators. 

Hagino, J., & Yamamoto, K. (2001). An IPv6-to-IPv4 transport relay translator. RFC 3142: 

Internet Engineering Task Force (IETF).


215 

This RFC 3142 IETF document discusses the transport relay (TRT) mechanism. In TRT, 

a router and protocol translator acts in the middle of the two networks and initiates a 

connection with the two hosts and relays and translates packets between the protocols as 

necessary. 

Hsieh, I. P., & Kao, S. J. (2005). Managing the co-existing network of IPv6 and IPv4 under 

various transition mechanisms. Paper presented at the Proceedings of the Third 

International Conference on Information Technology and Applications (ICITA’05). 

Retrieved from http://doi.ieeecomputersociety.org/10.1109/ICITA.2005.175 

This conference paper addresses the problem of managing multiple transition 

mechanisms on the same network. The study uses a qualitative methodology using 

description. It summarizes dual stack, tunneling, and translation methods used in 

transitional IPv6 networks. The study then provides a possible gateway based solution to 

allow all mechanisms to co-exist on the same network. The proposal is unique compared 

to other research; however, there not enough information on the proposed solution. 

Huang, S. M..Wu, Q., & Lin, Y. B. (2005). Tunneling IPv6 through NAT with Teredo 

mechanism. Paper presented at the Proceedings of the 19th International Conference on 

Advanced Information Networking and Applications (AINA’05). Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/AINA.2005.333 

This conference paper addresses the problem of scalability in Teredo IPv6 transition 

mechanisms. It is a qualitative study that uses description and a small qualitative study on 

performance of the proposed solution. The study introduces Teredo and proposes a 

possible Linux version that could be used as a relay. The description of how Teredo


216 

works is good; however, the proposed Linux solution does not contain enough detail to 

make it useful. 

Huang, S. Q..Zhang, H. M., & Yao, G. X. (2009). Research of NIDS in IPV6 based on protocol 

analysis and pattern matching. Paper presented at the Second International Workshop on 

Knowledge Discovery and Data Mining. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/WKDD.2009.24 

This IEEE conference paper addresses new intrusion detection techniques needed for 

detecting IPv6 based attacks. A qualitative approach using descriptions is used to present 

the results of the study. The paper does not outline any prior work in the IDS field related 

to IPv6; however it references research by; Cho, Identifying IPv6 network problems in 

the dualstack World; Tool, high alarm count issues in IDS rainstorm, and Zheng, A new 

worm exploiting IPv4-IPv6 dual-stack networks. The results of the research present a 

method to create a new IPv6 IDS and the resulting experiment indicated performance 

improvements over other solutions. The research provides sparse details and there 

appears to be a fully functioning program that was mentioned in the pne paragraph testing 

explanation. If the program operates as specified, it could be a great contribution; 

however, the paper does not present enough information to confirm this assumption. 

Huitema, C. (2006). Teredo: tunneling IPv6 over UDP through network address translations 

(NATs). RFC 4380: Internet Engineering Task Force (IETF). 

This RFC 4380 IETF document describes the operations of the Teredo IPv6 transition 

mechanism to tunnel through NAT using UDP. The method uses a teredo server to assign 

and manage tunnels and relays to transport packets. This source provides a significant 

amount of details about Teredo


217 

Jamhour, E., & Storoz, S. (2002). Global mobile IPv6 addressing using transition mechanisms. 

Paper presented at the Proceedings of the 27th Annual IEEE Conference on Local 

Computer Networks (LCN02). Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/LCN.2002.1181816 

This IEEE conference proceeding addresses the shortage or IPv4 addresses. It is a 

qualitative study using descriptive techniques. The research summarizes the existing dual 

stack, transparent gateway, superior layer, and tunnel based IPv6 transition mechanisms. 

It them proposes a possible solution that is similar to the 6to4 technique but calls for no 

software or hardware modifications by using a gateway. Overall, this source provided the 

best and most logical discussion of transition mechanisms compared to Afifi, Mackay, 

Tantayakul, and Yan-ge and the proposed solution seems very comprehensive. 

Kammas, P..Komninos, T., & Stamatiou, Y. C. (2009). Modeling the co-evololution DNS worms 

and anti-worms in IPv6 networks. Paper presented at the Fifth International Conference 

on Information Assurance and Security. Retrieved from doi:10.1109/IAS.2009.334 

This IEEE conference paper models IPv6 worm propagation rates. It is a qualitative study 

using differential equations and formulas. The study describes worms that use DNS to 

predict potential IP addresses and suggests that DNS honeypots designed to delay worm 

propagation are ineffective. Although the title indicates IPv6, this is not an IPv6 paper. 

Kempf, J..Nordmark, E., & Nikander, P. (2004). IPv6 neighbor discovery (ND) trust models and 

threats. RFC 3756: Internet Engineering Task Force (IETF). 

This RFC 3756 document discusses security vulnerabilities of the IPv6 Neighbor 

Discovery Protocol. The identified threats create DoS and man-in-the-middle situations 

and the document proposes some mitigation techniques.


218 

Kerr, O. S. (2005, Jan). Digital evidence and the new criminal procedure. Columbia Law Review. 

This paper, published in the Columbia Law Review, addresses the lack of an adequate 

legal framework for digital evidence. A qualitative methodology is used to present the 

current legal framework, unique attributes of digital evidence, and a new legal framework 

that addresses the problems identified. The arguments presented in the paper are based on 

specific case precedents and fourth amendment privacy implications on digital 

investigations. For future research, the author mentions the need to reform the legal 

framework of digital investigations across our borders. The ideas and suggestions are 

well supported and convincing. It would be interesting to investigate current law so 

determine if any of these suggestions were implements. 

Kim, J. W..Cho, H. H..Mun, G. J..Seo, J. H..Noh, B. N., & Kim, Y. M. (2007). Experiments and 

countermeasures of security vulnerabilities on next generation network. Paper presented 

at the Future Generation Communication and Networking. Retrieved from 


This IEEE conference paper addresses specific IPv6 security vulnerabilities like those 

introduced by the routing header, fragment header, extension header, and neighbor 

discovery. It is a qualitative study using description and an experiment. The research 

presents a number of details that could be used to reconstruct the attacks explained. It is 

lacking mitigation strategies and missing descriptions for some of the vulnerabilities 

listed in the tables presented. 

Kitamura, H. (2001). A SOCKS-based IPv6/IPv4 gateway mechanism. RFC 3089: Internet 

Engineering Task Force (IETF).


219 

This RFC 3089 IEFT document discusses the SOCKS64 IPv6/IPv4 transition 

mechanism. This method involves inserting a socket between the application and the 

outbound NIC to allow both IPv6 and IPv4 hosts to communicate with an application 

through a translation API. 

Lan, T. H..Lin, A. C..Lin, I. L., & Wu, T. (2005). Establishment of the standard operating 

procedure (SOP) for gathering digital evidence. Paper presented at the First International 

Workshop on Systematic Approaches to Digital Forensic Engineering (SADFE’05). 


doi:10.1109/SADFE.2005.12 

This IEEE conference paper addresses the low credibility of digital evidence in ad-hoc 

digital investigations. The qualitative methodology used is weakly supported by 

references to evidence handling procedures used by the FBI and Chinese investigators. 

They also base their proposed model on Lin (2000) "Study of Evidence Act on Digital 

Data", Chang (2000) "Study of Computer crime Evidence", and Casey (2000) "Handbook 

of Computer Crime: Forensic Science, Computer and the Internet". The proposed model 

is detailed and appears to be a model that could work in practice or further developed by 

other researchers. The paper seems to be more like a presentation of the authors views 

and beliefs that may be based more on experience than on their research efforts. 

Lee, S..Shin, M.-K..Kim, Y.-J..Nordmark, E., & Durand, A. (2002). Dual stack hosts using 

"bump-in-the-API" (BIA). RFC 3338: Internet Engineering Task Force (IETF). 

This RFC 3338 IETF document discusses the bump in the API IPv6 transition 

mechanism. This mechanism inserts functions between the TCP API and the network 

protocol stack to translate IPv4 API calls from applications into IPv6 API calls. The


220 

components in the method include the function mapper, name resolver, and address 

mapper. 

Lee, Y..Shin, S..Choi, S., & Son, H. g. (2007). IPv6 anomaly traffic monitoring with IPFIX. 

Paper presented at the Second International Conference on Internet Monitoring and 

Protection (ICIMP 2007). Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ICIMP.2007.23 

This IEEE conference paper addresses the lack of methods to track IPv6 flow data to 

identify anomalous traffic flows. The paper provides an analysis of the issues 

surrounding anomaly traffic in IPv6 networks and proposes a new solution to track and 

analyze the traffic. A qualitative methodology is used that presents data in a simulation 

format. Research is based on IPv6 threats presented by: Kamra, The Effect of DNS 

Delays on Worm Propagation in an IPv6 Internet; Convery, IPv6 and IPv4 Threat 

Comparison and Best-Practice Evaluation; Warfield, Security Implications of IPv6; 

Lucena, Covert Channels in IPv6; and Graf, Messaging over IPv6 Destination Options. 

Future research possibilities include expanding the model to address additional anomaly 

traffic and providing support for packet sampling. While, analyzing network flows is 

beneficial to identifying some attacks, the lack of a method to monitor packets at the 

detail level make the research less valuable. 

Leng, X..Bi, J..Zhang, M., & Wu, J. (2007). Connecting IPvX networks over IPvY with a P2P 

method. Journal of Network System Management, 15, 383-399. doi: 10.1007/s10922-007 

9071-z 

This Journal article addresses the problem of IPv6 relay bottlenecks when acting on local 

traffic. It is a qualitative study using description and a quantitative study using lab


221 

simulation to measure performance metrics. The proposal is an algorithm that allows 

local P2P traffic to bypass the IPv6 relay. This solution makes sense and would make 

more sense as a routing protocol as opposed to P2P. This is the more detailed version of 

the Bi conference paper. 

Leong, R. S. C. (2006). FORZA - Digital forensics investigation framework that incorporate 

legal issues. Digital Investigation, 3(Supplement 1), 29-36. doi: 

10.1016/j.diin.2006.06.004 

This journal article published by Elsevier Science attempts to consolidate the large 

number of different frameworks that exist in the field of digital forensics. The paper 

applies a qualitative methodology to propose a new consolidated framework based on 

Zachmans framework on enterprise architecture which we have seen on the Louwrens 

paper. It distils the models presented by: Mark Pollitt at the first DFRWS workshop, Lee 

et al. (2001) "Henry Lee’s crime Scene Handbook", Casey (2003) "Digital Evidence and 

Computer Crime – Forensic Science, Computers and the Internet", and Reith et al. "An 

Examination of Digital Forensic Models". The result is an organized framework that 

follows established enterprise architecture engineering principles in the context of the 

legal requirements of a good investigation. The paper identifies the need to further extend 

the research towards detailed forensic procedures. The strength in this model is in its 

linkage to an established engineering framework; however, EA is essentially a planning 

process and there may be difficulties applying detailed processes to the proposed 

framework.


222 

Lindqvist, J. (2006). IPv6 stateless address autoconfiguration considered harmful. Paper 

presented at the MILCOM. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/MILCOM.2006.302471 

This IEEE conference paper addresses the problem of covert channels embedded in IPv6 

addresses using stateless auto-configuration. This is a qualitative study that uses 

descriptions. The research identifies the possibility of using the duplicate address 

detection packets in a DoS attack. It also discusses and proposes methods that could be 

used to embed messages in the interface ID of an IPv6 address that would be difficult to 

detect. The study presents a compelling look at a vulnerability that may be limited by the 

64 bit length of the address; but, could be used maliciously. 

Losavio, M. M. (2005). The law of possession of digital objects: Dominion and control issues for 

digital forensics investigations and prosecutions. Paper presented at the First 

International Workshop on Systematic Approaches to Digital Forensic Engineering 

(SADFE’05). Retrieved from 


doi:10.1109/SADFE.2005.25 

This IEEE conference paper identifies the problem of applying existing laws of 

possession to digital investigations due to the possibility of alteration that could lead to 

the conviction of innocent people. The paper uses a qualitative study that results in 

logical conclusions drawn from case law. The conclusions could lead to additional care in 

future investigations or new legislation that could help prevent problems from occurring 

in the future. There is an opportunity to extend this research by updating the conclusions


223 

based on current case law and legislation. The strengths of this research is in the 

presentation of concrete case law examples to draw out the conclusions. 

Mac OS X 10.5 Help. (2010). Apple Inc. Retrieved Aug 6, 2010, from http://docs.info.apple.com 

This online help manual for the Apple operating system provides simple instructions on 

configuring MAC clients with IPv6. It includes manual interface setup, information about 

Apple IPv6 application support, 6to4, and firewall configuration. The instructions are 

very basic but easy to follow. 

Mackay, M..Edwards, C..Dunmore, M..Chown, T., & Carvalho, G. (2003, May-June). A 

scenario-based review of IPv6 transition tools. IEEE Internet Computing, 27-35. 

Retrieved from http://doi.ieeecomputersociety.org/10.1109/MIC.2003.1200298 

This IEEE journal article addresses the problem of how to effectively transition to an 

IPv6 network. The research uses the qualitative methodology using descriptive 

techniques. It presents a summary of IPv6 transition techniques including dual stack, 

tunneling, and translation and then suggests implementations for different scenarios. The 

research is a slightly better source of information than Yan-ge and Tantayakul however, it 

is still very basic. 

Naqvi, S..Dallons, G., & Ponsard, C. (2010). Applying digital forensics in the future internet 

enterprise systems - European SME's perspective. Paper presented at the Fifth 

International Workshop on Systematic Approaches to Digital Forensic Engineering. 


doi:10.1109/SADFE.2010.28 

This IEEE Conference addresses small to mid size business in Europe who have not 

adopted post incident handling of net attacks. There is not much information presented,


224 

poor examples using scientific notations, and I am not convinced SMBs need incident 

handling because they are not a target generally. 

Nikkel, B. J. (2005). Generalizing sources of live network evidence. Digital Investigation, 2(3), 

193-200. doi: 10.1016/j.diin.2005.08.001 

The journal article, published by Elsevier Science, addresses the lack of formalized 

methods for network forensics and the simplification of multiple types of network 

captures. A qualitative methodology is used to present logical arguments. Research is 

based on models presented in: the NIST CFTT Project; US Department of Justice; Carrier 

(2004) "A Hardware-Based Memory Acquisition Procedure for Digital investigations", 

Sommer (1999) "Intrusion Detection Systems as Evidence", Wei (2004) "A framework of 

distributed agent-based network forensics system", Tang (2005) "A Simple Framework 

for Distributed Forensics", Carrier (2003) "Defining Digital Forensic Examination and 

Analysis Tools Using Abstraction Layers", and Gerber (2004) "Formalization of 

computer input and output" which are represented in other research and part of this 

biography. The proposed methods have logical conclusions that have implications on 

sensor deployment and packet collection techniques used in organizations. Additionally, 

the paper identified multiple areas of future research including; verifying evidence 

against the source, network write blocking to protect the integrity of captured data at 

certain layers, more detailed capture procedures, extending the research to honeypot 

research, and extending the findings to other network technologies. The research was 

very informative and information that relates network forensics with evidence collection 

is not common in the research.


225 

Nikkel, B. J. (2006). Improving evidence acquisition from live network sources. Digital 

Investigation, 3(2), 89-96. doi: 10.1016/j.diin.2006.05.002 

This journal article, published by Elsevier Science, identifies the distributed nature of 

network based digital evidence and the issues and challenges associated with its 

collection. This paper extends the work done in Nikkel's previous work, as well as Casey 

(2004) "Network Traffic as a Source of Evidence", and Sommer (2005) "guide to digital 

investigations and evidence". The qualitative methodology is used in the research to 

present logical arguments to reach conclusions. The paper presents a detailed procedural 

framework that network forensic practitioners can use to increase the accuracy of 

network based evidence collection. The author further identifies the need to better define 

the methods and tools used in network captures. The proposed procedure appears to be a 

contribution to the science and is different than other digital evidence collection methods 

which implies a need for unique methods for different types of evidence. 

Nikkel, B. J. (2007). An introduction to investigating IPv6 networks. Digital Investigation, 4(2), 

59-67. doi: 10.1016/j.diin.2007.06.001 

This journal article addresses the problem of the growing popularity of IPv6 networks 

and the lack of awareness among investigators. The article does not present any previous 

research on investigating IPv6 networks; however, it supports arguments using a variety 

of IPv6 security and protocol informational resources. A qualitative methodology is used 

based on descriptive examples used to establish each point. The article provides a 

introductory tutorial for forensic investigators and practitioners in the field to better 

address IPv6 in the discipline. It provides a good introduction for non-technical


226 

practitioners, however, I think the article could have provide more technical details to 

provide more of an impact for the field. 

Nordmark, E. (2000). Stateless IP/ICMP translation algorithm (SIIT). RFC 2765: Internet 


This RFC 2765 IETF document describes the technical details of the SIIT algorithm that 

is used in IPv4/IPv6 header translation. It outlines the fields of an IPv4 and IPv6 header 

and how data should be translated from one protocol to the other. This includes 

translating addresses, ICMP messages, and ICMP error codes. 

Park, T. K., & Ra, I. (2008). Design and evaluation of a network forensic logging system. Paper 

presented at the Third International Conference on Convergence and Hybrid Information 

Technology. Retrieved from http://doi.ieeecomputersociety.org/10.1109/ICCIT.2008.28 

doi:10.1109/ICCIT.2008.28 

This IEEE conference paper addresses current approaches to audit at packet/kernel level 

but doesn't provide enough information or security against attack to be applicable. 

Previous research includes: Computer Associates, eTrust Network Forensics, Goel, A 

robust, high-performance reconstruction system, Jeffris, The Coroner’s Toolkit: Incident 

Handling and Forensics, The Honeynet Project, Know Your Enemy: Learning about 

Security Threats. Cont: detailed definition of system and test platform. This is a 

qualitative study using simulation. Additional research is needed to create formatted 

forensic data, expand to other operating systems, and optimize the program. The proposal 

seems good. It Includes many different correlating evidence that can be used. May not be 

applicable to large networks and did not address distributed systems. Sounds like another 

commercial tool being defined. Security may be addressed but should monitor passively.


227 

Phang, S. Y..Lee, H., & Lim, H. (2008). Design and implementation of V6SNIFF: An efficient 

IPv6 packet sniffer. Paper presented at the Third 2008 International Conference on 

Convergence and Hybrid Information Technology. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ICCIT.2008.279 

This IEEE conference paper addresses the lack of a IPv6 packet sniffer that provides 

adequate performance. This is a qualitative design science based research project that 

presents the framework for a new product and the testing for the product. The paper 

mentions previous sniffers like Kismet, Wireshark, and TCPDump and dated network 

analysis research including: Apisdorf, OC3MON: Flexible, Affordable, High 

Performance Statistics Collection; Malan, An Extensible Probe Architecture for Network 

Protocol Performance Measurement; Keys, The Architecture of CoralReef: An Internet 

Traffic Monitoring Software Suite; and Anagnostakis, Efficient packet monitoring for 

network management. The contributions is the definition of an IPv6 sniffer that increases 

performance over TCPDump and future work possibilities exist for reducing packet loss 

in the proposed solution. The resulting product seems like it may provide another option 

for capturing IPv6 packets; however, it is unclear whether the product is needed or if the 

performance tests presented will be applicable in a live environment. 

Ponec, M..Giura, P..Bronnimann, H., & Wein, J. (2007). Highly efficient techniques for network 

forensics. Paper presented at the Proceedings of the 14th ACM Conference on Computer 

and Communications Security, Alexandria, Virginia, USA. Retrieved from 

doi:10.1145/1315245.1315265 

The ACM conference paper addresses the problem of payload attribution which is the 

saving of all packets of data on a network to associate with certain excerption as evidence


228 

which takes a lot of space and is beyond capabilities of most organizations. Previous 

research includes: The research increased the accuracy and reduced the size of previous 

methods of attribution. The study is mixed method using sampling of data. This study 

looks good and may help solve the problem of large forensic data sets. 

Radhakrishnan, R..Majid, J..Shabana, M., & Moinuddin, M. (2007). Security issues in IPv6. 

Paper presented at the Third International Conference on Networking and 

Services(ICNS'07). Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ICNS.2007.106 

This IEEE conference paper addresses features of the IPv6 protocol. The qualitative 

methodology using description techniques is employed in the study. IPv6 enhancements 

were addressed including address efficiency, administration, and security. The study 

concludes that it is to early to determine the impact of IPv6 on security. The information 

in the study is simplistic at best. 

Savola, P. (2005). Observations of IPv6 traffic on a 6to4 relay. SIGCOMM Computer 

Communications Review, 35(1), 23-28. doi: http://doi.acm.org/10.1145/1052812.1052821 

This journal article presents a study that analyzes statistical data about 6to4 traffic 

flowing through a public 6to4 relay in Finland. A quantitative methodology is used to 

present data from system logs at the relay over a 3 year period. The study identified a 

large jump in the number of Windows nodes with 6to4 enabled and within range while 

only 1/100 notes actually utilized the relay for IPv6 traffic. The study is very interesting 

and helps identify a small part of the potential IPv6 activity. The large jump from 100K 

to 2 million nodes per month seems to indicate some other factor instead of new nodes 

being added to the network.


229 

Savola, P., & Patel, C. (2004). Security considerations for 6to4. RFC 3964: Internet Engineering 

Task Force (IETF). 

This RFC 3964 document details the security implications of the 6to4 transition 

mechanism. The research outlines the DoS based attacks that could be initiated using 

6to4 against other IPv6, IPv4, or 6to4 nodes. The RFC also includes mitigations 

strategies and detailed rules to prevent these problems. 

Schroeder, S. C. (2005). How to be a digital forensic expert witness. Paper presented at the 

Proceedings of the First International Workshop on Systematic Approaches to Digital 

Forensic Engineering (SADFE’05). Retrieved from 


This IEEE conference paper addresses the difficulty of adequately preparing to be an 

expert witness in cybercrime cases. It presents a descriptive methodology that presents a 

cybercrime case and the proper preparation methods for an expert witness. This research 

enhanced the knowledge of potential expert witnesses and provides a training tool to get 

them more familiar with the process. There was no prior research or areas for further 

research mentioned. It is difficult to classify this paper as research; however, the author 

worked for the DoJ which adds credibility to his perspective. It is also interesting to view 

a narrative of an entire cyber investigation through the criminal proceeding. 

Seo, S. H., & Kong, I. Y. (2005). A performance analysis model of PC-based software router 

supporting IPv6-IPv4 translation for residential gateway. Paper presented at the 

Proceedings of the Fourth Annual ACIS International Conference on Computer and 

Information Science (ICIS’05). Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ICIS.2005.14


230 

This IEEE conference proceeding addresses the problem of the lack of a comprehensive 

queue based method of IPv6 and IPv4 coexistence. The study is mixed method using both 

description and an experiment that measured performance statistics. The research created 

a working model for testing that created a software based gateway that uses NAPT-PT 

and SIIT together to translate IPv4 and IPV6 packets. The method looks very good for 

small networks. It will most likely allow transparent coexistence of IPv4 and IPv6 

network hosts; however, scalability will certainly be an issue. 

Shengyang, C., & Yanlei, S. (2010). P2P communication mechanism based on request 

forwarding in IPv4 and IPv6 coexistence network. Paper presented at the International 

Conference on e-Education, e-Business, e-Management and e-Learning. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/IC4E.2010.16 

This conference paper addresses the problem of transitioning IPv6 in a seamless way. It 

is a qualitative study that uses description and some quantitative performance elements. 

The research proposes building an overlay network on IPv4 that allows requests for IPv6 

services to be passed among P2P clients until a IPv6 client is located. The approach looks 

very promising as a solution to the problem identified. 

Shin, Y. (2008). New digital forensics investigation procedure model. Paper presented at the 

Fourth International Conference on Networked Computing and Advanced Information 

Management. Retrieved from http://doi.ieeecomputersociety.org/10.1109/NCM.2008.116 

doi:10.1109/NCM.2008.116 

This IEEE conference paper proposes a new forensic procedural model to address the 

lack of adequate forensic procedures. The paper specifically claims that the models 

proposed by the U.S. Department of Justice and Carrier (2003) "Getting Physical with


231 

the Digital Investigation Process" lacks an adequate analysis and classification process. 

There is a weak qualitative methodology applied based on other sources however, there is 

little support or basis for the results. The resulting conclusions seem somewhat obvious 

and it is likely that there is a research contribution in this paper. 

Sommer, P. (1999). Intrusion detection systems as evidence. Computer Networks, 31(23-24), 

2477-2487. doi: 10.1016/s1389-1286(99)00113-9 

This Elsevier journal article presents the problem of using IDS data as a source for digital 

evidence in a court of law. The research is a qualitative study using a description method 

to present legal information and analysis. The research concludes that digital evidence 

must be supported by corroborating evidence from different sources. It presents a 

convincing argument and is based on solid logic and facts. It also seems to be relevant 

today even though it was written in 1999. 

Sotillo, S. (2006). IPv6 security issues. 

This unpublished paper addresses the new security concerns for IPv6. It is a qualitative 

study using descriptions. The study begins by listing and explaining common IPv4 

vulnerabilities and IPv6 characteristics including security features. The study outlined 

some IPv6 security vulnerabilities including scanning, extension header DoS attacks, and 

multicast smurf attacks. There are some good basic points in the study; however, the 

content is fairly simplistic. 

System administration guide: IP services. (2009). Sun Microsystems. Retrieved Aug 6, 2010, 

from http://docs.sun.com/app/docs/doc/816-4554/ipv6-ref-83?l=en&a=view 

This Network Administration guide for the Solaris operating system provides a 

compressive description of the IPv6 protocol and setup for IPv6. This guide summarizes


232 

a number of RFC documents related to IPv6 and is an excellent source for understanding 

the IPv6 protocol. It also includes multiple sections about configuring IPv6 interfaces, 

router, and tunnels. This includes different sections for basic configuration and advanced 

configuration that provide more details. 

Szigeti, S., & Risztics, P. (2004). Will IPv6 Bring Better Security? Paper presented at the The 

30th EUROMICRO Conference. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/EURMIC.2004.1333418 

This conference paper attempts to determine if IPv6 will change security on the Internet. 

It is a qualitative study using description. The study identifies a number of considerations 

for IPv6 security including scanning, IPSec, auto-configuration, neighbor discovery, and 

option headers. The author concludes that it is to early to tell if there will be an impact of 

Ipv6 on the Internet. The source is well laid out and has some unique points. 

Tadayoshi, K. (2005). Remote Physical Device Fingerprinting. IEEE Transactions on 

Dependable and Secure Computing, 2, 93-108. 

This paper addresses methods to identify remote devices. Previous research includes 

Paxson, “On Calibrating Measurements of Packet Transit", Moon et al. "Estimation and 

Removal of Clock Skew From Network Delay Measurements ". The research established 

proof that time differences between packets can be used to identify the same source of 

traffic communications: It is interesting that this is used by Nmap and p0f to identify 

operating systems; however, I can't see how this is valuable for forensics. 

Tantayakul, K..Kamolphiwong, S., & Angchuan, T. (2008). IPv6@HOME. Paper presented at 

the Proceedings of the International Conference on Mobile Technology, Applications,


233 

and Systems, Yilan, Taiwan. Retrieved from 


This conference proceeding addresses the need for IPv6 in the homes and the eventual 

exhaustion of the IPv4 space. The research presents a possible methods of connecting a 

home router operating from a IPv4 network to a IPv6 network using 6to4 tunneling. The 

qualitative methodology with descriptive and experimental techniques was used in the 

study. The research did provide a good overview of IPv6 transition mechanisms and a 

proposal for modifying a router to operate the 6to4 tunnel. I cannot confirm if the router 

would still work however, I would guess it works best with the router the author utilized. 

Templin, F..Gleeson, T., & Thaler, D. (2008). Intra-site automatic tunnel addressing protocol 

(ISATAP). RFC 5214: Internet Engineering Task Force (IETF). 

This RFC 5214 describes the ISATAP IPv6 transition mechanism which allows IPv6 

tunneling from remote sites through IPv4 networks. The document described some 

aspects of the protocol and identified spoofing as a possible security vulnerability. 

Tseng, B..Chen, C. Y., & Laih, C. S. (2006). Design and implementation of an IPv6-enabled 

intrusion detection system (6IDS). Paper presented at the International Computer 

Symposium, Taipei, Taiwan. 

http://dspace.lib.fcu.edu.tw/dspace/bitstream/2377/1860/1/ce07ics002004000116.pdf 

This conference paper addresses the lack of an effective IPv6 IDS solution by providing 

an architectural summary and implementation description for a software based IDS 

solution. A qualitative methodology using description and scenario testing is used to 

present the solution. Prior research presented in the paper is based on IPv4 IDS methods 

and the author indicated a lack of sources for IPv6 IDS research. The paper is an initial


234 

study and further research areas are proposed to further integrate IPv6 into IPv4 and 

expand IPv6 attack signatures. This research appears to be promising with future 

opportunities to expand IPv6 attack signatures; although, more details could have been 

presented that outlined the proposed solution. 

Tsirtsis, G., & Srisuresh, P. (2000). Network address translation - protocol translation (NAT 

PT). RFC 2766: Internet Engineering Task Force (IETF). 

This RFC 2766 document defines the NAT-PT IPv6 transition mechanism. NAT-PT 

allows IPv6 nodes to communicate with IPv4 nodes using SIIT translation and assigning 

IP addresses as necessary. The other translation mechanisms like BIA and BIS employ 

functions similar to NAT-PT and are more widely deployed. 

Tsuchiya, K..Higuchi, H., & Atarashi, Y. (2000). Dual stack hosts using the "bump-in-the-stack" 

technique (BIS). RFC 2767: Internet Engineering Task Force (IETF). 

This RFC 2767 from the IETF describes the bump in the stack IPv6 transition 

mechanism. This method inserts three modules in the TCP/IP stack of a dual stack host 

and dynamically assign IPv4 addresses to communication sessions that it observes 

between IPv4 applications and IPv6 destinations or sources. 

Tulloch, M..Northrup, T..Honeycutt, J., & Wilson, E. (2010). Windows 7 Resource Kit: 

Microsoft Press. 

This Micosoft publication is a technical manual on Microsoft Windows 7 and Windows 

Server 2008. If explains a number of features and explains how to configure settings for 

available functionality. Chapter 28, "Deploying IPv6" explains the features of IPv6 in 

Windows products. This chapter provides a good overview but lacks some necessary 

details for a full understanding of IPv6 in Windows.


235 

Visoottiviseth, V., & Bureenok, N. (2008). Performance comparison of ISATAP implementations 

on FreeBSD, RedHat, and Windows 2003. Paper presented at the 22nd International 

Conference on Advanced Information Networking and Applications - Workshops. 

http://doi.ieeecomputersociety.org/10.1109/WAINA.2008.79 

This conference paper addresses the performance of the ISATAP IPv6 transition 

mechanism verses traditional IPv4. It is a quantitative study that uses testing of network 

packet loss, latency, and other metrics. The conclusion is that traditional IPv4 traffic has 

better performance than ISATAP packets. This conclusions seem obvious considering the 

traffic begins as IPv4 and ISATAP adds additional overhead to the network. 

Vives, A., & Palet, J. (2005). IPv6 distributed security: problem statement. Paper presented at 

the The 2005 Symposium on Applications and the Internet Workshops (SAINT-W’05). 

Retrieved from http://doi.ieeecomputersociety.org/10.1109/SAINTW.2005.72 

This IEEE conference paper addresses the limited information available concerning IPv6 

security vulnerabilities. The qualitative methodology is employed using description. The 

study describes vulnerabilities in IPv6 including Neighbor Discovery, end-to-end, and 

mobile. The author proposes host based security as a solution to the issues proposed. The 

paper has a large number of careless grammar errors and is very simplistic but does have 

a few notable points. 

Wagener, G..Dulaunoy, A., & Engel, T. (2008). Towards an estimation of the accuracy of TCP 

reassembly in network forensics. Paper presented at the Future Generation 

Communication and Networking. Retrieved from 


doi:10.1109/FGCN.2008.118


236 

This IEEE conference paper addresses the problem of accurate network analysis tied to 

stream reassembly because we need to know accuracy of tools and poor reassembly leads 

to corrupt data. This is a qualitative study using simulation. Prior research includes: Song 

et al. "Nidsbench - a network intrusion detection test suite", M.I. Cohen et al. "Pyflag - an 

advanced network", Eric Cronin et al. "On the reliability of current generation network 

eavesdropping tools". The research proposes a model to establish stream reassembly 

errors. Future research is needed to look for causes of error and build tools to solve them. 

The study is short with a lack of detail as in the author's other paper. This proposal 

doesn't seem applicable to forensics. 

Wang, S. (2007). Measures of retaining digital evidence to prosecute computer-based cybercrimes. 


This journal article published by Elsevier Science identifies the need for improved digital 

evidence extraction and handling by investigators. A qualitative methodology is used to 

present logical arguments. The paper uses Casey (2002) "Digital evidence and computer 

crime: forensic science, Computers and the Internet" and Kruse (2002) "Computer 

Forensic: Incident Response Essentials" as a basis for their research. The intended result 

of the research is to describe a set of tools and techniques that support digital evidence 

collection; however, it is unclear if the information presented is new information and 

useful to practitioners. It is the first source reviewed that presents information at the 

machine level. 

Wang, W., & Daniels, T. E. (2007). Diffusion and graph spectral methods for network forensic 

analysis. Paper presented at the Proceedings of the 2006 Workshop on New Security 

Paradigms, Germany.


237 

This ACM conference paper addresses the problem of the scale of cyber attacks 

combined with ad-hoc methods is not ideal for analysis. The research applies 

mathematical model to forensic science. Future research is needed to investigate how the 

approach would work in a noisy network environment and evaluate it in different 

environments. Previous research includes: Wang "Building evidence graphs for network 

forensics analysis", Chung, "Spectral Graph Theory", Mohar "The laplacian spectrum of 

graphs". This research is a little confusing . It is unclear if mathematical models can be 

applied to forensics? 

Warfield, M. H. (2003). Security implications of IPv6. Internet Security Systems. Retrieved 

from http://www.blackhat.com/presentations/bh-federal-03/bh-federal-03-warfield/bhfed-03-warfield.pdf 

This unpublished presentation addresses the need for better security with IPv6 

implementations by outlining the risks. The qualitative methodology is used and the 

document is in bullet point format. The presentation addresses some of the IPv6 

vulnerabilities; however, the most interesting information includes the example of an 

IPv6 backdoor implementation and the list of Ipv6 tools. 

Wei, X..Jiang-wei, Z., & Guo-dong, Z. (2009). Application research on IPv4/IPv6 dual stack 

technology. Paper presented at the International Conference on Signal Processing 

Systems. Retrieved from http://doi.ieeecomputersociety.org/10.1109/ICSPS.2009.200 

This IEEE conference paper addresses the need to transition from IPv4 to IPv6. It is a 

qualitative study. The research briefly describes dual stack architecture and proposes a 

possible implementation for a campus network, Overall, this is a limited and short


238 

document that doesn't address anything that has not already been addressed by other 

individuals. 

WenQi, W., & Weiguang, L. (2009). The research on forensic model based network. Paper 

presented at the Second International Workshop on Computer Science and Engineering. 

Retrieved from http://doi.ieeecomputersociety.org/10.1109/WCSE.2009.635 

doi:10.1109/WCSE.2009.345 

This IEEE conference paper address the shortcomings of other models that do not 

account for admissible evidence. Prior research includes: DoJ: Digital 

Evidence:Standards and Principles 

http://www.fbi.gov/hq/lab/fsc/backissu/april2000/swgde.htm This is a qualitative study. 

The research proposes another framework for analysis that addresses evidence directly. 

This is weak support from the literature and incorrect discussion of HTTP email which 

doesn't exist. 

Wu, L..Hai-xin, D..Tao, L..Xing, L., & Jian-ping, W. (2009). H6Proxy: ICMPv6 weakness 

analysis and implementation of IPv6 attacking test proxy. Paper presented at the 

Symposia and Workshops on Ubiquitous, Autonomic and Trusted Computing. Retrieved 

from http://doi.ieeecomputersociety.org/10.1109/UIC-ATC.2009.78 doi:10.1109/UIC 

ATC.2009.78 

This IEEE conference paper addresses the weakness in ICPMv6. It is a qualitative study 

using description and experiment. The research exposes vulnerabilities in destination 

unreachable or redirect messages that could cause DoS or man in the middle attacks. The 

study then explains how to implement a router redirect attack that could be used to


239 

reroute victims to spoofed web sites. This study is interesting; however, the author does 

not recommend a mitigation strategy. 

Xie, L..Bi, J., & Wu, J. (2007). A multihoming based IPv4/IPv6 transition approach. Paper 

presented at the Proceedings of the 6th international IFIP-TC6 conference on Ad Hoc and 

sensor networks, wireless networks, next generation internet, Atlanta, GA, USA. 

This conference paper addresses the problem of redundancy in transition networks. This 

is a qualitative study using narrative and description. The research proposes inserting a 

layer between the link and network layers to dynamically rout IPv6 packets between a 

tunnel broker and 6to4 dual homed interface. It provides the best of these methods and 

allows for redundancy on the IPv6 network connection. 

Yan-ge, C..Shui-mu, T., & Jun-ying, G. (2009). IPv4/IPv6 intercommunication technology 

research. Paper presented at the International Conference on Environmental Science and 

Information Application Technology. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ESIAT.2009.297 

This conference proceeding presents a summary of IPv6 transition mechanisms. The 

qualitative method was used and the problem addresses is the lack of research on 

transition mechanisms. The research presents three phases of IPv6 transition including 

IPv6 over IPv4, transparent interconnect, and IPv4 over IPv6. The author's English skills 

create a lot of confusing passages however, it provides a basic technical overview. 

Yang, J. (n.d.). Fast worm propagation in IPv6 networks. 

This unpublished work addresses the speed of IPv6 worm propagation and identifies 

methods to remove barriers to the large address space. This is a quantitative study that 

presents the results from numerical analysis. The research identifies various methods to


240 

reduce worm propagation on a IPv6 network from 22,000 years using random scanning to 

6 hours using faster connections, dense addressing, DNS, and local cache analysis. The 

analysis is interesting and discounts the benefits of the IPv6 address space as a worm 

propagation deterrent. 

Yang, X., & Ma, T. (2007). A link signature based DDoS attacker tracing algorithm under IPv6. 

Paper presented at the Future Generation Communication and Networking. Retrieved 

from http://doi.ieeecomputersociety.org/10.1109/FGCN.2007.15 

This IEEE conference paper addresses the problem of sourcing DDoS attacks in IPv6 

networks. It is a qualitative study using an experiment. The research proposes a packet 

marking method that is implemented at edge routers to allow a destination to reconstruct 

a packet's original path. The research seems to only extend other packet marking research 

onto IPv6 when this is not exclusively an IPv6 topic. Also it is unclear of the applicability 

of this approach given the added router overhead needed to write into each packet. 

Yang, X..Ma, T., & Shi, Y. (2007). Typical DoS/DDoS threats under IPv6. Paper presented at 

the Proceedings of the International Multi-Conference on Computing in the Global 

Information Technology (ICCGI'07). Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/ICCGI.2007.61 

This IEEE conference paper presents the methods used to initiate DoS attacks in IPv6. It 

is a qualitative study using an experiment to present results. The research described 

various DoS attacks related to the neighbor discovery protocol and flooding and then 

explained the steps they used and results of an experiment conducted in a lab 

environment. The study is interesting because of the details presented; however, it did not 

conduct an experiment with all of the attacks.


241 

Yangui, X..Xiangchun, L..Jiachun, Z., & Huanyan, Q. (2009). Worm detection in an IPv6 

internet. Paper presented at the International Conference on Computational Intelligence 

and Security. Retrieved from doi:10.1109/CIS.2009.216 

This IEEE conference paper attempts to define a method for detecting worms. It is a 

qualitative study using an experiment to draw conclusions. The research suggests that 

IPv6 worms will propagate faster at the local level; however, they will still use email and 

search engines to attack initially through email. The results of the experiment indicate 

that it may be possible to identify worms by analyzing DNS and SMTP traffic. The study 

is interesting; however, the experiment uses IPv4 even though the title is based on IPv6. 

Yao, G. x..Guan, Q. l..Lin, L. c..Huang, S. Q..Zhu, G. c..Zhang, H., et al. (2008). Research and 

Implementation of Next Generation Network Intrusion Detection System Based on 

Protocol Analysis. Paper presented at the ISECS International Colloquium on 

Computing, Communication, Control, and Management. Retrieved from 

http://doi.ieeecomputersociety.org/10.1109/CCCM.2008.30 doi:10.1109/CCCM.2008.30 

This IEEE conference paper addresses the belief that IPv4 IDS devices will not work for 

IPv6. The research proposes a new method for using NIDS devices in IPv6. Based on 

previous research, there is not a need to use a unique devices just for IPv6. It is more 

important to develop protocol analysis and pattern matching signatures. 

Zagar, D..Grgic, K., & Rimac-Drlje, S. (2007). Security aspects in IPv6 networks 

implementation and testing. Computers & Electrical Engineering, 33, 425-437. doi: 

10.1016/j.compeleceng.2007.05.008 

This Elsevier journal article addresses the new IP security threats in IPv6 which present 

unique challenges that were not considerations in IPv4. The study uses a qualitative


242 

methodology with logical descriptions and conclusions and also presents the results of an 

IPv6 scanning experiment. Sever IPv6 threats are identified and mitigation strategies 

using IDS and firewalls is proposed. The study provides a good list of threats; however, 

the suggestion of using Wireshark for IDS does not provide an ideal solution. 

Zander, S..Armitage, G., & Branch, P. (2007). A survey of covert channels and coutermeasures 

in computer network protocols. IEEE Communications Surveys & Tutorials, 9(3). 

This IEEE journal article addresses covert channels in network communication. It is a 

qualitative study and survey of other research. The survey presents other research in 

covert channels and constructs an extensive list of methods. It also presents discussion on 

identifying and eliminating covert channels. The overall conclusion is that not all covert 

channels can be eliminated; however, design flaws enable many of them to exist. 

Zheng, Q..Liu, T..Guan, X..Qu, Y., & Wang, N. (2007). A new worm exploiting IPv4-IPv6 dualstack 

networks. Paper presented at the Proceedings of the 2007 ACM workshop on 

Recurring malcode, Alexandria, Virginia, USA. 

This ACP conference paper addresses the problem of worm propagation in dual stack 

networks. It is a qualitative study the presents conclusions based on population statistics. 

The research concluded that worms are able to propagate faster in IPv6 networks due to 

the neighbor discovery protocol that causes every host to respond. Although, the research 

has a valid point, it only applies to nodes on the local link which are usually confined to a 

few nodes. The real problem is the worm spreading globally, not locally. 

Zhou, L., & Renesse, R. v. (2004). P6P: A peer-to-peer approach to Internet infrastructure. 

Paper presented at the International workshop on Peer-To-Peer Systems.


This conference paper addresses the problem of transitioning from IPv4 to IPv6 in P2P 

networks. It is a qualitative study using description. The author proposes a new P2P 

model called P6P that routes packets over the IPv4 network and provides IPv6 

connectivity in a P2P model. Like the work by Shengyang, the proposal looks promising 

as a replacement for P2P networks.

Crosby-Signed Thesis - Alliance Digital Repository

You also want an ePaper? Increase the reach of your titles

Delete template?

Save as template?