Subject: [v6ops] Please review the No IPv4 draft

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Apr 2014 10:50:13 -0400

Dearest V6OPS,

We are soliciting reviews for this SUNSET4 draft:

http://tools.ietf.org/html/draft-ietf-sunset4-noipv4-00

In a nutshell, it defines DHCPv6 and RA options indicating to the host
that IPv4 is not available. Reviews from operations-minded people in
V6OPS would be of tremendous help.

Thanks,
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: Nick Hilliard <[email-masked]>
Date: Mon, 14 Apr 2014 16:08:56 +0100

> V6OPS would be of tremendous help.

I'm puzzled as to why these options should go into dhcpv6.  Would dhcpv4
not be a much more sensible place to put them?  Putting them into dhcpv6 is
a very peculiar layering violation.

Creating a "No Service" option in DHCPv4 would be a more natural solution
to this problem which wouldn't involve layering violations or peculiar
inter-DHCP protocol hacks, and would only require modifying a single daemon
to implement it rather than creating a requirement for kernel level hacks
on multiple daemons.

Nick

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Apr 2014 11:11:57 -0400

> a very peculiar layering violation.

This is a comment that has already been made. It is addressed in section
4.1. Did you find the analysis unconvincing?

Thanks,
Simon

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 14 Apr 2014 16:44:42 +0100

> 4.1. Did you find the analysis unconvincing?

unfortunately, yes.  Taking the points in order:

4.1.1.1: "Devices that haven't been updated to speak IPv6 likely won't
recognize a new DHCPv4 code telling them that IPv4 isn't supported."  This
is a circular argument which is a bit pointless.

4.1.2 "Devices that don't speak IPv6...": this is not relevant.

4.1.3: maintaining ipv4 infrastructure:  this is reasonable, but there are
relatively simple workarounds with not much overhead (dhcp relays).

4.1.4: no way back: a DHCPv4 option can be enabled with a timeout.
Similarly, you could argue that there's no way back with any DHCP option
because you can set an option timeout to be unfeasibly large for anything.
 But we regard this as an operational or configuration error, not a
protocol problem.  Anyway, most PE access device operators will have some
back-door means of forcing a DHCP retry, e.g. forced line / carrier /
tunnel drops, etc.

Here are some reasons why No Service would be better served over DHCPv4:

0.  this is a protocol layering violation, plain and simple.  From an
architectural point of view, a v6 service should not provide signalling for
a v4 service or vice versa.

1. You need a protocol to allow the the DHCPv6 client to attempt to
communicate with the DHCPv4 client on the end host.  E.g. how do you get
the dibbler v6 client to tell ISC ipv4 dhclient to stop issuing DHCP
requests?  Unless there's a standardised mechanism for doing this, the
draft will not solve the problem you're trying to solve because the DHCPv4
and DHCPv6 clients may be different code trains from different vendors.

2. It would be necessary to implement this for both DHCPv4 and RA.  If it's
in the RA spec, then this will mean that some implementations will need to
have more kernel code to handle a user-space problem.  This is not sensible.

3. it would be trivially easy to implement a No Service option for dhcpv4.

As a separate issue, you may want to put in a time-out field into the
protocol with all-zeros or all-ones meaning infinite timeout.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Apr 2014 10:57:34 -0500

> a very peculiar layering violation.

How is it a layering violation?   And if you don't have IPv4, how do you have DHCPv4?

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 14 Apr 2014 17:08:28 +0100

On 14/04/2014 16:57, Ted Lemon wrote:
> How is it a layering violation?  

because you're using one protocol stack to send signals about another
protocol stack.  "layering violation" is possibly the wrong term.  Maybe
"protocol bleed" or some

> And if you don't have IPv4, how do you have DHCPv4?

this is the thing: the whole proposal is a bit circular. If there's no
DHCPv4 server, argument 3.1 is irrelevant and argument 3.2 is almost
irrelevant because on any shared access medium, dhcp traffic which is
ignored is not going to make up significant amounts of traffic.  There's
some justification for 3.3 but that can be dealt with on e.g. radio devices
by coalescing requests so that control request like this / RA / etc are
send alongside each other.  3.4 is an application level problem and it's
not the job of the ietf to fix stupid / broken applications.

If there is a dhcpv4 server in place (even a local stub server), then
bingo: create a No Service option and the problem disappears.

Nick

---

From: Owen DeLong <[email-masked]>
Date: Mon, 14 Apr 2014 09:06:15 -0700

I agree with NIck’s position. This should be addressed as a DHCPv4 option
rather than in DHCPv6.

Owen

On Apr 14, 2014, at 8:44 AM, Nick Hilliard <[email-masked]> wrote:

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

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Apr 2014 11:36:46 -0500

> protocol stack.  "layering violation" is possibly the wrong term.  Maybe

There is no such thing, and this isn't a valid distinction, at least according to current practice.   This is like saying that an HTTP server that runs over IPv6 can't redirect to a URL that would be fetched over IPv4, or that you can't do a DNS query for a AAAA record over IPv4, or an A record over IPv6.

> not the job of the ietf to fix stupid / broken applications.

It's broadcast traffic, which is expensive for everyone sharing a Wifi AP.   If every host is doing it, that's a lot of traffic.

Also, if I get a DHCPDISCOVER, and response with a DHCPOFFER with this option, is the expectation that the client will shut down at that point?   That's a substantial protocol change, if so.   If we're going all the way to DHCPACK, now the client has an IP address.   What if it tries to use it?

Only a client that's IPv6-capable is ever going to act on this option, so doing it with DHCPv4 doesn't really make sense.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 14 Apr 2014 09:49:12 -0700

> There is no such thing, and this isn't a valid distinction, at least according to current practice.   This is like saying that an HTTP server that runs over IPv6 can't redirect to a URL that would…

Not really…

An HTTP server shouldn’t be redirecting to an IP address at all. It should be redirecting via name. Since the address family that the name resolves to is opaque, a name is just a name.

Similarly, DNS is a database query, not a protocol signaling for configuration purposes.

What is being proposed here would be more like responding to an IPv4 packet with an ICMP6 unreachable, which I’m pretty sure would be considered problematic.

> It's broadcast traffic, which is expensive for everyone sharing a Wifi AP.   If every host is doing it, that's a lot of traffic.

Sure, so adding a form of NACK or DHCP-UNREACHABLE message to IPv4 makes sense to me.

> Also, if I get a DHCPDISCOVER, and response with a DHCPOFFER with this option, is the expectation that the client will shut down at that point?   That's a substantial protocol change, if so.   If w…

Why not, instead of using a DCHCPOFFER, provide an ICMPv4 DHCP-UNAVAILABLE message which can be sent in response to a DHCPREQUEST message by any router which is configured to authoritatively deny DHCPv4 on the link? A host receiving such a message should be expected to behave in an identical manner to the behavior proposed in this draft.

> Only a client that's IPv6-capable is ever going to act on this option, so doing it with DHCPv4 doesn't really make sense.

Only a client that’s going to try DHCPv4 is ever going to act on this option, so doing it in DHCPv6 doesn’t really make sense.

Owen

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 14 Apr 2014 18:15:36 +0100

On 14/04/2014 17:36, Ted Lemon wrote:
> Also, if I get a DHCPDISCOVER, and response with a DHCPOFFER with this
> option, is the expectation that the client will shut down at that point?
> That's a substantial protocol change, if so.

Stepping back a moment, the alternatives are:

1. wiring both dhcpv6 and ra to include an ipv4 protocol option, and then
designing and implementing a completely new protocol to get both
client-side dhcpv6 and ra to be able to talk to to a dhcpv4 client in a
standardised way so that either of them can pass a shutdown signal to the
dhcpv4 client.

2. implement a shutdown signal directly in dhcpv4.

The end result is the same:  the draft requests a requirement for a DHCPv4
client to shut itself down on receiving a signal.

> Only a client that's IPv6-capable is ever going to act on this option,
> so doing it with DHCPv4 doesn't really make sense.

Only a host which runs a dhcpv4 client is ever going to act on this option.
 From a strict point of view, it has nothing to do with ipv6.

Nick

---

From: Matthew Petach <[email-masked]>
Date: Mon, 14 Apr 2014 10:23:50 -0700

> >> protocol stack.  "layering violation" is possibly the wrong term.  Maybe
[...]

> Why not, instead of using a DCHCPOFFER, provide an ICMPv4 DHCP-UNAVAILABLE
> message which can be sent in response to a DHCPREQUEST message by any
> router which is configured to authoritatively deny DHCPv4 on the link? A
> host receiving such a message should be expected to behave in an identical
> manner to the behavior proposed in this draft.
>
>
Oooh, that could be fun at conferences...set my laptop up
to respond to broadcast DHCP requests with
DHCP-UNAVAILABLE responses, to keep all
the bandwidth for myself.  :)

Matt
(which is to say, the potential for abuse here seems
kinda high; are we sure this a good road for us to be
traveling down?)

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 14 Apr 2014 18:26:25 +0100

> kinda high; are we sure this a good road for us to be

This is no different to any other type of rogue dhcpv4 situation.

Nick

---

From: Philip Homburg <[email-masked]>
Date: Mon, 14 Apr 2014 19:33:19 +0200

In your letter dated Mon, 14 Apr 2014 11:36:46 -0500 you wrote:
>It's broadcast traffic, which is expensive for everyone sharing a Wifi AP.   I
>f every host is doing it, that's a lot of traffic.
>
>Also, if I get a DHCPDISCOVER, and response with a DHCPOFFER with this option,
> is the expectation that the client will shut down at that point?   That's a s
>ubstantial protocol change, if so.   If we're going all the way to DHCPACK, no
>w the client has an IP address.   What if it tries to use it?

I wonder if such an DHCPv4 option should be called 'no-service-at-the-moment'.
This can then be returned in the DHCPOFFER.

The option contains a timeout and clients should have a maximum what they
are willing the accept.

The client DHCP will stop sending DHCPDISCOVERs until the timeout has expired
or until the user/admin manually requests a DHCP lease.

This way the option becomes independent of IPv6 and can be use in any situation
where there won't be any offers for a while.

Note that if a client receives both an actual offer from one server and
the new option from an attacker, then the client can still continue with a
REQUEST, thus reducing the DoS potential.

---

From: Matthew Petach <[email-masked]>
Date: Mon, 14 Apr 2014 10:45:33 -0700

> This is no different to any other type of rogue dhcpv4 situation.
Correct me if I'm wrong, though; being an ICMP
response, rather than a DHCP response would
mean DHCP snooping wouldn't be sufficient to stop
me from engaging in mischief, where today settings
like DHCP snooping and DHCP guard could prevent
me from acting as a rogue DHCP server?

I suppose if we extend the concept of DHCP snooping
to also include ICMP snooping, that would work.

Thanks!

Matt

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Apr 2014 13:13:46 -0500

> What is being proposed here would be more like responding to an IPv4 packet with an ICMP6 unreachable, which I’m pretty sure would be considered problematic.

Okay, let's consider your example as it relates to the discussion.   Here we are talking about responding to an IPv6 packet with another IPv6 packet, which contains information about the availability of IPv4 service on the local wire.   In your example you are talking about responding to an IPv4 packet with an IPv6 packet.   So the two situations are not analogous.   I agree that if we were doing what you suggest in your example, that would be a bad idea, because the association between an IPv4 and an IPv6 address is something that would have to be inferred by the network, and that _would_ involve a layering violation.

But the actual use case we are talking about involves no such layering violation.

> Sure, so adding a form of NACK or DHCP-UNREACHABLE message to IPv4 makes sense to me.

So you are proposing a massive change to the DHCPv4 protocol in order to arrange for it to be able to be turned off, rather than a minor change to the DHCPv6 protocol to signal that there is no IPv4 available.   How does this make sense?

> Why not, instead of using a DCHCPOFFER, provide an ICMPv4 DHCP-UNAVAILABLE message which can be sent in response to a DHCPREQUEST message by any router which is configured to authoritatively deny D…

ICMP != DHCP.   You just objected to the No IPv4 proposal (or Nick did) on the basis that it's hard for a DHCPv6 client to pass information to a DHCPv4 client (which, TBH, sounds like a bug to me).   Why is it easier for the ICMP implementation in the kernel to pass information to the DHCPv4 client?   I have personal experience with this: there's code in the ISC DHCP server/client that has to catch bogus error messages pushed up the stack by the kernel and ignore them in order to avoid having its state machine broken, because the kernel has no way to associate ICMP messages with particular datagram sources.  My belief was that the kernel should discard such messages, because it can't do anything useful with them, but the linux guys decided to deliver them; neither solution is really satisfactory.  You are proposing to use this as a solution in favor of something that would actually work reliably.   That doesn't make sense.

The reality is that one of the biggest problems with the configuration system on linux is that the various components don't communicate with each other in a useful way.   Other operating systems manage to do a better job, and there's work ongoing in the linux community to fix this problem (e.g., systemd is now pulling a lot of network stack functionality into it specifically so that it can be part of the system configuration state machine as a whole, and dnsmasq does something similar).

So in reality it makes a tremendous amount of sense to put this information in DHCPv6, and the concern that it may be difficult to communicate the information to the IPv4 stack is a temporary situation that's easily addressed.   Putting it in IPv4 means more useless network traffic, more attack surfaces on IPv6-only routers, etc.

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Apr 2014 14:24:09 -0400

> standardised way so that either of them can pass a shutdown signal to the

$ grep "option no-ipv4" /var/db/dhclient6.leases.eth0 && pkill dhclient

- Is that too hard to implement?
- Why does that need to be standardized? It would be part of an OS'es
scripts and that usually doesn't get standardized.
- Wouldn't POSIX be the applicable standard? (semi-joking here)

>  From a strict point of view, it has nothing to do with ipv6.

Only a network that does provide IPv6 would ever want to set that
option. It has *everything* to do with IPv6.

Simon

---

From: Owen DeLong <[email-masked]>
Date: Mon, 14 Apr 2014 12:30:27 -0700

> the bandwidth for myself.  :)

And you can’t do this with the proposed IPv6 response we are discussing why?

Seems to me that the same potential for abuse exists with either situation.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 14 Apr 2014 12:32:49 -0700

> to also include ICMP snooping, that would work.

ICMP was just a suggestion. If you want to put it in DHCP/UDP to dodge abuse potential, I have no problem with that. The point is that this has no business being encoded in DHCPv6 or RA, it belongs in IPv4 somewhere.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Apr 2014 14:42:14 -0500

> Seems to me that the same potential for abuse exists with either situation.

This is true, and the remedy exists as well.  It's worth pointing out that "please review" doesn't mean "please redesign this."   It means "please point out technical flaws that you see."   None of what you or Nick has said sound like technical flaws to me—they sound like "I would prefer to do it this other way."

The working group considered doing it that other way and decided that on the balance, the way it's written now is better.   So unless there is some strong technical reason why it _shouldn't_ be done the way the working group has proposed, there's no basis for making a change.   It's issues like that that we are looking for in a v6ops review.

---

From: Gert Doering <[email-masked]>
Date: Mon, 14 Apr 2014 21:48:24 +0200

Hi,

> - Is that too hard to implement?

Yes.  My DHCP client is called "dhcpcd".  Nick's might be "pump".

> scripts and that usually doesn't get standardized.

Who do you expect to maintain that on the DHCPv6 client side, for all
possible combinations with DHCPv4 clients?

> option. It has *everything* to do with IPv6.

To the contrary.  A network that does not provide IPv4 would want to set
that option.  You might just not have public IPv4 here, because it's
a zeroconfo network with only IPv4 link-local (169.254) addresses.

Gert Doering
        -- NetMaster
-- 
have you enabled IPv6 on something today...?

SpaceNet AG                        Vorstand: Sebastian v. Bomhard
Joseph-Dollinger-Bogen 14          Aufsichtsratsvors.: A. Grundner-Culemann
D-80807 Muenchen                   HRB: 136055 (AG Muenchen)
Tel: +49 (0)89/32356-444           USt-IdNr.: DE813185279

---

From: Owen DeLong <[email-masked]>
Date: Mon, 14 Apr 2014 12:49:43 -0700

> So you are proposing a massive change to the DHCPv4 protocol in order to arrange for it to be able to be turned off, rather than a minor change to the DHCPv6 protocol to signal that there is no IPv…

Please explain to me why this is any more massive of a change to DHCPv4 than it would be to DHCPv6.

> ICMP != DHCP.   You just objected to the No IPv4 proposal (or Nick did) on the basis that it's hard for a DHCPv6 client to pass information to a DHCPv4 client (which, TBH, sounds like a bug to me).…

ICMP is the protocol generally intended to communicate that a service is unavailable. 

Using DHCPv6 to tell a client that DHCPv4 is not available seems a rather odd choice in my mind and I still have yet to see any clear indication why that’s preferable to using either DHCPv4 or some other IPv4 protocol such as ICMP to do so.

> The reality is that one of the biggest problems with the configuration system on linux is that the various components don't communicate with each other in a useful way.   Other operating systems ma…

I haven’t seen anything to indicate to me that the IPv6 configuration mechanisms in MacOS X, Solaris, BSD, or any other operating system are sufficiently coupled to the IPv4 configuration mechanisms (nor, arguably should they be) as to address this issue without substantial modification.

> So in reality it makes a tremendous amount of sense to put this information in DHCPv6, and the concern that it may be difficult to communicate the information to the IPv4 stack is a temporary situa…

You’re going to have to provide some clarification or documentation to back this claim up. I don’t see how responding to an IPv4 packet with an IPv4 packet indicating that the requested IPv4 service is unavailable means more useless network traffic or increases the attack surface on an IPv6-only router.

I’ll buy the argument that a simple ICMP response introduces new DOS vectors (though arguably if the RFC were written such that a client that receives both an ICMP and a DHCPOFFER would ignore the ICMP, I think that is largely mitigated), but I don’t buy that it increases the attack surface of the router or that it increases the useless network traffic.

In reality, most dual-stack clients are going to send out their DHCPv4 request either at the same time or earlier than their DHCPv6 request, so you’re going to see that first request either way. If the router immediately responds with a single packet saying “NO”, then that’s it. Otherwise, you wait until the DHCPv6 response comes back (mandating the additional overhead of DHCPv6 in networks that may well operate on SLAAC currently, thus introducing several additional unnecessary packets) and at most you’ve added one packet per client reboot, roughly. I have a hard time calling that “more useless network traffic”.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 14 Apr 2014 12:52:33 -0700

> option. It has *everything* to do with IPv6.

Nope…

Why wouldn’t a network that does not offer IPv4 autoconfigration not want to implement that option whether or not they do DHCPv6?

This is all about the unavailability of IPv4 auto configuration on the network. It has nothing inherently to do with IPv6 except that IPv6 is the most likely alternative to IPv4 that would be used. However, that’s just a likely majority use case, not the sole use case.

Owen

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Apr 2014 16:00:59 -0400

Le 2014-04-14 15:42, Ted Lemon a écrit :
> The working group considered doing it that other way and decided that
> on the balance, the way it's written now is better.   So unless there
> is some strong technical reason why it _shouldn't_ be done the way
> the working group has proposed, there's no basis for making a change.
> It's issues like that that we are looking for in a v6ops review.

This is entirely correct.

For the sake of history, we had in sunset4 a presentation of
draft-yang-dhc-ipv4-dis which is a DHCPv4-based solution. That was many
IETFs ago. We eventually merged with that draft. Since the goal is going
IPv6-only, a DHCPv4-based solution was considered a deal-breaker.

Simon

---

From: Owen DeLong <[email-masked]>
Date: Mon, 14 Apr 2014 13:01:49 -0700

> The working group considered doing it that other way and decided that on the balance, the way it's written now is better.   So unless there is some strong technical reason why it _shouldn't_ be don…

We can agree to disagree, but I feel that informing a host about the availability of IPv4 configuration services through an IPv6 configuration service is, in fact, a technically flawed concept.

Owen

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Apr 2014 16:05:17 -0400

> Yes.  My DHCP client is called "dhcpcd".  Nick's might be "pump".

I'm sorry, I don't see your point.

> possible combinations with DHCPv4 clients?

Why would anyone want to maintain that for all combinations of
implementations?

Take NetworkManager for example. It uses ISC DHCPv4+v6. So it implements
the above. That's all it needs to do. Other network daemons or sets of
init scripts would do similarly however they want. It's something that
gets implemented a level above the DHCP client, in the "glue" code.

> a zeroconfo network with only IPv4 link-local (169.254) addresses.

I'm not following your reasoning, sorry.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Apr 2014 16:10:13 -0400

> Why wouldn’t a network that does not offer IPv4 autoconfigration not want to implement that option whether or not they do DHCPv6?

Not sure what you mean. Our draft does specify RA and DHCPv6 versions of
the No-IPv4 option.

> This is all about the unavailability of IPv4 auto configuration on the network. It has nothing inherently to do with IPv6 except that IPv6 is the most likely alternative to IPv4 that would be used.…

Look, if IPv7 was a thing I would totally agree with you. It's not, so
what you're saying sounds like theoretical orthodoxy. We're trying to
fix real problems with moving to IPv6-only. I totally don't care about
non-IPv6 and non-IPv4 networks. And I don't see why anyone should.

Simon

---

From: Gert Doering <[email-masked]>
Date: Mon, 14 Apr 2014 22:12:31 +0200

Hi,

> I'm sorry, I don't see your point.

There are at least 3 different IPv4 DHCP clients on "Unix", and the
author and maintainer of the IPv6 DHCP client that is installed might
not know which IPv4 DHCP client you're using.

So either there is a standard way to communicate this across, as in
"all *IPv4* DHCP clients need to learn that", or it will fail in some
scenarios, no matter what the IPv6 DHCP client maintainers do.

(Also, I'd consider "just kill a foreign process" to be very rude - and
depending on the environment you're doing this in, it will be futile
as well, because a "service manager" of some sort could just report an
error, and restart the "failing" dhclient process).

> Why would anyone want to maintain that for all combinations of

"To make it work"?

[..]
> I'm not following your reasoning, sorry.

More bluntly: what makes you think that a network that has no IPv4 has IPv6?

Gert Doering
        -- NetMaster

---

From: Simon Perreault <[email-masked]>
Date: Mon, 14 Apr 2014 16:18:50 -0400

> scenarios, no matter what the IPv6 DHCP client maintainers do.

Ah I see what you mean.

I would not expect the DHCPv6 client to have any code added. It would be
the controlling "glue code" (e.g., NetworkManager, init scripts,
whatever) that would be modified.

> error, and restart the "failing" dhclient process).

Of course. The glue code would terminate the DHCPv4 client process in
the appropriate manner.

> More bluntly: what makes you think that a network that has no IPv4 has IPv6?

Because we absolutely don't care about other kinds of networks. We're
doing this so that IPv6 works better. We don't care about making IPv4
work better.

Simon

---

