Re: IPv6 doc. prefix (2001:db8::/32) - APNIC object ?

[Mark Andrews]

In message <6bcda810-52cd-4efe-9a69-4b1aabc90...@burn.net>, Brandon Applegate 
writes:
> Just did a whois on the documentation prefix and was surprised to see
> what looks like a user object registered for it:
>
> % Information related to '2001:0DB8::/32AS132111'
>
> route6: 2001:0DB8::/32
> descr:  FUTURE D SDN BHD
> origin: AS132111
> country:MY
> mnt-by: MAINT-FUTUREDSDNBHD-MY
> changed:hm-chan...@apnic.net 20160523
> source: APNIC
>
> Any idea what this is ?  I would have thought there might be some sanity
> check that would have stopped this from getting registered ?

Open a ticket with APNIC to get it fixed.

> --
> Brandon Applegate - CCIE 10273
> PGP Key fingerprint:
> 830B 4802 1DD4 F4F9 63FE  B966 C0A7 189E 9EC0 3A74
> "SH1-0151.  This is the serial number, of our orbital gun."

-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[William Herrin]

On Mon, Mar 6, 2017 at 9:13 PM, Brielle Bruns  wrote:
> Lets not even get into the fact that we still can't fully utilize things
> like already established standards such as ECN, EDNS, and PMTUD effectively
> because firewall and security vendors still can't extricate their heads from
> backside and handle basic functionality of IPv4 without throwing the packets
> on the floor.

PMTUD is broken as designed, the one thing about TCP which directly
violates the end-to-end principle.

-Bill

-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Brielle Bruns]

On 3/6/17 10:16 AM, valdis.kletni...@vt.edu wrote:

On Mon, 06 Mar 2017 03:08:35 -0500, Joly MacFie said:


routing hardware layer that will be hit & miss. Nevertheless, since much of
the world is still IPv4 dependent, it just could take off.


For it to "take off", the very same people who have dragged their heels
deploying IPv6 will need to suddenly jump up and upgrade all their gear
and personnel to support a *third* protocol.

Oh, and you're going to need support buy-in from *at least* Microsoft, Apple,
Linux, Cisco, Juniper, and a significant chunk of major makers of CPE gear.

What's the business case for all these stakeholders to buy into EZIP?  For
both the "We already do IPv6" and "We don't do IP6v" cases?




Lets not even get into the fact that we still can't fully utilize things 
like already established standards such as ECN, EDNS, and PMTUD 
effectively because firewall and security vendors still can't extricate 
their heads from backside and handle basic functionality of IPv4 without 
throwing the packets on the floor.


If the average 'security' device these days chokes and drops a packet 
due to not recognizing the ECN option, what makes anyone think shoving 
more special stuff in the headers just for IoT crap is a good idea?


Wouldn't it just be easier to use IPv6 tunneled over Teredo?

Oh wait, that would require the IoT vendors to actually build decent 
products with software that works.



--
Brielle Bruns
The Summit Open Source Development Group
http://www.sosdg.org/ http://www.ahbl.org

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Mark Andrews]

In message <59f04cec29296d59f589ee671c65edc8.squirrel@66.201.44.180>, "Bob 
Evans" writes:
> I have had ipv4 transit with ATT for years (one provider of many)and
> the order originally placed was for both ipv4 and 6yep still waiting.
> 
> Thank You
> Bob Evans
> CTO

Cancel your service and say it is because they failed to deliver
IPv6.  If they try to fight you for breaking the contract they don't
have a leg to stand on because they have failed to deliver on their
part of the contract.

I more people did this you would see IPv6 move up the priority stack.

Mark

> > On 3/6/17 14:04, Dennis Burgess wrote:
> >> Well try to get ATT to announce IPv6 though our AS!  Lol Been on the
> >> phone with the for over a month.  Still no ETA :(
> >
> >
> > Requests driven from the sales side should have the best results.
> >
> > Before Charter's sales turned into a hole of poor service, I had a
> > account manager that actually cared about the whole picture. I told him
> > the reason nobody before him was able to sell to us is because we have
> > requirements that need to be deliverable (no native IPv6 no sale), can't
> > deal in promises. Of course he's no longer there and I'm back to idiots
> > that just want to see how high of a price they can get you to sign for,
> > especially if you're already a customer there's no need to pretend to
> > care further.
> >
> > ~Seth
> >
> 
> 
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Bob Evans]

I have had ipv4 transit with ATT for years (one provider of many)and
the order originally placed was for both ipv4 and 6yep still waiting.

Thank You
Bob Evans
CTO




