James Knott
Sebastian Freundt wrote:
you know it searches the stale addresses first? It seems to me that
if the computer knows the addresses are stale, the active one would be checked first.
Because last time I checked Linux, BSD and IOS complied to RFC 4861, sections 7.2.2 and 7.3.2 clearly state when, why and how neighbour solicitations are sent.
After glancing through that RFC, I get the impression that "stale" is not relevant here. It appears to be related to different MAC addresses for an IP address or whether an IPv6 address is still valid.
That's wrong. Read the whole document.
One thing to bear in mind is that IPv6 supports deprecated addresses so that an old IP address is still valid for a period of time after a new one is available.
Yes.
Ok, I won't change a route willy-nilly but if someone else came along with their 4000+ computers using*my* address space there will be trouble, it's inevitable.
With IPv4, each of those 4000+ computers will have one address. With IPv6, they'd have 2 or 3 with the random address changing occasionally. How is that a significantly greater problem? Also, you
Because you're not living in the real world:) When we had a v4 network the computers were hierarchised, every working group had their 100 to 200 computers on a private net, with about 10 of them having globally routable unicast addresses.
Originally, there was no such thing as NAT and all hosts were globally routable. NAT was created to share IP addresses. There are limited scope IPv6 addresses that can be used to keep computers off the global network.
I was for that approach actually, so yes, I second that.
Then came IPv6, everyone was excited (well I think of it as overzealous) and it was considered a good idea to make them all globally routable. Someone read it was bad practice to split up the assigned /64 even further and so the decision was made to line them all up in one gigantic network. Daft, I know, because little did we know about*efficient* routing
The /64 subnets are required to support EUI-64 MAC addresses. EUI-48 bit MACs are extended to 64 bits by inserting FEFF in the middle. Using MAC addresses to form IPv6 addresses was around before random address generation. The other alternatives would be DHCP or manual configuration.
Yep, it's all manual configuration, well, until recently where magically more addresses appear out of nowhere.
Oh wait, there's more, and noone really considered that, expired addresses don't just disappear from NIC, they're just flagged `invalid' which means new sockets won't/can't use them, long standing data connections be thanked you can occasionally find up to 20, but at least one*additional* *expired* address on the NICs. Where are we, right, a neighbourhood table of more than 100000 addresses, constantly icmp'd for.
If a NIC stops using an address, it will shortly disappear from the caches in the other computers & switches in the network, just like in IPv4.
That makes no sense, a NIC never `stops using an address', define what you mean by that. An expired address cannot be bound by bind(3), of course you can still reach it, and of course it's in other computers' neighbour tables and stored in the switches. ip a a 2001:db8::dead:beef/64 dev eth0 preferred_lft 20 Open a socket use it, and look what happens after the expiry.
don't route to computers on your local network. All addressing there
is by MAC address. Routing is used when you go to other networks via the router. But again, the other routers only have to know the route Yes, so? I was talking about the neigh table. There is just one router on our network.
Ummm... The post I was referring to said:
"
As you can see, more than half the entries have to go STALE first before a new route is picked up. I know there's ip neigh flush but do I want to do that on 4000+ computers just because I changed a route?
Ok, I won't change a route willy-nilly but if someone else came along with their 4000+ computers using*my* address space there will be trouble, it's inevitable."
It sure sounds like you were talking about routing to me, not the neighbour table. The neighbour table or arp cache is used to match IP addresses to MAC address and is only used for hosts on the local network. Routing tables are used to determine how to reach a different network.
to your network. Then when the packet gets to your network does your
router match up the IP address with the MAC address and pass the packet to the final destination. Nicely explained, but that's my point, the ONE router does have to keep up with all the different neighbours.
It keeps track of the MAC addresses only on the local network(s) that it's connected to. It doesn't keep track of MACs at the remote
It's just one big local network. What are you trying to say? And of course it's only STALE addresses that need re-NDP'ing, FAILED addresses are known to be unreachable, DELAY'd addresses are forcedly considered reachable for a moment, PROBEs are soon to be probed as reachability is unknown and INCOMPLETEs are currently in the process of solicitataion. Read RFC 4661 again.
networks. You will never see a MAC from a remote network on your network, unless you have some sort of bridge between them. In that case you wouldn't need a router.
Never said that. It's just one local network. One router. You are the one to imagine wild things. Reread my posting, I said several times it's just one router, and one big v6 network. In v4 times we had a cascade of routers but those times are long gone.
IPv6. Most of what applies to IPv4 also does to IPv6. Using a single address& NAT is more complex than simply routing a block of addresses. Ah, you would have been on the side of the overexcited/underinformed (yes
At the basic level, there's not a lot of difference between IPv4& those are synonyms to me) people on our NOC team 4 years ago then. You don't know how much you remind me of them Please explain how NAT is simpler that just routing, when you have to add the translation to the routing. Don't forget you have to include special rules for some protocols and hosts.
You don't seem to see the problem, the problem is we are assigned a /64 and we can't split it into smaller blocks, as you stated correctly because EUI64 assignment wouldn't be possible. So you take 5 to 8 year old hardware and expect it to run in 2011 coping with more addresses on a SINGLE hop than the entire uni had in v4 times. The result, fun :) I'd say the last time I've seen more infrastructure packets (icmp6) was when someone tried an arp attack against one of our routers. Sure, you say what's the problem, we need new hardware. I absolutely agree. What I wanted to show you with this anecdote is how combining `not so different', highly praised technologies and unexperienced administrators (well I was unexperienced back then too, I should admit) can result in a disaster. I'm *SURE* other NOC guys will tell you exactly the same and probably have a similar story for you. And what I'm also trying to say is that the NOC team is always grateful for advice from unexperienced overzealous users </sarcasm> :) Am I right NOCers? Anyone following this? :) -- To unsubscribe, e-mail: opensuse-factory+unsubscribe@opensuse.org To contact the owner, e-mail: opensuse-factory+owner@opensuse.org