Subject: [dhcwg] Comment on RFC6939 (Client Link-Layer Address Option)

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Jan 2015 22:33:26 +0000

Hi, I have a comment on RFC6939 (Client Link-Layer Address Option - (CLLAO)).
This is a beautiful piece of work that essentially does for DHCPv6 what
Source/Target Link Layer Address Options (S/TLLAOs) do for IPv6 ND. It makes
link-layer address information visible to the network layer in cases where it may
be difficult for the network layer to parse the link-layer header.

Or, at least that's the way that it should be. Unfortunately, the draft restricts
the CLLAO to appear only in Relay-Forward messages:

Section 6:
   "The mechanism described in this document is
   not necessary in the case where the DHCPv6 server is connected to the
   same network link as the client, because the server can obtain the
   link-layer address from the link-layer header of the DHCPv6 message.
   If the DHCP server receives a Client Link-Layer Address option
   anywhere in any encapsulated message that is not a Relay-Forward DHCP
   message, the server MUST silently ignore that option."

Section 7:
   "The DHCPv6 client
   MUST NOT send the Client Link-Layer Address option, and MUST ignore
   the Client Link-Layer Address option if received."

I have a use case (DHCPv6 over tunnels) where the client and server are always
guaranteed to be on the same link, but it would be difficult for the server to
parse the link-layer header in DHCPv6 messages it receives from the client. In
that case, it would be very helpful if the client could include a CLLAO option
that the Server can use to easily obtain the link-layer address. So, I would
naturally like to see the above restrictions removed from the document.

I can see at least three ways to fix this:

  1) write an RFC6939(bis)
  2) bring CLLAO into RFC3315(bis) and address the issue there
  3) write it up in a link-layer-specific document that explains the use on
      that particular link layer.

I have already done 3) in 'draft-templin-aerolink', but IMHO it would be far
preferable to have the behavior documented in a link-layer-agnostic base
DHCPv6 specification. Again, done right the CLLAO should do the same
thing for DHCPv6 that S/TLLAO do for IPv6 ND.

Comments?

Thanks - Fred
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Jan 2015 17:36:17 -0500

> the CLLAO to appear only in Relay-Forward messages:

This was a deliberate choice.   If your network layer doesn't allow you to look at link-layer headers, it's broken and you should fix it (IMHO, of course!).

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Jan 2015 22:44:43 +0000

Hi Ted,

I am working with the ISC dhcp package, and it currently only supports Ethernet,
token ring, and the like where you can use a packet filter to capture the link-layer
header and deliver it to the application along with the upper layer payload. I had
to hack the sources to allow the package to run over tunnels, but in that case the
packet filter only retrieves the DHCPv6 message from the IP header on up, and
the link-layer header is lost. So, at least as far as the way common operating
systems function, it would be desirable to have a CLLAO from the client.

Thanks - Fred

> -----Original Message-----
> From: Ted Lemon [mailto:[email-masked]]
> Sent: Monday, January 19, 2015 2:36 PM
> To: Templin, Fred L
> Cc: dhcwg
> Subject: Re: [dhcwg] Comment on RFC6939 (Client Link-Layer Address Option)
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 19 Jan 2015 23:28:20 +0000

Hi Ted,

There is one more piece of this to tell so that you will have the whole story. In
addition to including the link-layer address, clients that have multiple link-layer
addresses can use the CLLAO to tell *which one* is being represented in this
message. Or, if the client wants to expose multiple link-layer addresses in the
same message it can include multiple CLLAOs.

Thanks - Fred

