Re: U.S. test of national alerts on Oct. 4 at 2:20pm EDT (1820 UTC)

[Fred Baker]

It’s been absurd for a while now…Sent using a machine that autocorrects in interesting ways...On Oct 6, 2023, at 1:15 PM, Warren Kumari  wrote:On Fri, Oct 06, 2023 at 2:58 PM, Sean Donelan  wrote:
The Disability Advocacy Community has been extensively involved with 
CMAS/WEA since President Bush signed the WARN Act, passed by a republican 
house and republican senate, in 2006.

The dozens of disability groups helped design the sound and vibration 
cadence (which is different than EAS), and the policies for alerting.

Nation-wide testing (EAS) has been conducted since 2011.  And nation-wide 
testing (WEA) since 2014.  National tests were conducted almost every 
between 2011 and 2020, suspended during the pandemic.

The national tests are announced at least 60 days in advance by the FCC 
and FEMA. News media have multiple stories.  Most state and many local 
goverments also had notifications.

If you haven't been involved with the disability community for a decade, 
and your school office didn't notify special education teachers about the 
news releases and government advance notifications, perhaps that's room 
for improvement with local school communications.  Fire drills, tornado 
drills, etc. often involve loud sounds and flashing lights.Fine! In that case I *demand* that we stop having fires and tornados and similar. It's super-disruptive to have to go and hide in my basement *every single time* there is a tornado, or pull over every time a fire engine comes barreling down the road…. and those sirens!... and the flashy lights! Wake up people, fire truck and police sirens are *specifically designed* to disrupt! It's all part of their plan to, erm…. well, something something….Ok, now that we have reached the absurdum part of reductio ad absurdum can we get back to network engineering?W

Re: Lossy cogent p2p experiences?

[Fred Baker]

It was intended to detect congestion. The obvious response was in some way to 
pace the sender(s) so that it was alleviated.

Sent using a machine that autocorrects in interesting ways...

> On Sep 7, 2023, at 11:19 PM, Mark Tinka  wrote:
> 
> 
> 
>> On 9/7/23 09:51, Saku Ytti wrote:
>> 
>> Perhaps if congestion control used latency or FEC instead of loss, we
>> could tolerate reordering while not underperforming under loss, but
>> I'm sure in decades following that decision we'd learn new ways how we
>> don't understand any of this.
> 
> Isn't this partly what ECN was meant for? It's so old I barely remember what 
> it was meant to solve :-).
> 
> Mark.

Re: Caveat emptor: avoid Inseego 5G products unless you still believe in classful routing

[Fred Baker]

If they think classful IPv4 is the state of the art, I would not assume they have heard of IPv6.Sent using a machine that autocorrects in interesting ways...On Mar 28, 2023, at 12:45 PM, Matt Harris  wrote:Matt Harris​VP OF INFRASTRUCTUREFollow us on LinkedIn!matt.har...@netfire.net816-256-5446www.netfire.comOn Tue, Mar 28, 2023 at 2:25 PM Matthew Petach  wrote:In the category of "I can't believe I still have to worry about this in 2023" comes an unfortunate discovery I made recently when setting up a network for a local non-profit.  The Inseego FX2000 5G router looked like a nice product, it supports OpenVPN out of the box, flexible firewall rules, etc.What I did *NOT* expect from a device made in 2023, and didn't think to ask about ahead of time, is whether it supported classless routing.Setting the unit up, I discovered the hard way that the developers are apparently still working from 1989 textbooks.  The only netmask the router will accept for a 10.x.x.x. subnet is 255.0.0.0.  Absolutely refuses to accept a different length netmask.Even the user manual reflects the inherent classful assumption:"IPv4 IP Address: The IP address for your FX2000, as seen from the local network. Normally, you can
use the default value. Subnet Mask: The subnet mask network setting for the FX2000. The default value 255.255.255.0
is standard for small (class "C") networks. If you change the LAN IP Address, make sure to use
the correct Subnet mask for the IP address range of the LAN IP address"So, before anyone else makes the same mistake I did, I thought I'd give the community a heads-up to avoid the Inseego line of 5G products, as they're woefully behind the times in their understanding of IPv4 subnetting as it exists in 2023.  ^_^;Thanks!MattBut how is their IPv6 support? ;)

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

[Fred Baker]

> What's the group's current thought on emergence or prevalence of
> IPv6-only hosts ?

They aren’t needed; dual stack hosts will work just fine in a single stack 
network. When they’re needed, they will be normal but nobody will care.

Re: Jon Postel Re: 202210301538.AYC

[Fred Baker]

Sent using a machine that autocorrects in interesting ways...

> On Nov 2, 2022, at 5:50 PM, Donald Eastlake  wrote:
> 
> In the early years of the
> NomCom, I believe there were a small number of cases of a 3 year term
> but only for an AD who had already successfully served for 2 years.

There were two such cases - Jeff Schiller and myself. The situation was that in 
1997 (IIRC) we had  four areas with a single AD, and the IESG told the nomcom 
that the imbalance was strange. At its option, the nomcom could extend the term 
of a sitting AD that wasn’t up for renewal/replacement by one year to even 
things out. They did. In 2001, I resigned, and I think Jeff resigned in 1999.

Re: IoT - The end of the internet

[Fred Baker]

> On Aug 9, 2022, at 8:06 PM, Mel Beckman  wrote:
> 
> Robert Metcalfe, InfoWorld columnist and the inventor of Ethernet, also in 
> 1995:
>  “I predict the Internet will soon go spectacularly supernova and in 1996 
> catastrophically collapse.”

In 1998 I invited Mr Metcalfe to address the IETF on the collapse of the 
Internet, which he renewed his prediction of. He declined.

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

[Fred Baker]

Sounds like a comment made on the FCC TAC in 1994: “there is no broadband 
market above 1 MBPS.”

Sent using a machine that autocorrects in interesting ways...

> On May 28, 2022, at 1:46 PM, Randy Bush  wrote:
> 
> 
>> 
>> Saying most people don't need more than 25 Mbps is like saying 640k is
>> enough for anybody.
> 
> somewhere around here i have saved the early '90s message (from a
> self-important person still on this list) saying africa will not need
> anything more than fidonet.
> 
> whole new classes of use emerge when enabled.  same as it ever was.
> 
> randy

Re: Let's Focus on Moving Forward Re: V6 still not supported

[Fred Baker]

Sent using a machine that autocorrects in interesting ways...

> On Apr 2, 2022, at 5:57 AM, Abraham Y. Chen  wrote:
> 
> 1)" ...  darknet ...  ":I am not aware of this terminology. 
> Nonetheless, I believe that bringing in a not commonly known word into a 
> discussion like this is just distraction tactic.

It’s actually a pretty common word for a prefix or other set of addresses used 
to detect address scans. If an address is unused and not in DNS, a packet sent 
to it is not obviously benign, nor is the systemvv be sending it.

Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC

[Fred Baker]

Sent using a machine that autocorrects in interesting ways...

> On Mar 27, 2022, at 12:18 PM, Abraham Y. Chen  wrote:
> 
> I am baffled by why does it cause problems on this mailing list.

Are you aware that NANOG is not an IETF list? What would you guess might be the 
topic of a list associated with a Network Operator Group?

Permit me to comment on what I have seen in this discussion, and what I haven’t 
seen. I would guess that your objective is primarily to build a constituency 
for a replacement paradigm for the Internet - instead of connectivity between 
endpoints, you want it to be connectivity between PABX-like islands. What I 
have observed is a steady patter of email indicating that everyone except you 
is wrong. What I have not observed is an emerging consensus in the direction 
your posted draft suggests.

Food fir thought.

Re: Let's Focus on Moving Forward Re: V6 still not supported Re: 202203261748.AYC

[Fred Baker]

Sent using a machine that autocorrects in interesting ways...

> On Mar 27, 2022, at 12:18 PM, Abraham Y. Chen  wrote:
> 
> Honestly, I am still trying to figure out what is the "required" etiquette, 
> since what I have received were mostly "complaints" not constructive 
> "instructions" (i.e., how about a cheat sheet of what to do and what not to?).

I suspect there are two important rules.

1) every mailing list has a topic.  Post on that topic.

2) a mailing list discussion is a conversation. We all get involved in 
conversations every day. Act as you would in polite conversation.

Re: "Permanent" DST

[Fred Baker]

> On Mar 15, 2022, at 1:24 PM, Elmar K. Bins  wrote:
> 
> 2 - I like how american politics is capable of creating new problems; where
> did this bill come from in the first place? And who's lobbying?

According to the universal time law, the US is on Standard Time unless a state 
chooses Daylight Savings, but most states have chosen the latter. Florida and 
California, and perhaps other states, have passed laws saying that if Congress 
passes a law allowing universal Daylight savings, we'd prefer that. Personally, 
I don' care. 

Re: "Permanent" DST

[Fred Baker]

> On Mar 15, 2022, at 1:01 PM, Mel Beckman  wrote:
> 
> We already have this problem with Arizona, which never changes time for the 
> summer. 

Except for the Navajo Nation…

Re: Dropping support for the .ru top level domain

[Fred Baker]

My viewpoint, and the reason I recommended against it, is that it gives Putin 
something he has wanted for a while, which is a Russia in which he is in 
control of information flows. We do for him what he has wanted for perhaps 20 
years, and come out the bad guys - “the terrible west gut us off!”.  I would 
rather have people in Russia have information flows that have a second 
viewpoint other than the Kremlin’s. I have no expectation that it will get 
through uncensored, but I would rather it was not in any sense “our fault” and 
therefore usable by Putin’s propaganda machine.

Sent from my iPad

> On Mar 14, 2022, at 2:14 PM, Brian R  wrote:
> 
> 
> I can understand governments wanting this to be an option but I would let 
> them do blocking within their countries to their own people if that is their 
> desire.  This is another pandoras box.  Its bad enough that some countries 
> control this already to block free flow of information.
> If global DNS is no longer trusted then many actors will start maintaining 
> their own broken lists (intentionally or unintentionally).
> This will not stop Russia, they will just run their own state sponsored DNS 
> servers.  We can imagine what else might be implemented on that concept...
> Countries or users that still want access will do the same with custom DNS 
> servers.
> This will take us down another path of no return as a global standard that is 
> not political or politically controlled.
> The belief that the internet is open and free (as much as possible) will be 
> broken in one more way.
> This will also accelerate the advancement of crypto DNS like NameCoin (Years 
> ago I liked the idea but I don't know how it is being run anymore.) or 
> UnstoppableDomains for example.   Similar to what is starting to happen to 
> central banking as countries start shutting down bank accounts for political 
> reasons.
> I am glad to see soo many people on here and many of the organizations 
> running these services state as much.
> 
> Brian
> 
> 
> From: NANOG  on behalf of 
> Patrick Bryant 
> Sent: Saturday, March 12, 2022 2:47 AM
> To: nanog@nanog.org 
> Subject: Dropping support for the .ru top level domain
>  
> I don't like the idea of disrupting any Internet service. But the current 
> situation is unprecedented.
> 
> The Achilles Heel of general public use of Internet services has always been 
> the functionality of DNS. 
> 
> Unlike Layer 3 disruptions, dropping or disrupting support for the .ru TLD 
> can be accomplished without disrupting the Russian population's ability to 
> access information and services in the West.
> 
> The only countermeasure would be the distribution of Russian national DNS 
> zones to a multiplicity of individual DNS resolvers within Russia. Russian 
> operators are in fact implementing this countermeasure, but it is a slow and 
> arduous process, and it will entail many of the operational difficulties that 
> existed with distributing Host files, which DNS was implemented to overcome. 
> 
> The .ru TLD could be globally disrupted by dropping the .ru zone from the 13 
> DNS root servers. This would be the most effective action, but would require 
> an authoritative consensus. One level down in DNS delegation are the 5 
> authoritative servers. I will leave it to the imagination of others to 
> envision what action that could be taken there...
> 
> ru  nameserver = a.dns.ripn.net
> ru  nameserver = b.dns.ripn.net
> ru  nameserver = d.dns.ripn.net
> ru  nameserver = e.dns.ripn.net
> ru  nameserver = f.dns.ripn.net
> 
> The impact of any action would take time (days) to propagate.
> 

Re: 202203071610.AYC Re: Making Use of 240/4 NetBlock

[Fred Baker]

On Mar 12, 2022, at 8:15 AM, Abraham Y. Chen  wrote:
> 
> 2)On the other hand, there was a recent APNIC blog that specifically 
> reminded us of a fairly formal request for re-designating the 240/4 netblock 
> back in 2008 (second grey background box). To me, this means whether to 
> change the 240/4 status is not an issue. The question is whether we can 
> identify an application that can maximize its impact.
> 
> https://blog.apnic.net/2022/01/19/ip-addressing-in-2021/  

I think there might be value in reviewing the discussion of the related 
Internet Drafts

https://datatracker.ietf.org/doc/html/draft-deshpande-intarea-ipaddress-reclassification-03
https://mailarchive.ietf.org/arch/search/?q=draft-deshpande-intarea-ipaddress-reclassification

https://datatracker.ietf.org/doc/html/draft-wilson-class-e-02
https://mailarchive.ietf.org/arch/search/?q=draft-wilson-class-e

https://datatracker.ietf.org/doc/html/draft-fuller-240space-02
https://mailarchive.ietf.org/arch/search/?q=draft-fuller-240space

The walkaway I had from these discussions was that while changing the 
definition of the address space would allow RIRs to sell more IPv4 address 
space for a few weeks (such as happened to APNIC when the last /8's were handed 
out), there were not enough addresses in the identified pools to solve the 
address shortage. So it was in the end a fool's errand. If you want to have 
address space to address the current shortage, you need an addressing 
architecture with more addresses. 

I was there for those discussions, and I'm not sure how to put it more simply.

Re: 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))

[Fred Baker]

> On Mar 11, 2022, at 8:39 AM, Joe Maimon  wrote:
> 
> Google's statistics...

I'm not sure which of you I'm replying to. The comment was made on NANOG the 
other day that we should discount Google statistics because they have been 
promoting IPv6 for a decade. It's true that they have been doing so. But they 
aren't the only people with statistics.

https://www.vyncke.org/ipv6status/compare.php?metric=p=in,my,sa,be,de,fr,gr,vn,tw,gf,zz,us,jp,th,br,mx,ae,lk,uy,hu,lu,fi,il,pt,gt,ch,gp,gb,mq,nl,ca,ee,ec,re,au,np,tt,at,ro,ga,ie,no,gy,bt,py,pe,kw,sx,mm,nz,co,cz,bo,ni,tg,ph,pl,sg,is,ar,kr,om,cl,sv,jm,si,mo,se,lv,jo,cg,ba,lc,zw,ir,id,md,hn,by,sk,al,rw,pf,ge,bz,dk,ru,hr,rs,it,vc,ke

You might look at the following links. Eric Vyncke has been putting up charts 
basically on Google, Akamai, and APNIC statistics for a while. One thing to 
consider is that around 90 countries (92 in this capture, as low as 89 a couple 
of days ago) have 5% or greater response rate using IPv6. Google and Akamai 
have their own content networks, and in at least some countries only 
externalize  records or respond to IPv6 requests. APNI isn't that way; they 
don't operate a content network, but rather accept traffic from across the 
backbone. Consider that a content network essentially reports traffic from a 
customer network to their first hop ISP, while when APNIC reports an IPv6 
access, the father form APNIC to the collector in question has to include every 
network and every router in the path. Now look at these:

https://www.vyncke.org/ipv6status/compare.php?metric=p=in
https://www.vyncke.org/ipv6status/compare.php?metric=k=in
https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=IN

I think the APNIC numbers demonstrate that paths through the backbone generally 
support IPv6 end to end, and that from a routing perspective there is no reason 
to favor IPv4.

There are 8 Countries (this evening) that Google reports roughly equal response 
rates from using IPv4 or IPv6. cf 
https://www.vyncke.org/ipv6status/compare.php?metric=p=in,my,sa,be,de,fr,gr,vn.
 This doesn't prove that IPv6 has taken over the world, but it does prove that 
those who would discount available statistics sources are a little too shrill 
in doing so.

