Re: Large prefix lists/sets on IOS-XR

[Sander Steffann]

Hi Ytti,

>> Pushing thousands of lines via CLI/expect automation is def not a great 
>> idea, no. Putting everything into a file, copying that to the device, and 
>> loading from there is generally best regardless. The slowness you refer to 
>> is almost certainly just because of how XR handles config application. If 
>> I'm following correctly, that seems to be the crux of your question.
> 
> If you read carefully, that is what Steffann is doing. He is doing
> 'load location:file' + 'commit'. He is not punching anything by hand.
> 
> So the answer we are looking for is how to make that go faster.
> 
> In Junos answer would be 'ephemeral config', but in IOS-XR as far as I
> know, the only thing you can do is improve the 'load' part by moving
> the server closer, other than that, you get what you get.

Perfect answer :)

Not what I was hoping to hear, but if that’s what it is, then that’s what it 
is. 

Cheers!
Sander

Large prefix lists/sets on IOS-XR

[Sander Steffann]

Hi,

What is the best/most efficient/most convenient way to push large prefix lists 
or sets to an XR router for BGP prefix filtering? Pushing thousands of lines 
through the CLI seems foolish, I tried using the load command but it seems 
horribly slow. What am I missing? :)

Cheers!
Sander

---
for every complex problem, there’s a solution that is simple, neat, and wrong

Re: SRv6 Capable NOS and Devices

[Sander Steffann]

Hi Randy,

> this is quite true, and a serious issue.  but it has a good side.  if
> you run an ipv6 enebled network, you can deploy srv6 without enabling
> srv6 everywhere, only at the marking encaps or embed) points.  nice for
> partial and/or incremental deployment.

Yep, that's what I like about it! But I haven't figured out a way to mitigate 
the risks. Easy deployment == easy abuse it seems :(

Cheers,
Sander

Re: SRv6 Capable NOS and Devices

[Sander Steffann]

Hi,

> No SRv6 is MPLS labeling where label is carried inside IP instead
> before the IP header. Layering violation which increases complexity
> and cost for no other purpose except dishonest marketing about 'it is
> IP, you already understand it, MPLS is hard'.

What worries me more is the opportunity for adversaries to inject SRv6 packets. 
MPLS is not enabled by default on most router interfaces, so an adversary would 
have to have access to an interface where MPLS processing is explicitly 
enabled. IPv6 packet processing on the other hand… Unless an operator has 
airtight protection on every interface to block unwanted SRv6 headers I see 
some interesting opportunities to cause havoc :)

Cheers,
Sander

Re: strange scam? email claiming to be from the fbi

[Sander Steffann]

> Quite a bit of discussion on the outages mailing list. It was an exploited 
> HTML form on the FBI site.

That's a flashback to the '90s :)
Sander

Re: Juniper hardware recommendation

[Sander Steffann]

Hi!

On Sat, 2021-05-15 at 11:38 +0300, Saku Ytti wrote:
> Juniper has worked like this since day1 and shockingly the world
> doesn't care, people really don't care for accuracy. CLI and SNMP are
> both L3. If you want to report L2 'set chassis fpc N pic N
> account-layer2-overhead'.
> 
> However, who decided that L2 is right? To me only L1 is right, I
> don't care about L2 at all. So any system I'd use, I'd normalise the
> data to L1.
> 
> Ethernet on minimum size packets
> L1 - 100%
> L2 -  76%
> L3 -  24%
> 
> Not sure why 76 is better than 24. Both are wrong and will cause
> operational confusion because people think the link is not congested.
> This is extremely poorly understood even by professionals, so poorly
> that people regularly think you can't get 100% utilisation, because
> you can't unless you normalise stats to L1 rate.

How do you normalise? Use L2 or L3 octets stats, and use the number of
packets to calculate the L2 and/or L1 overhead the stats are missing?
Or do you have a better way?

Cheers,
Sander



signature.asc
Description: This is a digitally signed message part

Re: OVH datacenter SBG2 in Strasbourg on fire 

[Sander Steffann]

> Again: all conjecture, which seems to be tolerated here. ;-)

It's all good food for thoughts! It's important to learn from these
things, because I (and I expect many others) assumed that fire
suppression systems would prevent something like this from happening.
It is good to think and talk about the limits of such systems.

Cheers!
Sander



signature.asc
Description: This is a digitally signed message part

Re: NDAA passed: Internet and Online Streaming Services Emergency Alert Study

[Sander Steffann]

Hi,

On Fri, 2021-01-01 at 17:07 -0500, Sean Donelan wrote:
> The House on Monday and the Senate on Friday have overriden the 
> President's veto of the National Defense Authorization Act for 
> Fiscal Year 2021 passing it into law.
> 
> Among the NDAA's various sections, it includes the Reliable
> Emergency 
> Alert Distribution Improvement (READI) Act.  The READI Act includes
> a 
> study and report for Emergency Alerts via the internet and streaming 
> services.
> 
> 
> SEC. 9201. RELIABLE EMERGENCY ALERT DISTRIBUTION IMPROVEMENT.
> [...]
> (e) INTERNET AND ONLINE STREAMING SERVICES EMERGENCY ALERT
> EXAMINATION.—
> (1) STUDY.—Not later than 180 days after the date of
> enactment of this Act, and after providing public notice and
> opportunity for comment, the Commission shall complete an
> inquiry to examine the feasibility of updating the Emergency
> Alert System to enable or improve alerts to consumers provided
> through the internet, including through streaming services.

Just to be clear: this is talking about IP traffic, not things like
SMS-CB, right? When there are already cell broadcast alerts, I have the
feeling that adding alerts to IP traffic (however that would be
supposed to work) wouldn't add that much coverage…

Cheers,
Sander



signature.asc
Description: This is a digitally signed message part

Re: 100G over 100 km of dark fiber

[Sander Steffann]

Hi,

On 30-10-2020 15:33, Dale W. Carder wrote:


You may also find that 100G PAM4 could work.  There are some vendors that
sell the optic, and an outboard EDFA + DCF pizza box.


We are about to deploy these on a couple of dark fibers:
https://www.solid-optics.com/product/edfamux-multiplexer-amplifier-dispersion-compensation-dwdm-mux-edfa/

They have amplified and dispersion compensated 8x100G to be used with 
PAM4 optics, and a pass-through port to connect existing 1G/10G MUXes to 
(which can have their own amplification if necessary).


They can provide models with different sets of channels of you need that 
(nice when cascading them with existing 1/10G MUXes). IIRC next year 
they can also build in a power meter so you can do remote monitoring.


If you're interested I can let you know how much we like them in a few 
months ;)


Cheers,
Sander

Re: Disney+ geolocation error for 213.134.224.0/19

[Sander Steffann]

Hi,

> I had a similar issue here in Sweden. The contact point listed at 
> http://thebrotherswisp.com/index.php/geo-and-vpn/ 
> (netad...@disneystreaming.com) helped me with this pretty quickly.

Useful link, thanks!
Sander

Disney+ geolocation error for 213.134.224.0/19

[Sander Steffann]

Hi,

Anybody around from Disney+?  my main customer (Solcon) is an ISP in the 
Netherlands. One of our ranges is 213.134.224.0/19 and it seems to be 
classified as non-Netherlands. The official support channel doesn't get any 
further than "you must be using a VPN" even though we are the ISP and it's our 
own address space...

Any assistance would be much appreciated!

Cheers,
Sander

Re: questions asked during network engineer interview

[Sander Steffann]

> I find there's a strong INVERSE correlation between the quantity of
> certificates on an applicant's resume and their ability to do the
> job.

Never got a certificate, don't want one either :)
Sander



signature.asc
Description: This is a digitally signed message part

Re: Mikrotik RPKI Testing

[Sander Steffann]

> Mostly.
> 
> I'm only living without IPv6 for the moment, which is painful... :)

OMG!!! Max, I'm so sorry to hear that :'(



signature.asc
Description: Message signed with OpenPGP

Re: "Is BGP safe yet?" test

[Sander Steffann]

Hi,

> Removing a resource from the certificate to achieve the goal you describe 
> will make the route announcement NotFound, which means it will be accepted. 
> Evil RIR would have to replace an existing ROA with one that explicitly makes 
> a route invalid, i.e. issue an AS0 ROA for specific member prefix. This seems 
> like a pretty convoluted way to try and take a network offline.

I've seen worse…
Sander



signature.asc
Description: Message signed with OpenPGP

Re: MX10003 rack size

[Sander Steffann]

Hi,

> here it does fit in 600x1000 racks (APC & Minkels), with everything plugged, 
> airfilter/frontpanel installed, doors closed.
> Front door / front rails / rear rails / rear door: 15cm / 72cm / 12cm

I can confirm those measurements. We have installed two MX10003 routers in 
100cm racks. As long as the rack posts are in the right place and the doors 
allow airflow you'll be fine. The 72cm between front and rear posts is what the 
specs say, but IIRC anything down to 63cm or so will work.

Cheers,
Sander

Re: MAP-E

[Sander Steffann]

Hi Lee,

> Also but, would that be a Net Neutrality problem, charging less for a service 
> that has arguably worse access to Amazon, Reddit, Twitter, etc.?

Net neutrality as it is here in Europe usually is satisfied when no 
preferential treatment is given to a limited set of services (Netflix has 
higher priority than Amazon Prime etc). The European regulators don't seem to 
specify things in technical terms but in "Apps" and "Services". As long as you 
don't treat those unfairly you should be fine. When you tell a regulator "yes, 
the new standard works better than the old standard, and we encourage everybody 
to support that new standard (which is a recognised best practice)" then there 
shouldn't be any problem.

Cheers :)
Sander



