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

[Ole Troan <[e-mail]>]

Ian,

apologies for the delay. I didn't intend for the review to create more work (for me). ;-)

>> MAP provides a data-link layer that supports transport of IPv4. given that it uses embedded addresses from
>> IPv6 to algorithmically determine an end-points IPv4 address, you can say that IPv4 addressing is inherit 
>> in the data-link layer. in this model the IPv4 address is tied to IPv6. this document proposes to provision IPv4
>> addressing separately with DHCPv4. either this document needs to describe how this is supposed to work,
>> or I think make a larger separation between in which cases only stateless DHCPv4 can be used, versus
>> which data-links that also stateful DHCPv4 can be used. (I'm only aware of Public 4over6 that can support full DHCPv4).
> 
> [ian] Could we clarify this by extending the introduction to scope the document a little more? Something like:
> 
> In the most basic case of IPv4 provisioning, where the client only needs to receive a static IPv4 address and restricted port range assignment (with no dynamic address leasing or additional IPv4 configuration), DHCPv6 based approaches (such as the one proposed in [I-D.ietf-softwire-map-dhcp] may provide a suitable solution. This document is concerned with more complex IPv4 configurations scenarios, to bring DHCPv4 configuration over IPv6 only networks in line with DHCPv4 over IPv4 networks.

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?
is this work meant to also provide stateful DHCPv4 for MAP tunnels?

e.g. a configured RFC2473 tunnel or Public 4over6, could work.

when it comes to provisioning of a shared IPv4 address, DHCPv4 doesn't really do that.
I don't see that described in this document?
I think we need to evaluate if there should be a completely new option for IPv4 address and port set, or
a the classic IPv4 address option combined with a new port set option.

>> Section 1.1
>> "2. Extend DHCPv6 with new options for IPv4 configuration, such as
>>  [I-D.ietf-softwire-map-dhcp] describes."
>> 
>> I think that could be phrased better. MAP DHCP does give the CE enough
>> information so that it can calculate it's own IPv4 address. Here it reads as if
>> we're adding DHCPv4 options to DHCPv6.
>> I'm not even sure you should have MAP DHCP in this table, it is not a solution
>> for passing DHCPv4 options, nor is it a solution to replicate all DHCPv4 options
>> in DHCPv6. It is a solution for having the CE calculate it's own IPv4 address,
>> shared IPv4 address or prefix. Note that the last two are not even supported in DHCPv4.
>> It does not offer any other IPv4 configuration information.
> 
> [ian] The text at the moment says that 'DHCPv6 has been extended to convey the parameters necessary for IPv4 in IPv6 softwire configuration' which is true. It doesn't say that MAP DHCP has, or will be, extended any further with additional DHCPv4 options.
> 
> So, as an example of extending DHCPv6 to carry IPv4 configuration, it's accurate. However, if we go with the scoping clarification above then we could remove the reference here.

thanks.

>> If you have it in the "approaches" list at all:
>> 2. Depend on the setup of data-link (softwire) to offer enough information to create IPv4 addressing.
>>     Require no other IPv4 configuration information.
>> 
>> ** Reading section 1.3. If you want this approach to be "copy relevant DHCPv4 options into DHCPv6",
>> then I suggest removing all references to MAP-DHCP.
>> 
> [ian] See above.
> 
>> 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.

>> Section 2:
>> Drop requirement 6, I can't see how you can evaluate that.
> 
> [ian] You can evaluate it on the following basis: If the requirements that are described in this document are not your requirements as an operator, then you shouldn't be forced to use whatever the conclusion of this document is. In practical terms, I see this as 'if MAP DHCP meets your requirements, you don't need to bring in DHCPv4 over Foo or whatever else'.

I didn't quite understand the implications of that.

>> 8 is empty
>> 
> [ian] Will fix.
> 
>> I suggest you add a new requirement:
>> x. Fate sharing. The provisioning of IPv4 addressing and other configuration information should be logically tied
>>     to the data-link layer that is uses to provide IPv4 connectivity.
> 
> [ian] This one's going to be more of a problem, as it pretty much directly conflicts with requirement 7, in that the two contradict each other. You can only implement data link fate sharing if you've got a hub and spoke architecture to locate the hub in (so that if it's not available, then IPv4 provisioning also fails)

which link-layer fails that?
I'm dubious about requirement 7 overall. and e.g. DHCPv4 over DHCPv6 is restricted to there being a DHCPv6 transport available.

> In the case of a pure mesh network, with no hub and spoke, how could you have fate sharing for the data-link layer? The proposed requirement pre-supposes a specific underlying architecture. 

is this the equivalent to the dentist's office case? can you give an example of other data link-layers where IPv4 can be provisioned on a NBMA link, without a router?

> Can we put this one to the workgroup to ask if this should be included as a new req, as it' has not been previously discussed?
> 
>> 
>> Section 3:
>> DHCPv4oDHCPv6 is "no" for requirement 4. and "no" on fate sharing.
> 
> [ian] Why is it a 'no' for req 4? Section 8 of the DHCPv4 over DHCPv6 draft:
> 
> Additionally, the DHCPv6 relay agent MAY allow the configuration of
>   dedicated DHCPv4 over DHCPv6 specific destination addresses,
>   differing from the addresses of the DHCPv6 only server(s).  To
>   implement this function, the relay checks the received DHCPv6 message
>   type and forwards according to the following logic:
> 
>   1.  If the message type is BOOTREQUESTV6, then the DHCPv6 request is
>       relayed to the configured DHCPv4 aware 4o6 Server's address(es).
> 
>   2.  For any other DHCPv6 message type, forward according to section
>       20 of [RFC3315].

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?
could you clarify the requirements?
now they do read like they have been reverse engineered.

> For the fate sharing req, as stated above.
> 
>> 
>> In the evaluation in section 3.x I suggest dropping the use of "complex" and "simple".
>> That appears very subjective.
>> 
> [ian] OK
> 
>> 3.4.2 bullet 3. applies to all approaches allowing DHCPv4 leases.
> 
> [ian] How so? If you have a 'wrapper' type of approach (where DHCPv4 is being put into IPv6 or DHCPv6), then the DHCPv4 over xv6 client function can be agnostic to what the physical interface is beyond 'it must support multicast or unicast'. If the DHCPv4oSW mechanism is not linked just to softwires and is essentially a 'vanilla' DHCPv4 client, then it must have awareness of the link layer capabilities of the link on which it is running and potentially adapt it's behaviour accordingly, such as per-client l4 port-restrictions.

I read this bullet to be about the interface to be _provisioned_. regardless of how that information reaches the client, the client must be aware of the link-layer restrictions. and that I believe apply to all mechanisms, regardless.

> 
>>         bullet 4. please expand.
> 
> [ian] This was from a question I asked on the ML some time ago, but wasn't answered. Does MAP-T support broadcasts through the translator function?

I don't see why it wouldn't.

>>         bullet 5. change to "Restricted to a broadcast capable link-layer."
> 
> [ian] Is the hub-and-spoke restriction incorrect? As mentioned above, I don't see how this approach can work in a mesh environment. The 'broadcast capable' restriction is not correct as if a h&s softwire can support broadcast, then a ptp mesh softwire can as well. You could broadcast DHCPDISCOVERs to peers in a mesh group, but it's not going to get you any response.

MAP in mesh mode, still has a point to point tunnel to the BR.
we have not described MAP in a 'pure' mesh mode, i.e. without a BR.

>> 3.5.1 bullet 3. DHCPv4 and DHCPv6 cannot really be separated from each other since it 
>>         it is DHCPv6 that provides transport for DHCPv4. and support for the new BOOTP messages
>>         are required in DHCPv6.
> 
> [ian] But a dedicated DHCPv4 over DHCPv6 server could be deployed separate from the DHCPv6 only server. What about changing to read?:
> 
> 'DHCPv4 and DHCPv6 based provisioning infrastructure can be seperated'

as long as there is a DHCPv4 message capable DHCPv6 server.

>> Minor comments:
>>  Introduction:
>>  "A general trend here is to relocate NAT44 functionality and IPv4
>>  address sharing from the centralized tunnel concentrator to the CPE
>>  in order to achieve better scalability. "
>> 
>>  I understand what you are trying to say, but unless the reader understands that the starting point
>>  are mechanisms like NAT444 and DS-lite, he would find this strange. As current deployments
>>  of IPv4 already use distributed NAT.
> 
> [ian] What about changing the wording to:
> 
> '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.

couldn't you say something along the lines of "In todays residential networks, each residential user gets a single global IPv4 address. Continuing that model of a decentralised NAT, provides excellent scaling properties and combined with stateless functions in the network, simple redundancy and logging." modify as you please.

cheers,
Ole