Subject: Re: [mif] Route option for DHCPv6 - next steps?

From: Ted Lemon <[email-masked]>
Date: Sun, 1 Apr 2012 10:34:10 +0000

*sigh*

This is why we keep failing to complete anything: people who want the option think the use cases are obvious, and don't want to go to the trouble of clearly articulating them.   People who don't want the option then look at the incompletely articulated use cases, recognize that they aren't valid, and quite rightly ask us to stop working on something for which there is no clear motivating use case.

If you are experiencing operational pain as a result of not having the route option, I would like to hear about that operational pain.   If you just think there ought to be a route option because that's what we did in IPv4, I don't agree with that argument.   I think there are real uses cases that involve real operational pain.   We should focus on addressing those use cases, hopefully in a way that fits in with the rest of the internet architecture, rather than trying to replicate IPv4 functionality just for the sake of completeness.

As for whether this ought to be a DHC or MIF item, part of what happened here is that I pushed pretty hard to *not* have this as a DHC item, because I don't think it's particularly a matter for the DHC working group unless we get a mandate from some other working group to work on it.  I personally am not experiencing any pain as a result of not having this option, and I am not aware of anybody who is except Alexandru and BBF, who actually have two very different use cases.

I personally have no wish to involve DHCPv6 route options in the operation of my home network, and I am pretty sure the ops team at Nominum doesn't need or want this option to operate their networks.   It's something that makes sense in a few cases, not generally.   So it's simply not work the DHC working group would ever adopt on its own, without some clear use case or some clear request from another working group that has already developed the use case.

---

From: "Tony Hain" <[email-masked]>
Date: Mon, 2 Apr 2012 09:18:42 -0700

Ted,

I agree that you don't do something just because it was done in IPv4, but
your response is exactly the same as your complaint about the public
lynching. Just because your local network is not using this mechanism is no
reason to deny others from having it for theirs. 

I didn't put more detail in the initial response because I thought it needed
more time to do it justice. I still intend to do an offline set of comments
about splitting the existing doc so that there is a dhcp mechanism and an RA
approach, but in short; people do operate VPNs with split tunneling, and
need a way to push the internal routes to the client. The operational pain
will occur when there is no option 121 for those networks that use it for
IPv4. The alternative is what I am doing; manually running a static route
script every time the vpn goes up and another when it goes down to pull them
back out. That is not operationally viable at scale, and is more than
annoying even during the interim while the nonsense fighting over the
"correct" operational model continues in the IETF. It really doesn't matter
what your local network uses or wants, what matters is can people clearly
articulate a use case and a mechanism to deal with it. 

As I said earlier, there are networks that want to use dhcp as their
centralized point of management control. For those networks we need to
document the IPv6 version of RFC 3442. At the same time there are networks
that want to avoid deploying dhcp just for one mechanism, so an alternative
needs to be defined. Not that it matters, but my corporate network only uses
IPv6 dhcp to provision a router that requires it for 6rd testing, and that
will go away at some point. I really don't want to keep dhcp just for the
VPN clients, but that is better than manual scripts. In the big picture
though, it really doesn't matter what my network uses any more than any
other. 

Widespread deployment requires that people have the tools they want to use
for managing their local network. Continued fighting in the IETF over why
someone else's operational model is "wrong" is simply delaying deployment.
MIF is supposed to be identifying all the operational issues raised by the
multiple interface case, then the resolutions. People have raised use cases
for why routes need to be pushed, yet MIF seems more interested in denying
the operational concerns than in documenting solutions.

Tony

-----Original Message-----
From: Ted Lemon [mailto:[email-masked]] 
Sent: Sunday, April 01, 2012 3:34 AM
To: Tony Hain
Cc: [email-masked]
Subject: RE: [mif] Route option for DHCPv6 - next steps?

*sigh*

This is why we keep failing to complete anything: people who want the option
think the use cases are obvious, and don't want to go to the trouble of
clearly articulating them.   People who don't want the option then look at
the incompletely articulated use cases, recognize that they aren't valid,
and quite rightly ask us to stop working on something for which there is no
clear motivating use case.

If you are experiencing operational pain as a result of not having the route
option, I would like to hear about that operational pain.   If you just
think there ought to be a route option because that's what we did in IPv4, I
don't agree with that argument.   I think there are real uses cases that
involve real operational pain.   We should focus on addressing those use
cases, hopefully in a way that fits in with the rest of the internet
architecture, rather than trying to replicate IPv4 functionality just for
the sake of completeness.

As for whether this ought to be a DHC or MIF item, part of what happened
here is that I pushed pretty hard to *not* have this as a DHC item, because
I don't think it's particularly a matter for the DHC working group unless we
get a mandate from some other working group to work on it.  I personally am
not experiencing any pain as a result of not having this option, and I am
not aware of anybody who is except Alexandru and BBF, who actually have two
very different use cases.

I personally have no wish to involve DHCPv6 route options in the operation
of my home network, and I am pretty sure the ops team at Nominum doesn't
need or want this option to operate their networks.   It's something that
makes sense in a few cases, not generally.   So it's simply not work the DHC
working group would ever adopt on its own, without some clear use case or
some clear request from another working group that has already developed the
use case.

---

From: Ted Lemon <[email-masked]>
Date: Tue, 3 Apr 2012 10:06:11 +0000

>reason to deny others from having it for theirs.

Lynching was a poor choice of words.   In any case, my point is that if you have a real need for this functionality on your network, you should be able to articulate that in a convincing way, and there should be some reason why DHCPv6 is a better solution than RA.   It shouldn't be the case that you'd just rather use DHCPv6.

> people do operate VPNs with split tunneling, and
> back out.

What's missing from this description is "RA doesn't work well in this situation because..."

> for managing their local network.

Widespread deployment requires that people have tools that work well to manage their local network.  If the tools that we have given them thus far do not work well, it should be easy to say why.   It's not the IETF's job, nor should it be, to give them specific tools just because those are the ones they want, any more than the building code should allow you to use deck screws in a shear wall just because you happen to prefer an impact driver to a nail gun.

