Subject: [shim6] next steps for the shim6 wg

From: Jari Arkko <[email-masked]>
Date: Wed, 03 Jun 2009 19:48:25 +0300

Hi,

I have finally found time to go through various pieces of input and come 
up with a suggested way forward.

I do think it would be useful to continue. But we need to make a careful 
selection for what the group should be looking at, because I'm not 
convinced that the amount of people and energy available for this is too 
big. And to be quite frank, while I get a lot of suggestions for further 
work, I have also gotten (privately) a fair number of suggestions that 
this would be a good time to close the WG. So I think we need to show 
some concrete and achievable steps in the charter.

My suggested new charter text is below -- please comment & suggest 
alternative content if needed.

The starting point for this proposal was that we have the following 
possible work:

1. implementation, testing, and deployment reports
2. API specification
3. applicability draft
4. firewall implications document
5. shim6 and 6to4 interactions; an informational document
6. network-based address pair selection preferences (i.e., provider control)
7. proxy shim6 specification
8. multipath-tcp and shim6 interactions
9. locator selection in general
10. dealing with ingress filtering issues

I believe the most useful output at this stage would be 1. Item 2 is 
fairly far along, and I have commitments from the authors to complete 
this work.

I think completing 3 would be useful as well, though I suspect it is 
going to take quite a bit of work. For instance, in the last two years 
we got quite a bit of feedback, and we also tweaked the specifications 
on a number of areas. Items 4 and 5 are small, and I think they could be 
tackled under the applicability document. Perhaps that would also 
provide some new energy to completing the applicability document.

Item 6, provider control, is interesting. But is there energy behind 
doing something?

Proxy Shim6, item 7, is a fairly big effort. It might be better dealt 
with in a group or a BOF of its own. I'm not in principle against doing 
this, however. The IETF seems to be taking on all the main approaches 
discussed in the RRG, so why not this too... but the main criteria for 
us to adopt any of these efforts has been the existence of a sufficient 
community interested in doing the work, implementing, and discussing it 
in the WG. Does this exist for Proxy Shim6? Are there implementations? 
AFAICT, there is no big enough community behind this.

The work on multipath TCP related to item 8 deserves its own working 
group, and in my opinion, should be focused on a very specific solution 
on the TCP layer and avoid any avoidable interaction with other 
components. I do believe Shim6 has a lot to give to the multipath TCP 
effort, but suspect the most useful input for that effort happens 
through re-use of concepts and algorithms. I hope the WG participants go 
to the BOF (or eventual WG) and provide input so that multipath TCP gets 
constructed correctly.

Address selection issues (item 9) are more fundamental than just about 
Shim6, and I would rather see them addressed in 6MAN, as a part of the 
current address selection improvement efforts. If that effort has not 
yet taken all Shim6 related requirements, it should. Ingress filtering 
issues (item 10) would be a high priority item, but its not clear to me 
that we have a solution that the community likes.

Given all this, my suggestion would be to do items 1 through 5 and leave 
the rest for later. This is what the charter below contains. I'm 
hesitating a bit on items 6 and 10 though. Thoughts?

Jari

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

Site Multihoming by IPv6 Intermediation (shim6)

Last Modified: 2009-06-03

Additional information is available at tools.ietf.org/wg/shim6

Chair(s):
Kurt Lindqvist <[email-masked]>
Geoff Huston <[email-masked]>

Internet Area Director(s):
Ralph Droms <[email-masked]>
Jari Arkko <[email-masked]>

Internet Area Advisor:
Jari Arkko <[email-masked]>

Technical Advisor(s):
Thomas Narten <[email-masked]>

Mailing Lists:
General Discussion: [email-masked]
To Subscribe: [email-masked]
Archive: http://ops.ietf.org/lists/shim6/

Description of Working Group:

Earlier efforts in this working group completed the Shim6 protocol
specification, documented in RFCs 5533 through 5535. This protocol is
a layer 3 shim for providing locator agility with failover
capabilities for IPv6 nodes. Hosts that employ Shim6 use multiple IPv6
address prefixes and setup state with peer hosts. This state can later
be used to failover to a different set of locators, should the
original locators stop working.

The Shim6 approach has a number of advantages, such as enabling small
sites to be multihomed without requiring a provider independent IPv6
address prefix for the site. But the approach has also been
criticized, e.g., for the operational impacts that the use of multiple
prefixes causes. At this time there is no clear view on how well Shim6
works in practice. Implementation and deployment in select networks is
needed to determine its true characteristics.

