# Presentation: 664590

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

**Will Ivancic****SYZYGY 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

## 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

## 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 a****n ****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].

## Hierarchical Addressing & Aggregation

**Larger address space enables (demands):**
**Aggregation of prefixes announced in the global routing table.   **
**  ****Helps improve routing speed.**
**  ****Efficient and scalable routing.**

**2001:0410:0002:/48**

**2001:0410:0001:/48**

**Only announces the /32 prefix**

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

**Notes:**
While we have a much larger address space, we have the potential for a much smaller routing table.
Hierarchical addressing and aggregation. It's not directly on the
slides, but maybe you'll actually talk about this: the aggregability (is
that a real word?) of IPv6 really comes from us starting with a fresh
sheet and fresh allocation guidelines, and doesn't have much to do with
the protocol. Except that now we've got more addresses we'd better be
really serious about doing aggregation.

## Site Multihoming

**Site Multihoming**

**ISP - C is not allowed to advertise ISP - A’s routes**

**Only announces the /32 prefix**

- Syzygy Engineering

**2001:A010:0001:/48**

**2001:B010:0001:/48**

**2001:C010:0001:/48**

## Policy Proposal 2005-1: Provider-independent IPv6 Assignments for End Sites

**6.5.8. Direct assignments from ARIN to end-user organizations**
**6.5.8.1. Criteria**
**To qualify for a direct assignment, an organization must: not be an IPv6 LIR; and **
**qualify for an IPv4 assignment or allocation from ARIN under the IPv4 policy currently in effect. **
**6.5.8.2. Initial assignment size**
**Organizations that meet the direct assignment criteria are eligible to receive a direct assignment. The minimum size of the assignment is /48. Organizations requesting a larger assignment must provide documentation justifying the need for additional subnets.**
**These assignments shall be made from a distinctly identified prefix and shall be made with a reservation for growth of at least a /44.**
**6.5.8.3. Subsequent assignment size**
**Additional assignments may be made when the need for additional subnets is justified. When possible, assignments will be made from an adjacent address block. **

## Restoring an End-to-End Architecture

**Restoring an End-to-End Architecture**

**End-to-End Connectivity Restores the “Promise”****of Multimedia Collaboration**

**NAT/PAT Breaks Peer-to-Peer**

**Elimination of NAT Bottleneck**
**Restores End-to-End**

**Peer-to-Peer Applications need****Global Addresses when You****Connect to:**
**IP Telephony**
**Enterprise, Mobile and Residential**
**IP Video Conferencing**
**Enhanced Instant Messaging**
**Distributed Gaming**

**IPv4**
**Internet**

**IPv6**
**Internet**

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

**Notes:**
To account for the disparity in available IPv4 routable addresses and the actual number of users of that address space, address translation was born.
PAT is the killer of new and existing collaborative applications.
Tactics such as static translations, proxies and tunneling have led to poor performance, security issues and nightmare management requirements.
Eliminating the need for translation due to non-routable address constraints allows for new and enhanced applications to be deployed.  
If I allow multimedia collaboration, which includes voice, video and app sharing, I have all but demanded a requirement for additional BW (GTTD, Gig-eChannel, 10-gigE), QoS, faster network devices (switches, routers, FWs, etc...). 

## Transition and Operations Costs

- Cost Difference
- Between IPv4 / IPv6
- Operations

- <footer>Source: PC of Japan

- Transition Cost

## 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

## IPv6 Transition Plan

**Unclassified, For Official Use Only**
- _[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)_

- Contents
- Overall Transition Strategy
- IPv6 Transition Governance
- Acquisition and Procurement of IPv6 Capabilities
- Networking and Infrastructure
- Addressing
- Information Assurance
- Pilots, Testing and Demonstrations
- Applications
- Standards
- Training

## IPv6 Transition Plan

- _[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)_

## Potential Showstoppers to Fully IP-based Tactical Operations Today

- 	Further research in the following areas is required in order to enhance the IPv6 protocol suite to support Network Enabled Command:
- Embedding/ Encapsulation of legacy systems by means of interoperable gateways
- Potential of Anycast Addressing to foster SOA,
- Service Discovery protocols such as IPSec Discovery need standardization;
- Global IP Security Architecture needs to encompass both deployable and highly dynamic domains supporting all kinds of host and network mobility,
- Scalable Tactical PKI, e.g. CA and distributed Sub-CAs;
- Optimization of MANET routing mechanisms,
- Need to find a compromise between low routing overhead of reactive routing and instant route availability of proactive routing,
- True multicast routing in the mobile domain;
- QoS that considers the heterogeneous (e.g. in terms of bandwidth and latency) and dynamic availability of communication links,
- Work on standardized service interoperability profiles;
- IPv6 (multicast) enabled applications.

