Subject: [Int-area] Starting some discussion on renumbering

From: Brian E Carpenter <[email-masked]>
Date: Thu, 11 Nov 2010 20:55:55 +1300

RFC 5887 (Renumbering still needs work) was published in May 2010.

I will assume that you've read it. It isn't a philosophical
document; it is meant to be technical.

So, the problem is that in any future scenario, site renumbering
will sometimes be needed, but remains very hard and impractical
for most sites. RFC 5887 justifies these statements.

What are we going to do about it?
- Is IPv4 site renumbering a lost cause?
- Should we focus entirely on IPv6? That is probably easier in several
  ways (new deployment for most sites, not constrained by a shortage
  of prefixes)
- We need a gap analysis. Is the gap analysis in RFC 5887 sufficient?
- In any case we should focus on what is doable, and put other problems
  on the "too hard" pile.

If you are interested in contributing to some work in this area,
please let me know (off-list is fine). If there is enough interest,
we can set up an ad hoc mailing list and decide on the next steps.
Remember that the cut-off for BOF requests for IETF 80 will be somewhere
round the end of January. Not much time...

-- 
Regards
   Brian Carpenter

---

From: Shane Amante <[email-masked]>
Date: Thu, 11 Nov 2010 03:59:40 -0700

Brian,

> document; it is meant to be technical.

I have read it, it is a good doc.

> - Is IPv4 site renumbering a lost cause?

Yes.

>    ways (new deployment for most sites, not constrained by a shortage

Yes.

> - In any case we should focus on what is doable, and put other problems

IMHO, we should avoid doing more analysis and start working on solutions 
to the problems.  As such, I would propose focusing on Section 5.3.4, 
Management Issues (and Appendix A), since this seems to be the most 
'target-rich' area to get fixed so that products start getting 
built/upgraded sooner rather than later that are more "friendly" to 
renumbering events.

To pick on one example, we all know (or, should know?) that we need to 
*stop* the well-worn practice of 'hard-coding' IP addresses and IP 
prefixes into various device and service configuration.  Along those 
lines there exists:
a)  DNS Service Discovery;
b)  RFC 3123, DNS RR Type for lists of Address Prefixes -- but, it's 
experimental; and,
c)  DNSSEC to secure (a) and (b).
Why are we not using the above as mechanisms so that devices and 
services can encode names and *not* addresses?  And, if the above are 
the wrong direction, then what is the right direction (LDAP, other?) and 
what (if any) work needs to be done with them to make them more "palatable".

> round the end of January. Not much time...

I am very interested in helping contribute to solutions to the 
renumbering problem(s).  Please count me in.

-shane

---

From: Eliot Lear <[email-masked]>
Date: Fri, 12 Nov 2010 14:30:09 +0100

Brian,

I am interested in participating in discussions, on or off list ;-)  One
comment now:

