Re: [dhcwg] I-D Action: draft-ietf-dhc-dhcpv6-client-link-layer-addr-opt-00.txt

["A. Gregory Rabil" <[e-mail]>]

No.  You asked for me to provide a scenario where the interface being
configured is not the interface on which the packet is sent.  I believe I
have done that.  The example was extended simply to demonstrate that we may
also consider other uses for this option beyond the box you wish to put it
in.  But you are clearly not interested in a larger box.  Got it.

On Wed, Jul 11, 2012 at 5:26 PM, Ted Lemon <[e-mail]> wrote:

> On Jul 11, 2012, at 5:10 PM, A. Gregory Rabil wrote:
> > Okay, consider prefix-delegation, for example.  The requesting router
> will send an IA_PD request out the WAN interface to get a prefix which is
> then allocated to the downstream/LAN interface.  Since the packet is sent
> via the WAN interface, I believe that the relay would insert the link-layer
> address of the WAN interface in the request, and thus the prefix would then
> be "associated" with the WAN interface, whereas it is really associated
> with the LAN interface.  So, this is how the interface being configured is
> NOT the interface on which the packet is sent.  Further, consider a
> requesting router with two distinct downstream/LAN interfaces.  The PD
> requests for both LAN interfaces would be sent via the WAN interface, and
> thus the WAN's link-layer address will be inserted into the option by the
> relay (or learnt by the server from layer 2).  An administrator may wish to
> configure different prefixes and/or options for each LAN interface, but has
> no way to do identify them individually via the proposed mechanism.
>
> So you're saying that we need the functionality because of a protocol
> feature that doesn't exist.   Got it.
>
>