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

From: Soliman Hesham <[email-masked]>
Date: Sat, 8 Nov 2003 05:41:43 -0500

Thanks for the comments. I'll put them in the 
presentation for the mipshop meeting.

 > In general, this draft is in reasonably good shape. It's 
 > been around for a
 > while, implemented at least once in part, and I didn't find 
 > anything that I
 > think should hold it up from a technical standpoint, 

=> Great. I agree of course! 

 > especially since it is
 > going to experimental.

=> I hope that this does not deter people from giving the 
draft a thorough review. This decision (unjustified IMO as it 
is) is not intended to reflect a lower quality spec. So 
hopefully it won't stop people from reviewing it thoroughly.

 > 
 > Section 5, Neighbor Discovery extension - I've brought this 
 > point up in the
 > past, but I am going to bring it up again. Given the exponential
 > proliferation of spam, viruses, etc., I wonder if it is wise 
 > to include
 > options that require ingress filtering to be turned off. 

=> There is nothing in the spec that requires ingress filtering
to be turned off. Exactly the opposite. The spec assumes that
ingress filtering is always on. Therefore, those flags are there 
to inform the MN that if it needs to use its RCoA as a src address
it should either tunnel through the MAP, or (if ingress filtering
is _configurable_ to allow for RCoA addresses) send directly.

  I 
 > believe the I, P,
 > and V options should be eliminated and the MN should be 
 > required to tunnel
 > back to the MAP exactly as for MIPv6, in order to encourage 
 > people to turn
 > on ingress filtering.

=> Why would you do that if you can configure an ingress
filter to allow RCoA to pass? Seems like an unnecessary
removal of features.

 > Section 9 paragraph 1 - I believe piggybacking was removed 
 > from MIPv6 for
 > now, so I wonder whether it should be recommended here.

=> Agreed. I thought we already removed that part. I'll
remove it in the next revision.

 > Section 12 - One of the problems I've had with this draft 
 > for a while is the
 > lack of any consideration of how to check if the MN is 
 > authorized for mobile
 > service. The intent seems to be that if the MN has IP 
 > service, it is also
 > authorized for mobility management. This may not be the case 
 > if the service
 > provider hosts fixed nodes also, or provides differential pricing for
 > customers that buy LMM service and those that don't.  

=> Well, you mentioned the possible use of auth certificates.
I believe I replied that this is already possible in the 
current spec. What's missing ?

 > Editorial:
 > 
 > There are two Section 2's, on pg. 4 and pg. 5.

=> Ok.

 > Section 2 (pg. 4) Paragraph 6 - "A MAP is essentially a 
 > local Home Agent"
 > This theme is repeated throughout the paper, and I think it 
 > is somewhat
 > misleading. While it is true that there are some elements of MAP
 > functionality that mimic a Home Agent, there are others (such as the
 > discovery protocols) that are quite different, and the MAP 
 > doesn't implement
 > some functionality that the HA does. I would suggest toning down this
 > comparison somewhat.

=> Just to be clear, there are 4 aspects of the MAP function:
- Forwarding: this is identical to the HA
- Signalling (BU): This is also the same with two minor exceptions:
       1. the M flag. and 2) the new optional 3-way handshake.
- Binding cache management: identical to HA
- Discovery: Different from HA.

we'll make sure that the context is clear in the next rev.

 > 
 > Section 2(pg 5) - "Furthermore, a smooth architectural 
 > migration can be
 > achieved from..."
 > I don't believe the MIPv4 group is planning on doing any 
 > work on LMM, so I
 > think this statement should be removed. Also, there is 
 > nothing in the draft
 > to support the statement.

=> Ok.

 > Section 5 Neighbor Discovery extension - Might be helpful to 
 > indicate in the
 > Valid Lifetime field description that a lifetime of 0 
 > indicates that the MAP
 > is not available. This is stated later in the paper, but the 
 > reader is keyed
 > into learning about this field here.

=> Ok.

 > 
 > Sections 6.1 and 7.3 seem to be saying essentially the same 
 > thing. Also,
 > Section 8 is a repeat of material earlier in the draft. 
 > These should be
 > consolidated.

=> ok.

 > 
 > Section 8 paragraph 1 - I don't believe RECOMMENDED is on 
 > the list of RFC
 > 2119 keywords, so I would advice "SHOULD".

=> From 2119:

   SHOULD   This word, or the adjective "RECOMMENDED", mean that there
   may exist valid reasons in particular circumstances to ignore a
   particular item, but the full implications must be understood and
   carefully weighed before choosing a different course.

 > Section 9 paragraph 3 - "This may be changed if it is proven..."
 > This isn't particularly helpful for implementors, in fact, 
 > it may make them
 > nervous. I'd suggest removing it.

