Subject: [Mip4] RFC 5177 on Network Mobility (NEMO) Extensions for Mobile IPv4

From: [email-masked]
Date: Wed, 23 Apr 2008 16:47:21 -0700 (PDT)

A new Request for Comments is now available in online RFC libraries.

        RFC 5177

        Title:      Network Mobility (NEMO) Extensions for 
                    Mobile IPv4 
        Author:     K. Leung, G. Dommety,
                    V. Narayanan, A. Petrescu
        Status:     Standards Track
        Date:       April 2008
        Mailbox:    [email-masked], 
                    [email-masked], 
                    [email-masked],
                    [email-masked]
        Pages:      26
        Characters: 56094
        Updates/Obsoletes/SeeAlso:   None

        I-D Tag:    draft-ietf-mip4-nemo-v4-base-11.txt

        URL:        http://www.rfc-editor.org/rfc/rfc5177.txt

This document describes a protocol for supporting Mobile Networks
between a Mobile Router and a Home Agent by extending the Mobile IPv4
protocol.  A Mobile Router is responsible for the mobility of one or
more network segments or subnets moving together.  The Mobile Router
hides its mobility from the nodes on the Mobile Network.  The nodes
on the Mobile Network may be fixed in relationship to the Mobile
Router and may not have any mobility function.

Extensions to Mobile IPv4 are introduced to support Mobile Networks.
[STANDARDS TRACK]

This document is a product of the Mobility for IPv4 Working Group of the IETF.

This is now a Proposed Standard Protocol.

STANDARDS TRACK: This document specifies an Internet standards track
protocol for the Internet community,and requests discussion and suggestions
for improvements.  Please refer to the current edition of the Internet
Official Protocol Standards (STD 1) for the standardization state and
status of this protocol.  Distribution of this memo is unlimited.

This announcement is sent to the IETF list and the RFC-DIST list.
Requests to be added to or deleted from the IETF distribution list
should be sent to [email-masked].  Requests to be
added to or deleted from the RFC-DIST distribution list should
be sent to [email-masked].

Details on obtaining RFCs via FTP or EMAIL may be obtained by sending
an EMAIL message to [email-masked] with the message body 

help: ways_to_get_rfcs. For example:

        To: [email-masked]
        Subject: getting rfcs

        help: ways_to_get_rfcs

Requests for special distribution should be addressed to either the
author of the RFC in question, or to [email-masked].  Unless
specifically noted otherwise on the RFC itself, all RFCs are for
unlimited distribution.

Submissions for Requests for Comments should be sent to
[email-masked].  Please consult RFC 2223, Instructions to RFC
Authors, for further information.

The RFC Editor Team
USC/Information Sciences Institute

...

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 24 Apr 2008 10:52:49 +0100

Hi all,

Now that NEMOv4-base is outof the way, how about starting the process
for http://tools.ietf.org/html/draft-ietf-mip4-nemov4-fa-02 ?

Regards
George

On Thu, Apr 24, 2008 at 12:47 AM,  <[email-masked]> wrote:
>  _______________________________________________
>  IETF-Announce mailing list
>  [email-masked]
>  https://www.ietf.org/mailman/listinfo/ietf-announce
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 24 Apr 2008 12:04:15 +0200

> for http://tools.ietf.org/html/draft-ietf-mip4-nemov4-fa-02 ?

Not sure whether you request procedural advancement or technical discussion.

Technically, I think there's need of some more syncing on FA-NEMO docs, 
eg citing numbers already allocated, ordering between different mobile 
network extensions, and maybe other things.  The Sec section could say 
how new risks are introduced by th etunnelling extension and how 
protection is offered.  3.1 background could picture a figure or two of 
tunnels.  Just some thoughts...

Alex

>>  USC/Information Sciences Institute

______________________________________________________________________
This email has been scanned by the MessageLabs Email Security System.
For more information please visit http://www.messagelabs.com/email 
______________________________________________________________________
-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 24 Apr 2008 11:09:54 +0100

Hi Alex,

Any feedback is good.

- we should indeed sync up the docs a bit more now that one is stable.
I will do that.
- what new threats do you see with the new tunneling extension?
- not sure I see a reason to do more figures, but if you or someone
puts together some relevant figures I would be ok with including them
in the draft.

Thanks
George

On Thu, Apr 24, 2008 at 11:04 AM, Alexandru Petrescu
<[email-masked]> wrote:
>  Technically, I think there's need of some more syncing on FA-NEMO docs, eg
> citing numbers already allocated, ordering between different mobile network
> extensions, and maybe other things.  The Sec section could say how new risks
> are introduced by th etunnelling extension and how protection is offered.
> 3.1 background could picture a figure or two of tunnels.  Just some
> thoughts...
>
>  Alex
>
>
>
>
> >
> >
> > Regards
> > George
> >

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 24 Apr 2008 12:27:08 +0200