From: "George, Wes" <[email-masked]>
Date: Mon, 14 Apr 2014 16:20:26 -0400

On 4/14/14, 4:01 PM, "Owen DeLong" <[email-masked]> wrote:

>We can agree to disagree, but I feel that informing a host about the
>availability of IPv4 configuration services through an IPv6 configuration
>service is, in fact, a technically flawed concept.

I believe DHC would beg to differ with your opinion:
http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-dhcpv6

http://datatracker.ietf.org/doc/draft-ietf-dhc-dhcpv4-over-ipv6

We had a joint meeting with DHC in Berlin where we discussed this, because
we wanted to ensure coordination between the two groups on matters where
there is interaction between IPv4 and IPv6 DHCP.
http://www.ietf.org/proceedings/87/sunset4.html

Wes George

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Ray Hunter <[email-masked]>
Date: Mon, 14 Apr 2014 22:21:01 +0200

Ted Lemon wrote:
> On Apr 14, 2014, at 2:30 PM, Owen DeLong<[email-masked]>  wrote:

That we are discussing turning off IPv4 in both RA and DHCPv6 just 
highlights to me how ridiculous host configuration has become.

To me this proposal just introduces all sorts of horrible race 
conditions and inconsistencies, and I'm not convinced it's any better 
than just configuring up IPv4 via DHCPv4 with either a self assigned 
address or an RFC 1918 address and saying nothing about remote 
connectivity (given that most OSes already have IPv4 detection 
mechanisms in place to work out whether they are on a corporate network 
with proxies or the Internet or on an isolated island or whatever.)

e.g. what does a host do if RA says turn off IPv4, but DHCPv4 replies 
either before or after a host receives that RA advertisement?
Does the host have to then disable IPv4 once it is already up? For how long?

What if DHCPv6 and RA are not consistent (given they may not even be the 
same router or device responding)?

What if one router is IPv4 only and the other IPv6 only? And they're 
from 2 different ISP providers connected to a common L2 LAN? That's a 
perfectly valid configuration in my opinion.

Can an absence of "turn off IPv4" message be taken as a "turn on IPv4"?

How would this be implemented consistently given RA is generally ICMP 
(kernel space) and DHCPv6 user space (daemon)?

Given the O and M bit saga, what makes anyone think that this additional 
signalling will be any better?

Why would any end host trust this message?

IMHO the place to turn off or signal limited IPv4 connectivity is in 
DHCPv4 (if we ever even attempt to do that).

-- 
Regards,
RayH

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Apr 2014 20:34:08 +0000

>So you are proposing a massive change to the DHCPv4 protocol in order to arrange for it to be able to be turned off, rather than a minor change to the DHCPv6 protocol to signal that there is no IPv4…

Are the changes really so massive? (In total, yes there probably is a lot of code to tweak, but that will happen if it is done on the IPv6 or IPv4 side.)

To add this to DHCPv4, we would need a new option code that a client that supports the new "DHCPTURNOFF" message (or whatever it is called) includes in the PRL. The server would then know it can send it (if applicable). For clients that don't support this feature, the server would likely just ignore the packets (as if there was no server).

I think the main reasons for considering using IPv6 were:
1. IPv6 components are more likely to be updated (many people would probably prefer not to touch the v4 code if they don't have to anymore). Thus, this change can be rolled out with other changes.
2. For v6 only deployments (where there is no v4), this does require SOME v4 (i.e., to deploy the server - though "link-local" v4 addresses would be perfectly usable). There may also be relays to configure (which involves yet more v4) -- or new small server to implement to eliminate the relay. (If relays are used there might be some issues with whether all relays will relay the packet back to the client with the 'unknown' message type.)

If you have v4 and v6 available on your network, there's no clear winner. If you have only v6 on your network, using v6 to signal this has advantages.

There's one other minor consideration ... if v6 is used to signal this, it can also be used for manually configured IPv4 hosts (though of course you could just manually reconfigure those).

- Bernie

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: Monday, April 14, 2014 2:14 PM
To: Owen DeLong
Cc: [email-masked]
Subject: Re: [v6ops] Please review the No IPv4 draft

On Apr 14, 2014, at 11:49 AM, Owen DeLong <[email-masked]> wrote:
> What is being proposed here would be more like responding to an IPv4 packet with an ICMP6 unreachable, which I'm pretty sure would be considered problematic.

---

From: Owen DeLong <[email-masked]>
Date: Mon, 14 Apr 2014 13:39:56 -0700

> Not sure what you mean. Our draft does specify RA and DHCPv6 versions of

Not responsive to the above statement. It is possible that there are networks which do not implement IPv4 auto configuration that would want to use this option that also do not do IPv6. For example, a statically addressed IPv4 Wireless network may want to turn off clients sending DHCP discovers.

> non-IPv6 and non-IPv4 networks. And I don't see why anyone should.

I am not sure how IPv7 got inserted into this, but whatever… I’m talking about the fact that this option could, in fact, be useful for some IPv4-only networks as well. Non-IPv4 is not the same as IPv4 with no auto configuration. This isn’t about turning off IPv4, this is about turning off IPv4 auto configuration unless I completely misunderstand the draft in question.

Owen

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Mon, 14 Apr 2014 20:44:47 +0000

BTW: How significant is the problem anyway? Has this been analyzed by anyone?

Sure, the clients broadcast these packets but this is the "good" direction in Wifi - the Wifi 'switch' can be told to drop them. Other switches can to?

Seems to me that this would be far better to leave to the networking infrastructure to just 'block' the DHCPv4 packets if IPv4 isn't enabled?

Or are there networks where the periodic DHCPv4 DHCPDISCOVERs will end up costing significant overhead?

I suspect many access networks (i.e. DOCSIS - the IP Provisioning Mode TLV) already provide some information about whether v4, v6, or both are available?

- Bernie

-----Original Message-----
From: Bernie Volz (volz) 
Sent: Monday, April 14, 2014 4:34 PM
To: 'Ted Lemon'; Owen DeLong
Cc: [email-masked]
Subject: RE: [v6ops] Please review the No IPv4 draft

- Bernie

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 14 Apr 2014 22:07:03 +0100

On 14/04/2014 20:42, Ted Lemon wrote:
> The working group considered doing it that other way and decided that on
> the balance, the way it's written now is better.

Ted, there seems to have been relatively little discussion about this
point.  There's nothing in any of the sunset4 mailing lists, and the only
reference I can find to not using dhcpv4 for this purpose were the
presentation and minutes at ietf84, neither of which devoted much attention
to the problem, as far as I can see.

> https://tools.ietf.org/agenda/84/slides/slides-84-sunset4-9.pdf
> https://tools.ietf.org/wg/sunset4/minutes?item=minutes-84-sunset4.html

I may be missing something though.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Apr 2014 22:12:30 -0500

> Please explain to me why this is any more massive of a change to DHCPv4 than it would be to DHCPv6.

Because you are changing the protocol state machine.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Apr 2014 22:15:23 -0500

> not know which IPv4 DHCP client you're using.

This is not something to brag about.   Network configuration works badly on machines that operate this way.   I say this as the author of one of those DHCP clients.   This problem needs to be fixed, not papered over, and using it as an excuse to do the wrong thing in a protocol spec is absurd.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Apr 2014 22:17:15 -0500

On Apr 14, 2014, at 3:21 PM, Ray Hunter <[email-masked]> wrote:
> e.g. what does a host do if RA says turn off IPv4, but DHCPv4 replies either before or after a host receives that RA advertisement?

The network is mismanaged or under attack.   Fix it.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 14 Apr 2014 22:23:11 -0500

> I may be missing something though.

You are, and I believe Simon already mentioned what it was.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 15 Apr 2014 13:20:36 +0900

> V6OPS would be of tremendous help.

I don't see a strong use case for this. It seems to me that the two
scenarios in the introduction can be solved by simply configuring the
DHCPv4 relay (or the server, if on-link) to drop all DHCPv4 requests.

Am I missing something?

---

From: Owen DeLong <[email-masked]>
Date: Mon, 14 Apr 2014 21:50:09 -0700

> Because you are changing the protocol state machine.

So, you’re saying having some external process kill the DHCP4 client in response to a message received via DHCPv6 is less of a change to the protocol state machine than having DHCPv4 client die in response to a similar message… Right.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Mon, 14 Apr 2014 21:51:06 -0700

> This is not something to brag about.   Network configuration works badly on machines that operate this way.   I say this as the author of one of those DHCP clients.   This problem needs to be fixed…

Calling it the wrong thing while advocating an even more wrong thing is equally absurd.

Owen

---

From: Ray Hunter <[email-masked]>
Date: Tue, 15 Apr 2014 08:08:15 +0200

> Ted Lemon <mailto:[email-masked]>
> 15 April 2014 05:17
>
See Homenet Architecture 3.2.2.2.  B: Two ISPs, Two CERs, Shared subnet. 
http://tools.ietf.org/html/draft-ietf-homenet-arch-13#page-18

What when one ISP says "No IPv4 Service" whilst the other ISP says "Yes 
IPv4, and here's your address"?

This is NOT a misconfiguration IMHO, but a weakness in the assumptions 
lying behind this draft i.e. that all routers on a link are managed by 
one self-consistent management entity for both IPv6 and IPv4.
> Ray Hunter <mailto:[email-masked]>
> 14 April 2014 22:21
>
>
>
>
> mechanisms in place to work out whether they are on a corporate 
> network with proxies or the Internet or on an isolated island or 
> whatever.)
>
> What if DHCPv6 and RA are not consistent (given they may not even be 
> the same router or device responding)?
>
> Given the O and M bit saga, what makes anyone think that this 
> additional signalling will be any better?
>
> ------------------------------------------------------------------------

-- 
Regards,
RayH

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Apr 2014 10:01:27 +0200 (CEST)

On Tue, 15 Apr 2014, Ray Hunter wrote:

> What when one ISP says "No IPv4 Service" whilst the other ISP says "Yes IPv4, 
> and here's your address"?

Then you will still have IPv4 within the home, but just a single subnet.

Perhaps the flag should be "IPv4 service available from me", and should 
be thought of as per-router based in the context of MIF. If all RAs seen 
has "0" on the IPv4 available option, then don't ask for IPv4.

Yes, this is a problem if "ships-in-the-night" approach is done, and IPv4 
and IPv6 is done by different routers. Perhaps the flag should be seen as 
a hint, approximately the same as the M flag, and if it's set to 0 then 
stop doing DHCPv4 after 1 minute if you don't get an answer?

> This is NOT a misconfiguration IMHO, but a weakness in the assumptions lying 
> behind this draft i.e. that all routers on a link are managed by one 
> self-consistent management entity for both IPv6 and IPv4.

As far as I can see, there is no good solution to the goal of indicating 
that IPv4 is available or not. There are just subjective opinion what is 
least bad. I think it's good we're discussing it.

>From what I can tell, explicitly telling DHCPv4 that there isn't IPv4 
available has a use-case, but also a way to turn DHCPv4 back on at a later 
date, and unless we come up with a new mechanism, this isn't available 
unless we do it with the existing IPv6 mechanisms.

So, what's the least evil here? Updating IPv4 software functionality or 
extend existing IPv6 ones? I think the draft is a good summary of the 
options we have. Clarification what should be done when there is 
non-congruent information sent by different routers in their RAs is 
needed, however.

I actually don't have a strong opinion either way, both solutions on their 
own have drawbacks. Only way to really solve this would be to have 
DHCPv4 gain "no IPv4 address available here" and also IPv6 gain hint flag 
as to if IPv4 is available or not, and this wouldn't be 100% 
deterministic.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: "Niall O'Reilly" <[email-masked]>
Date: Tue, 15 Apr 2014 09:25:02 +0100

At Tue, 15 Apr 2014 13:20:36 +0900,
Lorenzo Colitti wrote:
> 
> I don't see a strong use case for this.

  You are not alone!

> It seems to me that the two

  Why go even that far?  What's wrong with the minimalist solution of
  just not providing any DHCPv4 service, and leaving the client to
  pick a link-local IPv4 address?

  Is the noise/signal (stet!) ratio in client-generated traffic already
  so low that a few DHCPDISCOVERs per client would be noticeable?

> Am I missing something?

  Or I?

  ATB
  Niall O'Reilly

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Apr 2014 10:27:41 +0200 (CEST)

>  so low that a few DHCPDISCOVERs per client would be noticeable?

If you have thousands of devices in the same domain, so yes.

Also, you have to remember that some devices will try to ARP for 
"everything" when IPv4 is still turned on (using its IPv4 LL address). 
Having IPv4 be completely turned off on a LAN actually makes quite a lot 
of sense.

So yes, there is a use-case.

---

From: Gert Doering <[email-masked]>
Date: Tue, 15 Apr 2014 10:30:54 +0200

Hi,

On Mon, Apr 14, 2014 at 10:15:23PM -0500, Ted Lemon wrote:
> This is not something to brag about.   Network configuration works
> badly on machines that operate this way.   I say this as the author
> of one of those DHCP clients.   This problem needs to be fixed, not
> papered over, and using it as an excuse to do the wrong thing in a
> protocol spec is absurd.

It's called "multiple independent implementations of the same spec", and
I'm not sure what's wrong about it.  Actually it's pretty good to have
alternatives and competition there, if one of the implementations is
buggy or lacking behind.

Yes, it would be even nicer if all these implementations would use
a common API so you could really just plug-replace them, and remote-control
them, all in the same way - but *that* is not "part of the spec".

Gert Doering
        -- NetMaster

---

From: Gert Doering <[email-masked]>
Date: Tue, 15 Apr 2014 10:36:15 +0200

Hi,

> So yes, there is a use-case.

I agree to this.  Interestingly, this is something else than "just shutdown
the dhcpv4 client if this option is detected" - it is "shutdown IPv4", which
many OSes can't do today at all (and yes, that needs fixing).

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Apr 2014 10:53:56 +0200 (CEST)

On Tue, 15 Apr 2014, Gert Doering wrote:

> I agree to this.  Interestingly, this is something else than "just 
> shutdown the dhcpv4 client if this option is detected" - it is "shutdown 
> IPv4", which many OSes can't do today at all (and yes, that needs 
> fixing).

You're right. I just realised I implicitly thought that "shutdown DHCPv4" 
and "shutdown IPv4" is the same thing, but it isn't.

So the flag should really be "of IPv4 and IPv6, use only IPv6" and I 
actually think this is ok to put in IPv6.

I would prefer to see this information in RAs after thinking a bit more of 
this.. And I think it should be hints in the style of M and O flags, 
meaning the client can still try DHCPv4 for a short while if it really 
wants to, but it should listen to the hint if it doesn't see significant 
IPv4 traffic.

Would it make sense to have a "deactivate IPv6 stack for the lifetime of 
this RA"-message as well?

---

From: Tina TSOU <[email-masked]>
Date: Tue, 15 Apr 2014 09:01:17 +0000

Dear Gert et al,

Should it be addressed in sunset4 WG?

Thank you,
Tina

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Gert Doering
Sent: Tuesday, April 15, 2014 4:36 PM
To: Mikael Abrahamsson
Cc: [email-masked] WG
Subject: Re: [v6ops] Please review the No IPv4 draft

Hi,

On Tue, Apr 15, 2014 at 10:27:41AM +0200, Mikael Abrahamsson wrote:
> >  Is the noise/signal (stet!) ratio in client-generated traffic 
> > already  so low that a few DHCPDISCOVERs per client would be noticeable?
> 
> Having IPv4 be completely turned off on a LAN actually makes quite a 
> lot of sense.
> 

I agree to this.  Interestingly, this is something else than "just shutdown the dhcpv4 client if this option is detected" - it is "shutdown IPv4", which many OSes can't do today at all (and yes, that needs fixing).

Gert Doering
        -- NetMaster

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 15 Apr 2014 11:02:47 +0200 (CEST)

> Should it be addressed in sunset4 WG?

Sounds appropriate, yes.

---

From: Gert Doering <[email-masked]>
Date: Tue, 15 Apr 2014 13:24:55 +0200

Hi,

> Should it be addressed in sunset4 WG?

We're discussing a draft that came over from sunset4 for feedback.

Gert Doering
        -- NetMaster

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 15 Apr 2014 12:35:02 +0100

> You are, and I believe Simon already mentioned what it was.

Email is proving a bad medium for communication here.  Let me guess that
you're referring to Simon's comment in his email of 2014-04-14 16:00:59
-0400, which was stated on page 4 of slides-84-sunset4-9.pdf:

> Since the goal is going IPv6-only, a DHCPv4-based solution was
> considered a deal-breaker

and:

> Must be transported over IPv6
> –
> ...since the goal is eliminating IPv4

This is not an especially relevant argument because if there were a dhcpv4
option to handle this, all you would need to provide the service would be a
local stub dhcpv4 mechanism to reply with a DHCPOFFER with a No Service
option. There would be no requirement to back-haul the initial DHCPREQUEST
to a centralised provisioning system.  IOW, from an operational point of
view, this can be provided simply and easily using dhcpv4 at the local
level, and this mechanism would spectacularly avoid the deployment problems
that Ray outlined.  Handling this over DHCPv6 involves a level of string,
gum and duck tape that makes me want to cringe.

As a separate issue, if the operator really wants to disable all ipv4, why
not disable ethertypes 0x0800 and 0x0806 at the mac forwarding layer?

Nick

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 15 Apr 2014 12:54:56 +0100

> Because you are changing the protocol state machine.

it's a single new state with a single transition point, and it would need
to added to the state machine regardless of whether the signal comes
directly through dhcpv4 or indirectly through dhcpv6 or ra.  The difference
between the two is that dhcpv6/ra would need an asynchronous transition
which significantly complicates the dhcpv4 FSM because you would now have
the possibility of a transition from any dhcpv4 state to the No IPv4 state.
 IOW, you're creating a longjmp style exception mechanism in the FSM.  This
is not a sensible thing to aim for.

Nick

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 09:13:58 -0400

Le 2014-04-14 16:39, Owen DeLong a écrit :
>>> Why wouldn’t a network that does not offer IPv4 autoconfigration 
>>> not want to implement that option whether or not they do DHCPv6?
>> 
>> Not sure what you mean. Our draft does specify RA and DHCPv6 
>> versions of the No-IPv4 option.
> 
> Not responsive to the above statement. It is possible that there are 
> networks which do not implement IPv4 auto configuration that would 
> want to use this option that also do not do IPv6. For example, a 
> statically addressed IPv4 Wireless network may want to turn off 
> clients sending DHCP discovers.

Are you saying we should be trying to make non-IPv6 networks work
better? Because we totally don't care about those.

> I’m talking about the fact that this option could, in fact, be useful
> for some IPv4-only networks as well.

We don't care about IPv4-only networks.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 09:18:20 -0400

> DHCPv4 relay (or the server, if on-link) to drop all DHCPv4 requests.

DHCP clients do not interpret the absence of response as absence of IPv4
service. They will endlessly retry. It is this endless, periodic
retrying that causes the problems we list in section 3.

As an example, ISC dhclient retries every ~2 minutes or so by default.
(From my memory.)

> Am I missing something?

Basically we're trying to make DHCPv4 clients shut up.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 09:19:52 -0400

Le 2014-04-15 04:25, Niall O'Reilly a écrit :
>   just not providing any DHCPv4 service,

...which, from the point of view of the client, is exactly the same as
Lorenzo's suggestion of dropping requests.

>   and leaving the client to

The host will do that in some cases, but in general DHCPv4 clients will
not simply shut up. They will retry endlessly.

>   so low that a few DHCPDISCOVERs per client would be noticeable?

Yes. Please see the issues this creates that are listed in section 3 of
our draft.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 09:29:30 -0400

> Does the host have to then disable IPv4 once it is already up? For how

Yes. Forever. This is in our draft.

If IPv4 is already up, then there is a problem with your network's
configuration. If you're saying over IPv4 that there is no IPv4 service,
but on the other hand you *are* in fact providing IPv4 service, there's
a contradiction somewhere. So in fact what would happen is the host
would abort an unresponsive IPv4 provisioning process.

> same router or device responding)?

Then you have a network configuration consistency problem. We have the
same issue whenever we define similar options in DHCPv6 and RA. Take for
example DNS resolver provisioning, which is IMHO worse because we're not
even talking about conflicting binary options, but list-values options
that need to be merged somehow.

This is not germane to the No-IPv4 problem. I wouldn't mind removing
either the DHCPv6 or RA option if provisioning consistency proves to be
an issue that people care about.

> perfectly valid configuration in my opinion.

Absolutely. This is why we define how this option works in
multiple-interfaces scenarios. This is all in the draft.

> Can an absence of "turn off IPv4" message be taken as a "turn on IPv4"?

No. It's an absence of information, period.

> (kernel space) and DHCPv6 user space (daemon)?

I would make it all percolate all the way up to the controlling glue
code (e.g., NetworkManager or init scripts).

> signalling will be any better?

Because it helps fix real problems we're having today, and it helps
people move to IPv6-only networks.

> Why would any end host trust this message?

Why would any end host trust anything received over DHCP or RA? This
issue is not germane to the No IPv4 problem.

> DHCPv4 (if we ever even attempt to do that). 

Why?

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 09:31:56 -0400

> gum and duck tape that makes me want to cringe.

This doesn't work when the L2 link is shared with clients to which you
do want to provide IPv4 service.

> not disable ethertypes 0x0800 and 0x0806 at the mac forwarding layer?

This doesn't work when the L2 link is shared with clients to which you
do want to provide IPv4 service.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 09:36:46 -0400

> I suspect many access networks (i.e. DOCSIS - the IP Provisioning Mode TLV) already provide some information about whether v4, v6, or both are available?

That is true, but there's no way to propagate this information to more
hosts in the home. So you end up with DHCP requests eating battery life
in the home. Our draft describes how to propagate the No-IPv4 knowledge
inside the home.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 09:38:58 -0400

> many OSes can't do today at all (and yes, that needs fixing).

Correct, it means "shutdown IPv4". Our draft lists precisely what needs
to be shut down. And you're correct in that implementing this could mean
more than just "pkill dhclient" on some OSes. But that work needs to
happen anyway.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 09:41:29 -0400

> actually think this is ok to put in IPv6.

That's a nice way to put it!

> I would prefer to see this information in RAs after thinking a bit more
> of this.. And I think it should be hints in the style of M and O flags,

Sure, we can add some leeway to the text. As long as it makes hosts
eventually shut up, we're good.

> this RA"-message as well? 

I personally don't see a need.

Simon

---

From: Ray Hunter <[email-masked]>
Date: Tue, 15 Apr 2014 15:54:39 +0200

> do want to provide IPv4 service.
Wait a minute. If there's routers there that need to provide IPv4 
selectively to some client nodes on the same L2 link then you almost 
certainly have an on link DHCPv4 server already. Or at least an IPv4 
speaking router that can support one. And that is most likely already 
hooked in to a centralised provisioning system via DHCPv4 relays.

