Loh Chong Sim | 16 Jun 04:45 2005
Picon

DTCP issues on IPv6

Hi all,

Recently I have a short discussion with Dr. Jun Takei about DTCP
issues on IPv6 network. As Dr. Jun Takei said that it is not difficult
to apply the DTCP function on IPv6 network. The problem is because of
PMTU discovery function which might give some impact to DTCP.

AFAIK on the RFC3077 the requirement only defined on IPv4 network so
far. But I seen there is the DTCP available on BSD distro. Is it mean
that this DTCP couldnt support fully IPv6 yet?

I would like to know more what those issues should be carefully
studied on RFC3077 in term to implement IPv6 on it.

Anyway I still new in this field. 

Thank you.

Regards,
Loh Chong
Mansoor Ganji | 10 Nov 07:47 2004
Picon

Fw: MDaemon Warning - Virus Found

Hi
please check to see what's the problem with your mails? Our antivirus as you
see attached alerts me that your emails contains viruses.

Regards
Mansoor Ganji
10 Nov 2004

----- Original Message ----- 
From: <Postmaster <at> dci.ir>
To: <ganjim <at> dci.ir>
Sent: Tuesday, November 09, 2004 9:35 PM
Subject: MDaemon Warning - Virus Found

> The following message had attachment(s) which contained the viruses:
>
> From      : udlr-admin <at> udcast.com
> To        : ganjim <at> dci.ir
> Subject   :
> Date      : Tue, 09 Nov 2004 15:28:23 -0300
> Message-ID: <iuacftsrpucgebcbgre <at> udcast.com>
>
> Attachment                    Virus name               Action taken
> --------------------------------------------------------------------------
----
> Music_MP3.zip                 ???                      Removed
>
>
Izu | 2 Sep 19:52 2004
Picon

Re:

>Animals

Password:

Attachment (New_MP3_Player.zip): application/octet-stream, 34 KiB
William StanisLaus | 20 May 09:02 2004
Picon

RFC 3077 Security Issues

Hello,
	There are Security issues with ULDR during L2 tunneling through GRE from
receiver to feed, which passes through the public network without any
encryption. By which any packet sniffer in the path can expose the satellite
private network information which is dangerous.

	Hence we should work out different method, not just L2 tunneling rather L2
entrypted tunneling using GRE to any other protocol.

Please pass on your suggestions.
Best Regards,
William StanisLaus | Technical Consultant - CalSoft, Nortel Networks
email: williams <at> calsoft.co.in | Telephone: +91 44 22541853, 22541464
Mobile: +91 98411 57902
www.calsoft.co.in
Evangelos Stergiou | 6 Jan 18:17 2004

UDLR over 1 ethernet interface

Hi all, I am new to udlr.
 
For testing udlr I have a PC connected to a cisco udlr-capable router.
My aim is to communicate with a remote udlr-capable satellite receiver.
That router has a 2 eth (1 to the PC, the other to my network and internet via a firewall).
I want to program my cisco and firewall so that outgoing data produced by the PC are sent by satellite
and responses are received by internet.
The firewall should NAT accordingly for outgoing and incoming traffic.
 
My problem is that, at first sight, cisco documentation describes 2 distinct interfaces for outgoing and incoming data.
I this compulsory or my configuration is OK?
 
Many thanks!
 
 
Alex Zinin | 3 Dec 22:50 2003

Re: WG Action: Conclusion of UniDirectional Link Routing (udlr)


I would like to thank Emmanuel and Izu for serving as the chairs of
this WG, as well as participants of this WG for contributing their
time and effort. Thank you, guys!

--

-- 
Alex

Wednesday, December 3, 2003, 12:20:00 PM, The IESG wrote:
> The UniDirectional Link Routing WG (udlr) in the Routing Area has concluded.

> The IESG contact persons are Bill Fenner and Alex Zinin.
Hidetaka IZUMIYAMA | 1 Dec 02:03 2003
Picon

Conference for Business Using Satellite Internet

WISHnet Inc. Bandung Meeting 2004
International Conference in Asia for Business Using Satellite Internet
              January 19-20, 2004 at Bandung, Indonesia

   WISHnet Inc. was established in May 2003 aiming to provide satellite
