Subject: Re: State of play with Shim6 documents
From: Brian E Carpenter <[email-masked]>
To: "Henderson, Thomas R" <[email-masked]>
Cc: Geoff Huston <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]
Date: Mon, 29 Jan 2007 10:06:06 +0100

>  
> 
>> -----Original Message-----
>> From: Brian E Carpenter [mailto:[email-masked]] 
>> Sent: Saturday, January 27, 2007 12:32 PM
>> To: Henderson, Thomas R
>> Cc: Geoff Huston; shim6-wg; [email-masked]
>> Subject: Re: State of play with Shim6 documents
>>
>> On 2007-01-24 19:06, Henderson, Thomas R wrote:
>>>> -----Original Message-----
>> ...
>>>>      * TCP Checksum Failure
>>>>
>>>>            Its not clear what the WG want to do on this. 
>> Suggestions?
>>> I would vote to align the checksum with the locators, under the
>>> assumption that defining an alternate probing mechanism to discover
>>> these problems is more cumbersome.  If you care strongly 
>> enough about
>>> using the transport checksum to detect incorrect address 
>> rewriting in
>>> certain error scenarios, that may argue for putting better error
>>> detection in the shim proper, but I'm not sure it is a high enough
>>> probability event.
>> I have the opposite view. I think we should keep rock solid
>> on the notion that shim6 preserves the end to end model as far
>> as upper layers are concerned. Fixing the TCP checksum twice,
>> on the way in and out of the shim, would be an ugly hack on
>> that model, and also the first step towards inserting all
>> sorts of ALG functionality in the shim to compensate for
>> misbehaving middleboxes.
>>
>> Before taking any other decision, I'd want to see firm
>> observational evidence that there is a real problem. TCP
>> checksums are no business of middleboxes, except for the
>> TCP relay case which would probably need to be shim6-aware.
>>
> 
> I agree that it would be best to make decision based on operational
> experience, but I am suspicious about the future for IPv6 because there
> is no IP checksum, so it might encourage routers or middleboxes to
> provide transport checksum validation as a feature.
> 
> But perhaps it would be prudent to devise an extension only if
> shim6-awareness doesn't materialize in practice, and keep it cleaner for
> now.

I like that approach. I hope we have some spare bits that would allow
us to signal that TCP checksum recomputation is in use.

     Brian

Delivery-date: Mon, 29 Jan 2007 06:24:49 +0000
Content-class: urn:content-classes:message
Subject: RE: State of play with Shim6 documents
Date: Sun, 28 Jan 2007 22:21:34 -0800
From: "Henderson, Thomas R" <[email-masked]>
To: "Brian E Carpenter" <[email-masked]>
Cc: "Geoff Huston" <[email-masked]>, "shim6-wg" <[email-masked]>, <[email-masked]>

=20

> -----Original Message-----
> From: Brian E Carpenter [mailto:[email-masked]]=20
> Sent: Saturday, January 27, 2007 12:32 PM
> To: Henderson, Thomas R
> Cc: Geoff Huston; shim6-wg; [email-masked]
> Subject: Re: State of play with Shim6 documents
>=20
> On 2007-01-24 19:06, Henderson, Thomas R wrote:
> >> -----Original Message-----
>=20
> ...
> >>
> >>      * TCP Checksum Failure
> >>
> >>            Its not clear what the WG want to do on this.=20
> Suggestions?
> >>
> >=20
> > I would vote to align the checksum with the locators, under the
> > assumption that defining an alternate probing mechanism to discover
> > these problems is more cumbersome.  If you care strongly=20
> enough about
> > using the transport checksum to detect incorrect address=20
> rewriting in
> > certain error scenarios, that may argue for putting better error
> > detection in the shim proper, but I'm not sure it is a high enough
> > probability event.
>=20
> I have the opposite view. I think we should keep rock solid
> on the notion that shim6 preserves the end to end model as far
> as upper layers are concerned. Fixing the TCP checksum twice,
> on the way in and out of the shim, would be an ugly hack on
> that model, and also the first step towards inserting all
> sorts of ALG functionality in the shim to compensate for
> misbehaving middleboxes.
>=20
> Before taking any other decision, I'd want to see firm
> observational evidence that there is a real problem. TCP
> checksums are no business of middleboxes, except for the
> TCP relay case which would probably need to be shim6-aware.
>=20

I agree that it would be best to make decision based on operational
experience, but I am suspicious about the future for IPv6 because there
is no IP checksum, so it might encourage routers or middleboxes to
provide transport checksum validation as a feature.

But perhaps it would be prudent to devise an extension only if
shim6-awareness doesn't materialize in practice, and keep it cleaner for
now.

Tom

Delivery-date: Sat, 27 Jan 2007 20:33:44 +0000
Date: Sat, 27 Jan 2007 21:31:42 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: "Henderson, Thomas R" <[email-masked]>
CC: Geoff Huston <[email-masked]>, shim6-wg <[email-masked]>, [email-masked]
Subject: Re: State of play with Shim6 documents

On 2007-01-24 19:06, Henderson, Thomas R wrote:
>> -----Original Message-----

...
>>
>>      * TCP Checksum Failure
>>
>>            Its not clear what the WG want to do on this. Suggestions?
>>
> 
> I would vote to align the checksum with the locators, under the
> assumption that defining an alternate probing mechanism to discover
> these problems is more cumbersome.  If you care strongly enough about
> using the transport checksum to detect incorrect address rewriting in
> certain error scenarios, that may argue for putting better error
> detection in the shim proper, but I'm not sure it is a high enough
> probability event.

I have the opposite view. I think we should keep rock solid
on the notion that shim6 preserves the end to end model as far
as upper layers are concerned. Fixing the TCP checksum twice,
on the way in and out of the shim, would be an ugly hack on
that model, and also the first step towards inserting all
sorts of ALG functionality in the shim to compensate for
misbehaving middleboxes.

Before taking any other decision, I'd want to see firm
observational evidence that there is a real problem. TCP
checksums are no business of middleboxes, except for the
TCP relay case which would probably need to be shim6-aware.

     Brian

Delivery-date: Fri, 26 Jan 2007 12:57:03 +0000
Date: Fri, 26 Jan 2007 13:53:10 +0100
From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
To:  [email-masked],  [email-masked]
CC:  [email-masked]
Subject: About draft-ietf-shim6-failure-detection-07 {2}

Hi,

I have another question regarding the failure detection draft. This is 
about the end of an exploration. I think it is useful to have a notion of
- when an exploration process begins.
- when an exploration process terminates.

* Motivation :
    - An implementation might want to have a specific thread/process for 
each exploration. It is useful to know when the exploration thread may 
be terminated.
    - We need to store information about each probe sent/received 
(because reports are included in the probes). It is useful to know when 
the memory used by this information can be released. This would ensure 
that only information relative to the current exploration is stored in 
memory. Also, a context in operational state would need less space than 
a context in course of exploration, which is more scalable if lots of 
contexts are present.

* The problem :

While it is rather evident when we must trigger an exploration (send 
timer expiry or incoming probe exploring), we are not so certain about 
the end of an exploration. More precisely *one of the peers* is not 
certain, while the other is. Here is an example situation with the 
currently defined scheme for the end of an exploration :

 Peer A                                        Peer B
      |                                             |
    State:                                        State:
  Inbound_OK                                    Exploring
      |                                             |
      |           Probe Inbound OK                  |
      |-------------------------------------------->|
      |                                           State:
      |                                         Operational
      |           Probe Operational                 |
      |    	  /---------------------------------| path working, but probe lost (because of 
      |                                             | congestion for example)
      |           Probe Inbound OK                  |
      |-------------------------------------------->| 
      |                                             |
      |           Probe Operational                 |
      |<--------------------------------------------|
      |                                             | Now B can forget its received/sent probe reports, 
   State : 					    | because A is in state operational, but B has no way to know it.
 Operational

As illustrated in this scenario, when A receives a probe Operational, it 
knows for sure that B is operational, and so that the exploration 
process is terminated. But B won't receive such a probe. B enters into 
the Operational state when he receives a Probe Inbound OK. This means 
that he knows the conversation will work from now, but this doesn't 
mean, however, that A won't ever ask B to send its list of sent/recvd 
probe reports, as is the case in the above scenario (because of the 
first probe operational being lost).

* One possible (and simple :-) ) solution :

Because the only problem is for B to know for sure that A is 
operational. Just let it know this fact by sending another Probe 
Operational. Of course, with such a rule, we could end up with A and B 
infinitely sending Probes Operational. This can be simply solved by 
having something different in the last Probe Operational, such as a 
flag. This can also be solved by sending no probe report (psent=0 and 
precevd=0). This may seem contradictory with my previous mail, but it 
isn't : we are here in the special case where A *knows* that B is in 
operational state, so he doesn't need anymore to have any probe 
information, his only need is now to be sure that A is also in 
operational state. In fact, the only thing that B will do when receiving 
the last probe is check whether this is an operational probe or an 
Inbound OK probe :
    - in the first case : stop the exploration process gracefully
    - in the last case : The last probe operational from B has been 
lost, send another one.
This results in the following (very similar, but much simpler/efficient 
from an implementation point of view, IMHO) scenario :

 Peer A                                        Peer B
      |                                             |
    State:                                        State:
  Inbound_OK                                    Exploring
      |                                             |
      |           Probe Inbound OK                  |
      |-------------------------------------------->|
      |                                           State:
      |                                         Operational
      |           Probe Operational                 |
      |    	  /---------------------------------| path working, but probe lost (because of 
      |                                             | congestion for example)
      |           Probe Inbound OK                  |
      |-------------------------------------------->| 
      |                                             |
      |           Probe Operational                 |
      |<--------------------------------------------|
      |	                                            |
   State : 					    | 
 Operational					    |
      |						    |
      |           Probe Operational|final           |
      |-------------------------------------------->|
      |                                             | Now B can forget its received/sent probe reports, 

In fact, the final flag is not necessary, because there is no ambiguity, 
here would be the difference in the state machine :
event : Reception of the probe message State Operational
if in state Operational : just update timers (see draft) -> *end of 
exploration*
if in state Inbound_OK : goto Operational, update timers AND send a 
probe operational
if in state Exploring : goto Operational, update timers AND send a probe 
operational (mmm, in fact i guess this case should not occur, unless one 
of the peers is buggy, but this answer to this little probable event 
seems OK).

What is your opinion ?
Thanks for any comments,

S�bastien.

-- 
S�bastien Barr�
Researcher,
CSE department, UCLouvain, Belgium

Delivery-date: Fri, 26 Jan 2007 09:25:08 +0000
From: "Taewan You" <[email-masked]>
To: "'Matthijs Mekking'" <[email-masked]>
Cc: <[email-masked]>, <[email-masked]>
Subject: RE: shim6 interoperability / traffic analyzer
Date: Fri, 26 Jan 2007 18:23:26 +0900

Matthijs Mekking,

Past 67th IETF, some peoples, who interest implementing shim6 (Ericsson,
Boeing, ETRI, and SNU), discussed in collaboration with each other, included
interop. test.

As a result, we had set up the email list, and wiki by Marcelo. However, so
far the cooperation is the situation, which it barely starts. So currently
you can not get some information from the ML or wiki about shim6
implementing work. 

But first, anyone who wants to interest the shim6 implementing work can rise
up a thread to help or interop. test by using ML :-), then we will derive
concretely action items to collaborate it.

And if your information of a shim6 code also would be announced to all with
much circumstance, it will in pretty handy in our implementing work.

Regards,
Taewan You
ETRI, Korea.

p.s this is the ML for implementation issues
"To subscribe just send an email to: [email-masked]"

> -----Original Message-----
> From: [email-masked] [mailto:[email-masked]] On Behalf Of
> Matthijs Mekking
> Sent: Thursday, January 25, 2007 9:36 PM
> To: [email-masked]
> Subject: shim6 interoperability / traffic analyzer
> 
> 
> -----BEGIN PGP SIGNED MESSAGE-----
> Hash: SHA1
> 
> Hello,
> 
> For my research at NLnetLabs, I'm currently working at the Wireshark
> traffic analyzer that can read SHIM6. Additionally, I want to carry out
> an interoperability test on the early versions of SHIM6 implementations.
>  I only could find the implementation of Sebastien (of the UCL, many
> thanks for that), and I would like to play with an implementation from a
> different code base. Is anybody interested in having their
> implementation (even if it is an early version) to undertake an
> interoperability test? I will present my results to this list.
> 
> Regards,
> 
> Matthijs Mekking
> [email-masked]
> NLnetLabs/Radboud University
> -----BEGIN PGP SIGNATURE-----
> Version: GnuPG v1.4.1 (GNU/Linux)
> Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org
> 
> iD8DBQFFuKQtNiaStnTWEtYRAsQ+AJ936JHM7J9bzM+evKW7FUPt5lD0CQCguX8i
> vVsEl907UY9mjRULAKQAiAw=
> =eY4M
> -----END PGP SIGNATURE-----

Delivery-date: Thu, 25 Jan 2007 12:37:01 +0000
Date: Thu, 25 Jan 2007 13:35:57 +0100
From: Matthijs Mekking <[email-masked]>
To: [email-masked]
Subject: shim6 interoperability / traffic analyzer

