Subject: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic

From: Jari Arkko <[email-masked]>
Date: Sun, 19 Jun 2011 08:25:33 +0300

I have reviewed this draft. I think it is short, well written and ready 
to move forward with the exception of one issue:

> According to this specification, a Mobile Router MAY include one or
> more mobile network request extensions with the prefix field set to
> zero. 
...
> In this case, the Mobile Router MAY set the
> prefix length field of such extensions to zero or to a length of its
> choice as a hint to the home agent.
...
> If in response to a registration request with a mobile network
> request extension with the prefix field set to zero, a Mobile Router
> receives a registration reply with a network acknowledgement
> extension including Code field set to 1 "invalid prefix", it may use
> it as a hint that the home agent does not support dynamic prefix
> allocation.
>   

But RFC 5177 says:
> When the prefix
> length is zero or greater than decimal 32, the status Code MUST be
> set to MOBNET_INVALID_PREFIX_LEN.
>   

I think the model for backwards compatibility needs work. Specifically, 
if the mobile router uses a non-zero prefix length as a hint, it may 
happen that a plain RFC 5177 implementation thinks its a real prefix 
request, mistakenly inserts the prefix (with zero bits) to some routing 
table somewhere but does not check that this causes an error or 
undefined behavior. There is no text in RFC 5177 that asks to check for 
zero bits.

I see a few possibilities to fix this problem.

1) Convince ourselves that existing NEMOv4 implementations do in fact 
check for zero, despite RFC 5177 text.

2) Drop the prefix size hint functionality from this draft.

3) Move the prefix size hint to a new optional attribute that is carried 
separately in the requests.

Do you agree that this is a problem, or am I missing something obvious? 
If this is a problem, what does the working group want to do?

Jari

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 20 Jun 2011 12:32:31 -0700

Hi Jari.  Thanks for the thorough review.  Good catch. :) I would like
to confirm my understanding of the issue.

1) RFC 5177 checks the validity of Prefix Length field in the Mobile
Network Request Ext.  This value cannot be "zero or greater than decimal
32".  So there is no backwards compatibility issue.  In fact, the draft
uses this check to confirm HA does not support the dynamic feature based
on the return code 1 "invalid prefix length".

2) The backwards compatibility issue arises when the prefix is zero and
non-zero prefix length is used as a hint by MR.  In this case, HA cannot
tell the difference between RFC 5177 explicit mode and this draft's
dynamic hint mode.  The HA may inadvertently process network prefix zero
for routing setup.  This is likely not a problem because existing
NEMOv4-based implementation performs sanity check on prefix zero.
Though I agree that the case is not explicitly specified in the RFC.

Based on your suggested fixes, I would prefer #1 since the problem with
backward compatibility won't likely happen.  #2 would be my next choice
if folks feel strongly against #1.

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of
Jari Arkko
Sent: Saturday, June 18, 2011 10:26 PM
To: [email-masked]; Mobile IPv4 Mailing
List
Subject: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic

...
...

Jari

-- 
Mip4 mailing list: [email-masked]
    Web interface: https://www.ietf.org/mailman/listinfo/mip4
     Charter page: http://www.ietf.org/html.charters/mip4-charter.html
Supplemental site: http://www.mip4.org/

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Jun 2011 22:46:13 +0300

Yes, your understanding is correct as far as I can tell. Do you know 
_all_ nemov4 implementations? If you think you are aware of all of their 
behaviour, and they all check for zero bits, then we should go with 
solution #1.

Jair

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 20 Jun 2011 13:10:52 -0700

Obviously, I cannot speak for all implementations.  I only know about
the commercial deployment of Mobile IP standards based mobile network
technology on Cisco routers and MIP agents.  As for the logic of
allowing prefix zero, this would be quite problematic due to the
non-deterministic nature of multiple MRs registering such a prefix to
the HA.  In general, there are a bunch of issues with prefix zero that
is redistributed via routing protocols by HA.  Maybe we can go with #1
due to the possible calamity with any HA allowing prefix zero?  Such
implementation needs to be fixed anyways... ;)

Kent

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Monday, June 20, 2011 12:46 PM
To: Kent Leung (kleung)
Cc: [email-masked]; Mobile IPv4 Mailing
List
Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic

Jair

---

From: Jari Arkko <[email-masked]>
Date: Mon, 20 Jun 2011 23:15:29 +0300

Kent Leung (kleung) kirjoitti:
> technology on Cisco routers and MIP agents.

OK. Do you know of other implementations, even if you do not know their 
behavior?

Others, what other implementations are there? What do they do?

> As for the logic of

That's a possible argument, yes.

Jari

---

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 20 Jun 2011 13:19:12 -0700

-----Original Message-----
From: Jari Arkko [mailto:[email-masked]] 
Sent: Monday, June 20, 2011 1:15 PM
To: Kent Leung (kleung)
Cc: [email-masked]; Mobile IPv4 Mailing
List

KL> I'm not aware of other NEMOv4-based implementations used in
deployment.  There are commercial deployments that do not used NEMOv4.
So can't help there.

KL> Bug fix. :)

Kent

Jari

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Jun 2011 12:03:28 +0200

