Re: IPv6 deployment excuses

[Masataka Ohta]

Jared Mauch wrote:


https://youtu.be/v26BAlfWBm8

Is always good for a reminder and laughs on a holiday weekend.


But, end to end NATs are actually good:

https://tools.ietf.org/html/draft-ohta-e2e-nat-00

fully transparent to all the transport and application layer
protocols.

And, to applications running over TCP/UDP, UPnP capable legacy
NATs are transparent, if host TCP/UDP are modified to perform
reverse NAT, information to do so is provided by UPnP.

Masataka Ohta

Charter CMTS help requested

[Daniel Brisson]

Hello,

I’m hoping a Charter engineer with CMTS expertise would be willing to hit me 
off-list regarding a chronic connectivity issue.  I’m getting nowhere with 
customer service or escalation and would love to talk to someone who could get 
to the root cause.

Thanks in advance,
-dan

RE: IPv6 deployment excuses

[Gary Wardell]

Ok, 

 

I didn't dig.

 

Evidently it's because not all of the content could be delivered over v6.

 



 

> -Original Message-

> From: NANOG [mailto:nanog-boun...@nanog.org] On Behalf Of Alarig Le

> Lay

> Sent: Friday, July 01, 2016 5:53 PM

> To: nanog@nanog.org

> Subject: Re: IPv6 deployment excuses

> 

> On Fri Jul  1 17:43:21 2016, Gary Wardell wrote:

> > >

> > >   http://ipv6excuses.com/

> >

> > That website only supports IPv4.

> 

> It’s on your side.

> 

> alarig@pikachu ~ % telnet ipv6excuses.com http Trying

> 2403:7000:8000:500::26...

> Connected to ipv6excuses.com.

> Escape character is '^]'.

> ^]

> telnet> quit

> Connection closed.

> 

> --

> alarig

Re: IPv6 deployment excuses

[Hugo Slabbert]

 From: Alarig Le Lay  -- Sent: 2016-07-01 - 14:53 

> On Fri Jul  1 17:43:21 2016, Gary Wardell wrote:
>> >
>> > http://ipv6excuses.com/
>>
>> That website only supports IPv4.
>
> It’s on your side.
>
> alarig@pikachu ~ % telnet ipv6excuses.com http
> Trying 2403:7000:8000:500::26...
> Connected to ipv6excuses.com.
> Escape character is '^]'.
> ^]
> telnet> quit
> Connection closed.
>
> --
> alarig

twitter.com, OTOH...

--
Hugo




signature.asc
Description: PGP/MIME digital signature

Re: IPv6 deployment excuses

[Alarig Le Lay]

On Fri Jul  1 17:43:21 2016, Gary Wardell wrote:
> > 
> > http://ipv6excuses.com/
> 
> That website only supports IPv4.

It’s on your side.

alarig@pikachu ~ % telnet ipv6excuses.com http
Trying 2403:7000:8000:500::26...
Connected to ipv6excuses.com.
Escape character is '^]'.
^]
telnet> quit
Connection closed.

-- 
alarig


signature.asc
Description: Digital signature

RE: IPv6 deployment excuses

[Gary Wardell]

> 
> http://ipv6excuses.com/

That website only supports IPv4.

Gary

Re: IPv6 deployment excuses

[Jared Mauch]

https://youtu.be/v26BAlfWBm8

Is always good for a reminder and laughs on a holiday weekend. 

Jared Mauch

> On Jul 1, 2016, at 5:00 PM, Hugo Slabbert  wrote:
> 
> http://ipv6excuses.com/
> https://twitter.com/ipv6excuses

Re: IPv6 deployment excuses

[Hugo Slabbert]

 From: Mike Jones  -- Sent: 2016-07-01 - 12:52 

> Hi,
>
> I am in contact with a couple of network operators trying to prod them
> to deploy IPv6, I figured that 10 minutes to send a couple of emails
> was worth the effort to make them "see a customer demand" (now none of
> them can use the excuse that nobody has asked for it!), but the
> replies I got were less than impressive to say the least.
>
> I was wondering if you guys could summarise your experiences with
> people who make excuses for not deploying IPv6?

http://ipv6excuses.com/
https://twitter.com/ipv6excuses

>
> - Mike Jones
>

--
Hugo



signature.asc
Description: PGP/MIME digital signature

Re: IPv6 deployment excuses

[Marcin Cieslak]

On Fri, 1 Jul 2016, Mike Jones wrote:

> Hi,
> 
> I am in contact with a couple of network operators trying to prod them
> to deploy IPv6, I figured that 10 minutes to send a couple of emails
> was worth the effort to make them "see a customer demand" (now none of
> them can use the excuse that nobody has asked for it!), but the
> replies I got were less than impressive to say the least.

When I talked to one European residential cable provider ca. 2008
they used a similar argument. Fast forward to 2016 and
IPv6 (and dual stack lite) is *the* way they provide Internet access
those days. The reason is simple: their growth rate is way too high
to provide IPv4 to everyone at this point.

