Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

From: Ted Lemon <[email-masked]>
Date: Mon, 24 Sep 2012 16:00:29 +0000

First of all, I apologize for having taken so long to look at this draft.   The working group is doing quite a bit of work, and it's hard to stay on top of it all.

I just gave the draft a thorough read, and I have come away with it not knowing how I would write a shepherd doc for the draft, because I don't really understand what it's supposed to do.   The motivation for the draft is to be able to get a DHCP packet up through a tunnel to a DHCP server on the far end of the tunnel.   The solution is to use a relay agent to get the packet through the tunnel.

But how does this work?   The relay agent is co-located with the client, right?   So the client sends a DHCP packet, and the relay agent receives it, and then it relays it up the tunnel, right?   But on what interface does the client send the packet?   On what interface does the relay agent listen?

If the answer is that the client sends the packet on the tunnel interface, you haven't solved the stated problem, because you still are out of spec with respect to RFC3315: you still don't have a link-local address to use as a source address.   If the answer is that the client sends the packet on some other interface, that has several problems.

The first problem is that now the relay agent has to listen on the interface the client will transmit on.   But that interface is a configurable interface in its own right.  How do we distinguish between DHCP packets intended to configure that interface, and DHCP packets intended to go up the tunnel?

Second, how does the relay avoid relaying packets from _other_ hosts?

Third, how does the DHCP server know what configuration information to send?

I think it's quite possible that I have simply failed to understand what this draft is trying to do, and that if I did understand, all of these questions would be satisfactorily answered.   But the point of writing a draft is to allow a new reader to understand the proposed solution to the problem; since I haven't been able to accurately glean that answer from the draft as written, I think the draft needs more work.

As for the question of consensus, Bernie Volz also raised some questions about the draft which Leaf tried to answer, but as far as I can tell did not actually answer.   Although we do seem to have a consensus to advance the draft, without answering Bernie's questions and mine, we aren't actually ready to advance yet.

So I would appreciate it if the authors and the people who said they wanted the draft to advance, and whom I assume therefore carefully reviewed the draft, would make an effort to fix the draft so that it's possible for a naive reader like me to understand what it says to do.

Thanks!

---

From: Leaf yeh <[email-masked]>
Date: Tue, 25 Sep 2012 07:47:41 +0000

Ted - But how does this work?   The relay agent is co-located with the client, right?   So the client sends a DHCP packet, and the relay agent receives it, and then it relays it up the tunnel, right?   But on what interface does the client send the packet?   On what interface does the relay agent listen?

My reading from the draft sounds:  a. The relay is co-located with the client on the 6rd CE;  b. The relay got the packet from the client internally within the 6rd CE;

Ted - If the answer is that the client sends the packet on the tunnel interface, you haven't solved the stated problem, because you still are out of spec with respect to RFC3315: you still don't have a link-local address to use as a source address.

I suppose the draft intends to use the address of the relay to communicate with the server, then avoids the requirement for the LLA of the client. But the client and the relay sounds in the same device, there is no explicit interface between the client and the relay.

Ted - Second, how does the relay avoid relaying packets from _other_ hosts?

I guess CE might relay packet from other host, but the peer address in the Relay-Forward message will not be the unspecified address (::).

Ted - Third, how does the DHCP server know what configuration information to send?

I guess the server might assign the configuration to the client per the address of the relay, while the peer address in the Relay-Forward message will be the unspecified address (::).

Pls. the authors of the draft correct me if I got something wrong.

Best Regards,
Leaf

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Tuesday, September 25, 2012 12:00 AM
To: Leaf yeh
Cc: dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

Thanks!

---

From: Ole Trøan <[email-masked]>
Date: Tue, 25 Sep 2012 11:55:05 +0200

Ted,

> But how does this work?   The relay agent is co-located with the client, right?   So the client sends a DHCP packet, and the relay agent receives it, and then it relays it up the tunnel, right?   B…

this is quite similar to how http://tools.ietf.org/html/draft-ietf-dhc-dhcpv4-over-ipv6-05 works (I think).

