IPv6 … making progress - Texas IPv6 Task Force | IPv6 only, …€¦ · · 2015-11-221 2 3 4 5 6 7 8 RIR pool exhaust dates (zoomed) apnic ripencc arin ... –Identifying IPv4

Copyright 2012 - Hain Global Consulting, Inc. Copyright 2012 - Hain Global Consulting, Inc.

Tony Hain CEO

Hain Global Consulting, Inc.

[email protected]

IPv6 … making progress

2012 Txv6tf

Copyright 2012 - Hain Global Consulting, Inc.

Agenda

• Where are you?

• Management buy-in

• Processes

• Milestones

• Human factors

• Tools

• Security

• Measuring progress

• Wrap up


Mental & Emotional preparation

For many, IPv4 knowledge is their justification of value in the market. As demand for that knowledge withers, and demand for the unfamiliar grows, people progress through the stages of grief in a futile attempt to avoid the inevitable.

IPv4 to IPv6 transition and the stages of grief

Denial

Anger

Negotiation

Depression

Acceptance


What does your organization value?

Heroic Rescue Safety of the pack

Independent Thinking & Strategic Avoidance


Projecting RIR IPv4 pool depletion

• IANA exhausted the central pool Feb. 3, 2011

• APnic activated their ‘final /8 policy’ April 15, 2011

• RIPE activated their ‘final /8 policy’ Sept. 14, 2012

• ARIN slowed for awhile but has been picking up lately.

0

2

4

6

8

10

12

14

16

18

20

RIR pool exhaust dates

apnic ripencc

arin

lacnic

afrinic

0

1

2

3

4

5

6

7

8

RIR pool exhaust dates (zoomed)

apnic ripencc arin

lacnic

afrinic


Collective RIR IPv6 Allocations

0.001

0.01

0.1

1

10

100

Tho

usa

nd

s

RIR -- IPv6 /32 equiv. per year

Afrinic

Apnic

ARIN

Lacnic

RIPE

0.001

0.01

0.1

1

10

100

1000

Mill

ion

s

RIR -- IPv6 avg. /48 equiv. per allocation event

Afrinic

Apnic

ARIN

Lacnic

RIPE

0

1

2

3

4

5

6

7

Tho

usa

nd

s

RIR - IPv6 allocation events

Afrinic

Apnic

ARIN

Lacnic

RIPE

0

10

20

30

40

50

60

70

80

Tho

usa

nd

s

RIR -- IPv6 /32 equivalent allocations

Afrinic

Apnic

ARIN

Lacnic

RIPE


Google measured traffic • http://www.google.com/intl/en/ipv6/statistics.html#


Management buy-in

• Driving from the top or bottom?

• Making the case about business continuity requires recognizing the global shift in client platform to mobile devices.

• Engineering needs to be aware that the IPv4 routing table will explode as fragments of legacy allocations are sold off and routed as independent blocks.


Avoiding failure

• Get started !

The only way to fail is ... do nothing.

Study and preparation are necessary to a point, but delay from excessive planning has the same impact as delay due to remaining in denial that action is required.


Processes

• Assessment of the current network. – Technical capability of equipment – Design and operational assumptions ::: ask why

• Assessment of the evolved network

– Shifts in client platform & UI – Enable first, optimize later

• Find the business driver

– IPv6 deployment is about business continuity – Drive vendors & service providers to align with your business schedule

• Use transition mechanisms to minimize costs

– Tunnel over older gear until it reaches end-of-life

• Configure some systems as IPv6-only

– Identifying IPv4 dependencies may not be trivial


Milestones

• Lab – Start simple, gain experience

• Engineering & support desktops

– Daily use for familiarity

• Business case 1st step

– Frequently externally facing web – Self-contained application like network management

• Plan to move one business application at a time

– Enable support systems; then servers; then DNS – Expect a 3 - 5 year deployment timeframe


Human factors

• Memorizing and typing addresses will fail – DNS is more critical than in IPv4 – Use of [ ] around address required sometimes but not others

• Hex factoring is difficult for many

– Stick to nibble boundaries when possible

• Consistent subnet size

– /64 is not required, but simplicity should be the rule

• Screen real-estate is consumed faster

– Multiple addresses in addition to longer

• Multiple addresses per interface is different – This will just take time to get used to


Tools

• Network management software – Traffic analysis : don’t miscount tunneled traffic

• Firewall placement and rules – Protecting hosts vs. protecting data in a central store

• Spam mitigation tools – Open source tools often have incomplete IPv6 support

• NTP peer set – Caution:: asymmetric tunnel paths will cause ntp offset – OWPING http://www.internet2.edu/performance/owamp/index.html

• Pentest

– http://nmap.org (rather pathetic & manual IPv6 function)

– http://www.thc.org/thc-ipv6/

• WWW

– Google Analytics http://labs.apnic.net/tracker.shtml

• DNS

– RIPEstat https://labs.ripe.net/Members/becha/ripestat-dns-widget-for-world-ipv6-launch


Transition goals

• Decouple deployment dependencies – Applications : End system OS : Network topology

• Allow application deployment at a business-needs rather than network-driven pace – Start early: before network needs force the issue

• Minimize complexity – Avoid translation to the other version & back

