IETF55 Mobile IP WG meeting
November 19th, 2002 (1930 - 2200)
##################################

Chairs:
Basavaraj Patil
Phil Roberts
Gabriel Montenegro

Ack:
Thanks to Alper Yegin and Samita Chakrabarti for contributing these 
meeting minutes.

Minutes
=======

Agenda and Document Status
**************************

Meeting agenda presented by Basavaraj. Introduced the new co-chair 
Gabriel Montenegro to the WG.

WG document status presented by Phil Roberts

1. The WG is currently working on advancing RFC3344 and RFC2794 to DS. 
Interop data has been collected.
2. IESG approval for the MIPv4 NAT traversal I-D has been received and 
should be on the RFC-ed queue soon.
3. Mobile IPv6 draft 19 has been released. AD comments have been 
received by the WG.
4. WG last call completed on the following I-Ds: 
    - rfc3012bis, 
    - AAA Keys,
    - QoS requirements (this I-D has been handed off to the NSIS WG),
    - regional registration for Mobile IPv4 (authors addressing last call 
feedback), 
    - registration revocation for Mobile IPv4 (awaiting AD comments), 
    - FMIPv4 (experimental) and 
    - MIPv6 and IPSec HA-MN interaction (comments being addressed by 
authors). 
5. WG I-Ds ready for last call:
     - LMM Requirements
     - AAA NAI for Mobile IPv4
6. Work in progress
     - Mobile IPv6 I-Ds, FMIPv6 and FMIPv6 for 802.11 , HMIPv6 and LPAS 

Mobile IPv6 issue status and discussion
***************************************
Jari Arkko and Charles Perkins

Status as of draft version 19:
- All issues resolved
- HA-MN IPSec was produced
- Comments received from AD- will go to last call soon
- 102 Issues (12 rejected, 90 adopted, 6 major issues, 30 minor, 30 
medium, 24 editorial)
New issues have been filed since AD comments were received

Primary focus on AD comments at this meeting.

Issue 163: Run MLD between the MN and HA. Text has been proposed and 
agreed on the mailing list
Issue 159: D bit semantics: who should be responsible for knowing when to do 
DAD? Proposal: remove the D bit, and let the HA initiate
           DAD unless deregistration or defending the home address. 
Agreed on the mailing list. 
Issue 156: Conflict with ND and DAD 
           Proposal: Produce a separate doc on optimistic DAD
Issue 158: When to start RO
           Recommendation: Produce a guide line when to start RO by the MN, 
this guideline will/should be a result of experience gained with 
experimentation  and interop testing 
Discussion
Basavaraj: it depends. If CN has no binding, no RO even after you move.
Erik: If CN already had state (binding cache), you want to 
immediately update after movement. This case should make a 
difference. 
Thomas: there are a lot of things to think about "when to do RO".
You might want to give some guidelines.

Issue 160: HA discovery should not assume single address of a HA
           Proposal : Let DHAAD  return all addresses of  each HA


Issue 150: Failed de-reg when returning home (addressed )
Issue 157: Address collision action 
           Disable the interface and wait for reconfiguration when DAD 
fails. This is a drastic action. Where to fix this action? At SEND WG? 
Should we update IPv6 ND spec? Or, MIPv6 spec? No consensus on the 
mailing list. 
           RFC2462 says disable interface and wait 
           (drastic action for Mobile situation)
           Options discussed:
            1) Let SEND deal with this
            2) Generate private address (RFC3041) when address 
collision happens 
            Comments: What if SEND and non-SEND nodes are on the same 
subnet ?
                    Malicious case: Can't do much unless it is 
authenticated
                    Normal collision: Rarely happens, is it worth 
worring about ?
           Folks seem to prefer option 2) for MIPv6 case.

Issue 154:  ND constant tuning differs from ND 
            Options:
	    1) Let IPv6 wg change ND doc and remove reference from MIPv6
	    2) Write a separate draft 
	    3) Both above

There has been long discussion on this topic. Mostly working group 
members are in favor of not removing the MIPv6 specific ND constants from 
the base draft  as they are quite important for MIPv6 operation. ADs  
recommended a separate draft. Dave Johnson suggested that keep the 
information in the MIPv6 doc now and remove later when alternate 
document is available. Otherwise the information could be lost. 
Chairs supported this idea. 
Discussion:
Charlie P.: cost of modifications are not needed for all routers, just for 
those supporting mobile nodes. We can have documents that people can 
implement and get good results.
Bob Hinden: these changes are fairly generic. Let's bring them back to IPv6 
WG, as extensions to ND. It's not a special case, it's a normal case. 
Jari: most routers will have to do these.
Hesham: link-layer indications are not generic. Also, all routers need to 
implement these, as a router may serve mobiles at any time.
James Kempf: there are things that are specific to mobile nodes, not all 
nodes will be mobile node. Wireless links are different. 
Charlie P.: it's a tunable parameter. It's a mistake to bury tunable 
parameters in another document.
Greg Daley: I don't have opinion on which document should cover these. It's 
MIP's responsibility to look after these issues. It should be done in MIP 
(WG).
Basavaraj: if frequency increased, what's the problem here?
Erik: One issue: how frequently sent unsolicited RAs? Other issue: how 
frequently can they sent solicited RA? It makes sense to talk about 
applicability of these things. 
Brian: we can even add new options, but why can't we change existing ones?

