[Mipshop] Re: Review of draft-ietf-mipshop-fmipv6-rfc4068bis-02.txt

[Rajeev Koodli <[e-mail]>]

On 7/19/07 2:58 PM, "ext James Kempf" <[e-mail]> wrote:
> 
> Rajeev:> the initial justification is not the reason why we are using
> UNA/NAACK. UNA is not a new message, it's short for Unsolicited Neighbor
> Advertisement as in RFC 2461. 4068bis is specifying that such a message be
> sent upon attaching to NAR. NAACK is an option in RA.
> 
> We had a long discussion on the topic after 4068 was published on this. You
> should really consult the ML before jumping into things here. Briefly,
> 4068bis can be implemented w/o ODAD, which is specifying extensions to 2461
> and 2462. Folks have implemented 4068 (e.g., fmipv6.org, Tarzan) and
> provided input, which is taken into consideration in 4068bis.  Finally, if
> you would like to use ODAD, you can do that with 4068bis (please read the
> draft Syam Madanapalli and I wrote on using fmip with dna a while ago).
> 
> jak>> Yes, I remember the discussion well. I was not in agreement with using
> something other than ODAD then and I am not in agreement with it now. If
> there is a simple way to reduce the amount of complexity by using ODAD
> (which, from the looks of it, Syam has documented) then I think it should be
> made part of the base protocol. The less complexity, the less likely
> something will go wrong and the easier it will be to implement. Also, having
> FMIP well-integrated into well known and widely used link configuration
> protocols will make it easier to understand.

I am guessing that your impression of "complexity" is stemming primarily
from Section 5.5. What if I move most of that expository text to the
appendix and replace it with some text that in essence says "if NAR detects
an entry in NCE for NCoA, send an RA with NAACK"? Because, other than that,
we are not doing anything else.

Note that we a) got rid of FBU encapsulation guideline, and b) deprecated
FNA. 

> 
> jak>> Note that I am *not* proposing that DNA be made part of the base
> protocol, clearly that can be optional. But ODAD and DNA are two different
> protocols.
> 

I understand that clearly.

> 
> 
> Rajeev:> From Section 6.4.6, I assume you are referring to the Status values
> 1,2 and 3 in NAACK. These values are not there because of address collision
> alone. Example: a MN has configured NCoA using the aggregate prefix
> advertised in PrRtAdv, but the link uses per-MN (/64) prefix. (See a draft
> by Frank Xia on ptp links). In this case, the base spec can support an NCoA
> using the per-MN prefix in the RA using NAACK (Status value 2 in NAACK).
> 
> The text "The NAR responds to UNA with the NAACK option to notify the MN
> to use a different NCoA if there is address collision." needs to be revised
> to reflect the above.
> 
> jak>> Is there some deployment reason why the PrRtAdv would advertise
> something other than what the link actually supports? Shouldn't a per-MN
> prefix come back from the NAR via the HAcK if the MN is configuring to the
> new link and the new link supports per MN prefixes? I think it should be
> part of the protocol that if the link uses per-MN prefixes, these should be
> advertised in the PrRtAdv. I mentioned something about some tweaks to the
> currently documented mechanism to make that easier below.
> 

Advertising per-MN prefixes is one way to do it. However, this requires the
routers to keep track of prefix for each MN.
My point is the base spec can be used to accomplish what you need in this
case. We don not want to specify exactly how this is done, since it is (like
others) deployment specific.

> 
> Rajeev:> I don't know if it has crossed your thinking or not, but ODAD does
> not specify what to do if there is a collision. In a nutshell, it is
> specifying how to issue an NS and an RS with a tentative address. _We_ are
> concerned about getting packets from the PAR, which is on a different
> subnet, to the current location of the MN. We do some obvious rudimentary
> checking at NAR while processing the UNA message, just as in 2461, _and_
> report the outcome in NAACK _when_ necessary.
> 
> jak>> The statistical probability of an address collison in the absence of a
> deliberate attack is lower than the probability that a frame is dropped on
> wired ethernet. So that means, for 802.11 for example where the probability
> of droppage is even higher, the probability that the UNA or NAAK gets
> dropped is higher than the probability of a collision, meaning the MN won't
> find out about it. Putting all that additional mechanism in for such a low
> probability event doesn't make sense to me.

Which additional mechanism? Sending NAACK?
We need it even when not reporting any collision case as I explained above.
(Status values 2 in NAACK).

As I mentioned above, I can move much of the text in 5.5 to appendix.

> 
> jak>> If an attack occurs, then the UNA isn't going to help, since the
> attacker can watch for and respond to the UNA, which is multicast. The
> solution for that if ODAD is used is to use a CGA and sign the ODAD NA.
> 

I think you told me that CGA works for NA. So, the same should work for UNA
as well; UNA can be unicast to the router.

> jak>> Anyway, like I said, we have discussed this already and I doubt
> whether you are likely to change your position, and I am not about to change
> mine (namely "simpler is better"). If this remains in the document when it
> is submitted to the IESG, I'd like the IESG document writeup to indicate
> that there was disagreement in the WG about UNA/NAACK (Vijay, please note).
> 

Ahem.. It's what the WG wants. For instance, fmipv6.org folks who
implemented 4068 didn't want to implement another protocol. Please go back
to archives and take a look.

> 
> Rajeev:> I read Section 5.5 again. As far as I could tell, the intent is
> _not_ to specify _how_ an AR could maintain a pool of conflict-free
> addresses. But to qualitatively explain what happens _when_ an AR maintains
> such a pool. So, I don't see where we are defining a new method for an AR to
> come up with a pool of addresses.
> 
> jak>> But the text does, in fact, discuss having an AR maintain such a pool.
> This is a basic change to the fundamental local link architecture. The
> Neighbor Cache in 2461 is soft state. What this is saying is to make that
> hard state, absent a careful consideration of the implications and possible
> ways to mitigate the drawbacks of hard state. Not such a good idea, IMO.
> 

