Subject: RE: [Mipshop] FNA in the current spec

From: "Soliman, Hesham" <[email-masked]>
Date: Mon, 22 Aug 2005 14:21:19 -0400

James,

 > The current spec was supposed to handle duplicates. 

=> The current spec has nothing to do with address duplication. 
No more than its reliance on DAD, which is defined elsewhere.
If address duplication takes place then DAD will take care of it
as well as it can (not perfectly). 

Hesham

Are you 
 > saying it 
 > doesn't, or that you've not QA'ed your implementation to 
 > check how it 
 > handles them?
 > 
 >             jak
 > 
 > ----- Original Message ----- 
 > From: "Emil Ivov" <[email-masked]>
 > To: "James Kempf" <[email-masked]>
 > Cc: <[email-masked]>; "Rajeev Koodli" 
 > <[email-masked]>; 
 > "Soliman, Hesham" <[email-masked]>; <[email-masked]>
 > Sent: Monday, August 22, 2005 11:09 AM
 > Subject: Re: [Mipshop] FNA in the current spec
 > 
 > 
 > >> What happens if there's a duplicate address on the link?
 > >
 > > I was actually giving input (as I thought was requested) 
 > from different 
 > > scenarios with a protocol implementation. I was not 
 > proposing protocol 
 > > modification or optimization. Not in this mail exchange at 
 > least. So if 
 > > your question is along the same lines, i.e. what would 
 > happen in our 
 > > testbed using the fmipv6.org implementation if duplicate 
 > addresses occur, 
 > > then I'd say - I don't know, this didn't happen.
 > >
 > > Emil
 > >
 > >> ----- Original Message ----- 
 > >> From: "Emil Ivov" <[email-masked]>
 > >> To: "Rajeev Koodli" <[email-masked]>
 > >> Cc: "Soliman, Hesham" <[email-masked]>; <[email-masked]>
 > >> Sent: Sunday, August 21, 2005 11:40 AM
 > >> Subject: Re: [Mipshop] FNA in the current spec
 > >>
 > >>
 > >>
 > >>>So here's some more: (sorry for the delay)
 > >>>
 > >>>
 > >>>>The question was do host implementations send an 
 > unsolicited NA after
 > >>>>attaching to a new link or not. I think they don't, but 
 > I wanted some
 > >>>>input.
 > >>>
 > >>>Ah! I was close wasn't I!
 > >>>
 > >>>Anyway - the answer is no. No unsolicited NA is being sent by the 
 > >>>(linux2.6.8.1) IPv6 stack when attaching to a new link.
 > >>>
 > >>>Concerning the other NCE experiments:
 > >>>
 > >>>1) Setting NAR's NCE for the MN to STALE upon reception 
 > of HI- gives the 
 > >>>same behaviour as setting it to REACHABLE. In other words 
 > - no NS is
 > >>>being sent by the NAR when packets, destined to the MN, 
 > start arriving 
 > >>>and they are directly forwarded to NAR's link. The MN 
 > starts receiving 
 > >>>them right after it attaches to PAR's link. This means 
 > that it misses a 
 > >>>few and that no buffering is done since NAR believes that 
 > the MN is 
 > >>>there.
 > >>>
 > >>>2) Not setting NAR's NCE to anything and sending an 
 > unsolicited NA from 
 > >>>the MN upon connection produces the following results. 
 > Packets (in our 
 > >>>case) start arriving prior to MN attachment and trigger 
 > NDisc. An NS is 
 > >>>being sent and in the mean time packets are being 
 > buffered by the IPv6 
 > >>>stack while waiting for a reply to that NS. The MN then 
 > arrives and sends 
 > >>>its unsolicited NA. The fact that it's unsolicited 
 > doesn't seem to make 
 > >>>any difference and it seems to be accepted by the NAR as 
 > a reply to its 
 > >>>NS (btw, the NA almost always comes before a 
 > retransmission of the NS). 
 > >>>This "releases" the buffered packets and the MN gets them 
 > all (or at 
 > >>>least as much as the driver keeps). This is probably the 
 > solution that we 
 > >>>tend to favor performance-wise.
 > >>>
 > >>>3) Not setting NAR's NCE to anything and not sending an 
 > unsolicited NA 
 > >>>and having NAR try to modify its own NC cache from userspace upon 
 > >>>reception of an FNA. Doesn't work cause (as I've pointed 
 > out in my 
 > >>>previous mail) by the time the fmipv6-ar user space 
 > daemon tries to add 
 > >>>an NCE (i.e. as soon as the FNA arrives) there is already 
 > NDisc going on, 
 > >>>trigerred by the tunnelled packets and it seems impossible to 
 > >>>shortcut/override it once it has started. In that case 
 > packets (bufferred 
 > >>>or not) start flowing after the first NS has expired, a 
 > second one is 
 > >>>sent and it gets its reply.
 > >>>
 > >>>Of course all described problems and the above sequence 
 > of events are 
 > >>>highly specific to our testbed. It (the testbed) is quite 
 > roughly a setup 
 > >>>that looks more or less the same way as the RFC diagram 
 > on page 5. The MN 
 > >>>connects to the ARs through 802.11a/b/g wireless lan. and 
 > the ARs are 
 > >>>interconnected with a 100 MBit wired link.
 > >>>
 > >>>Hope this'll be helpful. Let me know if you have any 
 > further questions.
 > >>>
 > >>>
 > >>>Cheers
 > >>>Emil
 > >>>
 > >>>
 > >>>
 > >>>_______________________________________________
 > >>>Mipshop mailing list
 > >>>[email-masked]
 > >>>https://www1.ietf.org/mailman/listinfo/mipshop
 > >>>
 > >>
 > >>
 > >>
 > >>
 > > 
 > 
 > 
 > 

