August 4th, 2004 IETF 60th - San Diego 1

IPv6 multicast address assignment with DHCPv6

draft-jdurand-assign-addr-ipv6-multicast-dhcpv6-00

Jerome.Durand@renater.fr

August 4th, 2004 IETF 60th - San Diego 2

The M6Bone network

August 4th, 2004 IETF 60th - San Diego 3

The M6Bonenetwork

August 4th, 2004 IETF 60th - San Diego 4

The problem• Raised in 6NET (www.6net.org)• How end-users choose an IPv6 multicast address?

– ASM problem – Needed for a session– Session announcement not considered– Should work for all types of multicast addresses (RFC 3306,

Embedded-RP... ) and all scopes (global, site...)

• Mechanism must be– Easy to use– Scalable– Available (implementations)

August 4th, 2004 IETF 60th - San Diego 5

Existing mechanisms• MADCAP (RFC 2970)• SAP (RFC 2974)• Random choice of the address• GLOP (RFC 3180)• ZMAAP – Zeroconf Multicast Address

Allocation Protocol

August 4th, 2004 IETF 60th - San Diego 6

Why considering DHCPv6 ?• DHCPv6 (RFC 3315)

– Will be widely deployed (maybe as DHCP isfor IPv4)

– Flexible (use options)• DHCPv6 makes it possible to assign several

addresses to a host• Was not possible with DHCP• Let’s use this feature for multicast

August 4th, 2004 IETF 60th - San Diego 7

DHCPv6 – New options• No changes to the DHCPv6 protocol !• We propose 2 new options:

– IA_MA optionIA_MA: Identity Association for IPv6 Multicast AddressesIA_TA and IA_NA defined today for unicast addressesEmbeds requests for IPv6 multicast addresses

– Scope optionMakes it possible to request addresses within a specific

scope (site-local, global...)

August 4th, 2004 IETF 60th - San Diego 8

Messages overview

REQUEST

IA_MA1 @1 @2S1 S2

IA_MA2 @3 @4S1 @5

IA_TA1 @1 @2

Client ID Server ID Elapsed time others...

S2

@3

August 4th, 2004 IETF 60th - San Diego 9

IA_MA option0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Option number (to be defined) | option length |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| IAID (Identity Association IDentifier) |

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| |

. options (IPv6 multicast addresses, ...) .

. .+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

August 4th, 2004 IETF 60th - San Diego 10

Scope option0 1 2 3

0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

| Option number (to be defined) | option length (= 1) |+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+| scope | res |

+-+-+-+-+-+-+-+-+

August 4th, 2004 IETF 60th - San Diego 11

Address timers• Use the DHCPv6 IA address option fields :

– Preferred lifetime– Valid lifetime

• Address is assigned as soon as the request is accepted (minDesiredStartTime and MaxDesiredStartTime not used)

• Simplifies the assignment

August 4th, 2004 IETF 60th - San Diego 12

Group-ID for addresses assigned with DHCPv6

• RFC 3307 defines guidelines and group-ID ranges for IPv6 multicast addresses allocations– 0x80000000 – 0xFFFFFFFF for dynamic assignments

• We propose to reserve a specific group-ID range for addresses assigned with DHCPv6– 0x90000000 – 0x9FFFFFFF

• No overlap with other assignment protocols(MADCAP for instance)

August 4th, 2004 IETF 60th - San Diego 13

Scenario 1

2001:660:3001:12::1

2001:660:3001::/48

DHCPv6server RP FF7E:140:2001:660:3001:12::/96

Configured to assign IPv6 multicastaddresses in:

FF7E:140:2001:660:3001:12::/96

Site

August 4th, 2004 IETF 60th - San Diego 14

Scenario 1

DHCPv6server RP

Wants to start a global multicast session – needs

an address

Scope = global (E)...

Site

August 4th, 2004 IETF 60th - San Diego 15

Scenario 1

DHCPv6server RP

Can start transmittingon given address

and announce it toother participants

FF7E:140:2001:660:3001:12::/96

FF7E:140:2001:660:3001:12:92AB:1256

Site

August 4th, 2004 IETF 60th - San Diego 16

Scenario 1.2

2001:660:3001:12::1

2001:660:3001::/48

DHCPv6server RP FF7E:140:2001:660:3001:12::/96

Configured to assign IPv6 multicastaddresses in:

FF7E:140:2001:660:3001:12::/96FF15::/16

FF15::/16 BSR in the siteSite

August 4th, 2004 IETF 60th - San Diego 17

Scenario 1.2

DHCPv6server RP

