Subject: [Mipshop] RE: Last Call Comments on draft-ietf-mishop-hmipv6-00.txt

From: Soliman Hesham <[email-masked]>
Date: Tue, 18 Nov 2003 00:56:00 -0500

Gabriel,

Thanks for the comments. I've included the ones that need
further discussion in this email, the rest seem ok.

>For instance, I'm not too pleased with the OCoT mechanism which forces the
MN
>to send back a BA. This clearly departs from MIPv6 (in which MNs
>never send those out). Suggest defining a new error code ("OCoT Required")
>and having the MAP send back a Binding Error with that code and the 
>OCoT option. The MN replies with another BU and the exact same 
>option value. Don't see the need for incrementing the counter
>in the option. The rest would remain the same, just the packet format
>used for the OCoT would change.

=> That's doable, however, since you started by saying that
HMIPv6 departs from MIPv6 model, should we really have this
test at all? I mean it doesn't exist in MIPv6 and the issue
was dismissed for the HA. 

>I also share James' feeling that the P,I,V bits should be deleted.
>Again, this departs from the MIPv6 model. I tend to think about a MAP
>as little more than a HA, and any departure from that should be seriously
>questioned. I think they are similar enough that solving the problem of
>MN to MAP security is equivalent to solving the bootstrapping problem
>in MIPv6, and the same solutions should apply.

=> Could you explain your reasons for wanting
them to be deleted? The MAP option is not required to
look exactly like a DHAAD reply. I don't think this is 
a reason to delete them. Those flags are there for location
privacy and for telling the MN when it MUST user RCoA
as a src address. The irony is that the latter feature
was requested by James and the WG agreed...

>The 'Dist' field seems to be the number of levels of MAP hierarchy
>if one updates them via the dynamic MAP technique. If so, perhaps saying
>so would help. 

=> The Dist field is there to tell the MN how "far"
the MAP is. There is only one level of hierarchy in HMIPv6, 
so the Dist doesn't say anything about levels of hierarchy.
The purpose of this field is to aid the MN in selecting
the right MAP. The knowledge that the MN should have in order
to use this field is really link layer specific (i.e.
speed for instance) so we couldn't put more info than
that in the draft. I can add more text to explain this.

>Also, it is not clear if the proper use of this field
>implies that the newly arriving MN should spend some time in learning
>mode before it hears about the different values of 'Dist'. In one of the
>MAP discovery schemes (dynamic scheme) all 'Dist' values within any 
>given branch of the hierarchical tree are supposed to be available
>in a MAP advertisement.

=> There is no "hierarchical tree", perhaps this should
be made clearer, i.e. there are no tree-based hierarchies in HMIPv6. 
All MAP options are advertised within a MAP domain, independently
of the MAP discovery mechanism. The MN would listen to MAP
options in the RA when it moves, or before movement (if 
anticipation is used).

 But this says nothing of the other branches.
>Nor of MAP discovery via other methods. If the MN must learn, should
>there be an indication that this is the case? 

=> I'm not sure I follow. This is taken out of section 2.1:

   Upon arrival in a visited network, the mobile node will discover the 
   global address of the MAP. This address is stored in the Access 
   Routers and communicated to the mobile node via Router Advertisements 
   (RAs). A new option for RAs is proposed later in this specification. 
   This is needed to inform mobile nodes about the presence of the MAP 
   (MAP discovery). The discovery phase will also inform the mobile node 
   of the distance of the MAP from the mobile node. For example, the MAP 
   function could be implemented as shown in Figure 1 and at the same 
   time also in AR1 and AR2. In this case the mobile node can choose the 
   first hop MAP or one further in the hierarchy of routers. The details 
   on how to choose a MAP are provided in section 10. 
    
   The process of MAP discovery continues as the mobile node moves from 
   one subnet to the next. As the mobile node roams within a MAP domain, 

   ARs are configured to announce the same MAP address or addresses. If 
   a change in the advertised MAP's address is received, the mobile node 
   MUST act on the change by performing movement detection and sending 
   the necessary Binding Updates to its HA and correspondent nodes. 