> From: dhcwg [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Monday, January 19, 2015 2:45 PM
> To: Ted Lemon
> Cc: dhcwg
> _______________________________________________
> dhcwg mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/dhcwg

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Jan 2015 20:23:07 -0500

> systems function, it would be desirable to have a CLLAO from the client.

I am puzzled as to how this even makes sense.   Why would you run DHCP over a point-to-point link?

---

From: Ted Lemon <[email-masked]>
Date: Mon, 19 Jan 2015 20:24:23 -0500

> same message it can include multiple CLLAOs.

This doesn't sound like an IETF protocol.   Multiple link-layer headers from an end node?

---

From: Michael Richardson <[email-masked]>
Date: Mon, 19 Jan 2015 22:13:28 -0500

> over a point-to-point link?

DHCPv6 is how to do everything over an IPv6 PPP link.

However, on DHCPv6, I see no reason to use packet filters to get the packets.
You have link layer addressing for DHCPv6 messages, and you just bind
multicast sockets.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Jan 2015 07:10:10 -0500

> DHCPv6 is how to do everything over an IPv6 PPP link.

So PPP uses DHCPv6 to number the endpoints of the link?   Wow.

> You have link layer addressing for DHCPv6 messages, and you just bind

Right, the link-local IPv6 address.   I am puzzled as to why you'd need something more than a link-local address, but if you did, DHCPv6 ought to work with the link-local address, as long as one endpoint of the PPP link knows to be the DHCP client and the other end knows to be the DHCP relay.

When I've implemented DHCPv6, I haven't actually used a packet filter.   We designed it specifically so that would not be required.   You do need stack support for SO_RVCDSTADDR, but that's it, at least in principle.

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Jan 2015 15:32:16 +0000

Hi Ted,

> Sent: Monday, January 19, 2015 5:23 PM
> To: Templin, Fred L
> Cc: dhcwg

Not point-to-point - Non-Broadcast, Multiple Access. The DHCPv6 server can
serve many clients over the same NBMA tunnel interface.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Jan 2015 15:37:44 +0000

Hi Ted,

> Sent: Monday, January 19, 2015 5:24 PM
> To: Templin, Fred L
> Cc: dhcwg

This is covered in Section 3 of RFC4861:

    " Inbound load balancing - Nodes with replicated interfaces may want
           to load balance the reception of incoming packets across
           multiple network interfaces on the same link.  Such nodes
           have multiple link-layer addresses assigned to the same
           interface.  For example, a single network driver could
           represent multiple network interface cards as a single
           logical interface having multiple link-layer addresses."

This is precisely the scenario I am seeking to address.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Jan 2015 11:04:15 -0500

> This is precisely the scenario I am seeking to address.

And why do you want the link-layer address?   Do these NBMA devices use the same link-local address for all interfaces?

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Jan 2015 17:09:27 +0000

Hi Ted,

> Sent: Tuesday, January 20, 2015 8:04 AM
> To: Templin, Fred L
> Cc: dhcwg

Yes, exactly. The NBMA tunnel interface of each node has a single link-local address
with (possibly) multiple link-layer addresses. Each "link-layer" address is essentially
the address of the underlying IP interface over which the tunnel interface is
configured.

Thanks - Fred

---

From: Andre Kostur <[email-masked]>
Date: Tue, 20 Jan 2015 11:52:10 -0800

> the address of the underlying IP interface over which the tunnel interface is

I think I have the same question as Ted: Assuming the DHCPv6 server
gets this list of link-layer addresses (I would presume in one or more
IAs), what's it going to do with that information?

As I recall, one of the concerns with having a client-supplied
link-layer address is whether we trusted that information.  Gleaning
it from the incoming packet, or having a relay (presumably a more
trusted device) do that gleaning was deemed more reliable.

-- 
Andre Kostur

---

From: "Templin, Fred L" <[email-masked]>
Date: Tue, 20 Jan 2015 20:39:14 +0000

Hi Andre,

> From: Andre Kostur [mailto:[email-masked]]
> Sent: Tuesday, January 20, 2015 11:52 AM
> To: Templin, Fred L
> Cc: Ted Lemon; dhcwg

The DHCPv6 server will not care which of the link-layer addresses the
client uses, but the server uses the link-layer addresses to populate the
IPv6 neighbor cache entry for the client's link-local address. So, when the
client issues a Request/Renew/Rebind, it can use a different link-layer
address and that address will be maintained in the IPv6 neighbor cache
entry along with any other such addresses.

> trusted device) do that gleaning was deemed more reliable.

There are a couple different aspects of this. First, the client and server must
either have some form of trust relationship or they must use DHCPv6
security. So, when the client issues an authentic Request/Renew/Rebind
the server can cache the client's link-layer address and only accept future
traffic that is sourced from that address.

However, if the client is on the other side of a NAT the address in the CLLAO
will not match the link-layer address of the packet when the server receives
it. In that case, the server's tunnel driver will need to rewrite the CLLAO
before passing the packet (minus the link-layer header) up to the DHCPv6
server process. Even better, the client can simply write the value 0 in the
CLLAO and the server's tunnel driver will rewrite the value unconditionally
before handing up to the DHCPv6 server process.

Thanks - Fred
[email-masked]

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Jan 2015 20:43:14 -0500

> the address of the underlying IP interface over which the tunnel interface is

So you are proposing that the client send the layer two address so that the response can be sent back on that same interface, and not one of the other possible interfaces?

---

From: Ted Lemon <[email-masked]>
Date: Tue, 20 Jan 2015 20:44:26 -0500

On Jan 20, 2015, at 3:39 PM, Templin, Fred L <[email-masked]> wrote:
> So, when the

Why not just do neighbor discovery to populate the neighbor cache?

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Jan 2015 15:40:19 +0000

Hi Ted,

