Using /126 for IPv6 router links

Mon Jan 25 16:14:06 UTC 2010

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.seiler at 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.seiler at 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.seiler at mironet.ch
www.mironet.ch

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 5021 bytes
Desc: not available
URL: <http://mailman.nanog.org/pipermail/nanog/attachments/20100125/a948cbe4/attachment.bin>