Extension of DHCP LEASEQUERY in Bridging/Switching networks

draft-joshi-dhc-lease-query-ext-02.txtDHC Working Group

Bharat Joshi ( bharat_joshi@infosys.com )

Pavan Kurapati ( pavan_kurapati@infosys.com )

Infosys Technologies Ltd.

RFC 4388 for Layer 3 Access Network

PC

ACCESS CONCENTRATOR IP DSLAM /BRASLocal Loop

STB

RG

PC

STB

RG

Service Provider’sIP Network

DHCP Server

• Add option 82 and “giaddr”• Layer 3 Relay Agent

• Forwards DHCP reply based on option 82• Extract information like MAC/IP/Lease time

• Generates DHCP Lease Query

• Avoid MAC/IP Spoofing

• Enhance Security by avoiding ARP generation

• Extracted information can be used to:

Extension of RFC 4388 to Layer 2 Access Networks

Service Provider’sIP Network

DHCP Server

Local Loop

STB

RG

L3 Relay Agent

Ethernet Aggregation Switch

Access ConcentratorL2 Relay Agent

• Adds option 82

• Add “giaddr”

• Extracts information like MAC/IP/Lease time

• Forwards reply based on “giaddr” [Destination IP in DHCP reply]

• Forwards reply based on option 82

• Avoid MAC/IP Spoofing

• Avoid Unknown MAC Flooding

• Generates Lease Query

Local Loop

STB

RG

• Extracted information can be used to:

Changes from 00 to 02• New option for ‘Access Concentrator’ hardware address.

• Added text for:

– Layer 3 Relay Agent MUST NOT add option 82 to DHCPLEASEQUERY messages.

– DHCP server MUST add the new option only in the reply of DHCPLEASEQUERY messages.

– Handling multiple responses received for a DHCPLEASEQUERY message

– If a Layer 2 Relay Agent can use its management IP address to talk to DHCP server than that should be preferred.

– Added authentication details of DHCP LEASEQUERY messages as per RFC 3118 in security section.

– Removed the restriction of mandating the insertion of new option at the end

– Some minor comments and grammatical issues.

Next Step

• PoC implementation is done and verified.

• More review in WG mailing list.

• Working group item?

Unicast Address Sub-Option draft-decnodder-dhc-rai-unicast-01.txt

DHC Working Group

Stefaan De Cnodder

Alcatel

Pavan Kurapati

Infosys Technologies Ltd.

Need for unicast-address sub-option

• DHCP replies are broadcast/flooded to L2 RA under below

conditions :

– If client sets Broadcast flag in DHCP requests

– If L2 RA does MAC translation, Ethernet aggregation devices

does not learn client’s MAC address. Hence even if broadcast flag

is not set, replies are flooded to all the L2 RAs.

• Flooding need to be avoided between L2 RA and L3 RA

New sub-option in Option-82

• New sub-option called ‘unicast-address’ is defined for Relay agent option.

• L2 RA fills unicast-address sub-option with:

– ‘chaddr’ if L2 RA is acting as a bridge without MAC translation

– The hardware address which is used for translation (eg, ACs MAC address) if L2 RA does MAC translation.

.

Processing of new sub-option

• DHCP server MUST echo this sub-option as it is in option-82

• L3 RA should look for this new sub-option and if present use this MAC address to forward the DHCP messages irrespective of the broadcast flag.

• L2 RA should respect the broadcast flag and should change the destination MAC address accordingly. i.e

– If broadcast flag is set, change the destination MAC as broadcast

– If broadcast flag is not set, change the destination MAC to that of ‘chaddr’

Next Step

• More review in WG mailing list.

• Working group item?