Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-03.txt
From: Brian E Carpenter <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
Cc: shim6-wg <[email-masked]>
Date: Wed, 18 Jul 2007 11:57:52 +0200

On 2007-07-17 22:07, marcelo bagnulo braun wrote:
> Hi Brian,
> 
> thanks for the feedback
> 
> El 17/07/2007, a las 11:59, Brian E Carpenter escribió:
> 
>> This draft looks good to me on content; the English needs a
>> check.
>>
> 
> If you could be more specific on this i could try to fix it...

I was assuming that Joe would make a pass over it as co-author;
there's nothing serious for people used to Euroenglish :-)

>> One comment:
>>
>>> 4.3.  Traffic Engineering
>> ...
>>>               There is no defined mechanism which would allow use of
>>>    the Locator Preferences option amongst a site full of hosts to be
>>>    managed centrally.
>>
>> It might be worth noting that RFC 4384 policy is also available
>> as a primitive TE tool, with at least one mechanism for site-wide
>> distribution of that policy existing in draft.
>>
> 
> ok, we can include some text about this in the next version

Thanks.

> 
> One more question: do you think we should include other sections or 
> address other issues in here? For instance, one option would be to 
> "borrow" some text on application considerations from Erik expired 
> drafts and describe the referrals, call backs and so on. Imho these are 
> interesting conclusions we achieved in this work, and i would like to 
> reflect them somewhere...

Yes, discussing referrals would be very useful IMHO. Somewhere we
had responses to all the RFC 3582 goals, and those could possibly be
useful too.

     Brian

Delivery-date: Tue, 17 Jul 2007 22:55:47 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-03.txt
Date: Tue, 17 Jul 2007 22:07:32 +0200
To: Brian E Carpenter <[email-masked]>

Hi Brian,

thanks for the feedback

El 17/07/2007, a las 11:59, Brian E Carpenter escribi�:

> This draft looks good to me on content; the English needs a
> check.
>

If you could be more specific on this i could try to fix it...

> One comment:
>
>> 4.3.  Traffic Engineering
> ...
>>               There is no defined mechanism which would allow use of
>>    the Locator Preferences option amongst a site full of hosts to be
>>    managed centrally.
>
> It might be worth noting that RFC 4384 policy is also available
> as a primitive TE tool, with at least one mechanism for site-wide
> distribution of that policy existing in draft.
>

ok, we can include some text about this in the next version

One more question: do you think we should include other sections or  
address other issues in here? For instance, one option would be to  
"borrow" some text on application considerations from Erik expired  
drafts and describe the referrals, call backs and so on. Imho these  
are interesting conclusions we achieved in this work, and i would  
like to reflect them somewhere...

Regards, marcelo

>     Brian
>

Delivery-date: Tue, 17 Jul 2007 10:02:01 +0000
Date: Tue, 17 Jul 2007 11:59:49 +0200
From: Brian E Carpenter <[email-masked]>
To: shim6-wg <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-03.txt

This draft looks good to me on content; the English needs a
check.

One comment:

> 4.3.  Traffic Engineering
...
>               There is no defined mechanism which would allow use of
>    the Locator Preferences option amongst a site full of hosts to be
>    managed centrally.

It might be worth noting that RFC 4384 policy is also available
as a primitive TE tool, with at least one mechanism for site-wide
distribution of that policy existing in draft.

     Brian

Delivery-date: Mon, 16 Jul 2007 12:10:07 +0000
Date: Mon, 16 Jul 2007 14:07:45 +0200
From: Wouter Wijngaards <[email-masked]>
To:  [email-masked]
Subject: Verification thesis online

Hi,

As you've already seen from his comments on this list Matthijs Mekking
has written a thesis at NLnet Labs on Verification and Formalization of
the Shim6 Protocol. In his thesis he uses an automated protocol verifier
(UPPAAL) to check the shim6 protocol.

As his term has ended (with an excellent grade), the thesis from
Matthijs is now available on the NLnet Labs website:
	http://www.nlnetlabs.nl/downloads/fvShim6thesis.pdf

Best regards,
   Wouter

Delivery-date: Fri, 13 Jul 2007 09:22:12 +0000
Cc: shim6-wg <[email-masked]>, RAM Mailing List <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: proxy shim with hash in upper address bits?
Date: Fri, 13 Jul 2007 11:20:06 +0200
To: marcelo bagnulo braun <[email-masked]>

On 13-jul-2007, at 11:03, marcelo bagnulo braun wrote:

>> Another, possibly even harder to solve, problem with proxy shim is  
>> what happens when a host behind the proxy want to talk to a non- 
>> shim host.

> it depends what type of idetifiers are you using

Of course, I was assuming non-routable identifiers.

>> But quite possibly, we can solve this if we can make proxy shim  
>> interoperable with a LISP-like approach. So the user of the  
>> portable space would implement a shim proxy cq ETR/ITR which would  
>> obviously be able to talk to other shim proxy/ETR/ITR devices as  
>> well as to any host that supports shim6. Hosts that don't  
>> implement shim6 would have to reach hosts behind a proxy through  
>> ETRs that are deployed by their ISPs or possibly by the sellers of  
>> the portable address space.

> how does this solve the backward compatibility problem? I mean you  
> still need to deploy ETR/ITR in the remote site, so if you do that,  
> you may well deploy any other box i.e a pproxy shim

> Bottom line: proxy shim, shim6, lisp, you-name-it, they all require  
> support from both ends involved in the communication (either host  
> or a box next to the host (proxy, TR)) (and the multihoming  
> benefits only apply to the path between the two multihoming aware  
> boxes)

Yes, this is an important limitation. With shim6 in hosts, you can  
determine if the other side supports shim6 before selecting an  
unroutable identifier, and fall back on legacy IPv6 if it doesn't,  
but then you're not multihomed for that session. With LISP et al this  
isn't possible, but the logic doesn't have to be in the hosts, so as  
long as there is a box somewhere in the path that supports the  
protocol, you're in business. The degenerative case would be where  
the encapsuating devices for site X which is reachable through ISPs A  
and B are located in the networks of A and B.

Making (proxy) shim6 and LISP interoperable helps shim6 because the  
deployment of LISP boxes means more people to talk shim6 with, and it  
helps LISP because you get to optimize paths to a much higher degree  
because this can happen at individual hosts, even ones that are not  
served by a *TR device.

Delivery-date: Fri, 13 Jul 2007 09:05:33 +0000
Cc: shim6-wg <[email-masked]>, RAM Mailing List <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: proxy shim with hash in upper address bits?
Date: Fri, 13 Jul 2007 11:03:55 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 12/07/2007, a las 23:04, Iljitsch van Beijnum escribi�:

> [crossposted, please prune as required. RAM people, please look at  
> the bottom of the message]
>
> On 11-jul-2007, at 15:23, marcelo bagnulo braun wrote:
>
>>> After reading Marcelo's draft about a proxy implementation of  
>>> shim6 a while ago I was somewhat disheartened: this is extremely  
>>> hard to do, mostly because an unsuspecting host would need to  
>>> receive an HBA-compatible address.
>
>> why do you think so?... you can deal with this doing dhcp  
>> delegation of the HBAs/CGAs? (you would be breaking stateless  
>> address autoconf, but i guess the same would happen if you need a  
>> reasonable amount of bits in the prefix to carry crypto  
>> information...)
>
> You're right, if you can get the hosts to create only HBA addresses  
> by use of DHCPv6 or some other mechanism, that would work. Note  
> thought that most of today's IPv6 hosts don't support DHCPv6  
> address assignment so this may not be a suitable solution for true  
> legacy IPv6 support.
>
> Obviously stateless autoconf would have to work with the bits in  
> the upper part of the address or this would be an exercise in  
> futility.
>
>> Yes, creating a crypto prefix for the identifier namespace would  
>> bean option for dealing with this, but i guess it would break SAA
>
> SAA?
>

stateless address auto configuration

> Another, possibly even harder to solve, problem with proxy shim is  
> what happens when a host behind the proxy want to talk to a non- 
> shim host.

it depends what type of idetifiers are you using

if you are using routable identifiers, then you don't have problem

if you are not using routble ids, then you are in trouble and  
backward compatibility woudl require either configuring routable  
address to hosts (in addition of the non routable ids) or some form  
of nat

> But quite possibly, we can solve this if we can make proxy shim  
> interoperable with a LISP-like approach. So the user of the  
> portable space would implement a shim proxy cq ETR/ITR which would  
> obviously be able to talk to other shim proxy/ETR/ITR devices as  
> well as to any host that supports shim6. Hosts that don't implement  
> shim6 would have to reach hosts behind a proxy through ETRs that  
> are deployed by their ISPs or possibly by the sellers of the  
> portable address space.

how does this solve the backward compatibility problem? I mean you  
still need to deploy ETR/ITR in the remote site, so if you do that,  
you may well deploy any other box i.e a pproxy shim

Bottom line: proxy shim, shim6, lisp, you-name-it, they all require  
support from both ends involved in the communication (either host or  
a box next to the host (proxy, TR)) (and the multihoming benefits  
only apply to the path between the two multihoming aware boxes)

Regards, marcelo

Delivery-date: Thu, 12 Jul 2007 21:07:40 +0000
Cc: shim6-wg <[email-masked]>, RAM Mailing List <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: proxy shim with hash in upper address bits?
Date: Thu, 12 Jul 2007 23:04:37 +0200
To: marcelo bagnulo braun <[email-masked]>

[crossposted, please prune as required. RAM people, please look at  
the bottom of the message]

On 11-jul-2007, at 15:23, marcelo bagnulo braun wrote:

>> After reading Marcelo's draft about a proxy implementation of  
>> shim6 a while ago I was somewhat disheartened: this is extremely  
>> hard to do, mostly because an unsuspecting host would need to  
>> receive an HBA-compatible address.

> why do you think so?... you can deal with this doing dhcp  
> delegation of the HBAs/CGAs? (you would be breaking stateless  
> address autoconf, but i guess the same would happen if you need a  
> reasonable amount of bits in the prefix to carry crypto  
> information...)

You're right, if you can get the hosts to create only HBA addresses  
by use of DHCPv6 or some other mechanism, that would work. Note  
thought that most of today's IPv6 hosts don't support DHCPv6 address  
assignment so this may not be a suitable solution for true legacy  
IPv6 support.

Obviously stateless autoconf would have to work with the bits in the  
upper part of the address or this would be an exercise in futility.

> Yes, creating a crypto prefix for the identifier namespace would  
> bean option for dealing with this, but i guess it would break SAA

SAA?

Another, possibly even harder to solve, problem with proxy shim is  
what happens when a host behind the proxy want to talk to a non-shim  
host. But quite possibly, we can solve this if we can make proxy shim  
interoperable with a LISP-like approach. So the user of the portable  
space would implement a shim proxy cq ETR/ITR which would obviously  
be able to talk to other shim proxy/ETR/ITR devices as well as to any  
host that supports shim6. Hosts that don't implement shim6 would have  
to reach hosts behind a proxy through ETRs that are deployed by their  
ISPs or possibly by the sellers of the portable address space.

