Re: Public DNS64

[Mark Andrews]

IP6.ARPA lookups aren't working.  Adobe.com doesn't have  record
so it correctly returns a DNS64 mapped  record.  However when
you attempt to do a IP6.ARPA lookup on that address it does not
follow the synthesised CNAME record as you would expect from a
recursive DNS64 server.

Mark

; <<>> DiG 9.11.0a2 <<>>  adobe.com @2001:4860:4860::6464
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16081
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;adobe.com. IN  

;; ANSWER SECTION:
adobe.com.  10799   IN  64:ff9b::c096:1075

;; Query time: 435 msec
;; SERVER: 2001:4860:4860::6464#53(2001:4860:4860::6464)
;; WHEN: Mon May 30 11:55:56 EST 2016
;; MSG SIZE  rcvd: 66


; <<>> DiG 9.11.0a2 <<>> -x 64:ff9b::c096:1075 @2001:4860:4860::6464
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 16070
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;5.7.0.1.6.9.0.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.9.f.f.4.6.0.0.ip6.arpa. IN 
PTR

;; ANSWER SECTION:
5.7.0.1.6.9.0.c.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.0.b.9.f.f.4.6.0.0.ip6.arpa. 10799 
IN CNAME 117.16.150.192.in-addr.arpa.

;; Query time: 355 msec
;; SERVER: 2001:4860:4860::6464#53(2001:4860:4860::6464)
;; WHEN: Mon May 30 11:56:12 EST 2016
;; MSG SIZE  rcvd: 138


; <<>> DiG 9.11.0a2 <<>> ptr 117.16.150.192.in-addr.arpa @2001:4860:4860::6464
;; global options: +cmd
;; Got answer:
;; ->>HEADER<<- opcode: QUERY, status: NOERROR, id: 93
;; flags: qr rd ra; QUERY: 1, ANSWER: 1, AUTHORITY: 0, ADDITIONAL: 1

;; OPT PSEUDOSECTION:
; EDNS: version: 0, flags:; udp: 512
;; QUESTION SECTION:
;117.16.150.192.in-addr.arpa.   IN  PTR

;; ANSWER SECTION:
117.16.150.192.in-addr.arpa. 10532 IN   PTR www.wip4.adobe.com.

;; Query time: 338 msec
;; SERVER: 2001:4860:4860::6464#53(2001:4860:4860::6464)
;; WHEN: Mon May 30 11:56:36 EST 2016
;; MSG SIZE  rcvd: 88

In message 
, Tim Durack writes:
> For the record:
> 
> Tim,
> 
> I'm not on the NANOG lists and I don't see how I can respond to this thread:
> 
> https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html
> 
> but I figured I'd let you know that:
> 
> https://developers.google.com/speed/public-dns/docs/dns64
> 
> is now available for testing.  Perhaps it will be some use.
> 
> Regards,
> -Erik
> 
> On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack  wrote:
> 
> > Anyone know of a reliable public DNS64 service?
> >
> > Would be cool if Google added a Public DNS64 service, then I could point
> > the NAT64 prefix at appropriately placed boxes in my network.
> >
> > Why? Other people are better than me at running DNS resolvers :-)
> >
> > --
> > Tim:>
> >
> 
> 
> 
> -- 
> Tim:>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Public DNS64

[Mark Andrews]

In message 

Re: Public DNS64

[Mark Andrews]

DNS64 is a bad solution.  It breaks DNSSEC.  The proported benefits of
DNS64 over other ways of providing IPv4 over IPv6 don't actually exist.

DS-Lite or one of the MAP encapsulation will actually be better in the
long run.

I say this as someone who has written a DNS64 implementation.

Mark

In message 
, Tim Durack writes:
> For the record:
> 
> Tim,
> 
> I'm not on the NANOG lists and I don't see how I can respond to this thread:
> 
> https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html
> 
> but I figured I'd let you know that:
> 
> https://developers.google.com/speed/public-dns/docs/dns64
> 
> is now available for testing.  Perhaps it will be some use.
> 
> Regards,
> -Erik
> 
> On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack  wrote:
> 
> > Anyone know of a reliable public DNS64 service?
> >
> > Would be cool if Google added a Public DNS64 service, then I could point
> > the NAT64 prefix at appropriately placed boxes in my network.
> >
> > Why? Other people are better than me at running DNS resolvers :-)
> >
> > --
> > Tim:>
> >
> 
> 
> 
> -- 
> Tim:>
-- 
Mark Andrews, ISC
1 Seymour St., Dundas Valley, NSW 2117, Australia
PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org