===========================================================
This email may contain confidential and privileged material for the sole use
 of the intended recipient.  Any review or distribution by others is strictly
 prohibited.  If you are not the intended recipient please contact the sender
 and delete all copies.
===========================================================

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

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Aug 2005 11:30:27 -0700

jak>>>>

Section 5.4 paragraph 3 of RFC 4068:

   In some cases, the NAR may already have the knowledge required to
   assess whether the MN's address is a duplicate before the MN moves to
   the new subnet.  For example, the NAR can have a list of all nodes on
   its subnet, perhaps for access control, and by searching this list,
   it can confirm whether the MN's address is a duplicate.  The result
   of this search is sent back to the PAR in the HAck message.  If such
   knowledge is not available at the NAR, it may indicate this by not
   confirming the NCoA in the HAck message.  The NAR may also indicate
   this in the NAACK option in response to the FNA message.  In such
   cases, the MN would have to follow the address configuration
   procedure according to [6] after attaching to the NAR.

So, yes, the DA information is not assured, but it can be used if available.

            jak

---

From: Emil Ivov <[email-masked]>
Date: Mon, 22 Aug 2005 21:01:44 +0200

James,

What I meant to say is that I found your mail unnecessarily sarcastic.

There are currently no mechanisms in the implementation neither at the 
AR nor at the MN that handle DAD. We should be able to address that one 
day but we wanted to clear out basic scenarios first.

In the mean time any propositions as to how _exactly_ this is to be done 
would be most welcome since we haven't really considered how to reliably 
do that.

Cheers
Emil

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Aug 2005 12:48:45 -0700

> What I meant to say is that I found your mail unnecessarily sarcastic.

Sorry, it was meant to be terse, but not sarcastic. The two are sometimes 
hard to distinguish.

> There are currently no mechanisms in the implementation neither at the AR 
> nor at the MN that handle DAD. We should be able to address that one day 
> but we wanted to clear out basic scenarios first.
>

The spec has a paragraph on it. I quoted it in another email.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 22 Aug 2005 15:50:58 -0700

The approach has been not to specify a particular duplicate
handling mechanism, but to allow hooks. For instance, there
was a proposal to keep a pool of duplicate-free addresses (aDAD
I think) at an AR. The protocol itself does not bind to any
one mechanism, but allows transport to signal duplicates or
no-duplicates.

-Rajeev

James Kempf wrote:

>> In the mean time any propositions as to how _exactly_ this is to be 
>> done would be most welcome since we haven't really considered how to 
>> reliably do that.
>>
>

---

From: "James Kempf" <[email-masked]>
Date: Mon, 22 Aug 2005 16:03:19 -0700

I think the issue is whether or not the transport is required (i.e. MUST) 
signal duplicates or not. I think it would simplify the protocol if the spec 
were to take a position on this one way or the other:

- No duplicate signaling, HI/HAck not needed, reduces message complexity but 
node MUST do DAD (even oDAD) on new link possibly delaying packets, small 
but nonzero probability of address clash if the node sends unsolicted NA on 
the new link w.o. completing oDAD,

- Duplicate signaling, HI/HAck needed, more message complexity, lessens 
probability of address clash, unsolicted NA needed only to start packet 
flow, no DAD needed on new link.

Either way, I think predictive information is needed to make it work. If 
there's no predictive information, then DNA RS/RA is the most efficient.

