IPv6 & Multicast

IPv6 & Multicast

Acknowledgement

• Figures and texts are from:– Steve Deering(Oct. 2001 talk)– Peterson & Davie– McKeown(Stanford)

IPv6

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

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!

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)

What’s Been Happening Since Mid 1994?

• implementation by vendors, and interoperability testing

• building deployment testbeds

• shipping products

• deploying production services

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

IPv6 Header compared to IPv4 Header

Ver.

Time toLive

Source Address

Total LengthType ofService

HdrLen

Identification FragmentOffsetFlg

Protocol HeaderChecksum

Destination Address

Options...

Ver. TrafficClass

Source Address

Payload Length NextHeader

HopLimit

Destination Address

HdrLen

Identification FragmentOffsetFlg

HeaderChecksum

Options...

shaded fields have no equivalent in theother version

IPv6 header is twice as long (40 bytes) asIPv4 header without options (20 bytes)

Flow LabelFlow Label

Chapter 4, Figure 32

125– m– n– o– pponm3

SubscriberIDProviderIDRegistryID010 InterfaceIDSubnetID

IP Address Allocation History 1981 - 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

IP Address Allocation History

• theoretical limit of 32-bit space: ~4 billion devicespractical limit of 32-bit space: ~250 million devices

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

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)

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

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

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

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

Deployment

• experimental infrastructure: the 6bone– for testing and debugging IPv6 protocols and operations

(see www.6bone.net)

• 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 www.6ren.net, www.6tap.net)

• commercial infrastructure– a few ISPs (IIJ, NTT, Telia…) have started or announced

commercial IPv6 service

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: www.ipv6forum.com

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

IPv6 Timeline(A pragmatic projection)

Q1Q1

Q2Q2

Q3Q3

Q4Q4

20072007Q1Q1

Q2Q2

Q3Q3

Q4Q4

20042004Q1Q1

Q2Q2

Q3Q3

Q4Q4

20032003Q1Q1

Q2Q2

Q3Q3

Q4Q4

20002000Q1Q1

Q2Q2

Q3Q3

Q4Q4

20012001Q1Q1

Q2Q2

Q3Q3

Q4Q4

20022002Q1Q1

Q2Q2

Q3Q3

Q4Q4

20052005Q1Q1

Q2Q2

Q3Q3

Q4Q4

20062006

Consumer adoption <= Dur. 5+ yrs.Consumer adoption <= Dur. 5+ yrs. =>=>

Early adopterEarly adopter

Appl. Porting <= Duration 3+ yrs.Appl. Porting <= Duration 3+ yrs. =>=>

Enterprise adopt.Enterprise adopt.<= 3+ <= 3+ yrs. => yrs. =>

adoption <= Dur. 3+ yrs.adoption <= Dur. 3+ yrs. ISPISP =>=>

Q1Q1

Q2Q2

Q3Q3

Q4Q4

20072007Q1Q1

Q2Q2

Q3Q3

Q4Q4

20042004Q1Q1

Q2Q2

Q3Q3

Q4Q4

20032003Q1Q1

Q2Q2

Q3Q3

Q4Q4

20002000Q1Q1

Q2Q2

Q3Q3

Q4Q4

20012001Q1Q1

Q2Q2

Q3Q3

Q4Q4

20022002Q1Q1

Q2Q2

Q3Q3

Q4Q4

20052005Q1Q1

Q2Q2

Q3Q3

Q4Q4

20062006








AsiaAsia

Q1Q1

Q2Q2

Q3Q3

Q4Q4

20072007Q1Q1

Q2Q2

Q3Q3

Q4Q4

20042004Q1Q1

Q2Q2

Q3Q3

Q4Q4

20032003Q1Q1

Q2Q2

Q3Q3

Q4Q4

20002000Q1Q1

Q2Q2

Q3Q3

Q4Q4

20012001Q1Q1

Q2Q2

Q3Q3

Q4Q4

20022002Q1Q1

Q2Q2

Q3Q3

Q4Q4

20052005Q1Q1

Q2Q2

Q3Q3

Q4Q4

20062006








EuropeEuropeAsiaAsia

Q1Q1

Q2Q2

Q3Q3

Q4Q4

20072007Q1Q1

Q2Q2

Q3Q3

Q4Q4

20042004Q1Q1

Q2Q2

Q3Q3

Q4Q4

20032003Q1Q1

Q2Q2

Q3Q3

Q4Q4

20002000Q1Q1

Q2Q2

Q3Q3

Q4Q4

20012001Q1Q1

Q2Q2

Q3Q3

Q4Q4

20022002Q1Q1

Q2Q2

Q3Q3

Q4Q4

20052005Q1Q1

Q2Q2

Q3Q3

Q4Q4

20062006

AmericasAmericas



EuropeEuropeAsiaAsia




Enterprise adopt.Enterprise adopt.<= 3+ <= 3+ yrs. yrs. => =>


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 / interoperabilitywith IPv4(a bewildering array of transition tools and techniques)

Note: this indicates vitality, not incompleteness, of IPv6!

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

Multicast

Outline(Multicast)

• Applications that need multicast.• Trees, addressing and forwarding.• Multicast routing

– Link-state

– Distance Vector (DVMRP)

– Protocol Independent Multicast (PIM)

• Some interesting problems…

Multicast Routing

• Applications that need multicast.

• Trees, addressing and forwarding.

• Multicast routing– Distance Vector (DVMRP)– Protocol Independent Multicast (PIM)

• Some interesting questions…

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

Trees, addressing and forwarding

Multicast Trees

Multicast Routing

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

Multicast Treese.g. a teleconference

Sender/SpeakerMulticast Group (S1,G) S1

Class D

S1

R

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.

Multicast Treese.g. a teleconference

Sender/SpeakerMulticast Group (S2,G)

S2

Class D

S2

R

Multicast Forwarding isSender-specific

R

G S1

S2

2,31,3

12

GroupAddress

SrcAddress

SrcInterface

DstInterface

S2 G

S1 G 1 2 3

2 1

3

Outline

• Applications that need multicast.

• Trees, addressing and forwarding.

• Some interesting problems…

Multicast routing

Distance Vector (DVMRP)Protocol Independent Multicast

(PIM)

Distance-vector MulticastRPB: 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.



LAN

S1 1

Address PortUnicast

DV RoutingTable

1

23

Shortest Path to Source

Q: Is it shortest path from source?



LAN

Designated Parent Router:

One parent router picked per LAN (one “closest” to source).

Distance-vector MulticastRPM: 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.

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.

PIM-SM

R2

R1

RP

IGMP Join

Unicast to RP: (*, G)• RP knows R1 has joined• R2 learns to send (*,G) packets to R1

Sender/Source

S

Unicast to R3: (S,G)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.

PIM-SM

R2

R1

RP

Sender/Source

S

Optional Source-specific join to

bypass RP router:Routers along the

way learn new path for (S,G).

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?

Documents

IPv6 & Multicast