> On 3/6/17 14:04, Dennis Burgess wrote:
>> Well try to get ATT to announce IPv6 though our AS!  Lol Been on the
>> phone with the for over a month.  Still no ETA :(
>
>
> Requests driven from the sales side should have the best results.
>
> Before Charter's sales turned into a hole of poor service, I had a
> account manager that actually cared about the whole picture. I told him
> the reason nobody before him was able to sell to us is because we have
> requirements that need to be deliverable (no native IPv6 no sale), can't
> deal in promises. Of course he's no longer there and I'm back to idiots
> that just want to see how high of a price they can get you to sign for,
> especially if you're already a customer there's no need to pretend to
> care further.
>
> ~Seth
>

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Carsten Bormann]

On 6 Mar 2017, at 22:00, Baldur Norddahl  wrote:
> 
> Encode extra address bits in extension headers. Add a network element near 
> the destination that converts such that the destination IP of a packet to IP 
> a.b.c.d with extension header containing e.f is translated to 192.168.e.f. In 
> the reverse direction translate source address 192.168.e.f to a.b.c.d and add 
> option header with e.f.

6to4 essentially did this already.  The main problem with 6to4 that made us 
stop using it was communicating to non-6to4 (“native”) IPv6 addresses; if you 
don’t want that, you have running code for both router and host side and plenty 
of gear that already works.

(All this is still complete nonsense in the face of accelerating native IPv6 
adoption; I write this just to show that the idea already has been implemented 
out there.)

Grüße, Carsten

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Seth Mattinen]

On 3/6/17 14:04, Dennis Burgess wrote:

Well try to get ATT to announce IPv6 though our AS!  Lol Been on the phone with 
the for over a month.  Still no ETA :(



Requests driven from the sales side should have the best results.

Before Charter's sales turned into a hole of poor service, I had a 
account manager that actually cared about the whole picture. I told him 
the reason nobody before him was able to sell to us is because we have 
requirements that need to be deliverable (no native IPv6 no sale), can't 
deal in promises. Of course he's no longer there and I'm back to idiots 
that just want to see how high of a price they can get you to sign for, 
especially if you're already a customer there's no need to pretend to 
care further.


~Seth

RE: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Dennis Burgess]

Well try to get ATT to announce IPv6 though our AS!  Lol Been on the phone with 
the for over a month.  Still no ETA :(  


Dennis Burgess - Network Solution Engineer - Consultant 
MikroTik Certified Trainer/Consultant - MTCNA, MTCRE, MTCWE, MTCTCE, MTCINE

For Wireless Hardware/Routers visit www.linktechs.net
Radio Frequiency Coverages: www.towercoverage.com 
Office: 314-735-0270
E-Mail: dmburg...@linktechs.net 


-Original Message-
From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Bob Evans
Sent: Monday, March 6, 2017 3:34 PM
To: William Herrin 
Cc: nanog@nanog.org
Subject: Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

I think only 22% of networks with an AS announce IPv6 space.  Is that correct ?

Thank You
Bob Evans
CTO




> On Mon, Mar 6, 2017 at 4:00 PM, Baldur Norddahl 
>  wrote:
>> Major ISPs have IPv6 support now. It is the sites (=servers) that are 
>> lacking.
>
> Hi Baldur,
>
> Not exactly. My Verizon FiOS does not support IPv6. Neither does my 
> Cox Cable Internet. My Verizon Wireless service supports IPv6 but my 
> AT Wireless service does not.
>
> All four of these entities have IPv6 somewhere in their networks but 
> that's not at all the same thing as saying they "have IPv6 support."
>
> IPv6 deployment has gathered some momentum, enough that it's unlikely 
> to sputter out, but it's still laughably weak.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us 
> Dirtside Systems . Web: 
>

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Bob Evans]

I think only 22% of networks with an AS announce IPv6 space.  Is that
correct ?

Thank You
Bob Evans
CTO




> On Mon, Mar 6, 2017 at 4:00 PM, Baldur Norddahl
>  wrote:
>> Major ISPs have IPv6 support now. It is
>> the sites (=servers) that are lacking.
>
> Hi Baldur,
>
> Not exactly. My Verizon FiOS does not support IPv6. Neither does my
> Cox Cable Internet. My Verizon Wireless service supports IPv6 but my
> AT Wireless service does not.
>
> All four of these entities have IPv6 somewhere in their networks but
> that's not at all the same thing as saying they "have IPv6 support."
>
> IPv6 deployment has gathered some momentum, enough that it's unlikely
> to sputter out, but it's still laughably weak.
>
> Regards,
> Bill Herrin
>
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 
>

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[William Herrin]

