Subject: [homenet] Please review the No IPv4 draft

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

Dearest HOMENET,

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. Since home networks are among those likely
to see its use, reviews coming from HOMENET 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: Toke Høiland-Jørgensen <[email-masked]>
Date: Mon, 14 Apr 2014 17:19:23 +0200

> to see its use, reviews coming from HOMENET would be of tremendous

If I understand the draft correctly, a rogue user could completely
disable connectivity for all hosts on the local link, simply by sending
out a single RA message. Is that correct? (I am here thinking of the
case of an IPv4 only network where the real router is not including this
field in its DHCP/RA messages, but the clients understand it).

-Toke

---

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

> field in its DHCP/RA messages, but the clients understand it).

Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user
can already do this today without this extension.

Simon

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 15 Apr 2014 13:28:41 +0200

> can already do this today without this extension.

Right, to a certain extent that is true, of course; but not in the same
drive-by fashion where a single packet can put everyone offline (if the
option is not in the regular announcements).

Would it not be reasonable to add in a requirement that if a client has
already received a DHCPv4 lease (or more generally, has been configured
for IPv4 in some way), it will ignore requests to turn off the stack?

-Toke

---

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

> option is not in the regular announcements).

Sure it can. Just send them to a non-existing default gateway. Unless I
misunderstood your point.

> for IPv4 in some way), it will ignore requests to turn off the stack?

I'd be fine with that. Thanks for the idea!

Simon

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 15 Apr 2014 15:51:06 +0200

Simon Perreault <[email-masked]> writes:

> Sure it can. Just send them to a non-existing default gateway. Unless
> I misunderstood your point.

My point was that if you do this, the next time the real gateway sends
out an advertisement, connections are going to be restored. Whereas if
the gateway doesn't "speak" this option, all the hosts are just going to
shut down IPv4 and not come back up until someone realises this is what
happened.

> I'd be fine with that. Thanks for the idea!

Cool! :)

-Toke

---

From: Philip Homburg <[email-masked]>
Date: Tue, 15 Apr 2014 15:59:57 +0200

In your letter dated Tue, 15 Apr 2014 09:46:38 -0400 you wrote:
>Le 2014-04-15 07:28, Toke H=F8iland-J=F8rgensen a =E9crit :
>> =
>> =

Right now, on any network that doesn't do IPv6, sending RAs has marginal 
effect. Certainly traffic within the site would be unaffected if there are
no IPv6 addresses in DNS.

With an RA that kills IPv4, that changes dramatically. Sounds like something
no sane OS vendor would enable by default.

>From an OS perspective, I'd rather have this option in DHCPv4. That part
of the code knows about IPv4. Getting the IPv6 stack to tell the
IPv4 stack to shutdown is complicated and probably won't be implemented
until enough people bitch about it (and how stupid the IETF was) for quite
some time.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 15 Apr 2014 16:07:01 +0200

> that IPv4 is not available.

It seems to me that options relating to IPv4 don't belong in RA/DHCPv6
-- they belong in DHCPv4.  Having a degenerate DHCPv4 server that just
NAKs every request would appear to solve all of the problems in Section 3.
The main point is that having a dedicated DHCPv4-NAK-ing server avoids
the need to configure all IPv6 routers with IPv4-related information
-- a serious operational concern if you have many IPv6 routers on a single
link.

(To be fair, you might need a new DHCPv4 option that says "do not try
to contact any other DHCPv4 servers" to solve your problems 3.1/3.2.
But then, I'd like to see some operational experience that shows that it
is a problem in practice.)

-- Juliusz (who wishes people would stop dumping gazillions of unrelated
            options into existing protocols)

---

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

> option is not in the regular announcements).

This is a good point.   Given that this draft depends on IPv6 configuration that comes with lifetimes, it would make sense to specify that the no-ipv4 configuration information is only valid for the lifetime of the configuration message that delivered it—e.g., the prefix lifetime for RA, or the lease lifetime for DHCP, or for DHCP information-requests, the information refresh timer interval.   Since we're doing the IPv6 configuration protocol anyway, there's no damage done by continuing to rely on it to suppress IPv4 configuration.

> for IPv4 in some way), it will ignore requests to turn off the stack?

No, because this just leaves the client open to a different DoS attack.   If you have rogue configuration protocols running on your network, you need to fix it.   This just moves the problem around—it doesn't solve it.

One thing that I think would make this less likely to happen would be to state that no-ipv4 must be present on all valid configuration states received on a particular interface in order for no-ipv4 to be valid for that interface.   IOW, if you are getting rogue RAs that say "no IPv4" and also a non-rogue RA that doesn't say "no IPv4," the host assumes that IPv4 is permitted.   This prevents a rogue RA from killing IPv4 connectivity even for the lifetime of that RA.

Of course the downside to this is that if you have multiple advertisers on your link and they don't all agree, you lose, but again that's a configuration error that the admin can fix, and hence not something that needs to be addressed at a protocol level.

---

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

On Apr 15, 2014, at 9:07 AM, Juliusz Chroboczek <[email-masked]> wrote:
> Having a degenerate DHCPv4 server that just

Actually no, this would create packet storms.

---

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

> no sane OS vendor would enable by default.

You can do the same today with a rogue DHCPv4 server.

> IPv4 stack to shutdown is complicated

Please tell me how this is complicated:

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

For the systems I know, it would be trivial to implement. I could go and
submit a patch to NetworkManager today.

> and probably won't be implemented

This is an argument that always comes back with any proposal. I totally
disagree with it. Anyone could code this up and submit a patch to
Android. Then when the next release happens, bam, lots of support overnight.

Simon

---

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

> Actually no, this would create packet storms.

Correct, and just ignoring the requests would not make the clients shut
up either. They periodically wake up and see if IPv4 has become
available. There's no way to signal that IPv4 is not available.

Simon

---

From: Markus Stenberg <[email-masked]>
Date: Tue, 15 Apr 2014 18:28:53 +0300

> is a problem in practice.)

Disclaimer: I haven’t read the draft. I like the idea on high level, though. Certain not-quite-RFC-compliant DHCP clients send DISCOVER once every 3 seconds until end of the world. I’m not sure this would fix those, though.

NAK isn’t probably what you want (due to it’s semantics). However, OFFER that doesn’t really offer anything + magic option that says IPv4 is dead is what I’d want. 

I would rather see this than RA options as well; that way, the DHCP state machine (if any) can decide how long it honors this request not to do stuff. It also keeps v4 and v6 decoupled which actually makes life much easier in some implementations.

Cheers,

