Meeting minutes of Mobility for IPv6 (mip6) WG from IETF63
When: August 2nd, 2005
Credits for these minutes:
- Vidya Narayanan
- Christian Vogt
- TJ Kniveton (Jabber scribe)
Chairs: Basavaraj Patil and Gopal Dommety
- WG Document status update
BP presented the status of various WG documents. See slides. Concerns about the auth protocol have been raised by the security ADs. Chairs have provided a response to the ADs w.r.t these concerns.
- Mobile IPv6 bootstrapping in split and integrated scenarios
Presenter: Gerardo Giaretta
Integrated scenario: currently under study
Objective: The main objective of bootstrapping is minimzation of pre-configured data on the MN.
- Split Scenario: MSA and MSP are different entities
- HS: In the roaming scenario, is the HA assigned by the local network?
- GG: Yes, the HA may be assigned by the local network;
- HS: Do I lookup home.com or visiting.com?
- GG: visiting.com;
- HS: trying to understand the purpose of this HA
- GG: needed to solve the roaming case
- HS: this is not just a roaming case; there is also a case where the HA service is provided by an application provider, maybe in another network, or in the home network
- GG: this scenario is the same as the split scenario; while this is not roaming for network access, it is roaming for mobility service
- HS: the split scenario seems to be referring to roaming
- GD: Are you referring to dynamic HA assignment?
- HS: No, only the location of the HA
- HS: If this is not a roaming scenario, and I dont have an AAA server, can I use certs and use this solution?
- GG: Not addressed by this scenario, but addressed by the solution
- GG: MSA only authorizes the service; does not assign HA or HoA
- HT: Address is assigned by local network; HA assigned by home network
- HS: This is not an issue. Address can be assigned by local network; authorization does not rely on the HoA
- BP: Take it on ML
- Presentation continues HA address discovery (DHAAD, DHCP, DNS); bootstrapping using EAP and public keys; HoA assigned using IKEv2
- FD: Bad interpretation of what IKEv2 configuration is for; provides no validation; it is okay to use it to update DNS
- GG: We have used a new attribute to use for auto-configured HoAs to be used in creation of the child SA
- JA: Is this auto-config happening often or only once?
- GG: only once, upon bootstrap; SA depends on the lifetime of the SA
- AP: pre-configuring prefix is not bad; DNS also requires home.com to be pre-configured
- DT: just another option;
- AP: Anycast can be used for load balancing
- JK: What protocol does that?
- AP: nothing
- Presentation continues HoA registration with DNS;
- HT; A draft is present to link the components to Diameter
- EN: Today, DHCP server does DNS updates; that is the right way to do it; it may be an option to have the HA do it; it should not preclude the MN from doing it using DHCP or whatever, if it wants to
- GG: MN only requests HA to do it using the DNS Update mobility option
- Name?: Is dynamic HA assignment included in the integrated scenario?
- DT: No; DNS can do dynamic HA assignment
- ?: that doesnt do load balancing or other scenarios
- BP: Take it on the ML
- ??: If you use DNS to look up the HA address, is the request sent by the local network or home network?
- GG: by definition, the split scenario doesnt address HA assignment in the local network
- SC: Not very clear if AAA is a requirement for this solution or not
- GG: Not a req.; either AAA or certs can be used; e.g., IKEv2 w/EAP or IKEv2 w/certs can be used
Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture
Presenter: Vijay Devarapalli
- 2 Major Issues
- 1 RFC3775 & 3776 describe SPD and SAD configs assuming MH and ICMP protocols as selectors; this makes the need for per-interface SPD; 2401bis proposes more granular selectors should we make the use of this a MUST?
- FD: there are 2 reasons why this should not be a MUST you cant assume protocol selectors are available everywhere; SHOULD is good; implementers should have the choice of doing one or the other
- VD: How about if it is a MUST on the HA alone? MNs that do support it can use it
- FD: Use recommend, not MUST
- HS: If all ICMP is protected, there is no issue
- JA: Why is this a problem? If this is using IKEv2, and it uses 2401bis, what is the problem?
- VD: 2401bis does not say these selctors are a MUST
- JA: If you want to do the per-i/f SPD, not sure if you have to say all of it is supported
- Presentation continues Major issue 2 packet formats not meant to support all possible ipsec configs; detailing tunnel mode will bloat the draft
- HS: For HoTi and CoTi, why not tunnel the packet with a transport mode SA on the outer header?
- VD: that can be done
- HS: why not change 3775 to accommodate that?
- VD/BP: May be; send email on the ML
- FD: This is explicitly prevented in 3775 for good reason;
V4 traversal for IPv6 mobility protocols - Scenarios
Presenter: Vijay Devarapalli
I-D: DT still working on the I-D
- Scenario 1 – v4 access network; v6 home network;
- 2 same as 1, but MN is behind a NAT
- 3 MN wants both v6 and v4 sessions
- 4 HA does not have a v4 address; connecting a v4 network and v6 network not being addressed; nothing mobility related here;
- NAT traversal is in the scope
- FD: Do you want just re-addressing or full mobility with RO and everything?
- VD: we havent come to that yet;
- BP: Scope of the design team has been limited to a small set of scenarios to address immediate deployment scenarios
- FD: problem is not to just get solutions; need to select good solution
- AP: When mip4 already solves the issue of using IPv4 HoA, why solve this here?
- VD: doesnt make sense running mip4 and mip6 at the same time; lot of issues explained in the dsmip draft
Mobility management for Dual stack mobile nodes
Presenter: Hesham Soliman
- Signaling overheads of running mip4 and mip6 at the same time
- AP: why provide session continuity for v4 when tunneling in v6?
- HS: still a valid problem
- HS: problem providing reliable service
- DTh: Is it only an efficiency issue? Or more?
- HS: Both efficiency and connectivity; Erratic connectivity; optimized mobility management not possible
- DTh: It does work; just not efficient enough
- GT: optimization becomes necessary here
- GDa: Is there any spec on v4-v6 transition?
- DT: There is GRE
- Presentation continues; Solution suggestions;
- HT: NAT traversal work has been done for ikev2, ipsec
- AP: also done for mip4
- HS: ok. Henrick is on the DT
- AP: binding a v4 address to a v6 address – isn’t that part of 6-to-4 tunneling?
- HS: yes, but without anycast, this is a one-way solution; depends on how people deploy it
IP Address Location Privacy and IP Mobility
Presenter: Rajeev Koodli
- Address privacy and location privacy
- FD: HoA is not visible when BUs are protected, HoA is not visible
- RK: If BU is protected and HoTi and CoTi are used, it can be protected
- BP: Now that Mobopts has done the work, maybe the WG should take it up and publish as informational
- EN: those who are interested in this space can attend the Alien bof.
HA reliability and load balancing
Presenter: Li Qin
- BP: Reliability is a WG charter item and there are several solutions addressing this at the present time
- Questions about HA allocation raised by James Kempf. There are some concerns regarding this I-D and the solution being discussed in bootstrapping.
- Vidya N. had concerns about the fact that an HA could detect failures faster than an MN. It should be the other way around.
Presenter: Hui Deng
- Motivations for this I-D presented. Partial and full recovery mechanisms specified.
Presenter: Vijay Devarapalli
- This protocol was designed based on the needs expressed by Connexion for addressing their problem scope. But can be used for HA reliability as well.
Presenter: James Kempf
- James said that this draft proposes a mechanism that is needed by operators deployoing MIP6. They need a mechanism by which they can shutdown an HA gracefully while ensuring that the MNs are switched to other HAs.
Discussion about whether HA reliability works hould be taken up by the WG. Many expressed that a reliability solution is needed at this time in order to enable deployments. There were also opinions that HA vendors can have their own solutions to deal with reliability. The sense of the room was that work on this is needed. The chairs decided that the questions would be taken up on the ML and consensus determined therein about taking up this work now.
Review summary of I-D draft-irtf-mobopts-ro-enhancements-01
Presenter: Christian Vogt
- GG: On 120-ms RTT.. does handover delay include movement detection delay?
A: Yes, we are sending high frequency RtrAdv. It does not include LL handover delay. It also does not consider delay that normal IPv6 autoconf would require. We use optimistic DAD.
Securing HA list in MIP6
Presenter: Sachin Dutta
- Several solutions to address the problem of securing the HA list presented.
- JA: Solution 2-SEND". What is the 2nd issue that will not be resolved?
A: The frequency is high. So if multiple HAs send RA frequency,..
- JA: I'm not sure I agree. Frequent RAs are for the host. if the home link has hosts, it makes sense to have those RAs. If the HAs are on the same link, there's no need for high frequency.
- EN: It might even be possible, even if you do have hosts and want 30ms beacons, have those RAs not include information updates, HA list, SEND stuff.
New items before WG
- Application interface to exchange mobility information with Mobility subsystem
Chairs aked that the WG should take a look at this I-D and provide feedback to the authors.
- Care-of Address Test for MIPv6 using a State Cookie
The idea is to use a state cookie as in SCTP and IKE. SCTP explanations are very good. No state creation on CN, so no DoS problems with many BUs. There are IANA considerations and hence publishing this as experimental is one possible way forward. In MIPSHOP, Jari found a nice way to solve it.
Gopal discussed the next steps for the WG.
W.r.t the Auth I-D, Margaret Wasserman: I can tell you what the status is, but not how it's going to get resolved. Both Security ADs have discusses on the document. We had a brief meeting yesterday, and there/'s not definite resolution on the table. We might be able to make some traction with an applicability statement that it's specific to 3GPP2 networks, or that it should only be used on nets with some properties. But that won't necessarily resolve the discusses. There's a lot of bad feeling because one of the ADs was on the security directorate when it was asked to review this. Nothing was communicated back to them to clear this u
HS: Hesham Soliman
GG: Gerardo Giaretta
GD: Gopal Dommety
BP: Basavaraj Patil
JA: Jari Arrko
FD: Francis Dupont
AP: Alex Petrescu
JK: James Kempf
DT: Design Team
DTh: Dave Thaler
HT: Hannes Tschofenig
EN: Erik Nordmak
VD: Vijay Devarapalli
SC: Samita Chakrabarti
GT: George Tsirtsis
GDa: Greg Daley
RK: Rajeev Koodli
VN: Vidya Narayanan