Subject: [nemo] issue xxx: requirements chapter for Nemo.

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 2 Dec 2003 16:13:30 -0000

Hi: 

I understand from the discussion with Jari that we could (should) open
an issue regarding the equivalent of [MIPv6] chapter 8, that appears to
be missing from basic nemo.

Here's my view of what that text could be (largely inheriting from
[MIPv6]). What do you think?

8. Requirements for Types of IPv6 Nodes

   Basic Nemo extends the requirements placed by Mobile IPv6 on the 
   functions provided by different types of IPv6 nodes.  This section
   summarizes those requirements, identifying the functionality each 
   requirement is intended to support. Note that the category 'mobile
node'
   that is used in [MIPv6] really applies to mobile hosts and excludes 
   mobile routers which are placed in a separate category.

   The requirements are set for the following groups of nodes:

   o  All IPv6 nodes.

   o  All IPv6 nodes with support for route optimization.

   o  All IPv6 routers.

   o  All Mobile IPv6 home agents.

   o  All Mobile IPv6 mobile nodes.

   o  All Mobile IPv6 mobile routers.

   It is outside the scope of this specification to specify which of
   these groups are mandatory in IPv6.  We only describe what is
   mandatory for a router that supports network mobility.
   Other specifications are expected to define the extent of IPv6.

8.1 All IPv6 Nodes

   There are no Basic Nemo specific MUST requirements for such nodes, 
   and basic IPv6 techniques are sufficient.

8.2 IPv6 Nodes with Support for [MIPv6] Route Optimization

   Basic Nemo does not introduce a specific route optimization for
Mobile
   Networks. If a Mobile Router acts as a [MIPv6] Mobile Node, the Route

   Optimization follows the [MIPv6] rules with the same requirements no
the
   Correspondents. The Mobility of a Network is transparent to the
Visiting
   Mobile Nodes and does not create any additional requirement on the 
   Correspondent.

8.3 All IPv6 Routers

   Basic Nemo uses the movement detection mechanisms as described in
[MIPv6], 
   and places the same requirements on all routers as [MIPv6] does.

8.4 IPv6 Home Agents

   A Nemo Home Agent extends the feature set of a Mobile IPv6 HA. As
such, 
   It MUST support all the features described in [MIPv6] chapter 8.4.
and 
   process [MIPv6] messages per the [MIPv6] specification for all Mobile
Nodes.

   On top of that, the following additional requirements apply to all
[MIPv6] 
   Home Agents in order to serve as a Nemo Home Agent:

   o  Every home agent MUST recognize the mobility messages associated
to 
      mobile routers and support both the implicit and explicit prefix
modes.
      A home agent MAY optionally support an other routing protocol over
the
	MRHA tunnel.

   o  Every home agent MUST support establishing and tearing down a
bidirectional 
      tunnel to a mobile router careOF address. 

   o  Every home agent MUST support setting the forwarding states
proactively (static routes) 	or reactively (upon registration) in
order to route packets to the registered prefixes, 	via the mobile
router home address or over the tunnel.

   o  Every home agent MUST be able to authorize the registrations in
explicit prefix mode               	prior to installing the
associated forwarding states.

   o  Every home agent MUST fully support IPv6 tunneling [RFC2473] for
MRHA tunnel. 
	For packets sent received from a mobile router's careOf address,
every home
      agent MUST check that the inner packet is topologically correct.

   o  Every home agent MUST be able to return a Binding Acknowledgement
      in response to a Binding Update (Section 10.3.1).

   o  Every home agent MUST maintain a separate Home Agents List for
      each link on which it is serving as a home agent, as described in
      [MIPv6] Section 10.1 and 10.5.1, and in Section 7.

   o  Every home agent SHOULD be able to intercept packets (using proxy
      Neighbor Discovery [RFC2461]) addressed to a node on a mobile
network
      Associated with a mobile router for which it has an active binding
	on that mobile router's home Link. 
      (note: This is used in the aggregated physical Home Net only, thus

       the SHOULD)

   o  Every home agent performing that interception MUST be able 
	to encapsulate [RFC2473] such intercepted packets in order to
tunnel 
      them to the primary care-of address for the mobile router for
which 
      the forwarding states are established.

