Subject: [dhcwg] FW: I-D Action: draft-templin-client-cllao-00.txt

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

Hi, here is what I am after (about 2pgs of effective text). It would save me a world
of hurt and should not present any problems for existing implementations.

Comments?

Thanks - Fred
[email-masked]

-----Original Message-----
From: I-D-Announce [mailto:[email-masked]] On Behalf Of [email-masked]
Sent: Wednesday, January 21, 2015 10:41 AM
To: [email-masked]
Subject: I-D Action: draft-templin-client-cllao-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.

        Title           : Client-Inserted Client Link-Layer Address Options in DHCPv6
        Author          : Fred L. Templin
	Filename        : draft-templin-client-cllao-00.txt
	Pages           : 4
	Date            : 2015-01-21

Abstract:
   RFC6939 presents a method for DHCPv6 relay agents to insert a Client
   Link Layer Address Option (CLLAO) in a DHCPv6 Relay-Forward message.
   In some cases, however, the DHCPv6 client may need to insert a CLLAO
   in its message on its own behalf even though it is on the same link
   as the DHCPv6 server.  This document discusses client-inserted
   CLLAOs.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-templin-client-cllao/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-templin-client-cllao-00

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

_______________________________________________
I-D-Announce mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/i-d-announce
Internet-Draft directories: http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

---

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

> of hurt and should not present any problems for existing implementations.

You can already do this with a vendor option as an experiment.   Why do you need the IETF to publish a standard way of doing it?

---

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

Hi Ted,

> From: Ted Lemon [mailto:[email-masked]]
> Sent: Wednesday, January 21, 2015 12:26 PM
> To: Templin, Fred L
> Cc: dhcwg
> Subject: Re: [dhcwg] FW: I-D Action: draft-templin-client-cllao-00.txt
> 

Well, the CLLAO is exactly what I need now and I think may also be useful for
future data link types in a more generic sense going forward. For example, I
can remove the AERO reference from the document, and the specification
would still stand on its own.

The document explains the circumstances in which the client MAY insert a
CLLAO option, so it updates RFC6939. IMHO, that would complete the
RFC6939 specification and not contradict it. The timing is also such that
it  would be more convenient to update the specs and implementations
now rather than say a few years from now.

Thanks - Fred

---

From: Andre Kostur <[email-masked]>
Date: Thu, 22 Jan 2015 11:28:04 -0800

One item off the top:

"A DHCPv6 client SHOULD NOT include a CLLAO option if it is not on the
same link as the server."

The client doesn't know if it's on the same link as the server or not.
Something upstream may relay it elsewhere.

-- 
Andre Kostur

---

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

Hi Andre,

I understand your point in the general sense, but in some specific link types
the client may have a way of knowing that the server is on-link. How does
this sound for a re-write:

"A DHCPv6 client MUST NOT include a CLLAO option unless it has some
  way of knowing that it is on the same link as the server."

Thanks - Fred

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

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Jan 2015 15:56:39 -0500

>  way of knowing that it is on the same link as the server."

The point of DHCP is to configure clients.   Having the client "know" that it is on the same link as the server doesn't make sense.

---

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

Hi Ted,

> Sent: Thursday, January 22, 2015 12:57 PM
> To: Templin, Fred L
> Cc: Andre Kostur; dhcwg

I have a link type where there are guaranteed to be no relays; there will
only ever be clients and servers. Even if a client on a different link type
erroneously assumes that the server is on-link and a relay has to step in,
the following condition will be met:

   "A DHCPv6 server MUST ignore a CLLAO option supplied by the client if
   it is not on the same link as the client."

How does this sound as a rewrite:

  "A DHCPv6 client SHOULD NOT include a CLLAO option if there is a chance that
    its DHCPv6 messages will be processed by a relay."

Thanks - Fred

---

From: Ted Lemon <[email-masked]>
Date: Thu, 22 Jan 2015 16:26:24 -0500

> How does this sound as a rewrite:

We're talking at crossed purposes.   I haven't agreed that we need a rewrite.   I think you are trying to use a hammer to drive a screw.  I've explained to you how to use a screwdriver instead.