̕RFC4135̓{iajłB ̖̕|e̐m͕ۏłȂ߁A mȒm߂͌QƂĂB |҂͂̕ɂēǎ҂蓾@Ȃ鑹Q̐ӔC܂B ̖|eɌ肪ꍇAł̌JA ̎wE͓K؂łB ̔̕zz͌̂qeblɖłB

Network Working Group                                           JH. Choi
Request for Comments: 4135                                   Samsung AIT
Category: Informational                                         G. Daley
CTIE Monash University
August 2005

Goals of Detecting Network Attachment in IPv6
hoUlbg[NڑoڕW

Status of This Memo
̏̕

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.
̃̓C^[lbĝɏ񋟂܂B̓C^[lb
gWw肵܂B̃̔zz͖łB

쌠\

Copyright (C) The Internet Society (2005).

Abstract
v

When a host establishes a new link-layer connection, it may or may
not have a valid IP configuration for Internet connectivity.  The
host may check for link change (i.e., determine whether a link change
has occurred), and then, based on the result, it can automatically
decide whether its IP configuration is still valid.  During link
identity detection, the host may also collect necessary information
to initiate a new IP configuration if the IP subnet has changed.  In
this memo, this procedure is called Detecting Network Attachment
(DNA).  DNA schemes should be precise, sufficiently fast, secure, and
of limited signaling.
zXgVNCڑmƂAC^[lbgڑ
߂ɐȂhoݒ܂A邢͂Ȃ܂
BzXg̓NύX𒲂ׂ邩܂iȂ킿ANύX
Nǂ肷邩܂jAČʂɊÂĎI
ɂhoݒ肪܂Lǂ߂邱Ƃł܂BNʎqo
ԂɁAhoTulbgωꍇAzXg͐Vhoݒn
邽߂ɕKvȏW߂邩܂B̃ŁA̎菇̓lb
g[NڑoicmjƌĂ΂܂Bcm̌n͐mŁA\ɍ
ŁASŁAM肳ĂׂłB

ڎ

1. Introduction
1. ͂߂
2. Problems in Detecting Network Attachment
2. lbg[Nڑo̖
2.1. Wireless Link Properties
2.1. N̓
2.2. Link Identity Detection with a Single RA
2.2. Pqł̃Nʎq
2.3. Delays
2.3. x
3. Goals for Detecting Network Attachment
3. lbg[Nڑo̖ڕW
3.1. Goals List
3.1. ڕWXg
4. Security Considerations
4. ZLeB̍l@
5. Acknowledgements
5. ӎ
6. References
6. Ql
6.1. Normative References
6.1. QƂQl

6.2. Informative References
6.2. LvȎQl
҂̃AhX
쌠\S

1.  Introduction
1.  ͂߂

When a host has established a new link-layer connection, it can send
and receive some IPv6 packets on the link, including those used for
configuration.  On the other hand, the host has Internet connectivity
only when it is able to exchange packets with off-link destinations.
zXgVNCڑmƂAݒɎgpPbg
܂߁ANłhoUpPbg̑Mł܂BApPb
gNÖƌ\łƂAzXg̓C^[lbg
܂B

When a link-layer connection is established or re-established, the
host may not know whether its existing IP configuration is still
valid for Internet connectivity.  A subnet change might have occurred
when the host changed its point of attachment.
NCڑm邩A邢͍ĊmƂAzXg͊
̂hoݒ肪C^[lbgڑ̂߂ɂ܂Lł邩ǂm
Ȃ܂BzXgڑ_ςƂATulbg̕ύXN
܂B

In practice, the host doesn't know which of its addresses are valid
on the newly attached link.  It also doesn't know whether its
existing default router is on this link or whether its neighbor cache
entries are valid.  Correct configuration of each of these components
is necessary in order to send packets on and off the link.
ۂ́AzXg͐Vɐڑ郊NŁÃAhXLł邩
ǂm܂B̃ftHg[^Nɂ邩ǂ
A邢͂̋ߗ׃LbVڂLǂm܂B
\vf̂ꂼ̐ݒ̓pPbgNOɑ邽߂ɕKv
łB

To examine the status of the existing configuration, a host may check
whether a 'link change' has occurred.  In this document, the term
'link' is as defined in RFC 2461 [1].  The notion 'link' is not
identical with the notion 'subnet', as defined in RFC 3753 [2].  For
example, there may be more than one subnet on a link, and a host
connected to a link may be part of one or more of the subnets on the
̐ݒ̏󋵂𒲂ׂ邽߂ɁAzXguNύXvN
ׂ邩܂B̕ŁApuNv͂qebQSUP
[1]ŒʂłBqebRVTR[2]Łm悤ɁAu
Nv̊TÓuTulbgv̊TOƂ܂ł͂܂BႦ΁A
Nɕ̃Tulbg邩ꂸANɐڑzXg
Ñ̕Tulbg̈ꕔł邩܂B

Today, a link change necessitates an IP configuration change.
Whenever a host detects that it has remained at the same link, it can
usually assume its IP configuration is still valid.  Otherwise, the
existing one is no longer valid, and a new configuration must be
acquired.  Therefore, to examine the validity of an IP configuration,
all that is required is that the host checks for link change.
ANύX͂hoݒύXKvƂ܂BzXg͓NɎc
ĂƊƂ́AʏÂhoݒ肪܂LłƑz
邱Ƃł܂BȂ΁A̐ݒ͖ŁAVݒ肪l
ȂĂ͂Ȃ܂B]āAhoݒ̗L𒲂ׂ邽߂ɕKv
Ȃ̂́AzXgNύX𒲂ׂ邱ƂłB

In the process of checking for link change, a host may collect some
of the necessary information for a new IP configuration, such as on-
link prefixes.  So, when an IP subnet change has occurred, the host
can immediately initiate the process of getting a new IP
configuration.  This may reduce handoff delay and minimize signaling.
NύX𒲂ׂߒŁANvtBbNX̗lȁAzXgV
hoݒ̂߂̕KvȂW߂邩܂BŁAhoT
ulbgύXNƂAzXg͂ɐVhoݒ𓾂鏈
n߂邱Ƃł܂B̓nhIt̒x炵AMŏɂ
邩܂B

Rapid attachment detection is required for a device that changes
subnet while having on-going sessions.  This may be the case if a
host is connected intermittently, is a mobile node, or has urgent
data to transmit upon attachment to a link.
is̃ZbVێ܂܃TulbgύXɂ́Aڑ
o鑕uKvƂ܂BzXgfIɐڑ邩Aړ
m[hł邩ANɐڑđׂً}f[^ĂȂA
͐^ł邩܂B

Detecting Network Attachment (DNA) is the process by which a host
collects the appropriate information and detects the identity of its
currently attached link to ascertain the validity of its IP
configuration.
lbg[Nڑoicmj͂̂hoݒ̗Lm߂邽߁A
zXgK؂ȏW߁AݐڑĂ郊N̐̂oߒ
łB

DNA schemes are typically run per interface.  When a host has
multiple interfaces, the host separately checks for link changes on
each interface.
cm͈ʂɃC^tF[XɍsȂ܂BzXg̃C^
tF[XƂAzXg͂ꂼ̃C^tF[XŌʂɃN
ύX𒲂ׂ܂B

It is important to note that DNA process does not include the actual
IP configuration procedure.  For example, with respect to DHCP, the
DNA process may determine that the host needs to get some
configuration information from a DHCP server.  However, the process
of actually retrieving the information from a DHCP server falls
beyond the scope of DNA.
cmߒۂ̂hoݒ菇܂܂ȂƂwE邱Ƃ͏dvłB
Ⴆ΁AcgboɊւāAcmߒ̓zXgcgboT[o኱
̐ݒɓKvƌ肷邩܂BȂ
AcgboT[oۂɏߒ͂cm͈̔͂z
܂B

This document considers the DNA procedure only from the IPv6 point of
view, unless explicitly mentioned otherwise.  Thus, the term "IP" is
to be understood to denote IPv6, by default.  For the IPv4 case,
refer to [7].
IȂA͂̕hoǓn݂̂cm菇
l@܂BŁApuhov́AftHgŁAhoUӖ
Ɨ͂łBhoS̏ꍇɂĂ͂̂߂[7]QƂĂ
B

2.  Problems in Detecting Network Attachment
2.  lbg[Nڑo̖

A number of issues make DNA complicated.  First, wireless
connectivity is not as clear-cut as wired connectivity.  Second, it's
difficult for a single Router Advertisement (RA) message to indicate
a link change.  Third, the current Router Discovery specification
specifies that routers wait a random delay of 0-.5 seconds prior to
responding with a solicited RA.  This delay can be significant and
may result in service disruption.
̖肪cm𕡎Gɂ܂BŏɁAڑ͗Lڑقǖ
ł͂܂BɁAP̃[^LiqjbZ[WŃ
NύXƂ͓łBOɁÃ݂[^TdĺAv
ꂽqԂOɃ[^ODTb̃_xw肵܂B
x͏dvł蓾āAT[rXf炷܂B

2.1.  Wireless Link Properties
2.1.  N̓

Unlike in wired environments, what constitutes a wireless link is
variable both in time and space.  Wireless links do not have clear
boundaries.  This may be illustrated by the fact that a host may be
within the coverage area of multiple (802.11) access points at the
same time.  Moreover, connectivity on a wireless link can be very
volatile, which may make link identity detection hard.  For example,
it takes time for a host to check for link change.  If the host
ping-pongs between two links and doesn't stay long enough at a given
link, it can't complete the DNA procedure.
LƈقȂAN\͎̂ԂƋԂŕω܂B
NmȋE܂B̓zXgɕ
iWOQ.PPjANZX|Cg̃GAɂƂŎ邩
܂BɁAN̐ڑ͔ɕsŁAĂ
̓Nʎqo邩܂BႦ΁AzXg̓N
ω𒲂ׂ̂ɎԂ܂BzXgQ̃NԂs
藈肵āA\Ԏԓ̃Nɑ؍݂ȂȂAcm菇
邱Ƃł܂B

2.2.  Link Identity Detection with a Single RA
2.2.  Pqł̃Nʎq

Usually, a host gets the information necessary for IP configuration
from RA messages.  Based on the current definition [1], it's
difficult for a host to check for link change upon receipt of a
single RA.
ʏAzXg͂qbZ[WhoݒɕKvȏɓ܂B
݂̒[1]ɊÂƁAzXgP̂q̎MŃN̕ω
ׂ邱Ƃ͓łB

To detect link identity, a host may compare the information in an RA,
such as router address or prefixes, with the locally stored
information.
Nʎqo邽߂ɁAzXgA[^AhX邢̓v
tBbNX̂悤ȁAq̏[JɕۑꂽƔr邩
܂B

The host may use received router addresses to check for link change.
The router address in the source address field of an RA is of link-
local scope, however, so its uniqueness is not guaranteed outside a
link.  If it happens that two different router interfaces on
different links have the same link-local address, the host can't
detect that it has moved from one link to another by checking the
router address in RA messages.
zXg͎M[^AhXNύX𒲂ׂ邽߂Ɏg
܂BȂAq̃\[XAhXtB[h̃[^AhX
̓N[J͈̔͂̂ŁÄӂ̓NOŕۏ؂Ă܂B
قȂ郊N̂Q̈قȂ郋[^C^tF[XN[
JAhX܂܋NȂAzXg͂qbZ[W̃[
^AhX邱ƂŃNړ邱Ƃł܂
B

The set of all global prefixes assigned to a link can represent link
identity.  The host may compare the prefixes in an incoming RA with
the currently stored ones.  An unsolicited RA message, however, can
omit some prefixes for convenience [1], and it's not easy for a host
to attain and retain all the prefixes on a link with certainty.
Therefore, neither the absence of a previously known prefix nor the
presence of a previously unknown prefix in the RA guarantees that a
link change has occurred.
NɊ蓖ĂꂽׂẴO[ovtBbNX̏WŃN
ʂ鎖ł܂BzXg͂q肵vtBbNX
ۊǂĂ̂Ɣr邩܂BA]܂ĂȂq
bZ[W͕֗̂߂ɂvtBbNXȗ邱Ƃł܂
[1]AăzXgmɃNׂ̂ẴvtBbNXlĈ
邱Ƃ͗eՂł͂܂B̂߂ɁAqł̊mvtBbN
X̌@AmvtBbNX݂̑́ANύX̕ۏɂȂ܂.

2.3.  Delays
2.3.  x

The following issues cause DNA delay that may result in communication
disruption.
̖͂cmxAʐMf炷܂B

1) Delay for receiving a hint
1) AqgM̒x

A hint is an indication that a link change might have occurred.  This
hint itself doesn't confirm a link change, but initiates appropriate
DNA procedures to detect the identity of the currently attached link.
qg̓N̕ωNȂƂ\łB̃qg
g̓NύXmF܂AݐڑĂ郊N̐
o邽߂ɓK؂Ȃcm菇n܂܂B

Hints come in various forms and differ in how they indicate a
[6], the lack of RA from the default router, or the receipt of a new
RA.  The time taken to receive a hint also varies.
qgX̌ŋNāANύX̉\@قȂ܂B
̓NCCxgʒm[6]AftHg[^̂qA
͐Vq̎M̌@łBqg󂯎鎞Ԃω܂B

As soon as a new link-layer connection has been made, the link layer
may send a link-up notification to the IP layer.  A host may
interpret the new link-layer connection as a hint for a possible link
change.  With link-layer support, a host can receive such a hint
almost instantly.
VNCڑƂɁANC͘Aʒmho
Cɑ邩܂BzXgNύX̉\ƂĐV
NCڑqgƉ߂邩܂BNCT|[g
ŁAzXgقƂǒɂ̂悤ȃqg󂯎邱Ƃł܂B

Mobile IPv6 [4] defines the use of RA Interval Timer expiry for a
hint.  A host keeps monitoring for periodic RAs and interprets the
lack of them as a hint.  It may implement its own policy to determine
the number of missing RAs needed to interpret that as a hint.  Thus,
the delay depends on the Router Advertisement interval.
oChoU[4]qĝ߂ɂqԊu^C}̃^CAEg̎gp
𖾊mɂ܂BzXgIȂq̃j^OێāǍ
@qgƉ߂܂B̂q̌@qgƉ߂邩̃|V
邩܂BŁAx̓[^LԊuɈˑ܂B

Without schemes such as those above, a host must receive a new RA
from a new router to detect a possible link change.  The detection
time then also depends on the Router Advertisement frequency.
L̂悤ȑ̌nȂ΁AzXgNύX̉\o邽
ɁAV[^VqMȂ΂Ȃ܂BԂ
[^LɈˑ܂B

Periodic RA beaconing transmits packets within an interval varying
Because a network attachment is unrelated to the advertisement time
on the new link, hosts are expected to arrive, on average, halfway
through the interval.  This is approximately 1.75 seconds with
̃_ȊԊuő܂Blbg[Nڑ͐VN̍L
ԂƖ֌WȂ̂ŁAzXgςŔ̊ԊuŎM鎖҂
BߗגT[1]L[gA͂悻P.VTbłB

2) Random delay execution for RS/RA exchange
2) q/q̎s̃_x

Router Solicitation and Router Advertisement messages are used for
Router Discovery.  According to [1], it is sometimes necessary for a
host to wait a random amount of time before it may send an RS, and
for a router to wait before it may reply with an RA.
[^vƃ[^LbZ[W̓[^T̂߂Ɏg܂B[1]
΁AzXgqr𑗂OɁAă[^qԂOɁA_
ԑ҂Ƃ͎XKvłB

According to RFC 2461 [1], the following apply:
qebQSUP[1]ɂ΁AKp܂F

-  Before a host sends an initial solicitation, it SHOULD delay the
transmission for a random amount of time between 0 and
MAX_RTR_SOLICITATION_DELAY (1 second).
-  zXgŏ̗v𑗂OɁAOMAX_RTR_SOLICITATION_DELAY
iPbj̊Ԃ̃_ԁAMx点ׂłB

-  Furthermore, any RA sent in response to a Router Solicitation MUST
be delayed by a random time between 0 and MAX_RA_DELAY_TIME (0.5
seconds).
-  ɁA[^vɉđq͂OMAX_RA_DELAY_TIME
iO.Tbj̊Ԃ̃_ԁAx点ȂĂ͂Ȃ܂B

3.  Goals for Detecting Network Attachment
3.  lbg[Nڑo̖ڕW

The DNA working group has been chartered to define an improved scheme
for detecting IPv6 network attachment.  In this section, we define
the goals that any such solution should aim to fulfill.
cmƕ́AhoUlbg[Nڑoɑ΂āAPꂽ
𖾊mɂ錠^܂B̏͂ŁAX͂̂悤ȉ
􂪖ׂڕW܂B

DNA solutions should correctly determine whether a link change has
occurred.  Additionally, they should be sufficiently fast so that
there would be no or at most minimal service disruption.  They should
neither flood the link with related signaling nor introduce new
security holes.
cm􂪐mɃN̕ωNǂ肷ׂłB
ɁAT[rXfȂŏł悤ɁA͏\ɍł
ׂłB̓N֘AMňꂳAVZL
eB[z[𓱓ׂł͂܂B

When defining new solutions, it is necessary to investigate the usage
messages, RS/RA messages, link-layer event notifications [6], and
other features.  This will allow precise description of procedures
for efficient DNA Schemes.
VƂAp\ȎiAߗחv/ߗ׍LbZ[
WAqr/qbZ[WANCCxgʒm[6]Ƒ̎gp@̓
𒲍邱Ƃ͕KvłB͌IȂcm̌n̎菇̐mȋL
qł傤B

3.1.  Goals List
3.1.  ڕWXg

G1  DNA schemes should detect the identity of the currently attached
link to ascertain the validity of the existing IP configuration.
They should recognize and determine whether a link change has
occurred and initiate the process of acquiring a new
configuration if necessary.
G1  cm̌n̂hoݒ̗LmF邽߂Ɍݐڑ
郊N̐̂oׂłB̓N̕ωN
ǂFA肵AKvłȂAVݒl
鏈n߂ׂłB

G2  DNA schemes should detect the identity of an attached link with
minimal latency lest there should be service disruption.
G2  T[rXfȂ悤ɁA cm̌nŏ̔ԂŐڑN
̐̂oׂłB

G3  If a host has not changed a link, DNA schemes should not falsely
assume a link change, and an IP configuration change should not
occur.
G3  zXgNςȂȂAcm̌nԈăN
Xz肵AhoݒύXNׂł͂܂B

G4  DNA schemes should not cause undue signaling on a link.
G4  cm̌nN̏ŉߓx̐MNׂł͂܂B

G5  DNA schemes should make use of existing signaling mechanisms
where available.
G5  p\łꍇ́A cm̌n̐MJjY𗘗p
ׂłB

G6  DNA schemes should make use of signaling within the link
(particularly link-local scope messages), because communication
off-link may not be achievable in the case of a link change.
G6  cm̌nNŐM𑗂邱Ƃ𗘗pׂłiɃ
N[J͈̓bZ[WjAȂȂ烊NOʐM̓NύXɊ
Ă͒B\łȂȂłB

G7  DNA schemes should be compatible with security schemes such as
Secure Neighbor Discovery [3].
G7  cm̌n͈SȋߗגT[3]̂悤ȃZLeB̌nƌ݊
ׂłB

G8  DNA schemes should not introduce new security vulnerabilities.
The node supporting DNA schemes should not expose itself or other
nodes on a link to additional man-in-the-middle, identity-
revealing, or denial-of-service attacks.
G8  cm̌nVZLeB̎_𓱓ׂł͂܂B
cm̌nT|[gĂm[h́Ag⃊N̑m[
hAԎҍUT[rXWQUɁAV̂炷ׂł͂
B

G9  Nodes (such as routers or hosts) that support DNA schemes should
work appropriately with unmodified nodes that do not.
G9 cm̌nT|[gm[hi[^zXgȂǁjΉm[h
ƓK؂ɍ쓮ׂłB

G10 Hosts, especially in wireless environments, may perceive routers
reachable on different links.  DNA schemes should take into
consideration the case where a host is attached to more than one
link at the same time.
G10 zXǵAɖ̊ŁAقȂ郊N̓B\ȃ[^F
m邩܂Bcm̌nzXgɕ̃Nɐ
ꍇlɓׂłB

4.  Security Considerations
4.  ZLeB̍l@

The DNA process is intimately related to the Neighbor Discovery
protocol [1] and its trust model and threats have much in common with
those presented in RFC 3756 [5].  Nodes connected over wireless
interfaces may be particularly susceptible to jamming, monitoring,
and packet-insertion attacks.
cm͐eɋߗגTvgR[1]Ɗ֌W܂AĂ̐M
fƋЂ͋ʂŁAqebłRVTU[5]ŌJ܂BC
^tF[XŐڑꂽm[h́AɖWQƃj^OƃpPbg}
Uɉe₷܂B

With unsecured DNA schemes, it is inadvisable for a host to adjust
its security based on which network it believes it is attached to.
For example, it would be inappropriate for a host to disable its
personal firewall because it believed that it had connected to a home
network.
SłȂcm̌nŁAzXgǂ̃lbg[NɐڑƐM邩
ɊÂZLeB͊߂܂BႦ΁AzXgz[lb
g[NɐڑĂƂƐMAzXgp[\it@CAEH[
~邱Ƃ͕sKłł傤B

Even in the case where authoritative information (routing and prefix
state) are advertised, wireless network attackers may still prevent
soliciting nodes from receiving packets.  This may cause unnecessary
IP configuration change in some devices.  Such attacks may be used to
make a host preferentially select a particular configuration or
network access.
ȏi[eBOƃvtBbNXԁjLꍇłA
lbg[NU҂vm[h̃pPbgMj~邩
B͂鑕uŕsKvȂhoݒ̕ωN܂B
̂悤ȍÚAzXgɓ̐ݒANZXlbg[NI
邽߂Ɏg邩܂B

Devices receiving confirmations of reachability (for example, from
upper-layer protocols) should be aware that unless these indications
are sufficiently authenticated, reachability may falsely be asserted
by an attacker.  Similarly, even if such reachability tests are known
to originate from a trusted source, they should be ignored for
reachability confirmation if the packets are not fresh or have been
replayed.  This may reduce the effective window for attackers
replaying otherwise authentic data.
iႦ΁AʃCvgRjB̊mF󂯂Ă鑕u
̕\\ɔF؂ȂȂABUčU҂ɂ
咣邩ȂƂmĂׂłBlɁAƂ̂
ȓB\eXgMł񋟎҂ɗR邱ƂmĂ
ApPbgŐVłȂA邢͍ĐꂽȂA͓B
\mFŖׂł͐f[^̍Đɑ΂āAU
̍U炷܂B

It may be dangerous to receive link-change notifications from the
link layer and network layer, if they are received from devices that
are insufficiently authenticated.  In particular, notifications that
authentication has completed at the link layer may not imply that a
security relationship is available at the network layer.  Additional
authentication may be required at the network layer to justify
modification of IP configuration.
s\ɔF؂鑕u̎Mł΁ANwƃlbg[N
w烊NύXʒm󂯎邱Ƃ͊댯ł邩܂BɁA
NwŔF؂ʒmAlbg[Nw̃ZLeB֌W
p\ł邱ƂӖȂ܂Bǉ̔F؂lbg[N
włhoݒ̏C𐳓邽߂ɕKv܂B

5.  Acknowledgements
5.  ӎ

Erik Nordmark has contributed significantly to work predating this
document.  Also Ed Remmell's comments on the inconsistency of RA
information were most illuminating.  The authors wish to express our
appreciation to Pekka Nikander for valuable feedback.  We gratefully
acknowledge the generous assistance we received from Shubhranshu
Singh for clarifying the structure of the arguments.  Thanks to Brett
Pentland, Nick Moore, Youn-Hee Han, JaeHoon Kim, Alper Yegin, Jim
Bound, and Jari Arkko for their contributions to this document.
Erik Nordmark͂̕ɐsɍۗčv܂B
q̕sɂEd Remmell̃Rg͍ł𖾓IłB
͋MdȃtB[hobN̂߂Pekka NikanderɊӂ܂Bc_̍\
𖾊mɂ邱Ƃɑ΂ĉXShubhranshu Singh󂯎ȉ
Ɋӂ܂B̕ւ̍vɂāABrett PentlandNick Moore
Youn-Hee HanJaeHoon KimAlper YeginJim BoundJari ArkkoɊ
܂B

6.  References
6.  Ql

6.1.  Normative References
6.1.  QƂQl

[1]  Narten, T., Nordmark, E., and W. Simpson, "Neighbor Discovery
for IP Version 6 (IPv6)", RFC 2461, December 1998.

[2]  Manner, J. and M. Kojo, "Mobility Related Terminology", RFC
3753, June 2004.

[3]  Arkko, J., Kempf, J., Zill, B., and P. Nikander, "SEcure
Neighbor Discovery (SEND)", RFC 3971, March 2005.

6.2.  Informative References
6.2.  LvȎQl

[4]  Johnson, D., Perkins, C., and J. Arkko, "Mobility Support in
IPv6", RFC 3775, June 2004.

[5]  Nikander, P., Kempf, J., and E. Nordmark, "IPv6 Neighbor
Discovery (ND) Trust Models and Threats", RFC 3756, May 2004.

[6]  Yegin, A., "Link-layer Event Notifications for Detecting Network
Attachments", work in progress, July 2005.

[7]  Aboba, B., "Detecting Network Attachment (DNA) in IPv4", work in
progress, June 2005.

҂̃AhX

JinHyeock Choi
Samsung AIT
Communication & N/W Lab
P.O.Box 111 Suwon 440-600
KOREA

Phone: +82 31 280 9233
EMail: jinchoe@samsung.com

Greg Daley
CTIE Monash University
Centre for Telecommunications and Information Engineering
Monash University
Clayton 3800 Victoria
Australia

Phone: +61 3 9905 4655
EMail: greg.daley@eng.monash.edu.au

쌠\S

Copyright (C) The Internet Society (2005).
쌠ibjC^[lbgwiQOOTjB

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.
͂̕aboVWɊ܂܂錠ƋƐ̓Kp󂯁A
̒ɖ炩ɂȊO͒҂ׂĂ̌ێ܂B

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.
̕ƂɊ܂܂͂邪܂܂ɋ܂Av҂ƍv
҂\邩v҂㉇gDi΁jƃC^[lbgw
ƃC^[lbgZpW^XNtH[X́AmɂÖقɂȀ
̎gp̐NQȂƂ⏤Ɨpʂ̖ړIւ̗pɓK
鎖̕ۏ܂߁ASĂ̕ۏ؂ۂ܂B

Intellectual Property
mIL

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.
̕ɋLqꂽZpɊւĎ咣mIY⑼̌
͈͂ɂāA̗lȌ̌ŃCZXp\ps
\͈̔͂ɂāAhdse͉̗Ƃ܂G̗lȌ
FƗ̒Ƃ͏qׂ܂Bqeb̌Ɋւ葱
̏͂aboVWƂaboVXĂB

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.
̎҂◘p҂ɂĂꂽʓIȋ⋖𓾂邽߂ɂꂽ
݂̌ʂ́Ahttp://www.ietf.org/iprɂhdseIChoq
ɂœ܂B

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.
hdse͋Nł̕WŝɕKvȋZpJ
o[钘쌠o⑼̏L̒ӂĂ悤ɋ
߂܂Bǂietf-ipr@ietf.orĝhdseɏ`ĂB

Acknowledgement
ӎ

Funding for the RFC Editor function is currently provided by the
Internet Society.
qebGfB^@\̂߂̎݃C^[lbgwɂ
܂B

[]Japanese translation by Ishida So