Subject: [mobile-ip] RE: RFC3220 and possible forward compatibility issue "Dynamic Hom e Agent Allocation"

From: "Ahmad Muhanna"<[email-masked]>
Date: Tue, 2 Apr 2002 10:08:58 -0600

Hello all; 

I am sorry for the spelling mistake in the proposed text.
Please see correction inserted.

Regards;
Ahmad Muhanna

>  -----Original Message-----
> From: 	Muhanna, Ahmad [RICH1:2Q20:EXCH]  
> Sent:	Monday, April 01, 2002 3:11 PM
> To:	'mobile-ip'
> Cc:	Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Charlie Perkins'; 'Pete McCann';
> Nickell, Kent [RICH2:2Q20:EXCH]
> Subject:	RFC3220 and possible forward compatibility issue "Dynamic
> Home Agent Allocation"
> 
> Hello all;
> 
> RFC3220 (RFC2002) proposes a mechanism for Dynamic Home Agent Resolution
> or allocation.
> Sections 3.6.1.1, 3.6.1.2, and 3.8.2.2 introduces this mechanism for the
> following two scenarios:
> 
> MN with a co-located IP address:
> i.  MN sets the destination IP address of the IP packet that contain the
> MN 
>     Registration Request to the subnet-directed broadcast.
> ii. RFC3220 does not specify what IP address the Mobile Node insert in the
> HA 
>     field in the RRQ message. However, it may be understood that it is the
> 
>     same IP address. "subnet-directed broadcast" Since it does not know
> its HA.
> iii. Home Agent listens to the subnet-directed broadcast and
> "255.255.255.255." 
>     as mentioned in the RFC3220.
> iv. Every Home Agent which receives this IP packet MUST reject the RRQ
> with a code
>     of 136 and insert its HA unicast IP address in the RRP message to the
> MN.
> v.  After MN receives all the RRP messages from the different HAs, it
> chooses which HA
>      to register with and then uses that HA IP address.
> 
> 
> MN with a FA Care-Of Address:
> i.  MN sets the destination IP address of the IP packet that contain the
> MN 
>     Registration Request to the FA Care-Of Address.
> ii. RFC3220 specify that MN MAY use the "subnet-directed broadcast" IP
> address in the HA 
>     field in the RRQ message.
> iii. RFC3220 does not specify what the FA SHOULD do when receiving an IP
> packet which
>     contains a RRQ message with a HA field is set to the "subnet-directed
> broadcast". 
>     It is basically very wise to do so by leaving the door open for future
> forward compatibility.
>     
>     However, IF FA just uses the same concept of the MN co-located IP
> address, 
>     then FA will forward the RRQ message to the HA "subnet-directed
> broadcast" by
>     inserting this address in the destination IP address of the IP packet
> containing 
>     the RRQ message.
> 
> iv. Home Agents listens to the subnet-directed broadcast and Broadcast 
>     IP address "255.255.255.255." as mentioned in the RFC3220.
> v. Every Home Agent which receives this IP packet MUST reject the RRQ with
> a code
>     of 136 and insert the HA unicast IP address in the RRP message to the
> MN through the 
>     Foreign Agent Care-Of Address.
> vi.  After MN receives all the RRP messages from the different HAs, it
> chooses which HA
>      to register with and then use that HA IP address.
> 
> Now, the only conflict I see is what mentioned in section 3.8.3.2 which
> reads:
> 
> Section 3.8.2.2:
> "
>    If the Home Agent field in the Registration Request contains a
>    unicast address of this home agent, then that field MUST be copied
>    into the Home Agent field of the Registration Reply.  Otherwise, the
>    home agent MUST set the Home Agent field in the Registration Reply to
>    its unicast address.  In this latter case, the home agent MUST reject
>    the registration with a suitable code (e.g., Code 136) to prevent the
>    mobile node from possibly being simultaneously registered with two or
>    more home agents.
> "
> This section mandates that every HA rejects any RRQ message with HA 
> field is different than the HA unicast IP address.
> This will not allow dynamic Home agent allocation using RADIUS or future
> Diameter in ONE SINGLE ROUND TRIP of the initial registration.
> 
> In the spirit of resolving this issue to avoid forward compatibility
> problems, 
> I believe this text SHOULD be modified to be consistent with 
> what the RFC3220 is trying to propose for Home Agent dynamic allocation.
> 
> Proposed TEXT:
>  Section 3.8.2.2:
> "
>    If the Home Agent field in the Registration Request contains a
>    unicast address of this home agent, then that field MUST be copied
>    into the Home Agent field of the Registration Reply.  Otherwise, the
>    home agent MUST set the Home Agent field in the Registration Reply to
>    its unicast address.  In this latter case and only if this IP packet
> was distant 
>    to either the subnet-directed broadcast or 255.255.255.255, the home 
	[Muhanna, Ahmad]  
	I meant "In this latter case and only if this IP packet was destined