On Mon, Mar 6, 2017 at 4:00 PM, Baldur Norddahl
 wrote:
> Major ISPs have IPv6 support now. It is
> the sites (=servers) that are lacking.

Hi Baldur,

Not exactly. My Verizon FiOS does not support IPv6. Neither does my
Cox Cable Internet. My Verizon Wireless service supports IPv6 but my
AT Wireless service does not.

All four of these entities have IPv6 somewhere in their networks but
that's not at all the same thing as saying they "have IPv6 support."

IPv6 deployment has gathered some momentum, enough that it's unlikely
to sputter out, but it's still laughably weak.

Regards,
Bill Herrin



-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Baldur Norddahl]

That proposal is far too wordy. Here is the executive summary:

Encode extra address bits in extension headers. Add a network element 
near the destination that converts such that the destination IP of a 
packet to IP a.b.c.d with extension header containing e.f is translated 
to 192.168.e.f. In the reverse direction translate source address 
192.168.e.f to a.b.c.d and add option header with e.f.


Executive summary end.

As far as I can tell, the only advantage of this proposal over IPv6 is 
that the network core does not need to be changed. You could communicate 
with someone that had an EZIP address regardless that your ISP did 
nothing to support EZIP.


The disadvantage is that every single server out there would need to be 
changed so it does not just drop the option headers on the reply 
packets. All firewalls updated so they do not block packets with option 
headers. All applications updated so they understand a new address format.


Servers and applications could also confuse TCP or UDP streams that are 
apparently from the same source, same port numbers, only thing that 
differentiates the streams is some option header that the server does 
not understand.


The customers of the ISP that deploys EZIP would not need to update 
anything (unless they need to communicate with other poor souls that got 
assigned EZIP addresses), however everyone else would. This is not a 
good balance. The customers would experience an internet where almost 
nothing works. It would be magnitudes worse than the experience of an 
IPv6 only network with NAT64.


It is a fix for the wrong problem. Major ISPs have IPv6 support now. It 
is the sites (=servers) that are lacking. If Twitter did not deploy IPv6 
why would you expect them to deploy EZIP? Why would some old forgotten 
site with old song texts in some backwater country somewhere?


We already have better solutions such as CGN with dual stack, NAT64, 
DS-Lite, MAP etc.


None of that is discussed in the RFC. Is the author aware of it?

Regards,

Baldur




Den 06/03/2017 kl. 09.08 skrev Joly MacFie:

To say that Mr. Chen's EZIP proposal has not, thus far, been received with
open arms by the networking community would be an understatement. It is
seen as delaying the inevitable and introducing an impractical extra
routing hardware layer that will be hit & miss. Nevertheless, since much of
the world is still IPv4 dependent, it just could take off. ISOC-NY is happy
to give him the opportunity to expound on its merits.
​ We'd welcome some expert respondents.​

​See: ​
https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space-00


​==​

WEBINAR TUESDAY: Can We Make IPv4 Great Again? w/ @AbrahamYChen

On Tuesday March 8 2017 at noon EST the Internet Society New York Chapter
(ISOC-NY) presents a webinar Can We Make IPv4 Great Again?. Abraham Y.
Chen, VP of Engineering, Avinta Communications, will present his EzIP
proposal to reinvigorate the diminishing pool of IPv4 addresses.
​Optional registration
  at the link below. This will be recorded.

What: WEBINAR: Can We Make IPv4 Great Again?
When: Tuesday March 8 2017 Noon EST | 17:00 UTC
Register + info: https://www.meetup.com/isoc-ny/events/238164448/
Computer: https://zoom.us/j/914492141
Phone: http://bit.ly/zoomphone
​ ​
ID: 914 492 141
Twitter: #ezip

​​










Permalink

http://isoc-ny.org/p2/9031








--
---
Joly MacFie  218 565 9365 Skype:punkcast
--
-

RE: www.netflix.com / EC2 problem -- Persistent problems from Palo Alto to destinations to Netflix and other destinations with content on Amazon EC2 - 2000ms latency

[Peter Kranz]

First version got a little munged:

I'm not making progress with GTT's NOC on this issue, can someone clued in
at Netflix or Amazon comment on this problem. I believe it started after
Amazons outage last week.
 
This is an MTR to www.netflix.com   (52.5.161.36)
from 208.71.159.3  . this should be just a couple of ms away from Palo Alto:

   Packets
Pings
 HostLoss%   Snt
Last   Avg  Best  Wrst StDev
 1. 208.71.159.1130.0% 9
0.4   0.5   0.4   0.7   0.0
 2. 204.11.106.45 0.0% 9