Where IPv6 has a problem today is with enterprise. IMHO, this is basically 
because enterprise is looking at the bottom line. If ISPs were to do what 
Mythic Beasts says they do, which is charge their users for address space, IPv6 
is virtually free while IPv4 costs something. I suspect that enterprise would 
change its tune dramatically.

Re: Russia to disconnect from global Internet

[Fred Baker]

Of course, Ukraine had asked ICANN and the Root Server Operators to disconnect. 
We declined, but it may be done for us.

Sent using a machine that autocorrects in interesting ways...

> On Mar 6, 2022, at 1:59 PM, Jared Brown  wrote:
> 
> Accidentally put the wrong link for the translation.
> 
> Here is the correct link to the machine translation: 
> https://twitter.com/JiriVysin/status/1500560017640067077
> 
> --
> 
> According to Nexta (Belorussian media outlet: https://nexta.tv , 
> https://en.wikipedia.org/wiki/Nexta ) Russia has begun active preparations to 
> disconnection from the global Internet.
> 
> No later than March 11, all servers and domains must be transferred to the 
> Russian zone. In addition, detailed data on the network infrastructure of the 
> sites is being collected.
> 
> Source: https://twitter.com/nexta_tv/status/1500553480548892679
> 
> Machine translation of decree: 
> https://twitter.com/nexta_tv/status/1500553480548892679
> 
> Cogent exiting the Russian market is probably not related, but interesting 
> nevertheless.
> 
> 
> - Jared

Re: Ukraine request yikes

[Fred Baker]

China has worried that the root server operators would do such a thing to them, 
and I have argued that it is contrary to our published principles (RaSSAC055) 
and or practice. “We have never done so; what would that serve?”

I have the same question here.

Sent using a machine that autocorrects in interesting ways...

> On Mar 1, 2022, at 12:28 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.
> 
> 
> Rubens

Re: home router battery backup

[Fred Baker]

> On Jan 12, 2022, at 10:37 AM, Aaron C. de Bruyn via NANOG  
> wrote:
> 
> On Wed, Jan 12, 2022 at 10:18 AM Andy Ringsmuth  wrote:
> Given that most people barely even know what their home router is, I suspect 
> the percentage would be somewhere south of 1 percent. Outside of my home, I 
> honestly cannot recall EVER seeing someone’s home using a battery backup for 
> their internet infrastructure.
> 
> Same here.  The only people I've seen that have battery backups for their 
> home routers are fellow geeks.  I even bought one and shipped it to my 
> ~70-year-old mother...and she just doesn't want to install it.  "Too 
> complicated".
>  
> I personally do, but of course I (and probably everyone on this list) am by 
> no means representative of the population at large in this particular area.
> 
> Same.  My home office has 3 Cyberpower 2500 VA double-conversion UPS units 
> backed by Champion transfer switches.  Power goes out, and ~45 seconds later 
> I'm running on generator power.
> My local ISP runs out of power well before I do.  Thankfully there's Starlink.
> 
> Short of an asteroid hitting my office, it's highly unlikely I'll ever be 
> offline. ;)

In my case (California, home of SCE and PG), we have been notified by our 
electrical grid operators that power can go down at any time, for any reason, 
and any duration. I have just moved, so I am speaking in a historical context 
and future plans, but we have solar electricity as well and have a battery in 
the home that in effect backs up part of the house. We don't back up the 
Internet service, because frankly if power is down in the grid I'm not sure my 
favorite router is all that important, in addition to the considerations 
already mentioned. But power can and does go down - even without asteroids.

Re: IPv6 and CDN's

[Fred Baker]

On Nov 27, 2021, at 7:39 PM, Masataka Ohta  
wrote:
> 
> Mark Tinka wrote:
> 
>>> On 11/27/21 17:07, Masataka Ohta wrote:
>>> Because lengthy IPv6 addresses mean a lot more opex than IPv4.
>> I disagree
> 
> Try to type in raw IPv6 addresses.

People are likely to use a technology originally developed because IPv4 had the 
same perception problem: DNS.

Re: IPv6 and CDN's

[Fred Baker]

> On Oct 26, 2021, at 9:11 AM, David Conrad  wrote:
> 
> 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?”.

Unless you actually read the document. The process is that the fact is 
recognized and documented, the Designation and Removal function advises the 
ICANN board, they adopt a resolution, and instruct the IANA to remove the 
addresses from the relevant files, and from that point on nobody NEW tries to 
usevtheRSO. If someone does ask the company a question, they might or might not 
respond, and it might even have correct data, but then again might not. We 
can’t control who sends us requests, and we don’t have a black list.

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

[Fred Baker]

Sent using a machine that autocorrects in interesting ways...

> On Nov 18, 2021, at 5:15 PM, John Gilmore  wrote:
> 
> Keeping the price of IPv4 addresses reasonable means that dual-stack
> servers can continue to be deployed at reasonable cost, so that it
> doesn't matter whether clients have IPv6 or IPv4.  Any company that put
> its services on IPv6-only sites today would be cutting off 65% of their
> potential customers.  Even if v6 had 90% of the market, why would a
> company want 10% of its prospects to be unable to reach its service?

I find myself thinking about Reliance JIO, an Indian company. Iirc, their IPv4 
and IPv6 statistics are in the slide deck they presented to the IETF a year or 
two back, and they came to me/us a little later wanting somehow expand the IPv4 
address pool. In short, most of their services are IPv6 only. The only thing 
they want IPv4 addresses for is their enterprise customers, who want an IPv4 
option wherever IPv6 is an option - so they don’t have to select IPv6.

That’s all we’ll and good if the IPv4 addresses exist and work globally.  
Someone (was it you?) noted earlier in the thread that it might be acceptable 
to provide IPv4 address space that only worked in certain places. I find myself 
thinking about the arguments for a global DNS root. What a regional IPv4 
connectivity limit creates is a network that doesn’t work everywhere, meaning 
that the government of <> will be incented to deploy that address space locally 
within their country and provide a national NAT firewall to somehow protect 
their citizens - because of course the bad guys are always somewhere else. Kind 
of like the US wants to regulate encryption because nobody outside the US uses 
it or whatever. WHATEVER!

I tend to think that if we can somehow bless a prefix and make be global 
unicast address space, it needs to become Global Unicast Address Space.

This is becoming a rant, so I’ll stop…

Re: Redploying most of 127/8 as unicast public

[Fred Baker]

I have read through this thread, and you'll pardon me if it sounds like yet 
another rehash on yet another list. You might take a look at 
https://packetlife.net/blog/2010/oct/14/ipv4-exhaustion-what-about-class-e-addresses/,
 which responds to https://datatracker.ietf.org/doc/html/draft-wilson-class-e. 
I'm not sure what has changed in the past lotsa years other than which prefix 
people want to make essentially the same arguments about. My observation has 
been that people don't want to extend the life of IPv4 per se; people want to 
keep using it for another very short time interval and then blame someone else 
for the fact that the 32 bit integers are a finite set. 

That strikes me as crazy. Put all of the remaining IPv4 prefixes (for some 
suitable definition of "remaining") in a bucket, decide that if they were all 
made unicast IP address space that would add  microfortnights to the 
life of the IPv4 Internet, and think about what happens next. Immediately, we 
all go back to sleep, fail to update our applications and deployments, and when 
that time interval has expired, we all whine about the stupidity of the IPv4 
designers that didn't not make IPv4 forward compatible with *any*thing* - the 
next step has to be a replacement - and try to figure out a way to represent 
more than 2^32 interfaces in a single 32 bit number 
(https://datatracker.ietf.org/doc/html/draft-terrell-math-ipaddr-ipv4) or 
redesign the Internet in some way that would require as much effort and money 
to deploy as IPv6 has since its inception. 

If you don't think that's a true statement, I'd be very interested to hear what 
you think might be true. 

Re: . (was IPv6 and CDN's)

[Fred Baker]

> On Oct 26, 2021, at 9:25 AM, Bryan Fields  wrote:
> 
> Can you explain how it would work?  Say you have a root server operator who
> starts messing up, is there any ability to remove them?

You might look at 
https://www.icann.org/en/system/files/files/rssac-037-15jun18-en.pdf. Yes, 
there is a proposed way to remove an operator that is not working out.

Re: IPv6 and CDN's

[Fred Baker]

Sent using a machine that autocorrects in interesting ways...

> On Oct 23, 2021, at 1:55 PM, Christopher Morrow  
> wrote:
> 
>> On Sat, Oct 23, 2021, 15:17 Fred Baker  wrote:
>> I think you will find that there are some places in which getting IPv6 
>> network service has been difficult, and as a result even IPv6-
> 
> 
> Fred, do you mean places like, all of Verizon FiOS?

That would be an example. If I traceroute to an ipv6 address, the fact that I 
get a response is proof that the path works. F root has some servers for which, 
MOU be damned, there is no working IPv6 path. Mumble…

>> capable equipment is not reachable by IPv6. Those are, however, few and far 
>> between.
>> 
>> Sent using a machine that autocorrects in interesting ways...
>> 
>> > On Oct 23, 2021, at 6:04 AM, David Conrad  wrote:
>> > 
>> > So, in theory, all the root servers should be available via IPv6 and, as 
>> > far as I can tell, they are.

Re: IPv6 and CDN's

[Fred Baker]

I think you will find that there are some places in which getting IPv6 network 
service has been difficult, and as a result even IPv6-capable equipment is not 
reachable by IPv6. Those are, however, few and far between.

Sent using a machine that autocorrects in interesting ways...

> On Oct 23, 2021, at 6:04 AM, David Conrad  wrote:
> 
> So, in theory, all the root servers should be available via IPv6 and, as far 
> as I can tell, they are.

Re: S.Korea broadband firm sues Netflix after traffic surge

[Fred Baker]

I’m not sure I disagree, but let throw in a point of consideration. 
Historically, as you note, the caller pays the toll. However, the caller also 
CHOSE to call, even though the called party might find the call irritating. 
With a CDN, the network is out there hoping to be called, and the user makes 
that choice, “calling” the CDN. Could it not be accurately said that the user 
originated the “call”?

Sent using a machine that autocorrects in interesting ways...

> On Oct 20, 2021, at 12:43 PM, Matthew Walster  wrote:
> 
> 
> Seems pretty disingenuous to now say the called party has to pay as well, in 
> stark contrast to decades of precedent with their telephone product, just 
> because their customers are actually using what they were sold.

Re: Never push the Big Red Button (New York City subway failure)

[Fred Baker]

> On Sep 10, 2021, at 1:33 PM, Warren Kumari  wrote:
> 
> The utility let them know that they were going to be doing some maintenance 
> work in the area. No impact expected, but out of an abundance of caution, 
> they transfer over to generators. After the utility lets them know that the 
> maintenance work is all finished, they want to switch back. If the generators 
> are "emergency power", and you need to switch back to "utility power", 
> obviously the way to do this must be the big red button, clearly marked as 
> "EMERGENCY POWER OFF", no?!

One of the many stories that came out of 9/11 was a switching center in NY City 
that had a diesel generator as a power backup - which of course acted as 
primary when the city power is off. After a few days of operation, it needed to 
be refueled, so a truck was sent in carrying gasoline. The generator was 
refueled and restarted, and - oops - diesel != gasoline. So then they needed to 
bring in a new generator.

Yup, it happens, and it happened.

Re: IPv6 woes - RFC

[Fred Baker]

Sent using a machine that autocorrects in interesting ways...

> On Sep 8, 2021, at 1:31 AM, Saku Ytti  wrote:
> 
> If the mid size eyeballs knew ipv4 is going away in 10, 15, 20 years
> whichever it is, then they'd of course have to start moving too,
> because no upstream.

And they would fight it tooth and nail, just like they do now, and if they 
found an address they could NAT to, they would argue that that one address gave 
them the ability to avoid the transition -just like they do now.

Re: IPv6 woes - RFC

[Fred Baker]

> On Sep 8, 2021, at 1:26 AM, Bjørn Mork  wrote:
> 
> 
> I started wondering if there are areas where we can disable IPv4 today.

There are places in which it is disabled today, for at least some services.

Re: Where to get IPv4 block these day

[Fred Baker]

> On Aug 6, 2021, at 8:22 AM, Noah  wrote:
> 
> Do majority of smart handsets OS today support v6?
> 
> Majority of people I know (due to economic factors) own lowend android 
> handsets with no support for v6. This group forms majority of eyeballs that 
> contribute revenue to local Telecoms whose network is heavily CGNAT.

Handsets - Cameron would be in a better place than I to discuss this, but 
certainly anything used to connect to his network (T-Mobile) does, and enables 
access with IPv4 turned off. That includes at least iPhone (the handset I use 
to access his network), and Android. 
https://thirdinternet.com/ipv6-on-mobile-devices/

As to other systems, Apple and Linux platforms, and more recently Windows, 
supports IPv6, and has for quite a while. Issues there tend to be in specific 
applications (due to the socket interface).


signature.asc
Description: Message signed with OpenPGP

Re: Where to get IPv4 block these day

[Fred Baker]

> On Aug 6, 2021, at 6:48 AM, Josh Luthman  wrote:
> 
> v6 isn't a solution today for v4 problems.

I don't know that IPv6 was ever intended to be a solution to IPv4 problems per 
se. It was intended to be an IPv4 replacement to provide connectivity.


signature.asc
Description: Message signed with OpenPGP

Re: Call for academic researchers (Re: New minimum speed for US broadband connections)

[Fred Baker]

I would add packet loss rate. Should be zero, and if it isn’t, it points to an 
underlying problem.

Sent from my iPad

> On May 31, 2021, at 11:01 AM, Josh Luthman  
> wrote:
> 
> 
> I think the latency and bps is going to be the best way to measure broadband 
> everyone can agree on.  Is there a better way, sure, but how can you quantify 
> it?
> 
> Josh Luthman
> 24/7 Help Desk: 937-552-2340
> Direct: 937-552-2343
> 1100 Wayne St
> Suite 1337
> Troy, OH 45373
> 
> 
>> On Sun, May 30, 2021 at 7:16 AM Mike Hammett  wrote:
>> I think that just underscores that the bps of a connection isn't the 
>> end-all, be-all of connection quality. Yes, I'm sure most of us here knew 
>> that. However, many of us here still get distracted by the bps.
>> 
>> If we can't get it right, how can we expect policy wonks to get it right?
>> 
>> 
>> 
>> -
>> Mike Hammett
>> Intelligent Computing Solutions
>> http://www.ics-il.com
>> 
>> Midwest-IX
>> http://www.midwest-ix.com
>> 
>> From: "Sean Donelan" 
>> To: "NANOG" 
>> Sent: Saturday, May 29, 2021 6:25:12 PM
>> Subject: Call for academic researchers (Re: New minimum speed for US 
>> broadband connections)
>> 
>> 
>> I thought in the 1990s, we had moved beyond using average bps measurements 
>> for IP congestion collapse.  During the peering battles, some ISPs used to 
>> claim average bps measurements showed no problems.  But in reality there 
>> were massive packet drops, re-transmits and congestive collapse which 
>> didn't show up in simple average bps graphs.
>> 
>> 
>> Have any academic researchers done work on what are the real-world minimum 
>> connection requirements for home-schooling, video teams applications, job 
>> interview video calls, and network background application noise?
>> 
>> 
>> During the last year, I've been providing volunteer pandemic home 
>> schooling support for a few primary school teachers in a couple of 
>> different states.  Its been tough for pupils on lifeline service (fixed 
>> or mobile), and some pupils were never reached. I found lifeline students 
>> on mobile (i.e. 3G speeds) had trouble using even audio-only group calls, 
>> and the exam proctoring apps often didn't work at all forcing those 
>> students to fail exams unnecessarily.
>> 
>> In my experience, anecdotal data need some academic researchers, pupils 
>> with at least 5 mbps (real-world measurement) upstream connections at 
>> home didn't seem to have those problems, even though the average bps graph 
>> was less than 1 mbps.
>> 
>> 

Re: New minimum speed for US broadband connections

[Fred Baker]

On May 28, 2021, at 11:55 AM, Chris Adams  wrote:
> I know multiple people that had issues with slow Internet during the
> last year as two adults were working from home and 1-3 children were
> also schooling from home.  Parents had to arrange work calls around
> their kids classroom time and around each other's work calls, because of
> limited bandwidth.

The example that comes to mind is my daughter, who has two kids in elementary 
school (*elementary*, not high school or college) from home and a husband 
working from home. The kids will eventually be in person some subset of the 
time, but they're told to not expect 100%; the hubby is going to be 100% WFH 
for the foreseeable future. The thing that killed the kids wasn't the absolute 
bit rate, it was data caps - basically, all the families and the school had to 
upgrade service to something with a higher cap or education stopped for part of 
each month - and the school had a contract that supposedly had no cap, but was 
forced to renegotiate anyway. This isn't out of town, either; it's Walnut Creek 
California, a few blocks from the BART station.

So, yes, all of that.

I'm watching the conversation and thinking of my experience on the FCC TAC 15 
years ago. We had someone from an intentionally-nameless carrier that was 
fighting minimum broadband rates with everything he had. His statement was that 
"there is no market above 1 MBPS". In this conversation, I think carriers need 
to take on board the message that the minimum broadband rate in 2015 might not 
be adequate in 2021. We can argue the distinction between "has a market" and 
"is a universal market minimum", but "there is no market above 10 MBPS per user 
in the home" is a self-limiting discussion.


signature.asc
Description: Message signed with OpenPGP

Re: AWS Using Class E IPv4 Address on internal Routing

[Fred Baker]

The "RFC" you're looking for is probably 
https://tools.ietf.org/html/draft-wilson-class-e-02, which was not agreed to 
and so has no RFC number. The fundamental issue that was raised during that 
discussion was that while repurposing class e would provide a few more IPv4 
addresses and so delay the need to replace the IPv4 protocol for some period of 
time, APNIC's experience with a new /8 in 2011 (it was given the /8 in January 
2011, and by April had largely distributed it to its members) suggests that the 
address space would be used up almost immediately if distributed publicly, and 
if used privately doesn't benefit the many networks that really honestly wish 
that we could squeeze more than 2^32 addresses into a 32 bit container.

I'd really suggest using IPv6. Networks like Reliance JIO in India, which has 
turned off or never turned on IPv4 for most of its services, find that they 
don't need IPv4 apart from customer preference.

> On Mar 9, 2021, at 6:36 AM, Douglas Fischer  wrote:
> 
> So, if an organization wants to use that, they will require from the vendors 
> the compliance with that RFC.
> 
> 
> 
> Em ter., 9 de mar. de 2021 às 11:00, Forrest Christian (List Account) 
>  escreveu:
> Back a little bit ago when the thread about running out of RFC-1918 space was 
> going on, I was going to make a suggestion about repurposing the Class E 
> space in the case where one ran out of space, assuming one could get the 
> vendors on your network to support this address range.
> 
> I sort of discarded the suggestion just because of the whole issue of that 
> range being hardcoded as invalid in so many implementations that this didn't 
> seem all that useful.
> 
> On the other hand, if you're large enough that you're running out of RFC-1918 
> space you might be able to exert enough power over select vendors to get them 
> to make this work for selected purposes.   Router-to-Router links, especially 
> between higher-end routers seems to be one of those cases that it might be 
> useful. It might be the case that Amazon is already doing this
> 
> 
> On Mon, Mar 8, 2021 at 12:07 PM Douglas Fischer  
> wrote:
> Has anybody seen that also?
> 
> P.S.: I'm completely in favor of a complementary RFC assing FUTURE USE 
> exclusively to "Between Routers" Link Networks...
> 
> --
> Douglas Fernando Fischer
> Engº de Controle e Automação
> 
> 
> --
> - Forrest
> 
> 
> 



signature.asc
Description: Message signed with OpenPGP

Re: Texas internet connectivity declining due to blackouts

[Fred Baker]

True, Sean, but Texas has its own ISO. The counterpart wouldn’t be “Delaware 
has rolling blackouts”, but “The Eastern ISO has following blackouts”.

Sent from my iPad

> On Feb 15, 2021, at 8:49 PM, Sean Donelan  wrote:
> 
> 
> 
>> On Tue, 16 Feb 2021, Cory Sell via NANOG wrote:
>> adoption. Sure, wind isn’t perfect, but looks like solution relied on failed
>> in a massive way.
> 
> Strange the massive shortages and failures are only in one state.
> 
> The extreme cold weather extends northwards across many states, which aren't 
> reporting rolling blackouts.

Re: dumb question: are any of the RIR's out of IPv4 addresses?

[Fred Baker]

You may find this article interesting: 
https://blog.apnic.net/2019/12/13/keep-calm-and-carry-on-the-status-of-ipv4-address-allocation/

Sent from my iPad

> On Feb 16, 2021, at 3:07 PM, Michael Thomas  wrote:
> 
> 
> Basically are there places that you can't get allocations? If so, what is 
> happening?
> 
> Mike
> 

Re: DoD IP Space

[Fred Baker]

Streams Transport and PIP.

Good grief. V7 was Robert Ullman’s CATNIP. He wanted to sell hardware to 
everyone, and V7 was the interchange protocol between IPv4, IPX, and CLNS.

Sent using a machine that autocorrects in interesting ways...

> On Feb 15, 2021, at 12:41 PM, Valdis Klētnieks  
> wrote:
> 
> On Mon, 15 Feb 2021 10:51:51 -0800, Sabri Berisha said:
> 
>> Well, considering this RIPE article that talked about IPv7 already..
>> 
>> https://lists.ripe.net/pipermail/ripe-org-closed/1993/msg00024.html
> 
> Bonus points for those who remember/know where v5 and v8 were from :)

