Re: PlayStationNetwork blocking of CGNAT public addresses

[Masataka Ohta]

Simon Lockhart wrote:


Has anyone else come up against the problem, and/or have any suggestions on
how best to resolve it?


The best solution is to have a common practice on a set of public
port numbers assigned to a host behind NAT.

For example, with a practice that, if a port in a range between N*8
and N*8+7 is assigned to a host, other ports in the range is not
assigned to other hosts, service providers can block packets
based on IP addresses and ranges, especially if correspondence between
hosts and ranges are rather stable.

But, it may be too late to make such practice common, I'm afraid.

Or, wait for a while until service providers receive enough amount
of feedback from innocent users. To accelerate it, you can make  
correspondence between hosts and public addresses not so stable,

which makes almost all your IP addresses marked bad quickly,
which may make you loss some customer, unless other ISPs also do so.

Masataka Ohta

RE: Anyone with a clue at Zayo?

[Justin Krejci]

Might help if you indicate type of service as they have lots of services 
covered by different groups: IP transit, wave, dark fiber, voip, Colo, etc. 
Their Enterprise division does yet other services.

Might also help if you provide at least a general location/region.



-Original Message-
From: Patrick Sumby [patrick.su...@sohonet.com]
Received: Friday, 16 Sep 2016, 7:22PM
To: nanog@nanog.org [nanog@nanog.org]
Subject: Anyone with a clue at Zayo?

Have a turnup we've been working on all day and no luck so far. Now
we're being told that nobody can help outside hours :(

Any help much appreciated.

Thanks
Pat

RE: PlayStationNetwork blocking of CGNAT public addresses

[michalis.bersimis]

Another aspect, for those users that need to go the PSN network but experience 
issues via the CGNAT, an opt-out solution (giving them public IPv4) may should 
mitigate the problem, that PSN network does not support IPv6.

After all what percentage of your total subscribers that uses PSN and are 
gamers 2-3%  ?  Which might be relatively small amount to give public IPv4.

Michalis

-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Roland Dobbins
Sent: Friday, September 16, 2016 4:32 PM
To: nanog@nanog.org
Subject: Re: PlayStationNetwork blocking of CGNAT public addresses


On 16 Sep 2016, at 20:12, Simon Lockhart wrote:

> Has anyone else come up against the problem, and/or have any 
> suggestions on how best to resolve it?

I'm pretty sure that at least part of it has to do with DDoS-related activity.  
The best bet is to try and identify and engage with the relevant operational 
personnel with clue.  Going the customer-service route isn't fruitful, as you 
indicate.

Another aspect is ensuring that one has the ability to detect, classify, 
traceback, and mitigate outbound badness southbound of the CGN.

This sort of thing has always been a problem with NAT; as CGN becomes more 
prevalent on wireline broadband networks, it's only going to get worse.

AFAIK, PSN doesn't support IPv6.  That would be another topic of discussion 
with the operational folks.

---
Roland Dobbins 

Anyone with a clue at Zayo?

[Patrick Sumby]

Have a turnup we've been working on all day and no luck so far. Now 
we're being told that nobody can help outside hours :(


Any help much appreciated.

Thanks
Pat

RE: PlayStationNetwork blocking of CGNAT public addresses

[Tony Wicks]

