The subject says it all... anyone with experience with a setup like this ?
I am particularly wondering about possible NDP breakage.
cheers!
Carlos
+1
We allocate /64 per PtP but only configure /127 for NDP and secrity
concerns, I figure we can always change the mask if the space is set
asside from the get go.
ta
as a test case, i built a small home network out of /120. works just fine.
my home network has been native IPv6 for about 5 years now, using a /96 and IVI.
some thoughts. disable RD/RA/ND.
none of the DHCPv6 code works like DHCP, so I re-wrote
client and server code so that it does.
static address assignment is a good thing for services like DNS/HTTP
secure dynmaic update is your friend
summary - its not easy, vendors don't want to help. but it can be done.
--bill
bmanning@vacation.karoshi.com (bmanning) writes:
as a test case, i built a small home network out of /120. works just fine.
my home network has been native IPv6 for about 5 years now, using a /96 and IVI.some thoughts. disable RD/RA/ND.
none of the DHCPv6 code works like DHCP, so I re-wrote
client and server code so that it does.
static address assignment is a good thing for services like DNS/HTTP
secure dynmaic update is your friendsummary - its not easy, vendors don't want to help. but it can be done.
Right - /64 is an assumption that's hardcoded many places.
But it does work.
Doing a little introspection, I found myself realizing that one of the
most bothersome aspects of the /64 boundary (for me, just speaking for
myself here) is exactly that, the tendency to the hardcoding of boundaries.
C.
well... you are correct - he did say shorter. me - i'd hollar for my good
friends Fred and Radia (helped w/ the old vitalink mess) on the best way to
manage an arp storm and/or cam table of a /64 of MAC addresses. 
It was
hard enough to manage a "lan"/single broadcast domain that was global in scope
and had 300,000 devices on it.
"route when you can, bridge when you must"
--bill
Every time I see this question it' usually related to a fundamental
misunderstanding of IPv6 and the attempt to apply v4 logic to v6.
That said. Any size prefix will likely work and is even permitted by
the RFC. You do run the risk of encountering applications that assume
a 64-bit prefix length, though. And you're often crippling the
advantages of IPv6.
But in terms of the "best practice" it is indeed 64-bit for every
network, with the option of 126-bit prefixes for link networks and
128-bit loopback addresses.
You should think of IPv6 as a 64-bit address that happens to include a
64-bit host identifier.
The entire point of IPv6 having a 128-bit address space was to
facilitate this and put an end to having to determine the network
prefix length based on an (often incorrect) estimation of the number
of hosts the network will need to accommodate.
Use of 126-bit prefixes for point-to-point connections (link networks)
is acceptable. Use of 127-bit prefixes should be avoided as outlined
in RFC 3627.
So it really comes down to keeping it simple.
Remember, we're dealing with exponentials here. A 64-bit address
space isn't twice as large as a 32-bit address space; it's roughly 4.2
billion times larger. The 340 undecillion (that's 340 with 36 zeros
after it) unique identifiers available with a 128-bit address space is
blatantly excessive if you don't factor in that the host segment is
always intended to be 64 of those bits.
So if conservation of address space isn't the logic behind using a
smaller prefix, then the question becomes what is? Most people
tunnel-vision on the fact that Stateless Address Auto-Configuration
requires that a 64-bit prefix be advertised to work and assume that
the best way to disable it is to use a prefix-length other than 64.
While you could do this, a far better way would be to simply not
announce the prefix with the Autonomous bit set to true. Every IPv6
implementation respects the value of the "A" bit on a prefix
advertisement and will not use Stateless configuration if it is not
true, just as outlined in the RFC.
Another thing to consider is that most processors today lack
operations for values that are larger than 64-bit. By separating the
host and network segment at the 64-bit boundary you may be able to
take advantage of performance optimizations that make the distinction
between the two (and significantly reduce the cost of routing
decisions, contributing to lower latency).
Many cite concerns of potential DoS attacks by doing sweeps of IPv6
networks. I don't think this will be a common or wide-spread problem.
The general feeling is that there is simply too much address space
for it to be done in any reasonable amount of time, and there is
almost nothing to be gained from it.
But yes. Basic NDP, routing, forwarding, etc. should work fine with
anything shorter than 126. Just not really sure the logic behind
doing so.
The problem I see is the opening of a new, simple, DoS/DDoS scenario.
By repetitively sweeping a targets /64 you can cause EVERYTHING in
that /64 to stop working by overflowing the ND/ND cache, depending on
the specific ND cache implementation and how big it is/etc. Routers
can also act as amplifiers too, DDoSing every host within a multicast
ND directed solicitation group (and THAT is even assuming a correctly
functioning switch thats limiting the multicast travel)
Add to it the assumption that every router gets certain things right
(like everything correctly decrementing TTLs as assumed in RFC 4861
11.2 in order for hosts to detect off-link RA/ND messages and guard
themselves against those), in these ways it's certainly at least
somewhat worse than ARP.
If you're able to bring down, or severely limit, a site by sending a
couple thousand PPS towards the /64 it's on, or by varying the upper
parts of the /64 to flood all the hosts with multicast traffic while
simultaneously floodign the routers LRU ND cache well thats a cheap
and easy attack and it WILL be used, and that can be done with the
protocols working as designed, at least from my reading. Granted I
don't have an IPv6 lab to test any of this. But I'd be willing to bet
this exact scenario is readily and easily possible, it already is with
ARP tables (and it DOES happen, it's just harder to make happen with
ARP and IPv4 since the space is so small, esp when compared to a /64)
IPv6 ND LRU Caches/tables aren't going to be anywhere near big enough
to handle a single /64's worth of hosts. And if they're any
significant amt smaller then it'd be trivial to cause a DoS by
sweeping the address space. It would depend on the ND table
limits/sizes, and any implementation specific timers/etc and garbage
collection, and a some other details I don't have, but, I bet it'd be
a really small flow in the scheme of things to completely stomp out a
/64....someone I'm sure knows more about the implementations, and I'm
betting this has been brought up before about IPv6/ND...
So I pretty strongly disagree about your statement. Repetitively
sweeping an IPv6 network to DoS/DDoS the ND protocol thereby flooding
the ND cache/LRUs could be extremely effective and if not payed
serious attention will cause serious issues.
Bill,
It seems efforts related to IP address specific policies are likely doomed by the sheer size of the address space, and to be pedantic, ARP has been replaced with multicast neighbor discovery which dramatically reduces the overall traffic involved. Secondly, doesn't Secure Neighbor Discovery implemented at layer 2 fully mitigate these issues? I too would be interested in hearing from Radia and Fred.
-Doug
Every time I see this question it' usually related to a fundamental
misunderstanding of IPv6 and the attempt to apply v4 logic to v6.
Not exactly. If it's a point-to-point link, then there are *TWO* machines on it -- one at each end; there will *always* be two machines on it. There's no sane reason to assign 18trillion addresses to it. Yes, in this respect it's like not wasting an IPv4 /24, but it's also The Right Tool For The Job.(tm) If one were to assign a /64 to every p-t-p link in the world, IPv6 address space would be used at an insane rate. (and those assignments aren't free.) Do people not remember the early days of IPv4 where /8's were handed out like Pez?
That said. Any size prefix will likely work and is even permitted by
the RFC. You do run the risk of encountering applications that assume
a 64-bit prefix length, though. And you're often crippling the
advantages of IPv6.
And such applications are *BROKEN*. IPv6 is *classless* -- end of discussion.
/64 (and /80 previous) is a lame optimization so really stupid devices can find an address in 4 bytes of machine code. This is quite lame given all the other complex baggage IPv6 requires.
And then /64 is only required by SLAAC, which you are not required to use.
You should think of IPv6 as a 64-bit address that happens to include a
64-bit host identifier.
No, you should not. That underminds the fundamental concept of IPv6 being *classless*. And it will lead to idiots writing broken applications and protocols assuming that to be true.
Another thing to consider is that most processors today lack
operations for values that are larger than 64-bit. By separating the
host and network segment at the 64-bit boundary you may be able to
take advantage of performance optimizations that make the distinction
between the two (and significantly reduce the cost of routing
decisions, contributing to lower latency).
IPv6 is classless; routers cannot blindly make that assumption for "performance optimization".
Many cite concerns of potential DoS attacks by doing sweeps of IPv6
networks. I don't think this will be a common or wide-spread problem.
Myopia doesn't make the problem go away. The point of such an attack is not to "find things", but to overload the router(s). (which can be done rather easily by a few dozen machines.)
--Ricky
There will be two machines but not necessarially 2 addresses. For
inter router links there will usually only be the two adresses.
For port to point links to general purpose machines you should
expect multiple address at least one end.
Even routers can use CGAs.
Mark
Every time I see this question it' usually related to a fundamental
misunderstanding of IPv6 and the attempt to apply v4 logic to v6.Not exactly. If it's a point-to-point link, then there are *TWO* machines on it -- one at each end; there will *always* be two machines on it. There's no sane reason to assign 18trillion addresses to it. Yes, in this respect it's like not wasting an IPv4 /24, but it's also The Right Tool For The Job.(tm) If one were to assign a /64 to every p-t-p link in the world, IPv6 address space would be used at an insane rate. (and those assignments aren't free.) Do people not remember the early days of IPv4 where /8's were handed out like Pez?
Dude... In IPv6, there are 18,446,744,073,709,551,616 /64s. To put this in
perspective...
There are roughly 30,000 ISPs on Earth.
The largest ISPs have thousands (not tens of thousands) of point-to-point links.
Even if we assume 30,000 Point to point links per ISP and 60,000 ISPs,
you still only used 1,800,000,000 /64s. The remaining
18,446,744,071,909,551,616 are still available for other uses.
I think a use that does not effect the first 11 significant digits of the
total address space is hard to call "used at an insane rate".
Yes, I remember the early days. Now, let's compare the population
of the internet in those days (60+ organizations vs 256 /8s) to the
current ratio we're talking about (let's be generous and say there
are two end sites for every person on the planet...
12,000,000,000 vs. 281,474,976,710,656/48s).
In the former case, we're talking about a known population representing
23% of all available address space.
In the IPv6 case, we're talking about a generous potential estimate of
the population being less than 0.0043% of the available address space.
That said. Any size prefix will likely work and is even permitted by
the RFC. You do run the risk of encountering applications that assume
a 64-bit prefix length, though. And you're often crippling the
advantages of IPv6.And such applications are *BROKEN*. IPv6 is *classless* -- end of discussion.
/64 (and /80 previous) is a lame optimization so really stupid devices can find an address in 4 bytes of machine code. This is quite lame given all the other complex baggage IPv6 requires.
And then /64 is only required by SLAAC, which you are not required to use.
I disagree. There are many useful optimizations that come from /64 other than
just SLAAC. However, SLAAC is also a very useful tool.
You should think of IPv6 as a 64-bit address that happens to include a
64-bit host identifier.No, you should not. That underminds the fundamental concept of IPv6 being *classless*. And it will lead to idiots writing broken applications and protocols assuming that to be true.
True, but, in terms of deploying networks, unless you have a really good
reason not to, it is best to use /64 for all segments. It preserves what I
like to call the principle of least surprise (the less you surprise the
operators, the less likely they are to make mistakes) and it provides
a very clean, easy to comprehend boundary that works in virtually
any application. You never have to worry about outgrowing your
subnet. SLAAC works wherever you want it to. You don't have to keep
track of complex tables of allocations and optimizations of how you
carved things up at the individual subnet level. You can focus on
optimizing how you carve up aggregates of /64s into regions
or sites or whatever.
Personally I'm also a fan of using a /48 per site as well, allowing
better concentration on optimizing the higher levels of the addressing
hierarchy without getting buried in the minutiae of individual subnets.
Another thing to consider is that most processors today lack
operations for values that are larger than 64-bit. By separating the
host and network segment at the 64-bit boundary you may be able to
take advantage of performance optimizations that make the distinction
between the two (and significantly reduce the cost of routing
decisions, contributing to lower latency).IPv6 is classless; routers cannot blindly make that assumption for "performance optimization".
Blindly, no. However, it's not impractical to implement fast path switching that
handles things on /64s and push anything that requires something else
to the slow path.
Many cite concerns of potential DoS attacks by doing sweeps of IPv6
networks. I don't think this will be a common or wide-spread problem.Myopia doesn't make the problem go away. The point of such an attack is not to "find things", but to overload the router(s). (which can be done rather easily by a few dozen machines.)
Only if you don't deploy reasonable mitigation strategies.
Owen
> IPv6 is classless; routers cannot blindly make that assumption for "performance optimization".
>
Blindly, no. However, it's not impractical to implement fast path switching that
handles things on /64s and push anything that requires something else
to the slow path.
Any vendor who was stupid enough to do *hardware* switching for up to
/64 and punted the rest to software would certainly not get any sales
from us.
128 bits. No magic.
Steinar Haug, Nethelp consulting, sthaug@nethelp.no
> > IPv6 is classless; routers cannot blindly make that assumption for "performance optimization".
> >
> Blindly, no. However, it's not impractical to implement fast path switching that
> handles things on /64s and push anything that requires something else
> to the slow path.Any vendor who was stupid enough to do *hardware* switching for up to
/64 and punted the rest to software would certainly not get any sales
from us.
Actually, they'd most likely punt the rest to exact match rather than
longest match cams. Exact match cams are cheaper because they're
simpler, and have been made even more so because they've been for more
than a decade layer 2 switches, and they're are far many more of them
than there are routers.
128 bits. No magic.
"magic" is another way of describing progress. Electric start cars
would have been "magic" to owners of Motorwagens.
Every time I see this question it' usually related to a fundamental
misunderstanding of IPv6 and the attempt to apply v4 logic to v6.Not exactly. If it's a point-to-point link, then there are *TWO* machines
on it -- one at each end; there will *always* be two machines on it.
There's no sane reason to assign 18trillion addresses to it. Yes, in this
respect it's like not wasting an IPv4 /24, but it's also The Right Tool For
The Job.(tm) If one were to assign a /64 to every p-t-p link in the world,
IPv6 address space would be used at an insane rate. (and those assignments
aren't free.) Do people not remember the early days of IPv4 where /8's were
handed out like Pez?
Not sure we disagree? I happily use 126-bit prefixes on
point-to-point networks. The discussion is on LAN networks, though.
That said. Any size prefix will likely work and is even permitted by
the RFC. You do run the risk of encountering applications that assume
a 64-bit prefix length, though. And you're often crippling the
advantages of IPv6.And such applications are *BROKEN*. IPv6 is *classless* -- end of
discussion.
Yes, they are broken, but if you think the fact that 1% of users using
prefixes smaller than 64-bit will make those bad developers change
their ways I'm not sure what to tell you. The horse has already left
the barn on that one. But I'm not going to stop you from using
120-bit prefixes on all your networks if that's what you want.
Having to shuffle LAN networks around because they no longer have the
address space to support the number of hosts on it goes away if you
stick with the 64 rule. DoS problems exists regardless of the prefix
length. I'd rather find a solution to the problem than simply try to
mitigate it by turning IPv6 into IPv4.
/64 (and /80 previous) is a lame optimization so really stupid devices can
find an address in 4 bytes of machine code. This is quite lame given all
the other complex baggage IPv6 requires.And then /64 is only required by SLAAC, which you are not required to use.
You should think of IPv6 as a 64-bit address that happens to include a
64-bit host identifier.No, you should not. That underminds the fundamental concept of IPv6 being
*classless*. And it will lead to idiots writing broken applications and
protocols assuming that to be true.
IPv6 is classless. You can have any size prefix you want. Chopping
off the last 64-bits and calling it a host segment essentially turns
IPv6 into a 64-bit address that will never have a need for PAT (NAT
overload) which was the reasoning to go with the 128-bit address
space. You can use any size prefix you want for routing.
Are you of the mindset that everyone should use a 120-bit prefix for
each network, then advertise each of those into BGP without route
aggregation? I'm not really sure where you're going here.
The argument can also be made that using smaller prefixes with
sequential host numbering will lead to making network sweeps and port
scanning viable in IPv6 where it would otherwise be useless. At that
point you just need evidence of one IPv6 address being in use and you
know that a few hundred next to it have the interesting hosts
connected.
Another thing to consider is that most processors today lack
operations for values that are larger than 64-bit. By separating the
host and network segment at the 64-bit boundary you may be able to
take advantage of performance optimizations that make the distinction
between the two (and significantly reduce the cost of routing
decisions, contributing to lower latency).IPv6 is classless; routers cannot blindly make that assumption for
"performance optimization".
I'm not saying its make-or-break. It certainly does help. Especially
when we're trying to shave nanoseconds off. I don't foresee 128-bit
CPUs simply to accommodated IPv6 anytime soon. These kinds of
optimizations happen every day already in other applications. IPv6
will likely be no different as vendors begin to compete on who has the
best IPv6 hardware.
Many cite concerns of potential DoS attacks by doing sweeps of IPv6
networks. I don't think this will be a common or wide-spread problem.Myopia doesn't make the problem go away. The point of such an attack is not
to "find things", but to overload the router(s). (which can be done rather
easily by a few dozen machines.)--Ricky
Neither does avoiding it until it gets ignored? There are plenty of
solutions and best practices that have nothing to do with the prefix
length. I'm saying that you shouldn't use the possibility of a
specific type of DoS attack (that is less attractive to attackers than
nearly every other type of DoS attack out there) be your determinant
for what prefix length you use. If an attacker wants to DoS a router
and has the capacity to use this attack vector, they also have the
capacity to achieve it with a dozen other ones.
Yes.... This is an issue for point-to-point links but using a longer prefix (/126 or similar) has been suggested as a mitigation for this sort of attack.
I would assume that in the LAN scenario where you have a /64 for your internal network that you would have some sort of stateful firewall sitting infront of the network to stop any un-initiated sessions. This therefore stops any hammering of ND cache etc. The argument then is that the number of packets hitting your firewall / bandwidth starvation would be the the alternative line of attack for a DoS/DDos but that is a completely different issue.
There are many IPv4 networks that don't implement firewall rules for subnets which contain servers. DDoS mitigation is handled differently. It would not be unexpected for these networks to do the same with IPv6.
Jack
Concur 100%. Also note that firewalls don't provide any sort of useful DDoS protection, marketing claims aside, so reaction tools such as S/RTBH, et. al. are required to protect stateful firewalls in front of client access LANs, and everything behind said stateful firewalls, from DDoS.
I love this term... "repetitively sweeping a targets /64".
Seriously? Repetitively sweeping a /64? Let's do the math...
2^64 = 18,446,744,073,709,551,616 IP addresses.
Let's assume that few networks would not be DOS'd by a 1,000 PPS
storm coming in so that's a reasonable cap on our scan rate.
That means sweeping a /64 takes 18,446,744,073,709,551 sec.
(rounded down).
There are 86,400 seconds per day.
18,446,744,073,709,551 / 86,400 = 213,503,982,334 days.
Rounding a year down to 365 days, that's 584,942,417
years to sweep the /64 once.
If we increase our scan rate to 1,000,000 packets
per second, it still takes us 584,942 years to sweep
a /64.
I don't know about you, but I do not expect to live long
enough to sweep a /64, let alone do so repetitively.
Owen
>
> So I pretty strongly disagree about your statement. Repetitively
> sweeping an IPv6 network to DoS/DDoS the ND protocol thereby
flooding
> the ND cache/LRUs could be extremely effective and if not payed
> serious attention will cause serious issues.
>Yes.... This is an issue for point-to-point links but using a longer
prefix (/126 or similar) has been suggested as a mitigation for this
sort of attack.I would assume that in the LAN scenario where you have a /64 for your
internal network that you would have some sort of stateful firewall
sitting infront of the network to stop any un-initiated sessions. This
therefore stops any hammering of ND cache etc. The argument then is
that
the number of packets hitting your firewall / bandwidth starvation
would
be the the alternative line of attack for a DoS/DDos but that is a
completely different issue.
So for /64 subnets used for point-to-points you disable ND, configure
static neighbors and that's the end of it. No ND DDoS.