Hello,

For my research at NLnetLabs, I'm currently working at the Wireshark
traffic analyzer that can read SHIM6. Additionally, I want to carry out
an interoperability test on the early versions of SHIM6 implementations.
 I only could find the implementation of Sebastien (of the UCL, many
thanks for that), and I would like to play with an implementation from a
different code base. Is anybody interested in having their
implementation (even if it is an early version) to undertake an
interoperability test? I will present my results to this list.

Regards,

Matthijs Mekking
[email-masked]
NLnetLabs/Radboud University

Delivery-date: Thu, 25 Jan 2007 11:18:19 +0000
Date: Thu, 25 Jan 2007 12:15:38 +0100
From: =?ISO-8859-1?Q?S=E9bastien_Barr=E9?= <[email-masked]>
To:  [email-masked],  [email-masked]
CC:  [email-masked]
Subject: About draft-ietf-shim6-failure-detection-07

Hi,

while implementing the failure detection draft version 7 (new release 
available soon at http://gforge.info.ucl.ac.be/projects/shim6/), I have 
found some things I would like to ask precisions about :

section 3.1 : available addresses
----------------------------------------------------
--
 Where IPv6 link-local addresses are used, their use needs to be
      unambiguous as follows.  At most one link-local address may be
      used per node within the same connection between two peers.
--

Why ? What is the problem in dealing with multiple link-local addresses ?
In fact, I think the problem is not in dealing with multiple link-local 
addresses, but rather in making sure we use a link-local address over 
the right link.

* Using the peer's link-local address (announced during shim6 
intialization in the peer locator set) : The problem is that we have no 
way to know if the peer is in the same subnetwork as us. Moreover, if we 
have multiple interfaces, which is the one corresponding to the given 
link-local address ? Because of this, I think it is not correct to send 
the link-local addresses as part of the locator list during shim6 
initialization without a proper mechanism, but I also guess it is not 
worth designing such a mechanism, given the limited interest in doing that.
* Using the local link-local address as source for exploration : If we 
use our link-local address as source, we know over which link to use it, 
but this is not really useful if we don't know if our peer is inside our 
subnetwork.

* In summary, it appears to me that link-local addresses are not really 
suitable for use with shim6/reap. Am I missing something ?

State machine (table 4)
--------------------------------------

--
Upon a timeout on the Send timer, the node enters the Exploring
   state, sends a Probe, and stops the Keepalive timer if it was
   running.
--
 Why to stop the Keepalive timer ? Isn't it always stopped when the send 
timer is running ? (so necessarily also if it does a timeout).

Incoming probe Inbound OK
----------------------------------------------

As specified in the draft, the reception of a probe Inbound OK triggers 
a come back to the operational state. But a come back to the operational 
state implies that a pair of working locators are given to the shim, for 
use as current locator pair. AFAIK, this locator pair must be chosen in 
the list of probes received : each received probe report contains a 
working locator pair, which may be chosen as the new current locator 
pair. Now, the problem is that it is possible to receive a probe Inbound 
OK without any probe reception report inside. For example, if the peer 
receives an incoming packet while in state exploring, it will send an 
Inbound OK probe without any source reception report. In this case the 
receiver of that probe is only able to know that *there is* a working 
locator pair, but it cannot know which is that locator pair. In fact I 
guess we have two solutions to solve this :
- Let the draft as is : When we receive a probe Inbound OK without any 
received probe report (Precvd=0), we conclude that a payload packet or a 
keepalive has been received by the peer, which means that we can come 
back to the operational state without changing the current locators. 
(Because payload packets and keepalives are sent with current locators).
- Find some way to report the reception of data packets/keepalives : In 
the case of probes having been received, this would allow to tell the 
peer that also the current locator pair is working.

What do you think ?

S�bastien.

-- 
S�bastien Barr�
Researcher,
CSE department, UCLouvain, Belgium

Delivery-date: Thu, 25 Jan 2007 11:09:20 +0000
Date: Thu, 25 Jan 2007 12:05:34 +0100
From: =?UTF-8?B?U8OpYmFzdGllbiBCYXJyw6k=?= <[email-masked]>
To:  [email-masked]
CC: "Henderson, Thomas R" <[email-masked]>
Subject: Re: State of play with Shim6 documents

Hi,

Henderson, Thomas R wrote:
> from the current draft:
>   
>> The shim6 control messages use the same extension
>> header formats so that a single "protocol number" needs to be allowed
>> through firewalls in order for shim6 to function across the firewall.
>>     
>
> Besides the fragmentation issue, the way it is defined now, it seems
> burdensome to implementations that want to implement the shim6 control
> plane as a user-space daemon (as opposed to defining a separate protocol
> number for shim6 control messages).  My reading of IPv6 raw sockets
> semantics suggests that they cannot be used.
>
> from RFC 3542:
> "With IPv6 raw sockets will be
>    used for ICMPv6 and to read and write IPv6 datagrams containing a
>    Next Header field that the kernel does not process."
>
> This is not the case for shim6 since the kernel does process the payload
> extension header in the data plane.
>
> Under current definition, how should a user-space shim6 implementation
> use IPv6 sockets API to get only the control messages?  If there isn't
> an easy way, should we consider to separate the protocol numbers?  
>   
In the Linux Kernel, the packets are first delivered to the raw sockets, 
then processed by the kernel, if some protocol is implemented to handle 
this. This implies that if we want to have a user space raw socket that 
receives only the shim6 control messages, we need to have some shim6 
specific code inside the raw delivery kernel function, which is of 
course possible, but probably not the cleanest way to do things.

So I think I agree with Thomas : It would be helpful to have a separate 
protocol number for control and  payload messages.

Sébastien.
> Tom
>
>
>   

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium

Delivery-date: Wed, 24 Jan 2007 18:10:12 +0000
Content-class: urn:content-classes:message
Subject: RE: State of play with Shim6 documents
Date: Wed, 24 Jan 2007 10:06:27 -0800
From: "Henderson, Thomas R" <[email-masked]>
To: "Geoff Huston" <[email-masked]>, "shim6-wg" <[email-masked]>
Cc: <[email-masked]>

> -----Original Message-----
> From: Geoff Huston [mailto:[email-masked]]=20
> Sent: Monday, January 22, 2007 3:21 PM
> To: shim6-wg
> Cc: [email-masked]
> Subject: Re: State of play with Shim6 documents
>=20
> It seems that asking these questions has stopped all further=20
> discussion on this topic, which is a pity, as it would be good to=20
> resolve these matters in the next week or so if possible.
>=20
> The three topics that I see from the mailing list as being unresolved=20
> at this stage are:
>=20
>      * explicit shim6 error message (the lack thereof)
>=20
>            Its not clear what the WG want to do on this. Suggestions?

I think it would be useful to define a mechanism for this, even if we do
not yet have the implementation experience to decide on all the types of
errors that should/should not be reported.  Other control protocols such
as IKE (section 2.21 of RFC 4306) have defined such messages, although
whether a host generates them is a matter of security policy.  In HIP,
we cloned the IKE Notify parameter and defined a number of error cases
that could occur during context establishment.  Does this WG want to
adopt something similar?  Or just leave it for further study?

(see the current HIP base draft, sections 4.3 and 5.2.16 (NOTIFY
parameter))

>=20
>=20
>      * TCP Checksum Failure
>=20
>            Its not clear what the WG want to do on this. Suggestions?
>=20

I would vote to align the checksum with the locators, under the
assumption that defining an alternate probing mechanism to discover
these problems is more cumbersome.  If you care strongly enough about
using the transport checksum to detect incorrect address rewriting in
certain error scenarios, that may argue for putting better error
detection in the shim proper, but I'm not sure it is a high enough
probability event.

