Subject: Re: [nemo] About Test Specification in IPv6 Ready Logo

From: "K.Kawaguchi" <[email-masked]>
Date: Mon, 2 Oct 2006 15:15:04 +0900

Hi all,

We E-mails again for confirmation though there is no opinion.
The IPv6 Ready Logo NEMO will begin within one month if it is unquestionable.

NEMO allows to generates HoA either from home network prefix or mobile
network prefix. We treats the first configuration as a basic function
and the second one as the advanced function.
Does anybody comments on this?

Best regards
---
Kiyoaki KAWAGUCHI

In message <[email-masked]>
"[nemo] About Test Specification in IPv6 Ready Logo"
""K.Kawaguchi" <[email-masked]>" wrote:

> Hi,
> 
> We will begin IPv6 Ready Logo of RFC3963 (NEMO basic support).
> This is a program of the confidence to the NEMO product based
> on RFC3963. We want to hear your opinion in regard to the test
> condition in this test specification.
> 
> We have opened the preparation version of the test specification
> to the public.
> 
>   http://www.ipv6ready.org/announcement/public_review20060621_nemo.html
> 
> The point that we want to hear the opinion is the following parts.
>   http://cert.v6pc.jp/nemo/phase2/public_review/pdf/nemo_phase2policy-v1_0_b2.pdf
> 
> ---------------------------------------------------------------------
> 3. Policy for Basic and Advanced Functions
> 
> Here shows the view of satisfaction of the functions belonging to Basic
> Function (Priority A1) and Advanced Function (Priority A2) for Home
> Agent and Mobile Router.
> 
> - HA (Home Agent)
>  - Router functions defined in "Test Specifications for the IPv6 Core
>    Protocols" MUST be supported.
>  - Mobile network prefix registration supporting all of explicit mode,
>    implicit mode, home address derived from the Mobile Network Prefix, and
>                   ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
>    home address derived from the Home Network Prefix is a Basic Function (A1).
>    ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
> ---------------------------------------------------------------------
> * supplementation) keywords
>   Basic Function (Priority A1)  : It is defined as indispensable function.
>                                   It is always to be tested in Logo.
>   Advance Function (Priority A2): It is defined as enhanced feature.
>                                   It is tested by selection in Logo.
> 
> 
> RFC3963 has not described which method is a 'MUST'. Therefore,
> we had equally treated both. However, the operation is possible
> by either one.  And a lot of venders might implement only one
> of methods. Now, we think that it is too rich to demand both from
> all products.
> We will put the bias. Two alternatives without mandating either
> make non-interoperable world. So, mandating one is very reasonable.
> We think naturally that home Address be configured from Home Link
> Prefix is basic method same as MIPv6.
> We change the above-mentioned part as follows. 
> 
> ---------------------------------------------------------------------
> - HA (Home Agent)
>  - Router functions defined in "Test Specifications for the IPv6 Core
>    Protocols" MUST be supported.
>  - Mobile network prefix registration supporting all of explicit mode,
>    implicit mode, is a Basic Function (A1).
>  - Mobile network prefix registration supporting home address derived from
>    the Home Network Prefix is a Basic Function (A1).
>  - Mobile network prefix registration supporting home address derived from
>    the Mobile Network Prefix an Advanced Function (A2).
> ---------------------------------------------------------------------
> 
> We want to hear your opinion.
> Do you think it is unquestionable for this priority level in which
> it is made to bias in Logo?
> 
> 
> Relational part of RFC3963
> ---------------------------------------------------------------------
> 6.2.  Mobile Network Prefix Registration
> 
>  (snip)
> 
>    -  Mobile IPv6 specification [1] requires that the Home Address in
>       the Binding Update be configured from a prefix advertised on the
>       home link.  Otherwise the Binding Update is rejected with status
>       value 132 [1].  This specification relaxes this requirement so
>       that the Home Agent rejects the Binding Update only if the Home
>       Address does not belong to the prefix that the Home Agent is
>       configured to serve.
> ---------------------------------------------------------------------
> 
> 
> Best regards
> ---
> Kiyoaki KAWAGUCHI
> 
> 
> 
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Mon, 02 Oct 2006 09:08:23 +0200

