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

["MILES DAVID" <David.Miles at alcatel-lucent.com.au>]

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.

_______________________________________________
dhcwg mailing list
dhcwg at ietf.org
https://www.ietf.org/mailman/listinfo/dhcwg