V5 was 

Re: DoD IP Space

[Fred Baker]

On Jan 23, 2021, at 11:32 AM, Sabri Berisha  wrote:
> 
> Personally, I would 
> argue that a full implementation of IPv6 means that v4 could be phased out 
> without
> adverse effect on the production network.

I like that definition.

Re: DoD IP Space

[Fred Baker]

> On Jan 22, 2021, at 10:28 PM, Valdis Klētnieks  
> wrote:
> 
> And how would you define "fully implement v6", anyhow?

I would define it this way: if something can be done using IPv4, it has an 
obvious IPv6 counterpart that is usable by the same community to the extent 
that the community is itself able to use such. Web sites, mail, bandwidth, 
routing, ROAs, firewalls with appropriate rules, and so on. The problem with my 
suggested wording is that if one turns IPv4 off, by implication someone turns 
IPv6 off, and I don't intend that. So reword to make IPv6 the surviving service 
in some way, and I think you're pretty much there.


signature.asc
Description: Message signed with OpenPGP

Re: DoD IP Space

[Fred Baker]

I recently had a discussion with an Asian ISP that was asking the IETF to 
PLEASE re-declare DoD space to be private space so that they could use it. This 
particular ISP uses IPv6 extensively (a lot of their services are in fact 
IPv6-only) but has trouble with its enterprise customers. Frankly, enterprise 
use of IPv6 is a problem; they seem to push back pretty hard against using IPv6.

I find this thread highly appropriate.

> On Jan 20, 2021, at 6:58 AM, j k  wrote:
> 
> My question becomes, what level of risk are these companies taking on by 
> using the DoD ranges on their internal networks? And have they quantified the 
> costs of this outage against moving to IPv6?
> 
> Joe Klein
> "inveniet viam, aut faciet" --- Seneca's Hercules Furens (Act II, Scene 1)
> "I skate to where the puck is going to be, not to where it has been." -- 
> Wayne Gretzky
> "I never lose. I either win or learn" - Nelson Mandela
> 
> 
> 
> On Wed, Jan 20, 2021 at 9:06 AM John Curran  wrote:
> Indeed.
> /John
> 
> > On Jan 20, 2021, at 8:47 AM, Cynthia Revström  wrote:
> >
> > But if you do this, make sure you keep track of where you might have put 
> > policies like this in, in case the DoD sells some the space or whatever in 
> > the future.
> 



signature.asc
Description: Message signed with OpenPGP

Cox contact?

[Fred Baker]

Would an engineer from Cox please contact me privately?

Re: Is there *currently* a shortage of IPv4 addresses?

[Fred Baker]

> On Aug 4, 2020, at 1:01 PM, Tom Beecher  wrote:
> 
> The only other option then becomes the secondary transfer markets, where 
> costs to acquire v4 space are much higher than what direct allocations from 
> the RIRs used to be. 
> 
> On Tue, Aug 4, 2020 at 3:35 PM Anne P. Mitchell, Esq.  
> wrote:
>> I know that a shortage of IPv4 addresses has been anticipated for quite some 
>> time (literally decades), however, is there a shortage *right now*?
>> 
>> I ask, because Liquid Web is using it as an excuse to raise their prices:
>> 
>> "We're contacting you today to inform you of a change to your account. As 
>> you may know, the global shortage of IPv4 addresses 
>> (https://www.ripe.net/manage-ips-and-asns/ipv4/ipv4-run-out) continues to 
>> impact web hosting companies around the world. ... Effective August 31st, we 
>> will be updating our per IPv4 address price to $2.00 per IP."

For an overview of open market pricing, you might look at 
https://ipv4marketgroup.com/ipv4-pricing/.

You may also find this talk interesting in context:
Mythic Beasts, which is a data center operator in London, gave a talk to the 
IPv6 Operations Working Group in the IETF two years ago, and used these slides: 
https://www.ietf.org/proceedings/101/slides/slides-101-v6ops-ipv6-only-hosting-00.
 If you look through them, you'll find a discussion of the address shortage and 
what impact it has on pricing from them.

In short, Mythic Beasts find that IPv6 service is virtually free, and don't 
charge for it. They find that when a customer pushes them to also give IPv4 
addressing, they have to charge, as it costs them, and they find that making 
the customer engineer explain to his/her bean counters why the need it often 
has the effect of convincing the company to use IPv6 externally. 
https://image.slidesharecdn.com/ipv6atmythicbeasts-networkshop44-160323133644/95/ipv6-at-mythic-beasts-networkshop44-19-638.jpg?cb=1458740321

In short, yes, there is a shortage of IPv4 addresses, and the net result is 
both an increase in price and an increase in network complexity. 

Re: [v6ops] Question about "Operational Implications of IPv6 Packets with Extension Headers"

[Fred Baker]

Fernando, I asked a specific question, not "send me all of your comments". 
General discussion of your draft still belongs on the v6...@ietf.org list. 
Please don't confuse the issue.

> On Jul 28, 2020, at 11:44 PM, Fernando Gont  wrote:
> 
> Folks,
> 
> FYI. You can send your comments to  if you wish.
> 
> Thanks,
> Fernando
> 
> 
> 
> 
>  Forwarded Message 
> Subject: [v6ops] Question about "Operational Implications of IPv6 Packets 
> with Extension Headers"
> Date: Tue, 28 Jul 2020 22:55:45 -0700
> From: Fred Baker 
> Reply-To: V6Ops-Chairs 
> To: IPv6 Operations 
> 
> It looks like Fernando (et al) revised this and posted draft -04 on Saturday, 
> and there has been a flurry of discussion. I haven't been through the 
> document or the entire thread yet, but I do observe that a number of people 
> have comments, and several people have expressed interest in the document.
> 
> Let me ask the obvious question: you we want to adopt this as a working group 
> draft? I won't ask you to hum; whether you wish to say "yes", "no", or 
> "abstain", please reply to this email *privately* (which is to say, to 
> v6ops-chairs) with that word prepended on the subject line. I'll give us 48 
> hours, which is to say that I will evaluate and state the result Thursday 
> evening Pacific time.
> 
> https://mailarchive.ietf.org/arch/search/?qdr=a=%22draft-gont-v6ops-ipv6-ehs-packet-drops%22
> https://mailarchive.ietf.org/arch/search/?qdr=a=%22Operational Implications 
> of IPv6 Packets with Extension Headers%22
> https://datatracker.ietf.org/doc/draft-gont-v6ops-ipv6-ehs-packet-drops
> https://tools.ietf.org/html/draft-gont-v6ops-ipv6-ehs-packet-drops
>  "Operational Implications of IPv6 Packets with Extension Headers", Fernando 
> Gont, Nick Hilliard, Gert Doering, Warren Kumari, Geoff Huston, 2020-07-25,
> 
> ___
> v6ops mailing list
> v6...@ietf.org
> https://www.ietf.org/mailman/listinfo/v6ops
> 

Re: MAP-T in production

[Fred Baker]

For the record, we are asking similar questions about 464XLAT in v6ops. If you 
are deploying it, please advise Jordi Palet Martinez.

For those unfamiliar with them, MAP-T and 464XLAT are each deployment 
frameworks for IPv4/IPv6 translation, as described in RFCs 4164, 4166, 4167, 
and 7915.

Sent from my iPad

> On Jul 22, 2020, at 2:16 PM, Brian Johnson  wrote:
> 
> Has anyone implemented a MAP-T solution in production? I am looking for 
> feedback on this as a deployment strategy for an IPv6 only core design. My 
> concern is MAP-T CE stability and overhead on the network. The BR will have 
> to do overloaded NAT anyway to access IPv4 only resources. The idea being 
> that when IPv4 is no longer needed, this will be a quicker “clean-up” project 
> than a dual-stack solution.
> 
> I have reviewed Jordan Gotlieb’s presentation from Charter and would love to 
> hear if this is still in use at Charter or if was ever fully implemented and 
> the experiences)
> 
> I’d love any real life examples and success/failure stories.
> 
> Thanks.
> 
> - Brian

Re: QUIC traffic throttled on AT residential

[Fred Baker]

> On Feb 18, 2020, at 4:00 PM, Ca By  wrote:
> 
> I am not a fan of quic or any udp traffic. My suggestion was that Google use 
> an new L4 instead of UDP, but that was too hard for the Googlers.

The argument I have heard is that residential firewalls often block anything 
that is *not* UDP or TCP. The question for the googlers was existential - can 
it work at all?


signature.asc
Description: Message signed with OpenPGP

Re: power to the internet

[Fred Baker]

> This time it’s PG all alone, but still fallout from back then. Too much 
> liability and they’ve not maintained the infrastructure and so they decided 
> that to reduce the liability costs it’s cheaper to blackout. Same story again 
> different colors. PG making a mint while people get screwed (PG was 
> mostly at the getting screwed end in 2000-2001)

PG has been the one in the news, but SCE appears to have been making the same 
choices with about the same effects. The Thomas Fire was briefly the largest 
wildfire in state history, and the source (well, with the rain) of the 
Montecito mud flow a few weeks later. We're told that SCE seems to figure in 
that one and several others before and since.

I go back and forth on who might be responsible. The electric utilities bear 
blame for their infrastructure; it should be underground, not strung from 
poles. I would put some to the state and the management of the various national 
forests and national parks in the area - one of the outcomes from a fire in 
2007 or thereabouts was that the ecology folks had been protecting foliage, and 
that foliage burned and clogged streams, with all sorts of results. Surprise! 
If you're worried about ecology, you should support management of it. In 
California, there are also laws holding home-owners responsible for "defensible 
space" around their homes.

https://www.google.com/search?q=california+brush+clearing+laws
https://en.m.wikipedia.org/wiki/Thomas_Fire 

https://www.washingtonpost.com/graphics/2018/national/montecito-before-after/ 
https://www.edhat.com/news/10-homes-destroyed-in-holiday-fire 
https://www.edhat.com/news/cave-fire-now-100-contained

Re: Elephant in the room - Akamai

[Fred Baker]

Sent from my iPad

> On Dec 5, 2019, at 9:03 PM, Stephen Satchell  wrote:
> 
> For SP-grade routers, there isn't "code" that needs to be added to combat 
> buffer bloat.  All an admin has to do is cut back on the number of packet 
> buffers on each interface -- an interface setting, you see.

A common misconception, and disagrees with the research on the topic.

Let me describe this conceptually. Think of a file transfer (a streaming flow 
can be thought of in those terms, as can web pages etc) as four groups of 
packets - those that have been delivered correctly and therefore don’t affect 
the window or flow rate, those that have been delivered out of order and 
therefore reduce the window and might get retransmitted even though they need 
not be resent, those that are sitting in a queue somewhere and therefore add 
latency, and those that haven’t been transmitted yet. If I have a large number 
of sessions transiting an interface, each one is likely to have a packet or two 
near the head of the queue; after that, it tends to thin out, with the sessions 
with the largest windows having packets deep in the queue, and sessions with 
smaller windows not so much.

