[v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157

"Marksteiner, Stefan" <stefan.marksteiner@joanneum.at> Mon, 24 September 2012 18:03 UTC

Return-Path: <stefan.marksteiner@joanneum.at>
X-Original-To: v6ops@ietfa.amsl.com
Delivered-To: v6ops@ietfa.amsl.com
Received: from localhost (localhost [127.0.0.1]) by ietfa.amsl.com (Postfix) with ESMTP id 6E97D21F86A4 for <v6ops@ietfa.amsl.com>; Mon, 24 Sep 2012 11:03:17 -0700 (PDT)
X-Virus-Scanned: amavisd-new at amsl.com
X-Spam-Flag: NO
X-Spam-Score: 0.984
X-Spam-Level:
X-Spam-Status: No, score=0.984 tagged_above=-999 required=5 tests=[BAYES_40=-0.185, HELO_EQ_AT=0.424, HOST_EQ_AT=0.745]
Received: from mail.ietf.org ([64.170.98.30]) by localhost (ietfa.amsl.com [127.0.0.1]) (amavisd-new, port 10024) with ESMTP id VzPBVVPH8a9E for <v6ops@ietfa.amsl.com>; Mon, 24 Sep 2012 11:03:17 -0700 (PDT)
Received: from rzjgate.joanneum.ac.at (rzjgate.joanneum.ac.at [143.224.185.1]) by ietfa.amsl.com (Postfix) with ESMTP id ABFE121F8686 for <v6ops@ietf.org>; Mon, 24 Sep 2012 11:03:16 -0700 (PDT)
Received: from RZJS078.jr1.local (rzjs078.joanneum.ac.at [143.224.71.19]) by rzjgate.joanneum.ac.at (8.13.8/8.13.8) with ESMTP id q8OI37oH008605 for <v6ops@ietf.org>; Mon, 24 Sep 2012 20:03:07 +0200
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=joanneum.at; s=sel3; t=1348509787; bh=/3GkLc1meiVtLirFawl/VeNu501eBUQc8sRyqwoD4bQ=; h=From:To:Date:Subject:Message-ID:Content-Type: Content-Transfer-Encoding:MIME-Version; b=JLn+/ZNU9StP08ttQfXvbkOsL/p9hZQ4FK/YpSOU9ld3sVI92jG6qxeliVvc/E50V kNuT9VMoAo3ONEC013fajH3nLez0cQhT1o8yvtjEax4hHhFANU0k/UyY6HTFe0B0Wq vWFGHzCk9AyUStOIp1V5nKRpg5fZrD4pWXRwcXcY=
Received: from RZJC1EX.jr1.local ([169.254.2.9]) by RZJS078.jr1.local ([143.224.71.19]) with mapi; Mon, 24 Sep 2012 20:03:07 +0200
From: "Marksteiner, Stefan" <stefan.marksteiner@joanneum.at>
To: IPv6 Ops WG <v6ops@ietf.org>
Date: Mon, 24 Sep 2012 20:03:06 +0200
Thread-Topic: Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157
Thread-Index: AQHNmn5MFe6QqDDTL0+ZXCwWs+E2YQ==
Message-ID: <8A317FD8C00FEE448E52D4EE5B56BB3E0232A086D8FF@RZJC1EX.jr1.local>
Accept-Language: de-DE, de-AT
Content-Language: de-AT
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
acceptlanguage: de-DE, de-AT
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Subject: [v6ops] Operational guidelines for a company/organization IPv6 address scheme supplemental to RFC5157
X-BeenThere: v6ops@ietf.org
X-Mailman-Version: 2.1.12
Precedence: list
List-Id: v6ops discussion list <v6ops.ietf.org>
List-Unsubscribe: <https://www.ietf.org/mailman/options/v6ops>, <mailto:v6ops-request@ietf.org?subject=unsubscribe>
List-Archive: <http://www.ietf.org/mail-archive/web/v6ops>
List-Post: <mailto:v6ops@ietf.org>
List-Help: <mailto:v6ops-request@ietf.org?subject=help>
List-Subscribe: <https://www.ietf.org/mailman/listinfo/v6ops>, <mailto:v6ops-request@ietf.org?subject=subscribe>
X-List-Received-Date: Mon, 24 Sep 2012 18:03:17 -0000

Hi Folks,

RFC5157 presents hazards of sequentially numbering IPv6 networks and technical means (like CGAs and privacy extensions) to mitigate them. Unfortunately these mitigation methods may be deemed difficult to handle for administrators (SEND may be too complicated to implement, PEs bring difficulties to keep track of IP addresses). Therefore there may be demand for an addressing scheme (rather than a technical method) that makes IPv6 addresses easy to predict for tech staff but difficult to do so by outsiders, building a low-end supplement for the methods mentioned in RFC5157.

What I have in mind is an simple mental arithmetic operation, which generates an address out of a company fixed part plus a sequential number for host. Alternatively a Hash-Operation consisting again of a secret organisational plus a sequential host number. The first requires the scheme to be slightly different in every organisation in order to have a negative impact on IPv6 scanning from external sources, the second is more secure but requires an internal web site or smartphone app in order for field engineers to calculate an address out of the sequential information.

My question is, in your opinion, would this be worthwhile to be formulated as an ID an be drafted or does this idea sound absurd?


Cheers,

Stefan