The Shim6 working group is chartered to track the implementation and
testing or deployment efforts. The group is also expected to shepherd
to completion a few remaining informational documents that complement
the existing protocol specifications.

The specific work items of the group are:

o  Write an implementation and/or deployment experience report.

o  Specify socket API extensions. This API enables interactions between
   applications and the Shim6 layer for advanced locator management,
   and access to information about failure detection and path
   exploration. It also enables some applications to turn Shim6 off.

o  Complete the work on the applicability draft. This draft explains
   in detail in which types of networks Shim6 is applicable, and
   what its advantages and disadvantages are. The draft will also
   explain how firewalls are impacted by the use of Shim6. Finally,
   the draft will also explain how Shim6 can be used in situations
   where native IPv6 connectivity is not available, such as using
   Shim6 over 6to4.

The group will also work in co-operation with the 6MAN working group
as they continue their efforts in improving IPv6 address selection
mechanisms.

The group shall not work on extensions to the Shim6 protocol itself at
this time. However, new work items can be added through rechartering
as others get completed.

Goals and Milestones:

Sep 2009  Next revision of the API document
Nov 2009  First WG draft on an implementation report
Jan 2010  Submit API document to IESG for publication as Informational RFC
Jan 2010  Next revision of the applicability document
Dec 2010  Submit implementation report to IESG for publication as 
Informational RFC
Dec 2010  Submit applicability document to IESG for publication as 
Informational RFC
Dec 2010  Close or re-charter

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 04 Jun 2009 08:07:34 +0100

Hi Jari,

I think this is very reasonable, as long as "leave the rest for later"
is not intended to prevent people producing non-WG drafts if they have
the energy to do so, or for the locator selection issues being
folded into more general work elsewhere.

    Brian

On 2009-06-03 17:48, Jari Arkko wrote:
> _______________________________________________
> shim6 mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/shim6
>

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 04 Jun 2009 09:26:04 +0200

Exactly!
this was my reading of the proposed charter as well, and i think it is 
the correct approach at this point

Regards, marcelo

---

From: Pekka Savola <[email-masked]>
Date: Thu, 4 Jun 2009 10:28:11 +0300 (EEST)

On Wed, 3 Jun 2009, Jari Arkko wrote:
> selection for what the group should be looking at, because I'm not convinced 
> that the amount of people and energy available for this is too big. And to be 
> quite frank, while I get a lot of suggestions for further work, I have also 
> gotten (privately) a fair number of suggestions that this would be a good 
> time to close the WG. So I think we need to show some concrete and achievable 
> steps in the charter.
>

I share your concerns.  If the WG is to continue, I think the outline 
you suggest is reasonable and could achieve the objectives.

> The starting point for this proposal was that we have the following possible 
> work:
>
> I believe the most useful output at this stage would be 1. Item 2 is fairly 
> far along, and I have commitments from the authors to complete this work.
>
> I think completing 3 would be useful as well, though I suspect it is going to 
> take quite a bit of work. For instance, in the last two years we got quite a 
> bit of feedback, and we also tweaked the specifications on a number of areas. 
> Items 4 and 5 are small, and I think they could be tackled under the 
> applicability document. Perhaps that would also provide some new energy to 
> completing the applicability document.
>
> Item 6, provider control, is interesting. But is there energy behind doing 
> something?
>
> Proxy Shim6, item 7, is a fairly big effort. It might be better dealt with in 
> a group or a BOF of its own. I'm not in principle against doing this, 
> however. The IETF seems to be taking on all the main approaches discussed in 
> the RRG, so why not this too... but the main criteria for us to adopt any of 
> these efforts has been the existence of a sufficient community interested in 
> doing the work, implementing, and discussing it in the WG. Does this exist 
> for Proxy Shim6? Are there implementations? AFAICT, there is no big enough 
> community behind this.
>
> The work on multipath TCP related to item 8 deserves its own working group, 
> and in my opinion, should be focused on a very specific solution on the TCP 
> layer and avoid any avoidable interaction with other components. I do believe 
> Shim6 has a lot to give to the multipath TCP effort, but suspect the most 
> useful input for that effort happens through re-use of concepts and 
> algorithms. I hope the WG participants go to the BOF (or eventual WG) and 
> provide input so that multipath TCP gets constructed correctly.
>
> Address selection issues (item 9) are more fundamental than just about Shim6, 
> and I would rather see them addressed in 6MAN, as a part of the current 
> address selection improvement efforts. If that effort has not yet taken all 
> Shim6 related requirements, it should. Ingress filtering issues (item 10) 
> would be a high priority item, but its not clear to me that we have a 
> solution that the community likes.
>
> Given all this, my suggestion would be to do items 1 through 5 and leave the 
> rest for later. This is what the charter below contains. I'm hesitating a bit 
> on items 6 and 10 though. Thoughts?
>
> Jari
>
> ----------------------
>