And you anyway have to track L2 addresses to know which nodes on the 
link DO need a proper IPv4 service and which DON'T.

In that case, just assigning all clients that do not enjoy an IPv4 
service an address from a network 10.X.X.X/8 (the range can can be 
re-used on every end router) and filtering at L3 with an access list has 
exactly the same effect.
Better still: assign those hosts that should not be using IPv4 an 
address with a very long lease via DHCPv4 from one of your RTBH black 
hole ranges. http://tools.ietf.org/html/rfc5635.

They'll never send packets off link and they'll not retransmit DHCPv4 
requests for a very long time.

It's re-using an existing mechanism that is operationally proven, is 
unlikely to cause surprises, and has the advantage of not requiring any 
new code on either the end nodes nor the last-hop routers.

> do want to provide IPv4 service.
We should fix this in IPv4. Polluting IPv6 with IPv4 switches is a bad move.

Why does anyone think that badly behaved DHCPv4 clients will be any 
better behaved because there's a (new) DHCPv6 or RA option being advertised?
If they're broken for IPv4 and haven't been patched for a long time, 
they're even more likely to be broken for IPv6, and just as likely not 
to be patched IMHO.

-- 
Regards,
RayH

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 10:06:23 -0400

> new code on either the end nodes nor the last-hop routers.

Can this be propagated inside a home?

> better behaved because there's a (new) DHCPv6 or RA option being

Badly behaved? Who said anything about badly behaved clients? We're
assuming correct implementations here.

Simon

---

From: "Dale W. Carder" <[email-masked]>
Date: Tue, 15 Apr 2014 09:21:03 -0500

> V6OPS would be of tremendous help.

I guess I am still confused by your use cases.  In looking at our dhcpv4 
servers, I don't have No-IPX nor No-AppleTalk options sent to clients,
so I am confused why this is needed for IPv4.

3.1:  Turn off the dhcpv4 relay feature per router (sub)interface.  No more 
load on the dhcpv4 server.

3.2:  At the edge of your network, filter packets containing ethertypes you 
do not support.  

3.3:  Mobile device vendors have an incentive in fixing their code so
they do not chew up their battery more than their competitors.

3.4:  At the edge of your network, filter packets containing ethertypes you 
do not support.

I think I understand 5.3 however I think you made a much better argument for 
turning off dhcp relay and ethertype filtering.  The v4-level just says
where the filter would best be configured.

Since not every host would understand the No_IPv4 option, you are probably 
just going to have to filter in your network anyway if Section 3 is truly 
a problem.

Dale

---

From: Owen DeLong <[email-masked]>
Date: Tue, 15 Apr 2014 08:09:27 -0700

I would support an RA flag that says “If you’re reading this message, don’t do IPv4 on this network”.

That’s not even close to what is proposed here.

What is proposed here is a variety of IPv6 methods for telling a client to turn off it’s IPv4 dynamic configuration requests and there’s no reason to put that into IPv6 at all.

Owen

On Apr 15, 2014, at 1:53 AM, Mikael Abrahamsson <[email-masked]> wrote:

> You're right. I just realised I implicitly thought that "shutdown DHCPv4" and "shutdown IPv4" is the same thing, but it isn't.
> 
> So the flag should really be "of IPv4 and IPv6, use only IPv6" and I actually think this is ok to put in IPv6.
> 
> I would prefer to see this information in RAs after thinking a bit more of this.. And I think it should be hints in the style of M and O flags, meaning the client can still try DHCPv4 for a short while if it really wants to, but it should listen to the hint if it doesn't see significant IPv4 traffic.
> 
> Would it make sense to have a "deactivate IPv6 stack for the lifetime of this RA"-message as well?
> 
> --

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 11:16:02 -0400

> so I am confused why this is needed for IPv4.

IPv4 has billions of deployed devices. IPX and AppleTalk, not so much.

> load on the dhcpv4 server.

Not possible if the L2 link is shared with devices to which you do want
to provide IPv4 service.

> 3.2:  At the edge of your network, filter packets containing ethertypes you 

Not possible if the L2 link is shared with devices to which you do want
to provide IPv4 service.

> they do not chew up their battery more than their competitors.

Yet the problem has not been fixed.

> 3.4:  At the edge of your network, filter packets containing ethertypes you 

Not possible if the L2 link is shared with devices to which you do want
to provide IPv4 service.

Plus, that only works for ISPs. We need a way to propagate this inside
the home.

Simon

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 15 Apr 2014 15:19:23 +0000

> This doesn't work when the L2 link is shared with clients to which you do want to provide IPv4 service.

So, why can't other devices use IPv4 then?

> That is true, but there's no way to propagate this information to more hosts in the home. So you end up with DHCP requests eating battery life in the home.

That might require some tweaks in those devices (they probably already limit what discovery they do if they aren't getting DHCPv4 service to start with -- and that would benefit the device everywhere).

- Bernie

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Tuesday, April 15, 2014 9:37 AM
To: [email-masked]
Subject: Re: [v6ops] Please review the No IPv4 draft

> Seems to me that this would be far better to leave to the networking infrastructure to just 'block' the DHCPv4 packets if IPv4 isn't enabled?

This doesn't work when the L2 link is shared with clients to which you do want to provide IPv4 service.

> I suspect many access networks (i.e. DOCSIS - the IP Provisioning Mode TLV) already provide some information about whether v4, v6, or both are available?

That is true, but there's no way to propagate this information to more hosts in the home. So you end up with DHCP requests eating battery life in the home. Our draft describes how to propagate the No-IPv4 knowledge inside the home.

Simon

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 15 Apr 2014 15:20:42 +0000

Yeah, but we survived the transition away from these older networks without significant issues and special messages on IPv4 to tell clients "don't try IPX or AppleTalk or ...".

- Bernie

-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Simon Perreault
Sent: Tuesday, April 15, 2014 11:16 AM
To: Dale W. Carder
Cc: [email-masked]
Subject: Re: [v6ops] Please review the No IPv4 draft

Le 2014-04-15 10:21, Dale W. Carder a écrit :
> I guess I am still confused by your use cases.  In looking at our 
> dhcpv4 servers, I don't have No-IPX nor No-AppleTalk options sent to 
> clients, so I am confused why this is needed for IPv4.

> 3.1:  Turn off the dhcpv4 relay feature per router (sub)interface.  No 
> more load on the dhcpv4 server.

Not possible if the L2 link is shared with devices to which you do want to provide IPv4 service.

> 3.2:  At the edge of your network, filter packets containing 
> ethertypes you do not support.

Not possible if the L2 link is shared with devices to which you do want to provide IPv4 service.

> 3.4:  At the edge of your network, filter packets containing 
> ethertypes you do not support.

Not possible if the L2 link is shared with devices to which you do want to provide IPv4 service.

Plus, that only works for ISPs. We need a way to propagate this inside the home.

Simon

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 15 Apr 2014 16:21:41 +0100

> Basically we're trying to make DHCPv4 clients shut up.

then there's confusion about the draft's aims.  A good deal of the draft
goes into detail about completely stopping all ipv4 services on the client
system (which is something that is not going to be simple to achieve in
practice), whereas your stated aims and justification in the draft are all
about getting dhcpv4 clients to stop making noise.

Getting DHCPv4 clients to shut up is an admirable goal and I think it's
worth pursuing this by using the front-door method of creating a dhcpv4
no-service option (suggestion: use dhcpv4, implement a timeout, make it
interface specific, i.e. don't attempt to apply the configuration to
multiple interfaces, and don't attempt to complicate things by creating a
requirement to completely disable ipv4).  This would not be difficult to
achieve either operationally or from a protocol point of view; it would be
both clear and unambiguous, and it would not suffer from the technical /
implementation problems that either Ray or I brought up.  As a side issue
you may want to consider renaming the draft -nodhcpv4- instead of -noipv4-.

Getting hosts to stop talking ipv4 completely is a much more difficult
problem.  If you want to write a draft about this, then you need to start
from the beginning explaining the problem you're trying to solve, why
you're trying to solve it and then provide guidance on how it should be
handled.  This analysis is not present in your current draft.

At the very least I would be curious to know how and why a DHCP or RA
request coming in on any random interface should have the authority to
completely disable an entire communications protocol, O/S wide.  As a
client, I might well have multiple interfaces configured, only one of which
has ipv6 disabled, and it would be difficult to understand how e.g. my 3g
provider should have the right to tell me that my operating system should
completely shut down ipv4 while my computer was connected to my home wifi.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Apr 2014 10:29:44 -0500

On Apr 14, 2014, at 11:20 PM, Lorenzo Colitti <[email-masked]> wrote:
> I don't see a strong use case for this. It seems to me that the two scenarios in the introduction can be solved by simply configuring the DHCPv4 relay (or the server, if on-link) to drop all DHCPv4 requests.

In a v6-only network, there would be no relay, so you'd get this effect for free.

> Am I missing something?

Broadcast traffic on Wifi.   Vulnerability to on-link IPv4 attacks.   Otherwise, probably no.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Apr 2014 10:31:25 -0500

> So, you’re saying having some external process kill the DHCP4 client in response to a message received via DHCPv6 is less of a change to the protocol state machine than having DHCPv4 client die in…

Yes.   Not running a protocol is not a change to the protocol's state machine.   We don't need to write an RFC explaining how to not enable DHCPv4.   Changes to the state machine for the benefit of this use case would have to be considered in the larger context of intended uses of DHCPv4; turning off DHCPv4 requires no such consideration.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Apr 2014 10:37:19 -0500

> Calling it the wrong thing while advocating an even more wrong thing is equally absurd.

When I call it the wrong thing, I mean that it doesn't work well (and I explained that).  In practice, not in theory.   You are claiming that adding the capability to shut off DHCPv4 is even more wrong, but you haven't explained why.   So when we weigh the two considerations next to each other, one of which is substantiated by everybody's daily experience of Linux networking, and the other of which is purely speculative and not substantiated by any reasoning that would lead us to think it is true, then despite the fact that, if it were true, it would be worse, we should, logically, weigh the other consideration more heavily.

For comparison, suppose you were to assert that there's a significant risk of giant bunnies leaping out into the road when driving on any interstate highway in the U.S.  We could definitely say that if such a statement were true, it would require us to change our driving habits.   And yet we likely would not change our driving habits, because you have given us no reason to think it's true.

(Happy Easter!)

---

From: Owen DeLong <[email-masked]>
Date: Tue, 15 Apr 2014 08:35:14 -0700

> Yet the problem has not been fixed.

… YET

Reality, however, is that encouraging them to fix that could be accomplished just as easily as getting them to implement this new IPv6-based modification to their DHCPv4 client behavior. In fact, it could even be done without necessarily waiting for them to implement IPv6 in said client.

Owen

---

From: Matthew Petach <[email-masked]>
Date: Tue, 15 Apr 2014 08:39:55 -0700

> this RA"-message as well?
That would be an excellent feature to support, yes;
I have IPv4-only connectivity in some places, and
having hosts send out RS messages for connectivity
that will never happen is a waste of network resources;
it would be good for the local router to be able to say
"there is no v6 here, stop trying and deactivate your
IPv6 stack completely".

Thank you for that recommendation!

Matt

---

From: Owen DeLong <[email-masked]>
Date: Tue, 15 Apr 2014 08:40:46 -0700

> Yes.   Not running a protocol is not a change to the protocol's state machine.   We don't need to write an RFC explaining how to not enable DHCPv4.   Changes to the state machine for the benefit of…

Turning off DHCPv4 through an IPv6 dynamic configuration mechanism absolutely requires those considerations.

This argument has become a reductio ad absurdum, IMHO.

If you want to provide an automated way to shut down DHCPv4, it should be done in IPv4. An ICMPv4 message saying “Don’t keep trying to use DHCPv4” sent in response to a DHCPv4 request would be fine. Requiring clients that receive both an DHCPOFFER and the message to act on the DHCPOFFER and ignore the ICMP message would mitigate the DoS and other concerns and wouldn’t involve a significant change to the DHCPv4 state machine.

Owen

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 11:46:26 -0400

>> Basically we're trying to make DHCPv4 clients shut up.

This was a mistake on my part. We're trying to do much more. We're
trying to create an IPv4 kill switch.

> from the beginning explaining the problem you're trying to solve,

We do have a section titled "The Problems we're Trying to Solve".

> why you're trying to solve it

Because problems are problematic.

> and then provide guidance on how it should be

You might be interested in this analysis of problems preventing the
migration to IPv6-only:

http://tools.ietf.org/html/draft-ietf-sunset4-gapanalysis-04

> completely disable an entire communications protocol, O/S wide.

It does *not* have any authority. It is signalling. A host is free to
ignore the signalling.

> As a

It does not. Did you read our draft? We specify how the No-IPv4 option
is to be processed in multiple interfaces settings.

Simon

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Apr 2014 10:50:30 -0500

On Apr 15, 2014, at 3:30 AM, Gert Doering <[email-masked]> wrote:
> I'm not sure what's wrong about it.

There's nothing wrong with multiple implementations.   What's wrong is that there is no tight integration between the various configuration agents on Linux, and this breaks badly as soon as your network gets interesting.   It's better now than it use to be, but it's still all held together with bubble gum and bailing wire, and it falls apart at the slightest excuse.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 11:51:57 -0400

> Yeah, but we survived the transition away from these older networks without significant issues and special messages on IPv4 to tell clients "don't try IPX or AppleTalk or ...".

Of course. And this argument has first been made by Stuart Cheshire.

To me, the operational situation with IPv4 and its billions of deployed
devices is light-years away from AppleTalk/IPX.

People are experiencing real problems with moving to IPv6-only. I don't
think our answer should be "just do it the way it was done with
AppleTalk and IPX".

Simon

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Apr 2014 10:57:38 -0500

On Apr 15, 2014, at 6:35 AM, Nick Hilliard <[email-masked]> wrote:
> to a centralised provisioning system.

So now every v6-only CPE router has to have a DHCPv4 implementation and an IPv4 stack.

> not disable ethertypes 0x0800 and 0x0806 at the mac forwarding layer?

The draft speaks to this point.

BTW, the draft also speaks to the point of why you don't want to use DHCPv4 for this: once you've turned off IPv4, DHCPv4 can't be used to turn it back on again.

And the message from Simon that I was referring to was the one that discussed the draft that was proposed in sunset4 for solving this problem using DHCPv4, which was _not adopted by the working group_.   Draft adoption is part of the working group process; the fact that the working group decided to merge the DHCPv4 draft into this one, and not the other way around, is precisely what it means for a working group to have consensus to push this solution and not the other one.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Apr 2014 11:06:04 -0500

Owen, you are just repeating the same point over and over again, and you still haven't given any reason why we should consider it to be true.   Please either give a reason, or stop repeating yourself.

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 12:18:25 -0400

> That’s not even close to what is proposed here.

Uh?

At the very least, it was our intent to propose that very thing. An IPv4
kill switch.

> What is proposed here is a variety of IPv6 methods for telling a client to turn off it’s IPv4 dynamic configuration requests and there’s no reason to put that into IPv6 at all.

I'm sorry, I'm not following.

If your problem is with "variety of methods", then I can understand. We
started with DHCPv6 only, then we added RA because people were asking
for it. We expect one could be removed if it poses a problem.

Simon

---

From: Owen DeLong <[email-masked]>
Date: Tue, 15 Apr 2014 09:33:55 -0700

> When I call it the wrong thing, I mean that it doesn't work well (and I explained that).  In practice, not in theory.   You are claiming that adding the capability to shut off DHCPv4 is even more w…

No, I am not. I am claiming that putting DHCPv4 instructions into DHCPv6 (and/or RA) is even more wrong.

I’m all for adding an ICMP4 or DHCPv4 message to execute that task.

I have, in fact explained why and so has Gert and so have several other people. You are choosing to ignore us while simultaneously disagreeing with us, but that doesn’t change the fact that we have, in fact, done so.

However, to summarize:

1.	It makes little sense to me to try and turn off DHCPv4 using an IPv6 message when it can much more cleanly be
	done with a very simple IPv4 message.

2.	A client which is a “problem” as you describe the problem statement is a client which is sending DHCPv4REQUEST
	messages. Therefore, an appropriate way to identify and rectify such a problem is to send an IPv4 packet in
	response to the DHCPv4REQUEST message which says “STOP THAT”. Such a message could either be a
	new DHCP response type or an ICMP message indicating that the DHCPv4 service is unavailable.

3.	Others have raised a concern that forged ICMP based “STOP THAT” messages in IPv4 could:
	1.	Bypass DHCP Snooping safeguards
	2.	Serve as a DoS vector

4.	The concerns expressed in 3 received the following response:
	1.	The IPv6 based message would also bypass IPv4 DHCP snooping
	2.	Require clients which receive both a “STOP THAT” message and a DHCPOFFER to act on the Offer
		and ignore the “STOP THAT” message for some time.

5.	You argued that it is more difficult to implement changes to the DHCPv4 state machine than to implement something
	where the IPv6 DHCP or RA client would somehow pass a message to the upstream “glue code” whatever that may be
	on any given platform which would then cause it to kill off the DHCPv4 process on the client (and possibly shut down
	other aspects of the IPv4 stack on the client as well).

	I don’t buy that argument as I believe it would be pretty simple to add code to DHCPv4 clients that essentially does the following:

		...
		if (DHCP_SHUTDOWN_RECEIVED)
		{
			/* code here to listen for other DHCP responses over the next n seconds (probably n<30) */
			if (DHCP_OFFER_RECEIVED) break;
			/* If needed, any clean-up code before terminating the DHCPv4 process and/or to shutdown the IPv4 stack */
			exit(0);
		}
		…

	On the other hand, what you propose requires:

		1.	Add options to RA
		2.	Add options to DHCPv6
		3.	Update every RA implementation to somehow pass receipt of this option up to “glue code”
		4.	Update every DHCPv6 implementation to somehow pass receipt of this option up to “glue code”
		5.	Update glue code to deal with all possible variants of how the RA/DHCPv6 information may be passed up to that glue code.
		6.	Update glue code to properly terminate all possible variants of DHCPv4 client which may be running on the host.
		7.	Update glue code to do any other tasks required to shutdown IPv4 on the applicable interface on the host.

	I’ll note that in many cases, the DHCPv4, DHCPv6, RA, and “glue code” come in multiple variants and even in one set of variants,
	each of those 4 items may have different maintainers and/or different organizations/persons responsible for said maintenance.

	As near as I can tell the draft does not standardize any of the APIs necessary for the communications in the above 7 steps.

> For comparison, suppose you were to assert that there's a significant risk of giant bunnies leaping out into the road when driving on any interstate highway in the U.S.  We could definitely say tha…

If you simply want to bloviate while misrepresenting what has been said, then I see little point in the discussion.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 15 Apr 2014 09:46:09 -0700

> So now every v6-only CPE router has to have a DHCPv4 implementation and an IPv4 stack.

No, but the ones that want to be able to signal IPv4 operational behaviors would need to have a minimal IPv4 stack and the ability to do the following:

	1.	Detect an IPv4 DHCPREQUEST packet.
	2.	Respond with an ICMP DHCPv4 unavailable packet
	3.	A way to turn off this behavior

In reality, there’s not going to be any such thing as a v6-only CPE router implementation for many years to come, so this argument is rather specious to begin with. However, in that distant future, the above could be supported with a pretty small code-base.

> BTW, the draft also speaks to the point of why you don't want to use DHCPv4 for this: once you've turned off IPv4, DHCPv4 can't be used to turn it back on again.

As a general rule, once you turn off a network protocol, turning it back on requires intervention. I see no reason that we need to contemplate providing an IPv6 signaling mechanism to turn IPv4 on.

> And the message from Simon that I was referring to was the one that discussed the draft that was proposed in sunset4 for solving this problem using DHCPv4, which was _not adopted by the working gro…

I’m happy for the working group, but there is very little operator participation in the sunset4 working group at this time and I suspect that is one of the reasons said group decided to ask v6ops to review the draft. You are now hearing from people who are network operators that they feel this was the wrong approach to adopt and that we do not concur with the consensus of the sunset4 working group.

While I understand you may have expected us to just nod in agreement and say “looks good”, that’s not the outcome that is actually happening and continuing to tell us that we should merely nod in agreement or that our arguments against the choices sunset4 now considers to be fait accompli are not valid is not a productive approach to said review.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 15 Apr 2014 09:47:38 -0700

> for it. We expect one could be removed if it poses a problem.

IMHO, this should be reduced to a single bit in an RA if it is implemented in IPv6 at all.

Owen

---

From: Simon Perreault <[email-masked]>
Date: Tue, 15 Apr 2014 12:55:41 -0400

> IMHO, this should be reduced to a single bit in an RA if it is implemented in IPv6 at all.

Understood.

Thanks,
Simon

---

From: Ray Hunter <[email-masked]>
Date: Tue, 15 Apr 2014 18:56:38 +0200

> Simon Perreault <mailto:[email-masked]>
> 15 April 2014 16:06
Of course.

Assuming a CPE router allows the admin to configure an arbitrary ACL 
e.g. access restrictions/outbound/time of day access list to the 
Internet (which is a very common feature), plus the range of the 
addresses to be allocated via DHCP  (another common feature) you can 
blanket ban all IPv4 nodes from going off link, whilst shutting up 
chatty DHCP4 clients by giving them an address blocked by the ACL.

Or if you have a mixed scenario, you split your DHCP range into 2 
halves. Top half has an ACL preventing Internet access. Bottom half has 
no ACL preventing Internet access, and you use "Pre-assigned DHCP 
addresses" in the DHCP server to assign "static" addresses in the 
appropriate range based on the client's MAC address. That's also already 
a really common feature in IPv4 CPEs today.

-- 
Regards,
RayH

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 15 Apr 2014 18:16:07 +0100

> trying to create an IPv4 kill switch.

then you need to rewrite sections 1 and 3 from scratch before any other
comments from v6ops would be of any relevance.  As it stands, you have
provided justification for a dhcpv4 client kill switch, but no more.
Killing ipv4 on an interface - particularly given the semantics defined in
e.g. 5.3.3.h - is a substantial undertaking which will require substantial
justification.  Killing ipv4 system-wide, as suggested at the end of
section 5.3, is something which will be extraordinarily difficult to envisage.

> is to be processed in multiple interfaces settings.

I did read the draft and it does talk about killing ipv4 system-wide, and
across all interfaces:

>       The intent is to remove all traces of IPv4 activity.  Once the No-
>       IPv4 option with value 3 is activated, the network stack should
>       behave as if IPv4 functionality had never been present.  For
>       example, a modular kernel implementation could accomplish the
>       above by unloading the IPv4 kernel module at run time.

No way, Jose.

Simon, I think you need to go back to the drawing board on this draft.  As
I said before, stopping v4 DHCPREQUEST packets is a good idea and it would
be feasible to design a mechanism to implement it.  Beyond that, you're on
shaky ground.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Apr 2014 12:39:57 -0500

> 	done with a very simple IPv4 message.

An opinion, which is addressed and refuted in the draft.

> 	new DHCP response type or an ICMP message indicating that the DHCPv4 service is unavailable.

An opinion, not a technical objection to the current proposal.

> 	1.	Bypass DHCP Snooping safeguards

True, but since this draft doesn't propose such a mechanism, not a technical objection to the current proposal.

> 		and ignore the “STOP THAT” message for some time.

There's been some discussion of this specifically on the homenet mailing list which I think didn't get Cc'd here, unfortunately, and it looks like there will be a new draft out that addresses this issue.

> 	other aspects of the IPv4 stack on the client as well).

