Subject: RE: [mobile-ip] Re: RFC3220 and possible forward compatibility is sue "Dynamic Home Agent Allocation"

From: "Kuntal Chowdhury"<[email-masked]>
Date: Tue, 2 Apr 2002 10:39:27 -0600

Charlie,
This will certainly address the forward/backward compatibility issues
related to various dynamic HA assignment schemes. The suggested change
ensures a "single trip" dynamic HA solution and also covers the concern
about multiple simultaneous registrations with the dynamic HA assignment
scheme using "subnet directed broadcast".

Regards,
Kuntal

-----Original Message-----
From: Charles E. Perkins [mailto:[email-masked]]
Sent: Tuesday, April 02, 2002 10:23 AM
To: Muhanna, Ahmad [RICH1:2Q20:EXCH]; 'Pete McCann'; Nickell, Kent
[RICH2:2Q20:EXCH]
Cc: Mobile IP Working Group; Basavaraj Patil (NTC/Dallas); Phil Roberts
Subject: [mobile-ip] Re: RFC3220 and possible forward compatibility
issue "Dynamic Home Agent Allocation"

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:
> 
> 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: kleung <[email-masked]>
Date: Tue, 02 Apr 2002 09:39:06 -0800

Hmm, I've always assumed that "single trip" scheme is when MN sends
Reg Request with non-unicast HA address field and an
assigned HA responds with Reg Reply with its unicast address?

The proposed text still requires another trip after HA rejects.  MN
has to send another Reg Request to set up tunneling.  This dynamic HA
assignment scheme takes 2 transactions.

Kent

Kuntal Chowdhury wrote:

> ensures a "single trip" dynamic HA solution and also covers the
> concern about multiple simultaneous registrations with the dynamic HA
> assignment scheme using "subnet directed broadcast".
>
> Regards,
> Kuntal