2.3.9 Mobility for IPv4 (mip4)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-07

Peter McCann <mccap@lucent.com>
Henrik Levkowetz <henrik@levkowetz.com>
Internet Area Director(s):
Thomas Narten <narten@us.ibm.com>
Margaret Wasserman <margaret.wasserman@nokia.com>
Internet Area Advisor:
Thomas Narten <narten@us.ibm.com>
Mailing Lists:
General Discussion: mip4@ietf.org
To Subscribe: mip4-request@ietf.org
In Body: subscribe
Archive: www.ietf.org/mail-archive/working-groups/mip4/current/maillist.html
Description of Working Group:
IP mobility support for IPv4 nodes (hosts and routers) is specified in RFC3344. RFC 3344 mobility allows a node to continue using its "permanent" home address as it moves around the internet. The Mobile IP protocols support transparency above the IP layer, including maintenance of active TCP connections and UDP port bindings. Besides the basic Mobile IPv4 (MIPv4) protocols, several other drafts deal with concerns such as optimization, security, extensions, AAA support, and deployment issues.

Mobile IPv4 is currently being deployed on a wide basis (e.g., in cdma2000 networks). The scope of the deployment is on a fairly large scale and accordingly, the MIP4 WG will focus on deployment issues and on addressing known deficiencies and shortcomings in the protocol that have come up as a result of deployment experience. Specifically, the working group will complete the work items to facilitate interactions with AAA environments, interactions with enterprise environments when Mobile IPv4 is used therein, and updating existing protocol specifications in accordance with deployment needs and advancing those protocols that are on the standards track.

Work expected to be done by the MIP4 WG as proposed by this charter is as follows:

1. MIPv4 has been a proposed standard for several years. It has been adopted by other standard development organizations and has been deployed commercially. One of the next steps for the WG is to advance the protocol to draft standard status. As part of advancing base Mobile IP specs to DS, the Mobile IPv4 NAI RFC (2794) will also be progressed towards DS.

2. Key exchange using AAA infrastructures for setting up security associations defined in RFC3344 will be completed.

3. The AAA WG, which is currently dealing with the Diameter Mobile IP application, requires the AAA NAI for Mobile IPv4. This work will be completed by the WG. The MIP4 WG will also work with the AAA WG to ensure that the Diameter Mobile IP application is aligned with WG requirements.

4. Home agent assignment at the time of mobile-ip registration, rather than preconfigured for the mobile node, has been proposed in draft-kulkarni-mobileip-dynamic-assignment-01.txt. The WG will take on the task of completing this. The ability to switch the home agent assigned to a mobile node while registered will also be considered as part of this task.

5. Work items that are pending from the previous Mobile IP WG, which will be completed by the MIP4 WG, are RFC3012bis (Challenge-response mechanism), low-latency handover draft to experimental status and the completion of the MIB for the revised base Mobile IP specification (2006bis).

6. The MIP4 WG will also complete the work on Mobile IPv4 interactions in VPN scenarios. This work will involve identifying the requirements and a solution development for Mobile IPv4 operation in the presence of IPsec VPN's.

7. Experimental message types and extensions for Mobile IPv4 in accordance with draft-narten-iana-experimental-allocations-03.txt has been proposed in draft-patel-mobileip-experimental-messages-01.txt. The work group will take on and complete this specification.

Other potential work items may be identified in the future but will require an appropriate recharter.

