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

From: Henry Haverinen <[email-masked]>
Date: Wed, 8 Dec 1999 18:37:29 +0200

Hello Charlie,

> Alternative 1 would be fine as long as the home agent could
> still send the tunneled packets from any of its network
> interfaces.  Alternative 2 sort of gives this freedom automatically.
> Can you describe how specifying alternative 1 would be beneficial
> for your implementation?

Alternative 1 may be easier to implement on foreign agents and mobile nodes,
as
the exact entry point of the tunnel is known at the exit point. For example
when creating
tunnels on Windows 2000, you need to give a specific IP address for the
remote end of
the tunnel.

However, this isn't very important to me. Alternative 2 is fine too.

Regards,
Henry

---

From: Vipul Gupta <[email-masked]>
Date: Wed, 8 Dec 1999 11:42:24 -0800

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: Henry Haverinen <[email-masked]>
Date: Thu, 9 Dec 1999 09:51:43 +0200

Hello Qiang,

> 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?

I don't think it is a big deal which alternative we pick, as long
as we pick one.

The reverse tunnelling RFC specifies the source IP address of
reverse-tunnelled datagrams to be the care-of address. Thus, a multihomed
foreign
agent doesn't have the freedom of using the address of another network
interface.
Alternative 1 would be consistent with this.

Regards,
Henry