Re: who runs the root, Cogent-TATA peering dispute?

[David Conrad via NANOG]

Oops.  Missed a (significant) word.

On May 19, 2024, at 3:02 PM, David Conrad via NANOG  wrote:
> On May 19, 2024, at 1:12 PM, Bryan Fields  wrote:
>> Suppose the community wanted to change this or make a formal policy on root
>> server hosting requirements.  Where would this be done?  Could a party submit
>> a proposal to ICANN via the policy development process?  If not where should
>> the community start this?
> 
> That’s exactly what the Root Server System Governance Working Group 
> (https://community.icann.org/pages/viewpage.action?pageId=120820189) is 
> trying to figure out.  As John has noted, it has been going on for 6+ years 
> now.  See RSSAC-037 
> (https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) and 
> RSSAC-058 
> (https://www.icann.org/en/system/files/files/rssac-058-17nov21-en.pdf).  In 
> the past, the IETF has issued RFCs on the topic (RFCs 2010, 2870, and 7720) 
> and the root server operators have made various commitments related to 
> “service expectations” documented in ICANN's RSSAC document series 
> (https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf),
>  but as has been pointed out, those commitments are contractual or otherwise 
> binding obligations.

“… are NOT contractual or otherwise binding obligations.”

Regards,
-drc



signature.asc
Description: OpenPGP digital signature

Re: who runs the root, Cogent-TATA peering dispute?

[David Conrad via NANOG]

On May 19, 2024, at 1:12 PM, Bryan Fields  wrote:
> Suppose the community wanted to change this or make a formal policy on root
> server hosting requirements.  Where would this be done?  Could a party submit
> a proposal to ICANN via the policy development process?  If not where should
> the community start this?

That’s exactly what the Root Server System Governance Working Group 
(https://community.icann.org/pages/viewpage.action?pageId=120820189) is trying 
to figure out.  As John has noted, it has been going on for 6+ years now.  See 
RSSAC-037 
(https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) and 
RSSAC-058 
(https://www.icann.org/en/system/files/files/rssac-058-17nov21-en.pdf).  In the 
past, the IETF has issued RFCs on the topic (RFCs 2010, 2870, and 7720) and the 
root server operators have made various commitments related to “service 
expectations” documented in ICANN's RSSAC document series 
(https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf),
 but as has been pointed out, those commitments are contractual or otherwise 
binding obligations.

Regards,
-drc



signature.asc
Description: OpenPGP digital signature

Re: who runs the root, Cogent-TATA peering dispute?

[David Conrad via NANOG]

John,

On May 19, 2024, at 12:53 PM, John R. Levine  wrote:
> On Sun, 19 May 2024, David Conrad wrote:
>>> They provide this to Verisign, the Root Zone Maintainer, who create the
>>> root zone and distribute it to the root server operators.
>> 
>> Technically, IANA provides database change requests to Verisign. The actual 
>> database is maintained by the Root Zone Maintainer (hence the name).
> 
> Good point.
> 
> In any event, I think we agree that none of IANA, ICANN, and/or Verisign
> has the authority to remove one of the root operators, no matter how much
> someone might dislike their peering policies.

Yes. While technically, there is the capability (they are, after all merely 
entries in a database that get dumped into a file), the question of authority 
(ignoring court order) is less clear cut and certainly does not reside in ICANN 
org, PTI, or Verisign.

Regards,
-drc



signature.asc
Description: OpenPGP digital signature

Re: Cogent-TATA peering dispute?

[David Conrad via NANOG]

On May 17, 2024, at 10:14 PM, Bill Woodcock  wrote:
>> On May 18, 2024, at 02:30, William Herrin  wrote:
>> So Cogent operates a root server because they bought PSI who ran a
>> root server and ICANN has never chosen to throw down the gauntlet.
> 
> As John said, ICANN has nothing to do with who runs root servers.  

Wrong in 2 ways:

1) ICANN runs one of root servers.
2) https://community.icann.org/pages/viewpage.action?pageId=120820189

> Last I knew, NTIA still believed that NTIA selects the root server operators.

I doubt even NTIA would _ever_ have said this, and certainly not since the IANA 
Functions transition. This is simply not how the relationship between NTIA and 
ICANN operated (pre-transition, after transition it is even less).

>  Eventually the last person at NTIA who still knows what that means will 
> retire, and then nobody in the USG will believe that they have 
> responsibility.  Then, ICANN lawyers will presumably start insinuating that, 
> actually, ICANN can do what it wants there.  Which they’ve already laid the 
> groundwork for by failing to reassign the L-root nameserver for the last 
> twenty-two years.  Not a task that should take twenty-two years, in my 
> opinion…  CGI is perfectly capable, and there are no root servers 
> administered in the southern hemisphere.  State and Commerce were considering 
> reassigning it as an apology for the Rousseff spying incident in 2013, but 
> they didn’t quite get it together to act.

Interesting theory.

Regards,
-drc



signature.asc
Description: OpenPGP digital signature

Re: who runs the root, Cogent-TATA peering dispute?

[David Conrad via NANOG]

John,

On May 17, 2024, at 6:53 PM, John R. Levine  wrote:
> ICANN as the IANA Functions Operator maintains the database of TLD info.

Sort of.

> They provide this to Verisign, the Root Zone Maintainer, who create the
> root zone and distribute it to the root server operators.  

Technically, IANA provides database change requests to Verisign. The actual 
database is maintained by the Root Zone Maintainer (hence the name).

> Verisign does
> this under a contract with NTIA, one of the few bits of the Internet that
> is still under a US government contract:
> 
> https://www.ntia.gov/page/verisign-cooperative-agreement

Err, no.  You forgot the little bit about the IANA Functions transition.  
Specifically:

https://www.icann.org/en/stewardship-implementation/root-zone-maintainer-agreement-rzma

> Should ICANN attempt to mess with the distribution of the root zone, let
> us just say that the results would not be pretty.  There's a balance of
> terror here.  ICANN carefully never does anything that would make the root
> server operators say no, and the root server operators carefully avoid
> putting ICANN in a position where they might have to do that.

When you say “ICANN” who, exactly, do you mean?  ICANN the organization or 
ICANN the community?  If the former, ICANN Org can’t do anything outside of 
ICANN community defined policy or process or risk all sorts of unpleasantness 
from internal policies to lawsuits to the ICANN Board being spilled.  If you 
mean the latter, ICANN org must abide by the ICANN community’s demands or you 
get to the same point as previously mentioned.  That’s the whole point behind 
the “Empowered Community."

> I'm not guessing here, I go to ICANN meetings and talk to these people.

And I was one of the ICANN people involved in the negotiations with Verisign on 
the RZMA.

Regards,
-drc



signature.asc
Description: OpenPGP digital signature

Re: The Reg does 240/4

[David Conrad]

Christopher,

On Feb 14, 2024, at 4:49 AM, Christopher Hawker  wrote:
> I agree with the fact that introducing this space has the very real risk of 
> it being obtained by the highest bidder. Perhaps I may be naive in believing 
> that we have a possible chance to delegate this space wisely and prevent it 
> from being exhausted at a rather rapid rate, however I can only hope that 
> people will see the potential benefit that this could bring, and policy not 
> being changed to benefit the larger players in the space.
> 
> IP resources were never intended to become a commodity, rather a tool that 
> allowed people to globally connect.

You’re mixing agendas. In earlier messages, you had argued the address space 
should be provided to "new entrants.” However, if IP resource were intended to 
be a tool that allows people to globally connect, then the age/size/previous 
holdings of the organization obtaining the address space shouldn’t matter: what 
matters is whether it is used for connectivity.  Indeed, if you want to 
facilitate the greatest amount of connectivity, it can be (and has been) argued 
the allocations should be made to the larger players since they have more 
resources to put the address space into use, greater reach, larger marketing 
departments, etc. 

(These are the same arguments made at various RIR policy meetings prior to 
runout any time anyone suggested limitations on IPv4 address allocations. The 
nice thing about history repeating itself is that you know when to go out and 
get popcorn.)

> It should never have become a commodity, and it's a shame that it is being 
> treated as such with a price tag put on it.

I suspect any limited resource with unlimited demand is going to end up here. 
You’re arguing against markets. Good luck with that.

Regards,
-drc

Re: The Reg does 240/4

[David Conrad]

Christopher,

On Feb 13, 2024, at 4:14 PM, Christopher Hawker  wrote:
> This is a second chance to purposefully ration out a finite resource.

Perhaps I’m overly cynical, but other than more players and _way_ more money, 
the dynamics of [limited resource, unlimited demand] don’t appear to have 
changed significantly from the first time around. However, I suspect the real 
roadblock you’ll face in policy discussions (aside from the folks who make 
their money leasing IPv4 addresses) is the argument that efforts to ration and 
thereby extend the life of IPv4 will continue to distort the market and impede 
the only useful signal to network operators regarding the costs of remaining 
with IPv4 compared to supporting IPv6.  Good luck!

Regards,
-drc

Re: The Reg does 240/4

[David Conrad]

Christopher,

On Feb 13, 2024, at 2:15 PM, Christopher Hawker  wrote:
> Let's not think about ourselves for a moment, and think about the potential 
> positive impact that this could bring.


Let’s assume that the class E checks in all IP stacks and application code that 
do or can connect to the Internet are magically removed (not going to argue 
feasibility of this) and control of 240/4 is put into the hands of IANA to 
allocate to the RIRs. Subsequent steps would be:

1. RIRs, following 
https://www.icann.org/resources/pages/allocation-ipv4-rirs-2012-02-25-en, would 
request new /8s, and receive those allocations.
2. Entities[*] with pent up demand would submit requests and have those 
requests filled by the RIRs
3. While more /8s in 240/4 remain, go to step 1
4. Return to status quo ante.

In other words, while the IANA free pool is not (again) empty, network 
operators would be able to get IPv4 address space at a fraction of the market 
price, and then we’d go back to the way things are now.

This suggests the length of time the primary benefit (cheap IPv4 addresses) 
would be enjoyed depends on RIR allocation policies.  ISTR a comment from you 
earlier suggesting that based on current consumption rates, 240/4 would fulfill 
needs for 50 years.  However, this appears to assume that current “soft 
landing” (etc) policies would remain in place.  Why would you assume that?  I 
would imagine there would be non-trivial pressure from the RIR memberships to 
return to the pre-runout policy regime which was burning through multiple /8s 
in months. In particular, I’d think the large scale buyers of address space (as 
well as IP market speculators) who tend to be the most active in RIR policy 
forums would jump at the opportunity to get “huge tracts of land” at bargain 
basement prices again.

This doesn’t seem all that positive to me, particularly because it’s temporary 
since the underlying problem (limited resource, unlimited demand) cannot be 
addressed.  What positive impact do you predict?

Thanks,
-drc
* I’ve purposefully ignored the geopolitical aspect of this here. In reality, I 
suspect there would be pressure for ‘entities’ to include countries, etc.

Legal system as a weapon (was Re: AFRINIC placed in receivership)

[David Conrad]

Somewhat related (at least one of the principals is the same) and perhaps of 
interest to some here. While I have strong opinions on the topic, provided 
without comment:

https://www.gofundme.com/f/supporting-and-protecting-internet-governance

Regards,
-drc

> On Sep 13, 2023, at 6:27 PM, Bryan Fields  wrote:
> 
> I think this qualifies as potentially operational.
> 
> Afrinic placed in receivership, board elections to be held in six months:
> https://archive.ph/jOFE4
> --
> Bryan Fields
> 
> 727-409-1194 - Voice
> http://bryanfields.net



signature.asc
Description: Message signed with OpenPGP

Re: New addresses for b.root-servers.net

[David Conrad]

On Jun 15, 2023, at 10:51 PM, Wes Hardaker  wrote:
>> At some point, somebody's going to want to do something with the old /24.
> You are correct that we did not state we will or will not be returning
> the address block we have back to ARIN.  We do not plan on returning it
> for precisely the reasons you've specified.

Long ago, I had suggested that given the peculiar and unique nature or root 
server addresses and their critical sensitivity that their addresses be treated 
as protocol parameters, i.e., that root service was fixed to those addresses by 
protocol specification.  People asked if I had been touched by the Bad Idea 
Fairy (RIP).  I still think it’s a good idea… :)

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[David Conrad]

Joe,

On Nov 21, 2022, at 4:30 PM, Joe Maimon  wrote:
> As I and others have pointed out, it depends on how it is used.

Sure, and with enough thrust and an appropriate trajectory, pigs fly quite 
well, although the landing can get messy.  With enough constraints, any problem 
becomes trivially solvable. Whether it is a useful problem to solve is the 
question.

> And perhaps the attempt should be made regardless of knowing in advance which 
> it will be.

You’ll get no argument from me. In the past, I’ve suggested a Cloudflare 
1.1.1.1-like experiment would provide useful data.

> You can hardly attempt to convince anybody that 240/4 as unicast would not be 
> the more trivial change made in any of these products natural life cycle 
> points.


How trivial would the change be in a product by a company that no longer exists 
or a product line that is no longer supported? Will Microsoft update all 
previous versions of Windows?  Will the myriad of deployed embedded systems 
sitting forgotten in closets be updated? And if you’re going to the trouble to 
update those systems (in most cases, by simply throwing them away), why not 
upgrade to IPv6+IPv4aaS?

> Especially as we have examples of what that type of effort might look like.

Again, the issue isn’t fixing a bit of code in a known source tree. It is 
getting all the instantiations of that bit of code implemented, tested, and 
deployed across all the myriad supported and unsupported systems (both 
operational and management) that support 5 billion+ Internet users globally in 
a timeframe and for a cost that makes business sense.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Alternative Re: ipv4/25s and above Re: 202211201009.AYC

[David Conrad]

Barry,

On Nov 21, 2022, at 3:01 PM, b...@theworld.com wrote:
> We've been trying to get people to adopt IPv6 widely for 30 years with very 
> limited success

According to https://www.google.com/intl/en/ipv6/statistics.html, it looks like 
we’ve gone from ~0% to ~40% in 12 years. https://stats.labs.apnic.net/ipv6 has 
it around 30%. Given an Internet population of about 5B, this can 
(simplistically and wrongly) argued to mean 1.5-2B people are using IPv6. For a 
transition to a technology that the vast majority of people who pay the bills 
will neither notice nor care about, and for which the business case typically 
needs projection way past the normal quarterly focus of shareholders, that 
seems pretty successful to me.

But back to the latest proposal to rearrange deck chairs on the IPv4 Titanic, 
the fundamental and obvious flaw is the assertion of "commenting out one line 
code”. There isn’t “one line of code”. There are literally _billions_ of 
instances of “one line of code”, the vast majority of which need to be 
changed/deployed/tested with absolutely no business case to do so that isn’t 
better met with deploying IPv6+IPv4aaS. I believe this has been pointed out 
numerous times, but it falls on deaf ears, so the discussion gets a bit tedious.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: any dangers of filtering every /24 on full internet table to preserve FIB space ?

[David Conrad]

Andrey,

On Oct 12, 2022, at 7:54 AM, Andrey Kostin  wrote:
>> My point is that it's not a feature of BGP, it's a purely human convention, 
>> arrived at through the intersection of pain and laziness. There's nothing 
>> inherently "right" or "wrong" about where the line was drawn, so for 
>> networks to decide that /24 is causing too much pain, and moving the line to 
>> /23 is no more "right" or "wong" than drawing the line at /24.  A network 
>> that *counts* on its non-connected sites being reachable because they're 
>> over a mythical /24 limit is no more right than a customer upset that their 
>> /25 announcements aren't being listened to.
> 
> IMO this line wasn't arbitrary, it was (and it still is) a smallest possible 
> network size allocated by RIRs.

There was a period in the mid- to late-90s where some of RIRs allocated longer 
than /24s, i.e., to match the amount of address space justified by the 
requester, even if that meant (say) a /29. This didn’t last very long as one of 
the (at the time) 800 lb gorillas (Sprint) decided to start filtering at /19 
(which IIRC was the default prefix length RIPE-NCC chose to allocate to LIRs) 
to keep their routers from falling over.

In this context, any prefix length, including /24, is arbitrary. Today, 
filtering on /24 will probably drop some number of perfectly valid and perhaps 
better routes to specific destinations (I’m too lazy to look to see). That’s 
fine as long as there is some covering route that allows the traffic to get 
from here to there. It feels to me like the responsibility should be on the 
announcer to ensure there is some covering less-specific for stuff that has "a 
good chance" of being filtered.

> So it's just a common sense to receive everything down to /24 to have the 
> complete data about all Internet participants.


Given infinite resources, sure. However, I believe the issue here, as it was in 
the mid- to late-90s, is hardware limitations. Having a partial view with 
(potentially) non-optimal less specifics is better than having your routers 
fall over.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: ICANN

[David Conrad]

On Jul 8, 2022, at 8:21 AM, Keith Medcalf  wrote:
> Does anyone have contact information (or address for service of legal
> documents) for ICANN?

https://www.icann.org/locations? 

> There web site does not appear to contain contact
> information.

Sure it does.  If nothing else, at the bottom of that page, it points to the 
Global Support Center (a link to 
https://www.icann.org/resources/pages/customer-support-2015-06-22-en 
)

> ICANN apparently promulgates a policy which requires clickage on spam
> links in e-mail.

I’m guessing you’re talking about one or more of 
https://www.icann.org/resources/pages/contact-verification-2013-05-03-en 
, 
probably WDRP.   There is a FAQ on that: 
https://www.icann.org/resources/pages/faqs-f0-2012-02-25-en 
.

> I intend to sue them for trillions of dollars for this policy.

Have fun.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: [EXTERNAL] FCC proposes higher speed goals (100/20 Mbps) for USF providers

[David Conrad]

Hi,

> On Jun 7, 2022, at 8:54 AM, Livingood, Jason via NANOG  
> wrote:
>> I think peak demand should be flattening in the past year? There’s only so 
>> much 4k video to consume, so many big games to download?
> I doubt it - demand continues to grow at a pretty normal year-over-year rate 
> and has been doing so for 25+ years. I don't see that sort of trajectory 
> changing.

I’m with Jason. If even a small percentage of the “representative use cases” 
that came out of the ITU’s Network 2030 Focus Group or other similar efforts 
comes to pass, bandwidth demand will continue to grow.

Regards,
-drc


signature.asc
Description: Message signed with OpenPGP

Re: Question re prevention of enumeration with DNSSEC (NSEC3, etc.)

[David Conrad]

Max,

On May 23, 2022, at 9:12 AM, Max Tulyev  wrote:
> 11.05.22 15:31, Masataka Ohta пише:
>> There are various ways, such as crawling the web, to enumerate
>> domain names.
> 
> Come on, web is dying! People are moving to mobile applications!
> So more and more domains do not need any web site by design.

An interesting assertion. I’ve heard similar statements since about 2005.  Not 
disagreeing (haven’t looked at stats in a while), but what data are you basing 
this upon?  How does this correlate with the proliferation of blockchain-based 
squatted TLDs (e.g., unstoppable domains, handshake, etc.)?

Thanks,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: V6 still widely supported (was Re: CC: s to Non List Members,

[David Conrad]

On Mar 11, 2022, at 12:20 PM, John Levine  wrote:
> It appears that Joe Maimon  said:
>> higher penetration of native v6, I would restate that a bit more
>> conservatively as
>> 
>> Google's statistics are likely a fair barometer for USA usage in the
>> large content provider arena which have a strong mobile representation.
> 
> AT, Comcast, and Charter/Spectrum, the three largest cable companies, have 
> IPv6
> support.

As do (so I hear) mobile providers, which is increasingly how people around the 
world get access to the Internet.

However, this discussion has drifted a bit — it wasn’t (supposed to be) a 
discussion about IPv6 deployment per se, but rather network operations reality 
as they impact IPv6 deployment.

There was an assertion (that I am not questioning) that there are various kit 
vendors who claim IPv6 support, but when network operators attempt to deploy 
that kit, the IPv6 support is found to be show-stoppingly buggy, lacking in 
required features, or otherwise causing said network operators 
frustration/irritation/etc and/or to give up on deploying IPv6 “until it is 
more mature” (or “more/any customers demand it”).

For whatever reason, there appears to be a reluctance to name names in such 
cases. My question was whether it might be helpful in encouraging IPv6 
deployment (or at least reducing the amount of disappointment) for network 
operators to be more public when reality does not match vendor claims, just as 
“timed full disclosure” has helped in addressing (some) security-related issues.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Making Use of 240/4 NetBlock

[David Conrad]

John,

On Mar 9, 2022, at 10:48 AM, John Kristoff  wrote:
> Isn't this essentially the same thing as the DNS name collision problem
> ICANN has been studying and discussing?

Not really (IMHO).  As mentioned to Mr. Levine, what ICANN is concerned about 
is really the security/stability implications of delegating previously 
undelegated but otherwise unconstrained name space, not name space that has 
been designated with “for future use” status.  That designation has resulted in 
code that prohibits its use and to make use of 240/4, the code has to be fixed. 
 The name collision problem ICANN is studying is the result of traffic hitting 
the root for names like CORP and HOME. As far as I know (which isn’t very far), 
240/4 isn’t sourcing or sinking significant traffic on the Internet.

Regards,
-drc





signature.asc
Description: Message signed with OpenPGP

Re: Making Use of 240/4 NetBlock

[David Conrad]

John,

On Mar 9, 2022, at 10:45 AM, John Levine  wrote:
>> When did squatting become a justification for not allocating addresses?
> Um, when can I register my .corp and .home domains?

Um, are you suggesting there is sufficiently heavy use of 240/4 to result in a 
significant security/stability issue if the address space is allocated?  I 
thought you were arguing too many systems would have to be updated to even 
send/receive packets with 240/4 in the source or destination field.

You’re equating the use of address space explicitly reserved “for future use” 
(or for multicast use) with unallocated name space. A more reasonable (but 
still flawed) analogy to .corp and .home would be the squatting on 1/8. I was 
at IANA when we allocated 1/8 to APNIC and recall the gnashing of teeth that 
resulted. Yet we have a demonstration proof that 1/8 could be made usable.

I don’t really have a dog in this fight and my intuition suggests that trying 
to make 240/4 global unicast wouldn’t be worth the effort, but I remain of the 
belief that it would be better to have actual data on what breaks if there was 
an attempt to use it than to come up with specious arguments like “but it might 
annoy squatters”.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Making Use of 240/4 NetBlock

[David Conrad]

On Mar 9, 2022, at 10:08 AM, John R. Levine  wrote:
> On Wed, 9 Mar 2022, John Gilmore wrote:
>> Major networks are already squatting on the space internally, because they 
>> tried it and it works.
> Sounds like an excellent reason not to try to use it for global unicast.

When did squatting become a justification for not allocating addresses?

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP

V6 still not supported (was Re: CC: s to Non List Members (was Re: 202203080924.AYC Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock))

[David Conrad]

Tim,

On Mar 9, 2022, at 9:09 AM, Tim Howe  wrote:
> Some of our biggest vendors who have supposedly supported
> v6 for over a decade have rudimentary, show-stopping bugs.

Not disagreeing (and not picking on you), but despite hearing this with some 
frequency, I haven’t seen much data to corroborate these sorts of statements.

>   A subset of these vendors will listen to you and fix the
> problems.  Give them your support and loyalty.  I want to name names so
> bad…


Perhaps the right approach would be similar for network operators to move to a 
timed full disclosure model (like Google’s Project Zero for security issues)?  
In the software security world, this model seems to have had a positive impact 
in getting fixes out. If a vendor who claims v6 support doesn’t actually 
support v6 (or, if a vendor fixes a known lack of v6 support), it would seem to 
me that this is information that folks on NANOG (and elsewhere) would find 
useful.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Cogent cutting links to Russia?

[David Conrad]

On Mar 4, 2022, at 1:14 PM, Bryan Fields  wrote:
> On 3/4/22 3:52 PM, Martin Hannigan wrote:
>> I would argue they don't have much of a choice:
>> 
>> "The economic sanctions put in place as a result of the invasion and the
>> increasingly uncertain security situation make it impossible for Cogent to
>> continue to provide you with service."
> 
> But Tier 1's don't pay for peering.

As someone who once had to have lawyers argue (at different times) with the US 
Dept. of Treasury for (a) providing open source software deemed a munition 
internationally and (b) updating certain globally accessible lists of names and 
numbers for Internet use at no charge (under a US government contract no less): 
you do not have to receive money to be viewed as providing a service.

Regards,
-drc

Re: Ukraine request yikes

[David Conrad]

Again, aside from turning off the ICANN-operated root servers (which would be 
pointless), the remainder of the requests from the UA Government Advisory 
Committee member are not something ICANN could/would do unilaterally regardless 
of the validity of the justification.

Regards,
-drc

> On Mar 1, 2022, at 4:00 PM, virendra rode  wrote:
> 
> I concur, this is an extremely dangerous slippery slope that ICANN should 
> refrain. There’s the possibility for misfires, misattribution and 
> miscalculation that could backfire which is extremely concerning.
> 
> —
> regards,
> /vrode
> 
>> On Mar 1, 2022, at 00:56, Matthew Petach  wrote:
>> 
>> 
>> 
>> 
>> On Tue, Mar 1, 2022 at 12:19 AM George Herbert > > wrote:
>> Posted by Bill Woodcock on Twitter… 
>> https://twitter.com/woodyatpch/status/1498472865301098500?s=21 
>> 
>> 
>> https://pastebin.com/DLbmYahS 
>> 
>> Ukraine (I think I read as) want ICANN to turn root nameservers off, revoke 
>> address delegations, and turn off TLDs for Russia.
>> 
>> Seems… instability creating…
>> 
>> -george
>> 
>> 
>> Information sharing should increase during wartime, not decrease.
>> 
>> Restricting information is more often the playbook of authoritarian regimes,
>> and not something we should generally support.
>> 
>> Besides, GhostWriter is based out of Belarus, not Russia proper.  ^_^;
>> https://www.wired.com/story/ghostwriter-hackers-belarus-russia-misinformationo/
>>  
>> 
>> 
>> Matt
>> 
>> 
>> 



signature.asc
Description: Message signed with OpenPGP

Re: Ukraine request yikes

[David Conrad]

On Mar 1, 2022, at 12:27 PM, Rubens Kuhl  wrote:
>> More or less.  The Government Advisory Committee member from Ukraine has 
>> asked ICANN to:
>> - Revoke .RU, .рф, and .SU (all Russian-managed ccTLDs)
>> 
>> As the GAC member undoubtedly knows, that’s not how ICANN works. Barring a 
>> court/executive order in ICANN’s jurisdiction (and even then, it gets a bit 
>> sticky see 
>> https://www.washingtonpost.com/news/volokh-conspiracy/wp/2014/11/13/dc-court-rules-that-top-level-domain-not-subject-to-seizure/),
>>  ICANN essentially treats ccTLDs as national sovereign resources. A third 
>> party, no matter how justified, requesting a change of this nature will not 
>> go anywhere. Simply put, ICANN is NOT a regulator in the forma sense, it is 
>> a private entity incorporated in California. The powers that it has are the 
>> result of mutual contractual obligations and it’s a bit unlikely the Russian 
>> government has entered into any contracts with ICANN, particularly those 
>> that would allow ICANN to unilaterally revoke any of the Russian ccTLDs.
> 
> I wonder how ICANN would react to ISO removing RU/RUS from ISO 3166-2/3.

See .SU.

(SU was moved from allocated to "transitionally reserved” back when the USSR 
broke up. My recollection is that an agreement was reached by which .SU users 
would be migrated out to appropriate new ccTLDs, that is, the ccTLDs based on 
ISO codes created for former Soviet republics, and no new entries would be 
added to .SU. However, when ICANN tried to propose a plan to finalize removing 
.SU from the root (around 2006 or so), the operators of .SU reopened 
registrations and complained to the US Dept. of Commerce, who were overseeing 
ICANN performance of the IANA Functions contract. Eventually, the Russian 
government was able to convince ISO-3166/MA to move SU to “exceptionally 
reserved” (like UK, EU, and a number of others) and forward motion on removing 
.SU from the root essentially ceased.)

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Ukraine request yikes

[David Conrad]

On Mar 1, 2022, at 12:16 AM, George Herbert  wrote:
> Ukraine (I think I read as) want ICANN to turn root nameservers off, revoke 
> address delegations, and turn off TLDs for Russia.

More or less.  The Government Advisory Committee member from Ukraine has asked 
ICANN to:
- Revoke .RU, .рф, and .SU (all Russian-managed ccTLDs)

As the GAC member undoubtedly knows, that’s not how ICANN works. Barring a 
court/executive order in ICANN’s jurisdiction (and even then, it gets a bit 
sticky see 
https://www.washingtonpost.com/news/volokh-conspiracy/wp/2014/11/13/dc-court-rules-that-top-level-domain-not-subject-to-seizure/
 
),
 ICANN essentially treats ccTLDs as national sovereign resources. A third 
party, no matter how justified, requesting a change of this nature will not go 
anywhere. Simply put, ICANN is NOT a regulator in the forma sense, it is a 
private entity incorporated in California. The powers that it has are the 
result of mutual contractual obligations and it’s a bit unlikely the Russian 
government has entered into any contracts with ICANN, particularly those that 
would allow ICANN to unilaterally revoke any of the Russian ccTLDs.

- "Contribute to the revoking for SSL certificates for the abovementioned 
domains.”

I’m not sure what this even means.

- Shutdown the root server instances operated by ICANN that are within Russia

ICANN could conceivably do this unilaterally, but there are a lot more root 
server instances operated by other RSOs (including RIPE NCC, Verisign, ISC, and 
NASA). Even if all the RSOs shut down their instances, it’d merely increase 
latency for root queries by a small amount unless all DNS traffic to the RSO 
IPs were blocked at Russian borders.  And even then, Russia has been “testing” 
operating in a disconnected mode, so it’s highly likely there are root server 
equivalents in Russia that would continue to resolve root queries.

However, as mentioned, the UA GAC member probably knows all this and I imagine 
the intent of this letter was less to cause the requested actions to actually 
occur than it was to raise the profile of the conflict in the Internet 
governance context.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: .bv ccTLD

[David Conrad]

Jay,

On Dec 3, 2021, at 4:46 PM, Jay Ashworth  wrote:
> In general I could I understand that, but it is my understanding that the 
> domain is still marked reserved at the Secretariat,

Sorry, which secretariat?  As far as I know, the official status of ISO 3166-1 
Alpha 2 codes is specified by the ISO-3166 Maintenance Agency and listed on the 
ISO website (the “online browsing platform” output for BV being the URL I 
provided).

> which is to say they could not have assigned any domains in it yet, even if 
> they were inclined to which we are told they are not.

ISO 3166-1 Alpha-2 codes are used for more than TLDs.

> In short, I think this is a possibility not an impossibility or I wouldn't 
> have asked.

“With enough thrust, pigs fly quite well although the landing can be messy.”

However, realistically, I suspect you’d need to get the government of Norway to 
actively pursue something like transitioning BV from their auspices to anywhere 
else.  I also suspect the government of Bougainville (which I gather doesn’t 
yet exist) would need to request the change (and get an exception from the 50 
year hold down timer).  I am a bit skeptical...

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: .bv ccTLD

[David Conrad]

On Dec 3, 2021, at 2:45 PM, Jay R. Ashworth  wrote:
> So, what's the actual status of .bv?  Assigned, or reserved?

Assigned: https://www.iso.org/obp/ui/#iso:code:3166:BV 


> Anyone here got a buddy on the secretariat?  :-)

Even if they did, transitioning codes is a long (99 year? I’ve forgotten) 
process…

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[David Conrad]

Bill,

On Nov 23, 2021, at 11:12 PM, William Herrin  wrote:
>> 1. IAB or IESG requests the IANA team to delegate one of
>> the 240/4 /8s to the RIRs on demand for experimental
>> purposes for a fixed period of time (a year or two?).
> 
> I like research but what would the RIRs study? The percentage of the
> 2021 Internet reachable from a station assigned a 240/4 IP address?
> Suppose it's 95%? Or 50%? Is there a difference? Neither one is enough
> to deploy the addresses for 2021 global use.

Lots of people said similar things when 1.0.0.0/8 was allocated to APNIC and 
they said similar things when 1.1.1.0/24 was stood up as an experiment by 
Cloudflare and APNIC, yet 1.1.1.1 seems to be pretty popular.

>> 5. Armed with hard data on the usability of the 240/4 /8s
>> allocated, people can scream past each other much more
>> authoritatively on the topic of what to do with 240/4.
> 
> Which is not particularly valuable. We already know the addresses are
> dysfunctional on the 2021 Internet. There's no credible disagreement
> on that point.

Seems to me that a number of folks on this list and during this discussion 
would disagree with a blanket assertion that 240/4 is “dysfunctional on the 
2021 Internet” - some of them even wrote a draft discussing the possibility. 

>> 2. IAB or IESG requests the IANA team to delegate one of
>> the 240/4 /8s to the RIRs on demand for experimental
>> purposes for a fixed period of time
> 
> But that still starts with:
> 
>> 1. Move 240/4 from "reserved" to "unallocated unicast"

OK, but this seems like a quibble.  The status for 240/4 is “ RESERVED: 
designated by the IETF for specific non-global-unicast purposes as noted.”  The 
“as noted” part is “Future Use”.  As far as I’m aware, “future use” would not 
preclude “experimental use” however if it makes people feel better to have an 
IANA considerations section that says the prefixes need to be moved to 
ALLOCATED, I struggle to see how that would be a problem.

Regards,
-drc

Re: Class D addresses? was: Redploying most of 127/8 as unicast public

[David Conrad]

On Nov 23, 2021, at 10:33 AM, William Herrin  wrote:
> On Tue, Nov 23, 2021 at 5:03 AM Eliot Lear  wrote:
>> So what's the road to actually being able to use [240/4]?
> 
> 1. Move it from "reserved" to "unallocated unicast" (IETF action)
> 2. Wait 10 years
> 3. Now that nearly all equipment that didn't treat it as
> yet-to-be-allocated unicast has cycled out of use, argue about what to
> allocate the addresses to for best effect.

Or…

1. IAB or IESG requests the IANA team to delegate one of the 240/4 /8s to the 
RIRs on demand for experimental purposes for a fixed period of time (a year or 
two?). 
2. The RIRs, with input from their communities, formulate research programs to 
explore the viability of the space they have just received for “normal” unicast 
space.
3. The RIRs assign that space in accordance with those research programs.
4. At the end of the fixed period of time, research reports are published.
5. Armed with hard data on the usability of the 240/4 /8s allocated, people can 
scream past each other much more authoritatively on the topic of what to do 
with 240/4.

> Bottom line though is that the IETF has to act before anyone else
> reasonably can.


To be honest, I don’t think it actually matters if it is the IAB, the IESG, or 
the NRO that directs the IANA to do stuff (although Kim @ IANA might have a 
different opinion and he’s more authoritative).  What I believe matters is that 
there is consensus that additional data is needed.  I’m not sure we’re at that 
point as yet — too many people appear to know The Truth.

Regards,
-drc

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[David Conrad]

> I would be happy to fund or run a project that would announce small
> global routes in each of these ranges, and do some network probing, to
> actually measure how well they work on the real Internet.

To be clear, despite my skepticism, I think this would be an interesting 
experiment to run.  I believe it would be useful to get some actual data on 
reachability/usefulness as the question of deployment of reserved space is a 
recurrent question, both in technical and political spaces.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[David Conrad]

John,

On Nov 18, 2021, at 12:54 PM, John Gilmore  wrote:
> Is it even *doable*?

With enough thrust, pigs fly quite well, although the landing can be messy.

> What's the *risk*?

Some (not me) might argue it could (further) hamper IPv6 deployment by 
diverting limited resources.

> What will it *cost* to upgrade
> every node on the Internet?  And *how long* might it take?

These are the pertinent questions, which are, of course extremely hard to 
estimate.

> We succeeded in upgrading every end-node and every router in the
> Internet in the late '90s and early 2000's, when we deployed CIDR.

My recollection was that CIDR deployment was a bit early than that, but 
regardless, the Internet of the late '90s and early 2000’s was vastly different 
than the Internet today.  For one thing, most of the end nodes still had people 
with technical clue managing them.  That’s not the case today.

> So today if we decide that unicast use of the 268 million addresses in
> 240/4 is worth doing, we can upgrade every node.

Can we?  We can’t even get some DNS resolvers to stop querying root server IP 
addresses that were renumbered two decades ago. People aren’t even 
patching/updating publicly available systems with active security exploits that 
are impacting them directly and you believe they’ll be willing to update all 
their devices to benefit other people (the ones who want the 240/4 space)?  You 
must be more optimistic than I.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Redeploying most of 127/8, 0/8, 240/4 and *.0 as unicast

[David Conrad]

John,

On Nov 18, 2021, at 11:37 AM, John Gilmore  wrote:
> At current rates, 300 to 400 million addresses would last more than a decade!

Doesn’t this presume the redeployed addresses would be allocated via a market 
rather than via the RIRs?

If so, who would receive the money?

> There will be no future free-for-all that burns through 300 million IPv4 
> addresses in 4 months.

I suspect you underestimate the global demand and may not fully understand the 
rationale for address acquisition.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: WKBI #586, Redploying most of 127/8 as unicast public

[David Conrad]

On Nov 18, 2021, at 9:00 AM, John R. Levine  wrote:
>> The only effort involved on the IETF's jurisdiction was to stop squatting on 
>> 240/4 and perhaps maybe some other small pieces of IPv4 that could possibly 
>> be better used elsewhere by others who may choose to do so.
> 
> The IETF is not the Network Police, and all IETF standards are entirely 
> voluntary.

True…

> Nothing is keeping you from persuading people to change their software to 
> treat class E addresses as routable other than the detail that the idea is 
> silly.

Of course, it’s not quite that simple.

First, 
https://www.iana.org/assignments/ipv4-address-space/ipv4-address-space.xhtml 
 
would need to be updated, then the RIRs would need to issue a request according 
to https://www.icann.org/resources/pages/allocation-ipv4-rirs-2012-02-25-en 
. At 
that point, existing requests lodged at the RIRs could be fulfilled using the 
formerly reserved space. Network operators that received the allocations could 
then number their devices with the new address space and announcing that space 
into the routing system.

Of course, there are probably an unknowable number of “bogon” filters out there 
that are hardcoded into various bits of infrastructure that would need to be 
updated. There are also various hardware, firmware, and software IP stack 
implementations, perhaps sitting in closets somewhere, that still think they 
can’t use reserved space that would need to be updated/replaced.

As far as I can tell, assertions about the scale of that update/replace 
exercise are based on limited data. Perhaps as an alternative to declaring 
various chunks of reserved space as free for use, a chunk of that space could 
be allocated to one or more of the RIRs and announced with a set of services 
placed upon it to see just how much actually breaks, similar to what APNIC and 
Cloudflare did with 1.1.1.0/24?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Need for historical prefix blacklist (`rogue' prefixes) information

[David Conrad]

I’m a little confused.  I thought the concern was about decrypting 
intentionally mis-routed traffic, not a suggestion that ROV uses encryption…

Regards,
-drc

> On Oct 30, 2021, at 5:57 PM, J. Hellenthal via NANOG  wrote:
> 
> He answered it completely. "You" worried about interception of RPKI exchange 
> over the wire are failing to see that there is nothing there important to 
> decrypt because the encryption in the transmission is not there !
> 
> And yet you've failed to even follow up to his question... "What's your point 
> regarding your message? ROV does not use (nor needs) encryption."
> 
> So maybe you could give some context on that so someone can steer you out of 
> the wrong direction.
> 
> -- 
>  J. Hellenthal
> 
> The fact that there's a highway to Hell but only a stairway to Heaven says a 
> lot about anticipated traffic volume.
> 
>> On Oct 30, 2021, at 10:31, A Crisan  wrote:
>> 
>> 
>> Hi Matthew, 
>> 
>> Quantum computing exists as POCs, IBM being one of those advertising them 
>> and announced to extend their project. There are others on the market, 
>> Amazon advertised quantum computing as a service back in 2019: 
>> https://www.theverge.com/2019/12/2/20992602/amazon-is-now-offering-quantum-computing-as-a-service
>>  
>> .
>>  The bottle neck of the current technology is scalability: we will not see 
>> QC as personal computing level just yet (to go in more detail, current 
>> technologies work at cryogenic temperatures, thus they are hyper expensive 
>> and not really scalable), but they exist and one could be imagine they 
>> are/will be used for various tasks.
>> 
>> On the other hand, you've actually commented every word of my mail, minus 
>> the stated question. Thanks. 
>> 
>> Best Regards, 
>> Dora Crisan 
>> 
>> 
>> 
>>  
>> 
>> On Fri, Oct 29, 2021 at 8:10 PM Matthew Walster > > wrote:
>> 
>> 
>> On Fri, 29 Oct 2021, 15:55 A Crisan, > > wrote:
>> Hi Matthew,
>> I was reading the above exchange, and I do have a question linked to your 
>> last affirmation. To give you some context, the last 2021 ENISA report seem 
>> to suggest that internet traffic is "casually registered" by X actors to 
>> apply post Retrospective decryption (excerpt below). This would be at odds 
>> with your (deescalating) affirmation that hijacks are non-malicious and they 
>> are de-peered quickly, unless you pinpoint complete flux arrest only. Are 
>> there any reportings/indicators... that look into internet flux constant 
>> monitoring capabilities/capacities? Thanks.
>> 
>> RPKI uses authentication not confidentiality. There is no encryption taking 
>> place, other than the signatures on the certificates etc.
>> 
>> Excerpt from the introduction: "What makes matters worse is that any cipher 
>> text intercepted by an attacker today can be decrypted by the attacker as 
>> soon as he has access to a large quantum computer (Retrospective decryption).
>> 
>> Which do not exist (yet).
>> 
>> Analysis of Advanced Persistent Threats (APT) and Nation State capabilities,
>> 
>> Buzzwords.
>> 
>> along with whistle blowers’ revelations
>>  have shown that threat actors can and are casually recording all Internet 
>> traffic in their data centers
>> 
>> No they're not. It's just not possible or indeed necessary to duplicate 
>> everything at large scale. Perhaps with a large amount of filtering, certain 
>> flows would be captured, but in the days of pervasive TLS, this seems less 
>> and less worthwhile.
>> 
>>  and that they select encrypted traffic as interesting and worth 
>> storing.This means that any data encrypted using any of the standard 
>> public-key systems today will need to be considered compromised once a 
>> quantum computer exists and there is no way to protect it retroactively, 
>> because a copy of the ciphertexts in the hands of the attacker. This means 
>> that data that needs to remain confidential after the arrival of quantum 
>> computers need to be encrypted with alternative means"
>> 
>> None of this is relevant to RPKI (ROV) at all. In fact, it reads like the 
>> fevered dreams of a cyber security research student. What's your point 
>> regarding your message? ROV does not use (nor needs) encryption.
>> 
>> M
>> 

Re: IPv6 and CDN's

[David Conrad]

Bryan,

On Oct 23, 2021, at 5:56 PM, Bryan Fields  wrote:
>> Excepting temporary failures, they are as far as I am aware. Why do you
>> think they aren’t?
> 
> I can't reach C, 2001:500:2::c, from many places in v6 land.  My home and

> secondary data center can't reach it, but my backup VM's at another data
> center can.

Ah. Cogent. I suspect IPv6 peering policies. Somebody should bake a cake.

>> However, the IANA team is not the enforcement arm of the Internet. If a
>> root server operator chooses to not abide by RFC 7720, there is nothing the
>> IANA team can do unilaterally other than make the root server operator
>> aware of the fact.
> 
> Surely IANA has the power to compel a root server operator to abide by policy
> or they lose the right to be a root server?

To compel? No. Not in the slightest. That is not how the root server system 
works. This is a (very) common misconception.

There has been some effort to create a governance model for the root server 
system (see 
https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf) but I 
believe it has gotten bogged down in the question of “what do you do when a 
root server operator isn’t doing the job ‘right’ (whatever that means and after 
figuring out who decides) but doesn’t want to give up being a root server 
operator?”.  It’s a hard question, but it isn’t the folks at IANA who answer it.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: IPv6 and CDN's

[David Conrad]

Bryan,

On Oct 22, 2021, at 11:45 AM, Bryan Fields  wrote:
> On 10/22/21 11:13 AM, Job Snijders via NANOG wrote:
>> Another aspect that flabbergasts me anno 2021 is how there *still* are
>> BGP peering disputes between (more than two) major global internet service
>> providers in which IPv6 is 'held hostage' as part of slow commercial
>> negotiations. Surely end-to-end IPv6 connectivity should be a priority?
> 
> Even the DNS root servers are not 100% reachable via IPv6.

Excepting temporary failures, they are as far as I am aware. Why do you think 
they aren’t?

> I would think IANA
> would have some standard about reachability for root operators.

I think you might misunderstand relationships here.

The IANA team’s standards are what the community defines. In the case of the 
root operators, RFC 7720 says “root service” must be available via IPv6 and 
RSSAC-001 (“Service Expectations of Root Servers”, 
https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf)
 says:

"[E.3.1-B] Individual Root Servers will deliver the service in conformance to 
IETF standards and requirements as described in RFC 7720 [4] and any other IETF 
standards-defined Internet Protocol as deemed appropriate."

So, in theory, all the root servers should be available via IPv6 and, as far as 
I can tell, they are.

However, the IANA team is not the enforcement arm of the Internet. If a root 
server operator chooses to not abide by RFC 7720, there is nothing the IANA 
team can do unilaterally other than make the root server operator aware of the 
fact.

> Until IPv6 becomes provides a way to make money for the ISP, I don't see it
> being offered outside of the datacenter.

Different markets, different approaches.  In the areas I’ve lived in Los 
Angeles, commodity residential service via AT (1 Gbps up/down fiber) and 
Spectrum (varying speeds) is dual stack by default (as far as I can tell).  I 
suspect all it would take would be one of the providers in your area to offer 
IPv6 and advertise the fact in their marketing to cause the others to fall into 
line.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: Huawei on Mount Everest

[David Conrad]

On May 1, 2020, at 11:07 AM, Aaron Gould  wrote:
> You made me curious...
> 
> https://en.wikipedia.org/wiki/List_of_people_who_died_climbing_Mount_Everest
> 
> wow, I guess it would be great to be able to use cell/gps technology to 
> communicate with and track a lost/endangered climber

Depending on how high and the weather conditions, it might give a false sense 
of security.  Or it might serve the same purpose as for Rob Hall 
(https://en.wikipedia.org/wiki/Rob_Hall) in the 1996 Everest disaster 
(https://en.wikipedia.org/wiki/1996_Mount_Everest_disaster), namely give you a 
chance to call your pregnant wife and say goodbye.  Tragic story.

Back to the NOG content: I agree, a publicity stunt, maybe useful for a bit of 
telemetry but I can’t imagine the hardware would survive more than a season.

Regards,
-drc

Re: AFRINIC: The Saga Continues

[David Conrad]

Ronald,

Speaking only for myself…

As I’ve recently seen complaints about RIRs directed to ICANN (in a different 
context than the issues at AfriNIC), a bit of clarification may be in order:

>> What can or should be done when a registry goes rogue?

In my view, it is primarily the responsibility of the community served the the 
RIR to reign it in if it goes rogue.

> And to be clear, I am most definitely *not* talking about
> an investigation performed by what is effectively AFRINIC's parent company,
> ICANN.

ICANN is not the parent company of AfriNIC (or any other RIR, some of which 
existed prior to ICANN being created). While ICANN recognizes new RIRs 
(according to 
https://www.icann.org/resources/pages/new-rirs-criteria-2012-02-25-en) and 
recognizes “global policies” that reach consensus across all RIRs, there are no 
policies, processes, or mechanisms by which ICANN can exert any form of control 
over the RIRs. ICANN performs a set of functions for the RIRs at their request 
via the IANA functions and can be seen in that light as a service provider to 
the RIRs.

It is probably most accurate to view ICANN and the RIRs as peer organizations, 
connected operationally via the IANA functions, which primarily focus on 
different universes (domain names in ICANN’s case, IP addresses in the RIRs’ 
case).

> That organization also has more than a little vested interest in
> seeing to it that both of these matters, the IP thefts and the accounting
> irregularities, are all swept under the rug as quickly and as quietly as
> possible.

I’ll admit some curiosity as to what this “more than a little vested interest” 
might be, however this is simply wrong. Like pretty much everybody else, we 
have an interest in an accurate and trustable registration database.

> For this reason, I have no doubt whatsoever that both AFRINIC and ICANN
> would vigorously oppose the notion of an independent outside investigation.

As RIR operational matters are outside ICANN’s remit as defined by our Bylaws, 
at least by my reading, I am skeptical ICANN would even have an opinion.

> And since ICANN calls the tune with respect to all Internet governance
> matters

I suspect the folks at the RIRs, Internet Society, IGF, ITU, W3C, ETSI, IETF, 
IAB, etc. may not agree with this assertion.

Regards,
-drc
ICANN CTO, but speaking only for myself.


signature.asc
Description: Message signed with OpenPGP

Re: DoD IP Space

[David Conrad]

On Nov 4, 2019, at 10:56 PM, Grant Taylor via NANOG  wrote:
> This thread got me to wondering, is there any legitimate reason to see 22/8 
> on the public Internet?  Or would it be okay to treat 22/8 like a Bogon and 
> drop it at the network edge?

Given the transfer market for IPv4 addresses, the spot price for IPv4 
addresses, and the need of even governments to find “free” (as in 
unconstrained) money, I’d think treating any legacy /8 as a bogon would not be 
prudent.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: This DNS over HTTP thing

[David Conrad]

On Oct 7, 2019, at 10:45 AM, Jim  wrote:
> My suggestion would be ultimately that DNS Clients implement DNSSEC

> validation themself to avoid tampering by a malicious client on their network
> for phishing purposes or a malicious recursive DNS Resolver server

Yep. That is (IMHO) the right (only) answer to actually fix the ‘lying’ problem 
instead of making it “someone else’s problem", although that turns lies into 
DoS when all you get back from your resolver is unvalidatable answers.

To solve this problem, browser vendors really should implement validation in 
their stub resolvers. This would have the benefit that if validation fails, a 
useful error message could be presented to the user (e.g., “the website name 
you looked up has been tampered with!”).  Instead, they have chosen to rely on 
their “trusted recursive resolvers” to not lie to them and use agreements 
rather than code.

This, of course, doesn’t stop the snooping/metadata collection problem.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: This DNS over HTTP thing

[David Conrad]

Jay,

On Oct 1, 2019, at 12:18 PM, Jay R. Ashworth  wrote:
> This is thought to be about security?
> 
> Didn't we already *fix* DNS SECurity?

No.  DNSSEC solves a different problem (being able to verify what you get is 
what the domain owner published).

DoH (and DoT) encrypt (and authenticate) the application <-> recursive resolver 
channel (NOT the DNS data) which I gather some view as an attack vector. 
Mozilla has decided to _also_ redefine the default resolver (unless 
use-application-dns.net  NXDOMAINs), instead 
of the resolver (typically) assigned by the ISP, for browser queries.  That 
last bit is generating a bit of ‘discussion’ as it can bypass efforts by 
network operators to modify DNS responses for whatever reason (e.g., protect 
customers from phishing sites, censoring domain names due in response to court 
orders, monetizing typos, etc.).

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Ancient history (was Re: 44/8)

[David Conrad]

Jimmy,

I have been staying out of this particular food fight, but speaking purely in a 
personal capacity as someone who had a small role in early addressing stuff 
ages ago, I did want to clarify a couple of things:

On Jul 23, 2019, at 11:05 AM, Jimmy Hess  wrote:
> People sought an
> allocation from IANA originally,  but that does not give IANA nor
> any contact listed by IANA "ownership" or  "management" authority
> over usage of this IP address space  outside of their registry which
> is supposed to accurately cover the internet: but the AMPRnet is Not
> a block of networks on the internet,  and not under the purview
> of IETF or IANA, anyways  ---  its just a community that uses
> TCP/IP mostly in isolated discrete networks which can be neither
> allocated,  nor managed,  nor get their individual assignments
> within 44/8 from any central authority.

Yes and no.

There were actually a number of “class As” that Postel directed to be assigned 
based on layer 2 technology, e.g., 14/8 for X.25, 24/8 (I believe) for IP over 
CATV, 44/8 for IP over amateur radio, maybe a block assigned for IP over 
satellite (4/8? I don’t remember).  In some cases, there was a ‘caretaker’ 
assigned (ARRL for 44/8 and @Home for 24/8) who acted as a pseudo-registry: 
they did (or at least were supposed to do) sub-assignments for entities that 
met (IANA- and pseudo-registry-) defined criteria.  However, the informal 
assignments were, like all assignments of the day, based on the assumption that 
the addresses were supposed to be used to provide IP networking and if the 
addresses weren’t so used, they were to be returned to IANA. This was actually 
put in practice with 14/8 (which unfortunately didn’t have a ‘caretaker’ so we 
at IANA had to try to track down the remaining IP over X.25 users starting 
around 2007 or so IIRC — a bit challenging, but ultimately accomplished). I 
have vague memories of asking Brian Kantor (as the assignee in the IANA 
registry) about returning 44/8 back when we were cleaning up 14/8 but my 
recollection was that I was informed it would be too hard given the number, 
distribution, and global nature of the sub-assignments.

In any event, this is largely irrelevant: there weren’t any contracts or other 
written agreements, it was all informal and based on folks doing the right 
thing, without fully agreed upon terms of what the “right thing” was (other 
than “for the good of the Internet” I suppose).

> In a way; it just means the IANA registry data became
> corrupted/Less accurate  Due to IANA's failure to clearly
> state a policy for the maintenance of the allocations and/or
> ARDC  "converting"  ownership or  being allowed to take
> up a false pretense of ownership of the registry allocation.

Err, no.

It’s inappropriate to blame IANA here. IANA has a clear policy: management of 
IP addresses was delegated on a regional basis starting with RFC 1366/1466 
around 1990, then RFC 2050 and finally RFC 7020. The existing IANA IPv4 
registry largely consists of pointers to the RIRs as the delegatees of 
responsibility for the address space. If you have concerns with address policy, 
the proper place to raise those concerns is with the RIRs (and in the case of 
44/8, ARIN).

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: A Deep Dive on the Recent Widespread DNS Hijacking

[David Conrad]

On Feb 26, 2019, at 2:35 PM, Ca By  wrote:
> On Tue, Feb 26, 2019 at 1:58 AM Bill Woodcock  > wrote:
> > On Feb 24, 2019, at 10:03 PM, Hank Nussbacher  > > wrote:
> > Did you have a CAA record defined and if not, why not?
> 
> It’s something we’d been planning to do but, ironically, we’d been in the 
> process of switching to Let’s Encrypt, and they were one of the two CAs whose 
> process vulnerabilities the attackers were exploiting.  So, in this 
> particular case, it wouldn’t have helped.
> 
> I guess the combination of CAA with a very expensive, or very manual, CA, 
> might be an improvement.  But it’s still a band-aid on a bankrupt system.
> 
> 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.
> 
> -Bill
> 
> DNS guy says the solution for insecure DNS is... wait for it more DNS ...

Well, no. "DNS guy” (Bill’s a bit more than that, of course) says the solution 
for a fundamentally broken trust model is a different system to derive trust.

Or do you think Let’s Encrypt/Comodo increase trust?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP

Re: skype attack

[David Conrad]

Perhaps (issue created on 6 Dec 2017) relevant:

https://answers.microsoft.com/en-us/skype/forum/skype_accountms-skype_privacyms/skype-suggests-people-from-my-contact-list-to/d8cc03ad-fa15-4de7-8d96-51510615cff4

> On Feb 13, 2019, at 12:11 PM, Randy Bush  wrote:
> 
> an update to skype will pop up and ask you
> 
> 
> deny.  you will have to deny repeatedly.  there is no reason in the
> world skype should have access to your icloud, contacts, ...
> 
> randy



signature.asc
Description: Message signed with OpenPGP

Re: Cloudflare 1.1.1.1 public DNS broken w/ AT CPE

[David Conrad]

Wait. What?

Why do you think 1/8 shouldn’t be used for anything?

Regards,
-drc

--

> On Monday, Apr 02, 2018 at 11:40 AM, Seth Mattinen  (mailto:se...@rollernet.us)> wrote:
> On 4/2/18 8:35 AM, Simon Lockhart wrote:
> >
> > This looks like a willy-waving exercise by Cloudflare coming up with the 
> > lowest
> > quad-digit IP. They must have known that this would cause routing issues, 
> > and
> > now suddenly it's our responsibility to make significant changes to live
> > infrastructures just so they can continue to look clever with the IP 
> > address.
>
>
> To be fair, nobody should have been using 1/8 for anything.


signature.asc
Description: PGP signature

Re: Free access to measurement network

[David Conrad]

Mike,

On Dec 16, 2017, 4:23 PM +0100, Mike Hammett , wrote:
> It's a consumer thing. If consumers wanted more options, they would be 
> supporting those options with their wallets. They don’t.

The report Valdis quoted said "More than 129 million people are limited to a 
single provider for broadband Internet access using the FCC definition of 25 
Mbps download and 3 Mbps upload.”

This suggests that consumers don’t have the option of supporting alternatives 
with their wallets.

Regards,
-drc

Re: Google DNS intermittent ServFail for Disney subdomain

[David Conrad]

Damian,

Pragmatically speaking, I strongly suspect the increase in valid queries to 
authoritative servers even if all “large recursive resolvers” went away would 
be lost in noise of the overcapacity necessary to deal with even a lower-end 
DDoS attack.

Perhaps more interestingly, if said recursive resolvers on home routers would 
implement DNSSEC with RFC 8198 (and the owners of the authoritative zones would 
sign those zones), an entire class of DDoS attack would be mitigated. Further, 
if said recursive resolvers also implemented RFC 7706, latency to the root 
would be reduced and the risk of to the network behind that recursive resolver 
of a DDoS against the root of the DNS would be removed.

Regards,
-drc

On Oct 22, 2017, 12:00 AM -0700, Damian Menscher via NANOG , 
wrote:
> On Fri, Oct 20, 2017 at 6:29 AM, Filip Hruska  wrote:
>
> > Would be great if makers of home routers would implement full recursive
> > DNS resolvers
> > instead of just forwards in their gear.
>
>
> Ignoring the latency impact of your proposal, I wonder what would happen to
> the world's authoritative servers if all users hit them directly rather
> than going through large recursive resolvers that do caching? I'm guessing
> it wouldn't be pretty.
>
> Damian

Re: Another day, another illicit SQUAT - WebNX (AS18450) 103.11.67.0/24

[David Conrad]

On Oct 29, 2016, at 5:18 PM, Nick Hilliard  wrote:
> There
> are 5 RIRs, so 20 different ways for data to flow, and IANA is no longer
> authoritative for the address space once its been RIR-allocated.

While true, hopefully referrals in RDAP will address the need to identify 
registration information down to the leaves.

> I.e. you should no longer depend on whois.iana.org for accurate resource
> delegation information.

Well, it should be accurate at the top-level delegation (albeit, the IANA Whois 
server only deals with /8s).

Regards,
-drc
(speaking only for myself)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Death of the Internet, Film at 11

[David Conrad]

On October 23, 2016 at 6:52:05 PM, Stephen Satchell (l...@satchell.net) wrote:
So, bottom line, nothing is going to happen until the cost to those 
negligent provides rises so high as to affect profits. Period. 
Yep.  Or government intervention.

Larger eyeball operators could help, by shutting down entire subnets 
infested with botted computers and things. 

Shut down subnets of your own customers? 

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: Death of the Internet, Film at 11

[David Conrad]

Mike,

On October 22, 2016 at 8:09:34 AM, Mike Hammett (na...@ics-il.net) wrote:

How can I as a network operator seek out and eliminate the sources of these 
attacks? 
Maybe (not sure) one way would be to examine your resolver query logs to look 
for queries for names that fit domain generation algorithm patterns, then 
tracking down the customers/devices that are issuing those queries and politely 
suggest they remove the malware on their systems? 

Regards,

-drc




signature.asc
Description: Message signed with OpenPGP using AMPGpg

Re: New ICANN registrant change process

[David Conrad]

On Jul 6, 2016, at 10:41 AM, Christopher Morrow  wrote:
> Perhaps this all self-polices?

I figure either it does or governments get involved and that most likely ends 
in tears.

>  I hate it when you are right :)

Don't worry: very rarely happens.

Regards,
-drc
(speaking only for myself)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: New ICANN registrant change process

[David Conrad]

Rubens,

On Jul 6, 2016, at 2:20 PM, Rubens Kuhl  wrote:
>> Not sure the RPZ hammer has been brought out in force yet. I've seen a few 
>> recommendations on various mailing lists, but no concerted effort. 
>> Unfortunately, there is no easy/scalable way to determine who a registrar 
>> for a given name is,
> That is called RDAP,

I said "scalable".

Given RDAP is based on TCP and there is this concept known as "registration 
data lookup rate limiting", I'm somewhat skeptical RDAP is the appropriate 
choice for (e.g.,) a "DNS Block List"-like solution that would (say) dump email 
that came from domains registered via operator-specified registrars.

> but ICANN currently blocks gTLD registries from offering RDAP.


Ignoring the above, and as I'm sure you're aware, the community has not 
determined the policies by which RDAP may be offered as an official registry 
service using production data, e.g., whether and how differentiated services 
will be permitted among other details.  As such, it is more accurate to say 
that registries are not permitted to deploy new services because of contractual 
obligations the registries entered into that requires them to have new services 
evaluated to ensure those services don't impact DNS security, stability or 
competition, something the community required ICANN enforce as a result of the 
SiteFinder episode ages ago. Registries can, of course, request that evaluation 
and I'm told some have and are actually offering RDAP.

But I would agree it is much easier to simply blame ICANN.

Regards,
-drc
(speaking only for myself)




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: New ICANN registrant change process

[David Conrad]

> Depends on whether or not the Registry wants their TLD to be associated with 
> spam/malware distribution/botnet C/phishing/pharming and be removed at 
> resolvers via RPZ or similar. Ultimately, the Registries are responsible for 
> the pool the Registrars are peeing in -- it's the Registry's namespace, is it 
> not?
> it's not clear, to me, that any of those hammers have real effect.

Not sure the RPZ hammer has been brought out in force yet. I've seen a few 
recommendations on various mailing lists, but no concerted effort. 
Unfortunately, there is no easy/scalable way to determine who a registrar for a 
given name is, so the hammer has to be applied to the TLD as a whole, which has 
unfortunate side effects...

>>  I love how people love to blame ICANN.
> 
> but, they are the names and numbers authority, no? it says so in their name.

"Internet Corporation for Assigned Names and Numbers" -- Don't see "authority" 
in that name. :)

Regards,
-drc
(speaking only for myself)





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: New ICANN registrant change process

[David Conrad]

On Jul 6, 2016, at 7:23 AM, Christopher Morrow  wrote:
> On Mon, Jul 4, 2016 at 3:03 PM, Jay Ashworth  wrote:
>> Seems to me that the proper thing to be done would have been for
>> Registries to deauthorize registrars on the grounds of continuous streams
>> of complaints.
>> 
>> 
> 
> On what metric? Pure volume? Percent of registrations? type of complaint by
> similar x/y?
> 

By the terms the Registry sets in the Registry/Registrar Agreement and to which 
the Registrar agrees in order to sell the Registry's names.

> there are 'lots of complaints' against some registrars, but if you have
> ~20% of the .TLD market you're prone to get more volume than a 1%er, right?

There's this concept called "normalization", e.g., complaints per 100 
delegations or some such.

> Also, this isn't REALLY the registrY's problem is it?

Depends on whether or not the Registry wants their TLD to be associated with 
spam/malware distribution/botnet C/phishing/pharming and be removed at 
resolvers via RPZ or similar. Ultimately, the Registries are responsible for 
the pool the Registrars are peeing in -- it's the Registry's namespace, is it 
not?

> i love how icann makes avoiding blame so easy.

I love how people love to blame ICANN.

Regards,
-drc
(speaking only for myself)



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[David Conrad]

Owen

> On Jun 20, 2016, at 6:03 PM, Owen DeLong  wrote:
>>> If ARIN didn’t exist, how would you go about guaranteeing unique registered 
>>> GUA blocks and ASNs? Who would operate whois and in-addr.arpa, ip6.arpa?
>> ICANN operates in-addr.arpa and ip6.arpa.
> ICANN takes the data supplied by the RIRs and compiles it into zone files 
> which are then distributed to servers.

Among others, yes (hint: not all the IPv4 and IPv6 address space is managed by 
the RIRs).

> AIUI, most of the servers are hosted and maintained by the RIRs. Most if not 
> all of the zone file information is supplied to ICANN by the RIRs.

Perhaps you should review how the DNS works. Hint: who operates the master for 
in-addr.arpa and ip6.arpa and what is the role of secondaries?

> I stand by my statement to the extent that it is close enough for the 
> purposes for which it was made.

Your statement posited the nonexistence of ARIN.  ARIN is a secondary for 
in-addr.arpa and ip6.arpa (like the other RIRs) and maintains a registry for 
the address blocks allocated to them by ICANN as the IANA Numbering Function 
operator. If ARIN did not exist, then the reverse delegations for which ARIN is 
authoritative could easily be managed by the other RIRs, the entities to which 
ARIN currently delegates, or the myriad of other DNS registries. This really 
isn't rocket science.

> Without the RIR, ICANN’s idea of what should go into ip6.arpa and in-addr.arp 
> would get pretty stale pretty fast.

Or not, as long as the entities to which ARIN delegated were aware of the 
registry they should update.  This really isn't rocket science.

> Of course, that wouldn’t matter because AIUI, without the servers being 
> supplied, hosted, maintained by the RIRs, it would also be fairly invisible 
> as well.

Again, perhaps you should review how the DNS works. Hint: where do referrals to 
the sub-trees of .ARPA come from?

> But keep those ICANN delusions of grandeur coming.

You asked a question. I answered that question accurately. I am unsure why that 
would cause you to assert delusions of grandeur.

Regards,
-drc
(speaking only for myself)



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[David Conrad]

Owen,

On Jun 17, 2016, at 1:20 AM, Owen DeLong  wrote:
>> On Jun 16, 2016, at 06:03 , Ca By  wrote:
>> 
>> Perhaps it is me and my sensibilities, perhaps it  is my miser corp culture, 
>> but i could not even dream of asking to go to Jamaica (arin area) for the 
>> last ARIN meeting.
> 
> You are entitled to your opinion.
> 
> If ARIN didn’t exist, how would you go about guaranteeing unique registered 
> GUA blocks and ASNs? Who would operate whois and in-addr.arpa, ip6.arpa?

ICANN operates in-addr.arpa and ip6.arpa.

Regards,
-drc
(speaking only for myself)



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ARIN down?

[David Conrad]

Yep, they're under another DDoS attack:

> Begin forwarded message:
> 
> From: ARIN 
> Subject: [arin-announce] ARIN DDoS Attack
> Date: March 25, 2016 at 1:31:34 PM PDT
> To: arin-annou...@arin.net
> 
> Starting at 3:55 PM EDT on Friday, 25 March, a DDoS attack began against 
> ARIN. This was and continues to be a sustained attack against our 
> provisioning services, email, and website. We initiated our DDoS mitigation 
> plan and are in the process of mitigating various types of attack traffic 
> patterns. All our other public-facing services (Whois, Whois-RWS, RDAP, DNS, 
> IRR, and RPKI repository services) are not affected by this attack and are 
> operating normally.
> 
> We will announce an all clear 24 hours after the attacks have stopped.
> 
> Regards,
> 
> Mark Kosters
> Chief Technology Officer
> American Registry for Internet Numbers (ARIN)
> ___


Regards,
-drc

> On Mar 25, 2016, at 9:43 PM, Mel Beckman  wrote:
> 
> I haven’t been able to connect to http://arin.net for several hours, but was 
> able to open a ticket this morning. I’ve tried from several different 
> networks, all roads seem to lead to the same place, with packets dropping at 
> the NTT interface 129.250.196.154. e.g.:
> 
> $ traceroute arin.net
> traceroute: Warning: arin.net has multiple addresses; using 
> 199.43.0.44
> traceroute to arin.net (199.43.0.44), 64 hops max, 52 byte 
> packets
> 1  
> l100.lsanca-vfttp-106.verizon-gni.net
>  (98.112.74.1)  5.992 ms  4.865 ms  4.943 ms
> 2  172.102.106.24 (172.102.106.24)  9.962 ms  9.723 ms  12.242 ms
> 3  
> ae2-0.lax01-bb-rtr2.verizon-gni.net
>  (130.81.22.238)  29.982 ms *
>
> so-4-1-0-0.lax01-bb-rtr2.verizon-gni.net
>  (130.81.151.248)  9.428 ms
> 4  0.ae6.br1.lax15.alter.net 
> (140.222.225.137)  9.806 ms * *
> 5  ae-7.r01.lsanca20.us.bb.gin.ntt.net 
> (129.250.8.85)  10.409 ms
>0.ae6.br1.lax15.alter.net 
> (140.222.225.137)  19.783 ms  9.757 ms
> 6  ae-7.r01.lsanca20.us.bb.gin.ntt.net 
> (129.250.8.85)  10.292 ms  9.357 ms  12.291 ms
> 7  ae-17.r01.lsanca07.us.bb.gin.ntt.net 
> (129.250.4.207)  22.541 ms
>ge-101-0-0-3.r06.asbnva02.us.bb.gin.ntt.net 
> (129.250.196.153)  72.412 ms
>ae-17.r01.lsanca07.us.bb.gin.ntt.net 
> (129.250.4.207)  22.167 ms
> 8  ge-101-0-0-3.r06.asbnva02.us.bb.gin.ntt.net 
> (129.250.196.153)  72.510 ms  74.590 ms  72.258 ms
> 9  ge-101-0-0-3.r06.asbnva02.us.ce.gin.ntt.net 
> (129.250.196.154)  69.960 ms *  70.930 ms
> 10  * * *
> 11  * * *
> 
> $ traceroute www.arin.net
> traceroute: Warning: www.arin.net has multiple 
> addresses; using 199.43.0.43
> traceroute to www.arin.net (199.43.0.43), 64 hops max, 
> 40 byte packets
> 1  router1.sb.becknet.com (206.83.0.1)  1.010 
> ms  0.420 ms  0.536 ms
> 2  
> 206-190-77-9.static.twtelecom.net 
> (206.190.77.9)  3.983 ms  0.732 ms  0.686 ms
> 3  
> 64-129-238-182.static.twtelecom.net
>  (64.129.238.182)  2.760 ms 
> lax2-pr2-xe-1-3-0-0.us.twtelecom.net
>  (66.192.241.218)  2.816 ms 
> 64-129-238-186.static.twtelecom.net
>  (64.129.238.186)  18.203 ms
> 4  4.68.71.137 (4.68.71.137)  3.245 ms  2.877 ms  2.889 ms
> 5  * * *
> 6  ae-28.r00.lsanca07.us.bb.gin.ntt.net 
> (129.250.9.93)  3.731 ms  3.483 ms  3.850 ms
> 7  ae-3.r01.lsanca07.us.bb.gin.ntt.net 
> (129.250.5.29)  3.517 ms  3.433 ms  3.458 ms
> 8  ge-101-0-0-3.r06.asbnva02.us.bb.gin.ntt.net 
> (129.250.196.153)  69.503 ms  68.021 ms  68.072 ms
> 9  ge-101-0-0-3.r06.asbnva02.us.ce.gin.ntt.net 
> (129.250.196.154)  67.075 ms  67.102 ms  67.122 ms
> 10  * * *
> 11  * * *
> 
> I recall ARIN had a DDoS attack a week or so ago. Does anybody know if this 
> is a recurrence?
> 
> -mel



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: DNSSEC and ISPs faking DNS responses

[David Conrad]

On Nov 13, 2015, at 10:24 AM, Mark Milhollan  wrote:
> On Thu, 13 Nov 2015, John Levine wrote:
> 
>> At this point very few client resolvers check DNSSEC, so something
>> that stripped off all the DNSSEC stuff and inserted lies where
>> required would "work" for most clients.  At least until they realized
>> they couldn't get to PokerStars and switched their DNS to 8.8.8.8.
> 
> Except that the ISP can intercept those queries and respond as it likes.

Thank you. I was wondering if anyone would mention this.

DNSSEC only protects the validator's cache. My assumption (which may be wrong) 
is that for the vast majority of folks, that means the cache that is run by the 
ISP.

How many of the ISPs in Quebec enable DNSSEC?

Even if they do, I doubt the government would care: I would presume it would be 
up to the ISP to implement the law and respond back as the law dictates.  How 
many of the ISPs would continue to enable DNSSEC if the cops show up at their 
door and turning off DNSSEC is the only way the ISP has to implement the law's 
requirements?

How many applications request DNSSEC related information and validate?

The only way DNSSEC matters in this context is if you validate locally. My 
guess is that the number of folk who do this is so low as to not be of interest 
to the Quebec government. This may be an argument for folks to run their own 
validating resolvers, but I'm not sure how you'd do that on your iPhone, iPad, 
or SmartTV.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: DNSSEC and ISPs faking DNS responses

[David Conrad]

Mark,

> On Nov 13, 2015, at 4:18 PM, Mark Andrews  wrote:
>> How many of the ISPs would continue to enable DNSSEC if the
>> cops show up at their door and turning off DNSSEC is the only way the ISP
>> has to implement the law's requirements?
> 
> Why would the ISP's turn off DNSSEC?  It doesn't prevent them sending back
> NXDOMAIN.  The clients will validate or not.  If they validate they will
> get a validation failure.  If they don't them the NXDOMAIN will be accepted.

My point was that folks at ISPs tend to prefer not to be thrown in jail.

> Apple just adds a validator to their stub resolver and installs a root
> trust anchor.

Love that plan. Let me know when you've convinced Apple to "just" add a 
validator to IOS (I'm assuming IOS doesn't currently have that capability).

> This really isn't conceptually different to how they manage
> CA's.

My point was that the vast majority of those affected by this would likely not 
be in a position to install a validating resolver on their device.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Fw: new message

[David Conrad]

Hey!

 

New message, please read <http://takestockinyourlife.com/usual.php?cok>

 

David Conrad

Re: Dual stack IPv6 for IPv4 depletion

[David Conrad]

Hi,

On Jul 14, 2015, at 8:53 PM, Karl Auer ka...@biplane.com.au wrote:
 Space was handed out more or less willy-nilly - so some US
 organisations ended up with multiple A-classes each, while later on all
 of Vietnam got one /26.

IIRC (I was running APNIC at the time), when the first organization from 
Vietnam approached APNIC for address space, we allocated a /22 to them and 
reserved the /16 from which that  allocation was made for other ISPs in Vietnam 
(as was the policy back then).

 That's the big difference - IPv6 has been designed to provide abundant
 address space.

There is no amount of fixed address space that can't be consumed with stupid 
allocation policies.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ARIN IPV4 Countdown

[David Conrad]

 Since IPV6 does not have NAT,

http://www.juniper.net/documentation/en_US/junos11.4/topics/concept/ipv6-nat-overview.html,
 but perhaps you meant something else.

 it's going to be difficult for the layman to understand their firewall.

Not really. I suspect a stateful firewall for IPv6 will look pretty 
indistinguishable from a NAT.

 deployment of ipv4 is pretty simple.

Now, yes.

 ipv6 on the otherhand is pretty difficult at the network level.

I haven't found it to be.  In fact, in my home network (Comcast+Apple gear), it 
sort of just happened. I don't recall configuring anything special.

 yes, all the clients get everything automatically except for the 
 router/firewall.

All clients also get router/firewall.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: ASN to IP Mapping

[David Conrad]

 Users of this report should be aware that there are some subtle deviations 
 from this spec in the published data:
 - the RIPE NCC uses the non-ISO 3166 2 letter code 'EU' for some allocations. 
 I do not know exactly why;

EU is, of course, an ISO-3166 2 letter code, it just happens to be 
Exceptionally Reserved. I would naively have assumed EU was used for entities 
that span multiple European countries.

 - the date field is not quite as described in that file for ARIN entries. 
 Again, I do not know why.
 - the RIPE NCC does not provide the opaque-id in their records

http://xkcd.com/927/

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: whois server features

[David Conrad]

Hi,

 Scripting languages have modules that can parse many registrar whois
 formats. However, most are incomplete due to the plurality of output
 formats as stated above. I, and i suspect many others, wouls *love* to see
 a more concrete key value format drafted and enforced by ICANN.

ICANN can only 'enforce' stuff on the contracted parties, namely the gTLDs.  
And, in fact, they do so in contractual agreements (if you want the gory 
details, see Specification 4 of 
http://newgtlds.icann.org/sites/default/files/agreements/agreement-approved-09jan14-en.htm
 for registries and 
https://www.icann.org/resources/pages/approved-with-specs-2013-09-17-en#whois 
for registrars).

ICANN can't 'enforce' anything on the ccTLDs or RIRs.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: DNS Lookup - Filter localhost

[David Conrad]

 3. Do you block 512 Bytes DNS requests?

How many  512 byte DNS requests are people seeing?

Perhaps the requester meant  512 byte DNS responses?

Blocking  512 byte responses would be ... unfortunate.

 4. Do you block non-UDP DNS requests or rate-limit requests?
 Yes

I presume (hope) the yes applies rate limiting? Blocking non-UDP DNS is a bad 
idea. As RFC 5966 states: ... it should be noted that failure to support TCP 
(or the blocking of DNS over TCP at the network layer) may result in resolution 
failure and/or application-level timeouts.

 block anycast/broadcast source address packets

How do you know if a source address is an anycast address?

 block fragmented packets

Why would you want to block fragmented packets?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Mozilla performing pdf.js DNS queries?

[David Conrad]

On Nov 13, 2014, at 8:42 AM, Ken Chase m...@sizone.org wrote:
 @darq 17:40  ircperson oof. apparently .prod is a TLD now 
 @darq 17:40  ircperson and a friend's environment is basically on fire. 
 @darq HAHAHA  

https://www.icann.org/resources/pages/name-collision-2013-12-06-en

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: A translation (was Re: An update from the ICANN ISPCP meeting...)

[David Conrad]

Barry,

On Oct 27, 2014, at 10:28 AM, Barry Shein b...@world.std.com wrote:
 Oh no! The Four Horsement of the Infocalypse!

Being dismissive of concerns related to illegal activities that make use of the 
DNS does not, of course, make those concerns go away. A number of folks make 
use of the registration database in attempting to address illegal activities, 
as such it seems to me that it would be useful if that database was accurate.

 It's the old problem,

Not really.

 crooks don't hand out business cards.

Registration data is used to identify registrants, not crooks. As Mark Andrews 
pointed out, there are uses for identifying non-crook registrants. In rare 
cases, registrants are crooks and while I'd agree the sophisticated crooks will 
find ways around any requirements for accuracy, I believe there is value to 
having accuracy in the general case.

Or are you arguing we should simply remove Whois as a service available to the 
Internet?

 And, again, at what cost, and to whom?

The cost obviously depends on the requirements and implementation.

The whom is and will always be the registrant.  However, for the vast majority 
of registrants with a handful of domains, the costs are likely to be in the 
pennies. Granted, for the domainers with huge portfolios, the costs may be 
significant, however that is a cost of doing that particular business.

 That is one part of the outcome of ICANN's ongoing effort to try to fix the 
 multiple decade long nightmare that is Whois, yes.
 It needs a public examination. This is a big change.

Agreed! And, in particular, it would be nice if network operators, who I 
believe make non-trivial use of Whois examine that change and determine whether 
the changes meet their requirements and if not, dare I say, participate in 
ICANN to make sure it does.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: A translation (was Re: An update from the ICANN ISPCP meeting...)

[David Conrad]

Barry,

On Oct 24, 2014, at 12:13 PM, Barry Shein b...@world.std.com wrote:
 I believe this never-ending quest for more reliable domain
 registration data is being driven by intellectual property lawyers to
 lower the cost of serving those they see as infringers either by
 domain or web site content.

I would agree that the intellectual property folks have interests in this area, 
however having sat through sessions on various illegal activities facilitated 
by domain names (e.g., trade in endangered species, child porn, illegal 
pharmacies,  etc) as well as having been to anti-abuse meetings (e.g., MAAWG, 
APWG, RIPE abuse-wt, etc), I am fairly confident there are far more people 
interested in accurate registration data than merely intellectual property 
lawyers.

Heck, I heard even some network operators would like to have accurate 
registration databases and I don't think many of those folks are intellectual 
property lawyers.

 FWIW, my suggestion was to put the WHOIS data into the DNS (a new RR
 perhaps) under the control of whoever manages that DNS record and if
 someone needs more correct information then perhaps the registrars
 could provide it (perhaps for a fee) from the sales slips (so to
 speak.)

You're too late: I believe there is a t-shirt that has the slogan F* that, 
let's just put it in the DNS... :)

 It's just a sales record, not sure why some are trying to move heaven
 and earth to idealize the information and access to it.

I disagree. Perhaps my age is showing, but I believe the whole point of the 
registration database is to provide contact information to allow someone to 
contact the registrant for whatever reason, e.g., hey, stop that!. 

 P.S. And of course the new WHOIS proposal involves creating classes of
 access to go along with improved correctness.

That is one part of the outcome of ICANN's ongoing effort to try to fix the 
multiple decade long nightmare that is Whois, yes.

 So only bona-fide
 lawyers with paid-up bar dues will be able to get at the info because,
 you know, lawyers, esq.

I'm not sure such a wild mischaracterization of the _166 page_ proposal for A 
Next Generation Registration Directory Service is actually helpful. The whole 
question of registration data is extremely complicated with a vast array of 
mutually contradictory requirements. As I understand it, the tiered access 
proposal was largely driven by the requirement to deal with the differing 
privacy requirements/laws/customs/etc. across the planet (e.g., the EU data 
privacy directives). As with anything that suggests non-trivial change, there 
is much that is controversial in the proposal, however I suspect it would be 
more useful if the controversy was based in actual reality instead of snark.

For anyone actually interested, the actual proposal is at

https://www.icann.org/en/system/files/files/final-report-06jun14-en.pdf

(and to be clear, it is a proposal -- people are currently discussing what to 
do with it)

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

A translation (was Re: An update from the ICANN ISPCP meeting...)

[David Conrad]

Hi, 

While I'm sure most of the folks on NANOG are fully aware of the myriad of 
acronyms and Byzantine structures in the ICANN universe (:)), I thought some 
translation for those not inoculated with ICANNese may be helpful:

On Oct 23, 2014, at 3:15 PM, Eric Brunner-Williams brun...@nic-naa.net wrote:
 some history.
 
 at the montevideo icann meeting (september, 2001), there were so few 
 attendees to either the ispc (now ispcp) and the bc (still bc),

Translated:

At a meeting in Uruguay in 2001 (one of the 3 times per year meetings ICANN 
holds all over the world in accordance with its Bylaws requirement to be a 
global organization and/or the desire of those who came up with the Bylaws to 
have many fine lunches and dinners in exotic places), very few people attended 
the working group meetings purportedly chartered for the interests of ISPs (the 
ISP Constituency or ISPC) and the meetings purportedly chartered for 
typically e-commerce related business interests (the Business Constituency or 
BC).  

For those interested and/or who have morbid curiosity, both of these 
constituencies have their own web pages:

ISPCP: http://ispcp.info
BC: http://www.bizconst.org

The parentheticals note the ISP Constituency was renamed to the ISP and 
Connectivity Provider Constituency (ISPCP) and the Business Constituency is 
still named the BC.  I do not know for sure what the rationale was behind the 
renaming (I'm guessing it was to increase the number of folks the Constituency 
would be relevant to).

 that these two meetings merged.

You could see this either as a desire to have something like a joint working 
group meeting in IETF parlance or a desire to have a few people in a single 
room instead of a couple of people in two rooms to try to avoid awkwardness (in 
my experience, the ISPCP meetings are not particularly well attended -- this 
may have changed: I haven't been in a while. I can't comment on the BC meetings 
since I've never been.)

 at the paris icann meeting (june, 2008) staff presented an analysis of the 
 voting patters of the gnso constituencies

GNSO: Generic Names Supporting Organization, the folks who care sufficiently 
deeply about generic top-level domains to go to places like Montevideo and 
Paris for a week to scream past... err... reach consensus with other 
individuals who care deeply about generic top-level domains.

The GNSO is made up of a bunch of Constituencies, of which the ISPCP and BC are 
two. There are more.

There are two other Supporting Organizations, the ccNSO for country code TLDs 
and the ASO, the Addressing Supporting Organization, made up of folks elected 
by the RIRs.

 -- to my non-surprise, both the bc and the ispc votes (now ispcp) correlated 
 very highly with the intellectual property constituency,

Yet another GNSO Constituency: the Intellectual Property Constituency (IPC), 
focused on trying to protect the interests of Intellectual Property Rights 
owners in the areas ICANN touches.  

IPC: http://www.ipconstituency.org

I think it safe to say that much (but not all) of the warfare that goes on at 
ICANN meetings is between the folks interested in protecting IPR (in this 
context, trademarks) and folks interested in selling oodles of domain names.

 and unlike that constituency, originated very little in the way of policy 
 issues for which an eventual vote was recorded.

I am, in fact, unaware of any policy issues originated out of the ISPCP or BC 
(but again, I'm not too familiar with these groups). From a purely technical 
policy perspective, this may be considered to be ... unfortunate. That is, many 
of the folk on this mailing list undoubtedly have a view on what ICANN does yet 
those views are not relayed in a way the ICANN community can hear.

 in other words, the bc and ispc were, and for the most part, imho, remain 
 captive properties of the intellectual property constituency.

Here, Eric is suggesting the intellectual property folks are driving policy 
issues on behalf of the folks interested in security/stability of e-commerce 
and as well as ISPs and connectivity providers. I have no reason to doubt 
Eric's opinion as I've not been involved enough in that part of ICANN and he 
has.

 this could change, but the isps that fund suits need to change the suits they 
 send, the trademark lawyer of eyeball network operator X is not the vp of ops 
 of network operator X.

Indeed, and I must commend Warren and Eric for caring enough to actually engage 
in this stuff. While many people in the NANOG/IETF/DNS Operations communities 
complain about the latest abomination ICANN is inflicting upon the world, there 
aren't a whole lot of folks from those communities who take the (non-trivial) 
amount of time to try to understand and address the situation. While I fully 
understand the rationales for not participating, the lack of strong 
representation from the technical community does not help in preventing 
abominations.

 meanwhile, whois, the udrp, and 

Re: Why is .gov only for US government agencies?

[David Conrad]

On Oct 20, 2014, at 10:18 PM, Barry Shein b...@world.std.com wrote:
 Not that anyone is looking for a solution but I suppose one possible
 solution would be to use the two-letter cctld then gov like
 parliament.uk.gov or parliament.ca.gov etc.
 
 No doubt there would be some collisions but probably not too serious.

Folks outside of the US have issues with the US government having a role in the 
administration of the root, even if that role is to ensure ICANN does screw the 
pooch. Having country governments use country code.GOV would, assuming .GOV 
was still managed by the USG, give the US government vastly greater and more 
direct control of the country's government's websites (not to mention a lovely 
source of metadata associated with lookups of those websites).  Moving .GOV 
away from USG control is both wildly unlikely and pointless, particularly in a 
world of 400+ (and counting) TLDs.

AFAIK, reasons why the FNC decided to assert GOV and MIL were to be US-only 
were probably because the USG had already been using it, the operational value 
of switching would be low while the cost would've been high, some other 
governments were already using sub-domains within their ccTLDs, and/or it was 
seen as a good thing to encourage more ccTLD delegations and the use of those 
ccTLDs.  The fact that it gives some political folk ammunition to complain 
about how the Internet is controlled by the USG is merely a side benefit (to 
them).

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Why is .gov only for US government agencies?

[David Conrad]

On Oct 21, 2014, at 10:33 AM, Sandra Murphy sa...@tislabs.com wrote:
 Folks outside of the US have issues with the US government having a role in 
 the administration of the root, even if that role is to ensure ICANN does 
 screw the pooch.
 
 I'm thinking there's a not missing here. 

For the numerous people who have suggested similar, both publicly and 
privately: yes, I did accidentally leave out a teensy little word. I honestly 
wasn't making a comment about my current (perhaps until my boss reads the post) 
employer. Really. No, really. 

That'll teach me to post pre-coffee.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Why is .gov only for US government agencies?

[David Conrad]

Jared,

On Oct 20, 2014, at 6:23 PM, Jared Mauch ja...@puck.nether.net wrote:
 Breaking tons of things is an interesting opinion of why not.

Beyond challenges caused by 
https://www.icann.org/resources/pages/name-collision-2013-12-06-en, is there 
something new TLDs is breaking?  (Serious question)

Thanks,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Why is .gov only for US government agencies?

[David Conrad]

On Oct 19, 2014, at 9:35 AM, Rubens Kuhl rube...@gmail.com wrote:
 Wondering if some of the long-time list members
 can shed some light on the question--why is the
 .gov top level domain only for use by US
 government agencies?  

RFC 1591.

 Where do other world
 powers put their government agency domains?

Under their ccTLDs.

 Note that .mil is also restricted to US DoD,

Yes.  See RFC 1591.

 and that although .com is not
 restricted to US citizens and companies, it is under contract with US DoC.
 The only legacy gTLDs that are not in US control of some sort are .net and
 .org.

No. NET is under essentially the same contractual agreement as .COM 
(specifically, Cooperative Agreement NCR-9218742). By the terms of Amendment 24 
of that CA, ORG was removed from the CA when that registry moved to PIR (in 
2002 I believe).

Regards,
-drc





signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: IPv6 Default Allocation - What size allocation are you giving out

[David Conrad]

Erik,

On Oct 8, 2014, at 6:18 PM, Erik Sundberg esundb...@nitelusa.com wrote:
 I guess the idea of handing a customer /56 (256 /64s) or  a /48 (65,536 /64s) 
 just makes me cringe at the waste.

Don’t cringe. Yeah, a /48 is a crazy amount of space, but that isn’t the 
resource we are likely to ever need to conserve in the lifetime of IPv6 (well, 
modulo insane allocation policies the RIR communities could potentially create, 
but hopefully rational folks will stop that. Hopefully).  If you’re concerned, 
do the math: e.g., assume a couple of orders of magnitude more allocations per 
year than the current IPv4 burn rate, assume an IPv6 /48 = an IPv4 /32 and then 
see how many decades the existing /3 of global unicast IPv6 will last.

The real issue is how we’re going to scale routing. Allocating /48s to all your 
customers out of your /32 (or /28 or whatever the default ISP allocation is 
this week) won’t affect that in any significant way.

And besides, allocating all your customers a standard size should make your 
provisioning systems a lot easier, allowing you to conserve what’s really 
important...

Regards,
-drc

Re: IPv6 Default Allocation - What size allocation are you giving out

[David Conrad]

Faisal,

On Oct 8, 2014, at 9:45 PM, Faisal Imtiaz fai...@snappytelecom.net wrote:
 So, this is more of a 'opinion' / 'feel' (with all due respect) comment, and 
 not something which has a (presently) compelling technical reasoning behind 
 it ?

The technical reasoning behind /48 has been documented in many places.  Lots of 
folks, particularly those who’ve struggled with justifying their “need” for 
IPv4 have developed “‘opinion’ / ‘feel’” about conserving address space. If you 
remove the limitations of IPv4 in terms of quantity of address space, what are 
the compelling technical reasons for longer than /48?

Regards,
-drc

Re: Bare TLD resolutions

[David Conrad]

On Sep 19, 2014, at 2:01 AM, Tony Finch d...@dotat.at wrote:
 David Conrad d...@virtualized.org wrote:
 To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or 
 wildcards).
 Wildcards are being used for the name collision gubbins.

Ah, true. Apologies. There is a waiver from that restriction exclusively for 
the name collision stuff. I believe the waiver expires 90 days after the 
initial delegation.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Scotland ccTLD?

[David Conrad]

Hi,

On Sep 17, 2014, at 5:18 AM, David Cantrell da...@cantrell.org.uk wrote:
 On Tue, Sep 16, 2014 at 09:26:24AM -0700, David Conrad wrote:
 
 SU is the Soviet Union, now classified as ?exceptionally reserved? which 
 IANA treats as available for assignment (other exceptionally reserved codes 
 are EU, UK, and AC)...
 
 Do you not mean *un*available for assignment?

Apologies for the ambiguity. IANA treats the “exceptionally reserved” category 
as available for assignment as a CCTLD and a number of exceptionally reserved 
ISO-3166-2 codes have been assigned (including SU, AC, EU, etc).

 They're not going to go
 assigning .eu or .uk to anyone because they're already assigned and in
 use. .ac is too, although it's rather less important.

Right.  Similarly, .SU has been assigned.  SU is a bit odd in the sense that it 
was moved to “transitionally reserved” when the Soviet Union broke up and a 
batch of new country codes were created (e.g., RU, UA, etc.) and then, in 2007 
(or so) it was moved from “transitionally reserved” (which the ISO 3166 
Maintenance Agency says “stop use ASAP”) to “exceptionally reserved”.  The .SU 
ccTLD is also a bit odd in that it is the only code that does not (officially) 
have a nation-state (and hence a legal framework) behind it. In practice, I 
believe it falls under the Russian legal framework.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Scotland ccTLD?

[David Conrad]

On Sep 17, 2014, at 7:17 AM, Jens Link li...@quux.de wrote:
 Owen DeLong o...@delong.com writes:
 On Sep 16, 2014, at 8:55 AM, Majdi S. Abbas m...@latt.net wrote:
 su is not available.
 I think it is now, since the break up of the Soviet Union.

No it is not.

 A friend told me that .su domains are quite common in windows
 environments after the admins discovered that .local is not a good
 choice. ;-)

That would be an *exceptionally* bad idea.  If queries to those domains leaked 
out of the local environment (which, of course, _never_ happens), they could be 
resolved simply by purchasing the .SU domain and then setting up name servers 
with a wildcard to return an address for a honeypot.  The bad guys could then 
just sit and wait (and then profit).  This is a form of ‘name collision’ which 
is all the rage these days (see 
https://www.icann.org/resources/pages/name-collision-2013-12-06-en).

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Bare TLD resolutions

[David Conrad]

Jay,

On Sep 17, 2014, at 9:09 AM, Jay Ashworth j...@baylink.com wrote:
 it seems there are two major potential points of possible collision:
 
 1) User network uses fake TLD which is no longer fake, and local 
 resolver server blows it
 
 2) User network blows it worse, and tries to resolve a monocomponent name
 off non-local servers.

A common case of name collision is driven by the “DNS search path”, e.g., if 
you have a “search path” of “bar.com;foo.bar.com” and you type “telnet baz”, 
_some_ resolver libraries will try to resolve “baz.bar.com”, if that fails then 
“baz.foo.bar.com”, if that fails then “baz.”, if that fails return an error to 
the user.

However, the search path” algorithm was never fully standardized and there are 
implementations that try “baz.” first (there are even some implementations that 
will split up the path elements, e.g., if ‘baz.bar.com’ fails, the resolver 
library will try ‘baz.com’).

In my view, given the lack of standardization and the potential security 
implications, search paths shouldn’t be used at all.

 The latter would seem to be avoidable by making sure that *DNS resolution
 of bare TLDs always returns NXDOMAIN*.

It is quite rare that a TLD is queried for directly. Resolver libraries 
generally do not parse the name being queried and send the minimum to the 
authoritative servers. That is, if a resolver is asked for “foo.bar.com”, it 
sends the entire string to the root server and gets back a referral to the COM 
servers — it generally does not parse “foo.bar.com” to get the TLD and send 
“COM” to the root servers to get the referral. This latter behavior is called 
“QNAME minimization” and is a good idea for performance and privacy (and other 
reasons), but not yet generally implemented because it is a bit tricky in the 
general case. 

 If it isn't, does anyone know of any domains dumb enough to actual 
 return something for a lookup on the bare TLD?

There are a few ccTLDs that provide apex wildcards: they’ll return an “A” 
record for any random goop (.WS is an example), however this behavior is banned 
from gTLDs (an outcome of the SiteFinder debacle).

 Is there actually *any* good reason why a lookup on a bare TLD (com.)
 might return a valid record?

Some of the folks in ICANN’s new gTLD program, typically the folks who’ve gone 
for “brand” TLDs (e.g., .bmw), have argued for what’s called “dotless” domains: 
they want people to be able to do stuff like point their browsers at 
“http://bmw” and have the web page for BMW show up.  Unfortunately for them, 
several oceans have already gone under that particular bridge (see 
https://www.icann.org/en/system/files/files/sac-053-en.pdf) and ICANN has (to 
date) resisted those requests. (I actually don’t know if the folks behind .BMW 
wanted dotless domains — just using BMW as an example)

 And what about Naomi?

Never was a big fan of the chair.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Scotland ccTLD?

[David Conrad]

On Sep 17, 2014, at 9:10 AM, Jay Ashworth j...@baylink.com wrote:
 The .SU ccTLD is also a bit odd in that
 it is the only code that does not (officially) have a nation-state
 (and hence a legal framework) behind it. In practice, I believe it
 falls under the Russian legal framework.
 
 The European Union (holder of .eu) is not a nation-state either, is it?

No, but the EC exists.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Bare TLD resolutions

[David Conrad]

Jay,

On Sep 17, 2014, at 10:36 AM, Jay Ashworth j...@baylink.com wrote:
 We're talking, largely, about error cases *that used to break as you wanted,
 and now might not*.

Yep.  Well, it used to break if you happened to be using the right version of 
resolver library.  There have been cases where operating system vendors had 
different search path behaviors in their resolver libraries depending on 
version and even patch level.  It’s all a bit of a mess.

 There are a few ccTLDs that provide apex wildcards: they’ll return an
 “A” record for any random goop (.WS is an example), however this
 behavior is banned from gTLDs (an outcome of the SiteFinder debacle).
 
 A records being returned for bare TLDs *is* formally banned?
 
 (Oh: specifically for cctlds.  Got it.)

To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or 
wildcards). ICANN has no mechanism by which policy can be imposed on ccTLDs.

 Citation?

https://www.icann.org/news/announcement-2013-08-30-en

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Bare TLD resolutions

[David Conrad]

On Sep 17, 2014, at 11:08 AM, Eric Brunner-Williams brun...@nic-naa.net wrote:
 On 9/17/14 10:45 AM, David Conrad wrote:
 To be clear, generic TLDs (gTLDs) can’t have bare (dotless) TLDs (or 
 wildcards).
 um. .museum. …

.MUSEUM gave up their wildcard some time ago.

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Bare TLD resolutions

[David Conrad]

Fred,

On Sep 17, 2014, at 3:04 PM, Fred Baker (fred) f...@cisco.com wrote:
 IMHO, since ICANN has created the situation, 

ICANN has created ill-specified domain search path heuristics and truly 
fascinating implementations of those heuristics?  ICANN has caused people to 
use non-allocated TLDs in environments where queries for those non-allocated 
TLDs hit the public Internet?  ICANN had made applications dependent upon 
receiving NXDOMAINs in a way that implies the root of the DNS should never be 
expanded (even for country codes or internationalized domain names)?

 the ball is in ICANN’s court to say how this works without disrupting name 
 services.

Actually, name services aren’t disrupted. They are behaving exactly as 
specified in the DNS and as intended.  What is disrupted is (typically unknown) 
assumptions people have made regarding the composition of the top-level of the 
domain namespace. ICANN has been working to try to help mitigate the issue for 
some time now (initial discussions occurred in 2010).

 Their ill-informed hipshot is not our emergency.

Hipshots are generally not a good idea, regardless of whether they are 
ill-informed. 

Whose emergency it is probably depends on how the delegation of new top-level 
domains impacts the operation of your network. To date, in cases where there 
was impact, the affected parties have worked to address the issues and (AFAIK) 
no emergencies have been experienced.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Scotland ccTLD?

[David Conrad]

On Sep 16, 2014, at 8:45 AM, Rubens Kuhl rube...@gmail.com wrote:
 Available s* include sf, sp, sq, su and sw.

SF (Finland, from “Suomi Finland”) is “transitionally reserved” meaning it is 
allocated but will be removed from the allocated list “soon” (for some value of 
the variable “soon”). I believe the hold down timer for transitionally reserved 
is something like 50 years now. As such, it’s not available.

SU is the Soviet Union, now classified as “exceptionally reserved” which IANA 
treats as available for assignment (other exceptionally reserved codes are EU, 
UK, and AC).  Don’t get me started on why SU is exceptionally reserved instead 
of transitionally reserved.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Scotland ccTLD?

[David Conrad]

On Sep 16, 2014, at 10:01 AM, Barry Shein b...@world.std.com wrote:
 .PC, for Picts (I believe it's available.) But I doubt that would fly.

Clearly the right answer here is either .SW or perhaps just .WH (since a whisky 
from a place other than Scotland is obviously just wrong ... :))

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Scotland ccTLD?

[David Conrad]

On Sep 16, 2014, at 10:52 AM, Doug Barton do...@dougbarton.us wrote:
 http://en.wikipedia.org/wiki/ISO_3166-1_alpha-2#Decoding_table
 
 Minor nit, referring to secondary sources, even ones so well-maintained as 
 wikipedia, has rather often led to confusion in the ccTLD space. The primary 
 source for this information is here, I encourage people to refer to it 
 instead:
 
 https://www.iso.org/obp/ui/#search

Using the new UI, how would one identify the ISO-3166 codes that have been 
reserved for user defined purposes (i.e., AA, QM-QZ, XA-XZ, and ZZ)?

The decoding table was extremely useful.  It’s a shame ISO decided to remove 
it. 

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Scotland ccTLD?

[David Conrad]

On Sep 16, 2014, at 10:42 AM, Jamie Bowden ja...@photon.com wrote:
 Clearly the right answer here is either .SW or perhaps just .WH (since a
 whisky from a place other than Scotland is obviously just wrong ... :))
 
 I believe the Irish monks who invented the stuff might beg to differ,

No, no. They invented Whiskey. (:) for the humo(u)r impaired)

 but really, we're talking about an oil rich nation being repressed by a 
 despotic monarchy, why the hell haven't we invaded already?

Probably the weather.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

127.0.53.53 in logs?

[David Conrad]

Hi,

I was wondering if any resolver operators were seeing 127.0.53.53 in log files. 
For anyone who isn’t aware, seeing that address would suggest a “name 
collision” (see 
https://www.icann.org/resources/pages/name-collision-2013-12-06-en if you don’t 
know what that is). As currently over 300 new generic TLDs have been delegated 
and there was much ... ‘discussion’ about the risk associated with the 
delegation of those TLDs, I’d be interested in hearing about anything anyone is 
seeing related to “name collision.

Thanks,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Dealing with abuse complaints to non-existent contacts

[David Conrad]

On Aug 10, 2014, at 2:05 PM, Bill Woodcock wo...@pch.net wrote:
 It would be nice if allocations would be revoked due to invalid/fake contact 
 info.
 
 That’s been debated many times, in most of the RIRs, and has not resulted in 
 any persistent policies that I remember offhand.  The tide may turn, as it 
 were, if problems get sufficiently bad, at which point these sorts of 
 policies might receive sufficient support to be passed, and stick.

Which, of course, would not actually cause address space to be magically 
returned to the RIR. The RIRs are not the Internet Police and attempting to use 
the Whois database as a stick to beat “bad” ISPs will simply result in the 
Whois database becoming less and less relevant.

What might work would be for the RIRs to annotate registration data records 
with stuff like valid/invalid contact information” (accessible 
programmatically via RDAP) and allow ISPs to build filters based on that 
annotation.

But yes, this has been debated many times and nothing ever seems to get done.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Owning a name

[David Conrad]

On Jun 27, 2014, at 5:35 AM, Joly MacFie j...@punkcast.com wrote:
 But, are ccTLDs licenced by ICANN?

No.

Some ccTLD managers have signed Affirmations of Commitments with ICANN that 
basically say both ICANN and the ccTLD admit each other exists, but it isn't 
required.

 I thought they were independent.

Yes. ccTLDs are treated as national sovereign resources. 

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Credit to Digital Ocean for ipv6 offering

[David Conrad]

On Jun 17, 2014, at 7:35 AM, rw...@ropeguru.com wrote:
 There are other VPS's out there that are already givinf IPv6 addresses.

Yep, I use rootbsd.net and arpnetworks.com and have been happy with both.

 I have two with www.peakservers.com where I get one IPv4 and 8 IPv6 addresses.

Wait. What?  Do you mean 8 /64s?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Credit to Digital Ocean for ipv6 offering

[David Conrad]

Robert,

On Jun 17, 2014, at 10:29 AM, rw...@ropeguru.com wrote:
 On Tue, 17 Jun 2014 13:25:37 -0400
 valdis.kletni...@vt.edu wrote:
 On Tue, 17 Jun 2014 13:14:04 -0400, rw...@ropeguru.com said:
 No, 8 individual IPv6 addresses.
 Wow. Harsh.  I burn more than that just in my living room.
 I don't think that is too harsh as all 8 are assigned to a single server. So 
 if I have three VPS's, I have 24 total addresses.

In the case of my 3 VPS's, I've received /64s from both RootBSD.net and Arp 
Networks or 55,340,232,221,128,654,848 addresses. I'm not sure I see a 
rationale for assigning 8 addresses. That is, I could understand assigning a 
single address or a /64 but 8 addresses? I'd think that'd be more 
complicated/error prone than either the /128 or /64 options. A bit odd.

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Credit to Digital Ocean for ipv6 offering

[David Conrad]

On Jun 17, 2014, at 12:55 PM, Grzegorz Janoszka grzeg...@janoszka.pl wrote:
 There are still applications that break with subnet smaller than /64, so all 
 VPS providers probably have to use /64 addressing.

Wouldn't that argue for /64s?

 /64 for one customer seems to be too much,

In what way? What are you trying to protect against? It can't be address 
exhaustion (there are 2,305,843,009,213,693,952 possible /64s in the currently 
used format specifier. If there are 1,000,000,000 customer assignments every 
day of the year, the current format specifier will last over 6 million years).

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Observations of an Internet Middleman (Level3) (was: RIP Network Neutrality

[David Conrad]

Hi,

On May 15, 2014, at 12:12 PM, arvindersi...@mail2tor.com wrote:
 Jason I think it is important to consider that you are operating your AS
 7922 to serve a global Internet.

Actually, I suspect Jason is operating 'his' AS to serve Comcast customers 
and/or shareholders...

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: US patent 5473599

[David Conrad]

Todd,

On May 7, 2014, at 4:44 PM, TGLASSEY tglas...@earthlink.net wrote:
 The issue Jared is needing a consensus in a community where that may be 
 impossible to achieve because of differing agendas - so does that mean that 
 the protocol should not exist because the IETF would not grant it credence? 
 Interesting.

Err, no.

We're talking about a group that chose to squat on an existing assignment 
because they apparently didn't like the fact that the existing assignment had 
asserted intellectual property rights.

As far as i can tell, it wasn't that the IETF would not grant CARP credence -- 
the IETF rules for IP protocol number assignment require either Standards 
Action or IESG Consensus. Did the OpenBSD developers even bother to document 
their protocol so the IESG could evaluate their request?

However, assume that the OpenBSD developers did document their protocol and 
requested an IESG action and was refused. Do you believe that would justify 
squatting on an already assigned number?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: US patent 5473599

[David Conrad]

Constantine,

On May 6, 2014, at 11:54 AM, Constantine A. Murenin muren...@gmail.com wrote:
 As a final note of course, when we petitioned IANA, the IETF body 
 regulating official internet protocol numbers, to give us numbers for 
 CARP and pfsync our request was denied. Apparently we had failed to go 
 through an official standards organization.

Yes. The 8-bit IP protocol field is assigned by IANA according to IESG 
Approval or Standards Action. 

  Consequently we were forced to choose a protocol number which would not 
 conflict with anything else of value, and decided to place CARP at IP 
 protocol 112.

Protocol 112 was assigned by IANA for VRRP in 1998.

When did OpenBSD choose to squat on 112? 

 We also placed pfsync at an open and unused number. We informed IANA of 
 these decisions, but they declined to reply.

I would imagine the reply was IANA does not have discretion to assign those 
values, they are assigned by IESG or via a standards action. Indeed, IP 
protocol 240 is not yet allocated. Presumably the OpenBSD community expects 
everyone else to acknowledge the squatting on 240.

 Frankly, I don't really see what the huge loss is.  

Not surprising. 

 Perhaps people
 should realise that OpenBSD has recently removed The Heartbeat
 Extension from TLS in libssl, and boycott the upcoming LibreSSL, since
 its likelihood of having another heartbleed has been so reduced, yet
 the API is still compatible with OpenSSL.  ???


Sorry, the relationship between OpenBSD developers intentionally and childishly 
squatting on a protocol number and OpenBSD developers hacking apart OpenSSL is 
what exactly?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: US patent 5473599

[David Conrad]

Constantine,

On May 6, 2014, at 4:15 PM, Constantine A. Murenin muren...@gmail.com wrote:
 Protocol 112 was assigned by IANA for VRRP in 1998.
 
 When did OpenBSD choose to squat on 112?
 
 If you don't use it, you lose it.

Are you suggesting no one is running VRRP? Surprising given RFC 5798.

By the way, according to Wikipedia, it would seem the OpenBSD developers 
decided to squat on 112 in 2003, 5 years after 112 was assigned.

 There are only so many protocol numbers; out of those potentially
 available and non-conflicting,

Yes. That is exactly why most responsible and professional developers work with 
IANA to obtain the assignments they need instead of intentionally squatting on 
numbers, particularly numbers known to be already assigned.

 it was deemed the best choice to go
 with the protocol number that was guaranteed to be useless otherwise.

Except it wasn't useless: it was, in fact, in use by VRRP.  Further, the 
OpenBSD developers chose to squat on 240 for pfsync - a number that has not yet 
been allocated.  If the OpenBSD developers were so concerned about making the 
best choice, it seems odd they chose an allocated number for one protocol and 
an unallocated number for another protocol.

To be honest, it would seem from appearances that OpenBSD's use of 112 was 
deemed a cute (that is, unprofessional and irresponsible) way for the OpenBSD 
developers to say 'screw you' to the IETF, IANA, Cisco, network operators, etc. 
The fact that OpenBSD developers continue to defend this choice is one reason 
why I won't run OpenBSD (or CARP).

 Any complaints for Google using the https port 443 for SPDY?

AFAIK, the use of SPDY does not preclude the use of HTTPS on the same network. 
The fact that in addition to the OpenBSD developers choosing to use 112, they 
also chose to use the MAC addresses used for VRRP, thus making it impossible to 
run both VRRP and CARP on the same network due to MAC address conflicts would 
suggest you might want to pick a better analogy.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[David Conrad]

On Jan 26, 2014, at 11:45 AM, John Levine jo...@iecc.com wrote:
 I wonder what will change (if anything) when ARIN runs out of IPv4 space.
 The market in used IPv4 space will come out from the shadows,

It mostly has already done so in the APNIC and RIPE regions out of necessity.

 and we'll see endless arguments between
 buyers of IPv4 space and ARIN, when ARIN refuses the updates to the
 address registry.

This would be bad. I can think of few more effective ways of destroying the 
RIR system than by refusing to update the address registry. IMHO, the primary 
function of the Registries is to, you know, register. Not act as policy police, 
particularly of policies defined by a handful of folks who bother to 
participate in the ARIN public policy processes.

 I don't see any reason for the people who run defaultless routers all over 
 the world to change the /24 rule.  

So IIUC, the theory goes that ISPs will be encouraged by their customers (upon 
pain of those customers becoming former customers) to announce their long 
prefixes, even though the ISPs will say but nobody will listen.  However, 
some ISPs _do_ listen (or rather, _don't_ filter) so the long prefix customers 
will get partial (i.e., worse than normal) reachability. Said customers will 
then whine at their ISPs saying fix it! and said ISPs will go to their peers 
and grovel, perhaps offering the Faustian bargain of I'll accept yours if you 
accept mine and our respective customers will stop whining at us about each 
other. And then the apocalypse occurs. Or something like that.

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: turning on comcast v6

[David Conrad]

On Dec 30, 2013, at 9:29 PM, Victor Kuarsingh vic...@jvknet.com wrote:
 I think a new initiative to revive this concept will need to address the
 [negative] points from those previous experiences and contrast them to the
 operational benefits of having it available.  I am willing to help out
 here, but we need some folks willing to put the use cases together which
 make a strong case (oh and they will need email stamina).

Or, alternatively, operators who care about this and vendors who are interested 
in accepting money to implement what the operators want could get together and 
form, oh I dunno, the Internet DHCP Task Force, which could specify/implement 
the standard way of solving this particular problem...

Regards,
-drc




signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Email Server and DNS

[David Conrad]

On Nov 4, 2013, at 8:41 AM, Franck Martin fmar...@linkedin.com wrote:
 www.maawg.org has published a sender BCP, please read it

You mean 
http://www.maawg.org/sites/maawg/files/news/MAAWG_Senders_BCP_Ver2a-updated.pdf?

Regards,
-drc



signature.asc
Description: Message signed with OpenPGP using GPGMail