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

[<[e-mail]>]

Hi Ole,


Thanks for the review. I¹ve updated the draft based on your comments. And
some more answers in line.

Cheers,
Ian


>
>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?

[ian] It¹s not meant to be limited to any particular softwire or other v4
type. If someone was to have a reason for using stateful DHCPv4 for MAP at
some point in the future, then this IPv4 configuration

>
>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?

[ian] The draft¹s concerned with how IPv4 configuration is transported,
not what the specific v4 configuration is.

>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.

[ian] There¹s a couple of drafts out there that do this at the moment:
draft-sun-dhc-port-set-option & draft-farrer-dhc-shared-address-lease. I
think that it¹s better to handle the format and other considerations
around option formats and shared address leasing separate from the
transport question covered in this draft.

>
>>> 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.

[ian] During the discussion in Atlanta that led up to writing this
document, an opinion voiced by several operators was: If I can provision
everything I need using simple, static DHCPv6 (I.e. Option map), why
should I have the additional overhead of a DHCPv4 providing additional
DHCPv4 options and dynamic leasing which is unnecessary to me?

The requirement is there to evaluate whether a solution allows you to do
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.

[ian] There¹s a slot for this draft in Vancouver. Can we discuss it there
as this has a direct effect on the outcome?

>
>> 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?

[ian] Not familiar with the Dentist office in this particular context.

The obvious example would be a single Ethernet segment with a DHCP server
attached, but I¹m not sure how that¹s relevant to this discussion.

>
>> 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.

[ian] Or, you could add a minimal DHCPv6 encapsulation to a DHCPv4 server.

>what do you mean by "independent DHCPv4 and DHCPv6 servers" then?

[ian] if you wanted to deploy DHCPv6 servers and DHCPv4overDHCPv6 servers
as separate instances, you can. Given how complex the DHCPv6 server logic
can become, there¹s some good reasons no to overload the DHCPv6 server
with DHCPv4 functions as well.

>could you clarify the requirements?
>now they do read like they have been reverse engineered.

[ian] Extended the definition with an explanation.

>
>> 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.

[ian] OK, removed the con.

>
>>>         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.

[ian] This document isn¹t meant to be limited to MAP mesh. E.g. RFC5565.

>
>>> 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.

[ian] Sure. But if you didn¹t have a DHCPv4 capable server, then you
wouldn¹t have sent the DHCPv4pDHCPv6 client the option to tell it to
attempt DHCPv4oDHCPv6 configuration.

>