No, I said we'd have to update the DHCP protocol specification to add another state to the state machine, and we'd have to think through all the implications of that.   Whereas simply shutting off the DHCP client while the network says "suppress IPv4" is quite easy, and we already know how to do it.

> 			/* If needed, any clean-up code before terminating the DHCPv4 process and/or to shutdown the IPv4 stack */

Great, so what happens when I switch networks to an IPv4-only network?   My DHCP client is down, and you haven't implemented a mechanism for bringing it back up.   No offense, but I've had my hands deep and dirty in this code—I'm not just talking through my hat.

> 	As near as I can tell the draft does not standardize any of the APIs necessary for the communications in the above 7 steps.

We've never written a standard API for DHCP because nobody's been interested.   Microsoft has their way, Apple has their way, Linux hasn't really figured out a way yet.   When I wrote the ISC client, I made the action part of the client a shell script so that it would be easy to script, but that turned out to be a mistake because the DHCP client state machine interacts with so many other state machines.

Right now the state of the art on this is a homogenous configuration architecture.   I share your desire for the architecture to be general enough that parts can be plugged in and out, but that doesn't mean we can just punt on making it actually _work_.   And if we make it actually work, the points you raise above, while valid, are not a show stopper.   If we don't care about making it work, then we might as well punt on the turn-off-DHCPv4 thing entirely on that platform, because I don't think it can be made to work satisfactorily anyway.

If you are interested in what's going on in terms of advancing the state of the art on Linux, I encourage you to look at what the systemd team is doing, and also at what Simon Kelley has been doing in dnsmasq.   NetworkManager is not something I'd suggest wasting any time on, and the other configuration infrastructures on Linux are too half-baked to even seriously consider when we're talking about touchless configuration.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Apr 2014 12:47:15 -0500

On Apr 15, 2014, at 12:16 PM, Nick Hilliard <[email-masked]> wrote:
> I think you need to go back to the drawing board on this draft.  As

Nick, if you want something like what you just said to actually be the outcome of the process, you need to give a clear technical objection that motivates that outcome.

---

From: Karsten Thomann <[email-masked]>
Date: Tue, 15 Apr 2014 19:58:46 +0200

I have still problems to understand why a message on one link/interface should be able to 
shutdown the whole IPv4 stack or the dhcpv4 client, the scope of the message should be limited 
to the link/interface on which the message was received and not further... 

In my opinion the system should remove the v4 address, and the dhcpv4 client should stop 
sending discover messages on that specific interface, and the easiest way to tell dhcpv4 to do 
that is a dhcpv4 message.

Karsten

Am Dienstag, 15. April 2014, 09:38:58 schrieb Simon Perreault:
> > shutdown
> > the dhcpv4 client if this option is detected" - it is "shutdown IPv4",
> > which many OSes can't do today at all (and yes, that needs fixing).
>

---

From: "George, Wes" <[email-masked]>
Date: Tue, 15 Apr 2014 14:55:05 -0400

From: Karsten Thomann <[email-masked]<mailto:[email-masked]>>

I have still problems to understand why a message on one link/interface should be able to shutdown the whole IPv4 stack or the dhcpv4 client, the scope of the message should be limited to the link/interface on which the message was received and not further...

In my opinion the system should remove the v4 address, and the dhcpv4 client should stop sending discover messages on that specific interface, and the easiest way to tell dhcpv4 to do that is a dhcpv4 message.

WG] I’ve noted privately to Simon that I think we need much better text in the draft discussing what to do when there are multiple interfaces:
- when one interface has been given a code to indicate one of the 3 statuses documented in the draft, what if anything do you do on the others?
- When several interfaces receive the same or conflicting codes, what do you do, which has priority, or do you default to the least restrictive?
- when a local configuration is present to override the network-sent code, what happens?
- etc.

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I have no control over it.
-----------

________________________________
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 15 Apr 2014 12:09:39 -0700

> An opinion, which is addressed and refuted in the draft.

Not adequately refuted to change my opinion.

> An opinion, not a technical objection to the current proposal.

The current proposal states that the problem is clients sending DHCPv4REQUESTS.

> True, but since this draft doesn't propose such a mechanism, not a technical objection to the current proposal.

No, a technical solution to the proposed problem.

> There's been some discussion of this specifically on the homenet mailing list which I think didn't get Cc'd here, unfortunately, and it looks like there will be a new draft out that addresses this…

OK, but this is a technical problem with the current draft as written.

> No, I said we'd have to update the DHCP protocol specification to add another state to the state machine, and we'd have to think through all the implications of that.   Whereas simply shutting off…

And I’m saying you don’t need to add another state to the state machine, you simply provide a way to tell a DHCPv4 client to turn itself off. This does not have to be stateful or added to the state machine as shown below.

> Great, so what happens when I switch networks to an IPv4-only network?   My DHCP client is down, and you haven't implemented a mechanism for bringing it back up.   No offense, but I've had my hands…

Neither am I. In my experience on most hosts (and I admit I am not an expert on all operating systems, but this seems easy enough to change where a change would be required), the DHCP client gets relaunched on a link state transition from no-link to link, including sleep/wake events. Unless you believe such a transition would occur without a link-state or sleep/wake transition occurring, I don’t see this as a serious problem.

> We've never written a standard API for DHCP because nobody's been interested.   Microsoft has their way, Apple has their way, Linux hasn't really figured out a way yet.   When I wrote the ISC clien…

Right… But we’ve also never required interaction between DHCPv6 and the behavior of the DHCPv4 client before, either, whether directly or through “glue code”.

> Right now the state of the art on this is a homogenous configuration architecture.   I share your desire for the architecture to be general enough that parts can be plugged in and out, but that doe…

No, the state of the art is all over the map. There is absolutely no homogenous configuration architecture. One may be getting developed here and there on some platform(s) and some platforms may actually already have one, but it is by no means the ubiquitous state of the art.

I’m not proposing punting on making it work. In fact, I proposed what I believe to be a superior solution which keeps things properly modular, but you want to decry my concerns as invalid simply because I’m not paying attention to sunset4, but as an operator I am here in v6ops, which in my mind is one of the main reasons for bringing this draft to v6ops.

I care about making it work, but as you have just admitted, it can be made to work in a way which doesn’t break modularity.

> If you are interested in what's going on in terms of advancing the state of the art on Linux, I encourage you to look at what the systemd team is doing, and also at what Simon Kelley has been doing…

Unfortunately, while I might personally find that entertaining, I actually have other more pressing things that I must do for $DAYJOB.

I think you will find that this is one of the primary reasons that operator participation in the IETF and other such working groups and development efforts.

The biggest other one would be the tendency to tell us that we’re not complaining in the correct way or that our concerns are invalid when we do speak up.

Owen

---

From: "George, Wes" <[email-masked]>
Date: Tue, 15 Apr 2014 15:24:13 -0400

On 4/15/14, 11:20 AM, "Bernie Volz (volz)" <[email-masked]> wrote:

>Yeah, but we survived the transition away from these older networks
>without significant issues and special messages on IPv4 to tell clients
>"don't try IPX or AppleTalk or ...".
>
>- Bernie

Ok. Youngin’ (and cochair of Sunset4) speaking. My experience with
networking begins after these transitions were largely complete, so I
genuinely don’t have a good sense for what was done to “survive" this
transition, and I’d bet Simon doesn’t either. If that’s really the right
model, please explain what that actually means, since in Sunset4 we’re
supposed to be figuring out what this transition looks like, how to turn
off IPv4, etc. If it’s really been done, I don’t want to reinvent the
wheel, but I need more to go on than the handwaving that has so far
accompanied this assertion. Answer specifically if you are thinking of a
specific network, or generically if that’s more appropriate.

Did they die of natural causes I.e. most clients simply stopped having
them enabled by default? If yes, over what timeframe?
Were some networks forcing those protocols to be disabled via going to
each host and manually configuring? Or was the background traffic so
negligible that it was simply ignored?
What was the order of magnitude of size of the broadcast domain? Number of
hosts that might have to be touched on an average network? How many hosts
were dynamically configured vs static? DHCP was pretty new then, wasn’t it?
Since we’ve brought up reducing junk client-sourced traffic on wireless
networks as one of the goals of being able to tell clients to stop
speaking DHCPv4, or IPv4/arp in general, how many wireless IPX and
Appletalk networks were there? (and yes that last question is mostly
tongue-in-cheek)

Thanks,

Wes

Anything below this line has been added by my company’s mail server, I
have no control over it.
-----------

---

From: Karsten Thomann <[email-masked]>
Date: Tue, 15 Apr 2014 21:26:06 +0200

- when one interface has been given a code to indicate one of the 3 statuses documented in the 
draft, what if anything do you do on the others?
[KT] In my opinion such messages must be kept interface specific in all cases, for example you 
want to use a vpn connection to a IPv4 network behind the vpn gateway over an IPv6 network, 
how that should be possible when the ipv4 stack is disabled globally by one option on the 
interface?

- When several interfaces receive the same or conflicting codes, what do you do, which has 
priority, or do you default to the least restrictive?
[KT] as already written it must be kept interface specific, and with conflicting codes use the least 
restrictive, as the other router may still offer ipv4 connectivity, even only local or to other 
networks at the site

- when a local configuration is present to override the network-sent code, what happens?
[KT] Use the more specific approach, as host configuration is more specific than link specific the 
host configuration should take precedence over the network-sent code

Am Dienstag, 15. April 2014, 14:55:05 schrieb George, Wes:

*From: *Karsten Thomann <[email-masked][1]>

WG] I’ve noted privately to Simon that I think we need much better text in the draft discussing 
what to do when there are multiple interfaces:
- when one interface has been given a code to indicate one of the 3 statuses documented in the 
draft, what if anything do you do on the others?
- When several interfaces receive the same or conflicting codes, what do you do, which has 
priority, or do you default to the least restrictive?
- when a local configuration is present to override the network-sent code, what happens?
- etc.

Thanks,
 
Wes

--------------------
This E-mail and any of its attachments may contain Time Warner Cable proprietary information, 
which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-
mail is intended solely for the use of the individual or entity to which it is addressed. If you are not 
the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, 
copying, or action taken in relation to the contents of and attachments to this E-mail is strictly 
prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender 
immediately and permanently delete the original and any copy of this E-mail and any printout.

--------
[1] mailto:[email-masked]

---

From: "George, Wes" <[email-masked]>
Date: Tue, 15 Apr 2014 16:02:24 -0400

From: Owen DeLong <[email-masked]<mailto:[email-masked]>>
Date: Tuesday, April 15, 2014 at 12:46 PM
To: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]>" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Please review the No IPv4 draft

WG] yeah… have you seen how long it takes IETF work to progress from draft to actual deployed implementation? Especially if you’re factoring in the average half-life of a consumer CPE router? That’s why we are starting now.  It’s not a specious argument, just very forward looking.

And the message from Simon that I was referring to was the one that discussed the draft that was proposed in sunset4 for solving this problem using DHCPv4, which was _not adopted by the working group_.   Draft adoption is part of the working group process; the fact that the working group decided to merge the DHCPv4 draft into this one, and not the other way around, is precisely what it means for a working group to have consensus to push this solution and not the other one.
I’m happy for the working group, but there is very little operator participation in the sunset4 working group at this time and I suspect that is one of the reasons said group decided to ask v6ops to review the draft.
WG] Working group chair hat on: Actually, there’s decent operator participation as a percentage of overall, but unfortunately there is very little participation in the WG period, so we weren’t comfortable with the level of feedback the draft had received thus far and asked for additional review.

You are now hearing from people who are network operators that they feel this was the wrong approach to adopt and that we do not concur with the consensus of the sunset4 working group.

WG] Yes, but based on your previous messages, you seem to have a fundamental issue with any IPv4/DCHPv4 configuration being sent over IPv6, and as I noted in my previous response to you, DHC is also moving toward the path of doing this, just not with a kill switch, and with different technical justification. Not saying that makes it right, but if it’s not, there’s a much larger discussion to be had, and the folks in DHC that are working on those drafts probably need similar feedback if there’s truly a technical problem with it and not that it simply isn’t architecturally pure enough for you. In other words, Sunset4 is moving this direction because it enables us to leverage work that is already happening in DHC, and we are trying to coordinate those efforts with them.  So I’d recommend going to read the drafts I pointed you to yesterday, and determining whether you have a problem with the whole concept or just sunset4’s particular piece of it, and proceeding accordingly.

Thanks,

Wes

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Tue, 15 Apr 2014 20:24:28 +0000

I don't have good answers for you on the previous transitions - perhaps others do.

> networks as one of the goals of being able to tell clients to stop speaking
> DHCPv4, or IPv4/arp in general, how many wireless IPX and Appletalk 
> networks were there? (and yes that last question is mostly tongue-in-cheek)

If it is wireless that is a significant concern, wouldn't it be better to have the wireless layer communicate what networking protocols should [not] be run (that's a different standards organization though)?

BTW: In in the old days, "wired" broadcast domains were large because switches weren't used everywhere - though they weren't as large as some of the wireless ones are today.

Similar to the work done on RFC 7083 for reducing the rate at which DHCPv6 clients send Solicits, perhaps we should look at altering the DHCPv4 DHCPDISCOVER rates? RFC 2131 has "The retransmission delay SHOULD be doubled with subsequent retransmissions up to a maximum of 64 seconds." RFC 7083 changed DHCPv6's value from 120 to 3600 seconds. But this only helps the DHCPv4 DHCPDISCOVER issue (not the rest of the IPv4 issues, such as using a link local address). But I suspect that this would go a long way to reduce the issues with Wireless.

- Bernie

-----Original Message-----
From: George, Wes [mailto:[email-masked]] 
Sent: Tuesday, April 15, 2014 3:24 PM
To: Bernie Volz (volz); Simon Perreault; Dale W. Carder
Cc: [email-masked]
Subject: Re: [v6ops] Please review the No IPv4 draft

>"don't try IPX or AppleTalk or ...".

Ok. Youngin’ (and cochair of Sunset4) speaking. My experience with networking begins after these transitions were largely complete, so I genuinely don’t have a good sense for what was done to “survive" this transition, and I’d bet Simon doesn’t either. If that’s really the right model, please explain what that actually means, since in Sunset4 we’re supposed to be figuring out what this transition looks like, how to turn off IPv4, etc. If it’s really been done, I don’t want to reinvent the wheel, but I need more to go on than the handwaving that has so far accompanied this assertion. Answer specifically if you are thinking of a specific network, or generically if that’s more appropriate.

Did they die of natural causes I.e. most clients simply stopped having them enabled by default? If yes, over what timeframe?
Were some networks forcing those protocols to be disabled via going to each host and manually configuring? Or was the background traffic so negligible that it was simply ignored?
What was the order of magnitude of size of the broadcast domain? Number of hosts that might have to be touched on an average network? How many hosts were dynamically configured vs static? DHCP was pretty new then, wasn’t it?
Since we’ve brought up reducing junk client-sourced traffic on wireless networks as one of the goals of being able to tell clients to stop speaking DHCPv4, or IPv4/arp in general, how many wireless IPX and Appletalk networks were there? (and yes that last question is mostly
tongue-in-cheek)

Thanks,

Wes

---

From: Owen DeLong <[email-masked]>
Date: Tue, 15 Apr 2014 13:35:36 -0700

> transition, and I’d bet Simon doesn’t either. If that’s really the right

Well, I was around for these transitions, so let me shed some limited light…

> specific network, or generically if that’s more appropriate.

I had experience with sunsetting appletalk, IPX, netBEUI, DECNET, and ARCNET.

While I didn’t have direct experience sunsetting Vines or other XNS variants, I think that’s enough of a sampling to speak relatively generically.

> them enabled by default? If yes, over what timeframe?

Yes, they died of natural causes over the course of about 2-5 years and in some cases, as much as 10-15 years, depending on the organization.

However, “clients stopped having them enabled by default” doesn’t really apply because to my knowledge, other than Appletalk, IPv4 is the first protocol to have really been “enabled by default”. In the other cases, you generally had to take substantial effort to install each and every protocol you wanted to run on any given host. Every thing was much harder than what we take for granted now.

Even in the case of appletalk, mostly what happened is Apple moved to TCP/IP with OS X and as a result Appletalk simply evaporated.

Further, none of the things that are being considered a problem in this draft were considered problematic in those days. Low power applications simply didn’t exist. If it had a NIC back then, it probably involved a relatively thick piece of Co-Ax (or at least a thin one). In the (very rare) case there was a wireless network, it involved a PCMCIA card that was larger than many modern cellphones. Mobile connectivity was a pipe dream.

> negligible that it was simply ignored?

Some of the former, mostly the latter. 

> were dynamically configured vs static? DHCP was pretty new then, wasn’t it?

DHCP might even have been nonexistent on most networks when much of this occurred.

> Appletalk networks were there? (and yes that last question is mostly

Very nearly zero.

Owen

---

From: Owen DeLong <[email-masked]>
Date: Tue, 15 Apr 2014 13:53:40 -0700

On Apr 15, 2014, at 1:02 PM, George, Wes <[email-masked]> wrote:

> 
> 
> From: Owen DeLong <[email-masked]>
> To: Ted Lemon <[email-masked]>
> Cc: "[email-masked]" <[email-masked]>

Conceptually, I think it is generally ill-advised, just as I wouldn’t advocate putting IPv6 name server options in DHCPv4 (though there are others who would support doing so).

I agree that the DHC working group may well need more feedback than they are getting. Unfortunately, I don’t have the bandwidth to keep up with DHC, sunset4, etc. and I do my best to keep up with v6ops as that is the one that seems most relevant to my immediate circumstances.

This draft happened to hit v6ops, so I commented on it as requested.

In an ideal world, I’d be able to do just as you suggest and push on all the right places. In the real world, I’ve probably already spent more time on this issue than I really should.

Owen

---

From: Ray Hunter <[email-masked]>
Date: Tue, 15 Apr 2014 23:47:47 +0200

> specific network, or generically if that’s more appropriate.
I've personally been around for the sunset of Appletalk, IPX, LAT, DECnet IV, SNA, SNA tunneling, X25, WAN bridging, NetBIOS, Apollo/Domain in various organisations.
> them enabled by default?
Clients stopped enabling them. In many cases it was a commercial decision to remove support for the relevant code/ drivers. Mostly it was natural end of life renewal.
>   If yes, over what timeframe?
Some were very quick: wiped out within 6 months. Some took a very long time to die. Some became islands connected via tunnels.  Some became islands without external connectivity. I suspect IPv4 will be around for at least 20 years (e.g. factory automation). As soon as people started having to pay extra to maintain this service i.e. providing the old protocol demanded a premium, the death accelerated very quickly. I think sunset IPv4 has to be very clear what problem it is trying to tackle. Thinking that IPv4 can be turned off per ISP or per site in one big switch off is not going to fly IMHO.

> each host and manually configuring?
Removing the network statements on the router was generally the way it was triggered.
The equivalent would be disabling the DHCPv4 server, or serving up junk IPv4 network addresses +ACL.

But on some systems there was significant manual intervention per host required e.g. changing batch files to prevent loading a specific driver, reconfiguring or even recompiling  the OS, or removing a specialised card like a broadband-LAN adapter.

> Or was the background traffic so
Certainly not. Processors were much slower then. L2 Broadcasts could have significant impact on machine productivity e.g. mixing Novell Netware clients on a LAN carrying LAT/MOP which was broadcast heavy could impact those users. Remember there weren't any switches on 10Base5 or cable LAN systems (Sytek et al). A site was generally one big flat L2 LAN. From fading memory I remember 20Kbps of broadcasts (50 pps) on a 10Mb LAN was pretty significant. So we'd make a legacy LAN to connect up the poorly behaving systems (or more likely create a new LAN to accommodate the new well-behaved systems, and leave the old ones to die a natural death). A modern equivalent would be to create a new VLAN or separate SSID for IPv6 only hosts.
> What was the order of magnitude of size of the broadcast domain?
1000 hosts or more (WAN bridging)
> Number of
> hosts that might have to be touched on an average network?
1000-100000?
>   How many hosts
> were dynamically configured vs static?
Mostly statically configured for DECnet, but dynamic for LAT, IPX, Appletalk. Centrally configured for SNA.
> DHCP was pretty new then, wasn’t it?
I don't see how this is relevant. There are still many systems running with statically assigned IPv4 addresses.

> Appletalk networks were there? (and yes that last question is mostly
None. But there weren't many routers either (just the odd DEMSA, Proteon and those new fangled Cisco AGS thingies).
So excessive broadcasts were an issue back then too. Just try opening the finder on an original Macintosh when you had 100+ Appletalk zones and network IDs and watch your 64K WAN links fill up.

I personally get the feeling that this issue of background noise is being overblown. I haven't seen any evidence yet of why it isn't possible just to create a new VLAN/SSID/light up a new DWDM color/new bearer for the IPv6 only systems that are supposedly sensitive to broadcasts. Router ports cost way less than 1/100th of what they used to cost. And it's not like anyone is going to renumber their IPv4 subnets to create the super large prefixes that native IPv6 can theoretically support. So what's the real problem here? And why can't this be solved with existing techniques?

-- 
Regards,
RayH

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 15 Apr 2014 23:16:52 +0100

On 15/04/2014 18:47, Ted Lemon wrote:
> Nick, if you want something like what you just said to actually be the
> outcome of the process, you need to give a clear technical objection
> that motivates that outcome.

I've written 10 emails on the topic in the last 24h, which is at least 9
too many, and probably 10.  These contain details on a wide variety of
issues, but they can be broadly summarised as:

helicopter view of draft issues:

the draft is poorly structured; the problem statement does not match the
solution which is presented; the justification for the overall aims of the
draft is weak; the consequences of the draft as defined in S5.3.1 through
S5.3.3 are ill thought out and have far-reaching consequences which look
extremely difficult to implement as well as being contentious from an
operational point of view; there is no proposed "v4-level" option which
matches the problem statement; the draft proposes that a remote signalling
mechanism should be allowed to completely shut down ipv4 services right
across an entire client machine - an issue which is well beyond the remit
of the ietf standards process; there is no security analysis of anything.

technical implementation issues:

the justification for the proposed technical solution (as distinct from the
overall aims) is almost non-existent;  the proposal suggests a back-door
mechanism to implement a protocol shutdown when a front-door mechanism
would be technically much simpler to implement; the draft does not provide
any protocol to implement this inter-process communication mechanism while
all parties agree that there is a serious back-end problem here; the draft
does not detail how or why it is appropriate for a kernel level protocol
(RA) to signal a widescale kernel/userland behavioural change for an O/S;
any real-world implementation of this draft will require changes to both
dhcpv6 and RA rather than a single protocol, which will result in serious
implementation problems;  there has been no discussion alternative
approaches to handle the problem (e.g. mac layer filters); there is no
option for a timeout in the protocol proposal; the proposal as it stands
will open implementers up to a wide variety of race conditions and
inconsistent states; the implementation will cause the interpretation of RA
and its interaction with DHCPv6 to become further complicated (sufficient
ill-defined / complicated at the moment that it needs an entire rfc to
describe it).

There's discussion of most of these points on the v6ops mailing list. If
there are any you want clarification on, please let me know and I'll do my
best to elaborate.

Overall, I view the proposal as being a bizarre approach to handling far
too large a problem space.  However, small bits of it may worth salvaging
and re-working from the ground up, hence the suggestion for the authors to
go back to the drawing board and re-think the problem set and potential
solution space from scratch.  As it stands, I do not believe that further
work on this draft would be productive.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 15 Apr 2014 23:18:37 -0500

> I don't have good answers for you on the previous transitions - perhaps others do.

Apple stopped shipping Appletalk, and Apple has a pretty good upgrade rate.   And it had been off by default for a while.   And it was never widespread outside of the Apple ecosystem.   I really think comparing IPv4 to Appletalk is apples and oranges.

IPX was also Windows-only, and was pretty much dead when Windows 95 shipped because at that point its only use was for file sharing and other services on the LAN.   It had never had much use outside of that space.

IPv4 is general-purpose, not application-specific.   I think we can expect to see it shipping enabled for quite some time yet.   Whether there's any utility in having a way to shut it off, I don't know.   One way to find out is to release a specification for how to do it and see if anybody implements it.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Apr 2014 17:22:55 +0900

Ok. So:

   1. As regards impact to the client - "don't waste your resources sending
   DHCPv4 requests, there's never going to be a DHCPv4 server here", then:
   what's the advantage to the client above doing exponential backoff with one
   packet every 2 minutes / half hour / 2 hours? True, clients don't do
   exponential backoff today, but they will have to be modified anyway for
   this option to work.
   2. As regards impact to the infrastructure: on wifi,
   infrastructure-to-client broadcasts are expensive, but
   client-to-infrastructure broadcasts are effectively unicast. So just
   configuring the AP to drop the packets will do what you want. As regards to
   low-power clients, see #1.

Don't get me wrong - I don't think this is harmful (modulo security
considerations, of course). I just don't think it's a particularly good use
of our time.

If we do do this, on the face of it it would seem that from the host's
perspective it would be better to have this information in DHCPv4 than in
DHCPv6.

Cheers,
Lorenzo

On Tue, Apr 15, 2014 at 1:57 PM, Owen DeLong <[email-masked]> wrote:

>
> On Apr 14, 2014, at 9:20 PM, Lorenzo Colitti <[email-masked]> wrote:
>
> I believe the purpose is to get the DHC4 client to stop asking (broadcast
> DHCP4 requests) on networks where repeated garbage packets are less than
> desirable (low power applications, wifi, etc.)
>
> Owen
>
>

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Apr 2014 10:37:00 +0200 (CEST)

> to the link/interface on which the message was received and not further...

I can see the use-case for both. Let's say you have a mobile phone 
connecting to an IPv6 only wifi, and it has ipv4 on the mobile Internet 
side, and it's now connecting to dual stacked resources within the 
enterprise.

So regarding shutting down IPv4 completely on the device, that should be a 
policy decision. There are use cases for both behaviour, ie allowing a 
single interface to shutdown the complete IPv4 stack on the device, and 
the case where you *don't* want this to happen. This should be a policy 
decision on the device.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Apr 2014 17:50:44 +0900

On Wed, Apr 16, 2014 at 5:37 PM, Mikael Abrahamsson <[email-masked]>wrote:

> single interface to shutdown the complete IPv4 stack on the device, and the
> case where you *don't* want this to happen. This should be a policy
> decision on the device.
>

The device will do what it wants with the information you give it, and I
think it's unlikely to shut down all IPv4 on all interfaces just because
your network asks it to. :-)

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Apr 2014 10:54:39 +0200 (CEST)

> your network asks it to. :-)

