TrustArc Webinar - Unlock the Power of AI-Driven Data Discovery
Understanding i pv6 2
1. Understanding IPv6
The upsurge in use of the Internet has lead to an increased requirement for IP
numbers,which are rapidly running out. A new standard for IP numbering is
about to be introduced to help overcome some of the limitations of the old
system and to provide enough addresses to see us all well into the next century.
By Shireesh Bhat
3. Packet Size Issues
- Minimum MTU
• definitions:
link MTU a link’s maximum transmission unit,
i.e., the max IP packet size that can
be transmitted over the link
path MTU the minimum MTU of all the links in a
path between a source and a destination
• minimum link MTU for IPv6 is 1280 octets
(versus 68 octets for IPv4)
• on links with MTU < 1280, link-specific
fragmentation and reassembly must be used
4. Packet Size Issues
- Path MTU Discovery
• implementations are expected to perform path
MTU discovery to send packets bigger than 1280
octets:
for each dest., start by assuming MTU of first-hop link
if a packet reaches a link in which it cannot fit, will invoke
ICMP “packet too big” message to source, reporting the link’s
MTU; MTU is cached by source for specific destination
occasionally discard cached MTU to detect possible increase
• minimal implementation can omit path MTU
discovery as long as all packets kept = 1280
octets
e.g., in a boot ROM implementation
5. Security
• all implementations expected to support
authentication and encryption headers (“IPsec”)
• authentication separate from encryption for use
in situations where encryption is prohibited or
prohibitively expensive
• key distribution protocols are under
development (independent of IP v4/v6)
• support for manual key configuration required
6. Security
- Authentication Header
• Destination Address + SPI identifies security
association state (key, lifetime, algorithm, etc.)
• provides authentication and data integrity for
all fields of IPv6 packet that do not change enroute
• default algorithms is (was?) Keyed MD5
7. Quality of Service
- IP Quality of Service Approaches
two basic approaches developed by IETF:
• “Integrated Service” (int-serv)
fine-grain (per-flow), quantitative promises
(e.g., x bits per second), uses RSVP signalling
• “Differentiated Service” (diff-serv)
coarse-grain (per-class), qualitative promises
(e.g., higher priority), no explicit signalling
8. Quality of Service
- IPv6 Support for Int-Serv
20-bit Flow Label field to identify specific flows
needing special QoS
each source chooses its own Flow Label values;
routers use Source Addr + Flow Label to identify
distinct flows
Flow Label value of 0 used when no special QoS
requested (the common case today)
this part of IPv6 is not standardized yet, and may well
change semantics in the future
9. Quality of Service
- IPv6 Support for Diff-Serv
8-bit Traffic Class field to identify specific
classes of packets needing special QoS
same as new definition of IPv4 Type-of-Service
byte
may be initialized by source or by router
enroute; may be rewritten by routers enroute
traffic Class value of 0 used when no special
QoS requested (the common case today)
10. Mobility
• a mobile host has one or more home address(es)
relatively stable; associated with host name in DNS
• when it discovers it is in a foreign subnet (i.e.,
not its home subnet), it acquires a foreign
address
uses auto-configuration to get the address
registers the foreign address with a home agent,
i.e, a router on its home subnet
• packets sent to the mobile’s home address(es)
are intercepted by home agent and forwarded to
the foreign address, using encapsulation
11. IPv6 Transition
- Transition / Co-Existence Techniques
a wide range of techniques have been identified and
implemented, basically falling into three categories:
(1) dual-stack techniques, to allow IPv4 and IPv6 to co-exist
in the same devices and networks
(2) tunneling techniques, to avoid order dependencies
when upgrading hosts, routers, or regions
(3) translation techniques, to allow IPv6-only devices to
communicate with IPv4-only devices
expect all of these to be used, in combination
13. IPv6 Transition
- IPv6 over IPv4 Tunneling
• IPv6 over IPv4 tunneling is the encapsulation of IPv6
packets with an IPv4 header so that IPv6 packets can
be sent over an IPv4 infrastructure. Within the IPv4
header:
• The IPv4 Protocol field is set to 41 to indicate an
encapsulated IPv6 packet.
14. IPv6 Transition
- DNS Infrastructure
• A Domain Name System (DNS) infrastructure is
needed for successful coexistence because of the
prevalent use of names (rather than addresses) to
refer to network resources.
• Upgrading the DNS infrastructure consists of
populating the DNS servers with records to
support IPv6 name-to-address and address-to-
name resolutions.
• After the addresses are obtained using a DNS
name query, the sending node must select which
addresses are used for communication.
15. IPv6 Transition
- DNS Infrastructure
Address Records
The DNS infrastructure must contain the following resource records
(populated either manually or dynamically) for the successful
resolution of domain names to addresses:
∀ • A records for IPv4-only and IPv6/IPv4 nodes
∀ • AAAA records for IPv6-only and IPv6/IPv4 nodes
Pointer Records
The DNS infrastructure must contain the following resource records
(populated either manually or dynamically) for the successful
resolution of address to domain names (reverse queries):
∀ • PTR records in the IN-ADDR.ARPA domain for IPv4-only and
IPv6/IPv4 nodes
∀ • PTR records in the IP6.ARPA domain for IPv6-only and
IPv6/IPv4 nodes (optional).
16. IPv6 Deployment
- Background
• What does it mean to deploy an IPv6 infrastructure? This means
that today end users can begin to use the IPv6 capabilities from
vendors who provide IPv6 within their Internet Protocol stack to
create their own products.
• Users can begin to use IPv6 in conjunction with IPv4 on Local
Area Networks (LANs) within their Intranet enterprise.
• Users can also develop functional IPv6 LANs and can
communicate between those LANs using either native IPv6
forwarding or IPv6 tunneled within IPv4 across their Intranet.
Most common Internet applications can run over IPv6 (e.g.
Telnet, FTP, Web Server/Browser, Mail,DNS) and the common
system administration utilities for IPv6 can be used (e.g. Router
Configuration, Adapter Configuration) so users can begin using
IPv6 on a production basis today.
17. IPv6 Deployment
- T echnical Issues
• IPv6 packets will be tunneled across the IPv4 edge and core using the
base transition mechanism (RFC 2893) at first, which are configured
IPv6 over IPv4 tunnels.These additional mechanisms will permit more
automated procedures for moving packets across the IPv4 edge and
core using tunnels to move IPv6 packets end-2-end between enterprise
organizations and applications.
• This initial IPv6 infrastructure will also be used for markets that will
require IPv6 because of the lack of IPv4 address space and that will
want end-to-end computing. Wireless and Telephony will be one of the
first early adopters of IPv6 for specific parts of their system where the
IPv6 address space permits that business model to evolve (e.g.3GGP,
3GGP2, 802.11 NTT DOCOMO, SS7-to-IP).
• Other government and enterprise markets will use IPv6 to provide end-
to-end transparency (e.g. Military, Internet Cafe’s, Banking Services,
Distributed, Manufacturing) and can begin IPv6 deployment of the
essential infrastructure provided by current vendor products today.
18. Conclusion
• When I started to look into the prospect of presenting a seminar on IPv6 I was
both skeptical and nervous. It seemed to me that the rollout would be far from
problem free. The prospect of attempting to convert an entire company with
many thousands of hosts spread over dozens of sites worldwide, while making
sure that all their Internet providers understood the problems, and were ready
(and willing) to undertake a synchronized changeover seemed to represent an
insurmountable project management task.
• Further study has left me more than a little impressed. It’s obvious with
hindsight that the implementation of a new version of something as ubiquitous
as IP would have to be thought out thoroughly, and would have to include
forward and backward compatibility as part of its fundamental design. This
has been achieved, and I’m much less concerned about the changeover than I
once was. What has impressed me much more, though, is the amount of effort
that has been put into removing many of the bugbears of configuring a
complex IP network. The automatic configuration facilities, both for hosts and
for routers, have been described by some as worth the cost of switching to
IPv6 all on their own.
• I’m also sure that early adopters of IPv6 will experience their own teething
troubles and specially refined version of chaos. Nevertheless, the switch will
have to come, and it might be best to grasp the nettle sooner rather than later.
19. Bibliography
• http://www.ipv6.org
• http://www.ipv6forum.com
• http://ipv6.research.Microsoft.com/
• http://ipv6.bits-pilani.ac.in/
• Documents of Cisco and Sun Micro
Systems
