[184502] in North American Network Operators' Group

home help back first fref pref prev next nref lref last post

Re: /27 the new /24

daemon@ATHENA.MIT.EDU (Mel Beckman)
Sun Oct 4 14:15:17 2015

X-Original-To: nanog@nanog.org
From: Mel Beckman <mel@beckman.org>
To: Sander Steffann <sander@steffann.nl>
Date: Sun, 4 Oct 2015 18:15:04 +0000
In-Reply-To: <0A996CED-4AF7-4193-8AA2-701AFB4C26A7@steffann.nl>
Cc: "nanog@nanog.org" <nanog@nanog.org>
Errors-To: nanog-bounces@nanog.org

Stefann,

You're right. I remember hearing rumblings of vendors requesting this chang=
e, mostly because embedded processors of the time had difficulty performing=
 well with IPv6. I see that in 2011 rfc6434 lowered IPSec from "must" to "s=
hould". Nevertheless, plenty of products produced before 2011 included IPSe=
c and the vast majority of IPv6-capable nodes on the Internet have it today=
. Performance is no longer an issue.=20

 -mel beckman

> On Oct 4, 2015, at 8:58 AM, Sander Steffann <sander@steffann.nl> wrote:
>=20
> Hi,
>=20
>> Op 4 okt. 2015, om 16:52 heeft Mel Beckman <mel@beckman.org> het volgend=
e geschreven:
>>=20
>> If it doesn't support IPSec, it's not really IPv6. Just as if it failed =
to support any other mandatory IPv6 specification, such as RA.
>=20
> I think you're still looking at an old version of the IPv6 Node Requireme=
nts. Check https://tools.ietf.org/html/rfc6434#section-11, specifically thi=
s bit:
>=20
> """
> Previously, IPv6 mandated implementation of IPsec and recommended the key=
 management approach of IKE.  This document updates that recommendation by =
making support of the IPsec Architecture a SHOULD for all IPv6 nodes.
> """
>=20
> This was published in December 2011.
>=20
> Cheers,
> Sander
>=20

home help back first fref pref prev next nref lref last post