Delivery-date: Wed, 11 Jul 2007 13:24:13 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: proxy shim with hash in upper address bits?
Date: Wed, 11 Jul 2007 15:23:33 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 11/07/2007, a las 12:45, Iljitsch van Beijnum escribi�:

> [catching up]
>
> After reading Marcelo's draft about a proxy implementation of shim6  
> a while ago I was somewhat disheartened: this is extremely hard to  
> do, mostly because an unsuspecting host would need to receive an  
> HBA-compatible address.
>

why do you think so?... you can deal with this doing dhcp delegation  
of the HBAs/CGAs? (you would be breaking stateless address autoconf,  
but i guess the same would happen if you need a reasonable amount of  
bits in the prefix to carry crypto information...)

> I know we had discussions in the past about putting crypto bits in  
> the _upper_ rather than the _lower_ bits of an address, which would  
> solve this problem very nicely. That would (of course) be  
> incompatible with the idea that shim6 identifiers are also PA  
> routable locators, but that's actually an advantage: by doing this  
> we'd be creating an identifier space for shim6 that's distinct from  
> regular routable address space and also from all forms of ULA.
>

Yes, creating a crypto prefix for the identifier namespace would bean  
option for dealing with this, but i guess it would break SAA

regards, marcelo

> The only problem that I see is that under the normal regime (/48  
> per site), the number of hash bits would be very limited. The only  
> way to solve that would be to annex most of the subnet bits, so we  
> can have 52 - 56 hash bits.
>
> Thoughts?
>

Delivery-date: Wed, 11 Jul 2007 12:47:37 +0000
To: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: proxy shim with hash in upper address bits?
Date: Wed, 11 Jul 2007 12:45:15 +0200

[catching up]

After reading Marcelo's draft about a proxy implementation of shim6 a  
while ago I was somewhat disheartened: this is extremely hard to do,  
mostly because an unsuspecting host would need to receive an HBA- 
compatible address.

I know we had discussions in the past about putting crypto bits in  
the _upper_ rather than the _lower_ bits of an address, which would  
solve this problem very nicely. That would (of course) be  
incompatible with the idea that shim6 identifiers are also PA  
routable locators, but that's actually an advantage: by doing this  
we'd be creating an identifier space for shim6 that's distinct from  
regular routable address space and also from all forms of ULA.

The only problem that I see is that under the normal regime (/48 per  
site), the number of hash bits would be very limited. The only way to  
solve that would be to annex most of the subnet bits, so we can have  
52 - 56 hash bits.

Thoughts?

Delivery-date: Tue, 10 Jul 2007 12:23:57 +0000
Date: Tue, 10 Jul 2007 15:21:41 +0300
From: Jari Arkko <[email-masked]>
To: Geoff Huston <[email-masked]>
CC: Brian E Carpenter <[email-masked]>,  [email-masked],  [email-masked], Iljitsch van Beijnum <[email-masked]>,  Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>,  [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

Geoff, Brian,

>>>
>>> I would like to propose that your comments are addressed in the
>>> related current SHIM6 document activity on the topic of an
>>> applicability statement, and, given that situation, there is no
>>> compelling case to revise the protocol document to include this (and
>>> related) applicability considerations.
>>
>> However, the applicability draft is not cited in the proto draft.
>> It's listed as a reference, but is not cited. That's going to
>> have to be fixed editorially anyway. I agree that the applicability
>> draft is the appropriate place to discuss this.
>
> ok - we'll do this editorially, as its not a normative issue

I agree with Brian that needs to be mentioned at
least indirectly. Adding a reference to the app note
and a few words to explain the reference would be
my preference.

But lets not revise the document because of this.
Once the ADs have the proto questionnaires in
their hands, they will start AD review and eventually
IETF Last Call and IESG review. A small edit can live
as an RFC Editor note in the tracker until we've collected
enough to warrant a new revision in one of the stages
or until the document is shipped to the RFC Editor.
Chairs, authors, can you suggest text for the new
reference so that I can place it in the tracker?

Jari

Delivery-date: Mon, 09 Jul 2007 21:46:52 +0000
Date: Tue, 10 Jul 2007 07:48:30 +1000
From: Geoff Huston <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-ietf-shim6-applicability-03.txt 

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

	Title		: Applicability Statement for the Level 3 Multihoming Shim 
Protocol (Shim6)
	Author(s)	: M. Bagnulo, J. Abley
	Filename	: draft-ietf-shim6-applicability-03.txt
	Pages		: 20
	Date		: 2007-7-9
	
This document discusses the applicability of the shim6 IPv6 protocol
    element and associated support protocols to provide site multihoming
    capabilities in IPv6.

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

Delivery-date: Mon, 09 Jul 2007 21:46:14 +0000
Date: Tue, 10 Jul 2007 07:47:23 +1000
From: Geoff Huston <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-ietf-shim6-locator-pair-selection-02.txt 

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

	Title		: Default Locator-pair selection algorithm for the SHIM6 protocol
	Author(s)	: M. Bagnulo
	Filename	: draft-ietf-shim6-locator-pair-selection-02.txt
	Pages		: 11
	Date		: 2007-7-9
	
In this note, we present a locator-pair selection mechanism for the
    shim6 protocol.  The presented mechanism provides an ordered list of
    available locator-pairs that can be used for outgoing traffic.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-locator-pair-selection-02.txt

Delivery-date: Mon, 09 Jul 2007 21:32:30 +0000
Date: Tue, 10 Jul 2007 07:33:14 +1000
From: Geoff Huston <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked], [email-masked], Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>, [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

>>
>> I would like to propose that your comments are addressed in the 
>> related current SHIM6 document activity on the topic of an 
>> applicability statement, and, given that situation, there is no 
>> compelling case to revise the protocol document to include this (and 
>> related) applicability considerations.
> 
> However, the applicability draft is not cited in the proto draft.
> It's listed as a reference, but is not cited. That's going to
> have to be fixed editorially anyway. I agree that the applicability
> draft is the appropriate place to discuss this.

ok - we'll do this editorially, as its not a normative issue

>>
>> I trust that this is an acceptable approach to this consideration to 
>> you and the WG and that we are still in a position to submit the 
>> protocol document to the IESG as a Proposed Standard.
> 
> Indeed,it isn't a normative issue.
> 
>    Brian
>>
>>
regards,

   Geoff

Delivery-date: Mon, 09 Jul 2007 11:05:57 +0000
Date: Mon, 09 Jul 2007 12:58:44 +0200
From: Brian E Carpenter <[email-masked]>
To: Geoff Huston <[email-masked]>
CC:  [email-masked],  [email-masked],  Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>,  Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>,  [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

On 2007-07-09 12:40, Geoff Huston wrote:
> Brian,
> 
> Thanks for these (ever so slightly belated) WGLC comments.

Hey, you were just trying to take unfair advantage of your time zone :-)

> Among the shim6 documents still on our agenda as a WG is the 
> applicability document. The (currently expired) draft 
> draft-ietf-shim6-applicability-02.txt includes this consideration 
> regarding SHIM6 and SCTP, and also includes applicability comments 
> relating to interaction with other protocols (section 5).
> 
> I would like to propose that your comments are addressed in the related 
> current SHIM6 document activity on the topic of an applicability 
> statement, and, given that situation, there is no compelling case to 
> revise the protocol document to include this (and related) applicability 
> considerations.

However, the applicability draft is not cited in the proto draft.
It's listed as a reference, but is not cited. That's going to
have to be fixed editorially anyway. I agree that the applicability
draft is the appropriate place to discuss this.
> 
> I trust that this is an acceptable approach to this consideration to you 
> and the WG and that we are still in a position to submit the protocol 
> document to the IESG as a Proposed Standard.

Indeed,it isn't a normative issue.

    Brian
> 
> 
> regards,
> 
>   Geoff
> 
> 
> 
> Brian E Carpenter wrote:
>> On 2007-06-25 02:25, Geoff Huston wrote:
>>> Hi,
>>>
>>> This note starts the WG Last Call for comments on the three "base" 
>>> Shim6 documents as Proposed Standards:
>>>
>>> draft-ietf-shim6-proto-08.txt
>>>              "Level 3 multihoming shim protocol"
>>
>> One substantive comment. The need for some ULPs to bypass the
>> shim is mentioned in section 4.3, API Extensions, but there is
>> no reference to the need for SCTP to bypass the shim, which
>> is not an issue for the socket API. I think that needs to
>> be mentioned somewhere.
>>
>>> draft-ietf-shim6-hba-03.txt
>>>              "Hash Based Addresses (HBA)"
>>>
>>> draft-ietf-shim6-failure-detection-08.txt
>>>              "Failure Detection and Locator Pair
>>>               Exploration Protocol for IPv6
>>>               Multihoming"
>>
>> No substantive comments on these two.
>>
>>     Brian
>>
>>> These documents can be found at:
>>>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-08.txt
>>>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-03.txt
>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt 
>>>
>>>
>>> Please review the documents carefully, and send your feedback to the 
>>> SHIM6 list.
>>> Please also indicate whether or not you believe that these documents 
>>> are ready to
>>> go to the IESG for publication as a set of Proposed Standards.
>>>
>>> This Working Group Last Call will end in two weeks, on the 9th July 
>>> 2007 at
>>> 1100, UTC+10
>>>
>>>    Thanks,
>>>
>>>
>>>          Geoff & Kurtis
>>>
>>>
>>>
>>>
>>>
>>>
>>>
> 

Delivery-date: Mon, 09 Jul 2007 10:39:44 +0000
Date: Mon, 09 Jul 2007 20:40:32 +1000
From: Geoff Huston <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked], [email-masked], Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>, [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

Brian,

Thanks for these (ever so slightly belated) WGLC comments.

Among the shim6 documents still on our agenda as a WG is the 
applicability document. The (currently expired) draft 
draft-ietf-shim6-applicability-02.txt includes this consideration 
regarding SHIM6 and SCTP, and also includes applicability comments 
relating to interaction with other protocols (section 5).

I would like to propose that your comments are addressed in the related 
current SHIM6 document activity on the topic of an applicability 
statement, and, given that situation, there is no compelling case to 
revise the protocol document to include this (and related) applicability 
considerations.

I trust that this is an acceptable approach to this consideration to you 
and the WG and that we are still in a position to submit the protocol 
document to the IESG as a Proposed Standard.

regards,

   Geoff

Brian E Carpenter wrote:
> On 2007-06-25 02:25, Geoff Huston wrote:
>> Hi,
>>
>> This note starts the WG Last Call for comments on the three "base" 
>> Shim6 documents as Proposed Standards:
>>
>> draft-ietf-shim6-proto-08.txt
>>              "Level 3 multihoming shim protocol"
> 
> One substantive comment. The need for some ULPs to bypass the
> shim is mentioned in section 4.3, API Extensions, but there is
> no reference to the need for SCTP to bypass the shim, which
> is not an issue for the socket API. I think that needs to
> be mentioned somewhere.
> 
>> draft-ietf-shim6-hba-03.txt
>>              "Hash Based Addresses (HBA)"
>>
>> draft-ietf-shim6-failure-detection-08.txt
>>              "Failure Detection and Locator Pair
>>               Exploration Protocol for IPv6
>>               Multihoming"
> 
> No substantive comments on these two.
> 
>     Brian
> 
>> These documents can be found at:
>>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-08.txt
>>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-03.txt
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt 
>>
>>
>> Please review the documents carefully, and send your feedback to the 
>> SHIM6 list.
>> Please also indicate whether or not you believe that these documents 
>> are ready to
>> go to the IESG for publication as a set of Proposed Standards.
>>
>> This Working Group Last Call will end in two weeks, on the 9th July 
>> 2007 at
>> 1100, UTC+10
>>
>>    Thanks,
>>
>>
>>          Geoff & Kurtis
>>
>>
>>
>>
>>
>>
>>

Delivery-date: Mon, 09 Jul 2007 09:58:39 +0000
Date: Mon, 09 Jul 2007 11:57:56 +0200
From: Brian E Carpenter <[email-masked]>
To: Geoff Huston <[email-masked]>
CC:  [email-masked],  [email-masked],  Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>,  Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>,  [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

On 2007-06-25 02:25, Geoff Huston wrote:
> Hi,
> 
> This note starts the WG Last Call for comments on the three "base" Shim6 
> documents as Proposed Standards:
> 
> draft-ietf-shim6-proto-08.txt
>              "Level 3 multihoming shim protocol"

One substantive comment. The need for some ULPs to bypass the
shim is mentioned in section 4.3, API Extensions, but there is
no reference to the need for SCTP to bypass the shim, which
is not an issue for the socket API. I think that needs to
be mentioned somewhere.

> draft-ietf-shim6-hba-03.txt
>              "Hash Based Addresses (HBA)"
> 
> draft-ietf-shim6-failure-detection-08.txt
>              "Failure Detection and Locator Pair
>               Exploration Protocol for IPv6
>               Multihoming"

No substantive comments on these two.

     Brian

> These documents can be found at:
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-08.txt
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-03.txt
> 
> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt 
> 
> 
> Please review the documents carefully, and send your feedback to the 
> SHIM6 list.
> Please also indicate whether or not you believe that these documents are 
> ready to
> go to the IESG for publication as a set of Proposed Standards.
> 
> This Working Group Last Call will end in two weeks, on the 9th July 2007 at
> 1100, UTC+10
> 
>    Thanks,
> 
> 
>          Geoff & Kurtis
> 
> 
> 
> 
> 
> 
> 

Delivery-date: Mon, 09 Jul 2007 09:39:02 +0000
Date: Mon, 09 Jul 2007 19:39:16 +1000
From: Geoff Huston <[email-masked]>
To: Geoff Huston <[email-masked]>
Cc: [email-masked], [email-masked], Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>, [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

Hi,

This note concludes the working group last call on these documents.

No objections were posted to the proposed actions.

A further revision to the failure detection draft (-09) has been posted 
to the internet drafts editor based on the authors' response to comments 
posted to the working group immediately prior to the WG last call that 
have been taken on as last call comments.

The chair propose to now pass these documents to the IESG as proposed 
standards.

regards,

     Geoff and Kurtis

Geoff Huston wrote:
> Hi,
> 
> This note starts the WG Last Call for comments on the three "base" Shim6 
> documents as Proposed Standards:
> 
> draft-ietf-shim6-proto-08.txt
>              "Level 3 multihoming shim protocol"
> 
> draft-ietf-shim6-hba-03.txt
>              "Hash Based Addresses (HBA)"
> 
> draft-ietf-shim6-failure-detection-08.txt
>              "Failure Detection and Locator Pair
>               Exploration Protocol for IPv6
>               Multihoming"
> 
> These documents can be found at:
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-08.txt
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-03.txt
> 
> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt 
> 
> 
> Please review the documents carefully, and send your feedback to the 
> SHIM6 list.
> Please also indicate whether or not you believe that these documents are 
> ready to
> go to the IESG for publication as a set of Proposed Standards.
> 
> This Working Group Last Call will end in two weeks, on the 9th July 2007 at
> 1100, UTC+10
> 
>    Thanks,
> 
> 
>          Geoff & Kurtis
> 
> 
> 
> 
> 
> 

Delivery-date: Mon, 09 Jul 2007 08:09:01 +0000
Date: Mon, 09 Jul 2007 11:07:58 +0300
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: revised failure detection draft

I posted a small revision of the draft, based on Matthijs'
and Sebastien's comments. Before the draft gets posted on
the official site, the new version and diffs are available
here:

http://www.arkko.com/publications/shim6/faildet.txt
http://www.arkko.com/publications/shim6/faildetdiff.html

Jari

Delivery-date: Mon, 09 Jul 2007 07:54:16 +0000
Date: Mon, 09 Jul 2007 10:53:40 +0300
From: Jari Arkko <[email-masked]>
To: =?ISO-8859-1?Q?S�bastien_Barr�?= <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: About draft-ietf-shim6-failure-detection-07

A follow-up. Sebastien's comments have been addressed
as follows in the -09 that I will submit today:

>> 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.
>>     
>
> Right.
>   

Having thought about this again, I'm not sure there is anything we
can do with link local addresses unless we build support for recognizing
links. I'm not sure we want to do this, so I made the use of link local
addresses not allowed in Shim6.

>> 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).
>>     
>
> Right. Thanks for catching this.

Fixed in -09.

> There also are two extra STOP <timer>s
> in the state machine, stopping a timer that just timed out.
>   
Fixed.

>> 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. 
>>     
>
> reading on...
>
>   
>> 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.
>>     
>
> Very interesting case, indeed!
>
> I agree that this is a problem. I would prefer your first solution
> (or at least not changing the locator pair used for one direction,
> perhaps there was some other reason to change the other).
>   

I added some text about this (the first solution).

Jari

Delivery-date: Mon, 09 Jul 2007 07:47:27 +0000
Date: Mon, 09 Jul 2007 10:45:44 +0300
From: Jari Arkko <[email-masked]>
To: Matthijs Mekking <[email-masked]>
CC:  [email-masked]
Subject: Re: About draft-ietf-shim6-failure-detection-07

Hi Matthijs,

Thanks for your comments. Sorry for the late reply; but I have
now treated your comments as WGLC comments and addressed
them as follows:

> When I was reading the draft-ietf-shim6-failure-detection-07 again, I
> got a little confused about the probe messages. The confusion is mainly
> a result of the example scenario described in appendix A.
>
> Luckily the confusion is almost completely solved :-). However I found
> two small type mismatches (and I think were not reported yet).
>
> 1) Section 5.1 Keepalive Message (Page 15)
>
> Type
>       This field identifies the Probe message and MUST be set to 66
>       (Keepalive).
>
> This should the "This field identifies the Keepalive message".