2.1   2.1   2.0   2.2   0.0
 3. 173.205.47.1530.0% 9
36.4   5.8   1.9  36.4  11.5
 4. 89.149.184.1770.0% 9
37.8  38.1  37.6  40.5   0.6
 5. 173.205.39.1220.0% 9
37.9  37.8  37.6  38.3   0.0
 6. 176.32.125.1640.0% 9
50.0  48.4  39.0  55.5   5.8
 7. 176.32.125.1690.0% 9
38.0  37.9  37.7  38.5   0.0
 8. 54.239.43.20012.5% 9
1117. 1096. 862.8 1662. 274.5
 9. 54.239.43.17412.5% 8
1146. 1092. 872.1 1627. 261.4
10. ???
11. 54.239.110.227   12.5% 8
1266. 1247. 908.7 1566. 236.7
12. 54.239.111.6712.5% 8
1230. 1075. 883.4 1511. 227.7
13. 205.251.244.193  12.5% 8
1247. 1068. 890.1 1477. 219.1
14. ???

Via GTT's own looking glass tool: (Note the latency and packet loss starting
at hop 5)
 
IPv4 traceroute to 52.5.161.36

HOST: pao11-re0   Loss%   Snt   Last   Avg  Best  Wrst StDev
  1. et-2-1-0.cr4-dal3.ip4.gtt.ne  0.0% 5   42.3  39.4  36.1  42.3   2.2
  2. ip4.gtt.net   0.0% 5   36.1  38.6  36.1  41.5   2.4
  3. 176.32.125.1400.0% 5   48.5  55.2  48.5  61.9   5.0
  4. 176.32.125.1450.0% 5   39.5  41.2  36.2  45.0   3.4
  5. 54.239.43.20020.0% 5  1417. 1784. 1417. 2112. 306.6
  6. 54.239.43.98 20.0% 5  1413. 1770. 1413. 2116. 312.0
  7. ???  100.0 50.0   0.0   0.0   0.0   0.0
  8. 54.239.110.157   20.0% 5  1420. 1749. 1420. 2104. 306.9
  9. 54.239.109.9 20.0% 5  1394. 1720. 1394. 2081. 308.7
10. 205.251.245.65   20.0% 5  1395. 1706. 1395. 2072. 305.4
11. ???  100.0 50.0   0.0   0.0   0.0   0.0

 Peter Kranz
www.UnwiredLtd.com  
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com  

 

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Leo Bicknell]

In a message written on Mon, Mar 06, 2017 at 12:16:32PM -0500, 
valdis.kletni...@vt.edu wrote:
> Oh, and you're going to need support buy-in from *at least* Microsoft, Apple,
> Linux, Cisco, Juniper, and a significant chunk of major makers of CPE gear.

Valdis is just spouting a bunch of fake requirements.  It's all
lies folks.  I mean the thing is called "EZIP", the EZ is right in
the name.  We're going to drain that IETF swamp of all their so-called
experts and make sure simple proposals like this that regular people
can understand get a fair shot.  It's going to change the Internet,
bigly.

And, what about the e-mails?  I mean, come on, what are those SMTP
people hiding?

[For the humor impared, it's a joke folks.]

-- 
Leo Bicknell - bickn...@ufp.org
PGP keys at http://www.ufp.org/~bicknell/


signature.asc
Description: PGP signature

www.netflix.com / EC2 problem -- Persistent problems from Palo Alto to destinations to Netflix and other destinations with content on Amazon EC2 - 2000ms latency

[Peter Kranz]

I'm not making progress with GTT's NOC on this issue, can someone clued in
at Netflix or Amazon comment on this problem. I believe it started after
Amazons outage last week.

 

This is an MTR to www.netflix.com   (52.5.161.36)
from 208.71.159.3  . this should be just a couple of ms away from Palo Alto:

 



 

Via GTT's own looking glass tool:

 

IPv4 traceroute to 52.5.161.36

HOST: pao11-re0   Loss%   Snt   Last   Avg  Best  Wrst StDev

  1. et-2-1-0.cr4-dal3.ip4.gtt.ne  0.0% 5   42.3  39.4  36.1  42.3   2.2

  2. ip4.gtt.net   0.0% 5   36.1  38.6  36.1  41.5   2.4

  3. 176.32.125.1400.0% 5   48.5  55.2  48.5  61.9   5.0

  4. 176.32.125.1450.0% 5   39.5  41.2  36.2  45.0   3.4

  5. 54.239.43.20020.0% 5  1417. 1784. 1417. 2112. 306.6

  6. 54.239.43.98 20.0% 5  1413. 1770. 1413. 2116. 312.0

  7. ???  100.0 50.0   0.0   0.0   0.0   0.0

  8. 54.239.110.157   20.0% 5  1420. 1749. 1420. 2104. 306.9

  9. 54.239.109.9 20.0% 5  1394. 1720. 1394. 2081. 308.7

10. 205.251.245.65   20.0% 5  1395. 1706. 1395. 2072. 305.4

11. ???  100.0 50.0   0.0   0.0   0.0   0.0

 

 

Peter Kranz
www.UnwiredLtd.com  
Desk: 510-868-1614 x100
Mobile: 510-207-
pkr...@unwiredltd.com  

 

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[valdis . kletnieks]

On Mon, 06 Mar 2017 03:08:35 -0500, Joly MacFie said:

> routing hardware layer that will be hit & miss. Nevertheless, since much of
> the world is still IPv4 dependent, it just could take off.

For it to "take off", the very same people who have dragged their heels
deploying IPv6 will need to suddenly jump up and upgrade all their gear
and personnel to support a *third* protocol.

Oh, and you're going to need support buy-in from *at least* Microsoft, Apple,
Linux, Cisco, Juniper, and a significant chunk of major makers of CPE gear.

What's the business case for all these stakeholders to buy into EZIP?  For
both the "We already do IPv6" and "We don't do IP6v" cases?


pgp_q5lYaF_Pe.pgp
Description: PGP signature

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Joly MacFie]

