headers
Kent Leung (kleung | 4 Jan 2006 20:56
Picon
Favicon

Generalizing draft-jang-dhc-haopt for MIPv6 support in DHCP

Hi.   This draft should probably be named draft-jang-dhc-mip6options.

1) There were talks of folding this draft into draft-ietf-mip6-bootstrapping-integrated-dhc.  I would prefer to keep the DHCP draft as standalone as an independent DHCP options document for MIPv6.  How is this going to be decided?

2) Can we add the Home Address Option to the DHCP draft to provide general MIPv6 capability.  This allows the Home Address to be assigned by the network via DHCPv6.  There are solutions that use DHCP to obtain the Home Address for MN to register.  The Home Agent address can be obtained via DHCP, so seems natural for the HoA to be available as well.  There doesn't seem to be any harm for this additional option in the draft.

3) Any other MIPv6 attributes that should be conveyed in DHCP Options?

Kent

--
     |         |                   Kent Leung
    :|:       :|:                  IP Mobility Development
   :|||:      :|||:                 Internet Technologies Division
  :|||||||:  :|||||||:                Voice: +1.408.526.5030
.:|||||||||:.:|||||||||:.              Email: kleung <at> cisco.com
c i s c o S y s t e m s  http://www.ciscopress.com/title/158705132X

 
_______________________________________________
Mip6 mailing list
Mip6 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mip6
Permalink | Reply | 1 comment |
headers
johnny pan | 8 Jan 2006 11:22
Picon
Favicon

A question about MIPv6!

Hello everybody, i have a question about RFC3775 and i hope somebody can solve my puzzle.
It's about the procedure of the MIPv6.
When MN move into the foreign network, it register in HA with its CoA, and then the outside CN or MN itself may initiate the first communication with each other. Does that mean whoever initiate the communication, the first packet must pass the HA through the IPv6-in-IPv6 tunnel? Does MIPv6 differ from MIPv4 in this point? Because as i know in MIPv4, the packets sent by MN will be directed toward CN, but the packets return from CN will pass the tunnel between HA and MN.
Does that mean before MN initiate the Return Routability test and the Binding Update between MN and CN, the communication between MN and CN must forwarded by HA through the bi-directional tunnel between MN and HA?  In my opinion, the procedure is:
1.Registration of MN with HA.
2.Communications between MN and CN through HA with the bi-directional tunnel.
3.MN initiate the Return Routability test, and then send Binding Update to CN
4.After the BU and BA between MN and CN, communication between MN and CN can be set up directly without the participation of HA.
I don't know whether my understanding is right or not. The two modes of Reverse Tunneling and RO  only one of them could be used? or just they can be used both according to the accomplishment of RRT and Binding Update procedure between MN and CN.
 
Thank you so much!
 
pann
2006-01-08

雅虎1G免费邮箱百分百防垃圾信
雅虎助手¨D搜索、杀毒、防骚扰 
_______________________________________________
Mip6 mailing list
Mip6 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mip6
Permalink | Reply | 1 comment |
headers
Francis Dupont | 8 Jan 2006 18:27

Re: A question about MIPv6!

 In your previous mail you wrote:

     Does that mean before MN initiate the Return Routability test and
  the Binding Update between MN and CN, the communication between MN
  and CN must forwarded by HA through the bi-directional tunnel
  between MN and HA?

=> this is the standard behavior but is not mandatory, i.e., the MN or
the CN may launch a RR test before sending the first traffic packet.
(The real issue is this needs a priori knowledge of future communications)

   I don't know whether my understanding is right or not. The two modes of
   Reverse Tunneling and RO  only one of them could be used?

=> Routing Optimization is as its name suggests an *optimization*.

Regards

Francis.Dupont <at> point6.net
Permalink | Reply | 0 comments |
headers
johnny pan | 9 Jan 2006 11:02
Picon
Favicon

Re: A question about MIPv6!

