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

From: Mark Smith <[email-masked]>
Date: Tue, 1 Nov 2016 18:45:01 +1100

On 30 October 2016 at 05:34, Philip Matthews <[email-masked]> wrote:
> On 2016-10-28, at 18:00 , Mark Smith wrote:
>
<snip>
>
>
> Mark:
>
> You quoted the following sentences from the draft:
>
> "In IPv6, all interfaces are assigned a Link-Local Address (LLA) [ref]. The
> Link-Local address can only be used for communicating with devices that are
> on-link, so often additional addresses are assigned which are able to
> communicate off-link. These additional addresses can be one of three types:"
>
>
> These sentences were deliberately phrased that way to suggest that multiple
> addresses per interface are possible. However, as I now re-read them, I see
> that they are also consistent with the interpretation that at most a single
> additional address is permitted  per interface, though this was never the
> intention.
>
> To avoid the idea that an interface can have at most two addresses, I
> propose to change the wording to the following:
>
> "In IPv6, an interface is always assigned a Link-Local Address (LLA) [REF].
> The link-local address can only be used for communicating with devices that
> are on-link, so often one or more additional addresses are assigned which
> are able to communicate off-link. This additional address or addresses can
> be one of three types:"
>
>

That's better.

>
> Regarding lifetimes, this section is only about addresses used on loopbacks
> and router-to-router links, as is stately clearly in the first paragraph of
> the section.  This restriction is consistent with the overall scope of this
> document, which only talks about routing-related design choices, and avoids
> any discussion of end host addresses in enterprises, which is a bit of a
> minefield. In this regard, I personally don't know of any router
> implementation that allows the addresses on a router-to-router links to age
> out. Do you?
>

Addresses given to residential gateways (i.e., routers) via SLAAC or
DHCPv6 are likely to not have infinite lifetimes.

I worked on a production IPv6 residential broadband deployment back in
2009/2010, we used SLAAC for the customer link so that customers could
either plug a PC directly into the link or a CPE. DHCPv6-PD is used to
provide a /56 if the CPE requests it. Both the SLAAC /64 and the
DHCPv6-PD /56 have non-infinite lifetimes.

> Regarding your blog post, I am confused. It seems to be about NAT, which is
> not discussed in this document, so I don't see how it applies to this
> document.
>

The FAQ examples are ones that not only show why NAT isn't necessary,
but also how to leverage IPv6 capabilities that don't or don't
practically exist in IPv4.

I think an IPv6 mindset is "these are IPv6's capabilities; how can I
take advantage of them to my operational and network end-users
advantage". An IPv4 mindset applied to an IPv6 network is "this is how
we do it in IPv4, so I'll do it the same way in IPv6." The latter is
the more familiar, and IPv6 can accommodate it, however it is missing
opportunities to take much more advantage of IPv6.

Here's an example:

"2.3.1.  Link-Local Next-Hop in a Static Route?"

...

"   Furthermore, many network operators are concerned about the
   dependency of the default link-local address on an underlying MAC
   address, as described in the previous section.

   Today most operators use GUAs as next-hop addresses."

The concern about MAC addresses in LLs is quite valid, however I'd say
the solution of using GUAs/ULAs for NH addresses is IPv4 thinking.

The IPv6 way would be to set static LLA addresses on router
interfaces, and then continue to use LLAs as NH addresses, because
they decouple link scope next hops from GUA/ULA prefixes. In this
configuration, if you then change a router's interface GUA or ULA
address, you don't immediately invalidate any remote static routes
pointing to the local interface. That makes a GUA or ULA renumbering
event less disruptive and less work.

(RFC7217 / stable opaque IIDs specifically mentions that it applies to
LLAs and suggests using system slot/ports or Interface Indexes as
options for the Net_Iface parameter to decouple the stable opaque IIDs
from link-layer addresses. I think suggested this at the time, and the
router interface module swap/LLA MAC address dependency issue was
exactly my motivation.)

Regards,
Mark.

---

From: Victor Kuarsingh <[email-masked]>
Date: Wed, 2 Nov 2016 21:26:13 -0400

