Subject: Multi6 WG Last Call (1 of 3) draft-ietf-multi6-architecture-01.txt

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Oct 2004 00:13:09 +0200

It is proposed to forward
     draft-ietf-multi6-architecture-01.txt
to the IESG for approval as an Informational RFC

Any final comments must be sent to the WG list at [email-masked]
within two weeks, i.e. at the latest on November 3, 2004.

Thanks

   Brian Carpenter
   multi6 WG co-chair

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 21 Oct 2004 00:21:30 +0200

My minor substantive comments are below.
Some editorial comments were sent direct to the author.

 > 4.2  Multi-Homing: Mobility
...
 >    The aspect of MIPv6 which appears to present issues in the context of
 >    multi-homing is the return routeability mechanism.  In MIPv6 identity
 >    validity is periodically tested by return routeability of the
 >    identity address.  This regular use of a distinguished locator as the
 >    identity token cannot support return reachability in the multi-homing
 >    context in the event of extended path failure of the path that is
 >    associated with the identity locator.

This question isn't really relevant to multi6, but isn't it therefore
also the case that if the home agent becomes unreachable for more than
7 minutes, regular MIP6 also breaks for the same reason and the mobile
node loses connectivity?

 > 5.3.3  Layering Identity
...
 >    An alternative approach is to use a distinct protocol element placed
 >    between the transport and internet layers of the protocol stack.  The
 >    advantage of this approach is that it would offer a consistent form
 >    of mapping between identities and locators for all forms of transport
 >    protocols.  However this protocol element would not be explicitly
 >    aware of sessions and would either have to discover the appropriate
 >    identity / locator mapping for all identity-addressed packets passed
 >    from the transport protocol later, irrespective of whether such a
 >    mapping exists and whether this is part of a session context, or have
 >    an additional mechanism of signaling to determine when such a mapping
 >    is to be discovered and applied.  At this level there is also no
 >    explicit knowledge of when identity / locator mapping state is no
 >    longer required, as there is no explicit signaling of when all flows
 >    to and from a particular destination has stopped and resources
 >    consumed in supporting state can be released.

But there is knowledge, even with UDP, when a socket is closed (in
the worst case because the process that opened it goes away). I think
that because of some sort of layering religion, we tend to neglect
the fact that socket state exists and gets explicitly deleted, and
this should be exploited as the trigger for deleting id/loc
mapping state.

     Brian

---

From: Jari Arkko <[email-masked]>
Date: Thu, 21 Oct 2004 10:03:46 +0300

> 7 minutes, regular MIP6 also breaks for the same reason and the mobile

This is correct. Other mobility mechanisms such as HIP could
survive such scenarios, however.

--Jari

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 21 Oct 2004 10:57:13 +0200

Hi Brian,

El 21/10/2004, a las 0:21, Brian E Carpenter escribió:

> This question isn't really relevant to multi6,

Well, lots of people claim that there is a close relation between 
multihoming and mobility, since both problmes require changing the 
locators and keep the identifier.
Since there is an available solution for mobility, it seems quite 
natural to explore if such solution is suitable for multihoming.
The problem with the available solution for mobility is that the 
security mechanism used in mip is inherently incompatible with the 
multihoming requirements, since it is based on reaching the identifier.

so imho it is relevant to multihoming the explanation why the approach 
used for mobility is not suitable for multihoming.

regards, marcelo

>  but isn't it therefore
------------------------------------------
Please note that my former email address
[email-masked] is no longer in use
Please send mail to:
marcelo at it dot uc3m dot es
------------------------------------------

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 26 Oct 2004 09:46:49 +0200

Since draft-ietf-multi6-architecture-02.txt has just been
published, the WG Last Call now applies to this draft.
Since the differences are small (see the second page
of the draft), the comment deadline is still November 3.

    Brian
    multi6 WG co-chair