Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 17 Jul 2002 18:07:54 +0200

> > 	as you may have heard during IETF54 IESG plenary panel session,
  > > 	i would like to see the above "MUST" removed.  there 
  > are large amount
  > > 	of IPv6 install base, which supports no HAO, or old 
  > definition of HAO.
  > > 	for instance, FreeBSD beyond 4.0 has IPv6 but no 
  > support for HAO.
  > > 	MacOS 10.2, JunOS and ExtremeWare do not have HAO 
  > support either.
  > > 	suspect they have no HAO support.
  > 
  > the purpose of a standard is to describe what is necessary 
  > for interoperability
  > and proper functioning of the protocol, not to legitimize existing 
  > implementations.  so the installed base shouldn't dictate 
  > whether a feature
  > is a MUST in a new version of a standard unless 
  > interoperability with the 
  > installed base is important (it generally is) and imposing 
  > the MUST condition 
  > on implementations that conform with the new version of the 
  > standard affects 
  > interoperability with the installed base.

=> I agree, but as I said earlier, technically
removing the must on the HAO makes sense, according
to the meaning of the keywords. The BE message
is a bit difficult to remove though. I hope than
when we discuss this tomorrow we make some distinction
between the 2 functions. 

Hesham
--------------------------------------------------------------------
IETF IPng Working Group Mailing List
IPng Home Page:                      http://playground.sun.com/ipng
FTP archive:                      ftp://playground.sun.com/pub/ipng
Direct all administrative requests to [email-masked]
--------------------------------------------------------------------

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Wed, 17 Jul 2002 19:47:13 +0200

> I'm sorry, I must describe more to complete the scenario.
  > 
  > From: Keiichi SHIMA / 島慶一 <[email-masked]>
  > 
  > > > => Technically, removing the must on the HAO is not a problem. 
  > > > In fact, regardless of deployed base, keeping a must for 
  > > > the HAO makes no sense IMHO.
  > > > As for the BE message, I guess we need to make sure that
  > > > somehow the CN tells the MN that no binding exists. 
  > > > Not sure what can be done about this. 
  > > 
  > > If the CN supports mip6, the CN will send a BE message when it
  > > receives a packet which has HAO and it doesn't have a 
  > BCE.  If the CN
  > > doesn't support mip6, the CN will send an ICMP PRAMPROB 
  > with code 2
  > > based on the ICMPv6 specification.
  > Also, if the CN doesn't support mip6 and receives MH (ex. 
  > HoTI/CoTI),
  > the CN will send ICMP PARAMPROB with code 1 based on the ICMPv6
  > specification.
  >  
  > > When the MN receives a BE message, the MN will re-start 
  > RR procedure.
  > > When the MN receives ICMP PARAMPROB with code 2 and the pointer
  > > indicates HAO, the MN will switch to use bi-directional tunneling.
  > When the MN receives ICMP PARAMPROB with code 1 and the pointer
  > indicates MH, the MN will switch to use bi-directional tunneling.
  > 
  > > Is there any other scenarios?  Please correct me if the 
  > above rules
  > > are not enough to support non-mip6-aware IPv6 nodes.

=> You're right, provided that we got the right option type
value for the HAO (can't remember but it should be ok) so
that the CN drops the packet if there is a HAO. 

For others who are not up to date on the MIPv6 spec, 
the HAO is only accpeted by the CN if RO is used
or the packet is protected with IPsec. Otherwise reverse
tunelling is used. So the norm is reverse tunnelling. 
That's why I don't think the HAO needs to be mandated. 

Hesham

---

From: [email-masked]
Date: Thu, 18 Jul 2002 00:56:53 +0300

Hesham,

> => Exactly, IMHO the support for HAO is tied to
> RO support which is a SHOULD anyway, so the HAO
> should follow that. 

Logically, you are inconsistant.  

As an example, RO is a should, protecting RO is a MUST.

This set of mail exchanges have actually made me think
that this is important functionally and that implementing HAO is
important for security reasons and it is not unreasonable to
insist all nodes implement it.  

John

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 18 Jul 2002 02:19:40 +0200

> As an example, RO is a should, protecting RO is a MUST.

=> Huh? 

Protecting it is a must for those who support it! 
But supporting it is a should.

Hesham

---

From: "Hesham Soliman (EAB)" <[email-masked]>
Date: Thu, 18 Jul 2002 02:53:38 +0200

> 
  > The question more is, what do general implementations need 
  > to implement.
  > In my opinion, general often equals robust.  SHOULD does not mean
  > optional, it means you do it unless you have good reason 
  > not to do it.
  > I think the burden of proof, then, would be the endpoint 
  > which does not
  > implement a certain feature.

=> So are you saying should is ok? because that's all I'm
saying.

  > I think that since HAO is used for security reasons, it may 
  > have a strong
  > need to be a must than other functionality.  Just my opinion.

=> The HAO is not needed for security reasons at all. All
these arguments for SHOULD vs MUST are essentially because
some people want to allow triangular routing _for_IPsec_protected_
traffic _only_. As I said a few mails back, the HAO is only
accepted if the packet is protected by IPsec or if a BCE
exists.  

Hesham

---

From: Phil Roberts <[email-masked]>
Date: Wed, 17 Jul 2002 21:07:04 -0400

A few issues have become mingled here.

1) Keiichi and others have raised the issue of MUST support for HAO
and BE processing and have proposed a solution that allows communication
to happen between any two nodes with clarification in the MIP spec of
properly handling the ICMP errors returned.