On 2016-10-28 6:00 PM, Mark Smith wrote:
>
> There's still IPv4 mentality here:
>
> "In IPv6, all interfaces are assigned a Link-Local Address (LLA) 
> [ref]. The Link-Local address can only be used for communicating with 
> devices that are on-link, so often additional addresses are assigned 
> which are able to communicate off-link. These additional addresses can 
> be one of three types:"
>
> The last sentence is reading GUA PI xor GUA PA xor ULA, implying IPv6 
> interfaces only support a single LLA and a single other address, which 
> is not the case. I think it is also implying that address assignments 
> to nodes are semi-permanent rather than more dynamic, as supported by 
> IPv6 address lifetimes.
>
I have heard this sentiment noted a few times - re: "IPv4 mentality".  
However, I am not sure that paints the entire picture of how networks 
are built and how addresses are applied to network equipment.  In the SP 
world, I would say that addressing, although very important for services 
that are provided on such networks, is only one of many factors that 
determines how things are setup. I would say some of the reasoning for 
how things are addressed is also much about current operational thinking 
and considerations which are addressing agnostic.

When building out networks, geography, access technologies, spectrum, 
underlay technologies [e.g. MPLS], overlay requirements, and other such 
components play major factors in how stuff is built and/or but 
together.  Many of these are the things that cost the most money and 
therefore get the most attention.

Back to addressing, I would say some of the reasoning behind not 
stacking a bunch of IPv6 addresses on links on intermediary network 
nodes is less about how IPv4 was applied before and as much about 
operational considerations.  Even with IPv4, one could overlay addresses 
as well (was not as clean as IPv6, but it could be done). This was done 
at the network edge many times, like in Cable access networks, but 
was/is not popular in the middle of the network.

Outside of some specific use cases, operators need to consider the 
functional benefits of what you get from stacking addresses with the 
drawbacks related to additional administration and/or maintenance (one 
typically needs to track addresses used and connect them to DNS and/or 
internal tools).  If I were to consider a very large network with say 
1000s or 10Ks of links, tracking all these additional addresses would 
need to be justified with some significant operational gains to warrant 
applying them.  Also, if I applied more addresses to interfaces (e.g. 
part of an address overlay), I also increase my potential surface area 
for what I need to filter / protect against (very common practice to 
limit exposure to infrastructure nodes).

I am not arguing against using multiple addresses on network interfaces 
(e.g. multiple GUAs for example) per se, but disagree with the notion 
that not doing so is inherently based on IPv4 thinking.  There are 
examples where I have done this (or seen it done) and many example where 
I did not (and it had nothing to do with IPv4 thinking).

All that said I am not against some text the clarifies that one is not 
limited to just an LLA, or an LLA plus a single instance of a GUA or 
ULA.  However, one of the premises of the document is that we are 
writing for network designers, and these folks should familiarize 
themselves with IPv6.  Therefore, to me, noting that you can add a GUA 
or ULA to an interface that has a LLA does not inherently limit one to 
only adding one.  Granted, if folks think it's important to explicitly 
call that out, I have no strong objection either.

> If this draft is reflecting how people are deploying IPv6, then I 
> think it is reflecting an IPv4 mentality applied to IPv6. I don't 
> think that is a very useful thing to publish as advice on deploying 
> IPv6, as it isn't identifying opportunities to take advantages that 
> IPv6 provides and IPv4 does not.
>
I think this was addressed by Philip's comments.  The draft is 
concentrated on the network, not the edge hosts.

> If we want to go down that path, then I think it would be better to 
> state that this is a snapshot of current deployments, point out that 
> they are IPv4 oriented IPv6 deployments, and identify capabilities of 
> IPv6 that are not being taken advantage of that would provide 
> operational and end-user application advantages.
>
> The cost of developing and deploying IPv6 has been and will continue 
> to high for quite a while, so I think we should be looking to take 
> advantage of its capabilities as often as possible to maximise the 
> return on those costs. Some of what I wrote here is taking a "how to 
> do IPv6 better than IPv4" perspective which I think is the one the 
> v6ops group should be taking.
>
Agreed IPv6 is not normally cheap to retrofit into the network, but I am 
not sure I see any strong advantages of stacking addresses on network 
router interfaces as a generic practice, that provide subsequent 
benefits which compensate for massive IT and technology upgrade spends.  
I see some functional benefits in some cases, but it's not a clear bread 
winner.  I wish this was not the case as it would have made business 
cases I made years ago much easier.

However, I do like the overall notion of the v6ops group looking to 
document ways to improve services by doing "IPv6 better".  I see 
benefits of documenting this separately, showing uses cases highlighting 
functional benefits and improvement to services.

regards,

Victor K

> https://blog.apnic.net/2016/10/27/trouble-nat-part-3/
>
> Regards,
> Mark.
>
>