K.Kawaguchi wrote:
> Hi all,
> 
> We E-mails again for confirmation though there is no opinion. The 
> IPv6 Ready Logo NEMO will begin within one month if it is 
> unquestionable.
> 
> NEMO allows to generates HoA either from home network prefix or 
> mobile network prefix. We treats the first configuration as a basic 
> function and the second one as the advanced function. Does anybody 
> comments on this?

Hi Kiyoaki,

It is difficult for me to make comments towards supporting or not
supporting a certain logo.  An IETF RFC is the expression of striving to
interoperate.  The purpose of the logo seems to be different.

Technically speaking, the implementation with which I work uses a Home
Address derived from the home link prefix, and thus I find your decision
to support this as a basic configuration ok.

Alex

> 
> 
> Best regards --- Kiyoaki KAWAGUCHI
> 
> 
> 
> In message <[email-masked]> "[nemo] 
> About Test Specification in IPv6 Ready Logo" ""K.Kawaguchi" 
> <[email-masked]>" wrote:
> 
>> Hi,
>> 
>> We will begin IPv6 Ready Logo of RFC3963 (NEMO basic support). This
>>  is a program of the confidence to the NEMO product based on 
>> RFC3963. We want to hear your opinion in regard to the test 
>> We have opened the preparation version of the test specification to
>>  the public.
>> 
>> Here shows the view of satisfaction of the functions belonging to 
>> Basic Function (Priority A1) and Advanced Function (Priority A2) 
>> for Home Agent and Mobile Router.
>> 
>> - HA (Home Agent) - Router functions defined in "Test 
>> Specifications for the IPv6 Core Protocols" MUST be supported. - 
>> Mobile network prefix registration supporting all of explicit mode,
>> ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^ home 
>> address derived from the Home Network Prefix is a Basic Function 
>> (A1). 
>>  * supplementation) keywords Basic Function (Priority A1)  : It is 
>> defined as indispensable function. It is always to be tested in 
>> Logo. Advance Function (Priority A2): It is defined as enhanced 
>> feature. It is tested by selection in Logo.
>> 
>> 
>> RFC3963 has not described which method is a 'MUST'. Therefore, we 
>> had equally treated both. However, the operation is possible by 
>> either one.  And a lot of venders might implement only one of 
>> methods. Now, we think that it is too rich to demand both from all 
>> products. We will put the bias. Two alternatives without mandating 
>> either make non-interoperable world. So, mandating one is very 
>> reasonable. We think naturally that home Address be configured from
>>  Home Link Prefix is basic method same as MIPv6. We change the 
>> above-mentioned part as follows.
>> 
>>  - HA (Home Agent) - Router functions defined in "Test 
>> Specifications for the IPv6 Core Protocols" MUST be supported. - 
>> Mobile network prefix registration supporting all of explicit mode,
>>  implicit mode, is a Basic Function (A1). - Mobile network prefix 
>> registration supporting home address derived from the Home Network 
>> Prefix is a Basic Function (A1). - Mobile network prefix 
>> registration supporting home address derived from the Mobile 
>> Network Prefix an Advanced Function (A2). 
>> We want to hear your opinion. Do you think it is unquestionable for
>>  this priority level in which it is made to bias in Logo?
>> 
>> 
>> value 132 [1].  This specification relaxes this requirement so that
>>  the Home Agent rejects the Binding Update only if the Home Address
>>  does not belong to the prefix that the Home Agent is configured to
>>  serve. 
>> Best regards --- Kiyoaki KAWAGUCHI
>> 
>> 
>> 
>> 
> 
> 
>

---

From: "K.Kawaguchi" <[email-masked]>
Date: Mon, 2 Oct 2006 18:48:22 +0900

Hi Alex,

Thank you for the answer.

> interoperate.  The purpose of the logo seems to be different.

Yes.
Logo also aims at Interoperability. However, there might be some
differences though Logo followed RFC.

