Subject: Re: [MEXT] WGLC for draft-ietf-monami6-multiplecoa-07.txt

From: Chan-Wah Ng <[email-masked]>
Date: Sat, 03 May 2008 11:49:07 +0800

On Wed, 2008-04-30 at 13:31 +0200, marcelo bagnulo braun wrote:
> Hi,
> 
> This is the WGLC for draft-ietf-monami6-multiplecoa-07.txt. Please check 
> if all the issues that were raised have been addressed in this new 
> version. If you have issues with the document, please raise them. If you 
> are ok with the document and you think it should be sent to the ISEG, 
> please also say so. Provide comments till may 14.
> For your convinience, the document can be found at:
> 
> 	Title           : Multiple Care-of Addresses Registration
> 	Author(s)       : R. Wakikawa, et al.
> 	Filename        : draft-ietf-monami6-multiplecoa-07.txt
> 	Pages           : 44
> 	Date            : 2008-04-29
> 
> 
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-ietf-monami6-multiplecoa-07.txt
> 

Hello,

following is my review on the first 7 sections of the draft.

---

[Section 1 - Pg 5]

The first paragraph explained the motivation for this work, but failed
to reference the other WG document on the analysis of why MIPv6 cannot
fulfill such motivation.  I would add in some text as follows:

   A mobile node may use various types of network interfaces to obtain
   durable and wide area network connectivity.  This is increasingly
   become true with mobile nodes having multiple interfaces such as
   802.2, 802.11, 802.16, cellular radios, etc..  The motivations for
   and benefits of using multiple points of attachment are discussed in
   [ID-MOTIVATION].  When a mobile node with multiple interfaces uses
   Mobile IPv6 [RFC-3775] for mobility management, it cannot use its
   multiple interfaces to send and receive packets while taking
   advantage of session continuity provided by Mobile IPv6.  This is
   because Mobile IPv6 allows the mobile node to only bind one care-of
   address at a time with its home address.

<suggested addition>
   See [ID-MIP6ANALYSIS] on a further analysis of using multiple
   interfaces and addresses with Mobile IPv6.
</suggested addition>

----

[Section 2 - Pg 6]

   Binding Identification number (BID)

      The BID ...
                  ...        Zero and negative values MUST NOT be used.

This is strange ... BID is defined as unsigned 16 bit integer ... how
can negative values be used?  What is the meaning of "negative values"
here?  Note same comment applies to [Section 5.1, pg 16].

   Bulk Registration

      A mobile node can register multiple bindings at once by sending a
      single Binding Update.  A mobile node can also replace some or all
      the bindings available at the home agent with the new bindings by
      using the bulk registration.  Bulk registration is supported only
      for home registration (i.e. with the home agent) as explained in
      Section 5.4.  A mobile node MUST NOT perform bulk registration
      with a correspondent node.

The last part seems to be too strong ... the only reason why an MN
should not perform bulk registration IMHO is because this specification
does not want to support it "for protocol simplicity".  Simply say so
like changing the last sentence to "Bulk registration with a
correpondent node is not supported in this specification."  Saying MN
"MUST NOT" seems to suggest there is a strong security or protocol
design reason for MN not to do so which is not explained -- the only
reason stated is in pg 7:

                                                    ....  For protocol 
   simplicity, bulk registration to correspondent nodes is not supported
   in this document.  This is because the Return Routability mechanism
   introduced in [RFC-3775] cannot be easily extended to verify multiple
   care-of addresses stored in a single Binding Update.

This, IMHO, does not justify the use of a strong "MUST NOT".

---

[Section 3 - Pg 7]

Editorial -- plural/singular mismatch:

   Figure 1 illustrates the configuration where the mobile node obtains
   multiple care-of addresses at foreign links.  The mobile node can
   utilize all the care-of address.  In Figure 1, the home address of
                           ^^^^^^^  addresses

---

[ Section 4.2 - Pg 12-14]

4.2.  Binding Identifier Mobility Option

Typically for new options defined, the byte alignment should be
specified.   This may get a bit tricky, though, since depending on
whether Care-of Address field is present or not, and what kind of
care-of address, the byte alignment requirement will change.

   ...

   Status

      When the Binding Identifier mobility option is included in a
      Binding Acknowledgement, this field overwrites the status field in
      the Binding Acknowledgement.  If this field is zero, the receiver
      MUST use the registration status stored in the Binding
      Acknowledgement message.  This Status field is also used to carry
      error information related to the care-of address test in the
      Care-of Test message.  The status is 8-bit unsigned integer.  The
      possible status codes are the same as the status codes of Binding
      Acknowledgement.