> If the answer is that the client sends the packet on the tunnel interface, you haven't solved the stated problem, because you still are out of spec with respect to RFC3315: you still don't have a l…

a global source address is used by the relay.
or are you thinking of the link-address field in the relay message?

> The first problem is that now the relay agent has to listen on the interface the client will transmit on.   But that interface is a configurable interface in its own right.  How do we distinguish b…

the use of a relay message is purely to get around the 3315 restriction of using a link-local address.
the client is local to the node. assume for arguments sake that in the implementation the client is acting also as the relay.

> Second, how does the relay avoid relaying packets from _other_ hosts?

it isn't a relay, it is a client using the relay message. we should make this clearer I think.

> So I would appreciate it if the authors and the people who said they wanted the draft to advance, and whom I assume therefore carefully reviewed the draft, would make an effort to fix the draft so…

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Tue, 25 Sep 2012 14:17:57 +0000

> the client is local to the node. assume for arguments sake that in the implementation the client is acting also as the relay.

I suspected as much.   IMHO, this is the wrong thing to do.   Just use the tunnel endpoint address instead of the link-local address in the case where there is no link-local address.   You'd have to make this standards-track and update RFC3315, but I think that's okay.   There's no magic to using the link-local address on broadcast interfaces—it's just the one address we can always count on the client having.   Of course, in this case we can't count on that, and if you look at section 1.1 of RFC3315 and section 11, you can see that the standard already accounts for cases where the link-local address is not used.   Actually, it looks like the spec may have a bug with respect to unicast that needs to be fixed.

---

From: Xuxiaohu <[email-masked]>
Date: Wed, 26 Sep 2012 08:12:24 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表 Ted
> Lemon
> 发送时间: 2012年9月25日 22:18
> 收件人: Ole Trøan
> 抄送: dhc WG
> 主题: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt
> 
> > the client is local to the node. assume for arguments sake that in the
> implementation the client is acting also as the relay.
> 
> I suspected as much.   IMHO, this is the wrong thing to do.   Just use the
> tunnel endpoint address instead of the link-local address in the case where
> there is no link-local address.   You'd have to make this standards-track and
> update RFC3315, but I think that's okay.   There's no magic to using the

Hi Ted,

In fact, one of the co-authors had ever proposed to update RFC3315 for the purpose of relaxing that limitation of using link-local addresses. However, since it will cause changes to the protocol specifications and especially the implementations of DHCP servers, we co-authors finally reached a consensus that we'd better avoid updating RFC3315 if possible.

Best regards,
Xiaohu

> link-local address on broadcast interfaces—it's just the one address we can
> always count on the client having.   Of course, in this case we can't count on
> that, and if you look at section 1.1 of RFC3315 and section 11, you can see that	
> the standard already accounts for cases where the link-local address is not
> used.   Actually, it looks like the spec may have a bug with respect to unicast
> that needs to be fixed.
> 
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ole Trøan <[email-masked]>
Date: Wed, 26 Sep 2012 10:48:39 +0200

Ted,

> I suspected as much.   IMHO, this is the wrong thing to do.   Just use the tunnel endpoint address instead of the link-local address in the case where there is no link-local address.   You'd have t…

I think we should do this too. let us make sure we get that into the RFC3315bis that I clearly remember you volunteered to write. ;-)
this draft proposes a solution that only affects the client implementation though (that is changing anyway), so I think we need this for a deployable solution.

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Sep 2012 12:41:32 +0000

> In fact, one of the co-authors had ever proposed to update RFC3315 for the purpose of relaxing that limitation of using link-local addresses. However, since it will cause changes to the protocol sp…

Why is it so important not to update RFC3315?   And what changes would be required to DHCP servers?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Sep 2012 12:57:43 +0000

> this draft proposes a solution that only affects the client implementation though (that is changing anyway), so I think we need this for a deployable solution.

The changes required to RFC3315 to do what you want are minor and don't require a spin of the full document—you can just issue a short document, about the length of your current one, that updates RFC3315.   This will get you what you want in the short term, and then we can fold your work into the RFC3315 update when the time comes.

