Re: IPv6 Pain Experiment

Mark Andrews wrote: Actually you can do exactly the same thing for glue. KEY records below bottom of zone cut exactly the same way as you have A and below bottom of zone cut. The only difference is the zone listed in the UPDATE message. The tricky part is in converting a domain name of

Re: Update to BCP-38?

What part of BCP-38 do you think needs to be updated to support IPv6? Changing the examples to use IPv6 documentation prefixes instead of IPv4 documentation prefixes? Mark > On 3 Oct 2019, at 1:20 pm, Stephen Satchell wrote: > > Is anyone working on an update to include IPv6? -- Mark

Re: This DNS over HTTP thing

On Wed, Oct 2, 2019 at 9:13 AM Livingood, Jason wrote: > The challenge of course is that in the absence of a silver bullet > solution, that people working to combat all forms of child exploitation are > simultaneously trying several things, ranging from going to the source as > you suggest and

Re: IPv6 Pain Experiment

Actually you can do exactly the same thing for glue. KEY records below bottom of zone cut exactly the same way as you have A and below bottom of zone cut. The only difference is the zone listed in the UPDATE message. zone example.com { ... update-policy {

Update to BCP-38?

Is anyone working on an update to include IPv6?

Re: This DNS over HTTP thing

In article <6533015105f2d548812b4a445275b...@mail.dessus.com> you write: >Having unfiltered access to the malware installed by links in spam is a >self-limiting problem. Remove the DNS blocks and in >rather short order the problem will go away as all the idiots click their way >to oblivion. It

Re: IPv6 Pain Experiment

George Michaelson wrote: Personally, I choose to favour continued deployment of IPv6. With I sometimes wish I understood why SRC was the first element off the wire, and not DST, Since rational ASIC/FPGA hardware can latch early on the SRC and begin routing

Re: IPv6 Pain Experiment

Mark Andrews wrote: There is also nothing stopping machines updating their addresses in the DNS dynamically securely. Except that glue A/ can not be updated so easily and security configuration is even more painful than address configuration.

Re: IPv6 Pain Experiment

A fair comment would be "you massively mis-remember" and in both JANET-Email and IPv6 terms, I would not disagree. We're talking about things done, decisions made 35 or more years ago, to 25 years ago and my brain has had many fine beers since then. But the intent remains the same: we made

Re: IPv6 Pain Experiment

George Michaelson wrote: Could look inside beyond first header state to see DST as payload. optimisation for ICMP feels like premature optimisation. But, its semi-rational. Frag which dropped this, was going to make IP difficult for any real use anyway, not bothered by the corner-case breaks.

Re: IPv6 Pain Experiment

On Thu, Oct 3, 2019 at 12:12 PM Masataka Ohta wrote: > > George Michaelson wrote: > > Or, why we even have SRC in the header: it does not > > inform routing. > > Primarily for ICMP. Could look inside beyond first header state to see DST as payload. optimisation for ICMP feels like premature

Re: IPv6 Pain Experiment

George Michaelson wrote: > I too wish we had selected TUBA With 20B (optionally 40B) address? Basically, IPv6 is XNS IDP. https://en.wikipedia.org/wiki/Xerox_Network_Systems IDP uses Ethernet's 48-bit address as the basis for its own network addressing, generally using the machine's MAC

Re: IPv6 Pain Experiment

On Thu, Oct 3, 2019 at 11:39 AM Doug Barton wrote: > > Yes, IPv6 suffers from Second System Syndrome. No this is not news, > neither is it malleable (no matter how much whinging about roads not > taken occurs). Which is why I said: > On 10/2/19 6:30 PM, George Michaelson wrote: > > This is the

Re: IPv6 Pain Experiment

Yes, IPv6 suffers from Second System Syndrome. No this is not news, neither is it malleable (no matter how much whinging about roads not taken occurs). On 10/2/19 6:30 PM, George Michaelson wrote: A long time ago, in another country, JANET had a mail list to discuss email, in a world before

Re: IPv6 Pain Experiment

Another misconception. Humans (by and large) count in decimal, base 10. IPv4 is not that. It only LOOKS like that. In fact, the similarity to familiar decimal numbers is one of the reasons that people who are new to networking stumble early on, find CIDR challenging, etc. I do understand that

Re: IPv6 Pain Experiment

A long time ago, in another country, JANET had a mail list to discuss email, in a world before DNS. And, when DNS emerged, JANET mail list made a *deliberate* decision to make the domain order of UK email domains the reverse of every other country worldwide. A DELIBERATE decision. (I was there, on

Re: IPv6 Pain Experiment

> On 3 Oct 2019, at 10:49 am, Doug Barton wrote: > > On 10/2/19 3:03 PM, Naslund, Steve wrote: >> The next largest hurdle is trying to explain to your server guys that you >> are going to go with all dynamically assigned addressing now > > Completely false, but a very common misconception.

Re: IPv6 Pain Experiment

I disagree on that. Ipv4 is very human readable. It is numbers. Ipv6 is not human numbers. It’s hex, which is not how we normally county. It is all water under the bridge now, but I really feel like ipv6 could have been made more human friendly and ipv4 interoperable. > On Oct 2, 2019, at

Re: IPv6 Pain Experiment

On 10/2/19 3:03 PM, Naslund, Steve wrote: The next largest hurdle is trying to explain to your server guys that you are going to go with all dynamically assigned addressing now Completely false, but a very common misconception. There is nothing about IPv6 that prevents you from assigning

Re: Twilio

You’re right or course. SIP team please :) -Ben > On Oct 2, 2019, at 5:02 PM, Ross Tajvar wrote: > > They do a lot of things. It might help to specify what you're having issues > with. > >> On Wed, Oct 2, 2019, 7:51 PM Ben Cannon wrote: >> Can an engineer for Twilio please reach out to me

Re: Twilio

They do a lot of things. It might help to specify what you're having issues with. On Wed, Oct 2, 2019, 7:51 PM Ben Cannon wrote: > Can an engineer for Twilio please reach out to me off-list if possible? > Thanks. > -Ben. > > -Ben Cannon > CEO 6x7 Networks & 6x7 Telecom, LLC > b...@6by7.net > >

Twilio

Can an engineer for Twilio please reach out to me off-list if possible? Thanks. -Ben. -Ben Cannon CEO 6x7 Networks & 6x7 Telecom, LLC b...@6by7.net

RE: This DNS over HTTP thing

On Wednesday, 2 October, 2019 15:21, Jay R. Ashworth wrote: >>>HTTP/451 >> >> Completely different protocol than what the rest of this thread is >> about, much more invasive wrt possibility of logging, and requires >> a lot more infrastructure and actual lying in DNS to make work. > >Closed

Re: IPv6 Thought Experiment

On Wed, Oct 2, 2019 at 18:59 Owen DeLong wrote: > > > > On Oct 2, 2019, at 09:33 , Antonios Chariton > wrote: > > > > Dear list, > > First of all, let me apologize if this post is not allowed by the list. > To my best interpretation of the guidelines [1] it is allowed, but may be > in a gray

RE: This DNS over HTTP thing

On Wednesday, 2 October, 2019 14:52, John Levine wrote: >I think in the outside world you'll find very little support for an >argument that filtering DNS is fundamentally broken. Well, it is certainly trivial to bypass. Therefore it is a fantastic tools for tyrants and other fuckwads --

Re: IPv6 Thought Experiment

On Wed, Oct 2, 2019 at 9:33 AM Antonios Chariton wrote: > What if, globally, and starting at January 1st, 2020, someone (imagine a > government or similar, but with global reach) imposed an IPv4 tax. For > every IPv4 address on the Global Internet Routing Table, you had to pay a > tax. Let’s

Re: IPv6 Thought Experiment

> On Oct 2, 2019, at 09:33 , Antonios Chariton wrote: > > Dear list, > First of all, let me apologize if this post is not allowed by the list. To my > best interpretation of the guidelines [1] it is allowed, but may be in a gray > area due to rule #7. > > I would like to propose the

RE: This DNS over HTTP thing

On Wednesday, 2 October, 2019 10:55, Sabri Berisha wrote: >> Firefox and Chrome now reportedly use it unless you tell them not to. >Just imagine how this list would explode if BGP implementations would all >of a sudden have their default behavior changed to include auto- >negotiated MD5

RE: This DNS over HTTP thing

On Wednesday, 2 October, 2019 03:55, Tom Ivar Helbekkmo wrote: >However: because the browser cannot know for sure that the DNS traffic >is being routed over a secure channel, and browsers are being used for >all sorts of sensitive communication, it could check, and try to assist >the user.

Re: IPv6 Pain Experiment

Wouldn’t it be great if when IPv6 was designed there was some kind of automatic translation that could take place so that IPV four could go through a router that understands both IPv6 and IPV four and translate it? I’m not talking about NAT, but someway that that router could actually route

RE: IPv6 Pain Experiment

In my experience, the biggest hurdle to installing a pure IPv6 has nothing to do with network gear or network engineers. That stuff I expect to support v6. This biggest hurdle is the dumb stuff like machinery interfaces, surveillance devices, the must have IP interface on such and such of an

Re: IPv6 Pain Experiment

On Wed, 2 Oct 2019, Matt Harris wrote: I think ultimately the perception of the work required to deploy IPv6 is a much greater hurdle to IPv6 adoption than the actual work required to deploy IPv6. I'm describing my actual experience, so we'll have to disagree here. Regards, John Levine,

Re: This DNS over HTTP thing

On Wed, Oct 2, 2019 at 1:54 PM John Levine wrote: > In article <804699748.1254612.1570037049931.javamail.zim...@baylink.com> > you write: > >Tools. Are. Neutral. > > > >Any solution to a problem that involves outlawing or breaking tools will. > >Not. Solve. Your. Problem. > > I think in the

Re: IPv6 Thought Experiment

I suspect that even if there was an entity with the reach to impose such a tax, people will resort to deploying CGN more, to hide their IPv4 usage to the extent possible. That's time, money, and effort taken away from moving to IPv6. You might also find that many taxed organizations will simply

Re: This DNS over HTTP thing

- Original Message - > From: "John Levine" > In article <804699748.1254612.1570037049931.javamail.zim...@baylink.com> you > write: >>Tools. Are. Neutral. >> >>Any solution to a problem that involves outlawing or breaking tools will. >>Not. Solve. Your. Problem. > > I think in the

Re: IPv6 Pain Experiment

On Wed, Oct 2, 2019 at 3:46 PM John Levine wrote: > In article rcjz0hb1bcq2zy1hsdyosn...@mail.gmail.com> you write: > >For a small organization with limited staff and small margins, I'm curious > >where the actual burden in supporting IPv6 lies. In my experience, it's > not > >any more costly

Re: This DNS over HTTP thing

- Original Message - > From: "Niels Bakker" > To: nanog@nanog.org > Sent: Wednesday, October 2, 2019 1:42:08 PM > Subject: Re: This DNS over HTTP thing > * j...@baylink.com (Jay R. Ashworth) [Wed 02 Oct 2019, 19:30 CEST]: >>> From: "Livingood, Jason" >>> What many people dismiss as

Re: IPv6 Thought Experiment

> On Oct 2, 2019, at 4:04 PM, Nick Hilliard wrote: > > Antonios Chariton wrote on 02/10/2019 17:33: >> What if, globally, and starting at January 1st, 2020, someone (imagine a >> government or similar, but with global reach) imposed an IPv4 tax. For every >> IPv4 address on the Global

Re: IPv6 Thought Experiment

Antonios Chariton wrote on 02/10/2019 17:33: What if, globally, and starting at January 1st, 2020, someone (imagine a government or similar, but with global reach) imposed an IPv4 tax. For every IPv4 address on the Global Internet Routing Table, you had to pay a tax. Let’s assume that this can

Re: Friendly contact at Comcast about possible RF leaks

> On Sep 30, 2019, at 8:38 PM, Brandon Martin wrote: > > Anyone know a friendly contact at Comcast regarding possible RF leaks on > their HFC plant? I'm not a Comcast customer, so I can't get in via front > line support (not that it would probably do me much good, anyway), and I'm > not

Re: This DNS over HTTP thing

In article <804699748.1254612.1570037049931.javamail.zim...@baylink.com> you write: >Tools. Are. Neutral. > >Any solution to a problem that involves outlawing or breaking tools will. >Not. Solve. Your. Problem. I think in the outside world you'll find very little support for an argument that

Re: IPv6 Pain Experiment

In article you write: >For a small organization with limited staff and small margins, I'm curious >where the actual burden in supporting IPv6 lies. In my experience, it's not >any more costly than deploying IPv4 is ... Right, but that means it doubles your deployment costs since IPv4 isn't

Re: IPv6 Thought Experiment

-- “MUST NOT support IPv4”.. I think a good start would be: "MUST support IPv6"! --- Woah, there! Hold your horses. It's only been 20-something years. You can't expect these things to happen overnight! >;-) scott

Re: This DNS over HTTP thing

Livingood, Jason wrote: The challenge of course is that in the absence of a silver bullet solution, that people working to combat all forms of childsorship exploitation are simultaneously trying several things, ranging from going to the source as you suggest and arresting people, to trying to

Re: IPv6 Thought Experiment

> And for bonus points, consider the following: what if all certification > bodies of equipment, for certifications like FCC’s or CE in Europe, for > applications after Jan 1st 2023 would include a “MUST NOT support IPv4”.. I think a good start would be: "MUST support IPv6"!

Re: IPv6 Thought Experiment

On 10/2/19 9:33 AM, Antonios Chariton wrote: > Dear list, > First of all, let me apologize if this post is not allowed by the > list. To my best interpretation of the guidelines [1] it is allowed, but > may be in a gray area due to rule #7. > > I would like to propose the following thought

Re: This DNS over HTTP thing

    Well, 1 think for sure.     An application bypassing the OS and auto deciding where to resolve an address will break our DNS views for private versus public resolution of the same hostname.  I see fun times to be had in the Security world...     At least make it optional, not enabled by

Re: This DNS over HTTP thing

* j...@baylink.com (Jay R. Ashworth) [Wed 02 Oct 2019, 19:30 CEST]: From: "Livingood, Jason" What many people dismiss as 'lying' would be typically described as 'complying with the law' in certain countries. It is unfortunate that operators in countries with legally-mandated DNS blocks are

Re: IPv6 Thought Experiment

> On 2 Oct 2019, at 20:23, John Levine wrote: > > In article <5dcae7a8-1d33-4ea2-bbb1-7a3e8132d...@gmail.com> you write: >> What do you think would happen? Would it be the only way to reach 100% IPv6 >> deployment, or even that wouldn’t be sufficient? > > If you have to impose an artificial

RE: IPv6 Thought Experiment

It's certainly financial but it's not just companies being cheap. For example for smaller companies with a limited staff and small margins. They may want to have v6 everywhere but lack the resources to do it. It would for certain speed up the process but there would be collateral damage in the

Re: This DNS over HTTP thing

- Original Message - > From: "Livingood, Jason" > On 10/1/19, 3:44 AM, "NANOG on behalf of Stephane Bortzmeyer" > wrote: >> Note that the UK is probably the country in Europe with the biggest >use of lying DNS resolvers for censorship. > > What many people dismiss as 'lying' would

Re: This DNS over HTTP thing

- Original Message - > From: "Livingood, Jason" > The challenge of course is that in the absence of a silver bullet solution, > that > people working to combat all forms of child exploitation are simultaneously > trying several things, ranging from going to the source as you suggest and

Re: IPv6 Thought Experiment

In article <5dcae7a8-1d33-4ea2-bbb1-7a3e8132d...@gmail.com> you write: >What do you think would happen? Would it be the only way to reach 100% IPv6 >deployment, or even that wouldn’t be sufficient? If you have to impose an artificial tax to force people to use IPv6, you've clearly admitted that

Re: Spectrum (Charter) Fragmented UDP

Hi Phil, Contact me off list with the locations impacted and I will look into it. Jim On 10/2/19, 7:00 AM, "NANOG on behalf of Phil Lavin" wrote: > While we can say this should just work, the reality is, it's not very reliably true and I would not build product or business on the

RE: IPv6 Thought Experiment

A few thoughts: 1. What global organization has the ability to impose a tax on any nation’s citizens? 2. Do you not see an issue with making everyone worldwide get rid of every device that supports v4? Kind of a burden for a developing country, no? Also, a bit of an e-waste

Re: This DNS over HTTP thing

In article <146431.1569964368@turing-police> you write: >-=-=-=-=-=- > >On Tue, 01 Oct 2019 16:24:30 -0400, Warren Kumari said: > >> "More concretely, the experiment in Chrome 78 will **check if the >> user’s current DNS provider** is among a list of DoH-compatible >> providers, and upgrade to the

Re: IPv6 Thought Experiment

On Wed, Oct 2, 2019 at 11:48 AM Dovid Bender wrote: > Antonios, > > It's certainly financial but it's not just companies being cheap. For > example for smaller companies with a limited staff and small margins. They > may want to have v6 everywhere but lack the resources to do it. It would > for

Re: This DNS over HTTP thing

- On Sep 30, 2019, at 8:46 PM, Fred Baker fredbaker.i...@gmail.com wrote: > Firefox and Chrome now reportedly use it unless you tell them not to. Just imagine how this list would explode if BGP implementations would all of a sudden have their default behavior changed to include

Re: IPv6 Thought Experiment

On Wed, Oct 2, 2019 at 11:33 AM Antonios Chariton wrote: > Dear list, > First of all, let me apologize if this post is not allowed by the list. To > my best interpretation of the guidelines [1] it is allowed, but may be in a > gray area due to rule #7. > > I would like to propose the following

Re: IPv6 Thought Experiment

Let me clarify that I 100% agree with both Job and Dovid. It is indeed a terrible idea. And not everyone is even convinced IPv6 is the right next step. So it’s obviously wrong to push people towards where someone thinks, even if it’s the majority. I just had a hunch that even then we would

Re: IPv6 Thought Experiment

It appears in your thought experiment, a stick is dressed up like a carrot. I’m not a fan of deploying purely punitive strategies to promote adoption; technologies should stand on their own and be able to convince the potential users based on their merit, not based on penalties.

Re: IPv6 Thought Experiment

Antonios, It's certainly financial but it's not just companies being cheap. For example for smaller companies with a limited staff and small margins. They may want to have v6 everywhere but lack the resources to do it. It would for certain speed up the process but there would be collateral damage

Re: This DNS over HTTP thing

Damian Menscher via NANOG writes: > "This experiment will be done in collaboration with DNS providers who > already support DoH, with the goal of improving our mutual users’ > security and privacy by upgrading them to the DoH version of their > current DNS service. With our approach, the DNS

Re: This DNS over HTTP thing

The thing is: People were conditioned for years to look for the padlock, because padlock means secure. How will we ever get this out of their minds.. Jan SMTP: j...@philippi.pw XMPP: j...@himbeere.pw GPG: 45F3 2DF0 4D55 C4B4 2083 14C5 5727 D54F *E4E2 2A3C* Am 02.10.19 um 11:45 schrieb Valdis

Re: Optical training

Thank you everyone for your input. Certainly will look into the links provided. Regards, James Virus-free. www.avast.com

Re: IPv6 Thought Experiment

To clarify that further, this would be a monthly tax. So $2 / month. > On 2 Oct 2019, at 19:33, Antonios Chariton wrote: > > Dear list, > First of all, let me apologize if this post is not allowed by the list. To my > best interpretation of the guidelines [1] it is allowed, but may be in a

IPv6 Thought Experiment

Dear list, First of all, let me apologize if this post is not allowed by the list. To my best interpretation of the guidelines [1] it is allowed, but may be in a gray area due to rule #7. I would like to propose the following thought experiment about IPv6, and I would like your opinion on

Re: This DNS over HTTP thing

The challenge of course is that in the absence of a silver bullet solution, that people working to combat all forms of child exploitation are simultaneously trying several things, ranging from going to the source as you suggest and arresting people, to trying to interrupt the online tools that

Re: This DNS over HTTP thing

On 10/1/19, 3:44 AM, "NANOG on behalf of Stephane Bortzmeyer" wrote: > Note that the UK is probably the country in Europe with the biggest use of lying DNS resolvers for censorship. What many people dismiss as 'lying' would be typically described as 'complying with the law' in certain

Re: Optical training

Hello All:I held an OSP Engineer and Design certificate from the below trainers. Excellent training and it's hands on. Light Brigade Fiber Optic Training | | | | || | | | | | Light Brigade Fiber Optic Training Fiber Optic Training - Light Brigade offers fiber optic

OARC 31 Agenda Published ; OARC32 CfP!

Note for the record: I am not actually Keith, nor do I play Keith on TV. -- Dear colleagues, The agenda for the 31st DNS-OARC Workshop has now been published at: OARC 31 takes place at the JW Marriott Austin, in Texas, USA on October 31st and November

Re: Spectrum (Charter) Fragmented UDP

Wait till STIR/SHAKEN is enabled. Were going to see real quickly who isn't handling fragmentation correctly... On Wed, Oct 2, 2019 at 8:34 AM Saku Ytti wrote: > Hey Phil, > > > At some point over night on 30th September (i.e. the night going into > 1st October), we saw a number of Spectrum

Re: Spectrum (Charter) Fragmented UDP

hey, I don't know anything specific to this case, but you'd serve your best interest to send small enough packets that do not need fragmentation, particularly in the backbone. In this case the SIP invite is already sent fragmented from the source and no fragmentation is required in transit.

RE: Spectrum (Charter) Fragmented UDP

> While we can say this should just work, the reality is, it's not very > reliably true and I would not build product or business on the assumption > that it works well. Yup. Understood. We can't get away from sending multi-packet messages. We try our best to keep SIP messages as small as

Re: Spectrum (Charter) Fragmented UDP

Hey Phil, > At some point over night on 30th September (i.e. the night going into 1st > October), we saw a number of Spectrum (Charter) customers stop handling > fragmented UDP packets. This has manifested itself in such that the phones of > affected customers are no longer receiving UDP SIP

Spectrum (Charter) Fragmented UDP

At some point over night on 30th September (i.e. the night going into 1st October), we saw a number of Spectrum (Charter) customers stop handling fragmented UDP packets. This has manifested itself in such that the phones of affected customers are no longer receiving UDP SIP INVITE packets which

Re: This DNS over HTTP thing

* nanog@nanog.org (Damian Menscher via NANOG) [Tue 01 Oct 2019, 23:04 CEST]: Should be obvious to non-trolls that I was referring to Google changing the default nameserver *in Chrome*, as obviously Google doesn't have root access to change it on the host. Funny because just last week there

RE: This DNS over HTTP thing

>From a corporate standpoint, this is exactly correct. There are also some >regulatory issues involved (FINRA, SEC, etc...) We are required to block access to web based email (gmail, etc...) in our corporate network (please don't ask why, ours is not to reason why...), so every method to

Re: This DNS over HTTP thing

On Wed, Oct 02, 2019 at 05:45:57AM -0400, Valdis Klētnieks wrote: > On Wed, 02 Oct 2019 01:55:13 -0600, "Keith Medcalf" said: > > It is a common fallacy that TLS connections are authenticated. The vast > > majority of them are not authenticated in any meaningful fashion and all > > that > > can

Re: This DNS over HTTP thing

On Wed, 02 Oct 2019 01:55:13 -0600, "Keith Medcalf" said: > It is a common fallacy that TLS connections are authenticated. The vast > majority of them are not authenticated in any meaningful fashion and all that > can be said about TLS is that it provides an encrypted connection between the >

RE: This DNS over HTTP thing

On Tuesday, 1 October, 2019 22:15, David Conrad wrote: >DoH (and DoT) encrypt (and authenticate) the application <-> recursive >resolver channel (NOT the DNS data) which I gather some view as an attack >vector. Actually no. DoH and DoT encrypt the application <-> recursive resolver