What happens to this field when the option is included in the Binding
Update message?  Should it be set to zero, and ignored by the receiver
or what?

   ...

   Reserved

      5 bits Reserved field.  The reserved field MUST be zero.

Typically, a spec would mandate sender to set reserved bit to 0 and
response of receiver if the bits are non-zero -- so should the receiver
silently ignore the bits, silently discard the BU, reply with Binding
Error, or what?

---

   Care-of Address

      This field has the variable length depending on the specified
      flags.  Either IPv4 or IPv6 care-of address for the corresponding
      BID can be stored in this field.  This field MUST NOT be used if a
      Binding Identifier mobility option is included in any other
      message other than a Binding Update.

The description of this field leaves me wondering.   Firstly, "depending
on the specified flags."  What flags?  Whose flags?  There are only two
flags in this option, H and O.  None seems to affect the length of this
field.  A more precise description should be given here.  Secondly,
"This field MUST NOT be used ... in any other message other than a
Binding Update".  What is the meaning of must not be used?  Does it
means that this field is still there in a BA?  Should the field becomes
a zero-length field in BA or should it be set to zero and ignored by
receiver?  Or if the field is not there, i.e. the Length field is 8,
then this field can be omitted in this option (which is the case based
on later sections).  Some text here should describe it clearly here.
Answering this question also goes back to the question of byte alignment
for this BID option.

---

[Section 4.3 - pg 14 to 15]

   MCOA NOTCOMPLETE (TBD < 128)
   MCOA RETURNHOME WO/NDP (TBD < 128)
   MCOA MALFORMED (TBD more than 128)
   MCOA BID CONFLICT (TBD more than 128)
   ...

Editorial -- you used "TBD < 128" but use "TBD more than 128".  Better
to be consistent.

---

[Section 5.3, pg 17]

               IPv6 header (src=CoA, dst=HA)
                    IPv6 Home Address Option
                    ESP Header  (for home registration)
                    Mobility header
                        -Binding Update
                       Mobility Options
                          - Binding Identifier mobility option
                          - Binding Authorization mobility option
                            (for Route Optimization)

             Figure 6: Binding Update for Binding Registration

Figure 6 uses parenthesis in inconsistent ways.  The first line, IPv6
Header, it is used to display the contents; subsequently, it is used to
indicate the conditions for the relevant contents to be there.  I would
instead suggest you break the figure into two, one for BU sent to HA,
and one for BU sent to CN, thereby eliminating the need for subsequent
parenthesis.  Also, the use "-" as bullets can be omitted.

---

[Section 5.5, pg 18]

   ....               The care-of addresses field in each mobility
   option SHOULD be omitted by the sender and MUST be ignored by the
   receiver.  This is because the receiver will remove the binding that
   matches the specified BID.

Similar to previous comment in Section 4.2, what is the meaning of
"should be ommitted"?  The filed is there or not?

---

[Section 6.1, pg 27]

Apart from the first paragraph, the section seems to concentrate only on
correspondent node.  I think the description fits both the correspondent
node and home agent.  Thus, the terminology used should be corrected
(either replace "correspondent node" with "correspondent node or home
agent", or create a term such as "correspondent entity" as per RFC 4889,
"recipient", or even "the node" as used in later part of Sect 5).

---

[Section 6.3, pg 28]

   o  When the Length value is either 12 or 20, the care-of address MUST
      be present in the Binding Identifier mobility option.  If the
      care-of address is not present, the receiver MUST reject the
      Binding Identifier mobility option and returns the status value
      set to [MCOA MALFORMED].  If the Length value is 12, an IPv4 valid
      address MUST be present.  Otherwise, an IPv6 address MUST be
      stored in the Binding Identifier mobility option.

