Subject: [dhcwg] Some question and suggestion on LDRA draft

From: Bharat Joshi <[email-masked]>
Date: Wed, 27 Aug 2008 20:07:23 +0530

Hi David,

     I reviewed this draft and I have some questions and suggestions:

* In Abstract, it is not very clear what prompted the creation of LDRA. It would be good if it can have few statements on that.

* Introduction refers to private draft for Layer 2 Relay Agent Information draft. This draft was accepted some time back and we now have a 01 version of the same.

* In requirement, second point, does DHCPv6 really use Relay Agent Information option?

* In requirement, second point, should we have a point where we say that LDRA MUST remove any option from DHCP reply message.

* In terminology, 'host' is defined as 'A node that is not a router'. What about bridge/switch?

* Can you please reword the first statement of second paragraph of section 5.1? This statement has '... should use to be forwarded to the client'.

* In section 5.1, 'unspecified value' -> 'unspecified address'

* How does LDRA works if it is directly connected to the DHCP server?

* In section 6.1, it looks like interfaces in LDRA should be configured whether they are client facing or not. Right? Is this assumption correct?

* In section 6.1.2, 'or an intermediate relay had added' -> 'or an intermediate relay agent had added'

* In section 6.1.2, 'In DHCPv6 relay agents encapsulate' -> 'In DHCPv6, relay agents encapsulate'

* In section 6.1.2, I think we should stick to the trusted and untrusted interface in Relay Agent as suggested by RFC 3046. The hop-count method to identify the trusted entry can easily be spoofed.

* In section 6.2, 'the agent MUST listen to all' -> 'the LDRA MUST listen to all'

* In section 6.2, how does the source address is populated here?

* In section 7, first paragraph looks out of place. Also some where in previous section, its mentioned that LDRA intercept all DHCP traffic by looking at the UDP port and in this paragraph, it is mentioned that it intercepts all traffic destined to FF02::1:2.

* In section 7.3, in figure, the second LDRA should be connected to Relay D and not Relay C. Right?

* With this, a unicast message to the DHCP server would also be intercepted by LDRA and forwarded as other DHCP messages are forwarded through one or multiple relay agents. Right?

* BTW, though this draft does not suggest LDRA to create local states based on the intercepted DHCP messages but do you think it would be good to add a section for this in the document? Actually speaking, draft does not disallow this.

Thanks,
Bharat

**************** 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
[email-masked]
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "MILES DAVID" <[email-masked]>
Date: Mon, 1 Sep 2008 10:05:59 +0800

Thanks Bharat,

Inline:

* In Abstract, it is not very clear what prompted the creation of LDRA.
It would be good if it can have few statements on that.
>> More than happy to add additional words. In summary: to support IPv6
in the Broadband Forum TR-101 architecture where n:1 VLANs are used.

* Introduction refers to private draft for Layer 2 Relay Agent
Information draft. This draft was accepted some time back and we now
have a 01 version of the same.
>> Will update.

* In requirement, second point, does DHCPv6 really use Relay Agent
Information option?
>> The purpose of the LDRA is to insert Relay Agent options so I think
this may be a terminology issue. In the text it's referred to as : Relay
Agent Information parameters - would "Relay Agent options" be more
appropriate?

* In requirement, second point, should we have a point where we say that
LDRA MUST remove any option from DHCP reply message.
>> As a relay agent, the contents of the Relay Message option are sent
to the client. If the Relay-Reply message has other options (that may or
may not be relevant to the relay agent) these are never sent to the
client. The LDRA does behave like a normal DHCPv6 relay from this
perspective.

* In terminology, 'host' is defined as 'A node that is not a router'.
What about bridge/switch?
>> And a node is described as a device that implements IPv6. Happy to
add "An IPv6 node" to the start of that sentence.

* Can you please reword the first statement of second paragraph of
section 5.1? This statement has '... should use to be forwarded to the
client'.
>> No problem. That is a mouthful!

>> Done.

>> I can add this example if desired, however in brief it would not
differ in its behaviour. Messages would be transmitted to the
All_DHCP_Servers_and_Relay_agents address.

* In section 6.1, it looks like interfaces in LDRA should be configured
whether they are client facing or not. Right? Is this assumption
correct?
>> Yes, this is a valid assumption. I'll add words to ensure there is a
clear difference between the "client-facing interface" and any other
LDRA interfaces. 

* In section 6.1.2, 'or an intermediate relay had added' -> 'or an
intermediate relay agent had added'
>> Done.

* In section 6.1.2, 'In DHCPv6 relay agents encapsulate' -> 'In DHCPv6,
relay agents encapsulate'
>> Done

* In section 6.1.2, I think we should stick to the trusted and untrusted
interface in Relay Agent as suggested by RFC 3046. The hop-count method
to identify the trusted entry can easily be spoofed.
>> As the value is incremented by every relay agent, I'm not sure how
spoofing the value in a relay-forward message could alter the calculated
location (provided you trust relay agents between the LDRA and the
server). Regardless of a spoofed (or real value), the LDRA is always
known to be x hops away from the server - so a simple subtraction can
identify the any options inserted by the LDRA. This approach also allows
flexibility for future relays downstream of the LDRA without changing
the "trust" state of the interface.

* In section 6.2, 'the agent MUST listen to all' -> 'the LDRA MUST
listen to all'
>> Done

>> I'll add similar text to 6.1:
   The LDRA MUST copy the link-layer and IP source address from the
Relay-Forward
   message into the IP/UDP packet forwarded to the client.

* In section 7, first paragraph looks out of place. Also some where in
previous section, its mentioned that LDRA intercept all DHCP traffic by
looking at the UDP port and in this paragraph, it is mentioned that it
intercepts all traffic destined to FF02::1:2.
>> Thanks for the catch - this is along the same lines as what Truman
saw - a hang over from when we were trying to support unicast operation
as well. I'll re-check for consistency on this point. I'll change the
tone of the first paragraph to emphasise LDRA intercept DHCP messages
sent to FF02::1:2 like a normal DHCPv6 relay. 

* In section 7.3, in figure, the second LDRA should be connected to
Relay D and not Relay C. Right?
>> RelayC was meant to illustrate a functional location (a relay agent
downstream of the LDRA) and not an actual node. Ie, every instance of
relayC is independent and unique.

* With this, a unicast message to the DHCP server would also be
intercepted by LDRA and forwarded as other DHCP messages are forwarded
through one or multiple relay agents. Right?
>> No, unicast operation is not addressed.

* BTW, though this draft does not suggest LDRA to create local states
based on the intercepted DHCP messages but do you think it would be good
to add a section for this in the document? Actually speaking, draft does
not disallow this.
>> I agree that the LDRA may be co-located in a device that performs
other functions (such as a DSLAM) that may want to create states based
on DHCP message exchange. This is outside the scope of the LDRA (the
LDRA itself being stateless).

Thanks again for the comments!

-David Miles