Subject: Re: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt
From: Erik Nordmark <[email-masked]>
To: [email-masked]
Cc: [email-masked], [email-masked], [email-masked]
Date: Tue, 26 Jul 2005 06:19:26 -0700

[email-masked] wrote:

> What it seems is that we need to have 3 states for an address pair 
> (I'm sure we could come up with better names, but just humor me):
> 
>  1) Fully - Working for all ULPs
>  2) Partial - Working for one (some) ULPs
>  3) Failed - not working for any ULPs
> 
> So, in a scenario, you start your browser and a shim context is created
> for an interface that's behind a firewall/web proxy. Connecting to the
> web succedes and this shim context is marked 'Fully' since 'all' of
> the ULPs using this shim context is working.  However, when
> you click on a streaming link & your media player starts using this shim 
> context, the streaming media fails since its blocked by the firewall,
> so the shim context could be marked as 'Parial.'
> 
> I guess we could wrap this around some sort of multiple interface scenario
> like you started with a GPRS connection, but (corporate) WLAN comes available,
> so you re-home because you prefer a speedy connection, but the WLAN connection
> is firewalled.  
> 
> Still, what I'm wondering is how does the shim layer know that an address
> pair failed because of something like this, or because of some other
> reason, like a streaming server became unavailable, etc. etc.

In addition to that issue, there is also the issue whether the shim 
would be able to know how many ULPs (really, how many different users 
above it might provide advice) are in play.
I don't see how it can know this, since it can't know when ULP endpoints 
(such as TCP connections, or some form of associations built on top of 
UDP) come and go, unless we assume that all the ULPs are modified to 
provide this.

So I think one would need a much more complex way to deliver advice to 
venture in this direction.

And as you point out, it might be intractable to do anything useful in 
the shim even if we had the 3 different states.

    Erik

Delivery-date: Mon, 25 Jul 2005 09:59:10 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt
Date: Mon, 25 Jul 2005 12:58:57 +0300
From: <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>

Hi Iljitsch,

> > Detecting that there was a 'failure' due to a firewall is also quite
> > difficult to determine anyhow.  The only way would be to compare
> > multiple address pairs and determine in one case it works but
> > in another it doesn't work; and be sure that it wasn't just a =20
> > transiant
> > failure.
>=20
> I'm not sure what your point is. Either a firewall lets the shim =20
> packets through and then we consider the link working (well, if it =20
> does indeed work of course), or it doesn't, and we consider the link =20
> not working.
>=20
> In a pathalogical case it would be possible for an upper layer to =20
> fail consistently so it doesn't provide positive advice / provides =20
> negative advice all the time so we need to probe reachability more or  =

> less continously, but our probes would still make it.

Jari was worrying that for some ULPs, firewalls will let packets =
through,
but not for all ULPs.  In this case, how do we classify this negative =
feedback?

I guess I am thinking that this might be an unsolvable problem, because =
I
don't think that the shim layer will know why a certain ULP failed
and another ULP succeded.  It could be because there is no route for
one of the ULPs; it could be because someone typed a wrong URL; there
could be a momentary glitch; it could be due to firewalls, etc.

I'm sort of thinking that if we support negative feedback, that we
have to be careful about what we infer in terms of signifigance of the
failure.

John

Delivery-date: Mon, 25 Jul 2005 09:53:21 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt
Date: Mon, 25 Jul 2005 11:52:47 +0200
To: "<[email-masked]>" <[email-masked]>

On 25-jul-2005, at 10:06, <[email-masked]>  
<[email-masked]> wrote:

>> I disagree. If a firewall gets in the way, this can either be because
>> there is a valid reason, and then sneaking by is bad, or there is no
>> valid reason, so the firewall should be fixed. Adding additional
>> complexity and overhead to award people for laziness is very bad.

> Detecting that there was a 'failure' due to a firewall is also quite
> difficult to determine anyhow.  The only way would be to compare
> multiple address pairs and determine in one case it works but
> in another it doesn't work; and be sure that it wasn't just a  
> transiant
> failure.

I'm not sure what your point is. Either a firewall lets the shim  
packets through and then we consider the link working (well, if it  
does indeed work of course), or it doesn't, and we consider the link  
not working.

In a pathalogical case it would be possible for an upper layer to  
fail consistently so it doesn't provide positive advice / provides  
negative advice all the time so we need to probe reachability more or  
less continously, but our probes would still make it.

Delivery-date: Mon, 25 Jul 2005 08:06:43 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt
Date: Mon, 25 Jul 2005 11:06:32 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>

Iljitsch,

> Unless we take the rather radical approach of making the shim a TCP =20
> option (hard to do with such limited option space available) the shim  =

> negotiation and initial reachability verification packets need to get  =

> through in the first place or the path won't be used, because as far =20
> as the shim cal tell, it doesn't work.
>=20
> It is of course possible that an enterprising firewall admin cooks up  =

> a config that lets through shim and http packets, but not other =20
> important protocols.
>=20
> I guess the thing to do here is note the negative advice / lack of =20
> positive advice from the affected upper layer/sessions and keep =20
> looking for an alternative path.
>=20
> > If you believe some firewalls today are causing non-transparency =20
> > problems, the workaround seems to be to encapsulate in some general  =

> > connectivity protocol (http, ipsec/esp, ssh, ...) end to end.
>=20
> I disagree. If a firewall gets in the way, this can either be because  =

> there is a valid reason, and then sneaking by is bad, or there is no =20
> valid reason, so the firewall should be fixed. Adding additional =20
> complexity and overhead to award people for laziness is very bad.

Detecting that there was a 'failure' due to a firewall is also quite=20
difficult to determine anyhow.  The only way would be to compare
multiple address pairs and determine in one case it works but=20
in another it doesn't work; and be sure that it wasn't just a transiant
failure.

John

Delivery-date: Mon, 25 Jul 2005 08:03:41 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt
Date: Mon, 25 Jul 2005 11:03:26 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Jari,

> >> This makes sense, but I worry that the argument
> >> "one ULP works =3D> others should work too" may not
> >> hold in all cases. What if one ULP is TCP:xxxx->80, which
> >> happens to work over this crappy firewalled network that
> >> you are using, but it doesn't let through, say, TCP:xxxx->23?
> >> The shim could be making the wrong decision here.
> >
> > And this supposedly works today without a shim?
> > If the routing system has two routes to a given IP address, and =
there=20
> > are firewalls on those paths that let some port/protocols through =
but=20
> > not others, then things will not work today.
>=20
> I guess today's configuration would be that you have just one default =
route
> from the host's point of view, and multihoming, if any, would be =
on/off.=20
> That is, if your primary interface fails, switch to the other.
>=20
> This would of course still have the same problem when you move to the
> crappy interface that only lets http through.
>=20
> However, the shim solution has potential to make this problem worse.
> Suppose you have to switch to the crappy interface for a moment.
> Now, if the definition of "address pair works" is that one ULP says
> its OK, then the shim will never switch back to the primary, better
> interface.

What it seems is that we need to have 3 states for an address pair=20
(I'm sure we could come up with better names, but just humor me):

 1) Fully - Working for all ULPs
 2) Partial - Working for one (some) ULPs
 3) Failed - not working for any ULPs

So, in a scenario, you start your browser and a shim context is created
for an interface that's behind a firewall/web proxy. Connecting to the
web succedes and this shim context is marked 'Fully' since 'all' of
the ULPs using this shim context is working.  However, when
you click on a streaming link & your media player starts using this shim =

context, the streaming media fails since its blocked by the firewall,
so the shim context could be marked as 'Parial.'

I guess we could wrap this around some sort of multiple interface =
scenario
like you started with a GPRS connection, but (corporate) WLAN comes =
available,
so you re-home because you prefer a speedy connection, but the WLAN =
connection
is firewalled. =20

Still, what I'm wondering is how does the shim layer know that an =
address
pair failed because of something like this, or because of some other
reason, like a streaming server became unavailable, etc. etc.

John

Delivery-date: Mon, 25 Jul 2005 07:38:11 +0000
Content-class: urn:content-classes:message
Subject: RE: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt
Date: Mon, 25 Jul 2005 10:37:28 +0300
From: <[email-masked]>
To: <[email-masked]>, <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>

Hi all,

> > Can you explain why the first model wouldn't be able to use negative
> > feedback for faster failure detection? It seems like it could use a
> > trigger from TCP to send a probe earlier than it would otherwise
> > do it.
>=20
> I see two potential reasons for not using any negative advice in the=20
> NUD-based model.
>=20
> 1. If the probing by the shim (which is suppressible by positive =
advice)=20
> have been designed so that a failure can be detected in N seconds, =
then=20
> the shim would satisfy a requirement of detecting any failure in, at=20
> worst, N seconds. Is it really useful to sometimes be better, or is=20
> worst case the thing that matters? (I guess this is more a question =
than=20
> a reason.)
>=20
> 2. When you have multiple ULP "connections" using the same shim =
context,=20
> you have some more complexity to handle when some ULP advice might be=20
> negative and some positive at the same time (for the same context). If =