> Sent: Tuesday, January 20, 2015 5:43 PM
> To: Templin, Fred L
> Cc: dhcwg

What would solve my problem, and I think may in the future be useful for
other non-Ethernet type interfaces, is the following:

- client includes CLLAO in its DHCPv6 messages
- first-hop relay rewrites CLLAO if it does not match the client's
  actual link-layer address, but does not insert a new CLLAO of its own
- server uses CLLAO for whatever purposes it needs, then returns  it
   in DHCPv6 replies

This is different than in RFC6939, but I think more consistent with how 'chaddr'
is done in DHCPv4. It would allow DHCPv6 operation over interfaces where it
is difficult or impossible for the DHCPv6 server and/or relay to determine the
client's link-layer address.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Jan 2015 15:46:46 +0000

Hi Ted,

> Sent: Tuesday, January 20, 2015 5:44 PM
> To: Templin, Fred L
> Cc: Andre Kostur; dhcwg

Address resolution on broadcast-capable interfaces works fine, but on NBMA
interfaces requires broadcast emulation (e.g., NHRP). I have an interface where
even broadcast emulation would be difficult if not impossible, so all I am asking
for is a small clue from the DHCPv6 server.

Thanks - Fred

---

From: Andre Kostur <[email-masked]>
Date: Wed, 21 Jan 2015 08:02:35 -0800

>   actual link-layer address, but does not insert a new CLLAO of its own

Yikes.  Not in DHCPv6.  First-hop relay should turn that into a
RELAY-FWD encapsulating the the original message.  No rewriting of the
original packet!

-- 
Andre Kostur

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Jan 2015 11:03:36 -0500

> for is a small clue from the DHCPv6 server.

How is this handled for non-DHCP IP traffic?

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Jan 2015 16:11:59 +0000

Hi Andre,

> Sent: Wednesday, January 21, 2015 8:03 AM
> To: Templin, Fred L
> Cc: Ted Lemon; dhcwg

The client could be on the other side of an address translator from the relay.
So, if the client is using link-layer address 'A' but the relay sees link-layer
address 'B', the relay needs to somehow communicate 'B' to the server.
The client could also benefit from learning that it's "outward appearance"
is 'B' and not 'A' as an indication that it is behind an address translator.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Jan 2015 16:16:27 +0000

Hi Ted,

> Sent: Wednesday, January 21, 2015 8:04 AM
> To: Templin, Fred L
> Cc: Andre Kostur; dhcwg

For non-DHCP traffic, there either needs to be a neighbor cache entry in
place (e.g., through manual configuration) or a way to statelessly derive
the link-layer address from the network-layer address (e.g., 6rd, isatap).

What I am after is a way to dynamically establish the nbr cache entry for
NBMA links where the link-layer address cannot be derived from the
network-layer address. AERO is an example of such a link.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Jan 2015 16:22:09 +0000

Hi Andre,

> Sent: Wednesday, January 21, 2015 8:12 AM
> To: Andre Kostur
> Cc: dhcwg; Ted Lemon

Actually, I am OK with not requiring special behavior of relays if we only
require this mechanism to be used when the client is on the same link
as the server. So, perhaps it would un-complicate matters if we just
leave relays out of this?

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Jan 2015 11:30:13 -0500

> network-layer address. AERO is an example of such a link.

So you're proposing to use DHCP as a replacement for neighbor discovery?

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Jan 2015 16:39:56 +0000

Hi Ted,

> Sent: Wednesday, January 21, 2015 8:30 AM
> To: Templin, Fred L
> Cc: Andre Kostur; dhcwg

I am proposing DHCPv6 to include options that can aid address resolution;
other aspects of IPv6 neighbor discovery are the same as for any NBMA link.

Thanks - Fred

---

From: Michael Richardson <[email-masked]>
Date: Wed, 21 Jan 2015 12:35:11 -0500

> So PPP uses DHCPv6 to number the endpoints of the link?   Wow.

It's optional; like all links.  If the RA says M=1, then you should use DHCPv6.
Whether or not to number the endpoints of a PPP link *at all* seems like a
good question to me; if you are doing DHCPv6PD, I'd say don't do that, and
just make sure the CPE device answers traceroutes on that link from a
routerID, even if it winds up taking a /64 to do just that.

The IPv6 NAS/BNS implementation I worked on last year numbers the NAS/BNS end
via SLAAC it if radius says to number it using the uh... FRAMED_IPV6_PREFIX.
(Noting of course that the link-layer addresses for PPP are usually entirely
made up...)

    > Right, the link-local IPv6 address.   I am puzzled as to why you'd need
    > something more than a link-local address, but if you did, DHCPv6 ought
    > to work with the link-local address, as long as one endpoint of the PPP
    > link knows to be the DHCP client and the other end knows to be the DHCP
    > relay.

    > When I've implemented DHCPv6, I haven't actually used a packet filter.
    > We designed it specifically so that would not be required.   You do
    > need stack support for SO_RVCDSTADDR, but that's it, at least in
    > principle.

