Subject: I-D ACTION:draft-ietf-shim6-proto-08.txt
From: Geoff Huston <[email-masked]>
To: [email-masked]
Date: Tue, 24 Apr 2007 09:32:03 +1000

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

	Title		: Shim6: Level 3 Multihoming Shim Protocol for IPv6
	Author(s)	: M. Bagnulo, E. Nordmark
	Filename	: draft-ietf-shim6-proto-08.txt
	Pages		: 131
	Date		: 2007-4-23
	
This document defines the Shim6 protocol, a layer 3 shim for
   providing locator agility below the transport protocols, so that
   multihoming can be provided for IPv6 with failover and load sharing
   properties, without assuming that a multihomed site will have a
   provider independent IPv6 address prefix which is announced in the
   global IPv6 routing table.  The hosts in a site which has multiple
   provider allocated IPv6 address prefixes, will use the Shim6 protocol
   specified in this document to setup state with peer hosts, so that
   the state can later be used to failover to a different locator pair,
   should the original one stop working.

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

Delivery-date: Tue, 10 Apr 2007 11:33:26 +0000
To: shim6-wg <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: proposed version 8 of the proto draft
Date: Tue, 10 Apr 2007 13:31:10 +0200

Hi all,

I have updated the protocol draft with the received comments and 
produced a version 8 of the draft

You can find it at: http://www.shim6.org/draft-ietf-shim6-proto-08.txt

The idea is submit it soon, if there are no major comments at this point
Let me know if you have some comments

Regards, marcelo

Delivery-date: Sat, 07 Apr 2007 20:01:35 +0000
Cc: "Brian E Carpenter" <[email-masked]>, "shim6-wg" <[email-masked]>, "Erik Nordmark" <[email-masked]>
From: marcelo bagnulo braun <[email-masked]>
Subject: Re: error messages and silently discarding packets
Date: Sat, 7 Apr 2007 17:36:36 +0200
To: "Henderson, Thomas R" <[email-masked]>

So, i will

- Define a Shim6 error message
- substtitute the current usage of ICMP error messages for the newly=20
defined shim6 error message
- define an error type suitable for debugging purposes (i.e. error that=20=

can be enabled for debugging but that are not normally in the protocol)
- add e new paragraph mentioning that instead of silently discarding=20
packet with error, a host can be configured to send an shim6 error=20
messages for debugging purposes

makes sense?

the plan is to submit the new version of the proto draft this week, so=20=

if you have issues with this or other comments, please comment

regards, marcelo

El 07/04/2007, a las 0:24, Henderson, Thomas R escribi=F3:

>
>
>> -----Original Message-----
>> From: marcelo bagnulo braun [mailto:[email-masked]]
>> Sent: Friday, March 30, 2007 8:44 AM
>> To: Brian E Carpenter; Erik Nordmark
>> Cc: shim6-wg
>> Subject: Re: error messages and silently discarding packets
>>
> <snip>
>>
>> So accroding to Brian's criteria, we shoudl define a shim6 error
>> message.. what do others think?
>>
>
> I posted on this a few months ago, but we decided in HIP to adopt the
> approach taken in IKE to define these messages (HIP NOTIFY similar to
> IKEv2 Notify), especially for debugging, and I don't see why shim6=20
> would
> necessarily want to take a different stance.
>
> Tom
>

Delivery-date: Fri, 06 Apr 2007 22:26:40 +0000
Content-class: urn:content-classes:message
Subject: RE: error messages and silently discarding packets
Date: Fri, 6 Apr 2007 15:24:42 -0700
From: "Henderson, Thomas R" <[email-masked]>
To: "marcelo bagnulo braun" <[email-masked]>, "Brian E Carpenter" <[email-masked]>, "Erik Nordmark" <[email-masked]>
Cc: "shim6-wg" <[email-masked]>

=20

