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

From: Ole Troan <[email-masked]>
Date: Mon, 7 Oct 2013 11:55:17 +0200

all,

here are some comments on a first read of the document.

I have to general comments. one is on fate-sharing (see below), the other on address provisioning conflicts.

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

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.

  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.

  Rename 3. to "stateless DHCPv4" or DHCPINFORM only.

Section 2:
  Drop requirement 6, I can't see how you can evaluate that.
  8 is empty

  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.

Section 3:
  DHCPv4oDHCPv6 is "no" for requirement 4. and "no" on fate sharing.

  In the evaluation in section 3.x I suggest dropping the use of "complex" and "simple".
  That appears very subjective.

  3.4.2 bullet 3. applies to all approaches allowing DHCPv4 leases.
          bullet 4. please expand.
          bullet 5. change to "Restricted to a broadcast capable link-layer."

  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.

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.

cheers,
Ole

On Sep 30, 2013, at 16:14 , Ian Farrer <[email-masked]> wrote:

> Hi,
> 
> I've just posted an update to the draft based on the discussions in Berlin and Francis' review.
> 
> The contents of the conclusion remains unchanged.
> 
> Any comments etc. appreciated.
> 
> Cheers,
> Ian
> 
> 
> On 30 Sep 2013, at 16:00, [email-masked] wrote:
> 
>> 
>> A New Internet-Draft is available from the on-line Internet-Drafts directories.
>> This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.
>> 
>> 	Title           : Provisioning IPv4 Configuration Over IPv6 Only Networks
>> 	Author(s)       : Branimir Rajtar
>>                         Ian Farrer
>> 	Filename        : draft-ietf-dhc-v4configuration-02.txt
>> 	Pages           : 17
>> 	Date            : 2013-09-30
>> 
>> Abstract:
>>  As IPv6 becomes more widely adopted, some service providers are
>>  taking the approach of deploying IPv6 only networks, without dual-
>>  stack functionality for IPv4.  However, access to IPv4 based services
>>  is still an ongoing requirement and approaches such as IPv4-in-IPv6
>>  softwire tunnels are being developed to meet this need.
>> 
>>  In order to provision end-user's hosts with the necessary IPv4
>>  configuration, a number of different mechanisms have been proposed.
>>  This memo discusses the benefits and drawbacks of each, with the aim
>>  of recommending a single approach as the basis for future work.
>> 
>> 
>> 
>> The IETF datatracker status page for this draft is:
>> https://datatracker.ietf.org/doc/draft-ietf-dhc-v4configuration
>> 
>> There's also a htmlized version available at:
>> http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-02
>> 
>> A diff from the previous version is available at:
>> http://www.ietf.org/rfcdiff?url2=draft-ietf-dhc-v4configuration-02
>> 
>> 
>> Please note that it may take a couple of minutes from the time of submission
>> until the htmlized version and diff are available at tools.ietf.org.
>> 
>> Internet-Drafts are also available by anonymous FTP at:
>> ftp://ftp.ietf.org/internet-drafts/
>> 
>> _______________________________________________
>> dhcwg mailing list
>> [email-masked]
>> https://www.ietf.org/mailman/listinfo/dhcwg
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ian Farrer <[email-masked]>
Date: Wed, 9 Oct 2013 09:29:03 +0200

Hi Ole,

Thanks for the review. Please see inline.

Cheers,
Ian

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

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

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

>  8 is empty
[ian] Will fix.

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

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. 

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?

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

For the fate sharing req, as stated above.

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

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

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

>          it is DHCPv6 that provides transport for DHCPv4. and support for the new BOOTP messages

