Subject: Re: [MOBILE-IP] Proposed clarification to RFC2002bis

From: Vipul Gupta <[email-masked]>
Date: Wed, 8 Dec 1999 12:00:15 -0800

Please ignore the second paragraph here. Upon further review
   I relaize that the MN cannot really use a private HA address
   (there will be enough other problems besides the one I mention
   and the MN will have to use a public HA address).

   vipul
>
>   This is an interesting point worth further discussion.
>
>   I like Alternative 1 as well since Alternative 2 may cause
>   potential problems for certain tunnel drivers. In a specific
>   tunnel driver implementation I'm aware of :-), the foreign
>   agent needs to know the outer source address of incoming tunneled
>   packets before it can enable IPinIP decapsulation as part of
>   receiving a successful reply. The only address available
>   in the reply is the HA's so the FA cannot enable successful
>   decapsulation if the HA subsequently uses a different address
>   for the outer src.
>
>   But this gets interesting when we think of private addresses.
>   An MN on net-10 is likely to use a net-10 HA in registrations
>   but if the HA uses a private address as source in the outer
>   header, there can be potential problems. For example,
>   with PMTU discovery -- if an intermediate router needs to
>   send an ICMP message saying "DF set but fragmentation required",
>   the response to the HA's private address will never reach
>   the HA.
>
>   vipul
>
> > Hi all,
> >
> > I recently sent a question concerning the entry point of
> > forward tunnels. The exact entry point of the forward tunnel is not
> > clearly specified in RFC2002bis. I think this might cause interoperability
> > problems.
> >
> > Therefore, I'd like to propose one of the following clarifications to
> > be added to Section 4.2.3 of RFC2002bis:
> >
> > Alternative 1
> >
> > For multihomed home agents, the source address in the outer IP header of
> > the encapsulated datagram MUST be the address that the mobile node used in
> > the home agent field of the registration request. That is, the home agent
> > cannot use the the address of some other network interface as the source
> > address.
> >
> >
> > Alternative 2
> >
> > For multihomed home agents, the source address in the outer IP header of
> > the encapsulated datagram can be the address of any network interface on
> > the home agent.
> >
> > I prefer alternative 1.
> >
> > Regards,
> > Henry
>

---

From: Qiang Zhang <[email-masked]>
Date: Wed, 8 Dec 1999 15:18:57 -0500

I second Vipul's opinion that HA has to use the assistance of another
Public address entity in the VPN scenario.

Regarding the 2 alternatives, I dont understand why want to eliminate the
possibility that multi interfaces HA can borrow another interface to send
the packet, is it only because certain implementation has to have the
requirement?
Shine a light on me...

Best Regards
-Qiang