Re: IPv6 Prefix Delegation to customers.

[Henri Wahl]

Hi,
>
> Where I am struggling is the Prefix Delegation part. How are most
> folks getting the PD subnets into their IGPs? In my environment I
> don’t run the DHCP server process on the router that is directly
> connected to the clients.
>
Our project dhcpy6d allows to call some command when a prefix has been
delegated. This can be used to set this route via a ssh on the router
device. Maybe this would work for you too?

Best regards

-- 
Henri Wahl

IT Department
Leibniz-Institut fuer Festkoerper- u.
Werkstoffforschung Dresden

tel: +49 (3 51) 46 59 - 797
email: h.w...@ifw-dresden.de
https://www.ifw-dresden.de

Nagios status monitor Nagstamon: https://nagstamon.ifw-dresden.de

DHCPv6 server dhcpy6d: https://dhcpy6d.ifw-dresden.de

S/MIME: https://nagstamon.ifw-dresden.de/pubkeys/smime.pem
PGP: https://nagstamon.ifw-dresden.de/pubkeys/pgp.asc



smime.p7s
Description: S/MIME Cryptographic Signature

Re: IPv6 Prefix Delegation to customers.

[Radu-Adrian Feurdean]

On Thu, Jan 16, 2020, at 06:15, Hugo Slabbert wrote:
> https://mailman.nanog.org/pipermail/nanog/2019-May/101016.html

Actually that one DOES contain some information. 
TL;DR:
 - check the "subscriber" or "broadband" functionality of your gear if it has 
something like that - check if the DHCPv6 relay functionality on your gear can 
inject the delegated prefixes into IGP or BGP
 - if you just have an L2 up to the DHCPv6 server, you're most likely out of 
lack (an not only for the DHCPv6 part)
 - you can always build something on your own if you have the ressources (take 
the delegated prefixes from your server, inject them into something like 
ExaBGP/BIRD/whatever that will re-announce them to your network).

Re: 5G roadblock: labor

[Mark Tinka]

On 15/Jan/20 12:20, Alexandre Petrescu wrote:

>
>
> Arcep (the regulator) today mentions 5G in 2020 will be mostly an
> improved 4G, not the full plain 5G.  (makes think of 4G+ which is
> already widely available since some months).

This is an important point.


> iphone 11 is sold since September, with a feature list including
> codecs and frequencies which make think of 5G.

The iPhone certainly doesn't support 5G, but it does support 802.11ax.

Mark.

Re: IPv6 Prefix Delegation to customers.

[Hugo Slabbert]

Unfortunately not too much help, but previous discussion on this turned up
fairly empty:
https://mailman.nanog.org/pipermail/nanog/2019-May/101016.html
https://mailman.nanog.org/pipermail/nanog/2017-September/092416.html

-- 
Hugo Slabbert   | email, xmpp/jabber: h...@slabnet.com
pgp key: B178313E   | also on Signal


On Wed, Jan 15, 2020 at 6:02 PM Brandon Price 
wrote:

> Hey Nanog,
>
>
>
> I am in the process of building out a FTTH proof of concept, and I would
> really like to offer each of my customers a /48 of IPv6.
>
> I’ve been able to announce my /32 to my upstreams, dual-stack all of my
> internal infrastructure no-problem, build v6 recursive name servers, etc.
>
> This was fairly straight-forward.
>
>
>
> Where I am struggling is the Prefix Delegation part. How are most folks
> getting the PD subnets into their IGPs? In my environment I don’t run the
> DHCP server process on the router that is directly connected to the
> clients. I have seen documentation that cisco and juniper DHCPv6 processes
> are smart enough to insert that prefix into the routing table when they
> hand it out, but how is this handled in an environment with a central DHCP
> server? I do not currently run any PPPOE in my environment and I don’t use
> RADIUS for the subscriber management. I would really just like to stick to
> DHCP ideally.
>
>
>
> If anyone has any pointers, I would appreciate it.
>
>
>
> Brandon Price
>
> Senior Network Engineer
>
> City of Sherwood, Sherwood Broadband
>
> Desk: 503.625.4258
>
> Cell: 971.979.2182
>
>
>
> This email may contain confidential information or privileged material and
> is intended for use solely by the above referenced recipient. Any review,
> copying, printing, disclosure, distribution, or other use by any other
> person or entity is strictly prohibited and may be illegal. If you are not
> the named recipient, or believe you have received this email in error,
> please immediately notify the City of Sherwood at (503) 625-5522 and delete
> the copy you received.
>

