Mailing List Archive

> On 29 Nov 2021, at 09:41, scott <surfer@mauigateway.com> wrote:
>
>
> On 11/28/2021 9:47 AM, Owen DeLong via NANOG wrote:
>> Why not properly assign /48s to customers and /40s to cities?
>> ----------------------------------------------------------------------------------
>
> Side note: I recently tried to get /48 per customer with ARIN on repeated emails and they refused. We were already given an IPv6 block a while back. I told them I wanted to expand it so I could give out a /48 per customer and that we had more than 65535 customers, which is the block we got; 65535 /48s. I didn't even account for our needs.
>
> Without arguing the reasons, we will have to hand out /56s, rather than /48s because of this. So, it's not all /48-unicorns, puppies and rainbows.
>
> scott

Looks like a policy omission. You should be able to grow the per customer allocation up to /48 per customer.
One shouldn’t be stuck with /56 because one made a bad choice of prefix size initially.

--
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: marka@isc.org

sronan@ronan-online.com wrote:

> It certainly sounds like you’ve never operated a network at scale if
> you think knowing the IP address of something reduces Operational
> expense.

It's Mark, not me, who said:

: There was a time when knowing the IP(v4) address of every interface
: of every router in your network was cool.

> The only way to truly reduce Opex at scale is automation.

Automation by what? DNS?

Masataka Ohta

Dave Bell wrote:

>> That facebook poorly managed their DNS to cause the recent disaster
>> is an important evidence to support my point that DNS, so often, may
>> not be helpful for network operations against disastrous failures,
>> including, but not limited to, DNS failures.

> I don't want to wade into the middle of this argument, but has there been
> more information about the recent facebook outage released that I missed?

You should have missed:

https://engineering.fb.com/2021/10/05/networking-traffic/outage-details/
The end result was that our DNS servers became unreachable even though
they were still operational. This made it impossible for the rest of the
internet to find our servers.

> All I've read seems to say that the loss of connectivity to their DNS
> servers was a symptom, rather than the cause of the outage.

See above.

Another part of the release should also be interesting:

and second, the total loss of DNS broke many of the internal
tools we'd normally use to investigate and resolve outages
like this.

That is an evidence for my statement above "that DNS, so often,
may not be helpful for network operations against disastrous
failures".

You can't rely on automatic tools over DNS, when DNS is failing.

Masataka Ohta

William Herrin wrote:

> But, to hear Masataka tell it, copy and paste hasn't been invented yet
> so we all type IP addresses by hand on our vt100 CRT terminals.

You should be using so advanced technologies to input ASCII
text with touch and swipe, which is very slow, even slower
than cut and paste.

But, you should remember that using ASCII keyboard (of vt100
or whatever) is the fastest way to input IPv4 addresses.

Or, maybe, you can't touch type.

Masataka Ohta

On 11/29/21 00:41, scott wrote:

> Side note: I recently tried to get /48 per customer with ARIN on
> repeated emails and they refused.  We were already given an IPv6 block
> a while back.  I told them I wanted to expand it so I could give out a
> /48 per customer and that we had more than 65535 customers, which is
> the block we got; 65535 /48s.  I didn't even account for our needs.
>
> Without arguing the reasons, we will have to hand out /56s, rather
> than /48s because of this.  So, it's not all /48-unicorns, puppies and
> rainbows.

We have two types of customers - that that get assigned a /48, and those
that get assigned a /56.

Mark.

On 11/29/21 03:11, Masataka Ohta wrote:

>
> It's Mark, not me, who said:
>
> : There was a time when knowing the IP(v4) address of every interface
> : of every router in your network was cool.

In case you missed the nuance, I haven't had to do this in over 20 years.

Mark.

On 11/29/21 03:33, Masataka Ohta wrote:

> The end result was that our DNS servers became unreachable even though
> they were still operational. This made it impossible for the rest of
> the internet to find our servers.

So your suggestion to map machine addresses to human-readable names
is... what?

Or should we all just get bigger brains and remember machine addresses
by heart :-)?


> That is an evidence for my statement above "that DNS, so often,
> may not be helpful for network operations against disastrous
> failures".

Don't be drawn into Facebook's size as being what all operators on the
Internet do.

If DNS, for all operators, died in the same way it did for Facebook, I'm
certain we'd all be too busy to answer each other on this thread.

Operations significantly smaller than Facebook have had well-architected
DNS deployment for yonks. Don't let Facebook's scale leave you with the
assumption that if they cocked it up, the rest of us don't have a chance
in hell.

Mark.

Mark Tinka wrote:

>> It's Mark, not me, who said:
>>
>> : There was a time when knowing the IP(v4) address of every interface
>> : of every router in your network was cool.
>
> In case you missed the nuance, I haven't had to do this in over 20 years.

Say it to Shane, not me. That you two can not communicate well
is not my problem.

Masataka Ohta

man. 29. nov. 2021 02.12 skrev Masataka Ohta <
mohta@necom830.hpcl.titech.ac.jp>:

>
>
> > The only way to truly reduce Opex at scale is automation.
>
> Automation by what? DNS?
>
> Masataka Ohta
>


Most of our customers are provisioned by Radius. The remaining are
configured by scripting using Netconf.

We use DNS to document the network. If our DNS was down and I need to
connect to a router in some city, do you really expect me to remember the
IP address? I would have to look it up and our chosen database for that
happens to be DNS. It has some obvious advantages.

Regards

Baldur

>

I remember when I was a junior in a major NOC, we had this management host with a local hosts file for all critical components.



Probably worth reviewing some old school techniques. ????



If you can automate your gazillion routers business, you probably can also automate a couple of hosts file.



Jean



From: NANOG <nanog-bounces+jean=ddostest.me@nanog.org> On Behalf Of Baldur Norddahl
Sent: November 29, 2021 4:22 AM
To: NANOG <nanog@nanog.org>
Subject: Re: IPv6 and CDN's





man. 29. nov. 2021 02.12 skrev Masataka Ohta <mohta@necom830.hpcl.titech.ac.jp <mailto:mohta@necom830.hpcl.titech.ac.jp> >:



> The only way to truly reduce Opex at scale is automation.

Automation by what? DNS?

Masataka Ohta





Most of our customers are provisioned by Radius. The remaining are configured by scripting using Netconf.



We use DNS to document the network. If our DNS was down and I need to connect to a router in some city, do you really expect me to remember the IP address? I would have to look it up and our chosen database for that happens to be DNS. It has some obvious advantages.



Regards



Baldur

> On Nov 28, 2021, at 15:51 , Mark Andrews <marka@isc.org> wrote:
>
>
>
>> On 29 Nov 2021, at 09:41, scott <surfer@mauigateway.com> wrote:
>>
>>
>> On 11/28/2021 9:47 AM, Owen DeLong via NANOG wrote:
>>> Why not properly assign /48s to customers and /40s to cities?
>>> ----------------------------------------------------------------------------------
>>
>> Side note: I recently tried to get /48 per customer with ARIN on repeated emails and they refused. We were already given an IPv6 block a while back. I told them I wanted to expand it so I could give out a /48 per customer and that we had more than 65535 customers, which is the block we got; 65535 /48s. I didn't even account for our needs.
>>
>> Without arguing the reasons, we will have to hand out /56s, rather than /48s because of this. So, it's not all /48-unicorns, puppies and rainbows.
>>
>> scott
>
> Looks like a policy omission. You should be able to grow the per customer allocation up to /48 per customer.
> One shouldn’t be stuck with /56 because one made a bad choice of prefix size initially.

There is definitely something wrong here… Policy clearly states that you should be able to obtain an allocation large enough to provide /48s to all your customers if you so choose.

In fact, it is generally quite generous beyond that point.

Owen

> On Nov 28, 2021, at 23:19 , Mark Tinka <mark@tinka.africa> wrote:
>
>
>
> On 11/29/21 00:41, scott wrote:
>
>> Side note: I recently tried to get /48 per customer with ARIN on repeated emails and they refused. We were already given an IPv6 block a while back. I told them I wanted to expand it so I could give out a /48 per customer and that we had more than 65535 customers, which is the block we got; 65535 /48s. I didn't even account for our needs.
>>
>> Without arguing the reasons, we will have to hand out /56s, rather than /48s because of this. So, it's not all /48-unicorns, puppies and rainbows.
>
> We have two types of customers - that that get assigned a /48, and those that get assigned a /56.
>
> Mark.

So why be stingy to the second class? Why not just assign everyone a /48?

Owen

> On Nov 28, 2021, at 23:25 , Mark Tinka <mark@tinka.africa> wrote:
>
>
>
> On 11/29/21 03:33, Masataka Ohta wrote:
>
>> The end result was that our DNS servers became unreachable even though they were still operational. This made it impossible for the rest of the internet to find our servers.
>
> So your suggestion to map machine addresses to human-readable names is... what?

If you can limit the names to the characters a-f, i, o, s, and z then it’s possible to do so with IPv6 addresses natively.
(which you can’t do in IPv4).
(o=0, i=1, s=5, and z=2)

I’m not saying this is a good idea, but it is possible. There are a large number of english words that can be spelled with just those 9 characters.

Owen