In a message written on Mon, Jan 25, 2010 at 05:14:06PM +0100, Mathias Seiler wrote: > 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
/112: + 65535 possible addresses, can use a standardized subnet for everything from a 2 router point to point, to a six address vrrp to vrrp dual router static setup, and beyond. Becomes the universal "edge interface" when the far end is routers not hosts. + rDNS bit boundary++, since it falls on a :. + Limits the effects of scan-like attacks. + Can set aside 1 /64 of /112's for, well, forever. > > > /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 > > <[email protected]> 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 > >> [email protected] > >> 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 > > [email protected] > www.mironet.ch > -- Leo Bicknell - [email protected] - CCIE 3440 PGP keys at http://www.ufp.org/~bicknell/
pgpJhfssxAejV.pgp
Description: PGP signature
