Re: [dhcwg] Comments - draft-ietf-dhc-l2ra-extensions-00

[Bharat Joshi <[e-mail]>]

David,

   Please see my response in line.

Regards,
Bharat

> > Pavan> This problem can be solved in 2 ways. 1) Obsolte the broadcast
> flag 2) Use unicast option
>
> Maybe I am confused; the unicast option is a DHCPv6 feature, the
> broadcast flag is a DHCPv4 (bootp header) feature?

Pavan meant the unicast hardware sub-option we have proposed in layer 2 Relay Agent extension draft.

> > To do option 1 we have to formally obsolte the same. Option 2 is a
> cleaner solution for RA to pick up the address given in the option and
> unicast it back. Either way, it has to come through a draft and get WG
> approval. Ignoring broadcast flag otherwise is not DHCP standard
> compliant.
>
>
> Presuming DHCPv4 contextually; DHCPv4 agents may, at their ability,
> unicast or broadcast.  The only thing that is certain is that if the
> broadcast flag is set, they MUST broadcast.  With the broadcast flag
> cleared (indicating desire to unicast), they may still broadcast if
> they cannot unicast-without-arp (for example).
>
> Modern day networks realistically have software support for unicast.
> It is very rare to find instances where broadcast replies are
> actually used, excepting of course now that Vista sets the broadcast
> flag.  Even where DHCP server software is running on 'odd' server
> hardware (lacking sufficient raw packet support), a modern relay agent
> can be used to bridge the gap.
>
> So this is a condition that I think "IETF DHCP Extensions" must
> formally support, even if it hopefully has very little, if any,
> actual use.  Replies may be broadcast to the L2RA no matter what
> we do.

Ok.

> An area where L2RA can and should extend this featureset is in a
> missing indication between the DHCP Agent and the L2RA.
>
> The broadcast flag properly indicates the client's needs, meaning
> between the L2RA and the client.  The DHCPv4 protocol is missing a
> field that hints at the path between the server-side DHCP agent and
> L2RA.
>
> This could be solved with a relay agent information option scoped
> broadcast-request flag (perhaps extending the 'flags' option).
>
> The DHCP agent would use the relay agent information flags option
> contents to deliver the packet to the L2RA, which would use the
> bootp header flag to deliver to the client (limiting the broadcast
> to their specific port).

This is a very good idea. Let me rephrase it and let me know if my understanding of what you are proposing is correct.

L2 RA sets a flag [other than the broadcast flag] if it wants the reply to be unicast to him. DHCP server [if there is no layer 3 relay agent] or Layer 3 Relay Agent always looks at this flag and if the flag is clear, it unicast the message to the L2 RA. L2 RA looks at the broadcast flag and broadcast/unicast DHCP reply accordingly. This looks good.

One question remains. Is it enough if L3 RA [or DHCP server if L3 RA is not there] unicast the DHCP reply to hardware address available from the DHCP message's chadd field? Or we need some mechanism where L2 RA tells L3 RA [or DHCP server] as to what hardware address to use to unicast a DHCP reply message to him?

> > Woj> Unless we have a good reason for it to cache, I'd say it should go.
>
> Now that I consider it, I think there is a lease-time associated with
> active assignments, and no expiration time associated with inactive
> assignments.  To these ends, caching negative replies is probably
> actively harmful; it could be assigned at any moment, including the
> next nanosecond.

Yes. We completely agree. This was one of the reasons why we removed it from 'query-by-remote-id' draft. We will remove it from this draft as well.

**************** CAUTION - Disclaimer *****************
This e-mail contains PRIVILEGED AND CONFIDENTIAL INFORMATION intended solely 
for the use of the addressee(s). If you are not the intended recipient, please 
notify the sender by e-mail and delete the original message. Further, you are not 
to copy, disclose, or distribute this e-mail or its contents to any other person and 
any such actions are unlawful. This e-mail may contain viruses. Infosys has taken 
every reasonable precaution to minimize this risk, but is not liable for any damage 
you may sustain as a result of any virus in this e-mail. You should carry out your 
own virus checks before opening the e-mail or attachment. Infosys reserves the 
right to monitor and review the content of all messages sent to or from this e-mail 
address. Messages sent to or from this e-mail address may be stored on the 
Infosys e-mail system.
***INFOSYS******** End of Disclaimer ********INFOSYS***
_______________________________________________
dhcwg mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/dhcwg