8.5 IPv6 Mobile Nodes

	Basic Nemo is transparent to the activity of MIPv6 Mobile Nodes
and
      does not require any specific support from those.  

8.6 IPv6 Mobile Routers

   Finally, the following requirements apply to all IPv6 routers capable
   of functioning as mobile routers:

   o  The router MUST comply with the MIPv6 requirements on all nodes
and 
      on all routers ([MIPv6] Sections 8.1 and 8.3). It MAY comply with 
	section 8.2 as well. 

   o  The router MUST support establishing and tearing down a
bidirectional 
      tunnel to its Home Agent and a default route over that tunnel. 
      It MUST support forwarding packets between that tunnel and the
Mobile Networks. 

   o  The router MUST support at least one of the 2 modes, implicit or
explicit prefix,
      for its Home registration as a mobile router. It SHOULD support
both. It MAY support
      additional routing protocols over the MRHA tunnel.
 
   o  The router MUST support sending packets containing a Home Address
      option ([MIPv6] Section 11.3.1), and follow the required IPsec
interaction
      ([MIPv6] Section 11.3.2).

   o  The router MUST fully support [RFC2473]. As such, it MUST be able
to 
      perform IPv6 encapsulation and decapsulation, ICMP forwarding and
PMTU
      discovery.

   o  The router MUST be able to process type 2 routing header as
defined
      in [MIPv6] Section 6.4 and Section 11.3.3.

   o  The router MUST support receiving a Binding Error message ([MIPv6]
Section
      11.3.6).

   o  The router MUST support receiving ICMP errors ([MIPv6] Section
11.3.5).

   o  The router MUST support movement detection, care-of address
      formation. It MAY also support returning home.

   o  The router MUST be able to process Mobility Headers as described
in
      [MIPv6] and Section 5.

   o  The router MUST be able to send Binding Updates, as specified in 
	Section 5.2.

   o  The router MUST be able to receive and process Binding
      Acknowledgements, as specified in Section 5.3.

   o  The router MUST support receiving a Binding Refresh Request
([MIPv6] 
	Section 6.1.2), by responding with a Binding Update (section
5.2).

   o  The router SHOULD support use of the dynamic home agent address
      discovery mechanism, as described in Section 7.

   ?  The router MAY support receiving Mobile Prefix Advertisements
      (Section 11.4.3) and reconfiguring its home address based on the
      prefix information contained therein.

   o  The router MAY support stateful address autoconfiguration
mechanisms
      such as DHCPv6 [29] on the interface represented by the tunnel to
      the home agent.

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Wed, 3 Dec 2003 09:52:46 -0000

My text looks ugly, I must agree on that. It's more like an initial dump to be filtered out.  

The key is that basic nemo has dependencies, and at the moment they are implicit, thus Jari's comment on the deps on MIPv6. On top of MIPv6, we have dependencies on several RFCs like IPv6 spec, nd, autoconf, dhcpv6, tunnels. Most MUST be fully implemented, but it's not the case of MIPv6. I agree with Jari that there's a need to say so. Maybe it takes much less text then I actually used.

Something like:

Dependencies:
-------------
Basic Nemo MRs MUST implement this specification, [MIPv6] chapter 8.1 and 8.3, and RFCs 2460, 2461, 2462, 2463 and 2473.
Basic Nemo MRs MAY implement [MIPv6] chapter 8.2 and 8.5, and RFC 3041.
Basic Nemo HAs MUST fully implement this specification, [MIPv6] chapter 8.1, 8.3 and 8.4,  and RFCs 2460, 2461, 2462, 2463 and 2473.

> -----Original Message-----
> From: T.J. Kniveton [mailto:[email-masked]]
> Sent: mercredi 3 décembre 2003 02:10
> To: Pascal Thubert (pthubert)
> Cc: [email-masked]
> Subject: Re: [nemo] Re: issue xxx: requirements chapter for Nemo.
> 
> Question: Is there a specific complaint, or reason why the current spec
> does not adequately spell out the requirements of nodes to operate with
> NEMO? It seems like it's not too hard to see or figure out. I'd like to
> avoid making the draft longer than necessary.. best to keep it simpler
> if adequate.
> 
> tj