1 / 10

Bharat Joshi ( bharat_joshi@infosys ) Pavan Kurapati ( pavan_kurapati@infosys )

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

hisoki
Télécharger la présentation

Bharat Joshi ( bharat_joshi@infosys ) Pavan Kurapati ( pavan_kurapati@infosys )

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

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

  2. STB RG STB RG RFC 4388 for Layer 3 Access Network ACCESS CONCENTRATOR IP DSLAM /BRAS Local Loop DHCP Server Service Provider’s IP Network PC • 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. STB STB RG RG Extension of RFC 4388 to Layer 2 Access Networks DHCP Server Local Loop L3 Relay Agent Ethernet Aggregation Switch Service Provider’s IP Network Access Concentrator L2 Relay Agent • 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 doneand 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.txtDHC Working Group

  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?

More Related