So the pain has finally flowed down to other parts of the world. (APNIC ran
out of IP's a long time ago, so CGN has been in use here for a lot longer)
This issue is one I have been dealing with for the last four years. Only
with Sony, no other company has caused such a headache in regard to CGNAT. I
will not go into the long and painful saga of dealing with the constant
issue of Sony putting blocks on random pool addresses, refusing to supply
sufficient information to identify rouge users (timestamp, source IP,
destination IP and port) then telling our customers it is a problem at the
ISP end, but... Something happened about three months ago that Proves that
if the Sony technical people want to get off their asses they are perfectly
capable of supplying adequate information to identify a rogue user for the
ISP to deal with. One of the local Sony PSN helpline managers actually
managed to convince one of their technical people to supply a spreadsheet
that magically contained sufficient information to allow us to identify a
couple of users that did indeed have multiple infections.  Great I thought,
now if we can just get them to automate/regularly sent this info we will
have a way forward. Alas, it appears it was a one off and we are back to the
start. I will quote below what the Sony Network guy said when explaining why
they can't send detailed information every time -


" From: SNEI-NOC-Abuse [mailto:snei-noc-ab...@am.sony.com] 
Sent: Thursday, 11 August 2016 8:38 AM
To: ##me##
Cc: ##helpful Sony guy## Subject: RE: PSN / Flip Network blocks

Hello,

There is quite a bit of extra computing power required to produce the CSV
file with timestamps and destination IP addresses.  We send out over 6000
emails per day which already takes a significant amount of resources and
time.  We tend to get around 20-30 responses.  Instead of wasting the
resources on all those emails we generate CSV files for those who respond.

We hope you understand.

Thank you for taking action on these."

So there you go, Sony can indeed solve this issue, but apparently a company
that makes computers has insufficient computing power and staff to do so. Oh
and after this, despite being asked many times they have never responded to
requests for the CSV or similar detailed info.




-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Simon Lockhart
Sent: Saturday, 17 September 2016 1:13 AM
To: nanog@nanog.org
Subject: PlayStationNetwork blocking of CGNAT public addresses

All,

We operate an access network with several hundred thousand users.
Increasingly we're putting the users behind CGNAT in order to continue to
give them an IPv4 service (we're all dual-stack, so they all get public IPv6
too). Due to the demographic of our users, many of them are gamers.

We're hitting a problem with PlayStationNetwork 'randomly' blocking some of
our CGNAT outside addresses, because they claim to have received anomalous,
or 'attack' traffic from that IP. This obviously causes problems for the
other legitimate users who end up behind the same public IPv4 address.

Despite numerous attempts to engage with PSN, they are unwilling to give us
any additional information which would allow us to identify the 'rogue'
users on our network, or to identify the 'unwanted' traffic so that we could
either block it, or use it to identify the rogue users ourselves.

Has anyone else come up against the problem, and/or have any suggestions on
how best to resolve it?

Many thanks in advance,

Simon

Weekly Routing Table Report

[Routing Analysis Role Account]

This is an automated weekly mailing describing the state of the Internet
Routing Table as seen from APNIC's router in Japan.

The posting is sent to APOPS, NANOG, AfNOG, AusNOG, SANOG, PacNOG,
SAFNOG, SdNOG, BJNOG, CaribNOG and the RIPE Routing WG.

Daily listings are sent to bgp-st...@lists.apnic.net

For historical data, please see http://thyme.rand.apnic.net.

If you have any comments please contact Philip Smith .

Routing Table Report   04:00 +10GMT Sat 17 Sep, 2016

Report Website: http://thyme.rand.apnic.net
Detailed Analysis:  http://thyme.rand.apnic.net/current/

Analysis Summary


BGP routing table entries examined:  609829
Prefixes after maximum aggregation (per Origin AS):  220069
Deaggregation factor:  2.77
Unique aggregates announced (without unneeded subnets):  297950
Total ASes present in the Internet Routing Table: 54857
Prefixes per ASN: 11.12
Origin-only ASes present in the Internet Routing Table:   36396
Origin ASes announcing only one prefix:   15402
Transit ASes present in the Internet Routing Table:6516
Transit-only ASes present in the Internet Routing Table:168
Average AS path length visible in the Internet Routing Table:   4.3
Max AS path length visible:  54
Max AS path prepend of ASN ( 55644)  51
Prefixes from unregistered ASNs in the Routing Table:60
Unregistered ASNs in the Routing Table:  15
Number of 32-bit ASNs allocated by the RIRs:  15444
Number of 32-bit ASNs visible in the Routing Table:   11945
Prefixes from 32-bit ASNs in the Routing Table:   47636
Number of bogon 32-bit ASNs visible in the Routing Table:84
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:347
Number of addresses announced to Internet:   2826656228
Equivalent to 168 /8s, 123 /16s and 89 /24s
Percentage of available address space announced:   76.3
Percentage of allocated address space announced:   76.3
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   98.3
Total number of prefixes smaller than registry allocations:  197571

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   156454
Total APNIC prefixes after maximum aggregation:   42942
APNIC Deaggregation factor:3.64
Prefixes being announced from the APNIC address blocks:  169988
Unique aggregates announced from the APNIC address blocks:68960
APNIC Region origin ASes present in the Internet Routing Table:5194
APNIC Prefixes per ASN:   32.73
APNIC Region origin ASes announcing only one prefix:   1156
APNIC Region transit ASes present in the Internet Routing Table:946
Average APNIC Region AS path length visible:4.4
Max APNIC Region AS path length visible: 54
Number of APNIC region 32-bit ASNs visible in the Routing Table:   2380
Number of APNIC addresses announced to Internet:  759640004
Equivalent to 45 /8s, 71 /16s and 47 /24s
APNIC AS Blocks4608-4864, 7467-7722, 9216-10239, 17408-18431
(pre-ERX allocations)  23552-24575, 37888-38911, 45056-46079, 55296-56319,
   58368-59391, 63488-64098, 64297-64395, 131072-137529
APNIC Address Blocks 1/8,  14/8,  27/8,  36/8,  39/8,  42/8,  43/8,
49/8,  58/8,  59/8,  60/8,  61/8, 101/8, 103/8,
   106/8, 110/8, 111/8, 112/8, 113/8, 114/8, 115/8,
   116/8, 117/8, 118/8, 119/8, 120/8, 121/8, 122/8,
   123/8, 124/8, 125/8, 126/8, 133/8, 150/8, 153/8,
   163/8, 171/8, 175/8, 180/8, 182/8, 183/8, 202/8,
   203/8, 210/8, 211/8, 218/8, 219/8, 220/8, 221/8,
   222/8, 223/8,

ARIN Region Analysis Summary


Prefixes being announced by ARIN Region ASes:183986
Total ARIN prefixes after maximum aggregation:89627
ARIN Deaggregation factor: 2.05
Prefixes being announced from the ARIN address blocks:   189745
Unique aggregates announced from the ARIN address blocks: 88444
ARIN Region origin ASes present in the Internet Routing Table:16204
ARIN Prefixes per ASN:11.71

Re: "Defensive" BGP hijacking?

[Mel Beckman]

Doug,

Although RPKI is voluntary and decisions are local, those decisions are also 
automated. DNS is voluntary, and decisions are local as well, yet the 
government has been able to leverage DNS to unilaterally seize domain names 
without due process. Like Maxwell's Demons, it's theoretically possible for 
ISPs everywhere to notice government malfeasance and rush to a unified decision 
to counter it. But in practice this never happens.

Preventing government manhandling needs to be a design goal.

 -mel beckman

On Sep 16, 2016, at 8:32 AM, Doug Montgomery 
> wrote:

Ah, the global system I was referring to was the RPKI as distributed repository 
of routing information.  With consistent properties (data formats, security 
models, data validation techniques, etc) across all 5 RIRs.

What an ISP does with the RPKI data, interns of route filtering, is always a 
local policy decision.Somehow "global enforcement system" sounded like a 
vision where ISPs don't have a choice of how and where to use the system.  
Maybe I read too much into the phrasing.

In the end, I think the issues boils down to if the community has the desire 
and will to address the route hijack issue.If the answer is no, then no 
further discussion is needed.  If the answer is yes, then it is best to discuss 
and compare real proposals / mechanisms to address the issue at scale.

I am still interested in some detail on the "tyranny implications".  We can't 
address them until we know what they are and how they compare to any other 
solution that tries to address the same problem.

dougm

On Wed, Sep 14, 2016 at 6:04 PM, Mel Beckman 
> wrote:
Doug,

I was basing my comments on your statement "If only there were a global 
system.."  However you slice or dice it, the tyranny implications have not yet 
been addressed. That certainly needs to be in front of any technical idea such 
as RPKI.

Although I haven't participated in the OT, nothing I've read in RFC 6810 
talks about these issues. It talks about authentication and transport security, 
but doesn't talk about the potential for government interference.

 -mel beckman

On Sep 14, 2016, at 8:22 AM, Doug Montgomery 
> wrote:

Mel,

If you are speaking of RPKI based origin validation, I am not sure "automated / 
global enforcement system" is a useful description.   It does provide a 
consistent means for address holders to declare AS's authorized to announce 
prefixes, and a means for remote ASs to compare received updates vs such 
declarations.   What the receiving AS does with the validation information is 
strictly a local policy matter.

Frankly, this is no more a "new automated enforcement system" than IRR-based 
route filtering has been for 20 years.  The only difference is that there is a 
consistent security model across all 5 RIRs as to who can make such 
declarations and it is tightly tied to the address allocation business process.

I have seen a lot of FUD about the specter of interference, but not a lot of 
serious thought / discussion.  Having a serious technical discussion of 
potential risks and mitigations in the system would be useful.

dougm

On Wed, Sep 14, 2016 at 10:51 AM, Mel Beckman 
> wrote:
Scott and Doug,

The problem with a new automated enforcement system is that it hobbles both 
agility and innovation. ISPs have enjoyed simple BGP management, entirely 
self-regulated, for decades. A global enforcement system, besides being dang 
hard to do correctly, brings the specter of government interference, since such 
a system could be overtaken by government entities to manhandle free speech.

In my opinion, the community hasn't spent nearly enough time discussing the 
danger aspect. Being engineers, we focus on technical means, ignoring the fact 
that we're designing our own guillotine.

 -mel beckman

> On Sep 14, 2016, at 12:10 AM, Scott Weeks 
> > wrote:
>
>
>
> --- dougm.w...@gmail.com wrote:
> From: Doug Montgomery >
>
> If only there were a global system, with consistent and verifiable security
> properties, to permit address holders to declare the set of AS's authorized
> to announce their prefixes, and routers anywhere on the Internet to
> independently verify the corresponding validity of received announcements.
>
> *cough  https://www.nanog.org/meetings/abstract?id=2846 cough*
> 
>
>
> Yes, RPKI.  That's what I was waiting for.  Now we can get to
> a real discussion... ;-)
>
> scott