internet services.  Our initial aim is to focus on the standardization
of satellite internet technology, and then to contribute in providing
related business in Asia.
   Building and strengthening partnership in various areas such as R&D
and marketing is important in pursuing business in the region.
To deepen the understanding of satellite internet technology and
business as well as to give us opportunities to start building mutual
collaboration environment in partnership, we would cordially like to
invite you to join for the Bandung Meeting.
   This will be our first meeting and it is our pleasure to have you
with us to share the excitement of launching such meetings.  We look
forward to your participation in WISHnet Inc. Bandung Meeting 2004.

<Program>
Venue:              Sheraton Bandung Hotel & Towers (Bandung, Indonesia)
Dates:              January 19 - 20, 2004
Participation Fee:  US$ 50 per person (accommodation not included)
Expected participants:
          Those who have interest in business using satellite internet.

On-line registration and detailed programs are available on this URL:
                        http://www.wishnet.co.jp/en/bandung/index.html

-------------------------------------------
Hidetaka Izumiyama
President CEO, Wishnet Inc.

Cinq 101 5-15-10 Shirokanedai, Minato-ku
Tokyo, 108-0071, Japan
Email: izu <at> wishnet.co.jp
Tel.+81-3-5447-7130, Fax.+81-3-5447-7131
-------------------------------------------
Alex Zinin | 22 Nov 02:21 2003

Evaluation of WG progress and potential

Folks-

 The Area Directors and the WG chairs discussed current status and
 potential of the UDLR WG and agreed that given the level of interest
 and activity in the WG during the past year we should close the WG.
 The current WG internet draft will be reclassified as an individual
 contribution. The mailing list, however, will remain operational. If
 there is ever an increased level of interest in UDLR-related topics,
 creation of a WG with a new charter can be requested through regular
 IETF procedures.

 We would like to thank all UDLR participants for their efforts.

 Please contact the ADs and the WG chairs if you have any questions or
 comments.

Alex & Bill
IETF RTG Area Directors
Emmanuel Lety | 25 Aug 16:19 2003

I-D: add new PIM-DM Section

Hi All,

I just wrote and committed Section 4.4.2 Dense Mode PIM-DM
You can now get the new version of draft-ietf-udlr-experiments
from the CVS repository.

Thanks,
Emmanuel.

-- 
UDcast: Full IP over Broadcast Media        http://www.UDcast.com
Phone: (+33) (0)4 93 00 16 69,       Fax : (+33) (0)4 93 00 16 61
2455, Route des Dolines, BP 355, F-06906 Sophia Antipolis, France
4.4.2 Dense Mode PIM (PIM-DM)

4.4.2.1 Topology

   In order to study the advantages and limitations of a PIM-DM
   deployment in a UDLR context, we focus here on a typical Multicast
   Intranet topology. One feed and many receivers are connected via a
   unidirectional link, all running the PIM-DM multicast routing
   protocol. In this context, the feeds' and receivers' bi-directional
   interfaces do not need to be multicast enabled. Typical applications
   for such an infrastructure could be e-learning applications, video-
   conferencing tools, large-scale virtual environments, or reliable
   multicast files transfer, where both data and control multicast
   traffic could be generated by any end-host on any attached subnet.

                            Unidirectional Link
      ----------------->----------------->------------------->---------
      |                         |                      |
      |fu                       |r1u                   |r2u
   --------   -------        --------   -------     --------   -------
   |Feed  |--|subnet0|       |Recv1 |--|subnet1|    |Recv2 |--|subnet2|
   |PIM-DM|  --------        |PIM-DM|   -------     |PIM-DM|   -------
   --------                  --------               --------
      |fb (multicast            |r1b (multicast          |r2b (multicast
      |    disabled)            |     disabled)          |     disabled)
      -----------------------------------------------------------------
      |                       Internet
      -----------------------------------------------------------------
            Figure 1 : Typical UDLR - Multicast Intranet Topology

   As described in [DRAFT-PIM-DM-NEW], PIM-DM uses the Multicast Routing
   Information Base (MRIB) derived from the unicast routing table, to
   make decisions regarding Reverse Path Forwarding (RPF) interfaces and
   neighbors. All the nodes (feed and receivers) in Figure 1 implement
   the UDLR protocol, which implies that any PIM-DM node can reach any
   other PIM-DM node as if they were all PIM-DM neighbors, connected to
   the same ethernet LAN. Thus, for Recv1 the RPF neighbor toward
   subnet2 is Recv2, and NOT the Feed, which is only the RPF neighbor
   toward subnet0.