-Markus

---

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

> This is a good point.   Given that this draft depends on IPv6 configuration that comes with lifetimes, it would make sense to specify that the no-ipv4 configuration information is only valid for th…

Makes total sense. Will be added in the next revision.

(One could even argue that this is implicit with any information
received over DHCPv6 or RA, and that doing otherwise would be going
against design principles of those protocols.)

Thanks,
Simon

---

From: Toke Høiland-Jørgensen <[email-masked]>
Date: Tue, 15 Apr 2014 17:46:04 +0200

Ted Lemon <[email-masked]> writes:

> No, because this just leaves the client open to a different DoS
> attack. If you have rogue configuration protocols running on your
> network, you need to fix it. This just moves the problem around—it
> doesn't solve it.

Well, assuming this stays as an RA option and not a DHCPv4 one, I don't
think it will be unreasonable for someone running an IPv4-only network
to assume that they don't have to worry about IPv6 configuration
protocols disabling their IPv4. Having the exception that if IPv4
already works, don't disable it will make this assumption more likely to
be true.

As an example, consider a university campus network (or a conference
network) running IPv4 only, and someone broadcasting an RA packet onto
the open wireless. Suddenly everything goes offline and will stay that
way (until the RA expires) since no legitimate RAs come along to tell
hosts to turn IPv4 back on.

> One thing that I think would make this less likely to happen would be
> to state that no-ipv4 must be present on all valid configuration
> states received on a particular interface in order for no-ipv4 to be
> valid for that interface. IOW, if you are getting rogue RAs that say
> "no IPv4" and also a non-rogue RA that doesn't say "no IPv4," the host
> assumes that IPv4 is permitted. This prevents a rogue RA from killing
> IPv4 connectivity even for the lifetime of that RA.

I would definitely think it would be a good idea to have "option not
present" have the same semantics as "option set to allow ipv4".
Otherwise, those actually running dual-stack networks would have to
upgrade just to keep this from potentially causing problems.

-Toke

---

From: Philip Homburg <[email-masked]>
Date: Tue, 15 Apr 2014 17:48:10 +0200

>You can do the same today with a rogue DHCPv4 server.

No, you can't if the switches filter DHCP.

DHCP also has a completely different failure mode than RAs. To subvert
DHCP you have to wait for clients to send out DHCP discovers. For RA, you
just broadcast a couple of RAs.

A rogue DHCP server is annoying, but usually affects a few clients. A
rogue RA affects then entire subnet.

What you are doing is making IPv6 filtering mandatory on any network that
wants to do just IPv4.

>submit a patch to NetworkManager today.

Yes, and by the time this is fully configurable, you are talking about many
hundreds lines of code.

You are not going to just kill your DHCPv4 client each time you receive a
rogue RA. 

At least, not if you want people to use your OS.

>Android. Then when the next release happens, bam, lots of support overnight.

Yes, and all security consultants will have a field day either selling patches
to disable this or selling switches that can filter RAs.

With your proposed code (actually killing dhclient) any mistake means that
you have to reboot all systems in the affected LAN. Which means that
any serious vendor will spend a lot of code making sure that the DHCP
is only suspended for a couple of RA intervals, which leads to a way
more complex interaction.

---

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

> What you are doing is making IPv6 filtering mandatory on any network that

I see your point. But that's already necessary today. Remember the SLAAC
attack?

http://resources.infosecinstitute.com/slaac-attack/

When you have unfiltered L2 access, there are LOTS of evil things you
can do.

> Yes, and by the time this is fully configurable, you are talking about many

I completely disagree with your estimate.

> At least, not if you want people to use your OS.

Again: if there's an attacker with unfiltered L2 access to your host,
there are lots of things he can do today to DoS you.

> you have to reboot all systems in the affected LAN.

No, you can just re-send the No-IPv4 option with value 0. We added it
specifically to re-enable IPv4 when it has been previously disabled by
mistake.

And this is one advantage of using IPv6 for signalling the absence of
IPv4 service. If you use IPv4 instead, and you make a mistake, there's
no going back.

> Which means that

As discussed with Ted Lemon, the next revision will specify that the
No-IPv4 effect only lasts for the lifetime of DHCPv6 or RA.

Simon

---

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

> Makes total sense. Will be added in the next revision.

What about the other part?

I think it works with the use model you have in mind: if you want some devices to do IPv4 and others not, you can advertise "no IPv4" in the RA, and send "no IPv4" by default in DHCP information requests, but send nothing to clients that you want to use IPv4, and then the attack-rejection heuristic I proposed would result in those clients using IPv4.

---

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

> hosts to turn IPv4 back on.

Hm, okay, I guess that in order to address that use case you do need to have a DHCPOFFER override an IPv6 "no IPv4" advertisement.   However, this still creates a timing race during which an attack could occur.   So I think that if you really want to prevent IPv4 being shut off on an IPv4-only network by an RA, you really need to have your own RA going out that offers no prefixes and doesn't say "no IPv4" or else you need to filter IPv6 at layer 2 (which I tend to think is a really bad idea, since it prevents ad-hoc link-local use of IPv6).

---

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

Sorry, missed an important part. Replying in full.

> One thing that I think would make this less likely to happen would be to state that no-ipv4 must be present on all valid configuration states received on a particular interface in order for no-ipv4…

So that means if you're running DHCPv6, and assuming you use RAs for
provisioning at least the default gateway, you need to put the No-IPv4
option in both RA and DHCPv6. If we specify that then we could just kill
the DHCPv6 option since it would then be useless.

> Of course the downside to this is that if you have multiple advertisers on your link and they don't all agree, you lose, but again that's a configuration error that the admin can fix, and hence not…

Agreed.

Simon

---

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

> I completely disagree with your estimate.

I think you are talking apples and oranges.   Simon, you are assuming a functional configuration environment; in such an environment, the change would be fairly trivial.   Philip, I think you are assuming the current status quo on linux, which is badly broken and requires massive amounts of work to make small changes.   In that context, it probably is hundreds of lines of code.

But that really needs to get fixed regardless of the outcome of this discussion.

---

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

> the DHCPv6 option since it would then be useless.

No, the DHCPv6 option is useful for selectively enabling IPv4.

---

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

> No, the DHCPv6 option is useful for selectively enabling IPv4. 

Wait wait wait. If I get what you mean:

- RAs would always contain No-IPv4.
- DHCPv6 would selectively contain No-IPv4 or not.

Is that correct?

It can work. But it's sooo ugly! And I can just imagine the headaches it
could cause to a sysadmin trying to troubleshoot a connectivity issue...