2) There is a question about RO support requirements for all nodes.
Actually the current spec doesn't give a recommendation for support of
RO.  If a node is supporting it, there are a bunch of MUSTs.

We should make sure we agree as a working group on our consensus on these
two issues.  Perhaps we can sort this out on the MIP list first?

> -----Original Message-----
> From: Francis Dupont [mailto:[email-masked]]
> Sent: Wednesday, July 17, 2002 8:57 PM
> To: Vijay Devarapalli
> Cc: [email-masked]; [email-masked]; 
> [email-masked];
> [email-masked]
> Subject: Re: [mobile-ip] Re: HAO and BE processing will be mandated 
> 
> 
>  In your previous mail you wrote:
> 
>    > >it is. if a CN does not support HAO, it will send an 
> ICMP error message
>    > >pointing to the offending octet. when the MN receives 
> this message, it
>    > >starts reverse-tunneling through the Home Agent. where 
> is the problem?
>    > >if this is not clearly specified in the MIPv6 draft, it 
> can be. the
>    > >binding error functionality can also be substituted by 
> an ICMP error.
>    > >Binding Error was specified so that it is easier for 
> the MN to figure
>    > >out whats going on.
>    > 
>    >         then I see no reason for the MUST.
>    
>    I was discounting the reason (the already IPv6 installed base) you 
>    gave. the MUST is for newer IPv6 CN implementations. as I told you 
>    already, it makes the MN's life easier. but the current spec does 
>    ensure that a MN can still have a session with an old IPv6 
>    implementation (which does not implement HAO) through reverse 
>    tunneling. so again, where is the problem? why are you against the 
>    MUST?
>    
> => MUSTs are for interoperability problems, not for political matters.
> So Itojun is right and the fact that old IPv6 nodes still work with
> MNs proves the requirement should not be higher than SHOULD.
> 
> Regards
> 
> [email-masked]
> 
> PS: sorry but if someone is asking whether the RR/RO support should be
> mandatory I'll vote against it. And I can't see how the iETF will
> enforce it if I am being in the minority...
> (the topics has just been added to the ipv6 WG session agenda)

---

From: "Kuntal Chowdhury" <[email-masked]>
Date: Thu, 18 Jul 2002 00:56:23 -0500

Michael Thomas wrote:
>    Frankly, I don't think that there is any evidence
>    that the net would be substantially harmed if RO
>    wasn't widely implemented and/or enabled. Indeed, 
>    I think  there's good reason to believe that many/most
>    nodes will not enable RO even if their kernel
>    implements it. In some cases, it's likely to be
>    a nice and useful optimization, but I really
>    don't see it as a "if we don't do this the net
>    will fall apart". As such, SHOULD seems like it
>    strikes the right balance.
> 
> 	       Mike
> 

I could not agree more with this point. RO would be a required 
functionality a number of years back, when the net was in it's 
infancy and bandwidth availability in the backbone networks 
(even transoceanic links) were severely limited.
We are in the age of OC-192/768s over DWDM. The delay that an IP
packet incurs in the core is almost negligible. 
If bottleneck in the HA is the primary driver for RO, then it is
possible to solve the problem with load balancing with DHAAD.

My two cents.

Regards,
Kuntal

---

From: [email-masked]
Date: Fri, 19 Jul 2002 11:32:56 +0300

Pascal,

> Face it: Many of today's large web servers will not want to 
> maintain binding caches. 

We are not talking about forcing deployments to use RO, but
to have to code to support it & have code to support the
HAO.  

Think of it this way, this might always be a premium service
a web service could provide. If their OS has the code, they
could selectively support RO to premium clients.  

John

---

From: Phil Roberts <[email-masked]>
Date: Wed, 17 Jul 2002 21:07:04 -0400

---

From: "Glenn Morrow" <[email-masked]>
Date: Mon, 22 Jul 2002 14:14:41 -0500

sed r//HOA//HAO/g

