As a general rule, most clients are following the "If we gave them static
IPv4 addresses we will give them static IPv6 addresses" (infrastructure,
servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit
related) conversation ...
To try to stay operational about this, I have a reality testing question
I've used in IPv4 and, for that matter, bridged networks:
If you want to test a resource, be it the end user or an infrastructure
interface, how do you know how to foo it (foo being some value of ping,
traceroute, look it up in SNMP/NetFlow, etc)?
I submit that if you use dynamic assignment of any sort, you really have to
have DNS dynamic update, so you can use a known name to query the function
that's indexed by address. Otherwise, static addresses become rather
necessary if you want to check a resource.
This was especially a question when L2 was "in" and routing was out: how do
you ping a MAC address?
Hmmmm. I think this is an operational topic, but I can see how it would be seen as more of a strategic item.
I have a reality testing question
I've used in IPv4 and, for that matter, bridged networks:
I submit that if you use dynamic assignment of any sort, you really have to
have DNS dynamic update, so you can use a known name to query the function
that's indexed by address. Otherwise, static addresses become rather
necessary if you want to check a resource.
Naturally. DNS name would be required, or a static address. In an ISP/service provider environment I imagine that being able to hand out dynamic ranges would be useful. Having to handle that statically would be painful.
This was especially a question when L2 was "in" and routing was out: how do
you ping a MAC address?
l2ping works on bluetooth devices on Linux. Might work for other stuff as well. Not sure what Cisco offers in this regard.
As a general rule, most clients are following the "If we gave them static
IPv4 addresses we will give them static IPv6 addresses" (infrastructure,
servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit
related) conversation ...
----------------------------------------------------
I'm still an IPv6 wussie and would like to learn more before moving forward, so would anyone care to share info on experiences with this decision?
Here's some pro's and con's to both
SLAAC:
- widely implemented in host v6 stacks that have shipped
- widely implemented on v6 routers
- really, really, really broken: it didn't support handing out
any DNS info until RFC 5006, thus SLAAC still requires human
intervention on a client to make "teh v6 interwebs" work. It
will probably be a painful wait until 5006 gets more widely
implemented on hosts (if ever, for some) & routers.
- probably "faster" than dhcpv6 w/ tuning timers. Could be
better for mobile thingys.
- supports RFC 3041 "security by obscurity" extensions.
DHCPv6
- doesn't ship w/ some OS's
- new (danger code), not all features implemented
- router support for dhcpv6 relay very limited
- advanced things like prefix delegation don't really seem to
have been ironed out.
In case you weren't confused enough between the two, they are not
mutually exclusive. You can run both SLAAC and DHCPv6 at the same
time on the same L2.
As a general rule, most clients are following the "If we gave them static
IPv4 addresses we will give them static IPv6 addresses" (infrastructure,
servers, etc). The whole SLAAC(autoconfig) vs DHCPv6 is a separate (albeit
related) conversation ...
----------------------------------------------------
I'm still an IPv6 wussie and would like to learn more before moving forward,
so would anyone care to share info on experiences with this decision?
Which one?
"If we gave them static IPv4 addresses we will give them static IPv6 addresses"
Or
"SLAAC(autoconfig) vs DHCPv6"
For the first ... at the simplest, it is familiar and comfortable.
In general:
Servers, Routers, Firewalls, Switches (atleast those with L3 addresses) == static address
Hosts == dynamic ... either SLAAC or DHCPv6. Manual Configuration of hosts is a non-starter for most environments.
For the latter ... that gets more involved.
Many (most?) platforms do not support DHCPv6 client functionality. Ditto on the server side.
OTOH, SLAAC alone cannot currently give you DNS information ... a possible deal-breaker, that.
(Some work under way to change that, or the environment can cheat 0 rely on IPv4 transport for DNS )
To try to stay operational about this, I have a reality testing question
I've used in IPv4 and, for that matter, bridged networks:
If you want to test a resource, be it the end user or an infrastructure
interface, how do you know how to foo it (foo being some value of ping,
traceroute, look it up in SNMP/NetFlow, etc)?
I submit that if you use dynamic assignment of any sort, you really have to
have DNS dynamic update, so you can use a known name to query the function
that's indexed by address. Otherwise, static addresses become rather
necessary if you want to check a resource.
While I mostly agree, replace Dynamic DNS with "dynamic name resolution
services" (or, perhaps, a stable endpoint address) and I agree even more :).
Aside from static addresses, Dynamic DNS is one approach (currently the most
common).
PNRP, LLMNR are other possible solutions (depending on the scope we
are talking about).
WRT the "stable endpoint" piece, tunneling can work here.
Mobile IPv6, for example, starts off with my machine always being
reachable at the same address.
Some tunnel providers also allocate stable addressing - i.e.
wherever I am in IPv4-land I still have the same IPv6 address.
This was especially a question when L2 was "in" and routing was out: how do
you ping a MAC address?
I prefer Layer 11 - the money
(8 = people, 9-politics, 10=religion, 11=money)
As a general rule, most clients are following the "If we gave them
static
IPv4 addresses we will give them static IPv6 addresses"
(infrastructure, servers, etc). The whole SLAAC(autoconfig) vs DHCPv6
is a separate (albeit
related) conversation ...
----------------------------------------------------
I'm still an IPv6 wussie and would like to learn more before moving
forward, so would anyone care to share info on experiences with this
decision?
Here's some pro's and con's to both
SLAAC:
- widely implemented in host v6 stacks that have shipped
- widely implemented on v6 routers
- really, really, really broken: it didn't support handing out
any DNS info until RFC 5006, thus SLAAC still requires human
intervention on a client to make "teh v6 interwebs" work. It
will probably be a painful wait until 5006 gets more widely
implemented on hosts (if ever, for some) & routers.
Or rely on IPv4 to do the DNS part. I call this "cheating", but do not mean
to include the negative connotations that come with that word :).
- probably "faster" than dhcpv6 w/ tuning timers. Could be
better for mobile thingys.
- supports RFC 3041 "security by obscurity" extensions.
DHCPv6
- doesn't ship w/ some OS's
And some vendors have publicly stated that they would never support DHCPv6.
While I may not fully believe them (never is a long time), that is atleast
an indication not to expect it "soon".
- new (danger code), not all features implemented
- router support for dhcpv6 relay very limited
- advanced things like prefix delegation don't really seem to
have been ironed out.
In case you weren't confused enough between the two, they are not mutually
exclusive. You can run both SLAAC and DHCPv6 at the same time on the same
L2.
Indeed, Stateless DHCPv6 is exactly that. I should have mentioned that by
now - sorry!
- really, really, really broken: it didn't support handing out
any DNS info until RFC 5006, thus SLAAC still requires human
intervention on a client to make "teh v6 interwebs" work.
While I agree that it is bad that the DNS configuration issue took so long to fix, I wouldn't consider this a flaw of stateless autoconfiguration, which works extremely well. There have been many times that I was at conferences where the IPv4 DHCP wouldn't work so it was impossible to go online, while stateless autoconfig rarely creates any problems. (Although there could be connectivity problems upstream, though.)
DHCPv6
- doesn't ship w/ some OS's
Forget about it on XP, but it's in Vista. You can add it to BSD/Linux without too much trouble (are there good, bugfree implementations for those yet?) but Mac is a problem for prospective DHCPv6 users because the network configuration mechanisms are fairly proprietary and DHCPv6 isn't likely to be supported any time soon.
- new (danger code), not all features implemented
- router support for dhcpv6 relay very limited
- advanced things like prefix delegation don't really seem to
have been ironed out.
Actually the prefix delegation has worked just fine for me. This is the redeeming feature in DHCPv6.
In my opinion, DHCPv6 was severely misdesigned. For instance, there are stateful and stateless variations, and the _client_ has to choose which to use. DHCPv6 also doesn't give you a subnet prefix length or a default gateway, so you still need router advertisements (that are also used for stateless autoconfig). The latter can be considered a feature, but I'm guessing the lack of a subnet prefix other than the assumption that the whole world uses /64 has been giving DHCPv6 server implementers a lot of headaches.
In case you weren't confused enough between the two, they are not
mutually exclusive. You can run both SLAAC and DHCPv6 at the same
time on the same L2.
Of course there's no telling what exactly the clients are going to do in that case...
but it's in Vista. You can add it to BSD/Linux without too much trouble (are there good, bugfree implementations for those yet?)
Bugfree? Nothing is bugfree
but Mac is a problem for prospective DHCPv6 users because the network configuration mechanisms are fairly proprietary and DHCPv6 isn't likely to be supported any time soon.
Hmmmm. I have yet to play with the Mac Ipv6 support (typing this on a Mac now I should try in my lab later). What auto configuration mechanisms are you referring to? Bonjour? Isn't there an RFC or two for Zeroconf?
Did you see somewhere on that site, that WinXP does DHCPv6?
I don't. And it would be wrong, to boot.
(Not just IPv6 support - that is one simple command ...)
but it's in Vista. You can add it to BSD/Linux without too much
trouble (are there good, bugfree implementations for those yet?)
Bugfree? Nothing is bugfree
but Mac is a problem for prospective DHCPv6 users because the network
configuration mechanisms are fairly proprietary and DHCPv6 isn't
likely to be supported any time soon.
Hmmmm. I have yet to play with the Mac Ipv6 support (typing this on a Mac
now I should try in my lab later). What auto configuration mechanisms are
you referring to? Bonjour? Isn't there an RFC or two for Zeroconf?
No, I believe he is referring to the actual network configuration.
Not the (almost) automatic/automated service/device discovery ...
This was especially a question when L2 was "in" and routing was out: how do
you ping a MAC address?
l2ping works on bluetooth devices on Linux. Might work for other stuff as well. Not sure what Cisco offers in this regard.
The ideal solution would be OAM. Of course not everything supports that and it's not on by default either. Of all the things to turn off by default, this is one thing that I'd like to see on.
1. I think ARP is effectively a ping for a mac. It verifies connectivity on level 2 between two hosts. You have to be on the same segment though....
To make it work, you would have to know the mac address of the remote host, clear the arp table the local host, then send the ARP request out.
This would still require that each host have IP stacks in place with functioning IP addresses. Although ARP acts under IP, it still requires IP to function.
2. I think you might be able to fudge it using RARP, if you just look for signals sent to that address.
3. A kind of constant ping might be... if you knew the remote's MAC address you could poison the ARP table with an announcement, spoof the MAC locally, then do MITM stuff and relay communications.
ARPING still seems to rely upon a proper IP stack and address on both hosts.
Meh, your best bet might be just to scan your arp tables for the mac you are interested in. I think all NICs broadcast periodically saying "I am here". Passive ping.
--p
That's close. If you use dynamic assignment via DHCP (v4 or v6),
then you have a handy database of all the IPv4 addresses assigned and
whatever information you want to discern them by (if not by hostname)
that was available to the DHCP server at the time of assignment.
Strictly speaking, Dynamic DNS isn't even necessary, but it could be
reasonably handy (because IPv6 addresses do not pass 'the phone
test').
With technologies like SLAAC, tho, you are right. You're going to
have to give devices a means to register with the network
independently of their IP address allocation, because it only takes
one client to Router Solicit to configure multiple clients upon the
broadcast Router Advertisement reply. Unless you start sniffing for
their neighbor discovery probes (part of SLAAC is to ensure the new
address is not already in use), there's no transaction where the
resource(s) are assigned.
There is quite obviously a key distribution problem with that kind of
model, and if you have to manually configure a system to configure
itself dynamically, there is a significantly diminished reward.
At this point in the excercise, you may as well do what the rest of us
in the current SLAAC-only world have done; disable SLAAC and set v6
addresses (and DNS) manually. Welcome to 1985, the era DHCPv4 saved
us from.
But this leads you back to today's IPv6 operational problem; if you
need registered clients, then you can install any DHCPv6 software you
can find to get it via either its database or Dynamic DNS (quite a
lot of DHCPv6 server software supports Dynamic DNS). But you still
wont' have any DHCPv6 clients outside of Vista.
This is where the chicken meets the egg on our faces.