Subject: changes to the network management section in node requirements

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Aug 2010 16:49:11 +0200

Hi,

I like to suggest some changes to section 12 "Network Management" of
<http://tools.ietf.org/html/draft-ietf-6man-node-req-bis-05>.

---

OLD

   Network Management MAY be supported by IPv6 nodes.  However, for IPv6
   nodes that are embedded devices, network management may be the only
   possible way of controlling these nodes.

NEW

   IPv6 nodes may support network management via the Simple Network
   Management Protocol version 3 (SNMPv3) [RFC3411].  For IPv6 nodes
   that are embedded devices, network management via SNMPv3 may be the
   only possible way of controlling these nodes.

Rationale:

   I think it is important to provide a explicit references to SNMPv3
   to make it clear that SNMPv3 is the SNMP version to be implemented.

---

OLD

   IP Forwarding Table MIB [RFC4292] SHOULD be supported by nodes that
   support an SNMP agent.

NEW

   The IP-FORWARD-MIB module [RFC4292] SHOULD be supported by nodes that
   support an SNMP agent.

Rationale

   I believe it is clearer to list the MIB module name instead of a
   paraphrase of the respective RFC title.

---

OLD

   IP MIB [RFC4293] SHOULD be supported by nodes that support an SNMP
   agent.

NEW

   The IP-MIB module [RFC4293] SHOULD be supported by nodes that
   support an SNMP agent. Implementation of the IPv6-MIB module
   [RFC2465] is only recommended for backward compatibility reasons
   since [RFC2465] has been obsoleted by [RFC4293].

Rationale:

   I believe it is clearer to list the MIB module name instead of a
   paraphrase of the respective RFC title. The second sentence should
   take care of ongoing confusion where people think they should
   implement the IPV6-MIB module for IPv6 nodes.

---

/js

-- 
Juergen Schoenwaelder           Jacobs University Bremen gGmbH
Phone: +49 421 200 3587         Campus Ring 1, 28759 Bremen, Germany
Fax:   +49 421 200 3103         <http://www.jacobs-university.de/>

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 20 Aug 2010 08:22:00 -0700

Couple of comments on Section 9.0 (Mobility): draft-ietf-6man-node-req-bis-05

1.) When Mobile IPv6 was designed, one important feature that made into the protocol is the support for Route Optimization. The ability for a mobile node to provide the information on the direct (non-anchor or non-triangular) path to a Correspondent Node. This was not possible in Mobile IPv4, as any change requirement to IPv4 did not make much sense. This is one feature of Mobile IPv6 that stands out. The semantics of RO, say Type-II RH, is part of the basic IPv6 feature. Most IPv6 stacks have support for these options and in most cases the RO procedure as well. Given this,  It is very important that the IPv6 Correspondent Node functionality is mandated on every IPv6 node. However, the Home Agent functionality on IPv6 routers, or the Mobile Node stack on a IPv6 node, can be optional, that is fine. But, its important that the end-points has natural RO support.

2.) I'd additionally remove the comments around lack of deployment experience around the protocol. This comment applies to practically every IPv6 feature, SEND or other extensions.  In fact with Mobile IPv4 being a core mobility protocol in CDMA, we probably have bit more related experience on the node requirements from IPv6 node perspective.

3.) Section 9.0 should be reviewed by MEXT, NETLMM and NETEXT working groups, so the node requirements with respect to IP Mobility are properly presented.

Regards
Sri

---

From: Ed Jankiewicz <[email-masked]>
Date: Fri, 20 Aug 2010 14:24:46 -0400

Sri - I agree with all of your comments including the statement that 
RO is a key feature of MIPv6. I would add a caveat that there is not 
much incentive for a large scale server to implement RO, as it benefits 
the mobile node user rather than the application or the hosting service. 
It seems RO in that case might be a "value-add" that services pitched at 
mobile end-users might advertise as advantageous. In several 
conversations with vendors, there is resistance to the idea of making RO 
mandatory for all hosts.