I don't think there is really an issue about whether a link layer supports 
something or not, I think this is just an IP level issue about what 
modifications FMIP requires in the AR.

            jak

----- Original Message ----- 
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>; "Soliman, Hesham" 
<[email-masked]>; <[email-masked]>
Sent: Monday, August 22, 2005 3:50 PM
Subject: Re: [Mipshop] FNA in the current spec

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 22 Aug 2005 16:27:49 -0700

So, the position taken in RFC 4068 is MUST be supported and
SHOULD be used. Any reason to change that? Provide your
reasoning.

Also, I might turn this into text for the issue tracker,
unless you provide some explicit text.

-Rajeev

James Kempf wrote:

> I think the issue is whether or not the transport is required (i.e. 
> MUST) signal duplicates or not. I think it would simplify the protocol 
> if the spec were to take a position on this one way or the other:
> 
> - No duplicate signaling, HI/HAck not needed, reduces message complexity 
> but node MUST do DAD (even oDAD) on new link possibly delaying packets, 
> small but nonzero probability of address clash if the node sends 
> unsolicted NA on the new link w.o. completing oDAD,
> 
> I don't think there is really an issue about whether a link layer 
> supports something or not, I think this is just an IP level issue about 
> what modifications FMIP requires in the AR.
> 
>            jak
> 
> ----- Original Message ----- From: "Rajeev Koodli" <[email-masked]>

---

From: Emil Ivov <[email-masked]>
Date: Tue, 23 Aug 2005 01:39:50 +0200

When you say HI/HAck (not) needed do you mean so for DAD or in general? 
HI/HAck could serve as transport for more than just detecting 
duplicates. NAR may have other reasons to refuse the MN  and the NC 
problem that I gave in my other e-mails is another example of their use.

So if we agree that these (HI/HAck) are nice to have then why not using 
them for possible duplicate detection too. Making that the only and 
mandatory way of DADding however would add lots of complexity, to AR 
implementations since (if it is to be reliable)  they'd have to keep a 
pool of used addresses that would need to be authentic at all times, and 
one could see many issues here: nodes that left without ARs knowledge, 
and wanting to come back. Nodes that do have a duplicate address but the 
NAR is for some reason (no fmip (or other ext) support or being inactive 
for a long time) unaware of them.

Mandating oDAD on the other hand would add complexity for MN impls.

Isn't there any third option?

Emil

---

From: Rajeev Koodli <[email-masked]>
Date: Mon, 22 Aug 2005 16:45:53 -0700

Yes, it is important to bear in mind that HI/HAck can
be used for other purposes as well.

-Rajeev

Emil Ivov wrote:

>> - No duplicate signaling, HI/HAck not needed, reduces message 
>> complexity but node MUST do DAD (even oDAD) on new link possibly 
>> delaying packets, small but nonzero probability of address clash if 
>> the node sends unsolicted NA on the new link w.o. completing oDAD,
>>
>> - Duplicate signaling, HI/HAck needed, more message complexity, 
>> lessens probability of address clash, unsolicted NA needed only to 
>> start packet flow, no DAD needed on new link.
>>
>> Either way, I think predictive information is needed to make it work. 
>> If there's no predictive information, then DNA RS/RA is the most 
>> efficient.
>>
>> supports something or not, I think this is just an IP level issue 
>> about what modifications FMIP requires in the AR.
>>
>>             jak
>>
>>>>> done would be most welcome since we haven't really considered how 
>>>>> to reliably do that.
>>>>>
>>>>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Aug 2005 08:51:30 -0700

> HI/HAck could serve as transport for more than just detecting duplicates. 
> NAR may have other reasons to refuse the MN  and the NC problem that I 
> gave in my other e-mails is another example of their use.
>

I think it would help to clearly enumerate what other functions the HI/HAck
perform, relevant directly to FMIP. There are some outside functions, like
serving as a vehicle for context transfer, that are useful but should be
kept seperate . That is, I don't think the outside functions should be used
as the primary motivator for including these messages in the protocol,
though I think they could be considered if there is enough basic reasons to
keep HI/HAck.

> pool of used addresses that would need to be authentic at all times, and I 
> could see many issues here: nodes that left without ARs knowledge, and 
> wanting to come back. Nodes that do have a duplicate address but the NAR 
> is for some reason (no fmip (or other ext) support or being inactive for a 
> long time) unaware of them.
>