>      * Control Message length
>=20
>            Text proposed=20
> (http://ops.ietf.org/lists/shim6/msg01780.html)
>             Are we in agreement with this suggestion?

My first thought was "why not just use regular IPv6 fragmentation in the
control plane, perhaps with IPV6_USE_MIN_MTU socket option?" but then I
realized that the whole protocol is defined in terms of IPv6 destination
headers below the fragmentation layer. =20

from the current draft:
> The shim6 control messages use the same extension
> header formats so that a single "protocol number" needs to be allowed
> through firewalls in order for shim6 to function across the firewall.

Besides the fragmentation issue, the way it is defined now, it seems
burdensome to implementations that want to implement the shim6 control
plane as a user-space daemon (as opposed to defining a separate protocol
number for shim6 control messages).  My reading of IPv6 raw sockets
semantics suggests that they cannot be used.

from RFC 3542:
"With IPv6 raw sockets will be
   used for ICMPv6 and to read and write IPv6 datagrams containing a
   Next Header field that the kernel does not process."

This is not the case for shim6 since the kernel does process the payload
extension header in the data plane.

Under current definition, how should a user-space shim6 implementation
use IPv6 sockets API to get only the control messages?  If there isn't
an easy way, should we consider to separate the protocol numbers? =20

Tom

Delivery-date: Mon, 22 Jan 2007 23:22:57 +0000
Date: Tue, 23 Jan 2007 10:20:43 +1100
To: "shim6-wg" <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: Re: State of play with Shim6 documents
Cc: [email-masked]

It seems that asking these questions has stopped all further 
discussion on this topic, which is a pity, as it would be good to 
resolve these matters in the next week or so if possible.

The three topics that I see from the mailing list as being unresolved 
at this stage are:

     * explicit shim6 error message (the lack thereof)

           Its not clear what the WG want to do on this. Suggestions?

     * TCP Checksum Failure

           Its not clear what the WG want to do on this. Suggestions?

     * Control Message length

           Text proposed (http://ops.ietf.org/lists/shim6/msg01780.html)
            Are we in agreement with this suggestion?

thanks,

   Geoff & Kurtis

Delivery-date: Sun, 14 Jan 2007 23:05:36 +0000
Date: Mon, 15 Jan 2007 10:03:14 +1100
To: "shim6-wg" <[email-masked]>
From: Geoff Huston <[email-masked]>
Subject: State of play with Shim6 documents
Cc: [email-masked]

Working from the minutes of the SHIM6 WG meeting in November, and looking
at the mailing list traffic since then it appears that we are about as
close to submitting the HBA and Failure Detection shim6 documents to the
IESG as we'll ever be, but that the Protocol specification document
requires a little more discussion on a number of topics (noted below) and
definitely another rev of the draft.

Here's the state, as I understand it, relative to the comments raised in
the Last Call and in the IETF 67the Working Group meeting

  1. HBA (draft-ietf-shim6-hba-02.txt )

    -- IPR issues - we appear to have reached a level of consensus with
       acceptance of this document in the light of the Ericsson and
       Microsoft IPR statements

    -- IANA considerations - no further issues

    -- Security Considerations - no further issues

  2. Shim6 Protocol (draft-ietf-shim6-proto-07.txt)

    -- IPSEC - text added to the draft as noted in the WG meeting

    -- Provide SHIM 6 security based on IPSec SAs - no further action

    -- ULID Security Mechanism - no further issues

    -- DOS attacks on the context tag set - no consensus for further change

    -- Context Forking - no further issues

    -- CGA Key Length - text added to the draft as noted in the WG meeting

    -- Broken Flag - no further issues

  3. Failure Detection (draft-ietf-shim6-failure-detection-07.txt)

    -- Behaviour Section - text added per comments

Since then we've had a review of proto-7 by Iljitsch van Beijnum  (11
December http://ops.ietf.org/lists/shim6/msg01742.html), as well as a
number of other suggestions regarding thos document  The major issues
raised have been were:

  * context tag

    This review revisited the topic of inclusion of the context tag in the
    shim6 header.
    Followup postings to this were at (
    http://ops.ietf.org/lists/shim6/msg01772.html, and
    http://ops.ietf.org/lists/shim6/msg01777.html)

    As far as I can tell there is no apparent WG consensus to alter the
    existing text at this point in time,

  * congestion control

    It also noted issues regarding TCP congestion control.

    A TCPM approach (http://ops.ietf.org/lists/shim6/msg01788.html) is
    described in the document
    http://tools.ietf.org/wg/tcpm/draft-schuetz-tcpm-tcp-rlci-00.txt

    There appears to agreement to reference this draft in the proto
    document in order to address this issue.

  * explicit shim6 error message (the lack thereof)

    The review proposed a shim6 error message
    (http://ops.ietf.org/lists/shim6/msg01769.html)

    One posting in support of this
    (http://ops.ietf.org/lists/shim6/msg01775.html)

    **** Its not clear what the WG want to do on this. Suggestions? ****

  * TCP Checksum Failure

    The review noted that any intermediary system that performed a TCP
    checkum would fail.

    Proposal to add a middlebox consideration section to point out the
    problem and an idea to use some form of probe mechanism to detect paths
    with this problem

    Alternative proposal for the SHIM to alter the TCP and UDP checksums to
    match the selected locators on outgoing and match the ULIDs on
    incoming.

    **** Its not clear what the WG want to do on this. Suggestions? ****

  * Control Message length

    Text proposed (http://ops.ietf.org/lists/shim6/msg01780.html)

    Are we in agreement with this suggestion?

  * Sundry

    The review also listed a number of grammar errors, typos and
    suggestions relating to terminology

    These appear, on the whole, to have been accepted by the document
    editor (http://ops.ietf.org/lists/shim6/msg01774.html)

 *  Changes to the shim message exchange

    Proposed in http://ops.ietf.org/lists/shim6/msg01756.html

    This suggestion appears to have been accepted by the document editor

    Also http://ops.ietf.org/lists/shim6/msg01758.html

  * Receiving Receiving payload without extension headers

    This suggestion appears to have been accepted by the document editor

So we are almost ready with these documents, and as far as I can tell there
is a rough consensus for the HBA and failure detection document, but a
clear need to resolve the outstanding issues with the proto document and
incorporate the changes as noted above.

The three topics that I see from the mailing list as being unresolved at this stage
are:

    * explicit shim6 error message (the lack thereof)

          Its not clear what the WG want to do on this. Suggestions?

    * TCP Checksum Failure

          Its not clear what the WG want to do on this. Suggestions?

    * Control Message length

          Text proposed (http://ops.ietf.org/lists/shim6/msg01780.html)
           Are we in agreement with this suggestion?

thanks,

  Geoff & Kurtis

Delivery-date: Fri, 12 Jan 2007 17:16:23 +0000
Date: Fri, 12 Jan 2007 18:13:59 +0100
From: Xiaoming Fu <[email-masked]>
Organization: University of Goettingen, Germany
To:  [email-masked],  [email-masked]
Subject: CFP: MobiArch'07

[Apologies if you receive multiple copies of this CFP]
--------------------------------------------------------------------
               The Second International Workshop on
    Mobility in the Evolving Internet Architecture (MobiArch 2007)
                   Kyoto, Japan, August 27, 2007
        (to be held with ACM SIGCOMM 2007, August 27-31, 2007)
       http://user.informatik.uni-goettingen.de/~mobiarch/2007
--------------------------------------------------------------------

With the recent development of technologies in wireless access and
mobile devices, user, terminal, and network mobility has become an
indispensable component of today's Internet vision, and it is likely to
continue in the near future, while affecting the whole architectural
design of the future Internet. Yet, issues like efficient mobility
management and optimization, locator-identifier split, multihoming,
security, and related operational/deployment concerns are still in their
early stages of development. Moreover, the Internet architecture, its
end-to-end principles, and business models will require rethinking due
to the massive penetration of mobility into the Internet.

MobiArch'07 welcomes submissions, from both researchers and
practitioners, in exploration of recent advances in architectures,
protocols, and experiences with emerging technologies on wireless and
mobility over the Internet, with an emphasis on wireless infrastructures
and mobility patterns for mobility support, new mobility protocols,
service discovery, routing and location management, mobile network
performance evaluation and modeling, multi-homing, security,
architectural impacts and deployment considerations.

Topics of Interest:
==================
Topics of MobiArch�07 cover all aspects of architectural issues and
system support for wireless and mobility in the Internet, including but
not limited to:

- Impacts of new wireless technologies/services and mobility patterns on
the Internet architecture
- Architectures and protocols for mobility support in the Internet,
ranging from approaches in link, network, transport to
session/application layers and cross-layer design
- Location management, positioning and data management systems for
wireless and mobility
- Routing and addressing, including locator/identifier split issues and
their impacts to the Internet architecture
- IP multihoming including flow distribution and load sharing for
wireless and mobility
- Performance evaluation, experimentation and modeling of mobility in
the Internet
- Accounting, access control, security and privacy issues and impacts to
Internet architecture
- Economic, scalability and deployment issues of mobility infrastructure
design
- Mechanisms and issues with connecting developing regions into the Internet

Following the success of MobiArch'06, the MobiArch'07 workshop will be a
single-track one-day workshop. Early stages, position papers, systems
and measurement papers will be particularly welcome. The proceedings
will be published by the ACM and ACM digital library.

Submissions:
===========
Submissions must be made to MobiArch'07 EDAS entry:
http://edas.info/5238, following the guidelines in MobiArch'07 webpage:
http://user.informatik.uni-goettingen.de/~mobiarch/2007

Important Dates:
===============
Abstract registration:    March 20, 2007
Submission Deadline:      March 27, 2007
Acceptance Notification:  May 15, 2007
Camera-ready version due: June 12, 2007
MobiArch'07 Workshop:     August 27, 2007
SIGCOMM'07:               August 27-31, 2007

PROGRAM CO-CHAIRS
=================
Xiaoming Fu, University of Goettingen (Germany)
Katherine Guo, Bell Labs (USA)
Sue Moon, KAIST (Korea)
Ryuji Wakikawa, Keio University (Japan)

PUBLICITY CHAIR
===============
Jon Crowcroft, University of Cambridge (UK)

QUESTIONS
=========
Please consult the Program Co-Chairs
([email-masked]) if you are uncertain whether
your paper falls within the scope of the workshop.

Delivery-date: Tue, 09 Jan 2007 14:33:47 +0000
Date: Tue, 9 Jan 2007 09:29:34 -0500
From: Wesley Eddy <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Cc: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>, [email-masked], [email-masked]
Subject: Re: shim6-proto-07 review
Reply-To: [email-masked]

On Tue, Jan 09, 2007 at 11:43:15AM +0100, Brian E Carpenter wrote:
> How does SCTP handle this problem?
> 

Excerpted from RFC 2960:
   o  The sender keeps a separate congestion control parameter set for
      each of the destination addresses it can send to (not each
      source-destination pair but for each destination).  The parameters
      should decay if the address is not used for a long enough time
      period.

   o  For each of the destination addresses, an endpoint does slow-start
      upon the first transmission to that address.

This is pretty close to what's proposed in the TCP-RLCI draft designed
to work with shim6 because it initializes a new congestion control
parameter set (actually, it re-initializes the old set, but the effect
is the same) and slow-starts after a failover event.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Delivery-date: Tue, 09 Jan 2007 10:45:53 +0000
Date: Tue, 09 Jan 2007 11:43:15 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: [email-masked], shim6-wg <[email-masked]>
Subject: Re: shim6-proto-07 review

How does SCTP handle this problem?

     Brian

On 2007-01-08 19:22, Iljitsch van Beijnum wrote:
> On 8-jan-2007, at 17:11, Wesley Eddy wrote:
> 
>>> I think it's entirely reasonable for TCP or other transport protocols
>>> to have different behaviors for path changes where the speed
>>> difference is 1:2 vs where the speed difference is 1:1000.
> 
>> Well, even though the speed of the links may be known, the amount of
>> their capacity that is currently available at the time of a failover is
>> probably much less well known to the shims.  This knowledge also says
>> nothing about the paths after those links.
> 
> Sure, there is lots of stuff that we don't know. But when we have a 80 
> Mbps stream going through a 100 Mbps or faster interface, and then the 
> path changes so that the next hop is over a 56 kbps interface, we know 
> that bad stuff is about to happen unless we take action.
> 
>> One other point is that setting the congestion window to some percentage
>> of its previous value based on the ratio of failover link capacity to
>> primary link capacity is fairly naive, and ignores the significant
>> amount of other relevent TCP state.
> 
> In theory, the TCP window should be such that it throttles the data 
> stream to almost exactly the available bandwidth. In practice, this of 
> course doesn't work because the logic that determines the window size 
> isn't all that good.
> 
> I don't think there is a simple action that can be taken that's always 
> the right response. The only thing I do know is that this is an issue 
> that we can't ignore, we must say _something_ in the protocol document 
> and hopefully the implementers will be smart enough to come up with 
> something reasonable or at least do some testing to avoid problems from 
> becoming too big when all of this hits the streets.
> 
>> TCP can easily be
>> smart enough to do the right thing if shim6 just lets it know that
>> there's been a failover.
> 
> Sounds good, except that not all failovers are created equal so some 
> additional information, when available, would be even better. Especially 
> as the main issue is going in and changing specifications and 
> implementations, making the list of signals a bit longer is 
> inconsequential.
> 
> 
> 

Delivery-date: Mon, 08 Jan 2007 20:36:59 +0000
Content-class: urn:content-classes:message
Subject: RE: about the ULID in the TCP checksum
Date: Mon, 8 Jan 2007 12:34:47 -0800
From: "Henderson, Thomas R" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>

=20

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]]=20
> Sent: Monday, January 08, 2007 10:25 AM
> To: Henderson, Thomas R
> Cc: shim6-wg
> Subject: Re: about the ULID in the TCP checksum
>=20
> On 8-jan-2007, at 17:00, Henderson, Thomas R wrote:
>=20
> > What do you mean, "detect incorrect shimming using the=20
> checksum"?  Do
> > you mean context confusion?  I'm not sure it's any worse off.
>=20
> For instance, when some bit error occurs (or, more realistically, a =20
> few) so context a001 becomes context b001. The addresses are =20
> rewritten as per the wrong context, the checksum doesn't find any =20
> fault and hopefully there will be a demuxing problem or a session =20
> ends up with incorrect data.
>=20

I see.  It seems that, for data insertion to occur, it would still
require a shim6 checksum syndrome to another active context, matching
also the ports and, for TCP, falling within the active window.  But you
would lose the additional checksum protection, I agree.

Tom

Delivery-date: Mon, 08 Jan 2007 18:25:40 +0000
Cc: "shim6-wg" <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: about the ULID in the TCP checksum
Date: Mon, 8 Jan 2007 19:25:12 +0100
To: "Henderson, Thomas R" <[email-masked]>

On 8-jan-2007, at 17:00, Henderson, Thomas R wrote:

> What do you mean, "detect incorrect shimming using the checksum"?  Do
> you mean context confusion?  I'm not sure it's any worse off.

For instance, when some bit error occurs (or, more realistically, a  
few) so context a001 becomes context b001. The addresses are  
rewritten as per the wrong context, the checksum doesn't find any  
fault and hopefully there will be a demuxing problem or a session  
ends up with incorrect data.

Delivery-date: Mon, 08 Jan 2007 18:24:28 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim6-proto-07 review
Date: Mon, 8 Jan 2007 19:22:55 +0100
To: [email-masked]

On 8-jan-2007, at 17:11, Wesley Eddy wrote:

>> I think it's entirely reasonable for TCP or other transport protocols
>> to have different behaviors for path changes where the speed
>> difference is 1:2 vs where the speed difference is 1:1000.

> Well, even though the speed of the links may be known, the amount of
> their capacity that is currently available at the time of a  
> failover is
> probably much less well known to the shims.  This knowledge also says
> nothing about the paths after those links.

Sure, there is lots of stuff that we don't know. But when we have a  
80 Mbps stream going through a 100 Mbps or faster interface, and then  
the path changes so that the next hop is over a 56 kbps interface, we  
know that bad stuff is about to happen unless we take action.

> One other point is that setting the congestion window to some  
> percentage
> of its previous value based on the ratio of failover link capacity to
> primary link capacity is fairly naive, and ignores the significant
> amount of other relevent TCP state.

In theory, the TCP window should be such that it throttles the data  
stream to almost exactly the available bandwidth. In practice, this  
of course doesn't work because the logic that determines the window  
size isn't all that good.

I don't think there is a simple action that can be taken that's  
always the right response. The only thing I do know is that this is  
an issue that we can't ignore, we must say _something_ in the  
protocol document and hopefully the implementers will be smart enough  
to come up with something reasonable or at least do some testing to  
avoid problems from becoming too big when all of this hits the streets.

> TCP can easily be
> smart enough to do the right thing if shim6 just lets it know that
> there's been a failover.

Sounds good, except that not all failovers are created equal so some  
additional information, when available, would be even better.  
Especially as the main issue is going in and changing specifications  
and implementations, making the list of signals a bit longer is  
inconsequential.

Delivery-date: Mon, 08 Jan 2007 16:15:01 +0000
Date: Mon, 8 Jan 2007 11:11:12 -0500
From: Wesley Eddy <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: Brian Carpenter <[email-masked]>, shim6-wg <[email-masked]>, [email-masked], [email-masked]
Subject: Re: shim6-proto-07 review
Reply-To: [email-masked]

On Mon, Jan 08, 2007 at 04:34:10PM +0100, Iljitsch van Beijnum wrote:
> 
> >We have actually discussed and worked on a solution to this in TCPM  
> >that
> >is intended to work with shim6, among other protocols (including at
> >least mip4, mip6, and hip):
> >http://tools.ietf.org/wg/tcpm/draft-schuetz-tcpm-tcp-rlci-00.txt
> 
> Good, let's put in a reference.
> 
> >I think this type of general solution is far preferable  
> >architecturally
> >than asking shim6 to differentiate between path/interface  
> >properties and
> >transport protocols and take special actions.
> 
> If the information is available, it doesn't make sense to ignore it.  
> I think it's entirely reasonable for TCP or other transport protocols  
> to have different behaviors for path changes where the speed  
> difference is 1:2 vs where the speed difference is 1:1000.

Well, even though the speed of the links may be known, the amount of
their capacity that is currently available at the time of a failover is
probably much less well known to the shims.  This knowledge also says
nothing about the paths after those links.  For these reasons, TCP has
to slow-start from an initial window anyways, so I do not see how
specific knowledge about the links can be easily used.

One other point is that setting the congestion window to some percentage
of its previous value based on the ratio of failover link capacity to
primary link capacity is fairly naive, and ignores the significant
amount of other relevent TCP state.  This is why I posted the link to
the TCP-RLCI internet-draft that also updates the ssthresh, the rtt
estimation, and the PMTUD state.  TCP is too complex for the shim6
protocol to tell it _specifically_ what to do, but TCP can easily be
smart enough to do the right thing if shim6 just lets it know that
there's been a failover.  The same goes for SCTP and DCCP.  This is why
I'd advise that asking the shim to publish a generic failover
advertisement within the local stack is the extent of what is specified.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Delivery-date: Mon, 08 Jan 2007 16:02:05 +0000
Content-class: urn:content-classes:message
Subject: RE: about the ULID in the TCP checksum
Date: Mon, 8 Jan 2007 08:00:40 -0800
From: "Henderson, Thomas R" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>

=20

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]]=20
> Sent: Monday, January 08, 2007 7:37 AM
> To: Henderson, Thomas R
> Cc: shim6-wg
> Subject: Re: about the ULID in the TCP checksum
>=20
> On 4-jan-2007, at 23:39, Henderson, Thomas R wrote:
>=20
> >> If this is a problem, it's probably better to adjust the checksum
> >> such that it appears to be correct to a non-shim6 aware observer.
> >> This does have the downside that incorrect address rewriting isn't
> >> detected by the checksum, though.
>=20
> > Why not both twiddle the checksum at the shim so that it is=20
> aligned =20
> > with
> > locators, and de-twiddle when deshimming?
>=20
> I think I like this approach better than what's currently in=20
> the draft.
>=20
> However, it does have a downside: since the checksum is=20
> adjusted when =20
> doing the shim processing, it's not possible to detect incorrect =20
> shimming using the checksum.
>=20

What do you mean, "detect incorrect shimming using the checksum"?  Do
you mean context confusion?  I'm not sure it's any worse off.

Tom

Delivery-date: Mon, 08 Jan 2007 15:37:24 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: about the ULID in the TCP checksum
Date: Mon, 8 Jan 2007 16:36:58 +0100
To: "Henderson, Thomas R" <[email-masked]>

On 4-jan-2007, at 23:39, Henderson, Thomas R wrote:

>> If this is a problem, it's probably better to adjust the checksum
>> such that it appears to be correct to a non-shim6 aware observer.
>> This does have the downside that incorrect address rewriting isn't
>> detected by the checksum, though.

> Why not both twiddle the checksum at the shim so that it is aligned  
> with
> locators, and de-twiddle when deshimming?

I think I like this approach better than what's currently in the draft.

However, it does have a downside: since the checksum is adjusted when  
doing the shim processing, it's not possible to detect incorrect  
shimming using the checksum.

Delivery-date: Mon, 08 Jan 2007 15:36:46 +0000
Cc: Brian Carpenter <[email-masked]>, shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim6-proto-07 review
Date: Mon, 8 Jan 2007 16:34:10 +0100
To: [email-masked]

On 3-jan-2007, at 17:20, Wesley Eddy wrote:

> I'm all in favor of helping TCP to "do the right thing", but I think
> this proposal (and specifically that suggested text) misses the mark.

If someone cares to suggest something different...

> If this direction were to be pursued, I'd recommend not making any
> distinction between fast and slow interfaces, but rather specifying
> one behavior that is followed in all cases.

Let me explain why I make a big deal about the speed difference  
between the primary and the backup interface. When designing a  
multihomed network, the speed differences between the different  
possible configurations after different kinds of outages is an  
important concern. What I've seen in practice is that a backup that  
is 10% or less of the bandwidth of the original bandwidth used before  
the failure, is completely useless because congestion is immediate,  
persistent and fatal. I always recommend a minimum of 25% backup  
capacity. So far so good for multihomed _sites_ where these decisions  
are made explicitly. But shim6 can also easily work on a single host  
where the speed difference between the fastest interface (100 - 1000  
Mbps) and the slowest (9.6 - 56 kbps) is easily four orders of  
magnitude. Ignoring this will create problems.

> We have actually discussed and worked on a solution to this in TCPM  
> that
> is intended to work with shim6, among other protocols (including at
> least mip4, mip6, and hip):
> http://tools.ietf.org/wg/tcpm/draft-schuetz-tcpm-tcp-rlci-00.txt

Good, let's put in a reference.

> I think this type of general solution is far preferable  
> architecturally
> than asking shim6 to differentiate between path/interface  
> properties and
> transport protocols and take special actions.

If the information is available, it doesn't make sense to ignore it.  
I think it's entirely reasonable for TCP or other transport protocols  
to have different behaviors for path changes where the speed  
difference is 1:2 vs where the speed difference is 1:1000.

Delivery-date: Thu, 04 Jan 2007 22:42:37 +0000
Content-class: urn:content-classes:message
Subject: RE: about the ULID in the TCP checksum
Date: Thu, 4 Jan 2007 14:39:46 -0800
From: "Henderson, Thomas R" <[email-masked]>
To: "Iljitsch van Beijnum" <[email-masked]>, "Brian E Carpenter" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>

=20

> -----Original Message-----
> From: Iljitsch van Beijnum [mailto:[email-masked]]=20
> Sent: Wednesday, January 03, 2007 7:59 AM
> To: Brian E Carpenter
> Cc: shim6-wg
> Subject: Re: about the ULID in the TCP checksum
>=20
<snip>
> If this is a problem, it's probably better to adjust the checksum =20
> such that it appears to be correct to a non-shim6 aware observer. =20
> This does have the downside that incorrect address rewriting isn't =20
> detected by the checksum, though.
>=20

Why not both twiddle the checksum at the shim so that it is aligned with
locators, and de-twiddle when deshimming?

The implementation is fairly straightforward, to subtract off the ULID
components of the checksum and add back the locator components (and vice
versa).  We've done this for our HIP implementation when substituting
HITs for IP addresses, in certain configurations.

Tom

=20

Delivery-date: Thu, 04 Jan 2007 08:36:19 +0000
Date: Thu, 04 Jan 2007 09:35:59 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: about the ULID in the TCP checksum

On 2007-01-03 16:59, Iljitsch van Beijnum wrote:
> On 3-jan-2007, at 16:36, Brian E Carpenter wrote:
> 
>>> "Firewalls and other middleboxes SHALL NOT drop TCP, UDP and ICMP 
>>> packets with apparently incorrect checksums based on that fact alone 
>>> unless they implement (monitoring of) the full shim6 protocol and are 
>>> able to determine the checksum that must be present in a packet with 
>>> addresses rewritten by shim6."
> 
>> I'm sorry, putting such an imperative in a shim6 RFC is an exercise
>> in futility. You can certainly wish it to be true, but writing it
>> in this way is pointless.
> 
> I disagree. Although I recognize that middlebox makers will continue to 
> break protocols as they see fit, at least this provides guidance to 
> those middlebox makers who are on the fence.

Writing as guidance is fine. Writing it as a SHALL NOT is meaningless.
Logically, you can only address RFC 2119 language to the shim6 implementer.
> 
>> And I repeat my suggestion of a probe mechanism to detect paths
>> with this problem.
> 
> Detecting paths where packets with apparent incorrect checksums are 
> discarded? That doesn't make much philosophical OR technical sense to me.

Nevertheless, it would be an essential diagnostic tool (a TCP ping,
in effect).
> 
> If this is a problem, it's probably better to adjust the checksum such 
> that it appears to be correct to a non-shim6 aware observer. This does 
> have the downside that incorrect address rewriting isn't detected by the 
> checksum, though.

Yep. This is a tricky point either way you solve it.

    Brian

Delivery-date: Thu, 04 Jan 2007 08:33:25 +0000
Date: Thu, 04 Jan 2007 09:31:28 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: shim6-proto-07 review

On 2007-01-03 16:55, Iljitsch van Beijnum wrote:
> On 3-jan-2007, at 16:33, Brian E Carpenter wrote:
> 
>> Explain why TCP will react any differently to a sudden path
>> change due to shim6, compared to a sudden path change for
>> any other reason. I don't understand what is specific
>> to shim6.
> 
> The difference is that with shim6, we get to avoid massive congestion 
> when failing over from a very fast to a very slow path.

I'm sorry, why is that different from regular routing failing over from
a very fast to a very slow path? There's something I am completely
missing here.

     Brian

> 
> If there is no consensus for a general recommendation for slow start 
> when failing over, maybe we can make this specific to the situation 
> where a host fails over from a fast to a slow interface:
> 
> "When the shim protocol triggers the selection of a new path, and this 
> path utilizes a lower-bandwidth interface than the interface of the 
> prior path, it is recommended that the TCP window for any affected TCP 
> sessions are reduced relative to the reduction in interface bandwidth. 
> Alternatively, TCP slow start can be initiated. For non-TCP protocols, 
> similar measures are recommended where available."
> 

Delivery-date: Wed, 03 Jan 2007 16:23:40 +0000
Date: Wed, 3 Jan 2007 11:20:01 -0500
From: Wesley Eddy <[email-masked]>
To: Iljitsch van Beijnum <[email-masked]>
Cc: Brian E Carpenter <[email-masked]>, shim6-wg <[email-masked]>, [email-masked], [email-masked]
Subject: Re: shim6-proto-07 review
Reply-To: [email-masked]

On Wed, Jan 03, 2007 at 04:55:24PM +0100, Iljitsch van Beijnum wrote:
> On 3-jan-2007, at 16:33, Brian E Carpenter wrote:
> 
> >Explain why TCP will react any differently to a sudden path
> >change due to shim6, compared to a sudden path change for
> >any other reason. I don't understand what is specific
> >to shim6.
> 
> The difference is that with shim6, we get to avoid massive congestion  
> when failing over from a very fast to a very slow path.
> 
> If there is no consensus for a general recommendation for slow start  
> when failing over, maybe we can make this specific to the situation  
> where a host fails over from a fast to a slow interface:
> 
> "When the shim protocol triggers the selection of a new path, and  
> this path utilizes a lower-bandwidth interface than the interface of  
> the prior path, it is recommended that the TCP window for any  
> affected TCP sessions are reduced relative to the reduction in  
> interface bandwidth. Alternatively, TCP slow start can be initiated.  
> For non-TCP protocols, similar measures are recommended where  
> available."

I'm all in favor of helping TCP to "do the right thing", but I think
this proposal (and specifically that suggested text) misses the mark.

If this direction were to be pursued, I'd recommend not making any
distinction between fast and slow interfaces, but rather specifying
one behavior that is followed in all cases.

We have actually discussed and worked on a solution to this in TCPM that
is intended to work with shim6, among other protocols (including at
least mip4, mip6, and hip):
http://tools.ietf.org/wg/tcpm/draft-schuetz-tcpm-tcp-rlci-00.txt
I think this type of general solution is far preferable architecturally
than asking shim6 to differentiate between path/interface properties and
transport protocols and take special actions.

In my opinion, all that we need to ask of shim6 is that implementations
provide some way for higher layers to recognize when a failover has
occurred -- that failovers not be totally transparent.  The details of
how higher layers (including TCP) respond is up to them.

-- 
Wesley M. Eddy
Verizon Federal Network Systems

Delivery-date: Wed, 03 Jan 2007 15:59:49 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: about the ULID in the TCP checksum
Date: Wed, 3 Jan 2007 16:59:06 +0100
To: Brian E Carpenter <[email-masked]>

On 3-jan-2007, at 16:36, Brian E Carpenter wrote:

>> "Firewalls and other middleboxes SHALL NOT drop TCP, UDP and ICMP  
>> packets with apparently incorrect checksums based on that fact  
>> alone unless they implement (monitoring of) the full shim6  
>> protocol and are able to determine the checksum that must be  
>> present in a packet with addresses rewritten by shim6."

> I'm sorry, putting such an imperative in a shim6 RFC is an exercise
> in futility. You can certainly wish it to be true, but writing it
> in this way is pointless.

I disagree. Although I recognize that middlebox makers will continue  
to break protocols as they see fit, at least this provides guidance  
to those middlebox makers who are on the fence.

> And I repeat my suggestion of a probe mechanism to detect paths
> with this problem.

Detecting paths where packets with apparent incorrect checksums are  
discarded? That doesn't make much philosophical OR technical sense to  
me.

If this is a problem, it's probably better to adjust the checksum  
such that it appears to be correct to a non-shim6 aware observer.  
This does have the downside that incorrect address rewriting isn't  
detected by the checksum, though.

Delivery-date: Wed, 03 Jan 2007 15:56:03 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim6-proto-07 review
Date: Wed, 3 Jan 2007 16:55:24 +0100
To: Brian E Carpenter <[email-masked]>

On 3-jan-2007, at 16:33, Brian E Carpenter wrote:

> Explain why TCP will react any differently to a sudden path
> change due to shim6, compared to a sudden path change for
> any other reason. I don't understand what is specific
> to shim6.

The difference is that with shim6, we get to avoid massive congestion  
when failing over from a very fast to a very slow path.

If there is no consensus for a general recommendation for slow start  
when failing over, maybe we can make this specific to the situation  
where a host fails over from a fast to a slow interface:

"When the shim protocol triggers the selection of a new path, and  
this path utilizes a lower-bandwidth interface than the interface of  
the prior path, it is recommended that the TCP window for any  
affected TCP sessions are reduced relative to the reduction in  
interface bandwidth. Alternatively, TCP slow start can be initiated.  
For non-TCP protocols, similar measures are recommended where  
available."

Delivery-date: Wed, 03 Jan 2007 15:43:31 +0000
Date: Wed, 03 Jan 2007 16:38:08 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: always including the context tag

On 2007-01-02 14:56, Iljitsch van Beijnum wrote:
> On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote:
> 
>>> 1. Always including the context tag
> 
>>> As I've said many times, it's a very bad idea to unnecessarily 
>>> increase overhead.
> 
>> well, i think having an additional header is the clean way to do this, 
>> because there is an additional layer that is being inserted and the 
>> layer needs to perform its signalling and this is achieved using a 
>> extra header.
> 
> Clean != best

clean == best, all other things being equal.
> 
> We also have ample precedent for non-clean solutions.  :-)

Yes, NAT for example...

    Brian

Delivery-date: Wed, 03 Jan 2007 15:37:19 +0000
Date: Wed, 03 Jan 2007 16:36:40 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: about the ULID in the TCP checksum

On 2007-01-02 15:27, Iljitsch van Beijnum wrote:
> On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote:
...
>> do you think we should add text about this? (if you do, please send text)
> 
> "Firewalls and other middleboxes SHALL NOT drop TCP, UDP and ICMP 
> packets with apparently incorrect checksums based on that fact alone 
> unless they implement (monitoring of) the full shim6 protocol and are 
> able to determine the checksum that must be present in a packet with 
> addresses rewritten by shim6."

I'm sorry, putting such an imperative in a shim6 RFC is an exercise
in futility. You can certainly wish it to be true, but writing it
in this way is pointless.

All you can do is insert a "middlebox considerations" section
pointing out the failure cases and how they can be avoided. As I
think I said the other day, this has to include TCP relays.

And I repeat my suggestion of a probe mechanism to detect paths
with this problem.

     Brian

Delivery-date: Wed, 03 Jan 2007 15:35:51 +0000
Date: Wed, 03 Jan 2007 16:33:03 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: Iljitsch van Beijnum <[email-masked]>
CC: marcelo bagnulo braun <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: shim6-proto-07 review

Explain why TCP will react any differently to a sudden path
change due to shim6, compared to a sudden path change for
any other reason. I don't understand what is specific
to shim6.

    Brian

On 2007-01-03 12:38, Iljitsch van Beijnum wrote:
> On 28-dec-2006, at 18:58, marcelo bagnulo braun wrote:
> 
>>> There are no easy answers here, but congestion control is one of the 
>>> core concerns in the development of the internet, so I don't think we 
>>> can get away with ignoring this completely.
> 
>> i can see this is an issue...
> 
>> what do you suggest to do here? could you send text?
> 
> Thinking a bit more about this, I keep coming back to TCP slow start...
> 
>>>    o  Preserve established communications in the presence of certain
>>>       classes of failures, for example, TCP connections and UDP streams.
> 
>>> Shouldn't this be "communication"?
> 
>> i don't think so...
> 
>> it could be Preserve an established communication or Preserve 
>> established communications
> 
>> i think it is better the second one, because the first option seems we 
>> are talking about a given specific communication...
> 
> Hm, isn't the word "communication" like "water"? I.e., you don't have 
> several of it, it's just one thing of which you have more or less.
> 
>>> "The shim protocol is a site multihoming solution in the sense that 
>>> it allows existing communication to continue when a site that has 
>>> multiple connections to the internet experiences an outage on a 
>>> subset of these connections or further upstream. However, shim 
>>> processing is performed in individual hosts rather than through 
>>> site-wide mechanisms."
> 
>> ok will add this... did you have a place in the draft you were 
>> thinking for this text?
> 
> Maybe "placement of the shim", "terminology" or even "introduction"?
> 
>>>    the original locators become invalid at the same time and depending
>>>    on the time that is required to update the DNS and for those updates
>>>    to propagate.
> 
>>> Why is the DNS relevant here?
> 
>> because at least one valid locator must be published in the DNS in 
>> order for a shim host to be reachable, since the DNS is used as a 
>> rendez vous mechanism. OTOH, this is no specific of the shim6 
>> protocol, but generic for any host... do you prefer we remove the DNS 
>> consideration from here?
> 
> I don't understand what you mean here... The way I see it, the stuff 
> that's in the DNS doesn't change when there are outages, only when links 
> are added to or removed from the site. As such, the DNS timing is 
> irrelevant except in the corner case where all existing links are 
> replaced by all new ones or all the links that don't change go down.
> 
>>> This makes me uncomfortable. How do you know that an address has 
>>> become terminally invalid, rather than accidentally unusable?
> 
>> this was discussed during the last meeting in san diego and there was 
>> consensus that if a prefix is removed from the site, existing shim 
>> contexts that are using a ulid containing the prefix must be 
>> terminated when the prefix is removed.
>> however, i read from your comment is that you don't have a problem 
>> with this idea but your problem is with how to implement this, right?
> 
> Indeed. The autoconfig protocols don't have a mechanism to see the 
> difference between a router going down accidentally and administrative 
> removal of prefixes, unless you want to add significant amounts of 
> guesswork to the mix. And that's something I don't think is a good idea, 
> especially considering that in SITE multihoming the chances of clashing 
> ULIDs after renumbering are near-zero.
> 
>> what about when the address becomes invalid?
> 
> In many Unix stacks you can keep using an address even if it's removed 
> from all interfaces. This is a good thing, because it allows sessions to 
> survive short transitions such as moving out of radio range for a few 
> moments. With shim6 there is the potential that the address is gone for 
> a long time but it remains in use because the failure is repaired using 
> the shim.
> 
> I think the best thing to do here is keep using the address for a 
> limited amount of time, like 1 - 24 hours.
> 
>> in other words, i fail to see why this is easier to implement that 
>> what is currently in the draft. I mean, if the admin can determine the 
>> decomisioning time, it also can terminate the existing shim6 contexts...
> 
> Of course not. A site administrator can't reach out into the state 
> inside all the hosts in the site...
> 
>>> I don't see how regular nomadic behavior will result in two hosts 
>>> using the same address in quick succession, and they can further 
>>> reduce the potential for problems by not using temporary addresses as 
>>> ULIDs.
> 
>> i am not sure what part of the draft this comment is referred to, but 
>> if a nomadic host creates a ulid using a temporary prefix and it moves 
>> away and then another nomadic hosts attaches itself to the same 
>> network and generates the same address, it is possible that the the 
>> two nomadic hosts end up using the same address.
> 
> Right. So don't use this type of addresses as ULIDs and then there are 
> no problems.
> 
>>>       If the context establishment exchange fails, the initiator will
>>>       then know that the other end does not support shim6, and will
>>>       continue with standard unicast behavior for the session.
> 
>>> Unicast? Shouldn't this be "single homed"?
> 
>> will change to standard (non-shim6) behaviour, ok?
> 
> Ok.
> 
>>> More in general, the draft seems to suggest that the content of the 
>>> source address field in received packets may be ignored,
> 
>> this is explicitly stated in the draft
> 
> Hm, this makes me uncomfortable... As a receiver, I would much rather 
> know in advance which source addresses I'm going to see for established 
> sessions/context.
> 
> Also, the source address can't be changed arbitrarily because then ICMP 
> messages don't make it back to the source.
> 
>> the security level provided by the shim6 protocol relies on the 
>> context tag. Any attacker needs to learn the context tag before being 
>> able to inject addresses into an established context. It was concluded 
>> that this is an acceptable security level and similar to the one 
>> available in today's internet... do you agree?
> 
> I don't know. In general, I'm not all that paranoid about security so 
> I'm not really the person to ask if security is good enough.  :-)
> 
>>>    Bidirectional Communication (FBD).  FBD uses a Keepalive message
>>>    which is sent when a host has received packets from its peer but has
>>>    not yet sent any packets from its ULP to the peer.
> 
>>> No, this works per address (per locator even, not per ULID, IIRC), 
>>> not per ULP.
> 
>> the meaning here is that FBD generates packets when the ULPs are 
>> silent. It doesn't mean that it generates packets per ULP, just that 
>> when all ULPs are silent, FBD generates packets. It may be rephrased 
>> as follows:
> 
>>    FBD uses a Keepalive message
>>    which is sent when a host has received packets from its peer but has
>>    not yet sent any packets from any of its ULPs to the peer.
> 
>> would this be better?
> 
> No, because I don't see what the ULP has to do with anything. FBD is 
> between address pairs.
> 
>>>    which precedes a routing header).  When tunneling is used, whether
>>>    IP-in-IP tunneling or the special form of tunneling that Mobile IPv6
>>>    uses (with Home Address Options and Routing header type 2), there is
>>>    a choice whether the shim applies inside the tunnel or outside the
>>>    tunnel, which affects the location of the shim6 header.
> 
>>> How is this coordinated with the other side? If one side does 
>>> tunneling first and shim second and the other side the other way 
>>> around, there will be trouble. I don't see an easy way to avoid this.
> 
>> the header order would be enough imho. I mean, when tunneling is 
>> performed, two IP layers are involved and each ip layer can have its 
>> own shim sublayer inside. So, for each ip layer a shim header can be 
>> added, so depending on the location of the shim header, how it 
>> applies, makes sense?
> 
> Ok I don't see how it fails so I'll take your word for it...
> 
>>> So what happens when some other header follows the shim header? Could 
>>> this be used for attacks?
> 
>> this is for shim6 control messages and so far we haven't defined means 
>> to perform piggybacking of other protocols in shim6 control messages, 
>> so it is not possible for other protocols to follow the shim header. 
>> If this is defined in future extensions, they will need to update this 
>> part of the spec
> 
> Well, wouldn't it be better then to forbid having additional headers 
> after the shim header?
> 
>>> About the different messages: they are very similar. If I were to 
>>> implement all of this, I would rather work with one basic structure 
>>> for all of the messages, even if the _meaning_ of some fields is 
>>> different as long as their structure is always the same. I think this 
>>> can easily be done here, by including fields that nearly all messages 
>>> need (simply leave it zero when a particular message doesn't need a 
>>> field) and use options for things that a particular message needs 
>>> that aren't accommodated in the unified structure.
> 
>> i can clearly see the cost of this approach, additional overhead for 
>> unused fields and potential source of confusion when fields change 
>> their name... what is the advantage of such approach?
> 
> When you write an implementation, you need to extract all the values 
> from a header. Since these are all different sizes without natural 
> alignment this involves some complexity. When there are different 
> message headers, you need to do this multiple times. If there is only 
> one message header, you only have to implement the value extraction code 
> once.
> 
> The field names aren't an issue at all. In code it works something like 
> this:
> 
> void getheaders(int *field1, char *field2, unsigned int *field3);
> 
> void lookatmessage1()
> {
>   int contexttag;
>   char evilbit;
>   unsigned int remotecookie;
> 
>   getheaders(&contexttag, &evilbit, &remotecookie);
>   if (evilbit)
>     printf("You are breaking Evil Corp.'s patent, prepare to be sued!\n");
> }
> 
> void lookatmessage2()
> {
>   int contexttag;
>   char ossbit;
>   unsigned int localcookie;
> 
>   getheaders(&contexttag, &ossbit, &localcookie);
>   if (!ossbit)
>     printf("You are breaking the GPL, prepare to be sued!\n");
> }
> 
> Since the formats are so similar already there are only 1 or 2 cases 
> where an unused field would be included so I don't think the overhead is 
> a concern.
> 
>>> update request: why is this a request?
> 
>> because this is a two way protocol, update and request... (i do agree 
>> that it is not the best name in this case... suggestion?)
> 
> Just "update"?
> 
>>> Hm, is it smart to defer verification here?
> 
>> depending what verification we are talking about....
> 
>> this is explained in detail in section 7.2.  Locator Verification
> 
>> there are two type of verification HBA/CGA verification is one type 
>> and the other type is the one against flooding attakcs that is achived 
>> using a probe packets (of the path exploration protocol)
> 
>> The spec in section 7.2 states that:
> 
>>    Thus the HBA/CGA
>>    verification SHOULD be performed by the host before the host
>>    acknowledges the new locator, by sending an Update Acknowledgement
>>    message, or an R2 message.
> 
>>    Before a host can use a locator (different than the ULID) as the
>>    destination locator it MUST perform the HBA/CGA verification if this
>>    was not performed before upon the reception of the locator set.  In
>>    addition, it MUST verify that the ULID is indeed present at that
>>    locator.  This verification is performed by doing a return-
>>    routability test as part of the Probe sub-protocol [9].
> 
>> makes sense?
> 
> Is it useful to be able to defer locator verification? Simply doing it 
> immediately and either acknowledging that everything is ok or sending 
> back an error is much more robust than saying nothing and failing later.
> 
>> When the traffic generated by the ULPs results in a bidirectional flow 
>> of packet between the peers, no extra packets need to be inserted.
> 
>> is this ok?
> 
> No, it's still confusing. Why not leave this up to the reachability draft?
> 
>>> Ugh, this is certainly enough to make a grown man cry... Why all of 
>>> this alignment silliness? BGP works pretty well without it.
> 
>> i think this is general in IPv6 protocols which are optimized for 
>> handling 64 bits units.... but maybe someone with more expertise can 
>> answer this one...
> 
> Believe me, implementations aren't going to be any simpler because of 
> all the padding and length calculations, and the amounts of data 
> involved are so small that having faster copying because of the 
> alignment isn't an issue.
> 
> [...]
> 
>>> More in general, most error conditions are handled by silently 
>>> dropping packets, however, which is a very bad idea because that way, 
>>> there is no difference between an error and lost messages.
> 
> [...]
> 
>> sent this issue in a separate email
> 
> IIRC this mail doesn't go into the issue of silently dropping messages, 
> so I'll restate my objection to that here.
> 
>>> About the locator option: how many locators are allowed?
> 
>> there is no upper limit other than the ones that fit inside a packet 
>> with the other required options... As i mentioned above, roughly this 
>> seemed enough not to become a limitation
> 
> Some limit might be helpful, though.
> 
>>> So this has nothing to do with RFC 3041 temporary addresses?
> 
>> right
> 
>>> In that case, a different name is probably better.
> 
>> agree... what about "transient"?
> 
> Sure.
> 
>>>    | E-FAILED            | Context establishment exchange failed
> 
>>> How do we know this,
> 
>> becuase we have retried several times with I1 and never got a R1 back
> 
>>>  and is it necessary to explicitly take notice of this situation?
> 
>> yes, so we don't try again for a while
> 
>> makes sense?
> 
> I prefer to have as few states as possible, but if you think having a 
> separate state here is helpful, I guess it isn't really harmful.
> 
>>> Regarding section 7.9: shouldn't there be checks to make sure that 
>>> seemingly duplicate packets contain the same information as the 
>>> earlier packets they are supposedly the duplicate of?
> 
>> I am not following you here...
> 
>> are we talking about an initiator that receives a duplicate R1 back or 
>> a receiver that receives a duplicate I1?
> 
>> If a receiver receives a duplicate I1 it doesn't do anything special, 
>> just replies with a R1. don't see any problem here
> 
> So the issue whether it's a duplicate is irrelevant because the reply is 
> the same either way?
> 
>> If an initiator receives a duplicated R1 (this may be due that the 
>> initiator have retried with multiple I1), it will process the first 
>> one received, and send a I2. The second one received, there will be no 
>> shim6 context in I1-SENT state, so it will be discarded. I do not see 
>> the point in verifying that the other information in the packet is ok 
>> or not... what would be the point in doing this verification?
> 
> If you have special case handling for duplicates it's important to be 
> sure that you're actually dealing with duplicates. For instance, an 
> attack could be sending out fake shim6 packets so that when the real 
> ones come in later, those are rejected because they are presumed 
> duplicates.
> 
>>> What if validators don't match? Eventually this shouldn't be a 
>>> problem but I expect some initial trouble here because you're doing 
>>> hashes over a fairly large number of values, a small mistake 
>>> somewhere means the hash doesn't work, some feedback in the form of 
>>> an error message would be good.
> 
>> you mean for the first packet or for the following (duplicated)  
>> packets? for the first packet, this is a specific case of the general 
>> problem about whether it is ok to silently discard wrong packets (that 
>> i have initiated a new thread for this)
>> For the second case, i don't see any point on doing this...
> 
> Initial = when implementations first appear.
> 
> It's important that people know what's going on in order to debug 
> problems, not only when doing interoperability testing, but also "in the 
> wild" later on.
> 
>>> It occurs to me that there is nothing or very little in the protocol 
>>> that precludes shim negotiation using non-ULID addresses.
> 
>> not sure what you mean by non ulid addresses....
> 
> In the case of unreachable ULIDs where the shim packets use locator 
> source/destination addresses.
> 
>> if you mean that the shim protocol can support unreachable ULIDs like 
>> ULAs, then the answer is yes, it has been taken into account and 
>> should work fine with unreachable ulids...(you cannot do deferred 
>> setup but the spec supports it)
> 
> Good.
> 
>>> Adn why verify whether the source address is in Ls(peer)? The 
>>> security mechanisms do all the checking we need.
> 
>> could you point me where is the text you are referring to? i mean 
>> there is no such verification in section 7.15 which was the section 
>> the previous comment was referring to...
> 
> Page 59:
> 
>    If such a context exists in ESTABLISHED state, the host verifies that
>    the locator of the Initiator is included in Ls(peer) (This check is
>    unnecessary if there is no ULID-pair option in the I1 message).
> 
> Page 63:
> 
>    o  If the state is I1-SENT, then the host verifies if the source
>       locator is included in Ls(peer) or, it is included in the Locator
>       List contained in the the I2 message and the HBA/CGA verification
>       for this specific locator is successful
> 
> Page 69:
> 
>    o  If the state is I1-SENT, then the host verifies if the source
>       locator is included in Ls(peer) or, it is included in the Locator
>       List contained in the the I2 message and the HBA/CGA verification
>       for this specific locator is successful
> 
> 
>    o  If the state is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the host
>       verifies if the source locator is included in Ls(peer) or, it is
>       included in the Locator List contained in the the I2 message and
>       the HBA/CGA verification for this specific locator is successful
> 
> Page 74:
> 
>    Since context tags can be reused, the host MUST verify that the IPv6
>    source address field is part of Ls(peer) and that the IPv6
> 
> Page 76:
> 
>    Since context tags can be reused, the host MUST verify that the IPv6
>    source address field is part of Ls(peer) and that the IPv6
>    destination address field is part of Ls(local).
> 
> Page 81:
> 
>    o  Other control messages (Update, Keepalive, Probe): Deliver to the
>       context with CT(local) equal to the Receiver Context Tag included
>       in the packet.  Verify that the IPv6 source address field is part
>       of Ls(peer) and that the IPv6 destination address field is part of
>       Ls(local).  If not, send a R1bis message.
> 
>>>    NO_R1_HOLDDOWN_TIME = 1 min
> 
>>>    ICMP_HOLDDOWN_TIME = 10 min
> 
>>> This seems rather short, basically a shim host talking to a non-shim 
>>> host would retry setting up the shim every minute or every 10 minutes 
>>> even though there is good reason to assume this won't be successful. 
>>> Something like several hours seems more appropriate. (And only when 
>>> packets are actively exchanged.)
> 
>> well, NO_R1_HOLDDOWN_TIME is about how long we should wait until we 
>> retry when no R1 have been received. Note that this may be due to 
>> network outages that can be solved in a short time. So, we have a good 
>> reason to assume this will be successful, someone fixed the network 
>> path :-)
> 
>> in the other case, i agree, what about:
> 
>>    NO_R1_HOLDDOWN_TIME = 5 min
> 
>>    ICMP_HOLDDOWN_TIME = 60 min
> 
> The case where a firewall silently filters the packets is much more 
> likely. I still find what you list above rather short.
> 
>>> The Locator List Option Format only specifies two verification 
>>> methods at this time: CGA or HBA. What about the case where a locator 
>>> can be verified using either CGA or HBA? Maybe it makes more sense to 
>>> have each method be a bit so they can be present or absent 
>>> independently.
> 
>> if this turns to be useful we could define a verification code that 
>> would be CGA or HBA but i don't see why this would be useful... do you?
> 
> I guess you can argue that if HBA verification is possible, there is 
> never a need to do CGA verification.
> 
> Still, I think having bits for this rather than a single code is good 
> for two reasons:
> 
> 1. In case someone wants to implement either HBA or CGA but not both for 
> IPR reasons, then it becomes useful to announce both HBA and CGA capability
> 
> 2. So that when in the future a new verification method is introduced 
> that obviously isn't universally implemented but is better than CGA/HBA 
> in some way, so that people may want to take advantage of the new method 
> when supported but fall back on HBA/CGA if not
> 
>>> Please make this "I. van Beijnum"
> 
>> will try if the xml tool allows me to....
> 
> Please make sure this goes out correctly when it becomes an RFC.
> 

Delivery-date: Wed, 03 Jan 2007 11:40:48 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: shim6-proto-07 review
Date: Wed, 3 Jan 2007 12:38:38 +0100
To: marcelo bagnulo braun <[email-masked]>

On 28-dec-2006, at 18:58, marcelo bagnulo braun wrote:

>> There are no easy answers here, but congestion control is one of  
>> the core concerns in the development of the internet, so I don't  
>> think we can get away with ignoring this completely.

> i can see this is an issue...

> what do you suggest to do here? could you send text?

Thinking a bit more about this, I keep coming back to TCP slow start...

>>    o  Preserve established communications in the presence of certain
>>       classes of failures, for example, TCP connections and UDP  
>> streams.

>> Shouldn't this be "communication"?

> i don't think so...

> it could be Preserve an established communication or Preserve  
> established communications

> i think it is better the second one, because the first option seems  
> we are talking about a given specific communication...

Hm, isn't the word "communication" like "water"? I.e., you don't have  
several of it, it's just one thing of which you have more or less.

>> "The shim protocol is a site multihoming solution in the sense  
>> that it allows existing communication to continue when a site that  
>> has multiple connections to the internet experiences an outage on  
>> a subset of these connections or further upstream. However, shim  
>> processing is performed in individual hosts rather than through  
>> site-wide mechanisms."

> ok will add this... did you have a place in the draft you were  
> thinking for this text?

Maybe "placement of the shim", "terminology" or even "introduction"?

>>    the original locators become invalid at the same time and  
>> depending
>>    on the time that is required to update the DNS and for those  
>> updates
>>    to propagate.

>> Why is the DNS relevant here?

> because at least one valid locator must be published in the DNS in  
> order for a shim host to be reachable, since the DNS is used as a  
> rendez vous mechanism. OTOH, this is no specific of the shim6  
> protocol, but generic for any host... do you prefer we remove the  
> DNS consideration from here?

I don't understand what you mean here... The way I see it, the stuff  
that's in the DNS doesn't change when there are outages, only when  
links are added to or removed from the site. As such, the DNS timing  
is irrelevant except in the corner case where all existing links are  
replaced by all new ones or all the links that don't change go down.

>> This makes me uncomfortable. How do you know that an address has  
>> become terminally invalid, rather than accidentally unusable?

> this was discussed during the last meeting in san diego and there  
> was consensus that if a prefix is removed from the site, existing  
> shim contexts that are using a ulid containing the prefix must be  
> terminated when the prefix is removed.
> however, i read from your comment is that you don't have a problem  
> with this idea but your problem is with how to implement this, right?

Indeed. The autoconfig protocols don't have a mechanism to see the  
difference between a router going down accidentally and  
administrative removal of prefixes, unless you want to add  
significant amounts of guesswork to the mix. And that's something I  
don't think is a good idea, especially considering that in SITE  
multihoming the chances of clashing ULIDs after renumbering are near- 
zero.

> what about when the address becomes invalid?

In many Unix stacks you can keep using an address even if it's  
removed from all interfaces. This is a good thing, because it allows  
sessions to survive short transitions such as moving out of radio  
range for a few moments. With shim6 there is the potential that the  
address is gone for a long time but it remains in use because the  
failure is repaired using the shim.

I think the best thing to do here is keep using the address for a  
limited amount of time, like 1 - 24 hours.

> in other words, i fail to see why this is easier to implement that  
> what is currently in the draft. I mean, if the admin can determine  
> the decomisioning time, it also can terminate the existing shim6  
> contexts...

Of course not. A site administrator can't reach out into the state  
inside all the hosts in the site...

>> I don't see how regular nomadic behavior will result in two hosts  
>> using the same address in quick succession, and they can further  
>> reduce the potential for problems by not using temporary addresses  
>> as ULIDs.

> i am not sure what part of the draft this comment is referred to,  
> but if a nomadic host creates a ulid using a temporary prefix and  
> it moves away and then another nomadic hosts attaches itself to the  
> same network and generates the same address, it is possible that  
> the the two nomadic hosts end up using the same address.

Right. So don't use this type of addresses as ULIDs and then there  
are no problems.

>>       If the context establishment exchange fails, the initiator will
>>       then know that the other end does not support shim6, and will
>>       continue with standard unicast behavior for the session.

>> Unicast? Shouldn't this be "single homed"?

> will change to standard (non-shim6) behaviour, ok?

Ok.

>> More in general, the draft seems to suggest that the content of  
>> the source address field in received packets may be ignored,

> this is explicitly stated in the draft

Hm, this makes me uncomfortable... As a receiver, I would much rather  
know in advance which source addresses I'm going to see for  
established sessions/context.

Also, the source address can't be changed arbitrarily because then  
ICMP messages don't make it back to the source.

> the security level provided by the shim6 protocol relies on the  
> context tag. Any attacker needs to learn the context tag before  
> being able to inject addresses into an established context. It was  
> concluded that this is an acceptable security level and similar to  
> the one available in today's internet... do you agree?

I don't know. In general, I'm not all that paranoid about security so  
I'm not really the person to ask if security is good enough.  :-)

>>    Bidirectional Communication (FBD).  FBD uses a Keepalive message
>>    which is sent when a host has received packets from its peer  
>> but has
>>    not yet sent any packets from its ULP to the peer.

>> No, this works per address (per locator even, not per ULID, IIRC),  
>> not per ULP.

> the meaning here is that FBD generates packets when the ULPs are  
> silent. It doesn't mean that it generates packets per ULP, just  
> that when all ULPs are silent, FBD generates packets. It may be  
> rephrased as follows:

>    FBD uses a Keepalive message
>    which is sent when a host has received packets from its peer but  
> has
>    not yet sent any packets from any of its ULPs to the peer.

> would this be better?

No, because I don't see what the ULP has to do with anything. FBD is  
between address pairs.

>>    which precedes a routing header).  When tunneling is used, whether
>>    IP-in-IP tunneling or the special form of tunneling that Mobile  
>> IPv6
>>    uses (with Home Address Options and Routing header type 2),  
>> there is
>>    a choice whether the shim applies inside the tunnel or outside the
>>    tunnel, which affects the location of the shim6 header.

>> How is this coordinated with the other side? If one side does  
>> tunneling first and shim second and the other side the other way  
>> around, there will be trouble. I don't see an easy way to avoid this.

> the header order would be enough imho. I mean, when tunneling is  
> performed, two IP layers are involved and each ip layer can have  
> its own shim sublayer inside. So, for each ip layer a shim header  
> can be added, so depending on the location of the shim header, how  
> it applies, makes sense?

Ok I don't see how it fails so I'll take your word for it...

>> So what happens when some other header follows the shim header?  
>> Could this be used for attacks?

> this is for shim6 control messages and so far we haven't defined  
> means to perform piggybacking of other protocols in shim6 control  
> messages, so it is not possible for other protocols to follow the  
> shim header. If this is defined in future extensions, they will  
> need to update this part of the spec

Well, wouldn't it be better then to forbid having additional headers  
after the shim header?

>> About the different messages: they are very similar. If I were to  
>> implement all of this, I would rather work with one basic  
>> structure for all of the messages, even if the _meaning_ of some  
>> fields is different as long as their structure is always the same.  
>> I think this can easily be done here, by including fields that  
>> nearly all messages need (simply leave it zero when a particular  
>> message doesn't need a field) and use options for things that a  
>> particular message needs that aren't accommodated in the unified  
>> structure.

> i can clearly see the cost of this approach, additional overhead  
> for unused fields and potential source of confusion when fields  
> change their name... what is the advantage of such approach?

When you write an implementation, you need to extract all the values  
from a header. Since these are all different sizes without natural  
alignment this involves some complexity. When there are different  
message headers, you need to do this multiple times. If there is only  
one message header, you only have to implement the value extraction  
code once.

The field names aren't an issue at all. In code it works something  
like this:

void getheaders(int *field1, char *field2, unsigned int *field3);

void lookatmessage1()
{
   int contexttag;
   char evilbit;
   unsigned int remotecookie;

   getheaders(&contexttag, &evilbit, &remotecookie);
   if (evilbit)
     printf("You are breaking Evil Corp.'s patent, prepare to be sued! 
\n");
}

void lookatmessage2()
{
   int contexttag;
   char ossbit;
   unsigned int localcookie;

   getheaders(&contexttag, &ossbit, &localcookie);
   if (!ossbit)
     printf("You are breaking the GPL, prepare to be sued!\n");
}

Since the formats are so similar already there are only 1 or 2 cases  
where an unused field would be included so I don't think the overhead  
is a concern.

>> update request: why is this a request?

> because this is a two way protocol, update and request... (i do  
> agree that it is not the best name in this case... suggestion?)

Just "update"?

>> Hm, is it smart to defer verification here?

> depending what verification we are talking about....

> this is explained in detail in section 7.2.  Locator Verification

> there are two type of verification HBA/CGA verification is one type  
> and the other type is the one against flooding attakcs that is  
> achived using a probe packets (of the path exploration protocol)

> The spec in section 7.2 states that:

>    Thus the HBA/CGA
>    verification SHOULD be performed by the host before the host
>    acknowledges the new locator, by sending an Update Acknowledgement
>    message, or an R2 message.

>    Before a host can use a locator (different than the ULID) as the
>    destination locator it MUST perform the HBA/CGA verification if  
> this
>    was not performed before upon the reception of the locator set.  In
>    addition, it MUST verify that the ULID is indeed present at that
>    locator.  This verification is performed by doing a return-
>    routability test as part of the Probe sub-protocol [9].

> makes sense?

Is it useful to be able to defer locator verification? Simply doing  
it immediately and either acknowledging that everything is ok or  
sending back an error is much more robust than saying nothing and  
failing later.

> When the traffic generated by the ULPs results in a bidirectional  
> flow of packet between the peers, no extra packets need to be  
> inserted.

> is this ok?

No, it's still confusing. Why not leave this up to the reachability  
draft?

>> Ugh, this is certainly enough to make a grown man cry... Why all  
>> of this alignment silliness? BGP works pretty well without it.

> i think this is general in IPv6 protocols which are optimized for  
> handling 64 bits units.... but maybe someone with more expertise  
> can answer this one...

Believe me, implementations aren't going to be any simpler because of  
all the padding and length calculations, and the amounts of data  
involved are so small that having faster copying because of the  
alignment isn't an issue.

[...]

>> More in general, most error conditions are handled by silently  
>> dropping packets, however, which is a very bad idea because that  
>> way, there is no difference between an error and lost messages.

[...]

> sent this issue in a separate email

IIRC this mail doesn't go into the issue of silently dropping  
messages, so I'll restate my objection to that here.

>> About the locator option: how many locators are allowed?

> there is no upper limit other than the ones that fit inside a  
> packet with the other required options... As i mentioned above,  
> roughly this seemed enough not to become a limitation

Some limit might be helpful, though.

>> So this has nothing to do with RFC 3041 temporary addresses?

> right

>> In that case, a different name is probably better.

> agree... what about "transient"?

Sure.

>>    | E-FAILED            | Context establishment exchange failed

>> How do we know this,

> becuase we have retried several times with I1 and never got a R1 back

>>  and is it necessary to explicitly take notice of this situation?

> yes, so we don't try again for a while

> makes sense?

I prefer to have as few states as possible, but if you think having a  
separate state here is helpful, I guess it isn't really harmful.

>> Regarding section 7.9: shouldn't there be checks to make sure that  
>> seemingly duplicate packets contain the same information as the  
>> earlier packets they are supposedly the duplicate of?

> I am not following you here...

> are we talking about an initiator that receives a duplicate R1 back  
> or a receiver that receives a duplicate I1?

> If a receiver receives a duplicate I1 it doesn't do anything  
> special, just replies with a R1. don't see any problem here

So the issue whether it's a duplicate is irrelevant because the reply  
is the same either way?

> If an initiator receives a duplicated R1 (this may be due that the  
> initiator have retried with multiple I1), it will process the first  
> one received, and send a I2. The second one received, there will be  
> no shim6 context in I1-SENT state, so it will be discarded. I do  
> not see the point in verifying that the other information in the  
> packet is ok or not... what would be the point in doing this  
> verification?

If you have special case handling for duplicates it's important to be  
sure that you're actually dealing with duplicates. For instance, an  
attack could be sending out fake shim6 packets so that when the real  
ones come in later, those are rejected because they are presumed  
duplicates.

>> What if validators don't match? Eventually this shouldn't be a  
>> problem but I expect some initial trouble here because you're  
>> doing hashes over a fairly large number of values, a small mistake  
>> somewhere means the hash doesn't work, some feedback in the form  
>> of an error message would be good.

> you mean for the first packet or for the following (duplicated)   
> packets? for the first packet, this is a specific case of the  
> general problem about whether it is ok to silently discard wrong  
> packets (that i have initiated a new thread for this)
> For the second case, i don't see any point on doing this...

Initial = when implementations first appear.

It's important that people know what's going on in order to debug  
problems, not only when doing interoperability testing, but also "in  
the wild" later on.

>> It occurs to me that there is nothing or very little in the  
>> protocol that precludes shim negotiation using non-ULID addresses.

> not sure what you mean by non ulid addresses....

In the case of unreachable ULIDs where the shim packets use locator  
source/destination addresses.

> if you mean that the shim protocol can support unreachable ULIDs  
> like ULAs, then the answer is yes, it has been taken into account  
> and should work fine with unreachable ulids...(you cannot do  
> deferred setup but the spec supports it)

Good.

>> Adn why verify whether the source address is in Ls(peer)? The  
>> security mechanisms do all the checking we need.

> could you point me where is the text you are referring to? i mean  
> there is no such verification in section 7.15 which was the section  
> the previous comment was referring to...

Page 59:

    If such a context exists in ESTABLISHED state, the host verifies  
that
    the locator of the Initiator is included in Ls(peer) (This check is
    unnecessary if there is no ULID-pair option in the I1 message).

Page 63:

    o  If the state is I1-SENT, then the host verifies if the source
       locator is included in Ls(peer) or, it is included in the Locator
       List contained in the the I2 message and the HBA/CGA verification
       for this specific locator is successful

Page 69:

    o  If the state is I1-SENT, then the host verifies if the source
       locator is included in Ls(peer) or, it is included in the Locator
       List contained in the the I2 message and the HBA/CGA verification
       for this specific locator is successful

    o  If the state is ESTABLISHED, I2-SENT, or I2BIS-SENT, then the  
host
       verifies if the source locator is included in Ls(peer) or, it is
       included in the Locator List contained in the the I2 message and
       the HBA/CGA verification for this specific locator is successful

Page 74:

    Since context tags can be reused, the host MUST verify that the IPv6
    source address field is part of Ls(peer) and that the IPv6

Page 76:

    Since context tags can be reused, the host MUST verify that the IPv6
    source address field is part of Ls(peer) and that the IPv6
    destination address field is part of Ls(local).

Page 81:

    o  Other control messages (Update, Keepalive, Probe): Deliver to the
       context with CT(local) equal to the Receiver Context Tag included
       in the packet.  Verify that the IPv6 source address field is part
       of Ls(peer) and that the IPv6 destination address field is  
part of
       Ls(local).  If not, send a R1bis message.

>>    NO_R1_HOLDDOWN_TIME = 1 min

>>    ICMP_HOLDDOWN_TIME = 10 min

>> This seems rather short, basically a shim host talking to a non- 
>> shim host would retry setting up the shim every minute or every 10  
>> minutes even though there is good reason to assume this won't be  
>> successful. Something like several hours seems more appropriate.  
>> (And only when packets are actively exchanged.)

> well, NO_R1_HOLDDOWN_TIME is about how long we should wait until we  
> retry when no R1 have been received. Note that this may be due to  
> network outages that can be solved in a short time. So, we have a  
> good reason to assume this will be successful, someone fixed the  
> network path :-)

> in the other case, i agree, what about:

>    NO_R1_HOLDDOWN_TIME = 5 min

>    ICMP_HOLDDOWN_TIME = 60 min

The case where a firewall silently filters the packets is much more  
likely. I still find what you list above rather short.

>> The Locator List Option Format only specifies two verification  
>> methods at this time: CGA or HBA. What about the case where a  
>> locator can be verified using either CGA or HBA? Maybe it makes  
>> more sense to have each method be a bit so they can be present or  
>> absent independently.

> if this turns to be useful we could define a verification code that  
> would be CGA or HBA but i don't see why this would be useful... do  
> you?

I guess you can argue that if HBA verification is possible, there is  
never a need to do CGA verification.

Still, I think having bits for this rather than a single code is good  
for two reasons:

1. In case someone wants to implement either HBA or CGA but not both  
for IPR reasons, then it becomes useful to announce both HBA and CGA  
capability

2. So that when in the future a new verification method is introduced  
that obviously isn't universally implemented but is better than CGA/ 
HBA in some way, so that people may want to take advantage of the new  
method when supported but fall back on HBA/CGA if not

>> Please make this "I. van Beijnum"

> will try if the xml tool allows me to....

Please make sure this goes out correctly when it becomes an RFC.

Delivery-date: Tue, 02 Jan 2007 14:28:11 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: about the ULID in the TCP checksum
Date: Tue, 2 Jan 2007 15:27:34 +0100
To: marcelo bagnulo braun <[email-masked]>

On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote:

>> The problem here is that some intermediate system, such as a  
>> firewall or a smart NIC, may take it upon itself to check the TCP  
>> or UDP checksum and discard the packet if the checksum fails.

> how common is this practice? is this widely used?

Certainly not with IPv6. But checksumming NICs are very common for  
IPv4 so I'm sure we'll have those for IPv6 too in the future. And at  
one point, PIX firewalls would truncate DNS packets that were longer  
than 512 bytes, creating much mayham with EDNS0. So I have a healthy  
suspicion of firewall builders.

>>  For firewalls and the like, the best thing is probably either to  
>> fully monitor the shim state so they can do this properly, or  
>> forego such checking if a shim header is present.

> yes, this is probably useful in terms of security also, just like  
> in the case to TCP connections, where the firewall can decide to  
> accept segments of connections for which the firewall have  
> previosuly seen SYN exchange

> do you think we should add text about this? (if you do, please send  
> text)

"Firewalls and other middleboxes SHALL NOT drop TCP, UDP and ICMP  
packets with apparently incorrect checksums based on that fact alone  
unless they implement (monitoring of) the full shim6 protocol and are  
able to determine the checksum that must be present in a packet with  
addresses rewritten by shim6."

>> For NICs a better solution would be to do an incremental checksum  
>> verification and only over the ULP segment, so that the host stack  
>> must complete the calculation by applying the increment from the  
>> pseudo header, which can largely be cached, so the performance  
>> advantages are almost completely preserved

> i don't understand what do you mean by incremental checksum  
> verification... could you expand on this?

The checksum is defined as the one's complement of the one's  
complement additions of the 16-bit words making up the pseudo-header  
and the TCP/UDP/ICMP segment. So you could calculate it this way:

//  0  start
chksm = 0;

//  1  pseudoheader
for (i = 0; i < pseudo.length; i++)
   chcksm = 1cmpadd(chcksm, pseudo.hdr[i]);

//  2  TCP
for (i = 0; i < tcp.length; i++)
   chcksm = 1cmpadd(chcksm, tcp.data[i]);

//  3  check
if (1cmp(chcksm) == tcp.checksum)
   return happy;
else
   return sad;

As far as I can tell, NICs can do parts 0 - 2 and leave 3 up to the  
IP stack. This method isn't compatible with shim6 because then the  
NIC would have to be aware of the address rewriting. However, it  
wouldn't be hard to do 0 and 1 in the IP stack, 2 in the NIC and 3 in  
the IP stack again. Since the pseudoheader is always the same for a  
session, this part can be pre-computed, so the only part that  
actually requires real work is checking the TCP/UDP/ICMP segment,  
which is exactly the part that still happens in the NIC, so  
performance can be the same but now everything is shim-compatible.

Delivery-date: Tue, 02 Jan 2007 14:11:57 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: length of shim6 control mesages
Date: Tue, 2 Jan 2007 15:11:30 +0100
To: marcelo bagnulo braun <[email-masked]>

On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote:

> so far we haven't considered the case where the options wouldn't  
> fit in one packet... 1280 bytes seems big enough....

Famous last words.  :-)

> what do you suggest?

Some language that tells implementers whether they can make shim6  
packets that result in IPv6 packets bigger than 1280 bytes. For  
instance:

"Shim6 signalling packets may not be larger than 1280 bytes,  
including the IPv6 header and any intermediate headers between the  
IPv6 header and the shim6 header. One way to meet this requirement is  
to omit part of the locator address information if with this  
information included, the packet would become larger than 1280 bytes.  
An implementation may impose administrative restrictions to avoid  
excessively large shim6 packets, such as a limitation on the number  
of locators to be used or a limitation on the CGA key size."

Delivery-date: Tue, 02 Jan 2007 14:10:27 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: about the protection against on path attackers
Date: Tue, 2 Jan 2007 15:04:37 +0100
To: marcelo bagnulo braun <[email-masked]>

On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote:

>> Also, for CGA verification, don't we need to send the other side a  
>> challenge to avoid replays?

> I don't know if this is necessary...

Ah, ok, so the updates are their own challenge.

What I was thinking about was that the correspondent claims to have  
the secret key belonging to the public key, but you don't know that  
unless you see some data signed with the secret key that is  
particular to the session at hand.

>>       context.  In this case, we are in the Context confusion  
>> situation,
>>       and the host MUST NOT use the old context to send any  
>> packets.  It
>>       MAY just discard the old context (after all, the peer has
>>       discarded it), or it MAY attempt to re-establish the old  
>> context
>>       by sending a new I1 message and moving its state to I1- 
>> SENT.  In
>>       any case, once that this situation is detected, the host  
>> MUST NOT
>>       keep two contexts with overlapping Ls(peer) locator sets and  
>> the
>>       same context tag in ESTABLISHED state, since this would  
>> result in
>>       demultiplexing problems on the peer.

>> What if an attacker is trying to interfere with legitimate  
>> communication? We must be VERY sure that the new shim messages  
>> come from the same host as the one that created the existing state  
>> if we're going to mess with that existing state.

> THe current security level is that we don't provide protection  
> against on path attackers. If an attacker learns the context tag,  
> then it can do some nasty stuff, including destroying the  
> established context. this is the level of security that we have  
> defined for the protocol. We can discuss whether this security  
> level is approapriate, but i would like to have a high level  
> discussion on the issue.

I guess you're right. But as an added measure, I'd like to see that  
the old context isn't torn down until the new one is set up  
completely. This way, an attacker that somehow finds out a context  
tag needs to have return routability and do the full 4-way handshake  
to destroy a context, which is almost certainly not worth that much  
trouble.

Delivery-date: Tue, 02 Jan 2007 13:59:13 +0000
Cc: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: always including the context tag
Date: Tue, 2 Jan 2007 14:56:17 +0100
To: marcelo bagnulo braun <[email-masked]>

On 28-dec-2006, at 18:57, marcelo bagnulo braun wrote:

>> 1. Always including the context tag

>> As I've said many times, it's a very bad idea to unnecessarily  
>> increase overhead.

> well, i think having an additional header is the clean way to do  
> this, because there is an additional layer that is being inserted  
> and the layer needs to perform its signalling and this is achieved  
> using a extra header.

Clean != best

We also have ample precedent for non-clean solutions.  :-)