Does this clarify the issue for the MN?

>But if learning is in order, does this add delay precisely during
>the handoff period when things are supposed to run quickly? 

=> No more delays than movement detection. The "learning" means
being able to parse the MAP option and understanding it. Bascially,
like any other option in the RA.

>Or are
>MAP advertisements possible to learn before arriving in that particular
>branch of the hierarchy. 

=> If we decide to have a framework for merger of HMIP and FMIP, we 
would allow the MN to learn the MAP option before it moves.
This is already possible btw, FMIP ARs send rtr_adv for proxy
to the MN before it moves. The MAP option can be included in
those RAs. 

>The 'R' bit in the MAP option: Its definition disagrees with section
>7.3 (the only other section to mention it). Is it a bit that signals
>stateless address configuration of an RCoA? If so, is there an
>equivalent stateful RCoA configuration? The section on 'Protocol
>Operation' says that there isn't, that addresses are obtained in a
>stateless manner.  If so, is this bit even needed? Seems like it is
>rendered unecessary by the 'MUST' in the 'Global Address' field
>description. If it is required, then some description in the section
>on 'Mobile node Operation' is in order.

=> Originally, we had two different modes of operation 
(basic and extended), the R bit indicated basic and the 
M bit indicated extended. Now there is only one mode so 
I guess we can remove this bit if no one objects to it.

>On MAP discovery. There is a DHCP option that Charlie defined a long
>time ago for MIPv4, and more recent work by Henrik along these lines
>being discussed in the DHC WG. The MAP discovery problem is not all that
>different from bootstrapping a home agent (starting by ignoring even the
>home prefix) so similar (identical?) solutions should apply.

=> I think MAP discovery is very different from bootstrapping
an HA, mainly due to the timeliness required to achieve
this job. Bootstrapping an HA does not happen every time
the MN changes links, whereas MAP discovery does. Therefore,
having the MAP option in the RA makes this process very quick
(compared to other methods) because the RA tells the MN whether
it moved (which is needed, with or without HMIPv6) and at
the same time it tells the MN whether it's still in the 
same MAP domain.

Hesham

_______________________________________________
Mipshop mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/mipshop

---

From: "James Kempf" <[email-masked]>
Date: Tue, 18 Nov 2003 09:52:21 -0800

> was requested by James and the WG agreed...

Um, not quite.

The way I remember it, I originally (several years ago) objected to having
these flags because I thought they were too complex, and simply wanted the
MN to tunnel back to the MAP, but in the face a sustained email barrage from
one of the authors of the draft and lacking any support from other WG
members in helping me to fend off the barrage, I relented in order to spare
myself further DoS on my email reading and responding time. :-)

In the interim, the effect on ingress filtering occured to me (as I've been
sensitized to security issues of late) so I raised the issue again recently
in Last Call. While I agreed with your response about it being possible to
configure the routers locally to pass the RCoA, because the MAP is in the
local administrative domain (unlike the HA), Greg brought up the issue in
Minneapolis that this configuration could fail if the MN moves across
administrative domains, while tunneling would continue to work. So having
these options could make MAP handover more complicated. Also, if there is
some agreement to decouple HMIP from modifications and configuration of the
access router, then not having these options would help. As I've mentioned
in a separate email, not coupling MAP deployment to changes and
configuration of the access router would be preferable from a service
provider's standpoint, since it would allow deployment with stock IPv6
routers.

Also, I'm not clear how exactly these options help with location privacy.

> that in the draft. I can add more text to explain this.