If it's an enterprise device then the enterprise probably want to follow 
what the network says. But as I said before, there are use-cases for both 
and this is why I feel the flags announced should be hints.

Also again, I support this being put into RA.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Apr 2014 11:31:27 +0200

>Also again, I support this being put into RA.

Unfortunately, the discussion is now split over v6ops and homenet.

I think an option to shutdown IPv4 belongs in DHCPv4. Not in RA.

Having an RA shutdown a DHCPv4 client just creates all kinds of complexity 
I can do without.

>From a host OS point of view, acting on a DHCPv4 extension would be almost
trivial, whereas putting an option in RA creates all kinds of complexity 
nobody can predict at the moment.

---

From: Brian Haberman <[email-masked]>
Date: Wed, 16 Apr 2014 07:55:27 -0400

I purposely picked Owen's message since it is a perfect entry point...

On 4/14/14 3:32 PM, Owen DeLong wrote:
>> On Mon, Apr 14, 2014 at 10:26 AM, Nick Hilliard <[email-masked]>
>> wrote: On 14/04/2014 18:23, Matthew Petach wrote:
>>> (which is to say, the potential for abuse here seems kinda high;
>>> are we sure this a good road for us to be traveling down?)
>> 
>> Correct me if I'm wrong, though; being an ICMP response, rather
>> than a DHCP response would mean DHCP snooping wouldn't be
>> sufficient to stop me from engaging in mischief, where today
>> settings like DHCP snooping and DHCP guard could prevent me from
>> acting as a rogue DHCP server?
>> 
>> I suppose if we extend the concept of DHCP snooping to also include
>> ICMP snooping, that would work.
>> 
>> Thanks!
>> 
>> Matt
>> 
> 
> ICMP was just a suggestion. If you want to put it in DHCP/UDP to
> dodge abuse potential, I have no problem with that. The point is that
> this has no business being encoded in DHCPv6 or RA, it belongs in
> IPv4 somewhere.

Further down the thread, there have been arguments about IPv6 being the
only transport available, hence the need to put this option in
DHCPv6/RAs.  Seems to me the way you keep this option in its own address
family (i.e., carry it in DHCPv4) is to leverage a draft now going
through IETF Last Call (draft-ietf-dhc-dhcpv4-over-dhcpv6).  That draft
specifies how to carry DHCPv4 options in DHCPv6 (due to lack of IPV4
transport).

Regards,
Brian

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Apr 2014 08:53:24 -0400

Le 2014-04-16 04:37, Mikael Abrahamsson a écrit :
> So regarding shutting down IPv4 completely on the device, that should be
> a policy decision. There are use cases for both behaviour, ie allowing a

Absolutely. That was the intent. I see now that such language is absent
from the draft. We will add it in the next revision.

Thanks,
Simon

---

From: Owen DeLong <[email-masked]>
Date: Wed, 16 Apr 2014 05:55:44 -0700

> specifies how to carry DHCPv4 options in DHCPv6 (due to lack of IPV4

I’m still trying to fathom what you would need DHCPv4 information for at all in an environment lacking IPv4 transport.

If you don’t have DHCPv4 transport, how are you going to get the client’s DHCPv4 request in the first place?

Why would you try to configure DHCPv4 information on a client that has no IPv4 transport?

I can see IPv6 transport for DHCPv4 relay information, but using DHCPv6 as a transport to talk to the DHCPv4 client directly seems patently absurd to me.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Apr 2014 08:52:42 -0500

> I can see IPv6 transport for DHCPv4 relay information, but using DHCPv6 as a transport to talk to the DHCPv4 client directly seems patently absurd to me.

It gets you the IPv6 relay path information, which you would not get if you sent the request directly.   Doing a v4 shim relay doesn't really get you what you want since you don't want to configure the interface that's connected to the link the relay is connected to.   There's a draft, http://tools.ietf.org/html/draft-ietf-dhc-v4configuration-05, that talks about the why of this, but it needs a bit of work, so the dhcpv4-over-dhcpv6 draft made it into the last call queue first.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Apr 2014 08:57:36 -0500

> Unfortunately, the discussion is now split over v6ops and homenet.

The request was for feedback.   If you want to discuss what's in the document in the sense of participating in the working group effort, the place to do that is the sunset4 mailing list.   So the situation is working out just fine, actually, despite my remark yesterday: homenet is giving feedback, and v6ops is giving feedback.

You are not going to change the outcome by soliciting support for your position on other mailing lists.   The way to change the outcome is by raising technical issues that haven't already been addressed by the working group.   This is what the request for feedback was about.   It's not useful to rehash discussions about matters of preference that have already been settled.

---

From: "Dale W. Carder" <[email-masked]>
Date: Wed, 16 Apr 2014 09:45:29 -0500

Thus spake George, Wes ([email-masked]) on Tue, Apr 15, 2014 at 03:24:13PM -0400:
> model,

I'm not sure it was the "right" model, but we learned a lot.

Everything in that timeframe was manually configured, although host
numbering was automatic in IPX, plus we enforced bootp/dhcp use for v4.  

There were a number of factors that came into play in our migration off 
IPX.  Every PC was dual-stack in effect.  All major applications (really 
netware, and printing) were on IPX and used SAP for discovery.  When 
these applications made it to ipv4 they also used ipv4 SLP for discovery.

However, there was no RFC 3484 for IPX/IPv4.  This meant that every PC 
(thousands) had to be visited manually and reconfigured to prefer ipv4 
over ipx.  Only then could we start the migration off of IPX.

Today we do have 3484 (or better), plus happy eyeball variants.  If we
had either then, I think the transition would have been cake, and the
migration would have been through atrophy.  

These were good sized broadcast (and collision) domains.  Each was 
typically a big hub with a /22 that fed branches on thinnet.  Our final 
push was for getting rid of SAP broadcasts.  We had them at peak probably 
around 10 or 20 kpps, which was a disaster for the shared L2 segments
and slow clients.

We got lucky on appletalk because we forced most of the issues when we 
went from localtalk to ethernet.  However, we kept gator boxes running 
as protocol translators, primarily for printing from apple OS 7 - 9 
clients.  We had hundreds of zones though, which was still horrible.  I
disabled appletalk on each router subint one at a time over the course
of a year (this was 2006!).

> Appletalk networks were there? (and yes that last question is mostly

These days we have thousands of AP's, with an ipv4 /17 for clients.  
However clients sending unnecessary dhcp probes is in the OK direction 
because this can be filtered on ingress at the AP, and it won't be
broadcast back out to others.  In fact we suppress ARP and other
multicast in a similar manner.  Modern enterprise wireless controller 
networks are way, way more sophisticated than their wired counterparts 
due to the management of scarce RF time.  So, I don't buy any argument
in this draft that there is a problem in this direction.  If anything,
modify dhcpv4 to do exponential backoff, but I doubt this would work
either since the clients sleep and wake up too often.

Dale

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 16 Apr 2014 23:54:14 +0900

On Wed, Apr 16, 2014 at 10:57 PM, Ted Lemon <[email-masked]> wrote:

> The way to change the outcome is by raising technical issues that haven't
> already been addressed by the working group.
>

I think that doesn't work, actually. What happens instead is that someone
raises an issue, and you say that they're wrong. :-)

---

From: "Dale W. Carder" <[email-masked]>
Date: Wed, 16 Apr 2014 10:24:40 -0500

>    exponential backoff today, but they will have to be modified anyway for

I would worry that mobile clients may not be online continously long enough
for the backoff timer to get very high, unless there would be some way
to tie the backoff timer into rfc4436 or something if you reattach to the
same L2 domain.

Dale

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Apr 2014 10:25:05 -0500

On Apr 16, 2014, at 9:54 AM, Lorenzo Colitti <[email-masked]> wrote:
> I think that doesn't work, actually. What happens instead is that someone raises an issue, and you say that they're wrong. :-)

Hm.   Well, I think the objection that's been raised that's most compelling is "why bother?"   Philip's issues are technical, but they aren't objections, in the sense that he hasn't pointed out an oversight in the spec that means it can't be implemented or won't work.

We've gotten some good feedback that the document isn't clear enough, particularly with respect to how multiple interfaces are handled, and we've gotten some good feedback about how to handle validity of the assertion that IPv4 shouldn't be used, and about how to deal with various attacks that could be launched by shutting down IPv4.   The authors have agreed that there is work to do, and it sounds like they're going to do it.   I felt like that part of the conversation was productive and beneficial.

However, there's also been a lot of discussion about whether to use DHCPv4 or IPv6 configuration protocols for signaling, and that hasn't been so useful, because it's recapitulating discussions that have occurred previously, and revisiting a decision the working group already made, for reasons that are explained in the draft.

I never know how to deal with discussions like this.   I personally favor an open communications model where I actually say why I don't think the objections are useful, over a model where I just ignore them.   However, as we've seen, when people repeatedly re-assert the same point, it tends to drown out the useful part of the conversation, and when I say "no, that point isn't useful in this part of the discussion because FOO," people re-assert the point with slightly different wording rather than saying "oh, Ted might have a point, let me think about it."   So in that sense, me saying "that's not a valid point" isn't constructive.

This type of interaction, where we wind up endlessly re-stating the same point, is one of the failure modes of the IETF.   To the extent that I've been a part of it, I apologize, but I still don't know how to address the tradeoff between open communications and ignoring redundant comments.

---

From: "Dale W. Carder" <[email-masked]>
Date: Wed, 16 Apr 2014 10:57:14 -0500

Thus spake Mikael Abrahamsson ([email-masked]) on Wed, Apr 16, 2014 at 10:54:39AM +0200:
> >The device will do what it wants with the information you give it,
> >and I think it's unlikely to shut down all IPv4 on all interfaces
> >just because your network asks it to. :-)
> 
> If it's an enterprise device then the enterprise probably want to
> follow what the network says. But as I said before, there are
> use-cases for both and this is why I feel the flags announced should
> be hints.

We have probably tens of thousands of devices at any given time that are
attached to our enterprise and have the ability to be on a cellular
network.  While we can send as many "hints" as we want, the devices in
practice are tuned to operate in the best interest of it's owner or perhaps
the cellular provider subsidizing its cost.  

So, I am not in favor of adding more hints that may or may not observed
that result in additional complexity and create an even more diverse set
of behavior that has to be managed.  This is why I think the only real
solution that would work in practice is ethertype filtering.

Dale

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 16 Apr 2014 17:10:43 +0100

On 16/04/2014 16:25, Ted Lemon wrote:
> because it's recapitulating discussions that have occurred previously,
> and revisiting a decision the working group already made, for reasons
> that are explained in the draft.

well no, not really.  I can find no discussion at all about this on the
sunset4 mailing lists - where there was only a single email about the
entire draft from non-authors in the last couple of years, unrelated to
this issue.   From what I can tell from the sunset4 meeting minutes, there
was only minimal discussion about the choice of using dhcpv6/ra at ietf
meetings.

If we are missing something here, can you please point to some URL or other
resource where we can examine the justification for this decision, because
so far there is a not insignificant level of disquiet about this choice on
v6ops, and from what I can see, this body of opinion is being ignored.
This concerns me because I see no clear evidence that due consideration was
given to the issue in the first place.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Apr 2014 11:42:18 -0500

On Apr 16, 2014, at 11:10 AM, Nick Hilliard <[email-masked]> wrote:
> sunset4 mailing lists

There are actually two other drafts related to this topic:

http://tools.ietf.org/html/draft-yang-sunset4-weaken-dhcp-00
http://tools.ietf.org/html/draft-yang-dhc-ipv4-dis-01

The authors of draft-yang-sunset4-weaken-dhcp-00 decided to combine their work with the current working group draft.   This was discussed in the meeting at IETF 87, and there were no objections (although there was substantial comment on the draft).   The draft was adopted by the working group in September 2013; no objections were raised.

So unless you are saying that there was a process failure here, the issue is effectively settled.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Apr 2014 11:51:19 -0500

> So unless you are saying that there was a process failure here, the issue is effectively settled.

BTW, this does _not_ mean that it can't be reopened.   It just means that the presumption is that it won't be.

There is actually a precedent for something like this in IETF history: https://tools.ietf.org/html/rfc2563

RFC 2563 is not widely implemented (not at all implemented, actually, as far as I know).   I think this is actually the strongest argument against the current effort: if nobody implements it in any shipping stacks, what's the point?

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Apr 2014 18:58:33 +0200

>So unless you are saying that there was a process failure here, the issue is eff

I really love the false modesty in Section 4.1:
"The authors conclude that a DHCPv6 option is clearly necessary,
whereas it is not as clear for a DHCPv4 option.  More feedback on
this topic would be appreciated."

Well, we can safely assume that the authors (at least some of them) got their
feedback. It's up to them to decide what to do.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 16 Apr 2014 18:46:03 +0100

> There are actually two other drafts related to this topic:

ok, thanks for the refs.  I was aware of draft-yang-sunset4-weaken-dhcp
(and had already looked that up), but not of draft-yang-dhc-ipv4-dis.

> http://tools.ietf.org/html/draft-yang-dhc-ipv4-dis-01

there is no record of any discussion about draft-yang-sunset4-weaken-dhcp
on the sunset4 mailing list; just some notifications that the draft had
been published.

There were several emails on dhcwg@ about draft-yang-dhc-ipv4-dis, only one
of which provided any comments, and another (from you) which contained a
single question which was never answered.

> The authors of draft-yang-sunset4-weaken-dhcp-00 decided to combine
> their work with the current working group draft.   This was discussed in
> the meeting at IETF 87, and there were no objections (although there was
> substantial comment on the draft).   The draft was adopted by the
> working group in September 2013; no objections were raised.

The sunset4 minutes from IETF87 are here:

https://tools.ietf.org/wg/sunset4/minutes?item=minutes-87-sunset4.html

There's no mention of the DHCPv4 issue here either.

There was discussion about this draft in sunset4 at ietf84 through ietf86,
but all the discussion was entitled "Disabling IPv4 with DHCPv6", which
rather put the cart before the horse, so to speak.  Nothing in the minutes
indicated any discussion as to why DHCPv4 was discarded as an option.  This
doesn't mean that there wasn't a discussion, of course.  It just means that
if there was, it wasn't minuted and now we have no way of reviewing the
rationale for the decision.

> issue is effectively settled.

Process exists to serve the ietf, not the other way around.  Several people
in both v6ops and homenet have expressed serious concern about the choice
to use dhcpv6 and ra instead of dhcpv4.  If you want to invoke process to
close the discussion on this topic, then that's your prerogative, but given
the previous lack of discussion about it, I would view this as a very poor
idea.

Nick

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 16 Apr 2014 17:55:07 +0000

Maybe for those that want this done via DHCPv4, RFC 2563's time is finally here? Maybe it needs additional tweaks to have the DHCPv4 client extend the times between retransmission of the DHCPDISCOVERs (as RFC 2563 does not appear to mean stop sending those or send them less frequently).

But as you say, it may be that this effort isn't necessary.

- Bernie

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Apr 2014 14:05:07 -0500

> the previous lack of discussion about it, I would view this as a very poor

That's fine.   The working group is amenable to useful discussion, as far as I know.   What concerns me is that a lot of objections have been raised that are simply opinions, and that are addressed in the current document.   And motivations have been stated that do not match my personal experience of the state of the art in host configuration stacks.

So I raise process not because I think process should trump technical contribution, but because process is the only way to deal with disputes over matters of opinion.   There's no way everyone can win on a matter of opinion, and while there's clearly some support for a DHCPv4 solution, there's substantially more support for a DHCPv6/RA solution.   That's also why I asked people who object whether they had objections which were of the form "this won't actually work because FOO."   Nobody provided any values of FOO with respect to the current proposal.

You may get the impression that I feel strongly about this proposal and think it's a good idea.   I do support the work, and I think the choice that's been made is a good one, but I really don't feel strongly about it—I'd be just as happy if the conclusion of the process was "just filter IPv4 at the access points if you want it to go away," and I'd like to see more discussion on that topic.   But what I really do feel strongly about is that discussions should be productive, and that's why you see me participating in this discussion in the way that I have been doing.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Apr 2014 14:06:41 -0500

> Maybe for those that want this done via DHCPv4, RFC 2563's time is finally here? Maybe it needs additional tweaks to have the DHCPv4 client extend the times between retransmission of the DHCPDISCOV…

2563 doesn't shut down IPv4 altogether.   It just kills IPv4 stateless autoconfiguration (the 169.254.x.x addresses you see if you don't have DHCPv4 service).

---

From: Owen DeLong <[email-masked]>
Date: Wed, 16 Apr 2014 12:42:06 -0700

> So I raise process not because I think process should trump technical contribution, but because process is the only way to deal with disputes over matters of opinion.   There's no way everyone can…

Please explain how “substantially more support” was established in this context.

It sounds like there was very limited discussion mostly in relation to other drafts in working groups outside of v6ops.

There’s definitely been substantial objection to doing it in DHCPv6/RA and significant support for doing it either in DHCPv4 or ICMPv4.

> You may get the impression that I feel strongly about this proposal and think it's a good idea.   I do support the work, and I think the choice that's been made is a good one, but I really don't fe…

In which case, I would suggest it would be more productive to look for ways to take the feedback received and apply it in a useful way rather than simply attempt to unilaterally declare it out of scope for the review and that the issues raised are “settled” and immutable by this process.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Apr 2014 15:04:27 -0500

> Please explain how “substantially more support” was established in this context.

Well, let's see.   The working group produced the document, so you've got that support for DHCPv6/RA.   And I count four people so far who have stated strong opinions in favor of DHCPv4, none of whom participate in the working group, and none of whom participated in developing the specification.   I've counted at least four people with the same level of participation in sunset4 (none) who disagree with you.   

I will admit that there has been a _lot_ more email in favor of DHCPv4, but that's a bug, not a feature, because most of it has been repeats or questions about the fairness of the process.   None of this matters, since we don't vote, either by head count or email volume count; I mention it simply to point out that if we did vote, the outcome would not be any more satisfying for you.

> In which case, I would suggest it would be more productive to look for ways to take the feedback received and apply it in a useful way rather than simply attempt to unilaterally declare it out of s…

