One document matched: draft-irtf-dtnrg-ipnd-00.xml
<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd" [
<!ENTITY rfc1112 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.1112.xml'>
<!ENTITY rfc2119 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.2119.xml'>
<!ENTITY rfc3171 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3171.xml'>
<!ENTITY rfc3376 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3376.xml'>
<!ENTITY rfc3927 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3927.xml'>
<!ENTITY rfc3986 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.3986.xml'>
<!ENTITY rfc4838 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.4838.xml'>
<!ENTITY rfc5050 PUBLIC ''
'http://xml.resource.org/public/rfc/bibxml/reference.RFC.5050.xml'>
]>
<rfc category="exp" ipr="trust200902" docName="draft-irtf-dtnrg-ipnd-00">
<?xml-stylesheet type='text/xsl' href='rfc2629.xslt' ?>
<?rfc toc="yes" ?>
<?rfc symrefs="yes" ?>
<?rfc sortrefs="yes"?>
<?rfc iprnotified="no" ?>
<?rfc strict="no" ?>
<!--
$Id: draft-irtf-dtnrg-ipnd-00.xml 3179 2009-07-17 13:34:17Z dellard $
$Author: dellard $
$Date: 2009-07-17 09:34:17 -0400 (Fri, 17 Jul 2009) $
-->
<front>
<title abbrev="DTN-IPND">DTN IP Neighbor Discovery (IPND)</title>
<author initials='R.' surname="Beverly" fullname='Robert Beverly'>
<organization abbrev="BBN">
BBN Technologies
</organization>
<address>
<postal>
<street>10 Moulton St.</street>
<city>Cambridge</city> <region>MA</region>
<code>02138</code>
<country>US</country>
</postal>
<email>rbeverly@bbn.com</email>
</address>
</author>
<author initials='D.' surname="Ellard" fullname='Daniel Ellard'>
<organization abbrev="BBN">
BBN Technologies
</organization>
<address>
<postal>
<street>10 Moulton St.</street>
<city>Cambridge</city> <region>MA</region>
<code>02138</code>
<country>US</country>
</postal>
<email>dellard@bbn.com</email>
</address>
</author>
<date month="August" year="2009"/>
<abstract>
<t>
Disruption Tolerant Networking (DTN) IP Neighbor Discovery
(IPND), is a method for otherwise oblivious nodes to learn of the
existence, availability, and addresses of other DTN participants.
IPND both sends and listens for small IP UDP announcement
"beacons." Beacon messages are addressed to an IP unicast, multicast,
or broadcast destination to discover specified remote
neighbors, or unspecified local neighbors in the topology, e.g.
within wireless range. IPND beacons advertise neighbor
availability by including the DTN node's canonical endpoint
identifier. IPND beacons optionally include service availability
and parameters. In this way, neighbor discovery and service
discovery may be coupled or decoupled as required. Once
discovered, new neighbor pairs use advertised availabilities
to connect, exchange routing information, etc. This document
describes DTN IPND.
</t>
</abstract>
</front>
<middle>
<section title="Introduction">
<t>
Delay and Disruption Tolerant Networks (DTNs) <xref
target="RFC4838"/> make no presumptions about network topology,
routing, or availability. DTNs therefore attempt to provide
communication in challenged environments where, for instance,
contemporaneous end-to-end paths do not exist. Examples of such
DTNs arise is a variety of contexts including mobile social
networks, space communications, rural message delivery, military
networks, etc.
</t>
<t>
In many DTN scenarios, the identity and meeting
schedule of other participating nodes is not known in advance.
Therefore, an important primitive is Neighbor Discovery (ND), or
the ability to dynamically locate other DTN nodes. This document
specifies Internet Protocol Neighbor Discovery (IPND). In
contrast to link or physical layer discovery, IPND enables a
general form of neighbor discovery across a heterogeneous range
of links, as are often found in DTN networks. IPND is particularly
useful in mobile, ad-hoc DTN environments where meeting
opportunities are not known a priori and connections may appear
or disappear without warning. For example, two mobile nodes
might come into radio distance of each other, discover the new
connection, and move data along that connection before physically
disconnecting.
</t>
<t>
In addition to discovering neighbors, it is often valuable to
simultaneously discover services available from that neighbor.
Examples of DTN services include a neighbor's available
Convergence Layer Adapters (CLAs) and their parameters (e.g.
<xref target="TCPCLA"/>), available routers (e.g. <xref
target="PROPHET"/>), tunnels, etc. Newly discovered nodes will
then typically participate in bundle <xref target="RFC5050"/>
routing and delivery.
</t>
<t>
In other situations it is useful to decouple service
discovery from neighbor discovery for efficiency and generality.
For example, upon discovering a neighbor, a DTN node might
initiate a separate negotiation process to establish 1-hop
connectivity via a particular convergence layer, perform routing
setup, exchange availability information, etc.
</t>
<t>
IPND beacons thus optionally advertise a node's available
services while maintaining the ability to decouple node and
service discovery as necessary. This flexibility is important to
various DTN use scenarios where connection opportunities may be
limited (thus necessitating an atomic message for all
availability information), bandwidth might be scarce (thus
implying that service discovery should be an independent
negotiation to lower beacon overhead), or connections have very
large round-trip-times (service negotiation is therefore too
costly with respect to time).
</t>
<t>
DTN IPND is designed to be simple, efficient, and general.
</t>
<t>
Although this document describes a neighbor discovery protocol
in terms of IP, the principles and basic mechanisms used in this
protocol may also be expressed in terms of other datagram protocols.
</t>
<t>
The remainder of this document describes DTN IPND.
</t>
<section title="Terminology">
<t>
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 <xref target="RFC2119"/>.
</t>
<t>
The following terminology is used for describing DTN IPND.
</t>
<t>
<list>
<t>Bundle: A PDU as defined in <xref target="RFC5050"/>.</t>
<t>Node: A DTN entity in the network that receives and
processes bundles.</t>
<t>Beacon message: An IPND-specific message, defined in
this document, used to announce the presence of a
DTN node and parameters with which to connect to that
node.</t>
<t>Convergence layer adapter: A convergence layer adapter
(CLA) sends and receives bundles on behalf of a node by
providing the conversion between bundles and a transport
protocol such as TCP or UDP.</t>
</list>
</t>
</section>
</section>
<section title="Protocol Description">
<t>
Nodes use DTN IPND beacons, small UDP messages in the IP
underlay, to advertise presence. Similarly, IPND beacons
received from other nodes serve to detect the availability of DTN
neighbors. Nodes SHOULD both send and receive beacons. These
beacon messages, detailed in <xref target="beacons"/>, may be
sent either as IP unicast, multicast, or broadcast UDP packets.
The beacon message content is agnostic to the underlying
transport mode.
</t>
<t>
Broadcast beacons are designed to reach unknown neighbors in
neighborhoods within the local network broadcast domain.
Multicast <xref target="RFC1112"/> beacons extend the scope of
beacon dissemination to potentially include multiple networks
across routed boundaries. On broadcast media such as Ethernet or
wireless, multicast and broadcast beacons are sent as link-layer
broadcast messages.
</t>
<t>
Broadcast and multicast discovery are described in <xref
target="multicast"/>. In contrast, unicast beacons are sent only
to explicitly known and enumerated neighbors as described in
<xref target="unicast"/>.
</t>
<t>
Upon discovering a neighbor, IPND can establish a connection
to the new neighbor via an IP-based Convergence Layer Adapter
(CLA), for example the TCP <xref target="TCPCLA"/> or UDP <xref
target="UDPCLA"/> CLA. The CLA then negotiates the connection
per its individual specification and installs the appropriate
next-hop routing information in the BPA.
</t>
<section title="Unknown Neighbors" anchor="multicast">
<t>
In the general case, the IP addresses of potential
neighbors are not known in advance. To discover unknown
neighbors, IPND beacon messages are sent as IP packets with
either multicast or broadcast destination addresses. IPND MUST
support multicast IP destination addresses <xref
target="RFC1112"/> and multicast IGMP group membership <xref
target="RFC3376"/>. IPND MAY support IP broadcast destinations.
IPND multicast addresses SHOULD be from the IANA assigned local
network control block 224.0.0/24 <xref target="RFC3171"/>. This
block of multicast addresses is intentionally scoped to the local
network to prevent dissemination to the wider Internet.
</t>
<t>
IPND MAY also use other multicast addresses as required, such as
multicast addresses from the IANA assigned Internetwork Control
Block <xref target="RFC3171"/>.
</t>
<t>
In all cases, IPND MUST support a configurable IP time-to-live
value for all beacon messages.
</t>
</section>
<section title="Enumerated Neighbors" anchor="unicast">
<t>
IPND SHOULD support unicast beacons. IPND is primarily
designed for discovery of nodes in the current broadcast or
multicast domain. However, some situations mandate discovery
across multiple Internet IP overlay hops. Across the wide-area
Internet, multicast or broadcast discovery is not feasible. In
such instances, the IP addresses of potential neighbors must be
explicitly enumerated. While the neighbor's address is therefore
known, the availability of that neighbor is not known. IPND thus
permits DTN nodes to discover available remote neighbors across
multiple IP overlay hops simply by enumerating their addresses.
</t>
<t>
Note that unicast discovery scales with the square of the
number of enumerated nodes, i.e. one beacon packet per enumerated
destination. Therefore, unicast discovery is intended for
relatively small numbers of neighbors.
</t>
</section>
<!-- TODO: say something about linkchar -->
<section title="Beacon Message Format" anchor="beacons">
<t>
<xref target="beaconmsg"/> depicts the format of beacon messages.
Note that IPND follows the DTN convention of using Self-Delimiting
Numeric Values (SDNVs) <xref target="SDNV"/> to represent
variable length integers (denoted by *). IPND MUST use UDP
checksums to ensure correctness.
</t>
<figure title="Beacon Message Format" anchor="beaconmsg">
<artwork type="drawing">
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Flags | Beacon Len (*) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| EID Len (*) | Canonical EID (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| |
/ Service Blocks (optional) /
| |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
The beacon message is comprised of the following fields:
<list style="symbols">
<t>Version: A 1-byte field indicating the version of IPND
that constructed this beacon. The present document
describes version 0x01 of IPND.</t>
<t>Flags: A 1-byte field indicating IPND processing flags.
Two flags are currently defined. 0x00 indicates that
no special processing should be performed on the beacon.
0x01
indicates that no length or local EID fields follow and
allows for very short, efficient beacons;
see <xref target="zero"/> for details.</t>
<t>Beacon Length: The byte length of the beacon inclusive of the entire
beacon message, but exclusive of IP or UDP headers.
The length field is an SDNV and is therefore variable
length. A two-octet length is shown for convenience of
representation.</t>
<t>EID Length: The byte length of the canonical EID contained
in the beacon. The EID length field is an SDNV and is
therefore variable length. A two-octet length is shown for
convenience of representation.</t>
<t>Canonical EID: The canonical end node identifier of the neighbor
advertised by the beacon message. The canonical EID is
variable length and represented as a Uniform Resource
Identifier <xref target="RFC3986"/>.</t>
<t>Service Blocks: Optional announced services in the beacon,
described in <xref target="services"/>.</t>
</list>
</t>
<section title="Services" anchor="services">
<t>
As described previously, beacon messages may optionally
include service availability information. The services are
intended to represent available CLAs, routers, etc., but are
sufficiently general to accommodate unanticipated services
provided by the advertising node.
</t>
<t>
For example, the source IP address of a received beacon
suffices to identify the remote node at the IP level. However,
the IP address alone does not inform other processes via which
transport mechanism (e.g. TCP or UDP) or via which transport port
the remote node is offering a connection. Similarly, nodes do
not know which routers (e.g. <xref target="PROPHET"/>) are
running on a remote node in order to inform bundle exchange.
</t>
<t>
Therefore, beacons may contain service blocks. An
end-node determines the length of the announced service blocks
as follows.
</t>
<t>
A node parses the beacon length and EID length SDNV
fields. Let v(b) represent the value of the beacon length and
v(e) represent the value of the EID length. The SDNV
representation of beacon and EID length is itself variable
length. Let l(b) represent the on-wire length of the beacon
length SDNV and l(e) represent the on-wire length of the EID
length SDNV. The total byte length of any option service blocks
is then:
</t>
<figure><artwork>
service block length = v(b) - 2 - l(b) - l(e) - v(e)
</artwork></figure>
<t>
The format of a service block is given in <xref
target="servicesmsg"/>.
</t>
<figure title="Service Block Format" anchor="servicesmsg">
<artwork type="drawing">
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Name Len (*) | Service Name (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Service Param Len (*) | Service Parameters (variable) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
</artwork>
</figure>
<t>
A service block is comprised of the following fields:
<list style="symbols">
<t>Service Name Length: The length of the advertised service
name or description. The service name length is an SDNV and
is therefore variable length. The service name MUST
have non-zero length.</t>
<t>Service Name: An identifying name for the service, e.g.
"UDPCLA."</t>
<t>Service Parameters Length: The length of service-specific
parameters that accompany this announcement. The service
parameters length is an SDNV and is therefore variable
length.</t>
<t>Service Parameters: Service-specific parameters required
to use the service, e.g. "port=4453."</t>
</list>
</t>
</section>
<section title="Zero-length EID Beacons" anchor="zero">
<t>
A beacon with a 0x01 flag has special meaning and
indicates a "zero-length EID." IPND MUST support zero-length EID
beacons. Neither the beacon length, canonical EID, nor any
service block fields are present in these beacons, and the total
length of the beacon is therefore only two octets. Nodes SHALL
assume that the canonical EID of a zero-length EID is the
dotted-quad URI representation of the beacon's source IP address.
</t>
<t>
Zero-length beacons imply that any remote node receiving
the beacon may connect via the source IP address of the beacon,
using the UDP CLA on UDP port 4556. This optimization is made
for efficiency and ease of implementation reasons, for instance
in constrained scenarios where devices are unwilling or unable to
implement SDNV and a default connection procedure suffices.
</t>
</section>
</section>
<!--
RB: COMMENT OUT THE FOLLOWING AS THEY'RE MOST IMPLEMENTATION
DETAILS THAT DON'T NEED TO BE NEGOTIATED OR INTERPRETED
BETWEEN NEIGHBORS AT THIS TIME.
-->
<!--
<section title="Parameters" anchor="params">
<t>
It is RECOMMENDED that implementations of IPND provide the
following configurable parameters:
</t>
<t>Parameters:
<list style="hanging" hangIndent="5">
<t hangText="BeaconAddress:">IPv4 address string specifying the beacon
address destination. As described previously, the beacon address
may be either IP unicast, multicast, or broadcast.
</t>
<t hangText="BeaconIPTTL:">Time-to-live specifying the beacon
IPv4 TTL value.
<vspace blankLines="1" />
Unless beacon messages are intended to be disseminated beyond the local
link, the BeaconIPTTL should always be 1.
</t>
<t hangText="BeaconPeriod:">Integer wall clock time between
sending periodic beacon messages. The inter-beacon delay granularity
SHOULD be at least 1 millisecond.
</t>
<t hangText="NeighborRecvTimeout:">The neighbor receive
timeout period. A minimum integer wall clock time
that MAY pass without receiving a beacon before declaring an existing
neighbor unreachable. The neighbor receive timeout SHOULD be at
least millisecond granularity.
</t>
</list>
</t>
<t>
The BeaconPeriod and NeighborRecvTimeout parameters should be
chosen to reflect the expected properties of the network connection
between two nodes that discover each other via this protocol and the
requirements of the users of the network. A typical BeaconPeriod for
most purposes would be on the order of several seconds, and a typical
NeighborRecvTimeout is a multiple of the BeaconPeriod.
</t>
</section>
-->
<section title="Connection Establishment">
<t>
Once IPND discovers a new node and the connection
parameters, it may initiate the connection. The exact means by
which IPND communicates with the CLAs is implementation
dependent. The specified CLA should establish the connection
using the methods and conventions defined for that CLA.
</t>
<t>
Note that two nodes may discover each other simultaneously
and attempt to initiate connections simultaneously. In
instances of uni-directional CLAs, IPND must provide uni-directional
discovery. However, in general, bi-direction CLAs such as
TCP should attempt to form a single connection rather than two
separate connections. IPND does not discern between uni and
bi-directional connections or address potential race conditions
in bilateral connection establishment.
</t>
</section>
<section title="Disconnection">
<t>
Note that IPND SHOULD maintain state over all existing neighbors
in order to prevent CLAs from needlessly attempting to establish
connections between nodes that are already connected. To maintain
the current neighbor set, IPND removes stale neighbors after the
defined neighbor receive timeout period elapses without receiving
any beacon messages from a particular neighbor.
</t>
<t>
Upon detecting a neighbor that is no longer available, IPND
MAY provide hints to the CLA that the neighbor is gone. Note
that some CLAs themselves provide keepalive-type functionality
and therefore IPND is not necessarily required to detect down
neighbors. However, placing both discovery and availability
information in IPND provides a single, coherent point in the
system design to maintain neighbor information.
</t>
</section>
</section>
<section title="Relation to Other Discovery Protocols">
<t>
A variety of discovery protocols exist in other contexts
and domains. These discovery protocols include the ability to
discover available neighbors and services. For example, the IETF
zero configuration working group <xref target="RFC3927"/>, the
bonjour protocol <xref target="BONJOUR"/>, and the OLSR discovery
protocol <xref target="NHDP"/> all provide similar functionality.
</t>
<t>
Other rendezvous mechanisms are possible that allow a node to
find a neighbor of a particular type or with particular
properties. For example, the Domain Name System (DNS) or
Distributed Hash Tables (DHTs) could be used to find a neighbor
that provides an inter-planetary gateway. Such advanced
rendezvous schemes are beyond the scope of this document.
</t>
<t>
In contrast, DTN-IPND is designed to be DTN-specific,
efficient, and extremely lightweight. For instance, DTN-IPND is
capable of supporting arbitrary length DTN EIDs, and includes CLA
information in order to maximize the utility of each beacon
message without requiring multiple round-trip times in order to
perform complex protocol negotiation.
</t>
<t>
While DTN-IPND MAY be used in non-DTN environments, its use is
RECOMMENDED only in DTNs.
</t>
</section>
<section title="Implementation Experience">
<t>
BBN Technologies has implemented and deployed DTN IPND as part of
the SPINDLE <xref target="SPINDLE"/> project.
</t>
</section>
<section title="Security Considerations">
<t>
Neighbor discovery may be perceived as an impediment to
security because it advertises a potential target for attacks.
Discovering the existence of a particular node is orthogonal to
securing the services of that node. Nodes that desire or require
higher-levels of security SHOULD disable the broadcast IPND
beacons and rely instead on static neighbor configuration.
</t>
<t>
Further, neighbor discovery represents a potential source of
network congestion and contention. Therefore, careful
consideration should be made to the frequency and TTL scope of
beacons when setting implementation-specific parameters,
particularly when a setting affects larger regions of the
network.
</t>
</section>
<section title="IANA Considerations">
<t>
None at this time.
</t>
</section>
</middle>
<back>
<references title="Normative References">
&rfc2119;
&rfc3986;
</references>
<references title="Informative References">
&rfc1112;
&rfc3171;
&rfc3376;
&rfc3927;
&rfc4838;
&rfc5050;
<reference anchor="PROPHET">
<front>
<title>Probabilistic Routing Protocol for Intermittently
Connected Networks
</title>
<author initials="A." surname="Lindgren">
<organization abbrev="Lulea">
Lulea University of Technology
</organization>
</author>
<author initials="A." surname="Doria">
<organization abbrev="Lulea">
Lulea University of Technology
</organization>
</author>
<date month="Mar" year="2006" />
</front>
<format type='HTML'
target='http://www.dtnrg.org/docs/specs/draft-lindgren-dtnrg-prophet-02.txt' />
</reference>
<reference anchor="TCPCLA">
<front>
<title>Delay Tolerant Networking TCP Convergence Layer Protocol
</title>
<author initials="M." surname="Demmer">
<organization abbrev="UCB">
UC Berkeley
</organization>
</author>
<author initials="J." surname="Ott">
<organization abbrev="HELFI">
Helsinki University of Technology
</organization>
</author>
<date month="Nov" year="2008" />
</front>
<format type='HTML'
target='http://tools.ietf.org/id/draft-irtf-dtnrg-tcp-clayer-02.txt' />
</reference>
<reference anchor="UDPCLA">
<front>
<title>UDP Convergence Layers for the DTN Bundle
and LTP Protocols
</title>
<author initials="H." surname="Kruse">
<organization abbrev="OhioU">
Ohio University
</organization>
</author>
<author initials="S." surname="Ostermann">
<organization abbrev="OhioU">
Ohio University
</organization>
</author>
<date month="Nov" year="2008" />
</front>
<format type='HTML'
target='http://tools.ietf.org/id/draft-irtf-dtnrg-udp-clayer-00.txt' />
</reference>
<reference anchor="SDNV">
<front>
<title>Using Self-Delimiting Numeric Values in
Protocols
</title>
<author initials="W." surname="Eddy">
<organization abbrev="Verizon">
Verizon
</organization>
</author>
<date month="Jan" year="2009" />
</front>
<format type='HTML'
target='http://tools.ietf.org/id/draft-irtf-dtnrg-sdnv-01.txt' />
</reference>
<reference anchor="NHDP">
<front>
<title>MANET Neighborhood Discovery Protocol (NHDP)
</title>
<author initials="T." surname="Clausen">
<organization abbrev="lix">
LIX, Ecole Polytechnique
</organization>
</author>
<author initials="C." surname="Dearlove">
<organization abbrev="BAE">
BAE Systems ATC
</organization>
</author>
<author initials="J." surname="Dean">
<organization abbrev="NRL">
Naval Research Laboratory
</organization>
</author>
<date month="Mar" year="2009" />
</front>
<format type='HTML'
target='http://tools.ietf.org/id/draft-ietf-manet-nhdp-09.txt' />
</reference>
<reference anchor="SPINDLE">
<front>
<title>Survivable Policy-Influenced Networking:
Disruption-tolerance through Learning and Evolution
</title>
<author initials="R." surname="Krishnan">
<organization abbrev="BBN">
BBN Technologies
</organization>
</author>
<date month="Oct" year="2006" />
</front>
<format type='HTML'
target='http://www.ir.bbn.com/projects/spindle' />
</reference>
<reference anchor="BONJOUR">
<front>
<title>Bonjour
</title>
<author initials="S." surname="Cheshire">
<organization abbrev="Apple">
Apple, Inc.
</organization>
</author>
<date month="Apr" year="2005" />
</front>
<format type='HTML'
target='http://www.apple.com/bonjour' />
</reference>
</references>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 10:43:13 |