Subject: Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed

From: jouni korhonen <[email-masked]>
Date: Thu, 1 Dec 2011 18:43:26 +0200

On Nov 30, 2011, at 8:18 PM, Tao Sun wrote:

> Forgot to include a website link in the previous email. Now I included it.
>  
> Regards,
>  
> Tao Sun
> 
> On Thu, Dec 1, 2011 at 2:13 AM, Tao Sun <[email-masked]> wrote:
> Hi All,
>  
> Thanks for the discussion. As one of the author of the draft, I would like to share our view on DHCPv6 used case in three aspects.
> *Network management and configuration.
> 1. It is efficient for the network to configure this in a central DHCPv6 server to do unified routing policy configuration. The gateways (e.g., GGSN in cellular network) only need to perform DHCPv6 relay.

Just want to point out that 3GPP specs do not define/mandate DHCPv6 relay function in GGSN/PGW.. It is a server when seen from the UE point of view.

[snip]

- JOuni

---

From: Tao Sun <[email-masked]>
Date: Fri, 2 Dec 2011 01:07:49 +0800

Thanks for the discussion. Inline please.

On Thu, Dec 1, 2011 at 2:48 AM, Lorenzo Colitti <[email-masked]> wrote:

>  On Wed, Nov 30, 2011 at 10:13, Tao Sun <[email-masked]> wrote:
>
>> **Cellular network
>>
>> 1.       In cellular network, DHCPv6 is used for IPv6 parameter
>> configuration and RA is used for SLAAC of handset. This is start from 3GPP
>> release 8 (or earlier).
>>
>> 2.       The network gateway in cellular network (e.g., GGSN) can
>> naturally support DHCPv6 extension since the gateway acts as a DHCPv6
>> relay. However, it is very hard to update those gateways to use RA
>> announcing the route information.
>>
>> 3.       The handsets with MIF feature need to visit subscribed/operator
>> provided service. Some traffic is routed to the operator’s network through
>> 3G interface instead of to Internet through WiFi.  DHCPv6 will be used
>> to configure these specific routes.
>>
>
> You can already do this today with RIOs, and I don't see why there need to
> be two ways of doing the same thing. Adding a different method to configure
> the same information is twice the code and more than twice the complexity,
> since when you have two sources of information with different semantics you
> need to figure out how to merge them, what happens if they disagree, what
> to do if one is wrong, what to do if one expires, and so on.
>
We can not do this today. As 1 and 2 mentioned, both the deployed gateway
and the 3GPP specification need to be updated to use RIO.
I agree we need to consider the disagree/confliction among policies. That
is caused by the multiple interface feature. If you use RA for all the
interfaces, the rule received may still conflict. Addressing the
confliction is exactly what MIF WG shall consider IMHO.

>  Also, in the mobile case I don't understand how you would use a
> different gateway anyway. The mobile network is a point-to-point link, so
> there's no way to distinguish multiple gateways. How would you use this?
>
>
There are two types of scenarios. 1) A host is connected to the mobile
network and WiFi at the same time, a typical scenario of MIF. 2) A mobile
host connects to multiple APNs simultaneously, i.e., multiple PDN
connection is established. The type 2) scenrio is also considered to be
addressed in the OPIIS (Operator Policies for IP Interface Selection) work
item in 3GPP.

>   ***Broadband network
>>
>> 1.       WiFi network. Some WiFi hotspots provide local services. The
>> route configuration on RG is needed to direct some traffic to local network
>> while other traffic to the Internet.
>>
>
> I don't understand why you need host changes to do this. Since the hotspot
> router is a router, it can simply forward the packets the right way by
> itself.
>
>
You may refer to the  Section of 3.4 of this draft or Section 5.2 of RFC
4191.

>   2.       VPN network. When a user connect to enterprise VPN network,
>> the routing of VPN traffic need to be configured. Due to the large number
>> of such VPN network, we cannot assume all the VPN network only use RA.
>> DHCPv6 provides another choice which may be preferred by the VPN network.
>>
>
> The rationale here seems to be that "if we create a new option, some
> networks might use it". That's certainly true, but it doesn't provide a
> compelling reason why we need the option in the first place.
>
To us, its a compelling reason due to the network managment/operation,
per-subscriber service, foresee burden of modification to existing gateway
and specifications.

Best Regards,

Tao

---

From: Tao Sun <[email-masked]>
Date: Fri, 2 Dec 2011 01:24:08 +0800

Hi Jouni,

Thanks for the clarification. That is ture GGSN/PGW is not mandate to do
relay. "May" instead of "shall" is used to describe GGSN/PGW's action. The
only mandate is to use RA to obtain /64 prefix.

Regards,

Tao
On Fri, Dec 2, 2011 at 12:43 AM, jouni korhonen <[email-masked]>wrote:

> > Thanks for the discussion. As one of the author of the draft, I would
> like to share our view on DHCPv6 used case in three aspects.
> > 1. It is efficient for the network to configure this in a central DHCPv6
> server to do unified routing policy configuration. The gateways (e.g., GGSN
> in cellular network) only need to perform DHCPv6 relay.
>
> Just want to point out that 3GPP specs do not define/mandate DHCPv6 relay
> function in GGSN/PGW.. It is a server when seen from the UE point of view.
>
> [snip]
>
> - JOuni
>
>
>
>

---

From: Tao Sun <[email-masked]>
Date: Fri, 2 Dec 2011 01:45:41 +0800

On Thu, Dec 1, 2011 at 7:23 AM, Lorenzo Colitti <[email-masked]> wrote:

>  On Wed, Nov 30, 2011 at 13:30, Brian E Carpenter <
> [email-masked]> wrote:
>
>> To me this is a killer argument. A general solution that is applicable
>> to all deployment scenarios is vastly better than a free-for all of
>> vendor options, which will increase the implementation burden for
>> everybody and reduce the chances of smooth zero-conf operation.
>>
>
> Actually, what decreases the implementation burden is not having the
> option at all. The use cases I've heard so far for this option are all a
> bit specious and I think they are outweighed by the harm that would be
> caused if this option were to get into general use.
>
Form the discussion in this thread, the use cases exist in BBF and cellular
network, apply to host and RG/CPE and are met by individual user and
network operators. To me, they are not specious.

>
> The reasoning goes something like this:
>
> 1. The option is defined.
> 2. OS foo implements it.
> 3. Some network, somewhere, decides that they're only going to use DHCPv6
> for routing, because they only support OS foo.
> 4. Other OSes are forced to implement the option because if they don't,
> they are at a disadvantage compared to OS foo
> 5. Once all OSes implement it, some other network, somewhere else, decides
> that they're only going to support DHCPv6 for routing because it's easier
> and because it matches what they do in IPv4, so they turn off RAs.
>
You need not worry about turning off RAs. RA is mandated for mobile host to
abtain /64 prefix in cellular network. While, for DHCPv6, you anyway need
to switch on it IMHO. When you enable the tethering feature, the mobile
host shall use DHCPv6 for prefix delegation.

>  Then we have a problem, because DHCPv6 has much less rich semantics than
> RAs in the general case. A few examples:
>
> - DHCPv6 is static. A lease is a promise and it can't be deprecated except
> by the server that originally made the promise. If that server is not
> around any more, or if clients don't support reconfigure, it can't be
> deprecated at all. You can work around this with short lease times, but
> that creates a scaling problem on the DHCPv6 server, because it's
> centralized.
> - The way the standards and the clients are written, clients pick one
> DHCPv6 advertise and stick to it. So they can't merge multiple sources of
> information.
> - DHCPv6 does not share fate with routing; in fact, it has no knowledge of
> routing.
> - The combination of the fact that you can't merge multiple sources of
> information and the fact that you can only provide static information means
> that you're basically forced to hand out stuff that doesn't change. If
> you're using DHCPv6 to set the default router, that basically means you're
> forced to use VRRP or NAT if you want any sort of redundancy.
>
> To me, the lack of functionality that will result if we take the path of
> least resistance described above far outweighs the benefits of being able
> to configure [default] routes and on-link prefixes on a per-host basis. You
> can do this in lots of other ways, for example assigning the hosts you want
> to treat differently to different VLANs.
>
Here we discuss host with multiple interface. I am not sure how VLAN can be
used here. This also introduced the extra complexity.