-- 
Pekka Savola                 "You each name yourselves king, yet the
Netcore Oy                    kingdom bleeds."
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Jun 2009 10:28:25 +0300

Brian,

> I think this is very reasonable

Thanks.

> as long as "leave the rest for later"
> the energy to do so

Of course not. Also, if there truly is good drafts and energy to do 
something additional, I'm always happy to AD sponsor RFCs. Or, if the 
existence of good work becomes obvious, we can add things to the charter.

> or for the locator selection issues being

My preference is for the locator selection work in 6MAN to be 
sufficiently general that it takes into account requirements from Shim6 
and possibly some other things as well.

Jari

---

From: Geoff Huston <[email-masked]>
Date: Thu, 4 Jun 2009 17:40:06 +1000

This looks reasonable to me.

The usual caveat applies, though - there needs to be interest to  
actually do this work. Right now there is a single API draft in the  
works, but nothing current in the other proposed areas.

This would imply that the first objective of the chairs under this  
charter would be to see what interest there is to actually do this work.

thanks,

    Geoff

On 04/06/2009, at 2:48 AM, Jari Arkko wrote:

> Hi,
>
> I have finally found time to go through various pieces of input and  
> come up with a suggested way forward.
>
> I do think it would be useful to continue. But we need to make a  
> careful selection for what the group should be looking at, because  
> I'm not convinced that the amount of people and energy available for  
> this is too big. And to be quite frank, while I get a lot of  
> suggestions for further work, I have also gotten (privately) a fair  
> number of suggestions that this would be a good time to close the  
> WG. So I think we need to show some concrete and achievable steps in  
> the charter.
>
> fairly far along, and I have commitments from the authors to  
> complete this work.
>
> going to take quite a bit of work. For instance, in the last two  
> years we got quite a bit of feedback, and we also tweaked the  
> specifications on a number of areas. Items 4 and 5 are small, and I  
> think they could be tackled under the applicability document.  
> Perhaps that would also provide some new energy to completing the  
> applicability document.
>
> Proxy Shim6, item 7, is a fairly big effort. It might be better  
> dealt with in a group or a BOF of its own. I'm not in principle  
> against doing this, however. The IETF seems to be taking on all the  
> main approaches discussed in the RRG, so why not this too... but the  
> main criteria for us to adopt any of these efforts has been the  
> existence of a sufficient community interested in doing the work,  
> implementing, and discussing it in the WG. Does this exist for Proxy  
> Shim6? Are there implementations? AFAICT, there is no big enough  
> community behind this.
>
> group, and in my opinion, should be focused on a very specific  
> solution on the TCP layer and avoid any avoidable interaction with  
> other components. I do believe Shim6 has a lot to give to the  
> multipath TCP effort, but suspect the most useful input for that  
> effort happens through re-use of concepts and algorithms. I hope the  
> WG participants go to the BOF (or eventual WG) and provide input so  
> that multipath TCP gets constructed correctly.
>
> Address selection issues (item 9) are more fundamental than just  
> about Shim6, and I would rather see them addressed in 6MAN, as a  
> part of the current address selection improvement efforts. If that  
> effort has not yet taken all Shim6 related requirements, it should.  
> Ingress filtering issues (item 10) would be a high priority item,  
> but its not clear to me that we have a solution that the community  
> likes.
>
> Given all this, my suggestion would be to do items 1 through 5 and  
> leave the rest for later. This is what the charter below contains.  
> I'm hesitating a bit on items 6 and 10 though. Thoughts?
>
> Jari
>
> ----------------------
>

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 04 Jun 2009 09:54:09 +0200

Geoff,

> works, but nothing current in the other proposed areas.

...

> On 04/06/2009, at 2:48 AM, Jari Arkko wrote:

...

