Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 24 Nov 2013 22:02:32 +0000

Folks, the authors of draft-ietf-dhc-dhcpv4-over-dhcpv6-03 (http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-dhcpv6-03.txt) believe it is ready for working group last call. Please review this draft and indicate whether or not you feel it is ready to be published. Your input is important! Please respond by Dec 9th, 2013.

At the time of this writing, there is no IPR reported against this draft.

Bernie will be the document shepherd.

Thanks,

-          Tomek & Bernie

---

From: <[email-masked]>
Date: Wed, 27 Nov 2013 10:50:07 +0100

Hi,

A couple of comments on the current version of the draft:

Section 8, the sentence beginning ‘The client that intends…’ should read ‘A client that intends….'

Section 8  - Question regarding the sentence ‘The 4o6 DHCP client MUST NOT request the DHCPv4-over-DHCPv6 Enable Option nor the 4o6 Server Address Option in the Boot-request-v6 message’. I think that this text as written is ambiguous.

Is it meant to mean that the boot-request-v6-message can contain any DHCPv6 option with the exception of the 4o6 enable and 4o6 server options? Saying that the client may not request certainly implies that the client could include an ORO option alongside OPTION_BOOTP_MSG. Is the intention to allow this?

If not, why exclude requesting the 4o6 server option? Obviously, it’s pointless allowing the Enable option, but sending the 4o6 server option within the BOOTREPLYV6 to allow a dedicated DHCP4o6 server to tell the client to use unicast seems like it could be a good idea. What’s the reason for specifically excluding it?

There’s also a few other places in the text that need to be aligned with this (the ‘options’ description in Sec 5.2 and paragraph 8 of section 8).

Thanks,
Ian

From: "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>>
Date: Sunday, 24 November 2013 23:02
To: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

Thanks,

-          Tomek & Bernie

---

From: Qi Sun <[email-masked]>
Date: Wed, 27 Nov 2013 19:10:08 +0800

Hi Ian,

Thanks for comments.

> Section 8, the sentence beginning ‘The client that intends…’ should read ‘A client that intends….'

[Qi] Will correct it.

> Is it meant to mean that the boot-request-v6-message can contain any DHCPv6 option with the exception of the 4o6 enable and 4o6 server options? Saying that the client may not request certainly impl…

[Qi] The reason I added this sentence was that it's not necessary for the client to ask for the Enable Option again in Boot-request-v6 message as the DHCPv4-over-DHCPv6 function has been running. The DHCPv4-over-DHCPv6 function status should be refreshed alongside IPv6 configuration process rather than DHCPv4 over DHCPv6 process. 

IMHO, the Boot-request-v6 msg and Boot-reply-v6 msg should only be used for v4-related configuration, which makes it simple.  Would it reasonable to exclude the ORO option in the two messages?
> If not, why exclude requesting the 4o6 server option? Obviously, it’s pointless allowing the Enable option, but sending the 4o6 server option within the BOOTREPLYV6 to allow a dedicated DHCP4o6 ser…

[Qi] Allowing the client to request the 4o6 server address option would violate the Bullet 4 in section 8: the client only receives the 4o6 Server Address option but no DHCPv4 over DHCPv6 Enable option, then the client is required to ignore the 4o6 Server Address option. 

IMHO, we could make it simple: the server signals the client to use unicast or multicast when the client is enabled to invoke the DHCPv4 over DHCPv6 and it's not necessary for the client to change that.

Best Regards,
Qi 

> From: "Bernie Volz (volz)" <[email-masked]>
> To: "[email-masked]" <[email-masked]>
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 27 Nov 2013 14:01:51 +0000

Hi:

I agree with Qi that these options should not be used for the BOOTREQUESTV6/BOOTREPLYV6 messages.

While we might want to think about some words to indicate that these messages should not typically have options (other than the OPTION_BOOTP_MSG option), I think we do want to be careful as someone might have a reason to include some options that could be useful to the 4o6 DHCP Server or Client in the future.

The bottom line is that these messages SHOULD NOT be used to configure DHCPv6 client and interface related settings – hence why the OPTION_DHCP4_O_DHCP6_ENABLE and OPTION_DHCP4_O_DHCP6 options SHOULD NOT be present. Normal DHCPv6 messages should be used for configuring anything related to DHCPv6 (including the two just mentioned options).

-          Bernie