If you reduce the queue depth, it does reduce that deep-in-the-queue group - 
there is no storage deep in the queue to hold it. What it does, however, is 
increase any given packet’s probability of loss (loss being the extreme case of 
delay, and when you reduce delay unintelligently is the byproduct), and 
therefore the second category of packets - the ones that managed to get through 
after a packet was lost, and therefore arrived out of order and have some 
probability of being retransmitted and therefore delivered multiple times.

What AQM technologies attempt to do (we can argue about the relative degree of 
success in different technologies; I’m talking about them as a class) is 
identify sessions in that deep-in-the-queue category and cause them to 
temporarily reduce their windows - keeping most of their outstanding packets 
near the head of the queue. Reducing their windows has the effect of moving 
packets out of the network buffers (bufferbloat) and reordering queues in the 
receiving host to “hasn’t been sent yet” in the sending host.  That also 
reduces median latency, meaning that the sessions with reduced windows don’t 
generally “slow down” - they simply keep less of their data streams in the 
network with reduced median latency.

Re: RIPE our of IPv4

[Fred Baker]

> On Dec 3, 2019, at 3:22 PM, Valdis Klētnieks  wrote:
> 
> On Tue, 03 Dec 2019 14:58:59 -0800, FREDERICK BAKER said:
> 
>> I think he is saying that companies like Reliance JIO have started with a /22
>> of IPv4 and a /32 (or more) of IPv6,
> 
> As I said - you need IPv4 space to dual-stack. How does Reliance do this
> without any v4 address space?

They have a very small amount, and do CGN, the same as anyone else. If that's 
what you took away from the APNIC measurements, you missed the story, though.

Re: Russian government’s disconnection test

[Fred Baker]

> On Nov 1, 2019, at 8:15 PM, Constantine A. Murenin  wrote:
> 
> If somehow all the transatlantic (and/or transpacific) cables are offline; 
> will the whole internet outside of the US stop working, too?

This has nothing to do with cables, and everything to do with information 
control and politics.

Re: California public safety power shutdowns

[Fred Baker]

On Oct 9, 2019, at 12:36 PM, Sean Donelan  wrote:
> Pacific Gas & Electric and Southern California Edison have started Public 
> Safety Power Shut-offs (PSPS) in California wildfire high-risk areas.
> 
> Shut-offs are taking place in three phases. PG began shutoffs at midnight 
> in Northern California and the North Bay counties, while the rest of the Bay 
> Area is scheduled to begin losing power in waves at noon. A possible third 
> phase will occur later in the day in the southernmost parts of the PG 
> service area in the San Joaquin Valley and Central Coast.
> 
> Southern California Edison said it's considering cutting power to more than 
> 100,000 customers in eight counties. The utilities haven't said how many 
> people the outages will affect in all.

Indeed. Meanwhile, I'm in Walnut Creek, and estimates of wind velocity here 
vary from zero to five knots.

Re: Update to BCP-38?

[Fred Baker]

On Oct 3, 2019, at 3:15 PM, Stephen Satchell  wrote:
> You still need a IPv6 version of RFC 1812.

If we were to start with the current draft, I would probably want to start 
over, and have people involved from multiple operators.

That said, let me give you some background on RFC 1812. The development started 
a little after a largish group of people started on what eventually became RFCs 
1122 and 1123. The point was that there were a number of RFCs that needed to be 
updated with hard-earned wisdom - how ARP should work and so on. The group 
decided that instead of reissuing each individual RFC, they should do one 
omnibus effort. 1812 similarly covered a lot of "we discovered that this was 
true or needed to become true". The first editors was Philip Almquist, and it 
passed through several subsequent pairs of hands. It then sat on a shelf for 
several years, with people saying "we really should publish that" and not doing 
so. In 1994, the CIDR change was in full swing, and I was changing employers. 
Marshall Rose contacted me asking me to take it over, edit CIDR into it and "do 
whatever else was needed", and publish the thing. My new boss agreed to lt me 
do so, and I did.

I was given the text in RFC 1716 as input, which was then published as 
"historic", and RFC 1812 was the end product. RFC 1812 is kind of long in the 
tooth, BTW.

Since then, the way the IETF updates documents with hard-earned wisdom has 
changed. We don't do omnibus documents like RFC 1122/1123 and 1812; we write a 
document - or 20 of them - that "update" the document in question. You can find 
that information in the rfc-index.txt file, and in the datatracker. So if there 
were updates to include corresponding to those RFCs and on IPv6, I think the 
IETF would tell you to look at RFC 8200.

There is one thing in 1122/1123 and 1812 that is not in those kinds of 
documents that I miss; that is essentially "why". Going through 1122/1123 and 
1812, you'll ind several sections that say "we require X", and follow that with 
a "discussion" section that says "we thought about X, Y, and Z, there were 
proponents of each, the arguments were X', Y', and Z', and we chose X for this 
reason". I would presume that what you're really looking for in a 1812-for-IPv6 
is not "we require X" as much as "for this reason". Correct me if I'm wrong.

I can kick the idea around in the IETF if its important to you. I'll be looking 
for a LOT of operational input.

Re: Update to BCP-38?

[Fred Baker]

On Oct 3, 2019, at 12:30 PM, Stephen Satchell  wrote:
> 
> On 10/3/19 8:22 AM, Fred Baker wrote:
>> And on lists like this, I am told that there is no deployment - that
>> nobody wants it, and anyone that disagrees with that assessment has
>> lost his or her mind. That all leaves me wondering which of us
>> doesn't quite have their eye on the ball.
> For the reasons you provided in your original message, the learning
> curve for IPv6 -- EVERYTHING about IPv6, not "just enough to get by" --
> is steep and uncertain.
> 
> And I think you may be misunderstanding the problem.  It's not that
> people don't want it.  They lack the zen of it, they don't see the four
> corners of the thing, something that people took years to learn in IPv4.
> (I had a leg up, being involved in the original ARPAnet, so I got to
> watch it grow.  Still have the 1984 DDN handbooks, too.)

Funny thing. I was quoting the email in this thread just prior to yours. I 
won’t say there are no issues in IPv6 deployment; there are. However, having 
done some myself, if you have IPv4-zen, IPv6-zen is pretty easy to come by with 
a cheat sheet. For example, does your configuration have statements like

IP address 192.0.2.1 255.255.255.0 ?

Everywhere you find that, you add a statement like 
ipv6 address 2001:db8:AABB:1234::/64 eui-64
What I did for the IID (IPv4-speak: “host part”) in a recent project was use 
the IPv4 address of the interface:
IP address 192.0.2.1 255.255.255.0
IPv6 address 2001:db8:aabb:1234:192:0:2:1::/128
The idea was to give the operator a clue. I also put the VLAN number in as the 
subnet number. A security geek would be all over me - “too many clues!”. That 
said, 
I found that by typing “IPv6 address command” into google; the first hit was 
https://study-ccna.com/how-to-configure-ipv6/. Then, noting that Cisco has a 
bad habit of pulling things out of there air even though there is a defined way 
to accomplish it, I corrected the prefix to use the defined documentation 
prefix.
It gets a little interesting when you step away from the switch or router to 
the firewall; they have their own commands. The ASA, for example, really 
believes in what Cisco calls “zone-based access control” or “context-based 
access control”. The good news is that if that’s what you’re trying to achieve 
(it’s common), configuring that for IPv6 is pretty simple.
And similarly, BGP and access lists look a lot like their IPv4 counterparts.
What’s a little more of a pain is that if you are using other appliance in your 
network, they may or may not have IPv6 configurability, and there may or may 
not be a drop-in replacement. That becomes a conversation with your vendors of 
choice.

Re: Update to BCP-38?

[Fred Baker]

Sent from my iPad

> On Oct 3, 2019, at 12:14 PM, Stephen Satchell  wrote:
> 
> On 10/3/19 8:42 AM, Fred Baker wrote:
>> 
>> 
>>>> On Oct 3, 2019, at 9:51 AM, Stephen Satchell  wrote:
>>> 
>>> Someone else mentioned that "IPv6 has been around for 25 years, and why
>>> is it taking so long for everyone to adopt it?"  I present as evidence
>>> the lack of a formally-released requirements RFC for IPv6.  It suggests
>>> that the "science" of IPv6 is not "settled" yet.  That puts the
>>> deployment of IPv6 in the category of "experiment" and not "production".
>> 
>> And, of course, we now have companies like T-Mobile and others
>> turning IPv4 off. If that's an experiment, wow.
> The cellular data industry appears to have embraced IPv6 in one form or
> another.  I would expect that the network engineers have done some work
> to keep IPv4 off their *internal* networks, but provide IPv4 access at
> the edge.  (Isn't a netblock within IPv6 intended to enable bridging to
> IPv4?)  The applications on the phon could be configured to search DNS
> for  addresses first.

T-Mobile documented what they are doing at https://tools.ietf.org/html/rfc6877.

> My AT cell phone has both IPv4 and IPv6 addresses.  The IPv4 address
> is from my access point; the IPv6 address appears to be a public address.

So does my T-Mobile phone. It got the IPv4 address from my friendly 
neighborhood WiFi. 

> I would like to move to IPv6.  I just don't want to shoot myself in the
> foot, or cause trouble for other people, by being sure my edge router
> "follows all the rules."

Re: Update to BCP-38?

[Fred Baker]

> On Oct 3, 2019, at 9:51 AM, Stephen Satchell  wrote:
> 
> Someone else mentioned that "IPv6 has been around for 25 years, and why
> is it taking so long for everyone to adopt it?"  I present as evidence
> the lack of a formally-released requirements RFC for IPv6.  It suggests
> that the "science" of IPv6 is not "settled" yet.  That puts the
> deployment of IPv6 in the category of "experiment" and not "production".

And, of course, we now have companies like T-Mobile and others turning IPv4 
off. If that's an experiment, wow.

Re: Update to BCP-38?

[Fred Baker]

On Oct 3, 2019, at 9:51 AM, Stephen Satchell  wrote:
> It appears that the only parallel paper for IPv6 is
> draft-ietf-v6ops-ipv6rtr-reqs-04, _Requirements for IPv6 Routers_, which
> currently carries a copyright of 2018.  It's a shame that this document
> is still in limbo; witness this quote:  "It is inappropriate to use
> Internet-Drafts as reference material or to cite them other than as
> 'work in progress.'

Speaking as v6ops chair and the editor of record for 1812. 
draft-ietf-v6ops-ipv6rtr-reqs kind of fell apart; it was intended to be an 
1812-like document and adopted as such, but many of the "requirements" that 
came out of it were specific to the author's operation and not common to other 
operators. So it ultimately didn't happen.

> Someone else mentioned that "IPv6 has been around for 25 years, and why
> is it taking so long for everyone to adopt it?"  I present as evidence
> the lack of a formally-released requirements RFC for IPv6.  It suggests
> that the "science" of IPv6 is not "settled" yet.  That puts the
> deployment of IPv6 in the category of "experiment" and not "production".
> 
> Is that really true?

That's a long story. The IETF realized it needed a next generation protocol in 
1990; that's where NATs came from, the successive efforts to recover unused 
IPv4 space, and research into possible next generation protocols. IPv6 was 
proposed in 1993-1994, originally published in 1996 as RFC 1883, and 
republished in 1998 as RFC 2460. It was recently re-re-published as RFC 8200.

Supporting work was required in DHCP, DNS, and several routing protocols; that 
happened over time. ICANN didn't adopt a policy for the allocation of IPv6 
address space to RIRs until 2006, and in 2007 there were a number of 
allocations from IANA to the RIRs and from some of the RIRs to operators in 
various parts of the world. Testing was also important - primarily done by the 
NRENs. That wound up with comments going back to various vendors. I was 
employed by one of them, but will refrain from giving "insider" comments. 
Suffice it to say that there were multiple vendor implementations, mostly 
incomplete in one way or another. 

IANA allocated the last five IPv4 /8s to the RIRs in 2011, and since then the 
IPv4 address market has been mopping up the slop. Per 
https://ipv4marketgroup.com/ipv4-pricing/ (if addresses were real estate, 
ipv4marketgroup would be a real estate agent), the price of an address was 
stable at or near $10/address from several years, and in 2016-2018 shot to 
about $18/address. They expect the price to start to fall in the next year or 
so, as CIOs figure out that its a waste of money. 

There is no demand until further IPv4 deployment no longer suffices. I would 
say that there was no real market demand until after January 2011, and probably 
2012 or 2013.

At this point, there is fairly wide deployment among the ISP and CDN operators, 
and vendor implementations are fairly complete. Google, APNIC, and Akamai 
report on traffic levels; Google says that they see at least 5% of the requests 
they receive from 61 countries use IPv6, and from one country a tad more that 
half of the requests they receive use IPv6. 
https://www.vyncke.org/ipv6status/compare.php?metric=p=be,yt,de,gr,my,vn,in,gf,us,uy,fr,tw,jp,lu,ch,mx,br,pt,fi,mq,ax,th,ee,re,hu,gb,ca,gp,tt,ie,lk,nz,au,pe,ec,nl,ae,ro,ga,bo,sa,sx,cz,no,si,sg,pl,gt,at,mo,ar,mm,kr,fo,om,lv,zw,pr,ke,tg,ba.
 And interesting point in those reports is that Google and Akamai are CDNs, 
which means that (for the most part) a request goes almost directly from a 
user's broadband interface to the service in question. APNIC is different in 
that it operates no CDN; requests they receive cross the backbone, and 
therefore also measure backbone deployment. To that matter, let me list the 
APNIC charts of the top ten:

https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=BE
https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=YT
https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=DE
https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=GR
https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=MY
https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=VN
https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=IN
https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=GF
https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=US
https://stats.labs.apnic.net/ipv6/CC?x=1=1=1=30=UY

In each of those, APNIC measures and reports a distinction between a requestor 
being "IPv6 Capable" and "Preferring IPv6". This is done using a google ad that 
includes three one-pixel links; one of the names has only an A record, one has 
only a  record, and one bas both. If the requestor uses the first two links 
and APNIC receives the SYN, then the end system and every AS en route used and 
provided an IPv4 or IPv6 capability respectively. In the third case, the end 
system presumably gets both an IPv4 and an IPv6 address, and makes a choice. If 
it chooses IPv6, it is reported as preferring IPv6. If you select the links 

Re: This DNS over HTTP thing

[Fred Baker]

On Sep 30, 2019, at 10:25 PM, Jay R. Ashworth  wrote:
> Is there an official name for it I should be searching for?

The IETF calls it "DoH", pronounced like "Dough". 
https://datatracker.ietf.org/wg/doh/about/

There are a number of such services from Google, Amazon, and others. Firefox 
and Chrome now reportedly use it unless you tell them not to. It is also in use 
by at least one botnet, per reports.

https://www.proofpoint.com/us/threat-insight/post/psixbot-now-using-google-dns-over-https-and-possible-new-sexploitation-module
https://www.zdnet.com/article/first-ever-malware-strain-spotted-abusing-new-doh-dns-over-https-protocol/
https://www.bleepingcomputer.com/news/security/psixbot-modular-malware-gets-new-sextortion-google-doh-upgrades/