> you place more weight in the negative advice, then you will react more =

> strongly to random packet loss causing one connection to think there =
is=20
> a problem, etc.
> Only using positive advice avoids this complexity, because it =
implicitly=20
> assumes that if anybody ULP finds the locator pair working, then the=20
> probes can be suppressed.

I agree with Erik on this.  I remember discussions from trigtran, about=20
link-up and link-down events, that many people were worried about=20
link-down events because of the reasons Erik lists above and about
fears of DoS attacks forged link-down events.  I'm not sure if this =
would
be applicable in the shim6 case, but there is a threat, IMO, of this.

However, I think if we wanted to consider negative feedback, we'd have
to consider the aggregate case; if there are multiple ULPs using a =
single
shim context and they all are reporting negative feedback, then maybe =
its
a safe assumption that a failure has occured.=20

John

Delivery-date: Thu, 21 Jul 2005 16:12:06 +0000
To: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: is there an ml archive available?
Date: Thu, 21 Jul 2005 18:11:50 +0200

Delivery-date: Thu, 21 Jul 2005 12:55:14 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt
Date: Thu, 21 Jul 2005 14:54:33 +0200
To: Erik Nordmark <[email-masked]>

On 19-jul-2005, at 11:31, Erik Nordmark wrote:

>> I worry that the argument
>> "one ULP works => others should work too" may not
>> hold in all cases. What if one ULP is TCP:xxxx->80, which
>> happens to work over this crappy firewalled network that
>> you are using, but it doesn't let through, say, TCP:xxxx->23?
>> The shim could be making the wrong decision here.

> And this supposedly works today without a shim?

:-)

Unless we take the rather radical approach of making the shim a TCP  
option (hard to do with such limited option space available) the shim  
negotiation and initial reachability verification packets need to get  
through in the first place or the path won't be used, because as far  
as the shim cal tell, it doesn't work.

It is of course possible that an enterprising firewall admin cooks up  
a config that lets through shim and http packets, but not other  
important protocols.

I guess the thing to do here is note the negative advice / lack of  
positive advice from the affected upper layer/sessions and keep  
looking for an alternative path.

> If you believe some firewalls today are causing non-transparency  
> problems, the workaround seems to be to encapsulate in some general  
> connectivity protocol (http, ipsec/esp, ssh, ...) end to end.

I disagree. If a firewall gets in the way, this can either be because  
there is a valid reason, and then sneaking by is bad, or there is no  
valid reason, so the firewall should be fixed. Adding additional  
complexity and overhead to award people for laziness is very bad.

