Subject: Re: [dhcwg] DHCPv6 Server Option in RA

From: Xu Xiaohu <[email-masked]>
Date: Thu, 04 Feb 2010 15:38:28 +0800

By the way, there is a statement in section 15. Message Validation of
RFC3315
   "A server MUST discard any Solicit, Confirm, Rebind or
   Information-request messages it receives with a unicast destination
   address."

Can anybody please tell me the reason why the DHCP server MUST discard
Information-request messages it receives with a unicast destination address.

Best wishes,
Xiaohu

> -----邮件原件-----
> 发件人: Xu Xiaohu [mailto:[email-masked]]
> 发送时间: 2010年1月29日 9:47
> 收件人: [email-masked]'
> 主题: FWD: DHCPv6 Server Option in RA
> 
> 
> 
> Hi all,
> 
> Since the following discussion is related to DHCPv6, especially stateless
> DHCPv6, I forward it here.
> 
> Any comment is appreciated!
> 
> Best wishes,
> Xiaohu
> 
> > -----邮件原件-----
> > 发件人: Xu Xiaohu [mailto:[email-masked]]
> > 发送时间: 2010年1月28日 12:15
> > 收件人: 'IETF IPv6 Mailing List'
> > 主题: DHCPv6 Server Option in RA
> >
> > Hi all,
> >
> > In a scenario where hosts have obtained IPv6 addresses through some
other
> > mechanism, such as stateless address auto-configuration or manual
> > configuration while other configuration parameters (e.g., recursive DNS
> > servers)are learnt via stateless DHCPv6 [RFC 3736], would it be better
for
> these
> > hosts to obtain the DHCPv6 server addresses via a new RA option in
advance?
> > Thus these hosts could directly send unicast DHCP Information-request
> messages
> > to the stateless DHCP server without the need of DHCP relay agent
between
> the
> > client and server. As a result, delays due to the relaying of messages
by
> relay
> > agents, as well as overhead and duplicate responses by servers due to
the
> > delivery of client messages to multiple servers can be avoided.
> >
> > Meanwhile, I noticed there is a statement about unicast DHCP request in
the
> > DHCPv6 specification [RFC 3315] as follows:
> >    "When the server receives a Request message via unicast from a client
> >    to which the server has not sent a unicast option, the server
> >    discards the Request message and responds with a Reply message
> >    containing a Status Code option with the value UseMulticast, a Server
> >    Identifier option containing the server's DUID, the Client Identifier
> >    option from the client message, and no other options."
> >
> > Unless the unicast option is not available for all clients, I believe it
would
> > conflict with the basic principle of stateless DHCP that DHCP server
needs
> not
> > to maintain per host state.
> >
> > There is another statement about the unicast DHCP request in RFC 3315 as
> > follows:
> >       " ...Use of unicast may avoid delays due to the relaying of
messages
> by
> >       relay agents, as well as avoid overhead and duplicate responses by
> >       servers due to the delivery of client messages to multiple
> >       servers.  Requiring the client to relay all DHCP messages through
> >       a relay agent enables the inclusion of relay agent options in all
> >       messages sent by the client.  The server should enable the use of
> >       unicast only when relay agent options will not be used. "
> >
> > Judging from the above statement, especially the last sentence, it seems
that
> > the relay agent is preferred. Then what's the reason for that
preference?
> To
> > prevent flood attack on the DHCP server? If the answer is yes, then as
for
> > stateless DHCP, it seems that such attacks are not much serious since
the
> > stateless DHCP server doesn't need to maintain any dynamic state for
> individual
> > clients. At least, not worse than flood attacks on DNS servers.
> >
> > Comments?
> >
> > Xiaohu

---

From: Ted Lemon <[email-masked]>
Date: Thu, 4 Feb 2010 08:57:33 -0500

> Information-request messages it receives with a unicast destination address.

Because the server doesn't know the source network--the packet didn't go through any relay agents, and any topology information is lost.   It's a huge problem in DHCPv4.

---

From: "Wes Beebee (wbeebee)" <[email-masked]>
Date: Thu, 4 Feb 2010 07:57:57 -0600

I suspect that you may have problems not going through some DHCPv6 Relays because there are some routers which use the DHCPv6 Relay as a traffic forwarding validating authority.  If you try to bypass the Relay by sending traffic directly, and that traffic is not snooped, then you may end up with no network connectivity. 

Wes Beebee
Software Engineer
Product Development
[email-masked]

United States
Cisco.com - http://www.cisco.com
For corporate legal information go to:
http://www.cisco.com/web/about/doing_business/legal/cri/index.html

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xu Xiaohu
Sent: Thursday, February 04, 2010 2:38 AM
To: [email-masked]
Subject: Re: [dhcwg] DHCPv6 Server Option in RA