Remembering that by SHOULD we mean YOU REALLY SHOULD. REALLY. WE MEAN 
IT! (Unless you have a very good reason not to) which is every so 
slightly less imperative than MUST, can we avoid the SHOULD/MUST 
argument by keeping it as SHOULD but adding some strong language 
reiterating the importance of RO and the market value of having it?

For example, in the US DoD IPv6 Profiles document the following language 
has been included at least the last couple of annual revisions, 
attempting to address this issue. Maybe some of this text would help. 
Full disclosure: I am an editor on the cited document, and the wording 
on misalignment of incentive comes from prior discussions with Thomas 
Narten on the subject.

"Any IPv6 Capable Node can interoperate with a MIPv6 Mobile Node as a 
Correspondent Node as stated in Section 8.1 of RFC 3775 (no additional 
functionality is required). MIPv6 includes a feature called “Route 
Optimization” which increases the efficiency of packet routing between a 
Mobile Node and Correspondent Node. An IPv6 Capable Node to be deployed 
where MIPv6 is prevalent SHOULD support Route Optimization as defined in 
RFC 3775.

Route Optimization presents some unique challenges. There is a 
misalignment of incentive – for RO to be effective it must be widely 
implemented by the Correspondent Nodes including general purpose servers 
for which it provides no benefit. RO certainly would provide performance 
enhancement for a geographically dispersed enterprise, where it would 
eliminate triangular routing of packets to a home network when the MN 
was visiting a location where the enterprise maintained corporate 
servers. While it would be helpful for general servers to support RO, 
due to current lack of MIPv6 deployments and the small benefit it does 
not make sense to require RO for servers at this time.

RO raises some security concerns, especially in deployments where it 
would be undesirable to reveal the location of a travelling MIPv6 MN. At 
least an approximate location can be derived from IPv6 prefix of the 
network where the MN is operating. In those cases, it would be better to 
disable RO in the MN and rely on the Home Agent to conceal the current 
location of the MN."

On 8/20/2010 11:22 AM, Sri Gundavelli wrote:
> --------------------------------------------------------------------
> IETF IPv6 working group mailing list
> [email-masked]
> Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
> --------------------------------------------------------------------

---

From: Thomas Narten <[email-masked]>
Date: Fri, 20 Aug 2010 14:47:03 -0400

> 1.) When Mobile IPv6 was designed, one important feature that made
>  into the protocol is the support for Route Optimization. The
>  ability for a mobile node to provide the information on the direct
>  (non-anchor or non-triangular) path to a Correspondent Node. This
>  was not possible in Mobile IPv4, as any change requirement to IPv4
>  did not make much sense.

Actually, this explanation is not consistent with history. RO was not
added to MIP4 because there was no customer for the work. MIP has been
implemented and deployed in IPv4. But those using it had no need for
and didn't seem to have a business case for RO. There was an ID for RO
for MIP4 at one time, but the WG abandoned the draft when it became
clear no one had interest in actually deploying it.

I think this point is very much worth noting. We can jump up and down
all day and say some feature is really cool and beneficial, but what
really matters is whether someone will actually deploy and use it,
based on the value they see.

Also, deploying MIP is much more complicated than deploying other IPv6
protocol features. You need an HA and associated AAA
infrastucture. This is just for base MIP, without even getting to RO.

To date, I am not aware of any plans to deploy MIPv6. Sure, one can
argue that we have to get IPv6 deployed first, and then folk will use
MIPv6 as well, but I think that is also simplistic thinking. I believe
deploying and using MIPv6 (and the RO functionality specifically) is
still something we lack significant experience with. 

>  This is one feature of Mobile IPv6 that stands out.

Yes. But only for those who think MIPv6 is something they want to
use.

I think the IPv4 experience with MIPv4 suggests that there are target
scenarios where MIP technology is quite useful, but at the same time,
there is no broad general need for MIP. The vast majority of the
Internet seems to be doing Just Fine without using MIP.

