Internet DRAFT - draft-wen-ipv6-rsra-opt-multihoming
draft-wen-ipv6-rsra-opt-multihoming
IETF IPv6 Working Group Haibo Wen
Internet-Draft Alcatel Shanghai Bell
Expires: October 27, 2006 March 28, 2006
Multi-homing Information option for Stateless Address Auto-Configuration
draft-wen-ipv6-rsra-opt-multihoming-00.txt
Status of this Memo
By submitting this Internet-Draft, each author represents that any
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
aware will be disclosed, in accordance with Section 6 of BCP 79.
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.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that other
groups may also distribute working documents as Internet-Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on October 27, 2006.
Copyright Notice
Copyright (C) The Internet Society (2006). All Rights Reserved.
Wen Expires October 27, 2006 [Page 1]
Internet-Draft Multi-homing option for RS/RA messages March 2006
Abstract
This document makes an extension to the standard RS/RA messages for
IPv6 network to solve some problems occurring in multi-homing
evironment. A new options, that is, Multi-homing Information option
is defined to help host do network selection and prefix selection.
Conventions used in this document
The keywords MUST, MUST NOT, REQUIRED, SHALL, SHALL NOT, SHOULD,
SHOULD NOT, RECOMMENDED, MAY, and OPTIONAL, when they appear in this
document, are to be interpreted as described in RFC 2119 [3].
1. Introduction
Stateless Address Auto-Configuration (SAAC)[1] is a very important
feature for IPv6 technology. In the standard IPv6 stateless
configuration, a router sends periodical as well as solicited Router
Advertisement (RA) messages out its advertising interfaces. When an
interface of an IPv6 host becomes enabled, the host may be unwilling
to wait for the next unsolicited RA message to locate default routers
or learn prefixes, it will transimit Router Solicitation (RS) message
to request RA message.
IPv6 multi-homing environment is used to described this kind of IPv6
site that phsically or logically connects to more than one IP Service
Provider (ISP). Multi-homing can be used for the purposes of
redundancy, load-balancing, operational policy or cost. If the IPv6
multi-homing site uses provider-assigned address prefixes for every
host's SAAC within the site, the host can obtain these prefixes
assigend by different ISPs from RA messages, and then form its IPv6
global addresses. However, most ISPs may use ingress filtering, i.e.,
the ISP's edge router at the boundary of the chosen multi-homing site
will check the source address of the packets routed from multi-homing
site whether the prefix of its source address is assigned by the ISP,
if not, the packets will be discarded. How to help host implement
exit router selection and the associated prefix or address selection
must be investigated.
In the IPv6 multi-homing site, some hosts/terminals may want to
connect to some specified ISPs. When these hosts/terminals send out
RS messages, it's not necessary for all the edge router connecting to
this site to respond with its RA message, and it's a better way that
only the edge router of the specified ISP responds this RS message
with an appropriate RA message. This can be called network sevice
selection.
This document defines an option, i.e., Multi-homing Information
Wen Expires October 27, 2006 [Page 2]
Internet-Draft Multi-homing option for RS/RA messages March 2006
option for Router Solicitation/Router Advertisement(RS/RA) messages
which can be used to solve the problems above-mentiioned.
2. RS/RA message extension
To decrease the solicited RA messages, RS message must contain some
information to help router make the appropriate decision whether it
should an approriate RA message to respond. In addition, RA message
must contain some information related to the prefix assigned by the
corresponding ISP, thus hosts can easily find the correct exit router
, the associated prefix and also form their correct IPv6 addresses
that should be used as source address for outgoing packets. Multi-
homing Information option is defind for this purpose.
2.1 Multi-homing Information option
Multi-homing Information option is used for both RS message and RA
message.
In upstream RS message, it can contain host's network
service selection infromation, for example, it can have the name of
the ISP subscribered by the host, or vendor class identifier, or
other information. The option is used in RS message, and the
corresponding router can respond it with an appropriate RA message
containing the correct prefix information.
In the downstream RA message, this option appears immediately prior
to the corresponding Prefix Information option, i.e., in a pair form
<Multi-homing Information option, Prefix Information option>. This
option is used to indicate that some specific ISP assigns the prefix
in the immediately following Prefix Information option. It can help
the host to do correct exit router selection and prefix selection.
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-option Indicator |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Multi-homing Data ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
~ Pad ~
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Type 8-bit identifier of the option type (TBD: IANA)
Option Name Type Value
Multi-homing Information option (TBD)
Wen Expires October 27, 2006 [Page 3]
Internet-Draft Multi-homing option for RS/RA messages March 2006
Length 8-bit unsigned integer. The length of the option
(including the type and length fields) is in units
of 8 octets. The value 0 is invalid. Nodes MUST
silently discard an ND packet that contains an
option with length zero.
Sub-option indicator
Each bit of this field is used for indicating some
specific sub-option is included in this Multi-
homing Information option. The value 0 is invalid.
Nodes MUST silently discard an ND packet that
contains an option with length zero.
Currently only the least 5 bits are defined (refer
to subsection 2.1.1).
Multi-homing Data
This field is used to contain the information
related to multi-homing (e.g., the name of some
specified ISP, or the vendor class identifier
information, or any other information) for network
service selection in RS message and for prefix/exit
router selection in RA message. It can contain more
than one Multi-homing-subopiton if required (the
sub-options are shown in subsection 2.1.2).
Pad Variable-length field. This field is used to align
Multi-homing Information option in units of 8
octets. The content of Pad field is 0. That is,
using the minimum octets with 0 to make sure the
length of the whole option to be in units of 8
octets.
Description
When this option exists in RS and RA message for
different purpose. In RS message, it help router
decide whether it should respond. In RA message, it
help host do correct selection of prefix exit
router: the host can record each prefix and its
associated information (e.g., the ISP that assigns
this prefix, and the link-local address of the exit
router that advertises this RA) and form feasible
global IPv6 address as source address, and then
forward parckets to the apporiate ISP.
2.1.1 Format for the field of Sub-option Indicator
The format for the field of sub-option Indicator is shown below. Only
5 least bits are used for indicating some special information are
Wen Expires October 27, 2006 [Page 4]
Internet-Draft Multi-homing option for RS/RA messages March 2006
requsted from router or some special information is containing in the
following Multi-homing Data field. The corresponding sub-options are
explained in subsection 2.1.2.
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| reserved |S|D|E|V|I|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Reserved This 11-bit is currently unused. It must be set to
0. If required, other bit can be used.
S If set to 1: (i) for RS message, it means that host
is soliciting the address of SIP server in some ISP
; (ii) for RA message, it means there is a SIP
server sub-option in the Multi-homing Data field.
D If set to 1: (i) for RS message, it means that host
is soliciting the address of DNS server in some ISP
; (ii) for RA message, it means there is a DNS
server sub-option in the Multi-homing Data field.
E If set to 1: (i) for RS message, it means that host
is soliciting the address of the edage router of
some ISP; (ii) for RA message, it means there is an
edge-router addess sub-optiono in the Multi-homing
Data field.
V If set to 1, that means there is a Vendor class
sub-option in Multi-homing Data field.
I If set to 1, that means there is a ISP name sub-
option in Multi-homing Data field.
2.1.2 Multi-homing sub-options
Multi-homing sub-option will be used in the field of Multi-homing
Data of Multi-homing Information option.
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Sub-Type | Length | Sub-option Data ...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Fields:
Wen Expires July 8, 2006 [Page 5]
Internet-Draft Multi-homing option for RS/RA messages March 2006
Sub-Type 8-bit identifier of the type of sub-options
Sub-Option Name value
ISP name 1
Vendor Class 2
edge router address 3
DNS server address 4
SIP server address 5
Length 8-bit unsigned integer. The length of the field of
Sub-option Data in octets. The value 0 is invalid.
Nodes MUST silently discard an ND packet that
contains an sub-option with length zero.
Sub-option Data
Variable-length field. Option-Type-specific data.
This field is used to contain detailed information
for network service selection. Depending on the
value of Sub-Type field, Sub-option Data field can
have different format.
When Sub-Type is 1, the Sub-option Data field
contains ISP name. For RS message, it contains the
name of the desired ISP for the host.
When Sub-Type is 2, the Sub-option Data field
contains vendor class identifier, which may be used
to identify the vendor and fuctionality of a device
that iniates this RS message. The information is a
variable length string of characters or octets
which has a meaning specified by the vendor of the
device. It's kind of the Vendor Class Identifier (
option 60) in DHCPv4.
When Sub-Type is 3, the Sub-option Data field
contains the global IPv6 address of the edge router
, and this edge router is the nearest one close to
this multi-homing site from the ISP that assigns
the prefix to the multi-homing site. This global
address MAY be used by hosts with Type 0 Routing
Header for fast forwarding the packets to the
desird ISP.
Wen Expires October 27, 2006 [Page 6]
Internet-Draft Multi-homing option for RS/RA messages March 2006
When Sub-Type is 4 or 5, the Sub-option Data
field contains the corresponding address from the
specific ISP, i.e., the DNS server address and SIP
server address, respectively. It can simplify the
process of host obtaining the addresses of DNS
server and/or SIP server, for these information is
piggyback on SAAC.
Description
The sub-options can be used in a combination if
needed. The router, which can identify the sub-
options and find the matchings in its own data base
, will respond with corresponding information in a
RA message. The router, which can not indentify the
multi-homing infomration option will ignore this
option.
In additon, any other new sub-options can be
defined to make new extention. For example, it can
also be extended for access network to carry
authentication information when access network
requires simpler authentication without very strict
secure request. For this case, to make the
information far away from attack or snooping, IPv6
Encapsulating Security Payload Header option can be
used.
3. Scenario for usage of new option for IPv6 SAAC in multi-homing
environment
In order to explain the usages of Multi-homing Information option
more clearly, scenarios are shown in the following subsections.
3.1 Scenario 1: physically multi-homing site
+-------+-------+ +-------+-------+
| DNS server 1 | | SIP server 2 |
+-------+-------+ +-------+-------+ \
__________|_________ ________|___________ \
/ \ / \ \
| ISP1 core network | | ISP2 core network | |
\__________ _________/ \__________ _________/ |
| / | ISP
| / | network
| / /
+-------+-------+ +-------+-------+ /
| edge router 1 | | edge router 2 | /
+-------+-------+ +-------+-------+
Wen Expires October 27, 2006 [Page 7]
Internet-Draft Multi-homing option for RS/RA messages March 2006
\ / \
\--------+--------/ \
| | multihoming
+------------+--+--------------+ | site
| | | |
+-----+----+ +----+-----+ +-----+----+ /
| host 1 | | terminal | ... | host n | /
+----------+ +----------+ +----------+ /
Figure 1: IPv6 multi-homing site with two exit routers
Figure 1 illustrates an IPv6 multi-homing site with two exit routers.
In this scenario, the site is physcially connected to more than one
ISP core network through different edge router of the ISPs. Each ISP
has its own DNS server and ISP server. The edge router will advertise
RA message containing corresponding informtion. For the multi-homing
site, the edge routers of ISPs are its exit router. Normally, the
router advertises periodic RA message with Prefix Information option
and Multi-homing Information option only including ISP name
sub-options. When the interface of host is enabled, it will send out
a RS message which will contain some inforamtion that the host shows
interest in. If it wants to know other information (e.g., SIP server,
DNS server), router will repond with corresponding information.
Figure 2 shows the procedure of stateless auto-configuration in this
multi-homing environment. Here, we assume the interface of host 1 is
enabled, it wants service from ISP1, and in addition it wants to
obtain the DNS server address of ISP1.
+---------+ +-----------+ +-----------+
|User IPv6| | ISP1 edge | | ISP2 edge |
| host 1 | | router1 | | router2 |
+---------+ +-----------+ +-----------+
| | |
(a) |---RS with Multi-homing Info. option---->| |
| (including ISP name subopt. | |
| & DNS server subopt.)| |
| \this RS will reach the edge router2 of ISP2--->|
| |
(b) | edge router 1 of ISP1 sends out |
|<--RA with Multi-homing Info. option-----|
| (including ISP name subopt. |
| & DNS server subopt.)|
| and Prefix Info. option |
Figure 2. Procedure of stateless auto-configuration for host 1
requiring RA message from ISP1
Wen Expires October 27, 2006 [Page 8]
Internet-Draft Multi-homing option for RS/RA messages March 2006
The procedure consists of the following steps:
Step (a) : IPv6 Host1 sends RS (Router Solicitation) message
to get RA message. This RS message contains Multi-homing
information option for ISP selection and configuration:
ISP name sub-option with ISP1 name, and DNS server option
with 0 filled in Sub-option Data field. This RS message
will reach to all the edge routers that connect to this
multi-homing site.
Step (b) : According to the ISP name sub-option in the Multi-homing
Information option, the edge router 1 of ISP1 knows that
it should provide the appropriate information to respond
this RS message: Prefix information, and the requested DNS
server address. So it forms the RA message with correct
<Multi-homing Information option, Prefix Information
option> pair.The Multi-homing Information option contains
ISP name and DNS server address. Host 1 can obtain its
desired prefix information and the exact associated exit
router (its address is in the source address of RA message
). Then it can construct its IPv6 address via the method
in [1].
Note: Though the edge router 2 of ISP2 has received the RS
message too, it will not respond with a RA message because
it knows the host is soliciting information from ISP1.
3.2 Scenario 2: Access network connecting multiple ISPs, layer3 CPE in
subscriber network
____________________ ____________________ \
/ \ / \ \
| ISP1 core network | | ISP2 core network | \
\__________ _________/ \__________ _________/ |
| / | ISP
| / | network
| / /
+-------+-------+ +-------+-------+ /
| edge router 1 | | edge router 2 | /
+-------+-------+ +-------+-------+
\ / \
____\_________________/ \
/ \ |
| aggregation network | |
\__________ ___________/ |
| | access
+-------+-------+ | network
| layer 2 | |
Wen Expires October 27, 2006 [Page 9]
Internet-Draft Multi-homing option for RS/RA messages March 2006
| access node | |
+-------+-------+ |
| /
|DSL to subscriber /
|premises /
|
+------+------+ \
| layer3 CPE | \
| (routed-CPE)| \
+------+------+ | Subscriber
| | network
+------------+--------------+ |
| | | |
+-----+----+ +----+-----+ +-----+----+ /
| host1 | | host2 | | hostn | /
+----------+ +----------+ +----------+ /
Figure 3: IPv6 access network with multi-homing environment
Figure 3 illustrates the IPv6 access network with multi-homing
environment via connecting to multiple ISPs. RS/RA messages are
running between routed-CPE and hosts. The routed-CPE can obtain
different prefix from the edge router of each ISP connecting to the
access network. For the subscriber network, it's logically multi-
homing. Routed-CPE must record the mapping information that some
specific prefix is obtained from the specific edge router from the
specific ISP.
+---------+ +-----------+ +------------------+
|User IPv6| | routed | |ISP's edge router |
| host | | CPE | | |
+---------+ +-----------+ +------------------+
| |
(a)|-RS with Multi-homing->|
| Info. option | |
| / Prefix delegation \ |
(b)|<----|from desired ISP via | ----->|
| \ DHCP or RADIUS / |
(c)|<- RA with <Multi- --|
| homing Info option, |
| Prefix Info option> |
Figure 4. Procedure of stateless auto-configuration for scenario 2
Figure 4 shows the procedure of stateless auto-configuration for this
IPv6 access network in multi-homing environment. The procedure
consists of the following steps:
Wen Expires October 27, 2006 [Page 10]
Internet-Draft Multi-homing option for RS/RA messages March 2006
Step (a) : IPv6 host sends RS message to solicite RA message. This RS
message inlcudes Multi-homing Information option with ISP
name sub-option.
Step (b) : Routed CPE receives RS message. If the gateway hasn't
obtained a prefix from desired ISP, it will request prefix
delegation from desired ISP via DHCP or RADIUS or any
other methods.
Step (c) : Routed-CPE advertises the appropriate RA message based
on the RS message to host. The RA message contains
the appropriate multi-homing with ISP name and Prefix
Information option. Then the host can select the
appropriate prefix according to the ISP name to perform
stateless address autoconfiguration. In addition, routed-
CPE can know the global address of each edge router that
connects to it. Then it can contain the edge-router
address in Multi-homing Information option. Thus the host
in the subscriber network can use Type 0 Routing Header[2]
for fast forwarding the packets to the desird ISP.
In this scenario, since the routed-CPE has recorded the mapping of
prefix information and the ISP's edge router, if it addes function of
forward the outgoing packets from the subscriber network based on the
indiation of the source addresses (i.e., if the packet's source
address is in the domain of the prefix that is assigned ISP1, the
packet must be forwarded to the edge router of ISP1), it's not
necessary for host to use Type 0 Routing Header.
This procedure is also applicable for access node is a layer3 device
while CPE is a layer2 device. For this case, RS/RA is running between
access node and hosts.
3.3 Scenario 3: Layer2 access network and layer2 CPE in subscriber
network
In this scenario, the network architecture resembles the one in
Figure 3 except that a layer2 CPE (or bridged-CPE) replacs the
layer3 CPE (or routed-CPE) in the subscriber network. Access node is
still a layer 2 device. Here, RS/RA messages are run between hosts/
terminals and the edge routers. Figure 5 shows the procedure of SAAC
for this scenario.
Wen Expires October 27, 2006 [Page 11]
Internet-Draft Multi-homing option for RS/RA messages March 2006
+---------+ +-----------+ +------------------+
|User IPv6| | layer2 | |ISP's edge router |
| host | |access node| | |
+---------+ +-----------+ +------------------+
| | |
(a)|-- RS with Multi -->| |
| -homing Info. option | |
(b)|----RS to the appropriate router-->|
| |
(c)|<---RA with <Multi-homing info. --|
| option, Prefix Info. option> |
(d)|<-RA with<Multi-homing -|
| Info. option, Prefix |
| Info. option> |
Figure 5. Procedure of stateless auto-configuration for scenario 3
The procedure consists of the following steps:
Step (a) : IPv6 Host sends RS message to get RA message. This RS
message network selection information in Multi-homing
Information option.
Step (b) : Base on the information in Multi-homing Information option
, layer 2 access node can forward this RS to the correct
edge router of the desired ISP without sending it to the
router that will not respond this RS.
Step (c) : Edge router forms the appropriate RA message according to
the RS message. The RA message will containing the
appropriate <Multi-homing Information option, Prefix
Information option>.
Step (d) : Access node relays the RA message to the corresponding
subscriber network. Then the host can select the
appropriate prefix according to the ISP name to perform
stateless address autoconfiguration.
4. Acknowledgements
The author would like to thank Songwei Ma, David Watkinson and the
other members in R&I access and edge group in lcatel Shanghai Bell
for their comments and help.
5. References
5.1 Normative References
Wen Expires October 27, 2006 [Page 12]
Internet-Draft Multi-homing option for RS/RA messages March 2006
[1] S. Thomson, and T. Narten, "IPv6 Stateless Address
Autoconfiguration", RFC2462, December 1998.
[2] S. Deering, and R. Hiden, "Internet Protocol, Version 6 (IPv6)
Specification", RFC2460, December 1998.
[3] S. Bradner, "Key words for use in RFCs to Indicate Requirement
Levels", BCP 14, RFC 2119, March 1997.
Authors' Addresses
Haibo Wen
Alcatel Shanghai Bell Co., Ltd.
388#, NingQiao Road, Pudong Jinqiao
Shanghai 201206 P.R. China
Phone: +86 (21) 5854-1240, ext.: 9273
Email: Haibo.WEN@alcatel-sbell.com.cn
Intellectual Property Statement
The IETF takes no position regarding the validity or scope of any
intellectual property 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; neither does it represent that it
has made any effort to identify any such rights. Information on the
IETF's procedures with respect to rights in standards-track and
standards-related documentation can be found in BCP-11. Copies of
claims of rights made available for publication 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 implementors or users of this specification can
be obtained from the IETF Secretariat.
The IETF invites any interested party to bring to its attention any
copyrights, patents or patent applications, or other proprietary
rights which may cover technology that may be required to practice
this standard. Please address the information to the IETF Executive
Director.
Full Copyright Statement
Copyright (C) The Internet Society (2006). All Rights Reserved.
This document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any
Wen Expires October 27, 2006 [Page 13]
Internet-Draft Multi-homing option for RS/RA messages March 2006
kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing
the copyright notice or references to the Internet Society or other
Internet organizations, except as needed for the purpose of
developing Internet standards in which case the procedures for
copyrights defined in the Internet Standards process must be
followed, or as required to translate it into languages other than
English.
The limited permissions granted above are perpetual and will not be
revoked by the Internet Society or its successors or assignees.
"AS IS" basis and THE INTERNET SOCIETY AND THE INTERNET ENGINEERING
TASK FORCE DISCLAIMS 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.
Wen Expires October 27, 2006 [Page 14]
