Subject: [renum] Initial thoughts and questions

From: Brian E Carpenter <[email-masked]>
Date: Thu, 02 Dec 2010 10:29:11 +1300

Hi,

RFC 5887 (Renumbering still needs work) was published in May 2010.
It would be more productive if we can avoid redoing that work here,
but rather pick up where it left off. So I will pause briefly
while you read it...

https://datatracker.ietf.org/doc/rfc5887/

...thus the problem is that in any future scenario, site renumbering
will sometimes be needed, but remains very hard and impractical
for most sites.

My initial thoughts and questions are these:
- 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.

-- 
Regards
   Brian Carpenter

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 2 Dec 2010 08:53:51 -0800

Pardon this reckless foray into a taboo subject, but isn't
the obvious solution to renumbering pains to simply avoid
renumbering in the first place? In a perfect world, if every
end user network (aka site) were given their own PI prefixes
they could number their internal devices once and be done
for all time.

But true PI is hard, because somewhere down the line
someone has to either route it or map it. We know all about
the scaling issues for a pure routing solution, and we have
struggled for decades to come up with a pure mapping solution
that does not suffer from pitfalls of one form or another.

But, what about something in between? Something that leverages
the routing system without undue scaling impact, and something
that involves a mapping system of a sort that is interdependent
with (rather than independent from) the routing system? The
implication is that somewhere down the line there would need
to be a "broker" that a customer aquires its (quasi)PI prefixes
from, and if relations with that broker turn sour (or the broker
goes out of business) then the customer would be obliged to
relinquish its prefixes and aquire new ones from a different
broker. The penalty obviously being a renumbering event.

So, maybe we should be considering renumbering requirements
along a continuum, e.g.:

  - pure PI, in which renumbering is never needed
  - quasi-PI, in which renumbering occurs very rarely - perhaps
    once every 10 years
  - pure PA, in which renumbering may be a common event
  - all points in between

Is this the right place for such a discussion? Should there
even be such a discussion in the first place? Who wants to
go next?

Thanks - Fred
[email-masked]

---

From: Teco Boot <[email-masked]>
Date: Thu, 2 Dec 2010 17:59:31 +0100

Brian,

> - Is IPv4 site renumbering a lost cause?
No, not completely.
Although IPv6 automated renumbering would be much more seamless, it is not 
impossible to do a job for IPv4. When we are able to banish ingress filter 
problems with multi-homed sites, sites can be renumbered host by host.
I think automatic IPv4 renumbering of routers is a lost cause. 
Most IPv4 sites use NAT/PAT or proxies anyway, so working on IPv4 has
absolutely no priority for me.