The issue is that there are no rules for how to set this field and therefore
there is no way decide what to select except for the two extremes. That is,
suppose in one network I have Dist values of 100, 40, 7, and 2. All the MN
really knows is that 100 is the furtherst and 2 is the least. The others are
essentially useless, since there is no metric defined on the numbers that
would let the MN decide which is better. Furthermore, the numbers can vary
between networks. Suppose in another network the values are 40 10 and 6. Is
the 40 value comparable?

> to the MN before it moves. The MAP option can be included in

I think this will be necessary regardless in order to smooth MAP handover.
The MN needs to have a binding at the new MAP before it changes the binding
at the HA or deletes the binding at the old MAP. Otherwise, packets are
lost.

In fact, it might be useful to have a section that describes the order of
messaging to accomplish MAP handover, since it is major feature of HMIP
beyond simply using a local HA. With a local HA, there's no handover.

> the same time it tells the MN whether it's still in the

The current two discovery mechanisms are problematic in certain respects. As
I've mentioned before, the Router Advert method requires modifying access
routers, and it would be nice for service providers to be able to deploy
HMIP without modifying stock IPv6 routers. The router renumbering method is
somewhat speculative, and I can't really see it being deployed. Of course,
since the draft is going experimental, these are perhaps not so important.

I think MAP discovery could be done predictively if the MN knows the subnet
prefixes for access networks over which the current MAP has coverage
(essentially, it's topological span). The actual span could be set somewhat
larger than the advertised span, so that when the MN reaches the limits of
the advertised span, it uses some discovery protocol (like lightweight DHC)
to request a new MAP. This might have some difficulties at the boundary of
an administrative domain, but it is likely that the MN will need to undergo
some kind of authentication renewal to get into the new adminstrative
domain, which could be time consuming, so getting a new MAP will likely not
be the controlling item in handover. And, if the MN can continue to use the
old MAP while the new one is being set up (via tunneling) there should be
less pressure on handover performance-wise.

            jak

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Nov 2003 16:27:23 +0100

> I guess we can remove this bit if no one objects to it.

And even if everybody objects! If it serves no purpose it must
have been deleted as soon as it stopped being useful. And it seems
like it serves no purpose as its use is not discussed anywhere.

> the MN changes links, whereas MAP discovery does. Therefore,

Maybe bootstrapping doesn't (one would hope) but dhcp could
(on managed links) so it may be an alternative.

> the same time it tells the MN whether it's still in the 

Those are advantages. Disadvantages as compared to dhcp is that one must
modify the routers. I'm just agreeing with others that this is an alternative.
Not sure if we should work on it now or leave it for later (mobopts?).

-gabriel

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 24 Nov 2003 16:31:11 +0100

> the MAP is. There is only one level of hierarchy in HMIPv6, 

Is this an unspoken assumption? If so, it must be made explicit.
These statements are why I thought there were multiple levels:

    For these reasons a new Mobile IPv6 node, called the Mobility Anchor
    Point is used and can be located at any level in a hierarchical
    network of routers, including the Access Router (AR).

...
    In this manner, information about a MAP at a certain level in a
    hierarchy can be dynamically passed to a mobile node.
...

    The MAP option is propagated down the hierarchy. Each router along
    the path to the access router will increment the Distance field by
    one. If a router that is also a MAP receives advertisements from
    other MAPs, it MUST add its own MAP option and propagate both options
    to the next level in the hierarchy.

The above mandates that at each level of the hierarchy the 'Dist'
value get incremented by one. If this is incorrect, then there's work to do
in clearing all this up.

> so the Dist doesn't say anything about levels of hierarchy.

Not what the text implies.

> that in the draft. I can add more text to explain this.

Please, specially if you're using this in conjunction with link-layer
specific information.

> options in the RA when it moves, or before movement (if 

Yes, perhaps needs to be made clearer. Things like this:

    Upon reception of a router advertisement with the MAP option, the
    receiving router MUST copy the option and re-send it after
    incrementing the Distance field by one.

imply that there is. If so, some comments below may still apply. I'll stop here
to wait for further clarification.

tnx,

-gabriel