IPv6 Prefix Delegation to customers.

[Brandon Price]

Hey Nanog,

I am in the process of building out a FTTH proof of concept, and I would really 
like to offer each of my customers a /48 of IPv6.
I've been able to announce my /32 to my upstreams, dual-stack all of my 
internal infrastructure no-problem, build v6 recursive name servers, etc.
This was fairly straight-forward.

Where I am struggling is the Prefix Delegation part. How are most folks getting 
the PD subnets into their IGPs? In my environment I don't run the DHCP server 
process on the router that is directly connected to the clients. I have seen 
documentation that cisco and juniper DHCPv6 processes are smart enough to 
insert that prefix into the routing table when they hand it out, but how is 
this handled in an environment with a central DHCP server? I do not currently 
run any PPPOE in my environment and I don't use RADIUS for the subscriber 
management. I would really just like to stick to DHCP ideally.

If anyone has any pointers, I would appreciate it.

Brandon Price
Senior Network Engineer
City of Sherwood, Sherwood Broadband
Desk: 503.625.4258
Cell: 971.979.2182


This email may contain confidential information or privileged material and is 
intended for use solely by the above referenced recipient. Any review, copying, 
printing, disclosure, distribution, or other use by any other person or entity 
is strictly prohibited and may be illegal. If you are not the named recipient, 
or believe you have received this email in error, please immediately notify the 
City of Sherwood at (503) 625-5522 and delete the copy you received.

Re: 5G roadblock: labor

[Alexandre Petrescu]

Le 29/12/2019 à 23:49, Michael Thomas a écrit :


https://www.politico.com/news/2019/12/29/big-barrier-trump-5g-america-089883 



An interesting article on the road to 5G that they need to about double 
the size of the workforce to roll it out. I expect that this affects 
some of you directly.


But one of its premises seems a little shaky to me: has the US ever led 
the pack rolling out new network technology? I always thought it was 
Japan and South Korea that were years ahead of us. In silicon valley and 
SF it's still very rare to see FTTH. I'm not sure why we would expect to 
get to 5G any faster than we normally do.


Mike



In France, the situation is the following: it is not clear whether or 
not 5G will be available to lambda end users (Mr "tout le monde") in 2020.


All the data below is from publicly available sources like printed 
press, TV, and the web.


There is a plan by the regulator to allocate the 3500MHz band to various 
 operators, for money (auctions, "enchères").  There is a public 
ambition under the form of a timeline running until end of year, with 
various well identified steps.  One of the key steps is the delivery of 
authorisations to operators in the second trimester (3-month period of 
the year) of 2020.


Arcep mentions that, depending on 'department' (region), the 5G 
frequencies will be available for use in 2020 or in 2021. (remark 
'availability for use' different than 'selling').


Arcep (the regulator) today mentions 5G in 2020 will be mostly an 
improved 4G, not the full plain 5G.  (makes think of 4G+ which is 
already widely available since some months).


SFR operator touted "5G in 2020" by certain TV advertisements in 
December (CNEWS) but it stopped since.  It's important because in the 
past they also touted 4G before all the others, even though they were 
almost the first to deliver.


iphone 11 is sold since September, with a feature list including codecs 
and frequencies which make think of 5G.


Several 5G trials are listed and centralized on an Arcep site.  They 
have publicly visible specific licenses (pdf documents) which last 
explicitely for about 6 months, to be reviewed.  Warning - some of them 
are not really using 5G freq bands, but other techs.  Some of them are 
internal in buildings, not outdoors.  Only a very few approach to what 
5G is.