> The semantics of RO, say Type-II RH, is part of the basic IPv6
> feature. Most IPv6 stacks have support for these options and in most
> cases the RO procedure as well. Given this, It is very important
> that the IPv6 Correspondent Node functionality is mandated on every
> IPv6 node. However, the Home Agent functionality on IPv6 routers, or
> the Mobile Node stack on a IPv6 node, can be optional, that is
> fine. But, its important that the end-points has natural RO support.

I'm strongly opposed to mandating CN support for RO on general purpose
nodes (clients and servers) until:

a) we have significant experience with the technology showing that it
works in practice (i.e, in significant operational deployments), and

b) there is a more realistic sense that the technology would actually
get used, if it were available.

MIP appears to (possibly) be a "nice to have" feature. But it is not a
critical part of IPv6.  It is not the job of the IETF to broadly
mandate functionality that is not clearly necessary.

> 2.) I'd additionally remove the comments around lack of deployment
>  experience around the protocol. This comment applies to practically
>  every IPv6 feature, SEND or other extensions.  In fact with Mobile
>  IPv4 being a core mobility protocol in CDMA, we probably have bit
>  more related experience on the node requirements from IPv6 node
>  perspective.

We do not have experience with the RO part of MIP. that is new not
only to IPv6, but to IP overall.

SEND is also (IMO) not something we can recommend. We need more real
deployment/usage experience with it before it is appropriate to
mandate it.

Indeed, per previous discussions on this list, SEND is listed only as
a MAY in the current node requirements ID.

Thomas

---

From: <[email-masked]>
Date: Fri, 20 Aug 2010 21:03:28 +0200

On 8/20/10 1:47 PM, "Thomas Narten" <[email-masked]> wrote:

> To date, I am not aware of any plans to deploy MIPv6.

3GPP has specified the use of DSMIP6 on the S2c reference point in Rel8. And
there do exist some plans to deploy and use DSMIP6. (Note DSMIP6 and not
just MIP6). There do exist implementations and some unadvertised trials.

> Sure, one can

I tend to agree with Thomas' comments here... At least the point about RO.
There is no experience with RO and there has not been an overarching demand
for RO. 
Lack of RO and the fact that the MN is anchored at an HA (which could be
quite distant from the point of attachment) has resulted in other solutions
being developed, the most relevant one being the dynamic assignment of an
HA. The MN is assigned an HA based on its current point-of-attachment and
this alleviates some of the concerns that arise from being anchored.

I am also of the opinion that MIP6 by itself is difficult to deploy given
the lack of IPv6 only networks. And what we see is that there will be IPv4,
IPv6 and dual-stack networks out there. Hence DSMIP6 is the only pragmatic
IP mobility solution since it works over any type of access.

I would actually go so far as to recommend that the node-requirements
mobility section substitute the MIP6 RFCs with DSMIP6 (RFC5555).

>>  This is one feature of Mobile IPv6 that stands out.

While the RO is a nice feature of MIP6, its usefulness and need is only as
good as implementations and people asking for it. That is not the case at
the present time. 

> Internet seems to be doing Just Fine without using MIP.

There are some applications that would benefit from MIP and we will probably
see the use-cases and need for it. It is possible to solve the mobility
problem at different layers. However the IP layer mobility solution enabled
by MIP is one of the better ways (YMMV).

> get used, if it were available.

I would agree with Thomas' comments and would support not-mandating RO in
every CN for now. 

As an FYI, we are implementing RO in our DSMIP6-TLS implementation and
possibly demoing it by IETF79.

> mandate functionality that is not clearly necessary.

MIP6 lost its way during the development of IPv6 and hence is not an
integral part of the IPv6 stack today. That is just an unfortunate state
that we find ourselves today. But obviously the need for such functionality
has also been lacking.

> a MAY in the current node requirements ID.

Agree. 

-Raj

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Aug 2010 12:23:46 -0700

Did someone say Route Optimization? Here is a new routing,
addressing and mobility architecture that addresses it:

http://tools.ietf.org/html/draft-templin-iron-10