I believe that. However it behooves us to give any of our members' ideas a
fair hearing. I'm hoping he'll get some good push back in the session.

Joly MacFie
j...@punkcast.com 218 565 9365

On Mar 6, 2017 11:14 AM, "William Herrin"  wrote:

> On Mon, Mar 6, 2017 at 3:08 AM, Joly MacFie  wrote:
> > To say that Mr. Chen's EZIP proposal has not, thus far, been received
> with
> > open arms by the networking community would be an understatement. It is
> > seen as delaying the inevitable and introducing an impractical extra
> > routing hardware layer that will be hit & miss. Nevertheless, since much
> of
> > the world is still IPv4 dependent, it just could take off. ISOC-NY is
> happy
> > to give him the opportunity to expound on its merits.
> > We'd welcome some expert respondents.
> >
> > See:
> > https://tools.ietf.org/html/draft-chen-ati-ipv4-with-
> adaptive-address-space-00
>
> Hi Joly,
>
> If something like this was going to happen, we could have expanded the
> v4 address space to 64 bits with IPxl:
> http://bill.herrin.us/network/ipxl.html
>
> At this point IPv6 has enough momentum that it can be safely expected
> to happen. That means all proposals for extending the IPv4 address
> space are basically dead in the water, especially complicated ones.
>
> Regards,
> Bill Herrin
>
>
> --
> William Herrin  her...@dirtside.com  b...@herrin.us
> Dirtside Systems . Web: 
>

Re: WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[William Herrin]

On Mon, Mar 6, 2017 at 3:08 AM, Joly MacFie  wrote:
> To say that Mr. Chen's EZIP proposal has not, thus far, been received with
> open arms by the networking community would be an understatement. It is
> seen as delaying the inevitable and introducing an impractical extra
> routing hardware layer that will be hit & miss. Nevertheless, since much of
> the world is still IPv4 dependent, it just could take off. ISOC-NY is happy
> to give him the opportunity to expound on its merits.
> We'd welcome some expert respondents.
>
> See:
> https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space-00

Hi Joly,

If something like this was going to happen, we could have expanded the
v4 address space to 64 bits with IPxl:
http://bill.herrin.us/network/ipxl.html

At this point IPv6 has enough momentum that it can be safely expected
to happen. That means all proposals for extending the IPv4 address
space are basically dead in the water, especially complicated ones.

Regards,
Bill Herrin


-- 
William Herrin  her...@dirtside.com  b...@herrin.us
Dirtside Systems . Web: 

Re: IPv6 doc. prefix (2001:db8::/32) - APNIC object ?

[Job Snijders]

Hi.

On Mon, Mar 6, 2017 at 5:03 PM, Alarig Le Lay  wrote:
> On lun.  6 mars 10:55:18 2017, Brandon Applegate wrote:
>> Just did a whois on the documentation prefix and was surprised to see what 
>> looks like a user object registered for it:
>>
>> % Information related to '2001:0DB8::/32AS132111'
>>
>> route6: 2001:0DB8::/32
>> descr:  FUTURE D SDN BHD
>> origin: AS132111
>> country:MY
>> mnt-by: MAINT-FUTUREDSDNBHD-MY
>> changed:hm-chan...@apnic.net 20160523
>> source: APNIC
>>
>> Any idea what this is ?  I would have thought there might be some sanity 
>> check that would have stopped this from getting registered ?
>
> Hi,
>
> If you look for TEST-NET-3, it is also registered to APNIC:
> [snip]
>
> As long as APNIC is a RIR, I don’t see a big issue with that.