---

From: "Tony Hain" <[email-masked]>
Date: Tue, 3 Apr 2012 09:24:09 -0700

Ted Lemon wrote:
> > I agree that you don't do something just because it was done in IPv4,
> >but  your response is exactly the same as your complaint about the
> >public  lynching. Just because your local network is not using this
> >mechanism is no reason to deny others from having it for theirs.
> 
> Lynching was a poor choice of words.   In any case, my point is that if
you
> have a real need for this functionality on your network, you should be
able to
> articulate that in a convincing way, and there should be some reason why
> DHCPv6 is a better solution than RA.   It shouldn't be the case that you'd
just
> rather use DHCPv6.

It appears you missed my point that my personal preference is to avoid using
DHCPv6 for this single function, because I have no other ongoing need. At
the same time, as I said my personal preference doesn't matter, and I will
defend the right of others to have the tools they expect. Like it or not,
there are people that wouldn't know what to do with their network without
the centralized point of all operational knowledge in their DHCP server. In
some cases this is due to internal politics, where the end system
administrators operate the DHCP service, and they refuse to turn over
control to the evil network ops team and whatever they might do.  In other
cases the network ops team operates DHCP with the explicit intent to assert
some control over those evil end systems. 

> 
> > people do operate VPNs with split tunneling, and need a way to push
> > the internal routes to the client. The operational pain will occur
> > when there is no option 121 for those networks that use it for IPv4.
> > The alternative is what I am doing; manually running a static route
> > script every time the vpn goes up and another when it goes down to
> > pull them back out.
> 
> What's missing from this description is "RA doesn't work well in this
situation
> because..."

One size does not fit all ...  The reason that operations is such a mess
right now is the ongoing and unnecessary war about which operational model
is "right", resulting in the absurd need to do logically associated things
in different places. There should be a mechanism that makes this work well
via RA, but that does not mean the DHCP approach is wrong. The IETF needs to
create a complete tool set for operating networks both with and without
DHCP. Again, one size does not fit all ...

When we started this IPv6 effort DHCP was just getting started, and going
through growing pains. At this point an entire generation of network
operators don't know any different and would be lost if you told them their
point of control in DHCP is gone. While a well-functioning RA mechanism is
needed, that is simply inadequate for people that don't know anything but
DHCP.

> 
> > Widespread deployment requires that people have the tools they want to
> > use for managing their local network.
> 
> Widespread deployment requires that people have tools that work well to
> manage their local network.  If the tools that we have given them thus far
do
> not work well, it should be easy to say why.   It's not the IETF's job,
nor
> should it be, to give them specific tools just because those are the ones
they
> want, any more than the building code should allow you to use deck screws
> in a shear wall just because you happen to prefer an impact driver to a
nail
> gun.=

Following that analogy, a large percentage of the network operators out
there have a hammer. It doesn't matter if you give them screws or nails,
they are going to  use the hammer they know. At the end of the day one of
those choices is more efficient and less frustrating than the other, but
both can get the job done. At the same time, leaving the screws and a
screwdriver laying alongside the nails will lead many to realize there may
be a better fit for their needs. When you meet people where they are
mentally, you have a better chance of discussing alternatives than if you
insist they leave their comfort zone and follow your 'one true way' into the
vast unknown. 

Tony

---

From: Erik Kline <[email-masked]>
Date: Wed, 4 Apr 2012 10:53:19 +0900

> It's true, as Jari said, that this can be accomplished in other ways, and maybe it would be better if it would.   If there were some better central management solution for populating unicast RA mappings on the router, then unicast RA would indeed address the exact use case that I think we care about.   But without the mechanism for populating routers, we still have a poorly-addressed use case.   And then the question is, do we want to develop a whole new protocol just to solve this one small problem?
>
> It might be worth developing the protocol just to put this issue to bed.

Is RADIUS suitable for this?  At one point it was the general
non-client provisioning protocol of choice, I thought.  I have not
been following any of the evolving diameter work, but would a RADIUS
option suffice?

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 4 Apr 2012 11:01:21 +0900

On Wed, Apr 4, 2012 at 01:24, Tony Hain <[email-masked]> wrote:

> they are going to  use the hammer they know.

But that's a problem.

If we standardize a hammer, there is a risk that those people will use it
in the wrong scenarios - they might use the the hammer to drive screws into
the walls instead of using the screwdriver, because they don't know how to
use the screwdriver, even though they have it.

That's not a problem per se. The concern is that over time, "use what you
know", network effects, "security", and economics will lead to general
adoption of the hammer because it becomes the lowest common denominator. If
that happens, we as a community might not use the screwdriver any more, and
we will have replaced a sophisticated tool with a less sophisticated one.

---

From: Erik Kline <[email-masked]>
Date: Wed, 4 Apr 2012 11:07:07 +0900

> someone else's operational model is "wrong" is simply delaying deployment.

In the short time that I've been working on IPv6 I don't think I have
seen this as an actual blocker to deployment.  I've seen it claimed to
be a blocker, though, just as I've seen many other claimed blockers as
well.  When each of those claimed blockers were cleared it didn't
actually result in deployment, just identification of the next blocker
du jour.

For this reason I think I completely agree with Ted's earlier comments
about "just because it's in IPv4" and use cases.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Apr 2012 15:52:07 +0000

On Apr 3, 2012, at 9:53 PM, Erik Kline <[email-masked]<mailto:[email-masked]>> wrote:
Is RADIUS suitable for this?  At one point it was the general
non-client provisioning protocol of choice, I thought.  I have not
been following any of the evolving diameter work, but would a RADIUS
option suffice?

RADIUS could potentially be used for configuring unicast RAs on routers.   But since we don't have a clear description of the use cases we're trying to address, it's hard to evaluate.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Apr 2012 16:02:03 +0000

On Apr 3, 2012, at 12:24 PM, Tony Hain <[email-masked]<mailto:[email-masked]>> wrote:
It appears you missed my point that my personal preference is to avoid using
DHCPv6 for this single function, because I have no other ongoing need. At
the same time, as I said my personal preference doesn't matter, and I will
defend the right of others to have the tools they expect.

