On Apr 18, 2014, at 10:14 PM, Erik Kline e...@google.com wrote:
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
On 4/18/14 11:56 AM, Ted Lemon mel...@fugue.com wrote:
On Apr 18, 2014, at 7:51 AM, Simon Perreault
simon.perrea...@viagenie.ca wrote:
Got it. So, summarizing, for Android, DHCPv4 and DHCPv6 options would
likely not be problematic, but an RA option likely would.
This is weird, though. How
On 22/04/2014 06:36, Lee Howard wrote:
On 4/18/14 11:56 AM, Ted Lemon mel...@fugue.com wrote:
On Apr 18, 2014, at 7:51 AM, Simon Perreault
simon.perrea...@viagenie.ca wrote:
Got it. So, summarizing, for Android, DHCPv4 and DHCPv6 options would
likely not be problematic, but an RA option
In your letter dated Fri, 18 Apr 2014 09:57:21 -0430 you wrote:
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
I'd say that if
In your letter dated Thu, 17 Apr 2014 22:16:19 -0430 you wrote:
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
Le 2014-04-17 17:14, Mark Andrews a écrit :
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.
Uh, no. The levels are in strictly increasing order. 2 includes
everything in 1,
Le 2014-04-17 23:49, Lorenzo Colitti a écrit :
On Thu, Apr 17, 2014 at 11:24 PM, Simon Perreault
simon.perrea...@viagenie.ca mailto:simon.perrea...@viagenie.ca wrote:
Le 2014-04-16 12:25, Simon Kelley a écrit :
Android uses dhcpcd as its DHCP client.
Thought about this some
Hi Philip,
El 4/18/2014 3:28 AM, Philip Homburg escribió:
In your letter dated Thu, 17 Apr 2014 22:16:19 -0430 you wrote:
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
On Apr 18, 2014, at 7:51 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
Got it. So, summarizing, for Android, DHCPv4 and DHCPv6 options would
likely not be problematic, but an RA option likely would.
This is weird, though. How does a DHCPv6 client know to attempt
configuration, if
Le 2014-04-18 11:56, Ted Lemon a écrit :
On Apr 18, 2014, at 7:51 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
Got it. So, summarizing, for Android, DHCPv4 and DHCPv6 options would
likely not be problematic, but an RA option likely would.
This is weird, though. How does a
Dear Michael, all,
Please see inline.
Cheers,
Med
-Message d'origine-
De : homenet [mailto:homenet-boun...@ietf.org] De la part de Michael
Richardson
Envoyé : mercredi 16 avril 2014 15:08
À : homenet@ietf.org
Objet : Re: [homenet] Please review the No IPv4 draft
{I would love
Le 2014-04-16 18:12, Mark Andrews a écrit :
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
mohamed.boucad...@orange.com wrote:
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
In message 534fe395.1050...@viagenie.ca, Simon Perreault writes:
Le 2014-04-16 18:12, Mark Andrews a =E9crit :
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
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
In your letter dated Wed, 16 Apr 2014 09:07:46 -0400 you wrote:
Philip Homburg pch-homene...@u-1.phicoh.com wrote:
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
Le 2014-04-16 09:07, Michael Richardson a écrit :
Ideally the device will not announce an IPv4 default route if it hasn't got
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
On 4/16/14, 6:40 AM, Simon Perreault wrote:
Le 2014-04-16 09:07, Michael Richardson a écrit :
Ideally the device will not announce an IPv4 default route if it hasn't got
one itself.
The fact is that all CPE routers today do announce an IPv4 default route
to the LAN irrespective of their WAN
On Apr 16, 2014, at 9:52 AM, Lorenzo Colitti lore...@google.com wrote:
Not Android.
I thought Android used dnsmasq.
___
homenet mailing list
homenet@ietf.org
https://www.ietf.org/mailman/listinfo/homenet
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?
let me see what I recall...
That's interesting, especially the FTTH case. Thanks for the info.
--
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
Simon Perreault simon.perrea...@viagenie.ca writes:
Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user
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
Le 2014-04-15 07:28, Toke Høiland-Jørgensen a écrit :
Simon Perreault simon.perrea...@viagenie.ca writes:
Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user
can already do this today without this extension.
Right, to a certain extent that is true, of course; but not in
Simon Perreault simon.perrea...@viagenie.ca 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
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 :
Simon Perreault simon.perrea...@viagenie.ca writes:
=
Correct. But if DHCP or RAs are not filtered at layer 2, a rogue user
can already do this today without this
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.
It seems to me that options relating to IPv4 don't belong in RA/DHCPv6
-- they belong
On Apr 15, 2014, at 6:28 AM, Toke Høiland-Jørgensen t...@toke.dk wrote:
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).
This is a good point. Given
On Apr 15, 2014, at 9:07 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
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.
Le 2014-04-15 09:56, Philip Homburg a écrit :
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).
Sure it can. Just send them to a non-existing default
Le 2014-04-15 11:17, Ted Lemon a écrit :
On Apr 15, 2014, at 9:07 AM, Juliusz Chroboczek
j...@pps.univ-paris-diderot.fr wrote:
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
On 15.4.2014, at 17.07, Juliusz Chroboczek j...@pps.univ-paris-diderot.fr
wrote:
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.
Le 2014-04-15 11:15, Ted Lemon a écrit :
On Apr 15, 2014, at 6:28 AM, Toke Høiland-Jørgensen t...@toke.dk wrote:
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
Ted Lemon mel...@fugue.com 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
In your letter dated Tue, 15 Apr 2014 11:24:48 -0400 you wrote:
Le 2014-04-15 09:56, Philip Homburg a écrit :
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
Le 2014-04-15 11:48, Philip Homburg a écrit :
In your letter dated Tue, 15 Apr 2014 11:24:48 -0400 you wrote:
Le 2014-04-15 09:56, Philip Homburg a écrit :
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
On Apr 15, 2014, at 10:34 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
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
Sorry, missed an important part. Replying in full.
Le 2014-04-15 11:15, Ted Lemon a écrit :
On Apr 15, 2014, at 6:28 AM, Toke Høiland-Jørgensen t...@toke.dk wrote:
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
On Apr 15, 2014, at 10:46 AM, Toke Høiland-Jørgensen t...@toke.dk wrote:
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
On Apr 15, 2014, at 11:05 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
Yes, and by the time this is fully configurable, you are talking about many
hundreds lines of code.
I completely disagree with your estimate.
I think you are talking apples and oranges. Simon, you are
On Apr 15, 2014, at 11:22 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
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
Le 2014-04-15 12:25, Ted Lemon a écrit :
On Apr 15, 2014, at 11:22 AM, Simon Perreault simon.perrea...@viagenie.ca
wrote:
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.
In your letter dated Tue, 15 Apr 2014 12:05:59 -0400 you wrote:
http://resources.infosecinstitute.com/slaac-attack/
When you have unfiltered L2 access, there are LOTS of evil things you
can do.
The world is not black and white. Rogue RAs are easy for hit and run attacks.
Maybe I should already
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
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
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.
On Apr 15, 2014, at 11:47 AM, Philip Homburg pch-homene...@u-1.phicoh.com
wrote:
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
In your letter dated Tue, 15 Apr 2014 12:09:48 -0500 you wrote:
On Apr 15, 2014, at 11:47 AM, Philip Homburg pch-homene...@u-1.phicoh.com wro
te:
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
I'm only saying that from my perspective, changing DHCPv4 is the best
technical solution.
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
In message m1wabgi-...@stereo.hq.phicoh.net, Philip Homburg writes:
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
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
Simon Perreault simon.perrea...@viagenie.ca writes:
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.
If I understand the draft
Le 2014-04-14 11:19, Toke Høiland-Jørgensen a écrit :
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
52 matches
Mail list logo