Delivery-date: Thu, 21 Jul 2005 09:55:42 +0000
Date: Wed, 20 Jul 2005 09:19:08 +0300
From: Jari Arkko <[email-masked]>
To: Erik Nordmark <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>,  [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt

Erik Nordmark wrote:

> Jari Arkko wrote:
>
>> This makes sense, but I worry that the argument
>> "one ULP works => others should work too" may not
>> hold in all cases. What if one ULP is TCP:xxxx->80, which
>> happens to work over this crappy firewalled network that
>> you are using, but it doesn't let through, say, TCP:xxxx->23?
>> The shim could be making the wrong decision here.
>
>
> And this supposedly works today without a shim?
> If the routing system has two routes to a given IP address, and there 
> are firewalls on those paths that let some port/protocols through but 
> not others, then things will not work today.

I guess today's configuration would be that you have just one default route
from the host's point of view, and multihoming, if any, would be on/off. 
That
is, if your primary interface fails, switch to the other.

This would of course still have the same problem when you move to the
crappy interface that only lets http through.

However, the shim solution has potential to make this problem worse.
Suppose you have to switch to the crappy interface for a moment.
Now, if the definition of "address pair works" is that one ULP says
its OK, then the shim will never switch back to the primary, better
interface.

--Jari

Delivery-date: Tue, 19 Jul 2005 09:31:40 +0000
Date: Tue, 19 Jul 2005 02:31:47 -0700
From: Erik Nordmark <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt

Jari Arkko wrote:

> This makes sense, but I worry that the argument
> "one ULP works => others should work too" may not
> hold in all cases. What if one ULP is TCP:xxxx->80, which
> happens to work over this crappy firewalled network that
> you are using, but it doesn't let through, say, TCP:xxxx->23?
> The shim could be making the wrong decision here.

And this supposedly works today without a shim?
If the routing system has two routes to a given IP address, and there 
are firewalls on those paths that let some port/protocols through but 
not others, then things will not work today.

If you believe some firewalls today are causing non-transparency 
problems, the workaround seems to be to encapsulate in some general 
connectivity protocol (http, ipsec/esp, ssh, ...) end to end.

    Erik

Delivery-date: Tue, 19 Jul 2005 08:46:18 +0000
Date: Tue, 19 Jul 2005 11:45:51 +0300
From: Jari Arkko <[email-masked]>
To: Erik Nordmark <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>,  [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt

Erik Nordmark wrote:

> I see two potential reasons for not using any negative advice in the 
> NUD-based model.
>
> 1. If the probing by the shim (which is suppressible by positive 
> advice) have been designed so that a failure can be detected in N 
> seconds, then the shim would satisfy a requirement of detecting any 
> failure in, at worst, N seconds. Is it really useful to sometimes be 
> better, or is worst case the thing that matters? (I guess this is more 
> a question than a reason.)

Ok. (I wasn't so much arguing that we need to use negative advice, just
wondered why it couldn't be combined with this model.)

> 2. When you have multiple ULP "connections" using the same shim 
> context, you have some more complexity to handle when some ULP advice 
> might be negative and some positive at the same time (for the same 
> context). If you place more weight in the negative advice, then you 
> will react more strongly to random packet loss causing one connection 
> to think there is a problem, etc.
> Only using positive advice avoids this complexity, because it 
> implicitly assumes that if anybody ULP finds the locator pair working, 
> then the probes can be suppressed.

This makes sense, but I worry that the argument
"one ULP works => others should work too" may not
hold in all cases. What if one ULP is TCP:xxxx->80, which
happens to work over this crappy firewalled network that
you are using, but it doesn't let through, say, TCP:xxxx->23?
The shim could be making the wrong decision here.

--Jari

Delivery-date: Tue, 19 Jul 2005 04:57:28 +0000
Date: Mon, 18 Jul 2005 21:45:45 -0700
From: Erik Nordmark <[email-masked]>
To: Jari Arkko <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt

Jari Arkko wrote:

> Can you explain why the first model wouldn't be able to use negative
> feedback for faster failure detection? It seems like it could use a
> trigger from TCP to send a probe earlier than it would otherwise
> do it.

I see two potential reasons for not using any negative advice in the 
NUD-based model.

1. If the probing by the shim (which is suppressible by positive advice) 
have been designed so that a failure can be detected in N seconds, then 
the shim would satisfy a requirement of detecting any failure in, at 
worst, N seconds. Is it really useful to sometimes be better, or is 
worst case the thing that matters? (I guess this is more a question than 
a reason.)

2. When you have multiple ULP "connections" using the same shim context, 
you have some more complexity to handle when some ULP advice might be 
negative and some positive at the same time (for the same context). If 
you place more weight in the negative advice, then you will react more 
strongly to random packet loss causing one connection to think there is 
a problem, etc.
Only using positive advice avoids this complexity, because it implicitly 
assumes that if anybody ULP finds the locator pair working, then the 
probes can be suppressed.

    Erik

Delivery-date: Mon, 18 Jul 2005 06:54:43 +0000
Reply-To: <[email-masked]>
From: "Taewan You" <[email-masked]>
To: "'Brian E Carpenter'" <[email-masked]>, <[email-masked]>
Cc: "'marcelo bagnulo braun'" <[email-masked]>
Subject: RE: I-D ACTION:draft-you-shim6-l3shim-state-management-00.txt
Date: Mon, 18 Jul 2005 15:54:30 +0900
Organization: ETRI

Hello, Brian
Thank you for your kindly comments.

Your comment is right. 
If the notifications between L3Shim and TCP or ULP were needed, the proposed
way only should be performed at L3Shim layer.

Regards,
Taewan.

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]
> Sent: Monday, July 18, 2005 3:34 PM
> To: marcelo bagnulo braun
> Cc: [email-masked]; shim6
> Subject: Re: I-D ACTION:draft-you-shim6-l3shim-state-management-00.txt
> 
> 
> marcelo bagnulo braun wrote:
> > Hi Taewan,
> >
> > been reading your draft and i have some questions about it.
> >
> >
> > in section 2.1 it is stated that in order to trigger TCP slow start the
> > shim must:
> >
> >        When any locator change was occurred, L3Shim should discard the
> >        entire packets from correspondent node during TCP-Congestion-
> >        Triggering-Time. Consequently the TCP congestion control
> mechanism
> >        triggers naturally by this one. The main key point is that how
> > to set
> >        up the time of TCP-Congestion-Triggering-Time enhancing
> > performance.
> >        It can be heuristic setting up the value.
> >
> > Now, i think this is really a bad option. I mean, forcing the shim,
> > which is supposed to be a mechanisms for improving the fault tolerance,
> > to discard packets does not seems a good idea to me.
> 
> Yes, since there is no particular reason in the shim6 model that all
> packets sharing shim6 state should belong to the same TCP connection,
> this would be quite wrong. The only way to do this properly is to add
> an API such that the shim can announce the change to the ULP; if the
> ULP happens to be TCP, it can decide to use this as a trigger. If the
> ULP happens to be UDP, it will ignore the information. And if both
> TCP and UDP are using the same shim6 state, they will behave differently.
> (And SCTP will of course be different again.)
> 
>      Brian
> 

Delivery-date: Mon, 18 Jul 2005 06:34:39 +0000
Date: Mon, 18 Jul 2005 08:34:29 +0200
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: [email-masked], shim6 <[email-masked]>
Subject: Re: I-D ACTION:draft-you-shim6-l3shim-state-management-00.txt

marcelo bagnulo braun wrote:
> Hi Taewan,
> 
> been reading your draft and i have some questions about it.
> 
> 
> in section 2.1 it is stated that in order to trigger TCP slow start the  
> shim must:
> 
>        When any locator change was occurred, L3Shim should discard the
>        entire packets from correspondent node during TCP-Congestion-
>        Triggering-Time. Consequently the TCP congestion control  mechanism
>        triggers naturally by this one. The main key point is that how  
> to set
>        up the time of TCP-Congestion-Triggering-Time enhancing  
> performance.
>        It can be heuristic setting up the value.
> 
> Now, i think this is really a bad option. I mean, forcing the shim,  
> which is supposed to be a mechanisms for improving the fault tolerance,  
> to discard packets does not seems a good idea to me.

Yes, since there is no particular reason in the shim6 model that all
packets sharing shim6 state should belong to the same TCP connection,
this would be quite wrong. The only way to do this properly is to add
an API such that the shim can announce the change to the ULP; if the
ULP happens to be TCP, it can decide to use this as a trigger. If the
ULP happens to be UDP, it will ignore the information. And if both
TCP and UDP are using the same shim6 state, they will behave differently.
(And SCTP will of course be different again.)

     Brian

Delivery-date: Mon, 18 Jul 2005 06:33:38 +0000
Reply-To: <[email-masked]>
From: "Taewan You" <[email-masked]>
To: "'marcelo bagnulo braun'" <[email-masked]>, <[email-masked]>
Subject: RE: I-D ACTION:draft-you-shim6-l3shim-state-management-00.txt
Date: Mon, 18 Jul 2005 15:32:47 +0900
Organization: ETRI

Hello Marcelo,

About this point, there seemed to be so insufficient expectation at this
draft. Thank you for giving an opportunity to explain in detail again to =
me.

Please, find my inline comments.

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]
> Sent: Sunday, July 17, 2005 1:33 AM
> To: [email-masked]
> Cc: shim6
> Subject: Re: I-D ACTION:draft-you-shim6-l3shim-state-management-00.txt
>=20
>=20
> Hi Taewan,
>=20
> been reading your draft and i have some questions about it.
>=20
>=20
> in section 2.1 it is stated that in order to trigger TCP slow start =
the
> shim must:
>=20
>         When any locator change was occurred, L3Shim should discard =
the
>         entire packets from correspondent node during TCP-Congestion-
>         Triggering-Time. Consequently the TCP congestion control
> mechanism
>         triggers naturally by this one. The main key point is that how
> to set
>         up the time of TCP-Congestion-Triggering-Time enhancing
> performance.
>         It can be heuristic setting up the value.
>=20
> Now, i think this is really a bad option. I mean, forcing the shim,
> which is supposed to be a mechanisms for improving the fault =
tolerance,
> to discard packets does not seems a good idea to me.
>=20
> So, i would like to understand a bit more why this is needed and if =
so,
> if there are not other approaches that can be used.
>=20
> w.r.t. the alternative approaches (keep in mind that i am not a TCP
> expert)
>=20
> AFAIK TCP detects congestion based on two indications: lost packets =
and
> duplicate ACKs. The approach presented in your draft proposed to use
> the packet loss as a mean to indicate congestion to TCP. This has the
> obvious drawback that the shim is artifically discarding packets. The
> question is : wouldn't it be possible to use the duplicate ACK
> mechanism to indicate congestion to TCP? I mean, what if, after an
> outage, the shim passes to TCP during a while artificially created
> duplicate packets? wouldn't this result in TCP detecting congestion =
and
> acting accordingly?
>=20
> Later on, it is stated that the other action that is performed would =
be:
>=20
>                    Also, the VALID state, which is one of L3Shim state
> and is explained
>                    in next chapter, keep up the situation expecting
> error for
>                    operational primary address pair during
> Probably-Active-Duration-Time
>                    with indirect TCP Congestion control separately, =
TCP
> Congestion
>                    control mechanism should be achieved automatically.
>=20
>=20
> Well, i fail to understand what you are proposing here, could you
> expand on this?
>=20
> Regards, marcelo

As you already know, the TCP can detect packet loss using timeout =
occurring
and duplication ACK. The assumption of the algorithm is that packet loss
caused by damage is very small, therefore the loss of packet signals
congestion.=20

AFAIK the congestion control should react upon the two situations
differently. When the timeout occurs, the TCP slow start mechanism is
operated. The other case that receive duplication ACK, the TCP fast
retransmission mechanism is operated.=20

So, when an operational primary address pair should be changing, TCP =
fast
retransmission mechanism has been operated better than slow start for =
TCP
throughput.=20

However, the goal of site multihoming by L3Shim6 is supporting
fault-tolerant. But the goal of I proposed vertical layered =
communication is
expecting congestion situation where operational primary address pair =
switch
from a high-bandwidth LAN interface to a low bandwidth cellular =
interface,
and notifying TCP to perform TCP congestion control mechanisms =
beforehand.

In this draft, the notification of TCP should be performed by two =
timers;
Probably-Active-Duration-Time, TCP-Congestion-Triggering-Time.

For instance, when the primary address pair can be detected by receiving
ICMP error message or other layer 2 information, this detected failure =
do
not means that an operational primary address pair's rechability cut =
off.
This failure should be confirm local operational address=92 failure =
only. In
this situation, we indicated the VALID state was entered. Within this =
state,
there is no action until decided time (Probably-Active-Duration-Time) =
passed
so that the TCP congestion mechanism should be operated in naturally.
For example, we can establish Probably-Active-Duration-Time to small =
lest
the timeout should be occurred before receiving duplication ACK, so that =
the
duplication ACK can be receipt for fast retransmission within timeout =
after
achieving address pair changes completely. On the contrary, we can set =
the
Probably-Active-Duration-Time is bigger so that the slow start can be
operated by timeout occurring. Consequently we can control TCP =
congestion
mechanism through adjustment time of Probably-Active-Duration-Time

Before, we can use TCP-Congestion-Triggering-Time for indirect TCP
congestion control, we assume that the application would be able to tell =
the
L3Shim layer that the current connection in unsatisfactory. Whenever =
address
pair is changing under the situation where changed address pair is
unsatisfied, L3Shim should discard the entire packets from correspondent
node during TCP-Congestion-Triggering-Time to occur timeout. In other =
wards,
we should lead to operate the slow start of TCP congestion mechanism in =
case
of switching from high-bandwidth to lower-bandwidth.

I'm worry about that my explanation is unsatisfied for your question. If =
you
have any problem or comments about this draft, please hear your =
comments.
I'm highly welcomed.

Regards,=20
Taewan.

>=20
>=20
> El 15/07/2005, a las 3:30, Taewan You escribi=F3:
>=20
> > Hello folks,
> > We have submitted an I-D that describes L3Shim state management =
using
> > Vertical layered communication.
> >
> > In this draft, we proposed simple two ideas.
> > First is a vertical layered communication method in case of =
interaction
> > between L3Shim and TCP or Upper layer.
> > This mechanism is achieved using defined two timers;
> > TCP-Congestion-Triggering-Time and Probably-Active-Duration-Time.
> > Next is L3Shim state transition processes based on the events that =
can
> > be
> > happened during lifetime.
> >
> > We would appreciate to hear your comments.
> >
> > Regards,
> > Taewan You.
> >
> > =
-----------------------------------------------------------------------
> > -----
> > A New Internet-Draft is available from the on-line Internet-Drafts
> > directories.
> >
> >
> > 	Title		: L3Shim state management using Vertical layered
> > Communication
> > 	Author(s)	: T. You, et al.
> > 	Filename	: draft-you-shim6-l3shim-state-management-00.txt
> > 	Pages		: 14
> > 	Date		: 2005-7-14
> >
> > This draft proposed vertical layered communication method; =
especially
> > it is mechanism to notify locator changing from L3Shim to TCP layer.
> > In this draft, it is called indirect TCP congestion control. This
> > mechanism make TCP congestion situation using behavior of L3Shim
> > layer without correcting conventional TCP. And then we describe
> > L3Shim state through the event. These kinds of events and progress
> > state are presented in a single system view. And it will be help to
> > implement L3Shim functionality through understanding L3Shim process.
> >
> > A URL for this Internet-Draft is:
> > http://www.ietf.org/internet-drafts/draft-you-shim6-l3shim-state-
> > management-
> > 00.txt
> >
> >
> >

Delivery-date: Sun, 17 Jul 2005 07:16:28 +0000
Date: Sat, 16 Jul 2005 19:59:06 +0300
From: Jari Arkko <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, shim6 <[email-masked]>
Subject: Re: about reachability detection draft

Hi Marcelo,

> I think it is important to consider one step further then. I mean, 
> what can a host possibly do when he detects an outage in the incoming 
> path? If a host detects an outage in the outgoing path, he can change 
> the address pair that he is using to send packets and see if it solves 
> the problem, but what can he do if he detects an outage in the 
> incoming path? I guess that the only option would be to notify the 
> correspondent node about the failure so that the correspondent uses an 
> alternative path (Note that we are asuming the the case of 
> unidirectional connectivity is possible)
> So i guess that this mode needs an additional message informing the 
> failure, which needs to be taken into account when comparing the options.

This is related to the discussion we had in the MOBIKE WG about
the separation between detection and action. As an example,
the IKEv2 initiator could be in charge of all actions, i.e., actual
address pair changes, and the other party would only provide
indications to the initiator regarding its own address status,
current status of the communications, and it would assist in
address pair exploration. But all of this requires some signaling
communications.

> I guess it would also make sense to state how the those mechanisms 
> behave when there are no outgoing packets? i mean, i guess that in any 
> of the modes signaling is suppressed right?, however, i guess that the 
> hosts assume that the address pair is reachable, right?
>
> Additionally, i guess that there are other information that needs to 
> be taken into account when detecting reachability, such as ICMP error 
> messages, address deprecation, lower layers information (i know that 
> you state that you assume that addresses are available, but what 
> happens if an address of the currently used address pair is 
> deprecated? or if the associated interface goes down?) i guess it 
> would be important to deal with this cases also

Yes. Of course, it may also be useful to find abstractions, e.g., addresses
having some kind of a state that the lower layers (whatever they are) 
indicate
to the shim6 layer. Even so, my sense is that its still complicated enough
that some of the assumed impacts from lower layer need to be specified
in our protocol documents.

> Finally, in the security considerations section, i think that there is 
> closely related problem that perhaps needs to be presented here that 
> is flooding protection. I mean, the path exploration exchange can be 
> used for identifying working address pairs but also for preventing 
> that the shim can be used for flooding attacks. In order to enable the 
> path exploration exchange to be used for this, you need to include 
> some additional information in the exchange, some information that 
> identifies the shim context, so that the receiver of a packet of the 
> address pair exploration process can determine if this is one of its 
> own established sessions that are being genuinely rehomed or if this 
> is a flooding attack.

Good point.

--Jari

Delivery-date: Sat, 16 Jul 2005 16:33:46 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-you-shim6-l3shim-state-management-00.txt
Date: Sat, 16 Jul 2005 18:33:24 +0200
To: <[email-masked]>

Hi Taewan,

been reading your draft and i have some questions about it.

in section 2.1 it is stated that in order to trigger TCP slow start the =20=

shim must:

        When any locator change was occurred, L3Shim should discard the
        entire packets from correspondent node during TCP-Congestion-
        Triggering-Time. Consequently the TCP congestion control =20
mechanism
        triggers naturally by this one. The main key point is that how =20=

to set
        up the time of TCP-Congestion-Triggering-Time enhancing =20
performance.
        It can be heuristic setting up the value.

Now, i think this is really a bad option. I mean, forcing the shim, =20
which is supposed to be a mechanisms for improving the fault tolerance, =20=

to discard packets does not seems a good idea to me.

So, i would like to understand a bit more why this is needed and if so, =20=

if there are not other approaches that can be used.

w.r.t. the alternative approaches (keep in mind that i am not a TCP =20
expert)

AFAIK TCP detects congestion based on two indications: lost packets and =20=

duplicate ACKs. The approach presented in your draft proposed to use =20
the packet loss as a mean to indicate congestion to TCP. This has the =20=

obvious drawback that the shim is artifically discarding packets. The =20=

question is : wouldn't it be possible to use the duplicate ACK =20
mechanism to indicate congestion to TCP? I mean, what if, after an =20
outage, the shim passes to TCP during a while artificially created =20
duplicate packets? wouldn't this result in TCP detecting congestion and =20=

acting accordingly?

Later on, it is stated that the other action that is performed would be:

                   Also, the VALID state, which is one of L3Shim state =20=

and is explained
                   in next chapter, keep up the situation expecting =20
error for
                   operational primary address pair during =20
Probably-Active-Duration-Time
                   with indirect TCP Congestion control separately, TCP =20=

Congestion
                   control mechanism should be achieved automatically.

Well, i fail to understand what you are proposing here, could you =20
expand on this?

Regards, marcelo

El 15/07/2005, a las 3:30, Taewan You escribi=F3:

> Hello folks,
> We have submitted an I-D that describes L3Shim state management using
> Vertical layered communication.
>
> In this draft, we proposed simple two ideas.
> First is a vertical layered communication method in case of =
interaction
> between L3Shim and TCP or Upper layer.
> This mechanism is achieved using defined two timers;
> TCP-Congestion-Triggering-Time and Probably-Active-Duration-Time.
> Next is L3Shim state transition processes based on the events that can =
=20
> be
> happened during lifetime.
>
> We would appreciate to hear your comments.
>
> Regards,
> Taewan You.
>
> =
-----------------------------------------------------------------------=20=

> -----
> A New Internet-Draft is available from the on-line Internet-Drafts
> directories.
>
>
> 	Title		: L3Shim state management using Vertical layered
> Communication
> 	Author(s)	: T. You, et al.
> 	Filename	: draft-you-shim6-l3shim-state-management-00.txt
> 	Pages		: 14
> 	Date		: 2005-7-14
> =09
> This draft proposed vertical layered communication method; especially
> it is mechanism to notify locator changing from L3Shim to TCP layer.
> In this draft, it is called indirect TCP congestion control. This
> mechanism make TCP congestion situation using behavior of L3Shim
> layer without correcting conventional TCP. And then we describe
> L3Shim state through the event. These kinds of events and progress
> state are presented in a single system view. And it will be help to
> implement L3Shim functionality through understanding L3Shim process.
>
> A URL for this Internet-Draft is:
> http://www.ietf.org/internet-drafts/draft-you-shim6-l3shim-state-=20
> management-
> 00.txt
>
>
>

Delivery-date: Sat, 16 Jul 2005 15:49:44 +0000
Cc: shim6 <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: about reachability detection draft
Date: Sat, 16 Jul 2005 17:49:02 +0200
To: Iljitsch van Beijnum <[email-masked]>

Hi Iljitsch,

thanks for the draft, it is very clear in its presentation

i know this is 00 version, but some comments anyway of things i 
consider relevant.

In section 2 it is stated that:

- In the second model, a host can only detect problems in the receiving
   direction so it must depend on the correspondent to detect problems
   in the other direction

I think it is important to consider one step further then. I mean, what 
can a host possibly do when he detects an outage in the incoming path? 
If a host detects an outage in the outgoing path, he can change the 
address pair that he is using to send packets and see if it solves the 
problem, but what can he do if he detects an outage in the incoming 
path? I guess that the only option would be to notify the correspondent 
node about the failure so that the correspondent uses an alternative 
path (Note that we are asuming the the case of unidirectional 
connectivity is possible)
So i guess that this mode needs an additional message informing the 
failure, which needs to be taken into account when comparing the 
options.

I guess it would also make sense to state how the those mechanisms 
behave when there are no outgoing packets? i mean, i guess that in any 
of the modes signaling is suppressed right?, however, i guess that the 
hosts assume that the address pair is reachable, right?

Additionally, i guess that there are other information that needs to be 
taken into account when detecting reachability, such as ICMP error 
messages, address deprecation, lower layers information (i know that 
you state that you assume that addresses are available, but what 
happens if an address of the currently used address pair is deprecated? 
or if the associated interface goes down?) i guess it would be 
important to deal with this cases also

Another issue that may be of interest is what happens with an address 
(pair) after it becomes unreachable? i mean, is it used in followings 
address pair explorations? is it putted in quarantine?

Later on in section 3 it is stated that:

   In its essence, address pair exploration is very simple: just send
   probes using every possible address pair, wait for something to come
   back and possibly consider the round trip time.

I guess we agree that you are oversimplifying the issue here :-)
I mean, the complexity is not only due to the amount of probe packets 
that are needed, but also becuase of unidirectional connectivity. I 
think it is very important to express such difficulty. I mean, even 
with two address pairs, the problem can be quite complex, because 
replies need to carry information, not only about the particular 
incoming packet, but also from other previously received probes, in 
order to allow the transmitter to determine if previous probes have 
succesfully arrived. I think it is important to describe this problem 
and possible approaches to deal with it.

