MIP4 WG Minutes (Thursday, November 11, 2004, 1300-1500)
MIP4 WG Minutes (Thursday, November 11, 2004,
Minute taker: Eva Gustafsson
Charlie's presentation regarding 3344bis issues has been moved up,
as he has a plane to catch. No other comments on the agenda.
||RFC Ed Queue
||AD Evaluation :: AD Followup
||RFC Ed Queue
||Almost ready to be sent to IESG
||Draft with new boilerplate, then IESG
||RFC Ed Queue
||In WG last call
3012bis, issue raised with HMAC_CHAP_SPI, proposed solution
to delete HMAC_CHAP_SPI from text, i.e. no longer
Issue 45 remains unsolved - what to do if deregistration
message fails due to broken foreign-home authentication extension. New
revision specifies that FA MUST NOT apply foreign-home authentication
extension to MN's deregistration request.
- Kent Leung:
- Thought we had different agreement on mailing list.
- Pete McCann:
- Agreed that if FA-HA authentication failed, extension must be
- Hesham Soliman:
- If anything added on top, needs to be authenticated to avoid
- If extension is there, it needs to be respected.
Question by someone on different issue...
- Need to take this discussion to the list again.
- Henrik Levkowetz & Pete:
- Ok to only do this when care-of address was that of another FA,
not the FA transmitting this to you? Check lifetime zero, other
care-of address, FA would leave on authentication extension?
- Need to think this over...
- Exception on FA not to put this on, on HA not to discard.
- Simultaneous bindings?
- Charlie Perkins:
- Don't see connection with simultaneous bindings.
Action item: Charlie will write this down and send to
We still need a co-editor to help Sami Vaarala with this. Those
interested, please approach chairs after meeting.
Last call ended Friday, Nov 5th . One comment received:
what does MN do if receives unauthenticated FA extension?
- Since this message only goes on link local between FA and MN,
should not be too troublesome to leave as is. TTL check in this
message? Think so.
- Resolution of wording done in WG? Yes. Should get FA error on
MN. Case of MN-FA link being compromised minimal. Need text about
- Need text describing that FA does if it sees this from FA.
Should deregister. Be careful; not authenticated.
- Either go "MAY", or do the ping test first.
- Make sure HA does not deliver erroneous message, right?
- No guarantee that message actually came from HA.
- If you get FA error, calls for suspicion, wait a little longer
for successful registration reply, otherwise do something about
- Thinks this is overengineering it. Why dance around this
particular one? Just take it for what it is and act on it. Assume
link between MN and FA is safe.
Old problem. Do we want to take this up in the WG?
Earlier statement that there is considerable work to get
Would like to see some real-world deployment. Which are the
customers, what is the security model, assumptions?
- You got the right question. Also, first question should be
"what do you mean by route optimization?". If it's the same as for
MIP6, if we apply same security requirements, will be a challenge.
Old draft, signaling between FAs would be useful, more useful than
full-fledged route optimization.
- Would like to keep signaling orthogonal to existing
- Think we should do this, not to have all traffic go through HA.
Nokia would like this.
- What link layers? Carrier?
- For all environments...
- We need to pin down what environments need this.
- Alexandru Petrescu:
- Certain type of route optimization is useful. Is there common
idea what this leads to and what solutions we want to work on?
- Old draft (Perkins, Johnson), also MIP6 type of solution.
- We run and deploy MIP4, see no need for route optimization.
Whatever we see for MIP6 will be deployed. To enable service, not
needed. For efficient mobility, FA-FA signaling needed.
- James Kempf:
- We don't deploy MIP (4 or 6). Agree with Hesham; we don't need
route optimization now.
- Low-latency handoffs helpful. Experience says most efficient
solution would be low-latency stuff plus hierarchical stuff. We
effectively get route optimization with this.
- Get real customers to come forward so that we can nail down
requirements for this.
- Please post studies etc. on mailing list. Also, doing this in
our WG requires discussion with ADs to put it on charter.
- We need some more support for foreign agent error to move
MIP4/MIP6 combinations. New mailing list created:
draft-larsson-v6ops-mip-scenarios-00.txt ... describing scenarios
evolved. Will be submitted as individual submission, as there is
currently no WG where it belongs. If you have interest in this area,
read draft and comment.
To do MIP4 work in this space, we need clear statement of scenario
and environment where you need your solution to be applied, clear
statement of which combinations (from draft-larsson...) will be
addressed, and definition of problem (why does this need to be
We need to know why we are doing it and how it will apply.
- First time I see draft-larsson...
- Submitted recently, mentioned it because we want people to look
at it and comment.
- Example: MIP6 MN transmitting to IPv4 network?
- Yes, this scenario is one of many mentioned in this draft.
Would belong in MIP6 WG or possibly in new transition WG.
FMIPv4 motivation and design ideas, implementation
benchmarks. Available for anyone to work on - will not push
- Could you post something about similarities with low-latency on
the draft? We need discussion with ADs if we want this back on the
- Only two factors: performance and simplicity.
- Curious on the numbers. Is there a further breakdown on those
- Numbers due to advertising model.
- This is basically fast handoff for MIP6, low-latency. Hard to
find difference enough for so significant difference in
- We wanted answers as fast as possible.
- Very interesting. First two values I recognize from client I
used to work on. Would like to see as experimental.
- Agree with Henrik. We have a paper where we did extensive
comparison. We also did something similar to this; worked very well
- Can you send pointer to paper to the list.
- Will do as soon as it is published.
- Would be really good to see just email on difference between
this and low-latency.