4.4.2.2 Advantages

   PIM-DM has several advantages compared to other multicast routing
   protocols :

   1. It scales much better than DVMRP, as it does not need to carry the
   complete neighbor list for each Hello/Probe messages and to run its
   own specific topology discovery protocol.

   2. Even if PIM-DM is part of the flood-and-prune multicast protocol
   family, PIM-DM uses state-refresh messages which minimize periodic
   flooding of data to maintain state for a given (S,G) entry.

   3. PIM-DM has a simplified design compared to PIM-SM, without any
   Rendez-Point selection, Shortest-Path Tree switching, Register-
   encapsulation/Native Forwarding switching, MSDP interaction, etc.
   This simplified design could be a significant advantage in order to
   adapt the protocol to the specific constraints of a unidirectional
   link.

   4. Unlike IGMP-Proxy - which is not a multicast routing protocol -
   PIM-DM prevents the permanent flooding on the unidirectional link of
   downstream sources located on the attached subnets of UDLR receivers.

4.4.2.3 Limitations

   The deployment of PIM-DM on unidirectional links raises several
   issues, due to two main reasons :

   - the number of PIM-DM receivers, i.e. PIM-DM neighbors, could be
   very large.

   - the round trip delay could be much more important than an ethernet
   LAN, especially between two PIM-DM receivers (twice the delay between
   a receiver and the feed).

   Among these issues, we detail the following :

    1. Prune and Join
    2. Unicast Graft/Graft-ack
    3. Reverse Path Forwarding
    4. Assert Election

   Prune and Join

   For a given attached network, as soon as the last member of a
   multicast group sends an IGMP-v2 Leave message, its connected PIM-DM
   receiver has to prune explicitly each upstream PIM-DM router for
   every existing (Si,G) entry. Indeed, [DRAFT-PIM-DM-NEW] specifies
   that PIM-DM routers MUST set the Upstream Neighbor Address field to
   the RPF next hop. Moreover, each Prune sent on the UDL can generate
   one or several overriding PIM-DM Joins, if other PIM-DM receivers are
   in forwarding mode for these (Si,G) entries. In the case of large
   round trip times on the UDL, the number of overriding Joins can also
   aggravate a potential Prune storm happening at the end of a multicast
   session (where 90% of the session members un-subscribe in a short
   time interval).

   Note that a PIM-DM Prune message storm may not only waste bandwidth
   on the unidirectional link, but also may create congestion at the
   feed where all the UDLR GRE return channels converge. In addition,
   congestion at the feed will increase the probability of losses in
   PIM-DM Join, which again may lead to a PIM-DM Join message storm.

   Unicast Graft/Graft-ack

   For a given attached network, as soon as the first member of a
   Multicast Group sends a IGMP-v2 Report message, its connected PIM-DM
   receiver has to graft explicitly each upstream routers for every
   (Si,G) entry, even if the traffic is already flooding on the UDL.
   Unlike PIM-DM multicast Join messages that are cancelled by other
   PIM-DM Join messages, a PIM-DM unicast Graft will not be canceled by
   another Graft sent for the same (S,G) entry. Thus, simultaneous
   Graft/Graft-Ack message increase again the probability of a PIM-DM
   message storm.

   Reverse Path Forwarding

   Each receiver needs to have an up-to-date unicast routing table, that
   allows it to reach in unicast any source on any attached network.
   Indeed, in order to get the right RPF neighbor toward any source,
   PIM-DM assumes that this information is already available. However,
   in a UDLR context, UDLR receivers may have a simplified unicast table
   where the default unicast gateway is the Feed Unidirectional
   Interface (FUIP). In this case, a PIM-DM receiver will never be
   pruned by another PIM-DM receiver, as the upstream neighbor field of
   the PIM-DM Prune message will always be set to the FUIP. Moreover,
   maintaining all the unicast routing tables up-to-date on every UDLR
   receivers has a potentially significant cost (memory occupation,
   messages exchanges, etc..) as the number of PIM-DM receivers starts
   to be large.

   Assert Election

   Unlike PIM Hello messages where a PIM-DM router answers to a new
   Hello message after a random delay, there is no timer before sending
   a PIM-DM Assert in reply to an inferior Assert [DRAFT-PIM-DM-NEW],
   i.e. an Assert with a higher value of metric_preference. Once again,
   PIM-DM needs to be adapted in order to scale with the number of PIM-
   DM neighbors on a UDL.

