Subject: [Softwires] Is tunnelling DHCP multicast messages in 6rd unicast tunnel to BR acceptable for DHCP redundancy?//re: About draft-guo-softwire-6rd-ipv6-config-00

From: Xu Xiaohu <[email-masked]>
Date: Mon, 09 Aug 2010 11:59:52 +0800

Hi all,

(Since how to run stateless DHCPv6 in 6rd scenario is also related to DHC
WG, I copy this email to DHC WG mailing-list).

There are two options now for running DHCPv6 in 6rd scenario:

1) The CPE as a DHCP relay agent sends the DHCP-relay-forward message to
ALL-DHCP-SERVER/RELAY multicast address. The only available way of
forwarding multicast in 6rd is to tunnel this multicast DHCP message to the
BR which acts as a DHCP server/relay. If a 6rd SP deployed multiple BRs for
load-balancing (by using anycast), each BR should be enabled as a DHCP
server or a DHCP relay agent. In addition, in case that the DHCP
server/relay on a given BR is unavailable due to some reason (e.g., no
available address in the pool) but the other functions of it (e.g., the
anycast route for it) are still available, once the DHCP message is tunneled
to that BR, the DHCP service is unavailable any more. That's to say, it's
hard to achieve the high availability for DHCP servers/relay agents since
the DHCP information-request can not be relayed to other DHCP
servers/relays.
I wonder whether this option is acceptable from the perspective of DHCP
redundancy requirement.

2) The CPE as a DHCP relay agent sends the DHCP-relay-forward message to one
of the learnt DHCP server (unicast) addresses. Since 6rd can support unicast
flexible, the DHCP server can be located either on/behind any BR or behind a
6rd CPE which is owned by the 6rd SP. In comparison with the first option,
this option has no special limitation. Of course, the CPE needs to learn the
DHCPv6 server addresses through a new DHCPv4 option. For more details,
please see draft-guo-softwire-6rd-ipv6-config-00.

Best wishes,
Xiaohu

> -----邮件原件-----
> 发件人: Xu Xiaohu [mailto:[email-masked]]
> 发送时间: 2010年8月3日 16:59
> 收件人: 'Ole Troan'
> 抄送: [email-masked]'
> 主题: re: [Softwires] About draft-guo-softwire-6rd-ipv6-config-00
> 
> Hi Ole,
> 
> > -----邮件原件-----
> > 发件人: Ole Troan [mailto:[email-masked]] 代表 Ole Troan
> > 发送时间: 2010年8月2日 19:17
> > 收件人: xuxiaohu 41208
> > 抄送: [email-masked]
> > 主题: Re: [Softwires] About draft-guo-softwire-6rd-ipv6-config-00
> >
> > Xiaohu,
> >
> > > First, as stated in the DHCPv6 specification [RFC3315], "...The client
MUST
> > use a link-local address assigned to the interface for which it is
requesting
> > configuration information as the source address in the header of the IP
> > datagram." Since the link-local address can not travel through the 6rd
domain,
> > the CPE SHOULD act as a DHCPv6 relay agent. I think nobody will argue
against
> > this conclusion.
> >
> > do you only need "stateless" DHCPv6?
> > if so, I think the DHCPv6 specifications should loosen up on the
restrictions
> > of which source and destinations can be used. then you can just use a
global
> > address as a source and the IPv6 address of the BR as the relay/server.
(I
> > believe this was Townsley's proposal via IM during the softwires
meeting).
> 
> If the CPE could work as a DHCP relay agent which sends DHCP-relay-forward
> messages with its global IPv6 address being the source address, the DHCPv6
> specification doesn't need any change.
> 
> > > Second, as I mentioned during the presentation, relaying DHCP request
> > messages to All_DHCP_Servers multicast address by CPEs is not optimal in
6rd
> > scenario. Note that here what I said is "not optimal", rather than "not
> > possible". The CPE as a relay agent, could be upgraded to relay
> > information-request DHCPv6 messages (multicast) towards the 6rd BRs.
> However,
> > with this approach, the DHCPv6 servers would have to be located in the
IPv6
> > Interne
> > > t, rather than in a 6rd site which is owned by the 6rd SP. In
addition,
> this
> > usage will result in more traffic burden on the 6rd BRs.
> >
> > I don't quite see that this has to be the case. the DHCPv6 server can
obviously
> > also be part of the SP's network. it is just placed on an "IPv6 leg" of
the
> > BR or the BR acts as the DHCPv6 server. the multicast packets could very
well
> > be encapsulated in unicast L2 (IPv4) to the BR.
> 
> Yes, it works. However, it's not optimal. First, if a SP deployed multiple
BRs
> for load-balancing, each BR should be enabled as a DHCP server or a DHCP
relay
> agent. Second, in case that the DHCP server/relay on a given BR is
unavailable
> due to some reason but the other functions of it (e.g., the anycast route
for
> it) are still available, once the DHCP message is encapsulated in unicast
L2
> (IPv4) to that BR, the DHCP service is unavailable any more. That's to
say,
> it's hard to achieve the high availability for DHCP servers/relay agents.
> 
> > >
> > > Hence, we propose that the CPE as a DHCP relay agent, SHOULD know at
least
> > one DHCPv6 server address.
> >
> > of course, the other option is to just have a DNS proxy on the CPE.
> 
> Yes, in case that DNS is the only configuration information needed.
> 
> > in any case I would like to see these requirements in the next phase of
the
> > requirements for IPv6 routers in v6ops. and I'd like to start a
discussion
> in
> > DHC about this as well as some other clarifications needed for CPE
routers.
> Good idea.
> Best wishes,
> Xiaohu

