RFC3846 日本語訳

Network Working Group                                       F. Johansson
Request for Comments: 3846                                   ipUnplugged
Category: Standards Track                                   T. Johansson
                                                              Bytemobile
                                                               June 2004

コメントを求めるワーキンググループF.ヨハンソン要求をネットワークでつないでください: 3846はカテゴリをipUnpluggedしました: 標準化過程T.ヨハンソンBytemobile2004年6月

     Mobile IPv4 Extension for Carrying Network Access Identifiers

ネットワークアクセス識別子を運ぶためのモバイルIPv4拡張子

Status of this Memo

このMemoの状態

   This document specifies an Internet standards track protocol for the
   Internet community, and requests discussion and suggestions for
   improvements.  Please refer to the current edition of the "Internet
   Official Protocol Standards" (STD 1) for the standardization state
   and status of this protocol.  Distribution of this memo is unlimited.

このドキュメントは、インターネットコミュニティにインターネット標準化過程プロトコルを指定して、改良のために議論と提案を要求します。 このプロトコルの標準化状態と状態への「インターネット公式プロトコル標準」(STD1)の現行版を参照してください。 このメモの分配は無制限です。

Copyright Notice

版権情報

   Copyright (C) The Internet Society (2004).

Copyright(C)インターネット協会(2004)。

Abstract

要約

   When a mobile node moves between two foreign networks, it has to be
   re-authenticated.  If the home network has both multiple
   Authentication Authorization and Accounting (AAA) servers and Home
   Agents (HAs) in use, the Home AAA server may not have sufficient
   information to process the re-authentication correctly (i.e., to
   ensure that the same HA continues to be used).  This document defines
   a Mobile IP extension that carries identities for the Home AAA and HA
   servers in the form of Network Access Identifiers (NAIs).  The
   extension allows a Home Agent to pass its identity (and that of the
   Home AAA server) to the mobile node, which can then pass it on to the
   local AAA server when changing its point of attachment.  This
   extension may also be used in other situations requiring
   communication of a NAI between Mobile IP nodes.

可動のノードが2つの外国ネットワークの間を動くとき、それは再認証されなければなりません。 ホームネットワークに複数のAuthentication AuthorizationとAccounting(AAA)サーバと使用中のホームのエージェント(HAs)の両方があるなら、ホームAAAサーバには、正しく再認証を処理できるくらいの情報がないかもしれません(すなわち、そんなに同じHAを確実にするのは、使用され続けています)。 このドキュメントはホームAAAとHAサーバのためにNetwork Access Identifiers(NAIs)の形でアイデンティティを運ぶモバイルIP拡大を定義します。 ホームのエージェントは拡大で、アイデンティティ(そして、ホームAAAサーバのもの)を可動のノードに通過できます。(次に、接着点を変えるとき、それは、ローカルのAAAサーバにそれを通過できます)。 また、この拡張子はモバイルIPノードの間のNAIに関するコミュニケーションを必要とする他の状況で使用されるかもしれません。

Table of Contents

目次

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  2
   2.  Requirements terminology . . . . . . . . . . . . . . . . . . .  2
   3.  NAI Carrying Extension . . . . . . . . . . . . . . . . . . . .  3
       3.1.  Processing of the NAI Carrying Extension . . . . . . . .  3
   4.  HA Identity subtype  . . . . . . . . . . . . . . . . . . . . .  4
   5.  AAAH Identity subtype  . . . . . . . . . . . . . . . . . . . .  4
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . .  5
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . .  5
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . .  6

1. 序論. . . . . . . . . . . . . . . . . . . . . . . . . 2 2。 要件用語. . . . . . . . . . . . . . . . . . . 2 3 拡大. . . . . . . . . . . . . . . . . . . . 3 3.1を運ぶNAI。 拡大. . . . . . . . 3 4を運ぶNAIの処理。 HA Identity subtype. . . . . . . . . . . . . . . . . . . . . 4 5。 AAAH Identity subtype. . . . . . . . . . . . . . . . . . . . 4 6。 セキュリティ問題. . . . . . . . . . . . . . . . . . . 5 7。 IANA問題. . . . . . . . . . . . . . . . . . . . . 5 8。 承認. . . . . . . . . . . . . . . . . . . . . . . 6

Jhansson & Johansson        Standards Track                     [Page 1]

RFC 3846              MIPv4 Extension for AAA NAIs             June 2004