Logo aims to be able to connect all equipment under the Logo.
Only one common specification and procedure are necessary for it.
But, there is a selective part in RFC. Therefore, the only one is
selected from a selective part of RFC. And the only one is defined
as the basic in Logo.

> to support this as a basic configuration ok.

Thank you for information.
It is the basic that we defined.

Best regards
---
Kiyoaki KAWAGUCHI

"Re: [nemo] About Test Specification in IPv6 Ready Logo"

---

From: Greg Woodhouse <[email-masked]>
Date: Mon, 2 Oct 2006 10:02:47 -0700 (PDT)

It isn't hard to see two (or more) "sides" of the issue. On the one
hand, IPv6 should be universally adopted, and providing a logo for
people to use, seems to imply that adoption of IPv6 is something
special, and not the norm. Still, it provides a small incentive to
vendors, open source team, and so forth to incorporate IPv6
functionality in their products. I can't help but wonder if the snail
on the cover of the O'Reilly book on IPv6 isn't there as a kind of
commentary on the rate of IPv6 adoption!

Then again, are applications really the big issue? I know OS X, at
leasst supports IPv6, and I'd expect that other major operating
systemsx would do the same. What I don't know is whether "consumer"
ISPs even route IPv6 (though I don't expect this to be an issue on
enterprise networks), and I wonder hos many web sites and other serices
even advertise IPv6 addreses. I don't recall ever happening upon an A4
or AAAA record in dig or nslookup. That stikes me as odd because the
cost of advertising IPv6 addresses certainly seems small (assuming the
network supports them, of course).

===
Gregory Woodhouse  <[email-masked]>

"Mathematics is the science of patterns."
--Lynn Arthur Steen, 1988

---

From: Thierry Ernst <[email-masked]>
Date: Tue, 3 Oct 2006 10:35:17 +0200

Dear all,

There are a bulk of ISPs and vendors supporting IPv6 services, and all
major OS do have an IPv6 stack. This is not the issue of this
discussion.

Regarding the adoption of the NEMO logo, I would favor 2 slides on this
to show at the next IETF if Kawaguchi-san attend it. We could then reach
a reasonable conclusion there. So far, it's not clear to me if a
NEMO-compliant implementation should allow the configuration of  the
MR's HoA either from home network prefix or the mobile network prefix.  

Whether it happens on the ML or at the NEMO session in San Diego,, it
would be nice to obtain more feedback from those who have implemented
RFC 3963 and those who are considering selling products based on it.

Thierry

On Mon, 2 Oct 2006 10:02:47 -0700 (PDT)

-- 
Thierry ERNST, PhD
http://www.nautilus6.org/~thierry
IETF NEMO WG Chair, IETF MonAmi6 Chair, Nautilus6 Chair
--
INRIA Rocquencourt Project-Team IMARA, France.
+33 1 39 63 59 30 (office)

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 03 Oct 2006 20:34:48 +0200

Thierry Ernst wrote:
> Dear all,
> 
> 
> There are a bulk of ISPs and vendors supporting IPv6 services, and 
> all major OS do have an IPv6 stack. This is not the issue of this 
> discussion.
> 
> Regarding the adoption of the NEMO logo, I would favor 2 slides on 
> this to show at the next IETF if Kawaguchi-san attend it. We could 
> then reach a reasonable conclusion there.

Discussing ok, reaching a conclusion is probably impossible.  The logo
issue has indeed at least two facets.  Many IPv6 implementers currently
turn to "logo" type of claims in order to boast features understandable
by higher level speakers - TAHI comes to mind: how many times I've seen
IPv6 implementation projects targetting TAHI compliance; it's a good
motivator for implementers.  However, a logo is usually neglected in the
IETF talk, in that RFCs are often just that, _trying_ to interoperate.

A WiFi logoed equipment is supposed to give me compliance insurance
about two manufacturer's products.  But in practice it sometimes fails:
I came across two WiFi logoed equipments failing to interoperate
in the detail, or too inefficient.  We don't want that to happen
with NEMOv6.