Yup, and it works great.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Jan 2015 13:57:26 -0500

> other aspects of IPv6 neighbor discovery are the same as for any NBMA link.

Sure, but my point is that you are proposing to do the actual discovery of neighbors for addition to the neighbor table using DHCP.

This seems like a weird thing for the IETF to standardize, until AERO itself becomes a standard, which is something I haven't heard is in the offing.   I would encourage you to experiment with this using vendor options so that when/if that time comes, we will have some experience with it on which to base any standards work.   Is there some reason why we should rush this?

---

From: "Templin, Fred L" <[email-masked]>
Date: Wed, 21 Jan 2015 23:01:07 +0000

Hi Ted,

> Sent: Wednesday, January 21, 2015 10:57 AM
> To: Templin, Fred L
> Cc: Andre Kostur; dhcwg

The discovery of neighbors is actually happening within the AERO interface itself;
the DHCPv6 server itself has no idea that this is happening.

> This seems like a weird thing for the IETF to standardize, until AERO itself becomes a standard, which is something I haven't heard is in
> the offing.   I would encourage you to experiment with this using vendor options so that when/if that time comes, we will have some
> experience with it on which to base any standards work.   Is there some reason why we should rush this?

Understand your points. However, I do have a certain sense of urgency for specifying
the client-inserted CLLAO now because RFC6939 itself is still young enough that not all
implementations have picked up on it (at least I didn't see it in the ISC implementation)
and DHCPv6 security is not yet standardized nor widely deployed.

So, I would like to have this in place for when the time comes that AERO goes through
as standards track that it is already out in the DHCPv6 specs and implementations. Also,
I think this mechanism may well be useful for future data link types other than just
AERO. 

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Wed, 21 Jan 2015 20:59:12 -0500

> I think this mechanism may well be useful for future data link types other than just

Given that the working group explicitly decided not to do what you are proposing, I think this is not a good enough reason to revisit that consensus call.   However, it's really up to the chairs and the working group, not to me.   I haven't noticed anyone other than you and Andre participating in this discussion with me, so perhaps it would be good if we shut up and let the other working group participants weigh in.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 22 Jan 2015 04:25:10 +0000

I think the main reasons we didn't want clients to add this is a lack of trust (relay's extract the information from what the client actually sent the packet from - what if client puts different information in the packet?) and to remove redundant data.

I do think for "ethernet" networks we should not (MUST NOT) have clients add this option.

I see less of an issue for a dhcpv6 over foo document to allow the client can add this option. I am just concerned that clients will start always adding this and then we have "useless" baggage in packets.

The way to proceed is to write an individual submission draft justifying when this can be done by the client and why it is needed. The WG can discuss, then consider adoption and maybe eventual publication (if WG consenus exists).

We asked for agenda items for Dallas and have yet to receive a request.

Note that the -00 of the WG document allowed clients to add this, then it was removed for clients (though no real explicit prohibition), and finally in last version the clients MUST NOT was added. I believe I was strongly in favor of client prohibition.

- Bernie (from iPad)

> On Jan 21, 2015, at 8:59 PM, Ted Lemon <[email-masked]> wrote:
>

---

From: Ole Troan <[email-masked]>
Date: Thu, 22 Jan 2015 09:32:49 +0100

> I see less of an issue for a dhcpv6 over foo document to allow the client can add this option. I am just concerned that clients will start always adding this and then we have "useless" baggage in p…

in IPv6 we have tried very hard to make protocols data-link layer agnostic. e.g. ND works on any multicast capable link. so does DHCPv6. which is also the reason why there has been strong objections against replicating all the options of IPCP in IPv6CP for PPP.

I get concerned when you start talking about "DHCPv6 over foo" documents.

cheers,
Ole

---

From: perl-list <[email-masked]>
Date: Thu, 22 Jan 2015 06:41:28 -0500 (EST)

> and DHCPv6 security is not yet standardized nor widely deployed.

Indeed RFC6939 is young enough that even Cisco (two employees of which wrote the thing) hasn't deployed it, as far as I can tell. I have been waiting for router manufacturers to implement this. I hope 2015 is the year.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 22 Jan 2015 13:50:04 +0000

so where does that leave you on this issue about clients sending this option?

- Bernie (from iPhone)

---

From: Ole Troan <[email-masked]>
Date: Thu, 22 Jan 2015 15:02:30 +0100

> so where does that leave you on this issue about clients sending this option?

