2.3.16 Mobile Nodes and Multiple Interfaces in IPv6 (monami6)

NOTE: This charter is a snapshot of the 64th IETF Meeting in Vancouver, British Columbia Canada. It may now be out-of-date.
In addition to this official charter maintained by the IETF Secretariat, there is additional information about this working group on the Web at:

       Additional MONAMI6 Web Page

Last Modified: 2005-10-20

Chair(s):

Thierry Ernst <ernst@sfc.wide.ad.jp>
Nicolas Montavont <nicolas.montavont@enst-bretagne.fr>

Internet Area Director(s):

Mark Townsley <townsley@cisco.com>
Margaret Wasserman <margaret@thingmagic.com>

Internet Area Advisor:

Margaret Wasserman <margaret@thingmagic.com>

Mailing Lists:

General Discussion: monami6@ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/monami6
Archive: http://www.ietf.org/mail-archive/web/monami6/current/index.html

Description of Working Group:

There is currently rapid development in the area of new wireless
standards (802.11*, 802.16, 802.20, UMTS, Bluetooth and others). At
the same time, terminals which have radio and protocol support for
two, three or even more standards are appearing. This opens the
possibility of using multiple access types simultaneously, with each
access used to transport the traffic for which it is most
appropriate. For instance, an intermittent, but high-bandwidth access
type might be used for file transfers (e.g. music download) while a
low-bandwidth, high reliability access might simultaneously be used
for a voice call.

In the meantime, IP-level mobility support protocols such as Mobile
IPv6 (RFC 3775) and NEMO Basic Support (RFC 3963) have been conceived
by the IETF to support handoffs for IPv6 mobile hosts and routers,
respectively.

However, these protocols do not today provide standardized support for
simultaneous differentiated use of multiple access technologies,
although several proposals exist for such support, and some of them
have been implemented and tested.

When a mobile host/router uses multiple network interfaces
simultaneously, or when multiple prefixes are available on a single
network interface, the mobile host/router would end up with multiple
Care-of Addresses (CoAs). In addition, the Home Agent might be
attached to multiple network interfaces, or to a single network
interface with multiple prefixes, hence resulting in the option to use
multiple IP addresses for the Home Agent. This could result in the
possibility of using a multitude of bi-directional tunnels between
pairs of {Home Agent address, CoA} and a number of associated issues:
establishment, selection and modification of multiple simultaneous
tunnels. Some of the issues are very specific to mobility and are
generally applicable to both mobile hosts and mobile routers using
Mobile IPv6 and NEMO Basic Support respectively. Some of these issues
can be resolved with relatively small and straight-forward changes to
Mobile IPv6 and NEMO Basic Support (e.g. multiple CoAs registration).

The objective of the Monami6 WG is to produce a clear problem
statement and to produce standard track specifications to the
straight-forward problems associated with the simultaneous use of
multiple addresses for either mobile hosts using Mobile IPv6 or mobile
routers using NEMO Basic Support and their variants (FMIPv6, HMIPv6,
etc). Where the effects of having multiple prefixes on a single
interface is identical to the effects of having multiple interfaces
each with a single prefix, Monami6 will consider a generalized
approach to cater for multiple prefixes available to a mobile
host/router. Once this is done, the WG might re-charter in order to
work on more generic issues that prevent taking advantage of the
multiple CoAs and HoAs available to mobile nodes and routers.

The WG does not plan to define a tunnel selection mechanism, but may
document how to use existing mechanisms based upon preferences or
policies. In particular, the WG will consider that a tunnel
is alive as long as packets can be exchanged with the corresponding
peer. In addition, local information, such as interface up/down
events, or other failure detection mechanisms can be used to quickly
detect failure of tunnel(s).

WG Deliverables:

- A document explaining the motivations for a node using multiple
interfaces and the scenarios where it may end up with multiple
global addresses on its interfaces [Informational]

- An analysis document explaining what are the limitations for
mobile hosts using multiple simultaneous Care-of Addresses and Home
Agent addresses using Mobile IPv6, whether issues are specific to
Mobile IPv6 or not [Informational].