JhanssonとヨハンソンStandardsは2004年6月にAAA NAIsのためにRFC3846MIPv4拡張子を追跡します[1ページ]。

   9.  Normative References . . . . . . . . . . . . . . . . . . . . .  6
   10. Authors' Addresses . . . . . . . . . . . . . . . . . . . . . .  7
   11. Full Copyright Statement . . . . . . . . . . . . . . . . . . .  8

9. 引用規格. . . . . . . . . . . . . . . . . . . . . 6 10。 作者のアドレス. . . . . . . . . . . . . . . . . . . . . . 7 11。 完全な著作権宣言文. . . . . . . . . . . . . . . . . . . 8

1.  Introduction

1. 序論

   When building networks one would like to be able to have redundancy.
   In order to achieve this, one might place multiple AAA servers in one
   domain.  When a mobile node registers via a visited network, the
   authentication will be handled by one of the AAA servers in the home
   domain.  At a later point, when the mobile node moves to another
   visited domain it again has to be authenticated.  However, due to the
   redundancy offered by the AAA protocol, it can not be guaranteed that
   the authentication will be handled by the same AAAH server as the
   previous one, which can result in the new AAAH not knowing to which
   HA the session was assigned.  This document defines a Mobile IP
   extension which can be used to distribute the information needed to
   resolve this.

建てるとき、ネットワーク1には、冗長がありたがっています。 これを達成するために、1つは複数のAAAサーバを1つのドメインに置くかもしれません。 可動のノードが訪問されたネットワークを通して登録すると、認証は家のドメインのAAAサーバの1つによって扱われるでしょう。 可動のノードが別の訪問されたドメインに動くとき、後のポイントでは、それは再び認証されなければなりません。 しかしながら、AAAプロトコルによって提供された冗長のため、認証が前のものと同じAAAHサーバによって扱われるのを保証できません。ものはセッションがどのHAに割り当てられたかを知らない新しいAAAHをもたらすことができます。 このドキュメントはこれを決議するのに必要である情報を分配するのに使用できるモバイルIP拡張子を定義します。

   Furthermore, the only information that is normally available about
   the home agent in the registration request is the IP address as
   defined in RFC 3344 [5].  Unfortunately this may not be enough since
   some AAA infrastructures (such as Diameter [6]) use realm based
   routing; such a AAA infrastructure needs to know the FQDN identity of
   the home agent to be able to correctly handle the assignment of the
   home agent.  A reverse DNS lookup would only disclose the identity of
   the Mobile IP interface for that HA IP address, which may or may not
   have a one-to-one correspondence with the home agent FQDN identity.
   This is a reason for the HA to also include its own identity in the
   registration reply.  The MIP v4 extension defined in this document
   also has a subtype defined by which this may be done.  The HA
   identity can then be included by the mobile node in later
   registration requests when changing the point of attachment.

その上、唯一の通常、登録要求における家のエージェントに関して利用可能な情報がRFC3344[5]で定義されるようにIPアドレスです。 残念ながら、いくつかのAAAインフラストラクチャ以来これは十分でないかもしれません。(Diameter[6])が分野を使用するので、そのようなものはルーティングを基礎づけました。 そのようなAAAインフラストラクチャは、家のエージェントのFQDNのアイデンティティが正しく家のエージェントの課題を扱うことができるのを知る必要があります。 逆のDNSルックアップはそのHA IPアドレスのためにモバイルIPインタフェースのアイデンティティを明らかにするだけでしょう。(それは、家のエージェントFQDNのアイデンティティとの1〜1つの通信を持っているかもしれません)。 これはまたHAが登録回答にそれ自身のアイデンティティを含む理由です。 また、本書では定義されたMIP v4拡張子はこれをするかもしれない定義された「副-タイプ」を持っています。 そして、接着点を変えるとき、可動のノードは後の登録要求にHAのアイデンティティを含むことができます。

2.  Requirements terminology

2. 要件用語

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in BCP 14, RFC 2119 [1].

キーワード“MUST"、「必須NOT」が「必要です」、“SHALL"、「」、“SHOULD"、「「推薦され」て、「5月」の、そして、「任意」のNOTはBCP14(RFC2119[1])で説明されるように本書では解釈されることであるべきです。

   The Mobile IP related terminology described in RFC 3344 [5] is used
   in this document.  In addition, the following terms are used:

RFC3344[5]で説明されたモバイルIP関連用語は本書では使用されます。 さらに、次の期間は使用されています:

   AAAH
      One of several possible AAA Servers in the Home Network

ホームNetworkの数個の可能なAAA ServersのAAAH One

Jhansson & Johansson        Standards Track                     [Page 2]

RFC 3846              MIPv4 Extension for AAA NAIs             June 2004

JhanssonとヨハンソンStandardsは2004年6月にAAA NAIsのためにRFC3846MIPv4拡張子を追跡します[2ページ]。

   FQDN
      Fully Qualified Domain Name.

FQDN完全修飾ドメイン名。

   Identity
      The identity of a node is equal to its FQDN.

アイデンティティ、ノードのアイデンティティはFQDNと等しいです。

   NAI
      Network Access Identifier [2].

NAIはアクセス識別子[2]をネットワークでつなぎます。

3.  NAI Carrying Extension

3. 拡大を運ぶNAI

   This section defines the NAI Carrying Extension which may be used in
   Mobile IP Registration Request and Reply messages, and also in Mobile
   IP Agent Advertisements [5].  The extension may be used by any node
   that wants to send identity information in the form of a NAI [4].
   This document also defines some subtype numbers which identify the
   specific type of NAI carried in Sections 4 and 5.  It is expected
   that other types of NAI will be defined by other documents in the
   future.

このセクションはモバイルIP Registration RequestとReplyメッセージ、およびモバイルIPエージェントAdvertisements[5]でも使用されるかもしれないNAI Carrying Extensionを定義します。 拡張子はNAI[4]の形でアイデンティティ情報を送りたがっているどんなノードによっても使用されるかもしれません。 また、このドキュメントはセクション4と5で運ばれたNAIの特定のタイプを特定するいくつかの「副-タイプ」番号を定義します。 NAIの他のタイプが将来他のドキュメントによって定義されると予想されます。

     0                   1                   2                   3
     0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
    |     Type      |   Length      |   Sub-Type    |    NAI ...
    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | タイプ| 長さ| サブタイプ| NAI… +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

   Type      136 (skippable) [5].

136(skippable)[5]をタイプしてください。

   Length    8-bit unsigned integer.  Length of the extension, in
      octets, excluding the extension Type and the extension Length
      fields.  This field MUST be set to 1 plus the total length of the
      NAI field.

長さ、8ビットの符号のない整数。 拡大Typeと拡大Length分野を除いた八重奏における、拡大の長さ。 NAI分野の1と全長にこの分野を設定しなければなりません。

   Sub-Type  This field describes the particular type NAI which is
      carried in the NAI field.

サブType This分野はNAI分野で運ばれる特定のタイプNAIについて説明します。

   NAI       Contains the NAI [2] in a string format.

記号列の書式のNAI Contains NAI[2]。

3.1.  Processing of the NAI Carrying Extension

3.1. 拡大を運ぶNAIの処理

   When a mobile node or home agent adds a NAI Carrying Extension to a
   registration message, the extension MUST appear prior to any
   authentication extensions.

可動のノードか家のエージェントが登録メッセージにNAI Carrying Extensionを追加するとき、拡大はどんな認証拡大の前にも現れなければなりません。

Jhansson & Johansson        Standards Track                     [Page 3]

RFC 3846              MIPv4 Extension for AAA NAIs             June 2004

JhanssonとヨハンソンStandardsは2004年6月にAAA NAIsのためにRFC3846MIPv4拡張子を追跡します[3ページ]。

   In the event the foreign agent adds a NAI Carrying Extension to a
   registration message, the extension MUST appear prior to any
   authentication extensions added by the FA.

出来事では、外国人のエージェントは登録メッセージにNAI Carrying Extensionを追加して、拡大はFAによって加えられたどんな認証拡大の前にも現れなければなりません。

   If an HA has appended a NAI Carrying Extension to a Registration
   Reply to an MN, and does not receive the NAI extension in subsequent
   Registration Request messages from the MN, the HA can assume that the
   MN does not understand this NAI extension.  In this case, the HA
   SHOULD NOT append this NAI extension to further Registration Reply
   messages to the MN.

HAがミネソタへのRegistration ReplyにNAI Carrying Extensionを追加して、ミネソタからその後のRegistration RequestメッセージにおけるNAI拡張子を受け取らないなら、HAは、ミネソタがこのNAI拡張子を理解していないと仮定できます。 この場合、HA SHOULD NOTは、Registration Replyメッセージをミネソタに促進するためにこのNAI拡張子を追加します。

