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 M&Ms 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
