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

From: "James Kempf" <[email-masked]>
Date: Fri, 7 Nov 2003 14:50:00 -0800

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, especially since it is
going to experimental.

Here are my comments:

Technical:

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. 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.

Section 7.2 - I'm skeptical of the router renumbering method of MAP
advertisement. Last I heard (which admittedly was a while ago), router
renumbering was not widely implemented. Since this draft is going to
experimental it probably is OK to keep it in, but I think it needs to be
tested and co-ordinated with the IPv6 product deployment scene going
forward.

Also, I've brought up the issue of having a discovery option independent of
the router, but we've agreed to consider that in another draft.

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

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.  I think this will need
some attention before this protocol is ready for deployment in real ISP's
networks.

Editorial:

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

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.

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.

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.

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.

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

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.

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.

            jak

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