Don't confuse an 'inetnum' and a 'route' object. Inetnum's are fine,
as long as their documented purpose is correct. The route object the
OP mentioned makes no sense. AS132111 is not authorised to announce
the IPv6 Documentation prefix.

Kind regards,

Job

Re: IPv6 doc. prefix (2001:db8::/32) - APNIC object ?

[Job Snijders]

Hi,

On Mon, Mar 6, 2017 at 4:55 PM, Brandon Applegate  wrote:
> Just did a whois on the documentation prefix and was surprised to see what 
> looks like a user object registered for it:
>
> % Information related to '2001:0DB8::/32AS132111'
>
> route6: 2001:0DB8::/32
> descr:  FUTURE D SDN BHD
> origin: AS132111
> country:MY
> mnt-by: MAINT-FUTUREDSDNBHD-MY
> changed:hm-chan...@apnic.net 20160523
> source: APNIC
>
> Any idea what this is ?  I would have thought there might be some sanity 
> check that would have stopped this from getting registered ?

This registration is an error, and APNIC should remove it.

It would be good if IRRs ensure that special IANA prefixes cannot be registered.

The URL in the inetnum is broken:

Vurt:~ job$ whois 2001:0DB8::/32 | grep remarks
remarks:This address range is to be used for documentation
remarks:purpose only. For more information please see
remarks:http://www.apnic.net/info/faq/ipv6-documentation-prefix-faq.html

Kind regards,

Job

Re: IPv6 doc. prefix (2001:db8::/32) - APNIC object ?

[Alarig Le Lay]

On lun.  6 mars 10:55:18 2017, Brandon Applegate wrote:
> Just did a whois on the documentation prefix and was surprised to see what 
> looks like a user object registered for it:
> 
> % Information related to '2001:0DB8::/32AS132111'
> 
> route6: 2001:0DB8::/32
> descr:  FUTURE D SDN BHD
> origin: AS132111
> country:MY
> mnt-by: MAINT-FUTUREDSDNBHD-MY
> changed:hm-chan...@apnic.net 20160523
> source: APNIC
> 
> Any idea what this is ?  I would have thought there might be some sanity 
> check that would have stopped this from getting registered ?

Hi,

If you look for TEST-NET-3, it is also registered to APNIC:
alarig@pikachu ~ % whois 203.0.113.1
% [whois.apnic.net]
% Whois data copyright termshttp://www.apnic.net/db/dbcopyright.html

% Information related to '203.0.113.0 - 203.0.113.255'

inetnum:203.0.113.0 - 203.0.113.255
netname:TEST-NET-3
descr:  IANA
descr:  RFC5737 Documentation Address Block
country:AU
admin-c:HM20-AP
tech-c: HM20-AP
mnt-by: APNIC-HM
mnt-routes: APNIC-HM
status: ASSIGNED PORTABLE
remarks:-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
remarks:This block is reserved for use in documentation and
remarks:should not be used in any real networks.
remarks:Please see more details at
remarks:http://www.iana.org/go/rfc5737
remarks:-+-+-+-+-+-+-+-+-+-+-+-++-+-+-+-+-+-+-+-+-+-+-+-+-+-+
source: APNIC
mnt-irt:IRT-APNICRANDNET-AU
changed:hm-chan...@apnic.net 20100617

irt:IRT-APNICRANDNET-AU
address:PO Box 3646
address:South Brisbane, QLD 4101
address:Australia
e-mail: ab...@apnic.net
abuse-mailbox:  ab...@apnic.net
admin-c:AR302-AP
tech-c: AR302-AP
auth:   # Filtered
mnt-by: MAINT-AU-APNIC-GM85-AP
changed:hm-chan...@apnic.net 20110922
source: APNIC

role:   APNIC Hostmaster
address:6 Cordelia Street
address:South Brisbane
address:QLD 4101
country:AU
phone:  +61 7 3858 3100
fax-no: +61 7 3858 3199
e-mail: helpd...@apnic.net
admin-c:AMS11-AP
tech-c: AH256-AP
nic-hdl:HM20-AP
remarks:Administrator for APNIC
notify: hostmas...@apnic.net
mnt-by: MAINT-APNIC-AP
changed:hm-chan...@apnic.net 1998
changed:hm-chan...@apnic.net 20020211
changed:hm-chan...@apnic.net 20070612
changed:hm-chan...@apnic.net 20100217
changed:hm-chan...@apnic.net 20101217
changed:hm-chan...@apnic.net 20110815
changed:hm-chan...@apnic.net 20121024
changed:hm-chan...@apnic.net 20131023
source: APNIC