initially concerned. I'm not sure the right approach is to build neighbor/tunnel state based on this option.
I need to re-read what Fred is proposing in detail though.

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Jan 2015 15:59:00 +0000

Hi Ole,

> I get concerned when you start talking about "DHCPv6 over foo" documents.

You are right that this is motivated by a "DHCPv6 over (foo)" document. But, there
may be other "(foo's)" in the future that would benefit.

Still, the insertion of a CLLAO by the client could do no harm to legacy servers since
RFC6939 already says:

   "If the DHCP server receives a Client Link-Layer Address option
   anywhere in any encapsulated message that is not a Relay-Forward DHCP
   message, the server MUST silently ignore that option."

So, the text saying that the client "MUST NOT" include the option seems like
overkill.

Thanks - Fred

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 22 Jan 2015 16:06:09 +0000

Fred:

However, for your idea to work you have to change BOTH pieces of text -- client is allowed to insert the option AND server is allowed to process.

Just allowing the client to insert the option does no good if the server will be "silently ignoring that option"?

Or, are  you assuming the relay that will be using the client's option in your case (perhaps adding the CLLAO into the Relay-Forw so that the server uses it from there)? That would potentially be an interesting issue if Authentication is being used - since the relay doesn't authenticate the client's message (though if the client's CLLAO is just inserted by the relay without it using the information, perhaps not a big issue since the server would "drop" any client message that failed authentication).

Anyway, my suggestion of writing a (short) draft that explains the details of what you want to do is still the best as then we are hopefully more clear on exactly what you are proposing and why.

- Bernie

-----Original Message-----
From: Templin, Fred L [mailto:[email-masked]] 
Sent: Thursday, January 22, 2015 10:59 AM
To: Ole Troan; Bernie Volz (volz)
Cc: dhcwg; Ted Lemon; Andre Kostur
Subject: RE: [dhcwg] Comment on RFC6939 (Client Link-Layer Address Option)

Hi Ole,

> I get concerned when you start talking about "DHCPv6 over foo" documents.

You are right that this is motivated by a "DHCPv6 over (foo)" document. But, there may be other "(foo's)" in the future that would benefit.

So, the text saying that the client "MUST NOT" include the option seems like overkill.

Thanks - Fred

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Jan 2015 18:43:23 +0000

Hi Bernie,

> From: Bernie Volz (volz) [mailto:[email-masked]]
> Sent: Wednesday, January 21, 2015 8:25 PM
> To: Ted Lemon
> Cc: Templin, Fred L; dhcwg; Andre Kostur
> I think the main reasons we didn't want clients to add this is a lack of trust (relay's extract the information from what the client actually
> sent the packet from - what if client puts different information in the packet?) and to remove redundant data.

I am actually expecting the client to put a (mostly) NULL CLLAO in its message so that
the server's (foo) driver has a container to write the client's actual link-layer address
into before handing the DHCPv6 message up to the DHCPv6 server.
 
> I see less of an issue for a dhcpv6 over foo document to allow the client can add this option.

OK. For the ISC DHCPv6 implementation at least, the DHCPv6 server refuses to
run over anything that doesn't look a lot like Ethernet. So, perhaps we can see
this as opening new horizons for other (foo)-type documents.

> I am just concerned that clients will start
> always adding this and then we have "useless" baggage in packets.

Well, it is not a lot of extra space (22 bytes) and it will be put to good use.

> The way to proceed is to write an individual submission draft justifying when this can be done by the client and why it is needed. The
> WG can discuss, then consider adoption and maybe eventual publication (if WG consenus exists).

Here is the draft:

https://datatracker.ietf.org/doc/draft-templin-client-cllao/

> We asked for agenda items for Dallas and have yet to receive a request.

I will ask for an agenda slot.

> Note that the -00 of the WG document allowed clients to add this, then it was removed for clients (though no real explicit prohibition),
> and finally in last version the clients MUST NOT was added. I believe I was strongly in favor of client prohibition.

OK, but we have a new use case now that perhaps was not considered earlier.

Thanks  - Fred

> > Given that the working group explicitly decided not to do what you are proposing, I think this is not a good enough reason to revisit
> that consensus call.   However, it's really up to the chairs and the working group, not to me.   I haven't noticed anyone other than you
> and Andre participating in this discussion with me, so perhaps it would be good if we shut up and let the other working group
> participants weigh in.
> >

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Jan 2015 13:45:38 -0500

> into before handing the DHCPv6 message up to the DHCPv6 server.

The "server" you're describing here is a relay agent.   Just have it encapsulate the client message and send it as a relay message, with the l2 address exactly as described in RFC 6939.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Jan 2015 19:03:13 +0000

Hi Ted,