This argument would be a good justification for perpetuating the use of NetBIOS.

What I mean is that if we are trying to replicate functionality, that doesn't motivate us to choose DHCP over RA, or vice versa: we can just replicate the functionality in whatever way is most architecturally appropriate, and be happy that we have provided people with the tools they need to do their job.

If, on the other hand, what we need to do is to produce functionality that matches someone's mental model of how networks work, then that's a very different problem.   But we do not want to do that; if we did, we would have adopted NetBIOS.

Nobody's saying that people can't use NetBIOS if they want, and nobody's saying people can't use IPv4 behind a NAT if they want.   But your argument doesn't really address the question, which is, is there a *need* for the DHCPv6 route option?   Is there a use case that RA doesn't address, or addresses poorly, but that DHCPv6 route does address.

Tony, when I asked you to specifically say why RA didn't address your use case, you didn't answer my question.   Instead you said, effectively "no, people want NetBIOS."   That's orthogonal to the question.   *Is* there something RA can't do well that DHCPv6+Route can?   If so, can you clearly state what that is?   If not, then you haven't articulated a use case.   "Somebody wants to use a hammer" is not a use case.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 04 Apr 2012 18:28:45 +0200

Le 04/04/2012 17:52, Ted Lemon a écrit :
> RADIUS could potentially be used for configuring unicast RAs on routers.
> But since we don't have a clear description of the use cases we're
> trying to address, it's hard to evaluate.

I am not sure I understand between which entities would RADIUS be used 
and to configure what in particular?

In the case of connecting a mobile router (a router that moves) to an 
LTE infrastructure, I am not sure where would RADIUS fit?

Alex

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

---

From: "Tony Hain" <[email-masked]>
Date: Wed, 4 Apr 2012 12:39:37 -0700

Ted Lemon wrote:
> On Apr 3, 2012, at 12:24 PM, Tony Hain <[email-masked]> wrote:
> What I mean is that if we are trying to replicate functionality, that
doesn't motivate 
> us to choose DHCP over RA, or vice versa: we can just replicate the
functionality in 
> whatever way is most architecturally appropriate, and be happy that we
have provided 
> people with the tools they need to do their job.

If enough people wanted the IETF to work on standardizing issues related to
NetBIOS, it would be wrong to ignore that.

> If, on the other hand, what we need to do is to produce functionality that
>  matches someone's mental model of how networks work, then that's a very
different 
> problem.   But we do not want to do that; if we did, we would have adopted
NetBIOS.

It is not the IETF's place to tell people what protocols to run. The role
here is to tell implementers to be consistent so the operators have a chance
of doing something that works.

> Nobody's saying that people can't use NetBIOS if they want, and nobody's
saying 
> people can't use IPv4 behind a NAT if they want.   But your argument
doesn't really 
> address the question, which is, is there a *need* for the DHCPv6 route
option?  
> Is there a use case that RA doesn't address, or addresses poorly, but that
DHCPv6 route
> does address.

And you keep refusing to hear the use case that "an RA option does not work
for people that want to manage related functionality in their existing DHCP
server". Requiring some things in an RA and others in DHCP is just broken;
both operationally and architecturally. 

> Tony, when I asked you to specifically say why RA didn't address your use
case, 
> you didn't answer my question.   Instead you said, effectively "no, people
want NetBIOS."  
> That's orthogonal to the question.   *Is* there something RA can't do well
that 
>DHCPv6+Route can?   If so, can you clearly state what that is?   If not,
then you haven't 
>articulated a use case.   "Somebody wants to use a hammer" is not a use
case.

See above about the brokenness of requiring both RA and DHCP to make a
network work ...

Let's try a different analogy ... We need to deliver Champaign to clients.
The RA approach is the equivalent of a custom developed stemmed and fluted
crystal glass, while DHCPv6 is equivalent to a generic ceramic coffee mug.
We are NOT discussing delivering different types of Champaign, it is coming
from the same bottle. The only discussion point is the delivery mechanism.
My point is both need to exist and be viable because they serve different
operational models and efficiency needs.

Your argument against allowing the DHCP option to exist amounts to an
irrational fear that somehow allowing people to choose to consume from their
existing generic ceramic mug will be detrimental to your ability to consume
from the crystal glass. While I do understand some degree of that fear being
derived from the insanity of the ongoing IESG stance that the IETF's role is
to restrict everything to one-size-fits-all, then force everyone to adopt
that even when it doesn't work efficiently for them; that still doesn't
justify fighting against someone else's approach. If MIF is doing its job
right, it will present both the RA and the DHCP drafts at the same time and
tell the IESG to get over itself. What we have though is the ongoing
infighting between DHCP and RA that has done nothing but hamper progress for
15 years. If we don't define both in parallel, there is a very real chance
that the IESG will kill off efforts to define the second one, further
bolstering the claims that the IETF ignores the operations community. That
said, if we know they are going to kill one off anyway we should give them
the RA one; because any vendor can define an option in DHCP then bypass the
IESG stupidity by going straight to the RFC editor with an Informational
draft that explains to the community how to interpret that option number.

If we get 15 years down the road and one of the operational models has so
significantly dominated the other that the lesser one becomes operationally
irrelevant (re: your NetBIOS comments), then the right thing to do is define
the lesser one as Historic and move on. Again, the IETF is not here to tell
people how to run their networks, it is here to make sure the products they
attempt to use will work consistently with each other. The operator gets to
choose which approach is most efficient for their local needs. 

Tony

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Apr 2012 21:38:20 +0000

On Apr 4, 2012, at 12:28 PM, Alexandru Petrescu <[email-masked]<mailto:[email-masked]>> wrote:
I am not sure I understand between which entities would RADIUS be used and to configure what in particular?

In the case of connecting a mobile router (a router that moves) to an LTE infrastructure, I am not sure where would RADIUS fit?