>
>  >> 2) Per user/host configuration makes DHCPv6 be used for the
>> >> on-demand configuration.
>>
>> RA/RIO does not meet this requirement, which is a real requirement
>> in networks with heterogeneous types of host. DHCPv6 does meet this
>> requirement.
>>
>
> You can use selective unicast router advertisements for this if you want.
> There's no reason you can't look the RA properties in RADIUS. And of
> course, you can put the separate hosts on separate VLANs (which is probably
> the right thing to do in general).
>

If you use selective unicast RA for those on-demand subscribers, you are
more likely using RA in a stateful way. The benefits of RA is lost.

Regards,
Tao

> _______________________________________________
> mif mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/mif
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 09:59:51 -0800

> and the 3GPP specification need to be updated to use RIO.

What I meant is that a protocol and IETF perspective, you can do this today
using RIOs. So the protocol is there if 3GPP wants to use it. The
3GPP specs need to be updated regardless of whether we decide to
standardize the proposed DHCPv6 route option or not.

> confliction is exactly what MIF WG shall consider IMHO.

It is not caused by having multiple interfaces, it is caused by the fact
that there are potentially two sources of information. It can happen even
on only one interface, if the network on that interface supports both RAs
and DHCPv6 route.

> addressed in the OPIIS (Operator Policies for IP Interface Selection)
> work item in 3GPP.
>

#1 can't be solved using either the DHCPv6 route option or RIOs because in
general the carrier network doesn't know the IPv6 address of the default
gateway on the wifi network.
#2 can be fixed both using DHCPv6 route option and using RIOs.

>> I don't understand why you need host changes to do this. Since the
>> hotspot router is a router, it can simply forward the packets the right way
>> by itself.
>>
>>

I don't see how Section 3.4 of this draft ("applicability to routers") is
relevant to this discussion. Section 5.2 of RFC 5191 describes a different
scenario (two routers on the same link) than the one you suggested here
(one router on a given link).

> per-subscriber service, foresee burden of modification to existing gateway

Who is "us", and what is the use case? I don't see why the ones discussed
so far can't use RIOs.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 10:06:15 -0800

On Thu, Dec 1, 2011 at 09:45, Tao Sun <[email-masked]> wrote:

> Form the discussion in this thread, the use cases exist in BBF and
> cellular network, apply to host and RG/CPE and are met by individual user
> and network operators. To me, they are not specious.
>

I can see the BBF use case, but that seems to be a rather specific use case
and could be solved using a BBF-specific option. I can't see the cellular
use case, since the cellular network already uses RAs.

>> 5. Once all OSes implement it, some other network, somewhere else,
>> decides that they're only going to support DHCPv6 for routing because it's
>> easier and because it matches what they do in IPv4, so they turn off RAs.
>>
> You need not worry about turning off RAs. RA is mandated for mobile host
> to abtain /64 prefix in cellular network. While, for DHCPv6, you
> anyway need to switch on it IMHO. When you enable the tethering
> feature, the mobile host shall use DHCPv6 for prefix delegation.
>

I'm not talking about mobile networks specifically here. I think this
particular event (turning off RAs) is more likely that to happen on a wifi
network or an enterprise network.

>   To me, the lack of functionality that will result if we take the path
>> of least resistance described above far outweighs the benefits of being
>> able to configure [default] routes and on-link prefixes on a per-host
>> basis. You can do this in lots of other ways, for example assigning the
>> hosts you want to treat differently to different VLANs.
>>
> Here we discuss host with multiple interface. I am not sure how VLAN can
> be used here. This also introduced the extra complexity.
>

The DHCPv6 route option has nothing to do with multiple interfaces. It is
equally applicable to a use case where you have only one interface.

As regards VLANs: my point was that if you want different hosts to have
different gateways, you can put them on different VLANs and have different
RAs on each VLAN. You don't have to do it via DHCPv6.

>From the network point of view maybe. But not from the point of view of the
node that is receiving the RA. That node can still support / merge multiple
sources of information; it only needs to support one protocol (RA) to
configure routes and doesn't need the additional complexity that comes from
supporting two ways to configure the same thing; and so on.

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Dec 2011 18:19:31 +0000

On Dec 1, 2011, at 1:06 PM, Lorenzo Colitti wrote:
As regards VLANs: my point was that if you want different hosts to have different gateways, you can put them on different VLANs and have different RAs on each VLAN. You don't have to do it via DHCPv6.

If we are deciding between a DHCPv6 route option and requiring people to set up VLANs for every customer, I think it's pretty clear which choice is less onerous.   I think you need a better argument here—I agree that there should be only one source of routing info, but this is a better argument against that position than in favor of it.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 01 Dec 2011 19:27:20 +0100

Le 01/12/2011 00:23, Lorenzo Colitti a écrit :
> On Wed, Nov 30, 2011 at 13:30, Brian E Carpenter
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> 3. Some network, somewhere, decides that they're only going to use
> DHCPv6 for routing, because they only support OS foo.
> decides that they're only going to support DHCPv6 for routing because
> it's easier and because it matches what they do in IPv4, so they turn
> off RAs.
>
> RAs in the general case.

Yes, but generally speaking each is less rich than the other.  Whereas 
DHCPv6 does not communicate RA's MTU, RA does not communicate DHCPv6's 
printer lists.

Alex

> A few examples:
>
> - DHCPv6 is static. A lease is a promise and it can't be deprecated
> except by the server that originally made the promise. If that server is
> not around any more, or if clients don't support reconfigure, it can't
> be deprecated at all. You can work around this with short lease times,
> but that creates a scaling problem on the DHCPv6 server, because it's
> centralized.
> DHCPv6 advertise and stick to it. So they can't merge multiple sources
> of information.
> - DHCPv6 does not share fate with routing; in fact, it has no knowledge
> of routing.
> information and the fact that you can only provide static information
> means that you're basically forced to hand out stuff that doesn't
> change. If you're using DHCPv6 to set the default router, that basically
> means you're forced to use VRRP or NAT if you want any sort of redundancy.
>
> least resistance described above far outweighs the benefits of being
> You can use selective unicast router advertisements for this if you
> want. There's no reason you can't look the RA properties in RADIUS. And
> of course, you can put the separate hosts on separate VLANs (which is
> probably the right thing to do in general).
>
>

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Dec 2011 18:29:55 +0000

On Dec 1, 2011, at 1:27 PM, Alexandru Petrescu wrote:
Yes, but generally speaking each is less rich than the other.  Whereas DHCPv6 does not communicate RA's MTU, RA does not communicate DHCPv6's printer lists.

What Lorenzo is talking about when he says DHCP is less rich is that DHCP clients are currently required to choose one provisioning domain when more than one is present.   It has nothing to do with what options are on offer.

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 01 Dec 2011 19:30:27 +0100

Le 01/12/2011 17:43, jouni korhonen a écrit :
>> On Thu, Dec 1, 2011 at 2:13 AM, Tao Sun<[email-masked]> wrote:
>> Hi All,
>>
>> Thanks for the discussion. As one of the author of the draft, I
>> would like to share our view on DHCPv6 used case in three aspects.
>>  *Network management and configuration. 1. It is efficient for the
>> network to configure this in a central DHCPv6 server to do unified
>> routing policy configuration. The gateways (e.g., GGSN in cellular
>> network) only need to perform DHCPv6 relay.
>
> Just want to point out that 3GPP specs do not define/mandate DHCPv6
> relay function in GGSN/PGW..

Yes, but there are 3GPP specs implying that the DHCP Server is _not_ the
PGW and the DHCP Server is somewhere outside the 3GPP operator network
("external" config or so).  At which point the only possibility to keep
PGW able to participate in DHCP configuration is PGW to be a Relay.
This may be an assumption silently made by the 3GPP specs, or a
misunderstanding from my part.

Alex

  It is a server when seen from the UE
> point of view.
>
> [snip]
>
> - JOuni
>
>
>
> _______________________________________________ mif mailing list
> [email-masked] https://www.ietf.org/mailman/listinfo/mif
>

---

From: Alexandru Petrescu <[email-masked]>
Date: Thu, 01 Dec 2011 19:40:28 +0100

Le 01/12/2011 18:24, Tao Sun a écrit :
> Hi Jouni, Thanks for the clarification. That is ture GGSN/PGW is not
> mandate to do relay. "May" instead of "shall" is used to describe
> GGSN/PGW's action. The only mandate is to use RA to obtain /64
> prefix.

