|
Replies:
30
-
Last Post:
Jul 15, 2009 11:37 AM
by: seb
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
[clearview-discuss] Clearview IP Tunneling design document update
Posted:
Jun 29, 2009 11:42 AM
|
|
I've completed the (hopefully) final updates to the IP Tunneling design
prior to going to PSARC. The most significant addition to the document
since it was last reviewed is the addition of a section describing the
interaction with zones (section 10).
The document has also undergone overall house-keeping to bring it up to
date with the implementation.
http://www.opensolaris.org/os/project/clearview/iptun/iptun-design.pdf
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
Posts:
439
From:
PL
Registered:
11/17/06
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jun 30, 2009 8:50 AM
in response to: seb
|
|
Hi Seb,
The link is broken.
On Mon, Jun 29, 2009 at 8:42 PM, Sebastien Roy<Sebastien dot Roy at sun dot com> wrote:
> I've completed the (hopefully) final updates to the IP Tunneling design
> prior to going to PSARC. The most significant addition to the document
> since it was last reviewed is the addition of a section describing the
> interaction with zones (section 10).
>
> The document has also undergone overall house-keeping to bring it up to
> date with the implementation.
>
> http://www.opensolaris.org/os/project/clearview/iptun/iptun-design.pdf
>
> -Seb
>
>
>
> _________________________________
> clearview-discuss mailing list
> clearview-discuss at opensolaris dot org
>
--
Piotr Jasiukajtis | estibi | SCA OS0072
http://estseg.blogspot.com
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jun 30, 2009 8:54 AM
in response to: estibi
|
|
On Tue, 2009-06-30 at 17:50 +0200, Piotr Jasiukajtis wrote:
> Hi Seb,
>
> The link is broken.
Thanks; this is something that I have no control over, it seems.
opensolaris.org simply dropped all of our project attachments. I'm
trying to see what the problem is.
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,046
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 1, 2009 1:36 PM
in response to: seb
|
|
> I've completed the (hopefully) final updates to the IP Tunneling design
> prior to going to PSARC. The most significant addition to the document
> since it was last reviewed is the addition of a section describing the
> interaction with zones (section 10).
>
> The document has also undergone overall house-keeping to bring it up to
> date with the implementation.
>
> http://www.opensolaris.org/os/project/clearview/iptun/iptun-design.pdf
Seb,
This document is superb. I have some nits to pass along later, but one
thing I wanted to understand better up-front is the need for the special
handling of ip*.tun* in the kernel. Specifically, could you explain why
this needs to be specially handled by the kernel, rather than just
requiring ifconfig to issue the appropriate libdladm calls to create the
tunnels on behalf of the administrator? Seems like that'd be simpler and
would provide compatibility (I don't see a strong need for the special
destroy-when-not-in-use semantics either -- but if we do need such a
beast, there should probably be some way to observe that the tunnel has
that semantic with show-iptun).
--
meem
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 1, 2009 2:10 PM
in response to: meem
|
|
On Wed, 2009-07-01 at 13:36 -0700, Peter Memishian wrote:
> > http://www.opensolaris.org/os/project/clearview/iptun/iptun-design.pdf
>
> Seb,
>
> This document is superb.
Thanks.
> I have some nits to pass along later, but one
> thing I wanted to understand better up-front is the need for the special
> handling of ip*.tun* in the kernel. Specifically, could you explain why
> this needs to be specially handled by the kernel, rather than just
> requiring ifconfig to issue the appropriate libdladm calls to create the
> tunnels on behalf of the administrator?
The main reason for this is that ifconfig doesn't have the proper
context to delete tunnels that it would implicitly create. The
unplumbing of the last IP interface over an implicitly created tunnel
would be the context in which ifconfig could delete such a tunnel, but
other applications (wireshark for example) could still have the tunnel
link open. Since one cannot delete an open link, the deletion would not
be possible in such a scenario.
The existing link reference counts in dls's dls_devnet_t make this quite
simple to implement there, and simplicity was one of the reasons I
decided to place this in the kernel (in the exact same place that
implicit VLAN creation used to be in fact). It's a few dozen lines of
code.
> Seems like that'd be simpler and
> would provide compatibility (I don't see a strong need for the special
> destroy-when-not-in-use semantics either -- but if we do need such a
> beast, there should probably be some way to observe that the tunnel has
> that semantic with show-iptun).
I view the destroy-when-not-in-use semantics as valuable for existing
deployments of tunnel concentrators such as VPN servers, where large
numbers of ephemeral tunnels are created and destroyed. I don't believe
that having the superset of all tunnels ever created using up system
resources is optimal when only a fraction of them are actually plumbed.
Observability of implicitly created tunnels would be a good idea. I
could add a FLAGS column to the show-iptun output. For example:
bash-3.2# dladm show-iptun
LINK TYPE SOURCE DESTINATION FLAGS
ip.6to4tun0 6to4 10.8.57.240 -- i
othertunnel3 ipv4 11.0.0.1 12.0.0.2 -
The "implicit" flag could simply be a parameter passed in at creation
time for the sole purpose of observability. Thoughts?
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,046
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 1, 2009 2:32 PM
in response to: seb
|
|
> The main reason for this is that ifconfig doesn't have the proper
> context to delete tunnels that it would implicitly create. The
> unplumbing of the last IP interface over an implicitly created tunnel
> would be the context in which ifconfig could delete such a tunnel, but
> other applications (wireshark for example) could still have the tunnel
> link open. Since one cannot delete an open link, the deletion would not
> be possible in such a scenario.
>
> The existing link reference counts in dls's dls_devnet_t make this quite
> simple to implement there, and simplicity was one of the reasons I
> decided to place this in the kernel (in the exact same place that
> implicit VLAN creation used to be in fact). It's a few dozen lines of
> code.
I'm less worried about the complexity of the current codebase and more
worried about the long-term effects of having two different contexts in
which tunnels are created and destroyed. This sort of divergence tends to
become a thorn in the side of future development and maintenance.
> I view the destroy-when-not-in-use semantics as valuable for existing
> deployments of tunnel concentrators such as VPN servers, where large
> numbers of ephemeral tunnels are created and destroyed. I don't believe
> that having the superset of all tunnels ever created using up system
> resources is optimal when only a fraction of them are actually plumbed.
If it's generally valuable then it shouldn't be buried in a bit of
backward compatibility, but rather a first-class part of the
administrative story.
--
meem
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 1, 2009 7:31 PM
in response to: meem
|
|
On Wed, 2009-07-01 at 14:32 -0700, Peter Memishian wrote:
> > The main reason for this is that ifconfig doesn't have the proper
> > context to delete tunnels that it would implicitly create. The
> > unplumbing of the last IP interface over an implicitly created tunnel
> > would be the context in which ifconfig could delete such a tunnel, but
> > other applications (wireshark for example) could still have the tunnel
> > link open. Since one cannot delete an open link, the deletion would not
> > be possible in such a scenario.
> >
> > The existing link reference counts in dls's dls_devnet_t make this quite
> > simple to implement there, and simplicity was one of the reasons I
> > decided to place this in the kernel (in the exact same place that
> > implicit VLAN creation used to be in fact). It's a few dozen lines of
> > code.
>
> I'm less worried about the complexity of the current codebase and more
> worried about the long-term effects of having two different contexts in
> which tunnels are created and destroyed. This sort of divergence tends to
> become a thorn in the side of future development and maintenance.
I can't disagree with that. It sounds like you're more weary of
maintaining an implicit tunnel creation model than you are about where
it lives (dls_mgmt.c vs ifconfig.c). An implicit IP tunnel model brings
the same set of thorns that the old implicit VLAN model had before it
was yanked out. As I try to explain below, the requirements are
slightly different for IP tunnels.
> > I view the destroy-when-not-in-use semantics as valuable for existing
> > deployments of tunnel concentrators such as VPN servers, where large
> > numbers of ephemeral tunnels are created and destroyed. I don't believe
> > that having the superset of all tunnels ever created using up system
> > resources is optimal when only a fraction of them are actually plumbed.
>
> If it's generally valuable then it shouldn't be buried in a bit of
> backward compatibility, but rather a first-class part of the
> administrative story.
I'm not saying that it's generally valuable. What I'm trying to say is
that given that we have to keep the existing wart of an administrative
interface that is implicit tunnel creation, it is valuable to have
implicit tunnel destruction to keep existing deployments from exhibiting
strange side-effects.
We want people to move away from the implicit tunnel creation (and thus
implicit destruction) administrative model, and toward explicit use of
dladm. In fact, I'd really like to remove implicit tunnel creation and
require people to use dladm to explicitly create and delete tunnels.
This is the path that Crossbow took with VLANs, and that was mostly
acceptable assuming that configuration was done using /etc/hostname*
files that could easily be converted to persistent link configuration.
Unfortunately, existing tunnel deployments are different. There is
evidence of user scripts that create tunnels on the fly using ifconfig,
and so requiring them to modify their scripts would be more risky.
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,046
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 1, 2009 10:11 PM
in response to: seb
|
|
> I can't disagree with that. It sounds like you're more weary of
> maintaining an implicit tunnel creation model than you are about where
> it lives (dls_mgmt.c vs ifconfig.c).
To some degree. In general, userland is less constrained and thus having
compatibility code there imposes less of a burden on future work. I agree
that if we need to have implicit destruction then userland is off the table.
> > If it's generally valuable then it shouldn't be buried in a bit of
> > backward compatibility, but rather a first-class part of the
> > administrative story.
>
> I'm not saying that it's generally valuable. What I'm trying to say is
> that given that we have to keep the existing wart of an administrative
> interface that is implicit tunnel creation, it is valuable to have
> implicit tunnel destruction to keep existing deployments from exhibiting
> strange side-effects.
>
> We want people to move away from the implicit tunnel creation (and thus
> implicit destruction) administrative model, and toward explicit use of
> dladm. In fact, I'd really like to remove implicit tunnel creation and
> require people to use dladm to explicitly create and delete tunnels.
> This is the path that Crossbow took with VLANs, and that was mostly
> acceptable assuming that configuration was done using /etc/hostname*
> files that could easily be converted to persistent link configuration.
> Unfortunately, existing tunnel deployments are different. There is
> evidence of user scripts that create tunnels on the fly using ifconfig,
> and so requiring them to modify their scripts would be more risky.
We have evidence of such things beyond punchin? If so, that seems a more
compelling case for having such support -- though ipadm may well obsolete
/etc/hostname.* before Nevada sees the light of day.
--
meem
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
595
From:
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design
document update
Posted:
Jul 2, 2009 6:10 AM
in response to: meem
|
|
> We have evidence of such things beyond punchin? If so, that seems a more
> compelling case for having such support -- though ipadm may well obsolete
> /etc/hostname.* before Nevada sees the light of day.
Yes, explicit tunnel creation is the much cleaner model that fits more
naturally with other features like vanity naming and the layered *adm
model.
I've not read the design doc yet, but how does clearview iptun retrofit
the implicit tunnel creation? My understanding was that this, in effect,
does the equivalent of "dladm create-iptun -t ... ip.tun0". Is that
correct, or is there something more?
--Sowmini
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 2, 2009 6:54 AM
in response to: sowmini
|
|
On Thu, 2009-07-02 at 09:10 -0400, Sowmini dot Varadhan at Sun dot COM wrote:
> > We have evidence of such things beyond punchin? If so, that seems a more
> > compelling case for having such support -- though ipadm may well obsolete
> > /etc/hostname.* before Nevada sees the light of day.
>
> Yes, explicit tunnel creation is the much cleaner model that fits more
> naturally with other features like vanity naming and the layered *adm
> model.
Right, and no-one is disputing that.
> I've not read the design doc yet, but how does clearview iptun retrofit
> the implicit tunnel creation? My understanding was that this, in effect,
> does the equivalent of "dladm create-iptun -t ... ip.tun0". Is that
> correct, or is there something more?
That's in effect what implicit creation does, and there's also the
implicit destruction that happens when the last reference goes away.
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 2, 2009 6:58 AM
in response to: meem
|
|
On Wed, 2009-07-01 at 22:11 -0700, Peter Memishian wrote:
> > We want people to move away from the implicit tunnel creation (and thus
> > implicit destruction) administrative model, and toward explicit use of
> > dladm. In fact, I'd really like to remove implicit tunnel creation and
> > require people to use dladm to explicitly create and delete tunnels.
> > This is the path that Crossbow took with VLANs, and that was mostly
> > acceptable assuming that configuration was done using /etc/hostname*
> > files that could easily be converted to persistent link configuration.
> > Unfortunately, existing tunnel deployments are different. There is
> > evidence of user scripts that create tunnels on the fly using ifconfig,
> > and so requiring them to modify their scripts would be more risky.
>
> We have evidence of such things beyond punchin? If so, that seems a more
> compelling case for having such support -- though ipadm may well obsolete
> /etc/hostname.* before Nevada sees the light of day.
We do; in speaking with Dan McDonald and Paul Wernau, there are
customers who build IPsec appliances who have embedded use of ifconfig
to create tunnels. Paul also has experience with several support cases
where customers were using ifconfig this way.
This isn't to say that customers wouldn't be willing to modify their
scripts to adapt to a new administrative model. Rather, it would be a
more risky proposition than offering them full backward compatibility
along with a transition path to a better model.
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
595
From:
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design
document update
Posted:
Jul 2, 2009 7:32 AM
in response to: seb
|
|
On (07/02/09 09:58), Sebastien Roy wrote:
> We do; in speaking with Dan McDonald and Paul Wernau, there are
> customers who build IPsec appliances who have embedded use of ifconfig
> to create tunnels. Paul also has experience with several support cases
> where customers were using ifconfig this way.
How do these customers achieve persistence? do they have their own
database that tells them what to restore?
--Sowmini
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 2, 2009 7:50 AM
in response to: sowmini
|
|
On Thu, 2009-07-02 at 10:32 -0400, Sowmini dot Varadhan at Sun dot COM wrote:
> On (07/02/09 09:58), Sebastien Roy wrote:
> > We do; in speaking with Dan McDonald and Paul Wernau, there are
> > customers who build IPsec appliances who have embedded use of ifconfig
> > to create tunnels. Paul also has experience with several support cases
> > where customers were using ifconfig this way.
>
> How do these customers achieve persistence? do they have their own
> database that tells them what to restore?
Maybe, but I believe that this question is somewhat irrelevant. Think
of a VPN server. A protocol signals the server that a tunnel needs to
be created (a client wishes access to the private network), and the
server creates one on the fly according to whatever parameters it needs
(perhaps from a database, or perhaps as part of the VPN protocol). The
source of the tunnel creation parameters in this case is mostly
irrelevant (and it's definitely not /etc/hostname.<blablabla>); the
important piece of data is that ifconfig is used on-demand to create
tunnels.
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
595
From:
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design
document update
Posted:
Jul 2, 2009 8:15 AM
in response to: seb
|
|
On (07/02/09 10:50), Sebastien Roy wrote:
>
> On Thu, 2009-07-02 at 10:32 -0400, Sowmini dot Varadhan at Sun dot COM wrote:
> > On (07/02/09 09:58), Sebastien Roy wrote:
> > > We do; in speaking with Dan McDonald and Paul Wernau, there are
> > > customers who build IPsec appliances who have embedded use of ifconfig
> > > to create tunnels. Paul also has experience with several support cases
> > > where customers were using ifconfig this way.
> >
> > How do these customers achieve persistence? do they have their own
> > database that tells them what to restore?
>
> Maybe, but I believe that this question is somewhat irrelevant. Think
actually I wasn't suggesting anything, I was asking :-).
and I think we are focussing on different problems... but if
they use /etc/hostname* for persistence, then the logical method to translate
that to the *adm model is to split the /etc/hostname information into
persistent dladm and ipadm persistent config information
yes, I agree that there is some value to letting ifconfig itself invoke
libdladm to create the tunnel (which is what you are focussing on, I believe)
--Sowmini
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 2, 2009 8:46 AM
in response to: sowmini
|
|
On Thu, 2009-07-02 at 11:15 -0400, Sowmini dot Varadhan at Sun dot COM wrote:
> On (07/02/09 10:50), Sebastien Roy wrote:
> >
> > On Thu, 2009-07-02 at 10:32 -0400, Sowmini dot Varadhan at Sun dot COM wrote:
> > > On (07/02/09 09:58), Sebastien Roy wrote:
> > > > We do; in speaking with Dan McDonald and Paul Wernau, there are
> > > > customers who build IPsec appliances who have embedded use of ifconfig
> > > > to create tunnels. Paul also has experience with several support cases
> > > > where customers were using ifconfig this way.
> > >
> > > How do these customers achieve persistence? do they have their own
> > > database that tells them what to restore?
> >
> > Maybe, but I believe that this question is somewhat irrelevant. Think
>
> actually I wasn't suggesting anything, I was asking :-).
> and I think we are focussing on different problems...
Understood.
> but if
> they use /etc/hostname* for persistence, then the logical method to translate
> that to the *adm model is to split the /etc/hostname information into
> persistent dladm and ipadm persistent config information
Right, I understand that. I implied the same a few messages ago in a
response to Meem when I said:
"In fact, I'd really like to remove implicit tunnel creation and
require people to use dladm to explicitly create and delete tunnels.
This is the path that Crossbow took with VLANs, and that was mostly
acceptable assuming that configuration was done using /etc/hostname*
files that could easily be converted to persistent link configuration.
Unfortunately, existing tunnel deployments are different. There is
evidence of user scripts that create tunnels on the fly using ifconfig,
and so requiring them to modify their scripts would be more risky."
It is a given, however, that there are customers who don't
use /etc/hostname* for persistence, or have no requirements for
persistence at all (all configuration parameters come from the ether and
all objects created are temporary).
> yes, I agree that there is some value to letting ifconfig itself invoke
> libdladm to create the tunnel (which is what you are focussing on, I believe)
Almost; the design calls for implicit creation and destruction, which
means that ifconfig can't be involved. The kernel creates tunnels
implicitly while processing the open system call in the /dev/net code
(like implicit VLANs used to be created). What ifconfig _does_ have,
however, is support for the "tsrc" and "tdst" keywords (and hoplimit and
encapsulation limit keywords). Sections 5 and 8.2 of the design
document discuss this in more detail.
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,046
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 2, 2009 11:05 AM
in response to: seb
|
|
> > > We want people to move away from the implicit tunnel creation (and thus
> > > implicit destruction) administrative model, and toward explicit use of
> > > dladm. In fact, I'd really like to remove implicit tunnel creation and
> > > require people to use dladm to explicitly create and delete tunnels.
> > > This is the path that Crossbow took with VLANs, and that was mostly
> > > acceptable assuming that configuration was done using /etc/hostname*
> > > files that could easily be converted to persistent link configuration.
> > > Unfortunately, existing tunnel deployments are different. There is
> > > evidence of user scripts that create tunnels on the fly using ifconfig,
> > > and so requiring them to modify their scripts would be more risky.
> >
> > We have evidence of such things beyond punchin? If so, that seems a more
> > compelling case for having such support -- though ipadm may well obsolete
> > /etc/hostname.* before Nevada sees the light of day.
>
> We do; in speaking with Dan McDonald and Paul Wernau, there are
> customers who build IPsec appliances who have embedded use of ifconfig
> to create tunnels. Paul also has experience with several support cases
> where customers were using ifconfig this way.
Fair enough.
Your proposal for indicating implicit tunnels seems fine.
--
meem
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 2, 2009 2:45 PM
in response to: meem
|
|
On Thu, 2009-07-02 at 11:05 -0700, Peter Memishian wrote:
> Your proposal for indicating implicit tunnels seems fine.
>
Great. On that note, I've updated the document to describe the new
FLAGS field. I took the liberty of also defining an "IPsec policy
present" flag as it is generally useful to know whether or not IPsec
policy applies to a given tunnel link. See section 4.1.4 of the updated
doc:
http://www.opensolaris.org/os/project/clearview/iptun/iptun-design.pdf
Here are the example from that section:
# dladm show-iptun
LINK TYPE SOURCE DESTINATION FLAGS
vpn0 ipv4 63.1.2.3 192.4.5.6 s-
ipv6router0 6to4 63.4.5.6 -- --
ipv6site2 ipv6 2001:db8:feed::1234 2001:db8:beef::4321 --
ip.tun0 ipv4 10.0.0.1 10.0.0.2 -i
# dladm show-iptun vpn0
LINK TYPE SOURCE DESTINATION FLAGS
vpn0 ipv4 63.1.2.3 192.4.5.6 s-
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,046
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 2, 2009 2:51 PM
in response to: seb
|
|
> Great. On that note, I've updated the document to describe the new
> FLAGS field. I took the liberty of also defining an "IPsec policy
> present" flag as it is generally useful to know whether or not IPsec
> policy applies to a given tunnel link. See section 4.1.4 of the updated
> doc:
>
> http://www.opensolaris.org/os/project/clearview/iptun/iptun-design.pdf
>
> Here are the example from that section:
A nit, but it might be good to move the FLAGS field to be after TYPE so
that long IPv6 addresses in DESTINATION can just flow past the 80-column
boundary.
> # dladm show-iptun
> LINK TYPE SOURCE DESTINATION FLAGS
> vpn0 ipv4 63.1.2.3 192.4.5.6 s-
> ipv6router0 6to4 63.4.5.6 -- --
> ipv6site2 ipv6 2001:db8:feed::1234 2001:db8:beef::4321 --
> ip.tun0 ipv4 10.0.0.1 10.0.0.2 -i
> # dladm show-iptun vpn0
> LINK TYPE SOURCE DESTINATION FLAGS
> vpn0 ipv4 63.1.2.3 192.4.5.6 s-
--
meem
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 2, 2009 4:38 PM
in response to: meem
|
|
On Thu, 2009-07-02 at 14:51 -0700, Peter Memishian wrote:
> > Great. On that note, I've updated the document to describe the new
> > FLAGS field. I took the liberty of also defining an "IPsec policy
> > present" flag as it is generally useful to know whether or not IPsec
> > policy applies to a given tunnel link. See section 4.1.4 of the updated
> > doc:
> >
> > http://www.opensolaris.org/os/project/clearview/iptun/iptun-design.pdf
> >
> > Here are the example from that section:
>
> A nit, but it might be good to move the FLAGS field to be after TYPE so
> that long IPv6 addresses in DESTINATION can just flow past the 80-column
> boundary.
Good suggestion; done.
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
595
From:
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design
document update
Posted:
Jul 3, 2009 5:01 AM
in response to: seb
|
|
On (07/02/09 17:45), Sebastien Roy wrote:
>
> http://www.opensolaris.org/os/project/clearview/iptun/iptun-design.pdf
A few comments/questions:
- Editorial- Section 3: does ifconfig really push tun on top of /dev/ip?
seems like only 6to4relay does this. This paragraph needs to be updated.
(the dlpi_open magic is explained in a later section)
- page 5, 34: if the tsrc (link layer src of the tunnel) is
administratively brought down or deleted, what happens to the tunnel?
(I would expect that it would get marked !RUNNING)
Also, what happens with nested tunnels (i.e., if the tsrc of a tunnel
is itself another tunnels IP src)- the order of bringing them up
seems to matter.. would be nicer if the successful plumb/up of an interface
could go and enable any tunnels that depend on that interface (and the
converse for down/unplumb)
- nit: why the itp_* prefix? shouldn't this be ipt_*? e.g.,
it's a bit confusing to see itp_type values of IPTUN_TYPE*
--Sowmini
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 3, 2009 7:07 AM
in response to: sowmini
|
|
On Fri, 2009-07-03 at 08:01 -0400, Sowmini dot Varadhan at Sun dot COM wrote:
> On (07/02/09 17:45), Sebastien Roy wrote:
> >
> > http://www.opensolaris.org/os/project/clearview/iptun/iptun-design.pdf
>
> A few comments/questions:
>
> - Editorial- Section 3: does ifconfig really push tun on top of /dev/ip?
Any application that calls dlpi_open() with a link name of ip.tun* does
that, yes. The implementation of dlpi_open() does this. Since ifconfig
calls dlpi_open() this is done in the context of the ifconfig process.
> seems like only 6to4relay does this. This paragraph needs to be updated.
> (the dlpi_open magic is explained in a later section)
6to4relay doesn't do that at all. It just opens a socket and passes
down socket ioctls. The ip module has some shady logic to pass down
those ioctls to the tun module below the ill.
I can make it more clear that ifconfig plumbing of an IP tunnel works
through dlpi_open().
> - page 5, 34: if the tsrc (link layer src of the tunnel) is
> administratively brought down or deleted, what happens to the tunnel?
> (I would expect that it would get marked !RUNNING)
Not now (and it doesn't today with the tun implementation either), but
this is a valid RFE.
> Also, what happens with nested tunnels (i.e., if the tsrc of a tunnel
> is itself another tunnels IP src)- the order of bringing them up
> seems to matter.. would be nicer if the successful plumb/up of an interface
> could go and enable any tunnels that depend on that interface (and the
> converse for down/unplumb)
The order does matter now (as it always has), but an RFE I've been
thinking about for the future would remove such dependencies on tunnel
creation.
Nested tunnels in general (assuming that they're plumbed in the
appropriate order) work just fine.
> - nit: why the itp_* prefix? shouldn't this be ipt_*? e.g.,
> it's a bit confusing to see itp_type values of IPTUN_TYPE*
It stands for IP Tunnel Parameter. The IPTUN_TYPE* values have scope
beyond the user-land "IP Tunnel Parameter" structure; they're used by
the kernel as well. This is a similar distinction as the DLADM_* vs.
DATALINK_* prefixes. If you think "itp_*" is confusing, do you have any
better suggestion?
Thanks,
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
595
From:
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design
document update
Posted:
Jul 3, 2009 8:32 AM
in response to: seb
|
|
On (07/03/09 10:07), Sebastien Roy wrote:
> To: Sowmini dot Varadhan at Sun dot COM
> Cc: Peter dot Memishian at Sun dot COM,
> clearview-discuss <clearview-discuss at opensolaris dot org>
> From: Sebastien Roy <Sebastien dot Roy at Sun dot COM>
> Date: Fri, 03 Jul 2009 10:07:31 -0400
> Subject: Re: [clearview-discuss] Clearview IP Tunneling design document
> update
> Original-recipient: rfc822;Sowmini dot Varadhan at Sun dot COM
> In-reply-to: <20090703120109 dot GD14942 at quasimodo dot East dot Sun dot COM>
> Organization: Sun Microsystems
> X-Mailer: Evolution 2.26.1.1
>
>
> On Fri, 2009-07-03 at 08:01 -0400, Sowmini dot Varadhan at Sun dot COM wrote:
> > On (07/02/09 17:45), Sebastien Roy wrote:
> > >
> > > http://www.opensolaris.org/os/project/clearview/iptun/iptun-design.pdf
> >
> > A few comments/questions:
> >
> > - Editorial- Section 3: does ifconfig really push tun on top of /dev/ip?
I thought the paragraph in Section 3 referred to something like the following
from usr/src/cmd/cmd-inet/usr.sbin/6to4relay.c (today)
275 /* open /dev/ip for use */
276 if ((fd = open("/dev/ip", O_RDWR)) == -1) {
277 printerror(gettext("can't open /dev/ip"));
278 exit(EXIT_FAILURE);
279 }
280
281 if (ioctl(fd, I_PUSH, TUN_NAME) < 0) {
282 printerror("ioctl (I_PUSH)");
283 ret = EXIT_FAILURE;
284 goto done;
285 }
which ifconfig does not directly do (it seems to be done in dlpi_open)
> > - page 5, 34: if the tsrc (link layer src of the tunnel) is
> > administratively brought down or deleted, what happens to the tunnel?
> > (I would expect that it would get marked !RUNNING)
>
> Not now (and it doesn't today with the tun implementation either), but
> this is a valid RFE.
>
> > Also, what happens with nested tunnels (i.e., if the tsrc of a tunnel
:
> The order does matter now (as it always has), but an RFE I've been
Well, it would be simpler if tunnel creation always "succeeded" in
creating the tunnel, but left it !RUNNING if the tsrc was not available
yet. And, as each address becomes available (on any interface) an
additional task woudl be to go and mark any waiting tunnel interfaces
as RUNNING.
>
> > - nit: why the itp_* prefix? shouldn't this be ipt_*? e.g.,
> > it's a bit confusing to see itp_type values of IPTUN_TYPE*
>
> It stands for IP Tunnel Parameter. The IPTUN_TYPE* values have scope
> beyond the user-land "IP Tunnel Parameter" structure; they're used by
> the kernel as well. This is a similar distinction as the DLADM_* vs.
> DATALINK_* prefixes. If you think "itp_*" is confusing, do you have any
> better suggestion?
itp and ipt.. gets confusing when typing.. is iptp better? or maybe
even ipt_parm_*?
--Sowmini
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 3, 2009 10:11 AM
in response to: sowmini
|
|
On Fri, 2009-07-03 at 11:32 -0400, Sowmini dot Varadhan at Sun dot COM wrote:
> > >
> > > - Editorial- Section 3: does ifconfig really push tun on top of /dev/ip?
>
> I thought the paragraph in Section 3 referred to something like the following
> from usr/src/cmd/cmd-inet/usr.sbin/6to4relay.c (today)
>
> 275 /* open /dev/ip for use */
> 276 if ((fd = open("/dev/ip", O_RDWR)) == -1) {
> 277 printerror(gettext("can't open /dev/ip"));
> 278 exit(EXIT_FAILURE);
> 279 }
> 280
> 281 if (ioctl(fd, I_PUSH, TUN_NAME) < 0) {
> 282 printerror("ioctl (I_PUSH)");
> 283 ret = EXIT_FAILURE;
> 284 goto done;
> 285 }
>
> which ifconfig does not directly do (it seems to be done in dlpi_open)
Right, I've clarified that. The section tries to give an overview of
how IP tunnels are constructed by ifconfig.
> > > - page 5, 34: if the tsrc (link layer src of the tunnel) is
> > > administratively brought down or deleted, what happens to the tunnel?
> > > (I would expect that it would get marked !RUNNING)
> >
> > Not now (and it doesn't today with the tun implementation either), but
> > this is a valid RFE.
> >
> > > Also, what happens with nested tunnels (i.e., if the tsrc of a tunnel
> :
>
> > The order does matter now (as it always has), but an RFE I've been
>
> Well, it would be simpler if tunnel creation always "succeeded" in
> creating the tunnel, but left it !RUNNING if the tsrc was not available
> yet. And, as each address becomes available (on any interface) an
> additional task woudl be to go and mark any waiting tunnel interfaces
> as RUNNING.
Yes, I agree that it would be simpler. I'll add an appendix for "future
work" to the document. Again, this is an existing limitation of the
current implementation, and there's no explicit requirement to address
this now. The goal of the project wasn't necessarily to address every
pending RFE of the current IP tunneling implementation, but rather to
make IP tunnels fit the model of Clearview interface requirements.
Having this cleaner design at least allows us to implement these RFEs
using a more cohesive framework.
> > > - nit: why the itp_* prefix? shouldn't this be ipt_*? e.g.,
> > > it's a bit confusing to see itp_type values of IPTUN_TYPE*
> >
> > It stands for IP Tunnel Parameter. The IPTUN_TYPE* values have scope
> > beyond the user-land "IP Tunnel Parameter" structure; they're used by
> > the kernel as well. This is a similar distinction as the DLADM_* vs.
> > DATALINK_* prefixes. If you think "itp_*" is confusing, do you have any
> > better suggestion?
>
> itp and ipt.. gets confusing when typing.. is iptp better? or maybe
> even ipt_parm_*?
IPTP is something recognizably different, so I don't think it's better.
Maybe iptun_param_*...
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
595
From:
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design
document update
Posted:
Jul 3, 2009 7:07 PM
in response to: seb
|
|
> >
> > Well, it would be simpler if tunnel creation always "succeeded" in
> > creating the tunnel, but left it !RUNNING if the tsrc was not available
> > yet. And, as each address becomes available (on any interface) an
> > additional task woudl be to go and mark any waiting tunnel interfaces
> > as RUNNING.
>
> Yes, I agree that it would be simpler. I'll add an appendix for "future
> work" to the document. Again, this is an existing limitation of the
sounds good. I agree that this does not need to get fixed right away,
but I think that attempting to resolve tsrc dependancies through
smf can't cover all the permutations.
--Sowmini
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 4, 2009 7:15 AM
in response to: sowmini
|
|
On Fri, 2009-07-03 at 22:07 -0400, Sowmini dot Varadhan at Sun dot COM wrote:
> > >
> > > Well, it would be simpler if tunnel creation always "succeeded" in
> > > creating the tunnel, but left it !RUNNING if the tsrc was not available
> > > yet. And, as each address becomes available (on any interface) an
> > > additional task woudl be to go and mark any waiting tunnel interfaces
> > > as RUNNING.
> >
> > Yes, I agree that it would be simpler. I'll add an appendix for "future
> > work" to the document. Again, this is an existing limitation of the
>
> sounds good. I agree that this does not need to get fixed right away,
> but I think that attempting to resolve tsrc dependancies through
> smf can't cover all the permutations.
Indeed. The existing dependency is meant to maintain backward
compatibility with the administrative limitations we have now. I've
added Appendix B to the design document to describe the potential future
work that can be done to make this better.
http://www.opensolaris.org/os/project/clearview/iptun/iptun-design.pdf
Thanks,
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
37
From:
Menlo Park, CA
Registered:
1/23/06
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document update
Posted:
Jul 14, 2009 5:07 PM
in response to: seb
To: Projects » clearview » discuss
|
|
Seb-
I'm working improving the integration of Crossbow and Zones. One of the fixes will be the automatic creation of vnics for zones. You touched on this in the 'Future Work' section.
Here are my comments/questions:
I'm assuming that the proposed datalink.conf in the ngz will only have information on
links which are created in the ngz and not available to the global zone.
Would <zonename>:vnic<num> naming scheme apply to these automatically created vnics?
There are future plans to create separate /dev/net namespaces for exclusive ip zones which
would also rely on the ngz datalink.conf files.
Thanks,
Mike
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 14, 2009 6:28 PM
in response to: mll3k
|
|
Hi Mike,
On Tue, 2009-07-14 at 17:07 -0700, Michael Lim wrote:
> Seb-
>
> I'm working improving the integration of Crossbow and Zones. One of
> the fixes will be the automatic creation of vnics for zones. You touched
> on this in the 'Future Work' section.
Yes, this is something that came up in a discussion I had with Ed
Pilatowicz a while ago. I'm glad to see that this is gelling into
something more than an idea. :-)
>
> Here are my comments/questions:
>
> I'm assuming that the proposed datalink.conf in the ngz will only have information on
> links which are created in the ngz and not available to the global zone.
That's exactly right. I can make that more explicit in the doc.
> Would <zonename>:vnic<num> naming scheme apply to these
> automatically created vnics?
Yes, that was my thinking. In the future, all datalinks, regardless of
where they're created, would be visible from the global zone using this
hybrid namespace. The "<zonename>:" prefix would not be printed from
the non-global zone that owns the datalink in question though, much like
global zone links wouldn't show up as global:<linkname> in the global
zone, but instead just <linkname>.
> There are future plans to create separate /dev/net namespaces for exclusive ip zones which
> would also rely on the ngz datalink.conf files.
I'm not sure what you mean by that. Each exclusive stack zone already
has a separate /dev/net namespace with this design. Can you be more
specific about the plans you refer to?
Thanks,
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,046
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design
document update
Posted:
Jul 14, 2009 7:18 PM
in response to: seb
|
|
> > I'm assuming that the proposed datalink.conf in the ngz will only have information on
> > links which are created in the ngz and not available to the global zone.
>
> That's exactly right. I can make that more explicit in the doc.
Just to make sure I follow: if a zone is loaned a link from the global
zone, it will not show up in that zone's datalink.conf, right?
--
meem
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 14, 2009 7:45 PM
in response to: meem
|
|
On Tue, 2009-07-14 at 19:18 -0700, Peter Memishian wrote:
> > > I'm assuming that the proposed datalink.conf in the ngz will only have information on
> > > links which are created in the ngz and not available to the global zone.
> >
> > That's exactly right. I can make that more explicit in the doc.
>
> Just to make sure I follow: if a zone is loaned a link from the global
> zone, it will not show up in that zone's datalink.conf, right?
That's correct. The datalink.conf file in a zone only contains links
that were created in that zone. Links that are on loan to a non-global
zone from the global zone were created in the global zone.
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
Posts:
37
From:
Menlo Park, CA
Registered:
1/23/06
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 15, 2009 10:56 AM
in response to: seb
To: Projects » clearview » discuss
|
|
> Yes, this is something that came up in a discussion I
> had with Ed
> Pilatowicz a while ago. I'm glad to see that this is
> gelling into
> something more than an idea. :-)
>
> >
> > Here are my comments/questions:
> >
> > I'm assuming that the proposed datalink.conf in
> the ngz will only have information on
> > links which are created in the ngz and not
> available to the global zone.
>
> That's exactly right. I can make that more explicit
> in the doc.
OK
> > Would <zonename>:vnic<num> naming scheme apply to
> these
> > automatically created vnics?
>
> Yes, that was my thinking. In the future, all
> datalinks, regardless of
> where they're created, would be visible from the
> global zone using this
> hybrid namespace. The "<zonename>:" prefix would not
> be printed from
> the non-global zone that owns the datalink in
> question though, much like
> global zone links wouldn't show up as
> global:<linkname> in the global
> zone, but instead just <linkname>.
So then, the transfer of ownership would take place at
zoneadm install?
>
> > There are future plans to create separate
> /dev/net namespaces for exclusive ip zones which
> > would also rely on the ngz datalink.conf files.
>
> I'm not sure what you mean by that. Each exclusive
> stack zone already
> has a separate /dev/net namespace with this design.
> Can you be more
> pecific about the plans you refer to?
OK. Maybe Nicolas and Erik were referring to this when they mentioned it to me.
Thanks,
Mike
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: [clearview-discuss] Clearview IP Tunneling design document
update
Posted:
Jul 15, 2009 11:37 AM
in response to: mll3k
|
|
On Wed, 2009-07-15 at 10:56 -0700, Michael Lim wrote:
> > > Would <zonename>:vnic<num> naming scheme apply to
> > these
> > > automatically created vnics?
> >
> > Yes, that was my thinking. In the future, all
> > datalinks, regardless of
> > where they're created, would be visible from the
> > global zone using this
> > hybrid namespace. The "<zonename>:" prefix would not
> > be printed from
> > the non-global zone that owns the datalink in
> > question though, much like
> > global zone links wouldn't show up as
> > global:<linkname> in the global
> > zone, but instead just <linkname>.
>
> So then, the transfer of ownership would take place at
> zoneadm install?
The <zonename>: prefix would reflect the zone where the link is
assigned. That can change by setting the "zone" link property (which is
done at zone boot for those links that are part of the zone
configuration), so this is not an install-time property.
But really, this is a malleable idea at this point, as it's a result of
some discussions on what would be possible and/or useful. If other
models make sense, let's discuss those too.
-Seb
_________________________________
clearview-discuss mailing list
clearview-discuss at opensolaris dot org
|
|
|
|
|