George Tsirtsis wrote:
> Hi Alex,
> 
> Any feedback is good.
> 
> - we should indeed sync up the docs a bit more now that one is
> stable. I will do that. - what new threats do you see with the new
> tunneling extension?

For example what happens if FA requests with the tunneling extension but
the MR prefers it not.

You don't see any threat with the tunneling extension?  MR-FA-HA is a
three-party communication and very much prone to risks.

> puts together some relevant figures I would be ok with including them

Thinking about this.  I think the doc has no other figure.  Section 3.1
is way too short and compressed.  When reading, I need to mentally 
picture those tunnels to understand it.  If I had figures in 3.1 my 
reading would be eased.  Maybe I'll provide some figures later.

Alex

> Thanks George
>>> Now that NEMOv4-base is outof the way, how about starting the
>>> process for
>>> http://tools.ietf.org/html/draft-ietf-mip4-nemov4-fa-02 ?
>>> 
>> citing numbers already allocated, ordering between different mobile
>> 
network
>> are introduced by th etunnelling extension and how protection is
>> offered. 3.1 background could picture a figure or two of tunnels.
>> Just some thoughts...
>> 
>> Alex
>> 
>> 
>> 
>> 
>>> 
>>> Regards George
>>> 
>>>> Title:      Network Mobility (NEMO) Extensions for Mobile IPv4 
>>>> Author:     K. Leung, G. Dommety, V. Narayanan, A. Petrescu 
>>>> Status:     Standards Track Date:       April 2008 Mailbox:
>>>> [email-masked], [email-masked], [email-masked], 
>>>> [email-masked] Pages:      26 Characters:
>>>> 56094 Updates/Obsoletes/SeeAlso:   None
>>>> 
>>>> This document describes a protocol for supporting Mobile
>>>> Networks between a Mobile Router and a Home Agent by extending
>>>> the Mobile IPv4 protocol.  A Mobile Router is responsible for
>>>> the mobility of one or more network segments or subnets moving
>>>> together.  The Mobile Router hides its mobility from the nodes
>>>> on the Mobile Network.  The nodes on the Mobile Network may be
>>>> fixed in relationship to the Mobile Router and may not have any
>>>> mobility function.
>>>> 
>>>> Extensions to Mobile IPv4 are introduced to support Mobile
>>>> Networks. [STANDARDS TRACK]
>>>> 
>>>> This document is a product of the Mobility for IPv4 Working
>>>> Group of
>> the IETF.
>>>> STANDARDS TRACK: This document specifies an Internet standards
>>>> track protocol for the Internet community,and requests
>>>> discussion and
>> suggestions
>>>> for improvements.  Please refer to the current edition of the
>>>> Internet Official Protocol Standards (STD 1) for the
>>>> standardization state and status of this protocol.
>>>> Distribution of this memo is unlimited.
>>>> 
>>>> This announcement is sent to the IETF list and the RFC-DIST
>>>> list. Requests to be added to or deleted from the IETF
>>>> distribution list should be sent to [email-masked].
>>>> Requests to be added to or deleted from the RFC-DIST
>>>> distribution list should be sent to
>>>> [email-masked].
>>>> 
>>>> Details on obtaining RFCs via FTP or EMAIL may be obtained by
>>>> sending an EMAIL message to [email-masked] with the
>>>> message body
>>>> 
>>>> To: [email-masked] Subject: getting rfcs
>>>> 
>>>> help: ways_to_get_rfcs
>>>> 
>>>> Requests for special distribution should be addressed to either
>>>> the author of the RFC in question, or to
>>>> [email-masked].
>> Unless
>>>> specifically noted otherwise on the RFC itself, all RFCs are
>>>> for unlimited distribution.
>>>> 
>>>> [email-masked].  Please consult RFC 2223,
>>>> Instructions to
>> RFC
>>>> The RFC Editor Team USC/Information Sciences Institute
>>>> 
>>>> ...
>>>> 
>>>> 
>>>> _______________________________________________ IETF-Announce
>>>> mailing list [email-masked] 
>>  This email has been scanned by the MessageLabs Email Security
>> System. For more information please visit
>> http://www.messagelabs.com/email

---

From: "George Tsirtsis" <[email-masked]>
Date: Thu, 24 Apr 2008 11:31:47 +0100