Radius is good at getting per-user attributes to devices that are doing RADIUS anyway, typically for network access control.   I don't think it addresses every use case, and indeed it may not address *any* use case.  It pretty clearly *doesn't* address your use case.

So all I'm saying is that there may be some motivating use cases for the DHCPv6 route option that could be addressed equally well by RADIUS+RA.   Whether or not any such use cases exist, I do not know.   This is why we need people to clearly document their use cases and avoid hand-waving.   I think we're pretty clear now on your use case, so this comment is not directed at you.

---

From: Ted Lemon <[email-masked]>
Date: Wed, 4 Apr 2012 21:42:07 +0000

Instead of using a lot of analogies and guilt trips, why don't you just tell us what your use case is, Tony?   I'm sorry if you feel like you're not being heard here, but I really do hear you.   I just don't agree.   Maybe others here do, but even if they do, it's not going to help us to make forward progress.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Apr 2012 08:14:24 +0100

> Instead of using a lot of analogies and guilt trips, why don't you just tell us what your use case is, Tony?   I'm sorry if you feel like you're not being heard here, but I really do hear you.   I…

My understanding is that IT departments who currently manage layer 3
aspects of hosts via whatever database tool configures their DHCP[v6]
servers wish to continue doing so, rather than having to use a
different (or updated) tool to configure their RAs. The reason of
course is to reduce operational complexity and expense.

Access providers who already use RADIUS to configure users might
prefer that approach, for exactly the same reason.

This has felt for a long time like a case where we *cannot* reasonably
apply the principle advocated in RFC 1958: "If there are several ways
of doing the same thing, choose one."

  Brian (editor of RFC 1958)

---

From: Ted Lemon <[email-masked]>
Date: Thu, 5 Apr 2012 10:42:05 +0000

> course is to reduce operational complexity and expense.

But *why*?   Please stop talking about feelings.   Please say why. 

For example, if using DHCPv6 instead of RA reduces operational complexity and expense, you should be able to say *why* it does so.

---

From: Brian E Carpenter <[email-masked]>
Date: Thu, 05 Apr 2012 12:18:26 +0100

> For example, if using DHCPv6 instead of RA reduces operational complexity and expense, you should be able to say *why* it does so.

Because using one method of configuring hosts is less complex
and therefore cheaper than using two. It's clear that small simple
networks (the dentist's office scenario in the terminology we used
around 1995) can get by with RA alone, and it's clear that more
complex networks need much more flexibility. MIF and homenet are
both considering complex scenarios by this standard.

I now think that detailing use cases is beside the point. It's
simply a fact that above a certain level of complexity, operators
need the flexibility of DHCPv6 or RADIUS, and in that case, it is
less complex if everything configurable can be configured with the
same tool.

   Brian

---

From: jouni korhonen <[email-masked]>
Date: Thu, 5 Apr 2012 23:27:54 +0300

RADEXT is working on http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-06
which adds attributes for RFC4191 use, for example. That is then also implicitly
available for Diameter.

Assuming unicast RA would be doable using just RFC6085, then there should not
be much, if anything, to do protocol wise. The router that gets provisioned per
host via AAA knows the l2-l3 mapping already.. and the AAA server also learns
it. For dynamic changes of routes, AAA server can use e.g. l2 or l3 addresses
for a session identification when it sends a change of authorization..

The assumption here is that each host gets separately authorized when they attach
the network, which might be an issue on some links & deployments. However, some
network architectures with multiple routers/gateways (can) already use AAA for
centralized address management at per host granularity.

- Jouni

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 5 Apr 2012 15:46:50 -0500

On Thu, Apr 5, 2012 at 3:27 PM, jouni korhonen <[email-masked]> wrote:
> Assuming unicast RA would be doable using just RFC6085,

I don't understand what RFC 6085 has to do with this discussion?

> then there should not

---

From: Sri Gundavelli <[email-masked]>
Date: Mon, 09 Apr 2012 16:01:01 -0700

Response to one specific comment; ignoring/not taking any stand on the rest
of the DHCP/RA discussion...

On 4/5/12 1:27 PM, "jouni korhonen" <[email-masked]> wrote:

> 
> RADEXT is working on
> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-06

Yes. The router can learn the L2 to L3 mapping based on the Router
Solicitations/Attach Triggers of the host. It can also learn this mapping by
being in the Authentication path (supporting Proxy RADIUS), or by means of
handling RADIUS triggers. Now, with respect to unicast RA transmission, the
clarified L3 multicast/L2 unicast semantic defined in 6085 does allow
unicast RA transmission.

Sri

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 10 Apr 2012 12:22:40 +0900

On Fri, Apr 6, 2012 at 05:27, jouni korhonen <[email-masked]> wrote:

>
> RADEXT is working on
> http://tools.ietf.org/html/draft-ietf-radext-ipv6-access-06 which adds
> attributes for RFC4191 use, for example. That is then also
> implicitly available for Diameter.
>

That seems like it would meet the desired use case, right?

> Assuming unicast RA would be doable using just RFC6085, then there should
> not be much, if anything, to do protocol wise.

You mean the text that allows "mapping of an IPv6 packet with a multicast
destination address into an Ethernet link-layer unicast address, when it is
clear that only one address is relevant"?

So, in effect, the router would say that "this RA is only relevant to one
host, so I'm going to unicast it to that one host"?

---

From: Wojciech Dec <[email-masked]>
Date: Tue, 10 Apr 2012 17:09:50 +0200

Folks,

before we get carried away on the "let's use Radius to provision the edge
router" solution, allow me to say that:
a) this is already standardized if not actually practised today
b) it does not solve the problem of the operators who do not directly
control the access edge router (eg think wholesale)
c) it requires not only a specific type of Radius infrastructure, that some
operators choose not to have, but also a specific type of stateful NAS
router (eg a BRAS) that others still also do not want to have.

Beyond the above, and in much the same way as has been argued previously, a
Radius client on the end device solution variant could also be used to
provision the route on the client (or SNMP, or a script, etc).

