# Presentation: 579682

## Airborne Networks TIMWhy IPv6 ?

- Will Ivancic
- _[william.d.ivancic@nasa.gov](mailto:iwilliam.d.ivancic@nasa.gov)_
- 216-433-3494

## Introductions

- Who am I and what have I done with IPv6?
- Who are you?
- Have you deployed *ANY* IPv6 networks?
- What do you know about:
- Networking?
- Internet Protocols (v4 or v6)?
- Network Security?

- Informal and Interactive

## Are this your interest?

- Questions
- Why use IPv6 vs IPv4?
- How mature is IPv6?
- Mobile Networks and Ad Hoc Networks?
- IPv6 and Network Centric Operations
- What are the advantages for military networks?
- What are the advantages for airborne networks?

## Why use IPv6 vs IPv4?

## IPv6 vs IPv4

- Addressing
- Larger Address space
- Autoconfiguration
- Link Local Addressing
- Unique Local IPv6 Unicast Addressing (private addresses)
- Location Management
- Potentially more secure
- IPsec capability mandated
- Larger address space
- No need for Network Address Translation (NAT)
- Peer-to-Peer networking
- Potentially better Quality of Service (QOS)
- Nearly everything new is IPv6

## Internet Protocol version 6 and Network Centric OperationsKey Concepts

- Will IvancicSYZYGY Engineering_[ivancic@syzygyengineering.com](mailto:ivancic@syzygyengineering.com)_

- © 2004 Syzygy Engineering  – Will Ivancic

## Network Design Triangle

- © 2004 Syzygy Engineering  – Will Ivancic

## Policy

- Policy Drives Everything!

- Policy Can Make or Break IPv6!

- Source:   http://minhdo.bitterjerksociety.org/gallery/page_03.htm

- © 2004 Syzygy Engineering  – Will Ivancic

- Just because you can do something doesn’t mean you are permitted to do something.

## IPv6 Functional Capabilities

- Expanded Addressing and Routing
- Simplified Header Format
- Extension Headers and Options
- Options are placed in separate headers after the core routing information
- Options do not necessarily have to be processed in core network (speed)
- Authentication and Encryption Support
- Required in ALL implementations of IPv6!