signature.asc
Description: Message signed with OpenPGP

MX10003 rack size

[Sander Steffann]

Hi,

Has anyone ever managed to fit a Juniper MX10003 in a 90cm deep rack? Without 
applying power tools to either the rack or the router ;)

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: JunOS Fusion Provider Edge

[Sander Steffann]

Hi Aaron,

> Can I test fusion using vMX and vQFX ?  Will it work?

I have tried and haven't managed to get it working. It's one of the 
improvements that I would like to see in vMX and vQFX.

#featurerequest

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: QFX5k question

[Sander Steffann]

Hi,

> thanks for quick reply. I forgot to mention, 2 x 10G providers with full 
> routing table on each.

Those QFXs won't be able to hold full routing tables:
https://www.juniper.net/documentation/en_US/junos/topics/topic-map/layer-2-forwarding-tables.html#id-configuring-the-unified-forwarding-table-on-switches

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Sander Steffann]

> Op 26 feb. 2019, om 10:56 heeft Bill Woodcock  het volgende 
> geschreven:
> 
> We need to get switched over to DANE as quickly as possible, and stop wasting 
> effort trying to keep the CA system alive with ever-hackier band-aids.

+1
Sander



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[Sander Steffann]

Hi Paul,

> Reread this and felt I should clarify that I realize that John and Doug
> are not the ones saying DNSSEC is useless. I just hate to see the knee
> jerk "oh, see, DNSSEC didn't save the day so it's obviously
> useless". Let's give the world a better explanation.

Security is only as strong as its weakest link. No single link can be expected 
to protect the whole chain on its own.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: Last Mile Design

[Sander Steffann]

Hi Mark,

> My preference, for the home, would be Active-E. But I do understand the 
> economics that may support PON, and my position on that has softened over the 
> years.

Same for me. I like the architecture where the PON splitters are in powered 
roadside cabinets (even though the splitter is passive). That way the ISP can 
convert it to AE at any time they want. The architectures where PON has been 
hardcoded into the design has always felt like a huge risk regarding future 
developments.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: IP Dslams

[Sander Steffann]

Hi,

>> How many devices are you looking for?
>> Consider ZyXEL 1248: 
>> https://www.zyxel.com/uk/en/products_services/48-port-Temperature-Hardened-ADSL2--Box-DSLAM-IES-1248-5x-IES-1248-5xA-Series/
> 
> I had bad experiences with those.

My apologies, my problems were with a different Zyxel model (which I don't 
recall anymore).

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: Google Fiber v6 PD only giving /64

[Sander Steffann]

Hi,

> Anybody here from Google Fiber?  When I first got it last year, my IPv6
> setup got a /56 prefix delegated.  I now see that no matter what size I
> request, I only get a /64.  Is this intentional?

Sounds broken, especially considering how people like Lorenzo have always 
fought for giving everybody plenty of address space...

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: IP Dslams

[Sander Steffann]

Hi,

> How many devices are you looking for?
> Consider ZyXEL 1248: 
> https://www.zyxel.com/uk/en/products_services/48-port-Temperature-Hardened-ADSL2--Box-DSLAM-IES-1248-5x-IES-1248-5xA-Series/

I had bad experiences with those. When testing IPv6 they messed up the data 
inside the PPP session. The client would negotiate IPv6 just fine, but then no 
IPv6 packet ever made it through the Zyxel. I replaced them with Draytek 
VigorAccess, which worked fine for testing. My customer that used those 
Draytek's stopped using them last year. If anyone is interested I can ask them 
if they are still in storage somewhere.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: Puerto Rico Internet Exchange

[Sander Steffann]

Hi,

> In general an IX only makes sense when there are local resources to exchange. 
> It doesn’t seem like PR has a lot of, if any, content providers of its own, 
> so most consumer content is coming from offshore anyway.

This can also work the other way: once there is a local IXP, it can open 
opportunities for local content providers.

Cheers,
Sander

Re: Rising sea levels are going to mess with the internet

[Sander Steffann]

Hi,

> The available data does not support your speculation.
> 
>> https://data.worldbank.org/indicator/EN.ATM.GHGT.KT.CE?locations=US-EU-CN

Maybe it would be more fair to look at CO2 emissions per capita:

https://data.worldbank.org/indicator/EN.ATM.CO2E.PC?locations=EU-US-CN

Cheers,
Sander

Re: Whois vs GDPR, latest news

[Sander Steffann]

Hi,

>> The way GDPR is written, if you want to collect (and store) so much as
>> the IP address of the potential customer who visited your website, you
>> need their informed consent and you can’t require that they consent as
>> a condition of providing service.
> 
> What we were told is that since security > GDPR, storing IPs in logs is 
> obviously OK since it’s a legal requirement.

GDPR article 6.1c (legal obligation) and 6.1f (legitimate interests) would 
probably both qualify for logging HTTP requests.

In this context it's also not likely that the IP address is considered personal 
data at all. Personal data is defined as data related to "an identifiable 
natural person is one who can be identified, directly or indirectly, in 
particular by reference to an identifier such as a name, an identification 
number, [...]". If you have no way to determine who an IP address belongs to 
then it's not personal data to you.

This can actually be a tricky point: the ISP who provides connectivity to a 
customer obviously knows which IP address they provided, so to that ISP the IP 
address is definitely personal data. If you ask for someone's name on your 
website and you log the IP address together with answers then you suddenly turn 
that IP address into personal data, even regarding you web server logs.

To be safe, adding something like the following to the privacy notice on the 
website would be fine for this case: "In order to comply with law enforcement 
requirements and to be able to detect and investigate abuse of our website we 
log all requests in including the IP addresses of the requester. If our systems 
detect abuse they may block access to our services from that IP address. This 
data will be stored for up to 2 weeks and will then automatically be deleted.". 
Add boilerplate text for contact information etc and that should cover article 
13.

> Storing them in a database for targeting / marketing is not.
> 
> What is a gray area so far is any use of IDS/IPS…

Sounds like legitimate interests to me :)  But it really depends on what is 
done with that information. Just protecting your servers should be fine. The 
big change with the GDPR is that you have to tell your users that you do this.

Hmmm. It might be a good idea to write some boilerplate privacy policy text for 
common components like IDP/IDS, load balancers, web server logs, DDOS 
protection etc.

Cheers,
Sander

Re: Whois vs GDPR, latest news

[Sander Steffann]

Hi,

>> Thanks for the clarification. But whether that fine will be less than 10M is 
>> extremely vague and (I guess?) left up to the opinions or whims of a Euro 
>> bureaucrat or judge panel, or something like that... based on very vague and 
>> subjective criteria. I've searched and nobody can seem to find any more 
>> specifics or assurances. Therefore, there is NOTHING that a very small 
>> business with a very small data breach or mistake, could point to... to give 
>> them confidence than their fine will be any less than 10M Euros, other than 
>> that "up to" wording - that is in the same sentence where it also clarifies 
>> "whichever is larger".
>> 
>> All these people in this discussion who are expressing opinions that 
>> penalties in such situations won't be nearly so bad - are expressing what 
>> may very with be "wishful thinking" that isn't rooted in reality.
> 
> Still on ec.europa.eu  they seem to try to reassure 
> SMEs that the penalties will be “proportionate” both to the nature of the 
> infringement and to the size to the company. It also seem to largely be 
> related to whether you infringed the regulation in good faith or not. At 
> least in France where I live the climate is pro-SMEs so I guess small 
> mistakes will be forgiven. The head of our DPA also gave an interview 
> recently saying that there will be no sanctions in the coming months and that 
> they’re available to answer questions when in doubt about what to do.

That is also what I see in the Netherlands.

> Lastly, our law firm told us that basically we have to wait until the first 
> settlements to see what will be done…

True. Considering that GDPR is an EU regulation and that in general European 
culture is a lot less litigious than in the US I don't expect massive fines 
unless the infractions are malignant + persistent + performed by a large 
corporation. Smaller companies (or people) that make mistakes will not get 
fines that would bankrupt them. That's just not the way the justice system 
works on this side of the pond :)

Cheers,
Sander

Re: Whois vs GDPR, latest news

[Sander Steffann]

Hi,

> Dne 17/05/2018 v 15:03 Niels Bakker napsal(a):
>> * na...@ics-il.net (Mike Hammett) [Thu 17 May 2018, 14:44 CEST]:
>>> Agreed. This is garbage, un-needed legislation.
>> 
>> Disagreed.  These are great and necessary regulations.>
>> I'm loving the flood of convoluted unsubscribe notices this month from
>> companies that had stored PII for no reason.
> 
> Those who would give up essential liberty, to purchase a little
> temporary safety(*), deserve neither liberty nor safety(*).

