Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability

Mark Smith <> Mon, 20 July 2015 08:42 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id F05211A1A58 for <>; Mon, 20 Jul 2015 01:42:12 -0700 (PDT)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.523
X-Spam-Status: No, score=0.523 tagged_above=-999 required=5 tests=[BAYES_00=-1.9, DKIM_SIGNED=0.1, DKIM_VALID=-0.1, DKIM_VALID_AU=-0.1, FREEMAIL_FROM=0.001, FROM_LOCAL_NOVOWEL=0.5, HK_RANDOM_ENVFROM=0.001, HK_RANDOM_FROM=1, MALFORMED_FREEMAIL=0.001, MISSING_HEADERS=1.021, SPF_PASS=-0.001] autolearn=no
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id IpoUUPukxXq8 for <>; Mon, 20 Jul 2015 01:42:11 -0700 (PDT)
Received: from ( [IPv6:2607:f8b0:4001:c03::232]) (using TLSv1.2 with cipher ECDHE-RSA-AES128-GCM-SHA256 (128/128 bits)) (No client certificate requested) by (Postfix) with ESMTPS id 658681A1A3C for <>; Mon, 20 Jul 2015 01:42:11 -0700 (PDT)
Received: by ietj16 with SMTP id j16so113090196iet.0 for <>; Mon, 20 Jul 2015 01:42:10 -0700 (PDT)
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:cc :content-type; bh=8hz+o6lVlODhkQNLuLyXqK1cET61GV2lpImJtAUkxmk=; b=Ezhjl4oevRJnbcDaaZf4C50raaLZkV+lj+xO/trUTnxsIsBiPMcEa5eM8foBcXiLdD CTuQOUmjBYlHFy6E+D6QgTsL4s5of3GXswSK7xFj6Oz8dmkDpFlUNhWax1rY+JMiEPPF 1YXjoWfcbsw/0LKdyHKrZykNUVjLCWySU3YL0+t9V1YIa8ODaM8Ni4G60wF5oe8aUGha JOgC8cEr54BrbWzOb0UqqtVtnf9hNlQ3R7OV6df1PMsVD+1MfxzwaLPIRi2MrwvCNojB fxdXXRHjJZzzWw0CFxkeZ+235I8/279ND9C/MWjfg/mnZV/cgsI5Bk+mHltSy8TQRWdF nbOg==
X-Received: by with SMTP id u93mt25094242ioi.172.1437381730829; Mon, 20 Jul 2015 01:42:10 -0700 (PDT)
MIME-Version: 1.0
Received: by with HTTP; Mon, 20 Jul 2015 01:41:41 -0700 (PDT)
In-Reply-To: <>
References: <>
From: Mark Smith <>
Date: Mon, 20 Jul 2015 18:41:41 +1000
Message-ID: <>
Content-Type: text/plain; charset=UTF-8
Archived-At: <>
Cc: v6ops list <>,
Subject: Re: [v6ops] new draft: draft-colitti-v6ops-host-addr-availability
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: v6ops discussion list <>
List-Unsubscribe: <>, <>
List-Archive: <>
List-Post: <>
List-Help: <>
List-Subscribe: <>, <>
X-List-Received-Date: Mon, 20 Jul 2015 08:42:13 -0000


Firstly, I would support the WG adoption of this draft.

Some thoughts and comments,

Abstract & Intro

I think stating that it also describes benefits would create a bit
more of an interest in reading it e.g.,

"This document recommends that networks provide general-purpose end
   hosts with multiple global addresses, and describes *the benefits
and * options for doing

3.  Benefits of multiple addresses

Another benefit :

o  Increased robustness. RFC6724 prefers smaller scope addresses over
larger ones, meaning link-local source and destination addresses are
preferred over ULAs, which are preferred over GAUs. As link-local
addresses can be used by applications [RFC4007], this means that
communications robustness is increased when link-local addresses are
used by applications, because the application can continue to operate
regardless of the presence of one or more routers on the link and
other larger scope addresses. Similarly, when an application is using
ULA addresses, it is robust against events that would disrupt the
network's GUA addressing, such as a GUA renumbering event.

o  Future applications (e.g., per-application IPv6 addresses).

- I think "Transient addressing for related processes: Improved
firewalling by using IPv6 and multiple addresses per host." by Peter
M. Gleitz and Steven M. Bellovin would be an excellent example to

5.  Overcoming limits using Network Address Translation

A reference to RFC2993, "Architectural Implications of NAT", somewhere
would be good.

7.  Options for obtaining more than one address

"If the prefix is a /64, it can
      also reshare that prefix with any downstream clients via [RFC7278]
      /64 sharing."

I'm not sure RFC7278 should be suggested as a general purpose method,
as there were a number of kludges/limitations in that method specific
to dealing with the lack of DHCPv6-PD support on the 3GPP devices
e.g., switching from a /64 numbered upstream link to a link-local
upstream link (while the carrier device still thinks the /64 is on the
link) so the /64 could be used on the downstream link. Its basically
presenting methods that are a half way between routing and bridging
between the upstream and downstream links, and that created issues
because it wasn't completely one or the other.

8.1.  Stateful addressing and host tracking

I think it is also worth pointing out that network layer and
link-layer device identifiers/numbers/addresses are not a very
reliable identifier or analogue of people, or more specifically
attackers, because the identifiers/numbers/addresses can change, can
be changed and may not be globally unique, in particularly quite
easily if the attacker is using their own device. Identifying the
individual accessing the network using user/human authentication
methods such as 802.1X and one or more of the what you have, what you
are, or what you know, could provide a audit record of the much
tighter coupling between a human and the network identifiers they use
during the authenticated session.

Nits etc.

2.  Common IPv6 deployment model

There seems to be a reference error here, as RFC6433 is "Requirements
for a Working Group Milestones Tool" and doesn't have a 5.9.4 section.