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

From: [email-masked]
Date: Fri, 28 Oct 2016 14:04:35 -0700

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

        Title           : Some Design Choices for IPv6 Networks
        Authors         : Philip Matthews
                          Victor Kuarsingh
	Filename        : draft-ietf-v6ops-design-choices-11.txt
	Pages           : 26
	Date            : 2016-10-28

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:
https://tools.ietf.org/html/draft-ietf-v6ops-design-choices-11

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

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: Fri, 28 Oct 2016 17:09:10 -0400

Folks:

We have just published the -11 revision of the Design Choices draft.

The main change in this revision is totally new text for the Addresses section. We have totally rewritten this section after the comments we received in Yokohama (yes, one year ago, sigh). We also took into account the comments made by Brian Carpenter about 10 days ago, though we didn't structure the section the way he suggested.

The other significant change the addition of the scenario of using OSPFv3 to route both IPv4 and IPv6.  Thanks to John Mann for pointing out this omission. Unfortunately, we don't know of anyone actually running this combination in a non-trivial production network -- email the authors privately if you have data you are willing to share.

It is our belief that this revision addresses the concerns people had with previous versions, and that all that is required is a perhaps a few minor tweaks before it is finished off.  Let us know if you agree or disagree.

This draft has been in the works for a long time.  Hopefully we are getting close to the end.

- Philip and Victor

On 2016-10-28, at 17:04 , [email-masked] wrote:

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

---

From: Mark Smith <[email-masked]>
Date: Sat, 29 Oct 2016 09:00:45 +1100

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.

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.

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.

https://blog.apnic.net/2016/10/27/trouble-nat-part-3/

Regards,
Mark.

On 29 Oct. 2016 8:09 am, "Philip Matthews" <[email-masked]> wrote:
> The main change in this revision is totally new text for the Addresses
section. We have totally rewritten this section after the comments we
received in Yokohama (yes, one year ago, sigh). We also took into account
the comments made by Brian Carpenter about 10 days ago, though we didn't
structure the section the way he suggested.
>
> The other significant change the addition of the scenario of using OSPFv3
to route both IPv4 and IPv6.  Thanks to John Mann for pointing out this
omission. Unfortunately, we don't know of anyone actually running this
combination in a non-trivial production network -- email the authors
privately if you have data you are willing to share.
>
> It is our belief that this revision addresses the concerns people had
with previous versions, and that all that is required is a perhaps a few
minor tweaks before it is finished off.  Let us know if you agree or
disagree.

---

From: "Ackermann, Michael" <[email-masked]>
Date: Fri, 28 Oct 2016 23:25:18 +0000

As someone trying very hard to get Enterprises to implement IPv6 (and not succeeding),  anything that points out advantages over IPv4 is very compelling.
So a +1 on Marks comments.

From: v6ops [mailto:[email-masked]] On Behalf Of Mark Smith
Sent: Friday, October 28, 2016 6:01 PM
To: Philip Matthews <[email-masked]>
Cc: v6ops list <[email-masked]>
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-11.txt

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

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.

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.

Regards,
Mark.

On 29 Oct. 2016 8:09 am, "Philip Matthews" <[email-masked]<mailto:[email-masked]>> wrote:
> On 2016-10-28, at 17:04 , [email-masked]<mailto:[email-masked]> wrote:
>
> >
> > until the htmlized version and diff are available at tools.ietf.org<http://tools.ietf.org>.
> >
> > [email-masked]<mailto:[email-masked]>
> [email-masked]<mailto:[email-masked]>

The information contained in this communication is highly confidential and is intended solely for the use of the individual(s) to whom this communication is directed. If you are not the intended recipient, you are hereby notified that any viewing, copying, disclosure or distribution of this information is prohibited. Please notify the sender, by electronic mail or telephone, of any unintended receipt and delete the original message without making any copies.
 
 Blue Cross Blue Shield of Michigan and Blue Care Network of Michigan are nonprofit corporations and independent licensees of the Blue Cross and Blue Shield Association.

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 29 Oct 2016 06:44:07 +0200 (CEST)

> So a +1 on Marks comments.

I am preparing an IPv6 related presentation, and on one slide I have:

---
With A=1, M=1 a device can have address(es):
  EUI64 based address
  Privacy extensions based address(s)
  DHCPv6 IA_NA / IA_TA (one or more each)
  50 addresses that it (randomly) chose for itself from on-link /64 prefix
  Link-Local
  /56 delegated to it by means of DHCPv6-PD

This is perfectly valid deployment scenario
---