Simon

---

From: Philip Homburg <[email-masked]>
Date: Tue, 15 Apr 2014 18:34:36 +0200

>When you have unfiltered L2 access, there are LOTS of evil things you

The world is not black and white. Rogue RAs are easy for hit and run attacks.

Maybe I should already create 'ipv4begone'. Would be a nice way to reserve
the wireless for yourself in busy wifi networks.

In contract MITM attacks are much harder to pull off. Any don't really 
gain much compared to just sniffing the wifi.

>specifically to re-enable IPv4 when it has been previously disabled by

So now, any RA daemon also has to know to start dhclient. So it is more than
just your oneliner.

>IPv4 service. If you use IPv4 instead, and you make a mistake, there's

Not if you just suspend DHCP operation for a while...

>No-IPv4 effect only lasts for the lifetime of DHCPv6 or RA.

Similar to what you describe here.

There is of course an easy way out. Let this run its course and then write
an informational RFC that allocates the required option for DHCPv4. More
choices are always better...

Let the OS vendors decide.

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Apr 2014 12:43:06 -0400

I think it's important to read the draft, and understand section 5.3,
about the "v4-level".

I think that the security implications in the document are understood by the
authors, but simply not spelled out yet.

I think that some additional text in 5.3 might help make it
clearer that there might be competing v4-labels coming from different
routers/DHCPv6 servers, and that really the one with the lowest value wins.

Hosts that don't understand this option will continue to behave as if the
option did not occur, and any device for which this option is implemented
needs to think about how much credence they will put into it.

--
]               Never tell me the odds!                 | ipv6 mesh networks [
]   Michael Richardson, Sandelman Software Works        | network architect  [
]     [email-masked]  http://www.sandelman.ca/        |   ruby on rails    [

---

From: Philip Homburg <[email-masked]>
Date: Tue, 15 Apr 2014 18:47:03 +0200

In your letter dated Tue, 15 Apr 2014 11:24:31 -0500 you wrote:
>I think you are talking apples and oranges.   Simon, you are assuming a functio
>nal configuration environment; in such an environment, the change would be fair
>ly trivial.   Philip, I think you are assuming the current status quo on linux,
> which is badly broken and requires massive amounts of work to make small chang
>es.   In that context, it probably is hundreds of lines of code.
>

I'm also thinking about the code base for an embedded system I maintain.

And I can really do without more complex interactions between IPv6 and IPv4.

Adding an IPv4 suspend option to DHCPv4, that's easy. 

Doing the same thing from IPv6 is a nightmare. 

In any system that does DHCPv4, suspending IPv4 for a while is a purely local
interaction with the DHCPc4 client. If you implement it for the most common
DHCPv4 clients, you can probably get it implemented in little time.

On the other hand, if you need have RAs signal suspend and resume of IPv4
you are looking at rewriting the management code of lots of different Linux
distibutions (including various embedded ones) and many operating systems.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Tue, 15 Apr 2014 18:51:32 +0200

> > Having a degenerate DHCPv4 server that just NAKs every request
> > would appear to solve all of the problems in Section 3.

> Actually no, this would create packet storms.

My bad -- I didn't actually check.

So either an empty OFFER, as suggested by Markus, or an OFFER with
a new *DHCPv4* option.

-- Juliusz

---

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

> could cause to a sysadmin trying to troubleshoot a connectivity issue...

Sure, but imagine the headaches of a sysadmin trying to figure out why IPv4 isn't working if we don't do it this way.

---

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

> distibutions (including various embedded ones) and many operating systems.

Yes.   That will be a really good outcome.

I'm sorry, but I have no sympathy for your protestations about DHCPv4 clients in embedded applications.   If it's an RPi, you can run a full-featured DHCPv4/DHCPv6 implementation that works, so there's no excuse for running one that doesn't.   If it's a tiny sensor, you want to use 6lowpan anyway, so you're not running DHCPv4 _or_ DHCPv6.   And you also always have the option of just ignoring the option if you are implementing something that really is an edge case.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 15 Apr 2014 19:29:47 +0200

>Yes.   That will be a really good outcome.

You really think people are going to rewrite Linux network config for some
weird edge case?

>I'm sorry, but I have no sympathy for your protestations about DHCPv4 clients i
>n embedded applications.   If it's an RPi, you can run a full-featured DHCPv4/D
>HCPv6 implementation that works, so there's no excuse for running one that does
>n't.   If it's a tiny sensor, you want to use 6lowpan anyway, so you're not run
>ning DHCPv4 _or_ DHCPv6.   And you also always have the option of just ignoring
> the option if you are implementing something that really is an edge case.

Then you don't.

I'm only saying that from my perspective, changing DHCPv4 is the best 
technical solution.

Now of course, the IETF can pick the option that requires serious changes in
many operating systems, creates very interesting attacks, etc. Then that's
just too bad. 

Note, this is an edge case. Operating systems hardly benefit from this option,
but they will get the full load of any security issues.

So my guess is that staying on the RA/DHCPv6 route will just seriously
delay the implementation of this option.

---

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

> You really think people are going to rewrite Linux network config for some

People are rewriting Linux the network configuration system as we speak.   This particular edge case is just one example of why it's broken.   So yes, I agree that if this were the only reason to do the work, it would never happen, but since it's happening already, I think that's moot.

> I'm only saying that from my perspective, changing DHCPv4 is the best 

Right, but you haven't given a technical argument to support that.   You've just said that it's convenient in a particular existing implementation, which is not in wide use, and which is already undergoing changes that will coincidentally make addressing this less inconvenient.  So this isn't a good argument.

> delay the implementation of this option.

On Linux.   If neither systemd nor dnsmasq nor one of their replacements actually becomes popular (although dnsmasq is already popular in embedded environments).   I agree with this, if you accept the caveats I just added, but I don't think it's a big problem.

---

From: Philip Homburg <[email-masked]>
Date: Tue, 15 Apr 2014 23:51:26 +0200

In your letter dated Tue, 15 Apr 2014 13:20:19 -0500 you wrote:
>Right, but you haven't given a technical argument to support that.   
>You've just said that it's convenient in a particular existing 
>implementation, which is not in wide use, and which is already 
>undergoing changes that will coincidentally make addressing this less 
>inconvenient.  So this isn't a good argument.

Please describe how in OSX, OpenWRT, FreeBSD, Android, IOS, the various
Windows version gracefully starting and stopping IPv4 from an RA works?

Oh, maybe give one example of a documented clean architecture that can
handle this including every possible boundary condition. 

