A crazy idea

[Stephen Satchell]

First, I know this isn't the right place to propose this; need a pointer 
to where to propose an outlandish idea.


PROBLEM:  IPv6 support is still in its birthing pangs.  I see a problem 
that limits deployment of IPv6 fully:  reverse PTR records in the 
".in6.arpa." zones.


(Now that I think about it, this may very well be a network operator 
issue.  Who maintains the ".in.arpa." zones delegated by IANA now?)


I've been going 'round and 'round with AT&T about "static" IPv6 
addresses.  In particular, I can't get a PTR record in the ip6.arpa. 
zone to save my life.  Now, the problem is not really ripe yet, because 
the big reason for PTR records is for mail servers -- best practice 
calls for /PTR agreement, just like for IPv4 the best practice is 
for A/PTR agreement.


The existing DNS providers can support delegation domains, so that I 
don't have to have DNS servers of my own if I don't want to.  It could 
be that one would need to "buy" the delegation domain, but that's a 
front-office consideration.  Personally, I use register.com for my 
domain DNS zones.  I believe strongly that other registrars that offer 
customer zone editing, plus DNS service providers, can support reverse 
delegation zones with a minimum of hassle, and without charging an arm 
and a leg for the service.


From the customers' viewpoint, a GUI would make the maintenance 
relatively painless.


(Keying the information below took a long time.  Any rational DNS admin 
and DNS service provider would have automation in place to take out the 
painful work.)


What would the domain names look like?  Let's take my current IP/IPv6 
assignments from AT&T:


  2600:1700:79b0:ddc0::/64
  99.65.194.96/29

The IPv6 delegation would be easy:


0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-1.
0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-2.


because the delegation would always be on a /64 boundary. The customer 
assignments would be straightforward.  In my BIND9 zone file, it would 
look something like this:



$ORIGIN 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa.
@ IN SOA ...
@ NS my-DNS-server-1.
@ NS my-DNS-server-2.
1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR server1.example.com. 
2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR server2.example.com. 


Delegations for the IP range, not being on an octet boundary, would be a 
little more problematic:


> 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-1
> 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-2> $GENERATE 96-102 $ 
IN CNAME $.96-103.194.65.99.in-addr.arpa.


In my BIND9 zone file, it would look something like this:


$ORIGIN 96-103.194.65.99.in-addr.arpa.
@ SOA ...
@ NS my-dns-server-1.
@ NS my-dns-server-2.
96 IN PTR server1.example.com.
97 IN PTR server2.example.com.


The advantage to this system to the number providers is they would have 
one administrative record per customer, instead of having to deal with 
each PTR record individually.  The advantage to customers is they don't 
have to beg and snivel to get PTR records, just beg and snivel once to 
get the delegation.  The advantage to DNS server providers is they have 
something else to sell.


Want to encourage IPv6 adoption?  This would help.

Re: A crazy idea

[Feldman, Mark via NANOG]

What you propose is not outlandish; some ISPs have been dual stack and 
providing some combination of these services for years.  They already provide 
IPv6 ip6.arpa delegations should their business customers want them.  Some even 
provide at least a /56 so customers can have multiple /64 subnets.  And we, I 
mean they, can also provide RFC2317 in-addr.arpa delegations for those smaller 
IPv4 blocks.

  Mark


On 7/19/21, 8:13 AM, "NANOG on behalf of Stephen Satchell" 
 wrote:

First, I know this isn't the right place to propose this; need a pointer
to where to propose an outlandish idea.

PROBLEM:  IPv6 support is still in its birthing pangs.  I see a problem
that limits deployment of IPv6 fully:  reverse PTR records in the
".in6.arpa." zones.

(Now that I think about it, this may very well be a network operator
issue.  Who maintains the ".in.arpa." zones delegated by IANA now?)

I've been going 'round and 'round with AT&T about "static" IPv6
addresses.  In particular, I can't get a PTR record in the ip6.arpa.
zone to save my life.  Now, the problem is not really ripe yet, because
the big reason for PTR records is for mail servers -- best practice
calls for /PTR agreement, just like for IPv4 the best practice is
for A/PTR agreement.

The existing DNS providers can support delegation domains, so that I
don't have to have DNS servers of my own if I don't want to.  It could
be that one would need to "buy" the delegation domain, but that's a
front-office consideration.  Personally, I use register.com for my
domain DNS zones.  I believe strongly that other registrars that offer
customer zone editing, plus DNS service providers, can support reverse
delegation zones with a minimum of hassle, and without charging an arm
and a leg for the service.

 From the customers' viewpoint, a GUI would make the maintenance
relatively painless.

(Keying the information below took a long time.  Any rational DNS admin
and DNS service provider would have automation in place to take out the
painful work.)

What would the domain names look like?  Let's take my current IP/IPv6
assignments from AT&T:

   2600:1700:79b0:ddc0::/64
   99.65.194.96/29

The IPv6 delegation would be easy:

> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-1.
> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-2.