- Autoconfiguration
- Source Routing Support
- Ad Hoc Network
- Route Optimization for Mobility
- Simple and Flexible  Transition
- Incremental Upgrade
- Incremental Deployment
- Easy Addressing (
- Low Startup Costs
- Quality of Service Capabilities
- Real-Time Traffic
- Traffic Class
- Flow labels

- © 2004 Syzygy Engineering  – Will Ivancic

## IPv4 & IPv6 QoS Fields

| Version | IHL | Type of Service | Total Length |  |  |
| --- | --- | --- | --- | --- | --- |
| Identification |  |  | Flags | Fragment Offset |  |
| Time to Live |  | Protocol | Header Checksum |  |  |
| Source Address |  |  |  |  |  |
| Destination Address |  |  |  |  |  |
| Options |  |  |  |  | Padding |

| Version | Traffic Class | Flow Label |  |  |
| --- | --- | --- | --- | --- |
| Payload Length |  |  | Next Header | Hop Limit |
| Source Address |  |  |  |  |
| Destination Address |  |  |  |  |

**IPv4 Header 20 bytes**

**IPv6 ****Header, 40 bytes fixed**

** ****field****’****s ****name ****kept from IPv4 to IPv6**
** ****fields not kept in IPv6**
** ****Name & position changed in IPv6**
** ****New field in IPv6**

**Legend**

- © 2003 Cisco Systems, Inc. All rights reserved – Steve Pollock

## Currently Defined Headers (RFC2460)

- The IPV4 options field was replaced by the modular ***extension header***.
- There is no set limit on the number of these headers you can have.

_*H*_***opBy***_*H*_***op, ***_*R*_***outing ***_*H*_***eader, ***_*F*_***ragment ***_*H*_***eader, ***_*D*_***estination ***_*O*_***ptions, ***_*M*_***obility ***_*H*_***eader, ***_*A*_***uthentication ***_*H*_***eader, ***_*E*_***ncrypted ***_*S*_***ecurity ***_*P*_***ayload.  Hop-By-Hop must follow IPv6 Header, Otherwise no set order***

- © 2003 Cisco Systems, Inc. All rights reserved – Steve Pollock

**Notes:**
The IPV4 options field was replaced by the modular ‘extension header.’
Currently Defined Headers (RFC2460) are: Hop-by-Hop, Routing Header, Fragment Header, Destination Options, Authentication Header, Encrypted Security Payload,  and Mobility Header (?).
There is no set limit on the number of these headers you can have.
   The Hop-by-Hop Options header is used to carry optional information   that must be examined by every node along a packet's delivery path. Value =  0.
  The Routing header is used by an IPv6 source to list one or more intermediate nodes to be "visited" on the way to a packet's destination.  This function is very similar to IPv4's Loose Source and Record Route option. Value = 43 (Useful for Ad-Hoc Routing)
  The Fragment header is used by an IPv6 source to send a packet larger  than would fit in the path MTU to its destination.  (Note: unlike IPv4, fragmentation in IPv6 is performed only by source nodes, not by routers along a packet's delivery path -- see section 5.)  Value = 44. MTU Discovery done by source.
 The Mobility Header is used by mipv6 and NEMO, Value = 2.
   The Destination Options header is used to carry optional information that need be examined only by a packet's destination node(s). Value =  60.  Used by Mobile-IP.
  Authentication and Encryption headers will be covered in Security Section of this presentation.

## Addressing Architecture

- Unicast
- Unspecified  0::0
- Loopback  0::1
- User Local Addresses
- Link Local    prefix 1111111010
- Site Local     prefix 1111111011
- Unique Local IPv6 Unicast   prefix FC00::/7
- Analogous to IPv4 Private Address Space
- provides for 2.2 trillion addresses
- Anycast
- Multicast    prefix 11111111

- © 2004 Syzygy Engineering  – Will Ivancic

**Nice Explaination of Anycast for IPv4 at**
**http://www.net.cmu.edu/pres/anycast/Deploying%20IP%20Anycast.ppt**

**Notes:**
The Unspecified Address must never be assigned to any node.  It indicates the absence of an address.  One example of its use is in the Source Address field of any IPv6 packets sent by an initializing host before it has learned its own address.  The unspecified address must not be used as the destination address of IPv6 packets or in IPv6 Routing Headers.

The Link-Local is for use on a singlelink and the Site-Local is for use in a single site.

Site-Local addresses are designed to be used for addressing inside of a site without the need for a global prefix.  Routers must not forward any packets with site-local source or destination addresses outside of the site.
An IPv6 anycast address is an address that is assigned to more thanone interface (typically belonging to different nodes), with the property that a packet sent to an anycast address is routed to the "nearest" interface having that address, according to the routing protocols' measure of distance.
Anycast addresses are allocated from the unicast address space, using   any of the defined unicast address formats.  Thus, anycast addresses are syntactically indistinguishable from unicast addresses.  When a unicast address is assigned to more than one interface, thus turning it into an anycast address, the nodes to which the address is assigned must be explicitly configured to know that it is an anycast address.
o An anycast address must not be used as the source address of an IPv6 packet.
o An anycast address must not be assigned to an IPv6 host, that is, it may be assigned to an IPv6 router only.

## Address Allocation Policy

- 128-bit addresses:
-  340,282,366,920,938,463,463,374,607,431,768,211,456  (340 duodecillion)
-  Over a million addresses for every person on the planet!,
-  But not really due to inefficiency of address allocations
- Administered by IANA to Regional Registries: ARIN, APNIC, RIPE, LACNIC
- The allocation process is under reviewed by the Registries:
- IANA allocates 2001::/16 to registries
- Each registry gets a /23 prefix from IANA
- Formerly, all ISP were getting a /35
- With the new policy, Registry allocates a /32 prefix to an IPv6 ISP
- Then the ISP allocates a /48 prefix to each customer (or potentially /64)

**2001**

**0410**

**ISP prefix**

**Site prefix**

**LAN prefix**

**/32**

**/48**

**/64**

**Registry**

**/23**

**Interface ID**

**interface**
**identifier**
**(64 bits)**

- © 2003 Cisco Systems, Inc. All rights reserved – Steve Pollock

**Notes:**
	The generic allocation process is: 
IANA allocates 2001::/16 to registries from the full address space
Slow-start allocation process:
 Each registry gets a /23 prefix from IANA, within the 2001::/16 space
 Registry allocates an initial /32 prefix to a new IPv6 ISP
 ISP allocates a /48 prefix (out of the /32) to each customer
A /64 if there is only one subnet, a /128 if there is one and only one host.
9.3. The size of IPv6's address space
Compared to IPv4, IPv6 has a seemingly endless amount of address space. While superficially true, short-sighted and wasteful allocation policies could also result in the adoption of practices that lead to premature exhaustion of the address space.
It should be noted that the 128-bit address space is divided into three logical parts, with the usage of each component managed differently. The rightmost 64 bits, the Interface Identifier [RFC2373], will often be a globally unique IEEE identifier (e.g., mac address). Although an "inefficient" way to use the Interface Identifier field from the perspective of maximizing the number of addressable nodes, the numbering scheme was explicitly chosen to simplify Stateless Address Autoconfiguration [RFC2462].
The middle 16 bits of an address indicate the subnet ID. Per [RFC 3177, RIRs-on-48s], this field will often be inefficiently utilized, but the operational benefits of a consistent width subnet field were deemed to be outweigh the drawbacks.
The decisions to inefficiently utilize the bits to the right of /48 were made under the knowledge and assumption that the bits to the left of /48 would be managed prudently and that, if done so, will be adequate for the expected lifetime of IPv6 [RFC3177].

## Transition and Operations Costs

- Cost Difference
- Between IPv4 / IPv6
- Operations

- <footer>Source: PC of Japan

- Transition Cost

## IPv4 Address Pool

- Projections are based on history so all bets are off once the run-on-the-bank starts.
- The only sure thing that can be said is that the exhaustion event will occur before the end of this decade.

## IP Address Status in China

**Total IPv4 address (unit 1)**

- Data source: CNNIC, Dec.2003

**“****IPv6 is good for China and China is good for IPv6. China brings the scale needed for IPv6. IPv6 killer application will occur in China firstly"  - Latif Ladid--IPv6 Forum President**** **

- IPv6 is
- the Only
- Solution

## Key Technology Enablers

- Zero Configuration in rapidly deployed and mobile networks
- DNS, DHCP and KEY Servers

- PKI, IKE and Key and Policy Management and Applications

- © 2004 Syzygy Engineering  – Will Ivancic

## Peer-to-Peer Networking

- Voice, Video and Data
- Issues:
- Security (particularly in DoD and Corporate Networks)
- Control
- End-to-End relative to Peer-to-Peer
- End-to-End allows direct communication once peer’s address is known
- Typical IPv4 with NAT requires Peer-to-Peer server and may require application software (IM, KAZA, etc)

- Firewall and
- router w/NAT

- Firewall and
- router w/NAT

- Internet

- Peer-to-Peer
- Service
- (IM, KaZa, etc)

- Typical IPv4
- Peer-to-Peer
- Communications

- Firewall and
- router
- No NAT

- Internet

- Peer-to-Peer
- Service
- (IM, KaZa, etc)

- Firewall and
- router
- No NAT

**Client/Server Model **
**Peer-to-Peer Communication**

- 1

- 3

**Peer-to-Peer Server is not required**

- 2

- © 2004 Syzygy Engineering  – Will Ivancic

**Notes:**
P2P service really acts like a localized dynamic DNS.

P2P application software has FQDN of P2P server.

NATs require dynamic DNS 

P2P in Client/Server can be always via the server or once the address is known, direct P2P.  However, NATs make 

To get around NATs and Firewalls and Proxies, P2P applications will embed one protocol/application within another (FTP inside HTTP).  Basically application encapsulation.

## Flow Label

- Used by host to request special handling for certain packets
- Unique flow is identified by source address and non-zero flow label
- Expected use is per-flow end-to-end QoS
- RSVP, Video, Gaming, VOIP
- Without the flow label the classifier must use transport next header value and port numbers
- Less efficient (need to parse the option headers)
- May be impossible (due to fragmentation or IPsec ESP)
- Layer violation may hinder introduction of new transport protocols
- IPv6 nodes not providing flow-specific treatment MUST ignore the field when receiving or forwarding a packet
- Immature Technology – Research Area

- © 2004 Syzygy Engineering  – Will Ivancic

- The Flow Label field is useless, unless it is actually used!

## Flow LabelSecurity Considerations 

- The IPsec protocol, as defined in [IPSec, AH, ESP], does not include the IPv6 header's Flow Label in any of its cryptographic calculations
- In the case of tunnel mode, it is the outer IPv6 header's Flow Label that is not included
- Modification of the Flow Label by a network node has no effect on IPsec end-to-end security
- It cannot cause any IPsec integrity check to fail.
- As a consequence, IPsec does not provide any defense against an adversary's modification of the Flow Label (i.e., a man-in-the-middle attack).** **

- © 2004 Syzygy Engineering  – Will Ivancic

## How mature is IPv6?

## Maturity

- IPv6 Forum has created the “IPv6 Ready” Logo Program
- Phase I (Core)
- Phase II
- IPv6 Core Protocols (Now Available!)
- IPsec (Now Available!)
- MIPv6 (Now Available!)
- NEMO (Now Available!)
- MLD (Under Developing)
- Transition (Under Developing)
- IKE (Experimental)
- China Olympics
- China made a comprehensive national commitment to IPv6 way back in 2000
- "The Chinese are trying to build the number-one rated information infrastructure in the world, and want to announce in 2008 - at the time of the Beijing Olympics - that they are thus an economic superpower,"
- Cisco router in Low Earth Orbit (CLEO)

## IPv6

**IPv4 Mobile LAN**

**IPv6**
**Mobile **
**Router**

**Corresponding**
**Public Node**

**IPv6**
**Home**
**Agent**

**Monitoring**
**Points**

**IPv6**
**Network**

**Glenn Research **
**Center**

**GRC Open Network  (DMZ)**

**Globalstar**

**T-Mobile**

**IPv6 Mobile LAN**

**IPv4**
**Public**
**Internet**

**CNS**
**IPv6**
**Intranet**

**Eurocontrol**
**IPv6**
**Intranet**

- Z

- Z

**IPv6 Web **
**Server**

**IPv6 Web **
**Server**

**IPv6 Web **
**Server**

- 6-to-4 (DOOR)

- 6-to-4 (DOOR)

- 4-to-6 Tunnel

- 6-to-4
- (DOG)

- 6-to-4
- Tunnel

- 6-to-4
- Tunnel

**Remote**
**Controlled**
**Webcam**

**IPv6 Mobile**
**Networking**
**Demonstration**
**2004**

## The Cisco router in low Earth orbit (CLEO)

- Put a COTS Cisco router in space
- Determine if the router could withstand the effects of launch and radiation in a low Earth orbit and still operate in the way that its terrestrial counterparts did.
- Ensure that the router was routing properly
- Implement mobile network and demonstrate its usefulness for space-based applications.
- Since the UK–DMC is an operational system, a major constraint placed on the network design was that any network changes could not impact the current operational network

## CLEO

- Thursday, 29 March 2007, NASA Glenn Research Center, Cisco Systems and Surrey Satellite Technology Ltd (SSTL) performed the first configuration and demonstration of IPsec and IPv6 on a satellite in low Earth orbit.
- Applications / Functions
- Static IPv6 and IPv4 routing
- IPv6 over IPv4 mobile routing
- IPv6 over IPsec for IPv4
- IPv6 Applications
- Secure Shell, Telnet and Web browsing to the router.

## GRC/SSTL/CLEO IPv6/IPv4 Tunnels

**Cisco MAR**
**3251 on **
**UK-DMC**

- Internet

- native IPv6 between routers

- native IPv4

- frame relay DLCI 17 – unencrypted ‘clear’ link

- frame relay DLCI 18 – encrypted link

- 8.1Mbps from satellite

- 9600bps to satellite

- SSTL ground station LAN,
- carrying IPv4 and IPv6 over Ethernet

- 2621
- router

- PIX
- firewall

- IPv4 IPsec encryption between routers

- IPv4

- secured IPv6 in 6-over-4 tunnel over IPv4 IPsec

- IPv6 in 6-over-4 tunnel in Mobile IPv4 tunnel to Home Agent

- 6-over-4 tunnel for non-mobile IP traffic

- Secure VPN tunnel

- NASA
- Glenn
-  Home
- Agent

- IPv6 in 6-over-4 tunnel in Mobile IP as above, if IPsec link is preferred and used instead

- Mobile IPv4

- IPv4

- IPv6

- IPv4 IPsec

- Mobile IPv4 tunnel

**Private 192.x addressing**

**Public addressing**

**Private 192.x addressing**

- PIX
- firewall

## IPv6 Live Demonstrations

## Issues

- Site Multihoming
- Poorly written applications
- Written without consideration for IPv6
- Legacy Systems
- Dual Stack and Security

## What are the advantages for military networks?

## IPv6 Addressing Architecture

- The IPv6 addressing architecture utilizes scoped addresses, including scoped multicast addresses.
- Example: IPv6 has all-routers addresses in every subnet, which allow a node to find or communicate with routers without knowing their unicast addresses ahead of time.
- IP address resolution
- IPv4 uses the ARP and IPv6 uses Neighbor Discover (ND)
- ARP operates directly on top of the link layer
- ND operates using ICMPv6, on top of IPv6, on top of the link layer.
- IPv6’s ND is highly extensible through IP and ICMPv6 options which can be used for:
- Security (authentication of network elements and resolution protocol messages),
- Automatic prefix and interface identifier configuration
- Advertisement of link MTU.

## Routing

**  ****IPv6 Dynamic Routing works.**
**  ****IPv4 Dynamic routing DOES NOT?**

## Applications

- Sensorwebs
- Mobile Ad Hoc Networks (MANETs)

## Sensors

- IPv6 Myths
- Headers are too big
- Stateless header compression
- Code size
- IP stacks available in 3-6K range
- Initial indications are MAC, AODV and IP stack under 20K
- RAM
- 1.5 to 2K are current estimates
- Why IPv6
- Common Infrastructure
- Hybrid networks
- Larger address space
- No need for configuration servers
- No DHCP server
- No need for NAT
- Header more easily compressed
- Stateless Header Compression
- Header can be compressed to just 4 bytes on-net and 12 bytes off-net
- Assumes network will not be a transit network

- Source: Geoff Mulligan, Invensys Controls

**6LowPan Hardware**

## Global Information Grid

**UNCLASSIFIED**

**UNCLASSIFIED**

## The “Tactical Internet”

***“******OPEN SYSTEMS”***
***ROUTING***

***ROUTERS***

***Tactical***
***Internet***

**Dismounted**
**Soldiers**

***OPEN***
***INTERFACES***

***OPEN***
***INTERFACES***

**Radio**
**Net**

**Radio  Net**

**Military & Commercial **
**SATCOM**

**Radio**
**Net**

**Radio**
**Net**

**Radio**
**Net**

**Radio**
**Net**

**Self Forming, ****Self Healing,**
**Efficient**

**TOCs**

**UNCLASSIFIED**

**UNCLASSIFIED**

## Relationships between the DoD NICs, RIRs and IANA 

- The MIL NIC has, to date, acquired four IPv6 address blocks from ARIN.
- 2600:: /22, 2604:: /22, 2608:: /22, and 260C:: /22
- 4 /22 prefixes are not contiguous
- There are 255 /22 prefixes between each allocation.
- No stated policy by ARIN, but, a reasonable assumption that the unassigned 1020 /22 prefixes within the 260:: /22 prefix would be used for DoD’s future address acquisitions.
- Additional blocks outside of 2600::/12 may be reassigned from ARIN to DoD when this block is fully consumed

- /22

- /22

- /22

- /23

- /23

**UNCLASSIFIED**

**UNCLASSIFIED**

## Enclave Mapping

| Enclave Name | Address Block per Platform |
| --- | --- |
| Black Core | /48 |
| UNCLAS | /48 |
| SECRET | /48 |
| TOP SECRET | /48 |
| SCI | /48 |
| Allied | /48 |
| Coalition #1 | /48 |
| Coalition #2 | /48 |
| Coalition #3 | /48 |
| Coalition #4 | /48 |

**UNCLASSIFIED**

**UNCLASSIFIED**

## What are the advantages for airborne networks?

- This section is taken from a presentation by Terry Davis of Boeing

## V6 QoS & Traffic ManagementArchitecture Example 

**V6 QoS & Traffic Management****Architecture Example**

***v6 systems can join multiple networks***
- Implications:
- Architecture could assign networks for specific uses
- Traffic could be segregated by network
- High QoS can be assigned to “a” network
- Voice on one, video on one, etc.
- Special comm priority networks could be created
- ATC, FANS, ACARS, etc
- Link capacity could be managed by “network priority” not just “packet priority”
- System capability growth could be managed over time
- Older less capable systems assigned to specific networks
- Newer capabilities to other networks

- Source:  Terry L Davis, Boeing

## Network Partitioning by ServiceArchitecture Example

- Network Partitioning by ServiceArchitecture Example

- QoS & Security Service Levels for:
** ****Network Control**
** ****Voice over IP**
** ****High Priority**
** ****Special Projects**
** ****General Purpose**

**NSPs/Airlines/Framers/Suppliers/etc**

**PIES**

**Security Perimeter**

**VOIP**

**AOC**

**Networks are logically partitioned.**
***Many logical networks share a common physical infrastructure.***
**QoS can be managed by both network & flow**

**ATC**

**Network Infra.**

**Net-Mgt**
**& Routing**

**Data Center**

**Security Mgt**

**PIES**

- Source:  Terry L Davis, Boeing

## Security – Architecture Example

- IP-v6 Networks could:
- Require authentication to join
- Have different authentications (ATC/AOC/PIES)
- Have different security levels and encryption
- Utilize Transponder codes
- For authentication
- For encryption keying
- Individual systems with a single interface could:
- Join multiple secure networks simultaneously
- With different security levels (MLS) per network
- With different encryption per network
- With different QoS

- Source:  Terry L Davis, Boeing

## IP-v6 Network Overlay ConceptArchitecture Example

- IP-v6 Network Overlay ConceptArchitecture Example

**Concept:  ****Enable unified communications without impacting existing legacy services**

**US Division**

**Europe Home Office**

**Asian Partner**

- Source:  Terry L Davis, Boeing

## Conceptual v6 Strategic ArchitectureSummary

**Conceptual v6 Strategic Architecture****Summary**

- IP-v6 could provide a seamless NSP control handoffs
- Traffic segregation by network could provide better comm link mgmt and QoS than IP-v4 (+matches Domain model).
- GPS based v6 addressing could potentially allow significant control and data routing improvements.
- Layering of v6 networks could allow segregation of networks with similar capabilities and security levels.
- Security in a v6 architecture could be "network" based.
- “capability/compatibility" layers could allow change/evolution without updates of products, or fleets.

- Source:  Terry L Davis, Boeing

## Conceptual v6 Aviation Strategy

**Conceptual v6 Aviation Strategy**

**Full conversion is evolutionary over more than 25 years**
- Platforms will requires IP-v6 interoperability before end-of-life
- Specific customers will require support for v6
***Timeline to implement is in years from the first start***
- Leverage aviation assets and expertise globally
- Grow the base of v6 compatible equipment
- Grow the base of v6 staff skills through industry sponsored training
- Conversions are based on requirements or business case
**Regulatory changes will be needed to both allow and support IP-v6**

- Source:  Terry L Davis, Boeing

## References / Useful Links

*Wesley Eddy, William Ivancic, Joseph Ishac: “Analysis of IPv6 Features and Usability” Version 1.0 9/6/06*
- _[http://www.nav6tf.org/documents/nav6tf.analysis_ipv6_features_and_usability.pdf](http://www.nav6tf.org/documents/nav6tf.analysis_ipv6_features_and_usability.pdf)_
*IPv6_Transition_Plan_v1_0_3-24-05*
- _[https://disronline.disa.mil/a/DISR/docs/secure/DoD-IPv6_Transition_Plan_v1_0_3-24-05_update1.pdf](https://disronline.disa.mil/a/DISR/docs/secure/DoD-IPv6_Transition_Plan_v1_0_3-24-05_update1.pdf)_
*DoD_IPv6_Transition_Plan_v2_Final*
- _[https://disronline.disa.mil/a/DISR/docs/secure/DoD_IPv6_Transition_Plan_v2_Final.pdf](https://disronline.disa.mil/a/DISR/docs/secure/DoD_IPv6_Transition_Plan_v2_Final.pdf)_
*IPv6 Ready Logo Phase-1*
- _[http://www.ipv6ready.org/logo_db/approved_list.php](http://www.ipv6ready.org/logo_db/approved_list.php)_
*The Latest Approved Application List of Phase-2*
- _[http://www.ipv6ready.org/logo_db/approved_list_p2.php](http://www.ipv6ready.org/logo_db/approved_list_p2.php)_
*Geoff Mulligan, “IP and 802.15.4 – To V6 or not to V6” (IPv6 for Sensors)*
- _[http://roland.grc.nasa.gov/~ivancic/hidden/shared/v6%20Seminar.ppt](http://roland.grc.nasa.gov/~ivancic/hidden/shared/v6 Seminar.ppt)_