And that mandate is not sufficient when the UE is actually a Router
("mobile hotspot", "tethering").  For these cases, DHCPv6-PD is
suggested by 3GPP specs.  Thus, the 3GPP specs assume that a UE-Router
(new term for this conversation) runs both RA _and_ DHCP.  But 3GPP
specs overlook the fact that an UE-Router would't use RA to
auto-configure an address (stateless autoconf is only for Hosts).  Hence
3GPP specs could consider that _only_ DHCP should should be used by
DHCPv6.  In this sense, the above only mandate ("use RA to obtain /64
prefix") could be dropped altogether.

Alex

> Regards, Tao On Fri, Dec 2, 2011 at 12:43 AM, jouni korhonen
> <[email-masked] <mailto:[email-masked]>> wrote:
>
>
>
>> On Thu, Dec 1, 2011 at 2:13 AM, Tao Sun <[email-masked]
> <mailto:[email-masked]>> wrote:
>> Hi All,
>>
>> network to configure this in a central
> DHCPv6 server to do unified routing policy configuration. The
> gateways (e.g., GGSN in cellular network) only need to perform DHCPv6
> relay.
>
> relay function in GGSN/PGW.. It is a server when seen from the UE
> point of view.
>
> [snip]
>
> - JOuni
>
>
>
>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 11:19:07 -0800

On Thu, Dec 1, 2011 at 10:19, Ted Lemon <[email-masked]> wrote:

> If we are deciding between a DHCPv6 route option and requiring people to
> set up VLANs for every customer, I think it's pretty clear which choice is
> less onerous.
>

Why? In BBF scenarios, the VLANs are almost always created on-demand. I
think that was one of the major use cases presented for this option, right?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 11:22:44 -0800

On Thu, Dec 1, 2011 at 10:40, Alexandru Petrescu <
[email-masked]> wrote:

> auto-configure an address (stateless autoconf is only for Hosts).

That's not true - RFC 6204 says that an IPv6 CE router can use autoconf to
create an address. I think it's reasonable to say that if you were to
implement tethering using DHCPv6 PD, you would follow RFC 6204.

> Hence 3GPP specs could consider that _only_ DHCP should should be used
> by DHCPv6.  In this sense, the above only mandate ("use RA to obtain
> /64 prefix") could be dropped altogether.
>

See what I mean? We're already talking about not using RAs at all any more,
and we don't even have a DHCPv6 route option yet...

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Dec 2011 19:35:01 +0000

On Dec 1, 2011, at 2:19 PM, Lorenzo Colitti wrote:
Why? In BBF scenarios, the VLANs are almost always created on-demand. I think that was one of the major use cases presented for this option, right?

I don't actually know what the BBF is doing.   If they are creating per-customer VLANs in this case, then you're right.   But I think the intention here was to have less state in the edge routers, not more.   Using dynamically-created per-customer VLANs isn't less state.

---

From: jouni korhonen <[email-masked]>
Date: Thu, 1 Dec 2011 21:59:49 +0200

Actually.. to be more precise. Stage-2 and stage-3 have a slightly different view on this "DHCP matter", and depending on spec and whether it is about v4 or v6. I did remember with a bit lag there was something fishy about this ;)  

So, lets put in this way. There should not be a DHCPv6 relay in GGSN/PGW according to architecture, rather explicitly stated server and client functions. However, protocol specs do give an example of relay functionality. Therefore, we can assume someone actually might have implemented a relay in GGSN/PGW.

- Jouni

On Dec 1, 2011, at 7:24 PM, Tao Sun wrote:

> Hi Jouni,
>  
> Thanks for the clarification. That is ture GGSN/PGW is not mandate to do relay. "May" instead of "shall" is used to describe GGSN/PGW's action. The only mandate is to use RA to obtain /64 prefix.
>  
> Regards,
>  
> Tao
> On Fri, Dec 2, 2011 at 12:43 AM, jouni korhonen <[email-masked]> wrote:
> 
>

---

From: jouni korhonen <[email-masked]>
Date: Thu, 1 Dec 2011 22:17:51 +0200

On Nov 30, 2011, at 11:30 PM, Brian E Carpenter wrote:

[snip]

>>> 3) The centralized relay architecture is a widely
>>> used way at present for IPv4 and it will also be used for IPv6. 
> 
> That's the wrong way to say it IMHO. There are sound reasons why
> operators want a centralised host management system with distributed
> relays. The fact that the solution for IPv4 is called DHCP doesn't
> imply that the best solution for IPv6 is called DHCPv6. However, until
> there is a well-defined central management system for prefix delegation
> and routing options via RA, it seems that DHCPv6 *is* the only available

Like AAA? That is used and will be used a lot for address & prefix management, and can also be used for distributing per subscriber route information. 

> solution. And then we loop back to point 1): it's better to have a generic
> option than a bunch of competing vendor options.

I would not say competing vendor but competing SDO options.

- Jouni

>   Brian

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Dec 2011 10:14:59 +1300

I'm not going to repeat my arguments because Tao Sun is doing
a great job of explaining why DHCPv6 is going to be used in any
case. But on one point...

On 2011-12-02 07:06, Lorenzo Colitti wrote:
...

> network or an enterprise network.

I really don't see that as a real risk. Any network manager that tried it
would get so many help desk calls that it would be back on within the hour.
Of course, we should make sure that all scenarios that we document in the
IETF (and not just in MIF) make it clear that RA is a MUST with no exceptions.

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 13:22:01 -0800

On Thu, Dec 1, 2011 at 13:14, Brian E Carpenter <[email-masked]
> wrote:

> would get so many help desk calls that it would be back on within the hour.

Not once all operating systems (or all the operating systems that this
particular network desires to support) support the DHCPv6 route option.

> Of course, we should make sure that all scenarios that we document in
> the IETF (and not just in MIF) make it clear that RA is a MUST with no
> exceptions.

For operators, it doesn't necessarily matter what we say. It matters what
works and what doesn't.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Dec 2011 10:33:52 +1300

> Like AAA? That is used and will be used a lot for address & prefix management, and can also be used for distributing per subscriber route information. 

I stand corrected - the point is that AAA is centrally managed and tied to
subscriber info. RA is neither in any present implementation that I'm aware
of. It was designed thinking of completely unmanaged networks.

> I would not say competing vendor but competing SDO options.

Procedurally, as far as the IETF is concerned, they would be vendor
options I think. But in any case they would amount to solving the same
problem N times. See
http://www.tuv.com/media/germany/50_trainingandconsulting/pdf/patente/Circular_transportation_facilitation_device.pdf

  Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 13:36:47 -0800

On Thu, Dec 1, 2011 at 13:33, Brian E Carpenter <[email-masked]

> > Like AAA? That is used and will be used a lot for address & prefix
> management, and can also be used for distributing per subscriber route
> information.
>
> I stand corrected - the point is that AAA is centrally managed and tied
> to subscriber info. RA is neither in any present implementation that I'm
> aware of.

That's not true. I have personally designed a network that used layer 2
information (VLAN tags) to cause a router to look up a prefix in RADIUS
that it would then send out in an RA for hosts on that VLAN to do SLAAC.
That's both centrally managed and tied to subscriber info.

---

From: Brian E Carpenter <[email-masked]>
Date: Fri, 02 Dec 2011 10:57:34 +1300

> That's both centrally managed and tied to subscriber info.

If you're using VLANs you are operating multiple LANs as far as IP
is concerned, so this is not really solving the problem of heterogeneous
hosts on the same LAN.

I have to say that using VLANs in low-end networks is very similar to
attaching booster rockets to a pig that refuses to fly. Surely we (the
IETF) should be aiming to solve this problem at L3?

I'm not saying that the RA architecture can't be enhanced to support
this - for example by describing a stateful RA server - but that
really would end up looking awfully like a DHCPv6 server in all but
protocol details.

    Brian

---

From: Ted Lemon <[email-masked]>
Date: Thu, 1 Dec 2011 22:23:09 +0000

> really would end up looking awfully like a DHCPv6 server in all but

One small advantage to this would be that the change would only be required on the router, not on the nodes being configured by the router.

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 1 Dec 2011 14:23:37 -0800

On Thu, Dec 1, 2011 at 13:57, Brian E Carpenter <[email-masked]

> is concerned, so this is not really solving the problem of heterogeneous

Correct. I'm making the statement that in many of the use cases I've heard
so far, you don't have to solve this problem by changing the protocols that
are defined (e.g., by adding a route option), you can solve it at a
different layer, and that doing so is actually simpler.

