1. IPv6 & Multicast

2. Acknowledgement Figures and texts are from:
Steve Deering(Oct talk)
Peterson & Davie
McKeown(Stanford)

3. IPv6

4. IP Scaling Problems — the View from Late 1991
running out of Class B addresses (near-term)
solution:CIDR (Classless Interdomain Routing) to allow addresses to be allocated and routed as blocks of any power-of-two size, not just Class A, B, and C
running out of routing table space (near-term)
solution:provider-based delegation of address blocks, i.e., address hierarchy changed from organization:subnet:host to provider:subscriber:subnet:host

5. IP Scaling Problems — the View from Late 1991
running out of all IP addresses (long-term)
solution: a new version of IP with bigger addresses, dubbed IP Next Generation, of IPng
note: this was before the Web!

6. What’s Been Happening Since Mid 1994?
writing protocol specs, arguing about every detail, and progressing through the IETF Standards process
scores of documents, on IPv6 address formats and routing protocols (unicast & multicast), L2 encapsulations, auto-configuration, DNS changes, header compression, security extensions, IPv4/IPv6 co-existence & transition, MIBS,… (see playground.sun.com/ipv6 for list of documents)

7. What’s Been Happening Since Mid 1994?
implementation by vendors, and interoperability testing
building deployment testbeds
shipping products
deploying production services

8. Why IPv6? (Theoretical Reasons)
only compelling reason: more IP addresses!
for billions of new users (Japan, China, India,…)
for billions of new devices (mobile phones, cars, appliances,…)
for always-on access (cable, xDSL, ethernet-to-the-home,…)
for applications that are difficult, expensive, or impossible to operate through NATs (IP telephony, peer-to-peer gaming, home servers,…)
to phase out NATs to improve the robustness, security, performance, and manageability of the Internet

9. IPv6 Header compared to IPv4 Header
Ver.
Traffic
Class
Hdr
Len
Identification
Fragment
Offset
Flg
Header
Checksum
Options...
shaded fields have no equivalent in the
other version
IPv6 header is twice as long (40 bytes) as
IPv4 header without options (20 bytes)
Flow Label
Flow Label
Ver.
Hdr
Len
Type of
Service
Total Length
Payload Length
Next
Header
Hop
Limit
Identification
Flg
Fragment
Offset
Source Address
Time to
Live
Protocol
Header
Checksum
Source Address
Destination Address
Options...
Destination Address

10. 3 m n o p 125 – m – n – o – p 010 RegistryID ProviderID SubscriberID
SubnetID
InterfaceID
Chapter 4, Figure 32

11. IP Address Allocation History
IPv4 protocol published
1985 ~ 1/16 of total space
1990 ~ 1/8 of total space
1995 ~ 1/4 of total space
2000 ~ 1/2 of total space
this despite increasingly intense conservation efforts
PPP / DHCP address sharing
CIDR (classless inter-domain routing)
NAT (network address translation)
plus some address reclamation

12. IP Address Allocation History
theoretical limit of 32-bit space: ~4 billion devices practical limit of 32-bit space: ~250 million devices

13. Other Benefits of IPv6 server-less plug-and-play possible
end-to-end, IP-layer authentication & encryption possible
elimination of “triangle routing” for mobile IP
other minor improvements
NON-benefits:
quality of service (same QoS capabilities as IPv4)
flow label field in IPv6 header may enable more efficient flow classification by routers, but does not add any new capability
routing (same routing protocols as IPv4)
except larger address allows more levels of hierarchy
except customer multihoming is defeating hierarchy

14. Why IPv6? (Current Business Reasons)
demand from particular regions
Asia, EU
technical, geo-political, and business reasons
demand is now
demand for particular services
cellular wireless (especially 3GPP[2] standards)
Internet gaming (e.g., Sony Playstation 2)

15. Why IPv6? (Current Business Reasons)
potential move to IPv6 by Microsoft?
IPv6 included in Windows XP, but not enabled by default
to be enabled by default in next major release of Windows
use is >= 1.5 years away

16. IPv4-IPv6 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

17. Standards
core IPv6 specifications are IETF Draft Standards => well-tested & stable
IPv6 base spec, ICMPv6, Neighbor Discovery, PMTU Discovery, IPv6-over-Ethernet, IPv6-over-PPP,...
other important specs are further behind on the standards track, but in good shape
mobile IPv6, header compression,...
for up-to-date status: playground.sun.com/ipv6
3GPP UMTS Release 5 cellular wireless standards mandate IPv6; also being considered by 3GPP2

