Subject: (mobile-ip) Mobile IP Minutes from L.A.

From: Jim Solomon <[email-masked]>
Date: Wed, 22 Apr 1998 17:53:56 -0500

Greetings,

Here are the minutes from L.A.  Thanks to William Fisher for taking
notes.

Ms. Walker -- the slides for the proceedings will be sent in a
subsequent E-mail.

Regards,
Jim Solomon
Co-chair, mobileip wg

___________________________________________________________________________

           IP Routing for Wireless/Mobile Hosts (mobileip)
                    Thursday, April 2 at 1300-1500

Co-chairs:
Erik Nordmark, Sun Microsystems, <[email-masked]>
Jim Solomon, Motorola, <[email-masked]>

Minutes by: William Fisher <[email-masked]>
heavily edited by: Jim Solomon <[email-masked]>

I. IPv4 Update (Jim Solomon, Motorola)
======================================

1. Mobile-IPv4 Configuration Option for PPP IPCP <rfc2290.txt>
   => now a PROPOSED STANDARD RFC.

2. Reverse Tunneling for Mobile IP, <draft-ietf-mobileip-tunnel-reverse-05.txt>
   => awaiting IESG Last Call for PROPOSED STANDARD RFC.

3. Firewall Support for Mobile IP <draft-montenegro-firewall-sup-03.txt>
   => awaiting IESG Last Call for INFORMATIONAL RFC.

Issues
------

Encapsulator use and honoring of the 'DF' flag -- Some (broken!) hosts
are setting DF and not backing off when they receive ICMP Destination
Unreachable (fragmentation needed and DF set).  Proposal to change
RFC2003 to say that an encapsulator SHOULD set DF bit in encapsulating
packet instead of MUST.  Observation that this breaks Path MTU
discovery for well-behaved hosts.  [It turns out that the ICMP
Unreachable was being filtered by a firewall and never arrived at the
correspondent host.  This is a deployment issues that needs to be
undestood and documented. -- JDS].

[Perkins] Are we ready to go to Draft Standard from Proposed Standard
for RFC 2003?
[Solomon] We don't have sufficient implementation experience.

II. Mobility Support in IPv6 (David Johnson, CMU)
=================================================

Consensus on the following items from IPNGWG:
 - Add (H) bit in Router Advertisements to allow home agents to send a
   list of candidate home agents to mobile nodes doing Dynamic Home
   Agent Address Discovery;
 - New Advertisement Interval option for Router Advertisements to
   allow mobile nodes to actively determine when they've missed one;
 - Allowing routers to advertise more frequently than specified in
   base IPv6 document(s) in order to provide better service to mobile
   nodes.

Unresolved issues:
 - IANA:  Steve Deering and Dave Johnson to make a proposal regarding
   carving up the unicast space for anycast addresses;  Bob Hinden
   will serve as clearinghouse for the various option codes required
   by Mobile IPv6;
 - How do IPv6 implementors learn of the requirements conferred upon
   them by Mobile IPv6; namely, that *all* IPv6 implementations MUST
   process the Home-Address Option?  Proposal to list all documents
   specifying such obligations on the IPNGWG web page until a "real"
   requirements RFC can be written.

Since router advertisements are sent from link-local address, how does
mobile node ever learn home agent's global address?  Consensus that a
Global Address option (extension?) could be defined for Router
Advertisements in which Home Agents can place their global address.

Consensus that no one is really capable of defining what a "site" is
in the IPv6 architecture; thus, what should the Mobile IPv6 document
say about forwarding such addresses to mobile nodes by home agents?
In order to make progress, there was some consensus that we say that
an HA SHOULD forward site-local addresses and that this behavior
SHOULD be configurable.

Consensus on not adding new mechanism to distinguish preference among
the list-o-routers returned to a mobile node performing Dynamic Home
Agent Address Discovery.

Discussion about Mobile Networks, though it is uncertain what is being
lost in IPv6 compared to IPv4 mobility.  After further review, it is
not obvious how to optimize routing to a "mobile passenger"; i.e.,
someone mobile with respect to a piece of topology that is itself
mobile with respect to the rest of the Internet.  Dave to clarify this
in the draft.

Consensus on "Binding Multiple Home Addresses":  if a mobile node has
multiple addresses, then it needs to send different Binding Update
options for each and every such address.  Consensus not to try to
define an N-way Binding Update option.

III. IP Private Address Identification (T. Teo, NUS)
====================================================

Microphone Q/A:

1) Why do you need PAID, Why not use SNAP?
2) Why not use reverse tunneling and NAT today since it works?

Presenter Answer:

What mechanisms are used in Mobile IP to implement this today,
Registration Messages!

3) What are the real benefits here, when adding the extra headers?

Presenter Answer: Wait until the next presentation is shown.

IV. Mobile IP extension for Private Internets Support (Y. Li, Bay Networks)
===========================================================================

Microphone Q/A:

1) PAID added after beginning and really work together.  MVPN AGents
installed on Border.
2) Are they expected to have knowledge to parse PAID headers
3) Registration Process
4) Regarding the Firewall Reversal Draft, how does this compare?
 a) The firewall draft does not address the presentation process
 b) Can also remove a Foreign Agent with PAID in certain instances.
-----------------------------------------------------------------------------
IETF Mobile IP Working Group Mailing List - Archives:  software.watson.ibm.com
Unsubscribe:	unsubscribe mobile-ip		(as message body, not subject)
Direct all administrative requests to [email-masked]