draft-ietf-udlr-experiments-00.txt   draft-ietf-udlr-experiments-01.txt 
Network Working Group Emmanuel Duros et al. Network Working Group For list of authors
Internet-Draft Internet-Draft See Authors' section
July 2003 Expires december 2003
Experiments with RFC 3077 Experiments with RFC 3077
<draft-ietf-udlr-experiments-00.txt> <draft-ietf-udlr-experiments-01.txt>
Status of this Memo Status of this Memo
This document is an Internet-Draft and is subject to all provisions This document is an Internet-Draft and is subject to all provisions
of Section 10 of RFC2026. 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 groupsmay also distribute working documents as Internet-Drafts. other groupsmay also distribute working documents as Internet-Drafts.
skipping to change at page 2, line 18 skipping to change at page 2, line 18
2. Description of Network Architecture ......................... X 2. Description of Network Architecture ......................... X
2.1. Topology .................................................... X 2.1. Topology .................................................... X
2.2. Multicast Forwarding over UDLR .............................. X 2.2. Multicast Forwarding over UDLR .............................. X
3.0. Layer 2 Protocols ........................................... X 3.0. Layer 2 Protocols ........................................... X
3.1. Hardware Address Resolution ................................. X 3.1. Hardware Address Resolution ................................. X
3.1.1 Hardware Address Resolution protocol over UDLR ............. X 3.1.1 Hardware Address Resolution protocol over UDLR ............. X
3.1.2 Issues using a hardware resolution protocol over UDLR ...... X 3.1.2 Issues using a hardware resolution protocol over UDLR ...... X
3.1.2.1 Long round trip delays ................................... X 3.1.2.1 Long round trip delays ................................... X
3.1.2.2 Large number of receivers ................................ X 3.1.2.2 Large number of receivers ................................ X
3.2. PPPoE ....................................................... X 3.2. PPPoE ....................................................... X
3.2.1 Introduction ............................................... X
3.2.2 Architecture ............................................... X
3.2.2.1 Specificities ............................................ X
3.2.2.2 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.0. Layer 3 Protocols ........................................... X
4.1. Dynamic Host Configuration Protocol ......................... X 4.1. Dynamic Host Configuration Protocol ......................... X
4.1.1. DHCP Overview ............................................. X 4.1.1. DHCP Overview ............................................. X
4.1.2. DHCP over UDLR ............................................ X 4.1.2. DHCP over UDLR ............................................ X
4.1.2.1. Configuration and tuning guidelines ..................... X 4.1.2.1. Configuration and tuning guidelines ..................... X
4.1.2.2. Security issues ......................................... X 4.1.2.2. Security issues ......................................... X
4.2. Issues using IGMP over UDLR ................................. X 4.2. Issues using IGMP over UDLR ................................. X
4.2.1. Basic IGMP Operation ...................................... X 4.2.1. Basic IGMP Operation ...................................... X
4.2.2. IGMPv2 Leave Processing ................................... X 4.2.2. IGMPv2 Leave Processing ................................... X
4.2.3. IGMPv3 Operation .......................................... X 4.2.3. IGMPv3 Operation .......................................... X
skipping to change at page 12, line 7 skipping to change at page 12, line 10
packet destined to it triggers the request of its new MAC address. packet destined to it triggers the request of its new MAC address.
- ARP table size adjustable. Receivers may not be constantly - ARP table size adjustable. Receivers may not be constantly
connected to the satellite link. During idle periods, it is then connected to the satellite link. During idle periods, it is then
not necessary to keep an ARP entry for these receivers. The size 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 of the ARP table can then be adjusted to the number of active
receivers. receivers.
3.2 PPPoE 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.
3.2.2.1 Specificities
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
server).
- 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.
3.2.2.2 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
Internet
- 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.
- 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
shaping).
- 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.0 Layer 3 Protocols
4.1 Dynamic Host Configuration Protocol 4.1 Dynamic Host Configuration Protocol
The Dynamic Host Configuration Protocol (DHCP) provides a framework The Dynamic Host Configuration Protocol (DHCP) provides a framework
for passing configuration information to hosts on a TCPIP network, for passing configuration information to hosts on a TCPIP network,
and a mechanism for automatic temporary allocation of network and a mechanism for automatic temporary allocation of network
addresses. addresses.
4.1.1 DHCP Overview 4.1.1 DHCP Overview
skipping to change at page 19, line 19 skipping to change at page 21, line 48
1. Reverse Path Forwarding 1. Reverse Path Forwarding
2. Rendezvous Point selection 2. Rendezvous Point selection
3. Designated Router selection 3. Designated Router selection
This section describes these issues in details. In this section, all 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 nodes are assumed to be PIM-SM routers (Scenario D) and the UDL runs
PIM-SM as the only multicast routing protocol. PIM-SM as the only multicast routing protocol.
Reverse Path Forwarding Reverse Path Forwarding
In the case of UDLR Receivers do not use the Feed Router to forward In the case of Receive networks do not use the Feed Router to forward
unicast traffic to multicast sources and the Rendezvous Point, the unicast traffic to multicast sources and the Rendezvous Point, the
receivers do not send PIM-SM Join/Prune messages to the Feed Router. receivers do not send PIM-SM Join/Prune messages to the Feed Router.
As the result, multicast traffic does not flow on the unidirectional As the result, multicast traffic does not flow on the unidirectional
link. This is the PIM-SM reverse path problem on unidirectional link. This is the PIM-SM reverse path problem on unidirectional
links. links.
There are two solutions, at least, for this problem: There are two solutions, at least, for this problem:
1. Configure UDLR receive networks to route unicast traffics to all 1. Configure UDLR Receive networks to route unicast traffics to all
possible multicast sources and Rendezvous Points via the Feed possible multicast sources and Rendezvous Points via the Feed
router. router.
2. Prevent multicast listeners in UDLR receive networks from 2. Prevent PIM-SM routers in UDLR receive networks from
switching to the shortest-path tree of multicast sources located switching to the shortest-path tree of multicast sources located
outside the receive network. In this scheme, the UDL receive outside the receive network. In this scheme, the UDL receive
networks only need to route unicast traffic to all possible networks only need to route unicast traffic to all possible
Rendezvous Points via the Feed Router. Rendezvous Points via the Feed Router.
If the possible multicast sources includes all hosts in the Feed If the possible multicast sources includes all hosts in the Feed
network, then the first option is to route traffic to 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 network via the Feed Router. The second option simplifies the routing
requirement from routing to all hosts in the Feed network to routing requirement from routing to all hosts in the Feed network to routing
to the possible Rendezvous Points. The second option, however, to the possible Rendezvous Points. The second option, however,
skipping to change at page 20, line 21 skipping to change at page 23, line 4
interface address is the only possible Rendezvous Point. interface address is the only possible Rendezvous Point.
In the case where no unicast routing protocol is running on the uni- In the case where no unicast routing protocol is running on the uni-
directional link and unicast routing advertisements are limited only directional link and unicast routing advertisements are limited only
within each Feed network and Receive network, the UDLR receive within each Feed network and Receive network, the UDLR receive
networks may use static routes. Static routes to the possible RPs via 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 Feed router are set on the UDL receivers and they are injected to
the receive network's unicast routing protocol. the receive network's unicast routing protocol.
Designated Router selection Designated Router selection
A PIM-SM router performs Designated Router election on each A PIM-SM router performs Designated Router election on each
interface. A DR has the task to send PIM-SM Register packets and to 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 send Join/Prune messages toward the RP or the multicast source. The
DR election is important for unidirectional links if multicast DR election is important for unidirectional links if multicast
listeners exist. If a multicast listener exists on a unidirectional sources exist. If a multicast source exists on a unidirectional link,
link, the Feed Router should be elected as the DR for the the Feed Router should be elected as the DR for the unidirectional
unidirectional link to avoid the overhead due to the LLTM mechanism. link to avoid the overhead due to the LLTM mechanism. In the Scenario
In the Scenario 5, DR election result is not important as all UDL D, DR election result is not important as all UDL nodes are multicast
nodes are multicast routers. routers.
A PIM-SM router sends Hello messages periodically every Hello_Period A PIM-SM router sends Hello messages periodically every Hello_Period
to each active inteface. In addition, a PIM-SM router also sends a 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 Hello message when Hello message is received from a new neighbor, or
a Hello message with a new GenID is received from an existing 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 neighbor. a PIM-SM router will remove a neighbor if it does not
receive any neighbor's Hello message in the HoldTime advertised by receive any neighbor's Hello message in the HoldTime advertised by
the neighbor. the neighbor.
The number of neighbors is an issue for flat networks (see 1.1.5). The number of neighbors is an issue for flat networks (see 1.1.5).
skipping to change at page 21, line 18 skipping to change at page 23, line 48
Join message suppression can reduce the bandwidth consumption of a Join message suppression can reduce the bandwidth consumption of a
shared link. For flat networks with many nodes or large round trip shared link. For flat networks with many nodes or large round trip
delay, a large Override interval will help. The large Override delay, a large Override interval will help. The large Override
interval value causes a large Prune Pending Timer, thus multicast interval value causes a large Prune Pending Timer, thus multicast
traffic will flow for a longer time on the unidirectional link even traffic will flow for a longer time on the unidirectional link even
though there is no more downstream routers. though there is no more downstream routers.
4.5.2 PIM-SM RPs and MSDP 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.
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
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
function.
5. Security Considerations 5. Security Considerations
The recommendations contained in this document do not impact the The recommendations contained in this document do not impact the
integrity of IP multicast transport protocols, or applications using integrity of IP multicast transport protocols, or applications using
IP multicast transport protocols. IP multicast transport protocols.
There are known Denial of Service (DoS) attacks that can be staged There are known Denial of Service (DoS) attacks that can be staged
... XXX 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
The broadcast nature of the forward feed... XXX 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.
There are known vulnerabilities when using tunnels.... XXX 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 6. Conclusions
7. Acknowledgements 7. Acknowledgements
8. References 8. References
8.1 Normative References 8.1 Normative References
[RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", STD [RFC826] Plummer, D., "An Ethernet Address Resolution Protocol", STD
37, RFC 826, November 1982 37, RFC 826, November 1982
[RFC1112] Deering, S.E., "Host extensions for IP multicasting", [RFC1112] Deering, S.E., "Host extensions for IP multicasting",
RFC1112, 1989, (STD0003). RFC1112, 1989, (STD0003).
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2131] R. Droms, "Dynamic Host Configuration Protocol", RFC 2131,
1997
[RFC2132] S. Alexander,R. Droms, "DHCP Options and BOOTP Vendor
Extensions", RFC 2132, 1997
[RFC2236] Fenner, W., "Internet Group Management Protocol, Version [RFC2236] Fenner, W., "Internet Group Management Protocol, Version
2", 1997, RFC 2236, (Proposed Std). 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., [RFC2784] Farinacci, D., Li, T., Hanks, S., Meyer, D., Traina, P.,
"Generic Routing Encapsulation (GRE)", RFC2784, (Proposed "Generic Routing Encapsulation (GRE)", RFC2784, (Proposed
Std). Std).
[RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y. [RFC3077] Duros, E., Dabbous, W., Izumiyama, H., Fujii, N., and Y.
Zhang, 'A Link-Layer Tunneling Mechanism for Unidirectional Zhang, 'A Link-Layer Tunneling Mechanism for Unidirectional
[RFC-IGMPv3] "Internet Group Management Protocol, Version 3", [RFC-IGMPv3] "Internet Group Management Protocol, Version 3",
(Author's note, with IESG - this reference needs to be (Author's note, with IESG - this reference needs to be
solved when issued as an RFC). solved when issued as an RFC).
8.2 Informative References 8.2 Informative References
[DRAFT-AVT-RTP-NEW] Schulzrinne/Casner/Frederick/Jacobson, "RTP: A [DRAFT-AVT-RTP-NEW] Schulzrinne/Casner/Frederick/Jacobson, "RTP: A
Transport Protocol for Real-Time Applications, <draft-ietf- Transport Protocol for Real-Time Applications, <draft-ietf-
avt-rtp-new-11.txt>, Work in Progress. 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
Progress.
[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 [DRAFT-MAGMA-SNOOP] M. Christensen, F. Solensky "IGMP and MLD
snooping switches", <draft-ietf-magma-snoop-02.txt>, Work snooping switches", <draft-ietf-magma-snoop-02.txt>, Work
in Progress. in Progress.
[DRAFT-MAGMA-PROXY] Fenner, B. et al, "IGMP-based Multicast [DRAFT-MAGMA-PROXY] Fenner, B. et al, "IGMP-based Multicast
Forwarding (IGMP Proxying)", <draft-ietf-magma- Forwarding (IGMP Proxying)", <draft-ietf-magma-
proxy-02.txt>, (Author's note: not in ID archive), Work in proxy-02.txt>, (Author's note: not in ID archive), Work in
Progress. Progress.
[DRAFT-PILC-ASYM] Balakrishnan, H., V. N. Padmanabhan, G. Fairhurst, [DRAFT-PILC-ASYM] Balakrishnan, H., V. N. Padmanabhan, G. Fairhurst,
M. Sooriyabandara, "TCP Performance Implications of M. Sooriyabandara, "TCP Performance Implications of
Network Path Asymmetry", <draft-ietf-pilc-asym-08.txt>, Network Path Asymmetry", <draft-ietf-pilc-asym-08.txt>,
Work in Progress. Work in Progress.
[DRAFT-PIM-SM-NEW] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas, [DRAFT-PIM-SM-NEW] W. Fenner, M. Handley, H. Holbrook, I. Kouvelas,
"Protocol Independent Multicast - Sparse Mode (PIM-SM): "Protocol Independent Multicast - Sparse Mode (PIM-SM):
Protocol Specification (Revised)", <draft-ietf-pim-sm- Protocol Specification (Revised)", <draft-ietf-pim-sm-
v2-new-05.txt>, Work in Progress. v2-new-07.txt>, Work in Progress.
[EN00] "Digital Video Broadcasting (DVB); Interaction Channel for [EN00] "Digital Video Broadcasting (DVB); Interaction Channel for
Satellite Distribution Systems", Draft European Standard Satellite Distribution Systems", Draft European Standard
(Telecommunications series) ETSI, Draft EN 301 790, v.1.1.1 (Telecommunications series) ETSI, Draft EN 301 790, v.1.1.1
[RFC1889] Schulzrinne H. , S. Casner, R. Frederick, V. Jacobson, [RFC1889] Schulzrinne H. , S. Casner, R. Frederick, V. Jacobson,
"RTP: A Transport Protocol for Real-Time Applications", "RTP: A Transport Protocol for Real-Time Applications",
1996, (Proposed Std). 1996, (Proposed Std).
[RFC2933] K. McCloghrie, D. Farinacci, D. Thaler, "Internet Group [RFC2933] K. McCloghrie, D. Farinacci, D. Thaler, "Internet Group
skipping to change at page 23, line 22 skipping to change at page 27, line 43
Guidelines for IPv4 Multicast Address Assignments", 2001, ( Guidelines for IPv4 Multicast Address Assignments", 2001, (
BCP0051) BCP0051)
[RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group [RFC3228] Fenner, B., "IANA Considerations for IPv4 Internet Group
Management Protocol (IGMP)", RFC3228, 2002, (BCP0057). Management Protocol (IGMP)", RFC3228, 2002, (BCP0057).
9. Authors' Addresses 9. Authors' Addresses
In alphabetic order: In alphabetic order:
Gilles Chanteau
France Telecom R&D
38/40 rue du General Leclerc
92131 Issy-Les-Moulineaux Cedex
France
Phone: (+33) 1 45 29 58 67
EMail : gilles.chanteau@rd.francetelecom.com
Yann Codaccioni
France Telecom R&D
38/40 rue du General Leclerc
92131 Issy-Les-Moulineaux Cedex
France
Phone: (+33) 1 45 29 64 67
EMail : yann.codaccioni@rd.francetelecom.com
Emmanuel Duros Emmanuel Duros
UDcast UDcast
2455 Route des Dolines BP355 2455 Route des Dolines BP355
06906 Sophia Antipolis France 06906 Sophia Antipolis France
France France
EMail : Emmanuel.Duros@UDcast.com EMail : Emmanuel.Duros@UDcast.com
Virginie Faineant
France Telecom R&D
38/40 rue du General Leclerc
92131 Issy-Les-Moulineaux Cedex
France
Phone: (+33) 1 45 29 49 77
EMail : virginie.faineant@rd.francetelecom.com
Godred Fairhurst Godred Fairhurst
Department of Engineering Department of Engineering
Fraser Noble Building Fraser Noble Building
University of Aberdeen University of Aberdeen
Aberdeen AB24 3UE Aberdeen AB24 3UE
UK UK
Email: gorry@erg.abdn.ac.uk Email: gorry@erg.abdn.ac.uk
Web: http://www.erg.abdn.ac.uk/users/gorry Web: http://www.erg.abdn.ac.uk/users/gorry
Achmad Husni Thamrin Achmad Husni Thamrin
skipping to change at page 24, line 5 skipping to change at page 28, line 49
Japan Japan
Email: husni@ai3.net Email: husni@ai3.net
Amine Lamani Amine Lamani
France Telecom Research and Development France Telecom Research and Development
Satellite Networks Architecture Satellite Networks Architecture
38-40, rue du General Leclerc, 92794 38-40, rue du General Leclerc, 92794
ISSY-LES-MOULINEAUX cedex 9 ISSY-LES-MOULINEAUX cedex 9
FRANCE FRANCE
Jun Takei
JSAT Co.
1-11-1 Marunouchi, Chiyoda-ku
Tokyo 100-6218
JAPAN
EMail : takei@csm.jcsat.co.jp
10. Full Copyright Statement 10. Full Copyright Statement
"Copyright (C) The Internet Society (date). All Rights Reserved. This "Copyright (C) The Internet Society (date). All Rights Reserved. This
document and translations of it may be copied and furnished to document and translations of it may be copied and furnished to
others, and derivative works that comment on or otherwise explain it others, and derivative works that comment on or otherwise explain it
or assist in its implementation may be prepared, copied, published or assist in its implementation may be prepared, copied, published
and distributed, in whole or in part, without restriction of any and distributed, in whole or in part, without restriction of any
kind, provided that the above copyright notice and this paragraph are kind, provided that the above copyright notice and this paragraph are
included on all such copies and derivative works. However, this included on all such copies and derivative works. However, this
document itself may not be modified in any way, such as by removing document itself may not be modified in any way, such as by removing
 End of changes. 19 change blocks. 
17 lines changed or deleted 266 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/