Good catch. Fixed in -09.

> 2) Appendix A Example 5 (Page 37)
>
> The Probe id=q should report that it received probe p, not q.

Right. Fixed in -09.

> Why is in the example shown that it received payload? Should a probe
> message be able to include this information? If so, the message format
> should be changed to handle this (or can the probe data field be used
> for this?). If not, 'received payload' should be removed from the example.
This must be a remnant from an earlier revision of the probe
messages which had this ability. I removed this part from the
example.

Jari

Delivery-date: Wed, 18 Jul 2007 09:59:39 +0000
Date: Wed, 18 Jul 2007 11:57:52 +0200
From: Brian E Carpenter <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-03.txt

On 2007-07-17 22:07, marcelo bagnulo braun wrote:
> Hi Brian,
> 
> thanks for the feedback
> 
> El 17/07/2007, a las 11:59, Brian E Carpenter escribió:
> 
>> This draft looks good to me on content; the English needs a
>> check.
>>
> 
> If you could be more specific on this i could try to fix it...

I was assuming that Joe would make a pass over it as co-author;
there's nothing serious for people used to Euroenglish :-)

>> One comment:
>>
>>> 4.3.  Traffic Engineering
>> ...
>>>               There is no defined mechanism which would allow use of
>>>    the Locator Preferences option amongst a site full of hosts to be
>>>    managed centrally.
>>
>> It might be worth noting that RFC 4384 policy is also available
>> as a primitive TE tool, with at least one mechanism for site-wide
>> distribution of that policy existing in draft.
>>
> 
> ok, we can include some text about this in the next version

Thanks.

> 
> One more question: do you think we should include other sections or 
> address other issues in here? For instance, one option would be to 
> "borrow" some text on application considerations from Erik expired 
> drafts and describe the referrals, call backs and so on. Imho these are 
> interesting conclusions we achieved in this work, and i would like to 
> reflect them somewhere...

Yes, discussing referrals would be very useful IMHO. Somewhere we
had responses to all the RFC 3582 goals, and those could possibly be
useful too.

     Brian

Delivery-date: Tue, 17 Jul 2007 22:55:47 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-03.txt
Date: Tue, 17 Jul 2007 22:07:32 +0200
To: Brian E Carpenter <[email-masked]>

Hi Brian,

thanks for the feedback

El 17/07/2007, a las 11:59, Brian E Carpenter escribi�:

> This draft looks good to me on content; the English needs a
> check.
>

If you could be more specific on this i could try to fix it...

> One comment:
>
>> 4.3.  Traffic Engineering
> ...
>>               There is no defined mechanism which would allow use of
>>    the Locator Preferences option amongst a site full of hosts to be
>>    managed centrally.
>
> It might be worth noting that RFC 4384 policy is also available
> as a primitive TE tool, with at least one mechanism for site-wide
> distribution of that policy existing in draft.
>

ok, we can include some text about this in the next version

One more question: do you think we should include other sections or  
address other issues in here? For instance, one option would be to  
"borrow" some text on application considerations from Erik expired  
drafts and describe the referrals, call backs and so on. Imho these  
are interesting conclusions we achieved in this work, and i would  
like to reflect them somewhere...

Regards, marcelo

>     Brian
>

Delivery-date: Tue, 17 Jul 2007 10:02:01 +0000
Date: Tue, 17 Jul 2007 11:59:49 +0200
From: Brian E Carpenter <[email-masked]>
To: shim6-wg <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-03.txt

This draft looks good to me on content; the English needs a
check.

One comment:

> 4.3.  Traffic Engineering
...
>               There is no defined mechanism which would allow use of
>    the Locator Preferences option amongst a site full of hosts to be
>    managed centrally.

It might be worth noting that RFC 4384 policy is also available
as a primitive TE tool, with at least one mechanism for site-wide
distribution of that policy existing in draft.

     Brian

Delivery-date: Mon, 16 Jul 2007 12:10:07 +0000
Date: Mon, 16 Jul 2007 14:07:45 +0200
From: Wouter Wijngaards <[email-masked]>
To:  [email-masked]
Subject: Verification thesis online

Hi,

As you've already seen from his comments on this list Matthijs Mekking
has written a thesis at NLnet Labs on Verification and Formalization of
the Shim6 Protocol. In his thesis he uses an automated protocol verifier
(UPPAAL) to check the shim6 protocol.

As his term has ended (with an excellent grade), the thesis from
Matthijs is now available on the NLnet Labs website:
	http://www.nlnetlabs.nl/downloads/fvShim6thesis.pdf

Best regards,
   Wouter

