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

From: Bharat Joshi <[email-masked]>
Date: Mon, 1 Sep 2008 21:48:09 +0530

Hi David,

      Thanks for your reply. Please see my replies in line for some of the items.

Regards,
Bharat

> * 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.

Ok.

> * 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?

Yes. Because Relay Agent Information option mostly refers to Option 82. If you want, you can specifically mention Interface id option also.

> * 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.

Yes. Actually in this context, DHCPv6 is a little different than DHCPv4.

> * 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.

My point was mostly coming from the fact that 'router' alone may not be enough in this statement. Adding 'An IPv6 node' will help but still does not take care of my concern.

> * How does LDRA works if it is directly connected to the DHCP server?
> >> 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.

Ok. If you feel this will make it more explicit, please add.

> * 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.

Please add.

> * 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).

Yes. I was referring to this situation only.

> 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.

The advantage of using 'trust' interface is that a spoof packet is dropped in the network element where it is getting into the network while with this, it will reach all the way till DHCP server and DHCP server will parse it to find out that this is not a valid/trusted packet.

> * In section 6.2, how does the source address is populated here?
> >> 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.

Ok.

> * 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.

Ok.

> * 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.

Ok. This is fine.

> * 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.

Ok.

> * 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).

Ok.

> Thanks again for the comments!

Not a problem.

> -David Miles

**************** 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: Wed, 24 Sep 2008 00:33:56 +0800

With respect to the DHCPv6 LDRA, there is only one item that remains
outstanding - the capability of the LDRA to support client-side relays,
and the method to handle this.

Bharat has pointed out that:
>The advantage of using 'trust' interface is that a spoof packet is
dropped in the network element where it is getting into the network
while with this, it will reach all the way till DHCP server >and DHCP
server will parse it to find out that this is not a valid/trusted
packet.

It's fair to say there are two approaches:
- Re-use the IPv4 L2RA Trusted and Un-trusted approach with respect to
relay support (ie, is it okay to get a relay-forward from the client)
- Use hop-count to determine whether the message has been relayed, per
the current text in the draft

I'd like to invite others to comment on this item directly to resolve.
Can others give their opinion on their preferred approach?

Best Regards,

-David

Current extract below:
http://tools.ietf.org/html/draft-miles-dhc-dhcpv6-ldra-00

6.1.2.  Trusted and Untrusted Interfaces

   In [RFC3046] DHCPv4 relay-agents had their client-facing interfaces
   set to trusted and untrusted.  In DHCPv4 it was not possible for a
   DHCP server to determine whether the client or an intermediate relay
   had added relay agent information options and thus trusted interfaces
   (relay-agent interfaces that would allow any DHCP options to be
   present on incoming messages) and untrusted interfaces (relay-agent
   interfaces that would ensure there are no relay-agent options on
   incoming messages) were defined.  In DHCPv6 relay agents encapsulate
   the received message into the Relay-Message Option in addition to
   adding any relay-agent options.  This nested message behaviour allows
   a server to identify the options each relay-agent has inserted along
   the path.

   When an LDRA is deployed, DHCPv6 servers MUST be configured with the
   Relay-Forward hop-count of the LDRA to instruct at which level of
   nesting the relay-agent options should be parsed.  This removes the
   need for an interface to be configured as trusted or untrusted by
   providing the DHCPv6 server with an awareness of the LDRA logical
   location in the DHCP relay path.  This behaviour is dependant on the
   interception of all DHCP messages by the LDRA and the incrementing of
   the Relay-Forward hop-count if a Relay-Forward message is received
   from the client-facing LDRA interface.