One document matched: draft-cui-netext-route-optimization-agent-ext-00.txt
Netext Working Group X. Cui
Internet Draft Huawei
Intended status: Informational October 16, 2009
Expires: April 2010
Reflector Extension for Route Optimization Agent
draft-cui-netext-route-optimization-agent-ext-00.txt
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
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 April 15 2010.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Cui Expires April 15, 2010 [Page 1]
Internet-Draft Route Optimization Agent Extension October 2009
Abstract
Route Optimization is a very useful feature in Mobile IPv6. Mobile
node can communicate with correspondent node without the involvement
of the home agent by Route Optimization. But there are some
limitations to this feature. One problem is that the mobile node and
the correspondent node must be capable for Route Optimization. This
document introduces an extension mechanism used for Route
Optimization and this extension mechanism can enable Route
Optimization be used between mobile node and simple IP node. In the
extension solution, the MAG can reflect the RO-related signal
messages and fulfill the Route Optimization procedure on behalf of
the simple IP node.
Conventions used in this document
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 [RFC2119].
Cui Expires April 15, 2010 [Page 2]
Internet-Draft Route Optimization Agent Extension October 2009
Table of Contents
1. Introduction....................................................4
2. Terminology.....................................................4
3. Scenario Analysis and Use Case..................................5
3.1. Issues if the CN can't support Route Optimization..........5
3.2. Motivation.................................................7
3.3. Requirement................................................9
3.4. Use Case for Agent Extension to Fulfill Route Optimization.9
4. Solution and Operation Consideration...........................12
4.1. MAG Operation.............................................12
4.1.1. Incoming Flow Transmission...........................13
4.1.2. Outgoing Flow Transmission...........................13
4.1.3. Conceptual Data Structures...........................14
4.2. Operation in Other Network Element........................15
5. Security Considerations........................................15
6. IANA Considerations............................................15
7. Acknowledgments................................................16
APPENDIX A: Future Extension and Use Case.........................17
A.1. Extension for Mobile Router in NEMO.......................17
A.2. Extension for IPv4/MIP4...................................18
8. References.....................................................18
8.1. Normative References......................................18
8.2. Informative References....................................18
Author's Addresses................................................18
Cui Expires April 15, 2010 [Page 3]
Internet-Draft Route Optimization Agent Extension October 2009
1. Introduction
Mobile IPv6 protocol [RFC3775] provides a mobility extension to basic
IPv6 and introduces a Route Optimization (RO) mechanism. Route
Optimization enables mobile node (MN) to establish a directly
connection between mobile node and correspondent node (CN) without
the involvement of MN's home agent (HA).
But Route Optimization requires mobile node and correspondent node to
have some certain capabilities, such as MN's transmitting Home Test
Init (HoTI) message, Care-of Test Init (CoTI) message and direct
Binding Update message to CN, and CN's reflecting Home Test (HoT)
message, Care-of Test Init (CoT) message and Binding Ack message to
MN.
If the CN is a simple IP node without support for Route Optimization,
the MN with support for Route Optimization even can't use Route
Optimization with this CN, as [RFC3775] specified ''If a mobile node
attempts to set up route optimization with a node with only basic
IPv6 support, an ICMP error will signal that the node does not
support such optimizations and communications will flow through the
home agent.''
From the MN's viewpoint, the IPv6 nodes with support for MIP and IPv6
nodes without support for MIP are using the unified address space, so
the MN can't distinguish whether a correspondent node is a RO-capable
node or a none-RO-capable node. When the network is composed of
mobile IPv6 nodes, IPv6 nodes with support for Route Optimization and
enormous quantity of simple IPv6 nodes with support for only basic
IPv6 protocol, lots of Route Optimization attempts will go to
failure.
This document introduces an extension mechanism, which can be used
for IP nodes with only support for basic IPv6 protocol, to fulfill
the Route Optimization.
2. Terminology
All the mobility related terms used in this document are to be
interpreted as defined in the Mobile IPv6 specification [RFC3775] and
Proxy Mobile IPv6 [RFC5213].
Cui Expires April 15, 2010 [Page 4]
Internet-Draft Route Optimization Agent Extension October 2009
3. Scenario Analysis and Use Case
3.1. Issues if the CN can't support Route Optimization
Mobile IPv6 provides the Route Optimization mechanism, which may be
used between mobile nodes with support for MIPv6 or between mobile
nodes and IP nodes with support for Route Optimization.
In other situation, if the correspondent node can't support Route
Optimization, the correspondent node will reply an ICMP ERROR message
to the mobile node who initiates the Route Optimization.
On the other hand, Proxy Mobile IPv6 [RFC5213] provides a network-
based mobility solution. In Proxy Mobile IPv6 domain, Mobile Access
Gateway (MAG) can provide a proxy mobility management functionality,
e.g. transmitting binding update message to mobility anchor on behalf
of the mobile node.
The MAG works as the mobility proxy for the mobile node, as [RFC5213]
defined, ''Mobile Access Gateway is a function on an access router
that manages the mobility-related signaling for a mobile node that is
attached to its access link''. But by now the MAG is only a half-
function proxy for the mobile node, because the MAG can only transmit
mobility-related signal messages for the mobile node but can not
dispose the mobility-related signal messages destined to the mobile
node. The MAG is only an active proxy function but does not implement
reactive agent function in current specification. The function of
managing the mobility-related signaling defined for MAG is not fully
introduced by now.
Take the Route Optimization procedure as the example. If the mobile
node is setting up Route Optimization with a simple IP node which is
attached to the MAG, the message flow is as below:
Cui Expires April 15, 2010 [Page 5]
Internet-Draft Route Optimization Agent Extension October 2009
MN1 HA LMA MAG MN2
| | | | |
=== MN1 attached to HA and MN2 attached to MAG ===
(a) === MAG runs PMIP protocol for MN2 (Basic IP) ===
=== MN1 has no idea about the capability of MN2 ===
| | | | |
| HoTI | | | |
(b) |------ > | HoTI | | |
(c) | |--------- >| HoTI | |
(d) | | |------- >| HoTI |
(e) | | | |------- >|
| | | |ICMP(Err)|
(f) | | | |<--------|
| CoTI | | |
(g) |------------------- >| CoTI | |
(h) | | |------- >| CoTI |
(I) | | | |------- >|
| | | |ICMP(Err)|
(j) | | | |<--------|
|ICMP(Err)| | | |
(k) |<--------| | | |
| | | | |
| | | | |
| | | | |
Figure 1 Issue in Route Optimization.
The detailed descriptions are as follows:
(a) MN1 attached to Home Agent and MN2 attached to MAG, MAG runs PMIP
protocol for MN2, which only supports basic IP protocol. During
the lifetime of the session between MN1 and MN2, MN1 has no idea
about the capability of MN2.
(b~e) MN1 initiates a Route Optimization set up and sends Home Test
Init message to MN2. The destination address of the packet is
the home address of MN2 and the packet goes through HA, LMA and
MAG, at last arrives at MN2.
(f) MN2 can't recognize the Home Test Init message and replies an
ICMP error message to MN1.
Cui Expires April 15, 2010 [Page 6]
Internet-Draft Route Optimization Agent Extension October 2009
(g~i) MN1 sends Care-of Test Init message to MN2. The destination
address of the packet is the home address of MN2 and the packet
goes through LMA and MAG, at last arrives at MN2 too.
(j) MN2 can't recognize the Care-of Test Init message and replies an
ICMP error message to MN1.
(k) MN1 receives the ICMP error messages sent by MN2, has to stop
Route Optimization set up.
In this example, Home Test Init message and Care-of Test Init message
are both mobility-related signaling, but the MAG doesnot manage or
deal these messages for MN2. This miss induces the failure of Route
Optimization.
3.2. Motivation
The motivation for this extension is based on some mechanisms that
have been introduced in IETF. For example, Proxy ARP protocol, which
is specified in Using ARP to Implement Transparent Subnet Gateways
[RFC1027], has been adopted by lots of routers and gateways.
One basic Proxy ARP flow is as below:
Cui Expires April 15, 2010 [Page 7]
Internet-Draft Route Optimization Agent Extension October 2009
Host A Gateway Host B
| e0 | e1 |
| | |
------- Host A and Host B attached to the Gateway -------
| | |
| ARP request (IP B) | |
|----------------------- > | |
| | |
| proxy ARP reply (IP B) | |
|< ------------------------| |
| | |
| traffic data (IP B) | |
|------------------------ >| traffic data (IP B) |
| |------------------- >|
| | |
| | |
Figure 2 Proxy ARP message flow.
In this case, when host A wants to send IP packets to host B, if host
A knows only the IP address of host B but doesn't know the MAC
address of host B, host A need send out a ARP request message and
broadcast the message in MAC layer. The gateway will receive this ARP
request, whose destination IP address is the IP address of host B.
The destination of this message is not the gateway, but the gateway
knows that the destination (i.e. host B) is attached to itself and
also knows the destination can't receive this ARP request, so in this
situation, the gateway replies an ARP reply message for host B. In
the proxy ARP reply message, the source IP address is the IP address
of host B and the source MAC address is the MAC address of the e0
interface in the gateway. When host A receives this proxy ARP reply
message, it can know how to send IP packets to host B. Host A will
send IP packets to the gateway (i.e. the e0 interface) and the
gateway will forward these packets to host B.
Similar to this case, when the MAG in the PMIP domain receives some
mobility-related signal messages (e.g. HoTI, CoTI and BU) destined to
the mobile node that is attached to its access link, the MAG can also
know that the mobile node can't recognize these messages. Since the
MAG is the mobility proxy of the mobile node and can manage the
mobility-related signaling for the mobile node, it is reasonable for
the MAG to dispose these messages on behalf of the mobile node. The
MAG MAY work as a reactive mobility agent in this situation.
Cui Expires April 15, 2010 [Page 8]
Internet-Draft Route Optimization Agent Extension October 2009
3.3. Requirement
The Route Optimization Agent extension introduced in this document
depends on the operation of the MAG. The requirements on the MAG to
achieve the extension include following:
R1: MAG can recognize mobility-relate signal message. When the MAG
receives mobility-related signaling destined to the MN that is
attached to its access link, the MAG MAY intercept the messages and
reply response messages for the mobile node. Since all the mobility-
related signal messages contain a mobility header and a MH Type
field, the MAG can easily fulfill this requirement.
R2: MAG can achieve the operation of CN role for Route Optimization
specified in [RFC3775]. [RFC5213] has specified some mechanisms for
MAG to provide network-based mobility management function and the MAG
can create and maintain the Binding Update List as a mobile node
does, so it is also easy to expand the MAG to create and maintain a
Binding Cache Entry to meet this requirement. The MAG MAY do more
agent operation than specified in [RFC5213] as specified in this
document.
R3: MAG can modify the sent-out packets and route the packets to the
optimized route basing the created Binding Cache. The MAG MAY check
whether a binding cache exists and if the binding cache exists the
MAG modifies the destination address in the IP header and includes
Type 2 Routing Header in the sent-out packets. The MAG should set the
destination address as the care-of address of the destined mobile
node and set the Home Address field in the Type 2 Routing Header to
the home address of the destined mobile node.
3.4. Use Case for Agent Extension to Fulfill Route Optimization
This document extends the mobility proxy function of the MAG to the
full-functional proxy and enables the MAG to manage all the mobility-
related signaling for the mobile node that is attached to its access
link. The use case is as below:
Cui Expires April 15, 2010 [Page 9]
Internet-Draft Route Optimization Agent Extension October 2009
MN1 HA LMA MAG MN2
| | | | |
=== MN1 attached to HA and MN2 attached to MAG ===
a === MAG runs PMIP protocol for MN2 (Basic IP) ===
=== MN1 has no idea about the capability of MN2 ===
| | | | |
| HoTI | | | |
b1 |------ > | HoTI | | |
b2 | |--------- >| HoTI | |
b3 | CoTI |------- >| |
c1 |------------------- >| HoT | |
d1 | | |< -------| |
| | | CoTI | |
c2 | | HoT |------- >| |
d2 | HoT |< ---------| | |
d3 |< -------| | CoT | |
e1 | CoT |< -------| |
e2 |< -------------------| | |
| | | |
| | | |
| BU | | |
f1 |------------------- >| BU | |
f2 | |------- >| |
| |Binding Ack |
g1 | Binding Ack |< -------| |
g2 |< -------------------| | |
| Traffic data | | |
-|------------------- >| Traffic | |
/ | |------- >| Traffic |
/ | | |------- >|
h | | | | Traffic |
\ | | Traffic |< -------|
\ | Traffic data |< -------| |
-|< -------------------| | |
| | | |
Figure 3 Agent extension in Route Optimization.
The detailed descriptions are as follows:
(a) MN1 attached to Home Agent and MN2 attached to MAG, MAG runs PMIP
protocol for MN2, which only supports basic IP protocol. During
Cui Expires April 15, 2010 [Page 10]
Internet-Draft Route Optimization Agent Extension October 2009
the lifetime of the session between MN1 and MN2, MN1 has no idea
about the capability of MN2.
(b1~b3) MN1 initiates a Route Optimization set up and sends Home Test
Init message to MN2. The destination address of the packet is
the home address of MN2 and the packet goes through HA and LMA
and reaches MAG.
(c1~c2) MN1 sends Care-of Test Init message to MN2. The destination
address of the packet is the home address of MN2 and the packet
goes through LMA and reaches MAG too.
(d1~d3) MAG recognizes the Home Test Init message, which is a
mobility-related signaling, and generates a Home Test message
on behalf of MN2. The procedure for the MAG to generate the
Home Test message is as the same with CN's operation specified
in section 9.4.1 and section 9.4.3 of [RFC3775]. The MAG
transmits Home Test message to MN1 and the packet goes through
LMA and HA and arrives at MN1 at last.
(e1~e3) MAG recognizes the Care-of Test Init message, which is a
mobility-related signaling, and generates a Care-of Test
message on behalf of MN2. The procedure for the MAG to generate
the Care-of Test message is as the same with CN's operation
specified in section 9.4.2 and section 9.4.4 of [RFC3775]. The
MAG transmits Care-of Test message to MN1 and the packet goes
through LMA and arrives at MN1 at last.
(f1~f2) MN1 receives Home Test and Care-of Test message and sends
Binding Update message to the address of MN2 as specified in
[RFC3775]. The Binding Update message also reaches the MAG
which the MN2 attached to.
(g1~g2) MAG recognizes the Binding Update message, which is a
mobility-related signaling, and caches the Home Address, Care-
of Address and bindings on behalf of MN2. The procedure is as
the same with CN's operation as specified in section 9.5.1 of
[RFC3775]. The MAG also includes the IP address of the attached
IP node (i.e. the destination of the Binding Update message) in
the binding cache. The MAG transmits Binding Ack message to MN1
and the packet goes through LMA and arrives at MN1 at last.
(h) Route Optimization is achieved and Home Agent of MN1 is not
involved in the traffic data transport. For the traffic flow
from MN1 to MN2, the MAG forwards all the traffic packets basing
on the destination address of the packets. For the traffic flow
Cui Expires April 15, 2010 [Page 11]
Internet-Draft Route Optimization Agent Extension October 2009
from MN2 to MN1, the MAG achieves the operation specified in
section 4.1.2.
4. Solution and Operation Consideration
4.1. MAG Operation
The MAG is a function that typically runs on an access router. The
MAG transfers all the IP packets from or destined to the mobile node
that is attached to its access link. However, some more operation is
defined in this document for the expansion solution.
The operations for Route Optimization Agent Function consist of
following:
o Intercepting and disposing the mobility-related signaling destined
to the attached mobile node.
o Creating, maintaining and deleting the binding cache for the
mobile node to which the initiator wants to establish or release
a Route Optimization.
o Destination Address replacement for the outgoing traffic from the
attached mobile node.
o Security operation for the Return Routability Procedure and Route
Optimization. The MAG SHOULD works as specified in section 5.2
and section 15.4 in [RFC5213] for the role of correspondent node,
if the MAG runs the Route Optimization Agent Function.
Editor Note:
The introduced Route Optimization Agent Function in the reflector
may even be separate with the active Proxy Mobile IP function
introduced in [RFC5213]. This is to say that the binding cache
management and the binding update list management may be
independent. The details need more consideration and discussion.
Cui Expires April 15, 2010 [Page 12]
Internet-Draft Route Optimization Agent Extension October 2009
4.1.1. Incoming Flow Transmission
For the incoming (i.e. from the remote IP node to the IP node that is
attached to the access link of the MAG) flow, the MAG needs parse the
IP header to check the packet type as soon as it receives the packet
from the remote IP node.
If the IP packets received from other IP nodes don't contain mobility
header, the IP packets are not mobility-related signaling, the MAG
works as a normal router for these non-mobility-related IP packets.
If the IP packets received from other IP nodes contain the mobility
header, the MAG needs further check the MH type field in the mobility
header. The MAG MAY execute the expansion solution for these
mobility-related packets.
When the received packet is Home Test Init Message, the MAG stops
transferring the packet to the attached IP node and executes the
operation as specified for the correspondent node role in section
9.4.1 and 9.4.3 of [RFC3775].
When the received packet is Care-of Test Init Message, the MAG stops
transferring the packet to the attached IP node and executes the
operation as specified for the correspondent node role in section
9.4.2 and 9.4.4 of [RFC3775].
When the received packet is Binding Update message, the MAG stops
transferring the packet to the attached IP node and executes the
operation as specified for the correspondent node role in section
9.5.1 and 9.5.4 of [RFC3775].
4.1.2. Outgoing Flow Transmission
For the outgoing (i.e. from the IP node that is attached to the
access link of the MAG to the remote IP node) flow, the MAG needs
examine its Binding Cache for an entry for the address pair (i.e. the
source address and the destination address of the IP packet) as soon
as it receives the packet from the attached IP node.
If no corresponding binding cache entry exists, the MAG works as a
normal MAG for these packets.
If a corresponding binding cache entry exists, it means Route
Optimization has been established between the IP node pair. The MAG
MAY use a type 2 routing header to route the packet to the
Cui Expires April 15, 2010 [Page 13]
Internet-Draft Route Optimization Agent Extension October 2009
destination node by way of its care-of address. However, the MAG MUST
NOT do this in the following cases:
o When forwarding an IPv6 Neighbor Discovery packet.
o When forwarding the packets that are noted in Section 6.1 of
[RFC3775].
The MAG may implement following operation for Route Optimization:
o The MAG inserts the Type 2 routing header and sets the Home
Address in the routing header to the remote mobile node's home
address (the original destination address to which the packet was
being sent).
o The MAG sets the Destination Address in the packet's header to the
remote mobile node's care-of address copied from the Binding
Cache entry.
o The MAG forwards the modified packet as specified in section
6.10.5 of [RFC5213].
Note that the implementation creates some additional requirements for
path MTU discovery since the modification changes the packet size.
The MAG should choose an appropriate way to indicate the sending IP
node this situation.
4.1.3. Conceptual Data Structures
Every MAG maintains a Binding Update List Entry as specified in
[RFC3775] and this document adds Binding Cache to the MAG. When the
MAG receives the Binding Update message destined to the attached
mobile node the MAG creates the binding cache entry and associates
the entry to the destination mobile node.
The newly introduced Binding Cache Entry for this extension contains
two additional fields than the data structure specified in section
9.1 of [RFC3775].
o The binding cache entry contains a flag indicating whether or not
this binding cache is a agent binding cache entry.
Cui Expires April 15, 2010 [Page 14]
Internet-Draft Route Optimization Agent Extension October 2009
o The binding cache entry contains an associated mobile node
address, which is the true destination of the intercepted Binding
Update message.
Each binding cache is mapped with an address pair (i.e. the home
address of the RO-initiator mobile node and the IP address of the
attached mobile node). The binding cache contains the care-of address
of the RO-initiator mobile node as specified in section 9.1 of
[RFC3775]. Route Optimization may be applied between the address
pair.
4.2. Operation in Other Network Element
The extension mechanism introduced in this document doesn't impact
the operation in MN, HA, LMA and CN. These network elements follow
the operation described in other specification.
5. Security Considerations
The extension in this document is just to expand the scope of the
mobility management to cover the reactive mobility management agent
function, such as the acceptance of Route Optimization, and the MAG
still follows the principle that providing network-based mobility
management to the mobile node that is attached to its access link. So
this extension brings no new security issue to mobility management.
But this extension needs the MAG to implement packet inspection on
the packets destined to the mobile node, which would impact the
performance of the MAG and maybe bring some security risk. By the
time when this document is written, no explicit security problem has
been found and the accurate security consideration needs to be
further studied.
6. IANA Considerations
This document has no actions for IANA.
Cui Expires April 15, 2010 [Page 15]
Internet-Draft Route Optimization Agent Extension October 2009
7. Acknowledgments
The author would like to thank Netext Working Group for the review,
comment and discussion.
Cui Expires April 15, 2010 [Page 16]
Internet-Draft Route Optimization Agent Extension October 2009
APPENDIX A: Future Extension and Use Case
A.1. Extension for Mobile Router in NEMO
This solution can also be applied in Network Mobility (NEMO)
extension, in which the Mobile Router provides mobility management
for IP node with only support for basic IP. The extension for NEMO is
as below:
MN1 HA1 HA2 MR MN2
| | | | |
=== MN1 attached to HA and MN2 attached to MR ===
a === MR provides mobility management for MN2 ===
=== MN1 has no idea about the capability of MN2 ===
| | | | |
| HoTI | | | |
b1 |------ > | HoTI | | |
b2 | |--------- >| HoTI | |
b3 | CoTI |------- >| |
c1 |------------------- >| HoT | |
d1 | | |< -------| |
| | | CoTI | |
c2 | | HoT |------- >| |
d2 | HoT |< ---------| | |
d3 |< -------| | CoT | |
e1 | CoT |< -------| |
e2 |< -------------------| | |
| | | |
| | | |
| BU | | |
f1 |------------------- >| BU | |
f2 | |------- >| |
| |Binding Ack |
g1 | Binding Ack |< -------| |
g2 |< -------------------| | |
| Traffic data | | |
-|------------------- >| Traffic | |
/ | |------- >| Traffic |
/ | | |------- >|
h | | | | Traffic |
\ | | Traffic |< -------|
\ | Traffic data |< -------| |
-|< -------------------| | |
| | | |
Figure 4 Agent extension in Route Optimization.
Cui Expires April 15, 2010 [Page 17]
Internet-Draft Route Optimization Agent Extension October 2009
In this extension, Mobile Router manages the mobility-related
signaling destined to the mobile node that is attached to its access
link. Mobile Router responds Care-of Test and Home Test message and
manages the binding cache on behalf of the MN.
A.2. Extension for IPv4/MIP4
TBD.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC3775] Johnson, D., Perkins, C., and J. Arkko, "Mobility Support
in IPv6", RFC 3775, June 2004.
[RFC5213] Sri, G., Kent, L., Vijay, D. Kuntal, C. and Basavaraj, P.,
"Proxy Mobile IPv6", RFC 5213, August 2008.
8.2. Informative References
[RFC1027] Smoot, C. and John Q., "Using ARP to Implement Transparent
Subnet Gateways", RFC1027, October 1987.
Author's Addresses
Xiangsong Cui
Huawei Technologies
KuiKe Bld., No.9 Xinxi Rd.,
Shang-Di Information Industry Base,
Hai-Dian District, Beijing, P.R. China, 100085
Email: Xiangsong.Cui@huawei.com
Cui Expires April 15, 2010 [Page 18]
| PAFTECH AB 2003-2026 | 2026-04-24 08:02:09 |