draft-ietf-dna-frd-01.txt   draft-ietf-dna-frd-02.txt 
DNA WG JH. Choi DNA WG JH. Choi
Internet-Draft Samsung AIT Internet-Draft Samsung AIT
Expires: December 23, 2006 DongYun. Shin Intended status: Informational DongYun. Shin
Samsung Electronics Expires: March 3, 2007 Samsung Electronics
W. Haddad W. Haddad
Ericsson Research Ericsson Research
June 21, 2006 August 30, 2006
Fast Router Discovery with L2 support Fast Router Discovery with L2 support
draft-ietf-dna-frd-01.txt draft-ietf-dna-frd-02.txt
Status of this Memo Status of this Memo
By submitting this Internet-Draft, each author represents that any By submitting this Internet-Draft, each author represents that any
applicable patent or other IPR claims of which he or she is aware applicable patent or other IPR claims of which he or she is aware
have been or will be disclosed, and any of which he or she becomes have been or will be disclosed, and any of which he or she becomes
aware will be disclosed, in accordance with Section 6 of BCP 79. aware will be disclosed, in accordance with Section 6 of BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
skipping to change at page 1, line 37 skipping to change at page 1, line 37
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 23, 2006. This Internet-Draft will expire on March 3, 2007.
Copyright Notice Copyright Notice
Copyright (C) The Internet Society (2006). Copyright (C) The Internet Society (2006).
Abstract Abstract
For efficient Detecting Network Attachment (DNA), a host should For efficient Detecting Network Attachment (DNA), a host should
quickly receive a Router Advertisement (RA) message upon a new link- quickly receive a Router Advertisement (RA) message upon a new link-
layer connection. This draft presents a quick RA acquisition scheme layer connection. This draft presents a quick RA acquisition scheme
skipping to change at page 4, line 23 skipping to change at page 4, line 23
Triggering" and another one for a PoA to proxy an RA, "RA Proxying". Triggering" and another one for a PoA to proxy an RA, "RA Proxying".
In RA Proxying, we present a way to cache a suitable RA and send the In RA Proxying, we present a way to cache a suitable RA and send the
RA in unicast without any delay. RA in unicast without any delay.
IEEE 802.21 (Media Independent Handover) standard develops a IEEE 802.21 (Media Independent Handover) standard develops a
specification [13] that provides link layer intelligence and other specification [13] that provides link layer intelligence and other
related network information to upper layers to optimize handovers related network information to upper layers to optimize handovers
between heterogeneous media. between heterogeneous media.
Utilizing the services defined in 802.21 Media Independent Handover Utilizing the services defined in 802.21 Media Independent Handover
(MIH) standard, we can put 'RA Triggering' or 'RA Proxying' (MIH) standard, we may put 'RA Triggering' or 'RA Proxying'
functionality on a PoA to get the optimized result for quick RA functionality on a PoA to achieve quick RA acquisition without IPv6
acquisition without IPv6 standard change. standard change.
2. Terminology 2. Terminology
Access Router (AR) Access Router (AR)
- An Access Network Router residing on the edge of an Access - An Access Network Router residing on the edge of an Access
Network and offers IP connectivity to hosts. Network and offers IP connectivity to hosts.
Point of Attachment (PoA) Point of Attachment (PoA)
skipping to change at page 9, line 26 skipping to change at page 9, line 26
In the simplest way, an administrator can manually configure in PoA a In the simplest way, an administrator can manually configure in PoA a
suitable RA, such as an RA with the LinkID prefix or a CompleteRA suitable RA, such as an RA with the LinkID prefix or a CompleteRA
defined in [4]. In many cases, AR and PoA are under the same defined in [4]. In many cases, AR and PoA are under the same
administration and usually Router Advertisement (RA) message doesn't administration and usually Router Advertisement (RA) message doesn't
change so often. change so often.
5.1.2. Scanning 5.1.2. Scanning
A PoA may scan incoming L2 frames for a suitable RA and store it. A PoA may scan incoming L2 frames for a suitable RA and store it.
First it scans L2 frame header to see whether it is a multicast First it scans the L2 frame header to see whether it is a multicast
frame. If not, the PoA sends that frame down link and scans the next frame. If not, the PoA sends that frame down link and scans the next
L2 frame. If so, the PoA looks IP header to check whether it L2 frame. If so, the PoA looks IP header to check whether it
contains a suitable RA. If an incoming L2 frame doesn't contain a contains a suitable RA. If an incoming L2 frame doesn't contain a
suitable RA, the PoA sends that frame down link and scans a next L2 suitable RA, the PoA sends that frame down link and scans a next L2
frame. When the PoA finds a suitable RA, it stores it and sends a frame. When the PoA finds a suitable RA, it stores it and sends a
copy down link. copy down link.
A PoA can scan continuously, updating an old RA with a new RA. A PoA can scan continuously, updating an old RA with a new RA.
Alternatively, if it costs too much for the PoA to scan every Alternatively, if it costs too much for the PoA to scan every
incoming L2 frame, we can control the scanning rate. For example, we incoming L2 frame, we can control the scanning rate. For example, we
skipping to change at page 10, line 38 skipping to change at page 10, line 38
5.2.1. 802.11 5.2.1. 802.11
In 802.11 Wireless LAN technology, when a new host arrives at an In 802.11 Wireless LAN technology, when a new host arrives at an
AP(Access Point), it should associate with the AP. The host sends an AP(Access Point), it should associate with the AP. The host sends an
Association Request Message with its MAC address. Then the AP sends Association Request Message with its MAC address. Then the AP sends
an Association Response Message to grant association. an Association Response Message to grant association.
As soon as association is made, the AP sends a cached RA to the host As soon as association is made, the AP sends a cached RA to the host
in an unicast 802.11 frame with the MAC address from the Association in an unicast 802.11 frame with the MAC address from the Association
Request message. The host receives the unicast RA just after Request message. (In case of 802.11i RSN, the RA is sent after
association is made, which is the earliest possible time in current authentication procedures are completed.) The host receives the
standard. unicast RA just after association (or authentication) is made, which
is the earliest possible time in current standard.
5.2.2. 802.16 5.2.2. 802.16
IEEE 802.16 spec [11], [12] is rather different from Ethernet or IEEE 802.16 spec [11], [12] is rather different from Ethernet or
802.11 and work is still on-going about how to run IPv6 over 802.16. 802.11 and work is still on-going about how to run IPv6 over 802.16.
So we give a rough sketch of RA delivery over 802.16 and mention that So we give a rough sketch of RA delivery over 802.16 and mention that
further work is needed. further work is needed.
The 802.16 MAC is connection-oriented. All services, including The 802.16 MAC is connection-oriented. All services, including
inherently connectionless services, are mapped to a connection. inherently connectionless services, are mapped to a connection.
skipping to change at page 13, line 16 skipping to change at page 13, line 16
Because DNA is based on Neighbor Discovery, its trust models and Because DNA is based on Neighbor Discovery, its trust models and
threats are similar to the ones presented in RFC 3756 [9]. Nodes threats are similar to the ones presented in RFC 3756 [9]. Nodes
connected over wireless interfaces may be particularly susceptible to connected over wireless interfaces may be particularly susceptible to
jamming, monitoring and packet insertion attacks. jamming, monitoring and packet insertion attacks.
Note that a DNA scheme should not result in excessive signaling. An Note that a DNA scheme should not result in excessive signaling. An
attacker can make a bogus association with an PoA to trigger an attacker can make a bogus association with an PoA to trigger an
additional RA. This may result in amplification attack and consumes additional RA. This may result in amplification attack and consumes
wireless bandwidth. However a PoA performs FRD procedure to generate wireless bandwidth. However a PoA performs FRD procedure to generate
an RA message only when a new host is attached to itself. Usually an RA message only when a new host is attached to it. Usually there
there is an upper bound for the number of hosts (wireless stations) is an upper bound for the number of hosts (wireless stations) that a
that a PoA can support at a moment. So the number of RA messages PoA can support at a moment. So the number of RA messages from FRD
from FRD procedure is also limited by this upper bound. procedure is also limited by this upper bound.
The threats specific to DNA are that an attacker might fool a node to The threats specific to DNA are that an attacker might fool a node to
detect attachment to a different link when it is in fact still detect attachment to a different link when it is in fact still
attached to the same link, and conversely, the attacker might fool a attached to the same link, and conversely, the attacker might fool a
node to not detect attachment to a new link. node to not detect attachment to a new link.
In case PoA and AR are in the same box, FRD doesn't bring forth any In case PoA and AR are in the same box, FRD doesn't bring forth any
additional DNA specific security problem, because all procedures are additional DNA specific security problem, because all procedures are
executed within a local stack. In case PoA and AR are separated, FRD executed within a local stack. In case PoA and AR are separated, FRD
can be performed in secure manner only if there is a secure path can be performed in secure manner only if there is a secure path
skipping to change at page 13, line 43 skipping to change at page 13, line 43
The lack of secure path between the PoA and AR does not introduce any The lack of secure path between the PoA and AR does not introduce any
additional security attack when using FRD. Currently any node in a additional security attack when using FRD. Currently any node in a
link can cache an RA and retransmit it to mislead a host to false link can cache an RA and retransmit it to mislead a host to false
decision. But an attacker may poison a PoA's cache with a bogus RA decision. But an attacker may poison a PoA's cache with a bogus RA
to save itself from having to advertise the false information for to save itself from having to advertise the false information for
itself. Use of [8] to secure Neighbor Discovery are important in itself. Use of [8] to secure Neighbor Discovery are important in
achieving reliable detection of network attachment. DNA schemes achieving reliable detection of network attachment. DNA schemes
SHOULD incorporate the solutions developed in IETF SEND WG if SHOULD incorporate the solutions developed in IETF SEND WG if
available, where assessment indicates such procedures are required. available, where assessment indicates such procedures are required.
In the presence of SEND, RA Caching may raise security concerns, In the presence of SEND, RA Caching may raise security concerns.
since the PoA can be considered a man in the middle. Especially, it Especially, it may be difficult for RA Caching with Scanning (Sec
may be difficult for RA Caching with Scanning (Sec 5.1.2) to work 5.1.2) to work with SEND. If a router sends an RA with a SEND
with SEND. If a router sends an RA with a SEND Timestamp option, it Timestamp option, it puts upper bound on how long the RA remains
puts upper bound on how long the RA remains valid after the router valid after the router advertises it. So if a PoA caches the RA too
advertises it. So if a PoA caches the RA too long, it will become long, it will become invalid and a host will discard it. However
invalid and a host will discard it. However take notice that even in take notice that even in this case, the host will not make a false
this case, the host will not make a false DNA decision. DNA decision.
We may resolve this issue by including a unique 64 bit number called We may resolve this issue by including a unique 64 bit number called
an Ownership Proof (OP) in an RA. The 64 bit number, OP, is the hash an Ownership Proof (OP) in an RA. The 64 bit number, OP, is the hash
of a nonce and proves to a host that the RA was indeed generated by of a nonce and proves to a host that the RA was indeed generated by
the router which is listed as the source of the RA. The router must the router which is listed as the source of the RA. The router must
keep a table associating each OP to the nonce, which was used to keep a table associating each OP to the nonce, which was used to
generate it. When an RA carrying an OP option is received, a host generate it. When an RA carrying an OP option is received, a host
may ignore the SEND Timestamp option if it falls outside the may ignore the SEND Timestamp option if it falls outside the
allowable window. allowable window.
skipping to change at page 17, line 22 skipping to change at page 17, line 22
[2] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment [2] Choi, JH. and G. Daley, "Goals of Detecting Network Attachment
in IPv6", RFC 4135, August 2005. in IPv6", RFC 4135, August 2005.
9.2. Informative References 9.2. Informative References
[3] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix [3] Nordmark, E. and J. Choi, "DNA with unmodified routers: Prefix
list based approach", draft-ietf-dna-cpl-02 (work in progress), list based approach", draft-ietf-dna-cpl-02 (work in progress),
January 2006. January 2006.
[4] Kempf, J., "Detecting Network Attachment in IPv6 Networks [4] Kempf, J., "Detecting Network Attachment in IPv6 Networks
(DNAv6)", draft-ietf-dna-protocol-00 (work in progress), (DNAv6)", draft-ietf-dna-protocol-01 (work in progress),
February 2006. June 2006.
[5] Yegin, A., "Link-layer Event Notifications for Detecting [5] Yegin, A., "Link-layer Event Notifications for Detecting
Network Attachments", draft-ietf-dna-link-information-03 (work Network Attachments", draft-ietf-dna-link-information-03 (work
in progress), October 2005. in progress), October 2005.
[6] Daley, G., "Tentative Options for Link-Layer Addresses in IPv6 [6] Daley, G., "Tentative Options for Link-Layer Addresses in IPv6
Neighbour Discovery", draft-ietf-dna-tentative-00 (work in Neighbour Discovery", draft-ietf-dna-tentative-00 (work in
progress), February 2006. progress), February 2006.
[7] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network [7] Aboba, B., Carlson, J., and S. Cheshire, "Detecting Network
skipping to change at page 18, line 8 skipping to change at page 18, line 8
[11] IEEE Std 802.16-2004, "IEEE Standard for Local and [11] IEEE Std 802.16-2004, "IEEE Standard for Local and
metropolitan area networks, Part 16: Air Interface for metropolitan area networks, Part 16: Air Interface for
Fixed Broadband Wireless Access Systems", October 2004. Fixed Broadband Wireless Access Systems", October 2004.
[12] IEEE802.16e-2005, "IEEE Standard for Local and metropolitan [12] IEEE802.16e-2005, "IEEE Standard for Local and metropolitan
area networks, Amendment for Physical and Medium Access area networks, Amendment for Physical and Medium Access
Control Layers for Combined Fixed and Mobile Operation in Control Layers for Combined Fixed and Mobile Operation in
Licensed Bands", 2005. Licensed Bands", 2005.
[13] IEEE 802.21 Working Document (Draft Standard), [13] IEEE 802.21 Working Document (Draft Standard),
"IEEE P802.21/D01.00: Draft IEEE Standard for Local and "IEEE P802.21/D01: Draft IEEE Standard for Local and
Metropolitan Area Networks: Media Independent Handover Metropolitan Area Networks: Media Independent Handover
Services," July, 2005 Services," July, 2005
[14] WiMAX Forum Network Working Group (NWG), [14] WiMAX Forum Network Working Group (NWG),
http://www.wimaxforum.org http://www.wimaxforum.org
[15] Choi, J. and E. Nordmark, "DNA solution framework",
draft-ietf-dna-soln-frame-00 (work in progress), April 2005.
[16] Pentland, B., "An Overview of Approaches to Detecting Network
Attachment in IPv6", draft-dnadt-dna-discussion-00 (work in
progress), February 2005.
[17] Narayanan, S., "Detecting Network Attachment in IPv6 Networks
(DNAv6)", draft-pentland-dna-protocol-01 (work in progress),
July 2005.
[18] Madanapalli, S. and J. Choi, "DNA Solution: Link Identifier
based approach", draft-jinchoi-dna-protocol2-01 (work in
progress), July 2005.
[19] Nordmark, E., "MIPv6: from hindsight to foresight?",
draft-nordmark-mobileip-mipv6-hindsight-00 (work in progress),
November 2001.
[20] Daley, G. and J. Choi, "Movement Detection Optimization in
Mobile IPv6", draft-daley-mobileip-movedetect-01 (work in
progress), May 2003.
[21] Kempf, J., Khalil, M., and B. Pentland, "IPv6 Fast Router
Advertisement", draft-mkhalil-ipv6-fastra-05 (work in
progress), July 2004.
Authors' Addresses Authors' Addresses
JinHyeock Choi JinHyeock Choi
Samsung AIT Samsung AIT
Networking Technology Lab Networking Technology Lab
P.O.Box 111 Suwon 440-600 P.O.Box 111 Suwon 440-600
KOREA KOREA
Phone: +82 31 280 9233 Phone: +82 31 280 9233
Email: jinchoe@samsung.com Email: jinchoe@samsung.com
skipping to change at page 20, line 5 skipping to change at page 20, line 5
Email: yun7521@samsung.com Email: yun7521@samsung.com
Wassim Haddad Wassim Haddad
Ericsson Research Ericsson Research
Torshamnsgatan 23 Torshamnsgatan 23
SE-164 80 Stockholm SE-164 80 Stockholm
Sweden Sweden
Email: Wassim.Haddad@ericsson.com Email: Wassim.Haddad@ericsson.com
Intellectual Property Statement Full Copyright Statement
Copyright (C) The Internet Society (2006).
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.
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.
Intellectual Property
The IETF takes no position regarding the validity or scope of any The IETF takes no position regarding the validity or scope of any
Intellectual Property Rights or other rights that might be claimed to Intellectual Property Rights or other rights that might be claimed to
pertain to the implementation or use of the technology described in pertain to the implementation or use of the technology described in
this document or the extent to which any license under such rights 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 might or might not be available; nor does it represent that it has
made any independent effort to identify any such rights. Information made any independent effort to identify any such rights. Information
on the procedures with respect to rights in RFC documents can be on the procedures with respect to rights in RFC documents can be
found in BCP 78 and BCP 79. found in BCP 78 and BCP 79.
skipping to change at page 20, line 29 skipping to change at page 20, line 45
such proprietary rights by implementers or users of this such proprietary rights by implementers or users of this
specification can be obtained from the IETF on-line IPR repository at specification can be obtained from the IETF on-line IPR repository at
http://www.ietf.org/ipr. http://www.ietf.org/ipr.
The IETF invites any interested party to bring to its attention any The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary copyrights, patents or patent applications, or other proprietary
rights that may cover technology that may be required to implement rights that may cover technology that may be required to implement
this standard. Please address the information to the IETF at this standard. Please address the information to the IETF at
ietf-ipr@ietf.org. ietf-ipr@ietf.org.
Disclaimer of Validity
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.
Copyright Statement
Copyright (C) The Internet Society (2006). 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.
Acknowledgment Acknowledgment
Funding for the RFC Editor function is currently provided by the Funding for the RFC Editor function is provided by the IETF
Internet Society. Administrative Support Activity (IASA).
 End of changes. 15 change blocks. 
71 lines changed or deleted 45 lines changed or added

This html diff was produced by rfcdiff 1.32. The latest version is available from http://www.levkowetz.com/ietf/tools/rfcdiff/