Extended Deadline and Reminder OARC 39 - Call for Contribution

[John Todd]

OARC 39 will be a two-day hybrid meeting held on 22 & 23 October in 
Belgrade, Serbia at 10:00 AM (Local time - CEST (UTC+02:00)) The onsite 
part of the meeting will be colocated with RIPE 85.


The Programme Committee is seeking contributions from the community.

All DNS-related subjects and suggestions for discussion topics are 
welcome. For inspiration, we provide a non-exhaustive list of ideas:


  Operations: Any operational gotchas, lessons learned from an outage, 
details/reasons for a recent outage (how to improve TTR, tooling).

  Deployment: DNS config management and release process.
  Monitoring: Log ingestion pipeline, analytics infrastructure, anomaly 
detection.
  Scaling: DNS performance management and metrics. Increasing DNS 
Server Efficiency
  Security/Privacy: DNSSEC signing and validation, key storage, 
rollovers, qname minimization, DoH/DoT


Note: OARC 39 will be a joint conference with CENTR and abstract 
submissions from CENTR members are welcome.


As it is an hybrid workshop, we'd like to encourage brevity; 
presentations should not be longer than 20 minutes (with additional time 
for questions).


Workshop Milestones:

2022-07-30 Submissions open via Indico
2022-09-06 Deadline for submission (23:59 UTC)
2022-09-08 Preliminary list of contributions published
2022-09-20 Full agenda published
2022-10-03 Deadline for slideset submission and Rehearsal
2022-10-22 OARC 39 Workshop - Day1
2022-10-23 OARC 39 Workshop - Day2

The Registration page and details for presentation submission are 
published at:



To allow the Programme Committee to make objective assessments of 
submissions, so as to ensure the quality of the workshop, submissions 
SHOULD include slides. Draft slides are acceptable on submission.


Additional information for speakers of OARC 39
 - Your talk will be broadcast live and recorded for future reference
 - Your presentation slides will be available for delegates and others 
to download and refer to, before, during and after the meeting
 = Remote speakers have mandatory rehearsal on 2022-10-04 at 14:00 UTC. 
It would be very useful to have your slides (even if draft) ready for 
this.


Note: DNS-OARC provides registration fee waivers for the workshop to 
support those who are part of underrepresented groups to speak at and/or 
attend DNS-OARC. More details will be provided when registration opens.


If you have questions or concerns you can contact the Programme 
Committee:

https://www.dns-oarc.net/oarc/programme
via submissi...@dns-oarc.net

John Todd, for the DNS-OARC Programme Committee

OARC depends on sponsorship to fund its workshops and associated social 
events. Please contact spon...@dns-oarc.net if your organization is 
interested in becoming a sponsor.


(Please note that OARC is run on a non-profit basis, and is not in a 
position to reimburse expenses or time for speakers at its meetings.)

N86 Registration is Open + 2022 Election Cycle is Here!

[Nanog News]

*NANOG 86 Registration is Now Open! *
*Our 86th community-wide gathering is 17-19 Oct 2022*

Join us in person or virtually for our next meeting, NANOG 86!

Don't miss your chance to experience hours of ground-breaking industry
talks, legendary keynote speakers, opportunities for networking +
more. Standard registration rates are in effect until October 10th.

*REGISTER NOW * 

*2022 Election Cycle is Here!*
*Your Voice. Your Vote. Play a Role in Shaping NANOG's Future*

   - If you would like to self-nominate, verify that you are logged in with
   your NANOG Member credentials, then complete the "Candidate Nomination"
   form.
   - If you would like to nominate someone else, send their name and email
   address to nominati...@nanog.org.
   - Nominations close on 14 Sep 2022 at 11:59 pm PDT.

*LEARN MORE *


*Meet NANOG's Newest Team Member*
*A Conversation w/ Software "Craftsman" Greg Newman*

Get to know a new face at NANOG!

After 21 years of working full-time freelance, software "craftsman" Greg
Newman has joined our small but mighty team. Learn more about Greg's
background, including his incredible talent for drawing portraits and
wildlife art.

*READ NOW* 

RE: ServiceNow

[Chris Wright]

I guess now's a good time to recommend this handy site for when you'd like a 
view from the outside:

https://ping.pe

