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

From: [email-masked]
Date: Wed, 18 Feb 2015 12:57:28 -0800

A New Internet-Draft is available from the on-line Internet-Drafts directories.
 This draft is a work item of the IPv6 Operations Working Group of the IETF.

        Title           : Some Design Choices for IPv6 Networks
        Authors         : Philip Matthews
                          Victor Kuarsingh
	Filename        : draft-ietf-v6ops-design-choices-04.txt
	Pages           : 17
	Date            : 2015-02-18

Abstract:
   This document presents advice on certain routing-related design
   choices that arise when designing IPv6 networks (both dual-stack and
   IPv6-only).  The intended audience is someone designing an IPv6
   network who is knowledgeable about best current practices around IPv4
   network design, and wishes to learn the corresponding practices for
   IPv6.

The IETF datatracker status page for this draft is:
https://datatracker.ietf.org/doc/draft-ietf-v6ops-design-choices/

There's also a htmlized version available at:
http://tools.ietf.org/html/draft-ietf-v6ops-design-choices-04

A diff from the previous version is available at:
http://www.ietf.org/rfcdiff?url2=draft-ietf-v6ops-design-choices-04

Please note that it may take a couple of minutes from the time of submission
until the htmlized version and diff are available at tools.ietf.org.

Internet-Drafts are also available by anonymous FTP at:
ftp://ftp.ietf.org/internet-drafts/

---

From: Philip Matthews <[email-masked]>
Date: Wed, 18 Feb 2015 16:23:57 -0500

Hi Everyone:

Victor and I just posted this update, which addresses the comments raised in Honolulu, and generally cleans up the draft. No really big changes, but lots of little changes.  

A few highlights:
* The wording in the title, abstract and introduction has been modified to narrow the scope of the document. The document no longer claims to cover all choices around designing IPv6 network, but just certain choices that are routing-related. This always been the de-facto situation, but now the introduction etc reflect this.  Some additional sentences saying "X is not covered here, see doc Y" have also been added. Thanks to Dave Thaler and Eric Vyncke for suggestions in this area.
* The text around using BGP sessions to link-local addresses has been updated after some email exchanges with Francis Dupont (co-author of RFC 2545), who observed that RFC 2545 forbids this (even though most vendors support it).
* The text around security of link-local addresses has been modified since some routers forward packets containing link-local source addresses. Thanks to Jen Lincova for pointing this out.
* The initial few sentences in a number of sections has been changed in an attempt to improve the document flow.
* The document now has a security considerations section. There is nothing earth-shaking here; Victor and I elected to just point to some existing documents that are relevant to the choices discussed in the document.

There were many other small changes to try to improve document wording and clarity, and I thank a number of my colleagues at Alcatel-Lucent for their helpful reviews.

Overall, Victor and I feel this new version is much improved, and we hope you guys will too. As always, we welcome further comments.

- Philip

On 2015-02-18, at 15:57 , [email-masked] wrote:

> _______________________________________________
> v6ops mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/v6ops
>

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 19 Feb 2015 11:51:23 +1300

>  It is very difficult to impossible to ping a link-local address
>  from a device that is not on the same subnet. This is a	
>  troubleshooting disadvantage, though it can also be viewed as a
>  security advantage.

I am puzzled by how it could ever be possible at all.
Link-local addresses are by definition meaningless off
the link in question, and they should never even be known by
any node on another link. (And of course it gets even more
complicated on devices with several interfaces, such as routers,
since a link local address is only meaningful with a ZoneID,
and that is a node-specific value, meaningless to other nodes
on the *same* link.)

   Brian

---

From: Philip Matthews <[email-masked]>
Date: Thu, 19 Feb 2015 14:07:36 -0500

Hi Brian:

I personally do not know of a way to get a packet to a link-local address on a different link unless the routers in-between are very very broken. However, I think the discovery a couple of years ago that most routers happily forwarded packets with link-local _source_ addresses surprised people, even though in hindsight it should not have. And security folk (and researchers!) are always leery of absolute statements like "This is impossible". So when Jen Lincova requested that we soften the wording around link-local address security (in her comments at the mike during the Honolulu session), I was happy to comply.  Hence the text below, and similar changes in a couple of other spots.

- Philip

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 20 Feb 2015 02:47:09 +0000 (UTC)

Hi,

I'd like to see less implication that the choice between a single ULA and a single global prefix on a link is exclusive e.g.,

"The use of ULAs instead of globally-routed
addresses is also not discussed;"

"b.  Have global (or unique-local) addresses assigned in addition to
link-locals?"

People really need to get over this (somewhat IPv4) idea that there can only be one prefix on a link (of course, in IPv6 there are always link-locals too, but the limit on link prefixes isn't two either.).

"Proper" support for multiple prefixes on a link is one of IPv6's enhanced capabilities over IPv4's. People should be encouraged to take advantage of it if it would be useful to them.

Regards,
Mark.

----- Original Message -----
From: Philip Matthews <[email-masked]>
To: v6ops list <[email-masked]>
Cc: 
Sent: Thursday, 19 February 2015, 8:23
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt

Hi Everyone:

A few highlights:

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Thu, 19 Feb 2015 22:09:48 -0500

Mark:

Thanks for your comments.  Replies inline.

Philip

> addresses is also not discussed;"

How about I just remove the words "instead of globally-routed addresses" from the sentence?

> People really need to get over this (somewhat IPv4) idea that there can only be one prefix on a link (of course, in IPv6 there are always link-locals too, but the limit on link prefixes isn't two e…

Your point is a good one, but I don't see how the quoted sentence implies that there is just one address GUA (or ULA). It does say "addresses".
I admit I may have written the section thinking of just a single GUA or ULA (in addition to the LLA), but as I re-read it, I don't see any place where that is stated or implied.

> "Proper" support for multiple prefixes on a link is one of IPv6's enhanced capabilities over IPv4's. People should be encouraged to take advantage of it if it would be useful to them.

I agree, though it is not often I find an situation where I can take advantage of this.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 20 Feb 2015 03:13:31 +0000 (UTC)

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)

----- Original Message -----
From: Philip Matthews <[email-masked]>
To: v6ops list <[email-masked]>
Cc: 
Sent: Thursday, 19 February 2015, 8:23
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt

Hi Everyone:

A few highlights:

- Philip

---

From: Mark ZZZ Smith <[email-masked]>
Date: Fri, 20 Feb 2015 04:13:07 +0000 (UTC)

Hi,

----- Original Message -----
From: Philip Matthews <[email-masked]>
To: Mark ZZZ Smith <[email-masked]>
Cc: v6ops list <[email-masked]>
Sent: Friday, 20 February 2015, 14:09
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt

Mark:

Philip

/I think that would do it.

/I think 'or' in most text is interpreted as an exclusive or. I think the brackets around the 'or unique-local' further make it read like it is implying one or the other.

/"Have global and/or unique-local addresses assigned in addition to link-locals" would probably read better.

/One thought about when to use 'addresses' verses 'prefixes'. I and I think a lot of other people think at the level of assigning a prefix to a link, with the assumption and implication that all interfaces attached to the link would normally have addresses from each of the on-link prefixes. The case where link attached interfaces wouldn't have addresses from all of the present prefixes would be an exception (e.g., in IPv4, when the subnet is too small, or in IPv6, perhaps when migrating a prefix off of a link, or when the prefix has been configured on a stateful DHCPv6 server, but not all hosts have asked for addresses from it.)

/ "2.1.2.  Interfaces with Only Link-Local Addresses?" seems to be written from with the unstated assumption that all interfaces will have addresses from all on-link prefixes. As that isn't an IPv6 requirement, I think it would be best to state that assumption, and that there may be situations where that is not the case. 

/ More broadly, it seems that although interfaces are where addresses are assigned, this whole topic is really about whether to assign certain types of prefix to a link or not (and therefore implicitly all link-attached interfaces), rather than to individual interfaces or not. So I wonder if it might be a bit clearer if the perspective was changed slightly from addresses assigned to interfaces (implicitly all interfaces on a link) to prefixes assigned to links, and then stating the assumption that in most cases all interfaces will get addresses from all on-link prefixes. 

/ I think the case for ULAs is when link-local reachability is too small, and global scope reachability is too large, because it reduces security. For example, addressing internal only servers/services (e.g., network printers), or network equipment management addresses.

Regards,
Mark.

---

From: Philip Matthews <[email-masked]>
Date: Sat, 21 Feb 2015 22:40:39 -0500

> /I think that would do it.
It now reads:
	The details of ULA usage is also not discussed; for this the reader is referred to ...
> /"Have global and/or unique-local addresses assigned in addition to link-locals" would probably read better.
DONE

> / More broadly, it seems that although interfaces are where addresses are assigned, this whole topic is really about whether to assign certain types of prefix to a link or not (and therefore implic…

Interesting comment.  However, I confess that I am not seeing how this section might be rewritten.  Note that this section is just trying to contrast zero vs non-zero numbers of GUAs and/or ULAs, and not discuss one vs two vs ... GUAs/ULAs.
Perhaps you could give an example or two of rewritten sentences?

---

From: Philip Matthews <[email-masked]>
Date: Sun, 22 Feb 2015 18:12:47 -0500

Mark:

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.

---

From: Mark ZZZ Smith <[email-masked]>
Date: Mon, 23 Feb 2015 09:01:39 +0000 (UTC)

Hi Philip,

----- Original Message -----
From: Philip Matthews <[email-masked]>
To: Mark ZZZ Smith <[email-masked]>
Cc: v6ops list <[email-masked]>
Sent: Sunday, 22 February 2015, 14:40
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-04.txt

> Thanks for your comments.  Replies inline.
<snip> 
DONE

/There is a loose ')' in there though ;-)

/ I understand what it is trying to contrast, and I'd describe it as contrasting whether to have just a link-local prefix on the link, or whether to add one or more GUA and/or ULA prefixes to the link. 

/ If that description is correct, then it is assuming that all interfaces attached to the link will get addresses from what ever prefixes are present on the link. Yet the text, by being 'Interface' oriented', rather than 'link oriented' implies that it is a decision that would be made on a per-interface rather than a per-link basis. Technically it can be made on a per-Interface basis, but commonly isn't.

/ How about something like this:

2.1.2. Link-local prefix only links?

The Link-local prefix is automatically present on links on which IPv6 is operating over, as all IPv6 interfaces are required to have a Link-Local address [RFC4291]. Link-local addresses are or can be used for IPv6 operation or applications when the source and destination are on-link [RFC4007][RFC5942][RFC6724]

To provide on-link nodes with the ability to reach off-link destinations, or for off-link sources to reach on-link destinations, one or more GUA and/or ULA prefixes need to be present on the link. Note that although it is not required, it is common and likely that the attached nodes' link-attached interfaces will have addresses from all of the present GUA and/or ULA prefixes, as the nodes will be likely to automatically participate in the SLAAC and/or stateful DHCPv6 address configuration protocols.

There are two advantages of interfaces that only have Link-Local addresses.  The first
advantage is ease of configuration.  In a network with a large number
of Link-Local only interfaces, the operator can just enable an IGP on each
router, without going through the tedious process of assigning and
tracking the addresses for each interface.  The second advantage is
security.  Since packets with Link-Local destination addresses should
not be routed, it is very difficult to attack the associated
nodes from an off-link device.  This implies less effort around
maintaining security ACLs.

(etc.)

Regards,
Mark.