Re: [Mip4] New ID: End Node based IP Mobility
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

Re: [Mip4] New ID: End Node based IP Mobility



Hi Subrata,

Thank you for writing this concise ID. I have a few question:

1. Section 2: "...The CN would still use ipx1 as destination address for all
outgoing packets, which would result in all packets sent to subnet X2..."
Are you trying to say "...all packets sent to subnet X1."?

2. It seems you are trying to use only end nodes to support mobility. And as
you have pointed out, how subnet changes are detected is beyond the scope of
this document. However, IMHO, it is hard to quickly detect subnet changes
quickly without the network assistance. Also, how does the access network
know it should offer service to the MN without any securtiy entities in the
network for supporting mobility?

3. It seems you are considering the case that the MN can only communicate
with one access subnet at a time. Therefore, the CN receiving Subnet Change
Challenge responses from both old and new subnets could be viewed as
spoofing. What if the MN can simultaneously communicate with both new and
old access subnets at least during handovers? Are you assuming the MN always
sends only one Subnet Change Challenge response in this case?

4. Without the network assistance, how do you suppose to handle those
mis-routed packets to the old subnet after the MN connects to the new
subnet?

The ID looks like a simple interesting idea, but it seems a lot of issues
are waiting to be considered. Maybe you think it could be too earlly?

Jee

----- Original Message ----- 
From: "subrata goswami" <sgoswami at umich.edu>
To: <mip4 at ietf.org>
Sent: Thursday, February 10, 2005 7:39 PM
Subject: [Mip4] New ID: End Node based IP Mobility


> A new Internet Draft is available on mobility support in IP networks.
>
> Title: IPv4 Mobility through Peer Signaling
>
> ID: draft-goswami-mip4-peer-signaling-00.txt
>
> Abstract:  This document describes a way to perform mobility in IPv4
> (potentially IPv6) without requiring any new entity in networks
> infrastructure (e.g. Home Agent, Foreign Agent, etc.). Instead of using
> infrastructure entities this method delegates all the mobility function
> to the end nodes. The method relies on source and destination address
> translation at the end nodes, and signaling between end nodes to perform
> hand offs - all these function can be encapsulated in an entity called
> Mobility Agent (MA) in the end nodes.
>
> URL:
> https://datatracker.ietf.org/public/idindex.cgi?command=id_detail&id=12788
>
>
> -- 
> Mip4 mailing list: Mip4 at ietf.org
>     Web interface: https://www1.ietf.org/mailman/listinfo/mip4
>      Charter page: http://www.ietf.org/html.charters/mip4-charter.html
> Supplemental site: http://www.mip4.org/
>


-- 
Mip4 mailing list: Mip4 at ietf.org
    Web interface: https://www1.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/




Note: Messages sent to this list are the opinions of the senders and do not imply endorsement by the IETF.