--
DougM at Work



--
DougM at Work

Re: PlayStationNetwork blocking of CGNAT public addresses

[Ca By]

On Friday, September 16, 2016, Simon Lockhart  wrote:

> All,
>
> We operate an access network with several hundred thousand users.
> Increasingly
> we're putting the users behind CGNAT in order to continue to give them an
> IPv4
> service (we're all dual-stack, so they all get public IPv6 too). Due to the
> demographic of our users, many of them are gamers.
>
> We're hitting a problem with PlayStationNetwork 'randomly' blocking some
> of our
> CGNAT outside addresses, because they claim to have received anomalous, or
> 'attack' traffic from that IP. This obviously causes problems for the other
> legitimate users who end up behind the same public IPv4 address.
>
> Despite numerous attempts to engage with PSN, they are unwilling to give us
> any additional information which would allow us to identify the 'rogue'
> users
> on our network, or to identify the 'unwanted' traffic so that we could
> either
> block it, or use it to identify the rogue users ourselves.
>
> Has anyone else come up against the problem, and/or have any suggestions on
> how best to resolve it?
>
> Many thanks in advance,
>
> Simon


Here is a picture of what you are experiencing

http://test-ipv6.com/faq_avoids_ipv6.html

Sometimes people need pictures to understand why IPv6 is important

Re: "Defensive" BGP hijacking?

[Doug Montgomery]

Ah, the global system I was referring to was the RPKI as distributed
repository of routing information.  With consistent properties (data
formats, security models, data validation techniques, etc) across all 5
RIRs.

What an ISP does with the RPKI data, interns of route filtering, is always
a local policy decision.Somehow "global enforcement system" sounded
like a vision where ISPs don't have a choice of how and where to use the
system.  Maybe I read too much into the phrasing.

In the end, I think the issues boils down to if the community has the
desire and will to address the route hijack issue.If the answer is no,
then no further discussion is needed.  If the answer is yes, then it is
best to discuss and compare real proposals / mechanisms to address the
issue at scale.

I am still interested in some detail on the "tyranny implications".  We
can't address them until we know what they are and how they compare to any
other solution that tries to address the same problem.

dougm

On Wed, Sep 14, 2016 at 6:04 PM, Mel Beckman  wrote:

> Doug,
>
> I was basing my comments on your statement "If only there were a global
> system.."  However you slice or dice it, the tyranny implications have not
> yet been addressed. That certainly needs to be in front of any technical
> idea such as RPKI.
>
> Although I haven't participated in the OT, nothing I've read in RFC 6810
> talks about these issues. It talks about authentication and transport
> security, but doesn't talk about the potential for government interference.
>
>  -mel beckman
>
> On Sep 14, 2016, at 8:22 AM, Doug Montgomery  wrote:
>
> Mel,
>
> If you are speaking of RPKI based origin validation, I am not sure
> "automated / global enforcement system" is a useful description.   It does
> provide a consistent means for address holders to declare AS's authorized
> to announce prefixes, and a means for remote ASs to compare received
> updates vs such declarations.   What the receiving AS does with the
> validation information is strictly a local policy matter.
>
> Frankly, this is no more a "new automated enforcement system" than
> IRR-based route filtering has been for 20 years.  The only difference is
> that there is a consistent security model across all 5 RIRs as to who can
> make such declarations and it is tightly tied to the address allocation
> business process.
>
> I have seen a lot of FUD about the specter of interference, but not a lot
> of serious thought / discussion.  Having a serious technical discussion of
> potential risks and mitigations in the system would be useful.
>
> dougm
>
> On Wed, Sep 14, 2016 at 10:51 AM, Mel Beckman  wrote:
>
>> Scott and Doug,
>>
>> The problem with a new automated enforcement system is that it hobbles
>> both agility and innovation. ISPs have enjoyed simple BGP management,
>> entirely self-regulated, for decades. A global enforcement system, besides
>> being dang hard to do correctly, brings the specter of government
>> interference, since such a system could be overtaken by government entities
>> to manhandle free speech.
>>
>> In my opinion, the community hasn't spent nearly enough time discussing
>> the danger aspect. Being engineers, we focus on technical means, ignoring
>> the fact that we're designing our own guillotine.
>>
>>  -mel beckman
>>
>> > On Sep 14, 2016, at 12:10 AM, Scott Weeks 
>> wrote:
>> >
>> >
>> >
>> > --- dougm.w...@gmail.com wrote:
>> > From: Doug Montgomery 
>> >
>> > If only there were a global system, with consistent and verifiable
>> security
>> > properties, to permit address holders to declare the set of AS's
>> authorized
>> > to announce their prefixes, and routers anywhere on the Internet to
>> > independently verify the corresponding validity of received
>> announcements.
>> >
>> > *cough  https://www.nanog.org/meetings/abstract?id=2846 cough*
>> > 
>> >
>> >
>> > Yes, RPKI.  That's what I was waiting for.  Now we can get to
>> > a real discussion... ;-)
>> >
>> > scott
>>
>
>
>
> --
> DougM at Work
>
>


