Subject: [dhcwg] fwd: A question about rfc5739

From: Dacheng Zhang <[email-masked]>
Date: Tue, 14 Dec 2010 14:54:35 +0800

Hi, 
In rfc5793, a ipsec gateway can provide a unicast address of dhcp server to
a client so that the client can use the address to initiate communication
with the server. I doubt whether this is conflicted with the specification
of DHCP for ipv6, and whether we need to change the related texts in
rfc5793. Could you please give us some comments on this issue? Thanks a lot
in advance.

Best regards,
Dacheng

>> -----邮件原件-----
>> 发件人: Laganier, Julien [mailto:[email-masked]]
>> 发送时间: 2010年12月14日 0:29
>> 收件人: Dacheng Zhang; [email-masked]
>> 抄送: 'Yaron Sheffer'; 'Paul Hoffman'; [email-masked]
>> 主题: RE: A question about rfc5739
>> 
>> Hi,
>> 
>> Dacheng Zhang wrote:
>> >
>> > Hi,
>> >
>> > During reading RFC 5739, I find a little question and hope to get your
>> > comments. According to the rfc, an IPSec gateway is recommended to
>> > provide
>> > the IP addresses of DHCP servers to client. However, according to the
>> > [RFC3115], if a user attempts to use unicast address to initially
>> > access a
>> > DHCP server, the packets from the user will be discarded. That is, a
>> > user
>> > only can use a reserved multicast address when it tries to access a
>> > DHCP
>> > server at the first time. A related discussion can be found in
>> > http://tools.ietf.org/html/draft-xu-ipv6-ra-dhcp-server-option-
>> > 01#section-4.
>> > So, do you think whether we should still keep "INTERNAL_IP6_DHCP()" in
>> > IKEv2?
>> 
>> My personal view on this is that the RFC 3315 statement of DHCP
discarding
>> non multicast request should not apply in this case, i.e. it's fine if
the client
>> send the request unicast at the address provided in INTERNAL_IP6_DHCP.
>> 
>> That is however not what the RFC says, thus if you want this issue to be
>> addressed you should probably start a discussion on the IPsecme mailing
list,
>> and eventually move it to the DHC mailing list once there's agreement on
>> what the IPsecme working group would like to do with DHCPv6.
>> 
>> --julien

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 14 Dec 2010 17:05:10 -0600

Can you point to the specific text? I can't find "DHCP" or any mention of RFC 2131 or 3315 in this 5739 document?

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Dacheng Zhang
Sent: Tuesday, December 14, 2010 1:55 AM
To: [email-masked]
Subject: [dhcwg] fwd: A question about rfc5739

Hi, 

Best regards,
Dacheng

discarding
the client
list,
>> what the IPsecme working group would like to do with DHCPv6.

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

---

From: Dacheng Zhang <[email-masked]>
Date: Wed, 15 Dec 2010 09:36:04 +0800

Sure, here they are ^_^

IPv6 Configuration in Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 5739

4.  Solution Details

4.1.  Initial Exchanges

   During IKE_AUTH, the client sends a new configuration attribute,
   INTERNAL_IP6_LINK, which requests a virtual link to be configured.
   The attribute contains the client's interface ID for the link-local
   address (other addresses may use other interface IDs).  Typically,
   the client would also ask for the DHCPv6 server address; this is used
   only for configuration (such as DNS server addresses), not address
   assignment.

   [DHCPv6]     Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
                and M. Carney, "Dynamic Host Configuration Protocol for
                IPv6 (DHCPv6)", RFC 3315, July 2003.

Cheers
Dacheng
>> -----邮件原件-----
>> 发件人: Bernie Volz (volz) [mailto:[email-masked]]
>> 发送时间: 2010年12月15日 7:05
>> 收件人: Dacheng Zhang; [email-masked]
>> 主题: RE: [dhcwg] fwd: A question about rfc5739
>> 
>> Can you point to the specific text? I can't find "DHCP" or any mention of
RFC
>> 2131 or 3315 in this 5739 document?
>> 
>> - Bernie
>>

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 14 Dec 2010 22:08:49 -0600

OK (ah you mistyped the RFC in the original message body and I think that must be the one I looked at).

And, RFC 3315 is pretty clear that unicast is not allowed for Information-Request messages:

15. Message Validation

...

   A server MUST discard any Solicit, Confirm, Rebind or
   Information-request messages it receives with a unicast destination
   address.

So, this does not work (if the intent was to provide a unicast address).

Guess we (DHC WG) never noticed this document was referencing DHCPv6 to review it?

Probably best if an ERRATA is filed for this issue? (I see Alfred Hoenes has filed 2 ERRATA but neither are for this issue.)

- Bernie

-----Original Message-----
From: Dacheng Zhang [mailto:[email-masked]] 
Sent: Tuesday, December 14, 2010 8:36 PM
To: Bernie Volz (volz); [email-masked]
Subject: re: [dhcwg] fwd: A question about rfc5739

Sure, here they are ^_^

4.  Solution Details

4.1.  Initial Exchanges