>> Earlier, I proposed to include a mandatory way for a host to  
>> instruct its peer to not include the shim header, pending  
>> mechanisms to do demultiplexing without the context tag. After  
>> reading the draft, I realize that this imposes some extra ICMP  
>> demultiplexing difficulties on implementations.

> depending on which fields do you use for the demux, i guess... i  
> mean if you use the flow label, there wouldn't be additional  
> problems, i think, right?

Right, but that's not a discussion that we need to have. What I  
advocate is having the receiver tell the sender that it must not  
include the header because the receiver can demux. How the receiver  
does this is up to the receiver and doesn't need to be part of this  
spec. (The most obvious choice is having locator-only addresses for  
each ULID address so there is always an unambigious identification of  
packets sent to locators and an unambiguous mapping back to the ULID.)

>>  So if the wg doesn't want to include this mandatory option, I  
>> suggest something different: since the traffic engineering  
>> mechanisms aren't really developed anyway and this problem is  
>> related to that, simply remove the locator preferences mechanism  
>> so that the context tag suppression can be included when proper  
>> traffic engineering is added.

> i don't think this is such a good idea...

> i mean i think locator preferneces are useful, i don't see why we  
> should remove them from the spec...

They're useful, but if we have locator preferences and not context  
tag suppression, this creates the opportunity for using shim6 as a  
load balancing mechanism that introduces additional per-packet  
overhead in cases where there is no failure. This is a very bad  
thing, in my opinion.