-- 
DougM at Work

Re: PlayStationNetwork blocking of CGNAT public addresses

[A . L . M . Buxey]

Hi,

as others have said, need to engage with one of their other units to get this 
sorted
out - as a network provider, their customers are relying on YOU to access their 
service, PSN should
care. 

technically, you could start looking at netflows to the PSN and see if anyone 
is engaged in DDoS
via that route...and , if you offer IPv6 native service to end users, ask PSN 
when they are going to 
be offer an IPv6 service to their users - so this CGNAT stuff can go  ;-)

alan

Re: PlayStationNetwork blocking of CGNAT public addresses

[Roland Dobbins]

On 16 Sep 2016, at 20:38, Simon Lockhart wrote:


 Unless we know what to look for, it's hard to detect and stop it.


It's not just application-layer stuff - they're subject to all sorts of 
attacks.  Screening out the obvious stuff would certainly help.


The main issue is a dearth of engagement of clueful folks in the global 
operational community.  Some gaming-oriented networks are 
well-represented; others are not, sadly.


---
Roland Dobbins 

Re: PlayStationNetwork blocking of CGNAT public addresses

[Simon Lockhart]

On Fri Sep 16, 2016 at 08:32:12PM +0700, Roland Dobbins wrote:
> Another aspect is ensuring that one has the ability to detect, classify,
> traceback, and mitigate outbound badness southbound of the CGN.

