Subject: [mobile-ip] Meeting Minutes - IETF55 (Draft)

From: [email-masked]
Date: Sat, 14 Dec 2002 16:41:14 -0600

If you have any comments regarding the meeting minutes in terms of
discrepancy etc., please let me know.

-Basavaraj

----------------------------------------------------------------

(Draft version of the minutes)

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

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.

---

From: Sandor Vincze <[email-masked]>
Date: Wed, 18 Dec 2002 18:53:38 +0100 (MET)

Dear Mr. Patil!

I am an IP researcher working for Technical University part time as well
as for Hungarian Internet Found. This week I renewed my membership to EU
Framework 6, and would like to join an Active project. Is there any EU
project you know of launched this week? Who can I turned to in MIPv4 or
MIPv6 as private company, to completely focus on project issues?

I can get infrastructure from EU Infrastructure Framework.

I also marked some questions and comments in your letter below:

Friendly yours,

Sandor Vincze

> discrepancy etc., please let me know.

------> Is there any chance to get the testbed?

> 3. Mobile IPv6 draft 19 has been released. AD comments have been

------> Can I be a reviewer for this draft and how to get these
comments?

>      - Mobile IPv6 I-Ds, FMIPv6 and FMIPv6 for 802.11 , HMIPv6 and LPAS 

------> Can I join to help you in progress??

> Mobile IPv6 issue status and discussion

----> Is this Mobile IP list?

>          Generate private address (RFC3041) when address
> 	    collision happens 
--------> Is there any chance to get the test bed SPECS?

> Fast handovers for Mobile IPv6 over 802.11

-----> How to join IEEE for 802.11 participation? Can I be a tester or
reviewer?

> real-time handover decisions.
----> At Technical University we have TESTBED for MAC level MIP
experimenting. Could we join to this IEEE projects???

>        always imply final decision. 
--------> THIS SUBNET traversal speed depends on the applied
algorithms. Is there any chance to adjust our test bed to yours in order
to make algorithm swapping experiments??

> James: if no anticipation, no benefit.

------> what about participation on benefit?

> you can get some of thes things. things inside the host is not as

-----> How to go there?

> FMIPv6 Update

-----> Could we IP tunnel tu you for project participation???

 Samita Chakrabarti
> Proposal: How about mipv6 interop test bed on 6bone? for continuous

---> In Hungary our Institution is a 6bone member. Is there any chance to
connect Mr. Chakrabari at SUN or if it is securely not possible any
University for joint European EFFORT, please?

Sincerely yours,

Dr. Sandor Vincze
EU Framework 6 auditor and editor