In the BBF use case, for example, the hosts are actually forbidden to talk
to each other without using the BNG as an intermediary (for various reasons
including legal intercept, billing, and so on). In this case, using
separate VLANs is actually a much better solution than the complex
combination of DHCP snooping, ARP spoofing, and MAC-to-IP forcing that is
done in many existing deployments today. The complex solution works in
IPv4, but it really starts to show its limitations in IPv6.

I don't think the right solution is to complicate IPv6 until it reaches the
level of complexity that we have been forced to reach in IPv4 due to
address exhaustion and the resort to NATs as a crutch that allows the
network operator to fix the problem by making the application layer more
complex.

---

From: jouni korhonen <[email-masked]>
Date: Fri, 2 Dec 2011 08:53:18 +0200

Hi,

> of. It was designed thinking of completely unmanaged networks.

Latest yesterday I tweaked with such implementation. It is quite common feature e.g. in 3GPP defined networks that the per subscriber prefix for RA comes off AAA. It has been there in specs for say 9 years and deployed at least several years. Also the per subscriber delegated prefixes may come from AAA.. like the rest of the end host configuration information.

> http://www.tuv.com/media/germany/50_trainingandconsulting/pdf/patente/Circular_transportation_facilitation_device.pdf

great stuff ;-) 

- Jouni

---

From: Zhen Cao <[email-masked]>
Date: Fri, 2 Dec 2011 16:39:31 +0800

On Fri, Dec 2, 2011 at 6:23 AM, Lorenzo Colitti <[email-masked]> wrote:
> On Thu, Dec 1, 2011 at 13:57, Brian E Carpenter
> <[email-masked]> wrote:
>>
> including legal intercept, billing, and so on). In this case, using separate
> VLANs is actually a much better solution than the complex combination of
> DHCP snooping, ARP spoofing, and MAC-to-IP forcing that is done in many
> existing deployments today. The complex solution works in IPv4, but it
> really starts to show its limitations in IPv6.

For per-user configuration, the situation is that users are dynamic
and I do not see how the VLAN can be configured according to their
different requirements. If you use the extended information in the
VLAN setup and use selective unicast RA in 3GPP case, I think that
already reaches (and actually more complicated than) the threshold for
doing it using DHCPv6.

---

From: Tao Sun <[email-masked]>
Date: Sat, 3 Dec 2011 01:18:22 +0800

On Fri, Dec 2, 2011 at 1:59 AM, Lorenzo Colitti <[email-masked]> wrote:

>>   You can already do this today with RIOs, and I don't see why there
>>> need to be two ways of doing the same thing. Adding a different method to
>>> configure the same information is twice the code and more than twice the
>>> complexity, since when you have two sources of information with different
>>> semantics you need to figure out how to merge them, what happens if they
>>> disagree, what to do if one is wrong, what to do if one expires, and so on.
>>>
> What I meant is that a protocol and IETF perspective, you can do this
> today using RIOs. So the protocol is there if 3GPP wants to use it. The
We cannot only discuss the aplicability in IETF perspective. It is indeed
significant change. The operator always needs to consider the huge number
of legacy device and network elements. Change user's device and update
network elements are really non-trival things.

>
>
>>  I agree we need to consider the disagree/confliction among policies.
>> That is caused by the multiple interface feature. If you use RA for all the
For one interface in a single administrative domain, the network can pick
one mechanism. Even if two ways are used simutaneously (I do not see this
is necessary though), the administrator shall make the routing policy.

Again, I still think regardless which mechanism is used. MIF shall address
the issue of multiple sources of informaiton.

> gateway on the wifi network.
I don't understand why one interface need to know the address of the
default gateway on the other network. If neither DHCPv6 and RIO cannot
solve this MIF scenario, what solution can solve it?

>  #2 can be fixed both using DHCPv6 route option and using RIOs.
Here you *can* do this using RIO, but limited in IETF protocal perspective.

> (one router on a given link).
Section 3.4 related with your previous question, the hotspot router is a
multi-homing router which may need some specific route.

> Who is "us", and what is the use case? I don't see why the ones discussed
Us means operators owns and manage both cellular network and WiFi netowrk.
WiFi plays more and more important roles in mobile operator's network.

---

From: Tao Sun <[email-masked]>
Date: Sat, 3 Dec 2011 02:15:36 +0800

On Fri, Dec 2, 2011 at 2:06 AM, Lorenzo Colitti <[email-masked]> wrote:

> I can see the BBF use case, but that seems to be a rather specific use
> case and could be solved using a BBF-specific option. I can't see the
> cellular use case, since the cellular network already uses RAs.
>
I have to repeat my previous words that cellular network only use RA to do
SLAAC today. Further more, even SLAAC is not well supported by some
vendor's network elment today.

> network or an enterprise network.
As I pointed out in my previous email, WiFi network is already part of
mobile network. China Mobile deployed about more than one hundred of
thousand hotspots (over 1 million WiFi AP). Users use the same smart phone
to visit cellular network and WiFi network.

> equally applicable to a use case where you have only one interface.
If you have only one interface, DHCPv6 route option is not necessary for
configuring those specific routing informaiton.

>>> want. There's no reason you can't look the RA properties in RADIUS. And of
> From the network point of view maybe. But not from the point of view of
> the node that is receiving the RA. That node can still support / merge
> multiple sources of information; it only needs to support one protocol (RA)
> to configure routes and doesn't need the additional complexity that comes
> from supporting two ways to configure the same thing; and so on.
>
Good you see the suffer of network using RA in this way. Hope you also see
the complexity using VLAN on smart phones.

---

From: Tao Sun <[email-masked]>
Date: Sat, 3 Dec 2011 02:34:26 +0800

On Fri, Dec 2, 2011 at 3:22 AM, Lorenzo Colitti <[email-masked]> wrote:

> See what I mean? We're already talking about not using RAs at all any
> more, and we don't even have a DHCPv6 route option yet...
>

RA still must be used by the host to get the /64 prefix first and establish
the connection towards the gateway. After that, DHCPv6 PD is used if
shorter than /64 prefix is required.
If you worry about the possibility of dropping the use of RA, the draft can
be updated to clearly state that using DHCPv6 for route option shall not
prevent using RA for SLAAC... somthing like that.

I

---

From: Tao Sun <[email-masked]>
Date: Sat, 3 Dec 2011 02:49:49 +0800

On Fri, Dec 2, 2011 at 2:53 PM, jouni korhonen <[email-masked]>wrote:

> to
> Latest yesterday I tweaked with such implementation. It is quite common
> feature e.g. in 3GPP defined networks that the per subscriber prefix for RA
> comes off AAA. It has been there in specs for say 9 years and deployed at
> least several years. Also the per subscriber delegated prefixes may come
> from AAA.. like the rest of the end host configuration information.
>
>
[Tao] Could you be more specific which spec you are referring to?
Unfortunately, it is not ture that such implementation has "deployed at
least several years". Few vandor implement their network elements with good
support of RA, not mention of the per subscriber prefix from AAA or the
RIO. The basic RA works in new network element on 4G PDN gateways in recent
one year or so .

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 2 Dec 2011 11:06:33 -0800

> already reaches (and actually more complicated than) the threshold for

I'm not talking about VLANs for the 3GPP case. In the 3GPP case you have a
bunch of point to point interfaces (tunnels / PDP contexts / PDNs; one or
more per user) that each have their own network segment (a /64). Per-user
configuration is achieved simply by saying "the user on tunnel X gets an RA
with prefix Y". This is how IPv6 on mobile networks works today.

If you want more specific routes, you can easily include those in the RA,
because as Jouni says, this is tied into AAA already.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 2 Dec 2011 11:18:31 -0800

> network elements are really non-trival things.

Of course. But since the specs need to be updated anyway, and
implementations have to be updated anyway, the fact that changing existing
implementations is a lot of work is not an argument in support of either
RIO or DHCPv6 route: both require work to be done. RIO has the advantage
that less work needs to be done, because the protocol and some
implementations exist already. I know that on Android it would be much
easier to implement RIO than a DHCPv6 route option.

>   Again, I still think regardless which mechanism is used. MIF shall
>>> address the issue of multiple sources of informaiton.
>>>
>>
I think MIF should deal with the issue of how to make things work using
multiple interfaces. Making things work in two different ways on one
interface is orthogonal.