Cheers
Dacheng
RFC

---

From: Dacheng Zhang <[email-masked]>
Date: Wed, 15 Dec 2010 19:20:30 +0800

Another similar discussion can be found in RFC 5996:
"Internet Key Exchange Protocol Version 2 (IKEv2)
RFC 5996
3.15.1.  Configuration Attributes
   o  INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send
      any internal DHCP requests to the address contained within the
      attribute.  Multiple DHCP servers MAY be requested.  The responder
      MAY respond with zero or more DHCP server attributes."

I think the addresses mentioned there are unicast addresses as well. ^_^

--Dacheng

>> 发送时间: 2010年12月15日 12:09
>> 抄送: Cheryl Madson (cmadson); [email-masked];
>> [email-masked]; Ralph Droms (rdroms)
>> Probably best if an ERRATA is filed for this issue? (I see Alfred Hoenes
has filed
>> 2 ERRATA but neither are for this issue.)
>> 
>> - Bernie
>> 
>> >> From: [email-masked] [mailto:[email-masked]] On
>> Behalf
>> >> Of Dacheng Zhang
>> >> In rfc5793, a ipsec gateway can provide a unicast address of dhcp
server
>> to
>> >> rfc5793. Could you please give us some comments on this issue? Thanks
a
>> lot
>> >> >> > So, do you think whether we should still keep
"INTERNAL_IP6_DHCP()"
>> in
>> >> >> That is however not what the RFC says, thus if you want this issue
to
>> be
>> >> >> and eventually move it to the DHC mailing list once there's
agreement
>> on

---

From: Dacheng Zhang <[email-masked]>
Date: Wed, 15 Dec 2010 19:30:53 +0800

Hi, Bernie:

I found another similar discussion in RFC 5996:
"Internet Key Exchange Protocol Version 2 (IKEv2) RFC 5996 

3.15.1.  Configuration Attributes
   o  INTERNAL_IP4_DHCP, INTERNAL_IP6_DHCP - Instructs the host to send
      any internal DHCP requests to the address contained within the
      attribute.  Multiple DHCP servers MAY be requested.  The responder
      MAY respond with zero or more DHCP server attributes.
"
The addresses mentioned there should be unicast addresses as well. 

--Dacheng

has filed
server
a
"INTERNAL_IP6_DHCP()"
to
agreement

---

From: "Laganier, Julien" <[email-masked]>
Date: Wed, 15 Dec 2010 08:20:15 -0800

The issue exist in a scenario involving an IKEv2 (RFC 5996, obsoleting RFC 4306) based VPN client accessing a remote network where there is a desire to configure some host parameters on the VPN client with DHCPv6.

The requirement of unicasting DHCPv6 messages stems the inability to send multicast traffic in an IPsec tunnel mode SA.

We ran into a similar issue while trying to use DHCPv6 Prefix Delegation inside a Mobile IPv6 tunnel that can't really carry link-local multicast traffic.

Would documenting the use of unicast only with DHCPv6 in cases where the underlying link is not multicast capable an acceptable way forward?

--julien 
 
> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Tuesday, December 14, 2010 8:09 PM
> To: Dacheng Zhang; [email-masked]
> Cc: Cheryl Madson (cmadson); Laganier, Julien; [email-masked];
> Ralph Droms (rdroms)
> Subject: RE: [dhcwg] fwd: A question about rfc5739
> 
> Probably best if an ERRATA is filed for this issue? (I see Alfred
> Hoenes has filed 2 ERRATA but neither are for this issue.)
> 
> - Bernie
> 
> >> rfc5793. Could you please give us some comments on this issue?
> Thanks a
> lot
> >> in advance.
> >>
> >> Best regards,
> >> Dacheng
> >>
> >> >> -----邮件原件-----
> >> >> > During reading RFC 5739, I find a little question and hope to
> get
> your
> >> >> > the IP addresses of DHCP servers to client. However, according
> to
> the
> >> >> That is however not what the RFC says, thus if you want this
> issue to
> be

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 15 Dec 2010 10:43:51 -0600

The problem is that the servers are probably following RFC 3315, Section 15 (at least the one I work on does!) so the packet is dropped very early on (this only applies to non-relayed packets -- thus if the unicast address is a relay agent it might get through as the text applies to servers only).

Note that Section 15 text is a MUST, not a SHOULD.

So, this is a fairly significant change and without it will not work with servers that follow RFC 3315 requirements.

- Bernie

-----Original Message-----
From: Laganier, Julien [mailto:[email-masked]] 
Sent: Wednesday, December 15, 2010 11:20 AM
To: Bernie Volz (volz); Dacheng Zhang; [email-masked]
Cc: Cheryl Madson (cmadson); [email-masked]; Ralph Droms (rdroms)
Subject: RE: [dhcwg] fwd: A question about rfc5739

--julien

---

From: "Laganier, Julien" <[email-masked]>
Date: Thu, 16 Dec 2010 08:14:18 -0800