Unless PSN can tell us what traffic they consider bad, how can we detect and
classify it? We certainly have the ability to traceback and mitigate, once we
know what we're looking for.

My understanding of the issue is that there are infected PCs on our network,
which are being used as part of a distributed attack, but at the application
layer, rather than network layer - distributed password brute-force, or 
similar. Unless we know what to look for, it's hard to detect and stop it.
 
Simon

Re: PlayStationNetwork blocking of CGNAT public addresses

[Roland Dobbins]

On 16 Sep 2016, at 20:12, Simon Lockhart wrote:

Has anyone else come up against the problem, and/or have any 
suggestions on how best to resolve it?


I'm pretty sure that at least part of it has to do with DDoS-related 
activity.  The best bet is to try and identify and engage with the 
relevant operational personnel with clue.  Going the customer-service 
route isn't fruitful, as you indicate.


Another aspect is ensuring that one has the ability to detect, classify, 
traceback, and mitigate outbound badness southbound of the CGN.


This sort of thing has always been a problem with NAT; as CGN becomes 
more prevalent on wireline broadband networks, it's only going to get 
worse.


AFAIK, PSN doesn't support IPv6.  That would be another topic of 
discussion with the operational folks.


---
Roland Dobbins 

Re: PlayStationNetwork blocking of CGNAT public addresses

