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

From: [email-masked]
Date: Mon, 06 Jul 2015 14:25:06 -0700

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-08.txt
	Pages           : 21
	Date            : 2015-07-06

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-08

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

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: Mon, 6 Jul 2015 17:38:34 -0400

Folks:

Victor and I have just submitted a new revision of the Design Choices draft. There are two main changes:
1. A new section called "Addresses" that discusses the pros and cons of using PI vs. PA vs. Private addresses in your IPv6 or dual-stack network. This addresses some comments we got during the WG Last Call about using ULAs in certain situations. We consider this a significant addition to the draft.
2. Added EIGRP to the section on IGP Choice.  Some of you will recall the discussion around this on the mailing list a couple of months ago.

Victor and I have plans for more revisions to address other WG comments.  In particular, as you may remember, Victor and I have been gathering hard data from operators around the IGPs that are actually used in production networks. Unfortunately, Victor and I both got hit with other stuff in the last few weeks, so we didn't have time to add this data to the draft, or make some other planned changes. So consider this still a work-in-progress with other changes coming.

- Philip

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 07 Jul 2015 16:48:44 +1200

Hi,

I don't understand why you mention RFC 1918 in a document about
IPv6 deployment.

In the table in 2.1.1, I object strongly to the comment against
private (i.e. ULA) addresses
"Will probably require some sort of NAT on links to the Internet."

That isn't the architecture. The architecture is that nodes have multiple
addresses, and only use ULAs for internal traffic, and use PA or PI addresses
for Internet traffic. We shouldn't be documenting any other usage of
ULAs. We shouldn't be making statements like this:

"For an enterprise, the use of private address space is	
reasonable, but the enterprise will need to use NAT44 and/or	
NPT[RFC6296] on links to the Internet."

We clearly can't pretend that NAT44 isn't widely used, but IMHO it should
be completely out of scope in this document, and NPTv6 is an experimental
RFC that we should never recommend. ULAs should *only* be used in parallel
with PA or PI. That isn't an afterthought; that is the basic intention behind
ULAs.

Stepping back slightly in the text:
"In this case, the use of PI space is the best	
option, as it gives the most flexibility in the future.  However,	
some organizations may be unable or unwilling to obtain PI space - in	
this case PA space is the next-best choice."

What size of enterprise are you addressing? Whatever the current RIR policy
is, it remains irresponsible to hand out PI prefixes like candy. Please tune
this language to make it clear that it applies to hundreds or thousands of
large customers, probably not to small/medium enterprises, and definitely
not to millions of SOHO customers, who will inevitably get PA.

Stepping back to the first sentence of the Introduction:

"This document discusses certain choices that arise when designing a
IPv6-only or dual-stack network."

This really needs to specify the classes of customer it is addressing.
You split some of the later material into "ISP" and "Enterprise"
but that (and customers that are not covered) needs to be made clear
at the beginning, and even in the Abstract.

Nit:

"2.4.3.  RIP	
		
   A protocol option described in the table in this section is RIP	
   [RFC2080]."

Don't you mean "*not* described in the table"? And its name is RIPng.

Regards
   Brian

---

From: "Ackermann, Michael" <[email-masked]>
Date: Wed, 8 Jul 2015 15:01:51 +0000

Thanks for the great document that Enterprises considering the serious deployment of  IPv6 will find very valuable.  

The initial sections are good in pointing out what this document does and does not address.   Also pointing out RFC's where information on areas NOT addressed can be found. 

In Section 2.1.1 the reference to RFC1918 addresses seems to suggest this is the IPv4 equivalent to ULA's.     Is this a commonly accepted concept?  

In the Chart, under Tunneled,  it says private addresses are likely a better option.   Why?  A subsequent paragraph says something about these addresses having limited visibility.   Is that the rationale?       The paragraph goes on to describe reasons why  PI space is the next best option, but the discourse seems to suggest it may be the better option.     So I come away unclear of which would be "Best".  

Is Section 2.2 intended to address end hosts, as well as Routers (Middleboxes)?   Could the answer be different in certain situations?       Also, is option "a." Dual Stack?   Is there a reason this term is avoided?  

Section 2.2.2, seems to answer a question I have had.  IPAM can/should ignore Link Local addresses.  Is this the intended conclusion?   
In general, this section has a great deal of useful information regarding the use of Link-Local-Only addresses.  

Section 2.4.1, the IGP Choice chart shows 4 Multiple Known Deployments,  but the following paragraph says 3.     Other than that,  the chart contains a lot of relevant information and should be a helpful decision tool.    I also thank you for including EIGRP and RIP, which I recall was difficult and controversial.  

Thanks again for the effort, content and quality put into this document!

Mike 
  
-----Original Message-----
From: v6ops [mailto:[email-masked]] On Behalf Of Philip Matthews
Sent: Monday, July 06, 2015 5:39 PM
To: v6ops list
Subject: Re: [v6ops] I-D Action: draft-ietf-v6ops-design-choices-08.txt

Folks:

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

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: Mark Smith <[email-masked]>
Date: Thu, 9 Jul 2015 18:25:04 +1000

On 7 July 2015 at 14:48, Brian E Carpenter <[email-masked]> wrote:
> for Internet traffic.

I agree.

Unless you're using link-locals only in your network (and that isn't
really possible for the edge networks), there is always an address
selection process going on between the always present link-locals and
the other address or addresses that are available.

Perhaps it isn't that common knowledge that link-local addresses are
quite valid to be used by/for applications, as per RFC4007, and are
normally preferred over all other address types if they're available
to the application, excepting the loopback prefix, because link-locals
have the second smallest scope (and the smallest scope is preferred).

In other words, most IPv6 networks are multi-prefix even if their
operators think they aren't because they "only" have a single GUA.
This is probably worth more visibly highlighting or emphasising in
this draft, because it seems to be something that is commonly
forgotten or not completely realised.

> We shouldn't be documenting any other usage of

I've thought that if it is unacceptable for devices inside your
network to have global addresses, then your security requirements are
probably so stringent that NPTv6 devices, packet filters and stateful
firewalls would be too simple to achieve and implement them. Instead,
you'd use application layer proxies for specific applications you
permit, that act on behalf of and completely or near completely hide
the identity of the devices inside your network, and prevent any
possible reachability to those devices, inherent in ULA addressing,
unless the application layer proxy itself is compromised.

If using per-application application layer proxies is considered too
onerous or costly, then I think the security measures you'd have in
place (e.g., host firewalls, network perimeter firewalls/packet
filters) would mean there is less risk to deploying global addresses
internally compared to the benefits of having them.

<snip>

Regards,
Mark.