No need to keep a pool of addresses. If autoconfiguration is used, with
predictive handover the PAR sends the nCoA to the NAR in the HI, and the NAR
performs Proxy DAD on it. If nobody answers, the NAR sends HAck back with an
OK, proxies the address until the MN shows up. Proxy ND is part of 2461.
There are security issues, since proxy ND isn't covered by SEND, but there
are a bunch of ways around them (I gave a short talk at MOBOPTS last time on
one way).

Let's also not forget about the link local address. To really obtain
complete assurance of no duplicates, the HI would also need to carry a link
local address for the MN. The link local address will always be
autoconfigured.

> Mandating oDAD on the other hand would add complexity for MN impls.

oDAD is very simple. Most IPv6 MNs have the basic code since it is really
just a simplification of current DAD with no additional messaging. But the
problem with using oDAD is that the NAR can't send packets to the MN's link
address prior to completion of oDAD, and oDAD requires that the MN perform
DAD just as in 2461, except it can *send* while it is doing so. So any
incoming packets are delayed on the router until the MN completes oDAD. The
MN can't send a SLLAO in an NA as a response to an NS from the NAR until the
oDAD completes. It also can't send a proactive NA to the NAR. At least, if
we want to assure that duplicates are taken into account, despite the low
probability of them occuring.

Stateful configuration is the more complex issue, as you have mentioned. I
can think of a bunch of ways it could be approached:

1) Have the NAR maintain a pool of addresses, as you mention. When the HI
comes in, it picks one out, then sends it back in the HAck.
2) Have the NAR perform proxy DHCP on behalf of the MN when the HI arrives,
send the HAck back with the address.
3) Have the MN tunnel DHCP requests to the new link. The MN could do this
proactively every time it discovered a new NAR, kind of like
preauthentication in 802.11r. From an architctural standpoint, this would
probably be the preferred approach. Or the PAR and NAR could act as a DHCP
relay.
4) Run the DHCP request through a tunnel over HI/HAck.
5)  Forget about address preconfiguration with stateful. When the MN moves
to the new link, it must perform DHCP. So, in the stateful case, handovers
become reactive.

None of these is particularly appealing, but I don't think the spec deals
with stateful configuration very well (if at all) currently.

            jak

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Aug 2005 09:20:52 -0700

I think there are two issues for the issue tracker:

1) Re-examine the justification for FNA in light of oDAD and other 
developments to see if it is still needed.
2) Remove the ambiguity surrounding HI/HAck, and either clearly define why, 
when and how it is used, or drop it.

I think it will require some discussion and maybe some implementation 
experiments before we can come to a conclusion about how to resolve these 
issues.

            jak

----- Original Message ----- 
From: "Rajeev Koodli" <[email-masked]>
To: "James Kempf" <[email-masked]>
Cc: <[email-masked]>; "Soliman, Hesham" 
<[email-masked]>; <[email-masked]>
Sent: Monday, August 22, 2005 4:27 PM
Subject: Re: [Mipshop] FNA in the current spec

>> signal duplicates or not. I think it would simplify the protocol if the 
>> spec were to take a position on this one way or the other:
>>

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Aug 2005 10:16:27 -0700

I am glad to see someone thinking about the
issue tracker :-)

> developments to see if it is still needed.

Ok. This already being discussed from an implementation perspective. 
And, I will enter it in the issue tracker.
It is more to do with how NAR forwards packets than with
address duplication or oDAD. What we need minimally is a statement
requiring the MN to send an unsolicited NA (with 'O' flag cleared) as 
soon as attachment to NAR's link occurs. What we call this and whether
we allow this NA to have the option of requesting NAR's ND cache entry 
to be set to REACHABLE is to finalized. (Please see related input from
implementors).

> 2) Remove the ambiguity surrounding HI/HAck, and either clearly define 
> why, when and how it is used, or drop it.

Can we rephrase this "clarify the role of HI/HAck in address duplication
handling"?

As an implementor pointed out, at least some folks may want to have 
them. And, they are not required to be used even in the current spec.

Thanks,

-Rajeev

> experiments before we can come to a conclusion about how to resolve 
> these issues.
> 
>            jak
> 
>>> MUST) signal duplicates or not. I think it would simplify the 
>>> protocol if the spec were to take a position on this one way or the 
>>> other:
>>>
>>>>>> In the mean time any propositions as to how _exactly_ this is to 
>>>>>> be done would be most welcome since we haven't really considered 
>>>>>> how to reliably do that.
>>>>>>
>>>>>

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Aug 2005 10:27:14 -0700

> Can we rephrase this "clarify the role of HI/HAck in address duplication

Sure.