One thing that bothers me about the Google implementation is that they 
apparently download the IANA zone and, in effect, operate as an informal root 
server. Not that I am protective of the root per se, but the root operators 
operate by an ethos described in RSSAC001 
(https://www.icann.org/en/system/files/files/rssac-001-root-service-expectations-04dec15-en.pdf.).
 If Google wants to promote itself into those ranks, I would expect it to 
shoulder the ethos and responsibility implied. The articles I pointed to above 
would suggest that it does not.

Re: [nanog] Cisco GLBP/HSRP question -- Has it ever been dis

[Fred Baker]

> On Aug 4, 2019, at 5:29 PM, Chriztoffer Hansen  
> wrote:
> 
> The question was simply about if GLBP/HSRP had ever been up in discussions in 
> the IETF concerning publishing the protocol specifications as a standard. (As 
> pointed out. I totally forgot about the RFC concerning HSRP.) Haven't gotten 
> a response on the GLBP part. Which I am more than doubtful, myself, will ever 
> come to fruition as a standard in an IETF WG.

AFAIK (and any specific knowledge I have of Cisco is dated), Cisco has not 
asked the IETF to standardize its proprietary protocol. An obvious start would 
be for Cisco customers to ask Cisco to do so.

With HSRP/VRRP, someone wrote a specification that they thought Would 
accomplish the Cisco-proprietary objectives, and championed that through IETF 
processes. At least part of that had to do with a Cisco competitor and someone 
who had a bee in their bonnet. I'm not telling you to do that (my observation 
of HSRP/VRRP is that the result has been two competing protocols, not a winner 
and a loser), but it's a question you might ask your vendor about.

Re: What can ISPs do better? Removing racism out of internet

[Fred Baker]

> On Aug 4, 2019, at 8:41 PM, Mehmet Akcin  wrote:
> 
> I am sure there are many sites like this out there, but could network 
> operators do anything to make these sites “not so easy” to be found, reached, 
> and used to end innocent lives?

I''d suggest reducing their reputation rankings, as reported by SpamHous and 
their kin. That's not to say that "Spamhaus and their kin must", although that 
would be one implementation. Another would be to include them also some other 
ranking mechanism in the analysis, and reduce the reputation of such sites in 
the implied alternative.

Another would be to include such rankings in their calculations of whom to 
accept as customers - BGP or otherwise - and if some AS seems to accept such as 
customers, not accept them. I imagine they do, to some extent, but this could 
be followed up more closely.

Re: Best ways to ensure redundancy with no terrestrial ISPs

[Fred Baker]

Between overlaid ads and the thing trying to force an account, i’d Describe it 
as a waste of time. Now, a page that delivered the data advertised...

Sent using a machine that autocorrects in interesting ways...

> On Aug 3, 2019, at 3:36 PM, Mehmet Akcin  wrote:
> 
> 
> Feel free to open live.infrapedia.com on mobile. Click on share location 
> icon. And it will show 3D view of any fiber near by. 
> 
> We are thinking about adding wireless networks too and maybe overlaying 
> national cell phone coverage maps
> 
>> On Sat, Aug 3, 2019 at 14:21 Mark Tinka  wrote:
>> 
>> 
>>> On 3/Aug/19 23:09, Ross Tajvar wrote:
>>> On Sat, Aug 3, 2019 at 4:30 PM Brian Henson  wrote:
 If we had a location (or at least a part of the world) we might be able to 
 recommend a little better. 
>>> 
>>> 
>>> This is in northern Africa.
>> 
>> Hmmh - normally, when someone says North America, it's one of 2 countries. 
>> Not much fuss there...
>> 
>> North Africa (by some kind of definition) is 8 or 10 countries, depending on 
>> what you feel North Africa means.
>> 
>> In short, you'll have to be more specific than that...
>> 
>> 
>> Mark.
>> 
> -- 
> Mehmet
> +1-424-298-1903

Re: 44/8

[Fred Baker]

The fundamental reason given, from several sources, was that our experience 
with IPv4 address trading says that no matter how many IPv4 addresses we create 
or recover, we won't obviate the need for a replacement protocol. The reasons 
for that are two: (1) IPv4 isn't forward compatible with anything (if it had a 
TLV or equivalent for the address, we could have simply extended the address), 
and (2) 2^32 is a finite number less than the number of addressable entities in 
the world. Yes, it would be interesting to use Class E as unicast space. The 
instant we make it possible, it will be bought up by companies and countries 
desperate to delay their IPv6 deployment - and we will then, once again, be out 
of IPv4 space.

We even had a guy write five internet drafts about how it is possible to 
enumerate more than 2^n entities with an n bit number.

Speaking for myself, I don't see the point. It doesn't solve anything, and I'm 
not sure it even meaningfully delays anything. The time has come to move to a 
protocol that allows us to enumerate the set of addressable objects without 
losing our minds.

> On Jul 22, 2019, at 3:04 PM, William Herrin  wrote:
> 
> On Mon, Jul 22, 2019 at 11:56 AM andrew.brant via NANOG  
> wrote:
> Whatever happened to the entire class E block? I know it's reserved for 
> future use, but sounds like that future is now given that we've exhausted all 
> existing allocations.
> 
> The IPv6 loonies killed all IETF proposals to convert it to unicast space. It 
> remains reserved/unusable.
> 
> Regards,
> Bill Herrin
> 
> 
> -- 
> William Herrin
> b...@herrin.us
> https://bill.herrin.us/

Re: who attacks the weather channel?

[Fred Baker]

According to this, Weather Underground was purchased by the Weather Channel and 
firmed “The Weather Company”, and that was in turn purchased by IBM last year.

https://www.wunderground.com/blog/JeffMasters/weather-underground-bought-by-ibm.html

Sent using a machine that autocorrects in interesting ways...

> On Apr 18, 2019, at 8:38 AM, Christopher Morrow  
> wrote:
> 
>> On Thu, Apr 18, 2019 at 11:27 AM Stephane Bortzmeyer  
>> wrote:
>> 
>> On Thu, Apr 18, 2019 at 03:16:34PM +,
>> Kain, Rebecca (.)  wrote
>> a message of 69 lines which said:
>> 
>>> https://www.cnn.com/2019/04/18/media/weather-channel-hack/index.html
>> 
>> May be these people?
>> 
>> https://en.wikipedia.org/wiki/Weather_Underground
> 
> I think WU was actually bought by weatherunderground...

Re: Gi Firewall for mobile subscribers

[Fred Baker]

> On Apr 11, 2019, at 8:43 AM, Owen DeLong  wrote:
> 
> I’m pretty sure that no matter how good your power management is, any cell 
> phone’s battery will die long before its /64 can be scanned.

And that might be the point of the scan - not to find the addresses in use, but 
to deplete the battery. That would have the effect of service denial.


signature.asc
Description: Message signed with OpenPGP

Re: Stupid Question maybe?

[Fred Baker]

On Dec 19, 2018, at 3:50 AM, Brian Kantor  wrote:
> /24 is certainly cleaner than 255.255.255.0.
> 
> I seem to remember it was Phil Karn who in the early 80's suggested
> that expressing subnet masks as the number of bits from the top end
> of the address word was efficient, since subnet masks were always
> a series of ones followd by zeros with no interspersing, which
> was incorporated (or independently invented) about a decade later
> as CIDR a.b.c.d/n notation in RFC1519.
>   - Brian

Actually, not really. In the time frame, there was quite a bit of discussion 
about "discontiguous" subnet masks, which were masks that had at least one zero 
somewhere within the field of ones. There were some who thought they were 
pretty important. I don't recall whether it was Phil that suggested what we now 
call "prefixes" with a "prefix length", but it was not fait accompli.

Going with prefixes as we now describe them certainly simplified a lot of 
things.

Take a glance at https://www.google.com/search?q=discontiguous+subnet+masks for 
a history discussion.


signature.asc
Description: Message signed with OpenPGP

Re: It's been 20 years today (Oct 16, UTC). Hard to believe.

[Fred Baker]

On Oct 16, 2018, at 4:57 PM, Wayne Bouchard  wrote:
> Well, simply put, the idea is that you should be able to compensate
> for a certain amount of deviation from accepted usage as long as its
> still within what the protocol allows (or can be read to allow) but
> that you yourself should act with a fairly strict interpretation. In
> others, don't be the one *causing* the problems...

Indeed. To give a TCP example, the opening exchange is theoretically SYN, SYN 
ACK, ACK. A common case is that it is SYN, SYN ACK, data, either because the 
ACK got lost, or because someone cut a corner. The issue is to note that the 
SYN might have been duplicated in flight, and the receiver might therefore have 
the appearance of two sessions. Which one? The ACK (or data segment) - any 
segment within the sessions - clarifies that. So, if there is a minor protocol 
violation but the intent it clear, follow the intent.

The alternative version of the Robustness Principle: "S**t happens; deal with 
it."

Says someone who has implemented such things...

Victorious warriors win first and then go to war,
Defeated warriors go to war first and then seek to win.
 Sun Tzu



signature.asc
Description: Message signed with OpenPGP

Re: Oct. 3, 2018 EAS Presidential Alert test

[Fred Baker]

> On Oct 7, 2018, at 12:23 PM, b...@theworld.com wrote:
> 
> That was one advantage of the old air raid siren system, it was difficult to 
> ignore and required nothing special to receive (hearing
> impaired excepted.)

Where I grew up, the “Civil Defense Warning” was used for air raids, nuclear 
defense, and tornado warnings. By regulation, it was tested monthly. When we 
heard it, which we did, the usual response was “they’re testing the siren 
again” and resumption of the barely-interrupted activity.

Re: tcp md5 bgp attacks?

[Fred Baker]

Well, think about RST attacks, in which someone bombards a TCP connection with 
TCP RESET in the hopes of threading a needle and taking it down. It's not the 
end of the world - BGP restarts - but there is an outage. The simplest way to 
protect against that (and against having someone with a hijacked IP address 
connect to your router) is to put mutual authentication on the TCP connection. 
Having it also at the BGP layer, and having ACLs to be sure you know what's 
going on, are good things, but TCP MD5, TCP-AO, or IPsec are an awful lot safer.

> On Aug 14, 2018, at 4:28 PM, Grant Taylor via NANOG  wrote:
> 
> On 08/14/2018 03:38 PM, Randy Bush wrote:
>> so we started to wonder if, since we started protecting our bgp
>> sessions with md5 (in the 1990s), are there still folk trying to
>> attack?
> 
> n00b response here
> 
> I thought using ACLs or otherwise protecting the BGP endpoint was best 
> practice.  Thus it's really hard to even try break an MD5 protected BGP 
> session if you can't even establish the TCP connection.
> 
> Everything that I've seen or set up had an ACL to only allow the peer(s) to 
> be able to connect to (from memory) TCP port 179.
> 
> Is there something that I've missed the boat on?
> 
> #learningOpportunity
> 
> 
> 
> --
> Grant. . . .
> unix || die
> 


The fact that there is a highway to hell and a stairway to heaven is an 
interesting comment on projected traffic volume...



signature.asc
Description: Message signed with OpenPGP

Re: How to force rapid ipv6 adoption

[Fred Baker (fred)]

> On Oct 2, 2015, at 2:18 PM, William Herrin <b...@herrin.us> wrote:
> 
> On Fri, Oct 2, 2015 at 5:03 PM, Fred Baker (fred) <f...@cisco.com> wrote:
>> There's no way to change the IPv4 address to be larger
> 
> http://bill.herrin.us/network/ipxl.html
> 
> There's always a way.
> 
> Regards,
> Bill Herrin

We could discuss IPv8 and IPv16...

The question I would ask about your model is how one determines whether one is 
looking at a 32 or 64 bit destination address. Does one, for example, have to 
parse the options field before making that determination? How does that work in 
a router that drops an IPv4 header that is not 20 bytes in length?

There were a number of options kicked around that, in one way or another, 
reused packet fields (what is we assume that fragmentation doesn't ever 
happen?) or inserted options. Right, wrong, or indifferent, it wasn't that it 
wasn't considered, it was that it wasn't chosen.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: How to force rapid ipv6 adoption

[Fred Baker (fred)]

> On Oct 1, 2015, at 3:42 PM, Todd Underwood  wrote:
> 
> it's just a new addressing protocol that happens to not work with the rest
> of the internet.  it's unfortunate that we made that mistake

I understand the comment, but I see some issues with it. The problem isn't that 
IPv6 isn't backward-compatible, or that the changes to the Socket Library 
aren't backward compatible (the socket interface being the reason we have to 
upgrade applications, and btw getaddrinfo *is* backward-compatible), it's that 
the old stuff (IPv4, gethostbyname) aren't forward compatible.

If we had deployed a new protocol that allowed us to use IPv4 addresses as well 
as the new format (which, BTW, we did), it would still be a new protocol that 
had to be deployed and enabled. There's no way to change the IPv4 address to be 
larger, or to get gethostbyname to return a non-IPv4 address. Had there been an 
easy way to expand an IPv4 address to a larger number of bytes, we wouldn't 
have needed to replace IPv4.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: How to build an IPv6-only internal network?

[Fred Baker (fred)]

 On Jul 8, 2015, at 12:53 PM, Cryptographrix cryptograph...@gmail.com wrote:
 
 Hypothetically, I want to build an internal network that runs just IPv6 and
 apply stateless ACLs at redundant external connections.
 
 How do users access the current v4 address space?

There are two short answers:

(1) they don't
(2) they use NAT64 (RFC 6146/6147) translation

https://tools.ietf.org/html/rfc6052
6052 IPv6 Addressing of IPv4/IPv6 Translators. C. Bao, C. Huitema, M.
 Bagnulo, M. Boucadair, X. Li. October 2010. (Format: TXT=41849
 bytes) (Updates RFC4291) (Status: PROPOSED STANDARD) (DOI:
 10.17487/RFC6052)

https://tools.ietf.org/html/rfc6146
6146 Stateful NAT64: Network Address and Protocol Translation from IPv6
 Clients to IPv4 Servers. M. Bagnulo, P. Matthews, I. van Beijnum.
 April 2011. (Format: TXT=107954 bytes) (Status: PROPOSED STANDARD)
 (DOI: 10.17487/RFC6146)

https://tools.ietf.org/html/rfc6147
6147 DNS64: DNS Extensions for Network Address Translation from IPv6
 Clients to IPv4 Servers. M. Bagnulo, A. Sullivan, P. Matthews, I.
 van Beijnum. April 2011. (Format: TXT=75103 bytes) (Status: PROPOSED
 STANDARD) (DOI: 10.17487/RFC6147)

https://tools.ietf.org/html/rfc6877
6877 464XLAT: Combination of Stateful and Stateless Translation. M.
 Mawatari, M. Kawashima, C. Byrne. April 2013. (Format: TXT=31382
 bytes) (Status: INFORMATIONAL) (DOI: 10.17487/RFC6877)

With NAT64, a translator advertises a 96 bit prefix into the IPv6-only network 
as defined in RFC 6052, and attracts traffic destined to an address within it 
(which has an IPv4 address jammed into the last 32 bits) to the translator. The 
DNS translator, when asked for a  record, either has one or doesn't; if it 
doesn't have one, it concocts a  record from said prefix and the IPv4 
address and returns that. The translator extracts the IPv4 address from the 
destination address, and does a stateful mapping of the IPv6 source address 
similar to present NAT44 solutions.

There are several products on the market.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Residential VSAT experiences?

[Fred Baker (fred)]

 On Jun 22, 2015, at 3:11 PM, William Herrin b...@herrin.us wrote:
 
 Two-way satellite systems based on SV's in geostationary orbit (like
 the two you're considering) have high latency. 22,000 miles out,
 another 22,000 miles back and do it again for the return packet.
 You'll start around 500ms latency and go up from there. Any kind of
 interactive session (like SSH and RDP) will be excruciating.

It is indeed. This is first-hand in the sense that I once worked for an earth 
station manufacturer and did a fair bit of work related to this environment, 
and second-hand in that my sister, for a while, used VSAT connectivity to her 
home.