This is the Internet Routing Overlay Network (IRON). Route
Optimization is only one feature among many that makes IRON
a comprehensive solution for the Internet going forward.

Fred
[email-masked]

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of [email-masked]
> Sent: Friday, August 20, 2010 12:03 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: Re: Comments on Section 9.0 (Mobility) -draft-ietf-6man-node-req-bis-05
> 
> 
> 
> 
>

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Aug 2010 12:30:35 -0700

To add to this, RFC5522 makes the case for a route optimization
solution for civil aviation and space exploration.

Fred
[email-masked]

> From: [email-masked] [mailto:[email-masked]] On Behalf Of Templin, Fred L
> Sent: Friday, August 20, 2010 12:24 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]
> Subject: RE: Comments on Section 9.0 (Mobility)-draft-ietf-6man-node-req-bis-05
>

---

From: <[email-masked]>
Date: Fri, 20 Aug 2010 21:40:15 +0200

Fred,

We are discussing IPv6 node-requirements and considering specifications that
are standards-track RFCs. There is no point in throwing out specs that are
individual I-Ds at this time (at least in the context of this discussion).

-Raj

---

From: "Templin, Fred L" <[email-masked]>
Date: Fri, 20 Aug 2010 12:48:19 -0700

Raj,

IRON represents a new mobility architecture that has not been
discussed here before, and it is different from MIP in many ways.
IRON is currently in WGLC in the Routing Research Group, where it
was developed with guidance from wg participants.

Fred

> From: [email-masked] [mailto:[email-masked]]
> Sent: Friday, August 20, 2010 12:40 PM
> To: Templin, Fred L; [email-masked]; [email-masked]
> Cc: [email-masked]

---

From: Thomas Narten <[email-masked]>
Date: Fri, 20 Aug 2010 15:59:12 -0400

Hi Juergen.

Thanks for bringing up this topic!

>    to make it clear that SNMPv3 is the SNMP version to be

I'm fine with the reference to SNMPv3.

But, is that last sentence really accurate? Are embedded devices
typically or normally managed via SNMP?

And is there even a generally accepted definition of what an embedded
device is? Is it the same as, say, a network appliance?

>    paraphrase of the respective RFC title.

Agreed.

But thinking a bit, should we even go so far as saying SHOULD for the
two above MIBs when SNMP is implemented?

The reason I ask is that a year or two ago, when I looked into the
question of what MIBs to implement for hosts, my conclusion was that
MIBs aren't really used in the host/server space much. They are
clearly used for monitoring (but not necessarily configuration) in
routers.

I guess I'm asking should we give the same recomendation for all
devices, or should the recommendation for routers be different from
that of hosts?

>    implement the IPV6-MIB module for IPv6 nodes.

Agreed.

Thomas

---

From: Behcet Sarikaya <[email-masked]>
Date: Fri, 20 Aug 2010 13:48:38 -0700 (PDT)

Hi Thomas,

> Internet seems to be doing Just Fine without using MIP.

I disagree with this.
Maybe not MIPv6 itself but mobility protocols make up an important part of 
mobile phone technologies and they are heavily used.

> mandate functionality  that is not clearly necessary.

Again, I disagree. 
Right now IPv6 itself does not look that attractive to the operators because 
there is no business case for it.
IETF has developed sophisticated mobility protocols like MIPv6 that IETF should 
promote as part of promoting IPv6 saying that only with IPv6 you get all that is 
offered by MIPv6 including RO.
 I saw some slides online to this effect and applaud such efforts.

As Raj said you can use techniques like dynamic HA allocation to reduce the need 
for RO in managed networks but in other cases RO is good to mandate, IMHO.

Regards,

Behcet

---

From: Juergen Schoenwaelder <[email-masked]>
Date: Fri, 20 Aug 2010 22:53:48 +0200

> device is? Is it the same as, say, a network appliance?

The sentence in question was there before - I just removed the
'However'. Since the sentence neither uses 'typically' nor 'normally',
I am not sure I understand your first question. If your proposal
behind your questions is to remove the sentence, I would not object.
 