From: Qi Sun [mailto:[email-masked]]
Sent: Wednesday, November 27, 2013 6:10 AM
To: <[email-masked]>
Cc: Bernie Volz (volz); [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

Hi Ian,

Thanks for comments.

On 2013-11-27, at 下午5:50, <[email-masked]<mailto:[email-masked]>> <[email-masked]<mailto:[email-masked]>> wrote:

[Qi] Will correct it.

Best Regards,
Qi

Thanks,
Ian

Thanks,

-          Tomek & Bernie

_______________________________________________
dhcwg mailing list
[email-masked]<mailto:[email-masked]>
https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Simon Perreault <[email-masked]>
Date: Wed, 27 Nov 2013 09:08:29 -0500

Le 2013-11-27 06:10, Qi Sun a écrit :
>> If not, why exclude requesting the 4o6 server option? Obviously, it’s
>> pointless allowing the Enable option, but sending the 4o6 server
>> option within the BOOTREPLYV6 to allow a dedicated DHCP4o6 server to
>> tell the client to use unicast seems like it could be a good idea.
>> What’s the reason for specifically excluding it?
>
> [Qi] Allowing the client to request the 4o6 server address option would
> violate the Bullet 4 in section 8: the client only receives the 4o6
> Server Address option but no DHCPv4 over DHCPv6 Enable option, then the
> client is required to ignore the 4o6 Server Address option.

You don't want to have a server sending an option that was not requested 
by the client. Stay with the usual ORO model. Here's a proposal:

- The client MUST always include both OPTION_DHCP4_O_DHCP6_ENABLE and 
OPTION_DHCP4_O_DHCP6_SERVER in the ORO.

- The server responds with zero (if DHCPv4-over-DHCPv6 is not available) 
or one of two options. Never both.
     - OPTION_DHCP4_O_DHCP6_ENABLE means "multicast".
     - OPTION_DHCP4_O_DHCP6_SERVER means "unicast".

If this makes sense, then I would rename the options: 
s/ENABLE/MULTICAST/ and s/SERVER/UNICAST/. And maybe go further and kill 
OPTION_DHCP4_O_DHCP6_ENABLE, and just put the multicast address in the 
payload of OPTION_DHCP4_O_DHCP6_SERVER.

By the way, a suggestion for the document: replace all instances of "4o6 
Server Address option" with the full option name, 
"OPTION_DHCP4_O_DHCP6_SERVER". Always using the same terminology makes 
it much easier to grep the document.

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: <[email-masked]>
Date: Wed, 27 Nov 2013 15:31:34 +0100

Hi Bernie,

I wasn’t necessarily advocating that other options should be carried in the BOOTREQUEST/REPLYV6 messages, just that the current wording in the draft could be understood to mean that all DHCPv6 options are allowable with the exceptions of OPTION_DHCP4_O_DHCP6_ENABLE and OPTION_DHCP4_O_DHCP6_SERVER (the only ones expressly forbidden).

However, I can see that there is a case whereby other options may need to be transported within the DHCPv4 over DHCPv6 messages: If you are using dynamic, shared IPv4 address leases for softwire clients, then you need a way of learning the IPv6 address that the client will use for it’s 4over6 tunnel endpoint otherwise you can’t provision the tunnel concentrator with all of the necessary parameters.

This IPv6 address needs to be sent from the client to the DHCPv4o6 server as it’s validity is bound to the lease lifetime of the IPv4 address + ports. It would then make sense to allow this information to also be carried within BOOTREQUESTV6 messages as DHCPv6 options alongside the OPTION_BOOTP_MSG they are related to.

So, I agree that there should be some wording to allow the inclusion of options related to configuring IPv4 in a v6 only network, without allowing any/every DHCPv6 option out there.

Ian

From: "Bernie Volz (volz)" <[email-masked]<mailto:[email-masked]>>
Date: Wednesday, 27 November 2013 15:01
To: Qi Sun <[email-masked]<mailto:[email-masked]>>, Ian Farrer <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: RE: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

Hi:

-          Bernie

From: Qi Sun [mailto:[email-masked]]
Sent: Wednesday, November 27, 2013 6:10 AM
To: <[email-masked]<mailto:[email-masked]>>
Cc: Bernie Volz (volz); [email-masked]<mailto:[email-masked]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

Hi Ian,

Thanks for comments.

[Qi] Will correct it.

Best Regards,
Qi

Thanks,
Ian

Thanks,

-          Tomek & Bernie

---

From: Qi Sun <[email-masked]>
Date: Wed, 27 Nov 2013 23:06:33 +0800

Hi Bernie,

Thanks for your reminding. I agree that we should not exclude ORO option in the two messages.

Best Regards,
Qi

---

From: <[email-masked]>
Date: Wed, 27 Nov 2013 16:10:12 +0100

>     - OPTION_DHCP4_O_DHCP6_SERVER means "unicast".

[ian] Agree - this seems cleaner than needing two options to provision
unicast.

>payload of OPTION_DHCP4_O_DHCP6_SERVER.

[ian] IIRC, putting the multicast address into the option was discussed in
the authoring process, but was rejected as being too error prone.

Cheers,
Ian

---

From: Simon Perreault <[email-masked]>
Date: Wed, 27 Nov 2013 10:18:11 -0500

> the authoring process, but was rejected as being too error prone.

How is a multicast address more error prone than a unicast address? Any 
network admin would immediately notice the error when "it doesn't work". 
And once it's in place, you don't play with it every day. IMHO the 
reduced complexity is definitely worth it.

Does anyone have a convincing argument for this?

Simon

---

From: Marcin Siodelski <[email-masked]>
Date: Wed, 27 Nov 2013 17:03:43 +0100

On Wed, Nov 27, 2013 at 4:18 PM, Simon Perreault
<[email-masked]> wrote:
> network admin would immediately notice the error when "it doesn't work". And
> once it's in place, you don't play with it every day. IMHO the reduced
> complexity is definitely worth it.
>

The OPTION_DHCP4_O_DHCP6_SERVERS is by its definition a collection of
the IP addresses. So the server configuration will probably allow
multiple occurrences of All_DHCP_Relay_Agents_and_Servers in the
OPTION_DHCP4_O_DHCP6_SERVER option. In some cases, the server
configuration may even allow to specify the mixture of multicast and
unicast addresses. That already implies, that either configuration
mechanism or/and the client not only does have to validate that there
is one and only one occurrence of each address in the option, but also
it has to validate that if there are unicast addresses the multicast
shouldn't be present (or vice-versa). Which one the client would
choose if there were both multicast and unicast. Is it really making
it simpler?

In the case proposed in the draft: if I want to use the multicast, I
send minimal amount of information to the client (boolean option). If
I want to use unicast I send two options, if client receives both
options it uses unicast. I am not certain if this is any more
complicated that parsing the option, eliminate the duplicates and the
problem of presence of both multicast and unicast etc. At least, what
you propose causes additional burden on the client's side to prevent
amplification attack when using multicast - something that we only had
for unicast so far.

Marcin

---

From: Qi Sun <[email-masked]>
Date: Thu, 28 Nov 2013 00:18:16 +0800

Hi Simon,

Thanks for your review. Please see inline.
> 
> - The client MUST always include both OPTION_DHCP4_O_DHCP6_ENABLE and OPTION_DHCP4_O_DHCP6_SERVER in the ORO.
> 

[Qi] RFC3315 says that the client SHOULD use unicast if instructed by the server. In this document, if the client doesn't include this option, it can still work (using multicast). So I think it's SHOULD for the OPTION_DHCP4_O_DHCP6_SERVER.

> - The server responds with zero (if DHCPv4-over-DHCPv6 is not available) or one of two options. Never both.
> If this makes sense, then I would rename the options: s/ENABLE/MULTICAST/ and s/SERVER/UNICAST/. And maybe go further and kill OPTION_DHCP4_O_DHCP6_ENABLE, and just put the multicast address in the payload of OPTION_DHCP4_O_DHCP6_SERVER.

[Qi] The multicast address is a well-known address in RFC3315. The client knows it even you don't tell the client. I don't think it necessary to put the multicast address into the option. 

> 
> By the way, a suggestion for the document: replace all instances of "4o6 Server Address option" with the full option name, "OPTION_DHCP4_O_DHCP6_SERVER". Always using the same terminology makes it much easier to grep the document.

[Qi] Thanks for the suggestion! IMHO, the "4o6 Server Address option" is the name of the option, while the OPTION_DHCP4_O_DHCP6_SERVER is the option code to be assigned by the IANA. What I get from RFC3315 is that when you refer to an option, use the name; if you want to mention the code, then use the uppercase phrase.
But I will check to wording to make sure the document uses the same terminology.

Best Regards,
Qi

---

From: Simon Perreault <[email-masked]>
Date: Wed, 27 Nov 2013 13:03:29 -0500

Le 2013-11-27 11:03, Marcin Siodelski a écrit :
> send minimal amount of information to the client (boolean option).

What if you want to use a different multicast address than the 
well-known one?

> If
> problem of presence of both multicast and unicast etc.

I think that implementation-wise they're pretty much the same 
complexity. The gain would be in one less option to define, which would 
make the document shorter and easier to understand.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Wed, 27 Nov 2013 13:09:49 -0500

Le 2013-11-27 11:18, Qi Sun a écrit :
> [Qi] RFC3315 says that the client SHOULD use unicast if instructed by
> the server. In this document, if the client doesn't include this option,
> it can still work (using multicast). So I think it's SHOULD for the
> OPTION_DHCP4_O_DHCP6_SERVER.

Let me repeat: You don't want to have a server sending an option that 
was not requested by the client. Stay with the usual ORO model.

Please explain why deviating from the usual ORO model is warranted.

>> - The server responds with zero (if DHCPv4-over-DHCPv6 is not
>> available) or one of two options. Never both.
>> s/ENABLE/MULTICAST/ and s/SERVER/UNICAST/. And maybe go further and
>> kill OPTION_DHCP4_O_DHCP6_ENABLE, and just put the multicast address
>> in the payload of OPTION_DHCP4_O_DHCP6_SERVER.
>
> [Qi] The multicast address is a well-known address in RFC3315. The
> client knows it even you don't tell the client. I don't think it
> necessary to put the multicast address into the option.

I did not argue that it was necessary to tell the multicast address to 
the client. I did argue that it was simpler to have only one option.

>> By the way, a suggestion for the document: replace all instances of
>> "4o6 Server Address option" with the full option name,
> [Qi] Thanks for the suggestion! IMHO, the "4o6 Server Address option" is
> the name of the option, while the OPTION_DHCP4_O_DHCP6_SERVER is the
> option code to be assigned by the IANA. What I get from RFC3315 is that
> when you refer to an option, use the name; if you want to mention the
> code, then use the uppercase phrase.

Sure, it is common practice, but it still makes the document harder to 
grep. But this is just an editorial suggestion, I don't care much. Feel 
free to ignore it.

Simon

---

From: Marcin Siodelski <[email-masked]>
Date: Wed, 27 Nov 2013 19:42:29 +0100

On Wed, Nov 27, 2013 at 7:03 PM, Simon Perreault
<[email-masked]> wrote:
> What if you want to use a different multicast address than the well-known
> one?

The section "4. Architecture Overview" of the draft says:
" Typically, a 4o6 DHCP client communicates with the 4o6 DHCP servers
   using well known All_DHCP_Relay_Agents_and_Servers multicast address."

Also section "8.  4o6 DHCP Client Behavior" says:
   o  If the client receives the DHCPv4-over-DHCPv6 Enable Option but no
      4o6 Servers Address Option, it SHOULD enable the DHCPv4-over-
      DHCPv6 function, and use IPv6 All_DHCP_Relay_Agents_and_Servers
      multicast address to communicate with servers and relays.

The document assumes that there is only one multicast address that the
client uses. Why would client use any other multicast address? The
All_DHCP_Servers address is rather used by relays, not clients.

> I think that implementation-wise they're pretty much the same complexity.
> The gain would be in one less option to define, which would make the
> document shorter and easier to understand.
>

It would make a document shorter and easier in one section but would
make it longer and more complex in the other: how should client behave
receiving both unicast and multicast address, for instance? Also, it
should then give more thought to the security section.

The implementation complexity can be pretty much the same in that, you
can reuse the code which validates the unicast address list for
multicast case, yes. But it still doesn't solve the other problem
given above. Client doesn't have to check consistency of the addresses
if it receives the simple boolean-type option:
- duplicated unicast addrs
- more than one multicast
- invalid multicast
- both multicast and unicast present

If the document is unclear or ambiguous in the part that describes the
client's behavior when it receives two options, we should work to make
it clearer.

Marcin

---

From: Simon Perreault <[email-masked]>
Date: Wed, 27 Nov 2013 14:06:10 -0500

> All_DHCP_Servers address is rather used by relays, not clients.

You're right. Thanks for the answer.

> - both multicast and unicast present

Right, but you're comparing run-time complexity with implementation 
complexity.

Run-time complexity does not matter: it's of no importance to anyone how 
many ifs are traversed at run-time. Running the checks every time would 
not impact in any measurable way the CPE's performance.

It's implementation complexity that matters. We want implementers to 
spend less time coding this protocol, and we want to eliminate 
opportunities that they get it wrong.

We agree that the checks that need to be written with the one-option 
proposal also need to be written with the two-option proposal. So code 
size-wise, the proposals are pretty much equivalent. But having just one 
code path means it's easier to understand and easier to test. And it 
makes the doc simpler and shorter.

> client's behavior when it receives two options, we should work to make

I think that part is clear.

Simon

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 27 Nov 2013 19:24:18 +0000

I had suggested (perhaps privately) that at least in my mind, having a single option would be so much better.

The option can return a list of N IPv6 addresses where N can be 0.

If the option is returned with no IPv6 addresses, then it means enabled but with standard multicast.

If the option is returned with one or more addresses, then it means sent to those addresses (whether unicast or multicast - why does the sender care).

If the option is NOT returned, it means that the service is disabled.

Now, one issue against this is that it may be a bit unusual for servers to support an option with 0 or more IPv6 addresses? If that is a problem for a particular server, then one possibility is just configure it with one address - the All_DHCP_Relay_Agents_and_Servers. (I don't see a reason to prohibit this value from being included; it just isn't required as it can be implied by sending no addresses.)

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Wednesday, November 27, 2013 1:10 PM
To: Qi Sun
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

Le 2013-11-27 11:18, Qi Sun a écrit :
> the server. In this document, if the client doesn't include this 
> option, it can still work (using multicast). So I think it's SHOULD 
> for the OPTION_DHCP4_O_DHCP6_SERVER.

Let me repeat: You don't want to have a server sending an option that was not requested by the client. Stay with the usual ORO model.

> necessary to put the multicast address into the option.

I did not argue that it was necessary to tell the multicast address to the client. I did argue that it was simpler to have only one option.

>> "OPTION_DHCP4_O_DHCP6_SERVER". Always using the same terminology 
>> makes it much easier to grep the document.
>
> [Qi] Thanks for the suggestion! IMHO, the "4o6 Server Address option" 
> is the name of the option, while the OPTION_DHCP4_O_DHCP6_SERVER is 
> the option code to be assigned by the IANA. What I get from RFC3315 is 
> that when you refer to an option, use the name; if you want to mention 
> the code, then use the uppercase phrase.

Sure, it is common practice, but it still makes the document harder to grep. But this is just an editorial suggestion, I don't care much. Feel free to ignore it.

Simon

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 27 Nov 2013 19:28:01 +0000

I don't see a need to restrict the addresses allowed. Any IPv6 address should be valid.

If there is no address, you send to the standard All_DHCP_Relay_Agents_and_Servers multicast. But otherwise, the client can just send to those addresses.

There are source address selection issues here that are important and is pending an email about the draft I need to send. Obviously, the client's source address needs to be of the same or 'wider' scope than the destination address; otherwise, the responses may not make it back. This is a bit different than the RFC 3315 text which says to use the link-local source address.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Marcin Siodelski
Sent: Wednesday, November 27, 2013 1:42 PM
To: Simon Perreault
Cc: <[email-masked]>
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

The document assumes that there is only one multicast address that the client uses. Why would client use any other multicast address? The All_DHCP_Servers address is rather used by relays, not clients.

> document shorter and easier to understand.

It would make a document shorter and easier in one section but would make it longer and more complex in the other: how should client behave receiving both unicast and multicast address, for instance? Also, it should then give more thought to the security section.

The implementation complexity can be pretty much the same in that, you can reuse the code which validates the unicast address list for multicast case, yes. But it still doesn't solve the other problem given above. Client doesn't have to check consistency of the addresses if it receives the simple boolean-type option:
- duplicated unicast addrs
- more than one multicast
- invalid multicast
- both multicast and unicast present

If the document is unclear or ambiguous in the part that describes the client's behavior when it receives two options, we should work to make it clearer.

Marcin

---

From: Simon Perreault <[email-masked]>
Date: Wed, 27 Nov 2013 14:35:19 -0500

This is an even better proposal! I see nothing wrong with it. Thanks Bernie!

Simon

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 27 Nov 2013 19:35:24 +0000

Here's a question we can also ponder ...

Should we perhaps allow the server to send back the Server-Unicast option to tell the 4o6 Client where it can send unicast (DHCPv4) packets to? This would allow DHCPv4 unicast packets to be sent directly to the server (of course inside a BOOTREQUESTV6 message).

I'm not sure it is worth it (as RFC 5010 discusses issues related to server-id-override and the unicast flag addresses this).

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Bernie Volz (volz)
Sent: Wednesday, November 27, 2013 2:24 PM
To: Simon Perreault; Qi Sun
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Wednesday, November 27, 2013 1:10 PM
To: Qi Sun
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

Simon

---

From: <[email-masked]>
Date: Thu, 28 Nov 2013 08:28:34 +0100

+1. Definitely prefer a single option for this.

Ian

On 27/11/2013 20:24, "Bernie Volz (volz)" <[email-masked]> wrote:

>If the option is returned with one or more addresses, then it means sent
>to those addresses (whether unicast or multicast - why does the sender
>care).
>
>Now, one issue against this is that it may be a bit unusual for servers
>to support an option with 0 or more IPv6 addresses? If that is a problem
>for a particular server, then one possibility is just configure it with
>one address - the All_DHCP_Relay_Agents_and_Servers. (I don't see a
>reason to prohibit this value from being included; it just isn't required
>as it can be implied by sending no addresses.)
>
>- Bernie

---

From: Cong Liu <[email-masked]>
Date: Thu, 28 Nov 2013 15:31:43 +0800

Hi Bernie,

2013/11/28 Bernie Volz (volz) <[email-masked]>

> Should we perhaps allow the server to send back the Server-Unicast option
> to tell the 4o6 Client where it can send unicast (DHCPv4) packets to? This
> would allow DHCPv4 unicast packets to be sent directly to the server (of
> course inside a BOOTREQUESTV6 message).
>

Assume IPv6 lease time is 100s, and IPv4 lease time is 200s. Then the 4o6
Client receives a Server-Unicast option (which may contains 10 unicast
addresses) every 100s, and a Server-Unicast option (which contains 1
unicast address) every 200s. I think it adds more complexity for client to
deal with the same option from different servers (DHCPv6 / DHCP4o6).

Best Regards,
Cong

---

From: Branimir Rajtar <[email-masked]>
Date: Thu, 28 Nov 2013 13:34:13 +0000

> +1. Definitely prefer a single option for this.

I totally agree, in my opinion, it's always good to make it as simple as possible, especially since it's already quite hard to keep track of everything...

Branimir

> >If the option is returned with one or more addresses, then it means
> >sent to those addresses (whether unicast or multicast - why does the
> >sender care).
> >
> >to support an option with 0 or more IPv6 addresses? If that is a
> >problem for a particular server, then one possibility is just configure
> >it with one address - the All_DHCP_Relay_Agents_and_Servers. (I don't
> >see a reason to prohibit this value from being included; it just isn't
> >required as it can be implied by sending no addresses.)
> >
> >- Bernie
> 

<HTML><P><FONT face=Arial color=#999999 size=1>

IZJAVA O ODRICANJU ODGOVORNOSTI: Sadržaj ove poruke i eventualno priloženih datoteka je povjerljiv i namijenjen je samo osobama ili subjektima koji su navedeni u adresi. Ukoliko ste primili ovu poruku greškom, molimo Vas, obavijestite pošiljatelja, a poruku i sve njene privitke odmah, bez čitanja, trajno uklonite s računala. Bilo kakvo prenošenje, kopiranje ili distribucija informacija sadržanih u poruci trećim osobama je zabranjeno i može biti zakonski kažnjivo. Sadržaj, stavovi i mišljenja izneseni u poruci su autorovi i ne predstavljaju nužno stavove HT - Hrvatskih telekomunikacija d.d. HT ne prihvaća nikakvu odgovornost za eventualnu štetu nastalu primitkom ove poruke i priloga sadržanih u poruci.

</FONT></P><P><FONT face=Arial color=#999999 size=1>

 DISCLAIMER:The contents of this email as well as any files attached to it are confidential and intended solely for individuals or entities which they are addressed to. If you have received this email message in error, please notify the sender and permanently remove the message and all attached files from the computer. Any disclosure, copying or distribution of all or a part of information contained herein to or by third parties is prohibited and may be unlawful. Please note that any views or opinions presented in this message are solely those of the author and do not necessarily represent the views and opinions of Croatian Telecom Inc. Croatian Telecom Inc. accepts no liability for any potential damage caused by this message and files attached to it.

</FONT></P></HTML>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 28 Nov 2013 14:13:14 +0000

Cong, I don't understand this. Server-unicast option can only specify one address.

The 4o6 client has two lists - the "broadcast" list and the "unicast" list. When v4 packet is to be "broadcast", the "broadcast" list is used. When unicast and the unicast list is not empty, it is used; otherwise broadcast list is used. Broadcast list comes from new 4o6 option or the v6 multicast address. Unicast list is empty unless the server's v4 lease that was selected sent a server-unicast option.

Yes, if v4 client sends broadcast, packet could go to multiple servers but that's what happens with native v4.

Anyway, just a thought to reduce traffic for v4 unicast case.

- Bernie (from iPad)

On Nov 28, 2013, at 2:32 AM, "Cong Liu" <[email-masked]<mailto:[email-masked]>> wrote:

Hi Bernie,

2013/11/28 Bernie Volz (volz) <[email-masked]<mailto:[email-masked]>>
Here's a question we can also ponder ...

Assume IPv6 lease time is 100s, and IPv4 lease time is 200s. Then the 4o6 Client receives a Server-Unicast option (which may contains 10 unicast addresses) every 100s, and a Server-Unicast option (which contains 1 unicast address) every 200s. I think it adds more complexity for client to deal with the same option from different servers (DHCPv6 / DHCP4o6).

Best Regards,
Cong

---

From: Cong Liu <[email-masked]>
Date: Thu, 28 Nov 2013 23:43:41 +0800

Hi Bernie,

Sorry, I thought you were talking about reuse 4o6 Server Address option.

If regular DHCPv6 process is not affected by reusing Server Unicast option,
I think it's a good solution.

Cong

>  The 4o6 client has two lists - the "broadcast" list and the "unicast"
> list. When v4 packet is to be "broadcast", the "broadcast" list is used.
> When unicast and the unicast list is not empty, it is used; otherwise
> broadcast list is used. Broadcast list comes from new 4o6 option or the v6
> multicast address. Unicast list is empty unless the server's v4 lease that
> was selected sent a server-unicast option.
>
> On Nov 28, 2013, at 2:32 AM, "Cong Liu" <[email-masked]> wrote:
>
>   Hi Bernie,
>
>  Assume IPv6 lease time is 100s, and IPv4 lease time is 200s. Then the
> 4o6 Client receives a Server-Unicast option (which may contains 10
> unicast addresses) every 100s, and a Server-Unicast option (which
> contains 1 unicast address) every 200s. I think it adds more complexity for
> client to deal with the same option from different servers (DHCPv6 /
> DHCP4o6).
>
>  Best Regards,
> Cong
>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 28 Nov 2013 16:20:28 +0000

The Server-Unicast option (if this is adopted) would be in the BOOTREPLYV6 which is processed by the 4o6 DHCP Client and does not impact the normal DHCPv6 transactions. (The 4o6 DHCP Client would request this in the ORO in the BOOTREQUESTV6.)

I'm not sure if this is worth it. But just figured I'd suggest it.

-          Bernie

From: dhcwg [mailto:[email-masked]] On Behalf Of Cong Liu
Sent: Thursday, November 28, 2013 10:44 AM
To: Bernie Volz (volz)
Cc: [email-masked]
Subject: Re: [dhcwg] WGLC for draft-ietf-dhc-dhcpv4-over-dhcpv6-03 - Respond by Dec 9, 2013

Hi Bernie,

If regular DHCPv6 process is not affected by reusing Server Unicast option, I think it's a good solution.

Cong

- Bernie (from iPad)

Best Regards,
Cong

dhcwg mailing list

---

From: Simon Perreault <[email-masked]>
Date: Thu, 28 Nov 2013 11:27:08 -0500

Le 2013-11-28 11:20, Bernie Volz (volz) a écrit :
> The Server-Unicast option (if this is adopted) would be in the
> BOOTREPLYV6 which is processed by the 4o6 DHCP Client and does not
> impact the normal DHCPv6 transactions. (The 4o6 DHCP Client would
> request this in the ORO in the BOOTREQUESTV6.)
>
> I’m not sure if this is worth it. But just figured I’d suggest it.

My take: it's an interesting potential optimization, but it seems we 
don't really know if we need it or not. When in doubt, leave it out.

Simon