In theory thus, all of the Radius variants, are all perfectly good
solutions, and standards based too. The practicality of them is a different
matter, and this problem is all about per host configuration and
operational practicality. At least personally, I humbly think that there is
no one size fits all solution in this domain, and "perfectly good
theoretical solutions" are not necessarily practical ones; operators would
much rather have a choice of tools and an understanding of their tradeoffs,
rather than an SDO diktat in terms of how to operate their networks.

My 2c,
-Woj.

On 5 April 2012 22:27, jouni korhonen <[email-masked]> wrote:

> not
> >> It's true, as Jari said, that this can be accomplished in other ways,
> and maybe it would be better if it would.   If there were some better
> central management solution for populating unicast RA mappings on the
> router, then unicast RA would indeed address the exact use case that I
> think we care about.   But without the mechanism for populating routers, we
> still have a poorly-addressed use case.   And then the question is, do we
> want to develop a whole new protocol just to solve this one small problem?
> >>

---

From: Tao Sun <[email-masked]>
Date: Wed, 11 Apr 2012 20:10:18 +0800

People argued quite a lot that RS/RA can be used for the problem. It can be
seen that only rely on the RA based solution, the RA, Radius or even
protocols such as PMIP need to do enhancement or extension.

DHCPv6 option provides more easy way to implement in practice. This makes
the route configuration for multiple interface more easily adopted. Only
put all the hope to the RA related enhancement may prevent operators adopt
this functionality. In the end, neither RA nor DHCPv6 option may be used,
which may delay or even prevent the feature that a host can simultaneous
access through multiple interfaces.

Tao Sun

On Tue, Apr 10, 2012 at 11:09 PM, Wojciech Dec <[email-masked]> wrote:

> c) it requires not only a specific type of Radius infrastructure, that
> some operators choose not to have, but also a specific type of stateful NAS
> Beyond the above, and in much the same way as has been argued previously,
> a Radius client on the end device solution variant could also be used to

---

From: Arifumi Matsumoto <[email-masked]>
Date: Fri, 13 Apr 2012 18:06:40 +0900

Hi,

Besides multi-interface cases, DHCP relay functionality is widely deployed and really helpful function to implement a new way of information distribution.

Replacing or upgrading all the provider edge routers should be real headaches to access network providers, because the amount of edge routers tend to be large, and they are more and more overloaded with various features, and so not cheap. The provider edge routers are the place where control plane and data plane reside together. And DHCP servers and RADIUS servers are those entities separated from the data plane, so they are relatively cheaper and easier to get upgraded.

From the access network provider perspective,
RADIUS based approach needs standardization, implementation at the routing equipments, and upgrade of RADIUS servers.
DHCP based approach needs upgrade of just the DHCP servers.

How can we say this is not the show stopper ?

Best regards,

On 2012/04/11, at 21:10, Tao Sun wrote:

> People argued quite a lot that RS/RA can be used for the problem. It can be seen that only rely on the RA based solution, the RA, Radius or even protocols such as PMIP need to do enhancement or extension.
>  
> DHCPv6 option provides more easy way to implement in practice. This makes the route configuration for multiple interface more easily adopted. Only put all the hope to the RA related enhancement may prevent operators adopt this functionality. In the end, neither RA nor DHCPv6 option may be used, which may delay or even prevent the feature that a host can simultaneous access through multiple interfaces.
>  
> Tao Sun
> 
> before we get carried away on the "let's use Radius to provision the edge router" solution, allow me to say that:
> b) it does not solve the problem of the operators who do not directly control the access edge router (eg think wholesale)
> c) it requires not only a specific type of Radius infrastructure, that some operators choose not to have, but also a specific type of stateful NAS router (eg a BRAS) that others still also do not want to have.
> 
> Beyond the above, and in much the same way as has been argued previously, a Radius client on the end device solution variant could also be used to provision the route on the client (or SNMP, or a script, etc). 
> 
> In theory thus, all of the Radius variants, are all perfectly good solutions, and standards based too. The practicality of them is a different matter, and this problem is all about per host configuration and operational practicality. At least personally, I humbly think that there is no one size fits all solution in this domain, and "perfectly good theoretical solutions" are not necessarily practical ones; operators would much rather have a choice of tools and an understanding of their tradeoffs, rather than an SDO diktat in terms of how to operate their networks.
> 
> My 2c,
> -Woj.
> 
> 
> 

--
Arifumi Matsumoto
  NGN System Architecture Project
  NTT Service Integration Laboratories
  E-mail: [email-masked]
  TEL +81-422-59-3334 FAX +81-422-59-6364

---

From: Lorenzo Colitti <[email-masked]>
Date: Mon, 16 Apr 2012 11:03:08 +0900

On Fri, Apr 13, 2012 at 18:06, Arifumi Matsumoto <[email-masked]> wrote:

> RADIUS based approach needs standardization, implementation at the routing
> equipments, and upgrade of RADIUS servers.

I don't think that's a valid argument. You could say exactly the same about
RAs:

"DHCPv6 based approach needs standardization, implementation at the host
and CPE, and upgrade of DHCPv6 servers.
RA based approach needs upgrade of just the edge routers.

How can we say this is not a showstopper?"

(Yes - my paragraph omits the fact that the RADIUS servers need to be
updated. But your paragraph omits the fact that the hosts / CPEs need to be
updated, too.)

Basically, using DHCPv6 is pushing the state out of the network and on to
the CPE or the host. I'm sure this is desirable if you're a network
operator. However, it's not so desirable if you're a host or CPE developer.

In general, I think pushing complexity and state to the host is fine,
because hosts are the smartest entities in the network. However, I think
that DHCPv6 is the wrong tool for the job, because its semantics
(essentially, static configuration information that will not change for the
duration of the lease, and cannot be invalidated if the DHCPv6 server goes
away) are not rich enough to communicate routing information.

---

From: Arifumi Matsumoto <[email-masked]>
Date: Mon, 23 Apr 2012 18:31:21 +0900

Hi,

sorry for late response.

On 2012/04/16, at 11:03, Lorenzo Colitti wrote:

> I don't think that's a valid argument. You could say exactly the same about RAs:

I said, "From the access network provider perspective".
It is the cost they have to pay that matters to them.

> 
> "DHCPv6 based approach needs standardization, implementation at the host and CPE, and upgrade of DHCPv6 servers.

AFAIK, only Windows Vista and above supports RFC 4191 by default, though.

Best regards,

> (Yes - my paragraph omits the fact that the RADIUS servers need to be updated. But your paragraph omits the fact that the hosts / CPEs need to be updated, too.)
> 
> Basically, using DHCPv6 is pushing the state out of the network and on to the CPE or the host. I'm sure this is desirable if you're a network operator. However, it's not so desirable if you're a host or CPE developer.
> 
> In general, I think pushing complexity and state to the host is fine, because hosts are the smartest entities in the network. However, I think that DHCPv6 is the wrong tool for the job, because its semantics (essentially, static configuration information that will not change for the duration of the lease, and cannot be invalidated if the DHCPv6 server goes away) are not rich enough to communicate routing information.

---

From: Ted Lemon <[email-masked]>
Date: Mon, 23 Apr 2012 13:38:15 +0000

> It is the cost they have to pay that matters to them.

It would help to complete this argument if you unpacked the details here.   Why is RA so much more expensive than DHCP in this case?   I get the sense that this is obvious to the people who are promoting various DHCP route options, but it clearly isn't obvious to people who aren't network operators, so more detail is needed.

> AFAIK, only Windows Vista and above supports RFC 4191 by default, though.

This is not a good argument.   Windows Vista is ancient.   We can't define IPv6 in terms of the functionality present in Windows XP.

---

From: Maglione Roberta <[email-masked]>
Date: Tue, 24 Apr 2012 09:06:31 +0200

> It would help to complete this argument if you unpacked the details here.   > Why is RA so much more expensive than DHCP in this case?   I get the sense > that this is obvious to the people who are promoting various DHCP route
> options, but it clearly isn't obvious to people who aren't network
> operators, so more detail is needed.

Because in order to be able to use RA's you would need to somehow provision each single BNG (the router that is supposed to send the RA) with the route information to be sent into RA's for all the subscribers and if, for any reason, you need to move a subscriber from one BNG to another you would need to re-provision the same information on the other BNG.

While with DHCPv6 you can have a single centralized provision point and no additional configuration required on the BNG.  This is an operational difference for an operator.

Best regards,
Roberta

-----Original Message-----
From: [email-masked] [mailto:[email-masked]] On Behalf Of Ted Lemon
Sent: lunedì 23 aprile 2012 15.38
To: Arifumi Matsumoto
Cc: MIF List Mailing
Subject: Re: [mif] Route option for DHCPv6 - next steps?

Questo messaggio e i suoi allegati sono indirizzati esclusivamente alle persone indicate. La diffusione, copia o qualsiasi altra azione derivante dalla conoscenza di queste informazioni sono rigorosamente vietate. Qualora abbiate ricevuto questo documento per errore siete cortesemente pregati di darne immediata comunicazione al mittente e di provvedere alla sua distruzione, Grazie.

This e-mail and any attachments is confidential and may contain privileged information intended for the addressee(s) only. Dissemination, copying, printing or use by anybody else is unauthorised. If you are not the intended recipient, please delete this message and any attachments and advise the sender by return e-mail, Thanks.

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Apr 2012 16:18:20 +0900

On Tue, Apr 24, 2012 at 16:06, Maglione Roberta <
[email-masked]> wrote:

> Because in order to be able to use RA's you would need to somehow
> provision each single BNG (the router that is supposed to send the RA) with
> the route information to be sent into RA's for all the subscribers and if,
> for any reason, you need to move a subscriber from one BNG to another you
> would need to re-provision the same information on the other BNG.
>

Right. That's why RADIUS was mentioned earlier in this thread.

> While with DHCPv6 you can have a single centralized provision point and no
> additional configuration required on the BNG.  This is an operational
> difference for an operator.
>

But you have to update all the clients.

---

From: Brian E Carpenter <[email-masked]>
Date: Tue, 24 Apr 2012 08:22:47 +0100

> While with DHCPv6 you can have a single centralized provision point and no additional configuration required on the BNG.  This is an operational difference for an operator.

Unfortunately, people with zero experience of running a reasonably large
network seem unable to understand this elementary point.

This is much bigger than a MIF issue.

   Brian

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Apr 2012 09:23:58 +0200

Le 23/04/2012 15:38, Ted Lemon a écrit :
> On Apr 23, 2012, at 5:31 AM, Arifumi Matsumoto<[email-masked]>
> wrote:
>> I said, "From the access network provider perspective". It is the
>> cost they have to pay that matters to them.
>
> It would help to complete this argument if you unpacked the details
> here.   Why is RA so much more expensive than DHCP in this case?   I
> get the sense that this is obvious to the people who are promoting
> various DHCP route options, but it clearly isn't obvious to people
> who aren't network operators, so more detail is needed.

Let me add a comment here.

One part of the higher expense of RA vs DHCP is the burden of
administrative management.  An operator using RA to configure
RFC4191/4861 default and specific routes needs to put various
configuration data (the contents of radvd.conf) in _each_ access router
on which end user connect.

For an ADSL-type ISP this means to remotely configure, and maintain,
each first-hop router (CPE+1) with different sets of specific routes,
and each such router with a different default route.  It means there are
risks of collision (two specific routes valid at two different points,
upon wrong updates), risks of wrong default routes upon network card
replacement, and so on.

It would be easier to have all the default/specific routes written
centralized on a single (load-balanced?) server and push this data to
the first-hop routers upon request from clients - more coeherence, less
collision risks, higher reusability of specific routes.  It's what DHCP
does: the CPE+1 router is a Relay and the config file is in a unique
DHCP Server.

> This is not a good argument.   Windows Vista is ancient.   We can't
> define IPv6 in terms of the functionality present in Windows XP.

I have a comment about this, in the ADSL-type ISP case.