Finally, in the security considerations section, i think that there is 
closely related problem that perhaps needs to be presented here that is 
flooding protection. I mean, the path exploration exchange can be used 
for identifying working address pairs but also for preventing that the 
shim can be used for flooding attacks. In order to enable the path 
exploration exchange to be used for this, you need to include some 
additional information in the exchange, some information that 
identifies the shim context, so that the receiver of a packet of the 
address pair exploration process can determine if this is one of its 
own established sessions that are being genuinely rehomed or if this is 
a flooding attack.

regards, marcelo

Delivery-date: Sat, 16 Jul 2005 09:20:04 +0000
Cc: [email-masked]
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt
Date: Sat, 16 Jul 2005 11:18:54 +0200
To: Jari Arkko <[email-masked]>

On 15-jul-2005, at 21:14, Jari Arkko wrote:

>> There have been some discussions about positive versus negative
>> feedback. The first model doesn't have any use for negative feedback,
>> but needs positive feedback to reduce overhead. The second model has
>> little or no use for positive feedback, but may use negative feedback
>> to detect failures faster.

> Can you explain why the first model wouldn't be able to use negative
> feedback for faster failure detection? It seems like it could use a
> trigger from TCP to send a probe earlier than it would otherwise
> do it.

(The "first model" is the neighbor unreachability detection -like  
one, the "second model" is one where the shim makes sure there is  
always be bidirectional packet flow so packets flowing in just one  
direction means there are problems.)