• Avoid addiction to transition technology

– Long term the traffic should naturally flow away


Tunnels

• Logical overlay The Internet grew as a tunnel over the voice network

• From the application perspective is virtually identical to dual-stack

• Path MTU discovery important due to additional header

• Tunnel asymmetry often worse than IPv4 path

• Controlled vs. automated trade-offs

• Firewalls often overlook/fail encapsulated pkts


Translators

• IP header mangling intermediary

• May need to be application-aware along entire path to also translate addresses embedded in data stream

• Payload length concerns arise due to header length, and fragmentation rule differences

• Daisy-chain (4-6-4, 6-4-6) will lose some context as IP options do not map identically

• Lawful intercept may require per-connection 5-tuple/time logging


L

S

N

IPv6 End System

Private IPv4 End System

Public IPv4 End System

Public IPv6 Internet


Troubleshooting Connectivity Models

Single Stack / Translated Traffic

Dual Stack End System



Dual Stack Traffic

L

S

N

IPv6 End System

Private IPv4 End System

Public IPv4 End System

Dual Stack End System


The effects of multi-layer NAT

Source: Shin Miyakawa , Ph.D. NTT Communications Corporation

Max 10 Connections


Proxies

• Protocol intermediary creating state-independent connections on either side

– Application layer; semantic awareness

– Socks5 layer; arbitrary applications, may pass udp

– TCP layer; ‘appears’ to interlock state

• Payload length may cause reassembly and/or a different number of packets on either side

• If currently used for IPv4 security demarcation, it is a natural continuation, with the ability to do independent IP versions on either side


Trade-offs

• Deployment / placement of any or all is a local need’s-based decision

• May be used in combination

• Application awareness is a primary selection factor

• Fundamental security models require audit-trail. Translators inherently break the audit-trail.


IPv6 Security

• Restoration of audit trail – Removal of designed-in m-i-m attack on the header

• Secure Neighbor discovery RFC 3971

– Prevents rogue devices from becoming a transit point by claiming to be the local router.

• Sparse allocation

– Removes simple adjacent address attack

• Privacy addresses

– Designed to limit client tracking


Reconnaissance / Sparse allocation

• At 100M pings / second (40 Gbps fdx), it takes > 5,800 years to scan the address range for just one subnet.

Worm and virus propagation will fail or will have to find an alternative search path.

So will scanning based network management products …

Interface ID Routing

128 bits

64 bits 64 bits


Traditional Edge Security Design (evolved…)

Internet Internal network

Edge Router

Stateful Firewall

ISP Router

Public servers

• This design can be augmented with IDS, application proxies, and a range of host security controls

• The 3-interface FW design as shown here is in use at thousands of locations worldwide

• Firewall policies are generally permissive outbound and restrictive inbound

• As organizations expand in size the number of “edges” and the ability to clearly identify them becomes more difficult

IPv4 NAT


Where is the perimeter?

• Devices move in, out, and between trust zones

• Simple appliances lack UI to support complex access control

• Applications are generally unaware of topology impediments

• End users expect applications to work from any connection point without significant effort

Independence from Access Technologies

Hotspots

Home

Mobile

Operator

GPRS, 3G, 4G

Broadband ISP

The Ubiquitous Internet

Office

http://www.sonystyle.com/vaio/r505/index.shtml


Perspective

• ‘Security’ is a function of perspective:

– content privacy is a security value to the end user – content inspection is a security value to the network

manager tasked with asset protection

• In most environments the IP layer is not responsible for security, but stability and uniqueness at the IP layer are relied on by many security functions and mechanisms.

• Scanning is a futile effort in IPv6 networks, both for attackers and for network management tools.

• There are native IPv6 alternatives for the perceived beneficial functions of IPv4/NAT that avoid the application failures caused by address translation.

• IPv6 makes some things better, other things worse, and most things are just different, but no more or less secure


Measuring progress

• Focus on business drivers – Traffic will shift naturally as the path allows

– Use DNS resolution as a control point

• A successful IPv6 deployment should be transparent to the end users, so there should not be direct feedback. This means measurements need to be in the background.

• Track: training; equipment, software, & tools upgrades; business applications that have been enabled; and unfulfilled IPv6 queries against services that are not yet enabled.


Bottom line ...

There is no ‘one size fits all’ deployment model for the IPv4 Internet --- Sooooo ...

There is no ‘one size fits all’ transition deployment technology or approach.

Like it or not, multiple approaches will exist in parallel until IPv4 is finally weaned out of the system. This will happen in the core faster than at the edge, just as it has with every other preceding network technology.


Wrap up

• IPv6 deployment is about business continuity ...

• Plan for a 3-5 year deployment timeframe

• Make progress and avoid failure by taking action

• Staff attitude and training will impact progress

• Understand the current and target networks

• Transition technologies are about decoupling dependencies

• Update tools and focus on simplicity

Get started now!


[email protected]

http://hain-global-consulting.com

Documents

IPv6 … making progress - Texas IPv6 Task Force | IPv6 only, …€¦ · · 2015-11-221 2 3 4 5 6 7 8 RIR pool exhaust dates (zoomed) apnic ripencc arin ... –Identifying IPv4