In contrast, having a DHCPv4 client stop sending DISCOVERs upon reception of 
a particular reply packet is almost a no brainer. 

I guess you don't see this as a technical argument, so be it.

If you think that introducing network protocol changes that can only be handled
by a widely used OS by rewriting their network config is a good idea when
there is an alternative the can be implemented cleanly today, then there
is no point further arguing.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 16 Apr 2014 01:55:48 +0200

> Right, but you haven't given a technical argument to support that.

You're being somewhat disingeneous here, Ted.

We're arguing that information about IPv4 availability should not be
carried by IPv6 RAs, since it avoids a number of very unpleasant
incestuous interactions.  That is most certainly a "technical" argument,
however you care to define this particular term.

Keeping the two stacks cleanly separated has a number of practical
("technical"?) advantages:

  - in modular operating systems (not only Linux), this avoids dodgy
    interactions between separate daemons;
  - administrators can debug IPv4 issues without having to delve into
    the IPv6 configuration, and vice versa;
  - once (if?) IPv4 is phased out, we won't need to carry obsolete
    IPv4-related options within the IPv6 protocols.

-- Juliusz

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Apr 2014 10:28:51 +1000

> Windows version gracefully starting and stopping IPv4 from an RA works?

They write code.

There is already userland code that reacts to RA flags in FreeBSD
to start dhcpv6.  It's not hard to add yet another callback to
stop/start dhcpv4.  I suspect if I sat down to do this I could do
code it in a day.  This is not rocket science.  I could do it from
scratch with raw sockets in just about as much time.  I just need
to be able to see the RA's and know what interface they arrived on.

I have code in nameservers that listens for interface changes on
routing sockets and adjusts manages the sockets that the nameserver
listens on.  That took well under a day to write from scratch and
is about as complicated.  This is not hard to implement.

I would presume the others are roughly the same when you have access
to the development trees.

> _______________________________________________
> homenet mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/homenet
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742                 INTERNET: [email-masked]

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Apr 2014 20:55:19 -0400

Honestly, the decoupling of Wifi, IPv4 and IPv6 address configuration in
Linux, OpenWRT, and FreeBSD is really a mistake, and it's gotta stop.
It's a bug, not a feature.

I left out OSX, Android, IOS and Windows from your list on purpose.

My understanding is that OSX and IOS actually already do extensive coupling
of layer-2 and layer-3 configurations, such that one can actually do things
like recognize that the the layer-3 network configuration(s) on a particular
ESSID is broken, and pick another ESSID.

I know that there are interactions between IPv4 and IPv6 configurations on
Windows *ALREADY*, but I can't give you the details.

As for Android, as someone who has been deep into the code, there is so
little IPv6 code in there at all, there isn't really anything to replace.

There are multiple ways to couple things sensibly.
On OpenWRT, dnsmasq is pretty much doing it all already.
On Linux desktops, dbus and NetworkManager is there. Many don't like NM, but
it's getting better.

So that leaves FreeBSD.
Remember: you don't have to implement this.  Where it matters most is on home
routers; where failing to turn off IPv4/recognize there-is-none, results in
being on an IPv4 NOTwork.

{I didn't buy the argument that people doing IPv6 didn't want to run IPv4
DHCP, at first, but slowly I've gotten to understand the numerous layer-2 and
layer-3 savings by not having to have the whole DHCPv4 relay and broadcast
processing occuring. DHCPv4 is not a young protocol...}

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

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 16 Apr 2014 02:59:57 +0200

> slowly I've gotten to understand the numerous layer-2 and layer-3
> savings by not having to have the whole DHCPv4 relay and broadcast
> processing occuring.

Could you please explain that?  Perhaps with some examples, or even
actual empirical data?

-- Juliusz

---

From: Michael Richardson <[email-masked]>
Date: Tue, 15 Apr 2014 22:40:59 -0400

> Could you please explain that?  Perhaps with some examples, or even

I'm not a large scale residential ISP, and I've never played one on TV, but
I've operated niche ISPs since 1991,  and recently installed a few medium
sized business oriented DSL, Fiber and GPONs.  GPONs are odd.

I refer you to the sunset4 mailing list archives, but let me see what I recall.

1) Let's start with PPPoE/DSL
   No DHCPv4 server for IPv4, it's all done in PPP.
   So you'd have to have a DHCP server somehow, or a new PPP option.

2) Cable/FTTH using ethernet-type things.
   You need code (silicon actually, at FTTH speeds) to police DHCP traffic
   coming from each customer to make sure that they aren't running a rogue
   DHCPv4 server.
   That's something you can get rid of if you aren't running v4.
   You need to have DHCPv4 relay agents in each of your cable head ends,
   and they need to add option-82 to indicate where things are coming from.

   You'd like to turn off layer-2 broadcasts (ff:ff:ff:ff:ff:ff) because
   there is just a huge amount of noise coming from the customer machines,
   but you can't just do that because the DHCPv4 uses that, and you've
   got multiple layers of fiber backhauled cable modem.
   There is a significant ARP load on the network from every single box
   where 0.0.0.0/0->"eth0" because the network isn't configured yet.
   (Every single directly connected windows box does this, and some distros
   of Linux do this. I was surprised to learn it's allowed...)

   The broadcasts have actually forced you to subnet your IPv4 down into
   rather small pieces to contain it, and this has lead to uneven
   provisioning of IPv4 address space, and you've effectively run out.
   (Also see the history behind ARIN
   https://www.arin.net/policy/proposals/2012_7.html and
   http://www.crtc.gc.ca/eng/archive/2012/2012-96.htm might also be relevant)

   If you could turn off broadcasts, you could forward just the multicast you
   need (DHCPv6, RA..) which would significantly help reduce the MAC address
   load on much layer-2 equipment.  Moreso, it's pretty much all P2MP
   traffic, so perhaps a much simpler layer-2 forwarding system could be
   used. (I don't have such a thing; legacy layer-3 assumptions wouldn't let
   anyone create such a thing yet)

And again: if it's too hard, don't implement it (certainly not in open
source, for free), thousands of devices will never get updated to have it anyway.

---

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

> You're being somewhat disingeneous here, Ted.

No, I'm really not.

> however you care to define this particular term.

It's not a valid technical objection.   The working group thought about the question, came to a conclusion, which is not the one you are advocating, and you haven't said anything that indicates that their conclusion was wrong, because they considered the solution you are proposing and decided that a different solution was better.

A technical objection is "this won't work because FOO."   What is FOO?

---

From: Ray Hunter <[email-masked]>
Date: Wed, 16 Apr 2014 08:48:50 +0200

The alternative scenarios and management models for sunsetting do not 
seem to have been discussed: e.g.

1) allow a customer to run their own home router and control their own 
broadcast traffic and multicast traffic. With IPv6 there's no reason why 
stacked routers are harmful, because there's no NAT going on
2) ISP to provide an additional IPv6 only CPE router at the perimeter of 
the L2 broadcast network, again to limit the broadcast domain
3) to filter using MAC + DHCPv4 black hole addresses
4) to use an out of band management protocol such as active directory to 
turn off IPv4 in the kernel
5) to request users manual disable IPv4 when contracting the new IPv6 
only service
6) tolerate the noise and let IPv4 die a natural death
7) provide separate logical networks for IPv6 only users and legacy IPv4 
users
8) allow IPv4 to exist as individual disconnected islands