Thomas: these changes need to be reviewed by the IPv6 WG. We can get an 
updated doc. in 6 months. 
Gabriel M.: what if IPv6 WG not like it?
Thomas: either way. they can oppose it during the last call. 
Thomas: I think these apply to all nodes. Split up things.
Dave Johnson: We discussed this at the IPv6 WG. It was approved. Now it's 
being re-opened. Why the consensus established is no longer valid.
Also 6 months is too long. And 6 months is not accurate.
Thomas: consensus depends on the last calls.
Basavaraj: this WG believes 50ms is the right time. This WG made a 
decision. Now we are speculating the IESG last call might have 
problems. This is speculation. Everyone at the IETF will have a chance to 
review this at the last call.
Erik: modular specification is better. If we had realized that earlier, we 
could break MIP spec into several protocols, home agent discovery, etc..
Bob Hinden: IPv6 WG is your friend. 
Bob Hinden: Router builders won't see this spec. 50ms makes me nervous.
In productization, adding more features in a product slips the release 
date.
Charlie Perkins: this is a well understood technique.
Jim Bound: products can slip, but not for 6 months.

Phil Roberts: there might me more than this comment during the last call.
This group of people prefers to leave it in.
Thomas: please clarify what things will be left in.
Phil R.: only advertisement interval.
Thomas: how about the wait before sending solicited RA?
some people: both.
Greg: fastRA proposal should be handled separately.

Decision: RS/RA intervals as specified now will be in MIPv6 draft 
although they differ from ND doc at the moment. 

Issue 151:  MIPv6 and DHCPv6 
            -Does it work ? If MN follows DHCPv6 spec, does it get a 
DHCPv6 address assigned by HA ?
             Question: Does it need to be fixed before last call ?
             Thomas: MIPv6 should not preclude DHCPv6, at least an 
investigation should be made if MIPv6 protocol is able to handle DHCPv6 as it 
is or upon minor enhancement. 

Issue 162:  Site-local addresses - should we allow it ?
- Currently only on disconnected sites. Will update after ipv6 
site-local discussion. 
Mike: is the main issue with route optimization?
Charlie: initial discussion was about what addresses are legal in 
routing headers.
Mike: a compromise might be to forbid RO with site-locals.
Bod Hinden: just use gloabl for now, wait for IPv6 to decide.
Charlie: this is pretty restrictive.

Fast handovers for Mobile IPv6 over 802.11

******************************************
Pete McCann - 
draft-mccann-mobileip-80211fh-01.txt

802.11 needs to handle FMIPv6 situations.
  Implementing exotic device drivers ?
Is the signal-to-noise ratio information truly real-time or is it just 
updated every n sec ? 

802.11 trigers:
  -contains old AP and new AP MaC address
  - enables  IAPP operation
Discussion:
Anticipation is difficult. firmware/driver makes autonomous
real-time handover decisions.

Hesham: firmware makes this decision based on SNR?
Pete: yes. proprietary mechanisms.

But not impossible. HostAP or SoftWiFi model supports this.
Exotic device drivers support this. Not possible with all cards.

James: no way around to scan. scanning is costly. you can put in adhoc 
mode, this can be a solution.
Pete: you can rewrite the scan mechanisms.
Bernard Aboba: no specifications in this field. behavior is variable.
But this is not necessarily a problem. 
Gopal:  some nics allow you to associate with to APs.
Pete: this is againist the spec.
Bernard: you'd have two macs, and learning switches will take care of it.
Rajeev: motivation is not to disallow this feature where it's 
available.

People claim they are doing this in the experiments.
James: we couldn't do it.
Bernard: some nics don't use SNR. 
James: we cannot fix this here.
Hesham: exactly. if your nic can do that, use fmip, if not, bad luck.


Security:
       WEP ?
       802.1X? (secure but not fast enough across subnets) PANA? (Not 
ready yet) Both 802.1x and PANA require anticipation.
Bernard: pre-auth allows anticipation and reassociation does not always 
imply final decision. 


Next Step:
 It was recommended that more work is needed at IEEE for 802.11 to 
support MobileIP.
 Pete asked if this work should be a working group item. Fast handoff 
draft needs some updating to reflect 802.11 fast handoff.
Discussion:
- is anticipation realistic?
James: if no anticipation, no benefit.
Hesham: informing people about what information needs to be passed up.
Rajeev: distance of CN is also essential.
Bernard: IEEE is like IETF. if you are willing to go there, perhaps you can 
get some of thes things. things inside the host is not as 
interesting. 
- relationship of PrRtSol to CARD? Open issue
- Fate of this draft? - To be discussed further on list