No issues at this time reaching that address from pretty much anywhere.

-

Chris


From: NANOG  On 
Behalf Of Mann, Jason via NANOG
Sent: Wednesday, August 31, 2022 1:59 AM
To: nanog@nanog.org
Subject: ServiceNow

Anyone else having issues getting to service now? We use it for ticketing: 
montana.servicenowservices.com [149.96.184.230]. Im not seeing it in our 
internet routers nor on a couple of looking glass servers.

RE: Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)

[Vasilenko Eduard via NANOG]

Such router behavior is completely legal by ND RFC.
It does not matter that real routers implementations do not do this.
We should think that they do because the standard permits it.

And the RA in the chain may be lost.
It is better to attach information about completeness to the information itself.
Eduard
-Original Message-
From: Fernando Gont [mailto:fg...@si6networks.com] 
Sent: Wednesday, August 31, 2022 4:12 PM
To: Vasilenko Eduard ; nanog@nanog.org
Subject: Re: Mitigating the effects of SLAAC renumbering events 
(draft-ietf-6man-slaac-renum)

Hi,

On 31/8/22 09:43, Vasilenko Eduard wrote:
> Hi all,
> 
> The router could split information between RAs (and send it at 
> different intervals). It may be difficult to guess what is stale and 
> what is just "not in this RA".

You ask the router, and the router responds.

If you want to consider the case where the router intentionally splits the 
options into multiple packets (which does not exist in practice), AND the link 
is super lossy, you just increase the number of retransmissions.

There's no guessing.

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494

Re: Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)

[Fernando Gont]

Hi,

On 31/8/22 09:43, Vasilenko Eduard wrote:

Hi all,

The router could split information between RAs (and send it at
different intervals). It may be difficult to guess what is stale and
what is just "not in this RA".


You ask the router, and the router responds.

If you want to consider the case where the router intentionally splits 
the options into multiple packets (which does not exist in practice), 
AND the link is super lossy, you just increase the number of 
retransmissions.


There's no guessing.

Thanks,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494

RE: Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)

[Vasilenko Eduard via NANOG]

Hi all,

The router could split information between RAs (and send it at different 
intervals).
It may be difficult to guess what is stale and what is just "not in this RA".

Fernando proposing (not documented yet in draft-ietf-6man-slaac-renum-04) 
re-asking the router by RS and using timers (size of timers is not proposed 
yet) To guess that router has probably supplied the full set of information And 
we could start concluding what is stale.

There is an alternative proposal to signal by ND flag that "this RA has the 
complete set of information"
https://datatracker.ietf.org/doc/html/draft-vv-6man-nd-prefix-robustness-02
... then you could immediately make your reliable conclusion on what is stale.

IMHO: Clear signaling that "information is complete in this RA" is better than 
guessing by timers.
It is the more robust solution.
We need to sync the state between the host and just rebooted the router.

If you have an opinion on this matter,
Please send a message to i...@ietf.org

Thanks.

Eduard
-Original Message-
From: NANOG [mailto:nanog-bounces+vasilenko.eduard=huawei@nanog.org] On 
Behalf Of Fernando Gont
Sent: Wednesday, August 31, 2022 1:35 PM
To: nanog@nanog.org
Subject: Mitigating the effects of SLAAC renumbering events 
(draft-ietf-6man-slaac-renum)

Folks,

We have been discussing the potential problems associated with SLAAC 
renumbering events for a while now -- one of the most common cases being ISPs 
rotating home prefixes, and your devices ending up with stale/invalid addresses.

We have done quite a bit of work already:

   * Problem statement: https://datatracker.ietf.org/doc/html/rfc8978
   * CPE recommendations: https://datatracker.ietf.org/doc/html/rfc9096

But there's still some work to do to address this issue: The last remaining it 
is to improve SLAAC such that hosts can more gracefully deal with this 
renumbering events.

In that light, IETF's 6man has been working on this document: 
https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-04.txt

And we have proposed a simple algorithm for SLAAC (an extension, if you
wish) that can easily help, as follows:

 If you (host) receive an RA that contains options, but not all
 of the previously-received options/information, simply send a
 unicast RS to the local-router, to verify/refresh that such missing
 information is still valid. If the information is stale, get rid of
 it.