So that's why I think if we can't agree on the CT suppression in this  
spec, we should also remove the preferences and then introduce both  
of them at some later date, along with a more comprehensive traffic  
engineering solution, because the preferences alone aren't enough for  
that anyway.

Delivery-date: Mon, 01 Jan 2007 12:04:40 +0000
Date: Mon, 01 Jan 2007 12:58:52 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: always including the context tag

On 2006-12-28 18:57, marcelo bagnulo braun wrote:
> In his review Iljitsch raises the following issue:
> 
> my comments are online:
> 
> please comment on the issue related to if we should support other 
> mechanisms for demux other than the context tag contained in the shim 
> payload header
> 
>> 1. Always including the context tag
>>
>> As I've said many times, it's a very bad idea to unnecessarily 
>> increase overhead.

Has anyone looked at how this would interact with ROHC? The only context in
which I would agree with Iljitsch is where bandwidth is precious, and that
is exactly where ROHC should be used anyway. The context tag really
should be very compressible...
> 
> well, i think having an additional header is the clean way to do this, 
> because there is an additional layer that is being inserted and the 
> layer needs to perform its signalling and this is achieved using a extra 
> header.

Yes, and an architecturally clean solution may quite legitimately make it
necessary to increase overhead.

     Brian
> 
>>  Not only is this a bad thing in and of itself, but it also doesn't 
>> help convince people to forego IPv4+BGP in favor of IPv6+shim.
>>
>> Now if we only include the shim header containing the context tag 
>> after a failure, this could be a reasonable tradeoff. However, I'm 
>> quite sure that if and when shim6 is adopted, some people will use it 
>> to manage their traffic engineering by doing a locator change 
>> immediately and proceed in a shimmed state for the rest of the 
>> communication session.
>>
>> Earlier, I proposed to include a mandatory way for a host to instruct 
>> its peer to not include the shim header, pending mechanisms to do 
>> demultiplexing without the context tag. After reading the draft, I 
>> realize that this imposes some extra ICMP demultiplexing difficulties 
>> on implementations.
> 
> depending on which fields do you use for the demux, i guess... i mean if 
> you use the flow label, there wouldn't be additional problems, i think, 
> right?
> 
>>  So if the wg doesn't want to include this mandatory option, I suggest 
>> something different: since the traffic engineering mechanisms aren't 
>> really developed anyway and this problem is related to that, simply 
>> remove the locator preferences mechanism so that the context tag 
>> suppression can be included when proper traffic engineering is added.
>>
> 
> i don't think this is such a good idea...
> 
> i mean i think locator preferneces are useful, i don't see why we should 
> remove them from the spec...
> 
> 
>> Also see draft-van-beijnum-shim6-suppress-header-00.txt (do it while 
>> you can, it expires next week...), this outlines a more fully formed 
>> mechanism to suppress the context tag header.
>>
>> I would very much like to see a consensus call on this subject.
>>
>>     
> 
> 