Michael Richardson wrote:
> <snip>
> Michael Richardson<[email-masked]>, Sandelman Software Works

That's rather disingenuous.

The justification for this solution seems to be based on a very myopic 
view of the Internet.

What may happen is that something like this may be implemented (because 
it's good for the particular ISPs that heavily rely on large L2 
networks) whereas it does not benefit people who route everything (other 
ISP's and enterprises or home users who manage their own routers and 
thus broadcast domain.)

Large and small enterprises will then have to scramble to filter rogue 
IPv6 DHCPv6 servers, even if they aren't running IPv6 yet internally on 
their networks, and their switches are probably too old to support RA 
Guard. They'll also want a kill switch on the kill switch in the OS. 
'shutdown -h now' as a DHCPv6 option? That's effectively what's being 
proposed AFAICS.

Why can't I continue to run IPv4 in the privacy of my own home (as an 
Island)? RFC 6724 will ensure that IPv6 is preferred for all off site 
traffic.

-- 
Regards,
RayH

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Apr 2014 10:19:30 +0200

>   So you'd have to have a DHCP server somehow, or a new PPP option.

Maybe this is very the scope got overly broad.

There is an easy way to signal the lack of IPv4 on PPP: just don't do IPCP.

Note that signalling the lack of IPv4 in DHCPv6 over ppp when the CPE already
started handing out rfc-1918 address by DHCP leads to very confusing
interactions.

>   anyone create such a thing yet)

So the options are
- - Just drop all ethernet broadcasts. They are not needed for IPv6 anyhow.
  problem solved.
- - Give them IPv4 addresses without default routes. That clearly signals lack of
  IPv4 connectivity beyond the local subnet.
- - Implement a DHCPv4 option that asks the DHCPv4 to not configure a link local
  address. That kills all ARP traffic and reduces DHCP traffic (though not
  configuring link local is less ideal from an security point of view)
- - Redesign how ethernet broadcast works in those networks. I.e. treat ethernet
  broadcast as a special mac that needs to be routed towards the core. 
  Problem solved.

In any case, all these try to solve the problems directly instead of the
rounabout way of using IPv6 to signal lack IPv4.

---

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

On Wed, Apr 16, 2014 at 2:09 AM, Ted Lemon <[email-masked]> wrote:

> I'm sorry, but I have no sympathy for your protestations about DHCPv4
> clients in embedded applications.   If it's an RPi, you can run a
> full-featured DHCPv4/DHCPv6 implementation that works, so there's no excuse
> for running one that doesn't.
>

Ted, I think you'll have to accept that Philip's assessment of how much
work has to be done on his platform is accurate, since he's the one writing
that code.

We've had this discussion many times on many different drafts, and every
time the conclusions from the implementers (and of course, not from the
standards writers) was that tying together the state machines from
different protocol provisioning mechanisms was brittle and a lot of work.

An excellent example is provided by the CPE RFCs, 6204/7084, which
explicitly ignore the M and O bits and go out of their way to specify that
the DHCPv6 state machine and RA processing parts of the code can be
separate and run as ships in the night. That was based on extensive
feedback from implementers, who pushed back hard against any sort of
requirement to tie multple provisioning protocols together.

You're free to say that the "many different provisioning daemons" model
used by Linux and many CPEs is junk and that the multi-process model will
be replaced by monolithic system configuration daemons, but bear in mind
that that's not the current state of affairs in the real world.

The IETF is always free to come to consensus on the option that's hard to
implement. Unfortunately what typically happens after that is that it
doesn't get implemented.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Apr 2014 10:55:47 +0200

>to be able to see the RA's and know what interface they arrived on.

Does that include all edge cases and the user interface?

I.e. DHCPv4 has configured an address and by mistake a RA orders IPv4 to be
shutdown. Do you just shutdown IPv4? Does your code parse the output of
ifconfig to figure out if the interface was configured?

The user doesn't want this to happen on a production IPv4 network. Where in
the FreeBSD admin interface do you put the option to disable this behavior?

An admin has stopped DHCPv4, now an RA comes along with the option to start
IPv4. Does your code just start DHPv4 or does it know that an admin took it 
down?

Just a few the came to mind. I'm sure that when this is taken into production
there will be many more. And many confused admins who don't understand why 
DHCPv4 is suddenly starting or stopping.

In contrast a DHCPNOSERVICE message that just suspends sending DHCPDISCOVER
messages for a while has almost no impact. It gets slightly trickier if
that also implies no link local, but not much.

---

From: Mark Andrews <[email-masked]>
Date: Wed, 16 Apr 2014 20:13:45 +1000

> ifconfig to figure out if the interface was configured?

Yes. Why not as it been told it is allowed to shutdown IPv4 in the interface?
 
> the FreeBSD admin interface do you put the option to disable this behavior?

Given we are taking about FreeBSD /etc/rc.conf it would be
ifconfig_ed0_ranoipv4="NO" in there with the default in
/etc/defaults/rc.conf ifconfig_ed0_ranoipv4="YES" possibly commented
out.

> IPv4. Does your code just start DHPv4 or does it know that an admin took it 

More correctly it was told to start IPv4 and yes.  The admin should
have temporarially disabled processing of the option if he didn't
want ipv4 restarted.  It is not uncommon for functions to auto
start.

If I fiddle with /etc/resolv.conf DHCP will re-write it on the
next renew.  This is similar.

> DHCPv4 is suddenly starting or stopping.

Only because it is new.  Once it is known about there won't be much
confusion.
 
> that also implies no link local, but not much. 

And doesn't achieve the intent of turning off IPv4 for the interface
when you are not configuring using DHCP.

Mark

---

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