I presented this algorithm at the last IETF meeting 
(https://youtu.be/eKEizC8xhhM?t=1308).

(You may find the slides here: 
https://datatracker.ietf.org/meeting/114/materials/slides-114-6man-improving-the-robustness-of-stateless-address-autoconfiguration-slaac-to-flash-renumbering-events-00)

Finally, I've sent draft text for the specification of the algorithm
here: 
https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/

We would be super thankful if you could take a look at the draft text (i.e.,
https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/)
and provide feedback/comments.

If you can post/comment on the 6man wg mailing list 
(https://www.ietf.org/mailman/listinfo/ipv6), that´d be fabulous.
But we'll appreciate your feedback off-line, on this list, etc. (that'd still 
be great ;-) )

Thanks in advance!

Regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494

Mitigating the effects of SLAAC renumbering events (draft-ietf-6man-slaac-renum)

[Fernando Gont]

Folks,

We have been discussing the potential problems associated with SLAAC 
renumbering events for a while now -- one of the most common cases being 
ISPs rotating home prefixes, and your devices ending up with 
stale/invalid addresses.


We have done quite a bit of work already:

  * Problem statement: https://datatracker.ietf.org/doc/html/rfc8978
  * CPE recommendations: https://datatracker.ietf.org/doc/html/rfc9096

But there's still some work to do to address this issue: The last 
remaining it is to improve SLAAC such that hosts can more gracefully 
deal with this renumbering events.


In that light, IETF's 6man has been working on this document: 
https://www.ietf.org/archive/id/draft-ietf-6man-slaac-renum-04.txt


And we have proposed a simple algorithm for SLAAC (an extension, if you 
wish) that can easily help, as follows:


If you (host) receive an RA that contains options, but not all
of the previously-received options/information, simply send a
unicast RS to the local-router, to verify/refresh that such missing
information is still valid. If the information is stale, get rid of
it.

I presented this algorithm at the last IETF meeting 
(https://youtu.be/eKEizC8xhhM?t=1308).


(You may find the slides here: 
https://datatracker.ietf.org/meeting/114/materials/slides-114-6man-improving-the-robustness-of-stateless-address-autoconfiguration-slaac-to-flash-renumbering-events-00)


Finally, I've sent draft text for the specification of the algorithm 
here: 
https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/


We would be super thankful if you could take a look at the draft text 
(i.e., 
https://mailarchive.ietf.org/arch/msg/ipv6/KD_Vpqg0NmkVXOQntVTOMlWHWwA/) 
and provide feedback/comments.


If you can post/comment on the 6man wg mailing list 
(https://www.ietf.org/mailman/listinfo/ipv6), that´d be fabulous.
But we'll appreciate your feedback off-line, on this list, etc. (that'd 
still be great ;-) )


Thanks in advance!

Regards,
--
Fernando Gont
SI6 Networks
e-mail: fg...@si6networks.com
PGP Fingerprint: F242 FF0E A804 AF81 EB10 2F07 7CA1 321D 663B B494

Re: Disney+ Contact

[Mark Tinka]

On 8/31/22 11:03, Brian Turnbow wrote:

Hi Mark


Anyone from Disney who can help with a geo issue on-list? We have customers in 
South Africa mapping to India. Thanks.

Did you try the emails in thebrotherswisp geo page?
I have had some success though the Techops emails.
Sometimes it does take a while for a response...

Disney+: E-mail them the trouble subnet at 
techops-distribut...@disneystreaming.com. Also, 
techops-servi...@disneystreaming.com will probably be where that sends you. 
Another possible email is disneyplusispsupp...@disneyplus.com


Many thanks, Brian. Most helpful.

Mark.

RE: Disney+ Contact

[Brian Turnbow via NANOG]

Hi Mark

>Anyone from Disney who can help with a geo issue on-list? We have customers in 
>South Africa mapping to India. Thanks.

Did you try the emails in thebrotherswisp geo page?
I have had some success though the Techops emails.
Sometimes it does take a while for a response...

Disney+: E-mail them the trouble subnet at 
techops-distribut...@disneystreaming.com. Also, 
techops-servi...@disneystreaming.com will probably be where that sends you. 
Another possible email is disneyplusispsupp...@disneyplus.com


Brian