Ok let's summarize:
/64:
+ Sticks to the way IPv6 was designed (64 bits host part)
+ Probability of renumbering very low
+ simpler for ACLs and the like
+ rDNS on a bit boundary
You can give your peers funny names, like 2001:db8::dead:beef ;)
- Prone to attacks (scans, router CPU load)
- Waste of addresses
- Peer address needs to be known, impossible to guess with 2^64 addresses
/126
+ Only 4 addresses possible (memorable, not so error-prone at
configuration-time and while debugging)
+ Not prone to scan-like attacks
- Not on a bit boundary, so more complicated for ACLs and …
- … rDNS
- Perhaps need to renumber into /64 some time.
- No 64 bits for hosts
/127
Like /126 but there's an RFC not recommending it and an RFC (draft) which
revises that non-recommendation.
On 25 Jan 2010, at 10:14, Matthew Petach wrote:
On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler
mathias.sei...@mironet.ch wrote:
Hi
In reference to the discussion about /31 for router links, I d'like to know
what is your experience with IPv6 in this regard.
I use a /126 if possible but have also configured one /64 just for the link
between two routers. This works great but when I think that I'm wasting 2^64
- 2 addresses here it feels plain wrong.
So what do you think? Good? Bad? Ugly? /127 ? ;)
Cheers
Mathias Seiler
MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel
T +41 61 201 30 90, F +41 61 201 30 99
mathias.sei...@mironet.ch
www.mironet.ch
As I mentioned in my lightning talk at the last NANOG, we reserved a
/64 for each
PtP link,
but configured it as the first /126 out of the /64. That
gives us the most
flexibility for expanding to the full /64 later if necessary, but
prevents us from being
victim of the classic v6 neighbor discovery attack that you're prone
to if you configure
the entire /64 on the link.
I think I will go this way. Since we've got the usual /32 assignment I have
plenty of /64 to waste.
If I continue assigning a /48 to every customer I can set apart a /64 for each
PtP link and still have room to grow for a very long time (I'm not taking into
account the assignment of IPv6 addresses to high amounts of MMs so far ;) )
This way the configuration and addressing plan is simple and understandable to
anyone.
All someone out on the 'net needs to do
is scan up through
your address space on the link as quickly as possible, sending single packets
at
all the non-existent addresses on the link, and watch as your router CPU
starts
to churn keeping track of all the neighbor discovery messages, state table
updates, and incomplete age-outs.
Well I could filter that in hardware with an interface ACL but a /126 seems
much easier to maintain.
With the link configured as a /126, there's
a very small limit to the number of neighbor discovery messages, and the
amount
of state table that needs to be maintained and updated for each PtP link.
It seemed like a reasonable approach for us--but there's more than one way to
skin this particular cat.
Hope this helps!
Yes it does. Thanks!
Mathias Seiler
MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel
T +41 61 201 30 90, F +41 61 201 30 99
mathias.sei...@mironet.ch
www.mironet.ch
smime.p7s
Description: S/MIME cryptographic signature
