On 1/11/12 9:58 AM, Masataka Ohta wrote:
A better default could be that IGP will be automatically invoked
if DHCP does not supply a default router.
That's ridiculous. You need some link state to even find a
DHCP server. So, the very idea that DHCP would tell you where
your routers are is prep
valdis.kletni...@vt.edu wrote:
>> Beyond that, if there are multiple routers, having a default
>> router and relying
> Yes yes we know, and we've understood this for a quarter century or so. My
> disagreement is that even though 99.8% of machines *don't* have multiple
> routers, you seem to be p
On Tue, 03 Jan 2012 15:19:08 PST, Owen DeLong said:
> The implementation of IPv6 in a host MUST support SLAAC. That does not mean
> that the host must use that support in any particular environment.
The odd part is that the above paragraph is equally true if you replace SLAAC
with IPSec - but in
On Dec 24, 2011, at 4:36 PM, Masataka Ohta wrote:
> Joel jaeggli wrote:
>
>>> First of all, ND use is optional and, if ND is used, RA
>>> must be used.
>>>
>>> It means that, if RA is not used, ND can't be used.
>>
>> Finding and maintaining the l2 address for a device on a subnet where RA
>>
On Dec 23, 2011, at 1:23 PM, Jeff Wheeler wrote:
> On Fri, Dec 23, 2011 at 4:13 PM, Mohacsi Janos wrote:
>> If you can limit number of ARP/NDP entries per interfaces and you complement
>> RAGuard and DHCPv4 snooping your are done.
>
> That depends on how ARP/ND gleaning works on the box. In sh
>
> I agree with you, that is not typical for many networks. For example in
> our network we have enabled some of that features (not all) only in some
> subnets. Unfortunately those subnets connects over 70% of our users
> (6500). Is also great that many produces are going to take that issues
> se
>
>>
>>> - SLAAC is usually processed in a kernel, DHCPv6 is usually run as a
>>> process in the user space. Diagnostic and troubleshooting is more
>>> complicated.
>>
>> Some operating system do the SLAAC processing in user space. What is
>> the problem.
>
> As I wrote. Troubleshooting is more
Ray Soucy wrote:
Well, it seems now you've also added the requirement that we also
dramatically re-write all software that makes use of networking.
Seemingly for the sake of never admitting that you can be wrong.
Thank you for failing to point out where I am wrong.
You seem to think that the
Christian Esteve wrote:
> May be there is some light with Multipath TCP:
> http://www.ietf.org/proceedings/75/slides/mptcp-0.pdf
> http://datatracker.ietf.org/wg/mptcp/charter/
Not bad.
> If you can live without UDP and other issues discussed in this bizarre
> discussion...
UDP connection, if a
> Multihoming with multiple addresses works at transport/application
layer over existing IPv4 and IPv6.
May be there is some light with Multipath TCP:
http://www.ietf.org/proceedings/75/slides/mptcp-0.pdf
http://datatracker.ietf.org/wg/mptcp/charter/
If you can live without UDP and other issues d
On 29 Dec 2011, at 13:46 , Masataka Ohta wrote:
> we must assume MTU of 1280B. But, as IPv6 extension headers can
> be as lengthy as 1000B or 2000B, no applications are guaranteed
> to work over IPv6.
As IP is an unreliable datagram service, there are no guarantees, period.
The presence of firew
On 12/30/11 08:47 , Kevin Loch wrote:
> It is very common to have different "routers" (routers, firewalls or
> load balancers) on the same vlan with different functions in hosting
> environments. It is also sometimes necessary to have multiple default
> gateways on the same vlan for load balancin
VRRP is still useful, and for those who find it useful it has been
extended to IPv6 [RFC5798]. Vendors, such as Cisco, have already
begun shipping functional implementations as well it would seem.
There are certainly pieces of IPv6 that will need refinement (and we
will likely see that happen ove
Steven Bellovin wrote:
VRRP? The Router Discovery Protocol (RFC 1256). But given
how much more reliable routers are today than in 1984, I'm
not convinced it's that necessary these days.
VRRP is an absolutely essential protocol in today's Internet. We use
it on every non-bgp customer port.
Well, it seems now you've also added the requirement that we also
dramatically re-write all software that makes use of networking.
Seemingly for the sake of never admitting that you can be wrong.
You seem to think that the OSI model is this nice and clean model that
cleanly separates everything an
Ray Soucy wrote:
But that is only the case if you let customers have a PI prefix (which
I think is really required in a purist end-to-end model, but for the
sake of argument...).
Multihoming by routing, by the intermediate systems, is against
the end to end principle, which is why it does not
On 29 Dec 2011, at 0:16 , Doug Barton wrote:
> On 12/28/2011 03:13, Iljitsch van Beijnum wrote:
>> However, this has two issues. First, with RAs there are no risks that
>> incorrect default information is propagated because the default
>> gateway itself broadcasts its presence.
> Unless you have
OK, this is getting ridiculous.
Let's assume that we have a model where host systems receive the
global routing table from service providers. The stated reason for
this is so that they could make their own routing decisions when
multi-homed environment. Presumably with each ISP connected to a L2
In message <69748.1325208...@turing-police.cc.vt.edu>, valdis.kletni...@vt.edu
writes:
> On Fri, 30 Dec 2011 12:12:43 +1100, Mark Andrews said:
>
> > Well I'd like to be able to plug in the cable router and the DSL
> > router at home and have it all just work. Just because it is 0.2%
> > today
On Dec 29, 2011, at 7:00 PM, Jeff Kell wrote:
> The real-world case for host routing (IMHO) is a server with a public
> interface, an administrative interface, and possibly a third path for
> data backups (maybe four if it's VMware/VMotion too). Unless the
> non-public interfaces are flat subnet
Steven Bellovin wrote:
>> Considering that the reason to have multiple routers
>> should be for redundancy, there is no point to use
>> one of them as the default router.
> VRRP? The Router Discovery Protocol (RFC 1256). But given
> how much more reliable routers are today than in 1984, I'm
> n
On 12/29/2011 8:12 PM, Mark Andrews wrote:
> Well I'd like to be able to plug in the cable router and the DSL
> router at home and have it all just work.
Well, that's not too far removed from the plugged-in laptop with the
wireless still active. Toss-up which one wins default route.
What would y
On Fri, 30 Dec 2011 12:12:43 +1100, Mark Andrews said:
> Well I'd like to be able to plug in the cable router and the DSL
> router at home and have it all just work. Just because it is 0.2%
> today doesn't mean that it will be 0.2% in the future. As home
> users get more and more dependent on th
In message <68424.1325204...@turing-police.cc.vt.edu>, valdis.kletni...@vt.edu
writes:
> On Fri, 30 Dec 2011 07:30:16 +0900, Masataka Ohta said:
> > IGP is the way for routers advertise their existence,
> > though, in this simplest case, an incomplete proxy of
> > relying on a default router work
On Fri, 30 Dec 2011 07:30:16 +0900, Masataka Ohta said:
> IGP is the way for routers advertise their existence,
> though, in this simplest case, an incomplete proxy of
> relying on a default router works correctly.
Which is sufficient for 99.8% of hosts out there.
> Beyond that, if there are mult
On Dec 29, 2011, at 5:30 16PM, Masataka Ohta wrote:
> valdis.kletni...@vt.edu wrote:
>
>>> IGP snooping is not necessary if the host have only one next
>>> hop router.
>
>> You don't need an IGP either at that point, no matter what some paper from
>> years ago tries to assert. :)
>
> IGP is th
valdis.kletni...@vt.edu wrote:
>> IGP snooping is not necessary if the host have only one next
>> hop router.
> You don't need an IGP either at that point, no matter what some paper from
> years ago tries to assert. :)
IGP is the way for routers advertise their existence,
though, in this simples
On Dec 29, 2011, at 2:27 AM, Vitkovsky, Adam wrote:
>> ... host systems should participate in IGP
>
>> We tried that.
>
>> It didn't scale well.
>
>> The Internet today is very different than the Internet in 1981.
>
> -did you? I thought CLNS with plethora of ip addresses compared to ipv4 was
On 12/29/2011 7:59 AM, Cameron Byrne wrote:
Next topic, ethernet is too chaotic and inefficient to deploy and support
mission critical applications in LAN or WAN or data center.
See IEEE1588v2 (Precision Time Protocol), SyncE, and Data center
bridging (DCB) - all attempts to remedy such ineff
On Thu, 29 Dec 2011 21:53:29 +0900, Masataka Ohta said:
> IGP snooping is not necessary if the host have only one next
> hop router.
You don't need an IGP either at that point, no matter what some paper from
years ago tries to assert. :)
pgpOVkl5pWSgU.pgp
Description: PGP signature
On 12/28/2011 11:50 PM, Masataka Ohta wrote:
> With DHCP only, there is no DAD necessary.
Plonk
AlanC
--
a...@clegg.com | acl...@infoblox.com
1.919.355.8851
signature.asc
Description: OpenPGP digital signature
On Dec 29, 2011 6:38 AM, "Ray Soucy" wrote:
>
> Sounds like we have one group saying that IPv6 is too complicated and
> that all the "overhead" of IPv6 had resulted in slow adoption.
>
> Meanwhile we have others saying it doesn't have enough functionality,
> and should also include IGP.
>
> Seems
valdis.kletni...@vt.edu wrote:
> So what percent of the *CPE* in the average cable-internet or DSL farm
> *actually
> uses* an IGP,
As I wrote:
> If a host receives RAs only from a router, the host can do
> nothing other than installing the router as the default
> router. If not, however, the h
Ray Soucy wrote:
Sounds like we have one group saying that IPv6 is too complicated and
that all the "overhead" of IPv6 had resulted in slow adoption.
Meanwhile we have others saying it doesn't have enough functionality,
and should also include IGP.
Not at all. It is wrong that ND is so compli
On Thu, 29 Dec 2011 09:14:20 GMT, Florian Weimer said:
> Because there's a CPE which acts as a mediator, or the host uses some
> dial-up-type protocol which takes care of the IGP interaction.
So what percent of the *CPE* in the average cable-internet or DSL farm *actually
uses* an IGP, and how muc
Sounds like we have one group saying that IPv6 is too complicated and
that all the "overhead" of IPv6 had resulted in slow adoption.
Meanwhile we have others saying it doesn't have enough functionality,
and should also include IGP.
Seems like IPv6 as it is has struck a balance somewhere in the mi
(*) If you think I'm going to run an IGP on some of my file servers when
"default route to the world out the public 1G interface, and 5 static routes
describing the private 10G network" is actually the *desired* semantic because
if anybody re-engineers the 10G net enough to make me change the rout
>... host systems should participate in IGP
>We tried that.
>It didn't scale well.
>The Internet today is very different than the Internet in 1981.
-did you? I thought CLNS with plethora of ip addresses compared to ipv4 was
buried before it could be widely deployed, I was not around back than
* Valdis Kletnieks:
>>> According to the end to end argument, the only possible solution
>>> to the problem, with no complete or correct alternatives, is to
>>> let hosts directly participate in IGP activities.
>
> If it's the "only possible spolution", how come 99.8% of the end nodes
> do just fi
Masataka Ohta wrote:
Because that's the Microsoft quality. PERIOD.
"We knew it was a crooked game, but it was the only game in town."
valdis.kletni...@vt.edu wrote:
>>> Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled
>>> by
>>> default?
>
>> Sanity check with Windows? Are you sure?
>
> It's a quick sanity check to this statment:
>
>>> According to the end to end argument, the only possible solutio
On Thu, 29 Dec 2011 11:51:00 +0900, Masataka Ohta said:
> valdis.kletni...@vt.edu wrote:
> > Quick sanity check on the hypothesis: Does Windows ship with an IGP enabled
> > by
> > default?
> Sanity check with Windows? Are you sure?
It's a quick sanity check to this statment:
>> According to the
TJ wrote:
>> RA initiated DHCPv6 is slower than RA, of course.
> I am not counting the "delay" caused by waiting for the RA against DHCPv6.
Do you count random delay between RA and DHCPv6 solicit?
Do you count DAD delay after DHCPv6?
> Isn't the stateless operation of a router providing a pref
On Wed, Dec 28, 2011 at 6:16 PM, Doug Barton wrote:
> On 12/28/2011 03:13, Iljitsch van Beijnum wrote:
>> Second, publishing specifications, implementing them and waiting for
>> users to adopt them takes a very, very long time. For DHCPv6 support,
>> the time from first publication (2003) until w
valdis.kletni...@vt.edu wrote:
>> According to the end to end argument, the only possible solution
>> to the problem, with no complete or correct alternatives, is to
>> let hosts directly participate in IGP activities.
>
> That's only for hosts that are actively trying to communicate on more than
2011/12/28 Masataka Ohta
> TJ wrote:
>
> >> However, assuming you change the cells every 100m in average
> >> and you are moving at 100km/h, you must change the cells every
> >> 3.6 seconds in average, which means you must be able to change
> >> the cells frequently, which means each cell change
Leo Bicknell wrote:
> Moble networks do not today, and should not in the future expose
> those handoffs to the IP layer. Even WiFi networks are moving from
> the per-cell (AP) model you describe to a controller based
> infrastructure that seeks to avoid exposing L3 changes to the client.
The rea
TJ wrote:
>> However, assuming you change the cells every 100m in average
>> and you are moving at 100km/h, you must change the cells every
>> 3.6 seconds in average, which means you must be able to change
>> the cells frequently, which means each cell change take a lot
>> less than 3.6 seconds.
I would like to understand how you think RA is broken, and how you
think that it could be improved.
You have made some bold statements, but we lack the context to
understand their meaning.
On Wed, Dec 28, 2011 at 7:11 PM, Masataka Ohta
wrote:
> Ray Soucy wrote:
>
>> After reading some of your
Ray Soucy wrote:
After reading some of your work on end-to-end multihoming, I think I
understand some of what you're trying to say. My problem is that
while you seem to have a very strong academic understanding of
networking, you seem to be ignoring operational realities in
implementation.
To
> Second, publishing specifications, implementing them and waiting for
> users to adopt them takes a very, very long time. For DHCPv6 support,
> the time from first publication (2003) until wide availability (2011)
> has been 8 years. Are we ready to live in a half-baked world for
> another half
On Wed, Dec 28, 2011 at 18:16, Doug Barton wrote:
> On 12/28/2011 03:13, Iljitsch van Beijnum wrote:
> > However, this has two issues. First, with RAs there are no risks that
> > incorrect default information is propagated because the default
> > gateway itself broadcasts its presence.
>
> Unless
On 12/28/2011 03:13, Iljitsch van Beijnum wrote:
> However, this has two issues. First, with RAs there are no risks that
> incorrect default information is propagated because the default
> gateway itself broadcasts its presence.
Unless you have a malicious user on the network in which case all
tra
On Wed, 28 Dec 2011 21:56:19 +0900, Masataka Ohta said:
> According to the end to end argument, the only possible solution
> to the problem, with no complete or correct alternatives, is to
> let hosts directly participate in IGP activities.
That's only for hosts that are actively trying to commun
On Wed, Dec 28, 2011 at 7:28 AM, TJ wrote:
> 2011/12/28 Masataka Ohta
>
>> valdis.kletni...@vt.edu wrote:
>>
>
>
>>
>>
>> >> In this case, the following statement in RFC1883:
>> >>> If the minimum time for rebooting the node is known (often more than
>> >>> 6 seconds),
>> >> is the wrong a
In a message written on Wed, Dec 28, 2011 at 08:33:23PM +0900, Masataka Ohta
wrote:
> However, assuming you change the cells every 100m in average
> and you are moving at 100km/h, you must change the cells every
> 3.6 seconds in average, which means you must be able to change
> the cells frequentl
2011/12/28 Masataka Ohta
> valdis.kletni...@vt.edu wrote:
>
>
>
> >> In this case, the following statement in RFC1883:
> >>>If the minimum time for rebooting the node is known (often more than
> >>>6 seconds),
> >> is the wrong assumption which made RA annoying.
> >
> > Oddly enough, a
I mean no disrespect.
What I meant by that post was that I look forward to reading something
along the lines of:
8<
1. I believe RA should be moved to HISTORICAL status because of the
following concerns:
2. A better way to provide routing information to host systems would be:
8<---
On Wed, Dec 28, 2011 at 7:55 AM, Masataka Ohta
wrote:
> No counter argument possible against such abstract nonsense.
Yes. That was my point.
--
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
http://www.networkmaine
2011/12/28 Masataka Ohta :
> According to the end to end argument, the only possible solution
> to the problem, with no complete or correct alternatives, is to
> let hosts directly participate in IGP activities.
>
> See the paper by Saltzer et. al.
So your entire argument is based on an academic p
Iljitsch van Beijnum wrote:
>>> Granted that the notion of default router of IPv4 is no better
>>> than that of IPv6.
>
>> Please present a reasonable alternative.
>
> Obviously reducing down the entire DFZ to a single default route
> is a bad case of premature optimization,
Stop confusing "def
On 28 Dec 2011, at 13:26 , Ray Soucy wrote:
>> Granted that the notion of default router of IPv4 is no better
>> than that of IPv6.
> Please present a reasonable alternative.
Obviously reducing down the entire DFZ to a single default route is a bad case
of premature optimization, which we all k
Ray Soucy wrote:
>> Granted that the notion of default router of IPv4 is no better
>> than that of IPv6.
>
> Please present a reasonable alternative.
According to the end to end argument, the only possible solution
to the problem, with no complete or correct alternatives, is to
let hosts directl
Ray Soucy wrote:
Your straw man argument (which is what this has become) is just
dancing around the real issue.� You're going to have to back up and
make your case for us, rather than trying to respond to one-liners
made (most of which were sarcastic, by the way).
No counter argument possible
2011/12/28 Masataka Ohta :
> Granted that the notion of default router of IPv4 is no better
> than that of IPv6.
Please present a reasonable alternative.
--
Ray Soucy
Epic Communications Specialist
Phone: +1 (207) 561-3526
Networkmaine, a Unit of the University of Maine System
http://www.netw
Iljitsch van Beijnum wrote:
> Just to clear up a few misconceptions:
Only to add yet another misconception without any clearing up?
> Router advertisements are exactly what the name suggests,
> routers advertising their presence.
> The first function of router advertisements is to tell
> hosts w
Your straw man argument (which is what this has become) is just
dancing around the real issue. You're going to have to back up and
make your case for us, rather than trying to respond to one-liners
made (most of which were sarcastic, by the way).
You have yet to identify who (beyond yourself) is
valdis.kletni...@vt.edu wrote:
>> IPv6 does not work well in many environments.
>
> Feel free to try to deprecate *everything* that doesn't work well in many
> environments.
Why not?
> Heck, SMTP doesn't work well in many environments (it's done in
> cleartext unless you deploy STARTTLS, it's s
Just to clear up a few misconceptions:
begin explanation current situation
Router advertisements are exactly what the name suggests, routers advertising
their presence. The first function of router advertisements is to tell hosts
where the routers are, so the hosts can install a defau
On Wednesday, December 28, 2011 05:23:48 AM Tomas
Podermanski wrote:
> In that area we also tried to use longer prefixes than
> /64, but we had difficulties on some devices. There was
> two kind of problems. Some of devices weren't able
> properly handle longer prefixes for example in routing
> p
On Wed, 28 Dec 2011 07:49:21 +0900, Masataka Ohta said:
> valdis.kletni...@vt.edu wrote:
> > Especially when some of the biggest IPv6 networks out there are still using
> > it pretty heavily.
> That's not a valid counter argument against people who
> found problems in certain environment.
>
> IPv6
valdis.kletni...@vt.edu wrote:
>>> And, if RA is obsoleted, which is a point of discussion, there
>>> is no reason to keep so bloated ND only for address resolution.
>
>> By who? Sources please.
>> A few people on NANOG complaining about RA is pretty far from deprecation of
>> RA.
>
> Especial
On 12/27/11 10:53 PM, Ray Soucy wrote:
> Much like with IPv4, we capture the DUID at the time of registration
> and store it in the database. We make use of a web-based registration
> system that allows users to register computers for network access with
> a valid ID (that piece is still in develo
On Tue, 27 Dec 2011 22:23:48 +0100, Tomas Podermanski said:
> I agree with you. Deploying IPv6 is really not easy and not cheep as
> some IPv6 enthusiasts claims.
It's probably as easy and as cheap as IPv4 is. You've just forgotten
how expensive and painful it was to solve all the exact same pro
Much like with IPv4, we capture the DUID at the time of registration
and store it in the database. We make use of a web-based registration
system that allows users to register computers for network access with
a valid ID (that piece is still in development, though).
There is still work to be done
Hi,
On 12/23/11 7:48 AM, Ray Soucy wrote:
> On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski
> wrote:
>
>> Well, then how many devices do you have in the network that uses IPv6?
> Good question, and I applaud you for wanting to verify that people
> talking about IPv6 have legitimate experience
On Mon, 2011-12-26 at 13:23 -0500, Mark Radabaugh wrote:
> Find me some decent consumer CPE and I would be more than happy to
> deploy IPv6. So far the choices I have found for consumer routers
> are pathetic.A fair number of them still have IPv4 issues.
You might find Adrian Kennard's blo
On Tuesday, December 27, 2011 02:23:46 AM Mark Radabaugh
wrote:
> Find me some decent consumer CPE and I would be more than
> happy to deploy IPv6. So far the choices I have found
> for consumer routers are pathetic.A fair number of
> them still have IPv4 issues.
It's by no means exhaustiv
Op 26 dec 2011, om 20:46 heeft Steven Bellovin het volgende geschreven:
> Not quite what you're asking for, but I was very pleasantly surprised to see
> that some (at least) Brother printers support IPv6. Progress...
Indeed, my Mac has no issues printing or scanning to my MFC-9465DCN I purchase
On Dec 26, 2011, at 1:23 46PM, Mark Radabaugh wrote:
> On 12/26/11 12:56 PM, valdis.kletni...@vt.edu wrote:
>> On Mon, 26 Dec 2011 12:32:46 EST, Ray Soucy said:
>>> 2011/12/26 Masataka Ohta:
And, if RA is obsoleted, which is a point of discussion, there
is no reason to keep so bloated N
On 12/26/11 12:56 PM, valdis.kletni...@vt.edu wrote:
On Mon, 26 Dec 2011 12:32:46 EST, Ray Soucy said:
2011/12/26 Masataka Ohta:
And, if RA is obsoleted, which is a point of discussion, there
is no reason to keep so bloated ND only for address resolution.
By who? Sources please.
A few people
On Mon, 26 Dec 2011 12:32:46 EST, Ray Soucy said:
> 2011/12/26 Masataka Ohta :
> > And, if RA is obsoleted, which is a point of discussion, there
> > is no reason to keep so bloated ND only for address resolution.
> By who? Sources please.
> A few people on NANOG complaining about RA is pretty fa
2011/12/26 Masataka Ohta :
> And, if RA is obsoleted, which is a point of discussion, there
> is no reason to keep so bloated ND only for address resolution.
By who? Sources please.
A few people on NANOG complaining about RA is pretty far from deprecation of RA.
--
Ray Soucy
Epic Communicati
2011/12/26 Masataka Ohta
> TJ wrote:
>
> > I think perhaps you are confusing "what must be supported by
> > implementations" (and ignoring the text describing the requirements) as
> > stated in 6434, with operational usage.
>
> There is not much difference.
>
I disagree; there is a huge differe
TJ wrote:
> I think perhaps you are confusing "what must be supported by
> implementations" (and ignoring the text describing the requirements) as
> stated in 6434, with operational usage.
There is not much difference.
> For example - SLAAC must be supported by the implementations, but an
> env
I think perhaps you are confusing "what must be supported by
implementations" (and ignoring the text describing the requirements) as
stated in 6434, with operational usage.
For example - SLAAC must be supported by the implementations, but an
environment isn't required to use it.
/TJ
On Dec 24, 2
Joel jaeggli wrote:
>> First of all, ND use is optional and, if ND is used, RA
>> must be used.
>>
>> It means that, if RA is not used, ND can't be used.
>
> Finding and maintaining the l2 address for a device on a subnet where RA
> is not used is a pretty common activity so I'm not sure how your
On 12/24/11 15:33 , Masataka Ohta wrote:
> Karl Auer wrote:
>
>>> Not necessarily. You can use ARP and DHCPv6 and you don't have
>>> to waste time and power for DAD.
>
>> IPv6 does not do ARP, it does ND.
>
> First of all, ND use is optional and, if ND is used, RA
> must be used.
>
> It means t
Karl Auer wrote:
>> Not necessarily. You can use ARP and DHCPv6 and you don't have
>> to waste time and power for DAD.
> IPv6 does not do ARP, it does ND.
First of all, ND use is optional and, if ND is used, RA
must be used.
It means that, if RA is not used, ND can't be used.
Then, the only re
On Sat, 2011-12-24 at 17:58 +0900, Masataka Ohta wrote:
> Not necessarily. You can use ARP and DHCPv6 and you don't have
> to waste time and power for DAD.
IPv6 does not do ARP, it does ND. Even if you use DHCv6, you still need
ND. DAD is still performed on addresses assigned via DHCPv6.
> DHCPv6
Michael Sinatra wrote:
>> DHCPv6 works over link layers with unreliable multicast
>> better than ND.
>
> You still need ND to provide the link-layer address resolution (i.e. the
> IPv6 equivalent of ARP), even with DHCPv6.
Not necessarily. You can use ARP and DHCPv6 and you don't have
to waste t
Michael Sinatra wrote:
>> That's a configuration of RA, not DHCPv6.
>
> So? If DHCPv6 had default route capability you wouldn't need RA at all.
According to the end to end principle that hosts do everything,
default router is a bad idea and you should better snoop IGP,
which is the only solutio
On 12/23/11 13:00, Masataka Ohta wrote:
> Tomas Podermanski wrote:
>
>> It sounds good, but according to RFC 6434 ( IPv6 Node Requirements)
>> SLAAC is required,
>
> Not at all. SLAAC is required only if ND is supported, which
> is optional.
>
> Note that ND works poorly over link layers such a
On 12/23/11 12:52, Masataka Ohta wrote:
> Michael Sinatra wrote:
>
>> The only time you need to perform extra steps is when you want to run
>> DHCPv6. You need to enable the M and/or O flags and turn off the
>> 'autonomous' flag (if you don't want a host to get both SLAAC addresses
>> and DHCPv6
On Fri, Dec 23, 2011 at 10:19 AM, Tomas Podermanski wrote:
> On 12/23/11 6:56 AM, Mohacsi Janos wrote:
>> On Wed, 21 Dec 2011, Tomas Podermanski wrote:
>>> - There must be solved a situation what to do when SLAAC and DHCPv6
>>> provides some conflict information (quite long thread with various
>>
On Fri, 23 Dec 2011, Jeff Wheeler wrote:
On Fri, Dec 23, 2011 at 4:13 PM, Mohacsi Janos wrote:
If you can limit number of ARP/NDP entries per interfaces and you complement
RAGuard and DHCPv4 snooping your are done.
That depends on how ARP/ND gleaning works on the box. In short, Cisco
alr
On Fri, Dec 23, 2011 at 4:13 PM, Mohacsi Janos wrote:
> If you can limit number of ARP/NDP entries per interfaces and you complement
> RAGuard and DHCPv4 snooping your are done.
That depends on how ARP/ND gleaning works on the box. In short, Cisco
already has a knob to limit the number of ND ent
On Fri, 23 Dec 2011, Tomas Podermanski wrote:
It sounds good, but according to RFC 6434 ( IPv6 Node Requirements) SLAAC is
required, but DHCPv6 is only optional. So any
manufacturer of operating systems or devices do not have to support DHCPv6.
You might propose updating RFC 6434
On Fri, 23 Dec 2011, Tomas Podermanski wrote:
Port security does not help in that case (same as 802.1x). Port security
is a layer 2 feature so all layer 3 attacks can be still performed. That
prevents only against source MAC address spoofing. All other attacks
like DAD DOS, NDP Exhaustion, R
Tomas Podermanski wrote:
> It sounds good, but according to RFC 6434 ( IPv6 Node Requirements)
> SLAAC is required,
Not at all. SLAAC is required only if ND is supported, which
is optional.
Note that ND works poorly over link layers such as 802.11
where multicast is unreliable.
> but DHCPv6 is
1 - 100 of 145 matches
Mail list logo