So when will the RRT begin? Can this happen: after a short time of data transmission between MN and CN through bi-direnctional tunnel,  MN start RRT and send BU to CN, after that MN switch the transmisson directly to CN? Can this happen? Or it is for sure that after MN register with HA, it will start RRT and register with CN at once before any data transmission between MN and CN, if CN support MIPv6 and have a binding cache?
When i disscuss this with my classmate, we cannot agree with each other, and we cannot find enough evidence in RFC3775, so i hope i can get some help here.
His opinion about the procedure is as follow:
1.MN register with HA and get a CoA
2.begin RRT with CN at once before any data transmission, and through which MN will know whether CN support RO. If CN does support RO, MN will send data directly to CN; if not, all data transmission will pass HA. It can be described as a procedure of "Register with HA->RRT->direct data transmission".
And my opion is:
1.MN register with HA and get a CoA
2.MN or CN may initiate data communication first, and becauce MN have no information about CN(if MN send data to the "unknown" CN first), this kind of communication will have to pass HA. After some time of data transmission, MN initiate the RRT and register with CN. It can be described as a procedure of "Register with HA->data transmission->RRT->new transmission route".
I don't know who is right. So what do you think? Thank you so much!
 
ps: I am a postgraduate student and also a part-time tourist guide of Beijing. If anyone answer this letter and help me to solve this problem, i will offer you a free interpretation.
 
Regards
 
pann
2006-01-09
发件人： Francis Dupont
发送时间： 2006-01-09 01:27:48
收件人： johnny pan
抄送： mip6 <at> ietf.org
主题： Re: [Mip6] A question about MIPv6!
 
 In  your  previous  mail  you  wrote:
 
         Does  that  mean  before  MN  initiate  the  Return  Routability  test  and
   the  Binding  Update  between  MN  and  CN,  the  communication  between  MN
   and  CN  must  forwarded  by  HA  through  the  bi-directional  tunnel
   between  MN  and  HA?
 
= >  this  is  the  standard  behavior  but  is  not  mandatory,  i.e.,  the  MN  or
the  CN  may  launch  a  RR  test  before  sending  the  first  traffic  packet.
(The  real  issue  is  this  needs  a  priori  knowledge  of  future  communications)
 
     I  don't  know  whether  my  understanding  is  right  or  not.  The  two  modes  of
     Reverse  Tunneling  and  RO    only  one  of  them  could  be  used?
 
= >  Routing  Optimization  is  as  its  name  suggests  an  *optimization*.
 
Regards
     
Francis.Dupont <at> point6.net
 

雅虎1G免费邮箱百分百防垃圾信
雅虎助手¨D搜索、杀毒、防骚扰 
_______________________________________________
Mip6 mailing list
Mip6 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mip6
Permalink | Reply | 752 comments |
headers
Francis Dupont | 9 Jan 2006 11:49

Re: A question about MIPv6!

 In your previous mail you wrote:

     His opinion about the procedure is as follow:
     1.MN register with HA and get a CoA
     2.begin RRT with CN at once before any data transmission, and
     through which MN will know whether CN support RO. If CN does
     support RO, MN will send data directly to CN; if not, all data
     transmission will pass HA. It can be described as a procedure of
     "Register with HA->RRT->direct data transmission".

     And my opinion is:
     1.MN register with HA and get a CoA
     2.MN or CN may initiate data communication first, and becauce MN
     have no information about CN(if MN send data to the "unknown" CN
     first), this kind of communication will have to pass HA. After
     some time of data transmission, MN initiate the RRT and register
     with CN. It can be described as a procedure of "Register with
     HA->data transmission->RRT->new transmission route".

=> in fact both are possible, it is a matter of implementation.
At one possible exception, IMHO all implementations are reactive
(i.e., launch RRT only when some unoptimized traffic is seen on
the MN-HA tunnel) but some offer an API which can be used to
support the preactive (i.e., the first option) way.
BTW RFC 3775 gives some hints in the 11.7.2 section with this statement
at the beginning:

   Considerations regarding when (and if) to initiate the procedure
   depend on the specific movement and traffic patterns of the mobile
   node and are outside the scope of this document.

but just after there are the conditions for triggering RRT from
received traffic on the tunnel:

   In addition, the mobile node MAY initiate the correspondent
   registration in response to receiving a packet that meets all of the
   following tests:

this is why I use the term "hints" (:-).

Regards

Francis.Dupont <at> point6.net

