Transcript DHCP Lease Query Extension to Layer 2 Networks draft-joshi

Extension of DHCP LEASEQUERY in
Bridging/Switching networks
draft-joshi-dhc-lease-query-ext-02.txt
DHC Working Group
Bharat Joshi ( [email protected] )
Pavan Kurapati ( [email protected] )
Infosys Technologies Ltd.
RFC 4388 for Layer 3 Access Network
STB
Local Loop
RG
ACCESS CONCENTRATOR
IP DSLAM /BRAS
DHCP Server
Service Provider’s
IP Network
PC
STB
RG
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:
• Avoid MAC/IP Spoofing
• Enhance Security by avoiding ARP generation
• Generates DHCP Lease Query
STB
Extension of RFC 4388 to Layer 2
Access Networks
DHCP Server
Local Loop
RG
L3 Relay Agent
Ethernet Aggregation
Switch
STB
Access Concentrator
L2 Relay Agent
Service Provider’s
IP Network
• Add “giaddr”
• Forwards reply based on “giaddr”
[Destination IP in DHCP reply]
Local Loop
RG
• 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?
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?