>   ways (new deployment for most sites, not constrained by a shortage

While of course we should focus entirely on IPv6, I would not want to
overstate the value of the size of address space, for the following reasons:

    * Large portions of network devices still require (re)configuration.
    * While aspects of DHCP have evolved in IPv6, their use (a'la Prefix
      Delegation) has to date not been well deployed (yet).
    * One reason is that there is a perceived trade-off between
      stability and the use of signaling mechanisms.  This has been
      reinforced by some operator behavior, where they sell static
      stable address space at a different rate than dynamic space.
    * Interaction between the DNS/and the other L3 components really
      hasn't really evolved at all since RFC 4192, particularly on the
      inter-domain front.  I would propose that this be the subject of
      discussions LONG before a BoF proposal.

This is not to say that there isn't any improvement at all.  Having a
larger block provides for an opportunity to simplify certain aspects of
renumbering, especially when the lower-64 are reserved for hosts.  This
too has not changed since 4192.

Eliot

---

From: Stephane Bortzmeyer <[email-masked]>
Date: Sat, 13 Nov 2010 16:52:11 +0800

On Thu, Nov 11, 2010 at 03:59:40AM -0700,
 Shane Amante <[email-masked]> wrote 
 a message of 67 lines which said:

> To pick on one example, we all know (or, should know?) that we need
> to *stop* the well-worn practice of 'hard-coding' IP addresses and
> IP prefixes into various device and service configuration.

This is too strict a principle. If IP addresses are stored in one
place and then automatically integrated into configurations and then
pushed to devices via automatic means (Rancid, Chef, Puppet, etc),
then, it is not too big a problem for renumbering. 

My concerne with the current Most Common Practice is not the use of IP
addresses per se but the lack of decent, high-level, etc,
configuration management tools. This is what makes renumbering a
painful and dangerous operation.

> Along those

DNSSEC deployment only started seriously to be deployed two years ago
and, in many places, it is far from being over. At of today, you
certainly cannot suggest DNS+DNSSEC as a general solution to replace
hard-coded IP addresses in configurations, specially for
security-related devices (ACL in a firewall).

To seriously promote DNS+DNSSEC as a credible alternative to
hard-coded IP addresses, we would need (note that not all these points
depend on IETF):

* a standard API for applications to get the result of DNSSEC
validation (a firewall configured with names would certainly love to
use it),

* most DNS zones signed,

* a majority of DNS registrars (for TLD with registrars) which accept
DS records (today, they are only a small minority),

* better working relationships between network people and DNS people
(may be the hardest problem: in many places, people who configure the
firewall simply distrust/do not understand the DNS).

---

From: Shane Amante <[email-masked]>
Date: Sat, 13 Nov 2010 09:08:28 -0700

Stephane,

> painful and dangerous operation.

I agree with your above points; however, I think it should be fairly clear that we need a range of solutions depending on the size of the end-site.  For large-ish sites, the tools you mention above are invaluable[1]; however, what about small- to medium sites that have 'standalone' devices?  In that case, I don't believe tools like rancid, chef, etc. are applicable, mainly because there aren't full-time administrators to wrangle with them.  Alternatively, tools like rancid, chef, etc. could certainly benefit from using DNS + DNSSEC as a means to validate elements in configs (FQDN's, services, etc.) they generate on behalf of "legacy" devices in medium- to large-sites and push down to those devices, correct?

> security-related devices (ACL in a firewall).

Agreed; however, I think you're strengthening my point.  Specifically, if DNS is the "right tool" for this job and it requires new RR's or other modifications, it would be good to get those baked into DNS sooner rather than later in order that as new SW for DNSSEC gets deployed these new modifications/enhancements in DNS, to ease the burden of renumbering, also get deployed at the same time.  I would also note that there will be incremental deployment benefits for those early sites that start to use these enhancements (at least, internally) and could "encourage" (or, force) other external sites to use it as well.

> DS records (today, they are only a small minority),

Sure, but (again) I don't think we should "wait" until we think DNS + DNSSEC is fully/mostly deployed, before working _toward_ offering it as a credible solution for the renumbering problem at some point in the near future. 

> firewall simply distrust/do not understand the DNS).

I think this speaks to another point, which is that we need to remove the obstacles for consumers of information in the DNS from exclusively going through the "gatekeepers" of the DNS zones running on DNS servers to 'write' or update information they are responsible for in those zones.  IOW, we have RFC 3007, Secure DNS Dynamic Update, wh/ is already supported in Windows, Mac OS X and Linux.  IMHO, this needs to be mandated as the means to maintain these new RR's in order to reduce the barriers that currently separate these groups.

-shane

[1] I'm not sure how much NETCONF/NETMOD would help in relation to tools like chef, puppet, etc. other than avoiding the need for those tools (or, others like them in the future) from inventing new methods/languages/syntax to represent a device's config and/or interact with that device's config 'over the wire'.  Regardless, this is something else that we should probably look at in parallel and I'd be happy to participate in that effort too.