The trick in the context is what's called a performance-enhancing proxy, or 
PEP. What it does, in concept, is terminate a TCP connection at each earth 
station and use some form of private protocol over the bird. Cisco RBSCP (which 
maps TCP connections to SCTP sessions over the bird, 
http://www.cisco.com/c/en/us/td/docs/ios-xml/ios/interface/configuration/15-sy/ir-15-sy-book/ir-rt-bsd-sat.html)
 is an example of such a technology. The obvious benefit of a PEP is that it 
can convince a TCP sender to keep enough data in flight to make good use of the 
throughput rate of the satellite - you have a start-up issue with the first 
RTT, but after that it has essentially figured out what the effective window 
should be and makes that happen. The downside of a PEP is when the application 
is itself interactive (it's not about rate, it's about responsiveness clocked 
by end-to-end RTT) or the protocol in question isn't TCP (noting that TCP in 
IPsec ESP isn't TCP to the PEP - it's IPsec ESP, and can't be goosed along).

In my sister's case, her description of the service was somewhat colorful, and 
included the word slow.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Meeting IRS requirements for encrypted transmission of FTI

[Fred Baker (fred)]

Dumb question. So this is essentially physical or link layer encryption. That’s 
fine out on the wire, but is decrypted in memory (if I understand what you 
said), and requires point to point connectivity to be any better than that. Are 
you aware of anyone at NIST or other places suggesting end to end encryption?

 On Apr 2, 2015, at 3:13 PM, Watson, Bob bob.wat...@wwt.com wrote:
 
 
 Macsec use cases are valid when working with hop by hop encryption needs 
 between closets / buildings where structured wiring is not within control of 
 agency personnel,  in the case of other states we provide consulting services 
 to,  think multi tenant building with shared closet from other state agencies 
 or building leases with outsourced cabling.  Router / firewall based Vpn is 
 an option as well if transiting a consolidated state network or sp based 
 public or private network.  The physical sec control to mitigate true end to 
 end helps reign back some of the costed options.
 
 
 9.3.16.6 Transmission Confidentiality and Integrity (SC-8)
 
 Information systems that receive, process, store, or transmit FTI, must:
 
 a. Protecttheconfidentialityandintegrityoftransmittedinformation.
 b. Implement cryptographic mechanisms to prevent unauthorized disclosure of 
 FTI
 
 and detect changes to information during transmission across the wide area 
 network (WAN) and within the local area network (LAN). (CE1)
 
 If encryption is not used, to reduce the risk of unauthorized access to FTI, 
 the agency must use physical means (e.g., by employing protected physical 
 distribution systems) to ensure that FTI is not accessible to unauthorized 
 users. The agency must ensure that all network infrastructure, access points, 
 wiring, conduits, and cabling are within the control of authorized agency 
 personnel. Network monitoring capabilities must be implemented to detect and 
 monitor for suspicious network traffic. For physical security protections of 
 transmission medium, see Section 9.3.11.4, Access Control for Transmission 
 Medium (PE-4).
 
 This control applies to both internal and external networks and all types of 
 information system components from which information can be transmitted 
 (e.g., servers, mobile devices, notebook computers, printers, copiers, 
 scanners, fax machines).
 
 Sent from my iPad
 
 On Apr 2, 2015, at 2:15 PM, Hunt, Fred - DCF 
 fred.h...@wisconsin.govmailto:fred.h...@wisconsin.gov wrote:
 
 Does anyone have previous experience meeting IRS requirements for the 
 encrypted transmission of FTI across a LAN and WAN, specifically the 
 requirements called for in IRS Publication 1075?
 The IRS tests for the following:
 All FTI data in transit is encrypted when moving across a Wide Area Network 
 (WAN) and within the agency's Local Area Network (LAN).   If FTI is 
 transmitted over a LAN or WAN it is encrypted with FIPS 140-2 validated 
 encryption, using at least a 128-bit encryption key.
 
 MACsec is what we are looking at right now.  I'm wondering if anyone who has 
 been through such an implementation could share lessons learned, gotchas, etc.
 
 Any input is appreciated?
 
 Fred



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: IPv6 allocation plan, security, and 6-to-4 conversion

[Fred Baker (fred)]

 On Jan 29, 2015, at 3:28 PM, Eric Louie elo...@techintegrity.com wrote:
 
 If I have to do 6-to-4 conversion, is there any way to do that with
 multiple diverse ISP connections, or am I restricted to using one
 entry/exit point?  (If that's true, do I need to allocate a separate block
 of addresses that would be designated 6 to 4 so they'd always be routed
 out that one entry/exit point?)

On this point, you may find

https://datatracker.ietf.org/doc/draft-ietf-v6ops-6to4-to-historic
https://tools.ietf.org/html/draft-ietf-v6ops-6to4-to-historic
  Deprecating Anycast Prefix for 6to4 Relay Routers, Ole Troan, Brian
  Carpenter, 2015-01-28

of interest. t is coming from the IETF IPv6 Operations Working Group, and in 
essence suggests that operators not support anycast 6to4. Don’t prevent it, 
please understand, but don’t deploy it, and if it’s causing you problems, turn 
it off.

One of the authors, Brian carpenter, is the original designer of 6to4...


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Fred Baker (fred)]

On Oct 19, 2014, at 5:05 AM, Matthew Petach mpet...@netflight.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?  Where do other world
 powers put their government agency domains?
 
 With the exception of the cctlds, shouldn't the
 top-level gtlds be generically open to anyone
 regardless of borders?
 
 Would love to get any info about the history
 of the decision to make it US-only.
 
 Thanks!
 
 Matt

The short version is that that names were a process. In the beginning, hosts 
simply had names. When DNS came into being, names were transformed from 
“some-name” to “some-name.ARPA”. A few of what we now all gTLDs then came into 
being - .com, .net, .int, .mil, .gov, .edu - and the older .arpa names quickly 
fell into disuse. 

ccTLDs came later.

I’ve been told that the reason God was able to create the earth in seven days 
was that He had no installed base. We do. The funny thing is that you’ll see a 
reflection of the gTLDs underneath the ccTLDs of a number of countries - .ac, 
.ed, and the like.


signature.asc
Description: Message signed with OpenPGP using GPGMail

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

[Fred Baker (fred)]

On Oct 20, 2014, at 10:07 AM, John Orthoefer j...@direwolf.com wrote:

 
 On Oct 20, 2014, at 12:50 PM, Fred Baker (fred) f...@cisco.com wrote:
 
 […] and the older .arpa names quickly fell into disuse. 
 
 
 People don’t use in-addr.arpa anymore?  ;)
 
 johno

They do use that, of course. But for example they don’t go to IANA using a 
.arpa name.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Bare TLD resolutions

[Fred Baker (fred)]

IMHO, since ICANN has created the situation, the ball is in ICANN’s court to 
say how this works without disrupting name services. Their ill-informed hipshot 
is not our emergency.

On Sep 17, 2014, at 9:09 AM, Jay Ashworth j...@baylink.com wrote:

 Pursuant to
 
  https://www.icann.org/resources/pages/name-collision-2013-12-06-en)
 
 mentioned in the Scotland thread... 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.
 
 The latter would seem to be avoidable by making sure that *DNS resolution
 of bare TLDs always returns NXDOMAIN*.
 
 Is that a requirement for a TLD?
 
 If it isn't, does anyone know of any domains dumb enough to actual 
 return something for a lookup on the bare TLD?
 
 Is there actually *any* good reason why a lookup on a bare TLD (com.)
 might return a valid record?
 
 And what about Naomi?
 
 Cheers,
 -- jra
 
 -- 
 Jay R. Ashworth  Baylink   
 j...@baylink.com
 Designer The Things I Think   RFC 2100
 Ashworth  Associates   http://www.bcp38.info  2000 Land Rover DII
 St Petersburg FL USA  BCP38: Ask For It By Name!   +1 727 647 1274



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Prefix hijacking, how to prevent and fix currently

[Fred Baker (fred)]

On Aug 28, 2014, at 9:55 AM, Tarun Dua li...@tarundua.net wrote:

 AS Number 43239
 AS Name SPETSENERGO-AS SpetsEnergo Ltd.
 
 Has started hijacking our IPv4 prefix, while this prefix was NOT in
 production, it worries us that it was this easy for someone to hijack
 it.
 
 http://bgp.he.net/AS43239#_prefixes
 
 103.20.212.0/22 - This belongs to us.
 
 103.238.232.0/22 KNS Techno Integrators Pvt. Ltd.
 193.43.33.0/24 hydrocontrol S.C.R.L.
 193.56.146.0/24 TRAPIL - Societe des Transports Petroliers par Pipeline
 
 Where do we complain to get this fixed.
 
 -Tarun
 AS132420

Do you implement RPKI? Are providers that neighbor with them implementing RPKI?

If not, complain to the folks not indicating RPKI and therefore accepting a 
hijacked prefix. Including yourself.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Carrier Grade NAT

[Fred Baker (fred)]

On Jul 30, 2014, at 8:45 AM, Owen DeLong o...@delong.com wrote:

 I will say that if amazon would get off the dime and support IPv6, it would 
 make a significant difference. 

Per Microsoft public statements, they are now moving address space allocated 
them in Brazil to the US to fill a major service shortfall in Azure. They’re 
not the only kids on the block with that problem, but are perhaps the one most 
publicly reported. To my way of thinking, having services like that adopt IPv6 
and tell their customers that they need to access the service using IPv6 would 
go a lot farther that residential service in pushing enterprise adoption.

http://tools.ietf.org/html/draft-anderson-siit-dc gives a fairly clever way to 
make it possible for the service itself to be IPv6-only and yet provide IPv4 
access, and preserve IPv4 addresses in the process.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Carrier Grade NAT

[Fred Baker (fred)]

On Jul 30, 2014, at 8:45 AM, Owen DeLong o...@delong.com wrote:

 I will say that if amazon would get off the dime and support IPv6, it would 
 make a significant difference. 

Someone that works for Amazon once told me that they are primed for it now; the 
question is whether their customers tick the box appropriately.

Per Microsoft public statements, they are now moving address space allocated 
them in Brazil to the US to fill a major service shortfall in Azure. They’re 
not the only kids on the block with that problem, but are perhaps the one most 
publicly reported. To my way of thinking, having services like that adopt IPv6 
and tell their customers that they need to access the service using IPv6 would 
go a lot farther than residential service in pushing enterprise adoption.

http://tools.ietf.org/html/draft-anderson-siit-dc gives a fairly clever way to 
make it possible for the service itself to be IPv6-only and yet provide IPv4 
access, and preserve IPv4 addresses in the process. If I’m not mistaken, it’s 
pretty much what Facebook and others like them have implemented, with a view to 
being internally IPv6-only within a relatively short timeframe.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Inevitable death, was Re: Verizon Public Policy on Netflix

[Fred Baker (fred)]

On Jul 14, 2014, at 4:32 PM, Scott Helms khe...@zcorum.com wrote:

 I continue to vehemently disagree with the notion that ASN = ISP since
 many/most of the ASNs represent business networks that have nothing to do
 with Internet access.

And there are a number of ISPs with multiple ASNs.

If you look up the history of the term, Autonomous System is used without 
definition in most of its earlier RFCs, such as 820, 827, and 1105. In short, 
though, it is a network that connects to other networks using a routing 
protocol such as EGP or eBGP. The best formal definition I have seen involves 
a collection of physical networks under common administration which are 
reachable from the rest of the Internet by a common route. The quote is from 
RFC 1000 and refers to the domain of a prefix, but it's pretty close. An 
Autonomous System Number is a creature of EGP or BGP Routing, and identifies 
such a system.

If you look at http://bgp.potaroo.net/as6447/ and search for “AS numbers”, and 
you happen to be looking at exactly this instant (it changes), you’ll find that 
AS 6447 sees 47879 individual AS numbers in the Internet, of which 40339 show 
up *only* as origins (and therefore have to do with the AS a source or 
destination of traffic), 236 *never* show up as end last AS in an AS Path (and 
therefore are *always* transit), and 7304 that are sometimes origin and 
sometimes transit. To my small mind, an AS that functions as an ISP if highly 
likely to show up as a transit network, and an AS that never shows up as 
transit is very likely to be multihomed or to have justified its AS number on 
the basis of plans to multihome. Of course, one will also find that 30134 AS’s 
are origin AS’s visible through exactly one AS path, which says that at this 
instant they’re not actually multihomed.

No, AS != ISP. An AS is a network that needs to be identifiable in global 
routing but would be entirely reachable even if it had exactly one link with 
some other network.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: Net Neutrality...

[Fred Baker (fred)]

Relevant article by former FCC Chair

http://www.washingtonpost.com/posteverything/wp/2014/07/14/this-is-why-the-government-should-never-control-the-internet/


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: We hit half-million: The Cidr Report

[Fred Baker (fred)]

On May 1, 2014, at 4:10 PM, Jean-Francois Mezei jfmezei_na...@vaxination.ca 
wrote:

 Pardon my ignorance here. But in a carrier-grade NAT implementation that
 serves say 5000 users, when happens when someone from the outside tries
 to connect to port 80 of the shared routable IP ? 

More to the point, your trust boundary includes 5000 people. Do you know them 
all? Who maintains their systems and software? Do you trust them?

What happens if they approach you from behind the NAT?


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: The Cidr Report

[Fred Baker (fred)]

On Apr 26, 2014, at 12:19 PM, Deepak Jain dee...@ai.net wrote:

 Does anyone have doomsday plots of IPv6 prefixes? We are already at something 
 like 20,000 prefixes there, and a surprising number of deaggregates (like 
 /64s) in the global table. IIRC, a bunch of platforms will fall over at 
 128K/256K IPv6 prefixes (but sooner, really, because of IPv4 dual stack).

A /64 deaggregte only makes it through because folks let it; there’s something 
to be said for filters. That said, one might generally expect every AS (there 
are about 60K or them, I gather) to have one prefix, and if it deaggregates, it 
might be reasonable to expect it to multiply by four. RIR online records 
suggest that someone that asks for additional addresses beyond their /32 is 
told to shorten the existing prefix, not allocated a new one - the same prefix 
becomes a /31 or whatever. The reason we have 500K+ IPv4 prefixes is because we 
hand them out in dribbles, and there is no correlation between the one you 
received last week and the one you receive today.

Geoff’s slides are interesting in part because of their observations regarding 
deaggregates. If 1% of of all AS’s advertise over half of the deaggregates, 
that seems like a problem their neighbors can help with, and if not them, the 
neighbors' neighbors. It’s hard to imagine that a single Ethernet (a single 
/64) is so critical that the entire world needs a distinct route to it.

In any event, I would not approach this as a statistical issue, and say “well, 
IPv4 grew in a certain way, and IPv6 will do the same”. It can. But we have had 
the opportunity to think ahead and plan for the growth, and the RIR communities 
have been planning. It seems likely that, with a little care, IPv6 should do 
quite a bit better.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: IPv6 isn't SMTP

[Fred Baker (fred)]

On Mar 25, 2014, at 8:31 PM, Cutler James R james.cut...@consultant.com wrote:

 3.  Arguing about IPv6 in the context of requirements upon SMTP connections 
 is playing that uncomfortable game with one’s own combat boots.  And not 
 particularly productive.

That is one of my two big take-aways from this conversation. The other is that 
operators of SMTP MTAs should implement RDNS for them, which I thought we 
already knew.

To my knowledge, there are three impacts that IPv6 implementation makes on an 
SMTP implementation. One is that the OS interface to get the address of the 
next MUA or MTA needs to use getaddrinfo() instead of gethostbyname() (and 
would do well to observe RFC 6555’s considerations). Another is that, whether 
on an incoming or an outbound connection, when the application gets its own 
address from the OS (binary or as a character string), it needs to allocate 
more storage for the data structure. The third is that it needs to be able to 
interpret user@2001:db8::1 as well as user@dns-name and user@192.0.2.1. 

All things considered, that’s a pretty narrow change set.

Everyone here, no doubt, is clueful enough to implement RDNS for their MTAs. We 
know that there are people in the world that don’t implement it for IPv4. Yet, 
here we are, using SMTP/IPv4 to discuss this, and I don’t hear anyone saying 
that IPv4 isn’t ready for prime time as a result of the fact of some operators 
not implementing RDNS.

...



signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: NAT64 and matching identities

[Fred Baker (fred)]

On Nov 19, 2013, at 8:36 AM, Andrew Sullivan asulli...@dyn.com wrote:

 On Mon, Nov 18, 2013 at 03:06:52PM -0500, Justin M. Streiner wrote:
 Other IPv6 transition mechanisms appear to be no less thorny than
 NAT64 for a variety of reasons.
 
 Some of us who worked on the NAT64/DNS64 combination were content that
 it was a long way from the perfect solution.  The idea I at least had
 was to get something that mostly worked most of the time, and was
 simple enough that anyone could basically understand it.
 Nevertheless, I have to admit that it's a pig.
 
 That piggishness was not something I wanted to get rid of.  I thought
 (and still think) that if the transition mechanisms are awful enough,
 it will encourage moving things to v6 for real so that we can get rid
 of the kludges.  Perhaps this is wishful thinking, however.  
 
 In any case, I'm sorry to have contributed in some little way to this
 headache of yours.

