Re: [MEXT] questions/comments // Review of Re:I-DAction:draft-ietf-monami6-multiplecoa-12.txt

Thank you Christian for your reply.

I know the section 6.4 is about route optimization, but

I have another childish question: does any NAT may

exist between two IPv6 node? In my original question, I

think it as there is a NAT between two IPv6 node.

As to the trouble on mail-list, I have know how to avoid

it now.

Regards

Xiangsong

华为技术有限公司

地址：深圳市龙岗区坂田华为基地邮编：518129
http://www.huawei.com
-------------------------------------------------------------------------------------------------------------------------------------
本邮件及其附件含有华为公司的保密信息，仅限于发送给上面地址中列出的个人或群组。禁
止任何其他人以任何形式使用（包括但不限于全部或部分地泄露、复制、或散发）本邮件中
的信息。如果您错收了本邮件，请您立即电话或邮件通知发件人并删除本邮件！
This e-mail and its attachments contain confidential information from HUAWEI, which
is intended only for the person or entity whose address is listed above. Any use of the
information contained herein in any way (including, but not limited to, total or partial
disclosure, reproduction, or dissemination) by persons other than the intended
recipient(s) is prohibited. If you receive this e-mail in error, please notify the sender by
phone or email immediately and delete it!

----- Original Message -----

From: Christian Kaas-Petersen

To: Xiangsong Cui

Cc: mext at ietf.org

Sent: Thursday, March 19, 2009 4:37 PM

Subject: Re: [MEXT] questions/comments // Review of Re:I-DAction:draft-ietf-monami6-multiplecoa-12.txt

Concerning first comment. For reasons of security, the correspondent
node must reject bulk registrations. As a consequence, the mobile
node should refrain from sending bulk registrations. Bulk registrations
with a correspondent node is out of scope of the draft. I agree with
you the draft could use the keywords MUST and SHOULD more clearly.

Concerning second comment. Section 6.4 deals with payload packets,
explicitly stated not with signaling packets. It also explicitly states
what shall be done with the packet when a Home Address destination option
is present. This means the section talks about the case, where the
mobile node has done route optimization with a correspondent node.
Route optimization is possible from IPv6 addresses to correspondent
nodes's IPv6 addresses; route optimization cannot be done when sending
from IPv4 addresses.

I am not able to assist you on the mail-sending issue.

Christian

--- Den tors 19/3/09 skrev Xiangsong Cui <Xiangsong.Cui at huawei.com>:

Fra: Xiangsong Cui <Xiangsong.Cui at huawei.com>
Emne: questions/comments // [MEXT] Review of Re: I-DAction:draft-ietf-monami6-multiplecoa-12.txt
Til: "Christian Kaas-Petersen" <kaaspetersen at yahoo.dk>, "Benjamin Lim" <benjamin.limck at sg.panasonic.com>, ryuji at jp.toyota-itc.com, vijay at wichorus.com, thierry.ernst at inria.fr, nagami at inetcore.com
Cc: "mext" <mext at ietf.org>
Dato: torsdag 19. marts 2009 03.00

Hello all,

I am a newcomer in IETF and I am reading the draft
"draft-ietf-monami6-multiplecoa-12".

I have two questions/comments on the draft.

The first one:

In section 5.3 it says "A mobile node performing bulk registration
with a correspondent node is out of scope.", while in the section 6.2
it says that CN must reject the bulk registration from MN.
I think MN shall not perform bulk registration with a CN, if the
section 6.2 is followed, but not say "out of scope".

5.3. Bulk Registration
Bulk registration is an optimization for binding multiple care-of
addresses to a home address using a single Binding Update. This is
very useful if the mobile node, for instance, does not want to send a
lot of signaling messages through an interface where the bandwidth is
scarce. This document specifies bulk registration only for the
mobile node's home registration. A mobile node performing bulk
registration with a correspondent node is out of scope.

6.2. Processing Binding Update
o When multiple Binding Identifier mobility options are present in
the Binding Update, it is treated as bulk registration. If the
receiving node is a correspondent node, it MUST reject the Binding
Update and returns the status value in the binding Acknowledgement
set to [MCOA BULK REGISTRATION NOT SUPPORT].

The second one:

As the section 6.4, in my mind, if there is NAT between MN and CN, the
IP packets received by CN maybe have been modified by the NAT, especially
the source address. Is it true?
If the modification is permitted, I think CN shall not check the source
address and reject the packets whose address have been changed.

6.4. Receiving Packets from Mobile Node
When a node receives packets with a Home Address destination option
from a mobile node, it MUST check that the care-of address that
appears in the source address field of the IPv6 header MUST be equal
to one of the care-of addresses in the binding cache entry. If no
binding is found, the packets MUST be discarded. The node MUST also
send a Binding Error message as specified in [RFC-3775]. This
verification MUST NOT be done for a Binding Update.

If I made wrong comprehension please tell me.

By the way, I meet another problem in the E-mail. I have sent the E-mail
to the mail list mext at ietf.org twice, but I think nobody received the mail.
I have checked the E-mail Sever in my company and the result showes that
the E-mail has beed sent out successfully in the log.
I don't know whether this E-mail will be received by the mail-list and how
can I solve the problem?

Any response is appreciated.

Thanks and Regards

Xiangsong

Trænger du til at se det store billede? Kelkoo giver dig gode tilbud på LCD TV! Se her http://dk.yahoo.com/r/pat/lcd
_______________________________________________
MEXT mailing list
MEXT at ietf.org
https://www.ietf.org/mailman/listinfo/mext