In the first model the idea is that upper layer protocols say "going  
well, going well" so the shim knows it doesn't have to send probes to  
see if everything still works. When the upper layer protocol stops  
providing positive feedback, the upper layer protocol starts probing.  
As I remarked earlier, in a binary system, not saying yes is the same  
thing as saying no. So negative feedback is the same as lack of  
positive feedback in this scenario.

Of course negative feedback would be a stronger signal than lack of  
positive feedback, but I don't think the difference would matter  
here, except maybe that lack of positive wouldn't necessarily imply  
immediate action, but negative feedback would. But this can be solved  
by sending a probe as soon as positive feedback stops and there are  
still outgoing packets.

Also, the fact that everything still works can be detected fast,  
while detecting that things don't work usually means some kind of  
timeout, which takes longer.

>> To avoid exposing information (even if it's just the fact that an
>> address is reachable), hosts will probably want to limit  
>> themselves to
>> taking part in reachability detection with known correspondents. This
>> means that there must be identifying information and a nonce that  
>> is at
>> least hard to guess but easy to check in all reachability detection
>> packets.

> This may need to be spelled out in more detail.

Yes, when the protocol becomes clear we need to look at this.

> For instance,
> when verifying reachability of the current address pair, "known
> correspondent" probably means that (a) we have a shim6
> "connection" to the peer and that (b) some secret information
> from that connection is employed that makes at least blind
> attacks from the internet impossible.

"Impossible" is a very high standard. We should be careful not to  
impose very heavy security on an otherwise light-weight mechanism.

> On the other hand, when
> doing address state exploration, "known correspondent" has
> to mean something else, as we may need to do address
> exploration even for the initial connection -- or am I missing
> something?

No, this is absolutely true. So we can't just leverage shim state to  
reject reachability detection from undesired correspondents.

I think we talked about having a cookie or something like that in the  
first packet of a new session. (Obviously this wouldn't apply to all  
protocols.) The first packet is attractive for this because an  
attacker with just sniffing capability can't inject a fake first  
packet, and the chance an attacker was already active is slightly  
smaller.

Since in most cases we'll be initiating shim state for existing  
sessions, we already have return reachability here.

>> However, using negative feedback from upper
>> layer protocols may prove challenging because upper layers can't be
>> trusted to provide the right quality or quantity feedback ("feedback
>> spamming").

> I guess this is arguable. You could also claim that the upper layers
> are the place that really knows what the requirements for this
> particular flow are.

I'm afraid that's exactly what some implementers are going to  
think.  :-)

"My protocol needs 100 ms failovers! So I need to send negative  
feedback if I didn't hear from the other side when I don't hear an  
ack within 50 ms. What, transatlantic links? No, most of my users use  
the protocol on a LAN. They don't...?"

Even when a particular protocol does the right thing, when something  
changes, we need to update all protocols. If the shim is in charge,  
we only need to update the shim.

Iljitsch

Delivery-date: Sat, 16 Jul 2005 06:17:49 +0000
Date: Sat, 16 Jul 2005 16:08:18 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-functional-dec-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming by IPv6 Intermediation 
Working Group of the IETF.

         Title           : Functional decomposition of the multihoming protocol
         Author(s)       : M. Bagnulo, J. Arkko
         Filename        : draft-ietf-shim6-functional-dec-00.txt
         Pages           : 19
         Date            : 2005-7-15

    In this note we will present a functional decomposition of the
    multihomig protocol i.e. the protocol for preserving established
    communications in multihomed environments.  We will do so by
    describing a protocol walkthrough, presenting which functions have to
    be performed at each stage and the messages required to accomplish
    them.  The functional decomposition presented in this draft is based
    on the general functional analysis of multihoming approaches
    presented in [3].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-functional-dec-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the 
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
         "get draft-ietf-shim6-functional-dec-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Delivery-date: Fri, 15 Jul 2005 20:16:46 +0000
Date: Fri, 15 Jul 2005 22:14:49 +0300
From: Jari Arkko <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC:  [email-masked]
Subject: Re: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt

Thanks for writing this up, Iljitsch -- it captures the essence
of the problem very nicely. A couple of quick questions and
comments after the first read:

> In order to reduce packet overhead, it makes sense to have different
> on-the-wire protocols for confirming existing reachability and full
> exploration of potential reachability.

This makes a lot of sense.

> There have been some discussions about positive versus negative
> feedback. The first model doesn't have any use for negative feedback,
> but needs positive feedback to reduce overhead. The second model has
> little or no use for positive feedback, but may use negative feedback
> to detect failures faster.

Can you explain why the first model wouldn't be able to use negative
feedback for faster failure detection? It seems like it could use a
trigger from TCP to send a probe earlier than it would otherwise
do it.

> To avoid exposing information (even if it's just the fact that an
> address is reachable), hosts will probably want to limit themselves to
> taking part in reachability detection with known correspondents. This
> means that there must be identifying information and a nonce that is at
> least hard to guess but easy to check in all reachability detection
> packets.

This may need to be spelled out in more detail. For instance,
when verifying reachability of the current address pair, "known
correspondent" probably means that (a) we have a shim6
"connection" to the peer and that (b) some secret information
from that connection is employed that makes at least blind
attacks from the internet impossible. On the other hand, when
doing address state exploration, "known correspondent" has
to mean something else, as we may need to do address
exploration even for the initial connection -- or am I missing
something?

