名古屋市港区本星崎町は同区東端部に位置し、東・南・北は南区、西は大江町に接する。南区本星崎町は同区東部に位置し、東は本城町・星宮町、西は西田町・星園町に接する。港区本星崎町は、後述の通り南区本星崎町の一部が分割されて成立したものであるが、分割後に南区側で町名変更が実施されたため、現在両者の町域は接していない。
IKEv1は Internet Key Exchange protocol version 1 の意味であり、UDPポート番号500上で通信される鍵交換プロトコルである。開発時には ISAKMP/Oakley と呼ばれた過去があり、これはISAKMP(Internet Security Association and Key Management Protocol)プロトコルの上で Oakley 鍵交換手順を実装したものという意味である。すなわち、IKEv1 は ISAKMP と必ずしも同じものではない。IKEv1 はフェーズ1、フェーズ2と呼ばれる二段階の手順で鍵交換を行う。まずフェーズ1で IKE プロトコル同士の認証と暗号交換を行い（これをISAKMP SA交換とも呼ぶ）、フェーズ2で IPsec の適用条件と鍵情報の交換を行う（IPsec SA 交換とも呼ぶ）。フェーズ1には Main Mode,Aggressive Mode と呼ばれる2つの手順がある。前者は ISAKMP 仕様における Identity Protection Exchange 手順の呼び名であり、後者は ISAKMP 仕様における Aggressive Exchange 手順の呼び名である。（用語定義の錯綜と難解さも IKE の理解を難しくしている理由の一つである）。フェーズ2の通信はフェーズ1において成立した共有鍵を用いて暗号化される。フェーズ2の手順は Quick Mode と呼ばれ、これは ISAKMP にはなく IKEv1 で新たに定義されたものである。IKEv1 の規格上では New Group Mode という手順も定義されているが、実際には殆ど使われていない。Oakley 鍵交換手順は公開鍵暗号を用いた鍵交換手順のアルゴリズムとパラメータのセットをいくつか定めたもので、アルゴリズムは大きく分けて Diffie-Hellman鍵共有 (DH-MODP) と楕円曲線暗号 (EC2N) の2種がある。鍵長は DH-MODP で768,1024,1536,2048,3072,4096,6144,8192bit、EC2N で155,188,163,283,409,571bit が定義されている。IKE の通信を行うノードを IKE ピアと呼び、IKE 要求を発行する側をイニシエータ、受信した側をレスポンダと呼ぶ。Oakley のパラメータや IPsec SA の詳細はイニシエータ側が使用可能な組み合わせを提示し（これをプロポーザルと呼ぶ）、レスポンダ側が最も適切と判断したものを選択して合意を取るという手順を踏む。何をもって「適切」とみなすかは実装と設定に依存し、これを「ポリシー」と呼ぶ場合もあるが、狭義の意味における IPsec Security Policy とは必ずしも同じニュアンスではないので混同しないよう注意が必要である。用語の混同を避けるため、RFC 4301 においてはこれら「鍵交換時の挙動を定めるパラメータの一覧」を Peer Authorization Database (PAD) と呼んでいる。Aggressive Mode はフェーズ1におけるプロポーザル手順の一部を削減し、パラメータの一部を決め打ちとすることで Main Mode にくらべパケット交換回数を減らし（3往復6パケット → 1.5往復3パケット）通信効率を向上している。ただし Main Mode では最後に交換される ID パケットが暗号化されるのに対し、Agressive ModeではID情報が暗号化されないまま送信されるので、盗聴によるセキュリティホールを招きかねないというリスクもある。フェーズ1にどちらのモードを用いるかはイニシエータに依存し、やはりそのネットワークにおけるポリシー (PAD) によって決定される。IKEv1 では鍵交換と同時に相手ピアの認証を行う。認証アルゴリズムもフェーズ1において提示-合意のプロセスを踏んで実行され、認証方式には事前鍵共有方式 (PSK:Pre Shared Key)、デジタル署名方式 (Digital Signatures)、公開鍵暗号方式 (Public Key Encryption) などがある。フェーズ2で生成される IPsec SA の鍵情報は、原則としてフェーズ1で生成された共有鍵情報から生成される。しかし複数個の IPsec SA をまとめて生成するような使用法の場合、全ての IPsec SA 情報が1つの秘密情報に依存することは好ましくない場合がある。このような場合、IKEv1 では Perfect Forward Secrecy (PFS) と呼ばれるオプション機能の利用が（通信ピア双方に実装されていれば）可能である。PFS は個々のフェーズ2交換時に新たな Oakley 鍵交換を行い、個々に異なった共有鍵を生成して IPsec SA の秘密鍵生成時に適用するものである。PFSは一般に通信秘匿性を向上させるがピアの処理負荷も向上させるため、これを適用すべきか否かもポリシー（あるいはPAD）に応じて決定すべきとされている。なお1回のフェーズ1交換に付随するフェーズ2の回数を1回かぎりに制限することにより、結果的に全てのフェーズ2生成鍵を異なったものにすることで PFS と同等の秘匿性を得る実装もあり、これを Master PFS と呼ぶこともある。この場合、上記の「狭義のPFS」は Session PFS と呼ばれて区別される。このように IKEv1 には数多くのモードとパラメータとオプションの組み合わせがあり、さらに多くの拡張仕様が存在する。その中には標準案として提案されたもののドラフトを通過できず、正式な RFC として記載されずに終わったものも少なくない。また IKEv1 仕様には難解で紛らわしい用語が錯綜しているため、実装系において独自の名前を与えている場合もある（例えば Microsoft Windows では IPsec におけるセレクタをフィルタと呼び、ポリシーをアクションと呼んでいる)。このため「IETF標準」であるはずの IKEv1 同士でも異機種間接続のためにはプロトコルおよび製品実装の深遠な理解が必要になってしまい、「IPsec でネットワークを組む場合は同じメーカーの同じ機器を使用することが最も確実」という慣習を生むことになってしまった。IETF は混沌としてしまった IKEv1 の整理を諦め、IKEv2 をもって標準化の仕切り直しを図っている。