draft-ietf-6man-addr-select-sol-00.txt   draft-ietf-6man-addr-select-sol-01.txt 
IPv6 Maintenance Working Group A. Matsumoto IPv6 Maintenance Working Group A. Matsumoto
Internet-Draft T. Fujisaki Internet-Draft T. Fujisaki
Intended status: Informational NTT Intended status: Informational NTT
Expires: August 2, 2008 R. Hiromi Expires: August 2, 2008 R. Hiromi
K. Kanayama K. Kanayama
Intec Netcore Intec Netcore
January 30, 2008 June 18, 2008
Solution approaches for address-selection problems Solution approaches for address-selection problems
draft-ietf-6man-addr-select-sol-00.txt draft-ietf-6man-addr-select-sol-01.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 6, line 5 skipping to change at page 6, line 5
It can support central control. A site administrator or a service It can support central control. A site administrator or a service
provider can determine users' policy tables. provider can determine users' policy tables.
8. Route selection: 2 8. Route selection: 2
Current solutions, such as DHCPv6 and RA, do not have a mechanism Current solutions, such as DHCPv6 and RA, do not have a mechanism
for cooperation with routing protocols. This could be done with for cooperation with routing protocols. This could be done with
other techniques such as "source address based routing" or other techniques such as "source address based routing" or
"Default Router Preferences and More-Specific Routes" RFC4191. "Default Router Preferences and More-Specific Routes" RFC4191.
[RFC4191] [RFC4191]
9. Compatibility with RFC 3493: 3
This approach is able to coexist with any kind of applications
(socket API). In detail, any types of function such as
getaddrinfo(), getsockname(), connect() or other typical system
calls will work without alterations if this mechanism is applied
to a host.
10. Compatibility and Interoperability with RFC 3484: 3
The basic idea of this approach has a compatibility with RFC3484.
This approach make RFC3484 policy table configurable to put some
hints related with it's individual network case.
11. Security: 2
This approach has a weakness on hijacking.
A combination of Layer 2 securing techniques and this mechanism
will be able to be effective against security concerns.
DHCP and RA protocol have own security measures and they also
protect from them.
3.1.3. Other issues 3.1.3. Other issues
- The traffic volume will be equal to the number of policies. - The traffic volume will be equal to the number of policies.
- Hosts and servers need to support this function. - Hosts and servers need to support this function.
3.2. Routing system assistance for address selection (Proactive) 3.2. Routing system assistance for address selection (Proactive)
3.2.1. Overview 3.2.1. Overview
Fred Baker proposed this approach. A host asks the DMZ routers or Fred Baker proposed this approach. A host asks the DMZ routers or
skipping to change at page 6, line 48 skipping to change at page 7, line 21
retrieved from a huge database. retrieved from a huge database.
If any server or routing trouble occurs, the requester cannot get If any server or routing trouble occurs, the requester cannot get
the answer, and address selection will fail. This point is the the answer, and address selection will fail. This point is the
same in all systems that depend on other servers. same in all systems that depend on other servers.
3. Dynamic update: 3 3. Dynamic update: 3
A routing system always has up-to-date routing information, and it A routing system always has up-to-date routing information, and it
will be possible to provide suitable information whenever requests will be possible to provide suitable information whenever requests
come. come.
4. Node-pecific behavior: 3 4. Node-specific behavior: 3
Node-specific information can be provided if a server recognizes Node-specific information can be provided if a server recognizes
individual nodes. individual nodes.
5. Application-specific behavior: 2 5. Application-specific behavior: 2
A routing system does not care about applications. Using address A routing system does not care about applications. Using address
selection API allows nodes to behave in an application-specific selection API allows nodes to behave in an application-specific
way. way.
6. Multiple Interfaces: 2 6. Multiple Interfaces: 2
If all interfaces belong to the same administration domain, it is If all interfaces belong to the same administration domain, it is
skipping to change at page 7, line 29 skipping to change at page 7, line 47
7. Central Control: 3 7. Central Control: 3
It is possible to provide address selection information from one It is possible to provide address selection information from one
source. However, because routing information changes dynamically, source. However, because routing information changes dynamically,
it is difficult to control it in the way that administrators want. it is difficult to control it in the way that administrators want.
8. Route Selection: 3 8. Route Selection: 3
It is possible to give next-hop selection advice to a host. As It is possible to give next-hop selection advice to a host. As
routers have routing information, it would seem to be easier for routers have routing information, it would seem to be easier for
routers to implement this function. routers to implement this function.
9. Compatibility with RFC 3493: 3
This approach is able to coexist with any kind of applications
(socket API). In detail, any types of function such as
getaddrinfo(), getsockname(), connect() or other typical system
calls will work without alterations if this mechanism is applied
to a host.
In the existing TCP/IP protocol stack implementation, destination
address selection is mainly the role of the application and not
that of the kernel unlike source address selection. Therefore,
implementing this model without affecting applications is not so
easy.
10. Compatibility and Interoperability with RFC 3484: 2
Currently it just proposed and there is no implementation.
Therefore, it depends on how to implement with this requirement
and it can be coexistence with RFC3484.
11. Security: 2
This approach has a weakness on hijacking.
Currently it just proposed and there is no implementation.
Therefore, it depends on how to define security protection
mechanism and how to implement it.
3.2.3. Other issues 3.2.3. Other issues
- A host must consult the routing system every time it starts a - A host must consult the routing system every time it starts a
connection if the host does not have address selection information connection if the host does not have address selection information
for the destination host or if the information lifetime has for the destination host or if the information lifetime has
expired. This could be a possible scalability problem. expired. This could be a possible scalability problem.
- The existing host/router OS implementation must be changed a lot. - The existing host/router OS implementation must be changed a lot.
In the existing TCP/IP protocol stack implementation, destination
address selection is mainly the role of the application and not
that of the kernel unlike source address selection. Therefore,
implementing this model without affecting applications is not so
easy.
3.3. Trial-and-error approach (Reactive) 3.3. Trial-and-error approach (Reactive)
3.3.1. Overview 3.3.1. Overview
M. Bagnulo proposed a new address selection method in his draft. M. Bagnulo proposed a new address selection method in his draft.
When the host notices that a network failure has occurred or packets When the host notices that a network failure has occurred or packets
have been dropped somewhere in the network by, for example, an have been dropped somewhere in the network by, for example, an
ingress filter, the host changes the source address of the connection ingress filter, the host changes the source address of the connection
to another source address. to another source address.
skipping to change at page 9, line 20 skipping to change at page 10, line 5
The only way that a central administrator has to control the node The only way that a central administrator has to control the node
behavior is switching a filter on/off on the network. Therefore, behavior is switching a filter on/off on the network. Therefore,
advanced control such as traffic engineering and QoS is almost advanced control such as traffic engineering and QoS is almost
impossible. impossible.
8. Route Selection: 2 8. Route Selection: 2
This solution does not refer to next-hop selection for the This solution does not refer to next-hop selection for the
transmission of a packet. So, it should be used with some routing transmission of a packet. So, it should be used with some routing
function such as RFC 4191 on the nodes. function such as RFC 4191 on the nodes.
9. Compatibility with RFC 3493: 1
This approach has possibility to interfere with coexistence with
applications(socket APIs). The returen value of functions would be
changed for its meaning. A case is suspected that the return
value of connect() system call will change its state from "non-
blocking" to "blocking" and this will bring alteration to the
application behaviours. Because of this suspicion, this approach
scores 1.
10. Compatibility and Interoperability with RFC 3484: 2
It depends on how to implement with this requirement. But there
will be possible conflict which a result will be overwrite the
3484 policy table without any permission of domain administrators.
11. Security: 2
This approach has a weakness on hijacking.
Currently it just proposed and there is no implementation.
Therefore, it depends on how to define security protection
mechanism and how to implement it.
3.3.3. Other issues 3.3.3. Other issues
- A host must learn address selection information for each - A host must learn address selection information for each
destination host. Therefore, the number of cache entries could be destination host. Therefore, the number of cache entries could be
very large. very large.
- The existing host/router OS implementation must be changed a lot. - The existing host/router OS implementation must be changed a lot.
In particular, changing the source address of the existing In particular, changing the source address of the existing
connection is not so easy and has a big impact on the existing connection is not so easy and has a big impact on the existing
TCP/IP protocol stack implementation. TCP/IP protocol stack implementation.
skipping to change at page 10, line 46 skipping to change at page 11, line 50
The only way that a central administrator has to control the node The only way that a central administrator has to control the node
behavior is switching a filter on/off on the network. Therefore, behavior is switching a filter on/off on the network. Therefore,
advanced control such as traffic engineering and QoS is almost advanced control such as traffic engineering and QoS is almost
impossible. impossible.
8. Route Selection: 2 8. Route Selection: 2
This solution does not refer to next-hop selection for the This solution does not refer to next-hop selection for the
transmission of a packet. Therefore, it should be used with some transmission of a packet. Therefore, it should be used with some
routing function such as RFC 4191 on the nodes. routing function such as RFC 4191 on the nodes.
3.4.3. Other issues 9. Compatibility with RFC 3493: 3
- The shim6 host performs address selection that reflects network This approach is able to coexist with any kind of applications
(socket API). In detail, any types of function such as
getaddrinfo(), getsockname(), connect() or other typical system
calls will work without alterations if this mechanism is applied
to a host.
10. Compatibility and Interoperability with RFC 3484: 1
shim6 has different framework and coordination with RFC 3484.
The shim6 host performs address selection that reflects network
failures that have occurred between the source and destination failures that have occurred between the source and destination
host. host. This may lead some interference with RFC3484 policy table.
11. Security: 1
This approach has a weakness on Denial of Service attack. It
will be concerned that the malicious users can abuse of
failure detection and make the network falling into critical
condition. However, it depends on a situation how shim6
operate with ICMPv6.
3.4.3. Other issues
- End hosts themselves can avoid network failure. There is no need - End hosts themselves can avoid network failure. There is no need
to modify or reconfigure routers in the path. to modify or reconfigure routers in the path.
- A host must learn address selection information for each - A host must learn address selection information for each
destination host. Therefore, the number of cache entries can be destination host. Therefore, the number of cache entries can be
very large. very large.
- The existing host OS implementation must be changed significantly. - The existing host OS implementation must be changed significantly.
skipping to change at page 13, line 4 skipping to change at page 14, line 17
less more less more
<-------------------------------------------> <------------------------------------------->
policy-dist 3484update shim6 Fred policy-dist 3484update shim6 Fred
PolicyDist: PolicyDist:
- What must be implemented is a distribution mechanism. The - What must be implemented is a distribution mechanism. The
existing protocols, such as RA and DHCP, can be used for this existing protocols, such as RA and DHCP, can be used for this
purpose. purpose.
3484update: 3484update:
- The protocol stack or applications on a host must be modified. - The protocol stack or applications on a host must be modified.
Routers in a site must be configured to return error messages to Routers in a site must be configured to return error messages to
the sender of inappropriately addressed packets. the sender of inappropriately addressed packets.
- In RFC3484, precedences and labels are configurable, but not scopes.
Those of issues with ULA prefix or non routable global prefix still
be left behind even if this RFC would be updated.
RouterAssist: RouterAssist:
- The protocol stack and applications on a host must be modified. - The protocol stack and applications on a host must be modified.
Furthermore, routers must be modified. Furthermore, routers must be modified.
shim6: shim6:
- The protocol stack must be modified. For this address selection - The protocol stack must be modified. For this address selection
purpose, corresponding nodes need not support shim6. Basically, purpose, corresponding nodes need not support shim6. Basically,
there is no need to change the router implementation or there is no need to change the router implementation or
configuration. configuration.
skipping to change at page 13, line 48 skipping to change at page 15, line 21
situation should be selected. situation should be selected.
8. References 8. References
8.1. Normative References 8.1. Normative References
[I-D.ietf-v6ops-addr-select-ps] [I-D.ietf-v6ops-addr-select-ps]
Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama, Matsumoto, A., Fujisaki, T., Hiromi, R., and K. Kanayama,
"Problem Statement of Default Address Selection in Multi- "Problem Statement of Default Address Selection in Multi-
prefix Environment: Operational Issues of RFC3484 Default prefix Environment: Operational Issues of RFC3484 Default
Rules", draft-ietf-v6ops-addr-select-ps-03 (work in Rules", draft-ietf-v6ops-addr-select-ps-06 (work in
progress), January 2008. progress), May 2008.
[I-D.ietf-v6ops-addr-select-req] [I-D.ietf-v6ops-addr-select-req]
Matsumoto, A., "Requirements for address selection Matsumoto, A., "Requirements for address selection
mechanisms", draft-ietf-v6ops-addr-select-req-04 (work in mechanisms", draft-ietf-v6ops-addr-select-req-07 (work in
progress), November 2007. progress), May 2008.
[RFC3484] Draves, R., "Default Address Selection for Internet [RFC3484] Draves, R., "Default Address Selection for Internet
Protocol version 6 (IPv6)", RFC 3484, February 2003. Protocol version 6 (IPv6)", RFC 3484, February 2003.
8.2. Informative References 8.2. Informative References
[I-D.fujisaki-dhc-addr-select-opt] [I-D.fujisaki-dhc-addr-select-opt]
Fujisaki, T., "Distributing Address Selection Policy using Fujisaki, T., "Distributing Address Selection Policy using
DHCPv6", draft-fujisaki-dhc-addr-select-opt-05 (work in DHCPv6", draft-fujisaki-dhc-addr-select-opt-06 (work in
progress), November 2007. progress), June 2008.
[I-D.ietf-shim6-failure-detection] [I-D.ietf-shim6-failure-detection]
Arkko, J. and I. Beijnum, "Failure Detection and Locator Arkko, J. and I. Beijnum, "Failure Detection and Locator
Pair Exploration Protocol for IPv6 Multihoming", Pair Exploration Protocol for IPv6 Multihoming",
draft-ietf-shim6-failure-detection-10 (work in progress), draft-ietf-shim6-failure-detection-10 (work in progress),
January 2008. January 2008.
[I-D.ietf-shim6-locator-pair-selection] [I-D.ietf-shim6-locator-pair-selection]
Bagnulo, M., "Default Locator-pair selection algorithm for Bagnulo, M., "Default Locator-pair selection algorithm for
the SHIM6 protocol", the SHIM6 protocol",
skipping to change at page 15, line 35 skipping to change at page 16, line 45
Ruri Hiromi Ruri Hiromi
Intec Netcore, Inc. Intec Netcore, Inc.
Shinsuna 1-3-3 Shinsuna 1-3-3
Koto-ku, Tokyo 136-0075 Koto-ku, Tokyo 136-0075
Japan Japan
Phone: +81 3 5665 5069 Phone: +81 3 5665 5069
Email: hiromi@inetcore.com Email: hiromi@inetcore.com
Ken-ichi Kanayama Ken-ichi Kanayama
Intec Netcore, Inc. INTEC Systems Institute, Inc.
Shinsuna 1-3-3 Shimoshin-machi 5-33
Koto-ku, Tokyo 136-0075 Toyama-shi, Toyama 930-0804
Japan Japan
Phone: +81 3 5665 5069 Phone: +81 76 444 8088
Email: kanayama@inetcore.com Email: kanayama_kenichi@intec-si.co.jp
Full Copyright Statement Full Copyright Statement
Copyright (C) The IETF Trust (2008). Copyright (C) The IETF Trust (2008).
This document is subject to the rights, licenses and restrictions This document is subject to the rights, licenses and restrictions
contained in BCP 78, and except as set forth therein, the authors contained in BCP 78, and except as set forth therein, the authors
retain all their rights. retain all their rights.
This document and the information contained herein are provided on an This document and the information contained herein are provided on an
 End of changes. 16 change blocks. 
23 lines changed or deleted 99 lines changed or added

This html diff was produced by rfcdiff 1.35. The latest version is available from http://tools.ietf.org/tools/rfcdiff/