Le 2014-04-16 04:44, Lorenzo Colitti a écrit :
>     I'm sorry, but I have no sympathy for your protestations about
>     DHCPv4 clients in embedded applications.   If it's an RPi, you can
>     run a full-featured DHCPv4/DHCPv6 implementation that works, so
>     there's no excuse for running one that doesn't.
> 
> 
> work has to be done on his platform is accurate, since he's the one
> writing that code.

On his platform, sure. On all the platforms I know, it would be trivial.

> different protocol provisioning mechanisms was brittle and a lot of work.

They are already tied together on many platforms. NetworkManager,
systemd, Android, Mac, Windows, etc. /etc/rc.d/dhclient is dead. And
that's a good thing.

Simon

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Apr 2014 09:07:46 -0400

{I would love a description from Apple and Microsoft of how their
layer-2/layer-3 address discovery/configurartion systems already interact}

    > ifconfig to figure out if the interface was configured?

No, and no.

The order is not to shutdown v4.  The suggestion is to stop DHCPv4, if it
hasn't succeeded, and assume that there isn't any IPv4 for any downstream
devices.

Ideally the device will not announce an IPv4 default route if it hasn't got
one itself. If the admin has manually configured IPv4, then there is no issue.
What the ISP wants to prevent is barages of DHCPv4 broadcasts, and what the
homenet situation wants is to avoid offering an IPv4 default route when it
won't work.

    > In contrast a DHCPNOSERVICE message that just suspends sending
    > DHCPDISCOVER messages for a while has almost no impact. It gets
    > slightly trickier if

It's not that there isn't v4, it's that there isn't DHCPv4.
I personally think that both should actually exist.

---

From: Philip Homburg <[email-masked]>
Date: Wed, 16 Apr 2014 15:37:45 +0200

>hasn't succeeded, and assume that there isn't any IPv4 for any downstream

(This was in the context of FreeBSD.)

One option: the DHCPv4 client has an option to shutdown unless it already
obtained a lease. Probably requires allocating a signal, changes to the
DHCPv4 client, etc.

Otherwise, what happens if you kill a DHCPv4 client when it has a lease?
- A hard kill (-9) and the address remains installed even when the lease
  expires. Not good.
- (Unlikely) A hard kill and the kernel knows about the lifetime of the lease
  and deletes the address when it expires. This one would be really great to
  debug. Send one 'ipv4begone' packet and hour later the admin goes crazy.
- A soft kill (say TERM) and DHCPv4 removes the address before shutting down.
  Nice immediate DoS on IPv4.

Alternative, ifconfig $interface | grep 'inet '...
Ugly.

And unless all of this is spelled out in the RFC in extreme detail, I can
already see the presentations in a couple of years: we sent one 'ipv4begone'
packet and this is the kind of fireworks you get in the various operating
systems.

Somebody might just go ahead and implement
'grep "option no-ipv4" /var/db/dhclient6.leases.eth0 && pkill dhclient'
...

---

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

Le 2014-04-16 09:07, Michael Richardson a écrit :
> one itself.

The fact is that all CPE routers today do announce an IPv4 default route
to the LAN irrespective of their WAN connectivity status. And there's no
reason to think that this will ever change.

Simon

---

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

> systemd, Android, Mac, Windows, etc. /etc/rc.d/dhclient is dead. And

Not Android.

---

From: joel jaeggli <[email-masked]>
Date: Wed, 16 Apr 2014 07:54:06 -0700

> reason to think that this will ever change.

ipv4 cpe using rfc 1497/2132 option 3 are not announcing a default
route, they are indicating that they are a router, the client installs
the default route.

---

From: Simon Perreault <[email-masked]>
Date: Wed, 16 Apr 2014 11:03:05 -0400

Le 2014-04-16 10:52, Lorenzo Colitti a écrit :
> On Wed, Apr 16, 2014 at 9:49 PM, Simon Perreault
> <[email-masked] <mailto:[email-masked]>> wrote:
> 

You're right, my mistake.

Simon

---

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

> Not Android. 

I thought Android used dnsmasq.

---

From: Simon Kelley <[email-masked]>
Date: Wed, 16 Apr 2014 17:25:10 +0100

> I thought Android used dnsmasq.

Android uses dhcpcd as its DHCP client. Dnsmasq is used as DHCP and DNS
_server_ for wireless and USB tethering. It has nothing to do with the
Android DHCP client behaviour.

Simon.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 16 Apr 2014 20:31:44 +0200

>> Could you please explain that?

> let me see what I recall...

That's interesting, especially the FTTH case.  Thanks for the info.

-- Juliusz

---

From: Simon Kelley <[email-masked]>
Date: Wed, 16 Apr 2014 19:56:14 +0100

I've not had time to review the whole thread, so apologies if this has
been covered elsewhere.

It occurs to me that one scenario that needs to considered is when a
machine moves from a network which wants to suppress IPv4 to one which
is still providing IPv4 (possibly only IPV4).

To make that work implies that the DHCPv4 client should still exist in
the IPv4-suppressed state, doing nothing except looking for loss of
ethernet carrier or change of wireless ESSID, at which time is should
try again to get a DHCPv4 lease.

However this is implemented, just killing the DHCP client is not going
to cut it.

My personal feeling is that suppressing IPv4 should be a a DHCPv4
function, that keeps the go-into-hibernation transition solely in the
DHCPv4 code, it also means the when IPv4 support finally goes, so does
the transition mechanism.

Simon.

---

From: Juliusz Chroboczek <[email-masked]>
Date: Wed, 16 Apr 2014 22:17:30 +0200

> A technical objection is "this won't work because FOO."

`I meant "there's a nice knock-down argument for you!"'

`But "glory" doesn't mean "a nice knock-down argument,"' Alice objected.

`When I use a word,' Humpty Dumpty said in rather a scornful tone, `it
means just what I choose it to mean -- neither more nor less.'

`The question is,' said Alice, `whether you can make words mean so many
different things.'

`The question is,' said Humpty Dumpty, `which is to be master -- that's
all.'

-- Juliusz

---

From: Mark Andrews <[email-masked]>
Date: Thu, 17 Apr 2014 08:12:41 +1000

> hasn't succeeded, and assume that there isn't any IPv4 for any downstream

With the currently defined states yes you shut down everything for 1 and
3.  You don't shutdown for 0 and 2.  I think some here want a currently
undefined state, no dhcp but local connectivity.

I would switch 1 and 2 around so that you go from most (0) to least (3)
IPv4 support on the interface.