Not sure though that a lot of people will feel that this is progress 
(they're used to have more control), but it's important to make people 
understand that this is how IPv6 was designed.

-- 
Mikael Abrahamsson    email: [email-masked]

---

From: Philip Matthews <[email-masked]>
Date: Sat, 29 Oct 2016 14:34:21 -0400

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

Mark:

> "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 as…

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:"

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? 

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.

- Philip

---

From: Philip Matthews <[email-masked]>
Date: Sat, 29 Oct 2016 14:38:27 -0400

Mikael:

Is this something you would like to see happen on a router-to-router interface in a network near you?

- Philip

On 2016-10-29, at 0:44 , Mikael Abrahamsson wrote:

> Not sure though that a lot of people will feel that this is progress (they're used to have more control), but it's important to make people understand that this is how IPv6 was designed.
> 
> --

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sat, 29 Oct 2016 21:27:36 +0200 (CEST)

> Is this something you would like to see happen on a router-to-router interface in a network near you?

Nope.

I never read the draft before and didn't realise that this only covered 
router-router links.

Now that I have read some of it, I would like to comment that I think this 
document doesn't present its "within an ISP/enterprise, only 
router-to-router link" scope limitation well enough in its introduction 
paragraph.

btw typo: "when designing a Pv6-only or dual-stack network." , first 
sentence in the introduction.

---

From: Brian E Carpenter <[email-masked]>
Date: Sun, 30 Oct 2016 11:27:38 +1300

Hi,

Thanks for the rewrite.

> 2.1.  Addresses
...
> does not cover the choice of addresses
> for end hosts.

That's incorrect because everything else up to the start of subsection 2.1.1
is about site-wide addressing choices. Isn't it just subsection 2.1.1 that is
specific to router addressing?

The fact is that you can't completely separate the addressing choices for routers
from the addressing choices for subnets and hosts. So that aspect of your document
scoping is fundamentally illogical. You can wordsmith around it, but the Abstract
and Introduction need to make it clear that router addressing choices depend on
site-wide addressing choices. (For example, if you are running two site-wide
PA GUA prefixes, you could still choose to use ULAs for all router interfaces, or
one of the GUA prefixes.)

> These disadvantages mean that some
> smaller organization may not qualify or be willing to pay for these
> addresses.

Once we are talking about tens of millions of sites, this will not be 'some'.
s/some/many/

> ULAs ...
> Though there is currently no
> document that describes these situations,

I believe that RFC4864 is relevant.

> Not discussed in this document is the possibility of using the
> technology described in RFC 6296 to work around some of the
> limitations of PA GUAs and ULAs.

Then why mention it at all? It's only an experimental RFC.

> 2.1.1.  Where to Use Addresses

s/Where to Use Addresses/Addresses for Router Interfaces/

> Option (a) means that the router cannot be reached (ping, management,
> etc.) from farther than one-hop away.  The authors are not aware of
> anyone using this option.

I think people have seen LLAs in traceroutes. Not sure where that really
comes from, but in any case it's a strong argument for allocating GUAs
or ULAs to routers. In any case, ICMP MUST NOT be sourced from LLAs.

Regards
   Brian Carpenter

---

From: Philip Matthews <[email-masked]>
Date: Sat, 29 Oct 2016 21:19:17 -0400

On 2016-10-29, at 15:27 , Mikael Abrahamsson wrote:

> Now that I have read some of it, I would like to comment that I think this document doesn't present its "within an ISP/enterprise, only router-to-router link" scope limitation well enough in its introduction paragraph.

By "introduction paragraph" do you mean the first paragraph in section 2.1,  or do you mean the overall introduction (section 1)?

- Philip

---

From: Mikael Abrahamsson <[email-masked]>
Date: Sun, 30 Oct 2016 06:27:16 +0100 (CET)

> By "introduction paragraph" do you mean the first paragraph in section 2.1,  or do you mean the overall introduction (section 1)?

I mean 1.

"This document discusses routing-related design choices" isn't obvious in 
that it mens "ISP internal router-router interfaces".

with the current wording in the abstract and Introduction I expected to 
find for instance customer access port considerations.

---

From: Brian E Carpenter <[email-masked]>
Date: Mon, 31 Oct 2016 08:12:45 +1300

> find for instance customer access port considerations.

The title is also too general, IMHO.

(We've tried a few times to write more general guidance, e.g. RFC6036, RFC6883
and RFC7381. But when we're writing specific guidance, the title should be
equally specific.)

     Brian

---

From: Mark Smith <[email-masked]>
Date: Mon, 31 Oct 2016 08:46:48 +1100

On 31 Oct. 2016 5:43 am, "Brian E Carpenter" <[email-masked]>
wrote:
> >>> Now that I have read some of it, I would like to comment that I think
this document doesn't present its "within an ISP/enterprise, only
router-to-router link" scope limitation well enough in its introduction
paragraph.
> >>
> >> By "introduction paragraph" do you mean the first paragraph in section
2.1,  or do you mean the overall introduction (section 1)?
> The title is also too general, IMHO.

That's what caught me.

I've read the draft before, however the other day I just read the diff. I'd
forgotten the draft was about routing only, and the title is very generic .
The addressing text I commented on was both generic and also incorrect
(going by RFC2460, "router interfaces" are actually host interfaces because
the addresses on them are used as packet sources and destinations, so IPv6
host interface addressing etc. rules apply to them.)

The title needs to be something like "IPv6 Routing Design Choices", and the
next needs to use more specific terms more often to ensure the reader is
reminded that this is only advice for the IPv6 routing plane.

Regards,
Mark.

---

From: Philip Matthews <[email-masked]>
Date: Mon, 31 Oct 2016 12:25:40 -0400

Brian:

Thanks for your comments.  See responses inline.

> specific to router addressing?

The comment about scoped to just router addressing is made at the start of section 2.1.  The text before that section (section 1) is simply introductory material that primarily defines what this document does and does not cover. And the sections after 2.1 do not cover addressing. So I don't see how your comment applies.  See also my next response.

> one of the GUA prefixes.)

I agree that it is difficult to do, which is why we almost deleted this section from the draft.  We put it back in part because you encouraged us to.  The rest of the document is scoped to be just about routers, and there are many reasons why the authors do not want to expand that scope. If the WG really wants to discuss design choices for end host addressing, then the authors suggest this be done in a different document.

> Once we are talking about tens of millions of sites, this will not be 'some'.

We were trying not to say anything about how many organizations would fall into this category, but I agree that it is likely to be a lot.   I have changed the word as you suggested.

> I believe that RFC4864 is relevant.

I read through this RFC, and it seems to be talking about an entirely different set of problems than RFC 6752.  

> or ULAs to routers. In any case, ICMP MUST NOT be sourced from LLAs.

I agree that this option seems bad, but we are trying hard to be neutral and just present pros and cons.  Is there a specific disadvantage of this option that you think we should include?

- Philip

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Nov 2016 08:53:02 +1300

In line...

On 01/11/2016 05:25, Philip Matthews wrote:
> I agree that it is difficult to do, which is why we almost deleted this section from the draft.  We put it back in part because you encouraged us to.  

Yes, appreciated.

> The rest of the document is scoped to be just about routers, and there are many reasons why the authors do not want to expand that scope.

I think that's fine (but see other comments on the document title etc.). However, there
is a natural linkage between site-wide addressing strategy and router addressing strategy.
As far as I can see, you can't decide your router addressing strategy until after you
decide your site-wide subnet prefix strategy. I guess that the way round this without
confusing the reader is to say exactly that.

> If the WG really wants to discuss design choices for end host addressing, then the authors suggest this be done in a different document.

Well, between router addressing and end host addressing, there is subnet prefix
allocation. That too is a little hard to separate from router addressing.

We have already touched on address plans:
RFC6883 section 5.1, RFC7381 section 2.6, and HNCP for homenets.

> I read through this RFC, and it seems to be talking about an entirely different set of problems than RFC 6752.  

Yes. But they seem relevant to addressing strategy. This gets back to my point that
router addressing strategy is a subset of site addressing strategy, not a separate
thing. I guess that's the nub of my comments.

> I agree that this option seems bad, but we are trying hard to be neutral and just present pros and cons.  Is there a specific disadvantage of this option that you think we should include?

Well, it confuses traceroute and it breaks the rule that LLAs must never be
seen off-link.

Rgds
    Brian

---

From: Victor Kuarsingh <[email-masked]>
Date: Mon, 31 Oct 2016 22:03:44 -0400

Brian,

In line

> On Oct 31, 2016, at 15:53, Brian E Carpenter <[email-masked]> wrote:
> 
> 

I think in many ways this is correct (to a point).  It's quite possible as part of strategizing what addresses to use for the network (and/or other parts of the infrastructure ) one may want to consider both together.  

However , in my experience ,  it's also quite reasonable to select router addresses (types,  internal distribution ) independently from how end hosts are addressed.

So perhaps a bit of text here noting that a higher level strategy is needed or suggested,  without saying you need to know how you plan that part as a prerequisite would make sense.  Would that approach work?

Regards,

Victor K

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 1 Nov 2016 16:03:31 +1300

> So perhaps a bit of text here noting that a higher level strategy is needed or suggested,  without saying you need to know how you plan that part as a prerequisite would make sense.  Would that app…

Yes, I think so. That would match my experience of how operational folk
tend to address this topic.

Thanks
   Brian