But this regulation increases essential liberty for individuals, so I don't 
understand your argument...

Cheers,
Sander



smime.p7s
Description: S/MIME cryptographic signature

Re: Cogent BCP-38

[Sander Steffann]

Hi,

> Op 29 aug. 2017, om 15:29 heeft Rob Evans  het 
> volgende geschreven:
> 
>> Well, if you are using public IP addresses for infra you are violating your 
>> RIR’s policy more than likely.
> 
> [Citation needed.] :)

I am pretty confident that I know those policies well enough to say that you 
won't find any ;)

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: Cellular enabled console server

[Sander Steffann]

Hi,

> NANOG - Are any of you running a console server to access your network
> equipment via a serial connection at a remote site?  If so, what are you
> using and how much do you like it?  I have a project where I need to stand
> up over 100 remote sites and would like a backdoor to the console just to
> be able to see what's going on with the equipment to hopefully avoid a
> truck roll for something simple like a hung device.  I need 4 console ports
> and 1 RJ45 ethernet jack.  My quick Google search landed me at
> BlackBox LES1204A-3G-R2, but I've never actually used such a device.  This
> would be for use in the USA.

I don't have experience with those devices, but I did just have a conversation 
about this with people from Opengear and they told me they have experience with 
it and you can even set up a OpenVPN over cellular and bridge to the ethernet 
port to access the management LAN. I haven't tested it yet, but at least their 
sales people say it works :)

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP

Re: Questions on IPv6 deployment

[Sander Steffann]

Hi Bill,

> Op 17 jan. 2017, om 22:55 heeft William Herrin  het volgende 
> geschreven:
> 
> I'm always interested in learning something new. Please explain the
> DOS vectors you're referring to and how they're mitigated by
> allocating a /64 to the point to point link.

One thing that comes to mind is that it seems that some routers only have 
limited space in their routing tables for prefixes longer than a /64. If you 
would configure a /127 on the link but push the /64 to the routing table then 
you might both avoid ND Cache exhaustion and avoid the limitations on 
longer-than-/64 prefixes.

I personally prefer to set up my addressing plan that things like this are 
possible even if I don't do it today, but I also understand the choices you 
make. I don't think any of the choices is wrong. It mostly depends on 
expectations, used equipment and personal preference.

And thanks for mentioning "Minimum assignment to a customer: /60". That is 
indeed a very important one!

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Questions on IPv6 deployment

[Sander Steffann]

Hi,

> Suggest /128's for loopbacks and /124's for point to points, all from
> the same /64. This way you don't burn space needlessly, don't open
> yourself to neighbor discovery issues on point to points

I usually reserve one /64 for loopbacks, reserve a /64 per point-to-point 
connection and configure a /127 using ::a on one side and ::b on the other. All 
of these from a block reserved for infrastructure for filtering:

> and can
> filter inbound Internet packets to that /64 in one fell swoop so that
> it's harder to hit your routers directly. Just make sure not to filter
> the outbound packets.

Having a single block for infrastructure makes this very easy. In most cases I 
don't need to worry about "burning space needlessly" so I reserve /64s per 
point-to-point. Worrying about "wasting" address space is more often an 
IPv4-ism than good practice with IPv6 IMHO :-)  But it all depends on the 
complexity of your network. There are cases where it makes sense to think about 
this.

> Reminder: No matter what size you pick, use nibble boundaries for
> visual and DNS convenience. So /124, not /126.

Good advice!

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Bonded VDSL2 / ADSL2+ Modems with 4 or more lines bonded

[Sander Steffann]

Hi,

> Zyxel SBG3600-N may be another offering you might want to look into?

I think those are limited to 2x VDSL + LTE.

Cheers,
Sander

Re: NANOG67 - Tipping point of community and sponsor bashing?

[Sander Steffann]

> So here we are now... Where do we want to go?

I think IXPs have indeed become too much like ISPs, providing more services but 
also increasing complexity and cost. I prefer simple, scalable and cheap 
solutions!

I want to go to an IXP being a nice simple ethernet switch. Add some nice 
graphs and a route server, and we're done. Redundancy is a separate switch :)

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Netflix banning HE tunnels

[Sander Steffann]

Hi,

> Op 8 jun. 2016, om 23:39 heeft John Lightfoot  het 
> volgende geschreven:
> 
> How about:
> 
> Dear Netflix network engineer who’s on the NANOG list.  Could you please get 
> Netflix to fall back to ipv4

Just for geolocation please, the streaming works fine over IPv6 :)

> if you block your customer’s ipv6 because it’s in an HE tunnel?  Lots of 
> people who want to watch Netflix, be able to reach the whole internet, and 
> have Verizon FiOS would really appreciate it.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: small automatic transfer switches

[Sander Steffann]

Hi,

> There's also WTI, which we use:
> http://www.wti.com/c-41-automatic-transfer-switch.aspx

And for the small deployments their RSM series is great as well: automatic 
transfer switch, remote power switching and remote serial console all in one 
box. Those boxes are more expensive, but if you need all of that functionality 
in 1U they can be really useful.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Another Big day for IPv6 - 10% native penetration

[Sander Steffann]

Hi Vint,

> Op 11 jan. 2016, om 12:47 heeft Vint Cerf  het volgende 
> geschreven:
> 
> since google is a major implementor of IPv6, some people might claim this is 
> an attempt to artificially inflate scores for Google sites. Sigh.

Sigh indeed. On the other hand: IPv6 is getting enough traction that it can't 
be considered a "Google thing".

A thought: Maybe Google could announce that because of the increasing scarcity 
of IPv4 addresses and the rise of global IPv6 deployment Google is considering 
to start taking IPv6 reachability into account later this year. That would give 
the possibility for Google to watch how people respond before actually changing 
anything, it would take away some arguments of those that blame Google for 
artificially inflating scores (they have been warned long in advance) and it 
would make SEO companies more aware of IPv6 so they can start pushing the ISPs 
and hosters to support IPv6.

Google already provides webmaster tools. Maybe showing a warning for websites 
that aren't reachable over IPv6 (or even worse: that have completely different 
content on IPv6) would be nice. Even if IPv6 reachability doesn't affect the 
page rank (yet) the number of users with IPv6+IPv4-CGN is growing so enabling 
IPv6 will have a positive impact on a growing number of eyeballs (see 
Facebook's experience with IPv6 performance). Showing warning messages on 
Google Webmaster Tools when the site is not reachable over IPv6 (and error 
messages when the IPv4 content is very different from the IPv6 content) would 
be nice.

Even if Google gets so much pushback that they decide not to go forward with 
this at this point in time it might already cause some good awareness for IPv6.

Even though IPv6 is growing all over the world I still think Google doing 
something like this would help a lot.

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Another Big day for IPv6 - 10% native penetration

[Sander Steffann]

> Op 11 jan. 2016, om 15:05 heeft Vint Cerf  het volgende 
> geschreven:
> 
> sounds like the Federal Reserve testing the waters with hints of increasing 
> discount rate...

:)



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Another Big day for IPv6 - 10% native penetration

[Sander Steffann]

Hi,

> We just need Google to announce that IPv6 enabled sites will get a slight
> bonus in search rankings. And just like that, there will suddenly be a
> business reason to implement IPv6.

I already discussed that with them a long time ago, but they weren't convinced. 
Maybe now is the time to discuss it again :)

Cheers,
Sander



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Nat

[Sander Steffann]

Hi Nick,

> Unfortunately, this turned into a religious war a long time ago and the
> primary consideration with regard to dhcpv6 has not been what's best for
> ipv6 or ipv6 users or ipv6 operators, but ensuring that dhcpv6 is
> sufficiently crippled as a protocol that it cannot be deployed without
> RA due to lack of features.

As a network operator what I'm afraid of is the exact opposite: DHCP 
duplicating everything that RA does so that I now have duplicate and possibly 
conflicting sources of information. I already have to put DNS resolvers in both 
because some operating systems only use the ones provided in the RA and others 
only use those from DHCP. I can'd even begin to imagine the mess if e.g. 
routing information is also duplicated, with different operating systems using 
different sources.

I don't really care about the solution itself. I don't mind the original 
situation where routing stuff is done in RA and the rest is done in DHCP. I 
wouldn't have minded if everything was in RA, or everything was in DHCP. But 
the worst choice would be conflicting or overlapping solutions with some people 
religiously only implementing one of them.

There are always trade-offs. And some stupid design decisions were made in the 
past. But let's not create an even bigger mess...

Cheers,
Sander

Re: Nat

[Sander Steffann]

Hi Matthew,

> I have multiple sets of clients on a particular subnet; the subnet
> is somewhat geographically distributed; I have multiple routers
> on the subnet.  I currently am able to explicitly associate clients
> with the most appropriate router for them in v4.
> How can I do this using only RAs in IPv6?
> 
> I'd be happy to learn something new.  Unfortunately, my
> research hasn't shown me that there's something new
> to learn, it's shown me that "IPv6 can't do that, sorry."

Thanks for showing me a use-case that indeed doesn't work with IPv6 :)

Cheers,
Sander

Re: Nat

