Subject: [dhcwg] WGLC: draft-ietf-dhc-dhcpv4-over-ipv6

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Oct 2012 14:05:33 +0000

The authors have requested a new working group last call on this document.   The document has been updated based on feedback received during the previous working group last call.   The authors would appreciate review and feedback on this document.   If you favor advancing it, please say so on the mailing list.   If you oppose advancing it, also please say so and say why.

We will evaluate consensus on November 1.

Thanks!

---

From: Simon Perreault <[email-masked]>
Date: Thu, 18 Oct 2012 10:14:36 -0400

Le 2012-10-18 10:05, Ted Lemon a écrit :
> The authors have requested a new working group last call on this
> document.   The document has been updated based on feedback received
> during the previous working group last call.   The authors would
> appreciate review and feedback on this document.   If you favor
> advancing it, please say so on the mailing list.   If you oppose
> advancing it, also please say so and say why.

I favour advancing, but there's a technical issue: the draft does not 
specify how unicast DHCP requests are handled. Specifically in the case 
of an LCRA, if nothing is done the LCRA will only get broadcast packets 
while unicast packets will be sent directly to the DHCP server over 
IPv4, bypassing the LCRA. Unless the LCRA is somehow in the unicast path 
and is inspecting all packets, which is something you want to avoid for 
scalability and good architecture reasons.

Suggestion: the LCRA could insert a Server Identifier Override relay 
sub-option [RFC5107] with its own address to make the client unicast 
further requests directly to the LCRA. The result would be that both 
broadcast and unicast DHCP messages would be converted to IPv6.

With this change, the draft would be ready to go IMHO.

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: Ted Lemon <[email-masked]>
Date: Thu, 18 Oct 2012 15:31:46 +0000

On Oct 18, 2012, at 10:14 AM, Simon Perreault <[email-masked]> wrote:
> I favour advancing, but there's a technical issue: the draft does not specify how unicast DHCP requests are handled. Specifically in the case of an LCRA, if nothing is done the LCRA will only get broadcast packets while unicast packets will be sent directly to the DHCP server over IPv4, bypassing the LCRA. Unless the LCRA is somehow in the unicast path and is inspecting all packets, which is something you want to avoid for scalability and good architecture reasons.

Renewals would automatically go down the tunnel, so unless the tunnel doesn't provide a route to the DHCP server, I don't think this is a problem.   Am I missing something?

---

From: Peng Wu <[email-masked]>
Date: Thu, 18 Oct 2012 23:34:28 +0800

Hi simon

> specify how unicast DHCP requests are handled. Specifically in the case of
> an LCRA, if nothing is done the LCRA will only get broadcast packets while
> unicast packets will be sent directly to the DHCP server over IPv4,
> bypassing the LCRA. Unless the LCRA is somehow in the unicast path and is
> inspecting all packets, which is something you want to avoid for scalability
> and good architecture reasons.
The current draft kind of leave the unicast DHCP requests as it is.
For example, in public 4over6 case where a tunnel is provided,
it reaches the server id address through the tunnel.
While in implmentation, a server can chose to forbid the server id
option and force the client to broadcast DHCP request.

> sub-option [RFC5107] with its own address to make the client unicast further
> requests directly to the LCRA. The result would be that both broadcast and
> unicast DHCP messages would be converted to IPv6.
I haven't check RFC5107 yet but this also sounds possible. Will think
this through.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 18 Oct 2012 11:35:18 -0400

> Renewals would automatically go down the tunnel, so unless the tunnel doesn't provide a route to the DHCP server, I don't think this is a problem.   Am I missing something?

Yes you're missing something. ;)

The message would indeed go down the tunnel to the server. But remember 
that the CPE only has a partial IPv4 address on that tunnel interface. 
Messages sent from the server to the CPE's IPv4 address at port 68 will 
reach the CPE whose port range includes 68, not necessarily the CPE that 
sent the request. The result is that messages from client to server will 
work, but the reply will be lost.

Simon

---

From: Ted Lemon <[email-masked]>
Date: Thu, 18 Oct 2012 15:44:36 +0000

On Oct 18, 2012, at 11:35 AM, Simon Perreault <[email-masked]>
 wrote:
> The message would indeed go down the tunnel to the server. But remember that the CPE only has a partial IPv4 address on that tunnel interface. Messages sent from the server to the CPE's IPv4 address at port 68 will reach the CPE whose port range includes 68, not necessarily the CPE that sent the request. The result is that messages from client to server will work, but the reply will be lost.

Ah, I see.   You are talking about lightweight 4over6.   This is indeed a problem, but only when address sharing is in use.   The dhcpv4-over-ipv6 draft is a general-purpose document, not specifically for lightweight 4over6.   So I recommended to the authors that they address this use case in a separate document, since this document was quite far along in the publication process when the address sharing issue came up.

But of course this recommendation is just my personal recommendation—if the working group would prefer to fold the address pool work into this document, I don't have any objection.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 18 Oct 2012 11:53:34 -0400

Le 2012-10-18 11:44, Ted Lemon a écrit :
> On Oct 18, 2012, at 11:35 AM, Simon Perreault
> <[email-masked]> wrote:
>> The message would indeed go down the tunnel to the server. But
>> remember that the CPE only has a partial IPv4 address on that
>> tunnel interface. Messages sent from the server to the CPE's IPv4
>> address at port 68 will reach the CPE whose port range includes 68,
>> not necessarily the CPE that sent the request. The result is that
>> messages from client to server will work, but the reply will be
>> lost.
>
> Ah, I see.   You are talking about lightweight 4over6.

Right. Sorry for not realizing that my issue was specific to LW4o6.

> This is
> indeed a problem, but only when address sharing is in use.   The
> dhcpv4-over-ipv6 draft is a general-purpose document, not
> specifically for lightweight 4over6.   So I recommended to the
> authors that they address this use case in a separate document, since
> this document was quite far along in the publication process when the
> address sharing issue came up.

Makes sense to me.

But I would still appreciate if a paragraph was added to explain what 
happens to unicast messages. Namely, that an LCRA will not see them, and 
that they will take the regular IPv4 path.

In addition, the draft should say that an HCRA MUST NOT convert unicast 
messages to IPv6, the reason being that you want LCRA and HCRA to 
exhibit similar behaviour.

Thanks,
Simon