The description here is a bit dubious.  If the length is 12 or 20, the
next 32 or 128 bits after the Reserved field would be treated as the
care-of address.  Since this is a section about CN/HA's operation, it
shouldn't be CoA "MUST be present".  This is not a requirement for the
recipient, it is a requirement on the sender.  Instead, the CN/HA "MUST
treat the next few bits after Reserved field as the CoA.  Similarly,
there is no such thing as "If the care-of address is not present".  So,
the wording should instead be "if the address in the Care-of Address is
not valid".  Similarly for the later part, it is not a question of
IPv4/IPv6 address must be present.  It should instead be phrased as that
the CN/HA must treat the next 32 bits as an IPv4 care-of address, or
next 128bits as an IPv6 care-of address, and then returns error if it is
not a valid care-of address.

---

[Section 6.3, pg 29]

   o  If the 'O' flag is set in the de-registering Binding Update, it is
      ignored.  If the 'H' flag is set, the home agent stores a home
      address in the Care-of Address field of the binding cache entry.
      The home agent also stops performing proxy ND for the mobile
      node's home address.

The last part doesn't seems to be in sync with what was mentioned in
Section 5.6.3.  I think the home agent would decide whether to stop or
continue ND proxy depending on whether it is the only router on the home
link, and responds with the appropriate Status code according to Sect
5.6.3.

---

[Section 6.3, pg 29]

   When a correspondent node sends a Binding Acknowledgement, the status
   value MUST be always stored in the Status field of the Binding
   Acknowledgement and the Status field of Binding Identifier mobility
   option set to zero.  For the home agent, the status value can be
   stored in the Status field of either a Binding Acknowledgement or a
   Binding Identifier mobility option.  If the status value is specific
   to one of bindings in the bulk registration, the status value MUST be
   stored in the Status field in the corresponding Binding Identifier
   mobility option.  In this case, [MCOA NOTCOMPLETE] MUST be set to the
   Status field of the Binding Acknowledgement so that the receiver can
   examine the Status field of each Binding Identifier mobility option
   for further operations.

In the later part on home agent of the above paragraph, I think it might
be necessary to say that for BID Options that do not have a specific
different status, the status field of these BID options should be set to
zero (which mean the status in the BA will be used).

---

[Section 6.4, Pg 30]

6.4.  Sending Binding Refresh Request

   When a node (home agent or correspondent node) sends a Binding
   Refresh Request for a particular binding created with the BID, the
   node SHOULD include the Binding Identifier mobility option in the
   Binding Refresh Request.  If the mobile node had used bulk
   registration, the sender SHOULD include all the Binding Identifier
   mobility options.  If the mobile node had not used bulk registration,
   the sender includes the Binding Identifier mobility options only for
   those bindings that need to be refreshed.

The second sentence seems to indicate that the home agent must somehow
recall if the mobile node had previously used Bulk Registration or not.
No where else in this spec seems to mention this requirement for the
home agent.  My personal feeling is that it is redundant, since if the
mobile node used bulk registration, the lifetime for all the CoA should
be the same, and they would have to be refreshed at the same time and
hence be included in the BRR anyway.  So I suggest removing the 2nd
sentence, and remove the first part of the 3rd sentence -- i.e.:

   When a node (home agent or correspondent node) sends a Binding
   Refresh Request for a particular binding created with the BID, the
   node SHOULD include the Binding Identifier mobility option in the
   Binding Refresh Request.  The sender MAY include multiple Binding 
   Identifier mobility options if there are multiple bindings that 
   need to be refreshed.

---

[Section 6.5, pg 30-31]

Editorial:  Remove "silently" in

   .....                                                        If no
   binding is found, the packets MUST be silently discarded.  The node
   MUST also send a Binding Error message as specified in [RFC-3775].

If a BE is sent, it is not a "silently discard".

---

I am deferring Sect 8 and Sect 9 for later as I need to read the other
drafts more carefully first to understand the interactions.  

I am, however, curious with the omission of HMIP from this spec.  You
have Section 7 on NEMO, Section 8 on DSMIP (which is a work-in-progress,
so arguably the interaction might change if there are some changes in
DSMIP), but nothing is said on HMIP which is already an RFC long ago.

/rgds
/cwng
_______________________________________________
MEXT mailing list
[email-masked]
https://www.ietf.org/mailman/listinfo/mext

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 27 May 2008 13:51:45 +0900

Hello Chan-Wah

Thanks for detailed comments.

All your comments are editorial and clarification.
We can easily fix your comments.
Thanks again. Some comments are below.

>   interfaces and addresses with Mobile IPv6.

Right. I will add this reference.

> here?  Note same comment applies to [Section 5.1, pg 16].

