Re: [dhcwg] draft-ietf-dhc-dhcpv4-over-ipv6-02 / multiple ipv4 interfaces

[Francis Dupont <[e-mail]>]

 In your previous mail you wrote:

>  On Apr 14, 2012, at 4:10 PM, Francis Dupont wrote:
>  I am confused: either the tunnels are links (it is a bad idea IMHO
>  but it is not a priori impossible), or they are not links and they
>  don't exist for DHCP.
>  
> That is not the use case for this draft.  The use case for this
> draft is that a client wants IPv4 support on an IPv6-only network,
> and so it uses DHCP to get an address for the tunnel endpoint.

=> IMHO some of the confusion comes from this term "tunnel endpoint":
it is both the node at this end of the tunnel and the virtual interface
of the tunnel.

> It does this by broadcasting a DHCPv4 request on the local
> interface, which the CRA captures and forwards to the DHCPv4 server
> over IPv6.

=> this is the first interpretation and the local interface is the
physical interface used by the tunnel endpoint node to send encapsulated
packets to the tunnel other end.

> Once the tunnel is established, renewals are (one assumes) routed
> down the tunnel.

=> in fact to work well either the server has to handle both the TSV
function and the regular DHCPv4 over a tunnel, or a TRA is at the
tunnel other end. But this doesn't change the client/CRA so is a side
comment.

> But the idea, as I understand it at least, is to leverage the
> existing DHCPv4 client, not to require a special DHCPv4 client.

=> yes, this is the idea. And I tried with two very different and
unmodified clients so the idea is valid. Note it is not fully true
for the server side (even the I-D says it is).

> If we require a special DHCPv4 client, we might aswell just do all
> the DHCPv4 transactions over UDPv6.

=> I agree: on the client side the DHCPv4 client is unmodified and
the CRA is as simple as possible. IMHO these are critical for the
target deployment, i.e., low cost CPEs.

Thanks

[e-mail]