Subject: [GROW] I-D Action: draft-ietf-grow-private-ip-sp-cores-00.txt

From: [email-masked]
Date: Wed, 28 Mar 2012 04:21:28 -0700

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

	Title           : Issues with Private IP Addressing in the Internet
	Author(s)       : Anthony Kirkham
	Filename        : draft-ietf-grow-private-ip-sp-cores-00.txt
	Pages           : 15
	Date            : 2012-03-28

   The purpose of this document is to provide a discussion of the
   potential problems of using private, RFC1918, or non-globally-
   routable addressing within the core of an SP network.  The discussion
   focuses on link addresses and to a small extent loopback addresses.
   While many of the issues are well recognised within the ISP
   community, there appears to be no document that collectively
   describes the issues.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-cores-00.txt

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

This Internet-Draft can be retrieved at:
ftp://ftp.ietf.org/internet-drafts/draft-ietf-grow-private-ip-sp-cores-00.txt

---

From: "George, Wes" <[email-masked]>
Date: Fri, 30 Mar 2012 19:14:58 -0400

Cross-posting to both lists again because I was unable to attend the v6ops session where draft-behringer was discussed, draft-ietf-grow-private-ip-sp-cores is likely nearing WGLC, and I believe that the issue I raised needs to be addressed before either proceeds. I defer to the chairs of both groups to determine how to manage this across the two groups.

After reviewing both draft-grow-private-ip-sp-cores (Kirkham) and draft-behringer-lla-only again, I am even more convinced that they either need to be merged, or that draft-behringer needs to be abandoned altogether as a bad idea. Draft-grow-private-ip-sp-cores is quite a lot more complete in its discussion of the considerations around private IP usage, but focuses on IPv4, meaning that it *is* incomplete for lack of discussion of IPv6, which is a reality in most SP cores today. Nearly all of the same considerations apply for IPv4 and IPv6 in this case, so there are probably a limited number of changes that would be necessary to cover IPv6 in the Kirkham document.
I think that we need to come to some consensus on the recommended behavior on both cases. If the recommendation is different for one versus the other, we need to have a unified and clear articulation as to why this is the case. It may be that the consensus is to not recommend a behavior at all, and simply expand the format of Kirkham's document to cover any IPv6-specific items, since it discusses pros and cons evenly (as an informational doc) rather than recommending anything as a BCP. My vote is to do this, as I am unconvinced that use of LLA represents BCP today, nor should it. I outline some reasons below, but that's probably not as critical if others agree that this is the proper method to proceed with these documents.

If draft-behringer is left as a separate document, here are some specific comments:
The advantages proposed in draft-behringer are IMO not enough to justify recommending use of LLA.
- Smaller routing tables can be achieved through other methods such as setting the interfaces into passive mode in the IGP (so that they are not redistributed into the IGP) and/or not redistributing connected routes. Further, as SPs make great use of interface bundling (LAG), the number of interfaces with IP addresses is dramatically reduced, making the need to pull the point to point interfaces out of the routing table significantly lower.
- Reduced attack surface - draft-ietf-grow-private-ip-sp-cores sections 10 and 11 discuss this in great detail, and come to the conclusion that it is of limited benefit, and that alternatives exist to protect the infrastructure.
- lower configuration complexity - while this is true, it is replaced by additional complexity in troubleshooting. In the case of traces and pings locally on the box, it adds the additional step of requiring the operator to use extended ping and trace commands to specify the exit interface in order to make the ping work (vs simply issuing "ping [ip address]"), and makes it nearly impossible to derive the address of the remote interface without determining the remote side router through some other means and logging into the router to look. (vs practice today of using an IP in the same subnet, usually 1 digit up or down that can be guessed to save time).
- less address space: The other draft mentions this as well, in the context of IPv4 where it might make a difference, but this simply is not much of a concern with IPv6. An entire network could be numbered many times over out of one /64.
-simpler DNS : Most ISPs operating at the scale where this makes any difference at all have tools to build the DNS forward and reverse entries for their infrastructure automatically based on the router name and interface name extracted from their inventory tools. It's a few bits of scripting, so it's not like having less interfaces in DNS results in any net reduction in work or increase in the possibility of mistakes.

- Draft-ietf-grow-private-ip-sp-cores rightly notes that the proposed solution to broken pings/traces/PMTUD from draft-behringer (RFC 5837) has little or no implementation. This makes it a hard sell as any sort of recommended solution unless the benefits are much more significant than what is currently discussed in draft-behringer. This has to be a large enough benefit to justify pushing hard on router vendors to implement the feature and SPs to certify and deploy the code, and frankly there are many more important features to consider.

Thanks,

Wes George

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> [email-masked]
> Sent: Wednesday, March 28, 2012 7:21 AM
> To: [email-masked]
> Cc: [email-masked]
> Subject: [GROW] I-D Action: draft-ietf-grow-private-ip-sp-cores-00.txt
>
>
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories. This draft is a work item of the Global Routing Operations
> Working Group of the IETF.
>
> _______________________________________________
> GROW mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/grow