>> 1. implementation, testing, and deployment reports

For this, Sébastien Barré wrote a detailed implementation report that
describes his choices in implementing shim6 in the Linux kernel

http://tools.ietf.org/html/draft-barre-shim6-impl-02

Sébastien's implementation is freely available and can be used for
testing and deployment efforts. We would be happy to collaborate with
such efforts. Same for interoperability testing with other mature
implementations.

Olivier

-- 
http://inl.info.ucl.ac.be , UCLouvain, Belgium

---

From: Jari Arkko <[email-masked]>
Date: Thu, 04 Jun 2009 10:55:49 +0300

Is Sebastien interested in completing the implementation report as an 
RFC, or as a part of an RFC?

Jari

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 04 Jun 2009 09:57:07 +0200

Jari,
> RFC, or as a part of an RFC?

Yes, of course

Olivier

---

From: marcelo bagnulo braun <[email-masked]>
Date: Thu, 04 Jun 2009 09:57:31 +0200

Hi,

we do have an applicability draft already as well that i can update.

Regards, marcelo

Geoff Huston escribió:
>> number of suggestions that this would be a good time to close the WG. 
>> So I think we need to show some concrete and achievable steps in the 
>> charter.
>>
>> think they could be tackled under the applicability document. Perhaps 
>> that would also provide some new energy to completing the 
>> applicability document.
>>
>> with in a group or a BOF of its own. I'm not in principle against 
>> doing this, however. The IETF seems to be taking on all the main 
>> approaches discussed in the RRG, so why not this too... but the main 
>> criteria for us to adopt any of these efforts has been the existence 
>> of a sufficient community interested in doing the work, implementing, 
>> and discussing it in the WG. Does this exist for Proxy Shim6? Are 
>> there implementations? AFAICT, there is no big enough community 
>> behind this.
>>
>> about Shim6, and I would rather see them addressed in 6MAN, as a part 
>> of the current address selection improvement efforts. If that effort 
>> has not yet taken all Shim6 related requirements, it should. Ingress 
>> filtering issues (item 10) would be a high priority item, but its not 
>> clear to me that we have a solution that the community likes.
>>

---

From: Sébastien Barré <[email-masked]>
Date: Fri, 05 Jun 2009 12:01:10 +0200

Hi,

As explained by Olivier. I can use my current implementation report 
draft as a starting point for this work.
Currently the structure of the impl report is to list in details Shim6 
features, and check which of them are implemented in the latest LinShim6 
version.

Based on comments on this mailing list, I can update the format so that 
it fits better with a "standard" implementation report. If other mature 
implementations are available, they can be added to the draft. Beside 
LinShim6 which I authored, I only know about the Boeing implementation, 
which does not support the security stuff, though (HBA/CGA).

regards,

Sébastien.

-- 
Sébastien Barré
Researcher,
CSE department, UCLouvain, Belgium
http://inl.info.ucl.ac.be/sbarre

---

From: Jari Arkko <[email-masked]>
Date: Fri, 05 Jun 2009 13:13:24 +0300

Sébastien,

This all sounds good. It would also be great if you could add 
"experience" type information, e.g., comment on things that were not 
easy to implement, point out bugs that were found in the specifications, 
indicate problems that you've had when turning Shim6 on for test 
traffic, etc. In other words, data that would help us improve the 
specifications later. Or information that helps people to determine how 
easy or hard Shim6 in general is to implement and use.

Jari

---

From: Olivier Bonaventure <[email-masked]>
Date: Thu, 04 Jun 2009 09:48:39 +0200

Geoff,

...

...

Olivier

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Mon, 8 Jun 2009 08:26:09 -0700

> -----Original Message-----
> From: Sébastien Barré [mailto:[email-masked]] 
> Sent: Friday, June 05, 2009 3:01 AM
> To: Jari Arkko
> Cc: [email-masked]; [email-masked]
> Subject: Re: [shim6] next steps for the shim6 wg
> 
> Hi,
> 

Hi, we've previously published our shim6 documentation at this site:
http://www.openhip.org/docs/shim6.html
and code here:
http://sourceforge.net/project/showfiles.php?group_id=132288
in case this information can be of any use to the implementation report.  
We haven't been actively working on shim6 for over a year, though. 
Sebastien is right that we did not implement HBA/CGA but rather focused
on the multihoming and REAP behavior and how it might tie into HIP.

Regards,
Tom