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

[Mark Smith <[e-mail]>]

Hi,

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
   so."



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
reference:
https://www.cs.columbia.edu/~smb/papers/tarp.pdf


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.



Regards,
Mark.