|
Replies:
23
-
Last Post:
Dec 8, 2005 11:49 AM
by: meem
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Clearview IP Tunneling Device Driver: design
review (due 9/30)
Posted:
Sep 18, 2005 9:37 AM
|
|
OpenSolaris networking community,
As described last week, the Solaris Approachability team's Clearview
project aims to rationalize, unify, and enhance the way network
interfaces are handled in Solaris. The four components of Clearview
are:
IPMP Rearchitecture
IP Tunneling Device Driver
Vanity Naming and Nemo Unification
IP-Level Observability Devices
The second design document from this work, covering the IP tunneling
device, is available at:
http://opensolaris.org/os/community/networking/iptun-design.pdf
This document introduces a DLPI device driver that implements an IP
tunneling link-layer. It uses the newest networking driver framework
available in Solaris: Nemo. This work aims to bring parity between the
features of other networking interfaces and IP tunneling interfaces in
Solaris, one of which is observability.
All feedback is welcome. If you implement IPsec VPN solutions using
Solaris IP tunneling, provide IPv6 transition mechanisms to your
customers, or are interested in providing input to this project for any
other reason, please don't hesitate to post your comments.
The timer for comments is set at two weeks (October 1).
Thank you very much for being a part of this development process. We're
excited to have the opportunity to receive input from this community.
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
Posts:
6,813
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review (due 9/30)
Posted:
Oct 9, 2005 12:01 PM
in response to: seb
|
|
Sebastien Roy writes:
> The second design document from this work, covering the IP tunneling
> device, is available at:
>
> http://opensolaris.org/os/community/networking/iptun-design.pdf
Late, as always:
I reviewed revision 1.0 (September 17, 2005).
p2:
Any guesses what GRE (with or without UDP underneath) might look
like? It's an oft-requested feature, and it'd be good to know at
least vaguely how we'll eventually get there, even if this project
isn't doing that work.
p3 4.2.1:
Is it (or will it ever be) possible to make tsrc optional? Given a
destination, the system can obviously choose an appropriate source
address to use. And obviously, if the system uses DHCP, it may have
a dynamic source that will be hard to represent with this interface.
What are the issues? I'd imagine that we'd need to deal with
destinations that can themselves change in address. (Perhaps it's
possible only with UDP- or IPsec-based tunnels, where there's an
identifier [port or SA] that can identify the tunnel rather than
multiplexing on address.)
p8:
What does the text about ifconfig unplumb mean? I suspect that it
might mean that if the tunnel is permanent, then unplumbing it will
just remove it right now, and the tunnel will come back after after
reboot. Is that it? Or does the unplumb request actually fail when
the tunnel is considered permanent?
p10 6.2.1:
What is the state of the tunnel before source and destination are
both set? I'd assume that it's ~IFF_RUNNING. Is that correct?
p11 top:
For delete: if I say "apply both now and later," but the tunnel is
currently plumbed temporarily only, or if the tunnel is in the file
but not actually plumbed, is that an error?
p11 6.2.4:
Is it an error to ask for both now and later when getting
parameters?
p11 6.2.5:
nit: Asterisk on fnp looks wrong; that creates a pointer to a
function pointer.
p13 top:
How does iptun_create generate a unique data-link name atomically
across the system?
p15 top:
How does the tunnel module learn about path MTU changes?
p16 8:
Big sigh! There's no such thing as a "well-known DLSAP number space
for all DLPI devices." Mentat's IP design even has a per
dl_mac_type table for looking these things up. Unfortunately,
you're right that this isn't well maintained and that there is code
that mandates this usage. Still, it's wrong.
p16 8:
Why does binding to values other than IPv4 or IPv6 have no effect?
Shouldn't it return DL_ERROR_ACK if the value is non-zero but not
identified? We don't want arbitrary protocols attempting to plumb
themselves up on these interfaces, do we?
(If the DLSAP space were properly defined here rather than
translated from Ethertypes, it would actually be the IP Protocol
Identifier, and this ambiguity would go away.)
p18 9.1:
"unicst"? Can I buy a vowel?
The functionality proposed for m_unicst doesn't look right to me,
because it's taking a general-purpose function pointer and rendering
it into a single-purpose mechanism. This is the central problem
with GLD: as a generic framework that handles multiple MAC types, it
must do one of the following:
- Implement per-MAC-type features for every known MAC type,
and grow new ones every time a new MAC type is defined and
needed.
- Implement a *SEPARATE* MAC-type plug-in interface, that
allows MAC personalities to be inserted into the framework
apart from the driver clients of the framework.
Insisting that the driver clients provide the MAC-type-generic
functionality actually breaks the architectural model of GLD (and
Nemo). It means that it's no longer really "generic."
I can accept that for *some* special MAC types, it might be
worthwhile to co-package the MAC personality bits with the driver
that uses that MAC type, because there just is no chance that any
other driver will ever implement that MAC type. However, I don't
think that's a good general model, and it shouldn't be the direction
that Nemo takes for MAC type extension.
p19 9.5:
Is it possible that some exotic types of tunnels might support
multicast, such as 6to4?
p20 top:
Nit: s/an the resulting/and the resulting/
p20 9.5.3:
Most other implementations use a single pointer (or structure
member) for both broadcast address and destination address, because
broadcast addresses are not used on point-to-point, and destination
addresses are required on point-to-point. That needn't be done
here, but it could.
p21 9.6.1:
Need more information: what happens today if the user plumbs up IPv6
on a v4 tunnel that doesn't yet have tsrc/tdst set? What
interface-id or prefix is used? What happens later if these are set
after plumbing up IPv6? Do the generated link-local addresses
change on the fly?
p22 top:
This new DLPI mechanism poses some deeper questions. Why exactly
are we removing DL_IPV4 and DL_IPV6 in favor of a single DL_IP? It
seems to me that this design choice is exactly what causes this new
DLPI mechanism to be needed here: the right information isn't
communicated via dl_mac_type, and so a "capability" needs to be
added to make up for the lost information.
But more fundamentally, I'm not sure that this unification is really
right. Clearly, IPv4 and IPv6 have different "MAC" address formats,
different SAP spaces (if the Ethertype hack is removed), and
different behaviors. Isn't that enough to class them as being
separate dl_mac_types?
p22 9.7(4):
Nit: s/b_cont/b_next/
p23 9.8:
DL_NOTE_PHYS_ADDR, though, is documented and will need to be
updated.
p24 10:
Architectural issue: SMF doesn't really appear to be enough here.
Users probably should be able to deal with systems that use DHCP,
but they really can't today, unless DHCP just hands out static
addresses.
p25:
Need more information here. Collapsing the dl_mac_types causes
defects in other areas (the one that concerns me most is the
potential SAP space confusion), and it's not clear why doing this is
necessary for observability.
My guess is that you want to have a single tunnel device that can be
used for both v4 and v6 tunnels, and when the user opens the device,
you won't know what dl_mac_type to return for DL_INFO_REQ until the
tunnel is configured. But why not just have separate reserved minor
nodes for v4 and v6, so the user can ask for what he really wants?
p27 fig 2:
Why have iptun_{src,dst}? You can read these directly from the
conn_t, can't you?
p30 bottom:
Why is iptun_fields_t an enum? It looks like a bit field to me. If
so, then either use ":1" or #define.
I suggest using uintptr_t for the return type on iptun_walk_func_t
and having a stop-on-!=-0 semantic. This allows you to implement
arbitrary lookup functions via the walker.
p31:
There's a different iptun_fields_t here with different defined
values. This probably won't compile well.
p32:
I don't think that iptun_{src,dst} are really needed.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review (due 9/30)
Posted:
Oct 10, 2005 11:30 AM
in response to: carlsonj
|
|
On Sun, 2005-10-09 at 15:01, James Carlson wrote:
> Sebastien Roy writes:
> > The second design document from this work, covering the IP tunneling
> > device, is available at:
> >
> > http://opensolaris.org/os/community/networking/iptun-design.pdf
>
> Late, as always:
No matter, thanks for the comments.
> I reviewed revision 1.0 (September 17, 2005).
>
> p2:
>
> Any guesses what GRE (with or without UDP underneath) might look
> like? It's an oft-requested feature, and it'd be good to know at
> least vaguely how we'll eventually get there, even if this project
> isn't doing that work.
I could see this being another IP tunnel type configured via dladm. The
iptun driver could implement this type of tunneling. The link-layer
header would be either IP and GRE, or IP, UDP, and GRE. The driver
could either communicate directly with IP below it, or with UDP
(assuming there's some interface to use UDP from within the kernel).
> p3 4.2.1:
>
> Is it (or will it ever be) possible to make tsrc optional? Given a
> destination, the system can obviously choose an appropriate source
> address to use. And obviously, if the system uses DHCP, it may have
> a dynamic source that will be hard to represent with this interface.
It would be possible to make tsrc optional, but it wouldn't work well
with the tunnel types we're currently implementing. For configured
tunnels, both tunnel endpoints must be configured identically for the
multiplexing of tunneled packets to work properly (my tsrc has to match
your tdst, and vice versa). Having a variable tsrc makes this somewhat
problematic. For 6to4 tunnels, the IPv6 prefix of the entire 6to4 site
is a function of the tsrc. An automatic tunnel's IPv6 address is a
function of the tsrc. Without a tsrc, the interface above it would be
useless.
> What are the issues? I'd imagine that we'd need to deal with
> destinations that can themselves change in address. (Perhaps it's
> possible only with UDP- or IPsec-based tunnels, where there's an
> identifier [port or SA] that can identify the tunnel rather than
> multiplexing on address.)
That's right. Do you think it would be worthwhile to add such a
discussion to this design document?
> p8:
>
> What does the text about ifconfig unplumb mean? I suspect that it
> might mean that if the tunnel is permanent, then unplumbing it will
> just remove it right now, and the tunnel will come back after after
> reboot. Is that it?
No. Perhaps the wording here needs to be re-worked, and there's even a
mistake in the information given. What I want to address is the
difference between explicitly created tunnels (those created using
dladm), and implicitly created tunnels (those temporarily created by
ifconfig plumb when ifconfig couldn't find an existing tunnel device).
Explicitly created tunnels are created and destroyed using dladm. Only
the IP interfaces above them are created and destroyed by ifconfig.
Implicitly created tunnels are created by ifconfig as described above,
but destroyed when the last close of its DLPI device occurs (the last IP
interface is unplumbed, the last snoop process killed, etc...).
> Or does the unplumb request actually fail when
> the tunnel is considered permanent?
Unplumbing the IP interface will always succeed (barring any unrelated
failures). The tunnel link exists independently of the IP interfaces
above it.
> p10 6.2.1:
>
> What is the state of the tunnel before source and destination are
> both set? I'd assume that it's ~IFF_RUNNING. Is that correct?
Good question. Link-state might be a good way to represent a tunnel
whose configuration isn't complete. I'd agree with that, and I'll add
that in.
> p11 top:
>
> For delete: if I say "apply both now and later," but the tunnel is
> currently plumbed temporarily only, or if the tunnel is in the file
> but not actually plumbed, is that an error?
Hmm. I don't think it should be. I believe there's a way to reconcile
this. In the first case, add the configuration to the file and make any
necessary changes to the existing tunnel. In the second case, make any
necessary changes to the file, and create the tunnel. There may be
cases I'm not thinking about that could be difficult to deal with...
> p11 6.2.4:
>
> Is it an error to ask for both now and later when getting
> parameters?
Yes, it should be. I'll specify that.
> p11 6.2.5:
>
> nit: Asterisk on fnp looks wrong; that creates a pointer to a
> function pointer.
iptun_walk_func_t is defined in Appendix B as:
typedef void (iptun_walk_func_t)(const char *, ...);
I would think that "iptun_walk_func_t *" is just a pointer to a
function. Maybe I'm missing the point...
> p13 top:
>
> How does iptun_create generate a unique data-link name atomically
> across the system?
Very good question. Assuming that we serialize the creation of names
from within iptun itself, the only source of conflict originates from
administrators choosing vanity names of the form used by the iptun
driver for other types of links.
This is a generic problem to vanity naming, and it's not specific to the
names used by iptun. For example, if I rename my "qfe0" link to "bge0",
then plug in a real bge0 card, it will fail to register because it will
attempt to use the name "bge0" by default. In other words, there's
nothing preventing an administrator from using a link name that would
conflict with a name that would be used by default by another driver in
the future.
Perhaps the iptun driver can be smart and attempt a different name (by
increasing the PPA number) if the registration fails...
> p15 top:
>
> How does the tunnel module learn about path MTU changes?
The mechanism will be no different than what is implemented today in the
tun STREAMS module, except for one small change. The only difference
will be that instead of using IRE_DB_REQ_TYPE to request path MTU
information, it will use function calls to access ire's. Do you think
that the details of the existing implementation would be beneficial to
this document?
>
> p16 8:
>
> Big sigh! There's no such thing as a "well-known DLSAP number space
> for all DLPI devices." Mentat's IP design even has a per
> dl_mac_type table for looking these things up. Unfortunately,
> you're right that this isn't well maintained and that there is code
> that mandates this usage. Still, it's wrong.
>
Mike Ditto also brought this up. I'm not sure what I can do about
this...
>
> p16 8:
>
> Why does binding to values other than IPv4 or IPv6 have no effect?
> Shouldn't it return DL_ERROR_ACK if the value is non-zero but not
> identified? We don't want arbitrary protocols attempting to plumb
> themselves up on these interfaces, do we?
>
> (If the DLSAP space were properly defined here rather than
> translated from Ethertypes, it would actually be the IP Protocol
> Identifier, and this ambiguity would go away.)
Mike also brought this up, and I'm starting to think that the framework
plugin for mac types (as you suggest below) should probably include
information about legal SAP values.
>
> p18 9.1:
>
> "unicst"? Can I buy a vowel?
Bzzz! Sorry, no As. Spin the wheel. :-) I'll let Paul explain why
the letter a is missing from Nemo code, since I think he's on this list.
:-)
>
> The functionality proposed for m_unicst doesn't look right to me,
> because it's taking a general-purpose function pointer and rendering
> it into a single-purpose mechanism. This is the central problem
> with GLD: as a generic framework that handles multiple MAC types, it
> must do one of the following:
>
> - Implement per-MAC-type features for every known MAC type,
> and grow new ones every time a new MAC type is defined and
> needed.
>
> - Implement a *SEPARATE* MAC-type plug-in interface, that
> allows MAC personalities to be inserted into the framework
> apart from the driver clients of the framework.
>
> Insisting that the driver clients provide the MAC-type-generic
> functionality actually breaks the architectural model of GLD (and
> Nemo). It means that it's no longer really "generic."
>
> I can accept that for *some* special MAC types, it might be
> worthwhile to co-package the MAC personality bits with the driver
> that uses that MAC type, because there just is no chance that any
> other driver will ever implement that MAC type. However, I don't
> think that's a good general model, and it shouldn't be the direction
> that Nemo takes for MAC type extension.
I essentially agree with that. Implementing a MAC-type plug-in is an
attractive proposition, and one that I'll investigate. I like this
concept better than what I've proposed.
>
> p19 9.5:
>
> Is it possible that some exotic types of tunnels might support
> multicast, such as 6to4?
6to4 does not support multicast (because there's no defined mapping from
IPv6 multicast address to link-layer IPv4 address), but that doesn't
mean that other IP tunnel types implemented in the future won't support
multicast. I believe that the changes I'm proposing here allow for such
future implementation. The iptun driver can register a m_multicst()
callback for those types that do support multicast.
>
>
> p20 top:
>
> Nit: s/an the resulting/and the resulting/
Will fix.
>
> p20 9.5.3:
>
> Most other implementations use a single pointer (or structure
> member) for both broadcast address and destination address, because
> broadcast addresses are not used on point-to-point, and destination
> addresses are required on point-to-point. That needn't be done
> here, but it could.
So the pointer is overloaded to mean either broadcast or destination. I
could do that.
>
> p21 9.6.1:
>
> Need more information: what happens today if the user plumbs up IPv6
> on a v4 tunnel that doesn't yet have tsrc/tdst set?
The IPv6 addresses of the interface are left unspecified until tsrc/tdst
are set.
> What interface-id or prefix is used?
Both are unused until tsrc/tdst are set.
>
> What happens later if these are set after plumbing up IPv6?
The link-local addresses of the interfaces are generated and configured
at that time.
> Do the generated link-local addresses change on the fly?
They will in this design, but an existing bug prevents them from
changing today:
4289774 Changes to MAC address do not change IPv6 link-local address
This problem exists for IPv6 interfaces on Ethernet as well. When I
change the Ethernet address of an interface, the IPv6 link-local address
on that interface should be changed to match the new interface token.
It's no different for tunnels, really.
>
> p22 top:
>
> This new DLPI mechanism poses some deeper questions. Why exactly
> are we removing DL_IPV4 and DL_IPV6 in favor of a single DL_IP? It
> seems to me that this design choice is exactly what causes this new
> DLPI mechanism to be needed here: the right information isn't
> communicated via dl_mac_type, and so a "capability" needs to be
> added to make up for the lost information.
>
> But more fundamentally, I'm not sure that this unification is really
> right. Clearly, IPv4 and IPv6 have different "MAC" address formats,
> different SAP spaces (if the Ethertype hack is removed), and
> different behaviors. Isn't that enough to class them as being
> separate dl_mac_types?
Yes, it is, and the more I think about these differences, the more I
think they should be separate types. The reason that a single DL_IP
type is used is to match the kinds of packets that the IP observability
device (to be reviewed soon) will have access to. One observability
device (named bge0, for example) will have access to both IPv4 and IPv6
packets flowing over a single interface. DL_IPV4 or DL_IPV6 doesn't
describe this well at all. A version independent DL_IP does, and the
consumer of these observability devices can act on the version field of
the received IP headers.
The same is not true for IP tunnel devices. Once created, a tunnel
device will only ever use one type (or version) of link-layer IP header
(this is a function of the tunnel type). DL_IP is only used for
symmetry with the observability device, which also gives access to IP
packets. I'm still not convinced that this is the best approach.
>
>
> p22 9.7(4):
>
> Nit: s/b_cont/b_next/
Will fix.
>
> p23 9.8:
>
> DL_NOTE_PHYS_ADDR, though, is documented and will need to be
> updated.
Yes, I'll add that to this summary.
>
> p24 10:
>
> Architectural issue: SMF doesn't really appear to be enough here.
> Users probably should be able to deal with systems that use DHCP,
> but they really can't today, unless DHCP just hands out static
> addresses.
I don't understand the issue you're raising. Can you elaborate?
>
>
> p25:
>
> Need more information here. Collapsing the dl_mac_types causes
> defects in other areas (the one that concerns me most is the
> potential SAP space confusion), and it's not clear why doing this is
> necessary for observability.
It's not necessary for IP tunnels, but separate DL_IPV4 and DL_IPV6
types can't be used by the observability devices as I described above.
>
> My guess is that you want to have a single tunnel device that can be
> used for both v4 and v6 tunnels, and when the user opens the device,
> you won't know what dl_mac_type to return for DL_INFO_REQ until the
> tunnel is configured. But why not just have separate reserved minor
> nodes for v4 and v6, so the user can ask for what he really wants?
This is actually not a problem at all. Once a tunnel link has been
created, the version of IP used by the link-layer is known from the
beginning based on the tunnel type. We always know whether the
link-layer of a tunnel is IPv4 or IPv6. An IPv4 interface can be
created on that tunnel by binding to the IPv4 SAP, and similarly for
IPv6 interfaces. No separate minor nodes are needed. The only reason
the MAC-types were collapsed was to match what the observability device
was using.
>
> p27 fig 2:
>
> Why have iptun_{src,dst}? You can read these directly from the
> conn_t, can't you?
Yes, I could. I don't see a reason to keep them.
>
> p30 bottom:
>
> Why is iptun_fields_t an enum? It looks like a bit field to me. If
> so, then either use ":1" or #define.
It was originally a bit field of #define constants, but it was suggested
that an enum would be better for particular type-checking and debugging.
>
> I suggest using uintptr_t for the return type on iptun_walk_func_t
> and having a stop-on-!=-0 semantic. This allows you to implement
> arbitrary lookup functions via the walker.
Good suggestion, I'll do that.
>
> p31:
>
> There's a different iptun_fields_t here with different defined
> values. This probably won't compile well.
I meant to make it a separate type. I'll fix that.
>
> p32:
>
> I don't think that iptun_{src,dst} are really needed.
I'll remove them.
Thank you,
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,813
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review (due 9/30)
Posted:
Oct 10, 2005 12:34 PM
in response to: seb
|
|
Sebastien Roy writes:
> > Any guesses what GRE (with or without UDP underneath) might look
> > like? It's an oft-requested feature, and it'd be good to know at
> > least vaguely how we'll eventually get there, even if this project
> > isn't doing that work.
>
> I could see this being another IP tunnel type configured via dladm. The
> iptun driver could implement this type of tunneling. The link-layer
> header would be either IP and GRE, or IP, UDP, and GRE. The driver
> could either communicate directly with IP below it, or with UDP
> (assuming there's some interface to use UDP from within the kernel).
That's sort of what I figured. It seems unfortunate that it'll
probably lead to a minor combinatorial explosion in dl_mac_type values
(IP/IPv4, GRE/IPv4, GRE/UDP/IPv4, IP/IPv6, ...), but I suspect that
the overall population is small enough not to care.
> > What are the issues? I'd imagine that we'd need to deal with
> > destinations that can themselves change in address. (Perhaps it's
> > possible only with UDP- or IPsec-based tunnels, where there's an
> > identifier [port or SA] that can identify the tunnel rather than
> > multiplexing on address.)
>
> That's right. Do you think it would be worthwhile to add such a
> discussion to this design document?
It seems related to some of the IPsec changes that might come in the
future (not "tunnel reform," but rather a possible follow-on).
I suspect that the root issue is needing a tunnel control protocol
(something like L2TP or IPsec in its network configuration clothing)
to make this sane.
> > p8:
> >
> > What does the text about ifconfig unplumb mean? I suspect that it
> > might mean that if the tunnel is permanent, then unplumbing it will
> > just remove it right now, and the tunnel will come back after after
> > reboot. Is that it?
>
> No. Perhaps the wording here needs to be re-worked, and there's even a
> mistake in the information given. What I want to address is the
> difference between explicitly created tunnels (those created using
> dladm), and implicitly created tunnels (those temporarily created by
> ifconfig plumb when ifconfig couldn't find an existing tunnel device).
Oh, now I understand. So the real issue is just that temporaries go
away on last close, and permanents do not.
> > p11 top:
> >
> > For delete: if I say "apply both now and later," but the tunnel is
> > currently plumbed temporarily only, or if the tunnel is in the file
> > but not actually plumbed, is that an error?
>
> Hmm. I don't think it should be. I believe there's a way to reconcile
> this. In the first case, add the configuration to the file and make any
> necessary changes to the existing tunnel. In the second case, make any
> necessary changes to the file, and create the tunnel. There may be
> cases I'm not thinking about that could be difficult to deal with...
Your reply seems to read as though you're talking about a "change"
operation rather than a "delete" operation -- otherwise, I don't see
what the "create" references are about.
For delete, I think the first case is just an EBUSY: since the
temporary tunnel is in use, we know by definition that the interface
is held open by at least one stream, and you can just say it's busy.
The second case (writing "created in kernel" rather than "plumbed")
perhaps ought not happen, but I don't think it's an error to just
remove it from the file and drive on.
Any time you have state in two places (kernel and configuration file
in this case), questions like this will come up.
> > p11 6.2.5:
> >
> > nit: Asterisk on fnp looks wrong; that creates a pointer to a
> > function pointer.
>
> iptun_walk_func_t is defined in Appendix B as:
>
> typedef void (iptun_walk_func_t)(const char *, ...);
>
> I would think that "iptun_walk_func_t *" is just a pointer to a
> function. Maybe I'm missing the point...
OK. I was expecting (*iptun_walk_func_t) as part of that typedef, and
function pointers are a little bit funny in C. As defined, you're
allowing the user to do this as a prototype:
extern iptun_walk_func_t myfunc;
... which I guess is ok, though it's a bit surprising to me.
> > p13 top:
> >
> > How does iptun_create generate a unique data-link name atomically
> > across the system?
>
> Very good question. Assuming that we serialize the creation of names
> from within iptun itself, the only source of conflict originates from
> administrators choosing vanity names of the form used by the iptun
> driver for other types of links.
OK, it was that assumption that I was missing. I was under the
impression that the dladm utility itself would be forced to do this.
> Perhaps the iptun driver can be smart and attempt a different name (by
> increasing the PPA number) if the registration fails...
It probably just needs to be atomic when grabbing a PPA number, so
that it always picks "next available."
> > p15 top:
> >
> > How does the tunnel module learn about path MTU changes?
>
> The mechanism will be no different than what is implemented today in the
> tun STREAMS module, except for one small change. The only difference
> will be that instead of using IRE_DB_REQ_TYPE to request path MTU
> information, it will use function calls to access ire's. Do you think
> that the details of the existing implementation would be beneficial to
> this document?
I was asking about the inbound side, not how it accesses ires. In
other words, how does it know _when_ to go asking about a new MTU? At
a guess, it's still looking at the STREAMS-based messages from IP,
right?
> > p16 8:
> >
> > Big sigh! There's no such thing as a "well-known DLSAP number space
> > for all DLPI devices." Mentat's IP design even has a per
> > dl_mac_type table for looking these things up. Unfortunately,
> > you're right that this isn't well maintained and that there is code
> > that mandates this usage. Still, it's wrong.
> >
>
> Mike Ditto also brought this up. I'm not sure what I can do about
> this...
Possibly nothing, but noting in the document that this is "known to be
incorrect" might help.
Given that we're proposing exposing tunnels in a new way (allowing
things other than just IP to open and use them), it seems to me that
this is a good point at which to look at this problem again.
We could extend the existing ip_m_tbl[] array with entries for DL_IP*
so that it uses a new SAP space here, so I don't see why using a
fictitious "well-known" SAP is really required. To do better would
probably involve creating some sort of extensible dl_mac_type-to-
attributes table. (Certainly not required, but seems to have been
needed many times now.)
> > p18 9.1:
> >
> > "unicst"? Can I buy a vowel?
>
> Bzzz! Sorry, no As. Spin the wheel. :-) I'll let Paul explain why
> the letter a is missing from Nemo code, since I think he's on this list.
> :-)
"Go away" is a fine answer for this one.
> > p20 9.5.3:
> >
> > Most other implementations use a single pointer (or structure
> > member) for both broadcast address and destination address, because
> > broadcast addresses are not used on point-to-point, and destination
> > addresses are required on point-to-point. That needn't be done
> > here, but it could.
>
> So the pointer is overloaded to mean either broadcast or destination. I
> could do that.
No need ... I was just pointing out that there was some prior art.
> > p21 9.6.1:
[...]
> > Do the generated link-local addresses change on the fly?
>
> They will in this design, but an existing bug prevents them from
> changing today:
>
> 4289774 Changes to MAC address do not change IPv6 link-local address
OK. That answers my real question. ;-}
> > p22 top:
[...]
> Yes, it is, and the more I think about these differences, the more I
> think they should be separate types. The reason that a single DL_IP
> type is used is to match the kinds of packets that the IP observability
> device (to be reviewed soon) will have access to. One observability
> device (named bge0, for example) will have access to both IPv4 and IPv6
> packets flowing over a single interface. DL_IPV4 or DL_IPV6 doesn't
> describe this well at all. A version independent DL_IP does, and the
> consumer of these observability devices can act on the version field of
> the received IP headers.
But the two devices seem to me to be very different.
Though I haven't seen that document yet, the "DL_IP" observability
device seems like an odd beast to me. Unlike a real tunnel, it's not
something you can actually use for transmitting packets. And unlike a
real tunnel, it doesn't seem to have a use for SAPs or even addresses
in the conventional (DLPI) sense. Nor do I think it has any sort of
status, like MTU or link up/down.
I _think_ that device is just a convenience for snoop and friends so
that they don't have to learn about some new (possibly IP specific)
mechanism to grab packets.
So, I'm not sure how well the sharing works. (In fact, to avoid
confusion, you might want to rename that as "DL_IP_SNOOP" or some
such, to emphasize that it has just one goal in life.)
> > p24 10:
> >
> > Architectural issue: SMF doesn't really appear to be enough here.
> > Users probably should be able to deal with systems that use DHCP,
> > but they really can't today, unless DHCP just hands out static
> > addresses.
>
> I don't understand the issue you're raising. Can you elaborate?
I'm pointing out that SMF needs to be broken out on a per-interface
basis if this mechanism is to be used with anything more complicated
than static (hard-coded) addresses. Probably not an issue for now.
> > My guess is that you want to have a single tunnel device that can be
> > used for both v4 and v6 tunnels, and when the user opens the device,
> > you won't know what dl_mac_type to return for DL_INFO_REQ until the
> > tunnel is configured. But why not just have separate reserved minor
> > nodes for v4 and v6, so the user can ask for what he really wants?
>
> This is actually not a problem at all. Once a tunnel link has been
> created, the version of IP used by the link-layer is known from the
> beginning based on the tunnel type. We always know whether the
> link-layer of a tunnel is IPv4 or IPv6. An IPv4 interface can be
> created on that tunnel by binding to the IPv4 SAP, and similarly for
> IPv6 interfaces. No separate minor nodes are needed. The only reason
> the MAC-types were collapsed was to match what the observability device
> was using.
I'm sort of confused by that. If I open a tunnel driver instance and
do DL_INFO_REQ, what is in the DL_INFO_ACK? How do I tell what sort
of addresses I'm supposed to feed into it? (Should I key off of the
address length -- if it's 4, then it's IPv4, if it's 16, it's IPv6?
Or should I use the tunnel-private ioctl to find out what "type" of
tunnel it is?)
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review (due 9/30)
Posted:
Oct 10, 2005 1:26 PM
in response to: carlsonj
|
|
On Mon, 2005-10-10 at 15:34, James Carlson wrote:
> > > p8:
> > >
> > > What does the text about ifconfig unplumb mean? I suspect that it
> > > might mean that if the tunnel is permanent, then unplumbing it will
> > > just remove it right now, and the tunnel will come back after after
> > > reboot. Is that it?
> >
> > No. Perhaps the wording here needs to be re-worked, and there's even a
> > mistake in the information given. What I want to address is the
> > difference between explicitly created tunnels (those created using
> > dladm), and implicitly created tunnels (those temporarily created by
> > ifconfig plumb when ifconfig couldn't find an existing tunnel device).
>
> Oh, now I understand. So the real issue is just that temporaries go
> away on last close, and permanents do not.
More than that, only temporary tunnels created by ifconfig go away on
last close. Temporary tunnels created by dladm go away either when I
type dladm delete-iptun or when the system shuts down.
>
> > > p11 top:
> > >
> > > For delete: if I say "apply both now and later," but the tunnel is
> > > currently plumbed temporarily only, or if the tunnel is in the file
> > > but not actually plumbed, is that an error?
> >
> > Hmm. I don't think it should be. I believe there's a way to reconcile
> > this. In the first case, add the configuration to the file and make any
> > necessary changes to the existing tunnel. In the second case, make any
> > necessary changes to the file, and create the tunnel. There may be
> > cases I'm not thinking about that could be difficult to deal with...
>
> Your reply seems to read as though you're talking about a "change"
> operation rather than a "delete" operation -- otherwise, I don't see
> what the "create" references are about.
I misread your comment.
>
> For delete, I think the first case is just an EBUSY: since the
> temporary tunnel is in use, we know by definition that the interface
> is held open by at least one stream, and you can just say it's busy.
> The second case (writing "created in kernel" rather than "plumbed")
> perhaps ought not happen, but I don't think it's an error to just
> remove it from the file and drive on.
I agree with those semantics. Really, the first case isn't special at
all. You can never delete a tunnel link using this API when there is
something holding it open (this is mentioned in section 6.2.2).
>
> > > p11 6.2.5:
> > >
> > > nit: Asterisk on fnp looks wrong; that creates a pointer to a
> > > function pointer.
> >
> > iptun_walk_func_t is defined in Appendix B as:
> >
> > typedef void (iptun_walk_func_t)(const char *, ...);
> >
> > I would think that "iptun_walk_func_t *" is just a pointer to a
> > function. Maybe I'm missing the point...
>
> OK. I was expecting (*iptun_walk_func_t) as part of that typedef, and
> function pointers are a little bit funny in C. As defined, you're
> allowing the user to do this as a prototype:
>
> extern iptun_walk_func_t myfunc;
>
> ... which I guess is ok, though it's a bit surprising to me.
Either way, I don't really have a preference. Whatever method is most
common is what I'll use.
>
> > > p15 top:
> > >
> > > How does the tunnel module learn about path MTU changes?
> >
> > The mechanism will be no different than what is implemented today in the
> > tun STREAMS module, except for one small change. The only difference
> > will be that instead of using IRE_DB_REQ_TYPE to request path MTU
> > information, it will use function calls to access ire's. Do you think
> > that the details of the existing implementation would be beneficial to
> > this document?
>
> I was asking about the inbound side, not how it accesses ires. In
> other words, how does it know _when_ to go asking about a new MTU? At
> a guess, it's still looking at the STREAMS-based messages from IP,
> right?
It asks for new path-MTU information for the tunnel destination from ip
every 10 minutes to detect potential increases in path-MTU (IP will
increase path-MTU's that are smaller than the outboud link-MTU
periodically to adhere to the path-MTU algorithm described in RFC1191).
If the path-MTU to the tunnel destination decreases, we receive ICMP
frag-needed messages when sending packets that are too big, and
automatically adjust the link MTU of the affected tunnel link.
>
> > > p16 8:
> > >
> > > Big sigh! There's no such thing as a "well-known DLSAP number space
> > > for all DLPI devices." Mentat's IP design even has a per
> > > dl_mac_type table for looking these things up. Unfortunately,
> > > you're right that this isn't well maintained and that there is code
> > > that mandates this usage. Still, it's wrong.
> > >
> >
> > Mike Ditto also brought this up. I'm not sure what I can do about
> > this...
>
> Possibly nothing, but noting in the document that this is "known to be
> incorrect" might help.
>
> Given that we're proposing exposing tunnels in a new way (allowing
> things other than just IP to open and use them), it seems to me that
> this is a good point at which to look at this problem again.
I'd be more than glad to tackle this, but I think I need to do some
research before specifying the details in this doc. For now, I'll add
some text describing the broken use of SAP numbers with the intent to
update it once I've learned more about the existing mess in the ip
module...
>
> We could extend the existing ip_m_tbl[] array with entries for DL_IP*
> so that it uses a new SAP space here, so I don't see why using a
> fictitious "well-known" SAP is really required. To do better would
> probably involve creating some sort of extensible dl_mac_type-to-
> attributes table. (Certainly not required, but seems to have been
> needed many times now.)
Ok, I'll look into this.
> > > p22 top:
> [...]
> > Yes, it is, and the more I think about these differences, the more I
> > think they should be separate types. The reason that a single DL_IP
> > type is used is to match the kinds of packets that the IP observability
> > device (to be reviewed soon) will have access to. One observability
> > device (named bge0, for example) will have access to both IPv4 and IPv6
> > packets flowing over a single interface. DL_IPV4 or DL_IPV6 doesn't
> > describe this well at all. A version independent DL_IP does, and the
> > consumer of these observability devices can act on the version field of
> > the received IP headers.
>
> But the two devices seem to me to be very different.
Indeed.
>
> Though I haven't seen that document yet, the "DL_IP" observability
> device seems like an odd beast to me. Unlike a real tunnel, it's not
> something you can actually use for transmitting packets. And unlike a
> real tunnel, it doesn't seem to have a use for SAPs or even addresses
> in the conventional (DLPI) sense. Nor do I think it has any sort of
> status, like MTU or link up/down.
Correct.
>
> I _think_ that device is just a convenience for snoop and friends so
> that they don't have to learn about some new (possibly IP specific)
> mechanism to grab packets.
Exactly.
>
> So, I'm not sure how well the sharing works. (In fact, to avoid
> confusion, you might want to rename that as "DL_IP_SNOOP" or some
> such, to emphasize that it has just one goal in life.)
We'll discuss this possibility, and this will obviously come up again
when the IP-Level Observability Device design doc is posted here for
review.
>
> > > p24 10:
> > >
> > > Architectural issue: SMF doesn't really appear to be enough here.
> > > Users probably should be able to deal with systems that use DHCP,
> > > but they really can't today, unless DHCP just hands out static
> > > addresses.
> >
> > I don't understand the issue you're raising. Can you elaborate?
>
> I'm pointing out that SMF needs to be broken out on a per-interface
> basis if this mechanism is to be used with anything more complicated
> than static (hard-coded) addresses. Probably not an issue for now.
Ah, I see. Noted.
>
> > > My guess is that you want to have a single tunnel device that can be
> > > used for both v4 and v6 tunnels, and when the user opens the device,
> > > you won't know what dl_mac_type to return for DL_INFO_REQ until the
> > > tunnel is configured. But why not just have separate reserved minor
> > > nodes for v4 and v6, so the user can ask for what he really wants?
> >
> > This is actually not a problem at all. Once a tunnel link has been
> > created, the version of IP used by the link-layer is known from the
> > beginning based on the tunnel type. We always know whether the
> > link-layer of a tunnel is IPv4 or IPv6. An IPv4 interface can be
> > created on that tunnel by binding to the IPv4 SAP, and similarly for
> > IPv6 interfaces. No separate minor nodes are needed. The only reason
> > the MAC-types were collapsed was to match what the observability device
> > was using.
>
> I'm sort of confused by that.
What I meant was that the lack of information at open time is not the
motivation for DL_IP. I meant to imply that DL_IPV4 and DL_IPV6 could
easily have been used because the iptun driver knows the tunnel type at
creation time.
> If I open a tunnel driver instance and
> do DL_INFO_REQ, what is in the DL_INFO_ACK?
With the current design, DL_IP with appropriate address lenghts that are
based on the tunnel type.
> How do I tell what sort
> of addresses I'm supposed to feed into it? (Should I key off of the
> address length -- if it's 4, then it's IPv4, if it's 16, it's IPv6?
> Or should I use the tunnel-private ioctl to find out what "type" of
> tunnel it is?)
With the design as it is currently, either method would work, but
neither seems very practical. Really, even if I were to provide DL_IPV4
and DL_IPV6 MAC-types, there would still be the problem of whether a
destination is needed (that is also a function of the tunnel type). Is
the solution to create a different MAC-type for every tunnel type?
Hmmm...
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review (due 9/30)
Posted:
Oct 12, 2005 9:01 AM
in response to: seb
|
|
On Mon, 2005-10-10 at 16:26, Sebastien Roy wrote:
> > How do I tell what sort
> > of addresses I'm supposed to feed into it? (Should I key off of the
> > address length -- if it's 4, then it's IPv4, if it's 16, it's IPv6?
> > Or should I use the tunnel-private ioctl to find out what "type" of
> > tunnel it is?)
>
> With the design as it is currently, either method would work, but
> neither seems very practical. Really, even if I were to provide DL_IPV4
> and DL_IPV6 MAC-types, there would still be the problem of whether a
> destination is needed (that is also a function of the tunnel type). Is
> the solution to create a different MAC-type for every tunnel type?
> Hmmm...
The more I think about this (having a unique MAC-type for each tunnel
type), the more I think it makes sense. Some tunnel types will have
different SAP address spaces. For example, one cannot and should not be
allowed to configure an IPv4 interface on a 6to4 tunnel nor an automatic
tunnel, and thus one shouldn't be able to bind to the IPv4 SAP on such a
tunnel. The sole purpose of those tunnel links is to encapsulate IPv6
packets using IPv4... The MAC-types would also represent exactly what
kinds of IP interfaces the ip module should configure on these tunnels
without needing to use the kludgy capability mechanism currently defined
in the design doc.
Before I commit to such a scheme (assuming there are no strong
objections here), I'll go gather input from individuals (in addition to
you) who may have an opinion on this topic. I'll report back with a
decision either way.
Thanks,
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review (due 9/30)
Posted:
Oct 18, 2005 5:42 PM
in response to: seb
|
|
On Wed, 2005-10-12 at 12:01, Sebastien Roy wrote:
> The more I think about this (having a unique MAC-type for each tunnel
> type), the more I think it makes sense. Some tunnel types will have
> different SAP address spaces. For example, one cannot and should not be
> allowed to configure an IPv4 interface on a 6to4 tunnel nor an automatic
> tunnel, and thus one shouldn't be able to bind to the IPv4 SAP on such a
> tunnel. The sole purpose of those tunnel links is to encapsulate IPv6
> packets using IPv4... The MAC-types would also represent exactly what
> kinds of IP interfaces the ip module should configure on these tunnels
> without needing to use the kludgy capability mechanism currently defined
> in the design doc.
Based on private discussion, I believe that this is an acceptable design
decision (basically for the reasons I stated above). The design will
use the existing DL_IPV4 and DL_IPV6 to represent IPv4 and IPv6
configured tunnels respectively, and define a new DL_6TO4 to represent
6to4 tunnels. As we're EOL'ing automatic tunnels, no new type is needed
for that. :-)
I'll include this change in version 1.2 of the tunnel design document.
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
976
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device
Driver: design review (due 9/30)
Posted:
Oct 18, 2005 6:52 PM
in response to: seb
|
|
On Tue, 2005-10-18 at 20:42, Sebastien Roy wrote:
> Based on private discussion, I believe that this is an acceptable design
> decision (basically for the reasons I stated above). The design will
> use the existing DL_IPV4 and DL_IPV6 to represent IPv4 and IPv6
> configured tunnels respectively, and define a new DL_6TO4 to represent
> 6to4 tunnels. As we're EOL'ing automatic tunnels, no new type is needed
> for that. :-)
I didn't get a chance to respond earlier, but I agree with this.
looking at it from a policy enforcement perspective (ipsec & packet
filtering) this also makes a lot of sense -- different tunnel types may
require different extensions to the policy language to completely cover
the type of traffic that can go through the tunnel... using the mac
type as a indication of "can I understand what's going into/coming out"
might help out in mixing and matching....
- Bill
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,060
From:
Registered:
6/8/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review (due 9/30)
Posted:
Oct 17, 2005 11:28 PM
in response to: seb
|
|
> > Any guesses what GRE (with or without UDP underneath) might look
> > like? It's an oft-requested feature, and it'd be good to know at
> > least vaguely how we'll eventually get there, even if this project
> > isn't doing that work.
>
> I could see this being another IP tunnel type configured via dladm. The
> iptun driver could implement this type of tunneling. The link-layer
> header would be either IP and GRE, or IP, UDP, and GRE. The driver
> could either communicate directly with IP below it, or with UDP
> (assuming there's some interface to use UDP from
> within the kernel).
Is it beyond the scope of this project to add GRE support
to Solaris for tunnelling ?
Is there an RFE anywhere that we can add customer names
to for this (GRE) ?
Darren
|
|
|
|
|
Posts:
6,813
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Clearview IP Tunneling
Device Driver: design review (due 9/30)
Posted:
Oct 18, 2005 9:41 AM
in response to: darrenr
|
|
Darren Reed writes:
> Is it beyond the scope of this project to add GRE support
> to Solaris for tunnelling ?
I'd expect that it is. I agree that it'd be nice to have, but I don't
see how it is required by anything the project is doing.
> Is there an RFE anywhere that we can add customer names
> to for this (GRE) ?
One quick bugster search later: CR 6242750
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Re: Clearview IP Tunneling Device Driver:
design review (due 9/30)
Posted:
Oct 18, 2005 10:22 AM
in response to: darrenr
|
|
On Tue, 2005-10-18 at 02:28, Darren Reed wrote:
> Is it beyond the scope of this project to add GRE support
> to Solaris for tunnelling ?
Yes. New networking protocols are outside the scope of Clearview.
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review (due 9/30)
Posted:
Oct 13, 2005 5:01 PM
in response to: seb
|
|
I'd like to propose the following additional change to this design,
feedback is welcome:
Automatic tunnels (those that use IPv4-compatible IPv6 addresses, and
those of type "automatic" in the iptun design document) are being erased
from existence by the IETF.
The "Basic Transition Mechanisms for IPv6 Hosts and Routers" document
currently being edited as draft-ietf-v6ops-mech-v2-07.txt (meant to
eventually obsolete RFC2893) states:
10. Changes from RFC 2893
...
RFC 2893 contains a mechanism called automatic tunneling. But a much
more general mechanism is specified in RFC 3056 [RFC3056] which gives
each node with a (global) IPv4 address a /48 IPv6 prefix i.e., enough
for a whole site.
...
- Removed automatic tunneling and use of IPv4-compatible
addresses.
The general mechanism being referred to is 6to4, which is also supported
by the iptun driver.
Moreover, the "IP Version 6 Addressing Architecture" document currently
being edited as draft-ietf-ipv6-addr-arch-v4-04.txt (meant to eventually
obsolete RFC3513) states:
2.5.5.1 IPv4-Compatible IPv6 Address
...
The "IPv4-compatible IPv6 address" is now deprecated because the
current IPv6 transition mechanisms no longer use these addresses.
New or updated implementations are not required to support this
address type.
As such, the design document will be modified to EOL automatic tunnels
from Solaris. A new section will be written to document the reasoning
behind this EOL, and all functionality related to automatic tunnels will
be removed from this design.
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
1,992
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review (due 9/30)
Posted:
Oct 13, 2005 5:45 PM
in response to: seb
|
|
Sebastien Roy wrote:
...
>
> As such, the design document will be modified to EOL automatic tunnels
> from Solaris. A new section will be written to document the reasoning
> behind this EOL, and all functionality related to automatic tunnels will
> be removed from this design.
>
I absolutely support you doing this. Though I hadn't yet sent in any
comments on the spec, this was one that I was going to ask about since
my understanding had been that 6to4 was designed to supercede it.
Dave
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review
Posted:
Dec 6, 2005 3:09 PM
in response to: seb
|
|
I've incorporated the design review comments I've received, and also
done some prototyping of a Nemo MAC type plugin framework which I've
outlined in a companion design document. The resulting documents can be
found here:
http://opensolaris.org/os/community/networking/iptun-design.pdf
http://opensolaris.org/os/community/networking/nemo-mactype.pdf
The significant addition here is the MAC type plugin framework, and the
modifications to the IP Tunneling document to reflect its use of that
framework.
The only missing piece of this picture is how to abstract SAP spaces
from DLPI consumers for arbitrary MAC types. Currently, DLPI SAP spaces
are comprised of ethertypes for all DLPI providers, and at least two
reviewers of this design suggested that we move away from this misguided
association. I'll include an update the the nemo-mactype design when
I've done some more investigation into this.
In the meantime, I'd appreciate any comments on these updated
documents. Also, let me know if I've neglected to incorporate some of
your comments. I've attempted to address them all.
Thank you, your input has been invaluable so far.
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
619
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review
Posted:
Dec 7, 2005 9:09 AM
in response to: seb
|
|
Sebastien Roy wrote:
> I've incorporated the design review comments I've received, and also
> done some prototyping of a Nemo MAC type plugin framework which I've
> outlined in a companion design document. The resulting documents can be
> found here:
>
> http://opensolaris.org/os/community/networking/iptun-design.pdf
>
> http://opensolaris.org/os/community/networking/nemo-mactype.pdf
>
> The significant addition here is the MAC type plugin framework, and the
> modifications to the IP Tunneling document to reflect its use of that
> framework.
Seb,
In GLDv2 it was possible to have extended set of kstats for MAC types (I
think e.g. FDDI stats were defined). Is this already possible in GLDv3?
If not, it would be beneficial to add such a capability as part of the
MAC plugin framework. (An alternative would be to extend enum mac_stat
i.e., require a recompile to add type/driver-specific kstats.)
Two nits on the mactype document:
Section 3.4: Given that DL_ETHER is used for things other than IEEE
802.3 (such as WiFi), and IEEE 802.3ad link aggregation is only defined
for IEEE 802.3, I wonder if it would make sense to have a more exact way
to define where link aggregation can be used.
Section 3.5: Similarely, but in inverse. VLANs is an IEEE 802.1
standard, thus it applies to any(?) IEEE 802 standard at least in
theory. Even if the most wide-spread implementation and deployment is
for Ethernet, I don't know if we should restrict it to only apply to
Ethernet.
Erik
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
6,813
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review
Posted:
Dec 7, 2005 9:22 AM
in response to: nordmark
|
|
Erik Nordmark writes:
> Two nits on the mactype document:
> Section 3.4: Given that DL_ETHER is used for things other than IEEE
> 802.3 (such as WiFi), and IEEE 802.3ad link aggregation is only defined
> for IEEE 802.3, I wonder if it would make sense to have a more exact way
> to define where link aggregation can be used.
Interesting problem. I can find no particular protocol-related reason
to say that unmodified link aggregation wouldn't work with 802.11 as
well. Unless I'm missing something, it seems to be just a standards-
based restriction.
If that's so, should we have a way of saying, "all the stuff is in
place to make what you asked work, but we're not going to let you do
it because ieee.org says it's wrong?" I'm not sure whether or not
such restrictions are necessary and, if they are, whether it's a
matter for the tool or for documentation.
--
James Carlson, KISS Network <james dot d dot carlson at sun dot com>
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,046
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review
Posted:
Dec 7, 2005 6:41 PM
in response to: carlsonj
|
|
> > Section 3.4: Given that DL_ETHER is used for things other than IEEE
> > 802.3 (such as WiFi), and IEEE 802.3ad link aggregation is only defined
> > for IEEE 802.3, I wonder if it would make sense to have a more exact way
> > to define where link aggregation can be used.
>
> Interesting problem. I can find no particular protocol-related reason
> to say that unmodified link aggregation wouldn't work with 802.11 as
> well. Unless I'm missing something, it seems to be just a standards-
> based restriction.
I think so. The administrative architecture will certainly allow
aggregations to be formed over wireless links; the implementation is
another matter :-)
> If that's so, should we have a way of saying, "all the stuff is in
> place to make what you asked work, but we're not going to let you do
> it because ieee.org says it's wrong?"
Do they really say that?
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
619
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review
Posted:
Dec 8, 2005 11:28 AM
in response to: carlsonj
|
|
James Carlson wrote:
> Erik Nordmark writes:
>
>>Two nits on the mactype document:
>>Section 3.4: Given that DL_ETHER is used for things other than IEEE
>>802.3 (such as WiFi), and IEEE 802.3ad link aggregation is only defined
>>for IEEE 802.3, I wonder if it would make sense to have a more exact way
>>to define where link aggregation can be used.
>
>
> Interesting problem. I can find no particular protocol-related reason
> to say that unmodified link aggregation wouldn't work with 802.11 as
> well. Unless I'm missing something, it seems to be just a standards-
> based restriction.
Agreed. It was done by an IEEE 802.3 group and not an IEEE 802.1 group.
But there isn't anything preventing somebody from implementing the
protocol in some 802.something bridge as long as 802.something uses the
same reserved 6-byte MAC addresses to communicate with the bridge.
Erik
> If that's so, should we have a way of saying, "all the stuff is in
> place to make what you asked work, but we're not going to let you do
> it because ieee.org says it's wrong?" I'm not sure whether or not
> such restrictions are necessary and, if they are, whether it's a
> matter for the tool or for documentation.
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Andrew Gallatin
gallatin@cs.duke.edu
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review
Posted:
Dec 7, 2005 10:02 AM
in response to: nordmark
|
|
> Sebastien Roy wrote:
> >
> > http://opensolaris.org/os/community/networking/nemo-mactype.pdf
> >
> > The significant addition here is the MAC type plugin framework, and the
> > modifications to the IP Tunneling document to reflect its use of that
> > framework.
I just started looking at this when various people suggest I should be
writing a nemo, rather than gldv2 driver for my 10GbE nic.
I have a question about mtops_header() as described in 2.2.4.
Does this imply that every packet sent via a nemo driver from the stack
will begin with a teeny (14 byte if ethernet) header in a separate
mblk, which will necessitate a separate DMA?
Thanks,
Drew
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review
Posted:
Dec 7, 2005 10:18 AM
in response to: Andrew Gallatin
|
|
On Wed, 2005-12-07 at 13:02, Andrew Gallatin wrote:
> I just started looking at this when various people suggest I should be
> writing a nemo, rather than gldv2 driver for my 10GbE nic.
The Nemo driver interfaces are not public yet, but we're working on
fixing that.
>
> I have a question about mtops_header() as described in 2.2.4.
Great, keep the questions coming.
>
> Does this imply that every packet sent via a nemo driver from the stack
> will begin with a teeny (14 byte if ethernet) header in a separate
> mblk, which will necessitate a separate DMA?
Not necessarily. mtops_header() is only used in two places:
1. When IP asks for a link-layer header to use in every packet is sends
using fast-path (M_DATA). This only happens once when an IRE cache
entry is created for a particular on-link destination (look for where
ill_fastpath_probe() is called in ip). This data-path mechanism exists
precisely to avoid the situation you've described above; upper layers
can pre-allocate large buffers with enough space to include link-layer
header information along with the data.
2. When DLPI consumers use DL_UNITDATA_REQ to send packets. In this
case, yes, the link-layer header will end up as a separate mblk when the
packet is passed down to the MAC driver.
Does that answer your question?
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Andrew Gallatin
gallatin@cs.duke.edu
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review
Posted:
Dec 7, 2005 10:24 AM
in response to: seb
|
|
Sebastien Roy writes:
> Does that answer your question?
>
Yes, thanks. As long as they are not coming in the fast
path, that seems fine.
Thank you,
Drew
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
2,142
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review
Posted:
Dec 7, 2005 10:06 AM
in response to: nordmark
|
|
On Wed, 2005-12-07 at 12:09, Erik Nordmark wrote:
> In GLDv2 it was possible to have extended set of kstats for MAC types (I
> think e.g. FDDI stats were defined). Is this already possible in GLDv3?
> If not, it would be beneficial to add such a capability as part of the
> MAC plugin framework. (An alternative would be to extend enum mac_stat
> i.e., require a recompile to add type/driver-specific kstats.)
Thanks for bringing this up, this is not currently possible with GLDv3.
This definitely needs to be addressed, and I've thought about this
problem in the context of the prototype I have. I need to formalize the
method by which plugins will define new kstats in the nemo-mactype
document. I'll update you on this progress within the next few weeks.
>
> Two nits on the mactype document:
> Section 3.4: Given that DL_ETHER is used for things other than IEEE
> 802.3 (such as WiFi), and IEEE 802.3ad link aggregation is only defined
> for IEEE 802.3, I wonder if it would make sense to have a more exact way
> to define where link aggregation can be used.
Perhaps the plugin can tell Nemo at registration time whether links that
use that plugin can be aggregated using 802.3ad. This allows the
framework to be flexible while also restricting how the technology is
used.
>
> Section 3.5: Similarely, but in inverse. VLANs is an IEEE 802.1
> standard, thus it applies to any(?) IEEE 802 standard at least in
> theory. Even if the most wide-spread implementation and deployment is
> for Ethernet, I don't know if we should restrict it to only apply to
> Ethernet.
Ok, so maybe one piece of information the plugins can give at
registration time is whether they can handle VLANs. That should be easy
enough to define.
Thanks,
-Seb
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
619
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review
Posted:
Dec 8, 2005 11:31 AM
in response to: seb
|
|
Sebastien Roy wrote:
> Perhaps the plugin can tell Nemo at registration time whether links that
> use that plugin can be aggregated using 802.3ad. This allows the
> framework to be flexible while also restricting how the technology is
> used.
Good idea.
> Ok, so maybe one piece of information the plugins can give at
> registration time is whether they can handle VLANs. That should be easy
> enough to define.
That would work.
But in some cases (old hardware that can't handle frames larger than
1514 bytes?) it might only be the MAC driver that can tell that VLANs
are impossible. I don't know if you want to support such old hardware.
Erik
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
Posts:
3,046
From:
US
Registered:
3/9/05
|
|
|
|
Re: Clearview IP Tunneling Device Driver: design
review
Posted:
Dec 8, 2005 11:49 AM
in response to: nordmark
|
|
> But in some cases (old hardware that can't handle frames larger than
> 1514 bytes?) it might only be the MAC driver that can tell that VLANs
> are impossible. I don't know if you want to support such old hardware.
We will support it; check out the Nemo Unification design document that
Cathy just posted for details on how we propose to make that work safely.
--
meem
_______________________________________________
networking-discuss mailing list
networking-discuss at opensolaris dot org
|
|
|
|
|