> As an implementor pointed out, at least some folks may want to have them. 
> And, they are not required to be used even in the current spec.
>

Well, I think we do need to figure out if they are required or not and then 
not have them in the spec if they are not required. Like I said, I don't 
think this is an issue that depends on what capabilities are at the link 
layer. I think it is a straightforward case of what changes FMIP requires on 
the ARs (and to a lesser extent, the MN).

            jak

---

From: Emil Ivov <[email-masked]>
Date: Tue, 23 Aug 2005 19:30:07 +0200

> kept seperate. That is, I don't think the outside functions should be used

Here're a few that I could rapidly think of: (all apply to the 
predictive case)
1) Letting NAR know that an MN is coming so that it could if it wants to 
  do anything about that (e.g. creating an NCEntry) that would optimize 
the handover.

2) Give NAR the chance to refuse the handover, and not only because of 
DAD ... there could be many reasons for refusing an MN in your net. 
Resource overload, security ... I am sure you could think of more.

3) Verify that the NAR is still there.

4) Provide an extension point for future work on FMIP. The hack could 
server as a transport for data that the NAR would want to tell the MN 
before it comes to its net. And I'm thinking about purely handover 
related stuff not outside functions.

5) And of course - context transfer.

> OK, proxies the address until the MN shows up. Proxy ND is part of 2461.

We were actually thinking about adopting that approach at one point but 
we couldn't think of a way to do DAD fast enough, i.e. before the FBU 
transaction expires at the MN side. Besides if an MN has sent an FBU and 
wants to do predictive handover, chances are that it won't be willing to 
wait for the NAR as it might lose connectivity.

> oDAD is very simple. 

Absolutely! But it intervenes on a very low level. Implementors would 
therefore have to implement it kernel space, then distribute their 
implementations together with a modified kernel, and possible port their 
impls to new kernels, at least long enough for oDAD to be merged in main 
line kernels. Now I am not sure to what extent this argument applies, 
since once again its purely implementational. Depends on what goals u 
have for FMIP adoption - i.e. how long are you willing to wait.

> Most IPv6 MNs have the basic code since it is really
> just a simplification of current DAD with no additional messaging. 

It's not really a matter of how simple is the algorithm, but how simple 
it is to have it as a standard part of IPv6 impls.

> But the problem with using oDAD is that the NAR can't send packets to the MN's link
> incoming packets are delayed on the router until the MN completes oDAD. 

Agree.

> comes in, it picks one out, then sends it back in the HAck.

That would burden administration as one would have to take care for 
address assignment on multiple levels and the probability that this 
could lead to address duplication is greater thant it would be by simply 
shortcuting dad.

> send the HAck back with the address.

Once again, there's the problem of the FBU transaction expiring as we 
already have the HI/HAck exchange in it. Aren't u afraid that adding 
more RTTs and processing time would make the outcome quite unpredictable?

> probably be the preferred approach. Or the PAR and NAR could act as a DHCP

This one seems nice.

> 4) Run the DHCP request through a tunnel over HI/HAck.

Same problem as 1) isn't it

Cheers
Emil

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Aug 2005 10:49:27 -0700

> oDAD is very simple. Most IPv6 MNs have the basic code since it is really

My strong preference is to keep the set of normative references small, 
and limit it to specs like 2460, 2461, 3775..
I do believe that the FMIP protocol should be self-contained as much
as possible.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Aug 2005 11:01:59 -0700

Rajeev,

> My strong preference is to keep the set of normative references small, and 
> limit it to specs like 2460, 2461, 3775..

While I think this is a laudable goal and certainly every protocol designer 
tries to do this, I think in the case of FMIP it touchs too much of the 
functionality of ND to really get away with leaving the interactions 
undefined. I think we need to define them and if we need something like 
oDAD, I think we should use it. I believe oDAD is now in IETF last call and 
will go to PS well before FMIP does, so I think we should really try to use 
it if we can.

Another candidate is DNA, which could be quite useful when there is no 
predictive information available, but currently the DNA WG is somewhat 
bogged down, so avoiding a normative reference in the spec would probably be 
best. We can recalibrate if the WG gets unbogged.

Emil's implementation considerations are certainly an issue, but I don't 
think we should add extra complexity or leave something ambiguous just 
because we want to avoid normative references or because some kind of kernel 
change is needed. I'd like to see FMIP be well-defined and well-designed. If 
it is, I think people will implement it because its good.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Aug 2005 11:04:19 -0700

> 5) And of course - context transfer.

(with the editor hat off) My additions:

1. Access control: NAR may not wish to forward packets for the MN 
without indication from another trusted peer.
1. Allow NAR to validate its NCE, especially the MN's LLA
2. Buffering: I don't want to change my ND buffer size for all nodes.
(the required buffer size for address resolution is small. Making that
large affects all nodes not just the MN, and possibly opens up the 
resource exhaustion DoS attack on an AR).

I don't know to what extent these need to be mandated. I am thinking of
having a section where these functions are enumerated. And those 
interested in them are expected to implement them. Comments?

> implementations together with a modified kernel, and possible port their 

This is a very good point. I know MIPL had to redo their implementation 
of MIPv6 in userland in order to be able to make it to Linux 
distribution. (I don't know that current status of distribution however)

-Rajeev

---

From: Emil Ivov <[email-masked]>
Date: Tue, 23 Aug 2005 20:10:42 +0200

> resource exhaustion DoS attack on an AR).

Good point!

> interested in them are expected to implement them. Comments?

Agreed.

Emil

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Aug 2005 11:22:34 -0700

Jim,

James Kempf wrote:

> While I think this is a laudable goal and certainly every protocol 
> designer tries to do this, I think in the case of FMIP it touchs too 
> much of the functionality of ND to really get away with leaving the 
> interactions undefined. I think we need to define them and if we need 
> something like oDAD, I think we should use it. I believe oDAD is now in 
> IETF last call and will go to PS well before FMIP does, so I think we 
> should really try to use it if we can.

FMIP says you can use an address and if NAR does not see a conflict in
it's Neighbor Cache entry for that address, the MN can use that address.

As we converge on the FNA issue, we can try to keep the ND interaction 
cleanly separated. For instance, use unsolicited NA, only allow setting 
state to REACHABLE but not necessarily require it, etc.

> bogged down, so avoiding a normative reference in the spec would 
> probably be best. We can recalibrate if the WG gets unbogged.
> 

DNA interaction is documented in an informational ID.

> because we want to avoid normative references or because some kind of 
> kernel change is needed. I'd like to see FMIP be well-defined and 
> well-designed. If it is, I think people will implement it because its good.

All of these are valid points. I don't think I want to leave something 
ambiguous. However, sometimes you need to make a distinction between 
defining everything versus only allowing hooks for defining alternative 
mechanisms. I also believe that our implementors will tell me if 
something is ambiguous :-)
When it comes to kernel changes, I am sensitive to normative
dependencies. If Linux gatekeepers do not accept 3775 message processing 
in the kernel, that sort of sets the bar.

-Rajeev

---

From: "James Kempf" <[email-masked]>
Date: Tue, 23 Aug 2005 16:29:41 -0700

> state to REACHABLE but not necessarily require it, etc.

The problem is that if the state is set to REACHABLE there could be an issue 
with duplicates. So unsolicited NA doesn't always work. That's an 
interoperability problem if one implementer requires it and another doesn't. 
Right now, the protocol has a lot of ambiguity that could be a problem for 
interoperability.

Another example: whether or not to do HI/HAck during reactive handover. If 
one implementation does it and the other doesn't, there's an 
interoperability problem.

>> bogged down, so avoiding a normative reference in the spec would probably 
>> be best. We can recalibrate if the WG gets unbogged.
>>
>

That's OK.

> mechanisms.

Where the rubber of hooks hits the road of interoperability is my primary 
concern.

> I also believe that our implementors will tell me if something is 
> ambiguous :-)

Problem here is that one implementor can't necessarily tell if there's an 
interoperability problem. We need interoperability tests for that. Are there 
some planned?

> in the kernel, that sort of sets the bar.

Hmm. Linux isn't the only game in town, what about Free BSD and IOS? There 
are other people with products out there. If we're desigining this thing 
just for Linux, we could move the whole effort to the Kernel.org and forget 
about an Internet Standard.

Also, I don't think 3775 is really the issue. The issue is oDAD. DAD is 
always done in the kernel.

            jak

---

From: Rajeev Koodli <[email-masked]>
Date: Tue, 23 Aug 2005 16:40:02 -0700

James Kempf wrote:

> The problem is that if the state is set to REACHABLE there could be an 
> issue with duplicates. So unsolicited NA doesn't always work. That's an 

You don't overwrite an existing entry when doing this. I believe this is 
in the spec.

> interoperability problem if one implementer requires it and another 
> doesn't. Right now, the protocol has a lot of ambiguity that could be a 
> problem for interoperability.

Exactly what those are would be good to list so that we can go through 
the tracker.