Goals and Milestones:
Aug 03  AAA Keys for MIPv4 to IESG
Sep 03  MIPv4 VPN interaction problem statement to IESG
Oct 03  Low latency handover to experimental
Oct 03  Revised MIPv4 Challenge/Response (3012bis) to IESG
Oct 03  Advance RFC 2794 (NAI Extension specification) to IESG for Draft Standard
Nov 03  Revised MIB for MIPv4 to IESG
Dec 03  Revised MIPv4 specification to IESG for Draft Standard
Jan 04  Dynamic Home Agent assignment protocol solution to IESG
Jan 04  MIPv4 experimental extensions and message draft to IESG
Feb 04  MIPv4 VPN Solution to IESG
  • - draft-ietf-mip4-aaa-nai-00.txt
  • - draft-ietf-mip4-rfc2006bis-01.txt
  • - draft-ietf-mip4-aaa-key-01.txt
  • - draft-ietf-mip4-vpn-problem-statement-00.txt
  • - draft-ietf-mip4-rfc3012bis-00.txt
  • No Request For Comments

    Current Meeting Report

    IETF58 mip4 Working Group Minutes
    Monday, November 10, 2003
    1300 to 1500
    Chairs: Henrik Levkowetz, Pete McCann
    Thanks to Sami Vaarala and Eva Gustafsson for taking great notes.
    - unclear things marked with XXX
    - '???' refers to one and the same person who commented
      on the mike but whose name i did not get
    mobile ipv4 agenda (henrik levkowetz and pete mccann)
    introductions and agenda (pete)
    preliminaries (henrik)
    	- work status web page http://www.mip4.org/
    	- draft status
    			- reviewed by iesg, comments addressed in new text
    			- one new issue by Bjorn Andersson
    			- not re-submitted yet
    			- pretty much done, needs writeup by chairs, will send to iesg
    			- waiting for writeup, then to iesg
    			- waiting for mivp4 specific mib review
    			- after that, mib doctor review, finally iesg
    			- all comments addressed in latest version
    			- but document needs peer review to go forward
    			- wg chair review to be done soon
    	- charlie perkins
    		- what happened to the regional registration draft?
    		- seems that since it is done, should be sent to iesg?
            - Defer this question a bit while chairs confer with ADs
    aaa key draft (pete mccann)
    	- editorial mistake corrected in -01
    	- revisions from draft-ietf-mobileip-aaa-key-13
    		- clarify: for ipv4, not ipv6
    		- terminology cleanup
    		- clarified what happens if reg. reply fails
    		- iana considerations clarified
    		- explicit security requirements for aaa key
    			distribution infratstructure
    	- next steps
    		- one more ietf last call, then to iesg
    	- charlie perkins
    		- thought review was a response to iesg comments?
    	- pete mccan
    		- these were informal comments from iesg
    	- alpesh patel
    		- any work to support radius attributes?
    	- pete mccann
            - There is ongoing work on the Diameter MIP4 application in aaa WG
    		- mip4 not the place for RADIUS extensions, perhaps radiusext
              could take that work on
    experimental messages (alpesh patel)
    	- problem statement
    		- defines an experimental message, extensions and error code
    		- used to aid interoperability before standardization
    		- avoids overlap with reserved numbers
    	- status -- -02 published
    		- experimenteral message, extensions and error codes for mipv4
    	- where do we go from here?
    	- henrik levkowetz
    		- this problem has been added to charter, question is whether
    			this is the proper solution for the problem
    		- hum vote on whether this should be a work item
    			=> no hums in either direction
    		- hand voting
    			=> no hands for or against
    	- thomas narten
    		- is there interest in this work, do people know the issue?
    	- alpesh patel
    		- recap of motivation for the draft
    		- this is a problem, practical feedback from partners
    	- charlie perkins
    		- could not personally vote either way because had not read
    			the draft
    		- is this experimental?  sometimes you want to experiment with
    			two things, does the draft have subextensions
    	- alpesh patel
    		- yes, experimental
    	- thomas narten
    		- need to be able to experiment with protocols;
    			chicken-and-egg problem, need codepoints but iana
    			won't give you experimental allocations
    	- alpesh patel
    		- what if we need multiple numbers (e.g. two or three
    			message types?)
    	- thomas narten
    		- you could need requests and responses to be experimental
    	- alpesh patel
    		- you can also use experimental extensions etc
    	- henrik levkowetz
    		- we already have subtypes for extensions
    		- actually good to not reserve too many experimental numbers,
    			because you want to limit the number of extension
    			numbers you take for one single application
    	- thomas narten
    		- balance, you don't want to reserve too many, so that
    			numbers don't become permanent.  if number is
    			small enough, numbers cannot become permanent
    		- mobile ip has a history of having allocated without
    			talking to iana, sometimes problems in standardization
    			because numbers already iana
    		- idea here is that for experimentation and testing you
    			can do it the right way
    	- henrik levkowetz
    		- who's read the draft? ==> same hands that had an opinion
    		- we'll need more feedback on this
    		- please read the draft, chairs will post the question on
    			the list in a couple of weeks
    issues with rfc 3344 (charlie perkins)
    	- tracker for issues
    	- issue 9: fa should not reject rrq with error code 136
    		- conflicts with language describring the use of code 136
    		- straightforward solution: new error code
    		- this also provides the solution for issue 18?
    		(no discussion)
    	- issue 17: enhanced registration request processing at the home agent
    		- what is the motivation for the proposed text?
    		- error #129 is non-specific, #132 would do
    		- idea: what the ha is allowed to do if it gets a rrq to
    		  a unicast address the ha does not own?
    		- can't remember discussion why this would be interesting
    		- pete mccann
    			- some deployments where rrq might arrive at the ha
    			  maybe after being forwarded from another home agent,
    			  so the home agent address may not be set to any
    			  unicast address of the (final) home agent
    		 	- in those case, proposal was to allow ha to process
    			  that request and return a success indication but
    			  fill in its own address in the reply
    			- propose that we reject the issue
    		- charlie perkins
    			- agree, lot of recent discussion about ha failover
    			  in mipv6 context, starts to look like
    			  some sort of failover operation
    			-  also propose reject it
    		- rejected
    	- issue 18: the fa is rejecting with error code 137 which is
    			meant for the home agent
    		- proposal:  create a new error code in range 64-127, which
    			will then be a valid fa error code
    		(no discussion -- accepted?)
    	- issue 19: multiple authorization-enabling extensions should
    			be permitted
    		- suggestion: relax current restriction, we have multiple types
    			of authorization-enabling extensions now
    		- problem: what if one fails but other does not?
    			- possiblity: the ha checks until it finds one that
    			is verifiable?
    		- proposal: table the issue unless motivation increases or
    			problem is solved
    		- what is the motivation?
    			- which scenario is this a solution to?
    			- not personally favoring changes to do this,
    				introduces problems
    			- no strong feeling about this
    		- pete mccann
    			- there are cases where mn has both mn-ha and aaa
    			  extensions out in the field today, should be ok to
    			  append more than one extension, might be to
    			  authenticate yourself to two different nodes in the
    		- charlie perkins
    			- aaa authenticates use of charge card, and mn-ha
    			  authenticates mobility, for instance
    		- pete mccann
    			- reasonable use case
    		- charlie perkings
    			- can we require that all need to be verified, and
    			  must be rejected if any extension does not verify,
    			  different codes for different authentication failures
    		- charlie perkins:
    			- any other comments? (=> no)
    		- will take to the list
    	- issue 20: missing description - fa rejection code when
    		mn-ha auth ext invalid
    		- proposal: fa does not requre the existence of mn-ha
    			extension, nor reject the reg req if it is absent
    		- for this reason, related to issue 21
    		- is there a need for the fa to check "formatting" of the rrq?
    			- the packet will be rejected anyway by the ha
    			- rare case, imposing new requirements on the fa
    			- suggest fa does not need to check the mn-ha extension (XXX)
    		(no discussion)
    	- issue 21: mn-aaa ext. not considered in fa-to-ha forwarding rules
    		- proposal. reword to use "authentication-enabling" language
    		- observation: if, in future, more such authentication-enabling
    			extensions are defined, the fa may not be able to
    			identify those extensions as enabling
    		- suggestion: make sure that draft allows forwarding even
    			when fa does not understand some new auth extension
    		- want to avoid the situation where future authentication
    			extensions would not work in the specified model
    		(no discussion)
    challenge extensions (revised) (jayshree bharatia)
    	- changes from mobileip-rfc2013bis-06
    		- terminology changes, error codes renamed
    		- defined/clarified order of mn-aaa auth ext when coexists
    			with mn-ha existing in rfc 3344
    		- handling of solicited agent adv. at the fa is clarified
    		- suggestions are added to security considerations to
    			prevent invalidation of challenges caused by large
    			number of agent soliciations pr bogus registration
    		- editorial changes based on feedback from list
    	- issue 1: potential deadlock for slow reg. replies associated with
    			small (re)transmit rate at mn
    		- occurs when mn is busy downloading some large file and
    			trying to re-reg at the same time
    		- first identification field is old when first rrp arrives
    			(mn already sent a new rrq with new identification
    		- proposals:
    			1. introduce retransmitted challenge whose value
    				equal the challenge value used in the last
    				req reg + some constant value, and let fa
    				accept this retransmitted challenge as valid
    				=> potential security issues
    			2. reconfigure timer value at mn
    		- pete mccann
    			- this has been discussed on the mailing list
    			- root cause is link buffer that is getting full
    			- probably forward direction link towards the mn
    			- timer X has been set too short; rfc 3344 says,
    			  rexmit should be longer than roundtrip time
    			- proposal 2 used in the field, seems lower cost
    			  solution, least impact on standards
    			- one implementation trick: keep context around
    			  for the old request; if you get a response to
    			  an old request, you can accept it if this is
    			  valid;  this would also not affect the standards
    			- should consider lower cost alternatives
    		- charlie perkins
    			- consider handheld device case, chances of
    			  (end user) reconfiguring the timer in a mn
    			  are slim; most people would not do that even if
    			  option offered
    			- would like to see fa oriented solution
    		- pete mccann
    			- just increasing challenge window does not solve
    				the problem; same challenge would not work?
    		- charlie perkins
    			- it makes sense, does not seem like a big
    			  security problem  (XXX did not quite catch this)
    		- jayshree bharatia
    			- (XXX jayshree commented about the challenge
    			  being retransmitted, did not catch this)
    		- pete mccann
    			- because identifier changes it looks like a
    			  different request
    			- maybe we want to relax fa so that even if
    			  challenge previously used, it would still be ok
    			- we need to be careful with security considerations
    			- don't think this is a matter of user configuration
    			  of the timer, more manufacturer problem so that the
    		 	  manufacturer configures the proper timer (e.g. 4
    			  seconds), don't think that manufacturers are doing
    			  that correctly
    		- jayshree bharatia
    			- trade-off situation, rare scenario, the mn will
    			  most likely recover even without changes
    		- henrik levkowetz
    			- option 2 as a way to go?
    		- charlie perkins
    			- comment was just made that this is a fatal error
    			  and is recoverable
    			- thrust of pete's argument is that depending on
    			  traffic, the timer should be done by the manufacturer
    			  to antipicate these problems
    			- charlie agrees
    	- issue 2: processing of the invalid challenge at the fa upon receipt
    		of a registration reply from the ha
    		- MN => FA: reg req, chal = x
    		- FA => HA: reg req, chal = x
    		- HA => FA: reg rep, chal = z
    		- FA => MN: reg rep, chal = y 
    		- proposals
    			1. add text in sec. cons. regarding invalidation of
    		 	   the data supplied by the ha
    			2. discard received reg rep and send the reg rep with
    			   an appropriate error code once the time waiting for
    			   the valid response expires
    		- charlie perkins
    			- just wanted to expand on what the fa might do if
    			  it has bad format
    			- for a long time we had problem that if fa messes
    			  with code in reg rep, so was wondering whether we
    			  might have an extension where the fa could say
    			  "dont want to change reg rep code, but here's the
    			  code i would like to use")
    			- could have the original authentication data still
    			  verifiable, but still get the same data
    		- henrik levkowetz
    			- seems like the cleanest solution I heard so far
                - in favor of charlie's proposal
    		- jayshree bharatia
    			- (XXX take on the list?)
    vendor specific round up (henrik levkowetz)
    	- new possible charter item, currently a number of vendor specific
    		extensions for mipv4, which is good
    	- purposes of round-up
    		- catalogue v-s extensions found in the wild
    		- document purpoases and details of the messages
    			- understand why necessary
    			- see if there are commnon needs which new standard
    			  mipv4 extensions should be defined
    	- not work on
    		- v-s extensions that vendor does not want to share
    		- link specific v-s extensions
    	- is this a wortwhile effort for the wg to take on?
    		- espen klovning
    			- catalog would be nice, not aware of any
    			  actual vendor specific extensions
    		- thomas narten
                - I initiated this
    			- long time in ppp there was a similar situation, 
    			  having a document that listed the extensions useful
    			  in debugging
    			- simply provide information to people, but not
    			  necessarily take the work on
    		- henrik levkowetz
    			- we should add the debugging aspect
    		- charlie perkins
    			- might interact with iana work?  Individuals might get assignments
                  that they would not have gotten otherwise
    		- thomas narten:
    			- good question, if people are using same numbers
    		- charlie perkins: (XXX: did not get this)
    		- pete mccann
    			- clarification: charlie, are you talking about people who didn't use
    			  v-s extensions, but used the standards-track extension space without
    		- charlie perkins
    			- yes
    		- henrik levkowetz
    			- since these are vendor specific, they are orthogonal
    			  to each other, no collisions, are and will continue
    			  to be owned by the respective vendors;  if we
    			  standardize, we need to go through the normal
    			  routine and iana process
    		- pete mccann
    			- should not be a problem with iana
    		- thomas narten
    			- theory is that having more information is better
    			  than not having information
    		- ???
    			- practically every protocol has vendor specific
    			  options, not sure if this is useful
    		- thomas narten
    			- not necessarily, if its useful they do it, if not,
    			  they don't
    		- ???
    			- not ietf's job to find variations from vendors
    		- pete mccann
    			- will take cooperation of vendors, not a polling
    			  exercise to get extensions, vendors will need to
    		- ???
    			- how we actually do this?
    		- pete mccann
    			- will need to use our contacts in the industry
    		- ???
    			- the effort will be incomplete
    		- pete mccann
    			- some items are specificallty excluded, there is no
    			  intention to get a comprehensive list
    		- alpesh patel
    			- vendors can add proprietary information to messages
    			- why would vendors tell that information?
    		- henrik levkowetz
    			- maybe they wont
    		- alpesh patel
    			- if vendors think extensions add value, vendor should
    			  try to standardize the extensions themselves, the
    			  working group should not do it
    		- pete mccann
    			- this effort could be best seen as a way to facilitate
    			  the process
    		- thomas narten
    			- are there interoperabilty issues here, e.g. people
    			  need to implement vendor specific stuff to make
    			  things work, sometimes vendor specific extension
    			  becomes de facto standard, so vendors just need to
    			- not useful to have "the definitive list", but still
    			  might be a useful effort
    		- henrik levkowetz
    			- does the wg feel this is a wortwhile exercise?
    			- for: a few, opposed: a few
    			- no clear consensus
    			=> won't go into this at this time
    		- pete mccann
    			- if more interest in the list, might pick up later
    		- thomas narten
    			- do people feel there are issues with vendor
    			  specific extensions?
    		- pete mccann
    			- any examples?
    		- ???
    			- example with a test suite vendor who has test suites
    			  for vendor specific extensions; ietf has nothing
    			  to do with it
    		- henrik levkowetz
    			- at my company, we have only had problems in this
    			  area only once, where we came across a v-s ext
    			  and could not handle it correctly; the ext was
    			  skippable, so the processing was fixed to skip
    			- having skippable extensions makes this a non-issue
    			  for interoperability
    		- pete mccann
    			- we'll put this on the shelf for now, unless
    			  there is more interst on the mailing list
    dynamic ha assignment (alpesh patel)
    	- status
    		- version 02 published
    		- major changes from 01 to 02
    		- active interest from vendors
    		- at least 2 working implementations
    	- resolved issues / changes in 02
    		- terminology and editorial
    		- loop free routing of rrq
    		- load balancing by rejecting the rrq with special code and
    			suggesting an ha
    		- security consiederations
    	- terminology and editorial
    		- requested/assigned ha -- denote a single ha, indicates the
    			meaning depending on the message type
    		- redirected ha -- new ha that is being referred to for load
    			balancing, administrative policies etc, when the reply
    			message carries a special error code (TBD by IANA)
    		- changed text to take care of "outside the scope" as in -01
    	- loop free routing of rrq
    		- no ha redirection in network (as in version 01), ha could
    			forward rrq to another ha
    		- ha receiving rrq (assigned ha) may reject the request and
    			point to a redirected ha
    		- since ha does not forward rrq in network, no chance of same
    			rrq looping in the network
    		- also fixes a nat traversal problem
    	- load balancing
    		- requested ha can suggest an alternate ha to use by
    			rejecting with special error code and redirected ha
    			address in extension
    		- if special error code is present, the extension carrying
    			redirect ha address must be present
    	- security considerations
    		- since there is no redirection in network, fa receives rrp
    			from the ha it fowraded to rrq (no address mismatch)
    		- statement that "mn and all has may share same sa" removed
    		- mn and ha can derive dynamic seucrity association
    	- open issues
    		- in extension carrying redirected ha address, including
    			public and pricate ha ip address if available
    		- would like to get feedback on this
    	- questions ?
    	- ???
    		- question regarding redirection, how do you redirect without
    		  knowing the status of the target ha?  Could be redirecting into
              a black hole
    	- alpesh patel
    		- this is outside the scope, could be a heartbeat protocol,
    	- ???
    		- suppose that redirections start "bouncing"
    	- alpesh patel
    		- not enforcing that, management layer in mn could detect
    	- ???
    		- protocol should take care of reconfiguration
    	- alpesh patel
    		- can be built on client side, mn can simply keep state of
    		  registration attempts and redirections
    	- ???
    		- have to build state for each registration in the client,
    		  loop can be longer
    	- henrik levkowetz
    		- sounds like an earlier version of the draft, there is no
    		  forwarding of the rrq in the draft
    	- pete mccann
    		- i think the draft now puts mn in control of every reg
    		  retransmits, mn can decide what to do, much more in line
    		  with the end-to-end principle, and can detect config errors
    	- henrik levkowetz
    		- who has read the draft?  (=> a few hands)
    	- henrik levkowetz
    		- the issue is within the wg charter, sooner or later we
    		  need to decide whether this draft is a good solution to
    		  the accepted problem in the charter
    		- with the few readers who read, will not do this now
    		- will solicit a few more people to read, then get
    		  feedback from list
    ipv6 in mipv4 tunnels (scott corson)
    Representing George Tsirtsis & Hesham Soliman
    	draft-soliman-v4v6-mipv4-00 (incorrect file)
    	- the problem - 1
    		- mipv4 allows ipv4 node to move in ipv4 networks
    		- same for mipv6 (for mipv6 networks)
    		- but internet is a micture of ipv4, ipv6, and dual
    		  stack networks, interop issues
    	- best case scenario today - what works and what doesn't?
    		- mipv4 => IPv4 and dual stack
    		- mipv6 => IPv6 and dual stack
    		- mn supports mipv4 and mipv6 => ipv4, ipv6, dual stack okay
    			- but e.g. v4 => to v6 handover does not work
    		=> undesirable overhead, unpredictable connectivity
    	- the problem - 2
    		- double overheads
    		- inability maintaining sessions when doing v4/v6 handovers
    		- mobility micromanagement impossible
    	- solution: ds-mip
    		- use mip as a v4/v6 migration tool
    			- use the tunneling capaibility of mip to forward
    			  both ipv4 and ipv6 traffic over the same mip
    			  created tunnel
    		- mipv4 extension
    			- allow ipv4 and ipv6 hoas to bind to an ipv4 coa
    		- mipv6 extensions
    			- similarly
    		- mn can use either ds-mipv4 only (initially), or ds-mipv6
    		  only (future)   (XXX?)
    	- scenarios
    		- ds-mipv4 scenario - ipv4 dominant
    		- ds-mipv6 scenario - ipv6 dominant
    		- ds-mipv4 and ds-mipv6 solution works with both ipv4
    		  and ipv6 networks
    	- james kempf
    		- draft looks ugly, but maybe the problem is that the
    		  problem is ugly and requires an ugly solution
    		- not too common to wander from network to another and
    		  change from v4 to v6 or vice versa
    		- haven't seen a solution that looks nice
    	- pete mccann
    		- suggest that we adopt ipv6 everywhere? (:-)
    	- james kempf
    		- of course
    		- would like to see more thought on this, alternative
    	- alpesh patel
    		- couple of years ago there was a relevant contribution
    		- draft from Pat Calhoun & others
    	- pete mccann
    		- participated in the draft, no interest at the time
    		- i think the ds-mip approach solves some problems not
    		  in the previous draft
    	- pete mccann
    		- first exercise: do we want to add this to the charter?
    	- henrik levkowetz
    		- we will not make any decisions now
    		- we'd still like to see who thinks this is an interesting
    		  problem to look at?
    		- for: ~10 ? against: none  (XXX)
    filters for mobile ipv4 bindings (carsten bormann)
    	- motivation
    		- simultaneous use of multiple points of attachments on a
    		  single mobile device
    	- mobile ipv4
    		- simultaneous binding, s-bit, duplicates traffic
    		- if duplication is unwanted, only one poa can be active
    		- one hand-off affects all flows
    		- not enough ip addresses for multihoming
    	- filtering for mobile ip bindings (nomad)
    		- simultanous use of multiple points of attachment with
    		  a single home ip addresses without duplicating traffic
    		- distribution of multiple flows / single flow
    		- flow rejection
    	- applications
    		- load balancing
    		- network management (flow mgmt initiated by core network)
    		- enchanged terminal mobility (partial/smoothed handoffs)
    		=> better utilization of available network resources
    	- idea: send filters from mn to ha, mn can specify which parts of
    		data flow should be sent through which interfaces / points
    		of attachment
    	- mode of operation (slide illustrating modes of operation with
    		different filters)
    		- may have "competing" filter specifications, e.g. same filter
    		  but can specify that 20% to interface 1, 80% to interface 2
    		- also weights
    	- dynamic format filters
    		- nine types of filter modules, OR and AND between predicates
    	- conclusions
    	- do we want to do this work in this working group?
    	- ???
            - good idea, but have fundamental problems
    		- how will you stop from requesting a large number of flows?
    		- very complex filter policies, will affect traffic to
    		  every other device
    	- carsten bormann
    		- this is between mn and ha
    	- ???
    		- no, can affect other mns, e.g. huge number of filters
    	- carsten bormann
    		- you can work around this
    	- ???
    		- although theory is novel, not practical?
    	- james kempf
    		- i think this is a really bad idea; home agent is a
    		  convenient middle box, so we can do all nice things
    		  in the middle box [is often thought]
    		- you don't have some of this information in the ip
    		  layer to do this, relevant information may be in
    		  the transport layer
    		- i don't see any real usefulness
    	- carsten bormann
    		- several things in the question; are you addressing
    		  the case where one transport is through multiple
    		  connections, or several transports through multiple
    	- james kempf
    		- any case where you use multiple interfaces for
    		  other than sending traffic through them
    		- don't think this is the right way to deal with the
    	- pete mccann
    		- i see some good motivations for doing this thing,
    		  we have many interface types which are suitable
    		  for different things; e.g. voice over 3g, data
    		  over wlan.  if application can distinguish those
    		  things, app could control routing
    		- but, not convinced that mobile ipv4 is the right
    		  way to do it, what if all interfaces are at home?
              Then there is no home agent to do the filtering, and
              we need another solution.
    		- a bit confusing, not sure what is the right solution,
    		  should perhaps be independent of mipv4
    	- carsten bormann
    		- many situations where you want someone in the network
    		  to do something for you, addresses james's comments
    		  as well.  would be nice to have a general architectural
    		  approach for having this, a "friend" in the network
    		  to do this for you.
    		- rsvp does something similar but is a one connection
    		  protocol.  nsis is doing something similar.
    		- if you have an identifiable thing in the network
    		  where to do this work, it might be a good place
    		  to do the changes; you could also have a completely
    		  separate protocol for doing this. seems to me that 
    		  mobile ipv4 would be a good match for this problem.
    	- henrik levkowetz
    		- i have a couple of issues; first, basic idea of
    		  route appropriate flows over appropriate channels;
    		  i think really belongs in the end nodes, the appropriate
    		  would be to let applications select which interface to use
    		- second, if you want to go down this road, you want to do
    		  this for other things than mobile ipv4 (signaling), this
    		  is completely  incomplete as long as you don't have a
    		  way for applications to signal their needs and then some
    		  transport with filtering capability
    		- multiple interfaces with multiple capabilities, don't do
    		  anything except in end node
    	- carsten bormann
    		- counter-argument is that much depends on the mobile node
    		  actually moving, so the characterization of an interface
    		  changes as the mobile node moves; not clear that you want
    		  to involve correspondent node architecturally
    		- can you put this into one domain and without changing the
    		  correspondent node?  from protocol point of view, ha seems
    		  like a good choice
    		- i think there are good arguments for considering
    		  mobility aspects
    	- james kempf
    		- there are other possibilties in transport area for instance
    		- point is that it's not wise to complicate the home agent by
    		  putting this functionality in; it's not clear that you get
    		  the necessary nformation at the ip layer to do this
    		- one could consider another mechanism 	separate from mipv4
    	- henrik levkowetz
    		- some aspects are enticing, but feel that there are good
    		  things but not sure it has "landed" completely yet
    	- bof tonight
    	- any more comments? (=> no)
    	- henrik levkowetz
    		- agenda done, any more issues?
    	- charlie perkins
    		- loose question about the regional registration draft
    	- henrik levkowetz
    		- when mobile ip split to three groups, no-one took
    		  the draft
    		- merit to go forward?
    	- charlie perkins
    		- several people asked, several requests on the
    		  mailing list
    	- henrik levkowetz
    		- true
    	- charlie perkins
    		- expectation was this would be published
    	- thomas narten
    		- should take this off-line, the document was
    		  expired and appeared to be dead when documents
    		  were divided
    	- henrik levkowetz
    		- we're done


    AAA-Key Draft
    Experimental Message, Extension and Error Codes for Mobile IPv4
    Issues with RFC 3344
    RFC3012bis Updates/Issues
    Mobile IPv4 Dynamic Home Agent Assignment Framework
    Mobility in a Dual Stack Internet
    Filters for Mobile IP Bindings (NOMAD)