Jong-Hyouk Lee | 28 Aug 13:45 2015

Review request for the Home Network Prefix Renumbering in PMIPv6

Hi all

Kindly consider to review the draft "Home Network Prefix Renumbering in PMIPv6": Before the WG adoption call, authors
are willing to get further comments and improve the draft.

Jong-Hyouk Lee, living somewhere between /dev/null and /dev/random
Protocol Engineering Lab., Sangmyung University

#email: jonghyouk@...
Templin, Fred L | 22 Aug 00:50 2015

AERO source code available


AERO (draft-templin-aerolink) has been under internal development for
some time, and is now available for first public release:

This release includes a user-level daemon for use on AERO Clients and
Servers, and a kernel-level driver for use on AERO Relays. Also included are
network emulation models of simple AERO networks for experimentation
using the Common Open Research Emulator (CORE):

The code has been tested primarily on Ubuntu, but can be ported to other
linux-based platforms. Android testing should also be possible.

This release currently demonstrates the following aspects of AERO:

- AERO tunnel virtual NBMA link
- DHCPv6 Prefix Delegation (PD)
- IPv6 Neighbor Discovery (ND)
- BGP routing
- AERO Client to Internet host communications
- AERO Client to AERO Client route optimization
- AERO Client mobility

Guidance can be found in README files and manpages; please feel free to
experiment with the code and send feedback. We will address any issues
(Continue reading)

Jouni Korhonen | 12 Aug 20:35 2015

WG Last Call for draft-ietf-dmm-4283mnids-00


This mail starts a two week WGLC #1 for the I-D 
draft-ietf-dmm-4283mnids-01. The WGLC ends 26th August 2015 EOB Pacific 

Please, review the document and indicate your support or concerns on the 
mailing list. If you have concerns or comments that you want to be 
reflected in the draft text issue a ticket into the issue tracker as 
well. We urge you to utilize the issue tracker for comments that you 
want to be resolved.

- Dapeng and Jouni
Templin, Fred L | 23 Jul 08:21 2015

Comment on draft-moses-dmm-dhcp-ondemand-mobility


Section 3.1 of this document says:

   "If a client receives an IA Address option from a server with the IPv6
   Continuity Service option in the IAaddr-options field, without
   initially requesting a specific service using this option, it must
   discard the received IPv6 address."

But, this might leave the server with stale state. Perhaps it should say:

  " should send a Decline message to the server and must discard
   the received IPv6 address."

Same comment applies to the similar block of text that appears in
Section 3.2.

Thanks - Fred
Meetecho Team | 22 Jul 17:00 2015

Meetecho recordings of DMM WG session

Dear all,

the full recording (synchronized video, audio, slides and jabber room) of the 
DMM WG session at IETF 93 is available at the following URL:

In case of problems with the playout, just drop an e-mail to ietf-support@...

For the chair(s): please feel free to put the link to the recording in the minutes,
if you think this might be useful.

the Meetecho Team

dmm mailing list
Dave Dolson | 21 Jul 01:51 2015

mobility and link state


Although I’m new to this working group, today I watched you present at IETF on the subject of applications monitoring link state.

You asked for feedback on the mailing list… Maybe some of these ideas are useful:


Thinking as an application author,

-          I think some kind of signal about network loss is useful, rather than applications using arbitrary timeouts on transaction times. Example: when should a browser or database client give up on a request? The timeout approach is unsatisfactory for transactions that take a long time to run.

-          Having said that, the application should not have to know about links or layer2 health.

-          Links should be able to go up and down, without dropping a TCP connection, for example. I feel there is a strong tradition of this behavior. IP addresses should be able to move between interfaces (e.g., from a physical interface to a tunnel interface) without interruption of the socket.

-          but one thing that warrants an exception is when the address bound by the socket is no longer available on the host. I believe current behavior a socket will stay alive even when the IP address is no longer available on the host, presumably in the hope that the IP address will be assigned again.


-           The socket should only fail if the transaction is not going to finish. In mobility context this might mean that the loss of the IP address is likely permanent (what is “permanent”? --> need heuristics).

-          Typical applications will connect with “any” for the source address to bind to. When a host has multiple IP addresses (multi-homed), there is a complicated set of rules for choosing one (RFC 6724). Your thoughts on choosing best routes may fit in this framework. (Is RFC 5014 relevant here?)


So my proposal, which I think can be backwards compatible:

-          Add an ioctl or getsockopt so that the application can ask, “would there be a better choice of local address”, giving the application an opportunity to start another socket at the best opportunity (after the current transaction).

-          Add a socket option for the idea of “create socket error if local IP has been lost for X seconds”. I propose the timeout, allowing an IP address to be removed from one interface and added to another without socket error. This is better than an application timeout.


Consider the case of a database client using a persistent database connection for queries.

To handle the soft hand-over case a smart client would keep checking if the socket is optimal. If not, finish the current transaction on the existing socket and open a new socket for new transactions. The new socket presumably uses the newer and better local IP address.





dmm mailing list
Jouni Korhonen | 15 Jul 23:53 2015

Note takers, jabber scribe, etc


For a fluent flow during the DMM WG meeting, it would be great to have 
someone to volunteer as a note taker, a jabber scribe etc. Let the 
chairs know if you are volunteering (I'll get you a cookie and coffee as 
a reward for your trouble ;) Otherwise I will have to "volunteer" 
someone at the begining of the meeting..

- Jouni & Dapeng
Dapeng Liu | 15 Jul 04:06 2015

DMM agenda update

Hello all,

We update the DMM agenda:

Please send slides to chairs as soon as possible if you have presentation on the agenda.

Dapeng & Jouni
dmm mailing list
Z.W. Yan | 15 Jul 03:33 2015

New Version Notification for draft-yan-dmm-hnprenum-02.txt

Hi, all,
Based on the comments we collected on-line and off-line, we updated the draft of "HNP renumbering in PMIPv6".
Any comments from you are all welcome.
Zhiwei Yan
dmm mailing list
Sri Gundavelli (sgundave | 10 Jul 03:30 2015

Re: RFC4283bis progress..

 I can review and provide comments. I think its ready for publication, may be after a minor edit.

From: dmm <> on behalf of jouni korhonen <>
Date: Thursday, July 9, 2015 at 1:49 PM
To: "" <dmm <at>>, Charlie Perkins <>
Subject: [DMM] RFC4283bis progress..

Charlie, WG,

In last IETF and slightly after that there was discussion about missing MN-IDs in the current -00 version. Have these been or rather will these be addressed? I'd like to move this trivial document forward.

- Jouni & Dapeng
dmm mailing list
jouni korhonen | 9 Jul 22:49 2015

RFC4283bis progress..

Charlie, WG,

In last IETF and slightly after that there was discussion about missing MN-IDs in the current -00 version. Have these been or rather will these be addressed? I'd like to move this trivial document forward.

- Jouni & Dapeng
dmm mailing list