I haven't said that the outcome is immutable; indeed I've explicitly said that it's mutable, and explained how to mutate it.   A question is never so settled that a lone cry in the wilderness of "that won't work because FOO" can't unsettle it.

---

From: "Bernie Volz (volz)" <[email-masked]>
Date: Wed, 16 Apr 2014 20:23:16 +0000

I understand that. Hence why I said we need the additional tweak (and I'm suggesting to slow the retransmission rate, not eliminate it completely ).

For those that were willing to continue to run a DHCPv4 server of some limited capabilities (as well as enough IPv4), this would:
1. Cause the clients not to autoconfigure (this is provided by RFC 2563). This means they have no address.
2. Cause the clients to reduce the rate at which they send DHCPDISCOVERs (this is a new option or change to DHCPv4 clients - like DHCPv6 SOLMAX). Continuing to send these at a reduced rate is good in that someone might have erred and thus the client will eventually get back IPv4 service.

This would then be a tool in the toolbox that people can use on networks where they want to avoid (reduce) IPv4 traffic. (Other tools include blocking it where possible (switches, Wifi routers), just ignoring it, ...). And it keeps the tools in the IPv4 / DHCPv4 part of the network and doesn't pollute IPv6 RAs and DHCPv6.

There's little we can do to cause people to implement these if they don't feel the need. 

- Bernie

---

From: Tom Taylor <[email-masked]>
Date: Wed, 16 Apr 2014 16:29:40 -0400

The real debate over the issue of IPv4 configuration over IPv6 occurred 
jointly between DHC and Softwires. It got quite heated. Jabber logs at 
http://www.ietf.org/jabber/logs/dhc/2013-11-05.html.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 16 Apr 2014 23:11:29 +0200 (CEST)

> solution that would work in practice is ethertype filtering.

That still doesn't solve the problem of the enterprise network being IPv6 
only but publishes A and AAAA entries for internal resources on the 
internal DNS zone, because other networks they have are dual stack.

Otoh I think this would be better solved by implementing MIF functionality 
in the device but... oh well.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 16 Apr 2014 14:16:40 -0700

On Apr 16, 2014, at 2:11 PM, Mikael Abrahamsson <[email-masked]> wrote:

>> So, I am not in favor of adding more hints that may or may not observed that result in additional complexity and create an even more diverse set of behavior that has to be managed.  This is why I think the only real solution that would work in practice is ethertype filtering.
> 
> That still doesn't solve the problem of the enterprise network being IPv6 only but publishes A and AAAA entries for internal resources on the internal DNS zone, because other networks they have are dual stack.

A host which doesn’t have a v4 route to reach a given A record should ignore said A record pretty harmlessly in favor of the AAAA record. A host that does otherwise is a broken host.

Owen

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Apr 2014 18:12:45 -0500

On Apr 16, 2014, at 3:29 PM, Tom Taylor <[email-masked]> wrote:
> The real debate over the issue of IPv4 configuration over IPv6 occurred jointly between DHC and Softwires. It got quite heated. Jabber logs at http://www.ietf.org/jabber/logs/dhc/2013-11-05.html.

That was a bit of debate between me and Ole, but to characterize it as "the real debate" kind of misses what consensus is about.   This is something that's been discussed at great length over the past six years, and the working group has at various times had consensus about it.   Ole and my discussion is one brief vignette within that multi-year saga.

But again, it's orthogonal to what we are talking about here—the draft we were talking about is how to configure IPv4 addresses and service information when you don't have a local wire with IPv4 running on it, not how you turn off IPv4 when you don't want it.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 16 Apr 2014 16:40:21 -0700

> But again, it's orthogonal to what we are talking about here—the draft we were talking about is how to configure IPv4 addresses and service information when you don't have a local wire with IPv4 ru…

Huh??? The discussion we are talking about has nothing to do with that. It’s about how to turn off IPv4 services on a LAN where it is desired to get an IPv4 DHCP client to STFU (or we’re talking about two different drafts, one of which is IPv4 configuration over an IPv6 tunnel and the other of which is the DHCP STFU).

Owen

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Apr 2014 10:40:27 +0900

On Thu, Apr 17, 2014 at 4:05 AM, Ted Lemon <[email-masked]> wrote:

> What concerns me is that a lot of objections have been raised that are
> simply opinions, and that are addressed in the current document.
>

I think the problem is that while they are, as you say, addressed in the
current document, there are a number of people on this thread who find the
arguments incomplete and insatisfactory. In other words, a lot of
objections are opinions, but some of the arguments in the current document
are simply opinions, too.

Example: one thing that argues in favour of a DHCPv4 option is that on
current IPv4-only networks, it can be very easy to send out a rogue RA or
install a rogue DHCPv6 server, because IPv6 security features like RA guard
or DHCPv6 filtering are likely not in place. The impact of such an attack
on current hosts is severe, because it allows attackers to blackhole
packets, but at least hosts that implement happy eyeballs can defend
against that sort of attack. This option makes it much worse: if a rogue RA
sender or rogue DHCPv6 server sends out a "kill IPv4" option, then the
hosts are dead in the water.

There is no mention of this in the document.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Apr 2014 10:44:08 +0900

On Thu, Apr 17, 2014 at 10:40 AM, Lorenzo Colitti <[email-masked]>wrote:

> This option makes it much worse: if a rogue RA sender or rogue DHCPv6
> server sends out a "kill IPv4" option, then the hosts are dead in the water.
>

Ted - for the avoidance of doubt, I assert that this is a "this won't work
because FOO" objection. :-)

---

From: Ted Lemon <[email-masked]>
Date: Wed, 16 Apr 2014 21:04:21 -0500

On Apr 16, 2014, at 8:40 PM, Lorenzo Colitti <[email-masked]> wrote:
> Example: one thing that argues in favour of a DHCPv4 option is that on current IPv4-only networks, it can be very easy to send out a rogue RA or install a rogue DHCPv6 server, because IPv6 security features like RA guard or DHCPv6 filtering are likely not in place. The impact of such an attack on current hosts is severe, because it allows attackers to blackhole packets, but at least hosts that implement happy eyeballs can defend against that sort of attack. This option makes it much worse: if a rogue RA sender or rogue DHCPv6 server sends out a "kill IPv4" option, then the hosts are dead in the water.
> 

Yes, but Lorenzo, if you followed the conversation, you might recall that this very issue came up, and the authors agree that it's an issue, and will be updating the draft to address the issue.   After they've addressed it according to what we talked about, a host that implements the proposal will no longer be affected by rogue RAs in the way that you describe.

And, by the way, since rogue RAs are a problem regardless, they need to be mitigated regardless.

---

From: Owen DeLong <[email-masked]>
Date: Wed, 16 Apr 2014 21:02:07 -0700

On Apr 16, 2014, at 6:44 PM, Lorenzo Colitti <[email-masked]> wrote:

> On Thu, Apr 17, 2014 at 10:40 AM, Lorenzo Colitti <[email-masked]> wrote:
> This option makes it much worse: if a rogue RA sender or rogue DHCPv6 server sends out a "kill IPv4" option, then the hosts are dead in the water.
> 
> Ted - for the avoidance of doubt, I assert that this is a "this won't work because FOO" objection. :-)

+1

Owen

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Apr 2014 06:59:06 +0200 (CEST)

> A host which doesn’t have a v4 route to reach a given A record should ignore said A record pretty harmlessly in favor of the AAAA record. A host that does otherwise is a broken host.

It has a default IPv4 route out to the mobile network.

---

From: Ray Hunter <[email-masked]>
Date: Thu, 17 Apr 2014 10:55:19 +0200

Mikael Abrahamsson wrote:
>> So, I am not in favor of adding more hints that may or may not 
>> observed that result in additional complexity and create an even more 
>> diverse set of behavior that has to be managed.  This is why I think 
>> the only real solution that would work in practice is ethertype 
>> filtering.
+1
>
> That still doesn't solve the problem of the enterprise network being 
> IPv6 only but publishes A and AAAA entries for internal resources on 
> the internal DNS zone, because other networks they have are dual stack.
>
> Otoh I think this would be better solved by implementing MIF 
> functionality in the device but... oh well.
>
Enterprise networks will use alternative protocols/methods to configure 
their end nodes IMHO e.g. Active Directory

And we have https://tools.ietf.org/html/rfc7078 for cases where some 
LANs are IPv4 only, some are dual stack, and others are IPv6 only 
(assuming anyone implements it)

I'm hoping that a node connected to an authenticated AD server will by 
default ignore any unauthenticated configuration hints purportedly sent 
via a DHCPv6 server.

Although as I've pointed out earlier, there could be serious race 
conditions here (RA/DHCPv6 IPv4 shutdown packet of death arrives before 
AD authentication).

-- 
Regards,
RayH

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 17 Apr 2014 20:02:21 +0900

On Thu, Apr 17, 2014 at 11:04 AM, Ted Lemon <[email-masked]> wrote:

> Yes, but Lorenzo, if you followed the conversation, you might recall that
> this very issue came up, and the authors agree that it's an issue, and will
> be updating the draft to address the issue.   After they've addressed it
> according to what we talked about, a host that implements the proposal will
> no longer be affected by rogue RAs in the way that you describe.
>

Hard to tell since we're well past 200 messages at this point, but I think
the solutions to this scenario that are being proposed are "put a
legitimate IPv6 router to your network" (i.e., enable IPv6 on it) and
"enable IPv6 RA guard + DHCPv6 guard on your network or block ethertype
0x86dd". All of those will require hardware upgrades in some networks.

And, by the way, since rogue RAs are a problem regardless, they need to be
> mitigated regardless.

That's a great statement in theory. However, bear in mind that on a lot of
currently-installed equipment with no RA guard / DHCPv6 guard support, that
means "block ethertype 0x86dd in the switches". As you say, if you can't or
don't do this, you already have a problem today.

However, the impact (or should I say, the "enormity" :-)) of the problem is
different:

   - Today, the situation is "block ethertype 0x86dd in the switches, and
   if you don't or can't, your hosts won't be able to reach dual-stack
   websites unless they implement happy eyeballs". A nuisance, yes, but
   survivable, since most OSes implement happy eyeballs these days.
   - If this draft is published and implemented, that will turn into "block
   ethertype 0x86dd in the switches, and if you don't or can't, kiss your
   network goodbye".

It's not OK to blind-side network operators like this.

I repeat: FOO.

---

From: Owen DeLong <[email-masked]>
Date: Thu, 17 Apr 2014 04:56:39 -0700

> It has a default IPv4 route out to the mobile network.

Providing a mechanism for an IPv6 LAN to shut down the IPv4 mobile network on a device which is unlikely to be enterprise controlled is not a solution in the real world, but only an attack vector.

Sure, 5 years ago, you could make the case that corporate mobile devices might be under sufficient control that this could be an effective solution in many cases. Today, BYOD is becoming more and more the trend and the percentage of mobile devices under sufficient corporate control to make this feasible is small and shrinking rapidly.

Instead, it simply introduces a DoS vector for additional attacks on mobile devices in the wile, which is pretty much the last thing we need at this point.

So, to make Ted happy… I’ll put this into terms he will hopefully consider appropriate:

This won’t work because it introduces a significant new denial of service path to a fairly large fraction of non-afflicted hosts until such time as they turn off the solution leading to...

This won’t work because the solution will work on such a small fraction of the afflicted hosts as to be ineffective at best.

Owen

---

From: Nick Hilliard <[email-masked]>
Date: Thu, 17 Apr 2014 13:14:19 +0100

On 16/04/2014 20:05, Ted Lemon wrote:
> What concerns me is that a lot of objections have been
> raised that are simply opinions, and that are addressed in the current
> document.

>From what I can see, there was no initial justification to use v6 transport
other than a declarative "it shall be so!" pronouncement, and in this
situation it is reasonable to question this decision in v6ops, particularly
as it will cause operational problems as outlined by a bunch of people.

Several of the issues raised about this on v6ops were not opinions, e.g.
Ray Hunter's list of concerns in his email of 2014-04-14 22:21:01 +0200,
most of which were based on the technical reality that implementing this
option in dhcpv6/ra instead of dhcpv4 will create interpretation+state
problems and unavoidable race conditions.  Disappointingly, there was no
follow-up on that email.  Similarly the comments in my email of april 15,
23:16:52 +0100 were ignored.

I fully understand your position on handling opinion A vs opinion B by
using process, but we're not in this situation.  Legitimate technical
objections have been raised about a variety of fundamental issues in this
ID and have either been addressed inadequately or in many cases not at all,
and you are incorrectly writing several of these objections off as opinion.

> I'd be just as happy if the conclusion of the process was "just
> filter IPv4 at the access points if you want it to go away," and I'd
> like to see more discussion on that topic.

this is also a valid concern.  I can see no reason why anyone would heed an
unauthenticated signal to entirely shut down all ipv4 services o/s wide on
their ipv4-enabled client (or even no-ipv4 options 1-2 for that matter),
when we already have the existing option for operators to fully satisfy all
aims of this draft by declining to forward ethertypes 0x0800 and 0x0806.
Simple and enforceable are both good engineering principals to aspire to.
Complex+advisory+piles of failure modes+controversial need a much greater
level of justification, which is notably absent from this draft.

Nick

---

From: "George, Wes" <[email-masked]>
Date: Thu, 17 Apr 2014 08:41:52 -0400

On 4/16/14, 10:45 AM, "Dale W. Carder" <[email-masked]> wrote:

>Modern enterprise wireless controller
>in this draft that there is a problem in this direction.

A fair point, but this extends beyond simply enterprise networks, and I’m
not willing to assume that all wireless networks will have a controller,
modern or otherwise. There are plenty of small and midsize networks that
are simply one or more APs all strung together on the same LAN. And given
how universally bad hotel and conference center networks usually are, I’m
skeptical that even those networks are consistently using a modern
controller, or if they are, it’s not set up particularly well. I don’t
know for sure whether DHCPv4 and related IPv4 junk traffic constitutes
anything more than a trivial amount of additional load on the RF if we
assume that the network is less than a certain size, but my thought was
that anything that contributes extra traffic on a network that is already
overloaded and performing poorly is something that should be removed if
reasonably possible. So I look at it as an opportunity for optimization if
we can come up with a way to do it that is worth the tradeoffs and
relatively transparent to network operators and users.

Thanks,

Wes George

---

From: Mikael Abrahamsson <[email-masked]>
Date: Thu, 17 Apr 2014 15:09:40 +0200 (CEST)

On Thu, 17 Apr 2014, Owen DeLong wrote:

> Providing a mechanism for an IPv6 LAN to shut down the IPv4 mobile
> network on a device which is unlikely to be enterprise controlled is not 
> a solution in the real world, but only an attack vector.

One could imagine that the signal is authenticated, for instance by SEND. 
The user can choose to trust these kinds of signals the same way they 
enter SSIDs to connect to automatically.

As I said before, this is all about policy.

---

From: "Dale W. Carder" <[email-masked]>
Date: Thu, 17 Apr 2014 08:51:14 -0500

Thus spake George, Wes ([email-masked]) on Thu, Apr 17, 2014 at 08:41:52AM -0400:
> modern or otherwise. 

True enough.  Maybe this could also be clarified in the problem scope of
the draft.

> There are plenty of small and midsize networks that
> how universally bad hotel and conference center networks usually are, 

Is this the Godwin's law's for networking? ;-)

While dhcpv4 behavior could contribute to the chaos and potentially
could be cleaned up, there's obviously a lot more going on that makes these 
networks perform poorly.  Included in this is that there are also many more 
multicast protocols running for service discovery and sharing that are 
far more chatty and probably present a far larger problem in rf airtime.

> So I look at it as an opportunity for optimization if

What if rfc2131's transmission delay was changed from SHOULD to
MUST?  (Section 4.1 par. 7).  What if the maximum was set higher than 64
seconds?  Would that alleviate the concerns?

This is where the problem scope in the draft certainly could be clearer,
as to whether we are talking about making dhcp more friendly in the
absence of v4 connectivity (which may certainly be a good idea), or if 
we are talking about the kill switch (which has a lot of problems still).

Dale

---

From: "Dale W. Carder" <[email-masked]>
Date: Thu, 17 Apr 2014 09:01:46 -0500

Thus spake George, Wes ([email-masked]) on Thu, Apr 17, 2014 at 08:41:52AM -0400:
> are simply one or more APs all strung together on the same LAN. 

It's also worth pointing out that these will be the same networks that 
will be significantly vulnerable to the attack vector opened up by this
draft.  If they are not filtering packets for RF performance, I would
fear that they are not filtering for rogue dhcp packets either.

Dale

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Apr 2014 09:43:28 -0500

On Apr 17, 2014, at 3:55 AM, Ray Hunter <[email-masked]> wrote:
> Although as I've pointed out earlier, there could be serious race conditions here (RA/DHCPv6 IPv4 shutdown packet of death arrives before AD authentication).

In an enterprise network, if you aren't filtering rogue RAs, you probably need to hire a new network administrator.  But yeah, that's definitely an issue that should be covered in the security considerations section.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Apr 2014 09:46:00 -0500

On Apr 17, 2014, at 6:02 AM, Lorenzo Colitti <[email-masked]> wrote:
> Hard to tell since we're well past 200 messages at this point, but I think the solutions to this scenario that are being proposed are "put a legitimate IPv6 router to your network" (i.e., enable IPv6 on it) and "enable IPv6 RA guard + DHCPv6 guard on your network or block ethertype 0x86dd". All of those will require hardware upgrades in some networks.

No, the solution was a bit more detailed than that, and did not involve RA guard.   You should probably wait for the next version of the draft and re-evaluate.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Apr 2014 09:48:24 -0500

> Providing a mechanism for an IPv6 LAN to shut down the IPv4 mobile network on a device which is unlikely to be enterprise controlled is not a solution in the real world, but only an attack vector.

We are in full agreement on this point.   It has to be up to the device what it does with whatever configuration information the network supplies, and I would not expect a device to take advice from one network about how to operate on another.   You could imagine exceptions to this, but I think all of them would be equally well addressed by individually updating each device, so there's no reason to have a protocol for doing it.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 17 Apr 2014 09:57:34 -0500

> as it will cause operational problems as outlined by a bunch of people.

Sure, it's reasonable to question the decision, and the working group did ask for feedback, so there's nothing wrong with providing feedback.   However, my point is that v6ops doesn't get any special veto power over this if you don't raise substantive objections.

> 23:16:52 +0100 were ignored.

It's not an opinion that implementing the current proposal using the current network configuration framework on a typical Linux box is difficult and potentially brittle.   I agree that this is the case.   I also agree that it's easier to implement this as a DHCPv4 option.   But the question is not "is it easier to implement" but "is it better."   The authors of the draft thought about it, wrote drafts documenting various solutions, and came up with "no, it's better to do it over IPv6."

What I am characterizing as opinion is "this is hard to do on Linux, therefore we should do it this other way."   It's true that it's hard to do on Linux, for certain values of Linux, but the connection between that and "we should do it this other way" is opinion.   This is compounded by the fact that there are already other configuration interdependencies that are handled poorly by the same Linux configuration framework we are talking about, and consequently work is being done to come up with a more robust framework.   I've mentioned this, but the response was to ignore that point and continue to assert "this is hard on Linux."   Which is why I tend to see this as "opinion" rather than "technical objection."

> level of justification, which is notably absent from this draft.

Noted.   I think it would be good to have text in the document that explains why this isn't the proposed solution, so that it can be evaluated on the merits and we don't have to speculate.

---

From: Ray Hunter <[email-masked]>
Date: Thu, 17 Apr 2014 18:30:29 +0200

> 17 April 2014 16:43
> In an enterprise network, if you aren't filtering rogue RAs, you 
> probably need to hire a new network administrator. But yeah, that's 
> definitely an issue that should be covered in the security 
> considerations section.
>
Lorenzo said it already: the impact is potentially much more serious.

If you've left IPv6 enabled on end nodes, but given IPv4 absolute 
priority in the permanent copy of the RFC6724 address selection rules 
table, any IPv6 addressing and routing would only become active when 
connected to an IPv6 only environment. If you've not (correctly) taken 
heed of RFC6104 (and a lot of people haven't), any rogue RA would 
probably only be a temporary annoyance to IPv4 which anyway goes away 
automatically with the rogue RA. Same is true for nodes implementing 
Happy Eyeballs RFC6555.

If you had a complete protocol shutdown due to 
draft-ietf-sunset4-noipv4-00 (assuming the proposed flag is carried in a 
rogue RA) you may need a helpdesk call, a site visit, or access to an 
out of band console to be able to restart your machines.

How would most mere mortals find a rogue RA (process) that only sends a 
handful of packets per week/month and where the purpose of the packet is 
obfuscated with headers? RFC7113 was only published in February 2014.

Potential Ping of Death all over again.
> 17 April 2014 10:55
>>> observed that result in additional complexity and create an even 
>>> more diverse set of behavior that has to be managed.  This is why I 
>>> think the only real solution that would work in practice is 
>>> ethertype filtering.
> +1
>>
> Enterprise networks will use alternative protocols/methods to 
> configure their end nodes IMHO e.g. Active Directory
>
> default ignore any unauthenticated configuration hints purportedly 
> sent via a DHCPv6 server.
>
> conditions here (RA/DHCPv6 IPv4 shutdown packet of death arrives 
> before AD authentication).
>

-- 
Regards,
RayH

---

From: Gert Doering <[email-masked]>
Date: Thu, 17 Apr 2014 18:54:47 +0200

Hi,

On Thu, Apr 17, 2014 at 09:57:34AM -0500, Ted Lemon wrote:
> However, my point is that v6ops doesn't get any special veto power over this if you don't raise substantive objections.

It will be interesting to see IETF last call on this, if there is 
significant objection being ignored "because it's from the wrong WG".

(Besides this, I've long stopped caring about this thread.  There's way
too much religion in here)

Gert Doering
        -- NetMaster

---

From: Simon Perreault <[email-masked]>
Date: Thu, 17 Apr 2014 12:55:38 -0400

Le 2014-04-16 21:40, Lorenzo Colitti a écrit :
> current IPv4-only networks, it can be very easy to send out a rogue RA
> or install a rogue DHCPv6 server, because IPv6 security features like RA
> guard or DHCPv6 filtering are likely not in place. The impact of such an
> attack on current hosts is severe, because it allows attackers to
> blackhole packets, but at least hosts that implement happy eyeballs can
> defend against that sort of attack. This option makes it much worse: if
> a rogue RA sender or rogue DHCPv6 server sends out a "kill IPv4" option,
> then the hosts are dead in the water.
> 

Because nobody mentioned it before. :)

Will be added to section "4.1. DHCPv6 vs DHCPv4" in the next revision.

Thanks,
Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 17 Apr 2014 12:57:41 -0400

> A host which doesn’t have a v4 route to reach a given A record should ignore said A record pretty harmlessly in favor of the AAAA record. A host that does otherwise is a broken host.