Re: Public DNS64

[Baldur Norddahl]

Ok that would be a bad idea. Nat64 is not stateless so to anycast it would
be unstable.

Sorry time to get to sleep.

Regards

Baldur
Den 30. maj 2016 03.25 skrev "Baldur Norddahl" :

> Interesting. Now we just need someone like he.net to announce the
> 64:ff9b::/96 prefix and run a public nat64 service.
> Den 30. maj 2016 03.08 skrev "Tim Durack" :
>
>> For the record:
>>
>> Tim,
>>
>> I'm not on the NANOG lists and I don't see how I can respond to this
>> thread:
>>
>> https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html
>>
>> but I figured I'd let you know that:
>>
>> https://developers.google.com/speed/public-dns/docs/dns64
>>
>> is now available for testing.  Perhaps it will be some use.
>>
>> Regards,
>> -Erik
>>
>> On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack  wrote:
>>
>> > Anyone know of a reliable public DNS64 service?
>> >
>> > Would be cool if Google added a Public DNS64 service, then I could point
>> > the NAT64 prefix at appropriately placed boxes in my network.
>> >
>> > Why? Other people are better than me at running DNS resolvers :-)
>> >
>> > --
>> > Tim:>
>> >
>>
>>
>>
>> --
>> Tim:>
>>
>

Re: Public DNS64

[Baldur Norddahl]

Interesting. Now we just need someone like he.net to announce the
64:ff9b::/96 prefix and run a public nat64 service.
Den 30. maj 2016 03.08 skrev "Tim Durack" :

> For the record:
>
> Tim,
>
> I'm not on the NANOG lists and I don't see how I can respond to this
> thread:
>
> https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html
>
> but I figured I'd let you know that:
>
> https://developers.google.com/speed/public-dns/docs/dns64
>
> is now available for testing.  Perhaps it will be some use.
>
> Regards,
> -Erik
>
> On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack  wrote:
>
> > Anyone know of a reliable public DNS64 service?
> >
> > Would be cool if Google added a Public DNS64 service, then I could point
> > the NAT64 prefix at appropriately placed boxes in my network.
> >
> > Why? Other people are better than me at running DNS resolvers :-)
> >
> > --
> > Tim:>
> >
>
>
>
> --
> Tim:>
>

Re: Public DNS64

[Tim Durack]

For the record:

Tim,

I'm not on the NANOG lists and I don't see how I can respond to this thread:

https://mailman.nanog.org/pipermail/nanog/2014-August/069267.html

but I figured I'd let you know that:

https://developers.google.com/speed/public-dns/docs/dns64

is now available for testing.  Perhaps it will be some use.

Regards,
-Erik

On Fri, Aug 15, 2014 at 2:29 PM, Tim Durack  wrote:

> Anyone know of a reliable public DNS64 service?
>
> Would be cool if Google added a Public DNS64 service, then I could point
> the NAT64 prefix at appropriately placed boxes in my network.
>
> Why? Other people are better than me at running DNS resolvers :-)
>
> --
> Tim:>
>



-- 
Tim:>

Re: NANOG 67 closing social

[Ilissa Miller]

There is indeed a social weds night!
The host sponsor, EdgeConneX is holding its social on Weds.  Please
plan accordingly!

Ilissa Miller


> On May 29, 2016, at 4:00 PM, Mike Joseph  wrote:
>
> Sending this to the list as well as Betty, in case anyone on the PC has
> more details:
>
> I've noticed on the NANOG 67 agenda that there's a social scheduled for
> Wednesday night, which I think is odd since we (almost) never have any
> social or other events after conference closing.
>
> In fact, I noticed something very similar on a version of the NANOG 66
> agenda and then it was revised a week or two before the conference.
>
> So, the question is pose is:  *Is this an error on the NANOG 67 agenda, or
> are we really having a social on the last night?*
>
> -MJ

Re: CALEA

[Josh Luthman]

How many requests per 1k or 10k customers?  Is primarily residential a safe
assumption?


Josh Luthman
Office: 937-552-2340
Direct: 937-552-2343
1100 Wayne St
Suite 1337
Troy, OH 45373

On Fri, May 27, 2016 at 11:37 PM, Mike Joseph  wrote:

> I can say via firsthand knowledge that CALEA requests are definitely
> happening and are not even that rare, proportional to a reasonably sized
> subscriber-base.  It would be unlawful for me to comment specifically on
> any actual CALEA requests, however.  But if you have general questions
> about my observations, feel free to reach out directly.
>
> -MJ
>
> On Thu, May 12, 2016 at 11:28 AM, Brian Mengel  wrote:
>
> > My comments were strictly limited to my understanding of CALEA as it
> > applied to ISPs, not telcos.  A request for a lawful intercept can entail
> > mirroring a real time stream of all data sent to/from a customer's
> Internet
> > connection (cable modem/DSL/dedicated Ethernet) to a LEA.  AFAIK this
> > requires mediation before being sent to the LEA and it is the mediation
> > server itself that initiates the intercept when so configured by the ISP.
> > Perhaps some LEAs have undertaken the mediation function so as to
> > facilitate these intercepts where the neither the ISP nor a third party
> can
> > do so.  If that were the case then very little would be needed on the
> part
> > of the ISP in order to comply with a request for lawful intercept.  I can
> > say with certainty that these types of requests are being made of
> broadband
> > ISPs though I agree that they are very rare.
> >
> > On Wed, May 11, 2016 at 2:58 PM, Ricky Beam  wrote:
> >
> > > On Tue, 10 May 2016 17:00:54 -0400, Brian Mengel 
> > > wrote:
> > >
> > > AFAIK being able to do a lawful intercept on a specific, named,
> > >> individual's service has been a requirement for providers since 2007.
> > >>
> > >
> > > It's been required for longer than that. The telco I worked for over a
> > > decade ago didn't build the infrastructure until the FCC said they were
> > > going to stop funding upgrades. That really got 'em movin'. (suddenly
> > "data
> > > services" people -- i.e. ME -- weren't redheaded stepchildren.)
> > >
> > > have never heard of a provider, big or small, being called out for
> being
> > >> unable to provide this service when requested.
> > >>
> > >
> > > Where existing infrastructure is not already in place (read:
> > T1/BRI/etc.),
> > > the telco can take up to 60 days to get that setup. I know more than
> one
> > > telco that used that grace period to actually setup CALEA in the first
> > > place.
> > >
> > > did not perform intercepts routinely.
> > >>
> > >
> > > The historic published figures (i've not looked in years) suggest CALEA
> > > requests are statistically rare. The NC based telco I worked for had
> > never
> > > received an order in the then ~40yr life of the company.
> > >
> > > The mediation server needed to "mediate" between your customer
> > aggregation
> > >> box and the LEA is not inexpensive.
> > >>
> > >
> > > And also is not the telco's problem. Mediation is done by the LEA or
> 3rd
> > > party under contract to any number of agencies. For example, a telco
> tap
> > > order would mirror the control and voice traffic of a POTS line (T1/PRI
> > > channel, etc.) into a BRI or specific T1 channel. (dialup was later
> > added,
> > > but wasn't required in my era, so we didn't support it.) We used to
> test
> > > that by tapping a tech's phone. Not having any mediation software, all
> I
> > > could do is "yeap, it's sending data" and listen to the voice channels
> > on a
> > > t-berd.
> > >
> > > --Ricky
> > >
> >
> >
>

Re: CALEA

[Mike Joseph]

I can say via firsthand knowledge that CALEA requests are definitely
happening and are not even that rare, proportional to a reasonably sized
subscriber-base.  It would be unlawful for me to comment specifically on
any actual CALEA requests, however.  But if you have general questions
about my observations, feel free to reach out directly.

-MJ

On Thu, May 12, 2016 at 11:28 AM, Brian Mengel  wrote:

> My comments were strictly limited to my understanding of CALEA as it
> applied to ISPs, not telcos.  A request for a lawful intercept can entail
> mirroring a real time stream of all data sent to/from a customer's Internet
> connection (cable modem/DSL/dedicated Ethernet) to a LEA.  AFAIK this
> requires mediation before being sent to the LEA and it is the mediation
> server itself that initiates the intercept when so configured by the ISP.
> Perhaps some LEAs have undertaken the mediation function so as to
> facilitate these intercepts where the neither the ISP nor a third party can
> do so.  If that were the case then very little would be needed on the part
> of the ISP in order to comply with a request for lawful intercept.  I can
> say with certainty that these types of requests are being made of broadband
> ISPs though I agree that they are very rare.
>
> On Wed, May 11, 2016 at 2:58 PM, Ricky Beam  wrote:
>
> > On Tue, 10 May 2016 17:00:54 -0400, Brian Mengel 
> > wrote:
> >
> > AFAIK being able to do a lawful intercept on a specific, named,
> >> individual's service has been a requirement for providers since 2007.
> >>
> >
> > It's been required for longer than that. The telco I worked for over a
> > decade ago didn't build the infrastructure until the FCC said they were
> > going to stop funding upgrades. That really got 'em movin'. (suddenly
> "data
> > services" people -- i.e. ME -- weren't redheaded stepchildren.)
> >
> > have never heard of a provider, big or small, being called out for being
> >> unable to provide this service when requested.
> >>
> >
> > Where existing infrastructure is not already in place (read:
> T1/BRI/etc.),
> > the telco can take up to 60 days to get that setup. I know more than one
> > telco that used that grace period to actually setup CALEA in the first
> > place.
> >
> > did not perform intercepts routinely.
> >>
> >
> > The historic published figures (i've not looked in years) suggest CALEA
> > requests are statistically rare. The NC based telco I worked for had
> never
> > received an order in the then ~40yr life of the company.
> >
> > The mediation server needed to "mediate" between your customer
> aggregation
> >> box and the LEA is not inexpensive.
> >>
> >
> > And also is not the telco's problem. Mediation is done by the LEA or 3rd
> > party under contract to any number of agencies. For example, a telco tap
> > order would mirror the control and voice traffic of a POTS line (T1/PRI
> > channel, etc.) into a BRI or specific T1 channel. (dialup was later
> added,
> > but wasn't required in my era, so we didn't support it.) We used to test
> > that by tapping a tech's phone. Not having any mediation software, all I
> > could do is "yeap, it's sending data" and listen to the voice channels
> on a
> > t-berd.
> >
> > --Ricky
> >
>
>

NANOG 67 closing social

[Mike Joseph]

Sending this to the list as well as Betty, in case anyone on the PC has
more details:

I've noticed on the NANOG 67 agenda that there's a social scheduled for
Wednesday night, which I think is odd since we (almost) never have any
social or other events after conference closing.

In fact, I noticed something very similar on a version of the NANOG 66
agenda and then it was revised a week or two before the conference.

So, the question is pose is:  *Is this an error on the NANOG 67 agenda, or
are we really having a social on the last night?*

-MJ

Re: VOIP Monitoring Solution

[Dovid Bender]

Check out voipmonitor.org.

On Wed, May 25, 2016 at 3:10 AM, segs 
wrote:

> Hi All,
>
> I Am on the lookout for a solution that can monitor IP phones in use on the
> network.
>
>  The solution should have
>
>  -- a very intuitive GUI
>
>  -- detailed reporting mechanism.
>
>  --- send basic commands like restart to the phones
>
>   monitor number of active calls on the call manager
>
>   monitor status of trunks > --- can show visual details of two ip
> phones in an active call
>
>  --- show details of call quality.
>
> The environment in question is using Cisco Call manager BE7k and cisco Ip
> phones.
>
> Thanks in advance.
>
> Segun Rufai
>

Re: Global/distributed IXP operators?

[Marty Strong via NANOG]

I think he means IXes like NetIX: http://netix.net/map, a single distributed 
fabric.

Regards,
Marty Strong
--
CloudFlare - AS13335
Network Engineer
ma...@cloudflare.com
+44 7584 906 055
smartflare (Skype)

http://www.peeringdb.com/view.php?asn=13335

> On 29 May 2016, at 13:26, Mike Hammett  wrote:
> 
> Could you define what you mean by a distributed\global IXP? There are plenty 
> of IXPs, but there aren't really global IXPs, those just become networks. 
> 
> 
> 
> 
> - 
> Mike Hammett 
> Intelligent Computing Solutions 
> http://www.ics-il.com 
> 
> 
> 
> Midwest Internet Exchange 
> http://www.midwest-ix.com 
> 
> 
> - Original Message -
> 
> From: "Daniel Rohan"  
> To: "NANOG"  
> Sent: Friday, May 27, 2016 12:47:07 PM 
> Subject: Global/distributed IXP operators? 
> 
> If there are any operators working at distributed/global IXPs and wouldn't 
> mind having their brains picked regarding design questions, would you make 
> yourselves known to me (on or off-list is fine). 
> 
> Thanks, 
> 
> Dan 
> 

Re: Global/distributed IXP operators?

[Mike Hammett]

Could you define what you mean by a distributed\global IXP? There are plenty of 
IXPs, but there aren't really global IXPs, those just become networks. 




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



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


- Original Message -

From: "Daniel Rohan"  
To: "NANOG"  
Sent: Friday, May 27, 2016 12:47:07 PM 
Subject: Global/distributed IXP operators? 

If there are any operators working at distributed/global IXPs and wouldn't 
mind having their brains picked regarding design questions, would you make 
yourselves known to me (on or off-list is fine). 

Thanks, 

Dan