---

From: Ted Lemon <[email-masked]>
Date: Sat, 14 Aug 2010 13:15:20 -0400

On Aug 8, 2010, at 11:59 PM, Xu Xiaohu wrote:
> In addition, in case that the DHCP

I don't see the problem here.   If you want redundancy, you should configure each BR to relay to more than one DHCP server.   This would be the default anyway, according to RFC3315 section 20, which requires the relay to multicast if not otherwise configured.

> 6rd CPE which is owned by the 6rd SP.

This is completely contrary to the recommendations in RFC3315, which require the client to multicast, and require any relays to multicast by default.   Trying to relay DHCPv6 traffic over an IPv4 transport seems needlessly complicated.   You have the tunnel--why not use it?

---

From: Xu Xiaohu <[email-masked]>
Date: Mon, 16 Aug 2010 09:29:36 +0800

> -----邮件原件-----
> 发件人: Ted Lemon [mailto:[email-masked]]
> 发送时间: 2010年8月15日 1:15
> 收件人: Xu Xiaohu
> 抄送: 'Ole Troan'; [email-masked]; [email-masked]
> 主题: Re: [dhcwg] Is tunnelling DHCP multicast messages in 6rd unicast
tunnel
> to BR acceptable for DHCP redundancy?//re: [Softwires] About
> draft-guo-softwire-6rd-ipv6-config-00
> 
> I don't see the problem here.   If you want redundancy, you should
configure
> each BR to relay to more than one DHCP server.   This would be the default
anyway,
> according to RFC3315 section 20, which requires the relay to multicast if
not
> otherwise configured.

However, the BR itself (no matter as a relay agent or a DHCP server) is a
single point of failure, especially in the case where the DHCP service on
the BR is unavailable while the route for it (anycast address) is still OK. 

> > flexible, the DHCP server can be located either on/behind any BR or
behind
> a
> This is completely contrary to the recommendations in RFC3315, which
require
> the client to multicast, and require any relays to multicast by default.
> Trying to relay DHCPv6 traffic over an IPv4 transport seems needlessly
> complicated.   You have the tunnel--why not use it?

Yes, the CPE could directly tunnel the DHCP request messages (multicast)
received from the clients to the nearest BR. However, since the source
addresses of these DHCP messages are link-local addresses, how could the BR
return the corresponding DHCP reply messages to the clients in the 6rd
scenario?