[Sander Steffann]

Hi Matthew,

> The mix of having to do this crazy thing of gateway announcements
> from one place, DNS from somewhere else, possibly auto-assigning
> addresses from a router, but maybe getting them over DHCPv6. It's
> just confusing and unnecessary and IMHO isn't helpful for
> persuading people to move to IPv6. Especially when everyone
> already understands DHCP in the v4 world.
> 
> Both RAs and DHCP have their place and can be really useful
> together or apart in different situations, but witholding key
> functionality from DHCP "beacuse you can do it in a RA instead"
> isn't helping the v6 cause.

Have you ever tried to deploy IPv6 (even if only in a lab environment)? I have 
worked with several companies (ISP and enterprise) and once they stop thinking 
"I want to do everything in IPv6 in exactly the same way as I have always done 
in IPv4" and actually look at the features that IPv6 provides them they are 
usually much happier with IPv6 than they were with IPv4.

I am sure that a century ago people who were used to horse and buggy transport 
thought that cars were annoyingly complex and that having to put petrol in 
instead of hay was a huge problem. But I am very glad that in the end they 
adapted instead of convincing other people to make cars run on hay ;)

Just joking of course, but seriously: we need to look at what the best solution 
for the future is, not at ways of avoiding having to learn something 
new/different.

Cheers,
Sander

Re: Nat

[Sander Steffann]

Hi Jeff,

> It's far past time to worry about architectural purity.  We need people
> deploying IPv6 *NOW*, and it needs to be the job of the IETF, at this
> point, to fix the problems that are causing people not to deploy.

I partially agree with you. If people have learned how IPv6 works, deployed 
IPv6 (even if just in a lab) and came to the conclusion that there is an 
obstacle then I very much want to hear what problems they ran into. That's 
rarely the case unfortunately. Most of the time I hear "we don't want to learn 
something new".

If the choice is between the IETF having to change standards vs some people 
having to learn something new then sorry, they will have to invest some time 
and learn IPv4 != IPv6. You have to keep learning, that's part of the job.

Where we should focus our efforts is on making that learning process as easy as 
we can. That is an area where we have been failing horribly. Especially for 
enterprises. The mindset in enterprises is very different from that in ISPs, 
and we have been assuming for too long that documentation and best-practices 
for an ISP also work in an enterprise. I see a lot of enterprises that just 
don't know where to start, how to best run their networks with IPv6, with 
concerns about management, privacy, security etc. Changing standards isn't 
going to solve that (except to give them a false sense of security because it 
starts looking a lot like IPv4 on the surface). Besides: the time it takes to 
change standards and get new code deployed everywhere would be a bigger 
obstacle in getting IPv6 deployed soon anyway.

So yes, people have to deploy IPv6 as soon as possible, but it's not the job of 
the IETF to fix all of the obstacles. There are definitely obstacles that the 
IETF needs to fix. But I don't think this is one of them... This one is better 
solved by showing how to make good use of all the nice features that IPv6 
offers.

Cheers,
Sander

Re: Binge On! - And So This is Net Neutrality?

[Sander Steffann]

Hi Owen,

> To me, net neutrality isn’t as much about what you charge the customer for 
> the data, it’s about
> whether you prioritize certain classes of traffic to the detriment of others 
> in terms of
> service delivery.
> 
> If T-Mobile were taking money from the video streaming services or only 
> accepting
> certain video streaming services, I’d likely agree with you that this is a 
> neutrality
> issue.

You are right in that it could have been much worse. However: giving a big 
advantage to a certain technology does get in the way of innovation in e.g. new 
video delivery technologies. And in the long run less innovation will not be to 
the benefit of the internet's users. We are already too locked in to 
tcp-port-80-and-443 as it is :(

Cheers,
Sander

Re: IPv6 Irony.

[Sander Steffann]

> I bet most money is spent on hiring software developers to change/review all 
> BSS/NSS systems to adopt to IPv6 ;)

You should hire a consultant who can then push the software developers to hire 
people to change/review [..etc..]  ;-)

Cheers,
Sander

Re: Android and DHCPv6 again

[Sander Steffann]

Hi,

> SLAAC by default provides the address and default gateway (RA)
> If SLAAC managed flag is set, then DHCPv6  is used get the address and other 
> configs (DNS, etc..)
> If SLAAC other flag is set, then SLAAC  provides the address, and uses DHCPv6 
> to get the other configs (DNS, etc..)

It's even more flexible than that :)

The Managed flag indicates if there is a DHCPv6 server that can provide 
addresses and other config
The Other Config flag indicates if there is a DHCPv6 server that can provide 
other config

Besides those flags each prefix that is advertised in the RA has an Autonomous 
flag which tells the clients if they are allowed to do SLAAC.

So you can do all kinds of nice setups. For example you can advertise both the 
Managed and the Autonomous flags so that devices can get a DHCPv6-managed 
address (maybe for running services or for remote management) and get SLAAC 
addresses (for example for privacy extensions so they cannot be identified by 
their address when connecting to the internet). Or you can advertise multiple 
prefixes and allow Autonomous configuration in one and provide addresses in the 
other with DHCPv6.

I admit that you can also make things extremely complex for yourself, but it's 
certainly flexible! ;)

Cheers,
Sander

Re: /27 the new /24

[Sander Steffann]

Hi,

> Op 4 okt. 2015, om 16:52 heeft Mel Beckman  het volgende 
> geschreven:
> 
> If it doesn't support IPSec, it's not really IPv6. Just as if it failed to 
> support any other mandatory IPv6 specification, such as RA. 

I think you're still looking at an old version of the IPv6 Node Requirements. 
Check https://tools.ietf.org/html/rfc6434#section-11, specifically this bit:

"""
Previously, IPv6 mandated implementation of IPsec and recommended the key 
management approach of IKE.  This document updates that recommendation by 
making support of the IPsec Architecture a SHOULD for all IPv6 nodes.
"""

This was published in December 2011.

Cheers,
Sander

Re: cisco.com unavailable

[Sander Steffann]

> Is cisco.com  unavailable or it is affected just for 
> Rostelecom?

Works fine here in The Netherlands (ISP: Solcon).

Cheers,
Sander

Re: internet visualization

[Sander Steffann]

>   one of my colleagues just posted this visualiation
> of the internet from the as_path view of 2914.  if you are on
> a mobile, you have to physically move your device around.
> 
>   http://as2914.net/
> 
>   If you love it, send Job your accolades.  If you hate it,
> see above disclaimer.  If in a country with a holiday on monday,
> enjoy it safely.

WOW, nice!
Sander

Re: Dual stack IPv6 for IPv4 depletion

[Sander Steffann]

Hi,

 I was hoping to find a solution that maybe utilized some kind of session sync 
 or something of that matter [...]

And the session sync is then the weakest link. I have seen a cluster of Nexus 
switches crash in sync when saving the configuration (which was synced). True 
redundancy is only when the elements can operate independently of each other, 
and the syncing makes them dependent and vulnerable.

Cheers,
Sander

Re: Android (lack of) support for DHCPv6

[Sander Steffann]

Hi Lorenzo,

 It's certainly possible to make Android request N IPv6 addresses via
 DHCPv6, and not accept the offer if it is offered fewer than N addresses.
 But that only really makes sense if there's a generally-agreed upon minimum
 value of N. I'd be happy to work with people on an Internet draft or other
 standard to define a minimum value for N, but I fear that it may not
 possible to gain consensus on that.

I definitely think we should start pushing for N1 because that will really 
hurt IPv6 in the future. However any fixed N is a potential danger as 
requirements will change in the future. But maybe we can do something smarter 
here.

 It's also possible for Android to support DHCPv6 PD. Again I'd be happy to
 work with people on a document that says that mobile devices should do
 DHCPv6 PD and not DHCP NA, and then implement DHCPv6 PD. But I fear similar
 arguments will be had there.

I think this will be more difficult to get consensus on, and I can also see 
more deployment issues (much more state in the routers for all those PDs, 
needing huge amounts of /64s (or larger) to be able to deal with a few 
hundred/thousand clients) but it would be very nice if this was possible :)

 Asking for more addresses when the user tries to enable features such as
 tethering, waiting for the network to reply, and disabling the features if
 the network does not provide the necessary addresses does not seem like it
 would provide a good user experience.

I don't think it is unreasonable. If the network doesn't support the features 
you need then let the user know (grey out the feature and add a note that says 
broken network). It will put pressure on the network department to fix their 
DHCPv6 implementation.

I have read Lorenzo's arguments and while I don't agree with all of them I do 
see the risk of creating a situation where N=1 is the default. That would be 
bad. But instead of not supporting DHCPv6 I think we should work on making sure 
N1.

Cheers,
Sander

Re: Android (lack of) support for DHCPv6

[Sander Steffann]

 
 It's not the *only* option. There are large networks - O(100k) IPv6 nodes - 
 that do ND monitoring for accountability, and it does work for them. Many 
 devices support this via syslog, even. As you can imagine, my Android device 
 gets IPv6 at work, even though it doesn't support DHCPv6. Other universities, 
 too. It's obviously  not your chosen or preferred mechanism, but it does work.