This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout.

---

From: "t.petch" <[email-masked]>
Date: Sat, 31 Mar 2012 12:26:19 +0200

----- Original Message -----
From: "George, Wes" <[email-masked]>
To: <[email-masked]>; <[email-masked]>
Cc: <[email-masked]>
Sent: Saturday, March 31, 2012 1:14 AM
> Cross-posting to both lists again because I was unable to attend the v6ops
session where draft-behringer was discussed, draft-ietf-grow-private-ip-sp-cores
is likely nearing WGLC, and I believe that the issue I raised needs to be
addressed before either proceeds. I defer to the chairs of both groups to
determine how to manage this across the two groups.
>
> After reviewing both draft-grow-private-ip-sp-cores (Kirkham) and
draft-behringer-lla-only again, I am even more convinced that they either need
to be merged, or that draft-behringer needs to be abandoned altogether as a bad
idea. Draft-grow-private-ip-sp-cores is quite a lot more complete in its
discussion of the considerations around private IP usage, but focuses on IPv4,
meaning that it *is* incomplete for lack of discussion of IPv6, which is a
reality in most SP cores today. Nearly all of the same considerations apply for
IPv4 and IPv6 in this case, so there are probably a limited number of changes
that would be necessary to cover IPv6 in the Kirkham document.
<tp>
Disagree.  As you say, the grow draft is more or less complete, more or less
ready for WGLC.  And it has taken the IETF two years to get to this state.

IPv6 is different.  We probably know little as yet as to how it works or how it
should.

Adding IPv6 would put this work back a year or two, and given that GROW is not
the most lively of growps, it may never happen.

Get the grow draft out as an RFC while it is still of value to its audience.

Then contemplate a -bis with IPv6 if there is sufficient enthusiasm in a WG to
do so.

Tom Petch

> I think that we need to come to some consensus on the recommended behavior on
both cases. If the recommendation is different for one versus the other, we need
to have a unified and clear articulation as to why this is the case. It may be
that the consensus is to not recommend a behavior at all, and simply expand the
format of Kirkham's document to cover any IPv6-specific items, since it
discusses pros and cons evenly (as an informational doc) rather than
recommending anything as a BCP. My vote is to do this, as I am unconvinced that
use of LLA represents BCP today, nor should it. I outline some reasons below,
but that's probably not as critical if others agree that this is the proper
method to proceed with these documents.
> - Smaller routing tables can be achieved through other methods such as setting
the interfaces into passive mode in the IGP (so that they are not redistributed
into the IGP) and/or not redistributing connected routes. Further, as SPs make
great use of interface bundling (LAG), the number of interfaces with IP
addresses is dramatically reduced, making the need to pull the point to point
interfaces out of the routing table significantly lower.
> - Reduced attack surface - draft-ietf-grow-private-ip-sp-cores sections 10 and
11 discuss this in great detail, and come to the conclusion that it is of
limited benefit, and that alternatives exist to protect the infrastructure.
> - lower configuration complexity - while this is true, it is replaced by
additional complexity in troubleshooting. In the case of traces and pings
locally on the box, it adds the additional step of requiring the operator to use
extended ping and trace commands to specify the exit interface in order to make
the ping work (vs simply issuing "ping [ip address]"), and makes it nearly
impossible to derive the address of the remote interface without determining the
remote side router through some other means and logging into the router to look.
(vs practice today of using an IP in the same subnet, usually 1 digit up or down
that can be guessed to save time).
> - less address space: The other draft mentions this as well, in the context of
IPv4 where it might make a difference, but this simply is not much of a concern
with IPv6. An entire network could be numbered many times over out of one /64.
> -simpler DNS : Most ISPs operating at the scale where this makes any
difference at all have tools to build the DNS forward and reverse entries for
their infrastructure automatically based on the router name and interface name
extracted from their inventory tools. It's a few bits of scripting, so it's not
like having less interfaces in DNS results in any net reduction in work or
increase in the possibility of mistakes.
>
> - Draft-ietf-grow-private-ip-sp-cores rightly notes that the proposed solution
to broken pings/traces/PMTUD from draft-behringer (RFC 5837) has little or no
implementation. This makes it a hard sell as any sort of recommended solution
unless the benefits are much more significant than what is currently discussed
in draft-behringer. This has to be a large enough benefit to justify pushing
hard on router vendors to implement the feature and SPs to certify and deploy
the code, and frankly there are many more important features to consider.
> This E-mail and any of its attachments may contain Time Warner Cable
proprietary information, which is privileged, confidential, or subject to
copyright belonging to Time Warner Cable. This E-mail is intended solely for the
use of the individual or entity to which it is addressed. If you are not the
intended recipient of this E-mail, you are hereby notified that any
dissemination, distribution, copying, or action taken in relation to the
contents of and attachments to this E-mail is strictly prohibited and may be
unlawful. If you have received this E-mail in error, please notify the sender
immediately and permanently delete the original and any copy of this E-mail and
any printout.