> Sent: Thursday, January 22, 2015 10:46 AM
> To: Templin, Fred L
> Cc: Bernie Volz; dhcwg; Andre Kostur
> The "server" you're describing here is a relay agent.   Just have it encapsulate the client message and send it as a relay message, with
> the l2 address exactly as described in RFC 6939.

I get your point, but that model would not quite satisfy the requirements. On
the server platform, I have both the DHCPv6-over-(foo) driver and the DHCPv6
server. The (foo) driver receives the client's requests and then hands them up
to the DHCPv6 server, which is waiting for DHCPv6 messages to appear on a
socket (using standard socket APIs). If the (foo) driver were configured to act
as a relay agent and wrap the client's message in a "Relay-Forward" message,
it is true that the CLLAO would be delivered to the server in the normal fashion.

But then, the server would assume that it is not on the same link as the
client when in fact it is. Also, in the reverse direction, the server would
have no way to return the CLLAO to the client which is one of the key
requirements specified in the draft.

Another thought that came to mind last night is that the DHCPv6-over-(foo)
document could declare DHCPv6 AUTH as unsupported for this link type
and then use the DHCPv6 AUTH option to carry the client's link-layer address
in the forward and reverse directions. But, I think you would agree that such
a "hack" might not be the cleanest architectural choice.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Jan 2015 14:04:50 -0500

> it is true that the CLLAO would be delivered to the server in the normal fashion.

Oh.  That's even easier.   Just put the (foo) driver in the DHCP server.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Jan 2015 19:17:56 +0000

Hi Ted,

> Sent: Thursday, January 22, 2015 11:05 AM
> To: Templin, Fred L
> Cc: dhcwg; Bernie Volz; Andre Kostur

Or, another way of looking at it, put the DHCPv6 server in the (foo) driver.
But, I know you know what that code looks like and I guarantee it would be
a humongous mess. Also removes clean interfaces between layers, and
makes it very difficult to use COTS or unmodified public domain DHCPv6
implementations.

But again, that would not satisfy the requirement of getting the CLLAO
back to the client. The client needs to know what it looks like to the
outside world, and only the DHCPv6 server can tell it that.

Thanks - Fred

---

From: Andre Kostur <[email-masked]>
Date: Thu, 22 Jan 2015 13:20:54 -0800

> requirements specified in the draft.

Why would it assume that?  The relay would supply an all-zeros link
address (RFC 6221).

-- 
Andre Kostur

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Jan 2015 22:54:18 +0000

Hi Andre,

> Sent: Thursday, January 22, 2015 1:21 PM
> To: Templin, Fred L
> Cc: Ted Lemon; Bernie Volz; dhcwg

RFC6221 is indeed a very good reference - almost perfect for what I need, but not
quite. What I still do not get is a way for the client to discover what its link-layer
address is from the viewpoint of the server (or from the LDRA, I guess).

This means that the client would not be able to discover through DHCPv6 messaging
alone whether there were L2 switching elements (e.g., proxies) in the path that
change the link layer source address.

The client may need to know this, and I would prefer to discover it in the initial
DHCPv6 messaging exchange rather than some later time. Any ideas?

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Jan 2015 18:14:34 -0500

> DHCPv6 messaging exchange rather than some later time. Any ideas?

Send it to the client as a vendor option (section 2.2.10 of RFC 3315).   You can even bypass the server if you want and send it as a relay-supplied option (RFC 6422).   I don't know if the open source servers support it yet (actually, I'm pretty sure Dibbler does, but don't know about ISC).

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Jan 2015 23:34:10 +0000

Hi Ted,

> Sent: Thursday, January 22, 2015 3:15 PM
> To: Templin, Fred L
> Cc: Andre Kostur; dhcwg; Bernie Volz
> Send it to the client as a vendor option (section 2.2.10 of RFC 3315).

Not great, but workable as a kludge. Still, there must be some way to use
standard DHCPv6 options.

> You can even bypass the server if you want and send it as a relay-
> supplied option (RFC 6422). 

That would be great! The LDRA could ask for the CLLAO to be included as a
relay-supplied option. That way, the client gets the CLLAO back and all is well.

I guess for that to happen, though, we would need to get CLLAO added to the
IANA list of "Options Permitted in the Relay-Supplied Options Option". How
hard would that be? Would it be any easier than to just have the client supply
the CLLAO in the first place?

Thanks - Fred

> I don't know if the open source servers support it yet (actually, I'm pretty sure Dibbler does, but don't
> know about ISC).

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Jan 2015 18:43:22 -0500

> the CLLAO in the first place?

