[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: Comments to UDRL draft
I am sorry, that I am asking these kind of questions
in this stage of specification work, but I thought that
UDLR work was targeted to situations like UDL between
routers in relatively complex routing system (in backbone),
but now I realized that it tries to solve also lots of
other problems. So, probably the reason behind all this
is that I have grown in area (in Finland), where people
are known to be "slow".
>Emmanuel Duros wrote:
> > Harri Hakulinen NRC/Tre wrote:
> > I would claim, that it is not supported in
> > particularly scalable way. In Section 8.1 it
> > is assumed, that normal (ethernet)style ARP
> > is used in broacast feed.
> >...
> The link layer tunneling mechanism was designed in a scalable way
> without considering higher level protocols. The DTCP protocol does not
> generate significant traffic whatever the number of feeds or receivers.
That is true.
> However, as you mention it, an ARP traffic such as ARP responses
> encapsulated by receivers and sent to feeds may generate a sinificant
> traffic.
That's why I think that ARP issue should be left out of UDRL spec.
Actually, UDRL protocol should be capable to "signal" what
kind of ARP is used in this particular UDL.
I think that this was already in some version of the spec ?
> In this particular case of UDLs, we should think of redesigning ARP
> mechanisms in order to not overload the internet with responses. Beside
> ARP, IGMP is another protocol which is not well designed to work with
> UDLs. This is one item to talk about in Chicago...
I think that the danger is, that receivers are overloaded
more easily than Internet, if "Ethernet style" ARP is used.
In my mind there is a place for e.g. "DVB ARP" spec.
> > Section 6.1 says:
> > & 4) an IP address different from the previous cases
> > & (any IP address): the datagram is discarded.
> > & Packets whose destination does not belong to
> > & the unidirectional link are discared. Routing
> > & is not allowed, see Section 8.2.
> > Why discarded ?
> > I guess it is job of routing protocols to
> > affect to routing tables so, that these
> > packets are not send to tunnel, if that
> > is what is wanted (as is said in 8.2 ).
>
> In this case, routing IP traffic can be performed efficiently without
> the need of routing the traffic from the receivers to the feeds using
> the link layer tunneling mechanism.
>
> RIP as an example: a receiver must not take into account routes
> announced by feeds.
I am definitely not routing expert (that's why I
tried to stay away from UDRL in the first place),
but it seems logical that if feed announces routes
by using RIP (or some other routing protocol),
it puts high cost for those routes, because it
knows that cost of tunneling is rather high ?
(there is probably many hops in reverse tunnel)
BTW,
"RIP uses a very simple metric - the number of
hops in the path. ... it is not very advisable
to use RIP in a network mixing several links of
very different characteristics" ( from book
Routing in The Internet by Cristian Huitema,
Chapter 4.5.3 Support of Multiple Metrics )
> If it does, it will encapsulate IP datagrams (link layer tunnel) and
> will send the packets to the corresponding feed. This feed will then
> decapsulates the IP packets and will forward them to the next
> terrestrial router.
This may be the target, see Mobile IP references later.
> If it does not, the receiver has learnt how to reach the destination
> from a terrestrial neighbore router and will forward the traffic to
> it.
> In both cases the packets reach their destination. However the second
> is prefered because:
> - there is no processing due to the link layer encapsulation as in
> the first case
> - use of 'classical routing': no extra [IP,GRE] header added to every
> IP packet, does not overload unnecessary the Internet
> - the packet follows the 'physical shortest path' to the destination
> which is not the case when packets are encapsulated
To my understanding, there is lots of tunneling happening
in Internet for various reasons nowadays. I can't see that
as a particular problem, except in slow, usually PPP based
access links.
> > And, if this approach is selected, as well you
> > should NOT send via tunnel unicast packets that
> > belong to the unidirectional network, because
> > obviously they are routed there anyway, even if
> > they are not send via tunnel.
> The link layer tunneling mechanism provides a means for emulating an UDL
> in a broadcast local network. Every node connected to this udl should
> listen to/talk to each other. When a receiver sends a packet to receiver
> unidirectional interface, the packet should be received as it was coming
> from the udl, i.e. its ttl must be decreased only by 1 and not by
> [number of routers] if the packet was sent via the Internet without
> encapsulation. Furthermore, the ARP protocol may be required to work
> between receivers, this is only possible using the link layer tunneling
> mechanism.
ARP is probably separate issue also in this sense, because it
is not (usually) based on IP packets. But I still think, that
_if_ you want to prevent general unicast traffic on tunnel,
it is more logical to prevent it all. But personally I am not
in favour of preventing it.
> > Sometimes, like in Mobile IP it is requirement to
> > tunnel all "return traffic" back to "home subnet".
> > Why it is denied here ?
>
> For technical reasons (see above), it seems more efficient to prevent
> the whole traffic from being routed to the feed/"home subnet".
> Maybe there are security or commercial reasons to consider this ?
At least in the case of DVB link, receiver may be STB or PC,
which acts like router to home network or other (small)
domain or it may even be (multihomed) host itself.
Obviously you can't easily trust very much to these
kind of entities.
For security reasons, see
Reverse Tunneling for Mobile IP (RFC 2344)
ftp://ftp.isi.edu/in-notes/rfc2344.txt
--->
Computer Emergency Response Team (CERT), "IP Spoofing Attacks
and Hijacked Terminal Connections", CA-95:01, January 1995.
ftp://info.cert.org/pub/cert_advisories/CA-95:01.IP.spoofing
Ferguson, P., and D. Senie, "Network Ingress Filtering: Defeating
Denial of Service Attacks which employ IP Source Address
Spoofing", RFC 2267, January 1998.
ftp://ftp.isi.edu/in-notes/rfc2267.txt
Commercial reason might be, e.g. that satellite operator
may want to act like ISP, and in this case there may be
reasons to use topologically correct reverse tunnel.
> > Section 7.1 says:
> > > In our case, only the support of the MAC addressing
> > > scheme of the unidirectional link MUST be implemented.
> > > Note, this MAC level packet can carry an IP packet or
> > > an ARP packet.
> > What is ment here ? Somehow this sentence is
> > contradigting with previous Section (7.) ?
>
> I have just read this part and it is a bit confusing. I will make it
> clearer, it is meant MAC>GRE>IP in 7.1 and 7.
Why MAC>GRE>IP ??
I guess that you can encapsulate both ARP and IP
packets by using GRE without MAC.
So, why to send/use MAC here ?
And, if you don't use MAC here, you don't need MAC
address for for feed router, right ?
(remember recent mails considering lack of
sender MAC address in DVB IP encapsulation)
> > Section 7.2 says:
> > > An alternative is to encapsultate the MAC level packet
> > > within IP. The protocol field in the IP datagram is
> > > then set to the MAC level type of the unidirectional link.
> > IP protocol = MAC level type ?
> > What are these MAC level types ?
>
> They are not defined yet !
> Standard MAC level types should be defined for specific UDLs such for
> satellite links (IETF ipsat ?). And then specified as "Internet Assigned
> Numbers"...
Why not to stay in IP level and use some of already known
tunneling mechanisms ?
--
Harri.Hakulinen
@research.nokia.com Play the Snake
Visual Communications http://www.nokia.com/snake/
Tampere/Finland