Re: [dhcwg] I-D Action: draft-ietf-dhc-v4configuration-02.txt

[Ole Troan <[e-mail]>]

Qi,

answering mainly your questions of clarification below.

[...]

>> yes, I think a clarification in the introduction would help.
>> stateful DHCPv4 doesn't apply to DS-lite, and it is difficult to see how it applies to MAP.
>> which link-layer did you have in mind for this?
> 
> [Qi] What is the 'link-layer' you mentioned? Do you mean IPv6 can be seen as the 'link-layer' for IPv4 in the context of IPv4-over-IPv6 scenario? Sorry if I mis-understood you.

correct. a tunnel provides a data link-layer to the network layer protocol running over it.

[...]

>>>> Rename 3. to "stateless DHCPv4" or DHCPINFORM only.
>>>> 
>>> [ian] You mean the approach that's currently called DHCPv6+DHCPv4oSW (horrible name:-)? If so, are you proposing 'DHCPv6+stateless DHCPv4 over SW' as the new name? I not sure that's much better...
>> 
>> we don't call DHCPv4, "DHCPv4 over Ethernet" today.
>> "stateless DHCPv4" is most likely the only option available on link-layers which have IPv4 address configuration built in.
> [Qi] Could you please explain what 'stateless DHCPv4' is? Is this a term that I missed? Thanks!

when DHCPv4 is not used for address assignment, but only other configuration information.
as in DHCPINFORM. similar in function to RFC3736 for DHCPv6.

[...]

>> DHCPv4 over DHCPv6 requires support for transporting DHCPv4 messages in DHCPv6 servers and clients.
>> what do you mean by "independent DHCPv4 and DHCPv6 servers" then?
> 
> [Qi] IMHO, the intended meaning here is: the process of DHCPv4 and DHCPv6 are independent in DHCPv4-over-DHCPv6. 
> Besides what Ian has quoted, DHCPv4 over DHCPv6 support the client to communicate with a dedicated 4o6 Server for IPv4 configuration information (with the help of 4o6 Servers Addresses Option).

I see. perhaps make that clearer? that a DHCPv6 server has to be extended to support transport of DHCPv4 messages.
but all processing of them, including leases etc is done by the existing DHCPv4 server.

[...]

>>> 'A general trend here is to relocate the translation of privately addressed IPv4 traffic to a shared, public external address from the centralized tunnel concentrator to the CPE. The distribution of this function allows for better scalability.'
>> 
>> that reads better, but I don't agree with the statement that this is a general trend.
>> the trend as I see it from current deployments are centralised NAT. that happens in mobile, with NAT444 and with DS-lite.
> 
> [Qi] IMHO, Ian's new wording is precise enough. The centralized NAT has the problem of scalability which is known to all. So the trend _is_ to relocate the NAT function to CPE.

trend - a general direction in which something is developing or changing.
do you mean there is a 'trend' in standardisation? a trend in deployment? if so can you show data indicating that?
I'm sure there is someone on the list than can show trends in the sale of CGNs, so that we can compare.

cheers,
Ole