Currently it is:

	0 full IPv4 connectivity
	1 all IPv4 off on the interface
	2 local (link/site not global) connectivity only on the interface
	3 no IPv4 on the machine.

For 1 and 3 you remove all addressing on the interface in question.

For 2 you leave DHCP running.  It would be wise to not have default
routes being announced by the DHCP server.  Link-local may be in use
if there isn't a DHCP server.

I suspect that we may want a 5th state.  No DHCP, local connectivity.
That is split 2 into with and without DHCP.
 
> --=-=-=
> Content-Type: application/pgp-signature
> 
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.12 (GNU/Linux)
> 
> iQCVAwUBU06AooqHRg3pndX9AQINOQP/VRDO9bg6WYo3GZfPFe8kcrpMQ/pgn5rx
> R3iPe0+1P/KlFFr2QSlizUjMCyn4Kuo+vweRd7G+FTgrj/+xI988uxuNZ41hjNxt
> IUuyj7e+2jBfqPgTGSY36lGGWZ+VZA36GDa4pihqz0Htybq15A3kTC5ereGvJ7Ke
> ODvLKf35i5k=
> =jnPY
> -----END PGP SIGNATURE-----
> --=-=-=--
> 
> 
> --===============1429064588242792841==
> Content-Type: text/plain; charset="us-ascii"
> MIME-Version: 1.0
> Content-Transfer-Encoding: 7bit
> Content-Disposition: inline
> 
> --===============1429064588242792841==--
>

---

From: Michael Richardson <[email-masked]>
Date: Wed, 16 Apr 2014 21:02:27 -0400

> IPv4 support on the interface.

I agree.

    > For 1 and 3 you remove all addressing on the interface in question.

It's just that no DHCP (v4 or v6) server has really any clue about what
should happen on the *machine*.  It might have many other interfaces.

There might also be other DHCP* servers on that interface, and some of them
might not be spoofed!

---

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

> the transition mechanism.

What he said. (And of course, he's one of the people actually implementing
this stuff, too.)

---

From: <[email-masked]>
Date: Thu, 17 Apr 2014 15:55:41 +0200

Dear Michael, all,

Please see inline.

Cheers,
Med

>-----Message d'origine-----
>De : homenet [mailto:[email-masked]] De la part de Michael
>Richardson
>Envoyé : mercredi 16 avril 2014 15:08
>À : [email-masked]
>Objet : Re: [homenet] Please review the No IPv4 draft
>
>

[Med] This is not a valid generic statement. Consider the DS-Lite model (RFC6333): there is no dhcpv4 client in the CPE at all + no assigned IPv4 address in the wan side, but still IPv4 connectivity is offered to connected hosts. DHCPv4 client is disabled when the CPE detects it is attaching the network using DS-Lite. The no-dhcpv4 explicit signal is not required for this case for example.

---

From: Simon Perreault <[email-masked]>
Date: Thu, 17 Apr 2014 10:22:13 -0400

> 	3 no IPv4 on the machine.

Uh, no. The levels are in strictly increasing order. 2 includes
everything in 1, plus some more:

   2 - No IPv4 upstream, local IPv4 restricted:  Same semantics as value
      1, with the following additions:

2 deals with propagation to downstream interfaces. It has nothing to do
with link or site local stuff.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Thu, 17 Apr 2014 10:24:28 -0400

Le 2014-04-16 12:25, Simon Kelley a écrit :
> Android uses dhcpcd as its DHCP client.

Thought about this some more... Doesn't dhcpcd implement everything in a
single daemon? i.e., DHCPv4, DHCPv4, IPv4LL, IPv6 RS? If so, then it
would be easy for one protocol to affect another, wouldn't it?

Simon

---

From: Michael Richardson <[email-masked]>
Date: Thu, 17 Apr 2014 15:06:38 -0400

> [Med] This is not a valid generic statement. Consider the DS-Lite model
    > (RFC6333): there is no dhcpv4 client in the CPE at all + no assigned
    > IPv4 address in the wan side, but still IPv4 connectivity is offered to
    > connected hosts. DHCPv4 client is disabled when the CPE detects it is
    > attaching the network using DS-Lite. The no-dhcpv4 explicit signal is
    > not required for this case for example.

The device still has an default IPv4 route.

---

From: Mark Andrews <[email-masked]>
Date: Fri, 18 Apr 2014 07:14:37 +1000

In message <[email-masked]>, Simon Perreault writes:
> Le 2014-04-16 18:12, Mark Andrews a =E9crit :

Part of the problem here is that "upstream" is the only "interface"
for singlely attached devices other than loopback.  There is no
"only local connectivity is available" step for such nodes.

   0 - IPv4 fully enabled:  This is equivalent to the absence of the No-
      IPv4 option.  It is included here so that a DHCPv6 server can
      explicitly re-enable IPv4 access by including it in a Reply
      message following a Reconfigure, or similarly by a router in a
      spontaneous Router Advertisement.

   1 - No IPv4 upstream:  Any kind of IPv4 connectivity is unavailable
      on the link on which the option is received.  Therefore, any
      attempts to provision IPv4 by the host or to use IPv4 in any
      fashion, on that link, will be useless.  IPv4 MAY be dropped,
      blocked, or otherwise ignored on that link.

Mark

> -- =

---

From: Alejandro Acosta <[email-masked]>
Date: Thu, 17 Apr 2014 22:16:19 -0430

Hi,
  Nice idea & draft.

  I like the idea of having the No-IPv4 option for DHCPv6. I don't like
the idea of having this option in a v4 world; mainly because in mix
networks where you might have some folks which only speak IPv4, imagine
a case where this option is sent by a DHCPv4 to a client who do not
understand v6. Of course, probably the client won't understand the
option and won't turn off IPv4. There is also the chance that this is a
modern OS but for some reason IPv6 was disable in the host, yes, it will
understand the option No-VP6 (sent by a dhcp4).
  Last but not least, following this thread some of you mentioned
filtering (RA, DHCP OFFER) in the switch can prevent some unwanted
situations.., there are also other networks that are switch-less.

Regards,

Alejandro Acosta,

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Apr 2014 12:49:07 +0900

> would be easy for one protocol to affect another, wouldn't it?