18. Implementations
most IP stack vendors have an implementation at some stage of completeness
some are shipping supported product today, e.g., 3Com, *BSD(KAME), Cisco, Compaq, Epilogue, Ericsson/Telebit, IBM, Hitachi, Nortel, Sun, Trumpet, …
others have beta releases now, supported products “soon”, e.g., HP, Juniper, Linux community, Microsoft, …
others rumored to be implementing, but status unkown (to me), e.g., Apple, Bull, Mentat, Novell, SGI, …
(see playground.sun.com/ipv6 for most recent status reports)
good attendance at frequent testing events

19. Deployment experimental infrastructure: the 6bone
for testing and debugging IPv6 protocols and operations (see
production infrastructure in support of education and research: the 6ren
CAIRN, Canarie, CERNET, Chunahwa Telecom, Dante, ESnet, Internet 2, IPFNET, NTT, Renater, Singren, Sprint, SURFnet, vBNS, WIDE,… (see
commercial infrastructure
a few ISPs (IIJ, NTT, Telia…) have started or announced commercial IPv6 service

20. Deployment (cont.) IPv6 address allocation
6bone procedure for test address space
regional IP address registries (APNIC, ARIN, RIPE-NCC) for production address space
deployment advocacy (a.k.a. marketing)
IPv6 Forum:

21. Much Still To Do
though IPv6 today has all the functional capability of IPv4,
implementations are not as advanced (e.g., with respect to performance, multicast support, compactness, instrumentation, etc.)
deployment has only just begun
much work to be done moving application, middleware, and management software to IPv6
much training work to be done (application developers, network administrators, sales staff,…)
many of the advanced features of IPv6 still need specification, implementation, and deployment work

22. IPv6 Timeline (A pragmatic projection)Q1 Q2 Q3 Q4
2007
2004
2003
2000
2001
2002
2005
2006
Early adopter
Appl. Porting <= Duration 3+ yrs.
=>
adoption <= Dur. 3+ yrs.
ISP
=>
Consumer adoption <= Dur. 5+ yrs.
=>
Enterprise adopt.
<= 3+ yrs. =>

23. IPv6 Timeline (A pragmatic projection)Q1 Q2 Q3 Q4
2007
2004
2003
2000
2001
2002
2005
2006
Early adopter
Appl. Porting <= Duration 3+ yrs.
=>
adoption <= Dur. 3+ yrs.
ISP
=>
Consumer adoption <= Dur. 5+ yrs.
=>
Enterprise adopt.
<= 3+ yrs. =>
Asia

24. IPv6 Timeline (A pragmatic projection)Q1 Q2 Q3 Q4
2007
2004
2003
2000
2001
2002
2005
2006
Early adopter
Appl. Porting <= Duration 3+ yrs.
=>
adoption <= Dur. 3+ yrs.
ISP
=>
Consumer adoption <= Dur. 5+ yrs.
=>
Enterprise adopt.
<= 3+ yrs. =>
Asia
Europe

25. IPv6 Timeline (A pragmatic projection)Q1 Q2 Q3 Q4
2007
2004
2003
2000
2001
2002
2005
2006
Early adopter
Appl. Porting <= Duration 3+ yrs.
=>
adoption <= Dur. 3+ yrs.
ISP
=>
Consumer adoption <= Dur. 5+ yrs.
=>
Enterprise adopt.
<= 3+ yrs. =>
Asia
Europe
Americas

26. Recent IPv6 “Hot Topics” in the IETF
multihoming
address selection
address allocation
DNS discovery
3GPP usage of IPv6
anycast addressing
scoped address architecture
flow-label semantics
API issues
(flow label, traffic class, PMTU discovery, scoping,…)
enhanced router-to-host info
site renumbering procedures
inter-domain multicast routing
address propagation and AAA issues of different access scenarios
end-to-end security vs. firewalls
and, of course, transition / co-existence / interoperability with IPv4 (a bewildering array of transition tools and techniques)
Note: this indicates vitality, not incompleteness, of IPv6!

27. Conclusion(IPv6)
if I knew it was going to take so long, I would have let one of the other IPng candidates “win”!
one shouldn’t expect it to have taken less time, given the nature of the undertaking
the IETF was unusually far-sighted (lucky?) in starting this work when it did, instead of waiting till the Internet falls apart
the Internet is now falling apart
IPv6 is ready to put it back together again

28. Multicast

29. Outline(Multicast) Applications that need multicast.
Trees, addressing and forwarding.
Multicast routing
Link-state
Distance Vector (DVMRP)
Protocol Independent Multicast (PIM)
Some interesting problems…

30. Multicast Routing Applications that need multicast.
Trees, addressing and forwarding.
Multicast routing
Distance Vector (DVMRP)
Protocol Independent Multicast (PIM)
Some interesting questions…

31. Applications that need multicast
One way, single sender: “one-to-many” TV
Non-interactive learning
Database update
Information dispersal (e.g. Pointcast)
Two way, interactive, multiple sender: “many-to-many”
Teleconference
Interactive learning

32. Trees, addressing and forwarding

33. Multicast Trees

34. Multicast Routing
A multicast tree is a spanning tree with the sender at the root, spanning all the members of the group.

35. Multicast Trees e.g. a teleconference
Sender/Speaker
Multicast Group (S1,G) S1
Class D S1 R

36. Multicast Trees and Addressing
All members of the group share the same “Class D” Group Address.
An end station may be the member of multiple groups.
An end-station “joins” a multicast group by (periodically) telling its nearest router that it wishes to join (uses IGMP – Internet Group Management Protocol).
Routers maintain “soft-state” indicating which end-stations have subscribed to which groups.

37. Multicast Trees e.g. a teleconference
Class D S2 R S2
Sender/Speaker
Multicast Group (S2,G)

38. Multicast Forwarding is Sender-specific
Group
Address
Src
Address
Src
Interface
Dst
Interface G S1 1
2,3 S2 2
1,3 R 2 S1 G 1 3 1 S2 G 2 3

39. Outline Applications that need multicast.
Trees, addressing and forwarding.
Some interesting problems…

40. Distance Vector (DVMRP) Protocol Independent Multicast (PIM)
Multicast routing
Distance Vector (DVMRP) Protocol Independent Multicast (PIM)

41. Distance-vector Multicast RPB: Reverse-Path Broadcast
Uses existing unicast shortest path routing table.
If packet arrived through interface that is the shortest path to the packet’s SA, then forward packet to all interfaces.
Else drop packet.

42. Distance-vector Multicast RPB: Reverse-Path Broadcast
Sender/Speaker
Multicast Group (S1,G)
Address
Port
Unicast
DV Routing
Table S1 S1 1 1 3
LAN 2
Shortest Path to Source
Q: Is it shortest path from source?

43. Distance-vector Multicast RPB: Reverse-Path Broadcast
Sender/Speaker
Multicast Group (S1,G) S1
Designated Parent Router:
One parent router picked per LAN (one “closest” to source).
LAN

44. Distance-vector Multicast RPM: Reverse-Path Multicast
RPM = RPB + Prune
RPB used when a source starts to send to a new group address.
Routers that are not interested in a group send prune messages up the tree towards source.
Prunes sent implicitly by not indicating interest in a group.
DVMRP works this way.

45. Protocol Independent Multicast
PIM-DM (Dense Mode) uses RPM.
PIM-SM (Sparse Mode) designed to be more efficient that DVMRP.
Routers explicitly join multicast tree by sending unicast Join and Prune messages.
Routers join a multicast tree via a RP (rendezvous point) for each group.
Several RPs per domain (picked in a complex way).
Provides either:
Shared tree for all senders (default).
Source-specific tree.

46. PIM-SM Unicast to R3: (S,G) Unicast to RP: (*, G) RP
Source knows to send all G packets to RP.
Source “tunnels” mcast-in-ucast packets to RP.
RP unwraps mcast pkt and forwards to local tree.
Unicast to RP: (*, G)
RP knows R1 has joined
R2 learns to send (*,G)
packets to R1 RP R2 S
IGMP Join R1
Sender/Source

47. PIM-SM Optional Source-specific join to bypass RP router:
Routers along the way learn new path for (S,G). RP R2 S R1
Sender/Source

48. Multicast: Interesting Questions
How to make multicast reliable?
How to implement flow-control?
How to support/provide different rates for different end users?
How to secure a multicast conversation?
Will multicast become widespread?