draft-ietf-udlr-lltunnel-03.txt   draft-ietf-udlr-lltunnel-04.txt 
Network Working Group E. Duros Network Working Group E. Duros
Internet-Draft W. Dabbous Internet-Draft W. Dabbous
Feb 2000 INRIA Sophia-Antipolis April 2000 INRIA Sophia-Antipolis
H. Izumiyama H. Izumiyama
N. Fujii N. Fujii
WIDE WIDE
Y. Zhang Y. Zhang
HRL HRL
A Link Layer Tunneling Mechanism for Unidirectional Links A Link Layer Tunneling Mechanism for Unidirectional Links
<draft-ietf-udlr-lltunnel-03.txt> <draft-ietf-udlr-lltunnel-04.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is in full conformance with This document is an Internet-Draft and is in full conformance with
all provisions of Section 10 of RFC2026. all provisions of Section 10 of RFC2026.
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
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 39 skipping to change at page 1, line 39
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt http://www.ietf.org/ietf/1id-abstracts.txt
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
A version of this draft document is intended for submission to the A version of this draft document is intended for submission to the
RFC editor as a Proposed Standard for the Internet Community. RFC editor as a Proposed Standard for the Internet Community.
Note to the RFC editor
Please replace all references to rfcXXXX with references to the new
GRE specification when it is published as Proposed Standard. It
currently exists as <draft-meyer-gre-update-03.txt>. The entry in the
"References" section may also need updating at this time.
Abstract Abstract
This document describes a mechanism to emulate bidirectional This document describes a mechanism to emulate bidirectional
connectivity between nodes that are directly connected by a connectivity between nodes that are directly connected by a
unidirectional link. The "receiver" uses a link layer tunneling unidirectional link. The "receiver" uses a link layer tunneling
mechanism to forward datagrams to "feeds" over a separate mechanism to forward datagrams to "feeds" over a separate
bidirectional IP network. As it is implemented at the link layer, bidirectional IP network. As it is implemented at the link layer,
protocols in addition to IP may also be supported by this mechanism. protocols in addition to IP may also be supported by this mechanism.
1. Introduction 1. Introduction
skipping to change at page 2, line 37 skipping to change at page 2, line 28
The tunneling mechanism requires that all nodes have an additional The tunneling mechanism requires that all nodes have an additional
interface to an IP interconnected infrastructure. interface to an IP interconnected infrastructure.
The tunneling mechanism is implemented at the link layer of the The tunneling mechanism is implemented at the link layer of the
interface of every node connected to the unidirectional link. The aim interface of every node connected to the unidirectional link. The aim
is to hide from higher layers, i.e. the network layer and above, the is to hide from higher layers, i.e. the network layer and above, the
unidirectional nature of the link. The tunneling mechanism also unidirectional nature of the link. The tunneling mechanism also
includes an automatic tunnel configuration protocol that allows nodes includes an automatic tunnel configuration protocol that allows nodes
to come up/down at any time. to come up/down at any time.
Generic Routing Encapsulation [rfcXXXX] is suggested as the tunneling Generic Routing Encapsulation [rfc2784] is suggested as the tunneling
mechanism as it provides a means for carrying IP, ARP datagrams, and mechanism as it provides a means for carrying IP, ARP datagrams, and
any other layer-3 protocol between nodes. any other layer-3 protocol between nodes.
The tunneling mechanism described in this document was discussed and The tunneling mechanism described in this document was discussed and
agreed upon by the UDLR working group. agreed upon by the UDLR working group.
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 [rfc2119].
2. Terminology 2. Terminology
Unidirectional link (UDL): A one way transmission link, e.g. a Unidirectional link (UDL): A one way transmission link, e.g. a
broadcast satellite link. broadcast satellite link.
Receiver: A router that has receive-only connectivity to a UDL. Receiver: A router or a host that has receive-only connectivity to a
UDL.
Send-only feed: A router that has send-only connectivity to a UDL. Send-only feed: A router that has send-only connectivity to a UDL.
Receive capable feed: A router that has send-and-receive connectivity Receive capable feed: A router that has send-and-receive connectivity
to a UDL. to a UDL.
Feed: A send-only or a receive capable feed. Feed: A send-only or a receive capable feed.
Node: A receiver or a feed. Node: A receiver or a feed.
skipping to change at page 3, line 28 skipping to change at page 3, line 23
receivers can only receive data from it. Receive capable feeds have receivers can only receive data from it. Receive capable feeds have
both send and receive capabilities. both send and receive capabilities.
This mechanism has been designed to work with any topology with any This mechanism has been designed to work with any topology with any
number of receivers and one or more feeds. However, it is expected number of receivers and one or more feeds. However, it is expected
that the number of feeds will be small. In particular, the special that the number of feeds will be small. In particular, the special
case of a single send-only feed and multiple receivers is among the case of a single send-only feed and multiple receivers is among the
topologies supported. topologies supported.
A receiver has several interfaces, a receive-only interface and one A receiver has several interfaces, a receive-only interface and one
or more additional bidirectional communication interfaces. A receiver or more additional bidirectional communication interfaces.
MUST be a router.
A feed has several interfaces, a send-only or a send-and-receive A feed has several interfaces, a send-only or a send-and-receive
capable interface connected to the unidirectional link and one or capable interface connected to the unidirectional link and one or
more additional bidirectional communication interfaces. A feed MUST more additional bidirectional communication interfaces. A feed MUST
be a router. be a router.
Tunnels are constructed between the bidirectional interfaces of Tunnels are constructed between the bidirectional interfaces of
nodes, so these interfaces must be interconnected by an IP nodes, so these interfaces must be interconnected by an IP
infrastructure. In this document we assume that that infrastructure infrastructure. In this document we assume that that infrastructure
is the Internet. is the Internet.
skipping to change at page 5, line 15 skipping to change at page 4, line 44
Basically, for outgoing datagrams, the network layer selects the Basically, for outgoing datagrams, the network layer selects the
correct first hop on the connected network according to a routing correct first hop on the connected network according to a routing
table and passes the packet(s) to the appropriate link layer driver. table and passes the packet(s) to the appropriate link layer driver.
Referring to Figure 1, Recv 1 and Feed 1 belong to the same network. Referring to Figure 1, Recv 1 and Feed 1 belong to the same network.
However, if Recv 1 initiates a 'ping f1u', it cannot get a response However, if Recv 1 initiates a 'ping f1u', it cannot get a response
from Feed 1. The network layer of Recv 1 delivers the packet to the from Feed 1. The network layer of Recv 1 delivers the packet to the
driver of the receive-only interface, which obviously cannot send it driver of the receive-only interface, which obviously cannot send it
to the feed. to the feed.
Most protocols in the Internet assume that links are bidirectional. Many protocols in the Internet assume that links are bidirectional.
In particular, routing protocols used by directly connected routers In particular, routing protocols used by directly connected routers
no longer behave properly in the presence of a unidirectional link. no longer behave properly in the presence of a unidirectional link.
5. Emulating a broadcast bidirectional network 5. Emulating a broadcast bidirectional network
The simplest solution is to emulate a broadcast capable link layer The simplest solution is to emulate a broadcast capable link layer
network. This will allow the immediate deployment of existing higher network. This will allow the immediate deployment of existing higher
level protocols without change. Though other network structures, such level protocols without change. Though other network structures, such
as NBMA, could also be emulated, a broadcast network is more as NBMA, could also be emulated, a broadcast network is more
generally useful. Though a layer 3 network could be emulated, a link generally useful. Though a layer 3 network could be emulated, a link
layer network allows the immediate use of any other network layer layer network allows the immediate use of any other network layer
protocols, and most particularly allows the immediate use of ARP. protocols, and most particularly allows the immediate use of ARP.
A link layer (LL) tunneling mechanism which emulates bidirectional A link layer (LL) tunneling mechanism which emulates bidirectional
connectivity in the presence of a unidirectional link will be connectivity in the presence of a unidirectional link will be
skipping to change at page 13, line 7 skipping to change at page 12, line 7
0 = Send-only feed 0 = Send-only feed
1 = Receive-capable feed 1 = Receive-capable feed
IP Vers (4 bit unsigned integer): IP protocol version of the feed IP Vers (4 bit unsigned integer): IP protocol version of the feed
bidirectional IP addresses (FBIP): bidirectional IP addresses (FBIP):
4 = IP version 4 4 = IP version 4
6 = IP version 6 6 = IP version 6
Tunnel Type (8 bit unsigned integer): tunneling protocol supported by Tunnel Type (8 bit unsigned integer): tunneling protocol supported by
the feed; receivers MUST use this form of tunnel encapsulation when the feed; receivers MUST use this form of tunnel encapsulation when
tunneling to the feed. tunneling to the feed.
47 = GRE [rfcXXXX] (recommended) 47 = GRE [rfc2784] (recommended)
Other values may be used, but their interpretation is not specified Other values may be used, but their interpretation is not specified
here. here.
Nb of FBIP (8 bit unsigned integer): Number of bidirectional IP feed Nb of FBIP (8 bit unsigned integer): Number of bidirectional IP feed
addresses which are enumerated in the HELLO message addresses which are enumerated in the HELLO message
reserved (8 bits): Reserved/unused field, MUST be zero. reserved (8 bits): Reserved/unused field, MUST be zero.
Feed BDL IP addr (32 or 128 bits). The bidirectional IP address feed Feed BDL IP addr (32 or 128 bits). The bidirectional IP address feed
is the IP address of a feed bidirectional interface (tunnel end- is the IP address of a feed bidirectional interface (tunnel end-
skipping to change at page 14, line 50 skipping to change at page 13, line 50
- JOIN: - JOIN:
The process verifies if the address FUIP already belongs to the The process verifies if the address FUIP already belongs to the
list of active feeds. list of active feeds.
If it does not, a new entry, for feed FUIP, is created and added If it does not, a new entry, for feed FUIP, is created and added
to the list of active feeds. The number of feed bidirectional IP to the list of active feeds. The number of feed bidirectional IP
addresses to read is deduced from the 'Nb of FBID' field. These addresses to read is deduced from the 'Nb of FBID' field. These
tunnel end-points (FBIP1,...,FBIPn) can then be added to the new tunnel end-points (FBIP1,...,FBIPn) can then be added to the new
entry. The tunnel type and Seq values are also taken from the entry. The tunnel Type and Sequence values are also taken from the
HELLO packet and recorded in the new entry. A timer set to HELLO packet and recorded in the new entry. A timer set to
HELLO_LEAVE is associated with this entry. HELLO_LEAVE is associated with this entry.
If it does, the sequence number is compared to the sequence number If it does, the sequence number is compared to the sequence number
contained in the previous HELLO packet sent by this feed. If they contained in the previous HELLO packet sent by this feed. If they
are equal, the timer associated with this entry is reset to are equal, the timer associated with this entry is reset to
HELLO_LEAVE. Otherwise all the information corresponding to FUIP HELLO_LEAVE. Otherwise all the information corresponding to FUIP
is set to the values from the HELLO packet. is set to the values from the HELLO packet.
Referring to Figure 1 in Section 3, both receivers (recv 1 and Referring to Figure 1 in Section 3, both receivers (recv 1 and
skipping to change at page 17, line 29 skipping to change at page 16, line 29
hardware (or the driver) of the receiver can then filter the incoming hardware (or the driver) of the receiver can then filter the incoming
packets sent over the unidirectional links without any assumption packets sent over the unidirectional links without any assumption
about the encapsulated data type. about the encapsulated data type.
In a similar way, a receiver should be capable of sending unicast and In a similar way, a receiver should be capable of sending unicast and
broadcast MAC packets via its tunnels. Link layer packets are broadcast MAC packets via its tunnels. Link layer packets are
encapsulated. As a result, after decapsulating an incoming packet, encapsulated. As a result, after decapsulating an incoming packet,
the feed can perform link layer filtering as if the data came the feed can perform link layer filtering as if the data came
directly from the unidirectional link (See Figure 2). directly from the unidirectional link (See Figure 2).
Generic Routing Encapsulation (GRE) [rfcXXXX] suits our requirements Generic Routing Encapsulation (GRE) [rfc2784] suits our requirements
because it specifies a protocol for encapsulating arbitrary packets, because it specifies a protocol for encapsulating arbitrary packets,
and allows use of IP as the delivery protocol. and allows use of IP as the delivery protocol.
Other encapsulations are possible, such as directly encapsulating a Other encapsulations are possible, such as directly encapsulating a
MAC level packet within an IP datagram. MAC level packet within an IP datagram.
The feed's local administrator decides what encapsulation it will The feed's local administrator decides what encapsulation it will
demand that receivers use, and sets the tunnel type field in the demand that receivers use, and sets the tunnel type field in the
HELLO message appropriately. The value 47 (decimal) indicates GRE. HELLO message appropriately. The value 47 (decimal) indicates GRE.
Other values can be used, but their interpretation must be agreed Other values can be used, but their interpretation must be agreed
upon between feeds and receivers. Such usage is not defined here. upon between feeds and receivers. Such usage is not defined here.
8.1. Generic Routing Encapsulation on the receiver 8.1. Generic Routing Encapsulation on the receiver
A GRE packet is composed of a header in which a type field specifies A GRE packet is composed of a header in which a type field specifies
the encapsulated protocol (ARP, IP, IPX, etc.). See [rfcXXXX] for the encapsulated protocol (ARP, IP, IPX, etc.). See [rfc2784] for
details about the encapsulation. In our case, only support for the details about the encapsulation. In our case, only support for the
MAC addressing scheme of the unidirectional link MUST be implemented. MAC addressing scheme of the unidirectional link MUST be implemented.
A packet tunneled with a GRE encapsulation has the following format: A packet tunneled with a GRE encapsulation has the following format:
the delivery header is an IP header whose destination is the tunnel the delivery header is an IP header whose destination is the tunnel
end-point (FBIP), followed by a GRE header specifying the link layer end-point (FBIP), followed by a GRE header specifying the link layer
type of the unidirectional link. Figure 4 presents the entire type of the unidirectional link. Figure 4 presents the entire
encapsulated packet. encapsulated packet.
---------------------------------------- ----------------------------------------
skipping to change at page 19, line 36 skipping to change at page 18, line 36
transformation. transformation.
9.2. Routing protocols 9.2. Routing protocols
The link layer tunneling mechanism hides from the network and higher The link layer tunneling mechanism hides from the network and higher
layers the fact that feeds and receivers are connected by a layers the fact that feeds and receivers are connected by a
unidirectional link. Communication is bidirectional, but asymmetric unidirectional link. Communication is bidirectional, but asymmetric
in bandwidths and delays. in bandwidths and delays.
In order to incorporate unidirectional links in the Internet, feeds In order to incorporate unidirectional links in the Internet, feeds
and receivers must run routing protocols. These protocols will work and receivers might have to run routing protocols in some topologies.
fine because the tunneling mechanism results in bidirectional These protocols will work fine because the tunneling mechanism
connectivity between all feeds and receivers. Thus routing messages results in bidirectional connectivity between all feeds and
can be exchanged as on any bidirectional network. receivers. Thus routing messages can be exchanged as on any
bidirectional network.
The tunneling mechanism allows any IP traffic, not just routing The tunneling mechanism allows any IP traffic, not just routing
protocol messages, to be forwarded between receivers and feeds. protocol messages, to be forwarded between receivers and feeds.
Receivers can route datagrams on the Internet using the most suitable Receivers can route datagrams on the Internet using the most suitable
feed or receiver as a next hop. Administrators may want to set the feed or receiver as a next hop. Administrators may want to set the
metrics used by their routing protocols in order to reflect in metrics used by their routing protocols in order to reflect in
routing tables the asymmetric characteristics of the link, and thus routing tables the asymmetric characteristics of the link, and thus
direct traffic over appropriate paths. direct traffic over appropriate paths.
Feeds and receivers can run multicast routing daemons and therefore Feeds and receivers may implement multicast routing and therefore
dynamic multicast routing can be performed over the unidirectional dynamic multicast routing can be performed over the unidirectional
link. However issues related to multicast routing (e.g. protocol link. However issues related to multicast routing (e.g. protocol
configuration) are not addressed in this document. configuration) are not addressed in this document.
9.3. Scalability 9.3. Scalability
The DTCP protocol does not generate a lot of traffic whatever the The DTCP protocol does not generate a lot of traffic whatever the
number of nodes. The problem with a large number of nodes is not number of nodes. The problem with a large number of nodes is not
related to this protocol but to more general issues such as the related to this protocol but to more general issues such as the
maximum number of nodes which can be connected to any link. This is maximum number of nodes which can be connected to any link. This is
out of scope of this document. out of scope of this document.
10. Security Considerations 10. Security Considerations
Confidentiality and integrity concerns may arise from the lower layer Security in a network using the link layer tunneling mechanism should
technologies employed, e.g. if the unidirectional link is a satellite be relatively similar to security in a normal IPv4 network. However,
link and the backchannel is the public internet. Since this protocol as the link layer tunneling mechanism uses GRE[rfc2784], it is
aims to support a link layer, link layer confidentiality and expected that GRE authentication mechanism combined with a specific
integrity mechanisms may be appropriate. In the case of the link layer security mechanism on the back-channel will help to
backchannel only, IPSEC [rfc2401] may provide appropriate services. enhance security in a unidirectional link environment.
Theft of service and denial of service attacks become possible to In order to prevent unauthorised users from providing fake routing
systems which can discover the feed tunnel end-point addresses and information, routing protocols running on top of the link layer
can direct packets to them. It may be appropriate for feeds to tunneling mechanism MUST use authentication mechanisms when
authenticate tunnel sources, i.e. receivers. Feeds can validate the available.
IP source addresses of tunneled packets, but this can be easily
spoofed. MAC layer filtering may also be possible. Adequate
protection can be ensured using IPSEC [rfc2401] AH [rfc2402] to
provide strong authentication of tunnel sources. For reasons of
scalability, no particular mechanism is specified in this protocol.
11. Acknowledgments 11. Acknowledgments
We would like to thank Tim Gleeson (Cisco Japan) for his valuable We would like to thank Tim Gleeson (Cisco Japan) for his valuable
editing and technical input during the finalization phase of the editing and technical input during the finalization phase of the
document. document.
We would like to thank Patrick Cipiere (INRIA) for his valuable input We would like to thank Patrick Cipiere (INRIA) for his valuable input
concerning the design of the encapsulation mechanism. concerning the design of the encapsulation mechanism.
We would like also to thank for their participation: Akihiro Tosaka We would like also to thank for their participation: Akihiro Tosaka
(IMD), Akira Kato (Tokyo Univ.), Hitoshi Asaeda (IBM/ITS), Hiromi (IMD), Akira Kato (Tokyo Univ.), Hitoshi Asaeda (IBM/ITS), Hiromi
Komatsu (JSAT), Hiroyuki Kusumoto (Keio Univ.), Kazuhiro Hara (Sony), Komatsu (JSAT), Hiroyuki Kusumoto (Keio Univ.), Kazuhiro Hara (Sony),
Kenji Fujisawa (Sony), Mikiyo Nishida (Keio Univ.), Noritoshi Demizu Kenji Fujisawa (Sony), Mikiyo Nishida (Keio Univ.), Noritoshi Demizu
(Sony csl), Jun Murai (Keio Univ.), Jun Takei (JSAT) and Harri (Sony CSL), Jun Murai (Keio Univ.), Jun Takei (JSAT) and Harri
Hakulinen (Nokia). Hakulinen (Nokia).
A. Conformance and interoperability A. Conformance and interoperability
This document describes a mechanism to emulate bidirectional This document describes a mechanism to emulate bidirectional
connectivity between nodes that are directly connected by a connectivity between nodes that are directly connected by a
unidirectional link. Applicability over a variety of equipment and unidirectional link. Applicability over a variety of equipment and
environments is ensured by allowing a choice of several key system environments is ensured by allowing a choice of several key system
parameters. parameters.
skipping to change at page 21, line 33 skipping to change at page 20, line 28
GRE encapsulation for the tunnels." GRE encapsulation for the tunnels."
References References
[rfc826] 'An Ethernet Address Resolution Protocol', David C. Plummer, [rfc826] 'An Ethernet Address Resolution Protocol', David C. Plummer,
November 1982. November 1982.
[rfc1112] 'Host Extensions for IP Multicasting', S. Deering, Stanford [rfc1112] 'Host Extensions for IP Multicasting', S. Deering, Stanford
University, August 1989 University, August 1989
[rfc2119] 'Key words for use in RFCs to Indicate Requirement Levels',
[rfc2401] 'Security Architecture for the Internet Protocol', S. Kent, [rfc2401] 'Security Architecture for the Internet Protocol', S. Kent,
BBN Corp, R. Atkinson, @Home Network BBN Corp, R. Atkinson, @Home Network
[rfc2402] 'IP Authentication Header', S. Kent, BBN Corp, R. Atkinson, [rfc2402] 'IP Authentication Header', S. Kent, BBN Corp, R. Atkinson,
@Home Network @Home Network
[rfc2453] 'RIP Version 2', G. Malkin, Bay Networks, November 1998 [rfc2453] 'RIP Version 2', G. Malkin, Bay Networks, November 1998
[rfcXXXX] 'Generic Routing Encapsulation (GRE)', D. Farinacci, T. Li, [rfc2784] 'Generic Routing Encapsulation (GRE)', D. Farinacci, T. Li,
S. Hanks, D. Meyer, P. Traina. Procket Networks, S. Hanks, Enron Communications, D. Meyer,
Author's address Author's address
Emmanuel Duros Emmanuel Duros
INRIA Sophia Antipolis INRIA Sophia Antipolis
2004, Route des Lucioles BP 93 2004, Route des Lucioles BP 93
06902 Sophia Antipolis 06902 Sophia Antipolis
France France
Phone : +33 4 92 38 79 42 Phone : +33 4 92 38 79 42
Fax : +33 4 92 38 79 78 Fax : +33 4 92 38 79 78
skipping to change at page 22, line 26 skipping to change at page 21, line 26
Walid Dabbous Walid Dabbous
INRIA Sophia Antipolis INRIA Sophia Antipolis
2004, Route des Lucioles BP 93 2004, Route des Lucioles BP 93
06902 Sophia Antipolis 06902 Sophia Antipolis
France France
Phone : +33 4 92 38 77 18 Phone : +33 4 92 38 77 18
Fax : +33 4 92 38 79 78 Fax : +33 4 92 38 79 78
Email : Walid.Dabbous@inria.fr Email : Walid.Dabbous@inria.fr
Hidetaka Izumiyama Hidetaka Izumiyama
Japan Satellite Systems Inc. JSAT Corporation
Toranomon 17 Mori Bldg.5F Toranomon 17 Mori Bldg.5F
1-26-5 Toranomon, Minato-ku 1-26-5 Toranomon, Minato-ku
Tokyo 105 Tokyo 105
Japan Japan
Voice : +81-3-5511-7568 Voice : +81-3-5511-7568
Fax : +81-3-5512-7181 Fax : +81-3-5512-7181
Email : izu@jcsat.co.jp Email : izu@jsat.net
Noboru Fujii Noboru Fujii
Sony Corporation Sony Corporation
2-10-14 Osaki, Shinagawa-ku 2-10-14 Osaki, Shinagawa-ku
Tokyo 141 Tokyo 141
Japan Japan
Voice : +81-3-3495-3092 Voice : +81-3-3495-3092
Fax : +81-3-3495-3527 Fax : +81-3-3495-3527
Email : fujii@dct.sony.co.jp Email : fujii@dct.sony.co.jp
 End of changes. 22 change blocks. 
44 lines changed or deleted 37 lines changed or added

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