4.  HA Identity subtype

4. HA Identity subtype

   The HA identity uses subtype 1 of the NAI Carrying Extension.  It
   contains the NAI of the HA in the form hostname@realm.  Together the
   hostname and realm form the complete FQDN (hostname.realm) of the HA.

HAのアイデンティティはNAI Carrying Extensionの「副-タイプ」1つを使用します。 それはフォーム hostname@realm にHAのNAIを含んでいます。 ホスト名と分野はHAの完全なFQDN(hostname.realm)を一緒に、形成します。

   A Home Agent using this extension MUST provide it in the first
   Registration Reply sent to a Mobile Node which is not currently
   registered.  The extension only need to be included in subsequent
   Registration Replies if the same extension is included in
   Registration Requests received from the same Mobile Node.

この拡張子を使用しているホームのエージェントは現在登録されないモバイルNodeに送られた最初のRegistration Replyにそれを供給しなければなりません。 同じ拡大が同じモバイルNodeから受け取られたRegistration Requestsに含まれている場合にだけ、拡張子は、その後のRegistration Repliesに含まれる必要があります。

   A mobile node using this extension MUST, if it receives it in a
   registration reply message, provide it in every subsequent
   registration request when re-authentication is needed.  Failure to
   re-authenticate, for instance because no AAAH can be reached, will
   result in termination of the Mobile-IP session.  Upon initiation of a
   new session a new HA Identity NAI may be provided to the Mobile node,
   and the requirement above will apply to the newly received NAI.

再認証が必要であるときに、登録応答メッセージでそれを受けるなら、この拡張子を使用する可動のノードはあらゆるその後の登録要求にそれを備えなければなりません。 AAAHが全くあるはずがないので、例えば再認証する失敗は、達していて、モバイルIPセッションの終了をもたらすでしょう。 新しいセッションの開始のときに、新しいHA Identity NAIをモバイルノードに提供するかもしれません、そして、上記の要件は新たに受け取られたNAIに適用されるでしょう。

   If the mobile node requires a specific home agent and it has the NAI
   available it MUST provide this extension in its initial registration
   request.

可動のノードが特定の家のエージェントを必要として、利用可能なNAIを持っているなら、それは新規登録要求におけるこの拡大を提供しなければなりません。

   A foreign agent which receives the Home Agent NAI by this extension
   in a registration request SHOULD include the Home Agent NAI when
   requesting Mobile Node authentication through the AAA infrastructure
   if the AAA protocol used can carry the information.

使用されるAAAプロトコルが情報を運ぶことができるならAAAインフラストラクチャを通してモバイルNode認証を要求するとき、SHOULDがホームのエージェントNAIを含んでいるという登録要求にこの拡大でホームのエージェントNAIを受け取る外国人のエージェント。

5.  AAAH Identity subtype

5. AAAH Identity subtype

   The AAAH identity uses subtype 2 of the NAI Carrying Extension.  It
   contains the NAI of the home AAA server in the form hostname@realm.
   Together the hostname and realm form the complete FQDN
   (hostname.realm) of the home AAA server.

AAAHのアイデンティティは2「副-タイプ」NAI Carrying Extensionを使用します。 それはフォーム hostname@realm に家のAAAサーバのNAIを含んでいます。 ホスト名と分野は家のAAAサーバの完全なFQDN(hostname.realm)を一緒に、形成します。

Jhansson & Johansson        Standards Track                     [Page 4]

RFC 3846              MIPv4 Extension for AAA NAIs             June 2004

JhanssonとヨハンソンStandardsは2004年6月にAAA NAIsのためにRFC3846MIPv4拡張子を追跡します[4ページ]。

   If several AAA servers exist in the Home Network, a Home Agent
   providing AAAH selection support according to this document MUST
   provide the AAAH identity in the first Registration Reply sent to the
   Mobile Node.  The extension only needs to be included in subsequent
   Registration Replies if the same extension is included in
   Registration Requests received from the same Mobile Node.