> three-party communication and very much prone to risks.
GT> What I do not see is any threats different from what regular
MIPv4-FA mode offers. Section 5.4 indicates that if the MN uses
colocated mode, then the FA (even if it sets the R flag in the FAA)
must not include a tunneling extension. If the MN uses the FA mode,
however, it is of course up to the FA to decide to terminate handle
IPv6 packets or not. I do not see a problem with that,

>  Thinking about this.  I think the doc has no other figure.  Section 3.1 is
> way too short and compressed.  I need to mentally picture those tunnels to
> understand it.  If I had figures in 3.1 my reading would be eased.  Maybe
> I'll provide some figures later.
>

GT> That would be good. Thanks.

> eg
> offered.
> > > > >  This document is a product of the Mobility for IPv4 Working Group
> of
> > > > >
> > > >
> > > the IETF.
> > >
> > > >
> track
> > > > >  protocol for the Internet community,and requests discussion and
> > > > >
> > > >
> > > suggestions
> > >
> > > >
> Internet
> sending
> > > > >  author of the RFC in question, or to [email-masked].
> > > > >
> > > >
> > > Unless
> > >
> > > >
> > > > >  [email-masked].  Please consult RFC 2223, Instructions
> to
> > > > >
> > > >
> > > RFC
> > >
> > > >

---

From: Alexandru Petrescu <[email-masked]>
Date: Fri, 25 Apr 2008 23:31:21 +0200

George Tsirtsis wrote:
[...]
> puts together some relevant figures I would be ok with including them

George, some figures are ready, but please clarify me some things first.

When the FA CoA model is used, and no nemov4-fa optimizations, and MR
attached to FA, does a packet's header captured on the link from HA to
FA, packet originally sent from CN to LFN, look like this?

                             src= HA@
                             dst= FA@________________(1)
                             src= HA@
                             dst= MR's HoA___________(2)
                             src= CN@
                             dst= LFN@

Do we call this model a "Foreign Agent Care-of Address" model instead of
a "Care-of Address" model? (section 3.1 ambiguously says "When the
co-located care-of address model is used [vs] When the care-of address
model is used")?

Do we expect a Modified IP Header and a Minimal Forwarding Header (RFC
2004 "Minimal Encapsulation withn IP"), or a GRE Header (RFC 2784
"Generic Routing Encapsulation"), anywhere at points (1) or (2) above?
Or do we assume always IP-in-IP encapsulation (RFC 2003 "IP
Encapsulation within IP").

Alex

>> Technically, I think there's need of some more syncing on FA-NEMO 
>> docs, eg citing numbers already allocated, ordering between 
>> different mobile network extensions, and maybe other things.  The 
>> Sec section could say how new risks are introduced by th 
>> etunnelling extension and how protection is offered. 3.1 background
>>  could picture a figure or two of tunnels.  Just some thoughts...
>> 
>> Alex
>> 
>> 
>> 
>> 
>>> 
>>> Regards George
>>> 
>>>>  fixed in relationship to the Mobile Router and may not have
>>>> any mobility function.
>>>> 
>>>> standardization state and status of this protocol. Distribution
>>>>  of this memo is unlimited.
>>>>

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 28 Apr 2008 09:20:21 +0100

Hi Alex,

inline...

On Fri, Apr 25, 2008 at 10:31 PM, Alexandru Petrescu
<[email-masked]> wrote:
> George Tsirtsis wrote:
>  [...]
>
>
> > - not sure I see a reason to do more figures, but if you or someone puts
> together some relevant figures I would be ok with including them
> >  in the draft.
> >
>

GT> The above shows a "care-of address" model (aka "FA" model).
colocated care-of address model is the one where the MN has a unique
care-of addresses, as opposed to a shared on, and I think this is
standard MIPv4 terminology.

>  Encapsulation within IP").

GT> All the encapsulations are negotiated as part of RFC3344, which
should fully apply in this case for point (1). (2) is just IP in IP as
per NEMO.

> network extensions, and maybe other things.  The Sec section could say how
> new risks are introduced by th etunnelling extension and how protection is
> offered. 3.1 background
> Author:     K. Leung, G. Dommety, V. Narayanan, A. Petrescu Status:
> Standards Track Date:       April 2008 Mailbox: [email-masked],
> [email-masked], [email-masked], [email-masked]
> Pages:      26 Characters: 56094 Updates/Obsoletes/SeeAlso:   None
> > > > >
> between a Mobile Router and a Home Agent by extending
> > > > > This document is a product of the Mobility for IPv4 Working Group of
> > > > >
> > > >
> > > the IETF.
> > >
> > > >
> > > > >  track protocol for the Internet community,and requests discussion
> and
> > > > >
> > > >
> > > suggestions
> > >
> > > >
> Internet Official Protocol Standards (STD 1) for the standardization state
> and status of this protocol. Distribution
> Requests to be added to or deleted from the IETF distribution list should be
> sent to [email-masked]. Requests to be added to or deleted from the
> RFC-DIST distribution list should be sent to
> sending an EMAIL message to [email-masked] with the message body
> > > > >
> [email-masked].  Please consult RFC 2223, Instructions to
> > > > >
> > > >
> > > RFC
> > >
> > > >

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 28 Apr 2008 10:37:08 +0200

> standard MIPv4 terminology.

Not sure which RFC one is thinking about when invoking "care-of address 
model" but RFC3344 seems to mention "Foreign Agent Care-of Address mode" 
vs "Co-located Care-of Address mode", page 11.

RFC3344 doesn't seem to mention shared address, nor models.

What am I missing?

> should fully apply in this case for point (1). (2) is just IP in IP as

Ok.

Alex

---

From: "George Tsirtsis" <[email-masked]>
Date: Mon, 28 Apr 2008 10:02:38 +0100

You are missing nothing :-)
 I will align the terminology better when I incorporate your figures
in the draft.

Thanks
George

On Mon, Apr 28, 2008 at 9:37 AM, Alexandru Petrescu
<[email-masked]> wrote:
> puts
> model" but RFC3344 seems to mention "Foreign Agent Care-of Address mode" vs
> "Co-located Care-of Address mode", page 11.
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 28 Apr 2008 15:34:13 +0200

>>>  "Generic Routing Encapsulation"), anywhere at points (1) or (2)
>>> above? Or do we assume always IP-in-IP encapsulation (RFC 2003
>>> "IP Encapsulation within IP").
>>> 
> 
> should fully apply in this case for point (1). (2) is just IP in IP
> as per NEMO.

