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

From: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 8 Aug 2011 15:13:17 -0700

Hi Alex.  At this point, I don't think we should debate DHCPv4-based vs NEMOv4-based prefix allocation.  Given your implementation does not support explicit mode, the issue identified with the draft would not be encountered.

Kent

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Alexandru Petrescu
Sent: Wednesday, June 29, 2011 3:08 AM
To: [email-masked]
Subject: Re: [Mip4] AD review of draft-ietf-mip4-nemov4-dynamic

Le 20/06/2011 21:46, Jari Arkko a écrit :
> 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.

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

>
> Jair
>
> Kent Leung (kleung) kirjoitti:
>> 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
>>
>> 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
>>
>

-- 
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: "Kent Leung (kleung)" <[email-masked]>
Date: Mon, 8 Aug 2011 15:14:37 -0700

Hi Jari.  Should we proceed forth with this draft after the discussion
on the raised issue?

Kent

-----Original Message-----

I have reviewed this draft. I think it is short, well written and ready 

...
...

> 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