>> #1 can't be solved using either the DHCPv6 route option or RIOs because
>> in general the carrier network doesn't know the IPv6 address of the default

The default gateway address on the other interface is needed if you want
offload traffic to the other interface. That's what I thought you meant.

If all you want to do is say "this carrier walled garden is reachable
through the carrier interface, and the rest of the interface is over wifi",
then you can do that using either RIOs or DHCPv6 route option.

>    I don't see how Section 3.4 of this draft ("applicability to routers")
>>>> is relevant to this discussion. Section 5.2 of RFC 5191 describes a
>>>> different scenario (two routers on the same link) than the one you
>>>> suggested here (one router on a given link).
>>>>
>>>  Section 3.4 related with your previous question, the hotspot router is
> a multi-homing router which may need some specific route.
>

Sure, but that specific route can be given to that router in many ways
(static configuration, RIO, routing protocol). We don't have to define a
new DHCPv6 route option to do that.

> WiFi plays more and more important roles in mobile operator's network.

Then please explain the use case in more detail, and how you would use the
proposed DHCPv6 route option to solve the use case. I think you'll find
that what you're trying to do can be done today (from a protocol
perspective) using RIOs.

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 2 Dec 2011 11:21:09 -0800

> to visit cellular network and WiFi network.

Ok, so then let's take a look at that use case and see why it requires a
DHCPv6 route option to be defined. I suspect that you can do what you want
using RIO.

---

From: Jouni <[email-masked]>
Date: Fri, 2 Dec 2011 23:55:22 +0200

On Dec 2, 2011, at 8:49 PM, Tao Sun wrote:

> [Tao] Could you be more specific which spec you are referring to?  Unfortunately, it is not ture that such implementation has

TS29.061.. you can trace it back about ~9 for RADIUS interface to provide prefix for a RA.

- Jouni

>  "deployed at least several years". Few vandor implement their network elements with good support of RA, not mention of the per
>  subscriber prefix from AAA or the RIO. The basic RA works in new network element on 4G PDN gateways in recent one year or so .

---

From: Brian E Carpenter <[email-masked]>
Date: Sat, 03 Dec 2011 11:15:09 +1300

Where can I find TS29.061?

   Brian

---

From: Lorenzo Colitti <[email-masked]>
Date: Fri, 2 Dec 2011 14:23:31 -0800

On Fri, Dec 2, 2011 at 14:15, Brian E Carpenter <[email-masked]

> Where can I find TS29.061?

http://www.3gpp.org/ftp/Specs/html-info/29061.htm

---

From: Jouni <[email-masked]>
Date: Sat, 3 Dec 2011 00:26:46 +0200

- Jouni

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 03 Dec 2011 15:44:45 +0100

Le 02/12/2011 19:34, Tao Sun a écrit :
>
>
> On Fri, Dec 2, 2011 at 3:22 AM, Lorenzo Colitti <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> On Thu, Dec 1, 2011 at 10:40, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>>
> wrote:
>
> suggested by 3GPP specs.  Thus, the 3GPP specs assume that a
> UE-Router (new term for this conversation) runs both RA _and_ DHCP.
> But 3GPP specs overlook the fact that an UE-Router would't use RA to
> That's not true - RFC 6204 says that an IPv6 CE router can use
> autoconf to create an address. I think it's reasonable to say that if
> you were to implement tethering using DHCPv6 PD, you would follow RFC
> 6204.
>
> Hence 3GPP specs could consider that _only_ DHCP should should be
> used by DHCPv6.  In this sense, the above only mandate ("use RA to
> obtain /64 prefix") could be dropped altogether.
>
>
> RA still must be used by the host to get the /64 prefix first and
> establish the connection towards the gateway. After that, DHCPv6 PD
> is used if shorter than /64 prefix is required.

YEs, that is what the 3GPP specs say.  But I wonder whether better ways
exist, to reduce the software code size, and number of messages
exchanged on the air: use just DHCPv6 not RA to obtain address and its
on-link prefix, prefix behind it, default route and DNS address.

> If you worry about the possibility of dropping the use of RA, the
> draft can be updated to clearly state that using DHCPv6 for route
> option shall not prevent using RA for SLAAC... somthing like that.

In a sense I could agree with this statement, to not prevent use of RA
for SLAAC.  Even better would be to say _how_ the potentially
conflicting information received from RA and DHCP could be somehow ordered.

Additionally, it is worth mentioning that DHCP route option per se has
not any counterpart mechanism in pure non-4191 RA (the prefix advertised
by RA, most widely implemented is the on-link prefix, as a "connected C"
route at most, not to be confused with the "non-connected" route, as is
likely to happen with the DHCP route-option).

_Only_ if we talk route option to be a default route do we talk
potential conflict DHCP-RA.

For pure route-option there could be conflict between DHCP and e.g. OSPF
but not DHCP and RA.

Alex

> [email-masked] <mailto:[email-masked]>

---

From: Alexandru Petrescu <[email-masked]>
Date: Sat, 03 Dec 2011 15:49:58 +0100

Le 02/12/2011 20:06, Lorenzo Colitti a écrit :
> On Fri, Dec 2, 2011 at 00:39, Zhen Cao <[email-masked]
> <mailto:[email-masked]>> wrote:
>
> I'm not talking about VLANs for the 3GPP case. In the 3GPP case you have
> a bunch of point to point interfaces (tunnels / PDP contexts / PDNs; one
> or more per user) that each have their own network segment (a /64).
> Per-user configuration is achieved simply by saying "the user on tunnel
> X gets an RA with prefix Y". This is how IPv6 on mobile networks works
> today.
>

I don't know how much software exist for RFC4191 specific routes to be 
received by a Router (not a Host)?

Also, to support specific routes in RA towards a Router there would be 
need of specification change.  (you pointed to an RFC6xxx but it read to 
me as Informational).

Alex

---

From: Tao Sun <[email-masked]>
Date: Tue, 6 Dec 2011 01:51:52 +0800

I traced back the TS 29.061 V3.a.0 which is more than 9 years from now. It
is not convincing.

While, the spec already mention the using of DHCP for configure paramters:
"If the MS is DHCP capable and the IPv6 address has been allocated using
Stateless Address Autoconfiguration, the MS may use a procedure as in the
example below to configure additional external network protocol parameters,
or other parameters that apply to the Intranet or ISP."

RADIUS protocal from GGSN to AAA is mostly used for authorization,
authentication and accounting and is not a good choice for host specific
policy, as stated in the spec:
"RADIUS for authentication and DHCP for host configuration and address
allocation"

On Sat, Dec 3, 2011 at 6:26 AM, Jouni <[email-masked]> wrote:

> >>> Latest yesterday I tweaked with such implementation. It is quite
> common feature e.g. in 3GPP defined networks that the per subscriber prefix
> for RA comes off AAA. It has been there in specs for say 9 years and
> deployed at least several years. Also the per subscriber delegated prefixes
> may come from AAA.. like the rest of the end host configuration information.
> >>>
>  Unfortunately, it is not ture that such implementation has
> >>
> >>> "deployed at least several years". Few vandor implement their network
> elements with good support of RA, not mention of the per
> >>> subscriber prefix from AAA or the RIO. The basic RA works in new
> network element on 4G PDN gateways in recent one year or so .
> >>
> >>
> >>
>
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Dec 2011 10:18:51 -0800

> received by a Router (not a Host)?

Routers don't listen to RAs in general, so, not much. They also aren't
usually DHCPv6 clients. Unless they're customer routers, in which case they
use both.

> need of specification change.  (you pointed to an RFC6xxx but it read to me
> as Informational).
>

The router that is the next-hop to a particular prefix needs to send the RA
with an RIO for that prefix, yes. If that router does not wish to be the
default router, it can set the default lifetime field to zero. I don't a
router can can send an RIO option that says "send traffic to this prefix to
this other router". This is good because it encourages fate-sharing, which
usually makes things more likely to work.

---

From: Tao Sun <[email-masked]>
Date: Tue, 6 Dec 2011 03:25:03 +0800

Ok. I reiterate the use cases and the justification of using DHCPv6.

For the cellular network, I mainly focus on two use cases: 1) A host is
connected to the cellular network and WiFi at the same time. Some traffic
need to go cellular network, others go to WiFi. 2) A mobile host in the
cellular network simultaneously connects to multiple APNs (taking APN1 and
APN2 for example) . Some traffics go to APN1, others got to APN2.

