[Mip6] WG meeting minutes from IETF63

[[e-mail]]

Meeting minutes of Mobility for IPv6 (mip6) WG from IETF63
==========================================================
When: August 2nd, 2005

Credits for these minutes:
1. Vidya Narayanan
2. Christian Vogt
3. TJ Kniveton (Jabber scribe)

Chairs: Basavaraj Patil and Gopal Dommety

1. 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. 
   

2. Mobile IPv6 bootstrapping in split and integrated scenarios 
..............................................................
   Presenter: Gerardo Giaretta
   I-D: draft-ietf-mip6-bootstrapping-split-00 

   Integrated scenario:   currently under study

   Objective:  The main objective of bootstrapping is minimzation of
   pre-configured data on the MN.
   Discussion:
   -	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 


3. Mobile IPv6 Operation with IKEv2 and the revised IPsec Architecture
......................................................................
   Presenter: Vijay Devarapalli
   I-D: draft-ietf-mip6-ikev2-ipsec-02

   -	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; 

4. 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 

5. Mobility management for Dual stack mobile nodes
..................................................
	Presenter: Hesham Soliman
	I-D: draft-ietf-mip6-dsmip-problem-00

	- 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 

6. IP Address Location Privacy and IP Mobility
..............................................
   Presenter: Rajeev Koodli
   I-D: draft-koodli-mip6-location-privacy-00

   -	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. 

7. HA reliability and load balancing
....................................
   Presenter: Li Qin
   I-D: draft-deng-mip6-vrrp-homeagent-reliability-00

   - 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
   I-D: draft-deng-mip6-vrrp-homeagent-reliability-00

   - Motivations for this I-D presented. Partial and full recovery
     mechanisms specified.
  
   Presenter: Vijay Devarapalli
   I-D: draft-devarapalli-mip6-nemo-local-haha-00

   - 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
   I-D: draft-haley-mip6-ha-switch-00

   - 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.

8. 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.    

9. Securing HA list in MIP6
...........................
   Presenter: Sachin Dutta
   I-D: draft-dutta-mip6-ra-00

   - 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. 

10. New items before WG
.......................

  - Application interface to exchange mobility information with
  Mobility subsystem 
  I-D: draft-momose-mip6-mipsock-00

  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
  I-D: draft-dupont-mipv6-rrcookie-01 

   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.

11. Next steps
..............
   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    

===========================================================
Appendix:

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

_______________________________________________
Mip6 mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mip6