because the delegation would always be on a /64 boundary. The customer
assignments would be straightforward.  In my BIND9 zone file, it would
look something like this:

> $ORIGIN 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa.
> @ IN SOA ...
> @ NS my-DNS-server-1.
> @ NS my-DNS-server-2.
> 1.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR server1.example.com.
> 2.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0 IN PTR server2.example.com.

Delegations for the IP range, not being on an octet boundary, would be a
little more problematic:

 > 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-1
 > 96-103.194.65.99.in-addr.arpa. NS my-DNS-server-2> $GENERATE 96-102 $
IN CNAME $.96-103.194.65.99.in-addr.arpa.

In my BIND9 zone file, it would look something like this:

> $ORIGIN 96-103.194.65.99.in-addr.arpa.
> @ SOA ...
> @ NS my-dns-server-1.
> @ NS my-dns-server-2.
> 96 IN PTR server1.example.com.
> 97 IN PTR server2.example.com.

The advantage to this system to the number providers is they would have
one administrative record per customer, instead of having to deal with
each PTR record individually.  The advantage to customers is they don't
have to beg and snivel to get PTR records, just beg and snivel once to
get the delegation.  The advantage to DNS server providers is they have
something else to sell.

Want to encourage IPv6 adoption?  This would help.

Re: A crazy idea

[Stephen Satchell]

On 7/19/21 5:41 AM, Feldman, Mark wrote:

What you propose is not outlandish; some ISPs have been dual stack
and providing some combination of these services for years.  They
already provide IPv6 ip6.arpa delegations should their business
customers want them.  Some even provide at least a /56 so customers
can have multiple /64 subnets.  And we, I mean they, can also provide
RFC2317 in-addr.arpa delegations for those smaller IPv4 blocks.


The part that is missing isn't the "some ISPs", it's "all ISPs".  Also, 
I don't know of any DNS service provider that offers a product to handle 
delegations from the IN-ADDR.ARPA and IP6.ARPA trees.


I'm focusing on the SOHO customer market with my proposal.

The allocation of IPv6 space with prefixes shorter than /64 is indeed a 
consideration for bigger administrative domains like country 
governments, but on the other end, SOHO customers would be happy with 
/96, /104 or even /112 allocations if they could get them.  (Just how 
many light bulbs, fridges, toasters, doorbells, phones, &c does SOHOs 
have?)  I would *not* like to see "us" make the same mistake with IPv6 
that was made with IPv4, handing out large blocks of space like so many 
pieces of M&M or Skittles candy.

Re: A crazy idea

[Jared Mauch]

> On Jul 19, 2021, at 9:04 AM, Stephen Satchell  wrote:
> 
> On 7/19/21 5:41 AM, Feldman, Mark wrote:
>> What you propose is not outlandish; some ISPs have been dual stack
>> and providing some combination of these services for years.  They
>> already provide IPv6 ip6.arpa delegations should their business
>> customers want them.  Some even provide at least a /56 so customers
>> can have multiple /64 subnets.  And we, I mean they, can also provide
>> RFC2317 in-addr.arpa delegations for those smaller IPv4 blocks.
> 
> The part that is missing isn't the "some ISPs", it's "all ISPs".  Also, I 
> don't know of any DNS service provider that offers a product to handle 
> delegations from the IN-ADDR.ARPA and IP6.ARPA trees.
> 
> I'm focusing on the SOHO customer market with my proposal.

Most are regional carriers w/ monopoly and no incentive to offer anything else. 
 This is especially the case with AT&T in my area.  The same applies to other 
regional providers like Frontier and even services like Verizon FIOS that do 
not offer IPv6 at all.

You really want a SMB connection w/ dedicated IP space, and they may not be 
able to sell that to you on their consumer network.

- Jared

Re: [EXTERNAL] Re: A crazy idea

[Feldman, Mark via NANOG]

On 7/19/21, 9:04 AM, "Stephen Satchell"  wrote:

On 7/19/21 5:41 AM, Feldman, Mark wrote:
> What you propose is not outlandish; some ISPs have been dual stack
> and providing some combination of these services for years.  They
> already provide IPv6 ip6.arpa delegations should their business
> customers want them.  Some even provide at least a /56 so customers
> can have multiple /64 subnets.  And we, I mean they, can also provide
> RFC2317 in-addr.arpa delegations for those smaller IPv4 blocks.

The part that is missing isn't the "some ISPs", it's "all ISPs".

It's true that not all ISPs do IPv6.  There are those that do support it and 
those that will.  At some point the pain associated with the lack of IPv4 
address space will outweigh the pain of IPv6 deployment.   Those that do IPv6 
should support all of the service that I described.

Also,
I don't know of any DNS service provider that offers a product to handle
delegations from the IN-ADDR.ARPA and IP6.ARPA trees.

Any DNS service provider should be able to host an in-addr.arpa or ip6.arpa 
zone.  If they don't do "reverse/PTR" zones, they're really not a full service 
provider.  Zones are zones.