4.4.2.4 Security issues

   Among the different attacks based on forged PIM-DM messages, an
   attack based on forged Assert messages could result in dramatic
   effects. Fortunately, forged Hello/Prune/Join messages will have a
   less significant impact on a multi-access LAN with a large number of
   PIM-neighbors, since any legitimate PIM neighbor will Prune/Join a
   forged Join/Prune message.

   We distinguish two kinds of attacks based on PIM-DM Assert :

   1. Forged Inferior Assert (using very high value of metric_preference
   and route_metric) could generate a PIM-DM Assert storm on the
   unidirectional link (See Section 4.4.2.3).

   2. Forged Preferred Assert (using very low value of metric_preference
   and route_metric) could cause the legitimate forwarder to stop
   forwarding traffic on the unidirectional link.

4.4.2.5 Conclusion

   It appears that the deployment of PIM-DM on such an infrastructure
   may suffer from both scalability and security issues. However, the
   simplified design of this multicast protocol and the list of
   advantages listed in Section 4.4.2.2 still make it an ideal candidate
   for a specific adaptation to support unidirectional links. Over the
   unidirectional link the protocol could be adapted to take into
   account the remarks presented in this Section, whilst remaining fully
   compliant with a PIM-DM classical implementation over terrestrial
   links.
Fethi Filali | 31 Jul 15:52 2003
Picon
Picon

Paper on Multicast Support over "next-generation" DVB-based satellite systems

Hi,

I would like to announce you our work on multicast support over 
DVB-based satellite systems that will appear in JSAC Journal which I 
guess may interest some of you:

Title:
Efficient Support of IP Multicast in the Next-Generation of GEO Satellites

Abstract:

The satellites are expected to have an important role in providing the 
IP multicast service to complementing next generation terrestrial networks.
In this paper, we focus on the deployment of IP multicast over the 
next-generation of DVB-based GEO satellites supporting multiple 
spot-beams and on-board switching technologies. We propose a new 
encapsulation scheme optimized for IP multicast which has two distinct 
modes enabling two alternative on-board switching approaches: the 
self-switching and the label-switching. We also detail a set of 
mechanisms and protocols for ground stations as well as for the on-board 
processor to allow an efficient multicast forwarding in such type of 
environment, while reducing the load of control and data messages in the 
satellite segment, and building efficient multicast delivery trees 
reaching only the spot beams containing at least one member of the 
corresponding multicast session.
To integrate satellite links in the terrestrial Internet, we present 
SMAP (Satellite Multicast Adaptation Protocol), a protocol which is 
implemented in satellite stations to process incoming PIM-SM messages 
sent by terrestrial nodes to the satellite system. SMAP helps to update 
the tables required for the mapping between IP packets and MPEG-2 data 
segments, their switching on-board the satellite, and their filtering at 
the satellite receivers.

The paper is available at :
ftp://ftp-sop.inria.fr/rodeo/filali/pub/filali-jsac03.pdf

Regards,
Fethi Filali.
Achmad Husni Thamrin | 29 Jul 13:14 2003
Picon

Experiment I-D: write DVMRP

Dear All,

I wrote the DVMRP section and just commited the Experimental I-D.
Comments please.

Thank you,
--

-- 
Achmad Husni Thamrin <husni <at> ai3.net>

Gmane