=> ok.

 > Section 10.1 paragraph 3 - having a far away MAP is also 
 > better for location
 > privacy, since it provides a larger span of coverage. Might 
 > be good to
 > mention that here.

=> ok.

Hesham

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

---

From: "James Kempf" <[email-masked]>
Date: Sat, 8 Nov 2003 11:10:02 -0800

Hesham,

> filter to allow RCoA to pass? Seems like an unnecessary

Allowing the RCoA to pass is certainly an option, and it should be mentioned
in the spec. People familiar with the MIP spec are going to ask why HMIP
allows these options and MIP doesn't. The answer is that because the RCoA is
in the local network, it is controlled by the local network operator and
therefore the ingress filter can be configured by the network operator,
which isn't the case with MIP.

> current spec. What's missing ?

The auth needs to be checked when the MN gets a IPsec SA with the MAP. This
can be done in IKEv2 fairly easily. It doesn't require auth certs, which are
currently not deployed. It is also possible in IKEv1 under some fairly
restricted circumstances.

Ultimately, I think we will need a more complete description of the use of
IPsec for dynamic agents, like Jari, Vijay and Francis have done for how
IPsec is used for MIP, but that can come later.

>    carefully weighed before choosing a different course.

Ok.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Sat, 8 Nov 2003 15:28:52 -0800

One other point.

Is the appendix really necessary? draft-jung-mobileip-fastho-hmipv6-02.txt
is a far more complete description of the integration between the two
handover methods. I'd suggest dropping the appendix and introducting
draft-jung-mobileip-fastho-hmipv6-02.txt into the MOPOPTS RG.

            jak

---

From: gabriel montenegro <[email-masked]>
Date: Mon, 17 Nov 2003 19:49:39 +0100

General comments:
----------------

Contrary to some postings on the alias, I actually think that HMIPv6 already
departs gratuitously from the MIPv6 model and would prefer if it were
aligned a bit closer.

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.

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.

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. 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. 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? Doesn't seem to be the
'P' bit. But if learning is in order, does this add delay precisely during
the handoff period when things are supposed to run quickly? Or are
MAP advertisements possible to learn before arriving in that particular
branch of the hierarchy. Not clear how to use this, perhaps topics for
MOBOPTS?

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.

Section on "Local Mobility Management optimisation within a MAP domain"
seems a bit like overselling to me in the sense that it claims it does not
have the overload of Mobile IP. But if we think of it really as just
hierarchical use of MIPv6, then this kinda contradicts itself.
Perhaps tone down a bit and shorten?

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.

This section seems to talk about two things without making clear
distinction:

   - how the MN discover the MAPs via the (aggregated) MAP options but could
     perhaps be done via DHCP as well, and, 
   - how the infrastructure is populated with MAP options. This latter
     problem has (1) dynamic MAP Info Progagation and the funky router 
     renumbering

Suggest the distinction be made clear. Note that the increase in size of
aggregated MAP options may be a concern for wireless packets.

Several instances of referring to other sections by "later" or
"this document." Please insert proper section references instead to
help the reader.

Several places say: this is just like  a normal BU, or "a MAP is like an
HA." There are exceptions. Suggest detailing what the differences are
in its own section.

*Lots* of NITS. In addition to those sent out recently, page lengths
or page breaks are off. References that are not normative should be
labelled "Informative".

To be consistent with MIPv6:

   s/HOTI/HoTI/ s/HOT/HoT/ s/COT/CoT/ s/COTI/CoTI/ s/COA/CoA/
   s/Home Agent/home agent/

Editorial
---------
p. 1

   s/[email-masked]/[email-masked]/

Abstract: To be consistent with the LMM document:

   s/local/localized/

Terminology:

   Access Router is defined in
   draft-ietf-seamoby-mobility-terminology-04.txt, suggest just
   referring to that and only defining that which is not defined
   there.

