[Search] [txt|pdf|bibtex] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01                                                         
Network Working Group                                For list of authors
Internet-Draft                                      See Authors' section
July 2003 Expires december 2003

                       Experiments with RFC 3077


Status of this Memo

   This document is an Internet-Draft and is subject to all provisions
   of Section 10 of RFC2026.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groupsmay 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

   The list of Internet-Draft Shadow Directories can be accessed at


   In March 2001, [RFC 3077] was published and describes a protocol
   which allows to integrate unidirectional links in the Internet. Since
   then, a number of experimentations and deployements using this
   protocol have been led. This document presents various protocols,
   e.g. layer 2 and layer 3 protocols, which have been commonly used
   over [RFC 3077] in a satellite environment. This document raises
   issues for each of these protocols.

Table of Contents

   1.   Characteristics of Uni-Directional Links .................... X
   1.1. Characteristics of UDLR networks ............................ X
   1.1.1. Asymmetric routing paths .................................. X
   1.1.3. Forward link capacity ..................................... X

Authors                                                         [Page 1]

Internet Draft          Experiments with RFC 3077              July 2003

   1.1.3. Asymmetric link capacity .................................. X
   1.1.4. Asymmetric loss environment ............................... X
   1.1.5. Flat networks ............................................. X
   1.1.6. Subnetwork round trip delay ............................... X
   2.   Description of Network Architecture ......................... X
   2.1. Topology .................................................... X
   2.2. Multicast Forwarding over UDLR .............................. X
   3.0. Layer 2 Protocols ........................................... X
   3.1. Hardware Address Resolution ................................. X
   3.1.1 Hardware Address Resolution protocol over UDLR ............. X
   3.1.2 Issues using a hardware resolution protocol over UDLR ...... X Long round trip delays ................................... X Large number of receivers ................................ X
   3.2. PPPoE ....................................................... X
   3.2.1 Introduction ............................................... X
   3.2.2 Architecture ............................................... X Specificities ............................................ X Description of a connection .............................. X
   3.2.3 Advantages ................................................. X
   3.2.4 Limitations ................................................ X
   3.2.5 Security Issues ............................................ X
   4.0. Layer 3 Protocols ........................................... X
   4.1. Dynamic Host Configuration Protocol ......................... X
   4.1.1. DHCP Overview ............................................. X
   4.1.2. DHCP over UDLR ............................................ X Configuration and tuning guidelines ..................... X Security issues ......................................... X
   4.2. Issues using IGMP over UDLR ................................. X
   4.2.1. Basic IGMP Operation ...................................... X
   4.2.2. IGMPv2 Leave Processing ................................... X
   4.2.3. IGMPv3 Operation .......................................... X
   4.2.4. Forwarding Groups at the Receiver based on IGMP ........... X
   4.3. IGMP-Proxy .................................................. X
   4.4. Dense Mode Multicast Routing ................................ X
   4.4.1. DVMRP ..................................................... X
   4.4.2. Dense Mode PIM (PIM-DM) ................................... X
   4.5. Sparse Mode Multicast Routing ............................... X
   4.5.1. Sparse Mode PIM (PIM-SM) .................................. X
   4.5.2. PIM-SM RPs and MSDP ....................................... X
   5.   Security Considerations ..................................... X
   6.   Conclusions ................................................. X
   7.   Acknowledgements ............................................ X
   8.   References .................................................. X
   8.1. Normative References ........................................ X
   8.2. Informative References ...................................... X
   9.   Authors' Addresses .......................................... X
   10.  Full Copyright Statement .................................... X
   11.  IANA Considerations ......................................... X

Authors                                                         [Page 2]

Internet Draft          Experiments with RFC 3077              July 2003