Welcome to the real world, where hosts are broken and routes don't matter.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 17 Apr 2014 13:04:53 -0400

Le 2014-04-17 07:56, Owen DeLong a écrit :
> network on a device which is unlikely to be enterprise controlled is
> not a solution in the real world, but only an attack vector.

The current draft doesn't allow this. Let me know if you find the text
unclear on this point.

Simon

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Apr 2014 09:31:15 +0900

On Thu, Apr 17, 2014 at 11:46 PM, Ted Lemon <[email-masked]> wrote:

> > Hard to tell since we're well past 200 messages at this point, but I
> think the solutions to this scenario that are being proposed are "put a
> No, the solution was a bit more detailed than that, and did not involve RA
> guard.   You should probably wait for the next version of the draft and
> re-evaluate.
>

But will the solution address this issue? If not, then there's no point
waiting for a new version of the draft, right? You agree that if this is
not addressed, it's a substantial reason not to put this option in IPv6
provisioning protocols?

---

From: Owen DeLong <[email-masked]>
Date: Fri, 18 Apr 2014 13:56:28 -0700

>  The authors of the draft thought about it, wrote drafts documenting various solutions, and came up with "no, it's better to do it over IPv6."

Which is strictly THEIR OPINION. An opinion which is apparently NOT shared by many people on this list.

> What I am characterizing as opinion is "this is hard to do on Linux, therefore we should do it this other way."   It's true that it's hard to do on Linux, for certain values of Linux, but the conne…

I don't believe that is a valid characterization of what was said.

What was said was "This is a bad way to do it for a number of reasons..."

Beyond that, there was an "oh, by the way, it's also hard and brittle on Linux".

IMHO, this should be done in DHCPv4 or ICMPv4 (and the more I think about it, the more I think ICMPv4) and NOT IPv6 because:

	1.	Principle of least surprise. IPv4 developers do not expect to have to anticipate that things happening
		over IPv6 will affect the behavior of core IPv4 services, nor should they. Most systems and network
		administrator have the same expectation.

		Configuring an IPv4 address over an IPv6 tunnel might be an exception, but at least in that case, the
		operator is aware of the fact that they are trying to tunnel IPv4 through IPv6 and that is likely to modify
		their general expectation. Shutting down IPv4 on command issued over IPv6, OTOH, violates all kinds
		of expectations and is likely to result in significant surprise in the operator community.

	2.	This feature could be implemented in IPv4 with little or no IPv4 stack running on the implementing device
		in question (AP, Router, etc.), so the argument that it requires an IPv4 stack to be preserved is somewhat
		specious. All that is needed is enough to detect an IPv4 DHCPREQUEST (and/or BOOTPREQUEST) and
		respond with a preformed ICMP DHCP4UNAVAILABLE message.

	3.	A host could receive conflicting IPv6 and IPv4 messages about what it is supposed to do about IPv4
		configuration. You can argue that such behavior is a broken network configuration, but the reality is that
		failing to consider this in real world scenarios has undesirable operational effects and security implications.
		At the very least, behavior in the face of such an event on the client side should be specified and
		deterministic.

	4.	The number of clients likely to be affected by this change is much greater than the target space. Moving this
		to IPv4 would reduce the impact space to match the target space.

And Oh, by the way:

		While Linux is an example of a well modularized operating system where IPv4 configuration is handled
		by completely separate mechanisms than IPv6 configuration, it is likely not the only one. Implementation
		of this on any such modularized system is likely to result in brittleness and unexpected consequences.

> Noted.   I think it would be good to have text in the document that explains why this isn't the proposed solution, so that it can be evaluated on the merits and we don't have to speculate.

I'd agree with that at the very least, though modifying the draft to propose an ICMP4 DHCPUNAVAILABLE message and client behavior in the face of receiving both that and a DHCPOFFER would be preferable IMHO.

Owen

---

From: Nick Hilliard <[email-masked]>
Date: Sat, 19 Apr 2014 23:30:48 +0100

On 17/04/2014 15:57, Ted Lemon wrote:
> Sure, it's reasonable to question the decision, and the working group
> did ask for feedback, so there's nothing wrong with providing feedback.
> However, my point is that v6ops doesn't get any special veto power over
> this if you don't raise substantive objections.

the point people are raising is that there appears to be a considerable gap
between your understanding of "substantive objections" and theirs.

> Noted.   I think it would be good to have text in the document that
> explains why this isn't the proposed solution, so that it can be
> evaluated on the merits and we don't have to speculate.

As the draft demands that a single unauthenticated packet can shut down
ipv4 services on a client device either completely (as specified in 5.3.3)
or almost completely (5.3.2), both options will need a detailed security
analysis to describe how packets of this form cannot be abused by either an
malicious operator or by rogue packets caused by access domain
misconfiguration.  Also, given the extraordinary nature of these
requirements, the justification for including them in an internet standards
track document will need to be similarly extraordinary.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Sun, 20 Apr 2014 15:55:56 -0400

> track document will need to be similarly extraordinary.

There was discussion on this question, updates were proposed, and I expect to see them in the next draft.

---

From: Matthew Petach <[email-masked]>
Date: Mon, 21 Apr 2014 09:43:24 -0700

On Thu, Apr 17, 2014 at 7:48 AM, Ted Lemon <[email-masked]> wrote:

> network on a device which is unlikely to be enterprise controlled is not a
> solution in the real world, but only an attack vector.
>
> We are in full agreement on this point.   It has to be up to the device
> what it does with whatever configuration information the network supplies,
> and *I would not expect a device to take advice from one network about how
> to operate on another.*   You could imagine exceptions to this, but I think
> all of them would be equally well addressed by individually updating each
> device, so there's no reason to have a protocol for doing it.
>

Ted, I just want to repeat your statement once more:

"I would not expect a device to take advice from one network about how to
operate on another."

I don't think I could sum up my objections to this draft any
more clearly than you just did.  I would not expect any device
of mine to take advice from an IPv6 network about how to
operate on an IPv4 network.  Even if those networks happen
to be sharing the same physical piece of wire, or same range of
RF spectrum, they are independent and orthogonal networks.

Now, one can take steps to bring those networks together,
such as creating tunnels, encapsulating one network within
the other; but under those circumstances, one should realize
the now-shared-fate scenario one has delved into.  But by
default, the two protocols were designed to be ships in the
night, and what is being proposed here clearly violates
that.

(looking at this from the other side, it would have been an
interesting proposal a few years back to have a DHCPv4
option to tell hosts to shut down all those pesky teredo,
6in4, and other pesky IPv6 tunnelling, translation, and
encapsulation technologies that the hosts might have
tried to use that caused extra unnecessary packets
to clog the networks.  I'd like to imagine the outcry
against such a "packet of IPv6 death" would have
been equally as loud as what you're seeing now.)

Matt

---

From: Ted Lemon <[email-masked]>
Date: Mon, 21 Apr 2014 12:51:52 -0400

On Apr 21, 2014, at 12:43 PM, Matthew Petach <[email-masked]> wrote:
>  I would not expect any device
> operate on an IPv4 network.

I think you're abusing the term "network" here to make a point that's only tangentially related.   If you have a point to make, you should make it without torturing definitions like this to do it.   A physical wire (or SSID) is obviously owned by some one entity, and that entity is the network operator for that wire.   If conflicting information appears on that wire, it is either an attack or a misconfiguration; in either case, the network operator has to fix it.   We should try to be robust in the face of such attacks, but the distinction you are drawing gives us no help in doing so.

---

From: "George, Wes" <[email-masked]>
Date: Tue, 22 Apr 2014 09:00:32 -0400

From: Matthew Petach <[email-masked]<mailto:[email-masked]>>
Date: Monday, April 21, 2014 at 12:43 PM
To: Ted Lemon <[email-masked]<mailto:[email-masked]>>
Cc: "[email-masked]<mailto:[email-masked]> WG" <[email-masked]<mailto:[email-masked]>>
Subject: Re: [v6ops] Please review the No IPv4 draft

WG] I think that there’s a need for clarification here. A lot of this discussion has focused almost exclusively on the full-on disabling of IPv4. Part of what the draft discusses is that there are differing things that can be signaled to the local devices from the network based on the bit set in the proposed option. There is an option that simply signals “there is no IPv4 support on this network” and makes attendant recommendations that the device decide on its own what to do for any local IPv4 traffic on the LAN, including doing nothing, configuring 169 addresses, etc. but that it should disable IPv4 on the upstream interface facing the network that provided the signal (I.e. Stop forwarding IPv4 traffic and stop sending DHCPv4).
I’m willing to go with consensus (if exist) that the more aggressive option of something like a full-on IPv4 killswitch that affects more than one interface and affects the local network is a bridge too far, both for security reasons (It’ll be hard to secure to a level that exploits aren’t likely) and because it gets into a question about autonomy and span of control. But I think it’s worth highlighting that there are also less aggressive options discussed in the draft, and I’d like to have some sense that those are mostly on the right track, and your statement is so broad that I wanted to get clarification on what you think of this.

Thanks,

Wes George

---

From: Simon Perreault <[email-masked]>
Date: Tue, 22 Apr 2014 09:23:37 -0400

Le 2014-04-22 09:00, George, Wes a écrit :
> WG] I think that there’s a need for clarification here. A lot of this
> discussion has focused almost exclusively on the full-on disabling of
> IPv4. Part of what the draft discusses is that there are differing
> things that can be signaled to the local devices from the network based
> on the bit set in the proposed option. There is an option that simply
> signals “there is no IPv4 support on this network” and makes attendant
> recommendations that the device decide on its own what to do for any
> local IPv4 traffic on the LAN, including doing nothing, configuring 169
> addresses, etc. but that it should disable IPv4 on the upstream
> interface facing the network that provided the signal (I.e. Stop
> forwarding IPv4 traffic and stop sending DHCPv4). 
> I’m willing to go with consensus (if exist) that the more aggressive
> option of something like a full-on IPv4 killswitch that affects more
> than one interface and affects the local network is a bridge too far,
> both for security reasons (It’ll be hard to secure to a level that
> exploits aren’t likely) and because it gets into a question about
> autonomy and span of control. But I think it’s worth highlighting that
> there are also less aggressive options discussed in the draft, and I’d
> like to have some sense that those are mostly on the right track, and
> your statement is so broad that I wanted to get clarification on what
> you think of this.

Right.

To be very explicit, one of the "less aggressive" options on the table
is to specify a "there is no IPv4 on this network" signal while saying
nothing about how a host should react to this signal. Each
implementation could use that hint however it sees fit.

Simon

---

From: Philip Homburg <[email-masked]>
Date: Tue, 22 Apr 2014 15:50:36 +0200

In your letter dated Tue, 22 Apr 2014 09:00:32 -0400 you wrote:
>    WG] I think that there's a need for clarification here. A lot
>    of this discussion has focused almost exclusively on the full-on
>    disabling of IPv4. Part of what the draft discusses is that
   there are differing things that can be signaled to the local
>    devices from the network based on the bit set in the proposed
>    option. There is an option that simply signals "there is no IPv4
>    support on this network" and makes attendant recommendations
>    that the device decide on its own what to do for any local IPv4
>    traffic on the LAN, including doing nothing, configuring 169
>    interface facing the network that provided the signal (I.e.
>    Stop forwarding IPv4 traffic and stop sending DHCPv4).

I'm really curious about the resistance of putting the no-ipv4 option in
DHCPv4. As far as I can tell that can be done safely, with almost no 
drawbacks.

Instead, an endless amount of effort seems to be invested in defending the
current choice for DHCPv6 and RA.

Maybe there is document the describes why putting the no-ipv4 option in
DHCPv4 is such a horrible idea. It is just that I can't find it.

Does anyone have a link to that document? (Assuming it exists)

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Apr 2014 09:54:18 -0400

> DHCPv4. As far as I can tell that can be done safely, with almost no 

The current draft describes some of the problems.   Many of the objections raised here completely ignore what the current draft says.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 22 Apr 2014 16:11:13 +0200

In your letter dated Tue, 22 Apr 2014 09:54:18 -0400 you wrote:
>The current draft describes some of the problems.   Many of the 
>objections raised here completely ignore what the current draft says.

Okay. Let's see. These are all arguments in Section 4.1 of
draft-ietf-sunset4-noipv4-00 that are listed as negative for DHCPv4.

"-     Devices that haven't been updated to speak IPv6 likely won't
"      recognize a new DHCPv4 code telling them that IPv4 isn't
"      supported.

Doesn't seem to make sense in deciding between DHCPv4 and DHCPv6.

"   -  When the goal is to turn off IPv4, having to maintain and operate
"      an IPv4 infrastructure (routing, ACLs, etc.) just to be able to
"      send negative responses to DHCPv4 requests is not productive.
"      Having the option transported in IPv6 allows the ISP to focus on
"      operating an IPv6-only network.

This one makes sense. So what do we want? A very small amount of code can
can send and receive DHCPv4 messages or all of the security problems
associated with the alternatives?

Let me remark here that in Section 4.1, the security implications, network
mangement problems and implementations issues of putting the option in DHCPv6
are all not mentioned.

"-  Turning IPv4 off using an IPv4-transported signal means that there
"   is no way to go back.  Once the DHCPv4 option has been accepted by
"   the DHCPv4 client, IPv4 can no longer be turned on remotely
"   (rebooting the client still works).  Configurations change,
"   mistakes happen, and so it is necessary to have a way to turn IPv4
"   back on.  With a DHCPv6 option, IPv4 can be turned back on as soon
"   as the client makes a new DHCPv6 request, which can be the next
"   scheduled one or can be triggered immediately with a Reconfigure
"   message.

This argument mistakenly assumes that the goal is to switch off the IPv4 
stack. However that doesn't follow from the requirements. Suspending DHCPv4
for a while would equally support the requirements.

That leaves that in case of an error, a DHCPv6 reconfigure or a RA would allow
a more quickly recovery.

So conclusion is a that against the many arguments mentioned on this
list, putting the option in DHCPv4 requires a small amount of code in
routers to send the no-ipv4 option and it relies on timeouts to recover from
configuration errors.

In contrast, putting the option in RAs and DHCPv6 creates more security 
problems, a more complex network management and a more complex implementation
in a number of operating systems.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Apr 2014 11:17:27 -0400

> associated with the alternatives?

You are saying this as if there are no security problems associated with DHCPv4, but of course DHCPv4 has very similar security problems.   In order to prevent DHCPv4-based attacks on the local wire, you must filter bad DHCPv4 packets.   If you are filtering bad DHCPv4 packets on the wire, filtering bad RA packets is doable as well.  And you should be doing it, because RAs on an IPv4-only wire are a dead simple way to set up MiTM attacks.

I already addressed this point and the others you made in previous comments.   This conversation has gotten extremely repetitive.  I think if you want to make these points again and make sure they have been addressed, the way to do it is to open up an issue tracker for this draft, and continue the discussion on the sunset4 mailing list.   Otherwise we're just spamming v6ops, and I'm sure the people on v6ops who don't care about sunset4 would really like it if we stopped doing that.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 23 Apr 2014 00:32:04 +0900

On Wed, Apr 23, 2014 at 12:17 AM, Ted Lemon <[email-masked]> wrote:

> In order to prevent DHCPv4-based attacks on the local wire, you must
> filter bad DHCPv4 packets.   If you are filtering bad DHCPv4 packets on the
> wire, filtering bad RA packets is doable as well.
>

In networks that support only IPv4, filtering DHCPv4 packets is probably
supported. Filtering DHCPv6 or RA packets may not be supported and may
require hardware upgrades. On such networks, the damage from rogue DHCPv6
or RA packets is mitigated by happy eyeballs. The damage from rogue "shut
down your entire IPv4 stack" options cannot be.

> I already addressed this point and the others you made in previous
> comments.
>

Did you? IIRC, all you said was, "let's wait for the next version of the
draft".

> This conversation has gotten extremely repetitive.
>

It takes two to make a quarrel.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Apr 2014 11:39:11 -0400

On Apr 22, 2014, at 11:32 AM, Lorenzo Colitti <[email-masked]> wrote:
> In networks that support only IPv4, filtering DHCPv4 packets is probably supported. Filtering DHCPv6 or RA packets may not be supported and may require hardware upgrades. On such networks, the damage from rogue DHCPv6 or RA packets is mitigated by happy eyeballs. The damage from rogue "shut down your entire IPv4 stack" options cannot be.

Do you have data on this, or is it just supposition?

---

From: "Niall O'Reilly" <[email-masked]>
Date: Tue, 22 Apr 2014 17:07:13 +0100

At Tue, 22 Apr 2014 11:39:11 -0400,
Ted Lemon wrote:
> > In networks that support only IPv4, filtering DHCPv4 packets is
> > probably supported.

  Confirmed from personal experience on the campus network where I work.

> > Filtering DHCPv6 or RA packets may not be
> > supported and may require hardware upgrades. 

  Confirmed as mentioned above.

> > On such networks, the
> > damage from rogue DHCPv6 or RA packets is mitigated by happy
> > eyeballs.

  I cannot personally confirm this.

> > The damage from rogue "shut down your entire IPv4 stack"
> > options cannot be.

  None of us can confirm this, as it depends on future client
  implementation.

> Do you have data on this, or is it just supposition?

  I expect that the two points I was able to confirm above are widely
  known among those who have tried to implement IPv6 on an existing
  IPv4-only network.

  Best regards,
  Niall O'Reilly

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Apr 2014 12:12:48 -0400

>  I cannot personally confirm this.

I think this would protect from RA-based DoS, but not RA-based MiTM.   RA-based MiTM would be better if it could shut off IPv4, but will still work some of the time (or possibly all of the time) even if IPv4 is present.

>  known among those who have tried to implement IPv6 on an existing

Thanks.   So is it the case that there is a UI element that says "disable DHCPv4 except from the following IP source addresses/on the following physical ports," and the switch has no way to for instance disable arbitrary ethertypes?

---

From: Philip Homburg <[email-masked]>
Date: Tue, 22 Apr 2014 19:04:32 +0200

>I already addressed this point and the others you made in previous 

I hope I can take from this that the only substantial documented advantage
of DHCPv6/RA over DHCPv4 is that the DHCPv4 approach would require a 
small stub DHCPv4 implementation in future routers that lack IPv4 support.

If this is indeed correct, then I will leave to the sunset4 WG to decide 
how to move forward.

In my expectation, host operating systems will either not implement this RFC
or leave it disabled by default, defeating its purpose.

At least for me, this discussion provides enough arguments why it is a bad
idea to ship with this enabled by default.

---

From: Owen DeLong <[email-masked]>
Date: Tue, 22 Apr 2014 13:04:19 -0700

> implementation could use that hint however it sees fit.

Because IPv6 deployment has been helped so much in the past by ambiguous standards which allow wildly different implementations from vendor to vendor.

If we’re going to specify a signal, we should specify what the host should do with that signal.

Owen

---

From: Simon Perreault <[email-masked]>
Date: Tue, 22 Apr 2014 16:15:55 -0400

> If we’re going to specify a signal, we should specify what the host should do with that signal.

FWIW, I fully agree. I felt that it would only be fair to mention that
option which has been suggested by others in the past.

Simon

---

From: "Niall O'Reilly" <[email-masked]>
Date: Mon, 28 Apr 2014 17:20:38 +0100

Ted,

  I'm sorry for the delay in replying.

  I wasn't aware of a way to disable arbitrary ethertypes on the gear
  we use.  It took a little time to discover whether this was just due
  to my ignorance, or rather an indication of what the equipment could
  do.  After some digging, I'm still not entirely sure.

At Tue, 22 Apr 2014 12:12:48 -0400,
Ted Lemon wrote:
> Thanks.  So is it the case that there is a UI element that says
> "disable DHCPv4 except from the following IP source addresses/on the
> following physical ports,"

  Definitely.

> and the switch has no way to for instance disable arbitrary
> ethertypes?

  This is apparently so, as far as I and my colleagues in our Net-Ops
  team are aware or can establish from the experience and
  documentation available to us.

  So, a "yes" to your compound question, as far as I can see.

  This leaves such pre-IPv6 switch equipment as we have configurable
  to block rogue DHCP (v4) traffic but unable to protect against rogue
  IPv6 traffic on the link.

  ATB
  Niall O'Reilly

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Apr 2014 12:23:46 -0400

>  IPv6 traffic on the link.

Hm, okay.  Are you guys using a specific brand of equipment, or is this a problem you're seeing with a variety of switches from different vendors?

---

From: "Niall O'Reilly" <[email-masked]>
Date: Mon, 28 Apr 2014 19:30:54 +0100

At Mon, 28 Apr 2014 12:23:46 -0400,
Ted Lemon wrote:
> Hm, okay.  Are you guys using a specific brand of equipment, or is
> this a problem you're seeing with a variety of switches from
> different vendors?

  Where I work, we use Cisco gear.

  Current access-network kit, running a current image, doesn't show
  the kind of problem I've described, but most of our installed
  network plant does, and will until its turn for capital spend
  comes round.

  ATB
  Niall

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Apr 2014 14:52:34 -0400

>  network plant does, and will until its turn for capital spend

I thought Cisco had a policy of not charging extra for IPv6 upgrades.

---

From: Gert Doering <[email-masked]>
Date: Mon, 28 Apr 2014 21:08:04 +0200

Hi,

> I thought Cisco had a policy of not charging extra for IPv6 upgrades.

*If* the hardware you have is IPv6-capable, and *if* the business unit
in question remembers that policy, yes.

Gert Doering
        -- NetMaster

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Apr 2014 15:53:22 -0400

> in question remembers that policy, yes.

Seems like you could insist.   How old is the newest non-IPv6-capable equipment?

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 28 Apr 2014 21:37:52 +0100

> Seems like you could insist.   How old is the newest non-IPv6-capable

Well you can insist, yes, but it takes time and patience, during which your
network can be vulnerable to problems.

There's a slightly old list for RA guard support here:

> https://www.ernw.de/download/raguard_support_05022013.pdf

You can see that RA Guard (+ dhcpv6 guard) is absent on the entire Cisco
Nexus line.  This can be worked around to some degree for physical
hardware, but not for virtualised infrastructure, where the situation is
pretty grim at least for vmware based hypervisors.

I haven't found a similar list for DHCPv6 guard, but from previous
investigation, support was even less well developed compared to RA guard
due to the complexities involved if the support involves anything other
than a simple tcp/udp port block.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Apr 2014 17:00:55 -0400

Hm.   Cisco documentation for NX-OS does seem scant on the topic of RA-Guard.   Does anybody know any more about this?

---

From: Sander Steffann <[email-masked]>
Date: Mon, 28 Apr 2014 23:27:28 +0200

Hi Ted,

> Hm.   Cisco documentation for NX-OS does seem scant on the topic of RA-Guard.   Does anybody know any more about this?

