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

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

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

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?

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.

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?