/me starts to write that whitepaper that educates people on how to do this

Cheers,
Sander

Re: gmail security is a joke

[Sander Steffann]

 Op 29 mei 2015, om 08:42 heeft Joe Abley jab...@hopcount.ca het volgende 
 geschreven:
 
 [...]
 and around this point, I start to think
 
 - I've had enough of this
 - this is too hard
 - I don't even remember what I am signing up for at this point
 - I am going to look for amusing cats on youtube

Good plan,
Sander

Looking for Sky UK contact

[Sander Steffann]

Hi,

If there is anybody from Sky UK here please contact me off-list.

Cheers!
Sander

Re: v6 deagg

[Sander Steffann]

Hi Bill,

 I don't fully understand the math yet but the algorithm doesn't smell
 right. As near as I can figure it may only be correct in a static
 system. If after convergence the disaggregate ceases to be reachable
 from the aggregate, there doesn't appear to be either enough
 information in the system or enough triggers traveling between routers
 for it to reconverge to a correct state.

If a network announces an aggregate when they can't reach all more-specifics 
then things will already be broken. Don't announce address space that you can't 
handle traffic for...

But true: without Dragon the more specific would still arrive via another path 
and it would still be reachable.

Cheers,
Sander

Re: v6 deagg

[Sander Steffann]

Hi Mans,

 I'm working at one of those organisations who have a /48 and am announcing
 it into DFZ. We have a situation where I might have another site with
 separate connectivity to the DFZ (but there is internal networking)
 which would entitle me to another /48 according to RIR rules.

Correct.

 I did ask my LIR whether there is any thought given to the possibility of
 getting the next higher prefix, thus creating a /47. They did understand
 the why perfectly well, of course.
 
 However, apparently there is no such process or intention available
 from the RIR in question (RIPE), short of explicitly asking for that
 specific prefix.

So you asked to grow the /48 to a /47? Was it accepted? Or did you want the RIR 
to automatically grow your first assignment when you request a second one 
without you having to ask?

 Of course this does not help every case, but supporting aggregation
 where possible certainly ought to be in-scope for most policy-making
 bodies in this area.

Then please take this to the appropriate policy-making body: 
address-policy...@ripe.net :-)

Cheers!
Sander

Re: TeliaSonera IC Contacts

[Sander Steffann]

Hi,

 Does anyone have a contact for an account manager at TeliaSonera IC? We’ve 
 sent at least 3 requests for a quote through their website over a month or so 
 and haven’t got a single reply except for the automated “we’ve received your 
 query” email.

And you still want to buy from them?!?
Sander

Re: Transparent hijacking of SMTP submission...

[Sander Steffann]

Op 29 nov. 2014, om 19:37 heeft Randy Bush ra...@psg.com het volgende 
geschreven:
 i think of it as an intentional traffic hijack.  i would be talking to a
 lawyer.
 
 randy, who plans to test next time he is behind comcast

I am so glad that our Dutch net neutrality laws state that providers of 
Internet access services may not hinder or delay any services or applications 
on the Internet (unless [...], but those exceptions make sense)

Cheers,
Sander

Re: TeliaSonera IC Contacts

[Sander Steffann]

Hi,

 It's more of a have to buy from them as opposed to a want to buy from 
 them. I'd much prefer NTT, but they are nowhere near where we are 
 unfortunately.

You were talking about Amsterdam, right? There are plenty of transits you can 
buy from.

Cheers,
Sander

Re: Industry standard bandwidth guarantee?

[Sander Steffann]

Hi,

 and this industry would
 perhaps be better off if we called a link that can deliver at best 17
 Megabits of Goodput reliably a  15 Megabit goodput +5 service
 instead of calling it a 20 Megabit service

But you don't know what the user is going to do over the link. If the average 
packet size is very small the overhead will be much larger. And the path-MTU 
depends on many factors besides the customer link. The only real number to give 
to the customer is the raw link speed. Everything else depends on how the link 
is used. Giving customer numbers like IF you do X then expect a maximum speed 
of Y will only cause more confusion. Especially because you can only give 
theoretical maximums because real speeds depend on many other factors (pMTU, 
RTT, congestion somewhere etc) as well.

Cheers,
Sander

Re: IPv6 Default Allocation - What size allocation for Loopback Address

[Sander Steffann]

Hi,

 Op 11 okt. 2014, om 23:00 heeft Roland Dobbins rdobb...@arbor.net het 
 volgende geschreven:
 
 On Oct 11, 2014, at 2:09 PM, Tim Raphael raphael.timo...@gmail.com wrote:
 
 From my research, various authorities have recommended that a single /64 be 
 allocated to router loopbacks with /128s assigned on interfaces.
 
 Yes, this is what I advocate for loopbacks.

I often use the first /64 for loopbacks. Loopbacks are often used for 
management, iBGP etc and having short and easy to read addresses can be 
helpful. Something like 2001:db8::1 is easier to remember and type correctly 
than e.g. 2001:db8:18ba:ff42::1 :)

Cheers,
Sander

Re: Here comes iOS 8...

[Sander Steffann]

Hi,

 Do you have a reference? Someone just told me it is more around 5GB.

It seems to depend on the device. IIRC my iPhone 4S downloaded ±0.9GB and my 
iPad Mini ±1.3GB. That might be because the 4S is still a 32-bit device.

Cheers,
Sander

Re: The Next Big Thing: Named-Data Networking

[Sander Steffann]

Hi,

 How many Youtube subject tags will fit in *your* routers' TCAM?
 
  
 http://tech.slashdot.org/story/14/09/04/2156232/ucla-cisco-more-launch-consortium-to-replace-tcpip
 
 [ Can someone convince me this isn't the biggest troll in the history 
 of the internet? Cause it sounds like shoehorning DNS /and Google/ into 
 IP in place of, y'know, IP addresses. ]

Well, you don't need addresses for clients, just for content... From the 
architecture page at http://named-data.net/project/archoverview/:

Note that neither Interest nor Data packets carry any host or interface 
addresses (such as IP addresses); Interest packets are routed towards data 
producers based on the names carried in the Interest packets, and Data packets 
are returned based on the state information set up by the Interests at each 
router hop.

So it's basically suggesting a NAT-like table in every single router. And we 
all know how well NAT boxes scale...

Cheers,
Sander

Re: Akamai charges for IPv6 support?

[Sander Steffann]

Hi Aaron,

 Is it normal to bill for IPv6 service as a separate product?  I was
 surprised to hear from from my Akamai rep they they do:
 
 Hi Aaron, We can add the IPV6 service to the contract at an additional
 cost of $XXX/month. Please let me know if you would like to go ahead with
 the service and I can create the contract and send it for your review.

Sad to hear they are still doing this. I though they had learned by now :(

Cheers,
Sander

Re: fire ants

[Sander Steffann]

Hi Suresh,

Op 13 aug. 2014, om 03:16 heeft Suresh Ramasubramanian ops.li...@gmail.com 
het volgende geschreven:

 Needs an Anthill Inside sticker like Hex at the Unseen University.

I should have bought one at the Discworld Convention last weekend :)

http://www.pjsmprints.com/stickers/index.html

Cheers,
Sander

Re: Requirements for IPv6 Firewalls

[Sander Steffann]

Hi Bill,

 Also, I note your draft is entitled Requirements for IPv6 Enterprise
 Firewalls. Frankly, no enterprise firewall will be taken seriously
 without address-overloaded NAT. I realize that's a controversial
 statement in the IPv6 world but until you get past it you're basically
 wasting your time on a document which won't be useful to industry.

I disagree. While there certainly will be organisations that want such a 
'feature' it is certainly not a requirement for every (I hope most, but I might 
be optimistic) enterprises.

Cheers,
Sander

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[Sander Steffann]

Hi Owen,

 I, for one, would not want to start having to pay RIPE-level fees.
 
 ARIN fees are a much better deal than RIPE fees.

Only up to Small... The RIPE NCC membership fee is €1750 (±$2400 currently) for 
everybody. The ARIN fees are between $500 and $32000, with category Small at 
$2000 and Medium at $4000. I personally am glad about this (although in ARIN I 
would probably be Small) because it doesn't give operators any financial 
incentive to stingy when giving their customers IPv6 prefixes.

If you want to give a million customers a /48 it is not going to cost you more 
then giving them a /60. IPv6 resources are not such a scarce resource compared 
to IPv4, so differentiating price based on the amount of integers you need 
doesn't make much sense in the current world anymore :)

But: this is all RIPE NCC members/AGM stuff, independent of the RIPE community 
and its working groups. (well the RIPE NCC facilitates the RIPE meetings (note: 
RIPE meeting, not RIPE NCC meeting) and without the help of the NCC the RIPE 
community wouldn't have such well organised meetings. The NCC only facilitates 
though, it doesn't control or influence the RIPE working groups) and the 
structure of the RIPE working groups was what Randy was referring to.

Cheers,
Sander

Re: ARIN board accountability to network operators (was: RE: [arin-ppml] [arin-discuss] Term Limit Proposal)

[Sander Steffann]

Hi Owen,

 Compare and contrast the costs of being a PI holding end-user in the RIPE 
 region to those in the ARIN region and the difference becomes much more 
 noticeable.

Yeah, RIPE NCC is definitely much cheaper for PI: no initial registration fee 
of ≥$500. The maintenance cost is $100/year vs €100/year (±$137) so there is a 
little difference there. The $37 difference will take at least 13.5 years to 
make up for the $500 though. And that is just for up to a /22. The $4000 
initial fee for a /16 PI would take you more than a hundred years :)

So yes: for PI the difference is much more noticeable, in favour of the RIPE 
NCC :)

