Subject: HAO and BE processing will be mandated

From: Keiichi SHIMA / 島慶一 <[email-masked]>
Date: Tue, 16 Jul 2002 01:41:44 +0900 (JST)

Hi all,

I'm sorry to raise this topic so many times, I still don't understand
the reason.

The current mip6 (draft-18) says that all IPv6 nodes:

- MUST be able to validate a HAO
- MUST be able to send a Binding Error message

I think I understand the benefit of the above requirements.  If an
IPv6 node supports the above requirements, a mobile node can
communicate with the IPv6 node using a triangular routing if HAO is
protected by the IPsec.

But, even if there is no such requirement, a mobile node can
communicate with all IPv6 nodes in the world using bi-directional
tunneling.  This requires nothing to all existing and future IPv6
nodes.

I may misread/misunderstand something.  If so, please correct me.

I'm not sure it is important or not to mandate HAO/BE to make a
triangular routing possible.  But it seems to me that such
requirements make it harder to make mip6 become an rfc.  I still don't
think such new requirements are accepted by the IPv6 WG.

Again, I'm sorry I should have sent this comment earlier.  I really
want to make the mip6 spec RFC as soon as possible.  I think fewer
requirements is better for fast deploying.  

---
Keiichi SHIMA
IIJ Research Laboratory <[email-masked]>
KAME Project <[email-masked]>
--------------------------------------------------------------------
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: [email-masked]
Date: Wed, 17 Jul 2002 23:01:00 +0900

>tunneling.  This requires nothing to all existing and future IPv6

	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.

	we have no way to force upgrade for all users of the existing IPv6
	stacks.  therefore, i believe it very important for mobile-ip6 to be
	defined so that:
	- mobile-ip6 MN is interoperable with CN without HAO support, nor
	  binding error message support
	- do not require any changes to existing implementations
	- do not make them "non-conformant"

	i would really like to see the change included in draft 19.  thanks.

itojun

---

From: Keith Moore <[email-masked]>
Date: Wed, 17 Jul 2002 11:31:41 -0400

> 	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.

Keith

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Jul 2002 11:53:49 -0700

hi Itojun,

>           binding error message support

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.

>         - do not require any changes to existing implementations

we dont have to.

>         - do not make them "non-conformant"

everytime a new standard comes out, there is something new in it.

regards
Vijay

---

From: [email-masked]
Date: Thu, 18 Jul 2002 06:21:10 +0900

>Binding Error was specified so that it is easier for the MN to figure

	then I see no reason for the MUST.

itojun

---

From: Vijay Devarapalli <[email-masked]>
Date: Wed, 17 Jul 2002 14:33:21 -0700

>         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?

regards
Vijay

---

From: Michael Thomas <[email-masked]>
Date: Wed, 17 Jul 2002 14:35:23 -0700 (PDT)

> 	then I see no reason for the MUST.

Sez RFC 2119:

6. Guidance in the use of these Imperatives

   Imperatives of the type defined in this memo must be used with care
   and sparingly.  In particular, they MUST only be used where it is
   actually required for interoperation or to limit behavior which has
   potential for causing harm (e.g., limiting retransmisssions)  For
   example, they must not be used to try to impose a particular method
   on implementors where the method is not required for
   interoperability.

Given that MIPv6 will interoperate without binding
code in CN's, it looks pretty much like a SHOULD
to me. Indeed, the protocol would not be robust if
it didn't consider the case of a non-conformant CN.

	  Mike

---

From: Francis Dupont <[email-masked]>
Date: Thu, 18 Jul 2002 02:57:10 +0200

=> 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)
--------------------------------------------------------------------
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: Jari Arkko <[email-masked]>
Date: Thu, 18 Jul 2002 05:09:03 +0300

Hi Itojun,

 > 	  binding error message support

This is already the case. Draft 18 always work even with an IPv6 node that
has no MIPv6 support. A CN that doesn't support RR will be sending back
ICMP Parameter Problems, which we take in account. (In the current draft
also shows a rather special case where HAO could be used without RO if an
SA exists, but even in that case we would get an ICMP back and be able to
act if the other side didn't support this.)

By the way, this ability to support non-MIPv6 nodes is a new feature from
a couple of months back, a consequence of protecting against certain security
attacks. I really like this feature, and it should make new implementations
quite good in the interoperability sense.

So, technically everything works. But it's a separate question whether
the IETF wants to mandate (SHOULD/MUST) some level of additional support,
such as for the HAO or even for the RO. But regardless of whether such
mandates are accepted or implemented, the protocol should technically
work in all cases. If you can see a case where this would not be the case,
please let as know and we'll fix it.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Jul 2002 05:38:22 +0300

> interoperability with the installed base.

Agree with all of the above.

In this case, there are no interoperability problems. Since draft N-2
Mobile IPv6 has been able to work with IPv6 nodes that have *no* MIPv6
specific code.

Again, this is separate from what the IETF may mandate for IPv6 nodes
to support. To take a clearly unreasonable example, we could mandate
every node to support a 1,000,000 entry bindind cache. Even with
such a mandate a node conforming to this requirement would work
with a node that has never heard of MIPv6. So, interoperability and
must-implement are different in this particular case. I think that's
good because we can then decide more freely what to require from
all implementations.

Jari

---

From: Jari Arkko <[email-masked]>
Date: Thu, 18 Jul 2002 05:38:22 +0300

Jari