A logo vision gives insurance to buyers about interoperability.  But it
often turns into monetary interests to get "labelized" - you pay
enough you get the label, neglecting technical intricacies.  Check ISO
9001 and successors, guaranteeing the "quality" of a product or process;
"quality" is one of those undescribable matters but easily recognizable
by the skilled - thus why need of ISO 9001.

> So far, it's not clear to me if a NEMO-compliant implementation 
> should allow the configuration of  the MR's HoA either from home 
> network prefix or the mobile network prefix.

What's "NEMO-compliant".  I'm happy and not happy with rfc3963
suggesting HoA both from MNP and from home link.  The need for
HoA-from-MNP was strongly suggested by someone implementing it, so it
works.  Just like explicit-vs-implicit modes.

The logo in question suggests that HoA-from-MNP is but an extension and
HoA-from-home-link is the basis.   I'm happy with that too.

>  would be nice to obtain more feedback from those who have 
> implemented RFC 3963 and those who are considering selling products 
> based on it.

Yes.

> On Mon, 2 Oct 2006 10:02:47 -0700 (PDT) Greg Woodhouse 
> <[email-masked]> wrote:
> 
>> functionality in their products. I can't help but wonder if the 
>> snail on the cover of the O'Reilly book on IPv6 isn't there as a 
>> kind of commentary on the rate of IPv6 adoption!
>> 
>> systemsx would do the same.

YEs.  MS Vista (or the latest CE is that?) claims built-in MIP6 as well.

>> What I don't know is whether "consumer" ISPs even route IPv6 
>> (though I don't expect this to be an issue on enterprise networks),
>> 
>> 
Some do.  IIRC BT and KDDI are two examples.

>> and I wonder hos many web sites and other serices even advertise 
>> IPv6 addreses. I don't recall ever happening upon an A4 or AAAA 
>> record in dig or nslookup. That stikes me as odd because the cost 
>> of advertising IPv6 addresses certainly seems small (assuming the 

Striking indeed.

Google has reserved IPv6 address space, the Vatican as well.

Some ietf.org servers are IPv6 online.

Let's see.

Alex

---

From: "K.Kawaguchi" <[email-masked]>
Date: Wed, 4 Oct 2006 17:10:32 +0900

Thank you for comments and answers.

Logo is not intending one for a special system and the vender. We want
only to clarify one of the standard specification.

In our Logo activity, Logo is not a purpose. We think the means that
Logo accelerates deployment of a universal standards in support of IETF.

We think that it is preferable to examine a standard specification with
IETF (on this ML and meeting) and to clarify it with RFC. The test
specification of Logo will follow it.

To our regret, I cannot participate in next IETF.
However, other members have the possibility of participating.

Best regards
---
Kiyoaki KAWAGUCHI

---

From: Vijay Devarapalli <[email-masked]>
Date: Mon, 09 Oct 2006 14:12:51 -0700

>>    implicit mode, home address derived from the Mobile Network Prefix, and

sounds good to me.

Vijay

---

From: "K.Kawaguchi" <[email-masked]>
Date: Tue, 31 Oct 2006 10:00:46 +0900

Hi all and Vijay-san,

Thank you for answer.
# I'm sorry the delay.

To our regret, The IPv6 Logo Committee NEMO staffs cannot participate in
the next meeting. Instead of participation, I made text for the next
IETF meeting.

We have already gotten some opinions. We hope to obtain the conclusion
at the meeting. We want to examine only the conclusion at the meeting,
because the meeting have not much time.
If you have an additional opinion, please send it to ML before the
meeting.

Best regards
---
Kiyoaki KAWAGUCHI

---

From: "K.Kawaguchi" <[email-masked]>
Date: Tue, 31 Oct 2006 11:44:23 +0900

Hi all,

I'm sorry, the text is updated because the opinion from staff of v6LC
was received by the timing gap, 

Some sentences were changed, and it explains the policy of the Logo
program of Nemo.

Best regards
---
Kiyoaki KAWAGUCHI

In message <[email-masked]>
"Re: [nemo] About Test Specification in IPv6 Ready Logo"