Can anybody please tell me the reason why the DHCP server MUST discard Information-request messages it receives with a unicast destination address.

Best wishes,
Xiaohu

> Since the following discussion is related to DHCPv6, especially 
> stateless DHCPv6, I forward it here.
> 
other
> > configuration while other configuration parameters (e.g., recursive 
> > DNS servers)are learnt via stateless DHCPv6 [RFC 3736], would it be 
> > better
for
advance?
between
by
the
the
would
needs
messages
that
preference?
for
the
> > clients. At least, not worse than flood attacks on DNS servers.

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

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 05 Feb 2010 09:05:54 +0800

> -----邮件原件-----
> 发件人: Ted Lemon [mailto:[email-masked]]
> 发送时间: 2010年2月4日 21:58
> 收件人: Xu Xiaohu
> 抄送: [email-masked]
> 主题: Re: [dhcwg] DHCPv6 Server Option in RA
> 
address.
> 
> Because the server doesn't know the source network--the packet didn't go
> through any relay agents, and any topology information is lost.   It's a
huge
> problem in DHCPv4.

However, the information-request is intended for stateless DHCPv6 which
doesn't perform address assignment. Hence, it seems no problem that the
stateless DHCPv6 server doesn't know the source network of the client.
Correct?

Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 05 Feb 2010 09:35:16 +0800

> -----邮件原件-----
> 发件人: Wes Beebee (wbeebee) [mailto:[email-masked]]
> 发送时间: 2010年2月4日 21:58
> 收件人: Xu Xiaohu; [email-masked]
> 主题: RE: [dhcwg] DHCPv6 Server Option in RA
> 
> I suspect that you may have problems not going through some DHCPv6 Relays
> because there are some routers which use the DHCPv6 Relay as a traffic
> forwarding validating authority.  If you try to bypass the Relay by
sending
> traffic directly, and that traffic is not snooped, then you may end up
with
> no network connectivity.

Stateless DHCPv6 [RFC3736] is used by nodes to obtain configuration
information (e.g., the addresses of DNS recursive name servers), other than
address assignment. That's to say, the nodes have already obtained the
addresses through some other mechanisms, e.g., SLAAC [RFC2462] or manually
configuration. 

Address Admission Control can only be achieved by snooping or relaying the
stateful DHCP messages which is used for address assignment. The
Information-request message is only used for stateless DHCP. So I don't
believe it's much necessary for the router (i.e., the default gateway) to
relay the Information-request message. Besides, I think unicasting
information-request message will not end up with no network connectivity.

Comments?

Xiaohu

> From: [email-masked] [mailto:[email-masked]] On Behalf Of
Xu
address.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 5 Feb 2010 16:45:48 -0600

>stateless DHCPv6 server doesn't know the source network of the client.

The source network of the client can be derived from the source address of the client, so it really has little to do with this. (The source network may be useful in selecting appropriate options to return to the client, such as DNS server and search lists, etc.)

The main reason is, as I think has been pointed out, that in DHCPv4 not having the relay agent options often caused issues for determining the type of client and what to return to it (this was a particular issue in DOCSIS deployments). Some device types need different information.

Does this apply for all networks and client types, NO. But there are several where it has mattered and DHCPv4's bypassing the relay agent complicated things. So, in DHCPv6 we wanted to keep the model simple and avoid these kinds of pitfalls.

Note that in IPv6 we also have full multicast support and this multicast traffic is just link-local (the relay will usually unicast the packet to the server).

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xu Xiaohu
Sent: Thursday, February 04, 2010 8:06 PM
To: 'Ted Lemon'
Cc: [email-masked]
Subject: Re: [dhcwg] DHCPv6 Server Option in RA

address.
huge

Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 08 Feb 2010 11:15:19 +0800

> -----邮件原件-----
> 发件人: Bernie Volz (volz) [mailto:[email-masked]]
> 发送时间: 2010年2月6日 6:46
> 收件人: Xu Xiaohu; Ted Lemon
> 抄送: [email-masked]
> The source network of the client can be derived from the source address of
the
> client, so it really has little to do with this. (The source network may
be
> useful in selecting appropriate options to return to the client, such as
DNS
> server and search lists, etc.)
> 
> The main reason is, as I think has been pointed out, that in DHCPv4 not
having
> the relay agent options often caused issues for determining the type of
client
> and what to return to it (this was a particular issue in DOCSIS
deployments).
> Some device types need different information.

Hi Bernie,

Thank you for this information.