You would just have to add that option to the list in the DHCP server configuration.   Here's your text from 6422 to justify doing this:

   DHCP server implementations SHOULD
   have an administrator-configurable list of RSOO-enabled options, so
   that new RSOO-enabled options do not require software to be updated.

And yes, you could use the CLLAO that way, since the client isn't going to crash if it receives it.   It won't know what to do with it unless you tell it, but you were going to have to do that anyway.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 22 Jan 2015 23:52:36 +0000

Hi Ted,

> Sent: Thursday, January 22, 2015 3:43 PM
> To: Templin, Fred L
> And yes, you could use the CLLAO that way, since the client isn't going to crash if it receives it.   It won't know what to do with it unless
> you tell it, but you were going to have to do that anyway.

I still need to have the client tell the LDRA/server something about itself as
supplementary information that goes along with the link-layer address. I
could do that by having the client include a vendor option, but again that is
ugly. Or, I could do it by simply having the client insert a CLLAO that the
server subsequently returns. Which comes back full circle again to my
mini-draft.

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Jan 2015 21:18:07 -0500

On Jan 22, 2015, at 6:52 PM, Templin, Fred L <[email-masked]> wrote:
> ugly.

The client sends a DUID.   Why isn't that enough?

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 23 Jan 2015 17:06:28 +0000

Hi Ted,

> Sent: Thursday, January 22, 2015 6:18 PM
> To: Templin, Fred L
> Cc: dhcwg; Andre Kostur; Bernie Volz

I need the client to tell the server (possibly by way of the LDRA) which of its
link-layer addresses is being represented in this request, since the client may
have multiple link-layer addresses associated with the same link-local address.

My problem would be solved if we could introduce the notion of a "CLLAO
Solicitation" message. The message is included by the client in its DHCPv6
requests. When the server receives the "CLLAO Solicitation", it responds by
including a CLLAO in its replies. The "CLLAO Solicitation" includes any link
layer specific information known to the client, and the corresponding
CLLAO echoes this information and appends the link-layer specific
information known to the server. It also works through relays (including
LDRA relays).

The "CLLAO Solicitation" message shares the same option code value as
the "CLLAO" message. The two are differentiated by the fact that the
client can only include "CLLAO Solicitation" messages and the server
can only include CLLAO messages.

Comments?

Thanks - Fred

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Fri, 23 Jan 2015 18:38:51 +0000

so why not put cllao option code in oro to "solicit".

this issue does seem to be growing and becoming much more complex.

if not mainstream, i think Ted's original suggestion of vendor option(s) is looking much better. you can get an enterprise id for AERO (or use Boeing's).

- Bernie (from iPhone)

> On Jan 23, 2015, at 12:06 PM, Templin, Fred L <[email-masked]> wrote:
> 
> Hi Ted,
>

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Jan 2015 19:56:08 +0100

Bernie,

> if not mainstream, i think Ted's original suggestion of vendor option(s) is looking much better. you can get an enterprise id for AERO (or use Boeing's).

if this is an implementation having problems providing the link-layer address to an application, wouldn't it be easier to fix the implementation than trying to work around a short coming in code with standards?

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 23 Jan 2015 18:57:06 +0000

Hi Bernie,

Yes, I thought about ORO - but, all you can put in the ORO is the option number
for the CLLAO; you can't put ancillary data like what I need to include.

So, options are either to define a "CLLAO Request Option"" by reusing the
CLLAO option code, or to define a vendor option as you say that would do
exactly the same thing. The reason to use CLLAO is if we think there will
ever be other link types that need to do the same sort of thing; otherwise,
vendor option should be OK.

What I am learning is that there are about a million different ways to do
things in DHCPv6 - the hard part is to pick one!

Thanks - Fred

> Sent: Friday, January 23, 2015 10:39 AM
> To: Templin, Fred L
> Cc: Ted Lemon; dhcwg; Andre Kostur

---

From: Andre Kostur <[email-masked]>
Date: Fri, 23 Jan 2015 11:05:40 -0800

> things in DHCPv6 - the hard part is to pick one!

The hard part is that DHCPv6 is not DHCPv4.  (And IPv6 is not IPv4)