% This query was served by the APNIC Whois Service version 1.69.1-APNICv1r0 
(UNDEFINED)

As long as APNIC is a RIR, I don’t see a big issue with that.

-- 
alarig


signature.asc
Description: PGP signature

IPv6 doc. prefix (2001:db8::/32) - APNIC object ?

[Brandon Applegate]

Just did a whois on the documentation prefix and was surprised to see what 
looks like a user object registered for it:

% Information related to '2001:0DB8::/32AS132111'

route6: 2001:0DB8::/32
descr:  FUTURE D SDN BHD
origin: AS132111
country:MY
mnt-by: MAINT-FUTUREDSDNBHD-MY
changed:hm-chan...@apnic.net 20160523
source: APNIC

Any idea what this is ?  I would have thought there might be some sanity check 
that would have stopped this from getting registered ?

--
Brandon Applegate - CCIE 10273
PGP Key fingerprint:
830B 4802 1DD4 F4F9 63FE  B966 C0A7 189E 9EC0 3A74
"SH1-0151.  This is the serial number, of our orbital gun."

Re: WWV Broadcast Outages

[Royce Williams]

On Mon, Mar 6, 2017 at 5:12 AM, Andrew Gallo  wrote:
>
> On 3/6/2017 3:55 AM, Majdi S. Abbas wrote:
>>
>> On Wed, Feb 22, 2017 at 04:59:53AM -0800, Hal Murray wrote:
>>>
>>> Any suggestions for gear and/or software that works with WWV (or CHU)?
>>> Or general suggestions for non GPS sources of time?
>>
>> Hey Hal!
>>
>> In North America, WWV and CHU are pretty much it for accessible
>> backups these days.  Unfortunately time and frequency distribution is a
>> niche that tends to get neglected (if not actively gutted) in US
>> budgets.
>
> Agreed, but I'll share this- the recent FCC CSRIC V had a working group (4B) 
> that studied the reliability of time and frequency distribution.
> https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability
>
> It may be of interest.

Specifically, the "Network Timing Single Source Risk Reduction - Final
Report" part:

https://transition.fcc.gov/bureaus/pshs/advisory/csric5/WG4B_FinalReport_122116.docx

My summary of its points:

* Analysis of vulnerabilities in the "supply chain" of GPS

* Assertion that GPS mitigations and alternatives are needed to reduce risk

* Some likely characteristics of good mitigations and alternatives

* A list of potential alternatives, their features, and their current
state (L2C & L5 GPS, Galileo & GLONASS, LEO satelltes, commercial RF,
antenna pattern optimization, NMA on L2C, sync over fiber, eLORAN,
other RF sync, terrestrial beacons, and hybrid DME)


>From the executive summary:

The U.S. communications sector relies heavily on the Global
Positioning System (GPS) to provide network time. GPS is a widely
available, extremely precise timing source that is used across
multiple infrastructure sectors. However, given the high dependence of
the communications sector on GPS, the Federal Communications
Commission (Commission) is interested in identifying ways to increase
the resilience of communications networks by exploring complementary
or backup solutions that could be employed to offer similar time
precision as GPS in the event that GPS signals are lost. These
solutions also need to be completely independent of GPS to
significantly reduce any risk. This report addresses the problems
associated with relying on GPS solutions, the ideal technical
characteristics for systems to backup or supplement GPS, and our
recommendations for possible backup solutions by the communications
industry and others reliant on communications network timing sources.

Royce

Re: WWV Broadcast Outages

[Andrew Gallo]

On 3/6/2017 3:55 AM, Majdi S. Abbas wrote:

On Wed, Feb 22, 2017 at 04:59:53AM -0800, Hal Murray wrote:

Any suggestions for gear and/or software that works with WWV (or CHU)?
Or general suggestions for non GPS sources of time?

Hey Hal!

In North America, WWV and CHU are pretty much it for accessible
backups these days.  Unfortunately time and frequency distribution is a
niche that tends to get neglected (if not actively gutted) in US
budgets.



Agreed, but I'll share this- the recent FCC CSRIC V had a working group 
(4B) that studied the reliability of time and frequency distribution.

https://www.fcc.gov/about-fcc/advisory-committees/communications-security-reliability-and-interoperability

It may be of interest.

