Subject: Addresses and BGP (was RE: was a6/aaaa - RA/ND & exchanges)

From: "Christian Huitema" <[email-masked]>
Date: Tue, 1 May 2001 09:22:20 -0700

> BGP is bound between two IP addresses. When the IP addresses change
> the BGP peering is lost.

This is a valid point, which has already been discussed many times on
the list, but is not discussed or even alluded to in RFC 2283. The
solution in IGPs is to use link-local addresses for exchanging IGP
packets; this means that the "peering" in RIP, OSPF or IS-IS will
survive renumbering. This solution is not entirely applicable to BGP.
However, we can probably use a combination of the following:

1) Use of link local addresses when BGP peers are directly connected.
2) Use of site-local addresses when BGP peers belong to the same site.
3) Use of mobile-IP solutions so that TCP survives renumbering.
4) Use of IPv4 addresses in multi-protocol environments.

Each of these solutions is partial, and requires work, e.g. discovery
that peers are on the same link, or in the same site. I would argue that
this type of work is typical of the implementation phase that we are
entering, and should be conducted by pragmatists (the IDR working group)
rather than explorers (IPNG).

-- Christian Huitema
--------------------------------------------------------------------
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: Pekka Savola <[email-masked]>
Date: Fri, 4 May 2001 11:15:21 +0300 (EEST)

> 4) Use of IPv4 addresses in multi-protocol environments.
[snip]

When considering these options, please note that site-local addresses may
also need to be renumbered (probably often at the same time when
subnetting of global addresses changes).

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Robert Elz <[email-masked]>
Date: Fri, 04 May 2001 16:57:57 +0700

Date:        Fri, 4 May 2001 11:15:21 +0300 (EEST)
    From:        Pekka Savola <[email-masked]>
    Message-ID:  <[email-masked]>

  | When considering these options, please note that site-local addresses may
  | also need to be renumbered (probably often at the same time when
  | subnetting of global addresses changes).

This is certainly true, but this is a completely different kind of
event.

This one is a self-inflicted renumbering requirement, for whatever reason
a site has decided that some of its nodes have to be renumbered.  This
almost always only applies to some of the nodes (a busy subnet is being
split into two nets, or whatever).

Because of this, the site can plan the event as it likes, give itself
any amount of changeover time, and assess the cost/benefit tradeoff of
doing the change in the first place.

Then, because it is the internal part of the number space that is
being altered, it is much less likely that (aside from written forms
of particular host addresses) the changes will affect other sites - that
is, it isn't very likely that someone will be filtering one subnet of
your site and not others without your knowledge, that kind of thing is
usually all or nothing.   So you're not likely to suffer because of
lack of reconfig at other sites.

The renumbering that really hurts is the one you're forced into - where
you're given a period of N (days/weeks/months) and told that after that
your old number will no longer be valid.  No options.

This isn't to imply that any renumbering is easy - but the (almost always)
partial renumber that results in subnet numbers changing is by far the
easier one to deal with.   Most of us deal with that kind of event quite
regularly.

kre