to either 
	the subnet-directed broadcast or 255.255.255.255, the home .." 

>    agent MUST reject the registration with a suitable code (e.g., Code
> 136) 
>    to prevent the mobile node from possibly being simultaneously
> registered 
>    with two or more home agents.
> " 
> 
> Thanks for consideration.
> 
> Regards;
> Ahmad Muhanna
>

---

From: "Charles E. Perkins" <[email-masked]>
Date: Tue, 02 Apr 2002 08:23:29 -0800

Hello folks,

May I assume that this corrective text is acceptable to
everyone concerned?  I would like to incorporate the necessary
revisions and reissue RFC3220bis soon.  Is there any impact
on RFC3012bis?

Regards,
Charlie P.

> Ahmad Muhanna wrote:
>      Cc:     Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Charlie Perkins'; 'Pete
>      McCann'; Nickell, Kent [RICH2:2Q20:EXCH]
>      ii. RFC3220 does not specify what IP address the Mobile Node insert in
>      the HA
>          It is basically very wise to do so by leaving the door open for
>      future forward compatibility.
> 
>      v. Every Home Agent which receives this IP packet MUST reject the RRQ
>      with a code
>      I meant "In this latter case and only if this IP packet was destined to
>      either

---

From: kleung <[email-masked]>
Date: Tue, 02 Apr 2002 09:08:45 -0800

Hi Charlie.  I think the current specification is very clear on how MN
can signal that it needs to be dynamically assigned an HA - by
specifying a non-unicast IP address in the HA field of Reg Request.
This happens when MN boots up, and once assigned, MN can
reregister to that HA.

Seems counter-intuitive that HA field is changed in Reg Reply when MN
already specified exactly which HA to use?

See comments below ..

> >      field is different than the HA unicast IP address.

The advantage of this scheme is avoiding ambiguity of which MN wanted
to registered with when using unicast IP address of the HA.  If MN doesn't
know which HA, then it should not be setting HA field to a unicast address,
right?

> >      Diameter in ONE SINGLE ROUND TRIP of the initial registration.

Well, this depends on the scheme. :)

> >      what the RFC3220 is trying to propose for Home Agent dynamic allocation.