Delivery-date: Fri, 13 Jul 2007 09:22:12 +0000
Cc: shim6-wg <[email-masked]>, RAM Mailing List <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: proxy shim with hash in upper address bits?
Date: Fri, 13 Jul 2007 11:20:06 +0200
To: marcelo bagnulo braun <[email-masked]>

On 13-jul-2007, at 11:03, marcelo bagnulo braun wrote:

>> Another, possibly even harder to solve, problem with proxy shim is  
>> what happens when a host behind the proxy want to talk to a non- 
>> shim host.

> it depends what type of idetifiers are you using

Of course, I was assuming non-routable identifiers.

>> But quite possibly, we can solve this if we can make proxy shim  
>> interoperable with a LISP-like approach. So the user of the  
>> portable space would implement a shim proxy cq ETR/ITR which would  
>> obviously be able to talk to other shim proxy/ETR/ITR devices as  
>> well as to any host that supports shim6. Hosts that don't  
>> implement shim6 would have to reach hosts behind a proxy through  
>> ETRs that are deployed by their ISPs or possibly by the sellers of  
>> the portable address space.

> how does this solve the backward compatibility problem? I mean you  
> still need to deploy ETR/ITR in the remote site, so if you do that,  
> you may well deploy any other box i.e a pproxy shim

> Bottom line: proxy shim, shim6, lisp, you-name-it, they all require  
> support from both ends involved in the communication (either host  
> or a box next to the host (proxy, TR)) (and the multihoming  
> benefits only apply to the path between the two multihoming aware  
> boxes)

Yes, this is an important limitation. With shim6 in hosts, you can  
determine if the other side supports shim6 before selecting an  
unroutable identifier, and fall back on legacy IPv6 if it doesn't,  
but then you're not multihomed for that session. With LISP et al this  
isn't possible, but the logic doesn't have to be in the hosts, so as  
long as there is a box somewhere in the path that supports the  
protocol, you're in business. The degenerative case would be where  
the encapsuating devices for site X which is reachable through ISPs A  
and B are located in the networks of A and B.

Making (proxy) shim6 and LISP interoperable helps shim6 because the  
deployment of LISP boxes means more people to talk shim6 with, and it  
helps LISP because you get to optimize paths to a much higher degree  
because this can happen at individual hosts, even ones that are not  
served by a *TR device.

Delivery-date: Fri, 13 Jul 2007 09:05:33 +0000
Cc: shim6-wg <[email-masked]>, RAM Mailing List <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: proxy shim with hash in upper address bits?
Date: Fri, 13 Jul 2007 11:03:55 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 12/07/2007, a las 23:04, Iljitsch van Beijnum escribi�:

> [crossposted, please prune as required. RAM people, please look at  
> the bottom of the message]
>
> On 11-jul-2007, at 15:23, marcelo bagnulo braun wrote:
>
>>> After reading Marcelo's draft about a proxy implementation of  
>>> shim6 a while ago I was somewhat disheartened: this is extremely  
>>> hard to do, mostly because an unsuspecting host would need to  
>>> receive an HBA-compatible address.
>
>> why do you think so?... you can deal with this doing dhcp  
>> delegation of the HBAs/CGAs? (you would be breaking stateless  
>> address autoconf, but i guess the same would happen if you need a  
>> reasonable amount of bits in the prefix to carry crypto  
>> information...)
>
> You're right, if you can get the hosts to create only HBA addresses  
> by use of DHCPv6 or some other mechanism, that would work. Note  
> thought that most of today's IPv6 hosts don't support DHCPv6  
> address assignment so this may not be a suitable solution for true  
> legacy IPv6 support.
>
> Obviously stateless autoconf would have to work with the bits in  
> the upper part of the address or this would be an exercise in  
> futility.
>
>> Yes, creating a crypto prefix for the identifier namespace would  
>> bean option for dealing with this, but i guess it would break SAA
>
> SAA?
>

stateless address auto configuration

> Another, possibly even harder to solve, problem with proxy shim is  
> what happens when a host behind the proxy want to talk to a non- 
> shim host.

it depends what type of idetifiers are you using

if you are using routable identifiers, then you don't have problem

if you are not using routble ids, then you are in trouble and  
backward compatibility woudl require either configuring routable  
address to hosts (in addition of the non routable ids) or some form  
of nat

> But quite possibly, we can solve this if we can make proxy shim  
> interoperable with a LISP-like approach. So the user of the  
> portable space would implement a shim proxy cq ETR/ITR which would  
> obviously be able to talk to other shim proxy/ETR/ITR devices as  
> well as to any host that supports shim6. Hosts that don't implement  
> shim6 would have to reach hosts behind a proxy through ETRs that  
> are deployed by their ISPs or possibly by the sellers of the  
> portable address space.

how does this solve the backward compatibility problem? I mean you  
still need to deploy ETR/ITR in the remote site, so if you do that,  
you may well deploy any other box i.e a pproxy shim

Bottom line: proxy shim, shim6, lisp, you-name-it, they all require  
support from both ends involved in the communication (either host or  
a box next to the host (proxy, TR)) (and the multihoming benefits  
only apply to the path between the two multihoming aware boxes)

Regards, marcelo

Delivery-date: Thu, 12 Jul 2007 21:07:40 +0000
Cc: shim6-wg <[email-masked]>, RAM Mailing List <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: proxy shim with hash in upper address bits?
Date: Thu, 12 Jul 2007 23:04:37 +0200
To: marcelo bagnulo braun <[email-masked]>

[crossposted, please prune as required. RAM people, please look at  
the bottom of the message]

On 11-jul-2007, at 15:23, marcelo bagnulo braun wrote:

>> After reading Marcelo's draft about a proxy implementation of  
>> shim6 a while ago I was somewhat disheartened: this is extremely  
>> hard to do, mostly because an unsuspecting host would need to  
>> receive an HBA-compatible address.

> why do you think so?... you can deal with this doing dhcp  
> delegation of the HBAs/CGAs? (you would be breaking stateless  
> address autoconf, but i guess the same would happen if you need a  
> reasonable amount of bits in the prefix to carry crypto  
> information...)

You're right, if you can get the hosts to create only HBA addresses  
by use of DHCPv6 or some other mechanism, that would work. Note  
thought that most of today's IPv6 hosts don't support DHCPv6 address  
assignment so this may not be a suitable solution for true legacy  
IPv6 support.

Obviously stateless autoconf would have to work with the bits in the  
upper part of the address or this would be an exercise in futility.

> Yes, creating a crypto prefix for the identifier namespace would  
> bean option for dealing with this, but i guess it would break SAA

SAA?

Another, possibly even harder to solve, problem with proxy shim is  
what happens when a host behind the proxy want to talk to a non-shim  
host. But quite possibly, we can solve this if we can make proxy shim  
interoperable with a LISP-like approach. So the user of the portable  
space would implement a shim proxy cq ETR/ITR which would obviously  
be able to talk to other shim proxy/ETR/ITR devices as well as to any  
host that supports shim6. Hosts that don't implement shim6 would have  
to reach hosts behind a proxy through ETRs that are deployed by their  
ISPs or possibly by the sellers of the portable address space.

Delivery-date: Wed, 11 Jul 2007 13:24:13 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: proxy shim with hash in upper address bits?
Date: Wed, 11 Jul 2007 15:23:33 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 11/07/2007, a las 12:45, Iljitsch van Beijnum escribi�:

> [catching up]
>
> After reading Marcelo's draft about a proxy implementation of shim6  
> a while ago I was somewhat disheartened: this is extremely hard to  
> do, mostly because an unsuspecting host would need to receive an  
> HBA-compatible address.
>

why do you think so?... you can deal with this doing dhcp delegation  
of the HBAs/CGAs? (you would be breaking stateless address autoconf,  
but i guess the same would happen if you need a reasonable amount of  
bits in the prefix to carry crypto information...)

> I know we had discussions in the past about putting crypto bits in  
> the _upper_ rather than the _lower_ bits of an address, which would  
> solve this problem very nicely. That would (of course) be  
> incompatible with the idea that shim6 identifiers are also PA  
> routable locators, but that's actually an advantage: by doing this  
> we'd be creating an identifier space for shim6 that's distinct from  
> regular routable address space and also from all forms of ULA.
>

Yes, creating a crypto prefix for the identifier namespace would bean  
option for dealing with this, but i guess it would break SAA

regards, marcelo

> The only problem that I see is that under the normal regime (/48  
> per site), the number of hash bits would be very limited. The only  
> way to solve that would be to annex most of the subnet bits, so we  
> can have 52 - 56 hash bits.
>
> Thoughts?
>

Delivery-date: Wed, 11 Jul 2007 12:47:37 +0000
To: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: proxy shim with hash in upper address bits?
Date: Wed, 11 Jul 2007 12:45:15 +0200

[catching up]

After reading Marcelo's draft about a proxy implementation of shim6 a  
while ago I was somewhat disheartened: this is extremely hard to do,  
mostly because an unsuspecting host would need to receive an HBA- 
compatible address.

I know we had discussions in the past about putting crypto bits in  
the _upper_ rather than the _lower_ bits of an address, which would  
solve this problem very nicely. That would (of course) be  
incompatible with the idea that shim6 identifiers are also PA  
routable locators, but that's actually an advantage: by doing this  
we'd be creating an identifier space for shim6 that's distinct from  
regular routable address space and also from all forms of ULA.

The only problem that I see is that under the normal regime (/48 per  
site), the number of hash bits would be very limited. The only way to  
solve that would be to annex most of the subnet bits, so we can have  
52 - 56 hash bits.

Thoughts?