In practice, you can't use dhcpcd for autoconf because it doesn't support
privacy addresses or removing the default route when the RA lifetime
expires. (Or at least, the 6.3.2 version I downloaded today and ran on
Debian stable didn't seem to support this).

So you still need to run kernel autoconf, at which point you might as well
disable dhdpcd's RS processing since you probably don't want both the
kernel and dhcpcd to be running autoconf.

---

From: Philip Homburg <[email-masked]>
Date: Fri, 18 Apr 2014 09:58:14 +0200

>understand the option No-VP6 (sent by a dhcp4).

As far as I understand, this draft addresses the situation where the network
doesn't offer IPv4 in the first place.

So any IPv4-only host would have no internet connectivity anyhow, whether it
processes the option or not.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 18 Apr 2014 08:48:39 -0400

> "only local connectivity is available" step for such nodes.

Correct. For such nodes, 1 == 2. Is that a problem? It's still a
stairway going up, with steps 1 and 2 being at the same height for a
subset of nodes.

Simon

---

From: Simon Perreault <[email-masked]>
Date: Fri, 18 Apr 2014 08:51:08 -0400

Le 2014-04-17 23:49, Lorenzo Colitti a écrit :
> On Thu, Apr 17, 2014 at 11:24 PM, Simon Perreault
> In practice, you can't use dhcpcd for autoconf because it doesn't
> support privacy addresses or removing the default route when the RA
> lifetime expires. (Or at least, the 6.3.2 version I downloaded today and
> ran on Debian stable didn't seem to support this).
> 
> So you still need to run kernel autoconf, at which point you might as
> well disable dhdpcd's RS processing since you probably don't want both
> the kernel and dhcpcd to be running autoconf.

Got it. So, summarizing, for Android, DHCPv4 and DHCPv6 options would
likely not be problematic, but an RA option likely would.

Thanks,
Simon

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 18 Apr 2014 22:23:58 +0900

> likely not be problematic, but an RA option likely would.

A DHCPv6 option would also be  problematic because android doesn't support
DHCPv6. (Support for IPv6-only networks is being worked on, but it will use
RDNSS).

A DHCPv4 option would be better.

---

From: Alejandro Acosta <[email-masked]>
Date: Fri, 18 Apr 2014 09:57:21 -0430

Hi Philip,

> doesn't offer IPv4 in the first place.

You are absolutely right...., thanks.
But anyway the scenario I mentioned above can also exists (and for good
or bad eventually will happen).. I just wanted to express my position
about the option NO-IPv4 in DHCPv4

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Apr 2014 10:56:46 -0500

> likely not be problematic, but an RA option likely would.

This is weird, though.   How does a DHCPv6 client know to attempt configuration, if it doesn't see RAs?   I just hacked around this on my router at home in order to get Comcast IPv6 working, but that seems broken.

---

From: Simon Perreault <[email-masked]>
Date: Fri, 18 Apr 2014 13:15:11 -0400

> This is weird, though.   How does a DHCPv6 client know to attempt configuration, if it doesn't see RAs?   I just hacked around this on my router at home in order to get Comcast IPv6 working, but th…

I don't know how Android does it, but any DHCPv6 client is free to
unilaterally attempt configuration. It doesn't need to wait for an RA to
tell it to do so. RAs are just a hint.

Simon

---

From: Ted Lemon <[email-masked]>
Date: Fri, 18 Apr 2014 12:23:27 -0500

> tell it to do so. RAs are just a hint.

Sure, but then it's completely disconnected from the comings and goings of router advertisements on the wire.   And, indeed, from the comings and goings of the wire itself.

---

From: Lorenzo Colitti <[email-masked]>
Date: Sat, 19 Apr 2014 11:35:00 +0900

On 19 Apr 2014 02:23, "Ted Lemon" <[email-masked]> wrote:
> Sure, but then it's completely disconnected from the comings and goings
of router advertisements on the wire.   And, indeed, from the comings and
goings of the wire itself.

One of the many reasons DHCPv6 is not a good  protocol to configure
addressing and routing.

---

From: Philip Homburg <[email-masked]>
Date: Sat, 19 Apr 2014 11:32:38 +0200

>about the option NO-IPv4 in DHCPv4

I'd say that if you want to play games and turn off IPv4 for some hosts
and not for others then you are better off putting the option in DHCPv4.

Putting the option in RA makes it all or nothing. You either tell all IPv6
hosts to turn off IPv4 or none.

Putting the option in DHCPv6 requires careful coordination between the DHCPv6
and DHCPv4 configs. The DHCPv6 server would have to send the option in the
IPv6 config and the DHCPv4 server has to refrain from sending an offer. This
can be tricky if the DHCPv4 and DHCPv6 device ids are different.

In contrast, putting the option in DHCPv4 only requires setting a flag in the
DHCPv4 config that particular host should not get IPv4. If we require
the DHCPv4 client to include the option in the DISCOVER then it is also easy
to tell old and new hosts apart.

---

From: Lee Howard <[email-masked]>
Date: Mon, 21 Apr 2014 14:36:48 -0400

On 4/18/14 11:56 AM, "Ted Lemon" <[email-masked]> wrote:

>This is weird, though.   How does a DHCPv6 client know to attempt
>configuration, if it doesn't see RAs?   I just hacked around this on my
>router at home in order to get Comcast IPv6 working, but that seems
>broken.

Depends on OS. At least one version of Windows apparently optimistically
sends DHCPv6 SOLICIT regardless of RAs.

Lee

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 22 Apr 2014 08:43:42 +1200

> sends DHCPv6 SOLICIT regardless of RAs.

Yep. That is neither required nor forbidden by the standards, so YMMV.
http://tools.ietf.org/html/draft-ietf-v6ops-dhcpv6-slaac-problem-00

   Brian

---

From: Erik Kline <[email-masked]>
Date: Sat, 19 Apr 2014 11:14:06 +0900

> Sure, but then it's completely disconnected from the comings and goings of router advertisements on the wire.   And, indeed, from the comings and goings of the wire itself.

Make no mistake though, on some access networks what they need to see
is the client's RS, so it can get injected with Suresh's line id and
pass up to the BNG to craft the correct customer RA in response*.
Randomly doing DHCPv6 before even doing RS's is not guaranteed to get
you anything in these networks.

Always doing DHCPv6 regardless smells like "IPv4 think" to me.

* the RS resiliency work is aimed to make this as reliable as possible.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 22 Apr 2014 11:07:32 -0400

> you anything in these networks.

Right.   ISTM that in some cases sending DHCPv6 messages before getting a response to an RS might be a minor speedup, because you can do both processes in parallel, but you aren't actually going to have connectivity until you get the RA anyway.   And if the state machines aren't interdependent, you're going to see all sorts of bad behavior, which I am fairly sure the Microsoft implementation does not exhibit.

So the fact that the Microsoft state machine has this small speed hack in it does not mean that the state machines are not interdependent.