Intro and motivation

   Instead of "This draft introduces the concept of a Hierarchical
   Mobile IPv6 network, utilising", suggest: "This draft introduces the
   concept of Hierarchical Mobile IPv6 utilising"...
   The original seems to imply that a whole new network must be built
   for this, whereas that is not the case. Incremental deployment is
   actually possible.

   Suggest changing this:

	To do this a mobile node sends Binding Updates (BUs) to its
	Home Agent (HA) and all Correspondent Nodes (CNs) it
	communicates with, every time it moves."
   
   To this:

	Every time it moves, a mobile node sends Binding Updates (BUs) to its
	Home Agent (HA) and some (perhaps all) Correspondent Nodes (CNs) it
	communicates with.

   Suggest changing this:

	In addition, one round trip time is needed to update the Home
	Agent, this can be done simultaneously while updating
	correspondent nodes.

   To this:

	Updating the home agent requires one round trip time.
	This need not be additional to updating the correspondent nodes, 
	as both processes may, in fact, be partially simultaneous.

   Suggest changing this:

	...such solution reduces
	the number of messages sent over the air interface to all
	correspondent nodes and the Home Agent. A local anchor point will
	also allow Mobile IPv6 ...

   To this:

	...a local anchor point reduces
	the number of messages sent over the air interface to all
	correspondent nodes and the home agent. Such a solution 
	also allows Mobile IPv6 ...

   Suggest changing this:

	including the Access Router (AR).
	
   To this:

	including the access router (AR) (depending on the tradeoffs desired). 

   Change this:

   	- The mobile node sends Binding Updates to the local MAP rather than
          the HA that is typically further away and CNs

   	- The mobile node sends Binding Updates to the local MAP rather than
          to the HA and CNs, which are typically further away.

   Suggest changing this:

	The aim of introducing the hierarchical mobility management
	model in Mobile IPv6 is to enhance the performance of Mobile
	IPv6 while minimising the impact on Mobile IPv6 or other IPv6
	protocols.

   To this:

	The aim of introducing the hierarchical mobility management
	model is to enhance the performance of Mobile
	IPv6 while minimising the impact on it or other IPv6
	protocols.

   Suggest changing this:

	HMIPv6 allows mobile nodes to hide

   To this:

	HMIPv6 allows mobile nodes to obscure

Overview of HMIPv6

   Section number is wrong, should be 3.

   Change this: 

	This Hierarchical Mobile IPv6 scheme introduces a new function

   To this: 

	Hierarchical Mobile IPv6 introduces a new function

   Change this: 
   
	This makes the mobile node's mobility transparent to the
	correspondent nodes it is communicating with.

   To this: 
   
	This makes the mobile node's mobility within the MAP domain
   	transparent to the correspondent nodes it is communicating with.

   Figure 1 needs to be aligned/touched up.

HMIPv6 Operation

   Suggest deleting this:

	Normal processing of the received packets (as described in [1])
	will give the mobile node the necessary information.

   Because it repeats what the previous sentence says.

   Suggest changing this:

	To use the network bandwidth in a more efficient manner, a mobile
	node may decide to register with more than one MAP simultaneously

   To this:

	For several reasons, a mobile node may decide to register with
	more than one MAP simultaneously

   ...cuz multiple registrations offsets partially any gains in bandwidth
   utilization, but mainly because there may be other reasons for this
   (load balancing, etc).

   Suggest eliding the parentheses around:

	(of advertising the MAPÆs presence within its domain)

   s/introduced in future./introduced in the future./

Local Binding Update

   Move this:

	When a mobile node registers with the MAP, the M and A flags
	MUST be set to distinguish this registration from a Home
	Registration or a BU being sent to a correspondent node.

   After you've defined the packet format to be consistent with usage
   and for easier reading.

On-link Care-of address Test option

   Change this:

	In this section a new option, the On-link Care-Of address Test
	(OCOT) option is being introduced.

   To this:

	This section introduces a new option, the On-link Care-Of address Test
	(OCoT).

   cuz active voice is better (usually) than passive.

Neighbour Discovery extension - The MAP option message format

   Suggest adding before the packet format:

	Unless otherwise specified, processing is as dictated in [4].

   In the 'R' bit in the MAP option, change this:
   
	When set indicates that the mobile node MUST form an RCoA based
	on the prefix in the MAP option.

   To this:

	When set indicates that when forming an RCoA, the mobile node 
	MUST form it based on the prefix in the MAP option.

Protocol operation

   Change this:

	In HMIPv6, the mobile node has two addresses

   To this:

	The mobile node has two addresses derived as part of HMIPv6 operations
	(perhaps in addition to others it would normally acquire)

   Change this:

	This RCoA is formed in a stateless manner by combining the
	mobile nodeÆs interface identifier and the subnet prefix

   To this:

	This RCoA is formed in a stateless manner by appending the
	mobile nodeÆs interface identifier to the subnet prefix