So, I understand that the only way to use DHCPv6 to configure an IKEv2-based VPN client is to deploy a DHCPv6 relay, and the VPN GW to send the address of that relay to the VPN client in the IKEv2 INTERNAL_IP6_DHCP configuration payload. 

Is that correct?

--julien

> Sent: Wednesday, December 15, 2010 8:44 AM
> To: Laganier, Julien; Dacheng Zhang; [email-masked]
> The problem is that the servers are probably following RFC 3315,
> Section 15 (at least the one I work on does!) so the packet is dropped
> very early on (this only applies to non-relayed packets -- thus if the
> unicast address is a relay agent it might get through as the text
> applies to servers only).
> 
> So, this is a fairly significant change and without it will not work
> with servers that follow RFC 3315 requirements.
> 
> - Bernie
> 
> The issue exist in a scenario involving an IKEv2 (RFC 5996, obsoleting
> RFC 4306) based VPN client accessing a remote network where there is a
> desire to configure some host parameters on the VPN client with DHCPv6.
> 
> The requirement of unicasting DHCPv6 messages stems the inability to
> send multicast traffic in an IPsec tunnel mode SA.
> 
> We ran into a similar issue while trying to use DHCPv6 Prefix
> Delegation inside a Mobile IPv6 tunnel that can't really carry link-
> local multicast traffic.
> 
> Would documenting the use of unicast only with DHCPv6 in cases where
> the underlying link is not multicast capable an acceptable way forward?
> 
> --julien
> 
> > Guess we (DHC WG) never noticed this document was referencing DHCPv6
> to
> > review it?
> >
> > >> >> > comments. According to the rfc, an IPSec gateway is
> recommended
> > to
> > >> >> > provide
> > >> >> > DHCP server, the packets from the user will be discarded.
> That
> > is, a
> > >> >> > user

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 16 Dec 2010 17:23:50 -0600

I think perhaps part of the confusion here is exactly what is the DHCPv6 client and what is the VPN client doing? And who is to use this dhcpv6 address being sent by the VPN GW.

I assume what you are really saying is that the host DHCPv6 client will multicast as per the RFC 3315 specification (as I don't think you plan to replace the host OS DHCPv6 client software) and the VPN client software will intercept this packet and forward it to the VPN GW.

If that is the model, then there may not be any issue since the VPN GW can then multicast the DHCPv6 packet to the DHCPv6 server in the network? And the response will be sent back to the VPN GW (whether relayed to reach the DHCPv6 server or not) and the VPN GW can then forward the packet back to the VPN client (that might be a bit tricky without keep some state and looking inside the DHCPv6 packets). Having the VPN GW be a relay agent may be a better solution as then it has plenty of options for keeping sufficient state (such as interface-id option) to send the reply back to the correct end host (back through the VPN)?

I'm not really sure why the [VPN] client needs this DHCPv6 address anyway, as it can always just forward the traffic to the VPN GW? And the VPN GW can then do whatever it wants - multicast the packet on the client's behalf (as per RFC 3315) or be a relay agent.

How is this handled in IPv4 [DHCPv4]? Don't many of the same issues exist there? There are significant differences between DHCPv4 and DHCPv6, so what works in DHCPv4 might not work the same in DHCPv6. Part of the advantage in DHCPv6 though is that all devices have link-local addresses and there is no broadcast, just multicast. And, in DHCPv6, we want clients to multicast their packets because we never want to bypass the relay agent (unless the server has previously told the client that it is OK to unicast).

Note: I have not read the entire RFC and was just responding to issues raised by Dacheng.

As this document is EXPERIMENTAL, this probably isn't a significant issue anyway?

- Bernie

-----Original Message-----
From: Laganier, Julien [mailto:[email-masked]] 
Sent: Thursday, December 16, 2010 11:14 AM
To: Bernie Volz (volz); Dacheng Zhang; [email-masked]
Cc: Cheryl Madson (cmadson); [email-masked]; Ralph Droms (rdroms)
Subject: RE: [dhcwg] fwd: A question about rfc5739

Is that correct?

--julien

---

From: Dacheng Zhang <[email-masked]>
Date: Fri, 17 Dec 2010 10:20:54 +0800

See the inline please ^_^

>> 
>> I'm not really sure why the [VPN] client needs this DHCPv6 address
anyway, as
>> it can always just forward the traffic to the VPN GW? And the VPN GW can
>> then do whatever it wants - multicast the packet on the client's behalf
(as per
>> RFC 3315) or be a relay agent.
>> 
[Dacheng Zhang] 
That is correct. In practice, if a IPsec GW can act as a relay agent, it can
insert its address in the IKEv2 INTERNAL_IP6_DHCP configuration payload sent
to a client. However, I think the related statements in the RFCs should be
updated. Otherwise, they will cause confusion. 

>> As this document is EXPERIMENTAL, this probably isn't a significant issue

[Dacheng Zhang] 

In IKEv2 [RFC 5996], a IPsec gateway is also allowed to send a unicast
address of a DHCP server to a client. This RFC is Standards Track.

Cheers

Dacheng