[Mike Hammett]

A network that doesn't support IPv6, yet discriminates against CGNAT? That 
seems like a promising future. 




- 
Mike Hammett 
Intelligent Computing Solutions 

Midwest Internet Exchange 

The Brothers WISP 

- Original Message -

From: "Simon Lockhart"  
To: nanog@nanog.org 
Sent: Friday, September 16, 2016 8:12:46 AM 
Subject: PlayStationNetwork blocking of CGNAT public addresses 

All, 

We operate an access network with several hundred thousand users. Increasingly 
we're putting the users behind CGNAT in order to continue to give them an IPv4 
service (we're all dual-stack, so they all get public IPv6 too). Due to the 
demographic of our users, many of them are gamers. 

We're hitting a problem with PlayStationNetwork 'randomly' blocking some of our 
CGNAT outside addresses, because they claim to have received anomalous, or 
'attack' traffic from that IP. This obviously causes problems for the other 
legitimate users who end up behind the same public IPv4 address. 

Despite numerous attempts to engage with PSN, they are unwilling to give us 
any additional information which would allow us to identify the 'rogue' users 
on our network, or to identify the 'unwanted' traffic so that we could either 
block it, or use it to identify the rogue users ourselves. 

Has anyone else come up against the problem, and/or have any suggestions on 
how best to resolve it? 

Many thanks in advance, 

Simon 

PlayStationNetwork blocking of CGNAT public addresses

[Simon Lockhart]

All,

We operate an access network with several hundred thousand users. Increasingly
we're putting the users behind CGNAT in order to continue to give them an IPv4
service (we're all dual-stack, so they all get public IPv6 too). Due to the
demographic of our users, many of them are gamers.

We're hitting a problem with PlayStationNetwork 'randomly' blocking some of our
CGNAT outside addresses, because they claim to have received anomalous, or 
'attack' traffic from that IP. This obviously causes problems for the other
legitimate users who end up behind the same public IPv4 address.

Despite numerous attempts to engage with PSN, they are unwilling to give us
any additional information which would allow us to identify the 'rogue' users
on our network, or to identify the 'unwanted' traffic so that we could either
block it, or use it to identify the rogue users ourselves.

Has anyone else come up against the problem, and/or have any suggestions on 
how best to resolve it?

Many thanks in advance,

Simon

Re: QWEST.NET can you fix your nameservers

[Tony Finch]

Mark Andrews  wrote:
>
> My bet is the DNS vendor has issued a update already and that it
> hasn't been applied.

$ fpdns sauthns1.qwest.net.
fingerprint (sauthns1.qwest.net., 63.150.72.5): NLnetLabs NSD 3.1.0 -- 3.2.8 
[New Rules]
fingerprint (sauthns1.qwest.net., 2001:428:0:0:0:0:0:7): NLnetLabs NSD 3.1.0 -- 
3.2.8 [New Rules]
$ dig +nocookie +noall +answer version.bind ch txt @sauthns1.qwest.net.
version.bind.   0   CH  TXT "3.2.2"

https://www.nlnetlabs.nl/projects/nsd/
NSD 3.2.2 - May 18, 2009

Tony.
-- 
f.anthony.n.finch    http://dotat.at/  -  I xn--zr8h punycode
Humber, Thames, Dover, Wight: Cyclonic at first, but mainly northerly 5 to 7,
decreasing 4 at times later. Slight or moderate. Occasional rain, perhaps
thundery at first, fog patches at first in Humber. Moderate or poor,
occasionally very poor in Humber.