Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt

Philip Matthews <> Sun, 22 February 2015 23:12 UTC

Return-Path: <>
Received: from localhost ( []) by (Postfix) with ESMTP id 2E33F1A0092 for <>; Sun, 22 Feb 2015 15:12:52 -0800 (PST)
X-Virus-Scanned: amavisd-new at
X-Spam-Flag: NO
X-Spam-Score: 0.8
X-Spam-Status: No, score=0.8 tagged_above=-999 required=5 tests=[BAYES_50=0.8, RCVD_IN_DNSWL_NONE=-0.0001] autolearn=ham
Received: from ([]) by localhost ( []) (amavisd-new, port 10024) with ESMTP id mro_aqwceurK for <>; Sun, 22 Feb 2015 15:12:50 -0800 (PST)
Received: from ( []) by (Postfix) with ESMTP id 90CC01A008B for <>; Sun, 22 Feb 2015 15:12:50 -0800 (PST)
Received: from [] (helo=[]) by with esmtpa (Exim 4.72) (envelope-from <>) id 1YPfhh-0005wp-Ac; Sun, 22 Feb 2015 18:12:49 -0500
Mime-Version: 1.0 (Apple Message framework v1085)
Content-Type: text/plain; charset=us-ascii
From: Philip Matthews <>
In-Reply-To: <>
Date: Sun, 22 Feb 2015 18:12:47 -0500
Content-Transfer-Encoding: quoted-printable
Message-Id: <>
References: <> <>
To: Mark ZZZ Smith <>
X-Mailer: Apple Mail (2.1085)
X-Authenticated: philip_matthews - ([]) []
Archived-At: <>
Cc: v6ops list <>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt
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: Sun, 22 Feb 2015 23:12:52 -0000


I agree with you that, with the publication of RFC 7217, we are likely to see the "swapping-out" issue fade from importance as the years go on. However, I feel that today it is definitely an issue and something that is important to point out, even if not all routers today suffer from it (hence the wording "On some devices ..." in the bullet point).

To point out that RFC 7217 has addressed this problem, I have added the following sentence to the end of the bullet point:
              This problem should fade away over time as more
              and more routers select interface identifiers according to the
              rules in [RFC7217].

Regarding the term "unnumbered". In my opinion, the use of this term for a link or interface that has only a link-local IPv6 address is pretty established by now. I am hesitant to try to introduce a new term in this document, considering that any such new term would only be a very minor little aside.
In case the reader is not familiar with this term, the document tries to make this usage pretty obvious with the following wording:

   Should the interface:
   a.  Use only link-local addresses ("unnumbered"), OR
   b.  Have global and/or unique-local) addresses assigned in addition
       to link-locals?
   There are two advantages of unnumbered interfaces.

On 2015-02-19, at 22:13 , Mark ZZZ Smith wrote:

> Regarding these text about link-local only links:
> "o  On some devices, by default the link-layer address of the
> interface is derived from the MAC address assigned to interface.
> When this is done, swapping out the interface hardware (e.g.
> interface card) will cause the link-layer address to change.  In
> some cases (peering config, ACLs, etc) this may require additional
> changes.  However, many devices allow the link-layer address of an
> interface to be explicitly configured, which avoids this issue."
> And other similar text about LLs being derived from MAC addresses,
> I think it is worth referencing RFC7217, "A Method for Generating Semantically Opaque Interface Identifiers
> with IPv6 Stateless Address Autoconfiguration (SLAAC)", as one of the use cases it is intended to address is the case of interface swaps changing SLAAC addresses, which includes link-local addresses, as they're SLAAC addresses. (See Appendix A of RFC7217)
> Actually, I think it would be better to stop using "Unnumbered Interfaces"/"Unnumbered Links" because factually it is incorrect in IPv6. Something like "Link-Local Only Interfaces" would be better, and encourage people to remembering that link-local addresses are always present in IPv6. (and perhaps start to get people into the mindset that link-locals may also be used for application traffic too, as per RFC4007 and RFC6724)