Le 20/06/2011 21:32, Kent Leung (kleung) a écrit :
> Hi Jari.  Thanks for the thorough review.  Good catch. :) I would
> like to confirm my understanding of the issue.
>
>  Network Request Ext.  This value cannot be "zero or greater than
> decimal 32".  So there is no backwards compatibility issue.  In
> fact, the draft uses this check to confirm HA does not support the
> dynamic feature based on the return code 1 "invalid prefix length".
>
> 2) The backwards compatibility issue arises when the prefix is zero
> and non-zero prefix length is used as a hint by MR.  In this case,
> HA cannot tell the difference between RFC 5177 explicit mode and
> this draft's dynamic hint mode.  The HA may inadvertently process
> network prefix zero for routing setup.  This is likely not a problem
> because existing NEMOv4-based implementation performs sanity check on
> prefix zero. Though I agree that the case is not explicitly specified
> in the RFC.
>
> Based on your suggested fixes, I would prefer #1 since the problem
> with backward compatibility won't likely happen.  #2 would be my
> next choice if folks feel strongly against #1.

As I understand it, I prefer to use #2 "Drop the prefix size hint
functionality from this draft.".

The reason I prefer so is manyfold:

It is sufficient to put 0 in the prefix (not the length) to make it look
like a request, and ignore the prefix length altogether.  It's not
necessary to reinforce the 0 in prefix with another 0 in len to make it
sound like a "request" as opposed to prefix non-zero being "imposed".

It is good to make prefix allocation with DHCP subnet allocation
recently resurrected draft-ietf-dhc-subnet-alloc rather than with
MIP4/NEMOv4.  I am saying so after experimenting with DHCPv6 prefix
delegation for MIPv6/NEMOv6 (rather than MIPv6-based prefix allocation
for NEMOv6).

Prefix 0/length0 has a special meaning in IPv6 (not sure in IPv4) - it
means "default route" by RFC.  This is a different meaning than
requesting prefix allocation.

Alex

>
> Kent
>
>
> -----Original Message----- From: [email-masked]
> [mailto:[email-masked]] On Behalf Of Jari Arkko Sent:
> Saturday, June 18, 2011 10:26 PM To:
> [email-masked]; Mobile IPv4 Mailing
> List Subject: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic
>
> I have reviewed this draft. I think it is short, well written and
> ready to move forward with the exception of one issue:
>
>> In this case, the Mobile Router MAY set the prefix length field of
>> such extensions to zero or to a length of its choice as a hint to
>> the home agent.
> ...
>> request extension with the prefix field set to zero, a Mobile
>> Router receives a registration reply with a network acknowledgement
>> extension including Code field set to 1 "invalid prefix", it may
>> use it as a hint that the home agent does not support dynamic
>> prefix allocation.
>>
>
> But RFC 5177 says:
>> When the prefix length is zero or greater than decimal 32, the
>> status Code MUST be set to MOBNET_INVALID_PREFIX_LEN.
>>
>
> I think the model for backwards compatibility needs work.
> Specifically, if the mobile router uses a non-zero prefix length as
> a hint, it may happen that a plain RFC 5177 implementation thinks its
> a real prefix request, mistakenly inserts the prefix (with zero
> bits) to some routing table somewhere but does not check that this
> causes an error or undefined behavior. There is no text in RFC 5177
> that asks to check for zero bits.
>
> Do you agree that this is a problem, or am I missing something
> obvious? If this is a problem, what does the working group want to
> do?
>
> Jari
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Jun 2011 12:07:50 +0200

> behaviour, and they all check for zero bits, then we should go with

Our NEMOv4 implementation does not use explicit mode, but only the 
implicit mode (i.e. no prefix in the RegReq).  As such there is no means 
for our HA to check for a request of prefix allocation.

Currently I am divided between trying DHCP subnet allocation or NEMOv4 
prefix allocation.

Alex

>> Specifically, if the mobile router uses a non-zero prefix length as a
>> hint, it may happen that a plain RFC 5177 implementation thinks its a
>> real prefix request, mistakenly inserts the prefix (with zero bits) to
>> some routing table somewhere but does not check that this causes an
>> error or undefined behavior. There is no text in RFC 5177 that asks to
>> check for zero bits.
>>
>> obvious? If this is a problem, what does the working group want to do?
>>
>> Jari
>>
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 29 Jun 2011 12:11:32 +0200

Le 20/06/2011 22:19, Kent Leung (kleung) a écrit :
>
>
> -----Original Message----- From: Jari Arkko
> [mailto:[email-masked]] Sent: Monday, June 20, 2011 1:15 PM To:
> Kent Leung (kleung) Cc:
> List Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic
>
>> Obviously, I cannot speak for all implementations.  I only know
>> about the commercial deployment of Mobile IP standards based mobile
>> network technology on Cisco routers and MIP agents.
>
> OK. Do you know of other implementations, even if you do not know
> their behavior?
>
> deployment.  There are commercial deployments that do not used
> NEMOv4. So can't help there.

Hm.

This year there have been demoed trials for public transportation, with
press and commercial interests which do use NEMOv4.  The implementation
was from us not from Cisco.

But.  This is an ongoing reality check that we should bear in mind.
During several recent years there exist an increasing number of
commercial real deployments with sold product which look very much like
what we call "moving networks" and thus very pertinent to Mobile IP, but
not using Mobile IP nor NEMOv4.

Alex

>> As for the logic of allowing prefix zero, this would be quite
>> problematic due to the non-deterministic nature of multiple MRs
>> registering such a prefix to the HA.  In general, there are a bunch
>> of issues with prefix zero that is redistributed via routing
>> protocols by HA.  Maybe we can go with #1 due to the possible
>> calamity with any HA allowing prefix zero?  Such implementation
>> needs to be fixed anyways... ;)
>>
>