Subject: [MOBILE-IP] RFC 2344 Reverse Tunnel Broadcast/Multicast clarification

From: Kent Leung <[email-masked]>
Date: Thu, 2 Nov 2000 07:57:05 -0800

RFC 2344 Reverse Tunnel clarification request:

Here's the section:
------------------------------------------------------------
5.3. Support for Broadcast and Multicast Datagrams

    If a mobile node is operating with a co-located care-of address,
    broadcast and multicast datagrams are handled according to Sections
    4.3 and 4.4 of the Mobile IP specification [1]. Mobile nodes using a
    foreign agent care-of address MAY have their broadcast and multicast
    datagrams reverse-tunneled by the foreign agent.  However, any mobile
    nodes doing so MUST use the encapsulating delivery style.

    This delivers the datagram only to the foreign agent.  The latter
    decapsulates it and then processes it as any other packet from the
    mobile node, namely, by reverse tunneling it to the home agent.

------------------------------------------------------------

This doesn't seem to cover how FA should deal with reverse tunnel in Direct
Delivery Style?  What is the explicit behavior of FA when it receives
broadcast/multicast datagrams from MN in this Delivery mode?  Should FA
drop these packets since RFC is stating that Encap Delivery Style MUST be
used by MN?  Or should FA process them itself (which means local, not
reverse tunneling)?

Note that agent solicitations may be multicasts.

I'm interpreting that FA should process these packets, as in default
non-reverse tunnel behavior.  But would like to get explicit
definition.  Thanks.

-- Kent --

---

From: Samita Chakrabarti <[email-masked]>
Date: Sun, 5 Nov 2000 13:46:05 -0800

> non-reverse tunnel behavior.  But would like to get explicit

In our implementation of direct delivery mode, multicast/broadcast packets are
not reverse tunneled and FA performs it's usual processing for multicast
and broadcast packets.

-Samita

---

From: Samita Chakrabarti <[email-masked]>
Date: Fri, 17 Nov 2000 14:16:53 -0800

Hi Gabriel,

> both of you interpret the document as it was intended. this interpretation was
not made
> explicit. i'm not sure this is such a terrible oversight, as it does seem that
people draw the
> same conclusion you have drawn. at any rate, the revised version was already
sent
> to the IESG and approved for publication on oct 27. from the IESG queue:
>
> 2000/10/27   draft-ietf-mobileip-rfc2344-bis-02.txt

I think you meant draft-ietf-mobileip-rfc2344-bis-03.txt --right ?

> EDIT/IANA
> G. Montenegro
> Reverse Tunnleing for Mobile IP, revised
>
> this may not mean that it's impossible to add some clarifying text, but it
might not
> be worth it unless it's really essential.
>
> -gabriel
>

I agree with you. Personally I don't have any issues on the implied
interpretation as mentioned above.

Thanks,
-Samita