[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'

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

---

From: Ole Troan <[email-masked]>
Date: Tue, 22 Oct 2013 18:07:48 +0200

Ian,

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

> 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 co…

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.

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

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

> [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…

I didn't quite understand the implications of that.

> [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'…

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?

>   2.  For any other DHCPv6 message type, forward according to section

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.

> [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 be…

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.

> [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] 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 so…

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.

> 'DHCPv4 and DHCPv6 based provisioning infrastructure can be seperated'

as long as there is a DHCPv4 message capable DHCPv6 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 o…

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

---

From: Qi Sun <[email-masked]>
Date: Wed, 23 Oct 2013 21:57:52 +0800

Dear Ole ,

I have some thinkings about your message. Please see inline.

>> 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 c…

[Qi] Why static IPv4 address and port-set assignment is 'the most basic case of IPv4 provisioning'? For DHCPv4 (_Dynamic_ Host Configuration Protocol), dynamic assignment of IPv4 is the 'most basic case', IMO.

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

> a the classic IPv4 address option combined with a new port set option.

[Qi] AFAIK, in DHCPv4, IPv4 address is not put in an option. So to support the assignment of a shared IPv4 address, port-set is the information that needs to go to an option.

Actually there have been mechanisms to describe the usage. 

>>> It does not offer any other IPv4 configuration information.

[Qi] MAP-dhcp is _not_ the solution for having the CE calculate IPv4 info. MAP does. MAP-dhcp only provisions information. 

//A side note: I don't understand why map-dhcp needs to support to assign IPv4 prefix. It was not even supported when IPv4 addresses were sufficient. At the time we are running out of IPv4 addresses, but we need to assign IPv4 prefixes...
Sorry if I mis-lead the discussion...

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

[Qi] From my reading, the reference here is reasonable. map-dhcp does extend DHCPv6 with new options for IPv4 configuration. Further more, if there are needs to support other IPv4 configuration information using purely DHCPv6, the new mechanisms should be used together with map-dhcp, or update map-dhcp. Because map-dhcp is the base for configuring IPv4 using purely DHCPv6.

> "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!

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

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

Best Regards,
Qi

---

From: Ted Lemon <[email-masked]>
Date: Wed, 23 Oct 2013 18:00:41 +0000

> [Qi] Why static IPv4 address and port-set assignment is 'the most basic case of IPv4 provisioning'? For DHCPv4 (_Dynamic_ Host Configuration Protocol), dynamic assignment of IPv4 is the 'most basic…

I think it's really important not to find controversy where none exists.   My understanding is that what Ole is saying here is simply that in cases where no dynamic allocation or extra IPv4 service configuration is needed, DHCPv4 is not needed.   AFAIK that's the consensus expressed by the working group.   Am I missing something here?

---

From: Qi Sun <[email-masked]>
Date: Thu, 24 Oct 2013 13:19:12 +0800

Dear Ted,

Thanks for the explanation. 

Best Regards,
Qi

---

From: Ole Troan <[email-masked]>
Date: Thu, 24 Oct 2013 09:48:54 +0200

Qi,

answering mainly your questions of clarification below.

[...]

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

[...]

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

[...]

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

[...]

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

---

From: <[email-masked]>
Date: Tue, 29 Oct 2013 14:43:53 +0100

Hi Ole,

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

Cheers,
Ian

>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

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

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

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

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

>>> x. Fate sharing. The provisioning of IPv4 addressing and other
>>>configuration information should be logically tied
>> [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)
>
>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:

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

>now they do read like they have been reverse engineered.

[ian] Extended the definition with an explanation.

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

[ian] OK, removed the con.

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

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

>> [ian] But a dedicated DHCPv4 over DHCPv6 server could be deployed
>>separate from the DHCPv6 only server. What about changing to read?:
>> 

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

---

From: Ole Troan <[email-masked]>
Date: Wed, 30 Oct 2013 13:57:39 +0100

Hi Ian,

> some more answers in line.

thanks, some more comments inline.

> some point in the future, then this IPv4 configuration

the analogy to doing address assignment with DHCPv4 on a MAP tunnel,
would be to do DHCPv4 address assignment on top of IPCP for a PPP link-layer.
MAP already provides the IPv4 address, so I can't quite see how stateful DHCPv4
makes sense with MAP. can you explain?

> not what the specific v4 configuration is.

understood.

> transport question covered in this draft.

OK.

> The requirement is there to evaluate whether a solution allows you to do

OK, so the requirement is to not make DHCPv4 mandatory, for the cases
where the underlaying mechanism provides the required information.
isn't that a no-op? if you don't care about DHCPv4 then don't use it...?

> as this has a direct effect on the outcome?

I'm not going to be there physically, but we're trying to do a remote participant experiment.

> attached, but I¹m not sure how that¹s relevant to this discussion.

indeed, I don't think we need to consider the mesh case without a BR for MAP.

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

right, but then the DHCPv6 relay would have to support sending DHCPv6 messages
to multiple servers.

> with DHCPv4 functions as well.

absolutely. that applies even more to running DHCPv4 over the link-layer directly.

> [ian] Extended the definition with an explanation.

ack.

[...]

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

yes, my point was that you don't need to create the corner case for MAP,
where there is no BR. we haven't described that anywhere, so don't use
that as a reason why MAP cannot provide a link-layer that you can run
DHCPv4 on top of.

> attempt DHCPv4oDHCPv6 configuration.

from an architectural point of view, I don't really like signalling in IPv6 how IPv4 should be provisioned
and vice versa. Mark Townsley and I have an expired draft showing the complex state machine
that results in. I'd much rather prefer ships in the night.

cheers,
Ole