Subject: RE: Operational Renumbering Procedure

From: "Michel Py" <[email-masked]>
Date: Fri, 25 Apr 2003 14:40:04 -0700

Fred,

> Fred Baker wrote:
> It turns out that operationally, the best thing we can do to
> make renumbering easy is make manual configuration really hard.

This summarizes it very well I think.

I will comment on the draft later on when time permits (spread really
thin these days), however on a super-fast read it appears to be shallow
on internal policies and politics. For example, how do you make
renumbering easy when the following (with matching SNMP config) is a
requirement:

line vty 0 4
   no login
   transport input none

Michel.

--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Christian Huitema" <[email-masked]>
Date: Sun, 27 Apr 2003 17:20:34 -0700

Fred,
 
Pekka points out one issue with the "stable with two addresses" phase. At that point, the network is in effect  multihomed, and the two-address phase is only stable if we know how to handle well multi-homed sites. You don't discuss this in your draft, and in truth it would be conceivable to renumber a site just for the fun of it, without changing ISP. However, the practical case is that the site moves from "stable with one address from ISP A" to "multihomed to ISP A and ISP B" to "stable with one address from ISP B".
 
Previous discussions of multi-homing have shown that to do that we must at a minimum handle "ingress filtering" issues. Suppose that in the dual-home site a host configures an address from ISP B's prefix, send a packet to a 3rd party P, and that the routing tables are such that traffic to B is routed through ISP A. If ISP A performs ingress filtering, it will reject the packets whose source addresses don't match the site prefix as know by A -- i.e. it will reject the packets sent by hosts constructing an address with ISP B's prefix.
 
There are some possible simplifications. For example, for a site of any significant size, the second ISP who just won a contract for the site is likely to cooperate, e.g. by not performing ingress filtering, at least during the transition. But your draft ought to discuss these issues.
 
-- Christian Huitema

---

From: "Christian Huitema" <[email-masked]>
Date: Mon, 28 Apr 2003 10:52:03 -0700

I believe Fred's suggestion of adding 'a section 3 entitled "how not to
shoot one-self in the foot"' is a practical way to address the issue. I
also believe we should consider this under the hypothesis that the site
is "adding a provider", or possibly adding a native prefix to an
existing 6to4 prefix. Fred, the following is a first cut at your
proposed section 3.2.

In the intermediate phase of the renumbering, the site uses two
prefixes, possibly allocated by two different providers. There are
really three cases: both providers accept both prefix, a provider
accepts both prefix and the other does not, and each provider only
accepts its own prefix.

The case of two providers both practicing ingress filtering is pretty
hard to solve using the current tools. It requires that the exit link be
chosen as a function of the source address, something current routing
procedures don't do, or alternately that the source address is chosen as
a function of the destination address, something current hosts don't do.
Better tools may be available some day, but in the current state sites
should ensure the cooperation of at least one of the two providers, and
preferably both.

The preferred scenario is indeed to convince both providers to support
both prefixes. Providers often perform ingress filtering by using a
"reverse path" check. Providers can bypass this reverse path check by
adding a route for the second prefix in the router that performs ingress
filtering. However, adding the second prefix requires some
administrative action by the provider. The new provider may easily be
convinced, since after all it is getting some additional business. The
old provider may or may not be easily convinced.

If only one provider supports both prefixes, then the only easy solution
is to use that provider as the default route. That will work, but it has
the obvious issue of relying on only one of the two providers for
outgoing traffic.

Multi-homing with 6to4 is a special case. In 6to4, ingress filtering is
only an issue for the 6to4 relay routers, which are supposed to drop any
traffic that does not originate from a 6to4 prefix. In a scenario where
a site is adding a native IPv6 prefix to an existing 6to4 connectivity,
ingress filtering issues are solved by convincing the new provider to
accept traffic from both prefixes, by setting a default route through
the new provider, and by only routing 6to4 traffic (2002::/16) through
the existing 6to4 system.

-- Christian Huitema

---

From: Dan Lanciani <[email-masked]>
Date: Mon, 28 Apr 2003 16:12:30 -0400 (EDT)

Does anyone else find this thread ironic?  During the site-local debate a
number of people dismissed the need for a mechanism to provide connection
survival during renumbering on the grounds that renumbering would always
involve a generously long period of overlap between old and new prefixes.  Now
we are talking about flag days.  It would have been nice if the folks who are
currently (IMHO, correctly) pointing out the problems with the overlap scheme
had jumped in back then.  It would be nice if the folks who asserted the ease
of overlap (even though it is very difficult to distinguish this overlap from
the "hard" multi-homing problem) would jump in now and explain why the issues
being raised are non-problems.  In general, it would be nice if we could adopt
a more wholistic view of the set of problems around which we continue to dance.
Moving the hard work out of whatever piece of the protocol we are talking about
today only makes it show up in next month's piece--often as harder work.

				Dan Lanciani
				ddl@danlan.*com

---

From: Fred Baker <[email-masked]>
Date: Mon, 28 Apr 2003 15:09:51 -0700

At 02:40 PM 4/25/2003 -0700, Michel Py wrote:
>how do you make renumbering easy when the following (with matching SNMP 
>config) is a requirement:
>
>line vty 0 4
>    no login
>    transport input none

I think the fundamental answer is that the same procedure can be applied, 
but the duration will be (much) longer or the cost (much) will be higher, 
and perhaps (very probably) both. The ISP will have to transport 
appropriate operational staff to each relevant site, have them manually 
enter the required configuration changes, and proceed on. In the case that 
the trusted staff is relatively small (the only reason I can think of why 
someone would remove the permission from other operational staff), and 
especially in view of the fact that this procedure calls for as many as 
three visits to each site if not each network device (to add a prefix, to 
enable its use as a source address, and to remove the old prefix), the 
operation seems doomed to extreme griping.