> 
> Another example: whether or not to do HI/HAck during reactive handover. 
> If one implementation does it and the other doesn't, there's an 

You can ask whether they implement HI and HAck or not :-)
BTW, this issue (usage clause) is entered in the tracker.

> Problem here is that one implementor can't necessarily tell if there's 
> an interoperability problem. We need interoperability tests for that. 
> Are there some planned?

We should and I hope we will at Connectathon and ETSI plugtests.

> Hmm. Linux isn't the only game in town, what about Free BSD and IOS? 

There is a Free BSD implementation. IOS what? :-)

> There are other people with products out there. If we're desigining this 
> thing just for Linux, we could move the whole effort to the Kernel.org 
> and forget about an Internet Standard.
> 

Of course it is not Linux-only, but do you disagree that it is one of 
the important ones?

> always done in the kernel.

I would still like to be careful with _requiring _ kernel changes.

-Rajeev

---

From: Emil Ivov <[email-masked]>
Date: Wed, 24 Aug 2005 01:49:12 +0200

> Right now, the protocol has a lot of ambiguity that could be a problem for 

Actually the interoperability problem with this (as in the current spec) 
would be a wrongful assumption by any of the sides as to which of the 
following a positive HAck and therefore a positive FBAck would mean:

1) Yes, MN may handover and the NAR guarantess that there are no dups
or
2) Yes MN may handover but the NAR doesn't know anything as to whether 
there is going to be duplication.

That could easily be straightened out with a flag in HAck/FBAck thus 
indicating whether the burden of DAD is left to the MN (which may oDAD 
or ... sth else) or to the AR (which may have handled it in its 
preferred way).

> are other people with products out there. 

True, but that's not a reason for making it difficult for Linux. 
(Besides oDAD deployment would probably raise issues for any OS)

Cheers
Emil

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 24 Aug 2005 12:33:37 +0200

Emil Ivov wrote:
> James Kempf wrote:
> 
>>> FMIP says you can use an address and if NAR does not see a
>>> conflict in it's Neighbor Cache entry for that address, the MN
>>> can use that address.
>>> 
>>> As we converge on the FNA issue, we can try to keep the ND 
>>> interaction cleanly separated. For instance, use unsolicited NA,
>>> only allow setting state to REACHABLE but not necessarily require
>>> it, etc.
>>> 
>> 
>> 
>> The problem is that if the state is set to REACHABLE there could be
>> an issue with duplicates. So unsolicited NA doesn't always work.
>> That's an interoperability problem if one implementer requires it
>> and another doesn't. Right now, the protocol has a lot of ambiguity
>> that could be a problem for interoperability.
> 
> 
> Actually the interoperability problem with this (as in the current
> spec) would be a wrongful assumption by any of the sides as to which
> of the following a positive HAck and therefore a positive FBAck would
> mean:
> 
>  or 2) Yes MN may handover but the NAR doesn't know anything as to
> whether there is going to be duplication.
> 
> indicating whether the burden of DAD is left to the MN (which may
> oDAD or ... sth else) or to the AR (which may have handled it in its 
> preferred way).
> 
>>> dependencies. If Linux gatekeepers do not accept 3775 message 
>>> processing in the kernel, that sort of sets the bar.
>> 
>> 
>> Hmm. Linux isn't the only game in town, what about Free BSD and
>> IOS? There are other people with products out there.
> 
> 

Kernel processing has its own advantages.  The main is that kernel
packet processing threads take higher priority over userspace
processing.  This is logically of high importance to FMIPv6 where one
wants to make sure that the implementation of sending e.g. FBU is not
delayed by some intensive application.

Usually real-time video/audio applications are compute-intensive, even
more intensive on small devices.

Regarding linux gatekeepers not putting 3775 in the kernel.  So what.
It is still possible to have a separate kernel module that implements a
different IPv6 stack than the linux native.

Alex

---

From: Koshiro MITSUYA <[email-masked]>
Date: Thu, 25 Aug 2005 00:06:06 +0900

Hi,

please find my comments inline:

On 2005/08/24, at 3:04, Rajeev Koodli wrote:
>> 1) Letting NAR know that an MN is coming so that it could if it  
>> wants to  do anything about that (e.g. creating an NCEntry) that  
>> would optimize the handover.
>> 2) Give NAR the chance to refuse the handover, and not only  
>> because of DAD ... there could be many reasons for refusing an MN  
>> in your net. Resource overload, security ... I am sure you could  
>> think of more.
>> 4) Provide an extension point for future work on FMIP. The hack  
>> could server as a transport for data that the NAR would want to  
>> tell the MN before it comes to its net. And I'm thinking about  
>> purely handover related stuff not outside functions.