Well, I guess I will read again. You could also help me by pointing out the
text where it gives this impression, and suggest alternate text.

I didn't follow the stuff about soft state hard state. Last I remember, MIP4
has visitor list entry, which stays longer ("hard state"). That might be
another thread..


> 
> Rajeev:> an AR has an address that it can offer to a MN. How it has got it,
> what it does in a specific deployment scenario are not specified here.
> 
> If you have better text, please suggest. I will be glad to look into it and
> incorporate it.
> 
> 
> jak>> Then why not simply say that? Why not say "There are a variety of ways
> the NAR can proxy an address for the MN on the new link. The details of how
> that is done are outside the bounds of this specification."
> 

Ok.

> 
> Sorry, which sentence are you referring to?
> 
> jak>>  Ah, sorry, I got the wrong sentence. This one:
> 
>    "Finally, the access
>     routers could transfer network-resident contexts, such as access
>     control, QoS, header compression, in conjunction with handover."
> 
> jak>> I'd suggest:
> 
>    "Finally, the access
>     routers could transfer network-resident contexts, such as access
>     control, QoS, header compression, in conjunction with handover,
>      although the details about how to combine these operations
>      with HI/HAck are out of scope of this document."
> 

Ok.

> 
> I will see; at the same time, I don't wish to overuse it :-)
> 
> jak>> It's not a question of overuse. When doing interoperability testing,
> features marked MUST become "required to implement" and failure of
> interoperability on those features means that a particular protocol
> implementation fails conformance to the standard. SHOULD and MAY are
> "optional to implement" but if implemented, they should be interoperable. So
> consideration needs to be made about what features are necessary to be
> required to implement (i.e. the protocol fails to operate correctly without
> them) and which are optional (i.e. the protocol works less well or is not
> applicable in some cases). In the particular case cited, it seems to me that
> the protocol would, in fact, fail to operate correctly unless the feature
> was properly implemented.

I understand 2119 terms.

> Where this is a concern, noting that it is highly improbable, use HI and
> Hack, so that NAR can proxy the address until UNA is received. Description
> under bullet 1 says just that.
> 
> jak>> Right, but the paragraph before that implies that one could deploy the
> protocol for predictive handover *without* using HI/HAcK to confirm the
> NCoA. I think this needs to be changed to say that this is not allowed, that
> is, for correct operation of the protocol, all predictive NCoA configuration
> requires that the NAR confirm uniqueness and proxy the address until the MN
> shows up on the new link.
> 

It is clear that HI/Hack exchange is needed where the collision is a
concern. Where it is not, the concern is the same as in ODAD; you could send
a BU with a tentative address and traffic could go to an unsuspecting node
when using ODAD, and there are no preventive mechanisms. It is considered
such a case is unlikely however. The same applies with 4068bis.
  
> 
> Again, we and ODAD work under the assumption that collision probability is
> miniscule. ODAD does not specify recovery, but has some text showing how
> recovery is possible. I have done the same here (i.e., illustrate how
> recovery happens when using the protocol _if_ a collision happens.
> 
> jak>> See above. And, as I mentioned, FMIP is an optimization. Given the
> minuscule chance that address uniqueness fails, the MN can simply forgo the
> optimization. The recovery operation is complex and unnecessary, IMO.
> 

As I mentioned above, the recovery operation is send a NAACK in an RA. We
cannot get rid of NAACK because NAACK can be used to provide an address to
the MN (i.e, whatever NAR has proxied earlier on). We can move most of the
text in 5.5 to appendix.


> 
> I don't know. Perhaps we should establish a new registry?
> 
> jak>. Hmm. I think you need to check with IANA about this. I don't think a
> new registry is necessary. I don't really think it matters if the same
> number is used, but it probably ought not to be called experimental in that
> case. Maybe Jari can provide some guidance.

Ok.

> 
> I have thought about it earlier.. The MN needs NAR's IP address and the
> prefix on the new link. When NAR's IP address is derived from the same
> prefix that's advertised on-link, the prefix information option need not be
> present. The spec says it under 6.1.2 - New Router Prefix Info Option.
> When they are not (for whatever reason), the MN needs both.
> 
> jak>> I'm not sure I understand the issue. What's the problem with sending
> both? I'm not saying to merge the use, I'm saying to merge the Option types
> so there is one option that can be either a prefix or a full address,
> depending on the size. If the MN needs a prefix and an address, then two
> instance of the option would be sent. It could look exactly like the current
> IP address option. Whether or not it's a prefix should be apparent from
> whether or not there are any one's in the last 128 - n (or 128 - n - k if
> the prefix is shorter than a full subnet prefix) bits, where n is the value
> of the Prefix Size field. Alternatively, an additional field could be added
> to specify the number of valid bits.
> 

I think I agree with you. We could use a different Option-Code for Prefix to
simplify processing.


> jak>> Yes its:
> 
> http://www.iana.org/assignments/card-parameters
> 

Thanks.


> 
> Our previous discussion seems to concluded that signaling algorithm agility
> should be an option in the protocol that establishes the SA. FBU only makes
> use of the SA, so SPI should be enough to point out what algorithm to use.
> 
> jak>> Hmm, well, the SEND key is named by the CGA and if algorithm agility
> is part of the key provisioning negotiation then I suppose you are right.
> The key will have its prenegotiated algorithm type recorded along with the
> name.

Ok.

-Rajeev
-- 
http://people.nokia.net/~rajeev




_______________________________________________
Mipshop mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/mipshop