1. Extension of DHCP LEASEQUERY in Bridging/Switching networks draft-joshi-dhc-lease-query-ext-02.txt DHC Working Group
Bharat Joshi ( )
Pavan Kurapati ( )
Infosys Technologies Ltd.

2. RFC 4388 for Layer 3 Access Network
STB RG
ACCESS CONCENTRATOR
IP DSLAM /BRAS
Local Loop
DHCP Server
Service Provider’s
IP Network PC
STB RG
Layer 3 Relay Agent
Add option 82 and “giaddr”
Extract information like MAC/IP/Lease time
Forwards DHCP reply based on option 82
Extracted information can be used to: PC
Avoid MAC/IP Spoofing
Enhance Security by avoiding ARP generation
Generates DHCP Lease Query

3. Extension of RFC 4388 to Layer 2 Access Networks
STB RG
DHCP Server
Local Loop
L3 Relay Agent
Ethernet Aggregation Switch
Service Provider’s
IP Network
Access Concentrator
L2 Relay Agent
STB RG
Add “giaddr”
Local Loop
Forwards reply based on “giaddr”
[Destination IP in DHCP reply]
Adds option 82
Extracts information like MAC/IP/Lease time
Forwards reply based on option 82
Extracted information can be used to:
Avoid MAC/IP Spoofing
Avoid Unknown MAC Flooding
Generates Lease Query

4. 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.

5. Next Step PoC implementation is done and verified.
More review in WG mailing list.
Working group item?

6. Stefaan De Cnodder Alcatel Pavan Kurapati Infosys Technologies Ltd.
Unicast Address Sub-Option draft-decnodder-dhc-rai-unicast-01.txt DHC Working Group
Stefaan De Cnodder
Alcatel
Pavan Kurapati
Infosys Technologies Ltd.

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

8. 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. .

9. 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’

10. Next Step
More review in WG mailing list.
Working group item?