The justification of adopt DHCPv6 is the following:
1) DHCPv6 is anyway shall be implemented and is suitable for parameter
configuration. This is due to prefix delegation for tethering, network
parameter configuration such as DNS, network server informaiton of IMS, etc.
2) DHCPv6 is more management/operation friendly due to the central control
mechanism.
3) DHCP has been already used for paramter configuration, while using RA
will cause significant modification and enhancement for network elements
and hosts, especially for per-subscriber purpose (e.g., using VLAN).
4) Using RA to configure the route may cause potentially some messy. In 4G
cellular network, both GTP and PMIP protocal are used for mobility
management today. In GTP, it is a point-to-point link between mobile host
and PGW. However, in PMIP, PGW send /64 prefix to SGW through PBA. The SGW
sends RA to mobile host. If RA is also used for route configuration, how
SGW obtains the specific route information? how about the complexity due to
the large number of SGW as compared with PGW? how the SGW combine the
multiple RA route informatio nreceived from sources in use case 2
since there is always only one SGW at a time? ...

Based on above, using RA for SLAAC and DHCPv6 for route paramter
configuration is a more effective way.

In my view, the discussion is adequate enough to move the draft forward to
version 4 and we shall not continue to stay on the necessity analysis.

Tao Sun

---

From: Jouni <[email-masked]>
Date: Tue, 6 Dec 2011 02:39:56 +0200

Hi,

On Dec 5, 2011, at 9:25 PM, Tao Sun wrote:

> For the cellular network, I mainly focus on two use cases: 1) A host is connected to the cellular network and WiFi at the same time. Some traffic need to go cellular network, others go to WiFi. 2) A mobile host in the cellular network simultaneously connects to multiple APNs (taking APN1 and APN2 for example) . Some traffics go to APN1, others got to APN2.

These are (at least the example 1) doable using RFC4191 and RAs. For the latter case how the default router for "default traffic" gets selected (independent of DHCPv6 or RAs) is a bit of an issue if all interfaces (APNs) are equal.

I can use AAA (or hypothetically even PCC) as my central configuration database..

> 1) DHCPv6 is anyway shall be implemented and is suitable for parameter configuration. This is due to prefix delegation for tethering, network parameter configuration such as DNS, network server informaiton of IMS, etc.

It is still optional for 3GPP networks from specs point of view as far as I remember. Both RFC3736 and RFC3633 are "Both EPS network elements and UE may support".

> 2) DHCPv6 is more management/operation friendly due to the central control mechanism.

Compared to AAA based on what grounds?

> 3) DHCP has been already used for paramter configuration, while using RA will cause significant modification and enhancement for network elements and hosts, especially for per-subscriber purpose (e.g., using VLAN).

In the above (cellular oriented) example, I am not so sure. In cellular (3GPP) networks the RAs are already used in per subscriber manner.

> 4) Using RA to configure the route may cause potentially some messy. In 4G cellular network, both GTP and PMIP protocal are used for mobility management today. In GTP, it is a point-to-point link between mobile host and PGW. However, in PMIP, PGW send /64 prefix to SGW through PBA. The SGW sends RA to mobile host. If RA is also used for route configuration, how SGW obtains the specific route information? how about the complexity due to the large number of SGW as compared with PGW? how the SGW combine the multiple RA route informatio nreceived from sources in use case 2 since there is always only one SGW at a time? ... 

This is a good point in cellular context, especially the PMIPv6 case is very true.

>  Based on above, using RA for SLAAC and DHCPv6 for route paramter configuration is a more effective way.

Note that I have nothing against DHCPv6 router parameter configuration work in general (OK to complete it), however, RAs and RFC4191 do have merits especially in the above example (cellular) context. Specifically the push model of per-subscriber RAs is attractive.

- Jouni

>  
> In my view, the discussion is adequate enough to move the draft forward to version 4 and we shall not continue to stay on the necessity analysis.
>  
> Tao Sun
>  
> I'm not talking about mobile networks specifically here. I think this particular event (turning off RAs) is more likely that to happen on a wifi network or an enterprise network.
> As I pointed out in my previous email, WiFi network is already part of mobile network. China Mobile deployed about more than one hundred of thousand hotspots (over 1 million WiFi AP). Users use the same smart phone to visit cellular network and WiFi network.
> 
> Ok, so then let's take a look at that use case and see why it requires a DHCPv6 route option to be defined. I suspect that you can do what you want using RIO.
>

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 5 Dec 2011 16:48:26 -0800

> and hosts, especially for per-subscriber purpose (e.g., using VLAN).

In the 3G scenario you don't need VLANs, as all subscriber interfaces are
separate point-to-point interfaces, each with its own /64, and you're
already provisioning these /64s on a per-subscriber basis.

---

From: <[email-masked]>
Date: Tue, 6 Dec 2011 10:13:06 +0100

Hi,

Regarding use-cases below, the operator will likely rely on a centralized policy server; actually the 3GPP/ANDSF has been specified for that purpose.

Pierrick

________________________________

De : [email-masked] [mailto:[email-masked]] De la part de Tao Sun
Envoyé : lundi 5 décembre 2011 20:25
À : Lorenzo Colitti
Cc : [email-masked]
Objet : Re: [mif] Use cases for draft-ietf-mif-dhcpv6-route-option needed

Tao Sun

---

From: Tao Sun <[email-masked]>
Date: Wed, 7 Dec 2011 02:56:01 +0800

On Tue, Dec 6, 2011 at 8:39 AM, Jouni <[email-masked]> wrote:

> These are (at least the example 1) doable using RFC4191 and RAs. For the
> latter case how the default router for "default traffic" gets selected
> (independent of DHCPv6 or RAs) is a bit of an issue if all interfaces
> (APNs) are equal.
>
[Tao] The interfaces (APNs) are generally not equal, i.e., APN_IMS,
APN_Internet.

> I can use AAA (or hypothetically even PCC) as my central configuration
[Tao] Using AAA, maybe. Using PCC is hypotheses. :-)

> It is still optional for 3GPP networks from specs point of view as far as
> I remember. Both RFC3736 and RFC3633 are "Both EPS network elements and UE
> may support".
>
[Tao] From specs point of view, it is optional. From real implementation,
IMHO, it will be implemented, e.g., using LTE as backhaul for tethering is
a quite attractive feature.

> Compared to AAA based on what grounds?
[Tao] Using radius with AAA is only used for few enterprise users in some
operator's network.

> In the above (cellular oriented) example, I am not so sure. In cellular
> (3GPP) networks the RAs are already used in per subscriber manner.
>

[Tao] You need to update radius protocal and AAA specification in 3GPP to
convey the configuration information. The mandatory RA for prefix
assignment is supported not long time ago by network elements. Ohter
optional extension of RA such as RIO indeeds new requirement for network
elements and handset.

>
> > 4) Using RA to configure the route may cause potentially some messy. In
> 4G cellular network, both GTP and PMIP protocal are used for mobility
> multiple RA route informatio nreceived from sources in use case 2 since
> there is always only one SGW at a time? ...
>
[Tao] Good you share the same view.

> Note that I have nothing against DHCPv6 router parameter configuration
> work in general (OK to complete it), however, RAs and RFC4191 do have
> merits especially in the above example (cellular)

[Tao] Besides the exist of 4191, not sure about other merits.

> context. Specifically the push model of per-subscriber RAs is attractive.
>

[Tao] Do you mean the mechanisms of RA offloading? If so, we can discuss it
in another thread.

>
> - Jouni
>
>
> >
> > In my view, the discussion is adequate enough to move the draft forward
> to version 4 and we shall not continue to stay on the necessity analysis.
> >
> > Tao Sun
> >

---

From: Tao Sun <[email-masked]>
Date: Wed, 7 Dec 2011 03:09:02 +0800

In 2G/3G, it seems so. However, it seems not feasible for 4G as indicated
in 4).

Tao

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Dec 2011 11:14:01 -0800

> [Tao] The interfaces (APNs) are generally not equal, i.e., APN_IMS,

Yes, and each one already has its own RA.

> [Tao] Using radius with AAA is only used for few enterprise users in some

So what entity in the network decides what prefix to assign to a given user
when he sets up, say, the Internet PDN?

> optional extension of RA such as RIO indeeds new requirement for network