>  ways (new deployment for most sites, not constrained by a shortage
For sure we should start with IPv6. When a mechanism can be used for IPv4, 
why not mention such? But I have to admit there is a pitfall here, the 
more time spend on IPv4, the less progress made for IPv6.

> - We need a gap analysis. Is the gap analysis in RFC 5887 sufficient?
Most text I have seen is "renumber from old to new addresses". I think this
is only part of the problem, as PA multi-homed, and thus multiple in-use 
prefixes, will be common in the future. Even if a site wants to swap 
from one prefix to another, it doesn't want to schedule a flag day. So we 
have a gap here, the network has to support PA multi-homing, during the 
transition period or as normal mode of operation.

RFC3704 section 4.3 describes a solution for ingress filter on multi-homed
sites. But is starts with "requires careful planning and configuration". 
It is IMHO not for wide adoption for non-networkspecialists and totally 
out of scope for an automated procedure. So what is missing is a standard 
feature in routing, so that packets are not dropped when forwarded 
to a border router that doesn't "own" the source address of that packet. 
My suggested solution is to forward packets to that border router that 
owns the SA prefix. The other two described solutions in RFC3704 are not 
acceptable either. 

There is a lot of work already being done on source address selection 
shortcomings in RFC3484. I did not see a reference to it in RFC5887.

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

Teco.

---

From: Teco Boot <[email-masked]>
Date: Thu, 2 Dec 2010 18:13:20 +0100

Hi Fred,
Op 2 dec 2010, om 17:53 heeft Templin, Fred L het volgende geschreven:

> renumbering in the first place?
No. Some people want to work on this. If one does not, I kindly
ask him/her not to bother.

> In a perfect world, if every
This is just an opinion. I have another.

> Is this the right place for such a discussion?
IMHO we discuss ease of renumbering, for whatever reason, with 
whatever frequency.

> Should there
> even be such a discussion in the first place?
I think it is OK to have written down some scope for renumbering.

> Who wants to
We will see.

Thanks, Teco

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

---

From: "Joel M. Halpern" <[email-masked]>
Date: Thu, 02 Dec 2010 12:23:47 -0500

There are two approaches to this space.
One approach is to re-architect the system so that site renumbering is 
not needed.
Solutions such as IRON, LISP via site edge proxies, and NAT66 take that 
path.
The other approach is to observe that a number of archtiectures, 
including the existing archtiecture, MPTCP, ILNP without Proxies, LISP 
done in hosts, etc.. would benefit if it were significantly easier to 
renumber networks, ACLs, routers, and other components.
IPv6 helps with that, as hosts which do not need static numbers can 
renumber easily.
Dynamic DNS helps, as it lets services be offered more easily wihtout 
binding an address statically.

But, neither one is sufficient.
Some of those solutions help with renumbering, others don't.  Even the 
ones that help, do not cover the whole problem.

Since I am not prepared to assumed that we will be going with a network 
archtiecture that obviates the issue, it seems to me we need to look at 
what can be done.
The biggest win, frankly, is if we can come up with something that makes 
renumbering easier with the current architecture, as that has the most 
immediate and widest scope.
I personally think we should probably worry only about IPv6, as the IPv4 
networks are out there already, with their chosen solution.

There seems to be plenty to do, as outline in RFC 5887.

Yours,
Joel

PS: As far as I can tell, there is no point in trying to craft a 
solution for renumbering that occurs only once every 10 years.  The 
constraints which would lead one to such a solution are such that one 
would end up assuming administrative effort, which is what we already 
have, and turns out to be a hurdle high enough to discourage even once 
every 10 year renumber.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 2 Dec 2010 09:49:30 -0800

Joel,

> One approach is to re-architect the system so that site 
> renumbering is not needed.

In the case of IRON at least, this is not about
re-architecting the system. It is about leaving the
existing IPv4 system intact and building out IPv6 as
a "second story" on top of it. RFC1955-style, but with
added benefits such as mobility management, multihoming,
traffic engineering, route optimization, etc.

IRON looks at the whole package whereas renumbering
issues looks only at a single dimension (albeit an
important one).

Fred

> -----Original Message-----
> From: Joel M. Halpern [mailto:[email-masked]] 
> Sent: Thursday, December 02, 2010 9:24 AM
> To: Templin, Fred L
> Cc: [email-masked]
> Subject: Re: [renum] Scalable PI and its implications for renumbering
>

---

From: Teco Boot <[email-masked]>
Date: Thu, 2 Dec 2010 20:28:13 +0100

Fred,

It is not mapping _or_ renumbering. Both can be worked on.
There are scenario's, where networks must be renumbered. 
Think of split & merge of organizations. Or small offices / 
home offices. Or for those who prefer PA addresses and switch ISP.

I prefer arguing not_renumbering on a [email-masked] maillist.

Teco

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Dec 2010 08:43:49 +1300

On 2010-12-03 05:59, Teco Boot wrote:
...
> shortcomings in RFC3484. I did not see a reference to it in RFC5887.

Good point. I think that was less of a hot topic at the time we started
work on 5887. Are there any aspects of 3484 that affect renumbering on the
RFC4192 model? Are there any points missing from draft-ietf-6man-rfc3484-revise
that would help renumbering?

    Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 03 Dec 2010 08:49:35 +1300

> transition period or as normal mode of operation.

I fully agree, and so does RFC4192. And actually, whatever people say,
the only standardised multi-PA multihoming protocol we have today
is shim6. We should check whether shim6 is OK for renumbering without
a flag day.

We should also check draft-troan-multihoming-without-nat66.

   Brian

---

From: Fred Baker <[email-masked]>
Date: Thu, 2 Dec 2010 13:59:44 -0600

> transition period or as normal mode of operation.

I think 5887 is a good start. There are a number of issues surfaced in 4192 that are only peripherally addressed in 5887, though. For example, 5887 suggests that the way to resolve the issue with access lists and route maps (numeric configuration, primarily in routers and switches) is to have them centrally managed. I'm not sure I buy that as a solution, as there are cases in which the central manager is unable to update a remote host or doesn't know of a specific correlation.

One big problem I see with most stuff to date is that it tries to address the case in which I am globally changing my prefix without changing my subnetting. At Cisco, we rarely change providers - we might add one and we might drop one, but we don't *change* them. But we do reorganize subnetting from time to time, perhaps because we opened a new campus or someone saw the need due to cumulative cruft.

And as noted in 4192, the biggest issues tend to be with things that the administrator has forgotten or never knew, such as that a given system is day-to-day-critical and some remote system is simply not prepared for it to change its address.

So, for reasons expressed in 4192, I would be looking for the ability to:
 - add a prefix to the list of global prefixes in use by a router on a set of interfaces
 - drop a prefix from the list of global prefixes in use by a router on a set of interfaces
 - add a number to the list of subnet numbers in use by a router on a (set of) interface(s)
 - drop a number from the list of subnet numbers in use by a router on a (set of) interface(s)

I would specifically *not* be looking for the ability to "change" an address. Add, test, drop.

If a host has a fixed address (DHCPv6, as opposed to SLAAC), one hopes that DHCPv6 can keep up with that...

If you really want to follow the central management mantra, I think the right approach will be to build a management model of a set of nodes with relationships with subnets. You can subsume most hosts into subnets using DHCPv6 or SLAAC, but you will have to keep track of routers and connectivity among them and outside. You will wind up identifying specific hosts (servers) that have special attributes, such as a role (think role-based access control), and implications of those roles (if one of a host's roles is to serve financial data, it may only be allowed to talk with hosts whose roles include being a client of financial data). You will similarly want to assign roles to prefixes in BGP (which might be the same concept as communities, but I'll bet that it merely maps to communities). Given such a management model, it is a relatively simple task to derive access lists, route maps, and interface configurations, and renumbering becomes a special case of changing the dataset by adding/dropping a prefix or subnet number to/from a set of subnets, and by extension to/from a set of router and host interfaces.

---

From: "Templin, Fred L" <[email-masked]>
Date: Thu, 2 Dec 2010 12:10:33 -0800

> I prefer arguing not_renumbering on a [email-masked] maillist.

We had that discussion a few years ago, and people said
they liked PI. And, I don't even recall any smart-a**ed
suggestions of starting a new mail list.

Fred

---

From: Teco Boot <[email-masked]>
Date: Fri, 3 Dec 2010 09:06:43 +0100

> One big problem I see with most stuff to date is that it tries to address the case in which I am globally changing my prefix without changing my subnetting. At Cisco, we rarely change providers - w…
Not sure, but I think the need for smooth PI address renumbering or ULA renumbering is less urgent. This will lead us to a focus on IPv6 PA address renumbering, or PA multi-homing as normal mode of operation. Of course, all improvements would apply to PI and ULA addresses also.

> - drop a number from the list of subnet numbers in use by a router on a (set of) interface(s)
Yes. This is the router part. Also, routers has to inform hosts, so that seamless handover to new prefixes is arranged. This implies analyses which already available mechanisms can be used, and the gap left over.

> I would specifically *not* be looking for the ability to "change" an address. Add, test, drop.
This would provide basics for seamless handover, so +1.

> If a host has a fixed address (DHCPv6, as opposed to SLAAC), one hopes that DHCPv6 can keep up with that...
I don't think a host with a DHCPv6 provided address is blocked to configure additional addresses with SLAAC. Or use multiple DHCPv6 addresses, from one or more servers.

> If you really want to follow the central management mantra, I think the right approach will be to build a management model of a set of nodes with relationships with subnets.
What about a seamless switch from one to another of such central management mantra? Or multiple of such as normal mode of operation?

Teco.

---

From: Teco Boot <[email-masked]>
Date: Fri, 3 Dec 2010 12:16:31 +0100

> - We need a gap analysis. Is the gap analysis in RFC 5887 sufficient?

I don't think we need to repeat problem statement items of the MIF WG.
We could refer to draft-ietf-mif-problem-statement, and mention that
problems using multiple addresses, configured on distinct interfaces,
also may occur on multiple addresses, on a single interface.

On the DNS topic, I experienced problems myself with DNS name resolving. 
Scenario is very similar to draft-ietf-mif-problem-statement section 4.1 
DNS issues, problem 1. Description would be:

    DNS name resolver uses A1, with prefix from ISP1, and DNS2, managed 
    by ISP2. ISP2 has applied access control on its DNS servers, so that
    only its own customers get correct answers. The DNS name resolver gets 
    no reply, or even worse, an invalid reply.

DNS Updates may have similar problems. Assume a host uses DNS servers from
ISP1, and access these servers with A1. Does allow ISP1 configure addresses
from ISP2? 
Seamless transition would be:
 - Site uses ISP1 only, with DNS1
 - Sites starts using ISP2, with prefix P2 and DNS2
 - Nodes in site can use both P1 and P2, without problems (difficult already...)
 - DNS1 is updated with P2 addresses *)
 - DNS2 is populated, with P1 *) and P2 addresses
 - Domain is transferred to DNS2
 - Wait for TTL.....
 - Stop using DNS1
 - Remove info in DNS1
 - Stop using P1
 - Stop using ISP1