- A protocol extension to Mobile IPv6 (RFC 3775) and NEMO Basic
Support (RFC 3963) to support the registration of multiple Care-of
Addresses at a given Home Agent address [Standard Track].

- A "Flow/binding policies exchange" solution for an exchange of
policies from the mobile host/router to the Home Agent and from the
Home Agent to the mobile host/router influencing the choice of the
Care-of Address and Home Agent address [Standard Track].

Goals and Milestones:

Jun 2005  Submit Motivations and Scenario to IESG
Jun 2005  Submit Analysis of the use of Multiple Simultaneous Care-of Addresses and Home Agent addresses in Mobile IPv6
Jun 2005  Submit Multiple CoA Registration to IESG
Dec 2006  Submit Flow/binding policies exchange to IESG

No Current Internet-Drafts

No Request For Comments

Current Meeting Report

 

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# Monami6 WG Minutes, 64th IETF, Vancouver, Nov. 2005
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
- Notes taken by Will Ivancic
- Completed with notes from Thierry Ernst, Koshiro Mitsuya and Jabber logs.
- Get presentation material from
  https://datatracker.ietf.org/public/meeting_materials.cgi?meeting_num=64
- Get them also from http://www.nautilus6.org/ietf/ietf64
- Jabber logs: http://www.nautilus6.org/ietf/ietf64/monami6-ietf64-minutes-jabber.xmpp.org.rtf

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# 1. Monami6 welcome and introduction (5min.)
#    Chairs
#    http://www3.ietf.org/proceedings/05nov/slides/monami6-5.pdf
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# 2. Agenda Bashing (5min.)
#    Chairs
#    http://www3.ietf.org/proceedings/05nov/agenda/monami6.txt
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~   
Presented by Thierry.
No concerns.

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# 3. Charter description and explanation (10 min.)
#    Chairs
#    http://www3.ietf.org/proceedings/05nov/slides/monami6-17/sld1.htm
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Charter presented by Nicolas. See slides.

Q/A:

  TJ - how are we to interact with other working groups such as NEMO
  and Mobile-ipv6?

  Thierry suggested interaction by all members via participation on
  various working groups, but as chair of both NEMO and Monami6
  Thierry will make sure about this at least for NEMO.

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# 4. Motivations and Scenarios (10 min.)
#    (Goals and Benefits of Multihoming, draft-ernst-goals-and-benefits)
#    by Thierry Ernst
#    http://www3.ietf.org/proceedings/05nov/slides/monami6-9.pdf
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See slides. (Milestones should be read as "2006", instead of 2005)


