RE: DHCPv6 relay with PD

2016-06-08 Thread Templin, Fred L
Hi Nick,

More on this, please see Section 3.7 on the AERO Routing System (2 pages). It 
tells
how the DHCPv6 relay can inject delegated prefixes into the routing system 
without
imparting unacceptable churn and while allowing scaling to many millions of 
delegated
prefixes. There is a terminology gap to overcome in that an "AERO Server" 
actually
implements both a DHCPv6 server and relay, while an "AERO Relay" is a simple BGP
router and does not implement any DHCPv6 functions.

The section is only two pages long. Let me know if you have any questions or
comments.

Fred

> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de 
> [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Templin, 
> Fred L
> Sent: Wednesday, June 08, 2016 2:35 PM
> To: Nick Hilliard 
> Cc: ipv6-ops@lists.cluenet.de
> Subject: RE: DHCPv6 relay with PD
> 
> Hi Nick,
> 
> > -Original Message-
> > From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de 
> > [mailto:ipv6-ops-
> > bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Nick 
> > Hilliard
> > Sent: Wednesday, June 08, 2016 2:13 PM
> > To: Templin, Fred L 
> > Cc: ipv6-ops@lists.cluenet.de
> > Subject: Re: DHCPv6 relay with PD
> >
> > Templin, Fred L wrote:
> > > Folks, for real – read AERO. It works. I apologize if that offends anyone.
> >
> > Not at all.  It's just that I'm confused about why we would need to
> > resort to a tunneling protocol in order to make basic ipv6 functionality
> > work.
> >
> > Would it not be better to try to make ipv6 work without resorting to
> > tunnels?
> 
> Mobile clients that can change their point of attachment to the network and
> may be many hops away from the DHCPv6 relay are the primary use case that
> AERO is addressing. But, the way in which AERO manages the routing system
> I think applies even when tunnels aren't needed and the clients are on the
> same link as the relays.
> 
> Thanks - Fred
> fred.l.temp...@boeing.com
> 
> > Nick



RE: DHCPv6 relay with PD

2016-06-08 Thread Templin, Fred L
Hi Nick,

> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de 
> [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Nick Hilliard
> Sent: Wednesday, June 08, 2016 2:13 PM
> To: Templin, Fred L 
> Cc: ipv6-ops@lists.cluenet.de
> Subject: Re: DHCPv6 relay with PD
> 
> Templin, Fred L wrote:
> > Folks, for real – read AERO. It works. I apologize if that offends anyone.
> 
> Not at all.  It's just that I'm confused about why we would need to
> resort to a tunneling protocol in order to make basic ipv6 functionality
> work.
> 
> Would it not be better to try to make ipv6 work without resorting to
> tunnels?

Mobile clients that can change their point of attachment to the network and
may be many hops away from the DHCPv6 relay are the primary use case that
AERO is addressing. But, the way in which AERO manages the routing system
I think applies even when tunnels aren't needed and the clients are on the
same link as the relays.

Thanks - Fred
fred.l.temp...@boeing.com

> Nick



Re: DHCPv6 relay with PD

2016-06-08 Thread Nick Hilliard
Templin, Fred L wrote:
> Folks, for real – read AERO. It works. I apologize if that offends anyone.

Not at all.  It's just that I'm confused about why we would need to
resort to a tunneling protocol in order to make basic ipv6 functionality
work.

Would it not be better to try to make ipv6 work without resorting to
tunnels?

Nick


Re: DHCPv6 relay with PD

2016-06-08 Thread james machado
Wait, Wait!

So your telling me that it's wrong for DHCPv6 servers to feed default
gateways to endpoints because "who better than the router to know whom to
route too" but for DHCPv6-PD we should rely on the DHCPv6 servers to do
route injection?

This is classic!  just classic!

Take this back to the *Ivory Tower Population*(tm).  What we need now are
RA-PD packets!  Down with DHCPv6 servers doing useful work. We are in
danger of Non-Routing Personnel making Routing Decisions!

Man the Battlements! Light the Fires! Heed the call of the RA-PDs!  This
must be done *Real Soon Now*(tm)



On a more serious note.

v6 has given us crippled DHCP servers but now it looks like we are going to
need route injection servers just to do PD?

time for v7.

james

On Wed, Jun 8, 2016 at 1:15 PM, Mikael Abrahamsson  wrote:

> On Wed, 8 Jun 2016, Ole Troan wrote:
>
> So basically, regarding how to actually implement PD in a network (from an
>>> IETF point of view), everybody just gave up, declared the problem
>>> unsolvable, and went back to sleep?
>>>
>>
>> It shouldn't be the IETF's job to tell people how to run their networks.
>> The IETF provides the building blocks.
>>
>
> Seems to me that IETF in this case failed to provide a suggestion for a
> working solution.
>
> So neither equipment vendors nor network operators now have any kind of
> recommendation on how to do things, and we now see that several vendors
> have failed to implement DHCPv6-PD with routing in their equipment, and
> network operators are now supposed to modify their DHCPv6 backend servers
> to provision static routes in their routers? Is there even an IETF
> recommendation document that says this is the way things should be done?
> And that indentifies pitfalls in doing so?
>
>
> --
> Mikael Abrahamssonemail: swm...@swm.pp.se
>


Re: DHCPv6 relay with PD

2016-06-08 Thread Ole Troan
>>> So basically, regarding how to actually implement PD in a network (from an 
>>> IETF point of view), everybody just gave up, declared the problem 
>>> unsolvable, and went back to sleep?
>> 
>> It shouldn't be the IETF's job to tell people how to run their networks.
>> The IETF provides the building blocks.
> 
> Seems to me that IETF in this case failed to provide a suggestion for a 
> working solution.
> 
> So neither equipment vendors nor network operators now have any kind of 
> recommendation on how to do things, and we now see that several vendors have 
> failed to implement DHCPv6-PD with routing in their equipment, and network 
> operators are now supposed to modify their DHCPv6 backend servers to 
> provision static routes in their routers? Is there even an IETF 
> recommendation document that says this is the way things should be done? And 
> that indentifies pitfalls in doing so?

an interesting twist of blaming the IETF.
usually it's the IETF blaming the "market" that it doesn't adopt any of its 
more or less brilliant standards. ;-)

if you want anything to happen here, write a draft. not that we have an RFC 
describing DHCPv4 snooping either, so I'd hope you come up with something 
clever! ;-)

Best regards,
Ole


signature.asc
Description: Message signed with OpenPGP using GPGMail


Re: DHCPv6 relay with PD

2016-06-08 Thread Nick Hilliard
Ole Troan wrote:
> It shouldn't be the IETF's job to tell people how to run their networks.
> The IETF provides the building blocks.

Take a DHCP server, an ISP access router and a CPE.

The CPE connects to the ISP access router and issues a dhcp request.
This is relayed by the access device to the dhcp server which replies to
access device with a PD reply.  The access router relays this reply to
the CPE.

At this point, the state is that both the CPE and the dhcp server know
the delegated prefix, but the access router does not.  The result is
that the customer's prefix is not routed to the CPE.

The question is: how do we make this work so that PD is a viable
mechanism for handling customer ipv6 requirements?

The ISP operator cannot listen to the CPE if it's running a routing
protocol because the access router has no way of determining whether any
announcement it receives from the CPE is a legitimate announcement,
because it has no knowledge of what is or isn't assigned to a particular
customer.

Installing static routes on the access router is non-scalable and
constrains the network architecture in a way which isn't feasible.

It might work if the access router implements dhcpv6 snooping, but the
isp operator has little or no control over this.

I know you're not trying to be unhelpful here, but brushing this off as
someone-else's-problem is not going to make the problem go away.  Nor is
claiming that this is a problem with how the network is run, because
this isn't a problem that operators can feasibly fix because it's a
problem that vendors need to solve, potentially helped with some
guidelines from the ietf.

Nick


RE: DHCPv6 relay with PD

2016-06-08 Thread Templin, Fred L
Hi,

> -Original Message-
> From: ipv6-ops-bounces+fred.l.templin=boeing@lists.cluenet.de 
> [mailto:ipv6-ops-
> bounces+fred.l.templin=boeing@lists.cluenet.de] On Behalf Of Erik Kline
> Sent: Wednesday, June 08, 2016 11:37 AM
> To: Ole Troan 
> Cc: IPv6 Ops list ; Mikael Abrahamsson 
> 
> Subject: Re: DHCPv6 relay with PD
> 
> On 9 June 2016 at 03:16, Ole Troan  wrote:
> > Mikael,
> >
> >>> We also tried (and failed) to come up with a secure mechanism for the 
> >>> requesting router to advertise it's delegated prefix to first-
> hop routers.
> >>>
> >>> Less astonished? ;-)
> >>
> >> Well, I guess I shouldn't be astonished. I've even seen vendors implement 
> >> the DHCPv6-PD server on the router itself, and fail to
> install route according to the delegated prefix.
> >>
> >> So basically, regarding how to actually implement PD in a network (from an 
> >> IETF point of view), everybody just gave up, declared
> the problem unsolvable, and went back to sleep?
> >
> > It shouldn't be the IETF's job to tell people how to run their networks.
> > The IETF provides the building blocks.
> 
> But this sounds like what's missing is operational guidance on what
> collections of blocks have been known to work.

AERO provides operational guidance on collections of blocks that work:

https://datatracker.ietf.org/doc/draft-templin-aerolink/

Thanks - Fred



Re: DHCPv6 relay with PD

2016-06-08 Thread Mikael Abrahamsson

On Wed, 8 Jun 2016, Ole Troan wrote:


I've talked to several people who claim there are lots of equipment out there 
which will happily do DHCPv6 relaying of PD messages, but then not install a 
route for the corresponding delegation.


That's perfectly fine behaviour by the way.
DHCPv6 PD snooping is just one way of doing route injection, among many.


Ok, I invoke https://en.wikipedia.org/wiki/Principle_of_least_astonishment

Does the DHCPv6-PD server backend have access to all information needed to 
trigger a provisioning system to install/remove a static route on the 
relay?


What other methods are there apart from provisioning a static route on the 
relay? BGP?


--
Mikael Abrahamssonemail: swm...@swm.pp.se