Subject: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt

From: [email-masked]
Date: Tue, 04 Feb 2014 01:36:11 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the Dynamic Host Configuration Working Group of the IETF.

        Title           : IP Connectivity Status Notifications for DHCPv6
        Authors         : Prashanth Patil
                          Mohamed Boucadair
                          Dan Wing
                          Tirumaleswar Reddy
	Filename        : draft-ietf-dhc-conn-status-00.txt
	Pages           : 10
	Date            : 2014-02-03

Abstract:
   This specification extends DHCPv6 so that a DHCPv6 Relay Agent can
   dynamically inform the DHCPv6 server about the IP connectivity status
   of a host.  The IP connectivity status information is also triggered
   by any change in the connectivity as provided to the host.  The
   DHCPv6 server uses this information as an input to its decision-
   making about configuration parameters to be conveyed to that host.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-dhc-conn-status/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-dhc-conn-status-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/

---

From: Simon Perreault <[email-masked]>
Date: Tue, 04 Feb 2014 09:05:54 -0500

This is getting better!

Some editorial suggestions about this new part:

>       option-code   OPTION_HOST_CONNECTIVITY (TBA).
>       option-len    1.
>       status        8-bit field indicating IP family connectivity status
>                     of a host. The following codes are defined:
>                     +------+----------+
>                     |  Bit | Status   |
>                     +----- +----------+
>                     |  1   | IPv4     |
>                     |  2   | IPv6     |
>                     | 3..8 | Reserved |
>                     +------+----------+

Two things:
- It is customary to number bits starting from zero.
- It would be better to illustrate the bits in the preceding figure
rather than in a separate table. Something like this:

>       0                   1                   2                   3
>       0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |   OPTION_HOST_CONNECTIVITY    |          option-len           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |  Reserved |S|F|                                               |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

Then explain what Reserved, S, and F stand for. No need for a separate
table.

In that figure, please also offset bit numbers by one character to the
right. The rationale being that we are numbering bits, not frontiers
between bits. Also the 3-byte empty space needs to be either named or
removed. This would give either this:

>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |   OPTION_HOST_CONNECTIVITY    |          option-len           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |  Reserved |S|F|                Reserved                       |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

or this:

>        0                   1                   2                   3
>        0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |   OPTION_HOST_CONNECTIVITY    |          option-len           |
>       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
>       |  Reserved |S|F|
>       +-+-+-+-+-+-+-+-+

Simon
-- 
DTN made easy, lean, and smart --> http://postellation.viagenie.ca
NAT64/DNS64 open-source        --> http://ecdysis.viagenie.ca
STUN/TURN server               --> http://numb.viagenie.ca

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Feb 2014 09:14:46 -0500

> This is getting better!

It is, but I still don't understand why this is the right architectural solution.   We already have the DHCPv6 link-layer address relay option.   This allows a DHCPv4/DHCPv6 server to track clients and make allocations centrally in the same way that this proposal allows it to happen on relays.   From a management perspective, and from a relay complexity perspective, doing it on the server seems like a win.

Can you guys speak to this question?

---

From: Simon Perreault <[email-masked]>
Date: Tue, 04 Feb 2014 09:28:04 -0500

Le 2014-02-04 09:14, Ted Lemon a écrit :
> We already have the DHCPv6 link-layer address relay option.   This
> allows a DHCPv4/DHCPv6 server to track clients and make allocations
> centrally in the same way that this proposal allows it to happen on
> relays.   From a management perspective, and from a relay complexity
> perspective, doing it on the server seems like a win.

I'm sorry, I don't understand what you're suggesting. How would the
link-layer address be of any use? We want to know what kind of IP-layer
connectivity a client has, and we don't care about the link layer. What
do you mean by "making allocations"? How is the relay "making
allocations" in draft conn-status?

Simon

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Feb 2014 09:46:27 -0500

> allocations" in draft conn-status?

You can use the link-layer address in DHCPv6 to correlate to the link-layer address in DHCPv4.   By "make allocations" I mean "do what DHCP does, including assigning parameters."   Sorry for the imprecision.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 04 Feb 2014 09:57:42 -0500