I'm focusing on the SOHO customer market with my proposal.

My standard residential service has my router getting a /64 that allows my 
hosts to self-generate public, routable /128 IPv6 addresses using EUI64 and 
other mechanisms when I don't bother setting the RHS of the address.   I also 
get a single IPv4 address which gets NAT'd.   There's no reason for a SOHO 
customer to have less than that and there are reasons to have more.

Every modern device in my house preferes IPv6 when the service to which it is 
connecting is dual stack.  It all just works as-is.  When things break, it's 
usually an antiquated piece of equipment  that doesn't grok IPv6 itself or 
there's one in the way.

Most of our residential customers don't pay attention the underlying protocols. 
 They just plug things in and use them.  Well over half of the DNS queries 
coming from our customers come in over IPv6.

The allocation of IPv6 space with prefixes shorter than /64 is indeed a
consideration for bigger administrative domains like country
governments, but on the other end, SOHO customers would be happy with
/96, /104 or even /112 allocations if they could get them.  (Just how
many light bulbs, fridges, toasters, doorbells, phones, &c does SOHOs
have?)  I would *not* like to see "us" make the same mistake with IPv6
that was made with IPv4, handing out large blocks of space like so many
pieces of M&M or Skittles candy.

The standard for an IPv6 subnet is a /64.  It's what makes EUI64  and other 
useful addressing techniques possible.  You can't think of IPv6 with an IPv4 
scarcity mindset -- that will cause you to cripple IPv6.  And, no, even with 
/64 subnets, you won't run out of IPv6 addresses -- there are still billions of 
times more subnets available with IPv6  than there are host addresses in IPv4.

Making the standard subnet a /64 and having IPv6 delegations fall on nibble 
boundaries means a clean mapping to DNS without RFC2317 games.

We used to have someone with the title, IPv6 Evangelist.  He got us far.  Now 
it's everyone's job.

  Mark

Re: A crazy idea

[Lukas Tribus]

Hello,

On Mon, 19 Jul 2021 at 15:04, Stephen Satchell  wrote:
> The allocation of IPv6 space with prefixes shorter than /64 is indeed a
> consideration for bigger administrative domains like country
> governments, but on the other end, SOHO customers would be happy with
> /96, /104 or even /112 allocations if they could get them.

Well, for SLAAC you need a /64, so if you want to be able to use
multiple subnets in your environment, you need a prefix shorter than
/64.

RIPE's recommendation is /56 for residential customers:
https://www.ripe.net/publications/docs/ripe-690#4-2-2---48-for-business-customers-and--56-for-residential-customers

and *strongly discourages* to assign prefixes longer than /56
https://www.ripe.net/publications/docs/ripe-690#4-2-3--prefixes--longer-than--56


cheers,
lukas

Re: A crazy idea

[t...@pelican.org]

On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:

> The allocation of IPv6 space with prefixes shorter than /64 is indeed a
> consideration for bigger administrative domains like country
> governments, but on the other end, SOHO customers would be happy with
> /96, /104 or even /112 allocations if they could get them.  (Just how
> many light bulbs, fridges, toasters, doorbells, phones, &c does SOHOs
> have?)  I would *not* like to see "us" make the same mistake with IPv6
> that was made with IPv4, handing out large blocks of space like so many
> pieces of M&M or Skittles candy.

Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, think in 
terms of subnets.  I can't stress this enough, it's the big v4 to v6 paradigm 
shift - don't think about "how many hosts on this net", think about "how many 
nets".

It's potentially useful for SOHO users to have multiple subnets, particularly 
as they stick multiple devices in their home network that try to do PD from the 
upstream for each downstream function.  /56 for every SOHO is a 
fire-and-forget, you don't have to dick about with right-sizing anything, you 
don't have to evaluate requirements with the customer, you don't have to do all 
kinds of management system stuff to track who has what size, and it gives you 
some room for a couple of levels of hierarchy within the house.

Make all of the subnets /64s, and SLAAC etc Just Work too.

Wikipedia suggests a little short of 200M households in the US.  That's 28 bits 
of space to give a /56 to every household.  Let's assume ISPs are really bad at 
aggregation, so those bits are spread across multiple PoPs, multiple ISPs, etc, 
and we take 36 bits of space to actually allocate those.  (That's only in /56 
in every 256 used, *lots* of room for sparse PoPs, sparse ISPs, etc).  Shift 
back 36 bits from a /56, we've used a /20 to number the entire US.

Same again for India.  3 of those for China.  It's all smaller from there for 
the rest of the world.  Maybe 100 or so /20s to number the entire world on the 
same plan.  There are a million /20s in the IPv6 address space.

We've got room to be sensible about assignments without repeating the IPv4 
scarcity problem.

Cheers,
Tim.

NANOG 83 call for presentations is open

[Cat Gurinsky]

NANOG Community,