1. Characteristics of Uni-Directional Links

   This document describes issues that concern use of UDLR networks
   [RFC3077] to support the IP multicast service. In this document it is
   assumed that the feed router is a multicast router [RFC1122].

   The format of an IPv4 multicast packet [RFC 1112] is identical to
   that of an IPv4 unicast packet and is distinguished only by a special
   class of destination address (class D, i.e., addresses in the range
   from to

   There are five distinct multicast scenarios. The issues that arise
   and the approaches to be recommended will be a function of these
   scenarios.  The list of scenarios to be addresses is:

   Scenario A.  An edge-network, where end hosts receive a multicast
   service from an upstream router via the Feed Router. Multicast
   forwarding is controlled via a group memberhip protocol (e.g. IGMP
   [RFC2236]). Each end host is directly via a UDLR feed link.

   Scenario B.  A bridged edge-network, where one or more end hosts
   receive a multicast service via a common LAN connection to a UDLR
   Receiver. Multicast forwarding is controlled via a group memberhip
   protocol (e.g. IGMP [RFC2236]). The UDLR Receiver is connected to the
   upstream Feed Router via a UDLR tunnel.

   Scenario C.  A bridged-network supporting multicast routers, where
   one or more multicast routers receive a multicast service provided
   via a common LAN connection to a UDLR Receiver. Multicast forewarding
   is controlled by a Layer 3 Multicast Routing Protocol (e.g. PIM-SM
   [DRAFT-PIM-SM-NEW]). The UDLR Receiver is connected to an upstream
   router via a UDLR tunnel.

   Scenario D.  A multicast routed-network, where the UDLR Receiver acts
   as a multicast router.  This receives a multicast service provided
   from the upstream Feed Router. Multicast forewarding is controlled by
   a Layer 3 Multicast Routing Protocol, (e.g. PIM-SM [DRAFT-PIM-SM-

   Scenario E.  An inter-domain multicast network, in which two or more
   separate multicast domains are connected using the UDLR network. The
   complexity of this scenario increases with the need to support other
   protocols (e.g. MBGP, MSDP).

   A simple network may have only one of these scenarios, but more
   complex networks may have a combination.

1.1 Characteristics of UDLR networks

Authors                                                         [Page 3]

Internet Draft          Experiments with RFC 3077              July 2003

   UDLR subnetworks present characteristics which differ significantly
   from those experienced in the general Internet. These characteristics
   lead to specific problems and raise specific issues that need to be
   addressed to deploy an IP multicast service.  This section identifies
   specific characteristics that impact multicast performance resulting
   from the asymmetry and the types of network over which the UDLR is
   commonly implemented.  These are:

1.1.1 Asymmetric routing paths

   Unidirectional links give rise to differing forward (feed) and return
   (tunnel) paths. Multicast routing protocols that use the "reverse
   shortest path tree" towards the source as a part of their forwarding
   decision (e.g. DVMRP, PIM-SM [DRAFT-PIM-SM-NEW], PIM-DM) will not
   work correctly over asymmetric routing paths. Solutions include the
   use of UDLR [RFC 3077] and the use incongruent MBGP routing.

1.1.2 Asymmetric multicast capability

   Asymmetric multicast capability is not a fundamental feature of UDLR.
   In some UDLR networks both forward (feed) and return paths may
   support native IP multicast.  In other UDLR networks, a case may
   arise where the forward link supports native multicast, whereas
   return link may supports only unicast. UDLR routing allows a non-
   broadcast/multicast link to be used for the return path by employing
   a tunnel in the return direction [RFC2784].

1.1.3 Forward link capacity

   Since many UDLR networks employ wireless technology for the forward
   (feed) link (e.g., [EN00]), there may be an appreciable cost for
   forwarding traffic on the feed link. This leads to a desire to
   prevent forwarding unnecessary multicast traffic, this implies the
   need to control which groups are forwarded. However, other factors,
   (e.g., asymmetric links, and asymmetric loss environment), may
   suggest a desire to minimise the volume and frequency of control
   messages in the return direction.

1.1.3 Asymmetric link capacity

   The capacity of the forward (feed) and return (tunnel) paths may
   differ significantly (e.g., forward link using DVB-S [EN00], return
   using a GRE tunnel over a dial-up modem or ISDN interface for the
   return path). The high normalised bandwidth ratio can lead to a
   performance bottleneck, in addition the "cost" of setting up and
   maintaining capacity in the reverse direction may be significantly
   greater than in the forward direction [DRAFT-PILC-ASYM].  Although a

Authors                                                         [Page 4]

Internet Draft          Experiments with RFC 3077              July 2003

   class of multicast applications do not require a return path for
   their transport protocol (e.g.  unidirectional transmission of
   multimedia using RTP [DRAFT-AVT-RTP-NEW]), a path may still be
   required for other supporting protocols (e.g. DNS, IGMP , Multicast
   Routing).  The cost of establishing and maintaining a return path for
   these applications may be appreciable, especially considering its
   minimal use.

1.1.4 Asymmetric loss environment

   UDLR does not by itself introduce an imbalance in the packet loss
   rate between the transmit and receive paths, however different link
   technologies are often used to implement the forward (feed) and
   return (tunnel) links of UDLR networks. In some important cases this
   can lead to a significantly higher probability of packet loss in the
   return direction [DRAFT-PILC-ASYM].

1.1.5 Flat networks

   The link technologies that are often used to implement the  UDLR
   feed link may support a multicast/broadcast capability that permits a
   very large number of directly connected downstream receivers. For
   example, a single satellite down-link may support 1tens of thousands
   of UDLR Receivers. The numbers of Receivers connected via the same
   physical link may be much larger than found in other common LAN
   technologies, (e.g.  Ethernet).  Current routing protocols, and some
   multicast application protocols do not scale to arbitrary large
   numbers of participants.

1.1.6 Subnetwork round trip delay

   UDLR does not by itself introduce an appreciable subnetwork round
   trip delay, however many practical UDLR networks are built using
   links that may introduce significant path delay (e.g. satellite
   links). Since the subnetwork round trip delay impacts the performance
   of the protocols that support the multicast service, the impact of
   this delay needs to be considered.

2. Description of the Network Architecture

2.1 Topology

   The UDLR protocol can be used over various types of unidirectional
   links. Among these links we can list the DVB-S [EN00], DVB-T [], DAB
   [] links and some cable modems technologies which are
   unidirectionals. So far, the UDLR protocol has been mainly used in a
   satellite environment (DVB-S) whose technology seems speader than the

Authors                                                         [Page 5]

Internet Draft          Experiments with RFC 3077              July 2003


   In this document we focus on the use of UDLR in a satellite
   environment since most experiments have been performed with this
   technology. A send-only feed is connected to the global Internet with
   a bidirectional interface (e.g. Ethernet). It is also connected to
   the unidirectional link with a send-only interface. There is no
   receive-capable feed in the architecture.

   A set of receivers is connected to the unidirectional link with a
   receive-only interface. They all have a bidirectional interface (e.g.
   Ethernet or ppp) connected to the Internet. The receivers can reach
   the feed bidirectional interface through the Internet.

   All the nodes connected to the unidirectional link, i.e. the feed and
   the receivers, implement UDLR. As a result, every node can send a
   unicast, a multicast or a broadcast layer-two frame over the
   unidirectional link. A node can reach any other node as if they were
   connected to a bidirectional broadcast network. In other words, nodes
   are connected in a similar way to an Ethernet local area network.

   Figure 1 depicts this architecture with a single feed and several


                            ~~~~  ----   ~~~~
                           /   /-| OO |-/   /
                           ~~~    ----  ~~~
                         _/       \         \
                       _/          \         \
                     _/             \         \    Unidirectional
                   _/                \         \    Link
                 _/                   \         \
               _/                      \         \
              /                         \         \
             |                          |          |
        --------                   --------    --------   ----------
        | Feed |                   |Recv 1|    |Recv 2|---|subnet A|
        --------                   --------    --------   ----------
            |                          |           |         |
            |                          |           |         |
           |                     Internet                     |

                 Figure 1: Typical UDLR topology

Authors                                                         [Page 6]

Internet Draft          Experiments with RFC 3077              July 2003

   Recv 1 is host, e.g., the end-user work station integrating a
   satellite reception card. The host may have an ISDN or RTC connection
   for a terrestrial Internet provided by a local ISP.

   Recv 2 is a routeur connected to a local area network (Subnet A).
   Other routeurs may be connected to the subnet and exchange routing
   informations with Recv 2. Recv 2 may have an ISDN or RTC connection
   for a terrestrial Internet provided by a local ISP.

   The examples of terrestrial connecvities for a host or a router are
   non-exhaustives, they may also use other technologies such as
   Ethernet or GSM, etc.

   The UDLR protocol supports the case where several feeds are connected
   to a satellite. This case is not described in the document because
   not as many experiments as with a single feed, have been performed.

2.2 Multicast Forwarding over UDLR

   A UDLR Feed Router connected to an upstream multicast router MAY
   choose to forward all received IP multicast packets on all forward
   feeds, or MAY alternatively use a group management or routing
   protocol to determine the set of multicast groups that must be
   forwarded for each forward feed.

   MUST forward all IPv4 packets with an address [RFC
   1122].  It MAY also forward all other packets with other multicast
   addresses ( [RFC 3171], but SHOULD use group membership
   information to avoid forwarding packets belonging to groups for which
   there are no downstream members connected via UDLR receiver(s) (see
   section 4.2). In some cases, this forwarding will be controlled using
   MAC address filters. Since a number of IPv4 multicast addresses are
   often mapped to a common MAC address, address overlap may occur (e.g.
   [RFC1122]). In this cases a Feed Router may determine the set of IP
   multicast addresses in use, and hence the corresponding set of MAC
   address and then choose to forward all IP groups that map to this set
   of MAC addresses.

   This is normal IP multicast routing behaviour.

   The rules for forwarding those multicast packets received by the Feed
   Router differ when the packets are received via the feed tunnel end-
   point [RFC3077]. In this case, the Feed Router MUST forward all
   multicast packets to the interfaces associated with:

   (i) the list of send-only feed tunnel end-points
        (ii) the forward feeds
        (iii) the upper layer protocols of a multicast enabled Feed

Authors                                                         [Page 7]

Internet Draft          Experiments with RFC 3077              July 2003

   Router (i.e., for possible forwarding to upstream multicast

   In cases (ii) and (iii) the multicast forwarding does not include the
   normal Reverse Path Forwarding (RPF) check, the normal processing of
   the Time To Live (TTL) field, or the normal processing of
   administratively scoped multicast addresses.

   In addition, a UDLR Receiver MUST must perform normal multicast
   forwarding of IP multicast packets received on the forward feed
   interface, but MUST NOT forward any packets that were originated by
   the same Receiver (i.e., were previously sent via the return
   direction tunnel). This later requirement is equivalent to an RPF
   check. Multicast packets received by the node on other (i.e., non-
   feed) interfaces MUST be forwarded to the Feed Router using the
   return tunnel interface.

3.0 Layer 2 Protocols

3.1 Hardware Address Resolution

   A hardware address resolution can be used over UDLR to allow a node,
   e.g. a feed or a receiver, to discover the MAC address of another

   Regardless of whether the link is unidirectional or bidirectional, if
   a nodes sends a packet over a non-point-to-point type network, it
   requires the data link address of the destination. ARP [RFC826] is
   used on Ethernet networks for this purpose.

   This mechanism usually requires that the underlying transmission
   media is bidirectional in order for a node to obtain the data link
   address of a destination. The node sends an ARP REQUEST over the link
   and waits for an ARP RESPONSE from the destination that contains its
   data link address. Upon reception of the ARP response, the node can
   then send traffic to the destination. Note that an ARP REQUEST is
   broadcast-type frames, all nodes connected to the link receive it and
   process it. An ARP RESPONSE is a unicast-type frame, only the
   receiver whose hardware address is identical the MAC destination
   address of the frame processes it.

   3.1.1 Hardware Address Resolution protocol over UDLR

   In a satellite environment, receivers connected to a DVB-S link use
   reception cards which have their own unique hardware address. This
   hardware address is 6-bytes long, like an Ethernet address. It may be
   then sensible to use a mechanism similar to [RFC826] for a feed to

Authors                                                         [Page 8]

Internet Draft          Experiments with RFC 3077              July 2003

   discover the hardware address of a receiver. Thanks to the UDLR
   protocol which emulates a bidirectional connectivity over the
   satellite link. It allows a receiver to send back to the feed layer
   two packets such as ARP responses.

   Note that, for other satellite data link formats different from DVB-
   S, receivers still have a unique hardware address and a similar
   address resolution protocol based on exchanging REQUEST and RESPONSE
   messages may be used.

   In a topology where we have a feed and a number of receivers
   connected to the satellite link, there are 3 typical hardware address
   resolution scenarios:

      i) Scenario 1: A feed needs a receiver's hardware address.

        This usually occures when a feeds has to send a unicast IPv4
        packet to a receiver whose MAC address is unknown.

        The feed sends an ARP REQUEST over the satellite link whose
        payload contains the IP address of the receiver. All the
        receivers listen to the ARP REQUEST. The receiver which
        recognizes its IP address in the payload sends an ARP RESPONSE
        back to the MAC address of the feed. Note, the ARP REPONSE
        reaches the feed through the UDLR GRE tunnel. Upon reception of
        the ARP RESPONSE, the feed obtains the receiver MAC address from
        the payload and can send IPv4 packets to it.

      ii) Scenario 2: A receiver needs the feed's hardware address.

        This usually occures when a receiver has to send a unicast IPv4
        packet to the feed whose MAC address is unknown.

        The data link layer of the receiver creates a ARP REQUEST which
        is sent through the UDLR GRE tunnel. The ARP REQUEST payload
        contains the IP address of the feed. Upon reception of the ARP
        REQUEST, the feed which recognizes its IP address in the payload
        sends over the satellite link an ARP RESPONSE to the MAC address
        of the receiver. Upon reception of the ARP RESPONSE, the
        receiver obtains the feed MAC address from the payload and can
        send IPv4 packets to it.

      iii) Scenario 3: A receiver needs a receiver's hardware address.

        This usually occures when a receiver has to send a unicast IPv4
        packet to another receiver whose MAC address is unknown.

        The receiver sends an ARP REQUEST, which contains the IP address

Authors                                                         [Page 9]

Internet Draft          Experiments with RFC 3077              July 2003

        of a receiver, through the UDLR GRE tunnel. Upon reception of
        the frame, the feed forwards it over the satellite as it is a
        broadcast-type frame (see [RFC3077] for details).

        All the receivers listen to the ARP REQUEST. Only the receiver
        which recognizes its IP address in the payload sends back an ARP
        RESPONSE to the requesting receiver. The ARP RESPONSE is sent
        through the UDLR GRE tunnel to the feed. Upon reception of the
        frame, the feeds figures out that the destination MAC address is
        a receiver's one and then forwards it over the satellite link
        (see [RFC3077] for details). The requesting receiver receives
        the ARP RESPONSE, obtains the desired MAC address and can send
        IPv4 packets to it.

   These 3 scenarios allow any node connected to the satellite link to
   obtain the MAC address of any other node.

3.1.2 Issues using a hardware resolution protocol over UDLR

   The scenarios described in Section 3.1.1 raise a number of issues
   when using a hardware resolution protocol over UDLR in a satellite
   environment. Long round trip delays

   Regarding to scenarios 1 and 2, it requires over 250 milliseconds for
   a node, a feed or a receiver, to obtain the MAC a destination of a
   destination. 250 milliseconds is the fix and uncompressable satellite
   link propagation delay. It should also be added to it the propagation
   delay on the terrestrial link from the receiver to the feed. This
   delay may vary from a few milliseconds up to a couple of hundred
   milliseconds depending on the receiver's connectivity. E.g., a slow
   GSM connectivity has a significative impact on the overal round trip
   time whereas a fast T1 access has very little impact.

   Because of long round trip delays, reactive address resolution
   methods may not work well in some cases. For example, a feed may have
   to forward UDP unicast packets at high data rates to a receiver whose
   hardware address is unknown.  The stream of packets is passed to the
   link-layer driver of the feed send-only interface.  When the first
   packet arrives, the link-layer realizes it does not have the
   corresponding hardware address of the next hop, and sends an ARP
   request. While the link-layer is waiting for the response (at least
   250 milliseconds), IP packets are buffered by the feed.  If it runs
   out of space before the ARP response arrives, IP packets will be
   dropped. However, for TCP traffic, this should not happen since the
   first TCP packet sent to a receiver whose MAC address is unknown, is
   generally a TCP SYN indicating the start of a new session. This

Authors                                                        [Page 10]

Internet Draft          Experiments with RFC 3077              July 2003

   packet is not followed by a stream of packet until the receiver
   replies to it. Therefor not many packets are buffered or lost for the
   session. Note that subsequent IP packets sent to the same receiver
   hop are not buffered anymore as long as the ARP entry is valid.

   Regarding to scenario 3, the round trip delay between two receivers
   is twice the round trip delay of scenarios 1 and 2. Both, the ARP
   REQUEST and ARP RESPONSE are sent over the terrestrial network
   through UDLR GRE tunnel and over the satellite link. An IP packet
   delivered to the data link whose next hop MAC address is unknown,
   must be buffered at least 500 milliseconds before being sent.

   In order, to make a reactive harware address resolution protocol more
   efficient in scenario 3, i.e. to reduce the round trip delay, it
   might be sensible to configure an ARP server at the feed. The feed
   would learn MAC addresse from ARP RESPONSES it receives from
   receivers and would publish them as soon as a receiver requests one
   of them. This mechanism would reduce the round trip down to 250
   milliseconds, the feed would answer to an ARP REQUEST instead of a
   receive reducing the latency. Large number of receivers

   Due to the large number of receivers which may be connected to the
   satellite link, it is necessary to be able to allocate a sufficient
   number of ARP entries in a ARP table. A feed may need to send unicast
   packets to thousand of different receivers. For each of the
   receivers, a correspondance between a MAC address and the IP address
   of a receiver must be maintained.

   Furthermore, when the size of the ARP table is significant, the
   search for a MAC address corresponding to the next hop IP address
   must be performed rapidely in order to prevent IP packets from being
   buffered too long.

   It is also common to associate an expiration date to an ARP entry in
   order not to keep an entry for ever. After being deleted, an ARP
   entry associated to a receiver is renewed when an IP packet is sent
   again to this receiver. The main reasons for aging entries are:

      - Automatic discovery of a receiver new MAC address. One may
      replace the reception card of a receiver for maintainance puposes.
      The IP address of the receiver does not change but its MAC address
      does. When deleting the ARP entry of this receiver, a new IP
      packet destined to it triggers the request of its new MAC address.

      - ARP table size adjustable. Receivers may not be constantly
      connected to the satellite link. During idle periods, it is then

Authors                                                        [Page 11]

Internet Draft          Experiments with RFC 3077              July 2003

      not necessary to keep an ARP entry for these receivers. The size
      of the ARP table can then be adjusted to the number of active

3.2 PPPoE

3.2.1 Introduction

   The use of PPPoE with UDLR enables to offer a real satellite local
   loop.  It represents a good alternative for non covered by ADSL
   areas.  As PPPoE is a level 2 (OSI model) protocol, it matches well
   with the LLTM mechanisms of the UDLR that make all the equipments
   directly linked in Ethernet to the UDLR client and server see each
   other on the same logical LAN (Local Area Network).  The only needed
   routing is the one between the UDLR client and the UDLR server for
   establishing the GRE tunnel.

3.2.2 Architecture
                  Unidirectional Link
               |                       |
               |                       |
               |                       |
               |                       |
               |                       |
              \|/                      .
               .                      /|\
               |                       |
           ---------               ---------         --------
  Ethernet | PPPoE/|  IP Networks  | LLTM  |  PPPoE  | BAS  |
    -------| LLTM  |-------->------|Server |---------|      |
           | Router|               |       |         |      |
    |      ---------               ---------         --------
    |  ____                                              |
    |--|PC|                                              |
    |  ----                                           --------
    |  ____  LAN                                      | ISP  |
    |--|PC|                                           --------
    |  ----

     Figure 1 : Connectivity to a BAS via UDLR/PPPoE

In the Figure 1, the connections with arrow are unidirectionnal, others
are bidirectionnal. Specificities

Authors                                                        [Page 12]

Internet Draft          Experiments with RFC 3077              July 2003

   The specificities of this architecture are :
      - the use of a UDLR client (implementing the RFC 3077) on a
        satellite terminal.
      - the use of a UDLR server (implementing the RFC 3077) on a DVB
        (Digital Video Broadcasting) Gateway acting as an Ethernet
        Bridge (so you need a routeur co-located with the DVB gateway)
      - a connection to a BAS (Broadband Access Server). The BAS is
        directly connected to the DVB gateway in Ethernet. The BAS
        manages the PPPoE connection. The PPPoE can end into the BAS
        (open model) or continue and end into the RADIUS server of an
        ISP (Internet Service Provider) (closed model).  The PPPoE
        authentication is done where the PPPoE tunnel ends (PPPoE
      - the use of a PPPoE client; there are two possible scenarii :
                 > the PPPoE client is implemented on the satellite
          terminal that acts as a routeur for the PCs in LAN behind. The
          PPPoE session is initiated between the satellite terminal and
          the BAS or the Radius server.
                 > the PPPoE client is implemented on the PC, the
          satellite terminal is now acting as an Ethernet Bridge : each
          client is using its own PPPoE connection.   All the PPPoE
          tunnels are encapsulated in the same GRE tunnel. Description of a connection

   Here are the different steps of a connection to Internet :
      - a user on a PC is trying to connect to a distant server of the
      - the satellite terminal detects IP traffic
      - after an authentication on the satellite platform, a GRE tunnel
        is initiated between the DVB interface of the satellite terminal
        and the DVB gateway. Now a LAN has been emulated and all the
        Ethernet frames coming from the satellite terminal can be
        directed to the gateway DVB and therefore to the BAS.
      - after an authentication on the BAS (or the Radius server of an
        ISP), a PPPoE tunnel is initiated between the satellite terminal
        or the PC and the BAS (the specificities of a PPPoE connection
        is described in the RFC 2516).
      - the BAS redirect the PPP connection to the right ISP through a
        L2TP tunnel.

3.2.3 Advantages

        The bidirectionnal connectivity through PPPoE offers the
        following advantages :
      - a complete layer 2 (OSI model) satellite connectivity is offered
        with a total transparency at an IP level between the terminal
        satellite (UDLR client) and the IP network.

Authors                                                        [Page 13]

Internet Draft          Experiments with RFC 3077              July 2003

      - UDLR supports natively the PPPoE so no hardware development is
        needed.  The PPPoE client has to be integrated in the satellite
        terminal or in the PC.
      - PPPoE enables an interconnection with a Broadband Access Server
        and besides the use of its functionalities (such as traffic
      - A satellite access based on UDLR/PPPoE can be complementary with
        the ADSL network :
                 > same performances as the ADSL network
                 > reduction of the access costs due to the equipments'
          convergence point in the return channel and a unique
          management system for both satellite and terrestrial access
          (accounting, billing, etc.)
      - a multi-ISP configuration for the Internet access.
      - a difference can be made between the IAP (Internet Access
        Provider) and the ISP

3.2.4 Limitations

   It is important to notice that PPPoE supports only PPP connection for
   unicast flows.  The multicast is provided directly by the IAP at the
   DVB gateway level or coming from the Mbone through the BAS without
   using PPPoE.

3.2.5 Security issues

   The security issues are the same as the UDLR ones.  So you need a
   first authentication for the establishment of  the GRE tunnel.
   Afterwards, you need a second authentication of the client done by
   the BAS or the Radius server of the ISP.  This authentication is done
   within the PPPoE mechanism (PAP or CHAP).  It's also possible to use
   cryptography¿with the IPSec protocol (e.g. RFC 3457)

4.0 Layer 3 Protocols

4.1 Dynamic Host Configuration Protocol

   The Dynamic Host Configuration Protocol (DHCP) provides a framework
   for passing configuration information to hosts on a TCPIP network,
   and a mechanism for automatic temporary allocation of network

4.1.1 DHCP Overview

   DHCP is based on Bootstrap Protocol (BOOTP). It consists of two
   components: a protocol for delivering host-specific configuration
   parameters from a DHCP server to a host (default gateway, DNS server)
   and a mechanism for allocation of network addresses to hosts.  DHCP

Authors                                                        [Page 14]

Internet Draft          Experiments with RFC 3077              July 2003

   [RFC 2131] defines a set of transactions between a DHCP server and a
   DHCP client to afford/request a valid network address, configuration
   parameters or both. These transactions are constructed by DHCP
   that could include DHCP options defined in RFC2132.

   DHCP runs over UDP. It uses port 67 on server's side, and port 68 on
   client's side. A DHCP client is not supposed to know the DHCP
   server's IP address initially.

   When a host needs to acquire an IP address and eventually
   configuration parameters, it broadcasts a DHCPDISCOVER message on its
   physical subnet. Relay agents (if running on connected routers) may
   pass the message on to DHCP servers not on the same physical subnet.

   One or more DHCP server may respond to the client by proposing a
   network address in a DHCPOFFER message. Server may probe the offered
   address with an ICMP Echo Request.

   The client may receive one or more offers. It broadcasts anyway a
   DHCPREQUEST message that contains a server identifier option, and
   eventually other options, to notice all DHCP servers of its

   The selected server sends a DHCPACK message to confirm allocation.
   The client may probe a last time the allocated address (e.g. ARP
   request). This is a typical example of a successful DHCP transaction.

   There are other DHCP transactions, messages and options. Please refer
   to [RFC2131] for a complete description of DHCP protocol, and to
   [RFC2132] for a complete description of DHCP options.

4.1.2 DHCP over UDLR

   LLTM mechanism makes nodes connected to the UDL see themselves on the
   same logical Local Area Network. Encapsulating layer-two frames allow
   them to be sent in unicast and broadcast through Internet and UDL.
   Thanks to this feature, DHCP can run on networks using UDLR
   architecture, i.e. satellite networks.  DHCP may be a solution to IP
   addressing scalability and increasing number of nodes on such
   networks. e.g. A node can be assigned a temporary network address
   from a pool of public addresses . DHCP provides also a means of
   requesting and getting local configuration parameters for clients
   from their ISP. Configuration and tuning guidelines

   Before sending a DHCP request, a client node needs Layer-two

Authors                                                        [Page 15]

Internet Draft          Experiments with RFC 3077              July 2003

   connectivity to one DHCP server at least. Actually, a common use of
   DHCP consists of making a DHCP client send DHCPDISCOVER message at
   boot. While using DHCP over UDLR, DHCP client messages should be sent
   only after establishing the GRE tunnel. Therefore, use of DHCP should
   be taken into account while dimensioning the DTCP HELLO message

   Lease duration and address pools' width, configured on DHCP server
   side, depend on the number of nodes to serve and the nature of
   offered services. Lease duration should not be too short to avoid an
   increasing DHCP traffic and the risk of inability of renewing leases.
   And should not be too long to avoid misusing addresses and increasing
   the blocking probability.

   A DHCP server can reassign addresses allocated before. It may check
   an address before reallocation by an ICMP echo request; and the
   client may do the same, after receiving an address, by an ARP
   request. Such messages should be allowed to avoid address conflicts.

   A DHCP server can be located on a receiver or a feed. For security
   and delay considerations, implementing DHCP server on feed's side
   reduces transaction duration to a half, and prevents from allocating
   a lease by an unauthorised DHCP server.

   Client sends DHCPRELEASE message to notice the server that client has
   relinquished the lease. Some implementations of DHCP client keep
   configuration information even after sending a DHCPRELEASE message.
   This may lead to an address conflict and reduces the available
   address pool.

   DHCP servers and clients should take into account network transit
   delay while assigning timers: DHCP messages retransmission timeout,
   maximum delay that a DHCP server waits before deciding that the
   absence of an ICMP echo response means that the relevant address is

   The global delay of a successful DHCP transaction is composed of:

      1) One or two RTTs (Round Trip Time) for DHCP transaction. I.e.
      requesting and acquiring a lease is done by exchanging four
      messages, renewing a lease is done by exchanging two messages.

      2) More than one RTT, which is the time needed to check the
      availability of a network address. E.g. ICMP echo.

      3) Time needed to read/write configuration and database files on
      both server and client sides.

Authors                                                        [Page 16]

Internet Draft          Experiments with RFC 3077              July 2003

   DHCP clients may also retransmit DHCP messages if they do not receive
   a response. Some client implementations timeout DHCPDISCOVER message
   (for example) on an Ethernet delay basis. And a DHCP server may
   respond to DHCPDISCOVER retransmission before that checking lease
   availability (by an ICMP echo request) timeout expires, resulting on
   an eventual address conflict.   Security issues

   DHCP works over UDP/IP stack. These protocols are not inherently
   secure. And UDLR technology is widely used over links that may be
   easily accessed. Some DHCP messages (e.g. DHCPDISCOVER) are layer-two
   broadcasted on the UDL, a malicious DHCP server may allocate network
   addresses or false configuration information. An unauthorised host
   may capture information sent to a DHCP client; Configuration
   information can be then set manually. Link layer or IP security
   mechanisms are of great interest.

   Authorising DHCP server to serve unknown clients should be done with
   special attention. DHCP permits authentication on a hardware address
   basis through DHCP header and options, on the other hand LLTM
   mechanism encapsulates layer-two frames. Authentication is another
   important security feature.

   DHCP transactions should be allowed after client authentication.

4.2 Issues using IGMP over UDLR

   The Internet Group Management Protocol (IGMP) [RFC1112, RFC2236, RFC-
   IGMPv3] is used in multicast edge networks (i.e., an Ethernet LAN or
   the UDLR Scenarios A and B). Forwarded between multicast routers is
   controlled by a different protocol (see section 5). The first version
   of IGMP, IGMPv1 [RFC1112] is little used.  At the time of writing,
   most current end hosts use IGMPv2 [RFC2236]. IGMPv3 is increasingly
   being deployed [RFC-IGMPv3]. A MIB has also been defined [RFC2933].

   IGMP messages are sent with an IPv4 Time To Live (TTL) of 1,
   indicating these are link local.  On a UDLR return link, these
   messages are sent using the return link tunnel, and retransmitted
   over the feed (see 1.1.1).

4.2.1 Basic IGMP Operation

   IGMP Membership Reports are sent by end hosts to communicate their
   desire to receive specific IP multicast groups. Multicast routers in
   the same subnetwork use IGMP Membership Reports to help determine
   whether IP multicast packets should be forwarded to the subnetwork.
   Multicast routers may already be forwarding this group, if not they

Authors                                                        [Page 17]

Internet Draft          Experiments with RFC 3077              July 2003

   start to forward IP multicast packets for the reported group after
   the subnetwork RTT plus any additional delay required for the Feed
   Router to join the requested multicast flow.

   To validate the set of currently active groups, one multicast router
   per subnetwork (the Querier) periodically  sends a multicast packet
   containing an IGMP Group Membership Query to all end hosts (i.e.,
   using the IPv4 address The Query Interval must be greater
   than the sum of the Max Response Time and the Subnetwork Round Trip
   Time, and is typically much larger. The Query message is received by
   all systems in the subnetwork that have multicast enabled. This
   mechanism also acts as an opportunity for end hosts to resend a
   Membership Report which was not received by the UDLR Feed Router.

   Each end host sets a random timer for each group it wishes to
   receive.  When the timer expires, it responds with one IGMP Group
   Membership Report for each group which it wishes to receive. IGMP
   includes a technique to reduce the number of Reports received by the
   querier.  This suppression mechanism relies upon visibility of the
   responses sent by all members of the multicast group (i.e., the UDLR
   Feed Router must re-send received Membership Reports on the all
   feeds). If the other group members do not receive copies of the
   Membership Reports, they will each send one Membership Report per
   query, Groups which contain many members therefore generate a large
   volume of return traffic.

   Even when suppression is used, a large subnetwork RTT, may lead to
   many receivers sending IGMP Membership Reports for the same group(s)
   within the Max Response Time [RFC2236].  If it is known that there
   may be many group members, one mitigation is to increase the Max
   Response Time.  which allows suppression to occur after one
   Subnetwork RTT.

   A Querier that identifies a previously forwarded group that currently
   has no group members will send several (Robustness Variable) Queries
   each separated by the Query Interval. The Query Interval must be
   greater than the sum of the Max Response Time and the Subnetwork
   Round Trip Time. If no Membership Reports are received for a specific
   group (i.e., after a total period called the Group Membership
   Interval) the multicast routers stop forwarding multicast packets
   with this group address.  Decreasing the Robustness Variable and/or
   the Query Interval reduces the time  to detect the last memebr
   leaving a group(s).  This can reduce the volume of unnecessary
   multicast traffic sent over a UDLR feed link.  Reducing the
   Robustness Variable also reduces tolerance to loss of Membership
   Reports sent over the return link (see 1.1.4).

   The number of Membership Reports is an issue for flat networks (see

Authors                                                        [Page 18]

Internet Draft          Experiments with RFC 3077              July 2003

   1.1.5), particularly if they also exhibit a larger subnetwork RTT
   (see 1.1.6).  The number sent for each group is a function of the
   number of systems that wish to receive the group, the Subnetwork RTT,
   and the Max Response Time. Suppression requires the multicast packets
   containing multicast Membership Reports received from UDLR Receivers
   to be forwarded by the UDLR Feed Router.

   A large Max Response Time, can reduce the number of redundant
   Membership Reports, reducing return link traffic, but it also has the
   drawback of increasing the leave latency. This may, in turn, increase
   the volume of traffic unnecessarily forwarded on the forward link
   when there are no remaining group members. This is an issue for UDLR
   networks with limited forward link capacity (see 1.1.3).

4.2.2 IGMPv2 Leave Processing

   In IGMPv1, it may take a considerable time for a multicast router to
   discover there are no remaining end hosts interested in a group that
   it is already forwarding. A refinement in IGMPv2 [RFC2236] allows end
   hosts to send a Leave message explicitly indicating the group address
   which the end host wishes to leave. This message is sent to an IPv4
   address of In some, but not all implementations, end hosts
   will suppress sending an IGMP Leave message when they believe there
   are other remaining group members.

   Reception of an IGMP Leave message is not sufficient for a forwarding
   multicast router to determine that there are no longer any end hosts
   interested in a group. The Querier therefore responds by sending a
   Group-Specific Query to request responses  from other end hosts
   interested in the group. If no Membership Report is received, the
   Query is repeated each Last Member Query Interval up to Last Member
   Query Count times, after which it will conclude there are no
   remaining group members.  This allows multicast routers to more
   quickly stop transmission of multicast packets to groups for which
   there are no longer any active receivers. The value for Last Member
   Query Interval may be tuned, but MUST be greater than the Subnetwork
   RTT. The time taken to terminate an IP multicast flow is therefore
   the sum of the subnetwork RTT and the delay introduced by the IGMP

4.2.3 IGMPv3 Operation

   IGMPv3, allows an end host to report an interest in receiving not
   only a specific group address, but also from a specific set of IP
   source addresses (or all except a specific set of IP source
   addresses).  This allows finer control over the multicast packets
   forwarded to the subnetwork. This may conserve link capacity,
   especially when a system switches from receiving one multicast group

Authors                                                        [Page 19]

Internet Draft          Experiments with RFC 3077              July 2003

   to another.

   End hosts that receive an IGMPv3 Query start a random timer. The
   maximum value is specified as a parameter in the Query, allowing an
   appropriate scaling factor to be selected based on the anticipated
   size of the group and the Subnetwork RTT. IGMPv3 Membership Reports
   are sent to a specific multicast address (i.e. the IPv4 address A potential modification to UDLR would allow this group
   to be filtered by the Feed Router.

   One significant change in IGMPv3, is that end hosts MUST send
   Membership Reports following a Query to indicate the groups they wish
   to receive (i.e., there is no suppression), although a single message
   may report several groups.  This may increase the number of IGMP
   messages sent over a subnetwork. This can consume both feed and
   tunnel capacity (see 1.1.3, 1.1.4).  To mitigate this in flat
   networks (see 1.1.5) or networks with a large subnetwork RTT (see
   1.1.6), IGMPv3 therefore also allows the use of much larger response

   An advantage of IGMPv3 is that it allows routers (and connected LAN
   switches) to provide explicit tracking of which end hosts request
   each group.  Explicit tracking allows routers to discover immediately
   when the last group member leaves, and suspend forwarding of the
   group within a Subnetwork RTT.

4.2.4 Forwarding Groups at the Receiver based on IGMP

   Note that in IGMPv1 and IGMPv2, Leave and Membership Report messages
   are sent to the same group destination address as the group it is
   notifying.  A bridged (Scenario B) solution requires these messages
   to be parsed at the UDLR receiver in order to establish an
   appropriate filter set to forward multicast packets to the attached
   end hosts.  One scheme is called Snooping [DRAFT-MAGMA-SNOOP].
   Separating these Membership Reports from multicast traffic can be
   processor intensive and may impact performance, many Ethernet LAN
   switches employ ASICS to optimise this processing.

4.3 IGMP-Proxy

   The IGMP Querier function is normally implemented in a multicast
   Router, and the IGMP client in a multicast end host. It is also
   possible to implement the IGMP protocol within UDLR Receiver, this is
   called an IGMP membership Proxy [DRAFT-MAGMA-PROXY, DRAFT-MAGMA-

   Consider Scenario B.  An IGMP membership proxy at the UDLR Receiver
   behaves as if it were an end host (i.e., sends IGMP Membership

Authors                                                        [Page 20]

Internet Draft          Experiments with RFC 3077              July 2003

   Reports for groups it wishes to receive) in response to IGMP Queries
   received over the UDLR forward feed.

   The receiver also executes an IGMP Querier  for the attached LAN and
   therefore sends IGMP Queries.  The Membership Reports received by the
   Receiver allow it to collect group membership information, which can
   be directly used to control forwarding of multicast packets received
   over the UDLR feed.

   An IGMP Proxy may use different group membership protocols on the
   UDLR and LAN networks. This could be a mixture of IGMPv2 and IGMPv3,
   or could possibly be a modified protocol on the UDLR network.

   An IGMP Proxy may also implement Proxy Reporting [DRAFT-MAGMA-
   SNOOPING; DRAFT-MAGMA-PROXY], where the proxy only reports which
   sources and groups need to be forwarded.  This can significantly
   reduce the number / frequnecy of Reports. A UDLR Receiver employing
   an IGMP Proxy can separate the distribution of group membership
   information into the UDLR subnetwork and any attached networks
   connected via a UDLR client.  This allows the protocol parameters
   used within the UDLR network to be tuned.

4.4 Dense Mode Multicast Routing

4.4.1 DVMRP

4.4.2 Dense Mode PIM (PIM-DM)

4.5 Sparse Mode Multicast Routing

4.5.1 Sparse Mode PIM (PIM-SM)

   The issues of PIM-SM operation on unidirectional links are:

    1. Reverse Path Forwarding
    2. Rendezvous Point selection
    3. Designated Router selection

   This section describes these issues in details.  In this section, all
   nodes are assumed to be PIM-SM routers (Scenario D) and the UDL runs
   PIM-SM as the only multicast routing protocol.

   Reverse Path Forwarding

   In the case of Receive networks do not use the Feed Router to forward
   unicast traffic to multicast sources and the Rendezvous Point, the
   receivers do not send PIM-SM Join/Prune messages to the Feed Router.
   As the result, multicast traffic does not flow on the unidirectional

Authors                                                        [Page 21]

Internet Draft          Experiments with RFC 3077              July 2003

   link.  This is the PIM-SM reverse path problem on unidirectional

   There are two solutions, at least, for this problem:

   1. Configure UDLR Receive networks to route unicast traffics to all
      possible multicast sources and Rendezvous Points via the Feed

   2. Prevent PIM-SM routers in UDLR receive networks from
      switching to the shortest-path tree of multicast sources located
      outside the receive network. In this scheme, the UDL receive
      networks only need to route unicast traffic to all possible
      Rendezvous Points via the Feed Router.

   If the possible multicast sources includes all hosts in the Feed
   network, then the first option is to route traffic to the Feed
   network via the Feed Router. The second option simplifies the routing
   requirement from routing to all hosts in the Feed network to routing
   to the possible Rendezvous Points. The second option, however,
   doesn't work on SSM destination addresses. [DRAFT-PIM-SM-NEW]
   specifies some rules concerning the SSM destination addresses
   overriding the normal PIM-SM behavior. This document states that a
   router MUST NOT send a (*,G) Join/Prune message for any reason, thus
   PIM-SM never uses the rendezvous-point tree for traffic to SSM
   destination addreses.

   Rendezvous Point selection

   The Feed network can advertise routes to the possible Rendezvous
   Points using unicast routing protocols natively such that the UDLR
   receive networks route to them via the Feed Router. This scheme
   causes UDLR receive networks to route all networks between the Feed
   Router to the possible Rendezvous Points via the Feed Router. To
   minimize the number of networks routed via the Feed Router, the
   possible RPs should be as close as possible to the Feed Router. This
   number reaches the minimum if the Feed Router's unidirectional link
   interface address is the only possible Rendezvous Point.

   In the case where no unicast routing protocol is running on the uni-
   directional link and unicast routing advertisements are limited only
   within each Feed network and Receive network, the UDLR receive
   networks may use static routes. Static routes to the possible RPs via
   the Feed router are set on the UDL receivers and they are injected to
   the receive network's unicast routing protocol.

   Designated Router selection

Authors                                                        [Page 22]

Internet Draft          Experiments with RFC 3077              July 2003

   A PIM-SM router performs Designated Router election on each
   interface.  A DR has the task to send PIM-SM Register packets and to
   send Join/Prune messages toward the RP or the multicast source. The
   DR election is important for unidirectional links if multicast
   sources exist. If a multicast source exists on a unidirectional link,
   the Feed Router should be elected as the DR for the unidirectional
   link to avoid the overhead due to the LLTM mechanism. In the Scenario
   D, DR election result is not important as all UDL nodes are multicast

   A PIM-SM router sends Hello messages periodically every Hello_Period
   to each active inteface. In addition, a PIM-SM router also sends a
   Hello message when  Hello message is received from a new neighbor, or
   a Hello message with a new GenID is received from an existing
   neighbor. a PIM-SM router will remove a neighbor if it does not
   receive any neighbor's Hello message in the HoldTime advertised by
   the neighbor.

   The number of neighbors is an issue for flat networks (see 1.1.5).
   The bandwidth consumption Periodic Hello messages can be reduced by a
   large Hello_Period. A large HoldTime can reduce the probability of
   removing a PIM-SM neighbor due to Hello message packet loss, thus
   reducing the probability of a Hello message storm. However, the
   probability of a router reboot on flat networks having many nodes may
   be high, thus the probability of a Hello message storm due to
   receiving a Hello message with a new GenID from a newly rebooted

   Join/Prune messages are sent periodically toward the multicast source
   or the RP. An overriding Join is also sent by a router having a
   multi- cast state if it receives a Prune of that multicast state sent
   by a neighbor to the upstream router. If a PIM-SM router receives a
   Join with the same state, it can suppress sending a Join message of
   the same state.

   Join message suppression can reduce the bandwidth consumption of a
   shared link. For flat networks with many nodes or large round trip
   delay, a large Override interval will help. The large Override
   interval value causes a large Prune Pending Timer, thus multicast
   traffic will flow for a longer time on the unidirectional link even
   though there is no more downstream routers.

4.5.2 PIM-SM RPs and MSDP

   In the Scenario E, each Receive network has its own RP and MSDP is
   used to connect each RP. Each Receive network's RP MSDP peers with
   the RP of the Feed network.

Authors                                                        [Page 23]

Internet Draft          Experiments with RFC 3077              July 2003

   In the case of multicast routing using PIM-SM and MSDP, flowing
   multicast traffic from a source S in the Feed network to multicast
   listeners in Receive networks via a UDLR requires that: 1. Join(S,G)
   message from Receive networks to the Feed network flows via
      the UDLR.  2. The MSDP peer in the Feed network is the RPF peer of
   the MSDP peer
      in the Receive networks toward the originating RP of S.  These
   requirements suggest that a separate MRIB is needed to flow the
   traffic via the UDLR and the MRIB has to create the RPF route to S
   and its originating RP via the UDLR.

   [DRAFT-MSDP-DEPLOY] discusses several scenarios to deploy MSDP and
   PIM-SM.  The best current practice for inter-domain multicast is to
   use MBGP along with PIM-SM and MSDP. In the UDLR case, A Receive
   network MBP peers with the Feed network for the multicast address
   family only. This practice creates a different multicast topology to
   the unicast topology.

   If PIM-SM and MBGP are the only multicast routing protocols, the non-
   MBGP speaker routers in Receive networks do not have a separate MRIB.
   These routers perform RPF checks solely based on their unicast
   routing table; therefore they do not send Join(S,G) messages toward
   the Feed router.  These routers should be set to not join the SPT.

   The RP in Receive networks should be the Receive routers unless all
   rou- ters from the Receive routers to the RP learn the multicast
   topology from MBGP. If this is not the case, the MSDP peer in the
   Feed network passes the peer-RPF check at the MSDP peer in the
   Receive networks, but when the MSDP peer in the Receive networks send
   Join(S,G), the Join(S,G) path fol- lows the unicast routing table.

   Based on these facts, Receive networks should be configured as
   follows: 1. PIM-SM routers should not join the SPT.  2. RP, which is
   also the MSDP peer, should be the Receive router.  3. Receive routers
   should MBGP peer with the Feed router for the multi-
      cast address family.

   The configuration no. 1 basically also states that Receive networks
   can only be stub PIM-SM domain, because if they MBGP peer and MSDP
   peer with a downstream PIM-SM domain, the Receive networks have to
   create MRIBs on all routers along the intended Join(S,G) path from
   the RP of their down- stream domain to the Receive routers.

4.6 NAT environment

   Network Address Translation (NAT) technology is getting popular in
   the Internet these days. Normally NAT box translate private IP
   address to global IP address on regular TCP protocols and some of UDP

Authors                                                        [Page 24]

Internet Draft          Experiments with RFC 3077              July 2003

   services. UDLR defined by RFC3077 employs GRE encapsulation technique
   to communicate receivers and a feed. But RFC3077 does not consider to
   exist NAT box between the GRE tunnel between a receiver and a feed.
   By this nature RFC3077 does not support NAT environment. It may work
   with some NAT box but it depends on the implementation of NAT

5. Security Considerations

   The recommendations contained in this document do not impact the
   integrity of IP multicast transport protocols, or applications using
   IP multicast transport protocols.

   There are known Denial of Service (DoS) attacks that can be staged
   UDLR operation. UDLR employs GRE tunnel mechanism to carry a packet
   from a receiver to a feed. If the intruder send a faked packet to the
   tunnel end point at feed, it will be a cause of the link down of the
   UDL. Intruders also can send flooding packet to the UDL receivers via
   UDL. It will be a cause of UDL flood. Third case of the intrusion is
   related to ARP mechanism. If the operator employs ARP mechanism to
   resolve MAC address to IP address, these negotiation should be
   authenticated and protected from faked ARP packet. Faked ARP packet
   may be a cause of ARP table overflow on feed or other routers.

   To avoid these attack, it is recommended to protect tunnel end point
   at feed by packet filtering, hide tunnel interface IP address from
   unknown users, etc.. And it is also recommended that a packet sent to
   the UDL should be encrypted using any kind of encryption mechanism.
   UDL has a nature of broadcast link. That means packets on the UDL may
   be received by unexpected nodes.

6. Conclusions

7. Acknowledgements

8. References

8.1 Normative References

   [RFC826]  Plummer, D., "An Ethernet Address Resolution Protocol", STD
             37, RFC 826, November 1982

   [RFC1112]  Deering, S.E.,  "Host extensions for IP multicasting",
             RFC1112, 1989, (STD0003).

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

Authors                                                        [Page 25]

Internet Draft          Experiments with RFC 3077              July 2003

   [RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,

   [RFC2132] S. Alexander,R. Droms, "DHCP Options and BOOTP Vendor
             Extensions", RFC 2132, 1997

   [RFC2236]  Fenner, W., "Internet Group Management Protocol, Version
             2", 1997, RFC 2236, (Proposed Std).

   [RFC2516] L. Mamakos, K. Lidl, J. Evarts, D. Carrel, D. Simone, R.
             Wheeler, "A Method for Transmitting PPP Over Ethernet
             (PPPoE)",RFC 2516, February 1999

   [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina, P.,
             "Generic Routing Encapsulation (GRE)", RFC2784, (Proposed

   [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y.
             Zhang, 'A Link-Layer Tunneling Mechanism for Unidirectional
             Links', RFC 3077, March 2001

   [RFC-IGMPv3] "Internet Group Management Protocol, Version 3",
             (Author's note, with IESG - this reference needs to be
             solved when issued as an RFC).

8.2 Informative References

   [DRAFT-AVT-RTP-NEW]  Schulzrinne/Casner/Frederick/Jacobson, "RTP: A
             Transport Protocol for Real-Time Applications, <draft-ietf-
             avt-rtp-new-11.txt>, Work in Progress.

   [DRAFT-MSDP-SPEC] D. Meyer, B. Fenner, "Multicast Source Discovery
             Protocol (MSDP)", <draft-ietf-msdp-spec-20.txt>, Work in

   [DRAFT-MSDP-DEPLOY M. McBride, "Multicast Source Discovery Protocol
             (MSDP) Deployment Scenarios", draft-ietf-mboned-msdp-
             deploy-02.txt, Work in Progress.

   [DRAFT-MAGMA-SNOOP] M. Christensen, F. Solensky "IGMP and MLD
             snooping switches", <draft-ietf-magma-snoop-02.txt>, Work
             in Progress.

   [DRAFT-MAGMA-PROXY]  Fenner, B. et al, "IGMP-based Multicast
             Forwarding (IGMP Proxying)", <draft-ietf-magma-
             proxy-02.txt>, (Author's note: not in ID archive), Work in

Authors                                                        [Page 26]

Internet Draft          Experiments with RFC 3077              July 2003

   [DRAFT-PILC-ASYM]  Balakrishnan, H., V. N. Padmanabhan, G. Fairhurst,
             M.  Sooriyabandara, "TCP Performance Implications of
             Network Path Asymmetry", <draft-ietf-pilc-asym-08.txt>,
             Work in Progress.

   [DRAFT-PIM-SM-NEW] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas,
             "Protocol Independent Multicast - Sparse Mode (PIM-SM):
             Protocol Specification (Revised)", <draft-ietf-pim-sm-
             v2-new-07.txt>, Work in Progress.

   [EN00] "Digital Video Broadcasting (DVB); Interaction Channel for
             Satellite Distribution Systems", Draft European Standard
             (Telecommunications series) ETSI, Draft EN 301 790, v.1.1.1

   [RFC1889] Schulzrinne H. , S. Casner, R. Frederick, V. Jacobson,
             "RTP: A Transport Protocol for Real-Time Applications",
             1996, (Proposed Std).

   [RFC2933]  K. McCloghrie, D. Farinacci, D. Thaler, "Internet Group
             Management Protocol MIB", RFC2933, 2000, (Proposed Std).

   [RFC2402] Kent, S., Atkinson., R., "IP Authentication Header",
             RFC2402, 1998, (Proposed Std).

   [RFC2406] Kent, S., Atkinson., R., "IP Encapsulating Security Payload
             (ESP)", RFC 2406, 1998, (Proposed Std).

   [RFC3171] Albanna, Z., K. Almeroth, D. Meyer, M. Schipper. "IANA
             Guidelines for IPv4 Multicast Address Assignments", 2001, (

   [RFC3228]  Fenner, B., "IANA Considerations for IPv4 Internet Group
             Management Protocol (IGMP)", RFC3228, 2002, (BCP0057).

9. Authors' Addresses

   In alphabetic order:

   Gilles Chanteau
   France Telecom R&D
   38/40 rue du General Leclerc
   92131 Issy-Les-Moulineaux Cedex
   Phone: (+33) 1 45 29 58 67
   EMail : gilles.chanteau@rd.francetelecom.com

   Yann Codaccioni
   France Telecom R&D

Authors                                                        [Page 27]

Internet Draft          Experiments with RFC 3077              July 2003

   38/40 rue du General Leclerc
   92131 Issy-Les-Moulineaux Cedex
   Phone: (+33) 1 45 29 64 67
   EMail : yann.codaccioni@rd.francetelecom.com

   Emmanuel Duros
   2455 Route des Dolines BP355
   06906 Sophia Antipolis France
   EMail : Emmanuel.Duros@UDcast.com

   Virginie Faineant
   France Telecom R&D
   38/40 rue du General Leclerc
   92131 Issy-Les-Moulineaux Cedex
   Phone: (+33) 1 45 29 49 77
   EMail : virginie.faineant@rd.francetelecom.com

   Godred Fairhurst
   Department of Engineering
   Fraser Noble Building
   University of Aberdeen
   Aberdeen AB24 3UE
   Email: gorry@erg.abdn.ac.uk
   Web: http://www.erg.abdn.ac.uk/users/gorry

   Achmad Husni Thamrin
   Graduate School of Media and Governance
   Keio University
   5322 Endo, Fujisawa
   Kanagawa 252-8520
   Email: husni@ai3.net

   Amine Lamani
   France Telecom Research and Development
   Satellite Networks Architecture
   38-40, rue du General Leclerc, 92794

   Jun Takei
   JSAT Co.
   1-11-1 Marunouchi, Chiyoda-ku

Authors                                                        [Page 28]

Internet Draft          Experiments with RFC 3077              July 2003

   Tokyo 100-6218
   EMail : takei@csm.jcsat.co.jp

10. Full Copyright Statement

   "Copyright (C) The Internet Society (date). 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
   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

   The limited permissions granted above are perpetual and will not be
   revoked by the Internet Society or its successors or assigns.

11. IANA Considerations

   There are no IANA considerations associated with this draft.

Authors                                                        [Page 29]