If the provider is still using the "see a customer demand" argument
this could mean their IPv4 demand may not be growing fast enough. 
Depending on the market they operate on this an be an indication that
their market growth rate may not be fast enough.

Maybe their customer demand for IP(v4) leaves something to be desired?
Or they sit on some almost empty /8s.

Marcin

IPv6 deployment excuses

[Mike Jones]

Hi,

I am in contact with a couple of network operators trying to prod them
to deploy IPv6, I figured that 10 minutes to send a couple of emails
was worth the effort to make them "see a customer demand" (now none of
them can use the excuse that nobody has asked for it!), but the
replies I got were less than impressive to say the least.

I was wondering if you guys could summarise your experiences with
people who make excuses for not deploying IPv6? I regularly see a
specific person saying "we can't deploy it because X" followed by you
guys "correcting them" and telling them how to deploy it without the
problems they claim they will have, but that is only a small snapshot
of the people who bother to post about their ignorance in public. I
suspect there is also a lot of selection-bias in the NANOG membership
base but you deal with a lot of enterprise networks off of this list
so probably have broader experience than the NANOG archives.

Can we have a thread summarising the most common excuses you've heard,
and if they are actual problems blocking IPv6 deployment or just down
to ignorance? Perhaps this could be the basis for an FAQ type page
that I can point people to when they say they don't know how to deploy
IPv6 on their networks? :)

- Mike Jones

Re: yahoo mta admin help needed

[Elizabeth Zwicky via NANOG]

Start by going to https://postmaster.yahoo.com and describing symptoms (they're 
not going to respond well to mentions of ACL blocks, and will want to know 
what's actually happening in SMTP).
Also, timeouts on the Yahoo side are also rare in the extreme, so if your 
problem is that attempts time out or vanish into a black hole, I would start 
troubleshooting elsewhere.
Elizabeth Zwicky

On Friday, July 1, 2016 12:27 PM, Lyndon Nerenberg  
wrote:
 

 Is there a Yahoo MTA admin listening who can help diagnose what might be a 
network ACL block to one of our SMTP server subnets?

Thanks,

--lyndon

yahoo mta admin help needed

[Lyndon Nerenberg]

Is there a Yahoo MTA admin listening who can help diagnose what might be a 
network ACL block to one of our SMTP server subnets?

Thanks,

--lyndon

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

[Owen DeLong]

I have to agree with Rick here.

Owen

> On Jun 29, 2016, at 22:43 , Rick Astley  wrote:
> 
> I have to agree with Dan in that even if you disagreed with the talk you
> have to agree that it probably spawned relevant discussion and reflection
> (both on and off list). I would hate to see a move to ideas and discussions
> that are chosen simply for offending the fewest people. Another sort of
> similar critique aimed at large routing vendors was "Help! My big expensive
> router is really expensive" at NANOG 60 in Atlanta. Perhaps the critiques
> were seen as more constructive and I don't remember the same backlash after
> the talk but I found both talks and various discussions that followed
> insightful.
> 
> On Fri, Jun 17, 2016 at 4:53 PM, Daniel Golding  wrote:
> 
>> Hmm - as far as whether this was a good or bad NANOG presentation...this is
>> some of the best discussion I've seen on list in a while. There is a frank
>> exchange of views between many different parties. This may result in some
>> follow-up presentations at future NANOGs by IXP operators (please!).
>> 
>> Seems that, whether you agree with Dave or not, it was successful. It also
>> seems that the IXP operators who came under the most criticism have reacted
>> with a lot of professionalism and maturity. Other IXP operators have
>> reacted pretty poorly, which is ironic.
>> 
>> Dan
>> 

Re: IPv4 Legacy assignment frustration

[Mike Hammett]

<3 name and shame. 




- 
Mike Hammett 
Intelligent Computing Solutions 
http://www.ics-il.com 



Midwest Internet Exchange 
http://www.midwest-ix.com 


- Original Message -

From: "Tom Smyth"  
To: "Ray Soucy"  
Cc: nanog@nanog.org 
Sent: Thursday, June 23, 2016 10:23:39 AM 
Subject: Re: IPv4 Legacy assignment frustration 

Hi Ray, Kraig 
I think people affected just have to try to put pressure on their isps in 
the path between the afffected ips and hope for the best... public pressure 
is probably the only way to get around what I think most of us would agree 
is a terrible practice... I really hope that we can get rid of this 
practice as the last crumbs of IPv4 are carved up and re-distributed 
amongst new and growing isps. 

perhaps a name and shame project to highlight those isps that block ip 
ranges constantly and indiscriminately, 
needless to say the impact such practice has on peoples freedom to 
communicate, 

Thanks 

Tom Smyth 



On Thu, Jun 23, 2016 at 4:09 PM, Ray Soucy  wrote: 