Cheers,
Sander

Re: ARIN board accountability to network operators

[Sander Steffann]

Oops. /me was confused. €50 indeed!

Met vriendelijke groet,
Sander Steffann

 Op 28 mrt. 2014 om 15:20 heeft Nick Hilliard n...@foobar.org het volgende 
 geschreven:
 
 On 28/03/2014 14:03, Sander Steffann wrote:
 Yeah, RIPE NCC is definitely much cheaper for PI: no initial
 registration fee of ≥$500. The maintenance cost is $100/year vs
 €100/year (±$137) so there is a little difference there. The $37
 
 €50 per PI assignment from the ripe ncc, no?
 
 http://www.ripe.net/ripe/docs/ripe-591
 
 Nick
 
 

Re: ipv6 newbie question

[Sander Steffann]

Hi,

 Is it best practice to have the internet facing BGP router's peering ip (or 
 for that matter any key gateway or security appliance) use a statically 
 configured address or use EUI-64 auto config?
 
 I have seen comments on both sides and am leaning to EUI-64 (except for the 
 VIP's like the ASA's failover ip )

Static. You don't want to have to contact all of your peers when the EUI-64 
address changes when you replace hardware.

Cheers
Sander

Re: Will a single /27 get fully routed these days?

[Sander Steffann]

 
 But more important: which /10 is set aside for this? It is not listed on 
 https://www.arin.net/knowledge/ip_blocks.html
 
 I'm not sure it has been determined yet, let alone announced.
 
 According to https://www.arin.net/resources/request/ipv4_countdown.html 
 phase one it should have been done in September 2012: 'IPv4 address space 
 required for NRPM 4.10, which sets aside a contiguous IPv4 /10 block to 
 facilitate IPv6 deployment, was reserved and removed from the remaining IPv4 
 address pool.'  I can't find anything more specific though...
 
 OK, then I'm sure it's been determined, but I can't really fault them for not 
 announcing it yet.

?!?!?  How are people supposed to prepare their filters for those tiny 
allocations if the corresponding prefix is not published?

This is not making any sense...
Sander

Re: Will a single /27 get fully routed these days?

[Sander Steffann]

Hi,

 Op 27 jan. 2014 om 10:49 heeft Tore Anderson t...@fud.no het volgende 
 geschreven:
 
 * Sander Steffann
 
 But more important: which /10 is set aside for this? It is not listed
 on https://www.arin.net/knowledge/ip_blocks.html
 
 Probably 23.128/10:
 
 arin||ipv4|23.128.0.0|4194304||reserved|

Now that is useful information! Can someone from ARIN confirm this?

Cheers,
Sander

Re: Will a single /27 get fully routed these days?

[Sander Steffann]

Hi Owen,

 Same question… Will people adjust their filters, (even if only for that 
 prefix)? All over the world? I think 'will adjust their filters for XYZ' is 
 highly optimistic, but let's hope it will work, otherwise the ISPs in the 
 ARIN region will have a problem. (Or maybe not: existing ISPs (for who a 
 /2[4-8] is not a significant amount) might not mind if a new competitors 
 only gets a /2[5-8] that they cannot route globally. But I really hope it 
 doesn't come to that.)
 
 Realistically, anyone depending on IPv4 is going to has a growing problem 
 which will only continue to grow.

Yes, but those last IPv4 addresses are for ISPs who work with IPv6 and need a 
little bit of IPv4 to communicate with the legacy world. If they can't even do 
that it will be extra hard (impossible?) for them to function.

 But more important: which /10 is set aside for this? It is not listed on 
 https://www.arin.net/knowledge/ip_blocks.html
 
 I'm not sure it has been determined yet, let alone announced.

According to https://www.arin.net/resources/request/ipv4_countdown.html phase 
one it should have been done in September 2012: 'IPv4 address space required 
for NRPM 4.10, which sets aside a contiguous IPv4 /10 block to facilitate IPv6 
deployment, was reserved and removed from the remaining IPv4 address pool.'  I 
can't find anything more specific though...

 Consider the possibility of a policy change which allows the transfer of 
 smaller blocks (current ARIN policy limits this to /24 minimum, but ARIN 
 policy is not immutable, we have a policy development process so that 
 anyone who wants to can start the process of changing it.)
 
 I’m well aware of that, but I’ll stick to RIPE policies for now :-)
 
 I admit I'm not familiar with the details of the RIPE policy in this regard. 
 Do they allow longer prefixes to be transferred and/or acquired?

Allow: yes. Anybody doing that for globally routable purposes: no. Although it 
can be used for networks that don't need to be in the global BGP table.

 I will point out that the NA in NANOG mostly refers to the ARIN region.

??? No idea what this comment is supposed to mean. You may find this weird, but 
since the Internet is actually a global network I do care about what happens in 
NA...

Cheers,
Sander

Re: Will a single /27 get fully routed these days?

[Sander Steffann]

Hi,

 On 26/01/2014, at 10:35 pm, Dave Bell m...@geordish.org wrote:
 But more important: which /10 is set aside for this? It is not listed on
 https://www.arin.net/knowledge/ip_blocks.html
 
 100.64/10
 
 http://tools.ietf.org/search/rfc6598
 
 Correct me if I am wrong but this is the space reserved for internal use by 
 providers for space for CGN systems that is not 1918 space so it doesn’t 
 conflict with customers internal network IP Space.

You're correct. I actually assumed the 100.64/10 answer was meant as a joke :-)

Cheers,
Sander

Re: Will a single /27 get fully routed these days?

[Sander Steffann]

Hi Randy,

 i suspect that, as multi-homing continues to grow and ipv4 space
 fragments to be used in core-facing nat[64]-like things, a decade from
 now we'll see the boundary move to the right.

Maybe, if the equipment can handle the number of routes. I actually see two 
opposing things: the scarcity will require more fragmentation with smaller 
fragments, which requires less strict filtering. On the other hand the 
fragmentation will already start with e.g. /20s being fragmented into /24s. 
That might already cause problems for current hardware, which might cause 
people to filter more strictly. Unfortunately my crystal ball is broken at the 
moment.

When ARIN starts allocating /28s from the reserved /10 in ±12 months I wonder 
which direction it will go... I hope for the ARIN region that the majority of 
operators globally will loosen up their filters for at least that /10 within 
those 12 months so the allocations will actually be usable. For that to happen 
it would be very useful to know *which* /10 has been reserved in 2012 though... 
12 months is not much for global communication, education and filter 
adjustments.

And anyway, who needs IPv4 a decade from now? ;)

Cheers,
Sander

Re: Will a single /27 get fully routed these days?

[Sander Steffann]

Hi,

 Yeah, its been a while since I had to get involved in this.  We have a
 customer with their own IPv4 allocation that wants us to announce a /27 for
 them. Back in the day, it was /24 or larger or all bets were off.  Is
 that still the case now?

This is still the case today.

I wonder what will change (if anything) when ARIN runs out of IPv4 space. 
Geoff's current predictions say Feb 2015, but I wouldn't be surprised if it 
turns out to be sooner than that. But, when that happens ARIN will only have 
the 'Dedicated IPv4 block to facilitate IPv6 Deployment' [1] left, and it will 
use 'a minimum size allocation of /28 and a maximum size allocation of /24' for 
that block. The block is meant for things like dual stacked DNS servers, NAT64 
and other IPv6 deployments where a bit of IPv4 is still necessary.

I wonder how reachable those systems will be... Will people adjust their 
filters, or will most usage of this block (and thereby all new entrants in the 
ISP market in the ARIN region) just be doomed?

Cheers,
Sander


[1] https://www.arin.net/policy/nrpm.html#four10

Re: Will a single /27 get fully routed these days?

[Sander Steffann]

Hi,

Op 25 jan. 2014, om 23:05 heeft Jeff Kell jeff-k...@utc.edu het volgende 
geschreven:

 (snip)
 
 I doubt that anything  /24 will ever be eligible as a portable
 provider independent block.  If within a provider, you can slice and
 dice as you wish.