The CPE box wouldn't be a Windows machine.  It would be unix, and it
would be a router.  Thus, receiving RFC4191 specific routes from an RA
from CPE+1 would leave it shrugging shoulders.

If one wants to deliver specific routes to a CPE box one would't use
RAs, because routers ignore much of info in them.

Alex

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

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Apr 2012 16:29:14 +0900

> from CPE+1 would leave it shrugging shoulders.

Why? The Linux Kernel supports RFC 4191, for example.

> RAs, because routers ignore much of info in them.

RFC 6204 specifies how IPv6 CPEs should listen to default routes in router
advertisements. The CPEs could listen to more-specific routes as well.

---

From: Maglione Roberta <[email-masked]>
Date: Tue, 24 Apr 2012 09:29:38 +0200

> Right. That's why RADIUS was mentioned earlier in this thread.

and it was already clarified in this thread that RADIUS cannot be applicable in all scenarios.
http://www.ietf.org/mail-archive/web/mif/current/msg01757.html

Roberta

________________________________
From: Lorenzo Colitti [mailto:[email-masked]]
Sent: martedì 24 aprile 2012 9.18
To: Maglione Roberta
Cc: Ted Lemon; Arifumi Matsumoto; MIF List Mailing
Subject: Re: [mif] Route option for DHCPv6 - next steps?

On Tue, Apr 24, 2012 at 16:06, Maglione Roberta <[email-masked]<mailto:[email-masked]>> wrote:
Because in order to be able to use RA's you would need to somehow provision each single BNG (the router that is supposed to send the RA) with the route information to be sent into RA's for all the subscribers and if, for any reason, you need to move a subscriber from one BNG to another you would need to re-provision the same information on the other BNG.

Rispetta l'ambiente. Non stampare questa mail se non è necessario.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Apr 2012 09:52:50 +0200

Le 24/04/2012 09:29, Lorenzo Colitti a écrit :
> On Tue, Apr 24, 2012 at 16:23, Alexandru Petrescu
> <[email-masked] <mailto:[email-masked]>> wrote:
>>

Yes, linux kernel would support it, as a Host.  The CPE is not a Host.
(yes, a flag may exist to force it be a Router _and_ listen to RA - but
  is that flag standard).

> RFC 6204 specifies how IPv6 CPEs should listen to default routes in
> router advertisements. The CPEs could listen to more-specific routes as
> well.

This may mean one may need to: (1) modify RFC6204 to cover specific 
routes as well, (2) modify RFC4191 to cover Routers as well, (3) modify 
RFC6204 to do cellular base stations as well, in addition to CPE of 
ADSL-type.

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Tue, 24 Apr 2012 17:04:29 +0900

> (yes, a flag may exist to force it be a Router _and_ listen to RA - but

For the kernel, I believe all you need to do is enable forwarding
separately on the upstream and downstream interfaces instead of enabling
forwarding globally (but I'm not 100% sure so feel free to correct me if
that's wrong). That said, regardless of how it needs to be implemented,
Linux-based CPEs have to do it already if they implement RFC 6204.

> This may mean one may need to: (1) modify RFC6204 to cover specific routes
> as well, (2) modify RFC4191 to cover Routers as well, (3) modify RFC6204 to
> do cellular base stations as well, in addition to CPE of ADSL-type.
>

As for #1 and #2, RFC 6024 doesn't explicitly specify what CPEs should
listen to in RAs. I mentioned the default route earlier, but it mentions
lots of other things too (e.g., the prefix information option to do SLAAC
on the ISP-side interface, the L bit, and so on). If the CPE doesn't
already support RFC 4191 (which is possible, if it's just using the
standard Linux code), then it needs a code change regardless of whether you
want to use DHCPv6 or RFC 4194.

As for #3: RFC 6204 doesn't specify any specific technology, and it's
certainly not limited to ADSL. Much of the behaviour it specifies is
equally applicable to CPEs whose uplink is a cellular link.

---

From: Alexandru Petrescu <[email-masked]>
Date: Tue, 24 Apr 2012 14:20:00 +0200

Le 24/04/2012 10:04, Lorenzo Colitti a écrit :
> On Tue, Apr 24, 2012 at 16:52, Alexandru Petrescu
>     routes as well, (2) modify RFC4191 to cover Routers as well, (3)
>     modify RFC6204 to do cellular base stations as well, in addition to
>     CPE of ADSL-type.
>
>
> lots of other things too (e.g., the prefix information option to do
> SLAAC on the ISP-side interface, the L bit, and so on).

For example, RFC6204 says:
>    W-1:  When the router is attached to the WAN interface link, it MUST
>          act as an IPv6 host for the purposes of stateless [RFC4862] or
>          stateful [RFC3315] interface address assignment.

That is not enough for specific routes.  Ok it covers the default 
routes, but not specific routes such as rfc4191.

> If the CPE
> doesn't already support RFC 4191 (which is possible, if it's just using
> the standard Linux code), then it needs a code change regardless of
> whether you want to use DHCPv6 or RFC 4194.
>

?

'CPE' is not a term used for the cellular links, I think. RFC6204 says
'residential or small-office router'. I think it is a stretch to claim
that RFC6204 applies to cellular links. E.g. few if any cellular
terminals use DHCP as of today, whereas RFC6204 would require them all
to. Also, RFC6204 requires all cellular terminals to use Ethernet
encapsulation on their WAN interface whereas none actually does.

There is another RFC - 3316 - "IPv6 for some 2G and 3G Cellular Hosts"
which relates more to cellular.

Alex

---

From: jouni korhonen <[email-masked]>
Date: Wed, 25 Apr 2012 11:33:38 +0300

On Apr 24, 2012, at 3:20 PM, Alexandru Petrescu wrote:

[snip]

> that RFC6204 applies to cellular links. E.g. few if any cellular

RFC6204 is not necessarily the best fit for cellular (6204bis does it 
better) but it definitely does not preclude one making a compliant CE
device with a cellular WAN link.

> to. Also, RFC6204 requires all cellular terminals to use Ethernet

So? You would most likely use your cellular just as a modem to connect
to network and the rest of the system & stack would be in the host side
of the CE. This is sometimes referred as the "split-UE" in 3GPP circles.

> encapsulation on their WAN interface whereas none actually does.

All WLL-* requirements start with "If the WAN interface supports.."
effectively making the following MUST conditional. Those MUSTs, like
for ethernet, apply only when the WAN implements the said technology.

> which relates more to cellular.

Or a bit more recent RFC6459..

- Jouni

---

From: Lorenzo Colitti <[email-masked]>
Date: Wed, 25 Apr 2012 18:03:31 +0900

On Tue, Apr 24, 2012 at 21:20, Alexandru Petrescu <
[email-masked]> wrote:

> That is not enough for specific routes.  Ok it covers the default routes,
> but not specific routes such as rfc4191.

Sure. But RFC 6204 also doesn't say "must implement a DHCPv6 route option".
So if you want to ensure that the CE router can configure more-specific
routes, you have to modify RFC 6204 either way.

In one case, you need to modify it to say "must implement a DHCPv6 route
option". In the other, you need to modify it to say "must implement RFC
4191". Note that the RFC already says that "nodes that will be deployed
in SOHO environments SHOULD implement RFC 4191", so RFC 4191 is likely
already implemented.

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Apr 2012 22:43:49 +0200

Le 25/04/2012 11:03, Lorenzo Colitti a écrit :
> On Tue, Apr 24, 2012 at 21:20, Alexandru Petrescu
> Sure. But RFC 6204 also doesn't say "must implement a DHCPv6 route
> option". So if you want to ensure that the CE router can configure
> more-specific routes, you have to modify RFC 6204 either way.

Right, so either way RFC 6204 wouldn't be enough when one wants to 
achieve DHCP route-options neither DHCP default routes.

> in SOHO environments SHOULD implement RFC 4191", so RFC 4191 is likely

What does that "nodes" mean?  In that RFC 6204 context I guess it means 
all entities in the SOHO except the CPE.

At most, I think it means that the CPE sends 4191 RAs to SOHO Hosts 
which neead to read 4191 RAs.  I don't think it means a CPE router to 
read 4191 RAs sent by CPE+1 ISP routers.

A router to read 4191-specific-route does not exist today.

In this case, what would one prefer to specify - a 4191 router to read 
specific routes from 4191?  Or a DHCP Client already doing Prefix 
Delegation (a Requesting Router) to read DHCP route options and default 
route options?

Alex

---

From: Alexandru Petrescu <[email-masked]>
Date: Wed, 25 Apr 2012 22:55:23 +0200

Le 25/04/2012 10:33, jouni korhonen a écrit :
> better)