PS: the possible exception is from a very old discussion in this list
where an implementor described the proactive way (which has interesting
security properties).
Permalink | Reply | 0 comments |
headers
Alper Yegin | 10 Jan 2006 00:08

RE: Generalizing draft-jang-dhc-haopt for MIPv6 support in DHCP


Hi.   This draft should probably be named draft-jang-dhc-mip6options.
1) There were talks of folding this draft into
draft-ietf-mip6-bootstrapping-integrated-dhc.  I would prefer to keep the
DHCP draft as standalone as an independent DHCP options document for MIPv6. 
How is this going to be decided?

Alper>>> FWIW, the authors also think that it makes sense to keep this I-D a
standalone one.

2) Can we add the Home Address Option to the DHCP draft to provide general
MIPv6 capability.  This allows the Home Address to be assigned by the
network via DHCPv6.  There are solutions that use DHCP to obtain the Home
Address for MN to register.  The Home Agent address can be obtained via
DHCP, so seems natural for the HoA to be available as well.  There doesn't
seem to be any harm for this additional option in the draft.

Alper>>> It sounds useful and I cannot think of any problems with doing so.

Alper.

3) Any other MIPv6 attributes that should be conveyed in DHCP Options?
Kent
--
     |         |                   Kent Leung
    :|:       :|:                  IP Mobility Development
   :|||:      :|||:                 Internet Technologies Division
  :|||||||:  :|||||||:                Voice: +1.408.526.5030
.:|||||||||:.:|||||||||:.              Email: kleung <at> cisco.com
c i s c o S y s t e m s  http://www.ciscopress.com/title/158705132X
 
Permalink | Reply | 0 comments |
headers
rfc-editor | 10 Jan 2006 02:38
Favicon

RFC 4285 on Authentication Protocol for Mobile IPv6


A new Request for Comments is now available in online RFC libraries.

        RFC 4285

        Title:      Authentication Protocol for Mobile IPv6
        Author(s):  A. Patel, K. Leung, M. Khalil, H. Akhtar,
                    K. Chowdhury
        Status:     Informational
        Date:       January 2006
        Mailbox:    alpesh <at> cisco.com, kleung <at> cisco.com,
                    mkhalil <at> nortel.com, haseebak <at> nortel.com,
                    kchowdhury <at> starentnetworks.com
        Pages:      19
        Characters: 40874
        Updates/Obsoletes/SeeAlso:    None

        I-D Tag:    draft-ietf-mip6-auth-protocol-07.txt

        URL:        ftp://ftp.rfc-editor.org/in-notes/rfc4285.txt

IPsec is specified as the means of securing signaling messages
between the Mobile Node and Home Agent for Mobile IPv6 (MIPv6).
MIPv6 signaling messages that are secured include the Binding
Updates and Acknowledgement messages used for managing the bindings
between a Mobile Node and its Home Agent.  This document proposes an
alternate method for securing MIPv6 signaling messages between
Mobile Nodes and Home Agents.  The alternate method defined here
consists of a MIPv6-specific mobility message authentication option
that can be added to MIPv6 signaling messages.

This document is a product of the Mobility for IPv6 Working Group of
the IETF. 

This memo provides information for the Internet community.  It does
not specify an Internet standard of any kind.  Distribution of this
memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to IETF-REQUEST <at> IETF.ORG.  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to RFC-DIST-REQUEST <at> RFC-EDITOR.ORG.

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to rfc-info <at> RFC-EDITOR.ORG with the message body 
help: ways_to_get_rfcs.  For example:

        To: rfc-info <at> RFC-EDITOR.ORG
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to RFC-Manager <at> RFC-EDITOR.ORG.  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
RFC-EDITOR <at> RFC-EDITOR.ORG.  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

Joyce K. Reynolds and Sandy Ginoza
USC/Information Sciences Institute

...

Below is the data which will enable a MIME compliant Mail Reader 
implementation to automatically retrieve the ASCII version
of the RFCs.
Attachment: message/external-body, 102 bytes
Attachment (rfc4285.txt): message/external-body, 72 bytes
_______________________________________________
IETF-Announce mailing list
IETF-Announce <at> ietf.org
https://www1.ietf.org/mailman/listinfo/ietf-announce
Permalink | Reply | 0 comments |
headers
johnny pan | 11 Jan 2006 08:16
Picon
Favicon