Speaking as one of the co-authors of RFC 6052, 6144, and 6145...

I'm actually not sorry. The predecessor to RFCs 6052/6144/6145/6146/6147 was 
NAT-PT, which didn't work very well in part due to a nasty coupling (see RFC 
4966). It's pretty straightforward to insert an IPv4 address into a specified 
IPv6 prefix (RFC 6052), and use that to statelessly translate between a IPv4 
address and an RFC 6052 address (RFC 6145), or to statefully translate a random 
IPv6 address into an IPv4 space much in the way IPv4/IPv4 translation works 
(RFC 6146). What is hard is statefully translating from IPv4 to a generic IPv6 
address - its hard to compress 128 bits of information into 32 bits. NAT-PT 
does it by having the DNS lookup temporarily assign an IPv4 address to the IPv6 
device and inform the translator of the translation. 
http://tools.ietf.org/html/draft-anderson-siit-dc (which Tore didn't, to my 
knowledge, try to get turned into an RFC, although I'd be willing to discuss 
that with v6ops) does it by pre-assigning address pairs, enabling an IPv6-only 
domain to be accessed from an IPv4-only domain by a defined translation between 
the two for a small set of servers.

I'm all for helping people to transition. Where I get a little crazy is when 
the so-called transition tool makes them comfortable enough that they think 
they don't need to. What I expect to see in the IETF over the coming few years 
- and which I see in detail coming from several nationality competitors and 
their nationality network customers now - is a series of ideas of the form 
but people with ancient IPv4-only hosts are having trouble with the IPv6 
network; let's do this *temporary* patch to ease their pain. I submit that the 
best way to ease their pain is to upgrade their hosts. They will have to deal 
with it at some point.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: IP Fragmentation - Not reliable over the Internet?

[Fred Baker (fred)]

On Aug 27, 2013, at 12:34 AM, Owen DeLong o...@delong.com wrote:

 If I send a packet out as a legitimate series of fragments, what is the chance
 that they will get dropped somewhere in the middle of the path between the
 emitting host and the receiving host?
 
 To my thinking, the answer to that question is basically pretty close to 0 
 and
 if that changes in the core, very bad things will happen.

I mostly agree. I will argue that the actual path of an IP datagram is end to 
end, so the question is not the core, but the end to end path.

That said, with today's congestion control algorithms, TCP does pretty badly 
with an other-than-negligible loss rate, so end to end, fragmented messages 
have a negligible probability of being dropped, so the probability of sending a 
message that is fragmented and having it arrive at the intended destination is 
a negligibly small probability smaller than then probability of sending an 
unfragmented message and having it arrive.

The primary argument against that is firewall behavior, in which firewalls are 
programmed to drop fragments with high probability.

If we had a protocol that sat atop IP and did what fragmentation does that we 
could expect all non-TCP/SCTP protocols to use, I would have a very different 
viewpoint. But, playing the ball where it lies, the primary change I would 
recommend would be to support any firewall rule that permitted dropping the 
first fragment of a fragmented datagram in which the first fragment did NOT 
include the entire IP header and the entire subsequent header, and expecting a 
host to keep a fragment of a datagram no more than some stated number of 
seconds (I might pick two) with express permission to drop it more rapidly 
should the need arise. I would *not* support a rule that simple dropped 
fragments, or a protocol change that disallowed them.


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: It's the end of the world as we know it -- REM

[Fred Baker (fred)]

I guess my question is what the difference is between the sharp-demand curve 
(Tony's latest, which perhaps mirrors APNIC's final few months of IPv4) and the 
straight-line curve. My read is that we're arguing about the difference between 
late 2013 and some time in 2014. I suspect that what most ISPs are going to 
find necessary is some combination of keeping the lights burning in IPv4-land, 
by whatever means, and deploying the next generation.

Frankly, the ISPs likely to be tracking this list aren't the people holding 
back there. To pick on one that is fairly public, Verizon Wireline is running 
dual stack for at least its FIOS customers, and also deploying CGN, and being 
pretty up front about the impacts of CGN. Verizon Wireless, if I understand the 
statistics available, is estimated to have about 1/4 of its client handsets 
accessing Google/Yahoo/Facebook using IPv6.

http://www.verizon.com/support/residential/internet/highspeedinternet/networking/troubleshooting/portforwarding/123897.htm
http://www22.verizon.com/Support/Residential/Internet/HighSpeed/General+Support/Top+Questions/QuestionsOne/ATLAS8742.htm
http://www.worldipv6launch.org/measurements/

Where we're having trouble is in enterprise and residential deployments. 
Enterprise tends to view the address space run-out as Somebody Else's Problem - 
behind their NATs, they generally have enough address space to work with. On 
the residential side, the X-Box is still IPv4-only, Skype is still IPv4-only, 
the vast majority of residential gateways used by broadband subscribers are 
IPv4-only.

Some broadband ISPs are taking steps toward a managed service offering, by 
selling their customers a replacement router. If the router is IPv6-capable, 
that helps.

If we really want to help the cause, I suspect that focusing attention on 
enterprise, and finding ways to convince them that address shortages are also 
their problem, will help the most.

Re: It's the end of the world as we know it -- REM

[Fred Baker (fred)]

On Apr 24, 2013, at 4:50 PM, Michael Thomas m...@mtcc.com
 wrote:

 On 04/24/2013 03:26 PM, Fred Baker (fred) wrote:
 
 Frankly, the ISPs likely to be tracking this list aren't the people holding 
 back there. To pick on one that is fairly public, Verizon Wireline is 
 running dual stack for at least its FIOS customers, and also deploying CGN, 
 and being pretty up front about the impacts of CGN. Verizon Wireless, if I 
 understand the statistics available, is estimated to have about 1/4 of its 
 client handsets accessing Google/Yahoo/Facebook using IPv6.
 
 Fred, isn't the larger problem those enterprise's outward facing web presence,
 etc? As great as it is that vzw is deploying on handsets, don't they also need
 to dual-stack and by inference cgn (eventually) so that their customers can 
 get
 at the long tail of non-v6 sites?

Kind of my point. I hear a lot of complaining of the form I don't need to 
deploy IPv6 because there is relatively little traffic out there. Well, 
surprise surprise. That's a little like me saying that I don't need to learn 
Chinese because nobody speaks to me in Chinese. There are a lot of Chinese 
speakers; they don't speak to me in Chinese, which they often prefer to speak 
among themselves, because I wouldn't have a clue what they were saying.

The Verizon Wireless numbers, and a list of others on the same page, tell me 
that if offered a  record, networks and the equipment that use them will in 
fact use IPv6. What is in the way is the residential gateway, which is often 
IPv4-only, and the enterprise web and email service, which is often IPv4 only. 
You want to fix that, fix the residential gateway, the enterprise load 
balancer, and the connectivity between them and their respective upstreams.

Re: De-funding the ITU

[Fred Baker (fred)]

On Jan 12, 2013, at 8:17 PM, John Levine jo...@iecc.com wrote:

 Please learn a little more about the ITU before doing so.  There is
 more to the ITU than the dysfunctional ITU-T, and the political
 fallout from the US being seen as a big rich bully taking its wallet
 and going home is likely not worth the trivial amount of money
 involved.

On that I would agree. ITU-D and ITU-R do a lot of good work. ITU-T does 
reasonable work, for the most part, in regulatory matters, which neither the 
IGF nor the IETF address. Frankly, if the ITU gets shut down, ITU-R, ITU-D, and 
the regulatory component of ITU-T will have to be re-created to accomplish 
those roles. Where we have travelled in circles with the ITU is in conflicting 
technical standardization and in the desire of ITU-T staff to take over certain 
functions from ICANN and the NRO. Shutting down the ITU would be in effect 
discarding the baby with the bathwater.

http://www.itu.int/en/ITU-R/pages/default.aspx
http://www.itu.int/en/ITU-D/Pages/default.aspx

Re: TCP time_wait and port exhaustion for servers

[Fred Baker (fred)]

If you want to get into software rewriting, the simplest thing I might come up 
with would be to put TCBs in some form of LRU list and, at a point where you 
need a port back, close the TCB that least recently did anything. My 
understanding is that this was implemented 15 years ago to manage SYN attacks, 
and could be built on to manage this form of attack.

Or, change the period of time a TCB is willing to stay in time-wait. Instead of 
60 seconds, make it 10.

On Dec 5, 2012, at 1:11 PM, Jon Lewis wrote:

 On Wed, 5 Dec 2012, Ray Soucy wrote:
 
 So if I rebuild the kernel to use a 20 second timeout, then that 3
 port pool can sustain 1500, and a 6 port pool can sustain 3000
 connections per second.
 
 The software could be re-written to round-robin though IP addresses
 for outgoing requests, but trying to avoid that.
 
 It's kind of a hack, but you don't have to rewrite the software to get 
 different source IPs for different connections.  On linux, you could do the 
 following:
 
 *) Keep your normal default route
 *) Configure extra IPs as aliases (eth0:0, eth0:1,...) on the proxy
 *) Split up the internet into however many subnets you have proxy host IPs *) 
 route each part of the internet to your default gateway tacking on dev 
 eth0:n.
 
 This will make the default IP for reaching each subnet of the internet the IP 
 from eth0:n.
 
 Of course you probably won't get very good load balancing of connections over 
 your IPs that way, but it's better than nothing and a really quick fix that 
 would give you immediate additional capacity.
 
 I was going to also suggest, that to get better balancing, you could 
 periodically (for some relatively short period) rotate the internet subnet 
 routes such that you'd change which parts of the internet were pointed at 
 which dev eth0:n every so many seconds or minutes, but that's kind of 
 annoying to people like me (similar to the problem I recently posted about 
 with ATT 3G data web proxy).  Having your software round robin the source 
 IPs would probably introduce the same problem/effect.
 
 --
 Jon Lewis, MCP :)   |  I route
 Senior Network Engineer |  therefore you are
 Atlantic Net|
 _ http://www.lewis.org/~jlewis/pgp for PGP public key_
 

Re: IPv6 Netowrk Device Numbering BP

[Fred Baker (fred)]

On Nov 1, 2012, at 8:20 AM, Masataka Ohta wrote:

 We should better introduce partially decimal format for
 IPv6 addresses or, better, avoid IPv6 entirely.

With respect, it is already possible to use the decimal subset if you wish. For 
example, you could write

2001:dba::192:168:2:1

It wouldn't be very dense, but EID density wasn't the objective.

Re: abha ahuja

[Fred Baker (fred)]

On Oct 20, 2012, at 3:41 PM, Randy Bush wrote:

 abha ahuja died this day in 2001.  wonderful person, good netizen, good
 researcher.  sigh.

Yes. She is missed.

Re: IPv4 address length technical design

[Fred Baker (fred)]

On Oct 5, 2012, at 4:34 PM, Barry Shein wrote:

 Well, XNS (Xerox Networking System from PARC) used basically MAC
 addresses. Less a demonstration of success than that it has been
 tried. But it's where ethernet MAC addresses come from, they're just
 XNS addresses and maybe this has changed but Xerox used to manage the
 master 802 OUI list and are assigned OUIs 00...09. Not
 insignificant in their effect.

You need a memory refresh. XNS used a three part address: network number, host 
identifier, and socket number. Socket was in essence the TCP/UDP Port Number. 
the host identifier was as you say a 48 bit number and generally took as its 
value the MAC address on one of the interfaces - and the same MAC address was 
used on all interfaces. Hence, no need for ARP/ND. The network number was a 32 
bit number assigned to a LAN subnet. A multihomed host essentially implemented 
ILNP. 

The issue with the network number was, of course, that it couldn't be 
aggregated in any useful way. But XNS was not ethernet bridging on a wide scale.

Re: The End-To-End Internet (was Re: Blocking MX query)

[Fred Baker (fred)]

It would be really nice if people making statements about the end to end 
principle would talk about the end to end principle.

http://web.mit.edu/Saltzer/www/publications/endtoend/endtoend.pdf

The abstract of the paper states the principle:

This paper presents a design principle that helps guide
placement of functions among the modules of a distributed
computer system. The principle, called the end-to-end
argument, suggests that functions placed at low levels of a
system may be redundant or of little value when compared
with the cost of providing them at that low level. Examples
discussed in the paper include bit error recovery, security
using encryption, duplicate message suppression, recovery
from system crashes, and delivery acknowledgement. Low level
mechanisms to support these functions are justified only as
performance enhancements.

One of the authors of the paper has since restated it in a way that is 
significantly less useful, which is that the only place anything intelligent 
should be done in a network is in the end system. If you believe that argument, 
then WiFi networks should not retransmit lost packets (and as a result would 
become far less useful) and the Internet should not use routing protocols - it 
should only use source routing. So, yes, I think the Rise of the Stupid 
Network is a very interesting paper and site, but needs to be handled 
carefully.

The argument argues for simplicity and transparency; when a function at a lower 
layer does something an upper layer - not just the application, but any 
respectively higher and lower layers - it can be difficult to debug the 
behavior. However, it is not a hard-and-fast the network should never do 
things that the end system doesn't expect; the paper makes it clear that there 
is a trade-off, and if the trade-off makes sense (retransmitting at the link 
layer in addition to the end to end retransmission in the case of WiFi) it 
doesn't preclude the behavior. It merely suggests that one think about such 
things (retransmitting in LAPB turned out to be a bad idea way back when). 
Complexities of various types are unavoidable; to quote a fourteenth century 
logician, a satisfactory syllogism contains no unnecessary complexity.

Yes, I think that stateful network address translation violates the end to end 
principle. But it doesn't violate it because everyone can't talk with everyone 
directly; it violates it because a change is made in a packet that subverts an 
end system's intent and as a result randomly breaks things (for example, an 
ICMP packet-too-large response has to be specially handled by the NAT to make 
PMTU work). I would argue that a network-imposed policies like traffic filters 
violate the end to end principle no more than network-imposed routing 
(including not-routing) policies do. If you can't get somewhere or a given 
address isn't instantiated with a host, that's not particularly surprising. 
What might be surprising and difficult to diagnose would be something that 
sometimes allows packets through and sometimes doesn't without any clear reason.

I suspect everyone on this list will agree that the KISS principle, aka 
end-to-end, is pretty important, and get irritated with vendors (cough) that 
push them towards complex solutions. A host directly sending mail to a remote 
MTA is not automatically a bad actor for any reason related to KISS. There are 
two issues, however, that you might think about. My employer tells me that they 
discard about 98% of email traffic headed to me; a study of my own email 
history says that the email from outside that passes that filter and which is 
what I expect to receive comes through less than 1000 immediate SMTP 
predecessors to the first Cisco MTA; running the same survey on my junk folder 
(which is only 30 days, not 18 years) has about 5000 SMTP predecessors, the 
1000 and the 5000 are disjoint sets. So an SMTP connection to a remote MTA is 
not a bad thing automatically, but it raises security eyebrows - and should - 
because it is similar to how spam and other attacks are transmitted. In 
addition, at least historically, in many cases those MUAs directly connecting 
to remote MTAs try or tried to use them as open relays, and it was difficult 
for the relay to authenticate random systems. Having an MUA give its traffic to 
a first hop MTA using SSL or some other form of service 
authentication/authorization improves the security of the service. That can be 
overcome using S/MIME, of course, given a global PKI, but DKIM depends on the 
premise that the originator has somehow been authenticated and shown to be 
authorized to send email.

On Sep 4, 2012, at 11:22 AM, Jay Ashworth wrote:

 - Original Message -
 From: Owen DeLong o...@delong.com
 
 I am confused... I don't understand your comment.
 
 It is regularly alleged, on this mailing list, that NAT is bad *because it 
 violates the end-to-end principle of the Internet*, 

Re: Testing 1gbps bandwidth

[Fred Baker (fred)]

