Mobility for IPv4 WG (mip4)

1. Preliminaries 10 min Chairs

• Minutes
• Agenda bashing

No comments on agenda

2. Document Status 15 min Chairs

draft-ietf-mip4-rfc3344bis

New revision submitted right before the meeting. Next: Chair writeup and publication request

Comments:

Henrik:

Charlie submitted a new version before the meeting. One request for a new error number was done.

Charlie:

submitted the weekend before the deadline but it has been on the website for a month and there has been no change.

Vijay:

the target is draft standard?

Pete:

we had some subsequent technical changes therfore we need to recycle to proposed.

Henrik: Yes, we had indicated draft standard but people need to be

aware that we have done changes.

Vijay: not exactly sure what changes were made?

draft-ietf-mip4-vpn-problem-solution

Ready for WG last call

draft-ietf-mip4-dynamic-assignment

Waiting for AD Go-Ahead::AD Followup

draft-ietf-mip4-faerr

Waiting for AD Writeup

draft-ietf-mip4-reg-tunnel

AD Evaluation::Revised ID Needed

This draft has an Appendix which the authors don't agree on how to handle. We've had an independent review of the Appendix too, and need to decide what to do with it.

Comments:

Henrik:

Had a long and painful story. We may be splitting up the draft into an appendix and the main part and then do the appendix as informational.

draft-ietf-mip4-rfc3012bis

Waiting for AD Writeup

Several reviews done for AD, Need to decide whether to fork off the Generalized Mobile IP Authentication Extension as a separate draft.

Comments:

Henrik: Jayshree is doing the few changes..

draft-ietf-mobileip-lowlatency-handoffs-v4

IESG Evaluation::AD Followup

(Just re-submitted by Karim, ready to go to RFC Editor)

Comments:

Henrik: has been approved.

draft-ietf-mip4-rfc2006bis

MIP-centric review done, new revision needed

Comments:

Henrik:

Kent is going to do the review alone or with help. Hopefully ready for MIB doctor.

draft-ietf-mip4-experimental-messages RFC 4064

draft-ietf-mip4-vpn-problem-statement RFC 4093

Comments:

Henrik: that is nice.

3. New charter 5 min Chairs

http://mip4.org/charter/mip4-charter-2005-09-08.html

Comments:

Henrik:

Did not get to the IESG slate. No indication of negative results. If you have comments, this is your last chance. We have a new work items that will make into charters. Until that is cleared, we will not take new work items. There are some presentation are here for addition to the charter but that is the bottomline at this point.

4. New WG drafts: 20 min Author

Status summary, open issues:

draft-bharatia-mip4-gen-ext 5 min Kent

Presentation:

http://www3.ietf.org/proceedings/05nov/slides/mip4-2.pdf

Presentation by Kuntal.

The draft aims to send conf info from HA to the mobile during the initial exchange.

Changes from -00 to -01 is formatting of configuration parameter based on DHCP options, no longer MIP-specific

Also allows the MN to request config info from the home or visited network and that at the same time if needed.

Here we reuse DHCP codes so you don't have to define new subtypes. Adopted the DHCP option code structure and formatting.

received some comments on the mailing list and updated the draft based on that.

A generic extension to be used for the method was shown, including type, length, entity-type (distinguishing between FA ad HA), and config data (conf parameters are packed here).

an exampel of config parameters were shown.

open issues:only DHCP based parameters are considered. Do we have to define non-DHCP parameters?

Comments:

Sri:

You may also need a default realm for DNS queries.

Pres:

You can basically piggyback DHCP info with this.

Henrik:

Can we define this as DHCP-only information and if we need non-DHCP we define a different extension for that later.

Kuntal:

good idea

Yoshi:

DHCP option length

Kuntal:

If all the option are going to fit in one or multiple NVSE.

Kent:

We have talked among ourself on what to do with the DHCP versus non-DHCP, we think we should built that at subtype level rather at type level.

Henrik: either way works for me.

draft-devarapalli-mip4-mobike-connectivity 5 min ???

Presentation:

http://www3.ietf.org/proceedings/05nov/slides/mip4-3.pdf

Presented by Vijay:

Brief update from 00 to 01:

01 has been submitted with not many changes, some based on Jari and TJ's reviews.the target is going to a BCP doc. some additions on when this mechanism is used. the idea is use this for IKEV2. and IKEv1 reference was removed.

draft-sastry-mip4-string-extension 5 min Kent

Presentation:

http://www3.ietf.org/proceedings/05nov/slides/mip4-0.pdf

Presented by Kent:

Update since version 00:

update to 02 some changes regarding the revocation messages. Changes on the use of message string extension, correction to security considerations. Some changes based on TJ's comment and addressed most of the issues.

Can we have some comments? it seems to be pretty straight forward and should go to last call.

draft-nakhjiri-radius-mip4 5 min Madjid

Presentation:

http://www3.ietf.org/proceedings/05nov/slides/mip4-1.pdf

Presented by Madjid:

Update since version 01:

Clean up of the attribute section.

Review from Jari Arkko. There was a question on why the registration request was being hashed. this was to avoid the attribute size issue in the future if the reg. req gets too big.

Diameter can tell whether you are dealing with a HA or a FA. for RADIUS you can do this only by some information in the attributes. Something new is needed. A new MIP-Agent type

Some work remaining. More details on Diameter AVP-RADIUS attribute translations

Issue with MN-AAA authenticator and MFCE. please fix 3012bis.

Comments:

Vijay:

Don't agree with CCoA mode calculation in 3012bis draft

Kent:

Discusses already on WG. Folks agree there are 2 solutions in RFC 3012.

Henrik:

Take it to the WG alias.

Henrik:

We've had quite a bit of discussion with RADEXT chair and need to make clear what we are doing here and how we separate that from what it is done in Diameter. There should be a doc on this.

draft-koodli-fmipv4 5 min ???

Nothing to go over here.

5. IPv6 over MIPv4 and MIPv4 over IPv6. 5 min Chairs

Taking on some work in this area has been discussed earlier, during IETF-62. The question has been raised by some people again, in view of the work on MIPv6 over IPv4 and IPv4 over MIPv6 which is being done in the MIP6 working group.

Comments:

Henrik:

Authors have asked to reconsider this again. He likes to ask for a HUMMM on which way to go. No decision is to be done here.

Hesham:

The aim is to allow the operator to do IPv6 over MIPv4 and a similar work is done in MIPv6.

Kent agrees.

Vijay:

I like to discourage these sort of things in general. It is better to move on to IPv6 rather to do run things this way.

Henrik:

Not everybody agrees plus there are specific cases that you simply cannot do it.

Hesham:

Philosophically is better not to force people on these things.

Rajeev K:

questions what is the relation between this and the traversal work in MIPv6.

Henrik:

this only deals with MIpv4 and not MIPv6 and that is why.

Kent:

the goal is to use one signaling protocol.

Pete:

chair hat off, I submitted this draft a while ago. It makes sense IPv6 over MIPv4.

Vijay:

personal experience. Operators are willing and want to move to IPv6.

Henrik:

we are not proposing people to not move to IPv6 here. for information only how many people want to take this or not to take this on. The HUMM for for is stronger than the HUMM against.

Mohan:

Scope of work?

Chairs:

Both drafts.

Related drafts:

draft-tsirtsis-v4v6-mipv4

draft-larsson-v6ops-mip-scenarios

6. GRE Key Extension for Mobile IPv4 10 min Parviz

   draft-yegani-gre-key-extension

   GRE (Generic Routing Encapsulation) [ RFC 2784 ] is one of the encapsulation formats permitted by RFC 3344. GRE may use keys to distinguish different tunnels from each other. [RFC 2890]. This draft proposes a MIPv4 extension to communicate GRE keys between MIPv4 tunnel endpoints when requesting GRE tunnelling for MIPv4 traffic.

   Parviz presented.

   3344 optionally supports GRE tunneling. The proposal is to allow this tunneling.

   there is a need for subscribers who are home in 3GPP. YOu cannot really distinguish between traffic streams based on HoA, CoA. So we need a new extension.

   The idea is to allow both HA and FA to assign different keys (assymetric).

   There are situations that these keys can be available to HA and FA.

   But in 3344 the MN can set the G bit. Here we should be able to based on policy overwrite the G-bit setting and request a GRE tunneling.

   Henrik: clarification, we are talking about GRE key, not encryption key.

   Mohan: is it for FA CoA or colocated mode

   Parviz: no for both.

   This is for FA CoA mode only.

   Parviz: the HA can assign two addresses to the same subscriber because it is private addresses.

   back to presentation: GRE key assgnment is outside of the scope. The behavior of FA is new, the G-bit overwriting is not the in RFC. The impact is that key allocated by the FA can be used for FA-to-HA use.

   No changes to the MN behaviour.

   Questions/ comments/ working group item?

   Comments:

   Kent:

   good idea. When HA is wholesale, this is a good idea. Today the only solution is to have different instances of HAs.

   Pete:

   I like the idea, it is done 3GPP2. But not comfortable with G-bit overwrite.

   Parviz:

   the final decision is by the HA and the HA can reject and finally have a different tunneling.

   Henrik:

   what happens to MN-HA-AE if you can the G-bit?

   Parviz:

   G-bit in the GRE extension is not changed.

   Kuntal:

   why would the MN care whether you are GRE or not? why does have to be based on MN request.

   Kent:

   when the tunnel is between FA and HA, what is the role of MN? this is breaking the paradigm of the 3344.

   Sri:

   consistent. The extension is added by the FA.

   Parviz:

   which entity should assign those keys, FA or HA or both.

   Kuntal:

   both. the key that FA wants to receive should be specified by the FA and the one HA wants should be assigned by HA.

   Kent:

   Unidirectional and bidirectional should be supported. HA should be able to assign the keys for both sides.

   Kuntal:

   can't see a use case for when we want the HA to allocate both.

   Pete:

   receiver should allocate the key.

   Kent:

   agree, it is ok for the HA to allocate the key, technically.

   Henrik:

   may simplify what FA wants to do, but does not simplify the FA code.

   Kent:

   don't think implementation pov either way is harder.

   Kuntal:

   should we really have to have both optoins in the draft.

   Henrik:

   proposing to have the receiver assign the keys.

   Kent:

   Agree with everything but it does not hurt to add it and make it optional.

   Kuntal:

   how does the FA know what sort HA is it talking to.

   Henrik:

   Kent to propose some text and take it to the list.