Delivery-date: Mon, 01 Jan 2007 12:04:31 +0000
Date: Mon, 01 Jan 2007 13:04:02 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: about the ULID in the TCP checksum

On 2006-12-28 18:57, marcelo bagnulo braun wrote:
> Iljitsch in his review raises the following issue:
> 
> my comments are inline
> 
>>    The result of this consistent mapping is that there is no impact on
>>    the ULPs.  In particular, there is no impact on pseudo-header
>>    checksums and connection identification.
>>
>>
>> The problem here is that some intermediate system, such as a firewall 
>> or a smart NIC, may take it upon itself to check the TCP or UDP 
>> checksum and discard the packet if the checksum fails.
> 
> how common is this practice? is this widely used?

I've not heard of firewalls doing this, but TCP relays are a known
form of evil - probably shim6 would not work on such a path.

TCP/IP offload mechanisms in general will have to be shim6-aware,
for sure. This is going to be very common in server clusters.

(In general, do we need a TCP/shim6 probing procedure, to check
whether a path actually works?)

     Brian
> 
>>  For firewalls and the like, the best thing is probably either to 
>> fully monitor the shim state so they can do this properly, or forego 
>> such checking if a shim header is present.
>>
> 
> yes, this is probably useful in terms of security also, just like in the 
> case to TCP connections, where the firewall can decide to accept 
> segments of connections for which the firewall have previosuly seen SYN 
> exchange
> 
> do you think we should add text about this? (if you do, please send text)
> 
>> For NICs a better solution would be to do an incremental checksum 
>> verification and only over the ULP segment, so that the host stack 
>> must complete the calculation by applying the increment from the 
>> pseudo header, which can largely be cached, so the performance 
>> advantages are almost completely preserved
> 
> i don't understand what do you mean by incremental checksum 
> verification... could you expand on this?
> 
> 