The NANOG Program Committee (PC) would like to remind you they are
accepting proposals for in-person or remote presentations at all sessions
of NANOG 83, our first hybrid meeting, taking place in Minneapolis, MN on
November 1st-3rd, 2021. Below is a summary of key details and dates from
the Call For Presentations on the NANOG website, which can be found at
https://www.nanog.org/program/call-presentations/.


Don’t wait! Presentation abstracts and draft slides should be submitted no
later than Monday, September 27, 2021. Given by many of the industry’s top
minds, presentations at NANOG meetings are meant to spark the imagination,
encourage dialog, and drive new solutions to our greatest networking
challenges. Presentations may cover current technologies, soon-to-be
deployed technologies, and industry innovation. Vendors are welcome to
submit talks which cover relevant technologies and capabilities, but
presentations should not be promotional, or discuss proprietary solutions.


The primary speaker, moderator, or author should submit a presentation
proposal and abstract via the Program Committee Tool at:
https://www.nanog.org/meetings/submit-presentation/

   -

   Sign in with your Profile Account
   -

   Select the type of talk you propose to present, and complete the form


Timeline for submission and proposal review:

   -

   Submitter enters abstract (and draft slides if possible) in the Program
   Committee Tool prior to the deadline for slide submission.
   -

   PC performs initial review and assigns a “shepherd” to help develop the
   submission — typically within 2 weeks.
   -

   Submitter develops draft slides of talk if not already submitted with
   the initial proposal. Please submit initial draft slides early — the PC
   does not evaluate submissions until draft slides are available for review.
   NANOG Staff is available to assist with slide templates upon request from
   the submitter.
   -

   Panel and Track submissions should provide a topic list and
   intended/confirmed participants in the abstract.
   -

   PC reviews the slides and continues to work with Submitter as needed to
   develop the topic.
   -

   FINAL SUBMISSION DEADLINE Draft presentation slides should be submitted
   prior to the published deadline for slides (September 27, 2021).
   -

   PC evaluates submissions to determine presentations for the agenda
   (posted on October 18, 2021).
   -

   Agenda assembled and posted.
   -

   Submitters notified.
   -

   Final presentation slides must be submitted prior to the published
   deadline for slides (October 4, 2021 for Pre-recordings and October 22,
   2021 for in-person presentations).


If you think you have an interesting topic but want feedback or suggestions
for developing an idea into a presentation, please email the PC (
nano...@nanog.org), and a representative will respond to you in a timely
manner. Otherwise, submit your talk, keynote, track, or panel proposal to
the Program Committee Tool at your earliest convenience. We look forward to
reviewing your submission!


NANOG 83 Calendar of Events

Date

Event/Deadline

July 19, 2021

CFP Announced

Sept 27, 2021

Submission Deadline: Abstracts WITH Draft Presentation Slides Due

Oct 4, 2021

Pre-Record Presentation FINAL Slides Due

Oct 4, 2021

Topics List + Highlights Posted

Oct 15, 2021

Speaker Presentation Recordings Finalized

Oct 18, 2021

NANOG 83 Agenda Published

Oct 22, 2021

In-Person Presentation FINAL Slides Due

Nov 1-3, 2021

NANOG 83 Conference



Final slides for pre-recorded presentations must be submitted by Monday,
October 4, 2021. NO changes will be accepted between the recording date and
the conference. Final slides for in-person presentations must be submitted
by Friday, October 22, 2021. Materials received after that date may be
updated on the website after the completion of the conference.


We look forward to seeing you in November!


Sincerely,


Cat Gurinsky

Program Committee Chair

Sent on behalf of the NANOG PC

Any CloudFlare Rep?

[Kushal R. via NANOG]

Could someone from CloudFlare please contact me off the list? There is some 
crazy abuse going on one a site proxied through CF. Tried the usual twitter and 
abuse form. In the last 4 hours 2 people I know personally have lost $500+ each 
and hundreds are falling prey each day.


—   

Kushal R.   

Executive Management