## v4/v6 Co-Existence Strategy?

- Source: Sinead O’Donovan,Product Unit Manager Windows Networking  Microsoft

## Key Technology Enablers

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

**PKI, IKE and Key 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.

## New “IPv6 Capable” Definition – 

- A product must meet the IPv6 base requirements (defined in “DoD IPv6 Standard Profiles for IPv6 Capable Products”) and support requirements  for one (or more) product categories.
- e.g. Workstations, routers, switches, security devices, firewalls, etc...
- And support the IPv6 version of any IPv6 protocol functional categories required for its function within the DoD Global Information Grid (GIG)
- Official Site
- (May require Certificate or Common Access Card to obtain access
- _[http://jitc.fhu.disa.mil/adv_ip/register/register.html](http://jitc.fhu.disa.mil/adv_ip/register/register.html)_
- Otherwise try
- _[http://jitc.fhu.disa.mil/adv_ip/register/docs/disr_ipv6_product_profile_draft.pdf](http://jitc.fhu.disa.mil/adv_ip/register/docs/disr_ipv6_product_profile_draft.pdf)_

## What is Mobility?

**Transportable**
**Telecommuter**
**Traveler**
**Relatively static once connected**
**Single point of connection**
**Connectivity**
**IPv6 Autoconfiguration**
**VPN**

**Mobile**
**Mobile Devices**
**PDAs**
**Cell Phones**
**Mobile Networks**
**Trains**
**Planes**
**Automobiles**
**Connectivity**
**Mobile-IP**
**Networks in Motion (NEMO)**
**Ad Hoc Networks**

- © 2004 Syzygy Engineering  – Will Ivancic

## Mobile Networking Solutions

**Routing Protocols**
****** ****Route Optimization**
****** ****Convergence Time**
****** ****Sharing Infrastructure – who owns the network?**
**Mobile-IP **
****** ****Route Optimization**
****** ****Convergence Time**
****** ****Sharing Infrastructure**
****** ****Security – Relatively Easy to Secure**
**Domain Name Servers**
****** ****Route Optimization**
****** ****Convergence Time**
****** ****Reliability**

- Source  – Will Ivancic

## Mobility at What Layer?

**Layer-2 (Radio Link)**
**Fast and Efficient**
**Proven Technology *****within the same infrastructure***
**Cellular Technology Handoffs **
**WiFi handoffs**
**Layer-3 (Network Layer)**
**Slower Handover between varying networks**
**Layer-3 IP address provides identity**
**Security Issues**
**Need to maintain address**
**Layer-4 (Transport Layer)**
**Research Area**
**Identity not tied to layer-3 IP address**
**Proposed Solutions**
**HIP – Host Identity Protocol**
**SCTP – Stream Control Transport Protocol**

- © 2004 Syzygy Engineering  – Will Ivancic

## Location Identifier

**Location Identifier**

**Internet**

- © 2004 Syzygy Engineering  – Will Ivancic

## Securing Networks 

**Constraints/Tools**
**Policy**
**Security Policy**
**Education**
**Enforcement**
**Architecture **
**Protocols**
**Must be done up front to be done well**

- © 2004 Syzygy Engineering  – Will Ivancic

## Security

**Security ********    Bandwidth Utilization ******
**Security ********    Performance ******
**Tunnels Tunnels Tunnels and more Tunnels**
**Performance ********   Security ******
****** ****User turns OFF Security to make system usable!**
**Thus, we need more bandwidth to ensure security.**

- Source  – Will Ivancic

## Realities of ROI and Security

- Network Security itself does not provide any type of ROI – it is about cost management
- Example – You buy a Picasso straight from the artist and a safe to store it in. The safe adds no value to the painting – only helps prevent its loss (i.e. a cost to you)
- An organization that fails to adequately prepare a robust security solution faces potential loss from:
- Lost productivity/Lost e-commerce revenue
- Regulatory penalties
- Tort litigation
- Long-term business loss from lost customer confidence

- Source  – Yurie Rich  CommandInformation

## IPsec

**IPsec**

**	****In non-static environments such as mobile and ad hoc networks, your address no longer identifies you!**

- Source  – Merike Kaeo  merike@doubleshotsecurity.com

## GIG - Black Core

## GIG - Striped Core

## 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