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
> > <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
> 



-- 
       Leo Bicknell - bickn...@ufp.org - CCIE 3440
        PGP keys at http://www.ufp.org/~bicknell/

Attachment: pgpJhfssxAejV.pgp
Description: PGP signature

Reply via email to