Wants to start a multicast session in the site – needs

an address

Scope = local (5)...

Site

August 4th, 2004 IETF 60th - San Diego 18

Scenario 1.2

DHCPv6server RP

Can start transmittingon given address

and announce it toother participants

FF15::/16

FF15::92AB:1256

Site

August 4th, 2004 IETF 60th - San Diego 19

Scenario 2

RPISP

small site

August 4th, 2004 IETF 60th - San Diego 20

Scenario 2

2001:660:3001::1RP FF7E:140:2001:660:3001::/80

DHCPv6server

FF7E:140:2001:660:3001:AB15::/96 ISP allocatesmulticast prefixes to

its customers

ISP

RP The site can also deploy its own RP in this scenario. Use of resources depends then from the choice

of the address

August 4th, 2004 IETF 60th - San Diego 21

Scenario 2.2

RP FF18::/16Campus

Lab

August 4th, 2004 IETF 60th - San Diego 22

Scenario 2.2

RP

DHCPv6server

FF18:12B1::/32

FF18::/16

Campus allocates multicast prefixes to labs

Campus

RP The site can also deploy its own RP in this scenario. Use of resources depends then from the choice

of the address

August 4th, 2004 IETF 60th - San Diego 23

Scenario 3

RP

Campus

DHCPv6server

Lab 1Wants to start a global multicast session – needs

an address

Configured to assign IPv6 multicast addresses in:

FF7E:140:2001:660:3001:12A1::/96FF7E:140:2001:660:3001:12B8::/96

RP

Lab 2

2001:660:3001:12A1::1FF7E:140:2001:660:3001:12A1::/96

2001:660:3001:12B8::1FF7E:140:2001:660:3001:12B8::/96

August 4th, 2004 IETF 60th - San Diego 24

Scenario 3

RP

Campus

DHCPv6server

Lab 1

RP

Lab 2scope = E

August 4th, 2004 IETF 60th - San Diego 25

Scenario 3

RP

Campus

DHCPv6server

Lab 1

Retrieve client’s location (lab) using its address, client’s DUID, User class option....

RP

Lab 2

August 4th, 2004 IETF 60th - San Diego 26

Scenario 3

RP

Campus

DHCPv6server

Lab 1

RP

Lab 2

FF7E:140:2001:660:3001:12A1: 9ABC:1234

RP

The organization can also deploy its own RP in this scenario. Use of resources

depends then from the choice of the address

August 4th, 2004 IETF 60th - San Diego 27

Scenario 3.2

RP

Campus

DHCPv6server

Lab 1

FF15::/16

Wants to start a site-local multicast session – needs

an address

Configured to assign IPv6 multicast addresses in:

FF15::/16 for every lab

RP

Lab 2

FF15::/16

August 4th, 2004 IETF 60th - San Diego 28

Scenario 3.2

RP

Campus

DHCPv6server

Lab 1

FF15::/16RP

Lab 2

FF15::/16

scope = 5

August 4th, 2004 IETF 60th - San Diego 29

Scenario 3.2

RP

Campus

DHCPv6server

Lab 1

FF15::/16

Retrieve client’s location (lab) using its address, client’s DUID, User class option....

RP

Lab 2

FF15::/16

August 4th, 2004 IETF 60th - San Diego 30

Scenario 3.2

RP

Campus

DHCPv6server

Lab 1

RP

Lab 2

FF15::9ABC:1234FF15::/16

FF15::/16

August 4th, 2004 IETF 60th - San Diego 31

Scenario 3.2

RP

Campus

DHCPv6server

Lab 1

FF15::/16RP

Lab 2

FF15::/16

FF15::9ABC:1234

RP

The organization can also deploy its own RP in this scenario. Use of resources

depends then from the choice of the address

August 4th, 2004 IETF 60th - San Diego 32

Thanks !• Ralph Droms • David Meyer• Pekka Savola• Christian Strauf• Bernard Tuy• Stig Venås• All 6NET partners having worked on D3.4.3

August 4th, 2004 IETF 60th - San Diego 33

Open discussions• Split in 2 drafts:

– Assignment model to be discussed in MBoneD– New DHCPv6 options to be discussed in DHC

• Range for group ID – usefullness ?• Timers specified with a new DHCPv6 option ?• Scope option mandatory ?• DHCPv6 in userspace – not in kernel

– Potential problems ?• IPv4 multicast address assignment ?• Prefix delegation for IPv6 multicast addresses ?

August 4th, 2004 IETF 60th - San Diego 34

Next step: WG I-D ?