On Aug 14, 2012, at 4:40 AM, valdis.kletni...@vt.edu
 valdis.kletni...@vt.edu wrote:

 On Tue, 14 Aug 2012 15:32:47 +0400, Luqman Kondeth said:
 Is anyone aware of any public IPerf servers in the middle east or close
 by?(Europe) or anywhere that can do udp?. I have a 1gbps Internet link
 which I've been asked to show that it has 1gbps download speeds.
 
 First thing that comes to mind is remembering the difference between
 end-to-end throughput and the throughput across one link in the chain.
 If you really need to validate the one link, you probably need to get some
 system to inject packets at the other end of the link.

You might take a look at http://www.ameinfo.com/broadband_speed_checker/. I 
can't say I know anything about them beyond what Google says they say about 
themselves, but they claim to be able to test such things.

Let me put hands and feet on what Valdis points out. With a gigabit interface, 
you are able to carry about 83,333 1500 byte packets per second. If you're 
trying to download a file from, say, an Akamai server, TCP will allow you to 
move one window per round trip. If you are using standard window scaling (e.g., 
your window is in the neighborhood of 65,000 bytes), you can achieve 1 GBPS 
only if your round trip time is in the neighborhood of half a millisecond. 
Outside of a data center, such an RTT is Really Unusual. The obvious 
alternative is to use a larger window scaling value: if your RTT is 20 ms, 
scale up by at least 40 times, which is to say a shift of 6 bits for a 
multiplier of 64. Even with that, TCP's normal way of operating will prevent it 
from using the entire gigabit until quite a way into the session. You'll need a 
Really Long File.

The reason you get such an interface, I would imagine, is that you have a large 
number of users behind that interface and/or you are routinely moving a large 
amount of data. You can make it easier for yourself if you get a large number 
of your users to each download something really large all at the same time, and 
measure the performance at the interface.

Or, and this is a lot easier but involves math, you can turn on 
wireshark/Netflow/tcpdump/something that will record actual throughput, and 
download a file of your choosing. Later, offline, you can determine that you 
moved some number of bytes within some unit of time and the ratio is 1 GBPS, 
although you only ran the test for 20 ms or whatever.

Even those have caveats; upstream, you're sharing a link within your ISP with 
someone else. It's just possible that while your link will happily carry 1 
GBPS, at the instant you test, the upstream link gets hit with some heavy load 
and AT THAT INSTANT only has 750 MBPS for you, making your link look like it 
only supports 750 MBPS. That would be possible in any of the tests I just 
mentioned.

What Valdis is suggesting is to have someone at your ISP literally connect to 
their router and send you traffic at a 1 GBPS or faster rate for a period of 
time, while you record that with wireshark/netflow/etc. You can then do the 
math and record the result.

Re: using reserved IPv6 space

[Fred Baker (fred)]

On Jul 13, 2012, at 8:05 AM, TJ wrote:

 On Fri, Jul 13, 2012 at 10:38 AM, -Hammer- bhmc...@gmail.com wrote:
 
 OK. I'm pretty sure I'm gonna get some flak for this but I'll share this
 question and it's background anyway. Please be gentle.
 
 In the past, with IPv4, we have used reserved or non-routable space
 Internally in production for segments that won't be seen anywhere else.
 Examples? A sync VLAN for some FWs to share state. An IBGP link between
 routers that will never be seen or advertised. In those cases, we have
 often used 192.0.2.0/24. It's reserved and never used and even if it did
 get used one day we aren't routing it internally. It's just on segments
 where we need some L3 that will never be seen.
 
 On to IPv6
 
 I was considering taking the same approach. Maybe using 0100::/8 or
 1000::/4 or A000::/3 as a space for this.
 
 
 
 Would using just Link Locals not be sufficient?

If they're on the same link, of course. My understanding of the question said 
they're not on the same link.

 *(Failing that, as others noted, ULAs are the next right answer ... )*
 *
 *
 /TJ

Re: Wacky Weekend: The '.secure' gTLD

[Fred Baker]

On May 31, 2012, at 5:43 PM, Grant Ridder wrote:

 I think this is an interesting concept, but i don't know how well it will
 hold up in the long run.  All the initial verification and continuous
 scanning will no doubtingly give the .secure TLD a high cost relative to
 other TLD's.

not necessarily. It can be done with a laptop that does dig and sends email 
to the place.

What will drive the price up is the lawsuits that come out of the woodwork when 
they start trying to enforce their provisions. What? I have already printed my 
letterhead! What do you mean my busted DKIM service is a problem?

BTW, getting DKIM on stuff isn't the issue. I'm already getting spam with DKIM 
headers in it. It's getting the policy in place that if a domain is known to be 
using DKIM, to drop traffic from it that isn't signed or for which the 
signature fails.

You may find the following exchange with my military son, whose buddies 
apparently call me skynet, amusing...

Begin forwarded message:

 From: Fred Baker f...@cisco.com
 Date: May 9, 2012 12:55:40 PM PDT
 To: Colin Baker ...
 Subject: Re: skynet
 
 On May 9, 2012, at 2:14 PM, Colin Baker wrote:
 so my friends and i have taken to calling you 'Skynet' since you
 invented the internet and have full access to all technological
 secrets...
 
 A question came up last night regarding phishing attempts.  When we
 call our banks or other companies, we have to identify as the customer
 by giving specific info such as mother's maiden name, password, last
 4, etc.  That is so the company knows that this is us and not an
 identify thief.
 
 Why dont companies have to do the same thing with us?  I could get a
 random call from someone claiming to be Wells Fargo, but they dont
 have to do anything like 'the wells fargo secret code is 117 and the
 authentication for me to call about your account is 7G.'  would it
 make sense to have that sort of two-way authentication?
 
 We thought you might know, since your hands are in every realm of
 current business practices, technology, and you read the encyclopedia
 as a kid.
 
 Well, show this to your buddies.
 
 If you're using Apple Mail, right now, go to the View bar, go down to 
 Message, and from there to Raw Source. An email message contains two 
 parts - one that is the email itself, and one (called the envelope) that 
 contains information used in sending the message around. There will be 
 several lines that start with Received:; they tell you that the message was 
 received by a specific Mail Transfer Agent (an application running on a 
 computer) at a certain time; if there are several of them, you can infer that 
 the MTA that received it sent it to the next, and if you're looking for 
 delays in mail transfer, a large difference in time is a smoking weapon 
 saying where that delay was.
 
 Also in the envelope, you may find a datum that looks like:
 
 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple;
 d=cisco.com; i=t...@cisco.com; l=319; q=dns/txt;
 s=iport; t=1336587580; x=1337797180;
 h=subject:mime-version:from:in-reply-to:date:cc:
  content-transfer-encoding:message-id:references:to;
 bh=cXlHIR7jgb7lDsoGWEAx6MS6AJ7zJwnnwkO+N7lsBqs=;
 b=gks8REH7Yho0kcjPt/+H8FJMmi0qF/tZ/mpARWFevTiObT64ZaXog3+k
  tDKdaPOAYQYJ8OoJfT/ynOGdtOnN87adlM0lUoDgY5s7bg6juBnaSESG0
  UMo18OTQiwuXzV94LNzNSl3lsH++1tfzbsNJe1p+TzjGtBljFoQgMZu4l
  c=;
 
 That particular one is from an email sent to me by a colleague named Tony Li 
 t...@cisco.com, who is a Cisco employee. It gives you proof that the 
 message originated from Cisco, and in this case, that Cisco believes that it 
 was originated by Tony Li.
 
 I'll bet you find a similar thing in this very note.
 
 DKIM stands for Domain Keys Identified Mail, and is used by Google, 
 Yahoo, and Cisco among others. Here's the DKIM Information Element from the 
 email you sent me:
 
 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed;
   d=gmail.com; s=20120113;
   h=mime-version:date:message-id:subject:from:to:content-type;
   bh=+PAULPy6MwBt3TU1am4I5yRRvfudEeK0k2nzWGCD6kY=;
   b=aKMwdM9q/Jh72pJ51i3Kyumy6wIMk6osgAfCyukFh2ATgiy3yWuu5oam4/DgRvo81+
OD0xeYqSyTx2Z2qjUxHtz9kl5nxCkNWlePbOjefog0gfPH1nKN/Kw/562k7OFvl3WeXd
hOIfpNOZb+W5wBIavFg9HKLvr8oDCcNNNkAx0c4WlynMNodcpQVkFchsYDFfV0x5jNme
st/+XLCNmjE1h73/WGmRn3AVJ7WaHKWWdW8PDKw2p1HLnrN8l1FCDeWDX6dMHtABSLuH
C5ScenHkhgPDcAyDdjSmVqEPmuaUB4GU7BaNRqwsUMjcvJZxYuOETux05pBYY2HpRYTC
D6yQ==
 
 The theory is that if someone (your MTA, not your computer) receives such an 
 information element, it can apply a policy. The policy might say 
 
 - I don't think that domain  implements DKIM, so I'll just accept the 
 message, or 
 - I think it does, but this email doesn't have one, so obviously this isn't 
 from that domain and therefore is bogus; I'll drop it, or 
 - I think it does, and this email has one, but the signature is bogus; I'll 
 drop it, or 
 - I think it does, and this email has one that checks out, so I'll

Re: World IPv6 Launch Day - June 6, 2012

[Fred Baker]

On Jan 18, 2012, at 9:03 AM, Shumon Huque wrote:

 But, checking www.worldipv6launch.org just now shows that it
 have IPv6 records now:

I just successfully accessed it using IPv6. The service is real, not just the 
DNS record. The address I accessed it at was 2600:809:600::3f50:411.

Re: question regarding US requirements for journaling public email (possible legislation?)

[Fred Baker]

On Jan 5, 2012, at 10:42 AM, William Herrin wrote:

 On Thu, Jan 5, 2012 at 10:56 AM, Eric J Esslinger eesslin...@fpu-tn.com 
 wrote:
 His response was there is legislation being pushed in both
 House and Senate that would require journalling for 2 or 5
 years, all mail passing through all of your mail servers.
 
 Hi Eric,
 
 The only relatively recent thing I'm aware of in the Congress is the
 Protecting Children From Internet Pornographers Act of 2011.

Since you bring it up, I sent this to Eric a few moments ago. Like you, IANAL, 
and this is not legal advice.

 From: Fred Baker f...@cisco.com
 Date: January 5, 2012 10:46:30 AM PST
 To: Eric J Esslinger eesslin...@fpu-tn.com
 Subject: Re: question regarding US requirements for journaling public email 
 (possible legislation?)
 
 I don't know of anything on email journaling, but you might look into section 
 4 of the Protecting Children From Internet Pornographers Act of 2011, which 
 asks you to log IP addresses allocated to subscribers. My guess is that the 
 concern is correct, but the details have morphed into urban legend.
 
 http://www.govtrack.us/congress/billtext.xpd?bill=h112-1981
 http://www.techdirt.com/articles/20110707/04402514995/congress-tries-to-hide-massive-data-retention-law-pretending-its-anti-child-porn-law.shtml
 
 I'm not sure I see this as shrilly as the techdirt article does, but it is in 
 fact enabling legislation for a part of Article 20 of the COE Cybercrime 
 Convention http://conventions.coe.int/Treaty/en/Treaties/html/185.htm. US is 
 a signatory. Article 21 is Lawful Intercept as specified in OCCSSS, FISA, 
 CALEA, and PATRIOT. Article 20 essentially looks for retention of 
 mail/web/etc logs, and in the Danish interpretation, maintaining Netflow 
 records for every subscriber in Denmark along with a mapping between IP 
 address and subscriber identity in a form that can be data mined with an 
 appropriate warrant.

I can't say (I don't know) whether the Danish Police have in fact implemented 
what they proposed in 2003. What they were looking for at the time was that the 
netflow records would be kept for something on the order of 6-18 months. 

From a US perspective, you might peruse

http://en.wikipedia.org/wiki/Telecommunications_data_retention#United_States

The Wikipedia article goes on to comment on the forensic value of data 
retention. I think it is fair to say that the use of telephone numbers in TV 
shows like CSI (gee, he called X a lot, maybe we should too) is the comic 
book version of the use but not far from the mark. A law enforcement official 
once described it to me as mapping criminal networks; if Alice and Bob are 
known criminals that talk with each other, and both also talk regularly with 
Carol, Carol may simply be a mutual friend, but she might also be something 
else. Further, if Alice and Bob are known criminals in one organization, Dick 
and Jane are known criminals in another, and a change in communication patterns 
is observed - Alice and Bob don't talk with Dick or Jane for a long period, and 
then they start talking - it may signal a shift that law enforcement is 
interested in.

Re: Sad IPv4 story?

[Fred Baker]

On Dec 9, 2011, at 10:37 AM, Franck Martin wrote:

 I just had a personal email from a brand new ISP in the Asia-Pacific area 
 desperately looking for enough IPv4 to be able to run their business the way 
 they would like…
 
 This is just a data point.

We're going to be hearing a lot more of these. It's the nature of finite 
resources, and of human nature when faced with them. At some point, this will 
find its way into courtrooms under the rubric of a barrier to entry. It already 
has in terms of antitrust when a company wanted to move its PA prefix to 
different upstream.

Re: Traceroute explanation

[Fred Baker]

This is just a guess, but I'll bet the route changed while you were measuring 
it.

Traceroute sends a request, awaits a response, sends a request, ... Suppose 
that the route was

172.28.0.1 - 10.16.0.2
   - 41.200.16.1
   - 172.17.2.25
   - 213.140.58.10
   - 195.22.195.125
   - 4.69.151.13
   - 213.200.68.61
   - somewhere else

and after the test got that far, two systems got inserted into the path before 
level3, resulting in the route entering level3 at a different point, 
4.69.141.249. What you now have is

172.28.0.1 - 10.16.0.2
   - 41.200.16.1
   - 172.17.2.25
   - 213.140.58.10
   - 195.22.195.125
   - unknown
   - unknown
   - 4.69.141.249
   - 77.67.66.154
   - and so on

The effect would be to get a result like this.

Next time you see something like this, suggestion: repeat the traceroute and 
see what you get.


On Dec 7, 2011, at 12:12 PM, Meftah Tayeb wrote:

 Hey folks,
 i see a strange traceroute there
 
 Détermination de l'itinéraire vers www.rri.ro [193.231.72.52]
 avec un maximum de 30 sauts :
 
  1 2 ms 1 ms 1 ms  172.28.0.1
  2 1 ms 1 ms 1 ms  localhost [10.16.0.2]
  310 ms10 ms13 ms  41.200.16.1
  411 ms10 ms11 ms  172.17.2.25
  521 ms21 ms21 ms  213.140.58.10
  634 ms31 ms55 ms  pos14-0.palermo9.pal.seabone.net 
 [195.22.197.125
 ]
  734 ms33 ms35 ms  ae-5-6.bar2.marseille1.level3.net [4.69.151.13]
  8   106 ms68 ms67 ms  xe-1-1-0.mil10.ip4.tinet.net [213.200.68.61]
  974 ms73 ms74 ms  ae-1-12.bar1.budapest1.level3.net 
 [4.69.141.249]
 1063 ms63 ms79 ms  euroweb-gw.ip4.tinet.net [77.67.66.154]
 1185 ms84 ms84 ms  v15-core1.stsisp.ro [193.151.28.1]
 12   100 ms   100 ms   102 ms  inet-crli1.qrli1.buh.ew.ro [81.24.28.226]
 1381 ms81 ms81 ms  193.231.72.10
 1492 ms92 ms93 ms  ip4-89-238-225-90.euroweb.ro [89.238.225.90]
 1589 ms89 ms89 ms  webrri.rri.ro.72.231.193.in-addr.arpa 
 [193.231.7
 2.52]
 Itinéraire déterminé.
 C:\Documents and Settings\TAYEB
 Seabone, then level3, then Tinet, then level3, then tinet ?
 if is that a routing stufs that i don't know, please let me know :)
 i never saw that befaure
 
Meftah Tayeb
 IT Consulting
 http://www.tmvoip.com/ 
 phone: +21321656139
 Mobile: +213660347746
 
 
 __ Information from ESET NOD32 Antivirus, version of virus signature 
 database 6695 (20111208) __
 
 The message was checked by ESET NOD32 Antivirus.
 
 http://www.eset.com