Subject: [netlmm] comments to Sri's draft

From: RYUJI WAKIKAWA <[email-masked]>
Date: Sat, 10 Mar 2007 22:46:18 +0900

Hi Sri,

Here are my comments.

I didn't follow the netlmm ML before the Vidya's consensus call.  Some
of my comments may be already pointed out...

* end of P8
access access authentication procedure -> remove one access

* P9
"Upon accepting the Proxy Binding Update request, the mobile access
gateway sends a Proxy Binding Acknowledgment..."
-> It must be Local Mobility Anchor instead of mobile access gateway.

* What you referred as Policy in the draft can be defined in the
   terminology section

* Section 5.1
    "o  A flag indicating if IPv6 HoA mobility is accepted.  If this  
flag
       is set, the relevant IPv4 HoA fields in this data structure have
       to be set to the configured values.  If this flag."

    IPv4 HoA must be IPv6 HoA and the last sentence is incomplete.

* Section 5.1
    o  The interface id of the tunnel between the local mobility anchor
       and the mobile access gateway used for sending and receiving the
       mobile node's traffic.

Interface ID must be replaced with tunnel identifier.
Interface ID is too much implementation specific, although in section
6.2, the draft uses the tunnel identifier and explains how this can be
implemented.  I think this sentence must be fixed with the similar way
of section 6.2

* Time Stamp option.
I am not sure if this is the right way to ensure the BU order.  Which
time accuracy are you assumed for netlmm protocol?

There may be another way to solve this...
For example, whenever a new MAG sends PBU, it can flash the sequence
value with "0".  If the LMA receives PBU with the seq set to zero, it
just accepts this and discards any other PBUs sent by the old MAG.
Alternatively, you can set some flag indicating that this is PBU from
a new MAG.  This is a protocol for local domain, I am not sure whether
such restricted way to prevent packet ordering is required or not...

In addition to this, there is contradiction.  the draft first says
that LMA MUST ignore the sequence field in PBU. Then it said the LMA
can fall back to sequence number scheme if time stamp option is not
appeared.

* Section 5.4
What kind of scenario does MAG set 0.0.0.0 to the home address option?
The MAG can learn IPv4 HoA from the policy, no?  If this is the
required scenario, whenever a MN changes its attached MAG, each MAG
sends PBU with IPv4 HoA address allocation?  I may miss something
here, but I just don't understand the sequence of this IPv4 HoA
allocation...

* section 6.1
The first sentence missed period.

* section 6.11
When a LMA receives PBU from a new MAG due to MN movement, but it
still receives a PBU from the previous MAG.  LMA can notify to the
previous MAG to removes the BUL entry. It may useful to have signal
from LMA to MAG in general other than BA.

*section 7.1
The draft must mention when a MN has multiple interfaces.  In such
scenario, the MN may attach multiple interfaces to the netlmm link and
send identity from both of interfaces.  This scenario is not
considered in netlmm. Thus, the draft should say that something link:
"A MN can send its identity to only single access network in netlmm
domain all the time.  If MN has multiple active interfaces attached to
netlmm domain, it must send identify only from one of interface."

* section 7.3
The assumption of netlmm may be point-to-point access, but the draft
also supports shared link access network.

We recently publish
http://tools.ietf.org/id/draft-wakikawa-mip6-no-ndp-00.txt
This draft may help to update the RS/RA operation.

You must carefully operate RA (specially on-link flag). Otherwise, if
a malicious MN attached to a shared-link and obtains an IPv6 address
from a home prefix of some other MN, the malicious MN can communicate
with the MN on the link.  MAG cannot protects this packets between the
malicious MN and the MN.

* section 8
It is better to write MH type value for PBU and PBA.  It is not clear
whether this is an extension to the BU and BA of RFC3775 or brand-new
options.

thanks
ryuji

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

---

From: Heejin Jang <[email-masked]>
Date: Tue, 13 Mar 2007 23:12:18 +0000 (GMT)

I have some comments on the draft.

1. MAG location

- Unlike ver-01, it's not clearly stated where MAG is located. If MAG is not collocated with an access router, some functions such as sending MN-HNP in an RA would be difficult.

2. RA before PBU

- In Section 3, it seems that an RA with MN-HNP is sent before the PBU is accepted. There may be a problem if PBU is rejected.

- When the auto-configuration is allowed, the MN assumes that MN-HoA is valid right after completing the configuration. However, the HoA is valid only after PBU is accepted. Moreover, in case PBU is rejected afterward, the MN mistakenly assumes the invalid HoA is valid. 

- I think it's more robust to send an RA with MN-HNP after PBU is accepted.

- When PBU is rejected finally (after several trials), it's better to notify the rejection explicitly by sending RA (PI option including HLP with 0-lifetime) so that the MN cannot use the HoA based on HLP ASAP. 

3. Problem of RA unicast

- In Section 6, RA is supposed to be sent to the MN as a unicast by setting IPv6 destination = all-nodes multicast & link layer address = MN's MAC address. But how can MAG always know the MN's MAC address? If MN sends RS or NS with the unspecified source address (::) after link change, it may be difficult for MAG to learn MN's MAC address unless MN's profile includes it. 

4. Format of HNP option

- In Section 8, an HNP option can carry HNP or HoA but not both at the same time. We can make the option to carry both of them by defining a new bit as in 'R' flag in PI option (according to MIPv6 RFC3775). If the flag is set to 1, it means that HNP option includes HoA and the 'Prefix Length' field identifies the length of HLP which is already prepended to HoA. 

5. The use of 'on-link' prefix

- In section 7, it is written that ".. advertising the mobile node's home prefix as the on-link prefix and with the other configuration parameters". Does the 'on-link' mean that 'L-flag' in PI option should be set to 1 in RA? Should it be?

6. Overhead of RA unicast 

In PMIP domain, there may be MNs with cmip capabililty and without cmip capability that require network based mobility. Therefore MAG cannot send multicast RAs but needs to send unicast RAs node-by-node all the time.
 
-Regard
Heejin