What you are doing here is proposing something completely different, that is unnecessarily complicated, and makes things worse, and that will not be compatible with the subsequent update to RFC3315.   IOW, two solutions, where one would have done better.

---

From: Ole Trøan <[email-masked]>
Date: Wed, 26 Sep 2012 15:11:59 +0200

Ted,

> The changes required to RFC3315 to do what you want are minor and don't require a spin of the full document—you can just issue a short document, about the length of your current one, that updates R…

there would be two client/server changes:
 - allow global unicast addresses as source address
 - allow a unicast address as destination address to reach the DHCPv6 server

there are a few MUSTs that must be changed. equally there might be security implications, and new text for how the server should deal with on or offlink clients.

> What you are doing here is proposing something completely different, that is unnecessarily complicated, and makes things worse, and that will not be compatible with the subsequent update to RFC3315…

this isn't completely different. the draft describes how this can be achieved with existing DHCPv6 servers and within current RFC3315.
what is complicated and what is not compatible?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Wed, 26 Sep 2012 14:29:50 +0000

> - allow a unicast address as destination address to reach the DHCPv6 server

Huh.   How does the client know that address?   Why aren't you advertising a route to the All_DHCP_Servers multicast address down the tunnel?

> there are a few MUSTs that must be changed. equally there might be security implications, and new text for how the server should deal with on or offlink clients.

Wouldn't the security implications be the same in both cases?   You realize that RFC3315 does allow unicast to the server if it's been negotiated with the server, right?   How are the security implications different in that case than in this one?   How does putting in a fake relay agent change things?   Can't any client put in a fake relay agent, whether they are at a tunnel endpoint or not?   I can help you to work through the security considerations section if that's your only concern.

> what is complicated and what is not compatible?

You have to hack the client to pretend it's a relay agent.   If this happens, you're going to wind up with clients like that all over the place, and your DHCP deployment is going to have to handle them correctly.   And then if we change RFC3315 to solve the problem the right way, then your DHCP deployment is going to have to handle both mechanisms, one of which delivers a packet with an extra relay package.

---

From: Leaf yeh <[email-masked]>
Date: Thu, 27 Sep 2012 03:12:27 +0000

Section 11 of RFC3315 - <quote>If the server receives the message directly from the client and the source address in the IP datagram in which the message was received is not a link-local address, then the client is on the link identified by the source address in the IP datagram (note that this situation can occur only if the server has enabled the use of unicast message delivery by the client and the client has sent a message for which unicast delivery is allowed).</quote>

The above sounds the client could use the GUA for sending its message instead of LLA in some case. Supposed the client also knows the GUA of the server like the case of the relay. Then the technical question turns to be: if the assumption sounds the client already has its GUA of IPv6 (at its WAN interface?), why not use it directly for the stateless configuration.

Best Regards,
Leaf

-----Original Message-----
From: Ole Trøan [mailto:[email-masked]] 
Sent: Wednesday, September 26, 2012 4:49 PM
To: Ted Lemon
Cc: Leaf yeh; dhc WG
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

Ted,

> I suspected as much.   IMHO, this is the wrong thing to do.   Just use the tunnel endpoint address instead of the link-local address in the case where there is no link-local address.   You'd have to make this standards-track and update RFC3315, but I think that's okay.   There's no magic to using the link-local address on broadcast interfaces-it's just the one address we can always count on the client having.   Of course, in this case we can't count on that, and if you look at section 1.1 of RFC3315 and section 11, you can see that the standard already accounts for cases where the link-local address is not used.   Actually, it looks like the spec may have a bug with respect to unicast that needs to be fixed.

cheers,
Ole

---

From: Ole Trøan <[email-masked]>
Date: Thu, 27 Sep 2012 09:59:40 +0200

Ted,

> Huh.   How does the client know that address?   Why aren't you advertising a route to the All_DHCP_Servers multicast address down the tunnel?