Do you mean http://tools.ietf.org/html/draft-ietf-v6ops-6204bis-08 ?

> but it definitely does not preclude one making a compliant CE
> to network and the rest of the system&  stack would be in the host side

No cellular air interface to the terminal technology implements Ethernet 
encapsulation, so I don't understand the presence of that precluding If 
qualifier. (802.16 is not cellular).

> Or a bit more recent RFC6459.

Thanks for the pointer to RFC6459 "IPv6 in 3GPP EPS".  I checked its 
Prefix Delegation section and I have comments on it, but I guess it's 
not here to be discussed about.

BAsically that section does not tell what a UE router receving a /64 can 
do with its Ethernet-compatible attached devices doing SLAAC.  In 
practice that means to either forbid SLAAC for the devices (use DHCP) or 
impossibility to use the /64 coming from the network.

This section together with 3GPP documents I looked at recently are pure 
forms of speculation with no implementation couterpart.

(in other document we propose a solution for it, which, if given way, 
makes further the case for using default routes also in DHCP).

Alex

---

From: Lorenzo Colitti <[email-masked]>
Date: Thu, 26 Apr 2012 12:41:45 +0900

On Thu, Apr 26, 2012 at 05:43, Alexandru Petrescu <
[email-masked]> wrote:

> In one case, you need to modify it to say "must implement a DHCPv6
>> route option". In the other, you need to modify it to say "must implement
>> RFC 4191". Note that the RFC already says that "nodes that will be
>> deployed in SOHO environments SHOULD implement RFC 4191", so RFC 4191 is
>> likely already implemented.
>>
>

"Node" is defined by RFC 2460 as "a device that implements IPv6"

> At most, I think it means that the CPE sends 4191 RAs to SOHO Hosts which
> neead to read 4191 RAs.  I don't think it means a CPE router to read 4191
> RAs sent by CPE+1 ISP routers.
>

Nope. The CPE is a node, and thus per RFC 6434 (IPv6 node requirements) it
SHOULD implement RFC 4191 if it's deployed in a SOHO environment.

> A router to read 4191-specific-route does not exist today.

The linux kernel supports it, I believe.

> Delegation (a Requesting Router) to read DHCP route options and default

I think RFC 4191 has much richer semantics (multiple sources of
information, early deprecation, deprecation when the router originally
crashes). So I would prefer RFC 4191. As we know from this thread, others
disagree. :-)

---

From: Behcet Sarikaya <[email-masked]>
Date: Thu, 26 Apr 2012 10:47:12 -0500

Hi Lorenzo,

On Wed, Apr 25, 2012 at 10:41 PM, Lorenzo Colitti <[email-masked]> wrote:
> On Thu, Apr 26, 2012 at 05:43, Alexandru Petrescu
> <[email-masked]> wrote:
>>>
>> specific routes from 4191?  Or a DHCP Client already doing Prefix Delegation
>> (a Requesting Router) to read DHCP route options and default route options?
>
>
> I think RFC 4191 has much richer semantics (multiple sources of information,
> early deprecation, deprecation when the router originally crashes). So I
> would prefer RFC 4191. As we know from this thread, others disagree. :-)

RFC 4191 needs to be extended in view of route option work in MIF, I
think. This is what we have done in
http://tools.ietf.org/html/draft-sarikaya-mif-6man-ra-route-00

Take a look.

Behcet