> -----Original Message-----
> From: marcelo bagnulo braun [mailto:[email-masked]]=20
> Sent: Friday, March 30, 2007 8:44 AM
> To: Brian E Carpenter; Erik Nordmark
> Cc: shim6-wg
> Subject: Re: error messages and silently discarding packets
>
<snip>=20
>
> So accroding to Brian's criteria, we shoudl define a shim6 error=20
> message.. what do others think?
>=20

I posted on this a few months ago, but we decided in HIP to adopt the
approach taken in IKE to define these messages (HIP NOTIFY similar to
IKEv2 Notify), especially for debugging, and I don't see why shim6 would
necessarily want to take a different stance.

Tom=20

Delivery-date: Fri, 06 Apr 2007 17:54:55 +0000
Content-class: urn:content-classes:message
Subject: RE: State of play with Shim6 documents
Date: Fri, 6 Apr 2007 10:52:48 -0700
From: "Henderson, Thomas R" <[email-masked]>
To: "Erik Nordmark" <[email-masked]>
Cc: "Geoff Huston" <[email-masked]>, "shim6-wg" <[email-masked]>, <[email-masked]>

=20

> -----Original Message-----
> From: Erik Nordmark [mailto:[email-masked]]=20
> Sent: Tuesday, March 13, 2007 2:21 PM
> To: Henderson, Thomas R
> Cc: Geoff Huston; shim6-wg; [email-masked]
> Subject: Re: State of play with Shim6 documents
>=20
> Henderson, Thomas R wrote:
>=20
> > For the data plane, I understand your point that it may be=20
> moot if the
> > control plane were to be supported without modifications,=20
> if the data
> > plane could not be.  However, I was thinking that judicious=20
> use of Linux
> > netfilter could be used to insert the data plane shim.  In=20
> particular,
> > the IP6 local in and local out hooks seem well positioned=20
> in the stack
> > to support a shim6 shimming module.
>=20
> If you do that, then you could use the same hook for all the shim6=20
> messages, right?
>=20
> > My basic concern is that it would be nice to support shim6 without
> > patching the Linux kernel, for deployment/experimental=20
> purposes.  It may
> > be possible to make this work as defined now without a=20
> patched kernel.
> > I think it may require some more complicated matching rules=20
> to divert
> > shim6 control packets to user space while diverting shim6=20
> data packets
> > to a deshimming module, and making sure there is some way=20
> to inject the
> > control plane packets from user space.  I suspect it will=20
> be harder to
> > do the way it is defined, including for non-Linux systems,=20
> but perhaps
> > not impossible.
>=20
> There is a single bit in the shim6 header which says whether it is a=20
> payload message or something else. So it shouldn't be hard to have=20
> different rules.
>=20
> > Since I understand the motivation you have here, I think it would be
> > best to avoid speculating and experiment with the above to=20
> see if it can
> > work.  I'll try to get some results in the next week or two=20
> and report
> > back.
>=20

Erik,
It looks like we are able to achieve our objective of developing an
experimental shim6 implementation in Linux, with a user-space control
plane and kernel-based shimming, without patching the Linux kernel:
- shim6 control messages can be written out from user-space over IPv6
raw sockets
- shim6 control messages can be filtered and written to user-space
through a combination of ip6tables and libnetfilter_queue; the filtering
granularity can look at the shim6 P-bit
- shim6 data plane (the per-packet shim header) can be inserted and
removed via an ip6tables mangle rule (directed to a loadable kernel
module and controlled via netfilter)
- nf_conntrack can be used for connection tracking (to invoke the shim
after a certain number of packets)

The above pertains to Linux only; I haven't considered solutions for
other platforms.  Of course, on most platforms one can route all packets
through userspace where they can be filtered/touched, but there is a
performance hit when doing that.  But I don't think that having shim6 on
two protocol numbers will help that issue much anyway.

In conclusion, I don't think that it will make that big a difference
after all whether there are one or two protocol numbers, so it seems
like the firewall considerations lean towards keeping things the way
they are now.

-Tom