Delivery-date: Tue, 10 Jul 2007 12:23:57 +0000
Date: Tue, 10 Jul 2007 15:21:41 +0300
From: Jari Arkko <[email-masked]>
To: Geoff Huston <[email-masked]>
CC: Brian E Carpenter <[email-masked]>,  [email-masked],  [email-masked], Iljitsch van Beijnum <[email-masked]>,  Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>,  [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

Geoff, Brian,

>>>
>>> I would like to propose that your comments are addressed in the
>>> related current SHIM6 document activity on the topic of an
>>> applicability statement, and, given that situation, there is no
>>> compelling case to revise the protocol document to include this (and
>>> related) applicability considerations.
>>
>> However, the applicability draft is not cited in the proto draft.
>> It's listed as a reference, but is not cited. That's going to
>> have to be fixed editorially anyway. I agree that the applicability
>> draft is the appropriate place to discuss this.
>
> ok - we'll do this editorially, as its not a normative issue

I agree with Brian that needs to be mentioned at
least indirectly. Adding a reference to the app note
and a few words to explain the reference would be
my preference.

But lets not revise the document because of this.
Once the ADs have the proto questionnaires in
their hands, they will start AD review and eventually
IETF Last Call and IESG review. A small edit can live
as an RFC Editor note in the tracker until we've collected
enough to warrant a new revision in one of the stages
or until the document is shipped to the RFC Editor.
Chairs, authors, can you suggest text for the new
reference so that I can place it in the tracker?

Jari

Delivery-date: Mon, 09 Jul 2007 21:46:52 +0000
Date: Tue, 10 Jul 2007 07:48:30 +1000
From: Geoff Huston <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-ietf-shim6-applicability-03.txt 

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

	Title		: Applicability Statement for the Level 3 Multihoming Shim 
Protocol (Shim6)
	Author(s)	: M. Bagnulo, J. Abley
	Filename	: draft-ietf-shim6-applicability-03.txt
	Pages		: 20
	Date		: 2007-7-9
	
This document discusses the applicability of the shim6 IPv6 protocol
    element and associated support protocols to provide site multihoming
    capabilities in IPv6.

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

Delivery-date: Mon, 09 Jul 2007 21:46:14 +0000
Date: Tue, 10 Jul 2007 07:47:23 +1000
From: Geoff Huston <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-ietf-shim6-locator-pair-selection-02.txt 

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

	Title		: Default Locator-pair selection algorithm for the SHIM6 protocol
	Author(s)	: M. Bagnulo
	Filename	: draft-ietf-shim6-locator-pair-selection-02.txt
	Pages		: 11
	Date		: 2007-7-9
	
In this note, we present a locator-pair selection mechanism for the
    shim6 protocol.  The presented mechanism provides an ordered list of
    available locator-pairs that can be used for outgoing traffic.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-locator-pair-selection-02.txt

Delivery-date: Mon, 09 Jul 2007 21:32:30 +0000
Date: Tue, 10 Jul 2007 07:33:14 +1000
From: Geoff Huston <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked], [email-masked], Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>, [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

>>
>> I would like to propose that your comments are addressed in the 
>> related current SHIM6 document activity on the topic of an 
>> applicability statement, and, given that situation, there is no 
>> compelling case to revise the protocol document to include this (and 
>> related) applicability considerations.
> 
> However, the applicability draft is not cited in the proto draft.
> It's listed as a reference, but is not cited. That's going to
> have to be fixed editorially anyway. I agree that the applicability
> draft is the appropriate place to discuss this.

ok - we'll do this editorially, as its not a normative issue

>>
>> I trust that this is an acceptable approach to this consideration to 
>> you and the WG and that we are still in a position to submit the 
>> protocol document to the IESG as a Proposed Standard.
> 
> Indeed,it isn't a normative issue.
> 
>    Brian
>>
>>
regards,

   Geoff

Delivery-date: Mon, 09 Jul 2007 11:05:57 +0000
Date: Mon, 09 Jul 2007 12:58:44 +0200
From: Brian E Carpenter <[email-masked]>
To: Geoff Huston <[email-masked]>
CC:  [email-masked],  [email-masked],  Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>,  Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>,  [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

On 2007-07-09 12:40, Geoff Huston wrote:
> Brian,
> 
> Thanks for these (ever so slightly belated) WGLC comments.

Hey, you were just trying to take unfair advantage of your time zone :-)

> Among the shim6 documents still on our agenda as a WG is the 
> applicability document. The (currently expired) draft 
> draft-ietf-shim6-applicability-02.txt includes this consideration 
> regarding SHIM6 and SCTP, and also includes applicability comments 
> relating to interaction with other protocols (section 5).
> 
> I would like to propose that your comments are addressed in the related 
> current SHIM6 document activity on the topic of an applicability 
> statement, and, given that situation, there is no compelling case to 
> revise the protocol document to include this (and related) applicability 
> considerations.

However, the applicability draft is not cited in the proto draft.
It's listed as a reference, but is not cited. That's going to
have to be fixed editorially anyway. I agree that the applicability
draft is the appropriate place to discuss this.
> 
> I trust that this is an acceptable approach to this consideration to you 
> and the WG and that we are still in a position to submit the protocol 
> document to the IESG as a Proposed Standard.

Indeed,it isn't a normative issue.

    Brian
> 
> 
> regards,
> 
>   Geoff
> 
> 
> 
> Brian E Carpenter wrote:
>> On 2007-06-25 02:25, Geoff Huston wrote:
>>> Hi,
>>>
>>> This note starts the WG Last Call for comments on the three "base" 
>>> Shim6 documents as Proposed Standards:
>>>
>>> draft-ietf-shim6-proto-08.txt
>>>              "Level 3 multihoming shim protocol"
>>
>> One substantive comment. The need for some ULPs to bypass the
>> shim is mentioned in section 4.3, API Extensions, but there is
>> no reference to the need for SCTP to bypass the shim, which
>> is not an issue for the socket API. I think that needs to
>> be mentioned somewhere.
>>
>>> draft-ietf-shim6-hba-03.txt
>>>              "Hash Based Addresses (HBA)"
>>>
>>> draft-ietf-shim6-failure-detection-08.txt
>>>              "Failure Detection and Locator Pair
>>>               Exploration Protocol for IPv6
>>>               Multihoming"
>>
>> No substantive comments on these two.
>>
>>     Brian
>>
>>> These documents can be found at:
>>>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-08.txt
>>>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-03.txt
>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt 
>>>
>>>
>>> Please review the documents carefully, and send your feedback to the 
>>> SHIM6 list.
>>> Please also indicate whether or not you believe that these documents 
>>> are ready to
>>> go to the IESG for publication as a set of Proposed Standards.
>>>
>>> This Working Group Last Call will end in two weeks, on the 9th July 
>>> 2007 at
>>> 1100, UTC+10
>>>
>>>    Thanks,
>>>
>>>
>>>          Geoff & Kurtis
>>>
>>>
>>>
>>>
>>>
>>>
>>>
> 

Delivery-date: Mon, 09 Jul 2007 10:39:44 +0000
Date: Mon, 09 Jul 2007 20:40:32 +1000
From: Geoff Huston <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked], [email-masked], Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>, [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

Brian,

Thanks for these (ever so slightly belated) WGLC comments.

Among the shim6 documents still on our agenda as a WG is the 
applicability document. The (currently expired) draft 
draft-ietf-shim6-applicability-02.txt includes this consideration 
regarding SHIM6 and SCTP, and also includes applicability comments 
relating to interaction with other protocols (section 5).

I would like to propose that your comments are addressed in the related 
current SHIM6 document activity on the topic of an applicability 
statement, and, given that situation, there is no compelling case to 
revise the protocol document to include this (and related) applicability 
considerations.

I trust that this is an acceptable approach to this consideration to you 
and the WG and that we are still in a position to submit the protocol 
document to the IESG as a Proposed Standard.

regards,

   Geoff

Brian E Carpenter wrote:
> On 2007-06-25 02:25, Geoff Huston wrote:
>> Hi,
>>
>> This note starts the WG Last Call for comments on the three "base" 
>> Shim6 documents as Proposed Standards:
>>
>> draft-ietf-shim6-proto-08.txt
>>              "Level 3 multihoming shim protocol"
> 
> One substantive comment. The need for some ULPs to bypass the
> shim is mentioned in section 4.3, API Extensions, but there is
> no reference to the need for SCTP to bypass the shim, which
> is not an issue for the socket API. I think that needs to
> be mentioned somewhere.
> 
>> draft-ietf-shim6-hba-03.txt
>>              "Hash Based Addresses (HBA)"
>>
>> draft-ietf-shim6-failure-detection-08.txt
>>              "Failure Detection and Locator Pair
>>               Exploration Protocol for IPv6
>>               Multihoming"
> 
> No substantive comments on these two.
> 
>     Brian
> 
>> These documents can be found at:
>>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-08.txt
>>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-03.txt
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt 
>>
>>
>> Please review the documents carefully, and send your feedback to the 
>> SHIM6 list.
>> Please also indicate whether or not you believe that these documents 
>> are ready to
>> go to the IESG for publication as a set of Proposed Standards.
>>
>> This Working Group Last Call will end in two weeks, on the 9th July 
>> 2007 at
>> 1100, UTC+10
>>
>>    Thanks,
>>
>>
>>          Geoff & Kurtis
>>
>>
>>
>>
>>
>>
>>

Delivery-date: Mon, 09 Jul 2007 09:58:39 +0000
Date: Mon, 09 Jul 2007 11:57:56 +0200
From: Brian E Carpenter <[email-masked]>
To: Geoff Huston <[email-masked]>
CC:  [email-masked],  [email-masked],  Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>,  Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>,  [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

On 2007-06-25 02:25, Geoff Huston wrote:
> Hi,
> 
> This note starts the WG Last Call for comments on the three "base" Shim6 
> documents as Proposed Standards:
> 
> draft-ietf-shim6-proto-08.txt
>              "Level 3 multihoming shim protocol"

One substantive comment. The need for some ULPs to bypass the
shim is mentioned in section 4.3, API Extensions, but there is
no reference to the need for SCTP to bypass the shim, which
is not an issue for the socket API. I think that needs to
be mentioned somewhere.

> draft-ietf-shim6-hba-03.txt
>              "Hash Based Addresses (HBA)"
> 
> draft-ietf-shim6-failure-detection-08.txt
>              "Failure Detection and Locator Pair
>               Exploration Protocol for IPv6
>               Multihoming"

No substantive comments on these two.

     Brian

> These documents can be found at:
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-08.txt
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-03.txt
> 
> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt 
> 
> 
> Please review the documents carefully, and send your feedback to the 
> SHIM6 list.
> Please also indicate whether or not you believe that these documents are 
> ready to
> go to the IESG for publication as a set of Proposed Standards.
> 
> This Working Group Last Call will end in two weeks, on the 9th July 2007 at
> 1100, UTC+10
> 
>    Thanks,
> 
> 
>          Geoff & Kurtis
> 
> 
> 
> 
> 
> 
> 

Delivery-date: Mon, 09 Jul 2007 09:39:02 +0000
Date: Mon, 09 Jul 2007 19:39:16 +1000
From: Geoff Huston <[email-masked]>
To: Geoff Huston <[email-masked]>
Cc: [email-masked], [email-masked], Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>, [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

Hi,

This note concludes the working group last call on these documents.

No objections were posted to the proposed actions.

A further revision to the failure detection draft (-09) has been posted 
to the internet drafts editor based on the authors' response to comments 
posted to the working group immediately prior to the WG last call that 
have been taken on as last call comments.

The chair propose to now pass these documents to the IESG as proposed 
standards.

regards,

     Geoff and Kurtis

Geoff Huston wrote:
> Hi,
> 
> This note starts the WG Last Call for comments on the three "base" Shim6 
> documents as Proposed Standards:
> 
> draft-ietf-shim6-proto-08.txt
>              "Level 3 multihoming shim protocol"
> 
> draft-ietf-shim6-hba-03.txt
>              "Hash Based Addresses (HBA)"
> 
> draft-ietf-shim6-failure-detection-08.txt
>              "Failure Detection and Locator Pair
>               Exploration Protocol for IPv6
>               Multihoming"
> 
> These documents can be found at:
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-08.txt
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-03.txt
> 
> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt 
> 
> 
> Please review the documents carefully, and send your feedback to the 
> SHIM6 list.
> Please also indicate whether or not you believe that these documents are 
> ready to
> go to the IESG for publication as a set of Proposed Standards.
> 
> This Working Group Last Call will end in two weeks, on the 9th July 2007 at
> 1100, UTC+10
> 
>    Thanks,
> 
> 
>          Geoff & Kurtis
> 
> 
> 
> 
> 
> 

Delivery-date: Mon, 09 Jul 2007 08:09:01 +0000
Date: Mon, 09 Jul 2007 11:07:58 +0300
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: revised failure detection draft

I posted a small revision of the draft, based on Matthijs'
and Sebastien's comments. Before the draft gets posted on
the official site, the new version and diffs are available
here:

http://www.arkko.com/publications/shim6/faildet.txt
http://www.arkko.com/publications/shim6/faildetdiff.html

Jari

Delivery-date: Mon, 09 Jul 2007 07:54:16 +0000
Date: Mon, 09 Jul 2007 10:53:40 +0300
From: Jari Arkko <[email-masked]>
To: =?ISO-8859-1?Q?S�bastien_Barr�?= <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: About draft-ietf-shim6-failure-detection-07

A follow-up. Sebastien's comments have been addressed
as follows in the -09 that I will submit today:

>> 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.
>>     
>
> Right.
>   

Having thought about this again, I'm not sure there is anything we
can do with link local addresses unless we build support for recognizing
links. I'm not sure we want to do this, so I made the use of link local
addresses not allowed in Shim6.

>> 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).
>>     
>
> Right. Thanks for catching this.

Fixed in -09.

> There also are two extra STOP <timer>s
> in the state machine, stopping a timer that just timed out.
>   
Fixed.

>> 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. 
>>     
>
> reading on...
>
>   
>> 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.
>>     
>
> Very interesting case, indeed!
>
> I agree that this is a problem. I would prefer your first solution
> (or at least not changing the locator pair used for one direction,
> perhaps there was some other reason to change the other).
>   

I added some text about this (the first solution).

Jari

Delivery-date: Mon, 09 Jul 2007 07:47:27 +0000
Date: Mon, 09 Jul 2007 10:45:44 +0300
From: Jari Arkko <[email-masked]>
To: Matthijs Mekking <[email-masked]>
CC:  [email-masked]
Subject: Re: About draft-ietf-shim6-failure-detection-07

Hi Matthijs,

Thanks for your comments. Sorry for the late reply; but I have
now treated your comments as WGLC comments and addressed
them as follows:

> When I was reading the draft-ietf-shim6-failure-detection-07 again, I
> got a little confused about the probe messages. The confusion is mainly
> a result of the example scenario described in appendix A.
>
> Luckily the confusion is almost completely solved :-). However I found
> two small type mismatches (and I think were not reported yet).
>
> 1) Section 5.1 Keepalive Message (Page 15)
>
> Type
>       This field identifies the Probe message and MUST be set to 66
>       (Keepalive).
>
> This should the "This field identifies the Keepalive message".

