2.3.14 Mobility for IPv6 (mip6)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.

Last Modified: 2005-09-28

Chair(s):

Basavaraj Patil <basavaraj.patil@nokia.com>
Gopal Dommety <gdommety@cisco.com>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

Mailing Lists:

General Discussion: mip6@ietf.org
To Subscribe: https://www.ietf.org/mailman/listinfo/mip6
Archive: http://www.ietf.org/mail-archive/web/mip6/index.html

Description of Working Group:

Mobile IPv6 (MIPv6) specifies routing support to permit an IPv6 host to
continue using its "permanent" home address as it moves around
the Internet. Mobile IPv6 supports transparency above the IP
layer, including maintenance of active TCP connections and UDP port
bindings. The specifications for these mechanisms consist of:

        draft-ietf-mobileip-ipv6-24 (RFC XXX) and
        draft-ietf-mobileip-mipv6-ha-ipsec-06 (RFC XXX)

The protocol as specified in the above two documents can be considered
as  the baseline or minimum protocol set for implementing IPv6
mobility. During the development phase of the base protocol, a few
additional features were identified as necessary to facilitate
deployment (described below).

The primary goal of the MIP6 working group will be to enhance base
IPv6 mobility by continuing work on developments that are required for
wide-scale deployments. Additionally the working group will ensure
that any issues identified by the interop testing of the MIPv6
specifications are addressed quickly. Specific work items with this
goal in mind are listed below:

1) Create and maintain an issue list that is generated on the basis of
  interop testing and address these issues as enhancements to the
  base protocol

2) Features such as renumbering of the home link, home agent discovery,
  Route Optimization, which are currently a part of the base
  specification can be specified more explicitly as separate
  specifications. This will also enable modularizing the Mobile
  IPv6 specification further into the minimal subset and add-on
  features. Some of these specifications will be identified as
  base mechanisms of Mobile IPv6.

3) A number of enhancements to basic IPv6 mobility were identified
  during the development of the base specification. These
  enhancements will be taken up in a phased manner depending on the
  priority identified with each. Below are listed the work items to
  be taken up by the WG:

      - A bootstrap mechanism for setting up security associations
        between the Mobile Node (MN) and Home Agent (HA) that would
        enable easier deployment of Mobile IPv6. This bootstrap
        mechanism is intended to be used when the device is turned on
        the very first time and activates MIPv6. The WG should
        investigate and define the scope before solving the problem.

    - Improving home agent reliability: in the event of a home agent
      crashing, this would allow another home agent to continue
      providing service to a given mobile node.

    - Support for a Mobile Node changing its home address, either
      because of renumbering in its home network or because it
      periodically changes addresses (perhaps via RFC3041)

    - Route optimization will require security mechanisms for
      trusting and updating the binding information.Return-routability
      is the basic mechanism for route-optimization. Mechanisms using
      a shared secret Key/Security Association will be considered.
      Methods for establishing a security association between the
      mobile node and the correspondent node are out of the scope
      of the WG.

    - The working group will also document problem statements
      associated with deploying Mobile IPv6 in the following areas:
        a. Mobile IPv6 issues in the presence of firewalls
        b. Mobile IPv6 deployment and transition issues in the       
            presence of IPv4/IPv6 networks
        c. Multicast issues

It should be noted that there are potential optimizations that might
make mobile IP more attractive for use by certain applications (e.g.,
making handovers "faster"). The latter category of optimizations is
explicitly out-of-scope at this time; this WG will focus on issues
for which there is strong consensus that the work is needed to get
basic mobility deployable on a large scale.

Goals and Milestones:

Done  Submit I-D 'Issues with firewall Problem statement' to IESG
Done  Submit I-D 'MIPv6 MIB' to IESG
Done  Submit I-D 'Extensions to Socket Advanced API for MIPv6' to IESG
Done  Submit I-D 'Alternate Route Optimization (Pre-config Key) scheme' to IESG
Jul 2005  Submit Bootstrapping problem statement to IESG
Jul 2005  Submit ID Submit ID 'Motivation for Authentication I-D' to IESG
Aug 2005  Submit I-D 'Authentication Option for MIPv6' to IESG
Aug 2005  Submit I-D 'Identificaiton Option for MIPv6' to IESG
Nov 2005  Submit I-D 'MIPv6 operation with IKEV2 and the revised IPsec Architecture to IESG
Nov 2005  Submit Bootstrapping solution to IESG
Dec 2005  Submit Problem statement and Solution to Mobile IPv6 transition between v4/v6 networks to IESG
Feb 2006  Submit I-D 'Goals for AAA HA Interface' to IESG
Aug 2006  Separate specs for Home Agent (HA) Discovery, Route Optimization, Renumbering to IESG
Aug 2006  Submit Home agent reliability to IESG

Internet-Drafts:

  • draft-ietf-mip6-mipv6-mib-07.txt
  • draft-ietf-mip6-mipext-advapi-05.txt
  • draft-ietf-mip6-precfgkbm-03.txt
  • draft-ietf-mip6-ro-sec-03.txt
  • draft-ietf-mip6-auth-protocol-07.txt
  • draft-ietf-mip6-bootstrap-ps-03.txt
  • draft-ietf-mip6-firewalls-03.txt
  • draft-ietf-mip6-ikev2-ipsec-04.txt
  • draft-ietf-mip6-mn-ident-option-03.txt
  • draft-ietf-mip6-cn-ipsec-01.txt
  • draft-ietf-mip6-aaa-ha-goals-00.txt
  • draft-ietf-mip6-bootstrapping-split-01.txt
  • draft-ietf-mip6-dsmip-problem-01.txt
  • draft-ietf-mip6-whyauthdataoption-00.txt
  • draft-ietf-mip6-location-privacy-ps-00.txt
  • draft-ietf-mip6-nemo-v4traversal-00.txt
  • draft-ietf-mip6-bootstrapping-integrated-dhc-00.txt

    Request For Comments:

    RFCStatusTitle
    RFC3775 Standard Mobility Support in IPv6
    RFC3776 Standard Using IPsec to Protect Mobile IPv6 Signaling between Mobile Nodes and Home Agents

    Current Meeting Report

    Minutes of:
    Mobility for IPv6 (mip6)
    At: IETF64
    November 10, 2005 (Vancouver)
    
    Chairs: Basavaraj Patil ,
    	Gopal Dommety 
    
    Credit for these minutes: 
           1. Alper Yegin 
           2. Nicolas Montavont 
    				
    
    ####################################################
    
    1. WG document status update (Basavaraj Patil)
    
    - Bootstrapping DT has successfully completed their mandate.
      Gerado has been leading the DT. Task is completed.
      3 documents have been produced. 
      Problem Statement document. 
      Solutions: There are 2 different scenarios addressed. Split and
      integrated scenarios. 
      DT is disbanded. All future work will be taken up in the WG ML.
      DT no longer exists.
      Archves will be made publicly available.
     
    - Transition DT is active. Work is in progress. DT is quite
      active. They have been having several meetings and produced one
      document. DT is constituted in conjunction with the NEMO WG. 
     
    - WG documents:
     
     o mn-ident and mip6-auth are approved by iesg since the last ietf.
     o mip6-auth has taken significant amount of time.  It accompanies an
     iesg note, a warning. 
     o precfgkbm: completed WG LC, iesg reviewed once, had several discuss
     comments, all addressed. Rev 4 is submitted but lost by the drafts
     editor. Will send to iesg soon. 
     o bootstrap-ps: WG Lc completed. recently received several
     comments. This is a ps, we don't need to spend too much time on it. 
     o firewalls: several iesg discuss comments, all addressed. ready to
     go back to eisg. 
     o cn-ipsec: has fallen tru the cracks. LC will happen soon.
     o mip6-ikev2: WG LC completed. submitted to AD.
     o adv-api: will send to AD. 
       Samita: added a new socket option, and a section on applicability,
       and clarified few points. Addressed all the comments from
       iesg. There will be another rev 6 version right after this ietf.
     
    New WG I-Ds:
    - location privacy
    - bootstrap with dhcpv6
    - dual stack mipv6 for hosts and routers
    - why auth data suboption is needed
     
    8th tahi announcement: See slides
     
    Hesham: Can we go to WG LC for the dual stack ps?
    Raj: Do we really need a ps, or can we incorporate it as a paragraph into the 
         solution document.
    hesham: Lets discuss on the ML.
    vijay: It could be folded into the solution doc as a paragraph or section.
     
    --------------------------------------
    
    2a. MIP6 operation with IKEv2 (Vijay Devarapalli)
       I-D: draft-ietf-mip6-ikev2-ipsec (04)
    
    - A few changes have been made to the document 
      Refer to slides for changes made.
    
    hesham: There is no reason for hoti and coti. We can do all in
    	transport mode. Then we'll have only one transport mode.
    vijay: You end up with more headers. Most implementations can use any
    	kind of SA. 	
    
    2b. HA Assignment with IKEv2 (Francis Dupont)
    
    [See slides]
    
    No reason to use any other mechanism for HA assignment.
     
    gerardo: You still need to use home prefix on the mobile node to form
    	 the anycast address.
    francis: Yes, you need to find the anycast address one way. You can
    	 use static config or DNS.
    gerardo: There is no way to lookup home prefix.
    vijay: Just for HA assignment, this is a very heavy solution. Just use dns.
    francis: DNS is not assignment, it is discovery. We don't know if
    	 discovery is enough. Operator decides which HA to use for the
    	 service. 
    vijay: I'm ok with this mechanism. However it should not be the
    	 default option.  
    hesham: DNS lookup is not mutually exclusive. Difference between this
    	and dns is you want to do load sharing with anycast address.
    francis: You just publish an anycast address, helps with privacy.
    hesham: Why do you need a cookie?
    francis: 1. against DoS attacks. 2. to be able to reuse almost all
    	 code of IKEv2. 
    hesham: Is the cookie signed?
    francis: No. It is only for return routability check.
    hesham: If the cookie is not crypto generated.....
    francis: ???
    gerardo: This solution only used for load sharing in the same home
    	 link. HA assignment in different links dont work. 
    francis: You can do something with anycast without a real home link.
    james: I agree this could be used, and modify dns lookup. There is no
    	 way to securely update the anycast routing. You need to
    	 manually configure anycast routing. 
    francis: I dont see a difffernce between unicast and anycast routing.
    kuntal: I don't think it can be used to assign an HA in the access network.
    
    --------------------------------------
    
    3. IPv4 traversal for MIP6 (Hesham Soliman)
       I-D: draft-ietf-mip6-v4traversal (00)
    
    [See slides]
    
    Discussion:
    james: Do you think it works for HA to send something periodically?
    hesham: Processing wise it won't be as heavy.
    james: It is heavier to transmit than receiving.
    vijay: It is not possible since firewall will not the traffic pass.
    vijay: There are other mechanisms for keep alives. It can be vendor specific.
     
    francis: Do you use the same udp for singaling and traffic, or separate the port 
    	 numbers?
    hesham: They are the same. Shall we separate?
    francis: If you use the same, you get security for both. this can be a good thing, 
    	but a bit expensive.
    francis: Btw, you need nat traversal for IKE.
    hesham: IKEv2 has NAT traversal. I don't know if we need to solve the problem for 
    	Ike.
     
    c.perkins: You didn't say much about dynamic home address assignment.
    hesham: This is not to deprecate rfc 3344. We can do the same as in mip4. The problem 
    is, depending on where you are , you might want to use mip6. There is no need to 
    force the people to implement both mip4 and mip6. This is not to replace mip4.
    henrik: If mn with mip6, why should you need to add ipv4 to use mipv4? What is the 
    motivation?
    hesham: The idea is that we need one mobility management rptocol, not 2.
     
    francis: We should have a competition.
    raj: Should we use the nat traversal mechanism that already exists?
    francis: NAT traversal also includes mobility support.
    hesham: If you are moving and do not have a vpn gateway, do you still use mobike?
    francis: Road warrior case inlcudes nat traversal. You have competition with 
    something already available.
    hesham: I don't think we can rely on ikev2 only, you may not have ikev2. 
    francis: You already have mobile vpn.
    hesham: Not everyone is using mobile vpn.
    francis: You need IPsec.
     
    vidya: I disagree with francis. Mobike does not give you a permanate address.
    vidya: Do you allow all types of NATs?
    hesham: We don't assume protocol translators. 
    hesham: We allow port forwarding.
     
    (boeing): Your model is like the aviation model right now. We live in a translator 
    world. IPv4 aircraft wont change for 20 years.
     
    gerardo: MN can also ask for ipv4 and ipv6 home address.
    hesham: We had identity in the BU for allocation.
    gerardo: In bootstrapping, the HoA is assigned with IKEv2. We could do the same for 
    IPv4.
     
    kent: We can support the nat on the HA side dynamically. we can detect and deal with 
    it. 
    hesham: We think deploying a NAT is not a plug and play.
     
    vidya: Can we really hav NATs in front of HA?
    raj: Take it up on the ML. Pascal proposed this.
     
    (nasa): Service providers are doing filtering. it gives the same effect.
    
    
    --------------------------------------
    
    4a. Bootstrapping: Split scenario (Gerardo Giaretta)
    I-D: draft-ietf-mip6-bootstrapping-split (01)
    
     - Scenario
     - Summary of the solution
    
    Hesham: don't understand HoA registration in the DNS
    
    Gerardo: if the HA needs to update the DNS or not.
    
    Hesham; if the option is not there, the HA won't update the DNS.
    
    Gerardo: the optyion is to remove the DNS entry. No option means don't
    update.
    
     - Status update
     - issue 48: load balacing is out of scope of the document
    
    Francis: SRV has priority and weight. you should not update the
    	 weights to do dynamic assignment. 
    
     - Issue 50: identity in HoA config
     - Issue 51: CGA check
    
    francis: Issue 51 is not related to bootstrapping. If there is a check, it shall be 
    	 part of the authorization.
    
    Hesham: isn'"t this the opposite of the bootstrapping: if you go
    through AAA, you don't need this. Why you want to know it's CGA?
    
    Gerardo: That's the point. We won't know.
    
     - Issue 52: HoA auth in DNS update
    
    Hesham: Are you asuming to use IKEv2? Your method allows us to get rid of
    	AAA.
    ....................
        
    4b. Bootstrapping: Integrated scenario (Kuntal Chowdhury)
    I-D: draft-ietf-mip6-bootstrapping-integrated-DHC (00)  
    
    New document made by the DT
    
     - design gaols and assuptions
     - Solution presentation
    
    Hesham: Distinction between HA and ASP for accounting and using
    	something like this for bootstrapping. You should create an
    	entity for HA in ASP, because it's a local agent. The HA is
    	there because it is closer to the MN. 
    
    If you already have 2 HoAs. You chose one for a session and then you
    switch ISP. Can you use this HoA in this ISP?
    
    Raj: When you bootstrap,you get a HoA. You keep this HoA for your
         session.
    
    hesham: I though that we tried to avoid changing HoA when you move
    networks.
    
    Henrik: Question from the trust case: if I know as MN that my HA is in
    my home network. It's difficult to trust a HA which is ad-hoc located.
    
    Raj: It is a transitive trust. You don't have to use this HA.
    
    Alper: Don't see the pb as long as we have MIP authentication.
    
    Kuntal: the MSP can forbid to place HA in ASP.
    
    Henrik: Given the relationship in place, it's ok
    
    Gerarldo: ASM and MSP already ahve a trust relation.
    
    Alper: MN is aware wether he has a HA in ASP or MSP.
    
    Hesham: disagree. the purpose to allocate a certain HA to the MN is
    unknown to the MN. The reason does matter, it is ambigous, I don't
    understand why we don't distinguish between the two.
    
    Alper: When teh MN asks for a HA, it is aware of which HA it received.
    
    Hesham: no it doesn't know agbout the location, it only knows the
    identity.
    
    Alper: We have a flag asking for the location of the HA.
    
    Raj: Continue the discussion offline
    
    Jean-Michel: Why DHCP server is in the ASP?
    
    Kuntal: because it is usually locally where you are. It is the more
    pratical situation.
    
    Jean-Michel: So why do you need a DHCP relay?
    
    Kuntal: because the DHCP server may be on a remote link.
    
    Jean-Michel: strange to see that, as the dHCP has infomration from the
    home network.
    
     - Open issues
    
    Francis: if you need something for diamter, go to DHC WG.  I disagree
    about RRAO doesn't content MIP6 information. Please re-use existing
    mechanisms.
    
    Kuntal: I don't know hwo to process now, but we are aware of it.
    
    Raj: Don't argue where we have to do things.
    
    Francis: Nowhere you have something that says it's NEMO (don't want a
    second draft just for NEMO)
    ....................
    
    4c: Bootstrapping with IKEv1 (Vijay Devarapalli)
    I-D: draft-devarapalli-mip6-ikev1-bootstrap (00)
     
    greg: Have you looked why they are exprired? becaise they are not secure.
    vijay: Hybrid auth is secured.
     
    vijay: I don't know why these specs are not standardized.
     
    raj: How many people will use ikev1?
    combs: The choice is for operators'. We have to propose 2 solutions.
    francis: We need to use IKev2 as soon as possible.
    raj: Let's take this up on the ML.
       
    --------------------------------------
    
    5. Mobility header home agent switch message (James Kempf)
    I-D: draft-haley-mip6-ha-switch (00)
    
     
    [see slides]
     
    kuntal: The signal from HA to MN may cause harm. If the HA is going down, you need to 
    	send message to all mobiles, there may be a large number of
    	them. It would create a message storm and bring down
    	networks. Be very careful. Sometimes it is better not to do
    	anything. Don't wake up dormant nodes. Paging is a shared
    	resource. Networks go down with this kind of mechanisms.
    raj: This is a trade off.
    kuntal: If the reason is unfixable, let the binding expire or let the MN find out 
    instead of waking up the mobile. Why do you wake up the mobile?
    james: if the mobile is dormant, you have a point.
    kuntal: Carriers maintain the session in two box. 
    james: You are saying that carriers don't require that.
    kent: I like the mechanism, agree with kuntal. A good application may be a prepaid 
    mechanism. Unicast a particular mn is ok. In general this is a good idea.
    hui: EV-DO is using access channel for paging. Performance has improved.
    greg: It is not a bad idea. But concerned about the generic signaling, and if every 
    node will implement this. 
    james: So, you say we already have a solution.
    hesham: Idea of having a generic template to load options is a useful thing. 
    james: So, you support the idea of generic signalling.
    ryuji: I think this is important work. but we have to do more work to provide this 
    functionality. nowadasy there are different types of HAs, like for nemo. HA must 
    return same type of HA.
    henrik: I think idea is good. I think kuntal's comment is more about how you should 
    not use it. You can distribute messages to minutes or hours to lower the load.
    raj: There are some concerns. but most people agree that it is a good feature. We'll 
    put this to consensus call on the ML.
    
    --------------------------------------
    
    6. Route Optimization and location privacy using tunnelling agents
    (Kilian Weniger)
    I-D: draft-weniger-rota (01)
    
     
    [see slides]
     
    raj: Further discussion will be taken up on the list.
    francis: There are some other proposals, not for the exactly same scenario.
    
    --------------------------------------
    
    7. Improve communication between mobile nodes	(Yuzhi Ma)
    I-D: draft-yuchi-mip6-mntomn-improve (00)
    
    greg: Mip6 is defined for CNs which are also mobile. CN can also be a MN. There is a 
    draft in mobopts on this. I think this is  mobopts work.
     
    raj: You should discuss this in mobopts.
    
    --------------------------------------
    
    8. Next steps (Gopal Dommety)
     
    [see slides]
     
    rajeev: Solutions for location privacy, mobopts is also looking at
    that.
    
    ######################################################
    
    

    Slides

    Agenda, Status and Next steps
    MIP6 bootstrapping with IKEv1
    MIP6 bootstrapping - Split Scenario
    MIP6-bootstrapping via DHCPv6 for the Integrated Scenario
    Mobility header home agent switch message
    Route Optimization and location privacy using tunnelling agents
    Improve communication between mobile nodes
    Mobile IPv6 with IKEv2 and 2401bis
    IKEv2 based HA assignment
    MIP6 transition