> two above MIBs when SNMP is implemented?

Two? You include the IP-MIB in the following comment as well?

> devices, or should the recommendation for routers be different from

The question is whether we expect network management applications to
look at IP forwarding tables of hosts or not. I do not have a good
answer for this. The ipForwardReadOnlyCompliance allows read-only
implementations so monitoring vs. configuration is not an issue I
think. We could even be more explicit and state that explicitly by
refering to the compliance statement.

I believe the IP-MIB with read-only compliance SHOULD be on every node
that can afford it. On not resource constrained systems, I do not
recall having seen an SNMP agent that does not implement the old
IP-MIB plus the old IP-FORWARDING-MIB. My feeling is that if IPv4
nodes support SNMP, they do support the basic MIB modules we have.

/js

---

From: Sri Gundavelli <[email-masked]>
Date: Fri, 20 Aug 2010 14:06:17 -0700

Hi Thomas/Ed:

(I was not really expecting Thomas to respond to this thread, I want support from folks :), now they are gone).

1. We don't have any experience with MIPv6 RO, I agree. But, if we don't enable this function in every IPv6 node, we will never ever have the opportunity to turn this feature on. Mobile IPv6 is the only global mobility protocol, that we have standardized in IETF, ignoring PMIPv6 which is a local mobility protocol. When MIPv6 was designed (when you were the AD), it was always viewed a base feature of IPv6. The choice of MH, as supposed to using a transport layer ports, or the support for RO, was inline with that thinking.
  
2. When Mobile IPv4 was specified in 90's and even after CDMA adopted the protocol, there was always a comment on the lack of RO support. This is a protocol that suffered from "triangular routing", at least the perception, if anchoring is the right model and if operators liked it, is another topic. But, we never had the capability to support that feature in IPv4,  we can specify a solution for MIPv4 RO, but any solution that requires a change in every IPv4 node in the internet, implies the feature is useless. We have an opportunity here to make that change here.

3. I can understand that we have to be careful what we mandate in the node requirements document. If feature-x makes sense, useful, easy to implement, inline with Internet architectural direction. This protocol is specified, analyzed, implemented and studied in universities for number of years . Most Linux/BSD kernels have support Type-II RH, I remember some Linux distributions have included the RO feature by default. Its not a whole lot of code, or complexity that one needs to deal with. Its matter of including that package in all distributions. Making that mandatory.

4. On the comments related to deployments, the specs are referenced in various SDO interfaces. There are implementations (I cant speak for a vendor), but from what I believe, .Ex: Qualcomm LTE chipsets will have the MIPv6 stack. 

My point is that we have a good opportunity to make this a requirement of every IPv6 node (if we believe in the feature), else, even if we get all the experience with the RO approach, we can't do any thing 5 years from now, once there is massive roll out of IPv6 nodes.

I really hope we can add bit more text here to encourage, or include that feature.  I don't know how this work will be tied to the, Federal IPv6 Requirements spec, on all the different classifications and where this fits. I'm only hoping to see a better classification than the current "Optional". "No experience", type coloring.

Regards
Sri

---

From: Thomas Narten <[email-masked]>
Date: Fri, 20 Aug 2010 17:21:44 -0400

> (I was not really expecting Thomas to respond to this thread, I want
>  support from folks :), now they are gone).

> 1. We don't have any experience with MIPv6 RO, I agree. But, if we
>    don't enable this function in every IPv6 node, we will never ever
>    have the opportunity to turn this feature on. Mobile IPv6 is the
>    only global mobility protocol, that we have standardized in IETF,
>    ignoring PMIPv6 which is a local mobility protocol. When MIPv6
>    was designed (when you were the AD), it was always viewed a base
>    feature of IPv6. The choice of MH, as supposed to using a
>    transport layer ports, or the support for RO, was inline with
>    that thinking.

I've been around the IETF a pretty long time, and at one point, I was
also pretty sympathetic to the idea that if we require something, it
would prod industry in a positive direction.