Yes: it really is as bad as it seems :(

Cheers,
Sander

---

From: "Dale W. Carder" <[email-masked]>
Date: Mon, 28 Apr 2014 16:30:46 -0500

Thus spake Nick Hilliard ([email-masked]) on Mon, Apr 28, 2014 at 09:37:52PM +0100:
> hardware

RA Guard "the feature" is not there, but the workaround is simple.  This
example is for a n5548:

interface Ethernet1/14
  description omg_server :!P:
  ipv6 port traffic-filter G-T-v6NoDhcpServerNoRouterAdv in
  switchport mode trunk
  switchport trunk allowed vlan 38-3880
  spanning-tree port type edge trunk
  spanning-tree guard root
  spanning-tree bpdufilter enable
  no snmp trap link-status
  storm-control broadcast level 0.50

ipv6 access-list G-T-v6NoDhcpServerNoRouterAdv
  10 remark Id: G-T-v6NoDhcpServerNoRouterAdv.acl,v 1.2 2010/12/06 00:48:13 m6k Exp
  20 deny icmp any any router-advertisement
  30 deny udp any eq 547 any eq 546
  40 permit ipv6 any any

sn-cssc-b217-5-lab# sh ver | inc "system image"
  system image file is:    bootflash:/n5000-uk9.5.0.3.N2.1.bin

Dale

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Apr 2014 17:39:35 -0400

On Apr 28, 2014, at 5:30 PM, Dale W. Carder <[email-masked]> wrote:
> example is for a n5548: [...]

Cool, thanks!   I'm surprised that I didn't turn up any articles online on how to do this.   Cisco suggests this incantation for Catalyst, but not Nexus.

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 28 Apr 2014 22:58:02 +0100

> RA Guard "the feature" is not there, but the workaround is simple.  This

Not supported on nexus 1000 (the virtual switch). IPv6 acls are not supported on this platform at all.  That means no functional ipv6 client support on the esxi platform at the moment. 

Nick

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Apr 2014 18:03:04 -0400

> Not supported on nexus 1000 (the virtual switch). IPv6 acls are not supported on this platform at all.  That means no functional ipv6 client support on the esxi platform at the moment. 

Yes, but the nexus 1000 has a firewall.   Are you telling me that there's no way to configure the firewall to block rogue RAs?

---

From: Nick Hilliard <[email-masked]>
Date: Mon, 28 Apr 2014 23:27:06 +0100

On 28 Apr 2014, at 23:03, Ted Lemon <[email-masked]> wrote:
> Yes, but the nexus 1000 has a firewall.

I think you're getting mixed up here. The nexus 1000v is a virtual switch and the asa1000v is the virtual firewall. 

This isn't a firewalling issue because FWs act at layer 3 and ra guard / dhcpv6 guard act at l2.  If you're referring to vsg, that's zone based protection which is a different kettle of fish.

>  Are you telling me that there's no way to configure the firewall to block rogue RAs?

There is currently no way to block rogue RAs or rogue dhcpv6 pkts at layer 2 on VMware esxi, either with the Cisco nexus1000v soft-switch or the native soft-switch.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Mon, 28 Apr 2014 22:04:22 -0400

> Not supported on nexus 1000 (the virtual switch). IPv6 acls are not supported on this platform at all.  That means no functional ipv6 client support on the esxi platform at the moment. 

Hm, so you connect virtual machines that aren't in the same trust domain to the same virtual layer 2?   Why would you do that?

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 29 Apr 2014 06:18:28 +0100

On 29/04/2014 03:04, Ted Lemon wrote:
> Hm, so you connect virtual machines that aren't in the same trust domain
> to the same virtual layer 2?   Why would you do that?

Why is s/virtual/physical/ any different?

One reason specific to virtualised environments is that commercial services
require high availability with fast failover to alternative gateways.  This
means VRRP (or your favourite first-hop redundancy protocol) because fast
failover with RA isn't feasible.  You cannot run a vrrp instance per
customer because that doesn't scale.  That means putting tenants in a
shared domain so you can share the same gateway for multiple customers.

Nick

---

From: Mikael Abrahamsson <[email-masked]>
Date: Tue, 29 Apr 2014 07:29:33 +0200 (CEST)

On Tue, 29 Apr 2014, Nick Hilliard wrote:

> One reason specific to virtualised environments is that commercial 
> services require high availability with fast failover to alternative 
> gateways.  This means VRRP (or your favourite first-hop redundancy 
> protocol) because fast failover with RA isn't feasible.  You cannot run 
> a vrrp instance per customer because that doesn't scale.  That means 
> putting tenants in a shared domain so you can share the same gateway for 
> multiple customers.

Then demand that the virtualised environment vendors do what the access 
switch vendors have done for a long time, implement either private vlan or 
SAVI type functionality.

... or put L3 routing so far out into the network that VRRP actually does 
scale, or use virtualised machines to do the VRRP so you can split it up 
between a lot of CPUs.

It's not like this is unsolvable.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 29 Apr 2014 06:37:16 +0100

On 29/04/2014 06:29, Mikael Abrahamsson wrote:
> Then demand that the virtualised environment vendors

you know how well this works in practice: it takes years and the ability to
wave a massive amount of money in front of the vendor.

This is getting way off topic, btw.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Apr 2014 07:57:16 -0400

> This is getting way off topic, btw.

Not really.  You said "the following change is needed because X."   So we are exploring the parameters of X.   For you it seems to boil down to "because virtualization software from VMware and Cisco has serious limitations with respect to IPv6."   But given that the whole virtualization thing is fairly new, and that one of the points of doing virtualization is to commoditize the network environment, this seems like a problem that will get solved long before there is any significant deployment of the No IPv4 proposal.

Also, when I read the documentation, there did seem to be a way to completely disable IPv6 at least on Cisco virtual switches.   I don't know if that causes filtering to happen, or just prevents the switch from actively supporting IPv6, but it would be interesting to know which it is.

While we didn't actually find a smoking gun on your network, it's possible that your point is still valid on other networks.   If this is a real problem, it should be addressed.   So it's worth evaluating how serious and long-term a problem it is.   I don't know that this is the right place for that to happen, of course, but it does seem relevant.   This working group has published at least one draft recently on a closely related topic.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 29 Apr 2014 13:23:05 +0100

On 29/04/2014 12:57, Ted Lemon wrote:
> For you it seems to boil down to
> "because virtualization software from VMware and Cisco has serious
> limitations with respect to IPv6." 

No.  I was just clarifying a particular point about a particular question
you had about certain forms of ipv6 support on a specific line of cisco kit
which I happen to be familiar with.

If you do a stack unwind of this conversation:

- it is currently not possible to run large scale ipv6 shared L2 domains on
specific (albeit market leader) hypervisor platforms, which is a subset of
a much bigger problem:

 - dhcpv6 guard / ra guard support is not supported on plenty of types of
kit from a wide variety of vendors (link provided to show the scale of this
problem), which means that:

  - from an operational point of view, the poor support for dhcpv6/ra guard
is a general reason why, given the choice between using either (dhcpv4) or
(dhcpv6 + ra) for ending up with the same outcome, it would be
operationally more attractive to use dhcpv4,

   - which is only one of many reasons that a bunch of people have put
forward to suggest that dhcpv4 might be a better choice as a transport
mechanism for delivering the bits specified in draft-ietf-sunset4-noipv4,

    - assuming that the basic idea of having a signal to shut down ipv4
services as specified in the draft is a sensible idea in the first place.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Apr 2014 08:45:55 -0400

> problem), which means that:

The information in the link you provided was wrong.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 29 Apr 2014 16:54:20 +0100

> The information in the link you provided was wrong.

I did mention that the document was both a little old (13 months) and that
there were workarounds for some kit.  The document specifies "RA Guard",
which is a name for a category of ipv6 RA filtering, and some kit can use
IPv6 ACLs to implement some of the features suggested by the SAVI folks.
Certainly not all, but some yes.

This does not invalidate the reality that there is a problem with ipv6
control packet filtering on many l2 devices on the market, physical and
virtual.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Apr 2014 12:08:56 -0400

> control packet filtering on many l2 devices on the market, physical and

It also doesn't establish it.   That was what I was asking for earlier.   I think that if there is a serious gap here, the working group should consider that.   But we haven't actually established that such a gap exists.   My intuition is that you may be right about this, but I'd like to go on more than intuition.

---

From: Nick Hilliard <[email-masked]>
Date: Tue, 29 Apr 2014 22:38:53 +0100

On 29/04/2014 17:08, Ted Lemon wrote:
> It also doesn't establish it.   That was what I was asking for earlier.
> I think that if there is a serious gap here, the working group should
> consider that.   But we haven't actually established that such a gap
> exists.   My intuition is that you may be right about this, but I'd like
> to go on more than intuition.

there are three issues here: 1. how much kit out there that doesn't support
ra guard / dhcpv6 snooping or basic ipv6 acls on l2 ports, 2. for the kit
that does support these features, how good is that support and 3. how
important this is to the noipv4 proposal.

#1 is highly platform specific and depends on both hardware and software
support. e.g. Cisco Nexus 3000 doesn't support ipv6 acls on L2 ports.
cisco nexus 1000v doesn't support ipv6 acls at all.  Cisco 6500 boxes
support ra guard but not dhcpv6 guard.  Brocade ironware boxes will support
IPv6 ACLs, but can only install them on L2 ports on certain platforms, and
even then only if you don't have mac filters installed on those ports.
Same mac||ip filter problem on netiron s/w.

#2 is complicated enough that Fernando Gont wrote an ID on the topic.  Many
platforms are subject to the sort of fragmentation / extension header
evasion techniques that Fernando describes.  The only switch which I've
heard to support ra guard for difficult packets is the windows hyperv
soft-switch.  Hardware forwarded switches seem to be particularly prone to
the problem

#3: the ietf is fully within remit to write this off as an operational
issue and not a protocol problem, and that if your ipv6 first hop security
mechanism is broken, then you have bigger problems.  While this is
undoubtedly true, the draft will create the requirement for all networks -
including legacy ones - to protect against rogue RA / DHCPv6 packets
because otherwise you could find that newer clients on unprotected legacy
networks would be susceptible to having their ipv4 stacks shut down if
someone with a sense of humour starts playing around.

#3 means that the network operator must be trusted.  I don't trust many of
the networks that I connect to because sometimes operators and other agents
are malicious and I expect my phone / laptop / etc not to be particularly
interfered with by their malice.  The level of policy interference from
this ID is very large indeed.

Nick

---

From: Sander Steffann <[email-masked]>
Date: Tue, 29 Apr 2014 23:58:35 +0200

Hi Nick,

> this ID is very large indeed.

I think you summarised it really well.

Thanks!
Sander

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Apr 2014 18:41:35 -0400

On Apr 29, 2014, at 5:38 PM, Nick Hilliard <[email-masked]> wrote:
> #3 means that the network operator must be trusted.

If you are referring to the proposal that a packet from one network be able to shut off IPv4 on another network, I agree that that is a bad idea.   This has been discussed at length on this thread, and the authors agree that that point needs to be reconsidered.

Fernando's draft actually suggests filtering ethertype 0x86DD in order to avoid RA attacks on switches that don't have RA guard, which is why I assumed that that was an option for IPv4-only networks that don't want to be affected by this proposal.

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 30 Apr 2014 00:21:01 +0100

On 29/04/2014 23:41, Ted Lemon wrote:
> Fernando's draft actually suggests filtering ethertype 0x86DD in order
> to avoid RA attacks on switches that don't have RA guard, which is why I
> assumed that that was an option for IPv4-only networks that don't want
> to be affected by this proposal.

this creates a new requirement to implement mac layer filtering of 0x86dd
across all ipv4 networks, on all network media, everywhere - in order to
stop casual jokers from trashing people's ipv4 network connectivity, even
if the signal is only the interface option (i.e. semantic option 1).  The
operational cost of this is not feasible.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Tue, 29 Apr 2014 21:13:50 -0400

> operational cost of this is not feasible.

Yes, it's *much* worse than blocking bogus DHCPv4 servers, which can do exactly the same thing.

I hear what you are saying, Nick.   There's no need for hyperbole.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 30 Apr 2014 06:09:44 +0200 (CEST)

On Wed, 30 Apr 2014, Nick Hilliard wrote:

> this creates a new requirement to implement mac layer filtering of 
> 0x86dd across all ipv4 networks, on all network media, everywhere - in 
> order to stop casual jokers from trashing people's ipv4 network 
> connectivity, even if the signal is only the interface option (i.e. 
> semantic option 1).  The operational cost of this is not feasible.

Nick, if you're not doing this today you're exposing your customers to 
MITM attacks and all kinds of other bad things. What this proposal is 
doing is adding one more reason to implement proper L2 security. You're 
already screwed, this mechanism just adds one more way you're screwed.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 30 Apr 2014 14:36:03 +0900

On Wed, Apr 30, 2014 at 1:09 PM, Mikael Abrahamsson <[email-masked]>wrote:

> MITM attacks and all kinds of other bad things. What this proposal is doing
> is adding one more reason to implement proper L2 security. You're already
> screwed, this mechanism just adds one more way you're screwed.
>

Today, you're not too badly screwed if your first-hop security supports
IPv4 and your network only provides IPv4.

Yes, it's true that a rogue RA can still blackhole or MITM your traffic,
but happy eyeballs will protect you to some degree against blackholing, and
SSL will protect you (to some degree :-)) against MITM.

If this draft is published and people implement it, you are completely
screwed, because all it takes is one packet to shut down all the machines
on the network.

---

From: Doug Barton <[email-masked]>
Date: Wed, 30 Apr 2014 01:25:31 -0700

Ted,

Sometimes ideas that are cooked up in one environment don't stand the 
light of day when they escape the environment they were created in. I 
think this is one of those times.

First, any draft that suggests adding new options to RA is going to get 
a negative reaction from me, for reasons I've stated ad nauseum in the 
past, and I really don't want to open that can of worms on this point.

Second, as others have pointed out this is layering violation of 
monumental proportions, and thinking about this as an implementor (even 
if the RA stuff was dropped) I would not be keen to try and navigate 
this. Services which start up listening on IPv4 networks which suddenly 
have those networks yanked out from under them comes immediately to 
mind, but I haven't even started thinking hard about the problem(s) yet.

Third, this draft doesn't pass a simple laugh test. If you don't want 
IPv4 on your network, configure it away ... and you're done. There is no 
need for any of this.

Fourth, it doesn't pass the "stop tinkering with the protocol and let 
the installed base settle on a feature set" test.

Finally, and please pardon me for being brutally honest, this whole 
concept seems childish. When I saw the subject line I was deeply 
concerned that this was going to turn out to be a "We hate IPv4 so much 
we want a knob to make it go away" type of thing. As much as the authors 
may not have intended it that way, that's exactly how it reads.

So with all due respect to the authors, and the working group, this is a 
terrible idea, and the draft should be allowed to expire.

Doug

---

From: Fernando Gont <[email-masked]>
Date: Wed, 30 Apr 2014 04:46:49 -0300

On 04/30/2014 02:36 AM, Lorenzo Colitti wrote:
> On Wed, Apr 30, 2014 at 1:09 PM, Mikael Abrahamsson <[email-masked]
> <mailto:[email-masked]>> wrote:
> 
>     Nick, if you're not doing this today you're exposing your customers
>     to MITM attacks and all kinds of other bad things. What this
>     proposal is doing is adding one more reason to implement proper L2
>     security. You're already screwed, this mechanism just adds one more
>     way you're screwed.
> 
> 
> but happy eyeballs will protect you to some degree against blackholing,

Not necessarily. For instance, you can send an RA with RDNSS, and then
spoof DNS responses, and not even advertise a single A record.

Or spoof RAs and DHCP-server packets and advertise yourself as the
recursive DNS server.

Or just be very fast to respond to the IPv6-based SYN, such that IPv6
wins the HappyEyeballs race.

Cheers,
-- 
Fernando Gont
e-mail: [email-masked] || [email-masked]
PGP Fingerprint: 7809 84F5 322E 45C7 F1C9 3945 96EE A9EF D076 FFF1

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 30 Apr 2014 17:32:38 +0900

On Wed, Apr 30, 2014 at 4:46 PM, Fernando Gont <[email-masked]> wrote:

> Not necessarily.

[...]

Hence the words "to some degree". And really it depends on the HE
implementation. If it also races DNS queries and treats IPv4 and IPv6 like
ships in the night (i.e., tries all provisioning information from IPv4
consistently, and indipendently from all IPv6 provisioning information),
and if it over time blacklists source addresses or protocols that don't
work (like the Windows 8 implementation), then it won't be affected.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 30 Apr 2014 11:35:16 +0200

Hi Ted,

> Fernando's draft actually suggests filtering ethertype 0x86DD in order to avoid RA attacks on switches that don't have RA guard, which is why I assumed that that was an option for IPv4-only network…

Ouch, a solution like that would then increase the cost of deploying IPv6 later on. I agree it is effective to prevent (rogue) IPv6 stuff, but it would be a bit too effective for my taste.

Cheers :)
Sander

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 30 Apr 2014 12:04:24 +0200 (CEST)

On Wed, 30 Apr 2014, Sander Steffann wrote:

> Ouch, a solution like that would then increase the cost of deploying 
> IPv6 later on. I agree it is effective to prevent (rogue) IPv6 stuff, 
> but it would be a bit too effective for my taste.

Not really. I'd say if you are providing IPv4 service, then only allow 
IPv4 and ARP ethertypes. When you then provide IPv6 service, just allow 
that one as well. Network-wide change that can be done programatically.

---

From: Sander Steffann <[email-masked]>
Date: Wed, 30 Apr 2014 12:09:59 +0200

Hi Mikael,

> Network-wide change that can be done programatically.

I wish every network was as well-organised as the one you're working on ;)

Cheers,
Sander

---

From: Nick Hilliard <[email-masked]>
Date: Wed, 30 Apr 2014 12:29:26 +0100

On 30/04/2014 11:04, Mikael Abrahamsson wrote:
> as well. Network-wide change that can be done programatically.

if both the hardware and software support it.  As we're talking about
legacy stuff here, this may not be the case.

Nick

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Apr 2014 08:37:11 -0400

On Apr 30, 2014, at 4:25 AM, Doug Barton <[email-masked]> wrote:
> as others have pointed out this is layering violation of monumental proportions

Are you trolling me, Doug?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Apr 2014 08:38:39 -0400

On Apr 30, 2014, at 4:32 AM, Lorenzo Colitti <[email-masked]> wrote:
> Hence the words "to some degree". And really it depends on the HE implementation. If it also races DNS queries and treats IPv4 and IPv6 like ships in the night (i.e., tries all provisioning information from IPv4 consistently, and indipendently from all IPv6 provisioning information), and if it over time blacklists source addresses or protocols that don't work (like the Windows 8 implementation), then it won't be affected.

Hm, this is a good argument for treating IPv4 and IPv6 as separate provisioning domains in MIF.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Apr 2014 08:44:53 -0400

> Ouch, a solution like that would then increase the cost of deploying IPv6 later on. I agree it is effective to prevent (rogue) IPv6 stuff, but it would be a bit too effective for my taste.

Yup, I don't think the IETF should be recommending this.   That's why I abstained when the draft came up for IESG review.   RA guard is a much better solution; it's too bad that it (apparently) isn't universally available.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Wed, 30 Apr 2014 14:48:45 +0200 (CEST)

> legacy stuff here, this may not be the case.

I don't understand what part of my statement you object to. The 
programmatical change statement, the IPv4+ARP ethertypes solely being 
allowed, or something else?

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Apr 2014 08:50:15 -0400

> legacy stuff here, this may not be the case.

Clearly you have to stuff the configuration in somehow, unless the device doesn't support filtering by ethertype, in which case there's nothing to undo.

---

From: Fernando Gont <[email-masked]>
Date: Wed, 30 Apr 2014 12:04:29 -0300

On 04/30/2014 09:44 AM, Ted Lemon wrote:
>> Ouch, a solution like that would then increase the cost of
>> deploying IPv6 later on. I agree it is effective to prevent (rogue)
>> IPv6 stuff, but it would be a bit too effective for my taste.
> 
> Yup, I don't think the IETF should be recommending this.   That's why
> I abstained when the draft came up for IESG review.

FWIW, the draft doesn't recommend that. It discusses a problem, and
evaluates possible mitigations. There are trade-offs among them
(including whether you can cope with the implied risk, feasibility, etc.).

> RA guard is a
> much better solution; it's too bad that it (apparently) isn't
> universally available.

It's not just "availability", but also about quality of implementation.
-- hopefully RFC7113 will help in this latter area.

At the time we reported this to a few vendors years ago, they argued
that they would improve RA-Guard, because the right fix for these
problems was SEND...

That's when the folk needing to address these issues starts thinking
about employing whatever he has at hand...

Cheers,

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Apr 2014 11:13:11 -0400

> about employing whatever he has at hand...

To be clear, I'm not saying that what you said in the document is wrong, or that people shouldn't do it.   My argument with it is that the IETF shouldn't be the one saying it.   But I am in the rough on that.  Life goes on... :)

---

From: Doug Barton <[email-masked]>
Date: Wed, 30 Apr 2014 10:52:58 -0700

> Are you trolling me, Doug?

I'm not sure why you would say that, or why you would snip one phrase 
out of my entire e-mail to respond to and ignore all of the other 
arguments I made about why this draft is a bad idea.

Doug

---

From: joel jaeggli <[email-masked]>
Date: Wed, 30 Apr 2014 11:03:20 -0700

I think this discussion has served it's purpose with respect to review
of the no ipv4 draft.

We can go away an work on this.

Thanks
joel

---

From: Ted Lemon <[email-masked]>
Date: Wed, 30 Apr 2014 14:31:55 -0400

On Apr 30, 2014, at 1:52 PM, Doug Barton <[email-masked]> wrote:
> I'm not sure why you would say that, or why you would snip one phrase out of my entire e-mail to respond to and ignore all of the other arguments I made about why this draft is a bad idea.

The less said on this long, repetitive thread, the better.   The particular point I quoted was refuted early on and is utterly absurd.   Your other points have been addressed.   Please, can we stop talking about this and wait for the next version to be published?

---

From: Doug Barton <[email-masked]>
Date: Wed, 30 Apr 2014 12:01:24 -0700

On 04/30/2014 11:31 AM, Ted Lemon wrote:
>> I'm not sure why you would say that, or why you would snip one
>> phrase out of my entire e-mail to respond to and ignore all of the
>> other arguments I made about why this draft is a bad idea.
>
> The less said on this long, repetitive thread, the better.   The
> particular point I quoted was refuted early on and is utterly absurd.

I know that is your position. I, and others, disagree.

> Your other points have been addressed.   Please, can we stop talking
> about this and wait for the next version to be published?

Apparently my points have not been addressed adequately if another 
version of the draft is being considered. (And no, that's not a troll 
either.)

Doug