draft:
   "The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast address as the destination address, 
   section 20 of [RFC3315].  If the 6rd link supports multicast [I-D.ietf-mboned-auto-multicast] the 6rd
   CE DHCPv6 relay MAY use the All_DHCP_Servers [RFC3315] as the   destination address of Relay-forward messages."

some links (e.g. 6rd) do not support IPv6 multicast.

> You have to hack the client to pretend it's a relay agent.   If this happens, you're going to wind up with clients like that all over the place, and your DHCP deployment is going to have to handle…

I don't quite understand this concern. this draft describes how one can put together existing DHCP protocol modules to achieve support for links that do not support link-local addresses and multicast.

if we instead were to change 3315 how would a new client speak to an old server?

cheers,
Ole

---

From: Ted Lemon <[email-masked]>
Date: Thu, 27 Sep 2012 12:58:12 +0000

> I don't quite understand this concern. this draft describes how one can put together existing DHCP protocol modules to achieve support for links that do not support link-local addresses and multica…

This is really a two-bad-choices situation.   If you add a relay header just to hack around the restriction in the DHCP server, that's weird.   But if you hack the DHCP server to allow unicast, that's bad too, because then we'll start to see clients doing this because the implementor just tested against the server without carefully following the spec.

In practice, the ISC server currently will drop packets that are unicast.   The Nominum server, as far as I can tell, doesn't, and the return path in the Nominum server at least looks like it works for unicast packets; I suspect that's true of the ISC server as well, since unicast is an option for some packets.   Dunno what Cisco does.

I know the authors discussed this issue; quite a few people also responded saying that they were in favor of advancing this draft.   Can any of those people tell me what they think about this issue?   Can any of the usual suspects weigh in?

---

From: Tomek Mrugalski <[email-masked]>
Date: Thu, 27 Sep 2012 23:15:02 +0200

On 12-08-10 14:42, Ted Lemon wrote:
> The authors of this draft have requested a working group last call.
> The draft explains how DHCP clients operate in an environment where
> the interface being configured doesn't support multicast (e.g., 6RD).
> If this is a matter of interest to you, please review the draft and
> send comments to the list.
> 
> If you are in favor of advancing the draft, please say so on the
> list; if nobody supports it, it won't advance.   If you oppose
> advancing it, please also say so.   We will determine consensus on
> August 24.
Hi,

I'm terribly sorry for not joining the discussion earlier. I'm in favor
of advancing the draft, but not in its current form.

In my opinion allowing the client to send every message encapsulated in
relay-forw will not give you much, but will just bring more problems. In
particular:

- What would you put in the peer-addr and link-addr fields of the
relay-forw message? Bernie's suggestion for putting 0s in peer-addr
makes sense, but what about link-addr? Would you put CE's global unicast
address there? That would work, but in many cases it would scale up
poorly. If you have 1000 CEs in your network, you would potentially need
to configure 1000 subnets as the server is supposed to use link-addr to
find out those links. Some servers require explicit network topology
information (i.e. listing all links that the server is supposed to
support). On the other hand, you can define one large subnet that covers
all your 6rd CE's global addresses, but that would not work in certain
implementations. This leads to a question if the server is supposed to
treat all CEs as being the same or different links.

- This draft mentions DNS, SIP and NTP options. Are we talking stateless
or stateful (or both) here? That should be clarified.

- The argument for not having to update 3315 is weak. There are couple
inconsistencies in it and there's 3315 bis planned anyway. To be more
specific, This statement "client MUST use link-local address..." from
3315 is in direct contradiction with a another sentence from section
18.1 of 3315: "If the client has a source address of sufficient scope
that can be used by the server as a return address, and the client has
received a Server Unicast option (section 22.12) from the server, the
client SHOULD unicast any Request, Renew, Release and Decline messages
to the server."

Have you considered a different approach? Something like this:

1. Say that any DHCPv6 solution working over tunnels (or non-multicast,
no link-local interfaces in general) MUST support server unicast.
2. Make the 6rd CE send normal messages (not relayed) from its global
address to 6rd BR anycast address.
3. Extend the server unicast to work on solicit, confirm, rebind and
inf-request. (update 3315, section 15, second paragraph).
4. Optionally update 3315 to point out inconsistencies regarding source
address ("MUST use link-local address..." in section 16 vs. 18.1 "If the
client has a source address of sufficient scope..."). That is really
optional, as any server that implements server unicast already disobeys
that rule.

This will work on all servers that adhere to sections 17.2.2 (advertise)
and 18.2.8 (reply): " If the Solicit message was received directly by
the server, the server unicasts the Advertise message directly to the
client using the address in the source address field from the IP
datagram in which the Solicit message was received.".

I understand that you want to have it deployed as soon as possible, but
we have 3315bis work planned anyway, so there will be changes and that
is unavoidable. And with the server-unicast approach, it really isn't
that big change.

Step 4 will happen anyway. So it's a matter of updating section 15:

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

to

"A server MUST discard any Solicit, Confirm, Rebind or
Information-request messages it receives with a unicast destination
address, unless explicitly configured to use server unicast option with
that address.".

If we are concerned of any possible side effects in normal deployment
scenarios, we may work out some extra safety checks (add "... and the
receiving interface does not support multicast nor link-local addresses").

Sure, expecting the client to magically know server address when sending
the first solicit is odd, but if we want to make DHCPv6 work on
non-multicast, no link-local interfaces, we need to make some
compromises. I very much prefer that approach, compared to the server
reporting that there are 1000s of new relays or server starting to
blindly accepting unicast messages.

On the other hand, there's RFC6276 that talks about co-locating relay
and PD client, so the effort to avoid it is already lost.

Editorial comment:
"The 6rd CE DHCPv6 relay agent SHOULD use the 6rd BR IPv6 anycast
address as the destination address, section 20 of [RFC3315]". That
reference to section 20 of RFC3315 is strange. Section 20 describes
relay operation. What exactly authors want to point to in this context?

Hope that helps,
Tomek

p.s.
Where are we with the 3315bis plans? I know that it is a major work, so
it is not easy to commit to it, but there are more and more things that
require update. I'm already overburdened with the failover work and
other stuff, but for such a grand purpose I will find some time.

---

From: Xuxiaohu <[email-masked]>
Date: Fri, 28 Sep 2012 02:19:08 +0000

> -----邮件原件-----
> 发件人: [email-masked] [mailto:[email-masked]] 代表
> Tomek Mrugalski
> 发送时间: 2012年9月28日 5:15
> 收件人: [email-masked]

Hi Tomek,

Thanks a lot for your comments. As Ole has said earlier, we should do both. I fully agree that updating RFC3315 to relax the usage of link-local addresses is great. However, we still need a mechanism as described in the current draft so far to deal with existing DHCPv6 servers which have been implemented according to the current RFC3315 specifications, rather than the RFC3315bis.

Best regards,
Xiaohu

---

From: Leaf yeh <[email-masked]>
Date: Fri, 28 Sep 2012 03:47:19 +0000

Tomek - Where are we with the 3315bis plans? I know that it is a major work, ..., but for such a grand purpose I will find some time.

I'd also like to join the plan if I could provide any help.

Best Regards,
Leaf

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Tomek Mrugalski
Sent: Friday, September 28, 2012 5:15 AM
To: [email-masked]
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

Hi,

to

Editorial comment:

Hope that helps,
Tomek

p.s.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 28 Sep 2012 13:36:08 +0000

I also think the draft's proposed solution is a bad one. It does make locating the 'correct' relay agent information (since in some cases there may be multiple) difficult for the server -- sure lack of a link-address value (all 0's) might trigger correct processing (advance to next relay), but there are many other cases where the server needs to use the 'correct' relay information.

I think section 13 of RFC 3315 (Transmission of Messages by a Client) was meant to cover all aspects of sending packets - not just the 'destination' address of the packet.

While I don't know enough about the 6rd / tunnel environment, I'm not sure what other general IPv6 issues lack of a link-local address causes. But, let's put that aside as I don't think the client's packet source address is that critical -- it just needs to be something that the 'first' hop device can use to send a response packet back to the client.

The intent of using multicast addresses and link-local was to 'force' the client to always communicate via the relay agent since lack of relay agent information in some of the DHCPv4 interactions caused issues and had to have special workarounds to address. I think this is something CRITICAL to keep. The server can tell a client it is OK to use a unicast address, but that is not possible in the Solicit so I'm not sure how Tomek's proposal to extend this would work -- the client has to know what to use BEFORE it starts any interactions with the server.

And, in "traditional" RFC 3315 environments the only communication that was known to be possible was link-local (since that was the only address the client was known to always have available).

At the time RFC 3315 was written, if I recall, anycast addresses were still a bit new and not completely baked (and it wasn't possible to identify an anycast address, it was meant more for network locality issues (which doesn't really come into play with communication on a single link, and there wasn't any way to "tell" the client what anycast address to use anyway). However, I don't really see that an anycast address violates the spirit of RFC 3315 with respect to multicast -- in some ways, anycast is a different form of multicast.

I don't know for sure, but with the intent of using the "6rd BR IPv6 anycast address", there would be a relay agent on this end-point (or the DHCPv6 server would be there). If a relay agent is present, then there's no issue as the DHCPv6 server doesn't really care how the client <-> relay communication occurs and has nothing to check to determine how the packet was exchanged.

If the DHCPv6 server is present on that BR, then it can have rules for that environment.

So I think for this environment, I would prefer to see the transmission rules for clients changed to:

1. Allow unicast packets to an anycast address from clients (note that there is no way to tell an anycast address from a unicast address). Specifically the 6rd BR IPv6 anycast address. (There might be text here to recommend use of the standard DHCPv6 multicast address (ff02::1:2) if multicast available.)

2. Allow the client's source-address to be in whatever scope is appropriate for that destination address (i.e., whatever is appropriate for that first hop communication even if this is may be a globally routable address). There might be text here to recommend use of the link-local address if one is available as that limits the message exchange to where it should be.

And similar changes to accommodate any checking in relays or servers with respect to how the client packet was transmitted to that first hop devices.

Note that these changes do allow for DHCPv6 client traffic to not be limited to a single 'link'.

This does of course require the client to know that it is in this environment, but I think that is a given in the draft's solution too.

Personally, I think these changes are far better than having to include relay functionality into the client and dealing with the fallout.

Perhaps you've considered this but decided against it? I haven't been following this work closely so if this had been suggested but shot down previously, sorry for raising it again. 

- Bernie

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Xuxiaohu
Sent: Thursday, September 27, 2012 10:19 PM
To: Tomek Mrugalski; [email-masked]
Subject: Re: [dhcwg] WGLC: draft-ietf-dhc-dhcpv6-tunnel-01.txt

> I'm terribly sorry for not joining the discussion earlier. I'm in 
> favor of advancing the draft, but not in its current form.

Hi Tomek,

Best regards,
Xiaohu

> In my opinion allowing the client to send every message encapsulated 
> in relay-forw will not give you much, but will just bring more 
> problems. In
> particular:
> 
> makes sense, but what about link-addr? Would you put CE's global 
> unicast address there? That would work, but in many cases it would 
> scale up poorly. If you have 1000 CEs in your network, you would 
> potentially need to configure 1000 subnets as the server is supposed 
> to use link-addr to find out those links. Some servers require 
> explicit network topology information (i.e. listing all links that the 
> server is supposed to support). On the other hand, you can define one 
> large subnet that covers all your 6rd CE's global addresses, but that 
> would not work in certain implementations. This leads to a question if 
> the server is supposed to treat all CEs as being the same or different links.
> 
> - This draft mentions DNS, SIP and NTP options. Are we talking 
> stateless or stateful (or both) here? That should be clarified.
> 
> 1. Say that any DHCPv6 solution working over tunnels (or 
> non-multicast, no link-local interfaces in general) MUST support server unicast.
> 4. Optionally update 3315 to point out inconsistencies regarding 
> source address ("MUST use link-local address..." in section 16 vs. 
> 18.1 "If the client has a source address of sufficient scope..."). 
> That is really optional, as any server that implements server unicast 
> already disobeys that rule.
> 
> This will work on all servers that adhere to sections 17.2.2 
> (advertise) and 18.2.8 (reply): " If the Solicit message was received 
> directly by the server, the server unicasts the Advertise message 
> directly to the client using the address in the source address field 
> from the IP datagram in which the Solicit message was received.".
> 
> I understand that you want to have it deployed as soon as possible, 
> but we have 3315bis work planned anyway, so there will be changes and 
> that is unavoidable. And with the server-unicast approach, it really 
> isn't that big change.
> 
> address, unless explicitly configured to use server unicast option 
> with that address.".
> 
> Sure, expecting the client to magically know server address when 
> sending the first solicit is odd, but if we want to make DHCPv6 work 
> on non-multicast, no link-local interfaces, we need to make some 
> Where are we with the 3315bis plans? I know that it is a major work, 
> so it is not easy to commit to it, but there are more and more things 
> that require update. I'm already overburdened with the failover work 
> and other stuff, but for such a grand purpose I will find some time.
> 
> 
>

---

From: Xuxiaohu <[email-masked]>
Date: Sat, 29 Sep 2012 02:52:20 +0000

Hi Bernie,

Thanks a lot for your comments and suggestions. Please see my response in line.

> Bernie Volz (volz)
> 发送时间: 2012年9月28日 21:36
> 收件人: Xuxiaohu; Tomek Mrugalski; [email-masked]
> I also think the draft's proposed solution is a bad one. It does make locating the
> 'correct' relay agent information (since in some cases there may be multiple)
> difficult for the server -- sure lack of a link-address value (all 0's) might trigger
> correct processing (advance to next relay), but there are many other cases
> where the server needs to use the 'correct' relay information.

As said in section 20.1.2. Relaying a Message from a Relay Agent,
" If the source address from the IP datagram header of the received
   message is a global or site-local address (and the device on which
   the relay agent is running belongs to only one site), the relay agent
   sets the link-address field to 0 "  This is the case that you pointed out where the server could correctly process the received DHCP messages.

In addition, since this draft is just intended to use stateless DHCPv6, would you please list any concrete cases where the server needs to use the correct relay information?
 
> I think section 13 of RFC 3315 (Transmission of Messages by a Client) was
> meant to cover all aspects of sending packets - not just the 'destination'
> address of the packet.
> 
> While I don't know enough about the 6rd / tunnel environment, I'm not sure
> what other general IPv6 issues lack of a link-local address causes. But, let's put
> that aside as I don't think the client's packet source address is that critical -- it
> just needs to be something that the 'first' hop device can use to send a
> response packet back to the client.
> 
> The intent of using multicast addresses and link-local was to 'force' the client to
> always communicate via the relay agent since lack of relay agent information in
> some of the DHCPv4 interactions caused issues and had to have special
> workarounds to address. I think this is something CRITICAL to keep. The server
> can tell a client it is OK to use a unicast address, but that is not possible in the
> Solicit so I'm not sure how Tomek's proposal to extend this would work -- the
> client has to know what to use BEFORE it starts any interactions with the
> server.
> 
> And, in "traditional" RFC 3315 environments the only communication that was
> known to be possible was link-local (since that was the only address the client
> was known to always have available).
> 
> At the time RFC 3315 was written, if I recall, anycast addresses were still a bit
> new and not completely baked (and it wasn't possible to identify an anycast
> address, it was meant more for network locality issues (which doesn't really
> come into play with communication on a single link, and there wasn't any way
> to "tell" the client what anycast address to use anyway). However, I don't
> really see that an anycast address violates the spirit of RFC 3315 with respect
> to multicast -- in some ways, anycast is a different form of multicast.
> 
> I don't know for sure, but with the intent of using the "6rd BR IPv6 anycast
> address", there would be a relay agent on this end-point (or the DHCPv6 server
> would be there). If a relay agent is present, then there's no issue as the
> DHCPv6 server doesn't really care how the client <-> relay communication
> occurs and has nothing to check to determine how the packet was exchanged.

Sure, if a relay agent is present on that BR, there is no issue for the DHCPv6 servers. However, the implementation of relay agent on that BR is not in accordance with the existing RFC3315 specifications anymore. 

> If the DHCPv6 server is present on that BR, then it can have rules for that

Similarly, if a DHCP server is present on that BR, the implementation of DHCP server on that BR is not in accordance with the existing RFC3315 specifications anymore. 

> 1. Allow unicast packets to an anycast address from clients (note that there is
> no way to tell an anycast address from a unicast address). Specifically the 6rd
> BR IPv6 anycast address. (There might be text here to recommend use of the
> standard DHCPv6 multicast address (ff02::1:2) if multicast available.)
> 
> 2. Allow the client's source-address to be in whatever scope is appropriate for
> that destination address (i.e., whatever is appropriate for that first hop
> communication even if this is may be a globally routable address). There might
> be text here to recommend use of the link-local address if one is available as
> that limits the message exchange to where it should be.
> 
> And similar changes to accommodate any checking in relays or servers with
> respect to how the client packet was transmitted to that first hop devices.

As such, no matter a DHCP server or a DHCP relay agent is present on that BR, the implementations of DHCP on both the BR (either as a server or a relay agent) and the CE (as a client) should be changed and therefore are not in accordance with the existing RFC3315 specifications anymore.

Best regards,
Xiaohu

> This does of course require the client to know that it is in this environment, but
> I think that is a given in the draft's solution too.
> 
> Personally, I think these changes are far better than having to include relay
> functionality into the client and dealing with the fallout.
> 
> Perhaps you've considered this but decided against it? I haven't been following
> this work closely so if this had been suggested but shot down previously, sorry
> for raising it again.
> 
> - Bernie
> 
> Thanks a lot for your comments. As Ole has said earlier, we should do both. I
> fully agree that updating RFC3315 to relax the usage of link-local addresses is
> great. However, we still need a mechanism as described in the current draft so
> far to deal with existing DHCPv6 servers which have been implemented
> according to the current RFC3315 specifications, rather than the RFC3315bis.
> 
> Best regards,
> Xiaohu
>

---

From: Ted Lemon <[email-masked]>
Date: Sat, 29 Sep 2012 02:59:16 +0000

> In addition, since this draft is just intended to use stateless DHCPv6, would you please list any concrete cases where the server needs to use the correct relay information?

The reason that even information request messages are required to be broadcast is that a device that does stateful and then stateless should get the same answers, and this can't happen if the relays aren't in the path and aren't able to add their options.

Also, it seems to me that your tunnel draft is applicable to prefix delegation; I realize this isn't an intended use that you have in mind, but it's certainly a perfectly valid one, and someone will no doubt want it at some later date.   So we shouldn't design a solution that we're not comfortable with in that case.

> As such, no matter a DHCP server or a DHCP relay agent is present on that BR, the implementations of DHCP on both the BR (either as a server or a relay agent) and the CE (as a client) should be cha…

This is why we are talking about updating RFC3315.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Sat, 29 Sep 2012 03:37:45 +0000

> This is why we are talking about updating RFC3315.

Yup ... my point exactly.

As stated in RFC3315 section 13, a separate document may detail how to apply DHCPv6 to other link types. I think it is rather natural to have to relax some of the unicast restrictions if multicast isn't used (how else would this work). I think this is perfectly in line with what was intended by such a document.

I would also like to make sure we design something that can support all of DHCPv6 and not something limited to Information-Request/Reply. Also, perhaps I missed it but I see nothing in your document that states it is limited to Information-Request/Reply? But again, even if it did say that, I would still want us to specify something that could accommodate the full DHCPv6 range of messages.

- Bernie