I'm not in favor of changing the HA field in the Reg Reply when MN
requested a unicast IP address.  I think if HA needs to be dynamically
assigned, then MN should set HA field to non-unicast IP address (which
makes it clear that's what MN wants).  Once MN is anchored to an HA,
then MN uses unicast IP address for reregistrations.

Else, might get into situations where HA is constantly reassigned (ie. MN
has no control to stop this) even when MN is using unicast IP address.
With the current specificiation, this can't happen since only the initial
Reg Request with non-unicast HA field will
assign the MN an HA.  After that, MN will be using that HA for roaming.
No playing around with the HA field in the Reg Reply.

I think this proposed approach is trying to fit some particular scheme, but
breaks the generality and clarity of existing specification.  IMHO.

Kent

---

From: kleung <[email-masked]>
Date: Tue, 02 Apr 2002 09:33:41 -0800

Sorry folks.  Somehow I misread the text and assumed it was about
the unicast IP address.

Comments below...

> >      the subnet-directed broadcast or 255.255.255.255, the home .."

What about 0.0.0.0?

Isn't the current language already saying that in the non-unicast
case, set the HA field and reject?  This non-unicast address broadly
covers subnet-directed broadcast, 255.255.255.255, and 0.0.0.0.

"If the Home Agent field in the Registration Request contains a
unicast address of this home agent, ....  Otherwise, the
home agent MUST set the Home Agent field in the Registration Reply to
its unicast address.  In this latter case, ..."

I don't have a problem with listing out specific IP addresses in the spec,
just not sure if it's really needed.

Thanks.

Kent

---

From: Pete McCann <[email-masked]>
Date: Tue, 2 Apr 2002 15:38:05 -0600 (CST)

Hi, Ahmad,

I think this is your current proposal, cleaned up a bit:

Ahmad Muhanna writes:
>  Section 3.8.3.2:
>    unicast address of this home agent, then that field MUST be
>    copied into the Home Agent field of the Registration Reply.
>    Otherwise, the home agent MUST set the Home Agent field in the
>    Registration Reply to its unicast address.  In this latter case
>    and only if this IP packet was destined to either the
>    subnet-directed broadcast or 255.255.255.255, the home agent
>    MUST reject the registration with a suitable code (e.g., Code
>    136) to prevent the mobile node from possibly being
>    simultaneously registered with two or more home agents.

If I may summarize, you are proposing that the HA base its decision on
whether to accept or reject the request not only on the contents of
the HA field but also on the contents of the IP destination address of
the Registration Request.  Both the existing and proposed texts
mandate that an HA reject requests that were subnet-directed
broadcast, if they contain an HA address that doesn't match one of the
unicast interfaces of the HA.  However, you are proposing that the HA
be allowed to respond successfully to Registration Requests no matter
what the content of the HA field, as long as they were not
subnet-directed broadcast.  I am not sure this is entirely safe.

Rather, I would propose something like the following:

   If the Home Agent field in the Registration Request contains a unicast
   address of this home agent, then that field MUST be copied into the
   Home Agent field of the Registration Reply.  Otherwise, the home agent
   MUST set the Home Agent field in the Registration Reply to its unicast
   address.  In this latter case, the Home Agent MUST reject the request
   with a suitable code (e.g., Code 136) unless the Home Agent can
   determine by means outside the scope of this document (e.g., by
   receiving the Registration Request from a trusted authenticating
   entity) that it has been allocated to service the registration and
   that no other Home Agent will receive the same request.  This
   will prevent the mobile node from possibly being simultaneously
   registered with two or more home agents.  In case such a
   determination is made, the Home Agent MAY respond successfully if
   the Registration Request is otherwise valid.

-Pete

---

From: kleung <[email-masked]>
Date: Tue, 02 Apr 2002 15:36:47 -0800

> subnet-directed broadcast.  I am not sure this is entirely safe.

Thanks for the clarification.  Though just a little disagreement over
the intention.  :)

To keep scheme safe, my proposal follows below.

   If the Home Agent field in the Registration Request contains a unicast
   address of this home agent, then that field MUST be copied into the
   Home Agent field of the Registration Reply.  Otherwise, the home agent
   MUST set the Home Agent field in the Registration Reply to its unicast
   address.  In this latter case, the Home Agent MUST reject the request
   with a suitable code (e.g., Code 136) unless the destination IP address
   of the Registation Request is an unicast address.  In this case, the
   Home Agent MAY accept the Registration Request.  This
   will prevent the mobile node from possibly being simultaneously
   registered with two or more home agents.

How does this sound?  Was this the intent?

Kent

---

From: Marcello Lioy <[email-masked]>
Date: Tue, 02 Apr 2002 17:20:02 -0800

>What about 0.0.0.0?