Delivery-date: Mon, 01 Jan 2007 11:54:40 +0000
Date: Mon, 01 Jan 2007 12:52:20 +0100
From: Brian E Carpenter <[email-masked]>
Organization: IBM
To: marcelo bagnulo braun <[email-masked]>
CC: Iljitsch van Beijnum <[email-masked]>, shim6-wg <[email-masked]>
Subject: Re: error messages in shim6

On 2006-12-28 14:29, marcelo bagnulo braun wrote:
> Iljitsch has brought up the following issue in his review:
> 
>> More in general, most error conditions are handled by silently 
>> dropping packets, however, which is a very bad idea because that way, 
>> there is no difference between an error and lost messages.
>>  So in some cases, a host may continue to resend the offending packet 
>> because it doesn't know something went wrong. The main problem with 
>> this approach is that you can't debug it from one end: you need to see 
>> what happens on both ends to determine why something doesn't work.
>>
>> Silently dropping packets because of errors is the right approach for 
>> security reasons in some cases, but I don't think this applies here. A 
>> short error message with an error code and optionally a human-readable 
>> message would be much better. As long as these error packets are 
>> smaller than the packets that trigger them, there should be little or 
>> no security impact, especially considering that we're prepared to talk 
>> shim with the correspondent in question to begin with.
>>
> 
> his proposal as you can see is to include a shim6 error message to 
> handle this situations... any opinions?

I would agree with Iljitsch for any case where the sender will indeed
continuously repeat the message unless there is a response. (Alternatively,
get rid of the continuous repeats some other way.)

     Brian