Good catch. Fixed in -09.

> 2) Appendix A Example 5 (Page 37)
>
> The Probe id=q should report that it received probe p, not q.

Right. Fixed in -09.

> Why is in the example shown that it received payload? Should a probe
> message be able to include this information? If so, the message format
> should be changed to handle this (or can the probe data field be used
> for this?). If not, 'received payload' should be removed from the example.
This must be a remnant from an earlier revision of the probe
messages which had this ability. I removed this part from the
example.

Jari

Delivery-date: Wed, 18 Jul 2007 09:59:39 +0000
Date: Wed, 18 Jul 2007 11:57:52 +0200
From: Brian E Carpenter <[email-masked]>
To: marcelo bagnulo braun <[email-masked]>
CC: shim6-wg <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-03.txt

On 2007-07-17 22:07, marcelo bagnulo braun wrote:
> Hi Brian,
> 
> thanks for the feedback
> 
> El 17/07/2007, a las 11:59, Brian E Carpenter escribió:
> 
>> This draft looks good to me on content; the English needs a
>> check.
>>
> 
> If you could be more specific on this i could try to fix it...

I was assuming that Joe would make a pass over it as co-author;
there's nothing serious for people used to Euroenglish :-)

>> One comment:
>>
>>> 4.3.  Traffic Engineering
>> ...
>>>               There is no defined mechanism which would allow use of
>>>    the Locator Preferences option amongst a site full of hosts to be
>>>    managed centrally.
>>
>> It might be worth noting that RFC 4384 policy is also available
>> as a primitive TE tool, with at least one mechanism for site-wide
>> distribution of that policy existing in draft.
>>
> 
> ok, we can include some text about this in the next version

Thanks.

> 
> One more question: do you think we should include other sections or 
> address other issues in here? For instance, one option would be to 
> "borrow" some text on application considerations from Erik expired 
> drafts and describe the referrals, call backs and so on. Imho these are 
> interesting conclusions we achieved in this work, and i would like to 
> reflect them somewhere...

Yes, discussing referrals would be very useful IMHO. Somewhere we
had responses to all the RFC 3582 goals, and those could possibly be
useful too.

     Brian

Delivery-date: Tue, 17 Jul 2007 22:55:47 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-03.txt
Date: Tue, 17 Jul 2007 22:07:32 +0200
To: Brian E Carpenter <[email-masked]>

Hi Brian,

thanks for the feedback

El 17/07/2007, a las 11:59, Brian E Carpenter escribi�:

> This draft looks good to me on content; the English needs a
> check.
>

If you could be more specific on this i could try to fix it...

> One comment:
>
>> 4.3.  Traffic Engineering
> ...
>>               There is no defined mechanism which would allow use of
>>    the Locator Preferences option amongst a site full of hosts to be
>>    managed centrally.
>
> It might be worth noting that RFC 4384 policy is also available
> as a primitive TE tool, with at least one mechanism for site-wide
> distribution of that policy existing in draft.
>

ok, we can include some text about this in the next version

One more question: do you think we should include other sections or  
address other issues in here? For instance, one option would be to  
"borrow" some text on application considerations from Erik expired  
drafts and describe the referrals, call backs and so on. Imho these  
are interesting conclusions we achieved in this work, and i would  
like to reflect them somewhere...

Regards, marcelo

>     Brian
>

Delivery-date: Tue, 17 Jul 2007 10:02:01 +0000
Date: Tue, 17 Jul 2007 11:59:49 +0200
From: Brian E Carpenter <[email-masked]>
To: shim6-wg <[email-masked]>
Subject: Re: I-D ACTION:draft-ietf-shim6-applicability-03.txt

This draft looks good to me on content; the English needs a
check.

One comment:

> 4.3.  Traffic Engineering
...
>               There is no defined mechanism which would allow use of
>    the Locator Preferences option amongst a site full of hosts to be
>    managed centrally.

It might be worth noting that RFC 4384 policy is also available
as a primitive TE tool, with at least one mechanism for site-wide
distribution of that policy existing in draft.

     Brian

Delivery-date: Mon, 16 Jul 2007 12:10:07 +0000
Date: Mon, 16 Jul 2007 14:07:45 +0200
From: Wouter Wijngaards <[email-masked]>
To:  [email-masked]
Subject: Verification thesis online

Hi,

As you've already seen from his comments on this list Matthijs Mekking
has written a thesis at NLnet Labs on Verification and Formalization of
the Shim6 Protocol. In his thesis he uses an automated protocol verifier
(UPPAAL) to check the shim6 protocol.

As his term has ended (with an excellent grade), the thesis from
Matthijs is now available on the NLnet Labs website:
	http://www.nlnetlabs.nl/downloads/fvShim6thesis.pdf

Best regards,
   Wouter

Delivery-date: Fri, 13 Jul 2007 09:22:12 +0000
Cc: shim6-wg <[email-masked]>, RAM Mailing List <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: proxy shim with hash in upper address bits?
Date: Fri, 13 Jul 2007 11:20:06 +0200
To: marcelo bagnulo braun <[email-masked]>

On 13-jul-2007, at 11:03, marcelo bagnulo braun wrote:

>> Another, possibly even harder to solve, problem with proxy shim is  
>> what happens when a host behind the proxy want to talk to a non- 
>> shim host.

> it depends what type of idetifiers are you using

Of course, I was assuming non-routable identifiers.

>> But quite possibly, we can solve this if we can make proxy shim  
>> interoperable with a LISP-like approach. So the user of the  
>> portable space would implement a shim proxy cq ETR/ITR which would  
>> obviously be able to talk to other shim proxy/ETR/ITR devices as  
>> well as to any host that supports shim6. Hosts that don't  
>> implement shim6 would have to reach hosts behind a proxy through  
>> ETRs that are deployed by their ISPs or possibly by the sellers of  
>> the portable address space.

> how does this solve the backward compatibility problem? I mean you  
> still need to deploy ETR/ITR in the remote site, so if you do that,  
> you may well deploy any other box i.e a pproxy shim

> Bottom line: proxy shim, shim6, lisp, you-name-it, they all require  
> support from both ends involved in the communication (either host  
> or a box next to the host (proxy, TR)) (and the multihoming  
> benefits only apply to the path between the two multihoming aware  
> boxes)

Yes, this is an important limitation. With shim6 in hosts, you can  
determine if the other side supports shim6 before selecting an  
unroutable identifier, and fall back on legacy IPv6 if it doesn't,  
but then you're not multihomed for that session. With LISP et al this  
isn't possible, but the logic doesn't have to be in the hosts, so as  
long as there is a box somewhere in the path that supports the  
protocol, you're in business. The degenerative case would be where  
the encapsuating devices for site X which is reachable through ISPs A  
and B are located in the networks of A and B.

Making (proxy) shim6 and LISP interoperable helps shim6 because the  
deployment of LISP boxes means more people to talk shim6 with, and it  
helps LISP because you get to optimize paths to a much higher degree  
because this can happen at individual hosts, even ones that are not  
served by a *TR device.

Delivery-date: Fri, 13 Jul 2007 09:05:33 +0000
Cc: shim6-wg <[email-masked]>, RAM Mailing List <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: proxy shim with hash in upper address bits?
Date: Fri, 13 Jul 2007 11:03:55 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 12/07/2007, a las 23:04, Iljitsch van Beijnum escribi�:

> [crossposted, please prune as required. RAM people, please look at  
> the bottom of the message]
>
> On 11-jul-2007, at 15:23, marcelo bagnulo braun wrote:
>
>>> After reading Marcelo's draft about a proxy implementation of  
>>> shim6 a while ago I was somewhat disheartened: this is extremely  
>>> hard to do, mostly because an unsuspecting host would need to  
>>> receive an HBA-compatible address.
>
>> why do you think so?... you can deal with this doing dhcp  
>> delegation of the HBAs/CGAs? (you would be breaking stateless  
>> address autoconf, but i guess the same would happen if you need a  
>> reasonable amount of bits in the prefix to carry crypto  
>> information...)
>
> You're right, if you can get the hosts to create only HBA addresses  
> by use of DHCPv6 or some other mechanism, that would work. Note  
> thought that most of today's IPv6 hosts don't support DHCPv6  
> address assignment so this may not be a suitable solution for true  
> legacy IPv6 support.
>
> Obviously stateless autoconf would have to work with the bits in  
> the upper part of the address or this would be an exercise in  
> futility.
>
>> Yes, creating a crypto prefix for the identifier namespace would  
>> bean option for dealing with this, but i guess it would break SAA
>
> SAA?
>

stateless address auto configuration

> Another, possibly even harder to solve, problem with proxy shim is  
> what happens when a host behind the proxy want to talk to a non- 
> shim host.

it depends what type of idetifiers are you using

if you are using routable identifiers, then you don't have problem