> However, using negative feedback from upper
> layer protocols may prove challenging because upper layers can't be
> trusted to provide the right quality or quantity feedback ("feedback
> spamming").

I guess this is arguable. You could also claim that the upper layers
are the place that really knows what the requirements for this
particular flow are.

--Jari

Delivery-date: Fri, 15 Jul 2005 03:49:16 +0000
Date: Fri, 15 Jul 2005 13:47:59 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-hba-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming by IPv6 Intermediation 
Working Group of the IETF.

         Title           : Hash Based Addresses (HBA)
         Author(s)       : M. Bagnulo
         Filename        : draft-ietf-shim6-hba-00.txt
         Pages           : 28
         Date            : 2005-7-14

    This memo describes a mechanism to provide a secure binding between
    the multiple addresses with different prefixes available to a host
    within a multihomed site.  The main idea is that information about
    the multiple prefixes is included within the addresses themselves.
    This is achieved by generating the interface identifiers of the
    addresses of a host as hashes of the available prefixes and a random
    number.  Then, the multiple addresses are generated by prepending the
    different prefixes to the generated interface identifiers.  The
    result is a set of addresses, called Hash Based Addresses (HBAs),
    that are inherently bound.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the 
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
         "get draft-ietf-shim6-hba-00.txt".

Delivery-date: Fri, 15 Jul 2005 03:48:46 +0000
Date: Fri, 15 Jul 2005 13:48:21 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-reach-detect-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming by IPv6 Intermediation 
Working Group of the IETF.

         Title           : Shim6 Reachability Detection
         Author(s)       : I. van Beijnum
         Filename        : draft-ietf-shim6-reach-detect-00.txt
         Pages           : 6
         Date            : 2005-7-14

This draft discusses the issues of detecting failures in a currently
used address pair between two hosts and picking a new address pair to
be used when a failure occurs. The input for these processes are
ordered lists of local and remote addresses that are reasonably likely
to work. (I.e., not include addresses that are known to be unreachable
for local reasons.) These lists must be available at both ends of the
communication, although the ordering may differ. Building these address
lists from locally available information and synchronizing them with
the remote end are outside the scope of this document.

This text is for the most part based on discussions on the multi6 list,
several multi6 design team lists and the shim6 list, with notable
contributions from Erik Nordmark and Marcelo Bagnulo

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-reach-detect-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the 
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
         "get draft-ietf-shim6-reach-detect-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Delivery-date: Fri, 15 Jul 2005 03:48:46 +0000
Date: Fri, 15 Jul 2005 13:47:37 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-applicability-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming by IPv6 Intermediation 
Working Group of the IETF.

         Title           : Shim6 Applicability Statement
         Author(s)       : J. Abley
         Filename        : draft-ietf-shim6-applicability-00.txt
         Pages           : 6
         Date            : 2005-7-14

    This document discusses the applicability of the Shim6 IPv6 protocol
    element and associated support protocols to provide site multihoming
    capabilities in IPv6.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-applicability-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the 
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
         "get draft-ietf-shim6-applicability-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Delivery-date: Fri, 15 Jul 2005 01:31:33 +0000
Reply-To: <[email-masked]>
From: "Taewan You" <[email-masked]>
To: <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>, <[email-masked]>, <[email-masked]>
Subject: I-D ACTION:draft-you-shim6-l3shim-state-management-00.txt
Date: Fri, 15 Jul 2005 10:30:56 +0900
Organization: ETRI

Hello folks,
We have submitted an I-D that describes L3Shim state management using
Vertical layered communication.

In this draft, we proposed simple two ideas. 
First is a vertical layered communication method in case of interaction
between L3Shim and TCP or Upper layer.
This mechanism is achieved using defined two timers;
TCP-Congestion-Triggering-Time and Probably-Active-Duration-Time. 
Next is L3Shim state transition processes based on the events that can be
happened during lifetime.

We would appreciate to hear your comments.

Regards, 
Taewan You.

----------------------------------------------------------------------------
A New Internet-Draft is available from the on-line Internet-Drafts
directories.

	Title		: L3Shim state management using Vertical layered
Communication
	Author(s)	: T. You, et al.
	Filename	: draft-you-shim6-l3shim-state-management-00.txt
	Pages		: 14
	Date		: 2005-7-14
	
This draft proposed vertical layered communication method; especially 
it is mechanism to notify locator changing from L3Shim to TCP layer. 
In this draft, it is called indirect TCP congestion control. This 
mechanism make TCP congestion situation using behavior of L3Shim 
layer without correcting conventional TCP. And then we describe 
L3Shim state through the event. These kinds of events and progress 
state are presented in a single system view. And it will be help to 
implement L3Shim functionality through understanding L3Shim process. 

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-you-shim6-l3shim-state-management-
00.txt

Delivery-date: Thu, 14 Jul 2005 09:10:56 +0000
Cc: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: state loss detection
Date: Thu, 14 Jul 2005 11:10:25 +0200
To: Erik Nordmark <[email-masked]>

On 13-jul-2005, at 16:01, Erik Nordmark wrote:

>> It just occurred to me that the state loss problem may not be as   
>> intractable as we thought.
>>

> FWIW I don't think it is intractable. An error message "no shim6  
> context" and 8 or so protocol numbers is all that's needed to do  
> this without any byte overhead in the shim6 data packets.
>

Ok...

>> it may be a good idea to  rewrite the checksum too, in order to  
>> avoid confusing firewalls and  the like unnecessarily, and to  
>> maintain compatibility with NICs that  do checksum offloading.
>>

> I see a few problems with this:
> 1) The transport checksum no longer protects against packet  
> misdelivery to another IP address. Thus in the odd case that the  
> shim6 state has been lost, but there is some transport state which  
> matches the IP address fields and port numbers, the packet will  
> potentially be accepted by the transport (subject to sequence  
> number checks in the case of TCP).
>

Is this a realistic scenario?

I mean, hosts A and B must have a session, say using A1 and B1. Then  
there must be a rehoming, so now the packets flow between A2 and B2.  
Then, B loses state. A continues to send packets from A2 to B2. So  
obviously for a new session to clash with the existing one, either A  
must have set up a new session (which it wouldn't) or B would have to  
do it. Since A would presumably reject such a session if the protocol  
has a notion of sessions (ie, certainly TCP and probably UDP) there  
is only a window between the time B is setting up a new session and A  
hasn't rejected it. TCP and most UDP protocols use a sequence number  
or transaction id, so the chance of anything happening here is very  
small.

Alternatively, the protocol may not know about sessions. However:

- these protocols may not have checksums
- we (the shim) may not know where the checksum is in the packet
- we can selectively enable/disable checksum rewriting per protocol

So if we assume checksum rewriting will only be done for TCP and UDP,  
do you think the very small chance of session clashing is more  
important than the likelihood of confused firewalls and the  
fundamental inability to offload checksum calculations to the NIC?

> 2) Rewriting the transport checksum is hard when the packet is  
> protected by IPsec.
>

That's a feature.  :-)

> It is "just" an implementation chore in the normal case of a host  
> doing shim6, but if you ever want to have shim6 proxies/middleboxes  
> (to help with a transition to shim6) then this becomes intractable.
>

When there is encryption, there is no problem since we can't rewrite  
the checksum even if we wanted to.

For authentication-only IPsec it's still possible to do this. Since  
the authentication makes sure we have to write back the correct  
original checksum we basically get to have our cake and it it too.

Alternatively, we could only rewrite when the TCP or UDP protocol is  
the first header after the IPv6 header. I think we have to talk to  
NIC vendors.

> 3) Transport protocols unknown to the shim6 implementor (could be  
> implemented in some unrelated kernel patch, or in user space using  
> raw sockets) would need to trigger a shim6 state refresh in this  
> case. But the implementor of that (user level?) transport protocol  
> might not be aware of shim6.
>

This can be handled in several ways:

- well, learn about the shim then
- ignore this, live with the longer timeouts
- use extra bits or possibly and extra header for these protocols

What's important is that we get TCP and UDP right in an efficient  
way, because TCP is the most used protocol and UDP is often used with  
small payloads so any overhead there is especially bad.

Delivery-date: Thu, 14 Jul 2005 04:55:55 +0000
Date: Thu, 14 Jul 2005 14:52:47 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: SHIM6 WG Agenda
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Hi,

Please find attached the proposed agenda for the SHIM6 WG meeting
at IETF 63

Kurtis & Geoff

-----------------------------------------

Shim6 Working Group Agenda

     1. Agenda Bashing                        (5 minutes)

     2. Review of status and proposed work areas:

        Architecture                          (10 minutes)
           document: draft-ietf-shim6-arch-00.txt
           Geoff Huston

        Protocol                              (15 minutes)
           document:
              previous: draft-ietf-multi6-l3shim-00.txt
              submitted: draft-ietf-shim6-l3shim-00.txt

              previous: draft-ietf-multi6-functional-dec-00.txt
              expected: draft-ietf-shim6-functional-dec-00.txt
           Erik Nordmark

        Crytpo Locators                       (15 minutes)
           document:
             previous: draft-ietf-multi6-hba-00.txt
             expected: draft-ietf-shim6-hba-00.txt

             Refers to: draft-ietf-send-cga-06.txt
           Marcelo Bagnulo, Jari Arkko

        Triggers                              (15 minutes)
           document:   draft-ietf-shim6-reach-detect-00.txt
             previous: draft-ietf-multi6-failure-detection-00.txt
           Iljitsch van Beijnum

        Applicability                         (15 minutes)
           documents: draft-ietf-shim6-applicability-00.txt
                      draft-ietf-shim6-app-refer-00.txt
           Joe Abley

     3. Discussion about approach             (25 minutes)

     4. Additional Items:

       - Interactions between Shim6 and MIPv6 (15 minutes)
            draft-bagnulo-shim6-mip-00.txt
            Marcelo Bagnulo

       - L3Shim state management using Vertical (5 minutes)
         layered Communication
           draft-you-shim6-L3Shim-state-meagement-00.txt
           You Taewan

Co-Chairs

   Kurtis Lindqvist
   Geoff Huston

Delivery-date: Wed, 13 Jul 2005 15:32:36 +0000
Date: Wed, 13 Jul 2005 07:01:32 -0700
From: Erik Nordmark <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6 <[email-masked]>
Subject: Re: state loss detection

Iljitsch van Beijnum wrote:
> Hi,
> 
> It just occurred to me that the state loss problem may not be as  
> intractable as we thought.

FWIW I don't think it is intractable. An error message "no shim6 
context" and 8 or so protocol numbers is all that's needed to do this 
without any byte overhead in the shim6 data packets.

