Hi Ted,

I'm afraid there is no camel at all...and only a mirage in a desert.

Cheers,
Med

>-----Message d'origine-----
>De : Ted Lemon [mailto:[email protected]]
>Envoyé : lundi 15 avril 2013 15:35
>À : BOUCADAIR Mohamed OLNC/OLN
>Cc : Qi Sun; [email protected]; Softwires ([email protected])
>Objet : Re: [dhcwg] Adoption call on draft-scskf-dhc-dhcpv4-over-dhcpv6
>
>On Apr 15, 2013, at 3:40 AM, <[email protected]> wrote:
>> Except "IPv4 addressing"-related configuration, what additional
>configuration parameters can be provisioned with DHCPv4 and not with
>DHCPv6?
>> Why in the future, an IPv6-enabled node will require to retrieve
>configuration using DHCPv4-over-DHCPv6 and not directly using DHCPv6?
>
>That's exactly the point, Med.   We are attempting to separate out legacy
>solutions that continue to require native IPv4 from those that can survive
>entirely on IPv6, which we expect in the long run to be the vast majority.
>The point is simply to say that if you want to configure your IPv4 stack
>with DHCP, you should, in general, continue to use DHCPv4.
>
>There is general agreement that it's pretty harmless, and also quite
>efficient, to provision MAP-E-based solutions using DHCPv6, as long as all
>they need from the DHCP server is their MAP prefix/port set configuration.
>But we are trying to keep the camel's nose from coming any further under
>the tent by explicitly saying how you do any additional provisioning of the
>IPv4 stack, should you need to do so.
>
>This document also addresses the problem of doing _stateful_, as opposed to
>_stateless_ IPv4 address configuration for dual-stack nodes on an IPv6-only
>network with IPv4 tunneling to AFTRs.   In that case, again, the required
>extensions to DHCPv6 would be large, and it's actually pretty convenient to
>just leverage the DHCPv6 infrastructure to carry protocol messages to a
>DHCPv4 server, which already knows how to do dynamic IPv4 address
>allocation.

_______________________________________________
Softwires mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/softwires

Reply via email to