Re: Seeming contradiction on forwarding addresses?
Mike Fox <mjfox@US.IBM.COM> Tue, 14 October 2003 18:23 UTC
Received: from grape.ease.lsoft.com (grape.ease.lsoft.com [209.119.1.39]) by ietf.org (8.9.1a/8.9.1a) with ESMTP id OAA22769 for <ospf-archive@LISTS.IETF.ORG>; Tue, 14 Oct 2003 14:23:14 -0400 (EDT)
Received: from PEACH.EASE.LSOFT.COM (209.119.1.45) by grape.ease.lsoft.com (LSMTP for OpenVMS v1.1b) with SMTP id <3.003910D4@grape.ease.lsoft.com>; Tue, 14 Oct 2003 14:23:21 -0400
Received: from PEACH.EASE.LSOFT.COM by PEACH.EASE.LSOFT.COM (LISTSERV-TCP/IP release 1.8e) with spool id 57889964 for OSPF@PEACH.EASE.LSOFT.COM; Tue, 14 Oct 2003 14:23:20 -0400
Received: from 32.97.110.130 by WALNUT.EASE.LSOFT.COM (SMTPL release 1.0i) with TCP; Tue, 14 Oct 2003 14:23:20 -0400
Received: from westrelay02.boulder.ibm.com (westrelay02.boulder.ibm.com [9.17.195.11]) by e32.co.us.ibm.com (8.12.10/8.12.2) with ESMTP id h9EINJE6301236 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 14 Oct 2003 14:23:19 -0400
Received: from d03nm118.boulder.ibm.com (d03av02.boulder.ibm.com [9.17.193.82]) by westrelay02.boulder.ibm.com (8.12.9/NCO/VER6.6) with ESMTP id h9EINIlA115270 for <OSPF@PEACH.EASE.LSOFT.COM>; Tue, 14 Oct 2003 12:23:18 -0600
X-Mailer: Lotus Notes Release 5.0.11 July 24, 2002
X-MIMETrack: Serialize by Router on D03NM118/03/M/IBM(Release 6.0.2CF2|July 23, 2003) at 10/14/2003 12:23:18
MIME-Version: 1.0
Content-type: text/plain; charset="US-ASCII"
Message-ID: <OF77F1317B.9E8A0DFF-ON85256DBF.00624EE8-85256DBF.00642C3C@us.ibm.com>
Date: Tue, 14 Oct 2003 14:23:04 -0400
Reply-To: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
Sender: Mailing List <OSPF@PEACH.EASE.LSOFT.COM>
From: Mike Fox <mjfox@US.IBM.COM>
Subject: Re: Seeming contradiction on forwarding addresses?
To: OSPF@PEACH.EASE.LSOFT.COM
Precedence: list
Acee wrote:
> the forwarding address itself
> must be reachable
> by an OSPF intra-area or inter-area route (which is by definition part
> of the OSPF routing
> domain). In this context, I prefer to use the term OSPF routing domain
> rather than AS since
> there will often be non-OSPF routes in use within an AS running OSPF as
> the IGP.
This still does not resolve the contradiction. RFC 2328 contains the
following text in section 2.3:
====begin quoted text=====
For example,
suppose in Figure 2 there is an additional router attached to
Network N6, called Router RTX. Suppose further that RTX does
not participate in OSPF routing, but does exchange BGP
information with the AS boundary router RT7. Then, Router RT7
would end up advertising OSPF external routes for all
destinations that should be routed to RTX. An extra hop will
sometimes be introduced if packets for these destinations need
always be routed first to Router RT7 (the advertising router).
To deal with this situation, the OSPF protocol allows an AS
boundary router to specify a "forwarding address" in its AS-
external-LSAs. In the above example, Router RT7 would specify
RTX's IP address as the "forwarding address" for all those
destinations whose packets should be routed directly to RTX.
====end quoted text====
Since RTX is not participating in OSPF routing, a route to it would not be
internal to the OSPF AS (or routing domain if you prefer). Yet this text
says to use RTX's address as the forwarding address. Because of the
other requirement that the forwarding address be reachable via an OSPF
internal path, no other router would be able to use this AS External
advertisement.
This becomes more of a problem in IPv6 but it also causes problems in IPv4.
Consider this example, modified from the RFC:
|
+---+ |
|RTA|-----| +---+
+---+ |-----|RTX|
| +---+
+---+ |
|RTB|-----|
+---+ |
|
+---+ |
|RTC|-----|
+---+ |
|
+
RTA-RTC are running OSPF. RTX is not. RTA advertises an AS external
default route with a forwarding address of RTX. In IPv4, that forwarding
address would be in the network's subnet so even though RTX is not running
OSPF, RTB and RTC learn OSPF subnet routes that would allow packets to be
forwarded to RTX. However if the system programmer coded a static route to
RTX on RTB or RTC, that route would be more specific than the OSPF subnet
route, so it would be found when looking up RTX, and since it's not
internal to the OSPF domain the default route becomes unusable by RTB and
RTC.
In IPv6 the situation gets worse because there is no requirement for all
addresses on the link to fall into the same prefix. RTX could have a
global address that is not in any prefix known by the other routers,
requiring a static route to be coded -- but if the route to RTX is static
(i.e., not OSPF), that makes it unusable as a forwarding address for any AS
external LSAs.
Why not simply require that the forwarding address be reachable, period?
The route could be static, RIP, BGP or whatever. As long as it's possible
to route to the forwarding address, why be picky about the type of route?
Mike
-----------------------------------------------------------------------
Enterprise Network Solutions
-----------------------------------------------------------------------
Research Triangle Park, NC USA