The *) DNS Updates should not be blocked. Applies to other address registration 
services as well.
RFC4192 section 4 describes similar problems.

Teco

---

From: Teco Boot <[email-masked]>
Date: Fri, 3 Dec 2010 13:48:50 +0100

> that would help renumbering?

Question is: are all issues in RFC5220 solved in draft-ietf-6man-rfc3484-revise?

Another issue that comes up in my mind is that adding a prefix may trigger a 
huge change in traffic patterns. What about adding a low bandwidth link to an 
ISP, that hits source address selection rule 8 and immediately gets overloaded, 
because by coincidence there is a common prefix with destination addresses, with 
high volume connections?
IMHO we need an automated mechanism, that provide awareness of the costs of the
uplink. This would replace rule 8. I'll come up with a (BRDP based) solution one
day. For sure, MPTCP is applicable here.

Teco.

---

From: Fred Baker <[email-masked]>
Date: Fri, 3 Dec 2010 07:20:27 -0600

> What about a seamless switch from one to another of such central management mantra? Or multiple of such as normal mode of operation?

One could certainly go about it that way - a manager for each prefix that a domain is using for example. While I wouldn't want to make such things hard, I wouldn't go out of my way to make the probably arbitrarily complex or difficult.

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 04 Dec 2010 11:04:59 +1300

> day. For sure, MPTCP is applicable here.

Of course, shim6/REAP does perform path exploration but does not
optimise path usage in the way that MPTCP does. I would guess that
any mechanism below transport will fail to optimise, so REAP is
probably as good as anything. Unless anyone can figure out how to
do MPUDP ;-).

    Brian