7. Generic Notification Message for Mobile IPv4 10 min Hui

draft-deng-mip4-generic-notification-message-00.txt

This document proposes a protocol enhancement that allows Mobile IPv4 entities to asynchronously send and receive explicit notification messages. The Registration Revocation mechanism of RFC 3543 could have been specified using a message such as the one proposed here, had it been available at the time.

Presented by Hui

Presentation:

in some cases, there is a need for MIPv4 entities to send and rx asynch notification events during a session. 3344 does not provide specification for this.

This doc defines generic message and notification model for this process.

does not define specific notification extensions.

some examples are presented.

HA initiates a notfication to MN, FA initiates a notification to MN, another case.

Generic notification msg send by mobility agent to inform another mobility agent or a MN.

3 flags were defined

flag A, bit identifies if ack to the notification msg is need. other fields of the message were defined.

issues: to discuss whether a notification MUST be acked and whether the use of flag is good or not.

issue 2: R bit in Agent advertisement

usage examples were presented:

registration revocation, asynch. user notification (out of credit, coming service interruption), asynch MN or agent notification, may be necessary for high availability scenarios with long reg. life times.

Comments:

Henrik:

comments on the issues and the general idea

Kuntal:

similar in MIP6 regarding HA switch. I think this is a good idea, but I am struggling with the use cases and who will be doing this. Why would you notify the HA when the system is going down, and create more traffic.

Hui:

Just one BS with access channel in cellular won't cause that much traffic.

Henrik:

you are not sending 1 Million notification, it is good idea to cover in the draft for planned maintenance, when you notify that you want to take the HA down in so and so hour.

Kuntal:

still you may have thousands of MNs maintained by HA, still that is a lot of messages.

Henrik:

This a small subpercentage of the overall traffic.

Kuntal:

why not use reg. revoke. why this one?

Henrik:

Are you supposing that we should do this using another message? don't agree.

Kuntal:

reg. revoke is done today.

Kent:

make this optional, not mandatory.

Henrik:

We should put our foot down and say no if we think something is causing a lot of problem (personal opinion).

Hui:

3GPPX wants to use SIP SDP for this.

Parviz:

not sure I can see the use case scenario for this.

Hui:

the real scenario is HA switch.

Sri:

don't focus on where it is used, but focus on whether this is useful or not. example is prepaid.

Kuntal:

last comment on prepaid and people use text messages for that purpose. HA has no business sending notification to the MN when account is up. for MN-FA notifications you would need specific bootstrapping methods. If something is already solved in the industry we don't try to go and design a new solution.

Kent:

right now the revocation only goes to FA, but not to the MN, so it may not be the right way to do it but we do have a MN-HA association. In deployments people don't completely shut doewn the HA anyway, but if you want to do that more power to you.

8. Mobile IPv4 Fast Handovers for 802.16e networks 5 min Junghoon

draft-jee-mip4-fh80216e

IEEE 802.16e is an amendment of 802.16 ("WiMAX") which extends it from fixed terminals only to fixed and mobile operation. This document describes how Mobile IPv4 Fast Handover can be used IEEE 802.16e link layers.

Presented by Junghoon.

Presentation:

rfc 4068 is a work item (FMIPv4), so he proposes fmipv4 over 16. some of related work is done in MIPshop, so he is mentioning. some mobility is done in layer 2. predictive and reactive (??) modes were discussed.

Is there interest in this work? is this a topic for this working group?

Comments:

Pete:

the problem is that FMIPv6 over X is supported in MIPSHOP, but they have strict charter on v6. Should we get into FMIP stuff here?

Rajeev:

True, may be it should be here.

Parviz:

why just 16e? should be FMIPv4 over anything?

Pete:

you need to take the specifics of the link to make it working.

Hannes:

it is good stuff.

Kent:

it is interesting.

Henrik:

I can predict problems down the line when we want to go for publication.

9. Using multiple interfaces for increased throughput 5 min Srinivasa

draft-srinivasa-mip4-mir-00.txt

This document defines enhancements that allow a MN, when away from home, to simultaneously use multiple connected network interfaces so as to obtain higher aggregated bandwidth.

Henrik:

Author is not here. it is interesting work. uses multiple interfaces to stream videos to remote villages in India because the existing cellular systems and it is actual deployment. It is mature for adoptions. As an example of what you can do in a multiple interface scenarios.