In the figures below I assumed only IP-in-IP encapsulation (bits M and G 
are zero).  But if G is 1 - will NTE remove GRE header?

George Tsirtsis wrote:
> You are missing nothing :-) I will align the terminology better when
> I incorporate your figures in the draft.

LEt's talk the figures below.

Is this draft _only_ for FA CoA mode?  I'd suppose yes, but it says
"Extensions defined in this document allow the mobile node and/or a
foreign agent to indicate to the home agent".

Can the MR send a RegReq with a NEMOv4 Tunneling Extension when it
attaches to a FA?  To whom does it send it?

Could NEMOv4-enabled FA send a Registration Reply containing a NEMOv4
Tunnelling Extension?  To whom does it send it?

Sorry, these may be basic 3344 things that I'm not clear.  The figures 
below are only approximative and need to be more precise.  Shall I 
remove the exchange where FA originates RegRep?

Alex

   RFC3344/RFC5177 doing FA-CoA mode       This draft doing FA-CoA mode
                                       (NTE: NEMOv4 Tunnelling Extension)

     LFN MR  FA             HA  CN        LFN MR  FA             HA  CN
      |  |   |    RegReq    |   |          |  |   | RegReq NTE    |   |
      |  |   |------------->|   |          |  |   |------------->|   |
      |  |   |              |   |          |  |   |              |   |
      |  |   |    RegRep    |   |          |  |   | RegRep NTE   |   |
      |  |   |<-------------|   |          |  |   |<-------------|   |
      |  |   |              |   |          |  |   |              |   |

            OR                                        OR

      |  |   |              |   |          |  |   |              |   |
      |  | RegReq           |   |          |  | RegReq  NTE      |   |
      |  |-->|------------->|   |          |  |-->|------------->|   |
      |  |   |              |   |          |  |   |              |   |
      |  | RegRep           |   |          |  | RegRep  NTE      |   |
      |  |<--|<-------------|   |          |  |<--|<-------------|   |
      |  |   |              |   |          |  |   |              |   |
      |  |   |              |   |          |  |   |              |   |

              --------------
          ---/             /-\                    ----------------
       __/_ ( _ _ _ _ _ _ (_/_)__           _____/ _ _ _ _ _ _  _/_\__
         \  (             ( \ )                  \               \ /
          ---\             \-/                    ----------------
              --------------

     Application packet  RegReq           Application packet  RegReq
     header from CN to   captured         header from CN to   captured
     LFN, captured on    on HA-FA         LFN, captured on    on HA-FA
     HA-FA link          link             HA-FA link          link
     ------------------  ---------        ------------------  ---------
     src= HA@            src= FA@         src= HA@            src= FA@
     dst= FA@            dst= HA@         dst= FA@            dst= HA@
     src= HA@            UDP header       src= CN@            UDP header
     dst= MR's HoA                        dst= LFN@
     src= CN@                             Payload
     dst= LFN@
     Payload

[tunnel graphs Thubert-inspired]