The RADIUS attribute for it already exists, it's called Framed-IPv6-Route:
http://tools.ietf.org/html/rfc3162#section-2.5 .

The handsets can easily support it if they are based on operating systems
that support it. I know Linux does, so Android could use it. Don't know
about OS X / iPhone, but on the other hand the iPhone doesn't support IPv6
on the mobile interface yet.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 06 Dec 2011 21:34:46 +0100

Le 06/12/2011 01:39, Jouni a écrit :
>> For the cellular network, I mainly focus on two use cases: 1) A
>> host is connected to the cellular network and WiFi at the same
>> time. Some traffic need to go cellular network, others go to WiFi.
>>  2) A mobile host in the cellular network simultaneously connects
>> to multiple APNs (taking APN1 and APN2 for example) . Some
>> traffics go to APN1, others got to APN2.
>
> These are (at least the example 1) doable using RFC4191 and RAs.

I think 4191 is desirable if the host is a Host on cellular, not a
Router on cellular (tethering IPv6).  A pure Router does not consider
receiving RAs other than for logging purposes, thus ignoring the
potentially present RIO.

What is simpler: specify Routers to consider RIO'ed RAs?  or specify
DHCP extensions to communicate routes? (at least default routes).

Additionally, RIO (Route Information Option) does not seem to encode the
address of next-hop (it seems left to determine elsewhere, not clear its
relationship with the prefix in RIO).  The route-option proposal for
DHCP seems to tie together explicitely the prefix with the next-hop
address, which may have advantages.

Alex

> For the latter case how the default router for "default traffic" gets
> selected (independent of DHCPv6 or RAs) is a bit of an issue if all
> interfaces (APNs) are equal.
>
>> The justification of adopt DHCPv6 is the following: 1) DHCPv6 is
>> anyway shall be implemented and is suitable for parameter
>> configuration. This is due to prefix delegation for tethering,
>> network parameter configuration such as DNS, network server
>> informaiton of IMS, etc.
>
> It is still optional for 3GPP networks from specs point of view as
> far as I remember. Both RFC3736 and RFC3633 are "Both EPS network
> elements and UE may support".
>
>> 3) DHCP has been already used for paramter configuration, while
>> using RA will cause significant modification and enhancement for
>> network elements and hosts, especially for per-subscriber purpose
>> (e.g., using VLAN).
>
> In the above (cellular oriented) example, I am not so sure. In
> cellular (3GPP) networks the RAs are already used in per subscriber
> manner.
>
>> 4) Using RA to configure the route may cause potentially some
>> messy. In 4G cellular network, both GTP and PMIP protocal are used
>>  for mobility management today. In GTP, it is a point-to-point link
>>  between mobile host and PGW. However, in PMIP, PGW send /64 prefix
>>  to SGW through PBA. The SGW sends RA to mobile host. If RA is also
>>  used for route configuration, how SGW obtains the specific route
>> information? how about the complexity due to the large number of
>> SGW as compared with PGW? how the SGW combine the multiple RA route
>> informatio nreceived from sources in use case 2 since there is
>> always only one SGW at a time? ...
>
> Note that I have nothing against DHCPv6 router parameter
> configuration work in general (OK to complete it), however, RAs and
> RFC4191 do have merits especially in the above example (cellular)
>> In my view, the discussion is adequate enough to move the draft
>> forward to version 4 and we shall not continue to stay on the
>> necessity analysis.
>>
>> Tao Sun
>>
>> On Sat, Dec 3, 2011 at 3:21 AM, Lorenzo Colitti<[email-masked]>
>> wrote: On Fri, Dec 2, 2011 at 10:15, Tao Sun<[email-masked]>
>> wrote: I'm not talking about mobile networks specifically here. I
>> think this particular event (turning off RAs) is more likely that
>> to happen on a wifi network or an enterprise network. As I pointed
>> out in my previous email, WiFi network is already part of mobile
>> network. China Mobile deployed about more than one hundred of
>> thousand hotspots (over 1 million WiFi AP). Users use the same
>> smart phone to visit cellular network and WiFi network.
>>
>> Ok, so then let's take a look at that use case and see why it
>> requires a DHCPv6 route option to be defined. I suspect that you
>> can do what you want using RIO.
>>

---

From: Ted Lemon <[email-masked]>
Date: Tue, 6 Dec 2011 20:38:32 +0000

On Dec 6, 2011, at 3:34 PM, Alexandru Petrescu wrote:
What is simpler: specify Routers to consider RIO'ed RAs?  or specify
DHCP extensions to communicate routes? (at least default routes).

Of course, the answer to this question will vary depending on whether you are a provider operating routers, or a vendor implementing host stacks.   Which is why we are having this discussion.   Previous discussions really only considered the network operator case.

It's pretty clear that from the host implementation side, RIO is easier than DHCP, because the host already supports it.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 06 Dec 2011 21:40:47 +0100

Le 01/12/2011 20:22, Lorenzo Colitti a écrit :
> <[email-masked] <mailto:[email-masked]>> wrote:
>
> That's not true - RFC 6204 says that an IPv6 CE router can use autoconf
> to create an address.

Is it possible to make RFC6204 IPv6 CE router to be an arbitrary Router, 
like a handset device with cellular and wifi doing tethering, or like an 
OBU with many cellular interfaces, or like sattelite routers?  Could all 
these be IPv6 CE Routers? (CE: Customer Equipment, DSL, BBF, I believe).

> I think it's reasonable to say that if you were to

Hm, that seems good guide for this, and I wonder why is it INFORMATIONAL 
and not on the Standards Track?

Alex

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Dec 2011 09:50:58 +1300

Jouni,

I found some time to look quickly at this spec, and I see that indeed
prefix delegation via AAA *or* DHCPv6 is supported, but there is no mention
of RFC 4191 (RIO). Regular use of RA is of course covered.

You said

>> It is quite common
>> comes off AAA. 

But that doesn't explain how prefix delegation would be managed with RAs, or how
RIOs would be generated.

Regards
   Brian Carpenter

---

From: Jouni <[email-masked]>
Date: Tue, 6 Dec 2011 23:17:35 +0200

Brian,

> But that doesn't explain how prefix delegation would be managed with RAs, or how

Please, do not put words in my mouth.

Did I claim PD would work or be managed with RA? No. Per-subscriber prefix for RAs is for SLAAC purposes as you very well know.
Did I claim 29.061 carries more specific routes for RIOs? No.
Did I claim RFC4191 is even supported by 3GPP system? No. A GGSN/PGW implementation *can* use RFC4191 and put RIOs in RAs if it wishes. The system specification does not prohibit doing that. A "pedantic" 3GPP UE would then just ignore those options.

If your DHCPv6 server happens to be in GGSN/PGW, you can configure the delegated prefix using 29.061 AAA profile and Delegated-IPv6-Prefix attribute - as a one option.

- Jouni

---

From: Brian E Carpenter <[email-masked]>
Date: Wed, 07 Dec 2011 10:33:56 +1300

Jouni,

> Please, do not put words in my mouth.

I didn't mean to do that at all! I was just trying to state the problem. I'm sorry
if it appeared otherwise.

> Did I claim RFC4191 is even supported by 3GPP system? No. A GGSN/PGW implementation *can* use RFC4191 and put RIOs in RAs if it wishes. The system specification does not prohibit doing that. A "ped…

We agree; all of those things appear to be unspecified.

> If your DHCPv6 server happens to be in GGSN/PGW, you can configure the delegated prefix using 29.061 AAA profile and Delegated-IPv6-Prefix attribute - as a one option.

Indeed. What I don't see anywhere is a document describing how to create such
a stateful-server model using RAs. I think that's why this thread exists.

My understanding has always been that the strategy was to keep RA as a simple
model without rich extensibility, and to use DHCPv6 for more complex
scenarios. So the judgment to make here is whether all MIF scenarios
(and all HOMENET scenarios) are complex in that sense.

  Brian

---

From: Jouni <[email-masked]>
Date: Wed, 7 Dec 2011 00:18:33 +0200

Hi again,

On Dec 6, 2011, at 8:56 PM, Tao Sun wrote:

> [Tao] The interfaces (APNs) are generally not equal, i.e., APN_IMS, APN_Internet.

Afair, there is no information element in bearer setup signaling to state a certain APN, in case of multiple APNs, should be used as the default gateway beyond what RFC3484 does. If there is such e.g. in NAS signaling, let me know, and I'll stand corrected. I would actually be happy to know if there is one..