if you are not using routble ids, then you are in trouble and  
backward compatibility woudl require either configuring routable  
address to hosts (in addition of the non routable ids) or some form  
of nat

> But quite possibly, we can solve this if we can make proxy shim  
> interoperable with a LISP-like approach. So the user of the  
> portable space would implement a shim proxy cq ETR/ITR which would  
> obviously be able to talk to other shim proxy/ETR/ITR devices as  
> well as to any host that supports shim6. Hosts that don't implement  
> shim6 would have to reach hosts behind a proxy through ETRs that  
> are deployed by their ISPs or possibly by the sellers of the  
> portable address space.

how does this solve the backward compatibility problem? I mean you  
still need to deploy ETR/ITR in the remote site, so if you do that,  
you may well deploy any other box i.e a pproxy shim

Bottom line: proxy shim, shim6, lisp, you-name-it, they all require  
support from both ends involved in the communication (either host or  
a box next to the host (proxy, TR)) (and the multihoming benefits  
only apply to the path between the two multihoming aware boxes)

Regards, marcelo

Delivery-date: Thu, 12 Jul 2007 21:07:40 +0000
Cc: shim6-wg <[email-masked]>, RAM Mailing List <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: Re: proxy shim with hash in upper address bits?
Date: Thu, 12 Jul 2007 23:04:37 +0200
To: marcelo bagnulo braun <[email-masked]>

[crossposted, please prune as required. RAM people, please look at  
the bottom of the message]

On 11-jul-2007, at 15:23, marcelo bagnulo braun wrote:

>> After reading Marcelo's draft about a proxy implementation of  
>> shim6 a while ago I was somewhat disheartened: this is extremely  
>> hard to do, mostly because an unsuspecting host would need to  
>> receive an HBA-compatible address.

> why do you think so?... you can deal with this doing dhcp  
> delegation of the HBAs/CGAs? (you would be breaking stateless  
> address autoconf, but i guess the same would happen if you need a  
> reasonable amount of bits in the prefix to carry crypto  
> information...)

You're right, if you can get the hosts to create only HBA addresses  
by use of DHCPv6 or some other mechanism, that would work. Note  
thought that most of today's IPv6 hosts don't support DHCPv6 address  
assignment so this may not be a suitable solution for true legacy  
IPv6 support.

Obviously stateless autoconf would have to work with the bits in the  
upper part of the address or this would be an exercise in futility.

> Yes, creating a crypto prefix for the identifier namespace would  
> bean option for dealing with this, but i guess it would break SAA

SAA?

Another, possibly even harder to solve, problem with proxy shim is  
what happens when a host behind the proxy want to talk to a non-shim  
host. But quite possibly, we can solve this if we can make proxy shim  
interoperable with a LISP-like approach. So the user of the portable  
space would implement a shim proxy cq ETR/ITR which would obviously  
be able to talk to other shim proxy/ETR/ITR devices as well as to any  
host that supports shim6. Hosts that don't implement shim6 would have  
to reach hosts behind a proxy through ETRs that are deployed by their  
ISPs or possibly by the sellers of the portable address space.

Delivery-date: Wed, 11 Jul 2007 13:24:13 +0000
Cc: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: proxy shim with hash in upper address bits?
Date: Wed, 11 Jul 2007 15:23:33 +0200
To: Iljitsch van Beijnum <[email-masked]>

El 11/07/2007, a las 12:45, Iljitsch van Beijnum escribi�:

> [catching up]
>
> After reading Marcelo's draft about a proxy implementation of shim6  
> a while ago I was somewhat disheartened: this is extremely hard to  
> do, mostly because an unsuspecting host would need to receive an  
> HBA-compatible address.
>

why do you think so?... you can deal with this doing dhcp delegation  
of the HBAs/CGAs? (you would be breaking stateless address autoconf,  
but i guess the same would happen if you need a reasonable amount of  
bits in the prefix to carry crypto information...)

> I know we had discussions in the past about putting crypto bits in  
> the _upper_ rather than the _lower_ bits of an address, which would  
> solve this problem very nicely. That would (of course) be  
> incompatible with the idea that shim6 identifiers are also PA  
> routable locators, but that's actually an advantage: by doing this  
> we'd be creating an identifier space for shim6 that's distinct from  
> regular routable address space and also from all forms of ULA.
>

Yes, creating a crypto prefix for the identifier namespace would bean  
option for dealing with this, but i guess it would break SAA

regards, marcelo

> The only problem that I see is that under the normal regime (/48  
> per site), the number of hash bits would be very limited. The only  
> way to solve that would be to annex most of the subnet bits, so we  
> can have 52 - 56 hash bits.
>
> Thoughts?
>

Delivery-date: Wed, 11 Jul 2007 12:47:37 +0000
To: shim6-wg <[email-masked]>
From: Iljitsch van Beijnum <[email-masked]>
Subject: proxy shim with hash in upper address bits?
Date: Wed, 11 Jul 2007 12:45:15 +0200

[catching up]

After reading Marcelo's draft about a proxy implementation of shim6 a  
while ago I was somewhat disheartened: this is extremely hard to do,  
mostly because an unsuspecting host would need to receive an HBA- 
compatible address.

I know we had discussions in the past about putting crypto bits in  
the _upper_ rather than the _lower_ bits of an address, which would  
solve this problem very nicely. That would (of course) be  
incompatible with the idea that shim6 identifiers are also PA  
routable locators, but that's actually an advantage: by doing this  
we'd be creating an identifier space for shim6 that's distinct from  
regular routable address space and also from all forms of ULA.

The only problem that I see is that under the normal regime (/48 per  
site), the number of hash bits would be very limited. The only way to  
solve that would be to annex most of the subnet bits, so we can have  
52 - 56 hash bits.

Thoughts?