Le 2014-02-04 09:46, Ted Lemon a écrit :
> You can use the link-layer address in DHCPv6 to correlate to the
> link-layer address in DHCPv4.   By "make allocations" I mean "do what
> DHCP does, including assigning parameters."   Sorry for the
> imprecision.

Ah, I see.

One answer is that this needs to work with SLAAC.

I'll let the authors reply.

Simon

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Feb 2014 11:04:42 -0500

> One answer is that this needs to work with SLAAC.

How can it work with SLAAC?

---

From: Simon Perreault <[email-masked]>
Date: Tue, 04 Feb 2014 11:37:14 -0500

> How can it work with SLAAC?

I was thinking:
The relay snoops the addresses as described in section 7. Then it sends
a reconfigure request.

But then I wondered: where does the DHCPv6 server send its reconfigure
if the client is not already "known" by the server?

And then I further wondered: what use is this draft if a client is
IPv4-only? The DHCPv6 server would not be able to talk to the client.

Me confused.

(I really should let the authors speak for themselves.)

Simon

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Feb 2014 11:39:12 -0500

> IPv4-only? The DHCPv6 server would not be able to talk to the client.

If the client is IPv4-only, the DHCPv4 server might change its behavior, but the DHCPv6 server would not, because there would be no behavior.   :)

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 4 Feb 2014 17:23:22 +0000

This may be one consequence of trying to make the draft more generic.

The original problem was about DNS (DNS64) as I recall from draft-wing-dhc-dns-reconfigure-02.

There were only two significant transitions in the dns-reconfigure draft: IPv6-only transition to Dual-Stack and Dual-Stack to IPv6-only.

As this option is only for DHCPv6, this is only useful when IPv6 (DHCPv6) is present. The question is whether IPv4 is also present on the host or not as that could influence the DNS information returned.

This one may be a good document to add to the Agenda for the London IETF - to try to resolve exactly what problems this is trying to solve and when, and then to figure out the solution. Hopefully one or more of the authors' will make a request for time at the London IETF.

- Bernie

