- 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 difficult.
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
On Dec 23, 2011, at 1:23 PM, Jeff Wheeler wrote:
On Fri, Dec 23, 2011 at 4:13 PM, Mohacsi Janos moha...@niif.hu 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
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
is not used is a
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 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
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 subject
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
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
On Wed, Dec 28, 2011 at 7:55 AM, Masataka Ohta
mo...@necom830.hpcl.titech.ac.jp 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
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
2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
valdis.kletni...@vt.edu wrote:
SNIP
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.
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 frequently,
On Wed, Dec 28, 2011 at 7:28 AM, TJ trej...@gmail.com wrote:
2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
valdis.kletni...@vt.edu wrote:
SNIP
In this case, the following statement in RFC1883:
If the minimum time for rebooting the node is known (often more than
6
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.
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
mo...@necom830.hpcl.titech.ac.jp wrote:
Ray Soucy wrote:
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.
To me,
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
2011/12/28 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
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
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 prefix in
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 exhaustive,
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 blog
Hi,
On 12/23/11 7:48 AM, Ray Soucy wrote:
On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski tpo...@cis.vutbr.cz
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
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
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
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
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.
Especially when some
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, as is,
2011/12/26 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp
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;
2011/12/26 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp:
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.
On Mon, 26 Dec 2011 12:32:46 EST, Ray Soucy said:
2011/12/26 Masataka Ohta mo...@necom830.hpcl.titech.ac.jp:
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
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 Ohtamo...@necom830.hpcl.titech.ac.jp:
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
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 Ohtamo...@necom830.hpcl.titech.ac.jp:
And, if RA is obsoleted, which is a point of discussion, there
is no reason
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 purchased
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,
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
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 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 as 802.11
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 solution
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 time
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
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
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 that, if RA is
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 would
If you get DNS servers from RA and from DHCP, throw them all in the candidate
DNS server list. Unless something is broken, any one of them should work and
provide the same answers as the others.
You can't get NTP from SLAAC/RA, so, no conflict there. If the router and
dhcp server
On 12/22/11 16:16, Masataka Ohta wrote:
Glen Kent wrote:
While in some environments, typically with small number of devices,
its indispensable. Small businesses may not want the complexity of
setting up a central server (for DHCP) - SLAAC works very well in such
environments.
IPv6
On 12/22/11 12:09, Tomas Podermanski wrote:
We have to use SLAAC as well because we do not have other choice. Not
all operating systems supports DHCPv6 today. But we are not happy about
it (problems with privacy extensions, security as I mentioned before).
DHCPv6 do not have to be run on a
Hi,
On 12/23/11 7:07 AM, Mohacsi Janos wrote:
On Thu, 22 Dec 2011, Tomas Podermanski wrote:
Hi,
On 12/21/11 9:40 PM, Ray Soucy wrote:
I'm afraid you're about 10 years too late for this opinion to make
much difference. ;-)
My opinion is that there is never too late to make thinks easier
Hi,
On 12/23/11 4:33 AM, Owen DeLong wrote:
Sent from my iPad
On Dec 23, 2011, at 3:46 AM, Tomas Podermanski tpo...@cis.vutbr.cz wrote:
Hi,
On 12/22/11 12:18 AM, Owen DeLong wrote:
The long answer is:
I completely disagree with opinion that both DHCPv6 and RA (SLAAC)
should be
On Fri, Dec 23, 2011 at 2:51 PM, Tomas Podermanski tpo...@cis.vutbr.cz wrote:
That is true, but we know solution for IPv4 (DHCP snooping, ARP
protection, source address validation) and there are access switches on
the market having that security features. Switches supporting such
features for
On 12/23/11 6:56 AM, Mohacsi Janos wrote:
On Wed, 21 Dec 2011, Tomas Podermanski wrote:
Hi,
from my perspective the short answer for this never-ending story is:
- SLAAC/RA is totally useless, does not bring any benefit at all
and should be removed from IPv6 specs
- DHCPv6 should be
On Fri, Dec 23, 2011 at 3:06 PM, Tomas Podermanski tpo...@cis.vutbr.cz wrote:
Can you be more specific? I can not imagine situation where SLAAC could
solves a problem that DHCP would not.
SLAAC is the magic that makes the link-local scope work. I think
having a link-local scope is a good
On Fri, 23 Dec 2011 21:19:25 +0100, Tomas Podermanski said:
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.
Strictly speaking, they don't
On Fri, 23 Dec 2011 21:06:26 +0100, Tomas Podermanski said:
On 12/23/11 4:33 AM, Owen DeLong wrote:
If there is actual real world demand for it, it will get implemented.
Reality is that today, DHCPv4 has been running just as insecure for many
years
and nobody cares. I don't know why the
Hi,
On 12/23/11 9:09 PM, Ray Soucy wrote:
On Fri, Dec 23, 2011 at 2:51 PM, Tomas Podermanski tpo...@cis.vutbr.cz
wrote:
That is true, but we know solution for IPv4 (DHCP snooping, ARP
protection, source address validation) and there are access switches on
the market having that security
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 addresses.
That's a configuration of RA, not
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
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,
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, Jeff Wheeler wrote:
On Fri, Dec 23, 2011 at 4:13 PM, Mohacsi Janos moha...@niif.hu 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
On Fri, Dec 23, 2011 at 10:19 AM, Tomas Podermanski tpo...@cis.vutbr.cz 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
In many environments RA is a catastrophic disaster. Some operators need
to be able to do everything with RA turned off on routers, disabled on
hosts and filtered on switches.
While in some environments, typically with small number of devices,
its indispensable. Small businesses may not want
On 12/21/2011 11:28 PM, William Herrin wrote:
On Tue, Dec 20, 2011 at 1:27 AM, Ravi Duggal raviduggal2...@gmail.com wrote:
We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends
DHCPv6 to do what RA does. And now, we have
draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to
Hi,
On 12/21/11 9:40 PM, Ray Soucy wrote:
I'm afraid you're about 10 years too late for this opinion to make
much difference. ;-)
My opinion is that there is never too late to make thinks easier to
implement and operate, specially in situation when things are
unnecessary complicated. I do not
Hi,
On 12/22/11 12:04 AM, Michael Sinatra wrote:
On 12/21/11 12:40, Ray Soucy wrote:
I'm afraid you're about 10 years too late for this opinion to make
much difference. ;-)
We have been running IPv6 in production for several years (2008) as
well (answering this email over IPv6 now,
On Thu, 22 Dec 2011 21:04:42 +0100, Tomas Podermanski said:
Well, then how many devices do you have in the network that uses IPv6?
1,300+ wireless access points, 1,100+ switches, 30k+ users, around 55%
doing at least some IPv6 traffic (mostly when they hit Google).
Do you have implemented
Hi,
On 12/22/11 12:18 AM, Owen DeLong wrote:
The long answer is:
I completely disagree with opinion that both DHCPv6 and RA (SLAAC)
should be supported. It is easy to say that both have place but it has
some consequences. I and my colleagues have been working on deploying
IPv6 for a few
On 12/22/2011 04:48, Glen Kent wrote:
In many environments RA is a catastrophic disaster. Some operators need
to be able to do everything with RA turned off on routers, disabled on
hosts and filtered on switches.
While in some environments, typically with small number of devices,
its
Glen Kent wrote:
While in some environments, typically with small number of devices,
its indispensable. Small businesses may not want the complexity of
setting up a central server (for DHCP) - SLAAC works very well in such
environments.
IPv6 routers are the central servers for SLAAC with the
Sent from my iPad
On Dec 23, 2011, at 3:46 AM, Tomas Podermanski tpo...@cis.vutbr.cz wrote:
Hi,
On 12/22/11 12:18 AM, Owen DeLong wrote:
The long answer is:
I completely disagree with opinion that both DHCPv6 and RA (SLAAC)
should be supported. It is easy to say that both have place
On Wed, 21 Dec 2011, Tomas Podermanski wrote:
Hi,
from my perspective the short answer for this never-ending story is:
- SLAAC/RA is totally useless, does not bring any benefit at all
and should be removed from IPv6 specs
- DHCPv6 should be extended by route options as proposed in
On Thu, 22 Dec 2011, Tomas Podermanski wrote:
Hi,
On 12/22/11 12:04 AM, Michael Sinatra wrote:
On 12/21/11 12:40, Ray Soucy wrote:
I'm afraid you're about 10 years too late for this opinion to make
much difference. ;-)
We have been running IPv6 in production for several years (2008) as
On Thu, 22 Dec 2011, Tomas Podermanski wrote:
Hi,
On 12/21/11 9:40 PM, Ray Soucy wrote:
I'm afraid you're about 10 years too late for this opinion to make
much difference. ;-)
My opinion is that there is never too late to make thinks easier to
implement and operate, specially in
On Thu, Dec 22, 2011 at 3:04 PM, Tomas Podermanski tpo...@cis.vutbr.cz 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 deploying it.
I dug into the
Agree that in the long term support for more flexibility is good.
Acknowledge that change is slow, and we're just at a point now where
popular host systems even include mature DHCPv6 (but without route
options).
Both of the features discussed would be useful in specific
applications, but more
Hi,
from my perspective the short answer for this never-ending story is:
- SLAAC/RA is totally useless, does not bring any benefit at all
and should be removed from IPv6 specs
- DHCPv6 should be extended by route options as proposed in
I'm afraid you're about 10 years too late for this opinion to make
much difference. ;-)
We have been running IPv6 in production for several years (2008) as
well (answering this email over IPv6 now, actually) yet I have
completely different conclusions about the role of RA and DHCPv6.
Weird.
On
Hi,
Op 21 dec 2011, om 20:16 heeft Tomas Podermanski het volgende geschreven:
Hi,
from my perspective the short answer for this never-ending story is:
To be fair, SLAAC was designed as a light weight method to configure addressing
on the hosts.
Hosts. We don't have hosts on the internet
On Wed, Dec 21, 2011 at 10:40 AM, Ray Soucy r...@maine.edu wrote:
On Wed, Dec 21, 2011 at 2:16 PM, Tomas Podermanski tpo...@cis.vutbr.cz
wrote:
from my perspective the short answer for this never-ending story is:
- SLAAC/RA is totally useless, does not bring any benefit at all
and should
On 12/21/11 12:40, Ray Soucy wrote:
I'm afraid you're about 10 years too late for this opinion to make
much difference. ;-)
We have been running IPv6 in production for several years (2008) as
well (answering this email over IPv6 now, actually) yet I have
completely different conclusions about
On Dec 21, 2011, at 11:16 AM, Tomas Podermanski wrote:
Hi,
from my perspective the short answer for this never-ending story is:
- SLAAC/RA is totally useless, does not bring any benefit at all
and should be removed from IPv6 specs
Except that there are many environments where that's
Ravi Duggal wrote:
We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends
DHCPv6 to do what RA does. And now, we have
draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise
the NTP information that is currently done via DHCPv6.
My question is, that which then is the
On Wed, 21 Dec 2011 15:18:05 PST, Owen DeLong said:
Perhaps you have not, but, others have. I have seen environments where
SLAAC is much more useful than DHCPv6. I've seen environments where
DHCPv6 is needed.
OK, I'll name names. If you have end users still running WinXP, getting them
at
On Tue, Dec 20, 2011 at 1:27 AM, Ravi Duggal raviduggal2...@gmail.com wrote:
We thus have draft-droms-dhc-dhcpv6-default-router-00 that extends
DHCPv6 to do what RA does. And now, we have
draft-bcd-6man-ntp-server-ra-opt-00.txt that extends RA to advertise
the NTP information that is currently
Look at that, for once I agree with Owen on all points made. ;-)
On Wed, Dec 21, 2011 at 6:18 PM, Owen DeLong o...@delong.com wrote:
On Dec 21, 2011, at 11:16 AM, Tomas Podermanski wrote:
Hi,
from my perspective the short answer for this never-ending story is:
- SLAAC/RA is totally
valdis.kletni...@vt.edu wrote:
OK, I'll name names. If you have end users still running WinXP, getting
them at least somewhat working under SLAAC/DHCPv4 is a lot less headache
than trying to DHCPv6 them.
Anybody managed to stamp out WinXP in their end user population yet?
Heh. I
On Mon, 19 Dec 2011, Owen DeLong wrote:
Different operators will have different preferences in different environments.
Ideally, the IETF should provide complete solutions based on DHCPv6 and
on RA and let the operators decide what they want to use in their environments.
Agree. Selection
When a router needs to learn information from another router it will
*usually* use the RA messages and not DHCPv6, as the latter is
*usually* meant for Router - Host communication. However, it is NOT
uncommon to see hosts also learning the information using RA messages.
Router's afaik dont usually
I had some trouble parsing what Glen was saying, so, I'll provide some
clarification of how things actually work today and what I think would be
desirable in future development:
1. In IPv6, it is not uncommon for certain types of routers to be DHCP
clients.
DHCPv6-PD is relatively
* Owen DeLong
RAs are only useful (as far as routing is concerned) for routers to
announce themselves as default gateways. They do not provide
any mechanism for advertising more specific routes.
They do, actually. See RFC 4191.
--
Tore Anderson
Redpill Linpro AS -
On 20/12/2011 8:31 p.m., Owen DeLong wrote:
Ideally, the IETF should provide complete solutions based on DHCPv6 and
on RA and let the operators decide what they want to use in their environments.
+1
I would like to see a simple presentation of the different ways of
setting up a small
IPv6-RA autoconfiguration method allows to autoconfigure ipv6-capable
network interfaces by sending IPv6 prefixes throughout a link, so every
node that understands its message format can derive its own IPv6 address
based on internal algorithms. By using RA, you can configure almost any
node to
Different operators will have different preferences in different environments.
Ideally, the IETF should provide complete solutions based on DHCPv6 and
on RA and let the operators decide what they want to use in their environments.
Owen
On Dec 19, 2011, at 10:27 PM, Ravi Duggal wrote:
Hi,
93 matches
Mail list logo