[snip]

> [Tao] From specs point of view, it is optional. From real implementation, IMHO, it will be implemented, e.g., using LTE as backhaul for tethering is a quite attractive feature.

As I wrote above "from specs point of view"..

> [Tao] Using radius with AAA is only used for few enterprise users in some operator's network.

I would say that AAA footprint in current cellular networks as a subscriber management entity is far more common than DHCPv6.

> [Tao] You need to update radius protocal and AAA specification in 3GPP to convey the configuration information. The mandatory RA 
> for prefix assignment is supported not long time ago by network elements. Ohter optional extension of RA such as RIO indeeds new requirement for network elements and handset.

Framed-ipv6-prefix for SLAAC purposes has been in specs ~9 years. And it has been implemented. The DHCP I-D in question here is not even a standard yet as a comparison.

Currently RFC4191 is not even optional in 3GPP system and for RIOs there is currently no support in 29.061 RADIUS or Diameter profile - these are known facts. So far there just has not been use case for RFC4191 in 3GPP context. However, nothing prohibits implementing or using one.

[snip]

> Note that I have nothing against DHCPv6 router parameter configuration work in general (OK to complete it), however, RAs and RFC4191 do have merits especially in the above example (cellular)
> [Tao] Do you mean the mechanisms of RA offloading? If so, we can discuss it in another thread.

That's a side effect of what you can do with RFC4191. The nice feature is as stated above the "push model of per-subscriber RAs"

Anyway, I think I have said what I have to say on this topic.. one can sense slight pro AAA & RA bias from my side in cellular context ;) Still, nothing against draft-ietf-mif-dhcpv6-route-optio in general. I believe folks find multiple uses for it.

- JOuni

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 6 Dec 2011 17:15:17 -0800

> receiving RAs other than for logging purposes, thus ignoring the

IPv6 CE routers already listen to RAs and use them for routing information
(see RFC 6204). There's no reason a phone can't do the same.

> Additionally, RIO (Route Information Option) does not seem to encode
> the address of next-hop (it seems left to determine elsewhere, not clear
> its relationship with the prefix in RIO).

The next-hop is the router that sent you the RA. This is good because it
implies fate-sharing - if the router goes away or is not capable of
carrying your packets any more, then the RA goes away as well.

If you want to send traffic to a specific prefix through another router on
the link, then that router must send the RA itself. It doesn't have to
announce itself as a default router if it doesn't want to be - it can just
carry traffic to that prefix.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 07 Dec 2011 18:30:49 +0100

Le 07/12/2011 02:15, Lorenzo Colitti a écrit :
> On Tue, Dec 6, 2011 at 12:34, Alexandru Petrescu
> IPv6 CE routers already listen to RAs and use them for routing
> information (see RFC 6204). There's no reason a phone can't do the
> same.

Yes, it sounds logic.  But, looking again at RFC6204 - that is a set of
requirements.  It does not say how to implement it.

Moreover, it does not request the use of RFC4191 on the WAN interface of
CE (or I can not find it requiring it so).

For PD, it does not tell what to do with the delegated prefix (it should
say adding routes in CEA and in WAN).

For reasons like this I think RFC6204 may be enough for CE but not for
other settings like a telephone.

> the address of next-hop (it seems left to determine elsewhere, not
> clear its relationship with the prefix in RIO).
>
>
> The next-hop is the router that sent you the RA. This is good because
> it implies fate-sharing - if the router goes away or is not capable
> of carrying your packets any more, then the RA goes away as well.
>
> If you want to send traffic to a specific prefix through another
> router on the link, then that router must send the RA itself. It
> doesn't have to announce itself as a default router if it doesn't
> want to be - it can just carry traffic to that prefix.

Fate-sharing may be an advantage for CE, but can also be seen as the bad
single point of failure (RA and routing functionality tied together) (if
RA software on a Router dumps core, its routing kernel still works ok,
thus another router could inform about this route by sending RA about it.)

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Dec 2011 14:21:44 -0800

> requirements.  It does not say how to implement it.

Well, yes, because that behaviour is specified in RFC 4861 and RFC 4862.

Moreover, it does not request the use of RFC4191 on the WAN interface of CE
> (or I can not find it requiring it so).
>

That's a fair point. We should probably say the CE router should support it.

> other settings like a telephone.

This I don't understand. A CE and a telephone that implements tehering
don't need to do anything different (except you can't implement tethering
on a /64 without ND proxy)

> Fate-sharing may be an advantage for CE, but can also be seen as the
> bad single point of failure (RA and routing functionality tied together) (if

Then have two routers sending RAs all the time. The host is smart enough to
pick one.

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 7 Dec 2011 14:31:31 -0800

> since there is always only one SGW at a time? ...

I'm not sure I understand this. Why can't you configure the SGW to include
the RIO in the RA no matter what? If what you're doing is saying that
certain carrier services must be on certain interfaces, then the more
specific route(s) don't need to be different for each user, right?

---

From: Tao Sun <[email-masked]>
Date: Fri, 9 Dec 2011 02:42:22 +0800

On Wed, Dec 7, 2011 at 3:14 AM, Lorenzo Colitti <[email-masked]> wrote:

>>  These are (at least the example 1) doable using RFC4191 and RAs. For
>>> the latter case how the default router for "default traffic" gets selected
> So what entity in the network decides what prefix to assign to a given
> user when he sets up, say, the Internet PDN?
>

[Tao] The gateway (e.g., GGSN) is configured with an address pool and asign
IP address based on it.

>> cellular (3GPP) networks the RAs are already used in per subscriber manner.
>>

[Tao] I know only the WiFi mode support IPv6 for Android previously. I also
knew from my colleague that the Android 3.2.2 introduced support of dual
stack IPv4/v6 on LTE mode in Oct. this year.  Could you help to confirm
whether Anroid already support RIO?

---

From: Tao Sun <[email-masked]>
Date: Fri, 9 Dec 2011 02:51:18 +0800

On Wed, Dec 7, 2011 at 4:38 AM, Ted Lemon <[email-masked]> wrote:

> Of course, the answer to this question will vary depending on whether you
> are a provider operating routers, or a vendor implementing host stacks.
> Which is why we are having this discussion.   Previous discussions really
> only considered the network operator case.
>
> It's pretty clear that from the host implementation side, RIO is easier
> than DHCP, because the host already supports it.
>

[Tao] For the host here, you mean Linux or Android or something else?

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 8 Dec 2011 10:58:14 -0800

On Thu, Dec 8, 2011 at 10:42, Tao Sun <[email-masked]> wrote:

> [Tao] The gateway (e.g., GGSN) is configured with an address pool and
> asign IP address based on it.
>

But that gateway is talking to some AAA server (e.g., RADIUS or something
else), right? I can't imagine that all the users on a particular GGSN are
locally configured on the box.

>  The RADIUS attribute for it already exists, it's called
>> Framed-IPv6-Route: http://tools.ietf.org/html/rfc3162#section-2.5 .
>>
> [Tao] I know only the WiFi mode support IPv6 for Android previously. I
> also knew from my colleague that the Android 3.2.2 introduced support of
> dual stack IPv4/v6 on LTE mode in Oct. this year.  Could you help to
> confirm whether Anroid already support RIO?
>

It's supported by the Linux kernel but it's currently disabled in the
Android kernel for no particular reason that I know of. It would be much
easier to enable it than to package a DHCPv6 client.

---

From: Tao Sun <[email-masked]>
Date: Fri, 9 Dec 2011 03:02:58 +0800

> specific route(s) don't need to be different for each user, right?

[Tao]You can configure the PGW. However, you cannot configure SGW. A SGW
has no idea what PDN the user will connect to. A user can connect to
multiple PDNs through corresponding PGWs simultaneously, but only across
one single SGW.

Yes, but the specific route for each PDN is different.

---

From: Tao Sun <[email-masked]>
Date: Fri, 9 Dec 2011 03:19:11 +0800

> locally configured on the box.

The user's information is not locally configured on the box. The gateway is
configured with a block of IP address pool. It assigns IP addresses
dynamically to users who attach to it.

>>> The handsets can easily support it if they are based on operating
>>> systems that support it. I know Linux does, so Android could use it. Don't
>>> know about OS X / iPhone, but on the other hand the iPhone doesn't support
>>> IPv6 on the mobile interface yet.
>>>
>>