FMIPv6 Update
*************
Rajeev Koodli - 
draft-ietf-mobileip-fast-mipv6-05.txt

tunnel can be established by
- prrtadv
- L2 indication
- FBU

Forwarding on the tunnel started by FBU.

From mailing list discussions:
- move prrtsol/prrtadv to and earlier time
- allow prrtsol to include a wildcard, dowload info for all 
neighboring AP-AR.

Hesham:  we have a security problem. we need to solve that.

James: concerned about CoA configuration.
James: Concerned about FBU assumptions. With my IAB hat, I'm concerned 
about the architecture here. Two types of mobility here. 
Alternatives to FBU along the line of ND, ICMP redirect need to be 
considered.

Design Team status on MIP traversal across IPsec VPN gateways

****************************************
*********************
Gopal Dommety

steps:
- define problem statement (finished)
- get WG blessings on the problem statement (to be done)
- work on high level solution with IPv4 focus (to be done)

objective: 
 seamless IP mobility across VPN. (VPNs for remote access, or 
encrypting traffic. )

case:
- HA inside the enterprise, inside the VPN domain.
- MN inside the VPN domain, HA on the Internet. (only problem when the MN 
inside the VPN domain).

Solution guidelines:
- none or minimal IPsec changes
- no changes to vpn/dmz architecture
- minimize software upgrades

solution options:
- using dual mobile IP layering. one inside, one outside the DMZ.
- use of proxy entity which is mip aware
- making vpn concentrator accept outer IP address changes without 
breaking IP security.
- use IPsec tunnel instead of GRE/IPinIP tunnel.

RFC3012bis Issues
*****************
Jayshree Bharatia - 
draft-ietf-mobileip-rfc3012bis-03.txt

Jayashree discussed the issues and proposed clarification text for 
rfc3012bis in response to AD comments and mailing list discussions.
The details are available in the slide presentation. There was no 
objection on the changes proposed.

HMIPv6 Update
*************
Hesham Soliman - 
draft-ietf-mobileip-hmipv6-07.txt

changes:
- removed extended mode.
- updated BU format based on the base spec.
- MN allowed to perform RR to CNs.
- described how the MN establishes an SA with MAP in detail.

removed chapter 9: single message including two BUs.
specify timeouts and local retransmissions of local BUs.
need for another MAP discovery mechanism.

Question to the group:
current scheme assumes that there is no need for testing the CoA in order to 
authorize the local BU. MAP is similar to HA.  Is this assumption 
correct?

IPR only applies to Dynamic MAP discovery.

Erik: if LCoA is not limited, then attacker can launch an attack on 
victims outside. 
Hesham: We discussed this, but We don't have it in the draft. Three way 
handshake is an option.

Connectathon
************
Samita Chakrabarti

www.connectathon.org
registration deadline: feb 7, 2003
will focus on mobile IPv6 testing.
no mipv4 conformance testing, only interop on mipv4.

mobileip-ipv6-19
mipv6-ha-ipsec-01

rfc3344
rfc3012bis
rfc2794
rfc3024
other?

Proposal: How about mipv6 interop test bed on 6bone? for continuous 
testing.


Charter Revision
****************
Gabriel Montenegro outlined the charter revision proposal. The charter has 
been discussed between the chairs and the ADs and the outcome is as 
follows:

current charter/milestones outdated.
There is a desire for better focus.

different maturity levels, mipv4 vs. mipv6.
different goals: mipv4: deployment. mipv6: finishing basic 
functionality (and optimizations).

(mostly) different constituencies.
Current WG has a split personality.

Split into 2 WGs:
- mipdep WG: mobile IP deployment WG.
not mipv4 specific., focus on mipv4, but mipv6 also ok.
operator issues.
other SDO's requirements for deployment.

- mipv6 WG
hopefully short lived WG.

narrower charter, better focus.

mipdep:
vpn
lpas
mai extensions
challenge-reponse.
registration revocation
mibs

mipv6 wg:
- mipv6 spec.
- bootstraping
- modularizing mipv6 spec into smaller specs
- some optimziations
 - hmipv6
 - fmipv6
 - ND modifications
 - movement detection
 - simultaneous bindings
 - optimistic/fast DAD, router discovery.

Questions:
drafts will mostly be moved and adopted automatically.

Charles: would new attempts to develop mipv4 related protocol be 
discouraged if not related to deployment?
Basavaraj: they are not prohibited.
George T.: some deployment points to new protocols.

Hesham: what was the justification?
Gabriel: split personality. 
Hesham: why hmipv6/fmipv6 are experimental? what is the criteria do 
decide something is experimental.
Basavaraj: determination should not be arbitrarily set. interest level, and 
implementations are important.
James: these technologies need to be tied into real-life 
deployments.
Gopal D.: agree with the split personality problem. it's better to split 
mipv4 vs. mipv6.
George T.: are we opening the flood gates? one meeting per IETF was 
controlling it.
Samita: split is good, but... mipv4 and mipv6 is a better idea.


Phil Roberts: we'll be discussing this on the mailing list. no 
timeframe yet.