> Regardless of whether or not people "should" do this, I think the horse has 
> already left the barn on this one. I don't see any way of getting people 
> who decided to filter all of APNIC to make changes. Most of them are 
> static configurations that they'll never look to update. 
> 
> On Wed, Jun 22, 2016 at 12:06 PM, Kraig Beahn  wrote: 
> 
> > The following might add some clarity, depending upon how you look at it: 
> > 
> > We, as "core" engineers know better than to use some of the sources 
> listed 
> > below, tho, my suspicion is that when an engineer or local IT person, on 
> an 
> > edge network starts to see various types of attacks, they play 
> wack-a-mole, 
> > based upon outdated or incomplete data, and never think twice about 
> > revisiting such, as, from their perspective, everything is working just 
> > fine. 
> > 
> > In a networking psychology test, earlier this morning, I wrote to ten 
> > well-known colleagues that I was fairly confident didn't regularly follow 
> > the nanog lists. Such individuals comprised of IP and IT engineers for 
> > which manage various network sizes and enterprises, ultimately posing the 
> > question of "Where in the world is 150.201.15.7, as we were researching 
> > some unique traffic patterns". 
> > 
> > *Seven out of ten came back with overseas*. Two came back with more 
> > questions "as the address space appeared to be assigned to APNIC", but 
> was 
> > routed domestically. 
> > 
> > *One came back with the correct response.* (MORENET) 
> > 
> > Two of the queried parties were representative of major networks, one for 
> > an entire state governmental network with hundreds of thousands of actual 
> > users and tens of thousands of routers, the other from another major 
> > university. (Names left out, in the event they see this message later in 
> > the day or week) 
> > 
> > After probing the origin of their responses, I found the following 
> methods 
> > or data-sources were used: 
> > 
> > -Search Engines - by far, the worst offender. Not necessarily "the 
> engines" 
> > at fault, but a result of indexed sites containing inaccurate or outdated 
> > CIDR lists. 
> > -User generated forums, such as "Block non-North American Traffic for 
> > Dummies Like Me 
> > " 
> > (Yes - that's the actual thread name on WebMasterWorld.com, from a Sr. 
> > Member) 
> > -Static (or aged) CIDR web-page based lists, usually placed for 
> advertorial 
> > generation purposes and rarely up to date or accurate. (usually via SE's 
> or 
> > forum referrals) 
> > -APNIC themselves - A basic SE search resulted in an APNIC page 
> > < 
> > 
> https://www.apnic.net/manage-ip/manage-historical-resources/erx-project/erx-ranges
>  
> > > 
> > that, 
> > on it's face, appears to indicate 150.0.0.0/8 is in fact, part of the 
> > current APNIC range. 
> > -GitHub BGP Ranking tools: CIRCL / bgp-ranging example 
> > < 
> https://github.com/CIRCL/bgp-ranking/blob/master/lib/db_init/ip_del_list> 
> > (last 
> > updated on May 16th, 2011, tho an RT lookup 
> >  via the CIRCL 
> tool 
> > does shows the appropriate redirect/org) 
> > -Several routing oriented books and Cisco examples 
> > < 
> > 
> http://www.cisco.com/c/en/us/support/docs/ip/integrated-intermediate-system-to-intermediate-system-is-is/13796-route-leak.pdf
>  
> > > 
> > list 
> > such range, for example, FR/ISBN 2-212-09238-5. 
> > -And even established ISPs, that are publically announcing their "block 
> > list 
> > ", such as Albury's 
> > Local 
> > ISP in Australia 
> > 
> > The simple answer is to point IT directors, IP engineers or "the 
> > receptionists that manages the network" to the appropriate registry 
> > data-source, which should convince them that corrective action is 
> > necessary, i.e. fix your routing table or fir

[NANOG-announce] NANOG ON THE ROAD - NYC

[Betty Burke]

We are very excited to be holding the next NOTR event in New York
 on July 21, 2016, and we
invite you to join us!

Are you interested in Internet networking/peering? Do you work at a
colocation, hosting or data center facility? Are you a provider of
hardware/software solutions for the Internet industry?  If so, the NANOG On
The Road New York event is perfect for you!

Date:  Thursday, July 21, 2016
Time:  Registration Desk opens at 8:30am and Program is from 9:00 AM - 5:00
PM
Location: Marriott Marquis  - 1535
Broadway, New York, NY  10036
The FREE to attend event is open for registration.  Register Now!


If you are, or will be, in the New York area, we invite you to attend.  And
don’t forget to share the invitation with your colleagues or others you
feel may benefit from attending.  Make NANOG On The Road your first step
toward learning how you can take the wheel and steer the future of the
Internet.

Learn more about On The Road events here
.  Feel free to contact us at
nanog-supp...@nanog.org with any questions you may have.


Sincerely,

Betty

Betty J. Burke
NANOG Executive Director
2864 Carpenter Rd., Ste 100
Ann Arbor, MI 48108
+1 866-902-1336
___
NANOG-announce mailing list
nanog-annou...@mailman.nanog.org
http://mailman.nanog.org/mailman/listinfo/nanog-announce