[https://host4geeks.com/]   

WhatsApp: +1-(954)-737-4335 

Skype: kush.raha

Host4Geeks LLC - Premium Managed Hosting [https://host4geeks.com]   

Trusted by over 10,000 Clients Globally 

[https://www.trustpilot.com/review/www.host4geeks.com]  
[https://h4g.co/TtM493]

Re: A crazy idea

[Randy Bush]

> Well, for SLAAC you need a /64

this is not true

randy

---
ra...@psg.com
`gpg --locate-external-keys --auto-key-locate wkd ra...@psg.com`
signatures are back, thanks to dmarc header butchery

Re: A crazy idea

[Nathan Angelacos]

On Mon, 2021-07-19 at 08:51 -0700, Randy Bush wrote:
> > Well, for SLAAC you need a /64
> 
> this is not true
> 
> randy


That is cool!   Can you point me to the correct RFC please?

Re: Any CloudFlare Rep?

[Justin Paine via NANOG]

Hi,

Replying off list.



__
*Justin Paine*
He/Him/His
Threat Intel
101 Townsend St, San Francisco, CA 94107 

*PGP:* BBAA 6BCE 3305 7FD6 6452 7115 57B6 0114 DE0B 314D



On Mon, Jul 19, 2021 at 8:39 AM Kushal R. via NANOG  wrote:

> Could someone from CloudFlare please contact me off the list? There is
> some crazy abuse going on one a site proxied through CF. Tried the usual
> twitter and abuse form. In the last 4 hours 2 people I know personally have
> lost $500+ each and hundreds are falling prey each day.
>
>
> —
> Kushal R.
> *Executive Management*
> 
> WhatsApp: +1-(954)-737-4335 <+19547374335>
> Skype: kush.raha
>
> Host4Geeks LLC - Premium Managed Hosting 
> Trusted by over 10,000 Clients Globally
>
> 
> 
>

Re: A crazy idea

[Randy Bush]

On Mon, 19 Jul 2021 09:27:13 -0700,
Nathan Angelacos wrote:
> 
> On Mon, 2021-07-19 at 08:51 -0700, Randy Bush wrote:
> > > Well, for SLAAC you need a /64
> > 
> > this is not true
> > 
> > randy
> 
> 
> That is cool!   Can you point me to the correct RFC please?
> 

from the war zone, draft-classless6/draft-nbourbaki-6man-classless-ipv6
said

   The length of the Interface Identifier in Stateless Address
   Autoconfiguration [RFC4862] is a parameter; its length SHOULD be
   sufficient for effective randomization for privacy reasons.  For
   example, 48 bits might be sufficient.  But operationally we
   recommend, barring strong considerations to the contrary, using
   64-bits for SLAAC in order not to discover bugs where 64 was hard-
   coded, and to favor portability of devices and operating systems.

   Note that OpenBSD ships with SLAAC for lengths longer than /64.

   Nonetheless, there is no reason in theory why an IPv6 node should not
   operate with different interface identifier lengths on different
   physical interfaces.  Thus, a correct implementation of SLAAC must in
   fact allow for any prefix length, with the value being a parameter
   per interface.  For instance, the Interface Identifier length in the
   recommended (see [RFC8064]) algorithm for selecting stable interface
   identifiers [RFC7217] is a parameter, rather than a hard-coded value.

Re: A crazy idea

[John Waters via NANOG]

I'm with Tim on this.  I'm unsure if you've kept a mental note of just how big 
IPv6 is, but it's 340,282,366,920,938,000,000,000,000,000,000,000,000 IP 
addresses in IPv6

IPv4 on the other hand has 4,294,967,296 total IP addresses. 

I understand the issuance and total use leading to exhaustion concern, but at 
the same time, so long as we're somewhat sane with our using of IPv6, we will 
end up fine.
Thanks Much,
John Waters
President and Chief Architect
Capitol Hosting Solutions

//Dance like nobody is watching, Encrypt like everyone is.

\\This message was sent from my mobile device, please forgive any typos or 
brevity.

Jul 19, 2021 8:16:02 AM t...@pelican.org:

> On Monday, 19 July, 2021 14:04, "Stephen Satchell"  said:
> 
>> The allocation of IPv6 space with prefixes shorter than /64 is indeed a
>> consideration for bigger administrative domains like country
>> governments, but on the other end, SOHO customers would be happy with
>> /96, /104 or even /112 allocations if they could get them.  (Just how
>> many light bulbs, fridges, toasters, doorbells, phones, &c does SOHOs
>> have?)  I would *not* like to see "us" make the same mistake with IPv6
>> that was made with IPv4, handing out large blocks of space like so many
>> pieces of M&M or Skittles candy.
> 
> Nay, nay, and thrice nay.  Don't think in terms of addresses for IPv6, think 
> in terms of subnets.  I can't stress this enough, it's the big v4 to v6 
> paradigm shift - don't think about "how many hosts on this net", think about 
> "how many nets".
> 
> It's potentially useful for SOHO users to have multiple subnets, particularly 
> as they stick multiple devices in their home network that try to do PD from 
> the upstream for each downstream function.  /56 for every SOHO is a 
> fire-and-forget, you don't have to dick about with right-sizing anything, you 
> don't have to evaluate requirements with the customer, you don't have to do 
> all kinds of management system stuff to track who has what size, and it gives 
> you some room for a couple of levels of hierarchy within the house.
> 
> Make all of the subnets /64s, and SLAAC etc Just Work too.
> 
> Wikipedia suggests a little short of 200M households in the US.  That's 28 
> bits of space to give a /56 to every household.  Let's assume ISPs are really 
> bad at aggregation, so those bits are spread across multiple PoPs, multiple 
> ISPs, etc, and we take 36 bits of space to actually allocate those.  (That's 
> only in /56 in every 256 used, *lots* of room for sparse PoPs, sparse ISPs, 
> etc).  Shift back 36 bits from a /56, we've used a /20 to number the entire 
> US.
> 
> Same again for India.  3 of those for China.  It's all smaller from there for 
> the rest of the world.  Maybe 100 or so /20s to number the entire world on 
> the same plan.  There are a million /20s in the IPv6 address space.
> 
> We've got room to be sensible about assignments without repeating the IPv4 
> scarcity problem.
> 
> Cheers,
> Tim.

100G, input errors and/or transceiver issues

[Graham Johnston]

Good day,

Over the last two years, organizations that I've worked with have upgraded
equipment and now make regular use of 100G port speeds. To provide a frame
of reference on use cases, the organizations that I've worked for make use
of 100G speeds within their own data centers, in carrier neutral data
centers, and lease 100G transport from larger carriers; they don't
currently operate their own 100G coherent/long-haul networks.


   - How commonly do other operators experience input errors with 100G
   interfaces?
   - How often do you find that you have to change a transceiver out?
   Either for errors or another reason.
   - Do we collectively expect this to improve as 100G becomes more common
   and production volumes increase in the future?

Thanks,
Graham

Re: A crazy idea

[Bryan Fields]

On 7/19/21 8:09 AM, Stephen Satchell wrote:
> First, I know this isn't the right place to propose this; need a pointer 
> to where to propose an outlandish idea.

> What would the domain names look like?  Let's take my current IP/IPv6 
> assignments from AT&T:
> 
>2600:1700:79b0:ddc0::/64
>99.65.194.96/29
> 
> The IPv6 delegation would be easy:
> 
>> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-1.
>> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-2.

Yup, simple, I do this for my customers (and DS records).

However that reverse zone has DNSSEC on it.  You'd need a DS record to tie
my-DNS-server-1. to the ATT DNS server and your server would need to support
DNSSEC.  ATT may want to enforce DNSSEC on that zone, but not want to sign
stuff they can't control.

Just playing devils advocate.

-- 
Bryan Fields

727-409-1194 - Voice
http://bryanfields.net

Re: 100G, input errors and/or transceiver issues

[Saku Ytti]

On Mon, 19 Jul 2021 at 19:47, Graham Johnston
 wrote:

Hey Graham,

> How commonly do other operators experience input errors with 100G interfaces?
> How often do you find that you have to change a transceiver out? Either for 
> errors or another reason.
> Do we collectively expect this to improve as 100G becomes more common and 
> production volumes increase in the future?

New rule. Share your own data before asking others to share theirs.

IN DC, SP markets 100GE has dominated the market for several years
now, so it rings odd to many at 'more common'. 112G SERDES is shipping
on the electric side, and there is nowhere more mature to go from
100GE POV. The optical side, QSFP112, is really the only thing left to
cost optimise 100GE.
We've had our share of MSA ambiguity issues with 100GE, but today
100GE looks mature to our eyes in failure rates and compatibility. 1GE
is really hard to support and 10GE is becoming problematic, in terms
of hardware procurement.


-- 
  ++ytti

Re: 100G, input errors and/or transceiver issues

[Graham Johnston]

Saku,

I don't at this point have long term data collection compiled for the
issues that we've faced. That said, we have two 100G transport links that
have a regular background level of input errors at ranges that hover
between 0.00055 to 0.00383 PPS on one link, and none to 0.00135 PPS (that
jumped to 0.03943 PPS over the weekend). The range is often directionally
associated rather than variable behavior of a single direction. The data
comes from the last 24 hours, the two referenced links are operated by
different providers on very different paths (opposite directions). Over
shorter distances, we've definitely seen input errors that have affected
PNI connections within a datacenter as well. In the case of the last PNI
issue, the other party swapped their transceiver, we didn't even physically
touch our side; I note this only to express that I don't think this is just
a case of the transceivers that we are sourcing.

Comparatively, other than clear transport system issues, I don't recall
this sort of thing at all with 10G "wavelength" transport that we had
purchased for years prior. I put wavelengths in quotes there knowing that
it may have been a while since our transport was a literal wavelength as
compared to being muxed into a 100G+ wavelength.

On Mon, 19 Jul 2021 at 12:01, Saku Ytti  wrote:

> On Mon, 19 Jul 2021 at 19:47, Graham Johnston
>  wrote:
>
> Hey Graham,
>
> > How commonly do other operators experience input errors with 100G
> interfaces?
> > How often do you find that you have to change a transceiver out? Either
> for errors or another reason.
> > Do we collectively expect this to improve as 100G becomes more common
> and production volumes increase in the future?
>
> New rule. Share your own data before asking others to share theirs.
>
> IN DC, SP markets 100GE has dominated the market for several years
> now, so it rings odd to many at 'more common'. 112G SERDES is shipping
> on the electric side, and there is nowhere more mature to go from
> 100GE POV. The optical side, QSFP112, is really the only thing left to
> cost optimise 100GE.
> We've had our share of MSA ambiguity issues with 100GE, but today
> 100GE looks mature to our eyes in failure rates and compatibility. 1GE
> is really hard to support and 10GE is becoming problematic, in terms
> of hardware procurement.
>
>
> --
>   ++ytti
>

Re: 100G, input errors and/or transceiver issues

[Saku Ytti]

On Mon, 19 Jul 2021 at 20:19, Graham Johnston
 wrote:

> I don't at this point have long term data collection compiled for the issues 
> that we've faced. That said, we have two 100G transport links that have a 
> regular background level of input errors at ranges that hover between 0.00055 
> to 0.00383 PPS on one link, and none to 0.00135 PPS (that jumped to 0.03943 
> PPS over the weekend). The range is often directionally associated rather 
> than variable

On typical 100G link we do not get single FCS error in a typical day.
However Ethernet spec still allows very high error rate of 10**-12. So
1 error per 1Tb (b not B). I.e. 1 error per 10s, or 0.1PPS would be
in-spec. We see much better performance to this and vendors generally
accept lower error rates as legitimate errors.

-- 
  ++ytti

Re: 100G, input errors and/or transceiver issues

[Jared Mauch]

> On Jul 19, 2021, at 1:50 PM, Saku Ytti  wrote:
> 
> On Mon, 19 Jul 2021 at 20:19, Graham Johnston
>  wrote:
> 
>> I don't at this point have long term data collection compiled for the issues 
>> that we've faced. That said, we have two 100G transport links that have a 
>> regular background level of input errors at ranges that hover between 
>> 0.00055 to 0.00383 PPS on one link, and none to 0.00135 PPS (that jumped to 
>> 0.03943 PPS over the weekend). The range is often directionally associated 
>> rather than variable
> 
> On typical 100G link we do not get single FCS error in a typical day.
> However Ethernet spec still allows very high error rate of 10**-12. So
> 1 error per 1Tb (b not B). I.e. 1 error per 10s, or 0.1PPS would be
> in-spec. We see much better performance to this and vendors generally
> accept lower error rates as legitimate errors.
> 

I will confirm my experience with this at $dayjob as well.  We see interfaces 
with no errors over much longer periods of time inclusive of several of the 
technology options.  If you are seeing errors, there’s likely something wrong 
like unclean fiber or bad optic/linecard etc.

- Jared

Re: 100G, input errors and/or transceiver issues

[Graham Johnston]

Thank you all for the consensus. What I hear from you is that 100G takes
more care to operate error free, as compared to 10G, which wasn't
surprising to me. Also, that generally, we should be able to operate
without errors, or certainly less than I'm currently observing, and that
connector and transceiver interface cleanliness is our first likely point
of investigation.

Thanks to all who responded.

On Mon, 19 Jul 2021 at 12:58, Jared Mauch  wrote:

>
>
> > On Jul 19, 2021, at 1:50 PM, Saku Ytti  wrote:
> >
> > On Mon, 19 Jul 2021 at 20:19, Graham Johnston
> >  wrote:
> >
> >> I don't at this point have long term data collection compiled for the
> issues that we've faced. That said, we have two 100G transport links that
> have a regular background level of input errors at ranges that hover
> between 0.00055 to 0.00383 PPS on one link, and none to 0.00135 PPS (that
> jumped to 0.03943 PPS over the weekend). The range is often directionally
> associated rather than variable
> >
> > On typical 100G link we do not get single FCS error in a typical day.
> > However Ethernet spec still allows very high error rate of 10**-12. So
> > 1 error per 1Tb (b not B). I.e. 1 error per 10s, or 0.1PPS would be
> > in-spec. We see much better performance to this and vendors generally
> > accept lower error rates as legitimate errors.
> >
>
> I will confirm my experience with this at $dayjob as well.  We see
> interfaces with no errors over much longer periods of time inclusive of
> several of the technology options.  If you are seeing errors, there’s
> likely something wrong like unclean fiber or bad optic/linecard etc.
>
> - Jared
>
>

Re: 100G, input errors and/or transceiver issues

[Stonebraker, Jack J]

We have a moderately dense deployment of 100-Gig LR4 (Both DWDM Lambdas and 
Juniper MX) around our WAN and we don't clock any background input errors on 
our interfaces unless there is an ongoing problem.  That said, we have 
experienced issues with sub-millisecond link state changes between two 
endpoints that are physically cross connected to one another with no 
intermediary Layer 1 (DWDM, Etc.).  There doesn't seem to be rhyme or reason to 
this and we've looked at each lane extensively and so far, everything has been 
inconclusive.  We also experienced some code issues on Juniper MPC3D-NG's 
running 100-Gig's and our DWDM Client Ports where timing would start to slip 
and eventually cause the link to fail.  Both Juniper and the DWDM Vendor found 
code variances they patched.  We haven't had any such issues on Juniper MPC5's 
7's or the 10003 Line Cards.

TL;DR:  In my experience, 100-Gig might require some more TLC then 10-Gig to 
run clean and is more sensitive to variations in transport.  Other's mileage 
may vary.

Best,
JJ Stonebraker  |  Associate Director
The University of Texas System | Office of Telecommunication Services
(512) 232-0888  | j...@ots.utsystem.edu


From: NANOG  on behalf of Graham 
Johnston 
Sent: Monday, July 19, 2021 12:19 PM
To: Saku Ytti 
Cc: nanog list 
Subject: Re: 100G, input errors and/or transceiver issues

Saku,

I don't at this point have long term data collection compiled for the issues 
that we've faced. That said, we have two 100G transport links that have a 
regular background level of input errors at ranges that hover between 0.00055 
to 0.00383 PPS on one link, and none to 0.00135 PPS (that jumped to 0.03943 PPS 
over the weekend). The range is often directionally associated rather than 
variable behavior of a single direction. The data comes from the last 24 hours, 
the two referenced links are operated by different providers on very different 
paths (opposite directions). Over shorter distances, we've definitely seen 
input errors that have affected PNI connections within a datacenter as well. In 
the case of the last PNI issue, the other party swapped their transceiver, we 
didn't even physically touch our side; I note this only to express that I don't 
think this is just a case of the transceivers that we are sourcing.

Comparatively, other than clear transport system issues, I don't recall this 
sort of thing at all with 10G "wavelength" transport that we had purchased for 
years prior. I put wavelengths in quotes there knowing that it may have been a 
while since our transport was a literal wavelength as compared to being muxed 
into a 100G+ wavelength.

On Mon, 19 Jul 2021 at 12:01, Saku Ytti mailto:s...@ytti.fi>> 
wrote:
On Mon, 19 Jul 2021 at 19:47, Graham Johnston
mailto:johnston.grah...@gmail.com>> wrote:

Hey Graham,

> How commonly do other operators experience input errors with 100G interfaces?
> How often do you find that you have to change a transceiver out? Either for 
> errors or another reason.
> Do we collectively expect this to improve as 100G becomes more common and 
> production volumes increase in the future?

New rule. Share your own data before asking others to share theirs.

IN DC, SP markets 100GE has dominated the market for several years
now, so it rings odd to many at 'more common'. 112G SERDES is shipping
on the electric side, and there is nowhere more mature to go from
100GE POV. The optical side, QSFP112, is really the only thing left to
cost optimise 100GE.
We've had our share of MSA ambiguity issues with 100GE, but today
100GE looks mature to our eyes in failure rates and compatibility. 1GE
is really hard to support and 10GE is becoming problematic, in terms
of hardware procurement.


--
  ++ytti

Re: A crazy idea

[Mark Andrews]

It is theoretically possible to completely automate reverse DNS provisioning.
It just requires will to do it.  Enterprises have been doing automated reverse
DNS provisioning for decades now using DNS UPDATE requests from DHCP servers
using TSIG or GSS-TSIG.

This method does it as part of prefix delegation and provides support for
cryptographically secure updates by passing the public key as part of the
prefix delegation request.

https://www.ietf.org/archive/id/draft-andrews-dnsop-pd-reverse-02.txt

You could also just allow DNS UPDATE requests over TCP/IPv6 to add/delete NS
and DS records at the /48 level of reverse tree matching the TCP source address.
BIND has supported this for over a decade now as it was developed to provide a
mechanism to populate the 6to4 reverse zone (2.0.0.2.ip6.arpa).  It didn’t get
taken up as Geoff Huston decide to go the HTTP route.  I would have the DHCPv6
server delete the records when the prefix delegation expires.

key DHCP-SERVER {
...
};

zone 8.B.D.0.1.0.0.2.ip6.arpa {
...
update-policy {
  // limit to 10 NS records and 5 DS records.
  grant * 6to4-self . NS(10) DS(5);
  grant DHCP-SERVER subdomain *;
};
};

In both cases the customer populates the delegation and adds DS records as
required.

This is just bolting together existing technologies.

This will not take off unless ISPs buy into the mechanisms.

Mark

> On 20 Jul 2021, at 03:01, Bryan Fields  wrote:
> 
> On 7/19/21 8:09 AM, Stephen Satchell wrote:
>> First, I know this isn't the right place to propose this; need a pointer 
>> to where to propose an outlandish idea.
> 
>> What would the domain names look like?  Let's take my current IP/IPv6 
>> assignments from AT&T:
>> 
>>   2600:1700:79b0:ddc0::/64
>>   99.65.194.96/29
>> 
>> The IPv6 delegation would be easy:
>> 
>>> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-1.
>>> 0.c.d.d.0.b.9.7.0.0.7.1.0.0.6.2.ip6.arpa. NS my-DNS-server-2.
> 
> Yup, simple, I do this for my customers (and DS records).
> 
> However that reverse zone has DNSSEC on it.  You'd need a DS record to tie
> my-DNS-server-1. to the ATT DNS server and your server would need to support
> DNSSEC.  ATT may want to enforce DNSSEC on that zone, but not want to sign
> stuff they can't control.
> 
> Just playing devils advocate.
> 
> -- 
> Bryan Fields
> 
> 727-409-1194 - Voice
> http://bryanfields.net

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