Re: A question about MIPv6!

Thank you so much! You are such a kind man!
 
But my classmate still have some puzzle about the details and we still have some different understanding about the "Preactive mode" and the "Reactive mode".
 
In my previous letter, i wrote:
 
         His  opinion  about  the  procedure  is  as  follow:
         1.MN  register  with  HA  and  get  a  CoA
         2.begin  RRT  with  CN  at  once  before  any  data  transmission,  and
         through  which  MN  will  know  whether  CN  support  RO.  If  CN  does
         support  RO,  MN  will  send  data  directly  to  CN;  if  not,  all  data
         transmission  will  pass  HA.  It  can  be  described  as  a  procedure  of
         "Register  with  HA- >RRT- >direct  data  transmission".
 
         And  my  opinion  is:
         1.MN  register  with  HA  and  get  a  CoA
         2.MN  or  CN  may  initiate  data  communication  first,  and  becauce  MN
         have  no  information  about  CN(if  MN  send  data  to  the  "unknown"  CN
         first),  this  kind  of  communication  will  have  to  pass  HA.  After
         some  time  of  data  transmission,  MN  initiate  the  RRT  and  register
         with  CN.  It  can  be  described  as  a  procedure  of  "Register  with
         HA- >data  transmission- >RRT- >new  transmission  route".
 
In my understanding of your reply, the frist opinion is "Preactive mode" and the second is "Reactive mode" .And which mode to be chosen is just a matter of implentation as your very clear discription " in fact both are possible, it is a matter of implementation".
And my classmate's understanding is a little different.  His opinion is : After MN registered with HA. If MN initiate communication first, it MUST start RRT first before any data transmission to CN. But my understanding of your "Both  are  possible", it is possible to send data to CN through HA, and after some such data transmission, then switch the data transmission through HA to CN directly.
 
So what do you think about this? Thanks again! :)
 
Best Regards
 
Johnny Pan

想成为冯小刚、陈凯歌、张纪中三大导演的主角吗？ 
_______________________________________________
Mip6 mailing list
Mip6 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mip6
Permalink | Reply | 501 comments |
headers
Brian Haley | 11 Jan 2006 16:06
Picon
Favicon

Re: Re: A question about MIPv6!

johnny pan wrote:
> In my understanding of your reply, the frist opinion is "Preactive mode" 
> and the second is "Reactive mode" .And which mode to be chosen is just a 
> matter of implentation as your very clear discription " in fact both are 
> possible, it is a matter of implementation".
> And my classmate's understanding is a little different.  His opinion is 
> : After MN registered with HA. If MN initiate communication first, 
> it MUST start RRT first before any data transmission to CN. But my 
> understanding of your "Both  are  possible", it is possible to send data 
> to CN through HA, and after some such data transmission, then switch the 
> data transmission through HA to CN directly.

Section 11.7.2 addresses this.  A snippet:

    Considerations regarding when (and if) to initiate the procedure
    depend on the specific movement and traffic patterns of the mobile
    node and are outside the scope of this document.

There are only SHOULDs and MAYs regarding this decision in that section, 
no MUSTs...

-Brian
Permalink | Reply | 501 comments |
headers
Chantal Ladouce | 11 Jan 2006 17:04
Picon

International SIP Conference / WiMAX Summit 2006 - Paris - France

 The International SIP conference and the WiMAX Summit will start next February 21st in Paris. The two events are co-organised and will bring any necessary information on VoIP, mobility convergence and wireless broadband access.

 

The early registration 10% discount will end in one week.

 

Get all details on International SIP at:

http://www.upperside.fr/sip2006/sip2006intro.htm

 

Get all details on the WiMAX Summit at:

http://www.upperside.fr/wimax2006/wimax2006intro.htm

 

 

 

_______________________________________________
Mip6 mailing list
Mip6 <at> ietf.org
https://www1.ietf.org/mailman/listinfo/mip6
Permalink | Reply | 0 comments |

Gmane