Mobile node Operation

   There is no mention of the 'P' bit.

   s/The local BU is a BU defined in [1] and/The local BU is a BU as
   defined in [1] which/

   See comments on respinning the OCoT above.

   Suggest starting a new subsection titled "Registering with the Home
   Agent" before this line:

	After registering with the MAP, the mobile node MUST register
	its new

   s/with the MAP, received in/with the MAP as received in/

   s/privacy can not/privacy cannot/

MAP Operations

   s/The MAP acts like a HA/The MAP acts similar to an HA/

   This paragraph seems to be repeated:

	When sending a binding acknowledgement to the mobile node, the MAP...

   s/mobile node being the tunnel entry point and the MAP/
   mobile node's LCoA being the tunnel entry point and the MAP's global address/

   Change this:

	The MAP acts as a HA for the RCoA. Packets addressed to the
	RCOA are intercepted by the MAP, using proxy Neighbour
	Advertisement, encapsulated and routed to the mobile nodeÆs
	LCoA. This operation is identical to that of the HA described
	in [1].

   To this:

	Packets addressed to the RCoA are intercepted by the MAP, using
	proxy Neighbour Advertisement, encapsulated and routed to the
	mobile nodeÆs LCoA. This operation is analogous to that of the
	HA described in [1].

Router Operation for Dynamic MAP Discovery

   s/If the receiving router was also a MAP
   /If the receiving router is also a MAP/

Using Router Renumbering for MAP discovery

   The limitations should be listed in this section, not elsewhere.

Special optimisations for sending Binding Updates

   Perhaps doesn't add anything needed this time around.

Notes on MAP selection by the mobile node

   Erroneous reference to section 5.

Detection and recovery from MAP failures

   Suggest moving paragraph starting with:

	Access routers can be triggered to advertise...

   Before the paragraph starting with:

	In cases where such protocols are not supported,

Security considerations

   s/and the MAP is of strong nature/and the MAP be of strong nature/

Mobile node û MAP security

   Change this:

	A MAP only needs to make sure that when it receives a BU for a
	RCoA, this BU was issued by the same mobile node that
	established the Security Association.

   To this:

	A MAP only needs to make sure that when it receives a new BU for a
	RCoA, this BU was issued by the same mobile node with which it
	established the Security Association used to secure the initial 
	BU.

   The sentence:

	A return routability test is not necessary.

   ...seems unrelated. Note that a protocol such as IKE includes a liveness check
   already so an additional return routability test is not needed. Is this what is implied?

   The reference is missing in:

	either AH or ESP [ ] in transport mode

References

	s/Non-Normative/Informative

Authors' Addresses

	Get rid of chair section.

Appendix

   Agree with James that a reference may be better than this appendix (further 
   simplifying this draft).

---

From: Greg Daley <[email-masked]>
Date: Tue, 18 Nov 2003 12:54:21 +1100

Hi,

Just commenting on a couple of sections below.

gabriel montenegro wrote:
> 
> ------------------------------------------------------------------------
> 
> General comments:
> ----------------
> 

I'm actually a bit confused here, since the OCoT is essentially
an add-on test for HMIPv6, which already requires IKE for
security association bootstrapping.

This is more work than MIPv6 has to do to prove (to the HA) it is
at a location.

Maybe a BU without an ACK flag is sufficient, but there's some
chance of delivery being stalled if the OCoT message is lost
anyway.

> in MIPv6, and the same solutions should apply.

Just for reference, I think the discussion at the session
was that P and I bits were useful only if ingress filtering was
not applied to communications using the MAP prefix, within a domain.

It was difficult to see how this could be maintained on the edge of
a MAP domain, where it was possible that an MN roamed into a new
access network but needed (temporarily) to send and receive packets
using the existing RCoA.  Considering that the host may not know
(with current map options) whether it is in the same domain, and if
the RCoA can be used as a source without tunnelling.

If P and I flags aren't possible to use, then V is implied.

>      problem has (1) dynamic MAP Info Progagation and the funky router 

There are several reasons why  Dynamic propagation of information
is better than static configurations such as may be available in
DHC or in a router configured using command line options or
RADIUS.

The principle ones are that network topology can change, or
that the status of the HMIPv6 MAP is not actually known by
an advertiser.  Therefore, it would make sense if advertisement
was taking place, to develop a mechanism which allows dynamic
advertisement of HMIPv6 MAPs (or MIPv6 HAs), which actually
reflect the status of these systems.

How to do this correctly sounds like IRTF work.

At this stage, HMIPv6 is aiming at experimental, so we need only
have something to test with, but maybe the description offered could
talk about these goals.

Greg