Sure, but the text I quoted is about ARIN allocations, so ARIN - ISP. So the 
/28 is not provider-independent. It *is* the provider... And yes: I think this 
will become a mess in ARIN land :(

Cheers,
Sander

Re: Will a single /27 get fully routed these days?

[Sander Steffann]

Hi Jimmy,

 There aren't any /27 or /28 Allocations from ARIN to an ISP
 A /28 is longer than the ARIN Minimum allocation block size of /22,  and 
 longer than the minimum transfer size of a /24 block.

Now: yes. Soon: no. Read https://www.arin.net/policy/nrpm.html#four10
Sander

Re: Will a single /27 get fully routed these days?

[Sander Steffann]

Hi Owen,

Op 26 jan. 2014, om 05:36 heeft Owen DeLong o...@delong.com het volgende 
geschreven:

 On Jan 25, 2014, at 13:59 , Sander Steffann san...@steffann.nl wrote:
 
 Hi,
 
 […] But, when that happens ARIN will only have the 'Dedicated IPv4 block to 
 facilitate IPv6 Deployment' [1] left, and it will use 'a minimum size 
 allocation of /28 and a maximum size allocation of /24' for that block. The 
 block is meant for things like dual stacked DNS servers, NAT64 and other 
 IPv6 deployments where a bit of IPv4 is still necessary.
 
 I wonder how reachable those systems will be... Will people adjust their 
 filters, or will most usage of this block (and thereby all new entrants in 
 the ISP market in the ARIN region) just be doomed?
 
 That's actually may not be the best question. That block will come from 
 within a specific prefix and I suspect that ISPs and the like will adjust 
 their filters FOR THAT PREFIX.

Same question… Will people adjust their filters, (even if only for that 
prefix)? All over the world? I think 'will adjust their filters for XYZ' is 
highly optimistic, but let's hope it will work, otherwise the ISPs in the ARIN 
region will have a problem. (Or maybe not: existing ISPs (for who a /2[4-8] is 
not a significant amount) might not mind if a new competitors only gets a 
/2[5-8] that they cannot route globally. But I really hope it doesn't come to 
that.)

But more important: which /10 is set aside for this? It is not listed on 
https://www.arin.net/knowledge/ip_blocks.html

 Consider the possibility of a policy change which allows the transfer of 
 smaller blocks (current ARIN policy limits this to /24 minimum, but ARIN 
 policy is not immutable, we have a policy development process so that anyone 
 who wants to can start the process of changing it.)

I’m well aware of that, but I’ll stick to RIPE policies for now :-)

Cheers,
Sander

Re: turning on comcast v6

[Sander Steffann]

Hi,

Op 11 dec. 2013, om 20:46 heeft Kinkaid, Kyle kkink...@usgs.gov het volgende 
geschreven:
 I'm curious, do you know of a consumer-grade router which supports
 DHCPv6-PD?

I have tested a whole bunch of them more than a year ago. I can remember seeing 
IPv6 DHCPv6-PD client support on gear from AVM Fritz!box, D-Link, Draytek, 
Zyxel, Linksys, Asus, Thompson/Technicolor and I must be forgetting a few as 
well. Most of them weren't very advanced, but they worked to get IPv6 
connectivity in the house. What I am missing these days is DHCPv6-PD server 
support to re-delegate parts of the prefix it got from the ISP downstream to 
other home routers. As far as I know AVM Fritz!box is the only one that does 
that today.

Cheers,
Sander

Re: What routers do folks use these days?

[Sander Steffann]

Hi Mikael,

 Some go for the new Sup2T for the 6500, but I don't know how much more CPU it 
 has compared to your SUP/RSP720, perhaps someone else knows?

The Sup2T I worked on has:

 CPU: MPC8572_E, Version: 2.2, (0x80E80022)
 CORE: E500, Version: 3.0, (0x80210030)
 CPU:1500MHz, CCB:600MHz, DDR:600MHz

Compared to a Sup720:

 SR71000 CPU at 600Mhz, Implementation 0x504, Rev 1.2, 512KB L2 Cache

Needless to say, working on the Sup2T is wonderful compared to the Sup720 :-)

Cheers,
Sander

Re: Reverse DNS RFCs and Recommendations

[Sander Steffann]

Hi,

Op 2 nov. 2013, om 12:16 heeft Masataka Ohta mo...@necom830.hpcl.titech.ac.jp 
het volgende geschreven:

 Mark Andrews wrote:
 
 A cable modem both accepts DHCP packets (for management of the
 modem) and passes DHCP packets through to the customer device.
 
 Even if the CPE does so, which means there is no NAT, the key
 to update rDNS must, naturally, be contained only in DHCP reply
 to the CPE.

You are misunderstanding the technology. Many cable operators offer a cable 
modem in bridged mode so that the customer can attach his own home-router 
behind it. Sending keys over a medium shared between multiple customers is not 
safe.

Cheers,
Sander

Re: Reverse DNS RFCs and Recommendations

[Sander Steffann]

Hi,

 Also remember that this thread is on secure rDNS by the ISP,
 which means you can't expect the ISP operate rDNS very securely
 even though the ISP operate rest of networking not very securely.

You're linking things together that are completely orthogonal...
Sander

Re: IPAM

[Sander Steffann]

Hi,

 I'm pretty sure that if 6connect doesn't have an existing tool to import 
 Northstar that they'd work with your client to get it done.

+1 on 6connect. Very helpful people there :-)
Sander

Re: [c-nsp] VPLS PE Redundancy with Supervisor Engine 2T

[Sander Steffann]

Hi,

 We're trying to implement VPLS PE Redundancy with Supervisor Engine 2T (VSS) 
 as described in 
 http://www.cisco.com/en/US/prod/collateral/switches/ps5718/ps708/white_paper_c11-663645.html#wp9000139
  and constantly failing. It seems so simple: set up a VSS, use LACP or PAgP 
 port-channels to the distribution switches and do VPLS on the VSS. It just 
 doesn't seem to work. Using WS-X6908-10G-2TXL line cards already gives less 
 problems than with WS-X6704-10GE line cards, but still it fails to work very 
 often. I sometimes wonder if I am going mad or if this setup has never 
 actually been tested...
 
 So: has anybody ever set up a network like this, or am I really beta testing 
 for Cisco now?

With a lot of thanks, credits etc to Arie Vayner: enabling 'mpls ldp 
graceful-restart' is a work-around for this problem. If you run into this 
situation look at:
- https://supportforums.cisco.com/thread/2131580
- CSCsw70062

Cheers,
Sander

Re: IPV6 in enterprise best practices/white papaers

[Sander Steffann]

Hi,

 I have read many of those ipv6 documents and they are great but I
 still luck to find something like real word scenario.

Keep an eye on Deploy360: http://www.internetsociety.org/deploy360/ipv6/

 What I mean is that for example I want to start implementation of ipv6
 in my enterprise according to mu knowledge so far
 my first step is to create address plan

Yes. I wrote a document on that for SURFnet a couple of years ago (in Dutch). 
The RIPE NCC translated it to English: 
http://www.ripe.net/lir-services/training/material/IPv6-for-LIRs-Training-Course/IPv6_addr_plan4.pdf

 , then implement security on routers/switches then on hosts,

You'll at least have to think about security at this point. Think about how you 
do security for IPv4. If you do DHCP snooping for IPv4 then you might want to 
do it for IPv6. One thing to pay attention to is Router Advertisements (RA). 
Most operating systems these days listen to RA packets and will auto-configure 
their IPv6 stack based on the information in them. Someone (accidentally or on 
purpose) sending wrong RAs on your LAN can cause problems. But then: anybody 
who can access your LAN can cause trouble. This is a risk you already have, but 
still something to think about.

 and after that I can start to create  record and PTR records in DNS

Well, first you'll have to configure your systems and services to be available 
over IPv6. So you'll have to check the configurations of your web servers, DNS 
servers, mail servers, etc. Once you are confident that the service will work 
just as well over IPv6 as over IPv4 then add the DNS records.

First make it work, and only then add the DNS records to advertise it.

 and after that I should configure my dhcp servers

Think about whether you want a stateful DHCPv6 server (to keep track of every 
IPv6 address used by a system, to be able to do DHCP snooping on switches, etc) 
or whether a stateless DHCPv6 server (only supply DNS information and other 
configuration parameters, but not managing the client's addresses). If you 
don't do DHCP snooping now and you don't really care which IPv6 addresses a PC 
gets then stateless DHCP is fine.

 and after all has been done I can test ipv6 in LAN and

Once you start sending RAs and deploying DHCPv6 you will already have IPv6 in 
those LANs...

 after that I can start configure bgp with ISP.

No. *First* talk to your ISP, get address space (either from your ISP or 
provider independent), make an addressing plan, configure your firewalls and 
configure your back bone, then connect to your ISP, then deploy IPv6 on servers 
and clients (first on small test networks in your lab if possible), then 
advertise it in DNS.

 Is this correct procedure? Any thoughts? If all is correct I have a
 few questions..
 
 Regarding DNS, if I give a /64 to host

You give a /64 subnet to a LAN, and the systems on that LAN get addresses from 
that subnet.

 using SLAAC or DHCP how do I maintain PTR for this /64? I should use DDNS?

That depends. I know many organisations that don't care about reverse DNS for 
workstations, only for servers. Servers you usually give a static address, so 
you can configure the PTR records manually. When you use SLAAC (with optionally 
stateless DHCPv6) and you want to maintain the PTR records then you might use 
DDNS. If you use stateful DHCPv6 then let the DHCPv6 server handle the DNS 
updates.

 What do you use in your enterprise SLAAC or DHCP? If SLAAC why not DHCP?

I think I already answered this question above somewhere :-)

 Any other hints/tips?