Having been burned by many non-deployments, I recognize the limits to
this approach and am now much more cautious.

As the classic example, think about security. We used to think If we
just require strong security in our specs, great things will happen. I
think it's pretty safe to say that we have a pretty uneven record here
(at best). We even seem to have come to the (surprising!) agreement
that we should downgrade the requirement of IPsec in every node to a
SHOULD. Requiring IPsec just hasn't resulted in IPsec being widely
deployed (other than in VPNs) and hasn't resulted in it being used as
the security technology of choice.

Please carefully re-read Raj's posting. MIPv6 doesn't even appear to
be the right mobility technology to recommend these days. That pretty
much says it all...

> 2. When Mobile IPv4 was specified in 90's and even after CDMA
>    adopted the protocol, there was always a comment on the lack of
>    RO support. This is a protocol that suffered from "triangular
>    routing", at least the perception, if anchoring is the right
>    model and if operators liked it, is another topic. But, we never
>    had the capability to support that feature in IPv4, we can
>    specify a solution for MIPv4 RO, but any solution that requires a
>    change in every IPv4 node in the internet, implies the feature is
>    useless. We have an opportunity here to make that change here.

I will be at the front of the line championing RO technology once
there is demonstrable community support for a particular approach and
we have enough operational experience to give us confidence it is
ready for broad use.

> 3. I can understand that we have to be careful what we mandate in
>    the node requirements document. If feature-x makes sense, useful,
>    easy to implement, inline with Internet architectural
>    direction. This protocol is specified, analyzed, implemented and
>    studied in universities for number of years . Most Linux/BSD
>    kernels have support Type-II RH, I remember some Linux
>    distributions have included the RO feature by default. Its not a
>    whole lot of code, or complexity that one needs to deal with. Its
>    matter of including that package in all distributions. Making
>    that mandatory.

Support for the RH headers is a minor issue. The real complexity in RO
is in the signalling and management of the local Destination Cache. It
is lack of experience here that is one of my big concerns. E.g., we
don't even know when to recommend initiating RO. After 10 packets?
After a thousand? Every connection? Only certain ones? Without
experience, we just don't know if this stuff is fully baked.

And there was a thread a while back from big content providers that
had pretty serious concerns about putting RO in their servers (i.e.,
increased state and complexity for all their short-lived TCP
connections). There are legitimate concerns with RO that still need to
be worked through. Hence, again, we need real, substantive experience
with it.

Thomas

---

From: Randy Bush <[email-masked]>
Date: Sat, 21 Aug 2010 12:59:34 +0900

>    have the opportunity to turn this feature on.

for all values of X.  when we don't even have basics working and
deployed and actually used.  full employment for vendor developers, and
untested, and therefore buggy, code in the devices for which i pay you
way too much money already.

the purpose of standards is so the user can choose from multiple vendors
for the features and products the user wants.

randy

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Aug 2010 16:27:20 +0200

Le 20/08/2010 20:47, Thomas Narten a écrit :
> Sri Gundavelli<[email-masked]>  writes:
>
> Actually, this explanation is not consistent with history. RO was
> not added to MIP4 because there was no customer for the work. MIP has
>  been implemented and deployed in IPv4. But those using it had no
> need for and didn't seem to have a business case for RO. There was
> an ID for RO for MIP4 at one time, but the WG abandoned the draft
> when it became clear no one had interest in actually deploying it.
>
> I think this point is very much worth noting. We can jump up and
> down all day and say some feature is really cool and beneficial, but
> what really matters is whether someone will actually deploy and use
> it, based on the value they see.
>
> Also, deploying MIP is much more complicated than deploying other
> IPv6 protocol features.

Hm, depends on the perspective.

Sure, if one compares success of MIP6 vs e.g. that flash of ND one is
quickly deceived, seeing ND there everywhere whereas MIP6 only recently
getting tract in the mainline open unix distribs.

However, if one compares MIP6 deployment success to that of DHCPv6, one
gets a different picture.

