[121721] in North American Network Operators' Group
Re: Using /126 for IPv6 router links
daemon@ATHENA.MIT.EDU (Owen DeLong)
Mon Jan 25 19:37:07 2010
From: Owen DeLong <owen@delong.com>
In-Reply-To: <CDD0C3CC-8FAD-43D6-A3CF-C495EA6749FE@mironet.ch>
Date: Mon, 25 Jan 2010 16:33:15 -0800
To: Mathias Seiler <mathias.seiler@mironet.ch>
Cc: nanog@nanog.org
Errors-To: nanog-bounces+nanog.discuss=bloom-picayune.mit.edu@nanog.org
On Jan 25, 2010, at 8:14 AM, Mathias Seiler wrote:
> Ok let's summarize:
>=20
> /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
>=20
> <> You can give your peers funny names, like 2001:db8::dead:beef ;)
>=20
> - Prone to attacks (scans, router CPU load)
Unless of course you just block nonexistent addresses in the /64 at each =
end.
> - "Waste" of addresses
> - Peer address needs to be known, impossible to guess with 2^64 =
addresses
>=20
Most of us use ::1 for the assigning side and ::2 for the non-assigning =
side of
the connection. On multipoints, such as exchanges, the popular =
alternative is
to use either the BCD of the ASN or the hex of the ASN for your first =
connection
and something like ::1:AS:N for subsequent connections.
>=20
> /126
> + Only 4 addresses possible (memorable, not so error-prone at =
configuration-time and while debugging)
> + Not prone to scan-like attacks
Equally prone to scan like attacks, but, no ACL required to reduce =
vulnerability.
>=20
> - Not on a bit boundary, so more complicated for ACLs and =85
> - =85 rDNS
> - Perhaps need to renumber into /64 some time.
> - No 64 bits for hosts
>=20
>=20
> /127
> Like /126 but there's an RFC not recommending it and an RFC (draft) =
which revises that non-recommendation.
>=20
>=20
>=20
> On 25 Jan 2010, at 10:14, Matthew Petach wrote:
>=20
>> On Sat, Jan 23, 2010 at 4:52 AM, Mathias Seiler
>> <mathias.seiler@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.
>>>=20
>>> 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.
>>>=20
>>> So what do you think? Good? Bad? Ugly? /127 ? ;)
>>>=20
>>> Cheers
>>>=20
>>> Mathias Seiler
>>> MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel
>>> T +41 61 201 30 90, F +41 61 201 30 99
>>> mathias.seiler@mironet.ch
>>> www.mironet.ch
>>=20
>> 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. =20
>=20
> I think I will go this way. Since we've got the usual /32 assignment I =
have plenty of /64 to "waste".=20
> 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 ;) )
>=20
> This way the configuration and addressing plan is simple and =
understandable to anyone.=20
>=20
>> 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. =20
>=20
> Well I could filter that in hardware with an interface ACL but a /126 =
seems much easier to maintain.=20
>=20
>> 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.
>>=20
>> It seemed like a reasonable approach for us--but there's more than =
one way to
>> skin this particular cat.
>>=20
>> Hope this helps!
>>=20
>=20
> Yes it does. Thanks!
>=20
>=20
> Mathias Seiler
>=20
> MiroNet GmbH, Strassburgerallee 86, CH-4055 Basel
> T +41 61 201 30 90, F +41 61 201 30 99
>=20
> mathias.seiler@mironet.ch
> www.mironet.ch
>=20