I am with Kent on this one.  We already have fielded software out there 
that assumes that an address of 0.0.0.0 if for dynamic home agent allocation.

Also to my mind it makes the most sence as this is not a valid address for 
a host to have (correct me if I am wrong) while 255.255.255.255 already has 
a meaning.

> > >      Thanks for consideration.

-- Marcello

---

From: Wang Hui <[email-masked]>
Date: Wed, 3 Apr 2002 11:05:36 +0800 (CST)

Hi, folks here,

I found that WIDE project has been doing a protocol (called LIN6) to
support "mobility" for IPv6.

As they claim that LIN6 provides mobility to IPv6 without impact on the
existing IPv6 infrastructure and maintains compatibility with traditional IPv6.

So what do you think of LIN6?

Here is the web site for LIN6:
http://www.lin6.net/

Best,
Wang Hui

---

From: Jeff Dyck <[email-masked]>
Date: Tue, 02 Apr 2002 17:32:44 -0800

sense.

At 05:20 PM 4/2/2002 -0800, you wrote:
>a host to have (correct me if I am wrong) while 255.255.255.255 already 
>has a meaning.
>

__________________________________________________
Jeffrey Dyck, Engineer
QUALCOMM CDMA Technologies
(858) 845-7548
[email-masked]

---

From: Charlie Perkins <[email-masked]>
Date: Tue, 02 Apr 2002 20:15:35 -0800

Hello,

I think that LIN6 is mainly for people who want some of the
features of Mobile IPv6, but who got tired of waiting for us
to be finished with it.  It basically moves the binding update
to be a nameserver operation instead of a Mobile IP operation,
and I think it doesn't offer any advantages other than just
moving the necessary components to other parts of the
protocol stack.  I believe applications have to be rewritten
to handle a new nameserver record type, and smooth handover
is not really possible.  Binding updates are not delivered to
correspondent nodes.

If I have some of the details wrong, please excuse, but this
is my impression of it.

Regards,
Charlie P.

---

From: Pekka Savola <[email-masked]>
Date: Wed, 3 Apr 2002 08:09:31 +0300 (EEST)

> So what do you think of LIN6?

LIN6 has IPR.  'nuff said.  Even if it was any good, it isn't really worth 
checking out.

-- 
Pekka Savola                 "Tell me of difficulties surmounted,
Netcore Oy                   not those you stumble over and fall"
Systems. Networks. Security.  -- Robert Jordan: A Crown of Swords

---

From: Fumio Teraoka <[email-masked]>
Date: Wed, 03 Apr 2002 14:47:03 +0900

Hi, Charlie,

LIN6 is based on a different architecture than that of MIP, i.e.,
separation of node ID and node locator.

LIN6 has several advantages against MIPv6. For example:
 
  1) LIN6 has no header overhead while MIPv6 uses large extension
     headers for every packet.

  2) LIN6 is more fault tolerant than MIPv6. In MIPv6, the HA is the
     single point of failure and the HA cannot be replicated to the
     subnet other than the home network. In LIN6, the Mapping Agent
     can be replicated to anywhere.  

No modifications are necessary to applications, name servers, resolvers,
and TCP/UDP for LIN6. LIN6 is running on several UNIX operating systems
and Win2k. Source code is available from http://www.lin6.net/

Smooth handoff is already implemented to LIN6 although there is no
i-d of smooth handoff in LIN6.

Fumio Teraoka

---

From: Fumio Teraoka <[email-masked]>
Date: Wed, 03 Apr 2002 14:51:08 +0900

Section 8 of draft-teraoka-ipng-lin6-01.txt says:

   We really intend to contribute to development of the Internet community
   and to keep a good relationship with IETF. And our primary concern is to
   promote our technology so that others may feel it is useful and
   worthwhile in the spirit of the IETF.

   If indeed the mechanisms are granted as patents, the patents will be
   licensed under reasonable and non-discriminatory conditions to any
   person who wants to implement the mechanisms.

Fumio Teraoka