Deploy on test networks first. From your questions it seems that you have 
little hands-on experience with IPv6. Get that experience first before working 
on your production networks. Maybe even get an IPv6 tunnel with a /48 of IPv6 
addresses from HE / tunnerbroker.net to play with in your lab. It's free and 
works very well, especially for getting experience!

Cheers,
Sander

Re: CGN fixed/hashed nat question

[Sander Steffann]

Hi,

 There are several conflicting requirements, including:
 
 - requirement to run a business which makes money
 - constraints on IPv4 addresses which mandate NAT
 - law enforcement requirements, mandating either logging / port tracking
 - network telemetry
 
 law enforcement requirements aren't generally an issue until you get hit up
 by a LEA / court order, at which point they become critical to ensuring
 that your management doesn't end up displaying contempt of court.  For some
 reason, management can get quite excited about this - more so than any
 enthusiasm they might ever show for good quality network telemetry.

I am so glad that Dutch law enforcement officially confirmed that logging is 
not allowed by law because of privacy impact, and that port tracking is not 
required.

Yes: they see that this will cause problems. But it's the law (at least, the 
current law).

- Sander

Re: Slashdot: UK ISP PlusNet Testing Carrier-Grade NAT Instead of IPv6

[Sander Steffann]

Hi,

 If I have calculated the netmasks right that would mean to set aside:
 
 2001:0DB8:6440::/42
 
 for the use of 6rd service:
 
 2001:0DB8:6440:::/64 = 100.64.0.0
 
 2001:0DB8:647F:::/64 = 100.127.255.255

You probably should add a few extra bits for subnetting behind the 6rd CPE. 
Delegating one /64 would be annoying as more and more CPEs have separate 
home/office/guest networks. Giving a /56 to each customer would be good and 
would only take an IPv6 /34 to map from 100.64.0.0/10. That is a quarter of the 
smallest IPv6 allocation an ISP can get.

ISPs can get plenty of IPv6 address space these days if they need it. Smaller 
ISPs don't need to map the whole 100.64.0.0/10, they could just start with 
100.64.0.0/16 for example, which would only take a /40 to give every customer a 
/56. More blocks can always be added to the 6rd setup later.

Cheers,
Sander

Re: Notice: Fradulent RIPE ASNs

[Sander Steffann]

Hi,

 is likely to be following the
 reporting procedure for the provision of untruthful information to the
 RIPE NCC at http://www.ripe.net/contact/reporting-procedure, which is
 a well defined procedure.  RIPE NCC will investigate any report
 submitted though this procedure; there is a flowchart at this web
 address that clearly explains what will happen.
 
 See above. I have done a great deal of work on this already.  I leave
 it to other interested parties to file wharever additional reports they
 might feel are warranted or appropriate.

Sorry, but you post this information on public mailing lists where it can be 
discussed but where no action can be taken, and then refuse to post it to the 
single organisation that actually *can* do something with it?

Nobody else will take your research and submit it to a third party. It's your 
research: either you submit it to the RIPE NCC and action will be taken where 
appropriate, or you don't and then your research will be forgotten and nothing 
will be done... It's just one form to fill in.

Thanks,
Sander

Re: Notice: Fradulent RIPE ASNs

[Sander Steffann]

Hi,

 I'm having more than a little deja vu here - Romanian LIRs have come up on 
 this list (leave alone nanog, or various other RIPE lists) more than once in 
 this context.  In fact 

Yes, but like I said: talk on lists is not enough

 There is an apparent pattern of large scale misuse of resources here, with a 
 complex reporting procedure that puts the onus on the complainant to perform 
 validation

Filling in one web form is a complex reporting procedure?

The form only contains:
- the reason (probably Violation of RIPE Policies and RIPE NCC Procedures or 
Provision of untruthful information to the RIPE NCC)
- one of the relevant resources (can be an address, ASN or organisation object 
from the RIPE database) In order to identify the natural or legal person 
responsible.
- a text field where you can copypaste your report
- your contact details
- one checkbox I confirm that the information I provide is correct and to the 
best of my knowledge
- one checkbox I allow the RIPE NCC to forward my report and attachments to 
the party the report is about.
- a captcha

They add a note that your contact details will never be shared with a third 
party, only the content of your report. They also provide a nice flowchart that 
shows how they will handle the report, which basically comes down to: 
Report-submitted - report-accepted - start-investigation.

I really can't see how this is a complex reporting procedure that puts the 
onus on the complainant to perform validation. They don't ask for validation, 
only that you provide correct information on which they can base their 
investigation.

 that, given complaints of a widespread problem, RIPE staff is much better 
 qualified (not to mention, paid for their time) to do themselves, on a 
 proactive basis.

They do proactive audits and they do verification/validation of the information 
people write in the reports. They will take action on complaints of a 
widespread problem. They just need the proper information through the official 
channels, which in this case is a not-so-complicated web form...

Cheers,
Sander

Re: Advisory — D-root is changing its IPv4 address on the 3rd of January.

[Sander Steffann]

Hi,

 Additionally, we will be actively monitoring usage after the 6 month
 period to determine when best to terminate the service on the old IP.

Good to hear that.

 The old address, which is in the middle of UMD's network, is going to be
 black-holed once the change is over. Nothing will be on that IP once we
 move the root off.

Thank you, very important to get that confirmed :-)

 Additional notice to other listservs and on web pages is coming soon.

Thanks!
Sander

Re: Why do some providers require IPv6 /64 PA space to have public whois?

[Sander Steffann]

Hi,

 Ok, so I'll give you that tunneling a really short bit, tunneling isn't too 
 bad, but native is most of the time better.

So sad that some companies mess up in such a way that their customers rather 
tunnel than use their native infra... :-(
- Sander

Re: Big day for IPv6 - 1% native penetration

[Sander Steffann]

Hi,

 Again, where're the compelling IPv6-only content/apps/services?
 
 
 To answer your rhetorical question, http://www.kame.net/ has a dancing
 kame.  To my knowledge, that's the most compelling IPv6-only content.
 
 Don't forget http://loopsofzen.co.uk/ - that's definitely the most
 compelling IPv6-only content I've found.

Wow. Nice one!
Sander

Re: Big day for IPv6 - 1% native penetration

[Sander Steffann]

Hi,

 So, I assume 6in4 tunnels like HE.net are included in the native percentage?

As the traffic is delivered as native traffic to Google I don't think Google 
can even see that there is a tunnel between them and the user. They might see a 
lower MTU, but to Google the traffic is native IPv6.

- Sander

Re: Long and unabbreviatable IPv6 addresses with random overloaded bits, vs. tunnelbroker

[Sander Steffann]

Hi,

 I've tried contacting them in an effort to receive any kind of a
 proper IPv6 address without the plaintext IPv4 embedment, but
 they've given me all sorts of crazy and (IMHO) far-sketched excuses;
 from not wanting to maintain a separate database of IPv6
 addresses/subnets, and from lack of software provisioning support; to
 supposedly RIPE and/or edis' upstream providers requiring public whois
 entries for any /64's that edis.at would allocate for their customers

I can guarantee you that RIPE does *not* require public whois records for 
individual /64s (or even for separate /48s in PA space).

- Sander

Re: IPv6 Netowrk Device Numbering BP

[Sander Steffann]

Hi Owen,

 You really shouldn't need to parse these and it's perfectly valid to reject 
 them as invalid input. This really is an output only format [...]

I don't agree. I think it's actually the other way around. It's a valid 
representation of an IPv6 address so you be able to parse them. You don't need 
to be able to output them though.

 Finally, at this point, if you're feeling like you have to write your own IP 
 address parser, you're probably doing something wrong. PLEASE PLEASE PLEASE 
 use the standard
 libraries whenever possible.

Definitely +1 here!
Sander

Re: IP tunnel MTU

[Sander Steffann]

Hi,

 Certainly fixing all the buggy host stacks, firewall and compliance devices 
 to realize that ICMP isn't bad won't be hard.
 
 Wait till you get started on fixing the security consultants.
 
 Ack.  I've yet to come across a *device* that doesn't deal properly with 
 packet too big.  Lots (and lots and lots) of security people, one or two 
 applications, but no devices.


I know of one: Juniper SSG and SRX boxes used to block IPv6 ICMP errors when 
the screening option 'big ICMP packets' was enabled because it blocked all (v4 
and v6) ICMP packets bigger than 1024 bytes and IPv6 ICMP errors are often 1280 
bytes. I don't know if that has been fixed yet.

- Sander

Re: Issues encountered with assigning all ones IPv6 /64 address?

[Sander Steffann]

Hi,

 On a separate note, one of my customers discovered over the weekend
 that if they bring up an all ones IPv6 address in their /64
 (2001:db8:1:1::::) then they can't exchange traffic
 with stuff hosted at hetzner.de such as archives.postgresql.org or
 1-media-cdn.foolz.us. Seems filtered somewhere inside Hetzner.
 
 I found the same if I brought up an all ones address in any other
 /64 in the same /48 as well. Using ...:::fffe worked
 fine.
 
 I haven't had time to investigate further or tell them yet, though.

I discussed this with Hetzner and it seems to be a bug in JunOS 10.3R1.9.
- Sander