Spain and Germany witness similar evolutions.

All these data, dates, timelines, commitments change every few months. 
For example, in a region named 'Saclay' 5G was ambitionned for 
demonstration in 2019 with public announcements.  But it was retired a 
few months before 2019 by a manufacturer.  The retiring of the 
announcement was public, but in silence so to say.  The reasons given 
for the retirement of the 2019 5G ambition are technical.


Alex

Re: DDoS Mitigation Survey

[Lumin Shi]

Hi Roland,

Thank you for your comments and resources.  I think you may have
misunderstood our email (we could've made our email more clear --
apologies).

The following is our explanation if we interpreted your email correctly.

What we meant by "may not have necessary capacity" is that routers do not
have enough CAM/TCAM space to deploy/install ACLs, BGP FlowSpec rules
against large-scale DDoS attacks without 1) incurring major collateral
damage (e.g., deploy /16 source-based rules instead of /32 so that more
DDoS traffic can be filtered while using less CAM/TCAM space), or 2)
performance penalties that are introduced by deploying more filters than a
router's data plane can support (i.e., data plane to control plane I/O
limitation).

We believe DDoS mitigation based on layer 3 and/or 4 information can be
fine-grain. As a matter of fact, when we referred to fine-grained traffic
filtering in our original email, we meant DDoS mitigation based on layer 3
and 4 information.

I hope this addresses your concerns.

Best,
Lumin








On Tue, Jan 14, 2020 at 2:31 PM Dobbins, Roland 
wrote:

>
> On 14 Jan 2020, at 1:56, Lumin Shi wrote:
>
> > We believe that many routers on the Internet
> > today may not have the necessary capacity to perform fine-grained
> > traffic
> > filtering, especially when facing a large-scale DDoS attack with or
> > without
> > IP spoofing.
>
> There are literally decades of information on these topics available
> publicly.  Router and switch ACLs (both static and dynamically-updated
> via flow spec), D/RTBH, S/RTBH, intelligent DDoS mitigation systems
> (IDMSes; full disclosure, I work for a a vendor of such systems), et.
> al. are all used to mitigate DDoS attacks.
>
> Your comments about routers not having the 'capacity' (I think you mean
> capability) to filter traffic due to a lack of granularity are
> demonstrably inaccurate.  While it's always useful to be able to parse
> into packets as deeply as practicable in hardware, layer-4 granularity
> has been and continues to be useful in mitigating DDoS attacks on an
> ongoing basis.  Whether or not the traffic in question is spoofed is
> irrelevant, in this particular context.
>
> Here are some .pdf presentations on the general topic of DDoS
> mitigation:
>
> 
>
> There are lots of write-ups and videos of presentations given at
> conferences like NANOG which address these issues; they can easily be
> located via the use of search engines.
>
> 
> Roland Dobbins 
>
>

Re: DDoS Mitigation Survey

[Lumin Shi]

Hi Töma,

Thank you for the feedback (that is a good point)!

In our study, we lump both cloud/anycast-based and customer-premise
mitigation solutions together as solutions from DDoS mitigation service
providers.
And we believe if you are well-provisioned with such equipment, you are not
subject to the attack that we mentioned in the end of the original email.

Best,
Lumin

On Tue, Jan 14, 2020 at 12:37 PM Töma Gavrichenkov 
wrote:

> Peace,
>
> On Tue, Jan 14, 2020, 10:22 PM Lumin Shi  wrote:
>
>> With our preliminary survey so far, DDoS mitigation approaches in the
>> real world include 1) DDoS mitigation service providers (e.g., Akamai,
>> Cloudflare), 2) Remotely-Triggered Black Hole (RTBH), 3) BGP FlowSpec, and
>> 4) direct contact with upstream providers for traffic filtering.
>>
>
> What about customer-premises equipment, like Arbor or Radware?
>
> --
> Töma
>