And... I'm still not clear on what you're trying to do behind the
scenes, and why is seems that having the DHCPv6 sever send back what
it sees as link-layer address to the client solves some problem?  Or:
why doesn't the driver for whatever link type this is deal with this
complexity, instead of having the DHCP server send this back (and what
happens if the link _isn't_ using DHCPv6, but is using SLAAC?)

-- 
Andre Kostur

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 23 Jan 2015 20:08:17 +0000

Hi Andre,

> Sent: Friday, January 23, 2015 11:06 AM
> To: Templin, Fred L
> Cc: Bernie Volz (volz); Ted Lemon; dhcwg

Right. One of the things in DHCPv4 that got dropped when going to DHCPv6
is 'chaddr' (client-supplied h/w addr). That is why I have been struggling.

> it sees as link-layer address to the client solves some problem?

The server sees the client's link-layer address after it may have been
rewritten by some L2 device in the path (e.g., an L2 proxy). The client
only sees its link-layer address as it appears on the locally-attached
link segment before any L2 devices have a chance to rewrite it. In
essence, the server is holding up a mirror to show the client what
it really looks like to the outside world.

> Or:
> complexity, instead of having the DHCP server send this back

Because only the server (or relay) knows what the client looks like
from the outside world. So, the client needs to be told that.

> (and what

AERO links are link-local only. AERO nodes only ever use DHCPv6 PD
for autoconfiguration purposes (and then use any delegated prefixes
to number downstream links and networks, i.e., and *never* the
AERO link itself).

Thanks - Fred

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Jan 2015 21:17:14 +0100

Fred,

> it really looks like to the outside world.

sounds like you really want RFC5389.

cheers,
Ole

---

From: Ole Troan <[email-masked]>
Date: Fri, 23 Jan 2015 21:20:48 +0100

Fred,

cheers,
Ole

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 23 Jan 2015 20:57:03 +0000

Hi Ole,

> From: Ole Troan [mailto:[email-masked]]
> Sent: Friday, January 23, 2015 12:17 PM
> To: Templin, Fred L
> Cc: Andre Kostur; dhcwg; Bernie Volz (volz); Ted Lemon

Sort of like that, but this needs to be in-band with the DHCPv6 messaging
so that the correct L2 links are aligned with the correct L2 addresses. Other
works have also rolled their own when it comes to "layer 2 proxy discovery"
(e.g., RFC4380).

Thanks - Fred

---

From: Simon Hobson <[email-masked]>
Date: Sat, 24 Jan 2015 10:57:08 +0000

> to number downstream links and networks, i.e., and *never* the

Having been following this thread, albeit not too closely, it strikes me that many others may be in the same boat as me - wondering what on earth this AERO network is. A search comes up with all sorts of results that are clearly irrelevant (it's not a very unique name !) and a few that I have no idea if they are what you are talking about or not.
Perhaps if you could link to an "AERO for dummies" guide that gives a bit of an overview - particularly around these issues.

> sounds like you really want RFC5389.

Ah, STUN. As someone who's dealt with the problems NAT creates, I was kind of looking forward to not having NAT in IP6. What did strike me though, is that for those situations where people do insist on using prefix translation, there should be a protocol to allow endpoints to directly query the network and get an authoritative answer about what is being translated and how - rather than having to treat it as a black box and have to guess what is going on (which isn't much help with some forms of NAT, especially the "mangle things as much as possible and to hell with what it breaks" approach in some Zyxel devices).

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 26 Jan 2015 15:47:10 +0000

Hi Simon,

> From: dhcwg [mailto:[email-masked]] On Behalf Of Simon Hobson
> Sent: Saturday, January 24, 2015 2:57 AM
> To: dhcwg
> Having been following this thread, albeit not too closely, it strikes me that many others may be in the same boat as me - wondering
> what on earth this AERO network is. A search comes up with all sorts of results that are clearly irrelevant (it's not a very unique name !)
> and a few that I have no idea if they are what you are talking about or not.

Sorry for the contextual gap. Here is a pointer to the AERO draft:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

and, here are the charts I showed at IETF91:

http://www.ietf.org/proceedings/91/slides/slides-91-dhc-5.pdf

Thanks - Fred

> Ah, STUN. As someone who's dealt with the problems NAT creates, I was kind of looking forward to not having NAT in IP6. What did
> strike me though, is that for those situations where people do insist on using prefix translation, there should be a protocol to allow
> endpoints to directly query the network and get an authoritative answer about what is being translated and how - rather than having
> to treat it as a black box and have to guess what is going on (which isn't much help with some forms of NAT, especially the "mangle
> things as much as possible and to hell with what it breaks" approach in some Zyxel devices).
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Mon, 26 Jan 2015 20:46:16 +0000

Hi,

To conclude this thread, I have abandoned the idea of adapting RFC6939 CLLAOs for
AERO and will go with only Vendor Information Options for everything - which means
I will eventually need to ask IANA for an enterprise-number for AERO, which does not
seem like it should be too difficult.

I have also employed RFC6221 to address the "bump-in-the-wire" implementation
constraints, which appears to be exactly the purpose for which it was designed.

I would like to thank the working group for the guidance, and would appreciate
review input on Section 3.15 of the AERO draft itself (latest version is -51):

http://datatracker.ietf.org/doc/draft-templin-aerolink/

Thanks - Fred