> The problem is that when (for instance) a host taking part in the  shim6 
> protocol reboots, and it sees shimmed packets when it gets back  on its 
> feet again, it gets confused. If the packets that are  rewritten by the 
> shim only have their addresses rewritten, the  checksum on those packets 
> will be invalid, the packet will be dropped  and the source host doesn't 
> get to hear about it so the failure won't  be detected until there is a 
> timeout.
> 
> However, as I wrote in a draft a while ago, it may be a good idea to  
> rewrite the checksum too, in order to avoid confusing firewalls and  the 
> like unnecessarily, and to maintain compatibility with NICs that  do 
> checksum offloading. (Although I'm not familiar with ones that do  this 
> for IPv6.)

I see a few problems with this:
1) The transport checksum no longer protects against packet misdelivery 
to another IP address. Thus in the odd case that the shim6 state has 
been lost, but there is some transport state which matches the IP 
address fields and port numbers, the packet will potentially be accepted 
by the transport (subject to sequence number checks in the case of TCP).

2) Rewriting the transport checksum is hard when the packet is protected 
by IPsec. It is "just" an implementation chore in the normal case of a 
host doing shim6, but if you ever want to have shim6 proxies/middleboxes 
(to help with a transition to shim6) then this becomes intractable.

3) Transport protocols unknown to the shim6 implementor (could be 
implemented in some unrelated kernel patch, or in user space using raw 
sockets) would need to trigger a shim6 state refresh in this case. But 
the implementor of that (user level?) transport protocol might not be 
aware of shim6.

    Erik

Delivery-date: Wed, 13 Jul 2005 07:30:47 +0000
Date: Wed, 13 Jul 2005 17:29:05 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-failure-detection-00.txt

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming by IPv6 Intermediation 
Working Group of the IETF.

         Title           : Failure Detection and Locator Selection Design 
Considerations
         Author(s)       : J. Arkko
         Filename        : draft-ietf-shim6-failure-detection-00.txt
         Pages           : 28
         Date            : 2005-7-12

    This draft discusses locator pair selection and failure detection
    mechanisms for the IPv6 multihoming feature being developed in the
    SHIM6 working group.  Elements of this document may also be useful
    for developing the details of the MOBIKE or HIP multihoming
    mechanisms.  The draft also discusses the roles of a multihoming
    protocol versus network attachment functions at IP and link layers.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the 
message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
         "get draft-ietf-shim6-failure-detection-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Delivery-date: Wed, 13 Jul 2005 07:25:41 +0000
Date: Wed, 13 Jul 2005 17:25:02 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-l3shim-00.txt    

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming by IPv6 Intermediation 
Working Group of the IETF.

         Title           : Multihoming L3 Shim Approach
         Author(s)       : E. Nordmark, M. Bagnulo
         Filename        : draft-ietf-shim6-l3shim-00.txt
         Pages           : 30
         Date            : 2005-7-12

    This document specifies a particular approach to IPv6 multihoming.
    The approach is based on using a multihoming shim placed between the
    IP endpoint sublayer and the IP routing sublayer, and, at least
    initially, using routable IP locators as the identifiers visible
    above the shim layer.  The approach does not introduce a ^stack name^
    type of identifier, instead it ensures that all upper layer protocols
    can operate unmodified in a multihomed setting while still seeing a
    stable IPv6 address.

    This document does not specify the mechanism for authenticating and
    authorizing the ^rehoming^ - this is specified in the HBA document.
    Nor does it specify the messages used to establish multihoming state.

    The document does not even specify the packet format used for the
    data packets.  Instead it discusses the issue of receive side
    demultiplexing and the different tradeoffs.  The resolution of this
    issue will affect the packet format for the data packets.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-l3shim-00.txt

Delivery-date: Mon, 11 Jul 2005 13:10:06 +0000
To: shim6 <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: state loss detection
Date: Mon, 11 Jul 2005 15:09:32 +0200

Hi,

It just occurred to me that the state loss problem may not be as  
intractable as we thought.

The problem is that when (for instance) a host taking part in the  
shim6 protocol reboots, and it sees shimmed packets when it gets back  
on its feet again, it gets confused. If the packets that are  
rewritten by the shim only have their addresses rewritten, the  
checksum on those packets will be invalid, the packet will be dropped  
and the source host doesn't get to hear about it so the failure won't  
be detected until there is a timeout.

However, as I wrote in a draft a while ago, it may be a good idea to  
rewrite the checksum too, in order to avoid confusing firewalls and  
the like unnecessarily, and to maintain compatibility with NICs that  
do checksum offloading. (Although I'm not familiar with ones that do  
this for IPv6.)

With the checksum rewritten as well, the packet will flow through the  
shim layer without any action as there is no state, and the upper  
layer will generate an error, such as a TCP RST.

In and of itself this doesn't provide the host that still has state  
with the information it needs to recover from the remote state loss  
(it could have been a legitimate RST that was shimmed), but it  
wouldn't be huge imposition to send a shim state refresh when this  
happens.

For TCP and UDP where the host with the state loss used an ephemeral  
port this should work well. I'm not sure what happens when an UDP  
server does when it sees packets for an unknown "session". For non- 
UDP/TCP protocols the transport protocol would probably have to  
trigger a shim state refresh.

Delivery-date: Thu, 07 Jul 2005 03:44:50 +0000
Date: Wed, 6 Jul 2005 23:41:45 -0400
To: [email-masked]
From: Margaret Wasserman <[email-masked]>
Subject: NEW!!  Internet Area Mailing List

[This message is bcc:ed to all INT area WGs, the IESG and the IAB.]

Hi All,

We have created an Internet Area mailing list -- [email-masked]. 
This list will be used to announce Internet area BOFs, to discuss 
Internet area WG charter updates and to discuss other issues related 
to the Internet Area, as they arise -- such as whether we should hold 
an Internet area meeting in Paris.

If you wish to join the list, you can do so at:

https://www1.ietf.org/mailman/listinfo/int-area

The archives should be available at:

http://www.ietf.org/mail-archive/web/int-area/index.html

(Hopefully this will be the first message in the archive).

If you are interested in issues concerning the overall structure or 
scope of the Internet area and/or are interested in influencing how 
the Internet area is managed, I hope you will join this list.

Thanks,
Margaret

Delivery-date: Wed, 06 Jul 2005 20:24:20 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-shim6-app-refer-00.txt
Date: Tue, 05 Jul 2005 18:50:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming by IPv6 Intermediation Working Group of the IETF.

	Title		: Shim6 Application Referral Issues
	Author(s)	: E. Nordmark
	Filename	: draft-ietf-shim6-app-refer-00.txt
	Pages		: 12
	Date		: 2005-7-5

   In order to fully solve the scalable multihoming problem there is a
   need to separate the current IP address functionality into
   identifiers (which are used to identify e.g., TCP connections) and
   locators which are used to forward packets in the routing system.
   Such a separation has an impact on the current use of IP address in
   the application layer.

   This document presents these issues for the purposes of stimulating
   discussions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-app-refer-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-shim6-app-refer-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-shim6-app-refer-00.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-shim6-app-refer-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-shim6-app-refer-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Wed, 06 Jul 2005 20:23:09 +0000
To: [email-masked]
Cc: [email-masked]
From: [email-masked]
Subject: I-D ACTION:draft-ietf-shim6-arch-00.txt
Date: Tue, 05 Jul 2005 15:50:01 -0400

--NextPart

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming by IPv6 Intermediation Working Group of the IETF.

	Title		: Architectural Commentary on Site Multi-homing using a Level 3 Shim
	Author(s)	: G. Huston
	Filename	: draft-ietf-shim6-arch-00.txt
	Pages		: 16
	Date		: 2005-7-5

   This document provides an architectural description of the level 3
   shim approach to site Multi-homing in IPv6 as described in
   [ID.SHIM6], [ID.REFER], [ID.FUNC], and [ID.HBA], using as a framework
   for this analysis the approach described in [ID.ARCH].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt

To remove yourself from the I-D Announcement list, send a message to
[email-masked] with the word unsubscribe in the body of the message.
You can also visit https://www1.ietf.org/mailman/listinfo/I-D-announce
to change your subscription settings.

Internet-Drafts are also available by anonymous FTP. Login with the username
"anonymous" and a password of your e-mail address. After logging in,
type "cd internet-drafts" and then
	"get draft-ietf-shim6-arch-00.txt".

A list of Internet-Drafts directories can be found in
http://www.ietf.org/shadow.html
or ftp://ftp.ietf.org/ietf/1shadow-sites.txt

Internet-Drafts can also be obtained by e-mail.

Send a message to:
	[email-masked].
In the body type:
	"FILE /internet-drafts/draft-ietf-shim6-arch-00.txt".

NOTE:	The mail server at ietf.org can return the document in
	MIME-encoded form by using the "mpack" utility.  To use this
	feature, insert the command "ENCODING mime" before the "FILE"
	command.  To decode the response(s), you will need "munpack" or
	a MIME-compliant mail reader.  Different MIME-compliant mail readers
	exhibit different behavior, especially when dealing with
	"multipart" MIME messages (i.e. documents which have been split
	up into multiple messages), so check your local documentation on
	how to manipulate these messages.

