[RFC 1/5] gprs: Update documentation for IPv6
---
doc/connman-api.txt | 48 +++-
1 files changed, 43 insertions(+), 5 deletions(-)
diff --git a/doc/connman-api.txt b/doc/connman-api.txt
index 22c59dc..b885725 100644
--- a/doc/connman-api.txt
+++ b/doc/connman-api.txt
@@ -152,6 +152,15 @@ Properties boolean Active [readwrite]
Holds whether the context is activated. This value
can be set to activate / deactivate the context.
+ When the "Protocol" property is set to "ipv4v6",
+ oFono will first try to activate a combined "ipv4v6"
+ context (3GPP rel 8). Based on the result, oFono may
+ fall back to an IPv4 only or an IPv6 only context, or
+ activate separate IPv4 and IPv6 contexts under the
+ hood. The Protocol attribute is updated accordingly.
+ The "Settings" and "IPv6Settings" attributes will only
+ appear if the contained network settings are valid.
+
string AccessPointName [readwrite]
Holds the name of the access point. This is
@@ -182,7 +191,7 @@ Properties boolean Active [readwrite]
string Protocol [readwrite]
Holds the protocol for this context. Valid values
- are: "ip" and "ipv6".
+ are: "ip", "ipv6" and "ipv4v6".
string Name [readwrite]
@@ -196,8 +205,13 @@ Properties boolean Active [readwrite]
string Interface [readonly, optional]
- Holds the interface of the network interface
- used by this context (e.g. "ppp0" "usb0")
+ Holds the name of the IPv4 network interface
+ used by this context (e.g. "ppp0" "usb0").
+
+ For combined IPv4v6 context (3GPP rel 8) the
+ same network interface may be used for both
+ IPv4 and IPv6. IPv4 and IPv6 may also be
+ offered via separate network interfaces.
string Method [readonly, optional]
@@ -215,8 +229,8 @@ Properties boolean Active [readwrite]
array{string} DomainNameServers [readonly, optional]
- Holds the list of domain name servers for this
- context.
+ Holds the list of domain name servers accessible
+ via this network interface.
string Gateway [readonly, optional]
@@ -242,6 +256,30 @@ Properties boolean Active [readwrite]
via this proxy. All other values are left
out in this case.
+ dict IPv6Settings [readonly, optional]
+
+ Holds all the IPv6 network settings.
+
+ string Interface [readonly, optional]
+
+ Holds the name of the IPv6 network interface
+ used by this context (e.g. "ppp0" "usb0").
+
+ For combined IPv4v6 context (3GPP rel 8) the
+ same network interface may be used for both
+ IPv4 and IPv6. IPv4 and IPv6 may also be
+ offered via separate network interfaces.
+
+ string LinkLocal [readonly, optional]
+
+ Holds the IPv6 link local address for this
+ context.
+
+ array{string} DomainNameServers [readonly, optional]
+
+ Holds the list of domain name servers accessible
+ via this network interface.
+
string MessageProxy [readwrite, MMS only]
Holds the MMS Proxy setting.
--
1.7.1
___
ofono mailing list
ofono@ofono.org
http://lists.ofono.org/listinfo/ofono
Re: [RFC 1/5] gprs: Update documentation for IPv6
Hi, > + dict IPv6Settings [readonly, optional] > + > + Holds all the IPv6 network settings. > + > + string Interface [readonly, optional] > + > + Holds the name of the IPv6 network interface > + used by this context (e.g. "ppp0" "usb0"). > + > + For combined IPv4v6 context (3GPP rel 8) the > + same network interface may be used for both > + IPv4 and IPv6. IPv4 and IPv6 may also be > + offered via separate network interfaces. > + I think it would be nice if we could keep only one interface here. It's a bit messy that the difference between R7 and R8 networks will be visible to the users like this. So when in a R7 network the uplink traffic should be filtered into the right ipv4 and ipv6 pdp-connection automagically. I know STE will support this in the modem firmware. If firmware doesn't support this perhaps this could also be handled in the kernel drivers. This should be doable for phonet (and Caif), maybe a little more tricky with ppp/pppd? Regards, Sjur ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC 1/5] gprs: Update documentation for IPv6
Hi Sjur, > > + For combined IPv4v6 context (3GPP rel 8) the > > + same network interface may be used for both > > + IPv4 and IPv6. IPv4 and IPv6 may also be > > + offered via separate network interfaces. > > + > > I think it would be nice if we could keep only one interface here. > It's a bit messy that the difference between R7 and R8 > networks will be visible to the users like this. By users I assume you mean connman? > So when in a R7 network the uplink traffic should be filtered into the > right ipv4 and ipv6 pdp-connection automagically. > I know STE will support this in the modem firmware. It's cool that STE firmware can do that. However, for modems that don't (most of them), I frankly don't see any particular reason to try to bond the bearers within the kernel. That would just bring more complexity to the kernel drivers without providing any real benefit. The Linux networking stack will handle separate interfaces just fine. The IPv4 default route can point to one interface and IPv6 routes can point to another and everything will just work. Naturally connman will need to understand about the separate interfaces in order to configure them properly but that is a minor pain compared to doing bonding separately in each modem interface driver within the kernel. Br, MikaL ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC 1/5] gprs: Update documentation for IPv6
Hi Mika, > > > + For combined IPv4v6 context (3GPP rel 8) the > > > + same network interface may be used for both > > > + IPv4 and IPv6. IPv4 and IPv6 may also be > > > + offered via separate network interfaces. > > > + > > > > I think it would be nice if we could keep only one interface here. > > It's a bit messy that the difference between R7 and R8 > > networks will be visible to the users like this. > > By users I assume you mean connman? > > > So when in a R7 network the uplink traffic should be filtered into the > > right ipv4 and ipv6 pdp-connection automagically. > > I know STE will support this in the modem firmware. > > It's cool that STE firmware can do that. However, for modems that don't (most > of them), I frankly don't see any particular reason to try to bond the > bearers within the kernel. That would just bring more complexity to the > kernel drivers without providing any real benefit. The Linux networking stack > will handle separate interfaces just fine. The IPv4 default route can point > to one interface and IPv6 routes can point to another and everything will > just work. > > Naturally connman will need to understand about the separate interfaces in > order to configure them properly but that is a minor pain compared to doing > bonding separately in each modem interface driver within the kernel. I am not sure it is a good idea to make ConnMan do that. For IFX, I was actually considering just piping the two RawIP streams into one network interface. That seems easy enough. And to be honest for PPP, just doing IPv4 seems acceptable since PPP is bad idea in the first place. It is a limitation I am willing to accept. My concern is also on how we handle the Tethering cases properly. I have not yet spent enough time to think about it, but I have concerns here. So right now I would prefer to sit ipv6 out until we have proper ipv4v6 context support in the network and the modems. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC 1/5] gprs: Update documentation for IPv6
On Friday 28 January 2011 14:49:16 ext Sjur Brændeland, you wrote: > I think it would be nice if we could keep only one interface here. > It's a bit messy that the difference between R7 and R8 > networks will be visible to the users like this. > > So when in a R7 network the uplink traffic should be filtered into the > right ipv4 and ipv6 pdp-connection automagically. > I know STE will support this in the modem firmware. > > If firmware doesn't support this perhaps this could also be handled > in the kernel drivers. This should be doable for phonet (and Caif), Not really no. The API to create a Phonet gprs interface is tightly coupled with the underlying pipe. There are no easy ways to patch the driver to use two pipes, nor the corresponding userspace code. It would actually be much easier to write a bonding driver to rule both IPv4 and IPv6 instances of the existing driver. It would also be more generic, not Phonet/CAIF/PPP-specific, although it would probably not work for fake Ethernet devices. However it is questionable why we would optimize this when the only customer is ConnMan, and the only use case is 3GPP Rel7. Applications don't need to care whether IPv4 and IPv6 are through a single or two separate interfaces. They just use the socket API. -- Rémi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
Re: [RFC 1/5] gprs: Update documentation for IPv6
On Friday 28 January 2011 16:17:04 ext Marcel Holtmann, you wrote: > I am not sure it is a good idea to make ConnMan do that. For IFX, I was > actually considering just piping the two RawIP streams into one network > interface. That seems easy enough. > > And to be honest for PPP, just doing IPv4 seems acceptable since PPP is > bad idea in the first place. It is a limitation I am willing to accept. > > My concern is also on how we handle the Tethering cases properly. I have > not yet spent enough time to think about it, but I have concerns here. > > So right now I would prefer to sit ipv6 out until we have proper ipv4v6 > context support in the network and the modems. I would want to do that too. But my current guesstimate is that we will have to support dual-stack before we can assume dual-stack support in both the networks and the modems. This limitation might be acceptable for tethering though, which is the main customer for PPP. -- Rémi Denis-Courmont Nokia Devices R&D, Maemo Software, Helsinki ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC 1/5] gprs: Update documentation for IPv6
Hi Mika, > > I am not sure it is a good idea to make ConnMan do that. > > Why is that? we need to chat with Samuel about this. I foresee a bunch of issues trying to handle two context properly. This needs a bit more deeper thinking on how things are done. > > And to be honest for PPP, just doing IPv4 seems acceptable > > since PPP is > > bad idea in the first place. It is a limitation I am willing > > to accept. > > Yeah, PPP is not really a requirement for us, although it would be convenient > to have it for testing. As a matter of fact, I would already have trialed > atmodem support for IPv6 but that was blocked because of the lack of IPV6CP > support in oFono PPP implementation. Too bad. We have a TODO item open for that. So far nobody really bothered, because either the hardware did not support it or the network did not. But hey, patches are welcome ;) > > My concern is also on how we handle the Tethering cases > > properly. I have > > not yet spent enough time to think about it, but I have concerns here. > > Ok. Can you outline your concerns so we can talk about them? We are currently Tethering to one specific service with the assumption that it maps to one interface of the kernel. If that assumption is not true anymore, then we have to re-think this. Not sure if we should be bothered. But then again, on the other hand for IPv6 Tethering, don't wanna use NAT anyway. So that might be not an issue after all. This really needs some more thinking. I have no clear answers at the moment. > > So right now I would prefer to sit ipv6 out until we have > > proper ipv4v6 > > context support in the network and the modems. > > I'd like to progress with this. We also have people who are keen to help out > on the connman side. Just sitting and waiting for better times is not really > an approach I'd prefer to take. > > Currently, we only discussing whether the "Interface" setting is needed > separately in IPv4 and IPv6 settings or not. That's a minor detail as far as > I am concerned. For now, allowing separate network interfaces for IPv4 and > IPv6 is convenient for testing the IPv6 support on current modems. If it > turns out to be hugely difficult to manage separate interface on connman > side, we can always restrict the approach and drop support for older modems > when rel8 modems are available. So I like the ST-Ericsson approach where this details is abstracted in the modem firmware. Regards Marcel ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC 1/5] gprs: Update documentation for IPv6
Hi Marcel, > Hi Mika, > > > > I am not sure it is a good idea to make ConnMan do that. > > > > Why is that? > > we need to chat with Samuel about this. I foresee a bunch of issues > trying to handle two context properly. This needs a bit more deeper > thinking on how things are done. Ok. But again, can't really comment unless you guys come out with the actual issues. > > fact, I would already have trialed atmodem support for IPv6 > > but that was blocked because of the lack of IPV6CP support in > > oFono PPP implementation. Too bad. > > We have a TODO item open for that. So far nobody really bothered, > because either the hardware did not support it or the network did not. > > But hey, patches are welcome ;) I'm more interested in the core support at the moment. > > > My concern is also on how we handle the Tethering cases > > > properly. I have > > > not yet spent enough time to think about it, but I have > concerns here. > > > > Ok. Can you outline your concerns so we can talk about them? > > We are currently Tethering to one specific service with the assumption > that it maps to one interface of the kernel. If that assumption is not > true anymore, then we have to re-think this. Not sure if we should be > bothered. IPv4 and IPv6 are completely orthogonal, so I don't really see the problem you're alluding to here. > I have no clear answers at the moment. I believe the main question really is "How to do tethering with IPv6?". Clearly it needs to be thought out but I don't see why that work should block implementation of basic IPv6 access. You can start with IPv4 only tethering and just ignore IPv6 in the beginning. > > > So right now I would prefer to sit ipv6 out until we have > > > proper ipv4v6 > > > context support in the network and the modems. > > > > I'd like to progress with this. We also have people who are > keen to help out on the connman side. Just sitting and > waiting for better times is not really an approach I'd prefer to take. > > > > Currently, we only discussing whether the "Interface" > setting is needed separately in IPv4 and IPv6 settings or > not. That's a minor detail as far as I am concerned. For now, > allowing separate network interfaces for IPv4 and IPv6 is > convenient for testing the IPv6 support on current modems. If > it turns out to be hugely difficult to manage separate > interface on connman side, we can always restrict the > approach and drop support for older modems when rel8 modems > are available. > > So I like the ST-Ericsson approach where this details is abstracted in > the modem firmware. That's not an answer though, unless we only plan to support STE hardware in oFono. Br, MikaL ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
RE: [RFC 1/5] gprs: Update documentation for IPv6
Hi Marcel, > I am not sure it is a good idea to make ConnMan do that. Why is that? > And to be honest for PPP, just doing IPv4 seems acceptable > since PPP is > bad idea in the first place. It is a limitation I am willing > to accept. Yeah, PPP is not really a requirement for us, although it would be convenient to have it for testing. As a matter of fact, I would already have trialed atmodem support for IPv6 but that was blocked because of the lack of IPV6CP support in oFono PPP implementation. Too bad. > My concern is also on how we handle the Tethering cases > properly. I have > not yet spent enough time to think about it, but I have concerns here. Ok. Can you outline your concerns so we can talk about them? > So right now I would prefer to sit ipv6 out until we have > proper ipv4v6 > context support in the network and the modems. I'd like to progress with this. We also have people who are keen to help out on the connman side. Just sitting and waiting for better times is not really an approach I'd prefer to take. Currently, we only discussing whether the "Interface" setting is needed separately in IPv4 and IPv6 settings or not. That's a minor detail as far as I am concerned. For now, allowing separate network interfaces for IPv4 and IPv6 is convenient for testing the IPv6 support on current modems. If it turns out to be hugely difficult to manage separate interface on connman side, we can always restrict the approach and drop support for older modems when rel8 modems are available. Br, MikaL ___ ofono mailing list ofono@ofono.org http://lists.ofono.org/listinfo/ofono