For some other scenarios where the relay agent is not a must (e.g., the
device type is irrelevant to the configuration information selection), the
client could directly exchange messages with the server in unicast. In this
way, the rogue DHCP server problem can be eliminated. Besides, this approach
can eliminate the latencies imposed by relay agents and prevent the client
from receiving redundant responses from multiple DHCP servers. Hence, isn't
it worthwhile to explore such an option?

Xiaohu

> Does this apply for all networks and client types, NO. But there are
several
> where it has mattered and DHCPv4's bypassing the relay agent complicated
things.
> So, in DHCPv6 we wanted to keep the model simple and avoid these kinds of
> pitfalls.
> 
> Note that in IPv6 we also have full multicast support and this multicast
traffic
> is just link-local (the relay will usually unicast the packet to the
server).
Xu

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sun, 7 Feb 2010 22:50:38 -0600

>Hence, isn't it worthwhile to explore such an option?

I don't think there is.

1. Unicast offers no redundancy - so if the target server is down, client never gets an answer.

2. UDP packets are easy enough for an attacker to monitor and forge so any 'security' argument is really bogus.

3. Latency for relays ... if you're worried about that, you'd also worry about the forwarding costs for routers because in most cases your routers are your relays. And, implementing a stateless server on those routers isn't that difficult and would solve that issue as the clients would then multicast with the relay (router) responding to the client directly.

So, I see no strong arguments in favor of exploring such an option.

- Bernie

-----Original Message-----
From: Xu Xiaohu [mailto:[email-masked]] 
Sent: Sunday, February 07, 2010 10:15 PM
To: Bernie Volz (volz); 'Ted Lemon'
Cc: [email-masked]
Subject: re: [dhcwg] DHCPv6 Server Option in RA

the
be
DNS
having
client
deployments).

Hi Bernie,

Xiaohu

several
things.
traffic
server).
Xu

---

From: Xu Xiaohu <[email-masked]>
Date: Tue, 09 Feb 2010 09:18:44 +0800

> 发送时间: 2010年2月8日 12:51
> 1. Unicast offers no redundancy - so if the target server is down, client
never
> gets an answer.

The DHCP Server option contains a list of DHCPv6 server addresses.

> 'security' argument is really bogus.

Unicast messages are more difficult to intercept than multicast messages.
Therefore, if a client uses unicast to contact DHCP servers, the security
issues caused by rogue DHCP server can be mitigated to some extent.

> 3. Latency for relays ... if you're worried about that, you'd also worry
about
> the forwarding costs for routers because in most cases your routers are
your
> relays. And, implementing a stateless server on those routers isn't that
> difficult and would solve that issue as the clients would then multicast
with
> the relay (router) responding to the client directly.

There is a difference in delay between forwarding packets directly on the
data plane and relaying DHCP messages on the control plane. In a situation
where a burst of DHCP multicast messages are received by the DHCP relay
agent, due to process capability limitation, not all the DHCP messages can
be relayed successfully. On the contrary, unicast DHCP messages can be
forwarded at line rate to the servers by the above device.

By the way, a new draft about the stateless DHCP server option is available
at http://tools.ietf.org/html/draft-xu-ipv6-ra-dhcp-server-option-00. Any
further comment is appreciated.

Best wishes,
Xiaohu

---

From: Ted Lemon <[email-masked]>
Date: Tue, 9 Feb 2010 10:06:00 -0500

On Feb 8, 2010, at 1:41 AM, Dacheng Zhang wrote:
> I think it largely depends on how people design the systems. Redundancy can
> be easily achieved by sending unicast packets to multiple different DHCP
> servers, either simultaneously or in a sequence. The client can get the IP
> addresses of multiple DHCP servers from the option.

Sure, but this is a pretty major change to the DHCPv6 protocol, to solve a problem that's solved just as well by the existing protocol.   Hence, no reason to do the work.

---

From: "David W. Hankins" <[email-masked]>
Date: Tue, 9 Feb 2010 10:43:53 -0800

On Sun, Feb 07, 2010 at 10:50:38PM -0600, Bernie Volz (volz) wrote:
> never gets an answer.

A well-understood (and somewhat used in DHCPv4) mechanism for unicast
UDP redundancy is to use "anycast" addresses; where a number of DHCP*
servers are given the same IP address.  If the server is "up", it is
participating in routing, and the packet is delivered to the closest
server.  If it is "down", the route is revoked and the packet moves
on to the next nearest.

This has the obvious advantage in reducing the work on the part of
the (N) servers; only one receives and responds, reducing load on
the others.

Because Information-Request message processing is so minor, however,
it isn't really a commanding benefit to DHCP...

-- 
David W. Hankins	BIND 10 needs more DHCP voices.
Software Engineer		There just aren't enough in our heads.
Internet Systems Consortium, Inc.		http://bind10.isc.org/