I am thinking multicast optimization.  NAR can join a multicast tree  
triggered by HI/HACK before MN arrived at NAR's link.  This could be  
more faster than MN send a Join request once he arrived.

Agree.

>
>> Absolutely! But it intervenes on a very low level. Implementors  
>> would therefore have to implement it kernel space, then distribute  
>> their implementations together with a modified kernel, and  
>> possible port their
>>
>
> This is a very good point. I know MIPL had to redo their  
> implementation of MIPv6 in userland in order to be able to make it  
> to Linux distribution. (I don't know that current status of  
> distribution however)
>

I personally think we cannot avoid kernel modification if we needs  
highly optimized implementation.  Since it has own advantage, I think  
we should not discuss this for too long.

regards,
Koshiro

---

From: "James Kempf" <[email-masked]>
Date: Wed, 24 Aug 2005 08:28:01 -0700

> You don't overwrite an existing entry when doing this. I believe this is 

Yes, but the PAR doesn't know that there are duplicates. The NAR doesn't 
either, at least not before the unsolicited NA is sent. So some of the MN's 
packets may be delivered to the wrong node if the PAR starts tunneling them 
before the NAR finds out and there is a duplicate.

In reactive handover, the FBU probably gets sent first, then the unsolicited 
NA. Since the transit time for the FBU to PAR is longer, the NAR can know 
from the NA that there's a problem by the time the tunneled packets show up. 
It can then drop the packets. The optimization fails, of course, but, as 
Hesham has pointed out, this is a very low probability event.

Of course, this won't prevent a problem if there's a duplicate on the link 
and the NAR doesn't have a NCE for it.

Anyway, I think the spec needs to describe this specifically.

> Of course it is not Linux-only, but do you disagree that it is one of the 
> important ones?
>

I think Linux is important, but since FMIP requires changes on routers, I 
think it is more important to get support from router vendors. Otherwise, it 
won't happen commercially.

> I would still like to be careful with _requiring _ kernel changes.

This is an implementation issue. Some things do require kernel changes by 
their nature, but others don't. Not all of 3775 needs to be in the kernel.

            jak

---

From: Koshiro MITSUYA <[email-masked]>
Date: Thu, 25 Aug 2005 00:39:00 +0900

Hi,

> I would still like to be careful with _requiring _ kernel changes.

I don't know that the spec expects this or not, but we have to modify  
BSD kernel to skip DAD process for NCoA, otherwise MN cannot send an  
FBU immediately after attaching to NAR's link. (Here, it's a bit not  
clear what's attaching to NAR's link, after L2 handover or including  
NCoA DAD anyway).  So we already required kernel changes.

Again, I think we should not discuss this too long!

regards,
Koshiro

On 2005/08/24, at 8:40, Rajeev Koodli wrote:

>
>
> James Kempf wrote:
>
>
>> The problem is that if the state is set to REACHABLE there could  
>> be an issue with duplicates. So unsolicited NA doesn't always  
>> work. That's an
>>
>
> You don't overwrite an existing entry when doing this. I believe  
> this is in the spec.
>
>
>
>> interoperability problem if one implementer requires it and  
>> another doesn't. Right now, the protocol has a lot of ambiguity  
> Exactly what those are would be good to list so that we can go  
> through the tracker.
>
>
>
>> Another example: whether or not to do HI/HAck during reactive  
>> handover. If one implementation does it and the other doesn't,  
>> there's an interoperability problem.
>>
>
>> Problem here is that one implementor can't necessarily tell if  
>> there's an interoperability problem. We need interoperability  
>> tests for that. Are there some planned?
>>
>
>> There are other people with products out there. If we're  
>> desigining this thing just for Linux, we could move the whole  
>> effort to the Kernel.org and forget about an Internet Standard.
>>
>
> Of course it is not Linux-only, but do you disagree that it is one  
> of the important ones?
>
>
>
>> Also, I don't think 3775 is really the issue. The issue is oDAD.  
>> DAD is always done in the kernel.
>>
>

---

From: "James Kempf" <[email-masked]>
Date: Wed, 24 Aug 2005 08:45:40 -0700

Mitsuya-san,

> triggered by HI/HACK before MN arrived at NAR's link.  This could be  more 
> faster than MN send a Join request once he arrived.
>
>

There's a description in RFC 4067 about how to use CxTP to transfer 
multicast subscription context between ARs. Note that this procedure could 
also be used proactively, prior to the actual handover event.

            jak