Delivery-date: Tue, 10 Jul 2007 12:23:57 +0000
Date: Tue, 10 Jul 2007 15:21:41 +0300
From: Jari Arkko <[email-masked]>
To: Geoff Huston <[email-masked]>
CC: Brian E Carpenter <[email-masked]>,  [email-masked],  [email-masked], Iljitsch van Beijnum <[email-masked]>,  Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>,  [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

Geoff, Brian,

>>>
>>> I would like to propose that your comments are addressed in the
>>> related current SHIM6 document activity on the topic of an
>>> applicability statement, and, given that situation, there is no
>>> compelling case to revise the protocol document to include this (and
>>> related) applicability considerations.
>>
>> However, the applicability draft is not cited in the proto draft.
>> It's listed as a reference, but is not cited. That's going to
>> have to be fixed editorially anyway. I agree that the applicability
>> draft is the appropriate place to discuss this.
>
> ok - we'll do this editorially, as its not a normative issue

I agree with Brian that needs to be mentioned at
least indirectly. Adding a reference to the app note
and a few words to explain the reference would be
my preference.

But lets not revise the document because of this.
Once the ADs have the proto questionnaires in
their hands, they will start AD review and eventually
IETF Last Call and IESG review. A small edit can live
as an RFC Editor note in the tracker until we've collected
enough to warrant a new revision in one of the stages
or until the document is shipped to the RFC Editor.
Chairs, authors, can you suggest text for the new
reference so that I can place it in the tracker?

Jari

Delivery-date: Mon, 09 Jul 2007 21:46:52 +0000
Date: Tue, 10 Jul 2007 07:48:30 +1000
From: Geoff Huston <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-ietf-shim6-applicability-03.txt 

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

	Title		: Applicability Statement for the Level 3 Multihoming Shim 
Protocol (Shim6)
	Author(s)	: M. Bagnulo, J. Abley
	Filename	: draft-ietf-shim6-applicability-03.txt
	Pages		: 20
	Date		: 2007-7-9
	
This document discusses the applicability of the shim6 IPv6 protocol
    element and associated support protocols to provide site multihoming
    capabilities in IPv6.

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

Delivery-date: Mon, 09 Jul 2007 21:46:14 +0000
Date: Tue, 10 Jul 2007 07:47:23 +1000
From: Geoff Huston <[email-masked]>
To: [email-masked]
Subject: I-D ACTION:draft-ietf-shim6-locator-pair-selection-02.txt 

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

	Title		: Default Locator-pair selection algorithm for the SHIM6 protocol
	Author(s)	: M. Bagnulo
	Filename	: draft-ietf-shim6-locator-pair-selection-02.txt
	Pages		: 11
	Date		: 2007-7-9
	
In this note, we present a locator-pair selection mechanism for the
    shim6 protocol.  The presented mechanism provides an ordered list of
    available locator-pairs that can be used for outgoing traffic.

A URL for this Internet-Draft is:
http://www.ietf.org/internet-drafts/draft-ietf-shim6-locator-pair-selection-02.txt

Delivery-date: Mon, 09 Jul 2007 21:32:30 +0000
Date: Tue, 10 Jul 2007 07:33:14 +1000
From: Geoff Huston <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked], [email-masked], Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>, [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

>>
>> I would like to propose that your comments are addressed in the 
>> related current SHIM6 document activity on the topic of an 
>> applicability statement, and, given that situation, there is no 
>> compelling case to revise the protocol document to include this (and 
>> related) applicability considerations.
> 
> However, the applicability draft is not cited in the proto draft.
> It's listed as a reference, but is not cited. That's going to
> have to be fixed editorially anyway. I agree that the applicability
> draft is the appropriate place to discuss this.

ok - we'll do this editorially, as its not a normative issue

>>
>> I trust that this is an acceptable approach to this consideration to 
>> you and the WG and that we are still in a position to submit the 
>> protocol document to the IESG as a Proposed Standard.
> 
> Indeed,it isn't a normative issue.
> 
>    Brian
>>
>>
regards,

   Geoff

Delivery-date: Mon, 09 Jul 2007 11:05:57 +0000
Date: Mon, 09 Jul 2007 12:58:44 +0200
From: Brian E Carpenter <[email-masked]>
To: Geoff Huston <[email-masked]>
CC:  [email-masked],  [email-masked],  Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>,  Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>,  [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

On 2007-07-09 12:40, Geoff Huston wrote:
> Brian,
> 
> Thanks for these (ever so slightly belated) WGLC comments.

Hey, you were just trying to take unfair advantage of your time zone :-)

> Among the shim6 documents still on our agenda as a WG is the 
> applicability document. The (currently expired) draft 
> draft-ietf-shim6-applicability-02.txt includes this consideration 
> regarding SHIM6 and SCTP, and also includes applicability comments 
> relating to interaction with other protocols (section 5).
> 
> I would like to propose that your comments are addressed in the related 
> current SHIM6 document activity on the topic of an applicability 
> statement, and, given that situation, there is no compelling case to 
> revise the protocol document to include this (and related) applicability 
> considerations.

However, the applicability draft is not cited in the proto draft.
It's listed as a reference, but is not cited. That's going to
have to be fixed editorially anyway. I agree that the applicability
draft is the appropriate place to discuss this.
> 
> I trust that this is an acceptable approach to this consideration to you 
> and the WG and that we are still in a position to submit the protocol 
> document to the IESG as a Proposed Standard.

Indeed,it isn't a normative issue.

    Brian
> 
> 
> regards,
> 
>   Geoff
> 
> 
> 
> Brian E Carpenter wrote:
>> On 2007-06-25 02:25, Geoff Huston wrote:
>>> Hi,
>>>
>>> This note starts the WG Last Call for comments on the three "base" 
>>> Shim6 documents as Proposed Standards:
>>>
>>> draft-ietf-shim6-proto-08.txt
>>>              "Level 3 multihoming shim protocol"
>>
>> One substantive comment. The need for some ULPs to bypass the
>> shim is mentioned in section 4.3, API Extensions, but there is
>> no reference to the need for SCTP to bypass the shim, which
>> is not an issue for the socket API. I think that needs to
>> be mentioned somewhere.
>>
>>> draft-ietf-shim6-hba-03.txt
>>>              "Hash Based Addresses (HBA)"
>>>
>>> draft-ietf-shim6-failure-detection-08.txt
>>>              "Failure Detection and Locator Pair
>>>               Exploration Protocol for IPv6
>>>               Multihoming"
>>
>> No substantive comments on these two.
>>
>>     Brian
>>
>>> These documents can be found at:
>>>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-08.txt
>>>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-03.txt
>>>
>>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt 
>>>
>>>
>>> Please review the documents carefully, and send your feedback to the 
>>> SHIM6 list.
>>> Please also indicate whether or not you believe that these documents 
>>> are ready to
>>> go to the IESG for publication as a set of Proposed Standards.
>>>
>>> This Working Group Last Call will end in two weeks, on the 9th July 
>>> 2007 at
>>> 1100, UTC+10
>>>
>>>    Thanks,
>>>
>>>
>>>          Geoff & Kurtis
>>>
>>>
>>>
>>>
>>>
>>>
>>>
> 

Delivery-date: Mon, 09 Jul 2007 10:39:44 +0000
Date: Mon, 09 Jul 2007 20:40:32 +1000
From: Geoff Huston <[email-masked]>
To: Brian E Carpenter <[email-masked]>
Cc: [email-masked], [email-masked], Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>, [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

Brian,

Thanks for these (ever so slightly belated) WGLC comments.

Among the shim6 documents still on our agenda as a WG is the 
applicability document. The (currently expired) draft 
draft-ietf-shim6-applicability-02.txt includes this consideration 
regarding SHIM6 and SCTP, and also includes applicability comments 
relating to interaction with other protocols (section 5).

I would like to propose that your comments are addressed in the related 
current SHIM6 document activity on the topic of an applicability 
statement, and, given that situation, there is no compelling case to 
revise the protocol document to include this (and related) applicability 
considerations.

I trust that this is an acceptable approach to this consideration to you 
and the WG and that we are still in a position to submit the protocol 
document to the IESG as a Proposed Standard.

regards,

   Geoff

Brian E Carpenter wrote:
> On 2007-06-25 02:25, Geoff Huston wrote:
>> Hi,
>>
>> This note starts the WG Last Call for comments on the three "base" 
>> Shim6 documents as Proposed Standards:
>>
>> draft-ietf-shim6-proto-08.txt
>>              "Level 3 multihoming shim protocol"
> 
> One substantive comment. The need for some ULPs to bypass the
> shim is mentioned in section 4.3, API Extensions, but there is
> no reference to the need for SCTP to bypass the shim, which
> is not an issue for the socket API. I think that needs to
> be mentioned somewhere.
> 
>> draft-ietf-shim6-hba-03.txt
>>              "Hash Based Addresses (HBA)"
>>
>> draft-ietf-shim6-failure-detection-08.txt
>>              "Failure Detection and Locator Pair
>>               Exploration Protocol for IPv6
>>               Multihoming"
> 
> No substantive comments on these two.
> 
>     Brian
> 
>> These documents can be found at:
>>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-08.txt
>>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-03.txt
>>
>> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt 
>>
>>
>> Please review the documents carefully, and send your feedback to the 
>> SHIM6 list.
>> Please also indicate whether or not you believe that these documents 
>> are ready to
>> go to the IESG for publication as a set of Proposed Standards.
>>
>> This Working Group Last Call will end in two weeks, on the 9th July 
>> 2007 at
>> 1100, UTC+10
>>
>>    Thanks,
>>
>>
>>          Geoff & Kurtis
>>
>>
>>
>>
>>
>>
>>

Delivery-date: Mon, 09 Jul 2007 09:58:39 +0000
Date: Mon, 09 Jul 2007 11:57:56 +0200
From: Brian E Carpenter <[email-masked]>
To: Geoff Huston <[email-masked]>
CC:  [email-masked],  [email-masked],  Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>,  Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>,  [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

On 2007-06-25 02:25, Geoff Huston wrote:
> Hi,
> 
> This note starts the WG Last Call for comments on the three "base" Shim6 
> documents as Proposed Standards:
> 
> draft-ietf-shim6-proto-08.txt
>              "Level 3 multihoming shim protocol"

One substantive comment. The need for some ULPs to bypass the
shim is mentioned in section 4.3, API Extensions, but there is
no reference to the need for SCTP to bypass the shim, which
is not an issue for the socket API. I think that needs to
be mentioned somewhere.

> draft-ietf-shim6-hba-03.txt
>              "Hash Based Addresses (HBA)"
> 
> draft-ietf-shim6-failure-detection-08.txt
>              "Failure Detection and Locator Pair
>               Exploration Protocol for IPv6
>               Multihoming"

No substantive comments on these two.

     Brian

> These documents can be found at:
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-08.txt
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-03.txt
> 
> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt 
> 
> 
> Please review the documents carefully, and send your feedback to the 
> SHIM6 list.
> Please also indicate whether or not you believe that these documents are 
> ready to
> go to the IESG for publication as a set of Proposed Standards.
> 
> This Working Group Last Call will end in two weeks, on the 9th July 2007 at
> 1100, UTC+10
> 
>    Thanks,
> 
> 
>          Geoff & Kurtis
> 
> 
> 
> 
> 
> 
> 

Delivery-date: Mon, 09 Jul 2007 09:39:02 +0000
Date: Mon, 09 Jul 2007 19:39:16 +1000
From: Geoff Huston <[email-masked]>
To: Geoff Huston <[email-masked]>
Cc: [email-masked], [email-masked], Jari Arkko <[email-masked]>, Iljitsch van Beijnum <[email-masked]>, Marcelo bagnulo braun <[email-masked]>, Erik Nordmark <[email-masked]>, [email-masked]
Subject: Re: Shim6 Working Group Last call on the Shim6 Document Set

Hi,

This note concludes the working group last call on these documents.

No objections were posted to the proposed actions.

A further revision to the failure detection draft (-09) has been posted 
to the internet drafts editor based on the authors' response to comments 
posted to the working group immediately prior to the WG last call that 
have been taken on as last call comments.

The chair propose to now pass these documents to the IESG as proposed 
standards.

regards,

     Geoff and Kurtis

Geoff Huston wrote:
> Hi,
> 
> This note starts the WG Last Call for comments on the three "base" Shim6 
> documents as Proposed Standards:
> 
> draft-ietf-shim6-proto-08.txt
>              "Level 3 multihoming shim protocol"
> 
> draft-ietf-shim6-hba-03.txt
>              "Hash Based Addresses (HBA)"
> 
> draft-ietf-shim6-failure-detection-08.txt
>              "Failure Detection and Locator Pair
>               Exploration Protocol for IPv6
>               Multihoming"
> 
> These documents can be found at:
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-proto-08.txt
>   http://www.ietf.org/internet-drafts/draft-ietf-shim6-hba-03.txt
> 
> http://www.ietf.org/internet-drafts/draft-ietf-shim6-failure-detection-08.txt 
> 
> 
> Please review the documents carefully, and send your feedback to the 
> SHIM6 list.
> Please also indicate whether or not you believe that these documents are 
> ready to
> go to the IESG for publication as a set of Proposed Standards.
> 
> This Working Group Last Call will end in two weeks, on the 9th July 2007 at
> 1100, UTC+10
> 
>    Thanks,
> 
> 
>          Geoff & Kurtis
> 
> 
> 
> 
> 
> 

Delivery-date: Mon, 09 Jul 2007 08:09:01 +0000
Date: Mon, 09 Jul 2007 11:07:58 +0300
From: Jari Arkko <[email-masked]>
To: shim6 <[email-masked]>
Subject: revised failure detection draft

I posted a small revision of the draft, based on Matthijs'
and Sebastien's comments. Before the draft gets posted on
the official site, the new version and diffs are available
here:

http://www.arkko.com/publications/shim6/faildet.txt
http://www.arkko.com/publications/shim6/faildetdiff.html

Jari

Delivery-date: Mon, 09 Jul 2007 07:54:16 +0000
Date: Mon, 09 Jul 2007 10:53:40 +0300
From: Jari Arkko <[email-masked]>
To: =?ISO-8859-1?Q?S�bastien_Barr�?= <[email-masked]>
CC:  [email-masked],  [email-masked]
Subject: Re: About draft-ietf-shim6-failure-detection-07

A follow-up. Sebastien's comments have been addressed
as follows in the -09 that I will submit today:

>> 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.
>>     
>
> Right.
>   

Having thought about this again, I'm not sure there is anything we
can do with link local addresses unless we build support for recognizing
links. I'm not sure we want to do this, so I made the use of link local
addresses not allowed in Shim6.

>> 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).
>>     
>
> Right. Thanks for catching this.

Fixed in -09.

> There also are two extra STOP <timer>s
> in the state machine, stopping a timer that just timed out.
>   
Fixed.

>> 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. 
>>     
>
> reading on...
>
>   
>> 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.
>>     
>
> Very interesting case, indeed!
>
> I agree that this is a problem. I would prefer your first solution
> (or at least not changing the locator pair used for one direction,
> perhaps there was some other reason to change the other).
>   

I added some text about this (the first solution).

Jari

Delivery-date: Mon, 09 Jul 2007 07:47:27 +0000
Date: Mon, 09 Jul 2007 10:45:44 +0300
From: Jari Arkko <[email-masked]>
To: Matthijs Mekking <[email-masked]>
CC:  [email-masked]
Subject: Re: About draft-ietf-shim6-failure-detection-07

Hi Matthijs,

Thanks for your comments. Sorry for the late reply; but I have
now treated your comments as WGLC comments and addressed
them as follows:

> When I was reading the draft-ietf-shim6-failure-detection-07 again, I
> got a little confused about the probe messages. The confusion is mainly
> a result of the example scenario described in appendix A.
>
> Luckily the confusion is almost completely solved :-). However I found
> two small type mismatches (and I think were not reported yet).
>
> 1) Section 5.1 Keepalive Message (Page 15)
>
> Type
>       This field identifies the Probe message and MUST be set to 66
>       (Keepalive).
>
> This should the "This field identifies the Keepalive message".

Good catch. Fixed in -09.

> 2) Appendix A Example 5 (Page 37)
>
> The Probe id=q should report that it received probe p, not q.

Right. Fixed in -09.

> Why is in the example shown that it received payload? Should a probe
> message be able to include this information? If so, the message format
> should be changed to handle this (or can the probe data field be used
> for this?). If not, 'received payload' should be removed from the example.
This must be a remnant from an earlier revision of the probe
messages which had this ability. I removed this part from the
example.

Jari