> From: Morrow, Glenn [RICH2:C310:EXCH] 
> Sent: Monday, July 22, 2002 2:17 PM
> To: 'Michael Thomas'; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: RE: [mobile-ip] Re: HAO and BE processing will be mandated 
> 
> 
> I thought it was already decided that a CN MUST respond with 
> a rate limited "lack of resources" response to the request 
> for route optimization. If this is the case then it seems to 
> follow that the processing of the HOA for this purpose MUST 
> also be supported if the HOA is to be a part of the request 
> to do route optimization - but only to this extent. Perhaps 
> some clarification in the draft is all that is necessary as 
> to what is meant by the MUST.
>  
>

---

From: "Glenn Morrow" <[email-masked]>
Date: Tue, 23 Jul 2002 07:57:05 -0500

I agree - let's move on.

> From: Jari Arkko [mailto:[email-masked]]
> Sent: Tuesday, July 23, 2002 3:25 AM
> To: Morrow, Glenn [RICH2:C310:EXCH]
> Cc: Michael Thomas; [email-masked]; [email-masked];
> [email-masked]; [email-masked];
> [email-masked]
> Glenn Morrow wrote:
> > I thought it was already decided that a CN MUST respond with a rate 
> > limited "lack of resources" response to the request for route 
> > optimization.
> 
> 
> Yes!
> 
> > If this is the case then it seems to follow that the 
> > processing of the HOA for this purpose MUST also be 
> supported if the HOA 
> > is to be a part of the request to do route optimization - 
> but only to 
> > this extent.
> 
> 
> Indeed.
> 
> However, I believe this thread is not about the support of 
> HAO with RO --
> it is more about the support of HAO with IPsec and triangular routing.
> Folks are complaining that there is not sufficient reason to 
> have a MUST
> for that special case. And I'm starting to agree...
> 
> Jari
> 
> 
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 30 Jul 2002 14:31:06 -0400

John,

I would prefer all requirements for me to implement are in the specs as a programmer.  I view node reqs doc as a statement of further reqs of the std regarding conformance not implementation.  If we don't want HAO to be MUST make it a SHOULD this should be decided in the MIPv6 spec.k

thanks
/jim

> From: [email-masked] [mailto:[email-masked]]
> Sent: Wednesday, July 17, 2002 8:14 PM
> To: [email-masked]; [email-masked]
> Hi Mike,
> > Vijay Devarapalli writes:
> >  > RO is a SHOULD, it is not a MUST in the current draft. we were 
> >  > not talking about route optimization. we were talking about 
> >  > processing a HAO. in the current spec HAO MUST be processed but 
> >  > not accepted if it cant be verified. verification can be in the 
> >  > form of checking for a valid BCE (created securely), IPsec 
> >  > protected data session, same trusted domain (where you dont 
> >  > expect people to do reflection attacks), the tagging proposal 
> >  > from Rajeev and Charlie, smart ingress filtering from Francis 
> >  > Dupont, etc...
> > 
> >    Oh, OK. Sorry about that. Still if the code
> >    isn't in the CN, the MN should still be able
> >    to operate correctly, right? That still seems
> >    to me to be a SHOULD rather than a MUST for the
> >    same reasons in my reply to John.
> > 
> >    I guess the long and short of this is that I'm
> >    somewhat skeptical of putting general node
> >    requirements in the MIP draft since it's
> >    probably not the first place one would be
> >    looking to figure out if they were an IPv6
> >    compliant node. If it's really, really vital
> >    for the health of the net, yadda, yadda, it
> >    would be better to put it in a general v6 node
> >    requirements RFC, don't you think?
> 
> Just as an FYI, I replied to the earlier mail because I am
> trying to sort this out for the node requirements.  I think 
> that in MIPv6, it is OK that MIPv6 makes this recommendation (given 
> working group consensus, IESG approval, etc.) but the Node 
> Requirements
> document is the final word on the issue (assuming WG consensus, 
> IESG approval, etc.).
> 
> John
>

---

From: "Bound, Jim" <[email-masked]>
Date: Tue, 30 Jul 2002 14:35:18 -0400

HAO SHOULD be implemented.  MUST is a stretch and I always thought so since draft 1.
The security argument is irrelevant to being a MUST or SHOULD if I deployed MIPv6 I would not use RR or any IPsec there are many ways to secure the mobile nodes and CNs and I agree with Vijays point on this just not the MUST.

That being said anyone who would not want to implement mobile HAO is not in tune with the market at all.  But thats not the IETFs job to keep them in tune.

/jim

> Sent: Wednesday, July 17, 2002 8:41 PM
> To: [email-masked]; [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> Hi Hesham,
> We're dangerously on the edge of a rathole.
> 
> Debates on support / implement / use of various functions is something
> to often causes pointless discussions.
> 
> The question more is, what do general implementations need to 
> implement.
> optional, it means you do it unless you have good reason not to do it.