Below is the data which will enable a MIME compliant mail reader
implementation to automatically retrieve the ASCII version of the
Internet-Draft.

--NextPart
Content-Type: Multipart/Alternative; Boundary="OtherAccess"

--OtherAccess
Content-Type: Message/External-body;
	access-type="mail-server";
	server="[email-masked]"

Content-Type: text/plain
Content-ID:	<[email-masked]>

ENCODING mime
FILE /internet-drafts/draft-ietf-shim6-arch-00.txt

--OtherAccess
Content-Type: Message/External-body;
	name="draft-ietf-shim6-arch-00.txt";
	site="ftp.ietf.org";
	access-type="anon-ftp";
	directory="internet-drafts"

Content-Type: text/plain
Content-ID:	<[email-masked]>

--OtherAccess--

--NextPart--

Delivery-date: Tue, 05 Jul 2005 23:35:21 +0000
Date: Wed, 06 Jul 2005 09:35:00 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-app-refer-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming by IPv6 Intermediation 
Working Group of the IETF.

         Title           : Shim6 Application Referral Issues
         Author(s)       : E. Nordmark
         Filename        : draft-ietf-shim6-app-refer-00.txt
         Pages           : 12
         Date            : 2005-7-5

    In order to fully solve the scalable multihoming problem there is a
    need to separate the current IP address functionality into
    identifiers (which are used to identify e.g., TCP connections) and
    locators which are used to forward packets in the routing system.
    Such a separation has an impact on the current use of IP address in
    the application layer.

    This document presents these issues for the purposes of stimulating
    discussions.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-app-refer-00.txt

Delivery-date: Tue, 05 Jul 2005 22:18:14 +0000
Date: Wed, 06 Jul 2005 08:17:38 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: Proposed Agenda for the SHIM6 WG meeting
Cc: [email-masked], [email-masked]

Hi,

Here's the proposed agenda for initial SHIM6 WG meeting

Please let us know if you have any additions / comments

regards,

    Geoff & Kurtis

-------------------------------------------------------

     Shim6 Working Group Agenda

     1. Agenda Bashing                        (5 minutes)

     2. Review of status and proposed work areas:

        Architecture                          (10 minutes)
           document: draft-ietf-shim6-arch-00.txt
           Geoff Huston

        Protocol                              (15 minutes)
           document: tbd
           Erik Nordmark

        Crytpo Locators                       (15 minutes)
           document: tbd
           Marcelo Bagnulo, Jari Arkko

        Triggers                              (15 minutes)
           document:
           Iljitsch van Beijnum

        Applicability                         (15 minutes)
           document: tbd
           Joe Abley

        Other documents:
          draft-ietf-shim6-app-refer-00.txt

     3. Discussion about approach             (30 minutes)

     4. Additional Items:

       - Interactions between Shim6 and MIPv6 (15 minutes)
            (no draft yet)
            Marcelo Bagnulo

Delivery-date: Tue, 05 Jul 2005 22:03:52 +0000
Date: Wed, 06 Jul 2005 08:03:10 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: I-D ACTION:draft-ietf-shim6-arch-00.txt 

A New Internet-Draft is available from the on-line Internet-Drafts directories.
This draft is a work item of the Site Multihoming by IPv6 Intermediation 
Working Group of the IETF.

         Title           : Architectural Commentary on Site Multi-homing 
using a Level 3 Shim
         Author(s)       : G. Huston
         Filename        : draft-ietf-shim6-arch-00.txt
         Pages           : 16
         Date            : 2005-7-5

    This document provides an architectural description of the level 3
    shim approach to site Multi-homing in IPv6 as described in
    [ID.SHIM6], [ID.REFER], [ID.FUNC], and [ID.HBA], using as a framework
    for this analysis the approach described in [ID.ARCH].

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-arch-00.txt

Delivery-date: Mon, 04 Jul 2005 03:34:44 +0000
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: Joe Abley <[email-masked]>
Subject: Re: proposed workplan for Shim6
Date: Sun, 3 Jul 2005 23:34:11 -0400
To: Geoff Huston <[email-masked]>

On 2005-07-03, at 18:03, Geoff Huston wrote:

> Will you be lining up someone to assist you to present this material?

I will try hard to do so, if it turns out that I can't make it.

Joe

Delivery-date: Sun, 03 Jul 2005 22:04:23 +0000
Date: Mon, 04 Jul 2005 08:03:01 +1000
To: Joe Abley <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: proposed workplan for Shim6
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

Hi Joe,

Will you be lining up someone to assist you to present this material?

   regards,

     Geoff

At 05:53 AM 4/07/2005, Joe Abley wrote:
>Hey,
>
>On 2005-07-03, at 01:02, Geoff Huston wrote:
>
>>   - applicability statements
>>      Joe Abley
>>      no initial base document, although the functional description
>>      and architecture documents may provide initial material, and
>>      the app-refer draft may also be relevant here.
>
>This will be fine, however:
>
>>        Aplicability                          (15 minutes)
>>           document: tbd
>>           Joe Abley
>
>the chances are reasonable to good that I will not be in Paris in
>August, and so I will need to present by proxy.
>
>
>Joe
>

Delivery-date: Sun, 03 Jul 2005 19:54:00 +0000
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]
From: Joe Abley <[email-masked]>
Subject: Re: proposed workplan for Shim6
Date: Sun, 3 Jul 2005 15:53:20 -0400
To: Geoff Huston <[email-masked]>

Hey,

On 2005-07-03, at 01:02, Geoff Huston wrote:

>   - applicability statements
>      Joe Abley
>      no initial base document, although the functional description
>      and architecture documents may provide initial material, and
>      the app-refer draft may also be relevant here.

This will be fine, however:

>        Aplicability                          (15 minutes)
>           document: tbd
>           Joe Abley

the chances are reasonable to good that I will not be in Paris in  
August, and so I will need to present by proxy.

Joe

Delivery-date: Sun, 03 Jul 2005 05:18:40 +0000
Date: Sun, 03 Jul 2005 15:02:22 +1000
To: [email-masked]
From: Geoff Huston <[email-masked]>
Subject: proposed workplan for Shim6
Cc: [email-masked], [email-masked], [email-masked], [email-masked], [email-masked], [email-masked]

The proposed workplan for SHIM6

We have a relatively aggressive set of milestones for this effort
which will require some organizational effort to see through, while
at the same time making sure that we are looking at this in terms
of the quality of the work.

In particular the initial focus is on the August milestones of
our charter, publishing initial drafts of

   - architecture
   - protocol
   - use of cryptographic locators
   - multi-homing triggers
   - applicability statement

The good news is that we're building from where Multi6 left off,
and the document set that we can start from is:

   draft-huston-l3shim-arch-00.txt
   draft-ietf-multi6-functional-dec-00.txt
   draft-ietf-multi6-l3shim-00.txt
   draft-ietf-multi6-failure-detection-00.txt
   draft-ietf-multi6-hba-00.txt
   draft-ietf-multi6-app-refer-00.txt

To get things started, Kurtis and I have asked a number of folk to
take the role of lead author / editor of each of these areas, and
they have kindly agreed to do so. They are:

   - architecture of Shim6
      Geoff Huston
      initial base document: draft-huston-l3shim-arch-00.txt

   - protocol
      Erik Nordmark
      initial base document: draft-ietf-multi6-l3shim-00.txt
      (depending on scope, an additional person may be needed here)

   - use of cryptographic locators
      Marcelo Bagnulo, Jari Arkko
      initial base document: draft-ietf-multi6-hba-00.txt

   - multi-homing triggers
        Iljitsch van Beijnum
       initial base document: draft-ietf-multi6-failure-detection-00.txt

   - applicability statements
      Joe Abley
      no initial base document, although the functional description
      and architecture documents may provide initial material, and
      the app-refer draft may also be relevant here.

The current plan is:

a) to request the lead authors / editors to resubmit the multi6
    documents as shim6 wg documents in the next week (prior to the
    -00 draft cutoff for the Paris IETF meeting)

b) to proceed with a 2 hour Working Group meeting in August as
    follows:

     Shim6 Working Group Agenda

     1. Agenda Bashing                        (5 minutes)

     2. Review of status and proposed work areas:

        Architecture                          (10 minutes)
           document: tbd
           Geoff Huston

        Protocol                              (15 minutes)
           document: tbd
           Erik Nordmark

        Crytpo Locators                       (15 minutes)
           document: tbd
           Marcelo Bagnulo, Jari Arkko

        Triggers                              (15 minutes)
           document: tbd
           Iljitsch van Beijnum

        Aplicability                          (15 minutes)
           document: tbd
           Joe Abley

     3. Discussion about approach             (30 minutes)

     4. Additional Items:

       - Interactions between Shim6 and MIPv6 (15 minutes)
            (no draft yet)
            Marcelo Bagnulo

Thanks,

   Kurtis & Geoff