いくつかのAAAサーバがホームNetworkに存在しているなら、このドキュメントに応じて選択サポートをAAAHに供給するホームのエージェントはモバイルNodeに送られた最初のRegistration ReplyにAAAHのアイデンティティを供給しなければなりません。 同じ拡大が同じモバイルNodeから受け取られたRegistration Requestsに含まれている場合にだけ、拡張子は、その後のRegistration Repliesに含まれる必要があります。

   A mobile node SHOULD save the latest AAAH Identity received in a
   registration reply message and SHOULD provide the AAAH Identity in
   every registration request sent when re-authenticating, for
   efficiency reasons.  Failure to reach the indicated AAAH during re-
   authentication will result in a new AAAH Identity NAI being returned
   (which should then be saved and provided in subsequent registration
   requests).  Similarly, failure to re-authenticate, for instance
   because no AAAH can be reached, will result in termination of the
   Mobile-IP session; on initiation of a new session, a new AAAH
   Identity NAI may be provided to the Mobile Node for re-use during
   later re-registrations.

SHOULDが最新のAAAH Identityを取っておく可動のノードは登録応答メッセージで受信しました、そして、SHOULDは効率のために理由を再認証するとき送られたあらゆる登録要求にAAAH Identityを提供します。 再認証の間に示されたAAAHに達しないと、返される新しいAAAH Identity NAI(次に、その後の登録要求に救われて、提供されるべきである)をもたらすでしょう。 同様に、AAAHが全くあるはずがないので、例えば再認証する失敗は、達していて、モバイルIPセッションの終了をもたらすでしょう。 新しいセッションの開始のときに、再使用のために後の再登録証明書の間、新しいAAAH Identity NAIをモバイルNodeに提供するかもしれません。

   A foreign agent which receives the AAAH NAI by this extension in a
   registration request SHOULD include the AAAH NAI provided when
   requesting Mobile Node authentication through the AAA infrastructure
   if the AAA protocol used can carry the information.

使用されるAAAプロトコルが情報を運ぶことができるならAAAインフラストラクチャを通したモバイルNode認証を要求するとき、SHOULDがAAAH NAIを含んでいるという登録要求にこの拡大でAAAH NAIを受け取る外国人のエージェントは提供しました。

6.  Security Considerations

6. セキュリティ問題

   This specification introduces new Mobile IP extensions that are used
   to carry mobility agent and AAA server identities, in the form of
   Network Access Identifiers.  The Mobile IP messages that carry this
   extension MUST be authenticated as described in [4], unless other
   authentication methods have been agreed upon.  Therefore, this
   specification does not lessen the security of Mobile IP messages.

この仕様は移動性エージェントとAAAサーバのアイデンティティを運ぶのに使用される新しいモバイルIP拡張子を紹介します、Network Access Identifiersの形で。 [4]で説明されるようにこの拡大を運ぶモバイルIPメッセージを認証しなければなりません、他の認証方法が同意されていないなら。 したがって、この仕様はモバイルIPメッセージのセキュリティを少なくしません。

   It should be noted that the identities sent in the extensions
   specified herein MAY be sent in the clear over the network.  However,
   the authors do not envision that this information would create
   security issues.

アイデンティティが、ここに指定された拡大がネットワークの上の明確で送られるかもしれないのを送ったことに注意されるべきです。 しかしながら、作者はそれを思い描きません。この情報は安全保障問題を作成するでしょう。

7.  IANA Considerations

7. IANA問題

   This document defines one new mobile IP extension, and one new Mobile
   IP extension sub-type numbering space to be managed by IANA.

このドキュメントは1つの新しい可動のIP拡大、およびIANAによって管理されるようにスペースに付番する1つの新しいモバイルIP拡大サブタイプを定義します。

   Section 3 defines a new Mobile IP extension, the Mobile IP NAI
   Carrying Extension.  The type number for this extension is 136.  This
   extension introduces a new sub-type numbering space where the values

セクション3は新しいモバイルIP拡大、モバイルIP NAI Carrying Extensionを定義します。 この拡大の形式数は136です。 この拡大がスペースに付番しながら新しいサブタイプを導入する、どこ、値

Jhansson & Johansson        Standards Track                     [Page 5]

RFC 3846              MIPv4 Extension for AAA NAIs             June 2004

JhanssonとヨハンソンStandardsは2004年6月にAAA NAIsのためにRFC3846MIPv4拡張子を追跡します[5ページ]。

   1 and 2 have been assigned in this document.  Approval of new Mobile
   IP NAI Carrying Extension sub-type numbers is subject to Expert
   Review, and a specification is required [3].