Best wishes,
Xiaohu

---

From: Xu Xiaohu <[email-masked]>
Date: Thu, 19 Aug 2010 13:27:27 +0800

tunnel
configure
anyway,
not
> otherwise configured.

Yes. However, the question is:  in most cases, should the unicast or the
multicast be preferred by the relay agents to relay the DHCP request message
if both of them are available? 

With multicast, many DHCP authentication mechanisms will not be available
any more, e.g., IPsec mechanism for securing the messages exchanged between
servers and relay agents, and CGA usage for DHCP server authentication. By
the way, is the 6rd domain deemed as a secure network for DHCP message
exchange?

I admit that the DHCP relay agent on the CPE could relay the
information-request message to ALL_SERVERS_OR_RELAY-AGENT_ADDRESS in a 6rd
tunnel towards a 6rd BR, However, is it actually an optimal choice? 

Best wishes,
Xiaohu

behind
require

---

From: Ted Lemon <[email-masked]>
Date: Thu, 19 Aug 2010 11:14:52 -0400

> the way, is the 6rd domain deemed as a secure network for DHCP message

I don't see how you would use IPsec for authenticating DHCP from the client--how would the client choose a security association?   Hm, okay, maybe that works because the client has the DHCP server's IP address.   Still, this doesn't seem to fit the problem very well--the client would have to go around with a long list of server IP addresses and security associations.

If CGA authentication is one of the major goals, a solution to this would be for the client to request a unicast response.   Servers that don't implement that would respond normally; servers that do implement it would respond via unicast to the client's unicast address, and could sign their response using CGA.   The client could also send a CGA-based signature along with the message containing the unicast request--since the CGA address the client would be providing will only work if it belongs to the client, this is useful authentication.

> tunnel towards a 6rd BR, However, is it actually an optimal choice? 

We have to remember that "optimal" can mean a lot of different things in this context.   I agree that in principal what you are proposing is optimal in some cases, but overall, I am concerned that it creates a lot of problems for a very small benefit--thus all the questions.

---

From: Xu Xiaohu <[email-masked]>
Date: Fri, 20 Aug 2010 10:57:08 +0800

> 发送时间: 2010年8月19日 23:15
tunnel
> I don't see how you would use IPsec for authenticating DHCP from the
client--how
> would the client choose a security association?   Hm, okay, maybe that
works

Here I'm talking about using IPsec between relay agents and servers.

> because the client has the DHCP server's IP address.   Still, this doesn't
seem
> to fit the problem very well--the client would have to go around with a
long
> list of server IP addresses and security associations.
> 
> If CGA authentication is one of the major goals, a solution to this would
be
> for the client to request a unicast response.   Servers that don't
implement
> that would respond normally; servers that do implement it would respond
via
> unicast to the client's unicast address, and could sign their response
using

As been said many times before, if the DHCP client or the relay agent has no
knowledge of intended DHCP servers and sends a DHCP message to the ALL
ALL_SERVERS_OR_RELAY-AGENT_ADDRESS, any DHCP server, even the rogue server
could send a unicast response with its own CGA signature. That is to say,
the CGA usage is almost meaningless in this case.

> CGA.   The client could also send a CGA-based signature along with the
message
> containing the unicast request--since the CGA address the client would be
> providing will only work if it belongs to the client, this is useful
> authentication.
> 
> We have to remember that "optimal" can mean a lot of different things in
this
> context.   I agree that in principal what you are proposing is optimal in
some
> cases, but overall, I am concerned that it creates a lot of problems for a
very
> small benefit--thus all the questions.

Here I just propose that the DHCP relay agent on a 6rd CPE could be
configured automatically with one or more DHCP server addresses by using a
new option in DHCPv4 which has been used by 6rd CPEs to automatically
configure the 6rd AFBR addresses. Can you explain more about why it creates
a lot of problems?

Best wishes,
Xiaohu