RO is different yet.  Discouraging is to know that every single CN would
need it.  Encouraging is to see that only recently google and social
nets went IPv6 - on this scale we should wait a few more years to see
first signs of RO deployment.

Alex

> You need an HA and associated AAA infrastucture. This is just for
> base MIP, without even getting to RO.
>
> argue that we have to get IPv6 deployed first, and then folk will
> use MIPv6 as well, but I think that is also simplistic thinking. I
> believe deploying and using MIPv6 (and the RO functionality
> specifically) is still something we lack significant experience
> with.
>
> I think the IPv4 experience with MIPv4 suggests that there are
> target scenarios where MIP technology is quite useful, but at the
> same time, there is no broad general need for MIP. The vast majority
> of the Internet seems to be doing Just Fine without using MIP.

WEll.  I wanted to remark to this specific point.  I

>> feature. Most IPv6 stacks have support for these options and in
>> most cases the RO procedure as well. Given this, It is very
>> important that the IPv6 Correspondent Node functionality is
>> mandated on every IPv6 node. However, the Home Agent functionality
>>  on IPv6 routers, or the Mobile Node stack on a IPv6 node, can be
>> optional, that is fine. But, its important that the end-points has
>>  natural RO support.
>
> I'm strongly opposed to mandating CN support for RO on general
> purpose nodes (clients and servers) until:
>
> a) we have significant experience with the technology showing that
> it works in practice (i.e, in significant operational deployments),
> and
>
> b) there is a more realistic sense that the technology would
> actually get used, if it were available.
>
> MIP appears to (possibly) be a "nice to have" feature. But it is not
>  a critical part of IPv6.  It is not the job of the IETF to broadly
> Indeed, per previous discussions on this list, SEND is listed only
> as a MAY in the current node requirements ID.
>
> Thomas
> IETF IPv6 working group mailing list [email-masked] Administrative
> Requests: https://www.ietf.org/mailman/listinfo/ipv6

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 23 Aug 2010 16:41:33 +0200

Sri, I take advantage of your email to insert another comment.

I have already posted this comment one year ago.  I have also stated it
at the microphone in Maastricht recent IETF meeting:

If you cite rfc3775 (Mobile IPv6) in the node req document then please
cite rfc3963 (NEMOv6, mobile networks) too, because the latter is a
simple extension of the former.

It is hard to get code accepted in the linux mainline kernel, because of
high reliability requirements.  For MIP6 it took several years, with at
least a couple of simultaneous multiple person projects geared at that.

Alex

Le 20/08/2010 17:22, Sri Gundavelli a écrit :
> into the protocol is the support for Route Optimization. The ability
>  for a mobile node to provide the information on the direct
> (non-anchor or non-triangular) path to a Correspondent Node. This was
> not possible in Mobile IPv4, as any change requirement to IPv4 did
> not make much sense. This is one feature of Mobile IPv6 that stands
> out. The semantics of RO, say Type-II RH, is part of the basic IPv6
> the Mobile Node stack on a IPv6 node, can be optional, that is fine.
> But, its important that the end-points has natural RO support.
>
> 3.) Section 9.0 should be reviewed by MEXT, NETLMM and NETEXT working
> groups, so the node requirements with respect to IP Mobility are
> properly presented.
>
>
>
> Regards Sri
>
>
>
>
>

-- 
Alexandru Petrescu
CEA LIST
Ingénieur Chercheur
tél 0169089223
[email-masked]
http://www-list.cea.fr

---

From: Vijay Devarapalli <[email-masked]>
Date: Tue, 24 Aug 2010 11:12:45 -0700

> be the right mobility technology to recommend these days. That pretty

This needs a clarification. DS-MIPv6 (RFC 5555) is an extension of 
MIPv6. Raj's email makes it appear like it is an alternate mobility 
management protocol. It is not. It allows a MIPv6 mobile node to bind an 
IPv4 Care-of Address to an IPv6 Home Address, when the mobile node find 
itself on an IPv4-only access network. It has a few other extensions, 
but not relevant to this discussion.

Vijay