本書では1と2を割り当ててあります。 新しいモバイルIP NAI Carrying Extensionサブ形式数の承認はExpert Reviewを受けることがあります、そして、仕様は必要な[3]です。

   The content and format for this extension is not specific to AAA
   NAIs, so if in the future new NAIs are defined which do not strictly
   fall within the category of AAA NAIs, they may nevertheless be
   accommodated within the subtype numbering space defined for the NAI
   Carrying Extension defined in this document.

この拡大のための内容と形式がAAA NAIsに特定でない、したがって、将来の新しいNAIsはコネであるなら定義されて、(AAA NAIsのカテゴリの中で厳密に低下しません)それにもかかわらず、彼らは本書では定義されたNAI Carrying Extensionのために定義された「副-タイプ」付番スペースの中に収容されるかもしれません。

   The NAI Carrying Extension should be assigned a type value from both
   the IANA number space for Mobile IPv4 skippable extensions and from
   the IANA number space for Mobile IPv4 advertisement extensions.
   Ideally, the numbers assigned from these two numbering spaces should
   have the same value.

タイプ値はモバイルIPv4 skippable拡張子のための両方のIANA数のスペースとモバイルIPv4広告拡張子のためのIANA数のスペースからNAI Carrying Extensionに割り当てられるべきです。 理想的に、これらの2つの付番空間から割り当てられた数は同じ値を持つべきです。

8.  Acknowledgements

8. 承認

   Thanks to the original authors of the GNAIE document, Mohamed M
   Khalil, Emad Qaddoura, Haseeb Akhtar, and Pat R. Calhoun.  The
   original document was removed from the MIP WG charter when no use was
   seen for the extension.  The original ideas have been reused in this
   document.  Also thanks to Henrik Levkowetz and Kevin Purser for
   valuable feedback and help when writing this document.

GNAIEドキュメントの原作者、モハメドMカリル、Emad Qaddoura、Haseeb Akhtar、およびパットR.をありがとうございます。カルフーン。 無駄が拡大に関して見られたとき、正本はMIP WG特許から取り外されました。 着想は本書では再利用されました。 また、有益なフィードバックのためにHenrik LevkowetzとケビンPurserをありがとうございます、このドキュメントを書くのを助けてください。

9.  Normative References

9. 引用規格

   [1]  Bradner, S., "Key words for use in RFCs to Indicate Requirement
        Levels", BCP 14, RFC 2119, March 1997.

[1] ブラドナー、S.、「Indicate Requirement LevelsへのRFCsにおける使用のためのキーワード」、BCP14、RFC2119、1997年3月。

   [2]  Aboba, B. and M. Beadles, "The Network Access Identifier", RFC
        2486, January 1999.

[2]AbobaとB.とM.用務員、「ネットワークアクセス識別子」、RFC2486、1999年1月。

   [3]  Narten, T. and H. Alvestrand, "Guidelines for Writing an IANA
        Considerations Section in RFCs", BCP 26, RFC 2434, October 1998.

[3]Narten、T.とH.Alvestrand、「RFCsにIANA問題部に書くためのガイドライン」BCP26、RFC2434(1998年10月)。

   [4]  Calhoun, P. and C. Perkins, "Mobile IP Network Access Identifier
        Extension for IPv4", RFC 2794, March 2000.

[4] カルフーンとP.とC.パーキンス、「IPv4"、RFC2794、2000年3月のためのモバイルIPネットワークアクセス識別子拡張子。」

   [5]  Perkins, C., "IP Mobility Support for IPv4", RFC 3344, August
        2002.

[5] パーキンス、C.、「IPv4"、RFC3344、2002年8月のIP移動性サポート。」

   [6]  Calhoun, P., Loughney, J., Guttman, E., Zorn, G. and J. Arkko,
        "Diameter Base Protocol", RFC 3588, September 2003.

[6] カルフーンとP.とLoughneyとJ.とGuttmanとE.とゾルンとG.とJ.Arkko、「直径基地のプロトコル」、RFC3588、2003年9月。

Jhansson & Johansson        Standards Track                     [Page 6]

RFC 3846              MIPv4 Extension for AAA NAIs             June 2004

JhanssonとヨハンソンStandardsは2004年6月にAAA NAIsのためにRFC3846MIPv4拡張子を追跡します[6ページ]。

10.  Authors' Addresses

10. 作者のアドレス

   Fredrik Johansson
   ipUnplugged AB
   Arenavagen 23
   Stockholm  S-121 28
   SWEDEN