Re: WWV Broadcast Outages

[Majdi S. Abbas]

On Wed, Feb 22, 2017 at 04:59:53AM -0800, Hal Murray wrote:
> Any suggestions for gear and/or software that works with WWV (or CHU)?  
> Or general suggestions for non GPS sources of time?

Hey Hal!

In North America, WWV and CHU are pretty much it for accessible
backups these days.  Unfortunately time and frequency distribution is a 
niche that tends to get neglected (if not actively gutted) in US
budgets.

> Dave Mills had a driver in ntpd that used a PC audio port to listen to WWV.  
> I don't know anybody who ever used it.  I think there was code to tell some 
> brand of receiver with a serial/USB port how to change frequencies so you 
> could use the one that worked best for that time of day.

You do now.  The WWV and CHU audio drivers work fine.  If you
want the auto-tuning functionality, you need to use an Icom receiver
that supports their CI-V protocol.  (This can be a full fledged tabletop
like the R-75, or a more compact receiver like their PCR-100 or 1000.  
Some of these are no longer produced, but they're easy to come by on the
secondary markets.  I picked up multiple PCR-100s off eBay at $25 ea a
while ago.)

You can always use any shortwave receiver, and just tune it to a
good frequency.  There are also kit and prebuilt 10 MHz receivers out 
there in the $30-$40 range which will work.  You accept a slight loss in
daily coverage by selecting a compromise frequency, but it's better than
nothing and independent of GPS.

If you (or anyone else on NANOG) needs some help getting the
audio refclocks working; drop me a line.

> There used to be WWVB (60 KHz) receivers.  The good ones phase locked 
> to the carrier.  The general rise in EMI made those close to useless 
> in most locations.  NIST finished the job when they changed the 
> modulation format a few years ago.  As far as I know, there aren't any 
> replacements for the old gear that take advantage of the new modulation 
> format.  GPS works too well.

It's not so much that GPS works so well, as there's no way to
produce a commercial receiver that uses the enhanced format.  By gifting
the developed IP back to the developer as part of the SIPR grant, it is
all sitting under a patent umbrella.  Unfortunately, the startup that 
developed it appears to have failed (at least, they've mostly vanished,
folks seem to have moved on, and they're late on corporate reports at 
this point.) -- leaving the new format only usable by hackers and not
something that can be rolled into a commercial timing receiver.

My biggest beef with the new format was the rollout, 5 years ago
now, before a commercial receiver was available on the market.  I'm not
sure why NIST has stuck with it.

> There are some boxes that recover the time from nearby cell phone towers.  I 
> think they will stop working as the towers get upgraded to the newer 
> protocols that use a different form of timing.  That will probably take many 
> years.  But the cell phone towers depend on GPS.  (You can ususlly spot the 
> conical antenna(s) if you look around a bit.)

CDMA was only ever good to +/- 10ms anyway, at least any of the
boxes I ever used.  You can actually outperform it with classic WWV or CHU,
and those get you a real backup, rather than an indirect dependancy on
GPS.

--msa

WEBINAR TUESDAY: Can We Make IPv4 Great Again?

[Joly MacFie]

To say that Mr. Chen's EZIP proposal has not, thus far, been received with
open arms by the networking community would be an understatement. It is
seen as delaying the inevitable and introducing an impractical extra
routing hardware layer that will be hit & miss. Nevertheless, since much of
the world is still IPv4 dependent, it just could take off. ISOC-NY is happy
to give him the opportunity to expound on its merits.
​ We'd welcome some expert respondents.​

​See: ​
https://tools.ietf.org/html/draft-chen-ati-ipv4-with-adaptive-address-space-00


​==​

WEBINAR TUESDAY: Can We Make IPv4 Great Again? w/ @AbrahamYChen

On Tuesday March 8 2017 at noon EST the Internet Society New York Chapter
(ISOC-NY) presents a webinar Can We Make IPv4 Great Again?. Abraham Y.
Chen, VP of Engineering, Avinta Communications, will present his EzIP
proposal to reinvigorate the diminishing pool of IPv4 addresses.
​Optional registration
 at the link below. This will be recorded.

What: WEBINAR: Can We Make IPv4 Great Again?
When: Tuesday March 8 2017 Noon EST | 17:00 UTC
Register + info: https://www.meetup.com/isoc-ny/events/238164448/
Computer: https://zoom.us/j/914492141
Phone: http://bit.ly/zoomphone
​ ​
ID: 914 492 141
Twitter: #ezip

​​










Permalink

http://isoc-ny.org/p2/9031








--
---
Joly MacFie  218 565 9365 Skype:punkcast
--
-