ok

> reason stated is in pg 7:

This specification isn't designed to perform bulk registration to CN.
We need to prohibit this, right?

> This, IMHO, does not justify the use of a strong "MUST NOT".

Here are the definition from RFC2119.

2. MUST NOT This phrase, or the phrase "SHALL NOT", mean that the  
definition is an absolute prohibition of the specification.
4. SHOULD NOT This phrase, or the phrase "NOT RECOMMENDED" mean that  
there may exist valid reasons in particular circumstances when the  
particular behavior is acceptable or even useful, but the full  
implications should be understood and the case carefully weighed  
before implementing any behavior described with this label.

I still think "MUST NOT" is appropriate here.
Bulk registration specified in this doc has no mechanism to verify the  
CoAs. RR cannot not protect all the CoAs.
Other separate document can specify the bulk registration for CN later.

>   utilize all the care-of address.  In Figure 1, the home address of

thanks:-)

> Update message?  Should it be set to zero, and ignored by the receiver

Should be set to zero. However, the receiver ignores this field if the  
option is carried with BU.

> silently ignore the bits, silently discard the BU, reply with Binding

There is no reason to reject the BU only because the reserved field is  
not zero.

> on the specified flags."  What flags?  Whose flags?  There are only  

right. This is old text. According to George's comment, we removed the  
flags.
Will fix this.

> receiver?  Or if the field is not there, i.e. the Length field is 8,

this field is appeared only when a CoA address value is presented.

> Editorial -- you used "TBD < 128" but use "TBD more than 128".  Better

Ok.

> "should be ommitted"?  The filed is there or not?

The field is not there.

> "recipient", or even "the node" as used in later part of Sect 5).

ok
> link, and responds with the appropriate Status code according to Sect

right. will fix this.

> zero (which mean the status in the BA will be used).

OK.

>   Identifier mobility options if there are multiple bindings that

OK, I will use your proposed text.

> DSMIP), but nothing is said on HMIP which is already an RFC long ago.

There were strong interests to extend NEMO/DSMIP for MCoA.
You are the first to mention HMIP.  Are you interested in HMIP?
How about considering HMIP after PS RFC is published, if anybody are  
interested in this work.

I am not going to support HMIP in this spec and want to finish WGLC.

thanks!
ryuji

---

From: Chan-Wah Ng <[email-masked]>
Date: Tue, 27 May 2008 14:29:13 +0800

Hello Ryuji,

Some responses to your responses inline (while others are snipped).

> We need to prohibit this, right?

Prohibit?  Why?  I think it suffice to say this spec does not provide
mechanism for bulk registration to CN.

> Other separate document can specify the bulk registration for CN later.
If you still prefer to use the phrase "MUST NOT", I suggest some text
change:

     ... home registration (i.e. with the home agent) as explained in
     Section 5.4.  A mobile node MUST NOT use the bulk registration
     mechanism described in this specification with a correspondent node.

> option is carried with BU.

My point is, this receiver behavior should be specified.

> There is no reason to reject the BU only because the reserved field is  

As above, my point is, this behavior should be specified.

> I am not going to support HMIP in this spec and want to finish WGLC.

Ah, it is not that I want HMIP ... I just see no reason why MCoA cannot
be used with HMIP.  A simple description (as simple as that for NEMO)
would have sufficed, I think.  However, I am okay if the WG feels it is
okay to omit HMIP.  Just be careful then with the flow filtering work --
I think I read some version of the individual drafts, and they claim
that it is possible for a MAP to be a filtering agent.  I just don't see
how MAP can be a filtering agent if it does not have the capability to
accept multiple LCoAs bound to a RCoA.

/rgds
/cwng

---

From: Ryuji Wakikawa <[email-masked]>
Date: Tue, 27 May 2008 15:58:00 +0900

Hi Chan-Wah

>     mechanism described in this specification with a correspondent  

this is fine.

> My point is, this receiver behavior should be specified.

I will add this sentence.
"The receiver MUST ignore this field if the option is not carried with  
BA."

> As above, my point is, this behavior should be specified.

I'll change it to
"The value MUST be  initialized to zero by the sender, and MUST be  
ignored by the receiver."

> accept multiple LCoAs bound to a RCoA.

If nobody uses it and wants it, no reason to support HMIP.
It is endless if we support all the extensions for Mobile IP;-)

ryuji