フレドリックヨハンソンipUnplugged AB Arenavagen23ストックホルムS-121 28スウェーデン

   Phone: +46 8 725 5916
   EMail: fredrik@ipunplugged.com

以下に電話をしてください。 +46 8 725 5916はメールされます: fredrik@ipunplugged.com

   Tony Johansson
   Bytemobile Inc
   2029 Stierlin Court
   Mountain View, CA  94043
   USA

トニーヨハンソンBytemobile Inc2029ステアリン・法廷カリフォルニア94043マウンテンビュー(米国)

   Phone: +1 650 862 0523
   EMail: tony.johansson@bytemobile.com

以下に電話をしてください。 +1 0523年の650 862メール: tony.johansson@bytemobile.com

Jhansson & Johansson        Standards Track                     [Page 7]

RFC 3846              MIPv4 Extension for AAA NAIs             June 2004

JhanssonとヨハンソンStandardsは2004年6月にAAA NAIsのためにRFC3846MIPv4拡張子を追跡します[7ページ]。

11.  Full Copyright Statement

11. 完全な著作権宣言文

   Copyright (C) The Internet Society (2004).  This document is subject
   to the rights, licenses and restrictions contained in BCP 78, and
   except as set forth therein, the authors retain all their rights.

Copyright(C)インターネット協会(2004)。 このドキュメントはBCP78に含まれた権利、ライセンス、および制限を受けることがあります、そして、そこに詳しく説明されるのを除いて、作者は彼らのすべての権利を保有します。

   This document and the information contained herein are provided on an
   "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS
   OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET
   ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED,
   INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE
   INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED
   WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.

このドキュメントと「そのままで」という基礎と貢献者、その人が代表する組織で提供するか、または後援されて、インターネット協会とインターネット・エンジニアリング・タスク・フォースはすべての保証を放棄します、と急行ORが含意したということであり、他を含んでいて、ここに含まれて、情報の使用がここに侵害しないどんな保証も少しもまっすぐになるという情報か市場性か特定目的への適合性のどんな黙示的な保証。

Intellectual Property

知的所有権

   The IETF takes no position regarding the validity or scope of any
   Intellectual Property Rights or other rights that might be claimed to
   pertain to the implementation or use of the technology described in
   this document or the extent to which any license under such rights
   might or might not be available; nor does it represent that it has
   made any independent effort to identify any such rights.  Information
   on the procedures with respect to rights in RFC documents can be
   found in BCP 78 and BCP 79.

IETFはどんなIntellectual Property Rightsの正当性か範囲、実現に関係すると主張されるかもしれない他の権利、本書では説明された技術の使用またはそのような権利の下におけるどんなライセンスも利用可能であるかもしれない、または利用可能でないかもしれない範囲に関しても立場を全く取りません。 または、それはそれを表しません。どんなそのような権利も特定するためのどんな独立している努力もしました。 BCP78とBCP79でRFCドキュメントの権利に関する手順に関する情報を見つけることができます。

   Copies of IPR disclosures made to the IETF Secretariat and any
   assurances of licenses to be made available, or the result of an
   attempt made to obtain a general license or permission for the use of
   such proprietary rights by implementers or users of this
   specification can be obtained from the IETF on-line IPR repository at
   http://www.ietf.org/ipr.

IPR公開のコピーが利用可能に作られるべきライセンスの保証、または一般的な免許を取得するのが作られた試みの結果をIETF事務局といずれにもしたか、または http://www.ietf.org/ipr のIETFのオンラインIPR倉庫からこの仕様のimplementersかユーザによるそのような所有権の使用のために許可を得ることができます。

   The IETF invites any interested party to bring to its attention any
   copyrights, patents or patent applications, or other proprietary
   rights that may cover technology that may be required to implement
   this standard.  Please address the information to the IETF at ietf-
   ipr@ietf.org.

IETFはこの規格を実行するのに必要であるかもしれない技術をカバーするかもしれないどんな著作権もその注目していただくどんな利害関係者、特許、特許出願、または他の所有権も招待します。 ietf ipr@ietf.org のIETFに情報を記述してください。

Acknowledgement

承認

   Funding for the RFC Editor function is currently provided by the
   Internet Society.

RFC Editor機能のための基金は現在、インターネット協会によって提供されます。

Jhansson & Johansson        Standards Track                     [Page 8]

Jhanssonとヨハンソン標準化過程[8ページ]