-----Original Message-----
From: dhcwg [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Tuesday, February 04, 2014 11:39 AM
To: Simon Perreault
Cc: [email-masked] WG
Subject: Re: [dhcwg] I-D Action: draft-ietf-dhc-conn-status-00.txt

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

---

From: Ted Lemon <[email-masked]>
Date: Tue, 4 Feb 2014 12:25:13 -0500

> This one may be a good document to add to the Agenda for the London IETF - to try to resolve exactly what problems this is trying to solve and when, and then to figure out the solution. Hopefully o…

Sounds like a good plan.   Thanks!

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 5 Feb 2014 04:07:14 +0000

On 2/4/14 8:16 PM, "Ted Lemon" <[email-masked]> wrote:

>link-layer address in DHCPv4.

Sure. The idea was to be able to detect transitions as well i.e. Dual
stack to IPv6 only, which the server cannot detect unless informed.
Whether this detection is generically useful, needs discussion.

-Prashanth

>   By "make allocations" I mean "do what DHCP does, including assigning
>parameters."   Sorry for the imprecision.
>

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Feb 2014 07:44:01 -0500

> Whether this detection is generically useful, needs discussion.

Of course the server can detect this.   When the DHCPv4 lease expires without being renewed, either the host is no longer attached to the network, or it's v6-only.   Am I missing something?

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 5 Feb 2014 13:48:08 +0000

On 2/5/14 6:14 PM, "Ted Lemon" <[email-masked]> wrote:

>Of course the server can detect this.   When the DHCPv4 lease expires
>without being renewed, either the host is no longer attached to the
>network, or it's v6-only.   Am I missing something?

I should've been more precise. I meant a relay, using snooping mechanisms
(http://tools.ietf.org/html/draft-ietf-dhc-conn-status-00#section-7),
detecting that IPv4 is no longer active (even if lease hasn't expired) and
signaling this to the server.

-Prashanth

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Feb 2014 08:50:45 -0500

> signaling this to the server.

This seems pretty sketchy.

---

From: "Prashanth Patil (praspati)" <[email-masked]>
Date: Wed, 5 Feb 2014 14:15:03 +0000

>This seems pretty sketchy.

Yes, I suppose it is. The desire was to better manage configuration sent
down to the host, if possible. Especially if I started dual stack, see my
IPv6 working great and decide to turn off IPv4. The server could then
reconfigure appropriately, maybe with something more v6 efficient.

-Prashanth

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Feb 2014 09:18:46 -0500

On Feb 5, 2014, at 9:15 AM, Prashanth Patil (praspati) <[email-masked]> wrote:
> The desire was to better manage configuration sent
> IPv6 working great and decide to turn off IPv4.

It's unlikely that anybody would ever do that.   Most end users don't know the difference, and those that do are probably wise enough to realize that if the network configuration is working, changing it is as likely to cause problems as improvements.

More likely the network configuration would change as the result of a software update.   The software update would probably reconfigure the network anyway, so the problems would come out in the wash.   A software update that disables IPv4 by default when it is available on the network seems vanishingly unlikely.

More likely is that the network will stop providing IPv4, and the host will become IPv6-only by virtue of that change.

Are you seeing operational demand for this functionality?

---

From: Sten Carlsen <[email-masked]>
Date: Wed, 05 Feb 2014 16:17:27 +0100

If you turn off IPv4 on the host, that would mean a restart in most
cases. Tha means it would also not do anything on IPv4, no Discovery
etc. after some time the lease runs out and nothing more happens.

Is anything more needed? I am surely missing some detail here.

-- 
Best regards

Sten Carlsen

No improvements come from shouting:

       "MALE BOVINE MANURE!!!"

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Feb 2014 13:39:18 -0500

> Is anything more needed? I am surely missing some detail here.

The theory is that the relay agent will be able to inform the DHCPv6 server that this has happened.   I'm just having trouble imagining when this will happen, or why it's worth putting into a router's firmware.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 5 Feb 2014 22:14:55 +0000

Yeah, I was kind of skeptical about this too ... but (at least some) coauthors are from a router vendor, so they obviously believe this is worth doing (or getting someone within their organization to do). And, that issue was asked at the Vancouver IETF:

    Ted: the draft creates a problem: dual stack should always connect
      to IPv6 only
    Ted: asked if on charter?
    Ted: what router vendors plan to implement (Cisco as authors are
      from there)
    Simon Perreault: likes the solution

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Feb 2014 18:31:35 -0500

> Yeah, I was kind of skeptical about this too ... but (at least some) coauthors are from a router vendor, so they obviously believe this is worth doing (or getting someone within their organization…

The fact that someone who works for Cisco thinks Cisco might implement this isn't an indication that Cisco will implement it.   Maybe they will, maybe they won't.   That's why I was asking if there was demand for this solution.

I realize that this has been adopted by the working group, and that we talked about whether it fits with the charter, but if I agreed that it fit, I don't know what I was smoking.   What's interesting about this work is its operational aspect.   So the motivation for doing this should be coming from an ops working group, not the DHC working group.

Did this in fact come about as the result of some consensus from v6ops that this work was needed?

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Thu, 6 Feb 2014 00:12:19 +0000

> Did this in fact come about as the result of some consensus from v6ops that this work was needed?

Not to my knowledge.

If you won't allow it on the Charter, we will have to drop it. (That might even be the outcome if it does go on the charter.) From the call for adoption, there was support for this work and no one against it.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 5 Feb 2014 20:05:39 -0500

> If you won't allow it on the Charter, we will have to drop it. (That might even be the outcome if it does go on the charter.) From the call for adoption, there was support for this work and no one…

It's not covered by the current charter.   We could charter DHC to do the work, but is the working group enthusiastic enough about it to go to that trouble?   I'm sorry for being a sticky wicket after you've already adopted, but I think you need to get some working group who is competent to evaluate the proposal to look at it before DHC does any serious work on it.