Q/A: Multiple input from the floor, summary: - need distinction
between multi-homed and multi-addressed and multi-interfaced.  When we
need to make a distinction between multi-addressed, multi-interfaced
and multi-homming.

  Hesham: termilogy, need distinction between multihoming and
  multiaddressed. There are scenarions with different actions

  Henrik: different definitions is confusing. Choose different terms,
  multiple iface = multihoming, if not pick another word. Can help to
  find a word.

  Erik: historically: back to RFC, no distinctions. Confusion because
  of that. Useful to have a term which covers the union of the 2, and
  one to make the distinction. Make sense to come up with a term that
  better cover the union of the 2 ?

  Tim Sheppard - In what situation would one have multiple prefixes
  and not be multihomed?

  Hesham. Good to make that distinctions.  Not against using mhoming
  to cover both, but need to be able to have terms which cover one but
  not the other.

  Henrik: actually happy to use any term. (as long we agree, and we
  need to establish this terminology if it's not established yet

  Take terminology to mail list.

  Eric: Need to distinguish between host multihoming and site
  multihoming - particularly with regard to shim6.

  Erik: not finished read. In this document: going from the host
  aspect to site multihoming: become confusing when doc speaks about
  multihomed routers (MR -> multihomed site => making it clear =>
  things common with the bigger picture. Would make the document
  clearer and easier to undersatnad bigger pidure.

  Jim Bound: Do you want to address this situation, not sure. Do we
  need to consider manet technologies?
 
  Answer by Thierry - This WG is directed toward mobile-ipv6 and nemo.

Poll and conclusions:
- 20 people have read the doc.
- 40 OK for WG item - no opposition
- Document will become working group
- Renamed, probably to draft-ietf-monami6-scen-motivations
- Confirmation on the ML

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# 5. "Analysis of the use of Multiple Simultaneous Care-of Addresses and Home
#    Agent addresses in Mobile IPv6" (15 min.)
#    (draft-montavont-mobileip--multihoming-pb-statement)
#    by Nicolas Montavont
#    Discussion: adopt as a WG document?
#    Slides: http://www3.ietf.org/proceedings/05nov/slides/monami6-18/sld1.htm
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
Nicolas goes through the description of the draft. See slides

Q/A:

  Hesham: Is focus on CoAs or multiple HoAs?  Discussion in Paris
  indicated that focus would be in mulbiple CoAs?

  Nicolas replies:  WG focus on multiple CoA/several HA addresses

  HS: strange because some is not related to mobility in the draft.

  Erik: The 2 documents are actually broader than the solutions to be
  provided by Monami6. Covering the important stuff.

  Hesham: different prefixed for all HAs, or the same ?

  Erik: Standardized multiple CoAs may result in multiple HoAs.
  Tunnel may have multiple addresses at either or both ends.  Doesn't
  mean the MN has multiple HoAs. For this case, you need a Shim6
  solution. You can seperate up the concern about these two cases.

  Jim Bound: Having read all the specs. It points Shim6 is ongoing
  work. Don't agree there all in one HA. MN can have multiple HoAs -
  2, 4, 6 or more. Question to the chairs - (didn't catch all)
  WG willing to work on operational paradigms ? 

  Thierry - Need help from people with operational
  expertise/requirements. Let's take this to the mailing list.

  Pekka Nikander (PN) - Recommendation: Keep it simple.  Avoid
  complexity and trying to solve all problems.  There is a lot of
  other areas working mobility problems and the space is in flux with
  new proposed solutions.

  Question from Thierry: Is description too complex? There is an
  ppportunity to describe all the issues as done in NEMO WG for NEMO
  Basic Support (draft-ietf-nemo-multihoming-issues).

  PN - Be careful about idendity and locators. When doing the
  analysis, what is the identify, what is the locator. Clarify when a
  HoA is a locator and when it is an identifier

  Eric: Agree there is a risk. Getting those description correct is
  difficult. We need to understand enough as a WG that those solutions
  will fit a bigger picture, but no need to describe what is a locator
  or an identifier."

  PN: Try to keep it focus and narrowed, but if you want to go wider,
  you will enter this subtilities.

  HS: You would be boiling the ocean if you would describe everything,
  but understand it's not what you want to do. If analysis is
  describing general issues and work documents are focused, that is
  OK.

Poll and Conclusions:
- 10-15 people have read the draft
- 30 agree as a WG doc, nobody agains.
- Hesham: Only ten read document.  Can group have a week to read and
respond before acceptance as working group?
- Thierry: Item will be confirmed on the mailing list.  Initial
response from those that read document was positive.

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# 6. Implementation report and virtual interface usage (5 min.)
#    draft-hong-virtualif-mn-mipv6-00.txt
#    by Yong-Geun Hong
#    Slides: http://www3.ietf.org/proceedings/05nov/slides/monami6-12/sld1.htm
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See slides. Try to adap MIP6 and NEMO BS codes. Got comments on the ML before 
the meeting.

Q/A:

  Eric: How would DNA and other movement detection apply here?
  Layering virtual interfaces on top of physical interfaces may be
  very difficult.

  YongGeun: Will look at this.

  Ryuji W: SHISA implementation supports virtual
  interfaces. Implemented in a different way. Also, look very
  implementation specific. What are main issues regarding
  interoperability ?
 
  Floor:  Appears implementation specific.    

  Jim Bound: Good work, but needs to understand that people may have
  to change there code.  Needs lots of discussion. It should be part
  of the group that this particular draft should be followed up.

  Will Ivancic: Be careful how virtual model interacts with multiple
  physical radios.  Could cause problems - particularly if layer-2
  triggers come about.

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# 7. Accept Multiple Care-of Addresses Registration as a WG item? (15 min)
#    (draft-wakikawa-mobileip-multiplecoa-04.txt)
#    Ryuji Wakikawa
#    http://www3.ietf.org/proceedings/05nov/slides/monami6-8.pdf
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See slides.

Q/A on slide 4 (issue 2)

  Hesham: BID appears better than "old CoA"

  Eric: BID appears more robust.

  Vijay: Question, how does one search binding cache update. Home
  address is still an identifier, not always required to combine with
  BID.

  Hesham: 16bits is too much. We need to consider bandwidth when
  development.  Perhaps 8 bits vs 16 bits with 8 bits in reserve.

  Ryuji: Right. Explains why it's currently 16, not important reason,
  just for convenience: most of implementation is using 16 bits for
  interface identifier.

  Alex: we always search the BC (this is implementation
  dependant). This will probably lead to assign the BID to an
  identifier to the host ?  [Ryuji: no] To multiple identifiers to the
  host ?

  ChanWah: How are your going to define a new structure ? (separate
  entries, or new field)

  Ryuji: 100% implementation specific

  ChanWah: Don't think it's implementation specific. You need to
  define the conceptual data structure. You need to modify the
  conceptual data structure of MIP6, because it would help to describe
  how to look for CoAs.

Q/A on slide 5 (issue 3)

  Hesham: Is "primary" CoA necessary? 

  Hesham: MN with two home addresses registers them home. What happens
  when multihomed MN returns home?  Either you come home or you don't.

  Ryuji: Impossible with the current MIP6 spec. The HA defends only
  one address currently.  Which of the two will the HA defend?

  Answer: If any interface moves home, remove all CoAs.

  Ryuji: Perhaps terminology policy.  All agree in general how system
  should operate.  When home, some interface needs to be "effectively"
  disabled.  Either the HA interface or the CoA.

  Benjamin: Sorry guys sometimes I can't understand. Flags are scare.

  Vijay and Hesham commented on Flag in BU and DHADD.  [please comment
  on mail, what was resolved was not catched up by the minute takers]

  -- Vijay: difference between using a flag and a mobility option; a
  flag is non-skippable; an mobility header is...
  -- Vijay: extension of DHAAD is unnecessary  
  -- Hesham: agree, we don't want to extend DHAAD step when we have
  new tech.

Q/A next steps: How to proceed.  Should document be WG document?  

  Hesham: Document is good, this is framework. Later on, if we want to
  provide policies, this would be possible. Don't have anything
  against with this doc, but should be processed at the same time as
  the policy doc.

  Alex:  Is policy design team needed ?  This may be going too fast.

  ChanWah: Perhaps not enough requirements yet from the industry side.

  Basavaraj: work has been presented for a couple of years. No reason
  to delay. Should proceed forward. No need to discuss requirement
  from the industry and so on.

  Alex:  Work should proceed and WG document.

  Hesham: It is not constructive to wait for new drafts to show up.
  We should proceed.

Poll and Conclusions:
- 40 people have read the draft
- 20 support this doc as WG doc. Nobody opposes
- Consensus of room is to proceed as WG document.  Will take to mail
list for confirmation.

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# 8. IKEv2 and IPsec issues with multiple CoAs (15 min.)
#    Vijay Devaparalli
#    Slides: http://www3.ietf.org/proceedings/05nov/slides/monami6-14.pdf
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See slides.

Q/A:

  Erik: When doing forwarding over multiple CoA's things can get out
  of order? Mobike doens't do this. ISPs would thrtough away some
  packet


  Vijay: When sending a packet on 1 iface, then on anoter, you mean the
  sequence number may be stuck [???]

  Erik: Try to use a single IPsec SA for multiple flows and going
  through a single CoA.

  Hesham: Couldn't work at all.Use one primary CoA for HoTI and CoTI
  but we can't use same SA over multiple interfaces.

  Erik: Does one flow use one CoA and therefore one SA ? 

  Hesham: as far as protecting MIP6 signalling, pick one address for
  HoTI and CoTI.  But if we want to protect multiple interfaces then
  there should be multiple SAs, unless VPN gateway.

  Francis: Issue 8 in MOBIKE is similar.

  Vijay, all: Yes (laugths)

  Francis: Issue 8 is multiple address change.  USe one IKEv2 session
  to manage the different CoAs.

  Vijay: if you have to have multiple exchanges and multpile SAs then
  it becomes a pain.

# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# 9. Discussion on A "Flow/binding policies exchange" solution for an
#    exchange of policies from the mobile host/router to the Home Agent
#    and from the Home Agent to the mobile host/router influencing the
#    choice of the Care-of Address and Home Agent address" (20 min.)
#    Hesham Soliman
#    Slides: http://www3.ietf.org/proceedings/05nov/slides/monami6-16.pdf
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

See slides.

Multiple drafts address problems. Many have similar solutions.  All
agree to use the BU/BA to set filters for different flows.  Receivers
of the BU would route according to the filters received.

Documents will be merged.  Differences are very minor and should not
impede the merger.

Mobile host issues appear easier to mobile router issues.  Need a lot
of work ensuring group address all significant issues.

Out of Scope is Local Policies due to this being a implementation
issue.

Need more discussion on the MR side; MN side is clear.

Q/A:

  Floor: Traffic flow templates [as defined by 3GPP ?] have possible
  use here.

  Sri:  Can one prioritize interfaces and how?

  Hesham: Good question, we touched on it on the last slide. Simple
  case, some intelligence on the MN. Other case, MN behind
  MR. Information should be sent on the link (discover capabilities
  should be considered for this).  How far along the path should one
  go to discover capability.

  Thierry: What is next step for this ? Should this item done in the
  Monami6 WG ?

  Hesham: Not sure, but certainly needs to be discussed. May be
  analysis document ?

  Calrsten, floor: Couple of other differences between the existing
  propositions on the table. Binding flows to different CoAs [...],
  dropping or splitting a flow [...]

  Hesham: Did not bring up intentionally at this time.  Concerned
  about middle boxes dropping packets, not mobile node. HA doing it
  unilateraly would be dangerous.

Conclusions:
- Hesham: Start on what we agree on. Combine documents by next
IETF. Set up an issue tracker. 5 or 6 issues to discuss.


# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# 10. "Benefits of multiple care-of addresses and home addresses for low
#     power multimode mobiles" (10 min.)
#     draft-tsao-mip-multihoming-lowpower-00
#     Shiao-Li Tsao
#     Slides: http://www3.ietf.org/proceedings/05nov/slides/monami6-19/sld1.htm
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
See  slides.

Turn on multiple interfaces consumes up to 30 percent of power even if
inactive. Want to add text in "Scenarios and Motivations" doc. Want to
add text in the MIP6 analysis doc.

Q/A:

  Floor: Is assumption that different services are provided by same
  Administrative Domain?

  Shioa-Li: No, assumes different ISPs

  Floor: Then ISPs will not be able to route your addresses.

  Hesham: HA is tied to physical address resulting in multiple
  encapsulations.

Conclusions:
- Thierry: Be more precise on mail list about which text you would
like to see added in the oter documents.


# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
# 11. Conclusion and next steps (5 min.)
#     Chairs.
#     Slides: http://www3.ietf.org/proceedings/05nov/slides/monami6-15.pdf
# ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
 
This document was updated during the meeting and presents the
conclusions reached during the meeting.

Documents 1, 2 and 3 accepted as WG. Will be confirmed on the ML.

#3 should be proceeded at the same time/pace as #4

WG item 4,  merge 3 existing drafts into one.  Set up issue tracker.

Potential Next Steps:  
- Move multihomieng activity from NEMO WG? HAHA ?
- Discover capabilities between RM and MNNs ?
- Work on seamless handover?

Q/A:
- Margaret points out that the WG was accepted based on the current
charter (very focused).

Slides

Introduction
Charter description and explanation
Goals and Benefits of Multihoming
Analysis of multihoming in Mobile IPv6
Implementation Issues about Virtual Interfaces
Multiple CoAs
MCoA and IPsec
Support of Flow Bindings
Benefits of multiple CoAs and HoAs for low power multimode mobiles
Conclusions