Subject: [mobile-ip] Comments on hmipv6 draft and a proposal on a third mode

From: Samita Chakrabarti <[email-masked]>
Date: Mon, 26 Mar 2001 10:56:32 -0800 (PST)

Sorry for the late posting... But  most of the comments have been discussed with
hmipv6 authors in private emails. 

The comments are based  mostly on hmipv6 version 2 draft.
Also, I'd like to propose a third mode in hmipv6 especially
for those systems which do not have ROHC implementation
at their network.
Thus this proposed mode will save 40 bytes of tunnel overhead
between MAP and mobile node in the basic mode. I understand that
this would be useful for IPRAN  as James Kempf had pointed out 
earlier in the list.

Editorial comments:

section 3.0 : one or two word description of 'B' flag would be helpful

section 3.1 : Load-balancing sub-option : needs more clarification as to where the
              sub-option is sent ( to MAP only or CN as well ?)
              Load-balancing may be a misnomer, perhaps a more suitable name should
              be used as this option basically is used by the MN for balancing load
              over different interfaces. But the load-balancing is dependent on the
              flow policies. So, how about "Policy" sub-option or other suitable names ?

              How about changing 'prot number' to 'proto number' ?
              Needs description for dest-port, r and Destination address, I suppose
              destination address should be LCOA

              'P' bit description should clarify which "ip-address" (LCOA?) is used
               to identify flow.

               Since checking for flow-label or port-ipaddr pair also involve checking
               each packet at MAP, 'per-packet' load balancing description is a bit
               confusing in this context. Since 'per-packet' load-balancing refers to
               'A' bit only, another beeter name or more clarification required here.

Section 4.0    An example of 'T' bit would help

Section 5.0    A little more detailed analysis of choices of MAP discovery will be
               a good guide for implementors and users to pick which one to pick
               in their implementation/operating environment.

Section 5.4:   3rd paragraph mentions :
               "If a MN has access to several ARs.......it's current MAP"
               an example will be helpful in order to describe this scenario.
Section 11:    Needs more clarification ( I was told that version 3 has improved texts)

Section 15:   Reference for AAAv6 should be recorded.

Technical :
----------
 (Some of the following are discussed with hmipv6 authors)

Section 3.1 : 'r' bit may be moved adjacent to F|P|A flags for future use ?
               Next version of draft should also specify possible error codes--
               at least the 'errors in text form'.

Section 5  :  For simplicity, hmipv6 draft should limit the choices of MAP discovery
              and specify one or two options as 'MUST' to implement. Otherwise,
              implementations either will become too complex or will not interoperate.

Section 6.1 : Please specify that alternate COA sub-option is optional when RCOA is
              used as source address of the BU. (for location privacy)

Section 11 : This section should also mention that the hierarchical network between
             MAP and MNs must be a trusted network and no src-address filtering is done
             on the outging packets from the mobile nodes.

Section 7.1 and 7.2 :
              Added operation in HA can be easily avoided if :
              A MN MUST (instead of SHOULD) send a BU for each different Home-addr it
              uses for connection.

              But I think, having HA to add RH in the outer IP layer, has two
              advantages:

              1) less signalling between MN and AR ( this is probably desirable by
                 wirelss vendors)
      
              2) Supporting site-local addressed home-addr in the foreign domain.
              
Load Balancing in general:              
BTW, a detailed load balancing scheme for fault-tolerance for MAP should be schetched
out so that the backup MAP can takes over when the orginial MAP goes down. Perhaps the
policy and MAP load babalncing scenarios should be discussed in a separate draft to
keep this draft simple. But we can toss ideas and discuss more on that in the 
discussion team.

Proposal of having optional 3rd mode(Basic-non-tunneled) in a hierarchical network where
ROHC is not available.

Basic non-tunnel mode: Supporting mobile nodes with RCOA without tunnels between MAP and MN
         
MAP Operation: 
           In this mode, MAP recives BU and sends BAck after performing DAD operation
           as described in basic mode. A new bit will be introduced in the MAP advertisement
           to distinguish "Basic non-tunnel" mode service from other two modes.

      The new MAP option format ( as per discussion with Hesham Soliman):

      0                   1                   2                   3
      0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Type      |    Length     |  Distance     |  Pref         |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |     Plen      |R|M|T|N|            Reserved                   |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                         Valid Lifetime                        |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
      |                                                               |
      +                                                               +
      |                                                               |
      +                  Global IP Address for MAP                    +
      |                                                               |
      +                                                               +
      |                                                               |
      +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

          N  - Indicates that the MN MUST be able to replace the destination
               address of incoming packet from LCOA to RCOA when the packets
               are coming from either a correspondent node or it's home agent.
               R bit MUST be set when N bit is set. N bit MUST not be set
               when M is bit is set. Basicaly N bit is an indication of MAP
               supporting basic-non-tunnel mode.

           The MAP keeps a binding cache containing association
           of RCOA, LCOA and MN's home-addr. It intercepts the packets that are destined
           to RCOA (either from HA or from CN. Note that in basic mode RCOA is different
           from MAP's own address.) MAP then replaces the destination IP-address RCOA by
           LCOA after looking up the binding cache, and simply forwards the packet to
           the topologically correct router in the hierarchy.

MN Operations:
         
           MN forms LCOA and RCOA exactly the same way as described in basic mode. It also
           sends BU to MAP and home agent subsequently exactly the same way as described
           in 6.1 (Basic mode MN operations). MN may also send BU to CN informing RCOA as
           it's new COA ( same as in basic-mode operation).

           MN receives packets addressed to MN's LCOA address, MN replaces the LCOA address
           by the corresponding RCOA address after determining that this packet is
           coming from either it's home agent or correspondent node. MN then proceeds
           with normal processing of packets as described in base mobile IPv6 draft.

           The differnce between basic mode MN and basic-non-tunnel mode MN is that
           the latter, does not need to detunnel the packet from MAP at all. Instead it
           swaps the destination address of the incoming  packet when the
           source address is home agent address or  correspondent node address.
           Thus a mobile node implementation may maintain a list of CNs and
           Home agents for address verification.

HA Operation:
           No change from basic mode operation.

----------------------------------------------------------------------------------------

Thanks,
-Samita

---

From: Claude Castelluccia <[email-masked]>
Date: Tue, 27 Mar 2001 10:33:49 +0200

Hello Samita and thanks a lot for your comments concerning HMIPv6.

We'll take your comments into consideration for the next version of the draft
(some of them are already integrated in the 03 version...
(http://www.inrialpes.fr/planete/people/ccastel/draft-ietf-mobileip-hmipv6-03.txt)

Concerning the third mode proposal, i have 3 comments:

-in the basic mode, the MAP is nothing more that a HA.  This was one of our requirements
when designing this mode. The basic mode is very simple to implement... adding the
fonctionality
you are proposing would require to modify the MAP and we won't be able to use a HA as MAP
anymore...

-in your proposal, the MAP modifies the destination address of the packets that are sent to a
Mobile host.
What will happen if the packet is authenticated with AH? The packets will be rejected by the
MN. This
is an issue when the CN is also mobile and piggybacks  its BUs with its packets (the whole
packets must then be
authenticated with AH) ...

- Most of wireless networks will use RoHC (as confirmed by Hesham email) so I don't see the
motivation
for this 3rd mode (considering the 2 previous issues).

Thanks again for your comments,

regards,

Claude.

Samita Chakrabarti wrote:

> Hello:

--

----------------------------------------
Claude CASTELLUCCIA, INRIA Rhone-Alpes
ph:  +33 4.76.61.52.15 (fax: 52.52)
http://www.inrialpes.fr/planete/