On 7/04/2013 19:46, Jared Mauch wrote:
I've continued to update my dataset originally posted about two weeks ago.
Please take a moment and review your CIDRs which may be running an open
resolver.
I've exposed one additional bit in the user-interface that may be helpful.
Some DNS servers wil
In message <51626cf9.1040...@phyxia.net>, Tom Laermans writes:
> On 7/04/2013 19:46, Jared Mauch wrote:
> > I've continued to update my dataset originally posted about two weeks ago.
> > Please take a moment
> and review your CIDRs which may be running an open resolver.
> >
> > I've exposed one
On Apr 7, 2013, at 23:27 , Tore Anderson wrote:
> * Owen DeLong
>
>> The need for CGN is not divorced from the failure to deploy IPv6, it
>> is caused by it.
>
> In a historical context, this is true enough. If we had accomplished
> ubiquitous IPv6 deployment ten years ago, there would be no I
On Mon Apr 08, 2013 at 01:41:34AM -0700, Owen DeLong wrote:
> Respectfully, I disagree. If the major content providers were to deploy
> IPv6 within the next 6 months (pretty achievable even now), then the
> need for CGN would at least be very much reduced, if not virtually
> eliminated.
Surely the
On 4/8/13 9:41 AM, Owen DeLong wrote:
> On Apr 7, 2013, at 23:27 , Tore Anderson wrote:
>
>> > * Owen DeLong
>> >
>>> >> The need for CGN is not divorced from the failure to deploy IPv6, it
>>> >> is caused by it.
>> >
>> > In a historical context, this is true enough. If we had accomplished
On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote:
Thankfully, MAP is not CGN. Correctly stated, unlike DS-Lite, MAP
doesn't require any CGN that causes the SP network to put up with the
NAT state. This means that all the subsequent issues of CGN/DS-Lite no
longer apply.
For me as an operator,
* Mikael Abrahamsson
> On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote:
>
>> MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled
>> access. MAP makes much more sense in any SP network having its
>> internet customers do IPv4 address sharing and embrace IPv6.
>
> It's still NAT.
* Owen DeLong
> Respectfully, I disagree. If the major content providers were to deploy
> IPv6 within the next 6 months (pretty achievable even now), then the
> need for CGN would at least be very much reduced, if not virtually
> eliminated.
I agree with "very much reduced". However, and IMHO, "v
On Mon, 8 Apr 2013, Tore Anderson wrote:
* Mikael Abrahamsson
On Mon, 8 Apr 2013, Rajiv Asati (rajiva) wrote:
MAP is all about stateless (NAT64 of Encapsulation) and IPv6 enabled
access. MAP makes much more sense in any SP network having its
internet customers do IPv4 address sharing and emb
The referral, including a referral to root can be quite large. Even larger than
answering a normal query. I have broken the data out for the purpose of letting
people identify the IPs that provide that.
Jared Mauch
On Apr 8, 2013, at 3:08 AM, Tom Laermans wrote:
> As far as I know, respondin
* Mikael Abrahamsson
> On Mon, 8 Apr 2013, Tore Anderson wrote:
>
>> AIUI, the standards-track flavour of MAP, MAP-E, is *not* NAT - it is
>> tunneling, pure encap/decap plus a clever way to calculate the outer
>> IPv6 src/dst addresses from the inner IPv4 addresses and ports. The
>> inner IPv4 p
* Tore Anderson
>> Does anyone see MAP-E being implemented on regular linecards or is it
>> going to be implemented on processor based dedicated hardware? At least
>> initially, I would just assume it's going to be some kind of CGN blade.
>
> No idea, sorry.
https://ripe65.ripe.net/presentations
On Mon, 8 Apr 2013, Tore Anderson wrote:
If this is to be called "translation", then any tunneling mechanism that
works by stacking layer-3 headers, including GRE, IPIP, ESP, and
proto-41, must be also called "translation".
Oki, my bad. I read
https://ripe65.ripe.net/presentations/91-townsle
* Tore Anderson
> The tunnel endpoint will 99.99% of cases be a CPE with a NAPT44
> component though, so there is some NAT involved in the overall solution,
> but it's pretty much the same as what we have in today's CPEs/HGWs. The
> only significant difference is that a MAP CPE must be prepared to
On 4/8/2013 7:20 AM, Tore Anderson wrote:
BTW. It is AIUI quite possible with MAP to provision a "whole" IPv4
address or even a prefix to the subscriber, thus also taking away the
need for [srcport-restricted] NAPT44 in the CPE.
The problem is NAPT44 in the CPE isn't enough. We are reaching the
> I understand why MAP-E is not translation now.
so far, the sexiest implementation of statless a+p to date.
randy
In a message written on Mon, Apr 08, 2013 at 01:41:34AM -0700, Owen DeLong
wrote:
> Respectfully, I disagree. If the major content providers were to deploy
> IPv6 within the next 6 months (pretty achievable even now), then the
> need for CGN would at least be very much reduced, if not virtually
>
On 4/8/13 7:23 AM, Jack Bates wrote:
On 4/8/2013 7:20 AM, Tore Anderson wrote:
BTW. It is AIUI quite possible with MAP to provision a "whole" IPv4
address or even a prefix to the subscriber, thus also taking away the
need for [srcport-restricted] NAPT44 in the CPE.
The problem is NAPT44 in the
On 4/8/2013 9:58 AM, joel jaeggli wrote:
That happened a long time ago. I realize the people like to think of
wireless providers as different, they really aren't. A big chuck of
our mobile gaming customers come to us via carrier operated nat
translators. Some of them now come to us via ipv6, mo
Indeed MAP-E requires CPE replacement/upgrade cost.
But I would like to share JANOG Softwire WG Activity.
http://conference.apnic.net/__data/assets/pdf_file/0005/58856/apnic35-janog-softwire_1361559276.pdf
MAP-E already supported by 6 vendors,7 implementations.
It includes 2 open source(OpenWRT an
Can anyone from Verizon comment on what IP space that's being used for
this? Or perhaps what the rDNS mask will look like?
>From an abuse perspective, knowing that an IP is being used for this can
make the difference between traffic looking like abuse and traffic
looking like multiple legitimate us
> CGN-like box. Yes, it's stateless. Doesn't matter, I still need to flow
> traffic through a dedicated box because MAP won't be implemented in my
> regular routers (if you know otherwise, please speak up).
Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
routers that I kno
On Mon, Apr 8, 2013 at 2:19 PM, Rajiv Asati (rajiva) wrote:
> Yes, MAP (T-Translation or E-Encap mode) is implemented on two regular
> routers that I know of - ASR9K and ASR1K. Without that, you are right that
> MAP wouldn't have been as beneficial as claimed.
>
glad it's cross platform... is it
Tore is spot on. With MAP, you can use your regular routers, whether it is
the Encap mode or Translation mode.
One can decide between Encap mode and Translation mode of MAP per his/her
environment/requirements. I do find -T mode preferable since it requires
no changes to the transparent caching i
Sam,
> What may make 'much more sense' in one network, doesn't necessarily make
> as much since in another network. As I understand it, MAP requires at
> least a software change on existing CPE, if not wholesale CPE change.
> Some providers may prefer to implement CGN instead if the capital outlay
Like you, I would like to be optimistic about many v4-only apps and
v4-only devices becoming dual-stack sooner than later.
But knowing that a significant (50%+) of android devices may not support
IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over
the weekend) being v4-only)
Jack,
I am assuming that you meant MAP, when you wrote MAPS.
> The larger issue I think with MAP is CPE support requirements. There are
> ISP layouts that use bridging instead of CPE routers (which was a long
> term design to support IPv6 without CPE replacements years later). CGN
> will handle t
Chris,
UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
encumbered?
If so, the answer is Yes. v6 addressing doesn't need to change to
accommodate this IPv4 A+P encoding.
Cheers,
Rajiv
-Original Message-
From: Christopher Morrow
Date: Monday, April 8, 2013 2:28 PM
To:
I think he means patent encumbered.
On Mon, Apr 08, 2013 at 07:13:11PM +, Rajiv Asati (rajiva) wrote:
> Chris,
>
> UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
> encumbered?
>
> If so, the answer is Yes. v6 addressing doesn't need to change to
> accommodate this IPv4 A+P
Oh, it certainly is (per the IETF IPR rules).
Thanks for the clarity, Chuck.
Cheers,
Rajiv
-Original Message-
From: Chuck Anderson
Date: Monday, April 8, 2013 3:18 PM
To: Rajiv Asati
Cc: Christopher Morrow , nanog list
Subject: Re: Verizon DSL moving to CGN
>I think he means patent e
Tore,
> I haven't tested, but I believe that if you were to hook up a standard
> Linux box to a ISP that provides /32 or shorter over MAP, you don't
Yes, indeed.
In fact, almost all of the MAP CE implementations (that I am aware of) are
open source/linux based -
http://enog.jp/~masakazu/vyatt
On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva) wrote:
> Oh, it certainly is (per the IETF IPR rules).
>
>
which rfcs? I can find a draft in softwire:
http://tools.ietf.org/html/draft-mdt-softwire-map-translation-01
and a reference to this in wikipedia:
http://en.wikipedia.org/wiki/IPv6
http://datatracker.ietf.org/ipr/search/?option=document_search&id_document_tag=draft-ietf-softwire-map
http://datatracker.ietf.org/doc/draft-ietf-softwire-map/?include_text=1
On Mon, Apr 08, 2013 at 03:41:54PM -0400, Christopher Morrow wrote:
> On Mon, Apr 8, 2013 at 3:21 PM, Rajiv Asati (rajiva)
Chris,
That's an incorrect draft pointer. Here is the correct one -
http://tools.ietf.org/html/draft-ietf-softwire-map
tools.ietf.org/html/draft-ietf-softwire-map-t
http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp
And no, Cisco has no IPR on MAP wrt the above drafts.
Cheers,
Rajiv
PS: P
In what sense do you mean that? The end-user IPv6 prefix certainly ties
IPv4 and IPv6 together, hence the interest in the Light-Weight IPv4 over
IPv6 alternative.
Tom
On 08/04/2013 3:13 PM, Rajiv Asati (rajiva) wrote:
Chris,
UmmmŠ you mean the IPv6 and IPv4 inter-dependency when you say IP
e
Hi all
Do you know any opensource program bandwidthgraph by ipaddess?
Thank you
On Mon, Apr 8, 2013 at 3:48 PM, Rajiv Asati (rajiva) wrote:
> Chris,
>
> That's an incorrect draft pointer. Here is the correct one -
>
> http://tools.ietf.org/html/draft-ietf-softwire-map
> tools.ietf.org/html/draft-ietf-softwire-map-t
> http://tools.ietf.org/html/draft-ietf-softwire-map-dhcp
>
>
Maybe http://en.wikipedia.org/wiki/Cacti_(software) would do what you want.
www: http://www.cacti.net/index.php
On Mon, Apr 8, 2013 at 3:51 PM, Deric Kwok wrote:
> Hi all
>
> Do you know any opensource program bandwidthgraph by ipaddess?
>
> Thank you
--
~ Andrew "lathama" Latham lath...@g
Ntop has my vote. Nprobe is a great bolt on for sans NetFlow environments.
Sent from my T-Mobile 4G LTE Device
Original message
From: Andrew Latham
Date: 04/08/2013 1:07 PM (GMT-08:00)
To: Deric Kwok
Cc: nanog list
Subject: Re: need help about free bandwidth graph program
I'm not sure of your specific application, but it sounds to me like
netflow/sflow exports would be the most scalable way to do this.
For small applications, ntop or bandwidthd can do this.
http://www.ntop.org/products/ntop/
http://bandwidthd.sourceforge.net/
Cheers,
jof
On Mon, Apr 8, 2013 at 12
Once upon a time, Rajiv Asati (rajiva) said:
> But knowing that a significant (50%+) of android devices may not support
> IPv6 (just like my brand new Samsung Galaxy 7'' tablet (just bought over
> the weekend) being v4-only) and may not be upgraded by their users to the
> right software, and that
This is to announce the BGP Secure Router Extension (BGP-SRx) Version 0.3
Prototype Implementation.
This release includes extensive performance and robustness improvements,
multi router support, re-design/re-write of the Quagga integration,
and many bug fixes.
BGP-SRx is an open source reference
On 2013-04-08, Andrew Latham sent:
> Maybe http://en.wikipedia.org/wiki/Cacti_(software) would do what you want.
>
> www: http://www.cacti.net/index.php
If we're talking SNMP counters, Observium might be worth a look.
http://www.observium.org/
--
Chip Marshall
http://2bithacker.net/
pgp19w
Do you know any opensource program bandwidthgraph by ipaddess?
What are you trying to accomplish?
sam
If you can export netflow you can use the FlowViewer / flow-tools / SiLK
open-source toolset. It can track bandwidth over time according to any
filter you provide it, including IP address. User interface includes an
updating dashboard.
http://sourceforge.net/projects/flowviewer
Joe
From:
We got this modem and router all in one box from Comcast directly. And by the
way, home use routers don't assign 10.0.0.0 numbers.
Joe
Sent from my iPhone
On Apr 7, 2013, at 9:11 PM, "Rajiv Asati (rajiva)" wrote:
> Nope. Comcast is not using any CGN, as much as I know.
>
> Is your MacBook di
Chris,
Your points are well taken.
Cheers,
Rajiv
-Original Message-
From: Christopher Morrow
Date: Monday, April 8, 2013 3:57 PM
To: Rajiv Asati
Cc: Chuck Anderson , nanog list
Subject: Re: Verizon DSL moving to CGN
>
>
>
>On Mon, Apr 8, 2013 at 3:48 PM, Rajiv Asati (rajiva)
> wrote
- Original Message -
> From: "Huasong Zhou"
> We got this modem and router all in one box from Comcast directly. And
> by the way, home use routers don't assign 10.0.0.0 numbers.
I have seen consumer NAT routers assign addresses in all three RFC1918
blocks, though I couldn't cite particu
On Apr 8, 2013, at 07:58 , joel jaeggli wrote:
> On 4/8/13 7:23 AM, Jack Bates wrote:
>> On 4/8/2013 7:20 AM, Tore Anderson wrote:
>>> BTW. It is AIUI quite possible with MAP to provision a "whole" IPv4
>>> address or even a prefix to the subscriber, thus also taking away the
>>> need for [srcpo
I think what that screenshot is saying is that after you deploy MAP,
then if you stop using it the IPv6 addresses don't need to change. I
would assume you're not saying that you can take your IPv6 addresses as
you find them and interpret them as MAP End-user prefixes.
Tom
On 08/04/2013 5:38 P
On Apr 8, 2013, at 11:54 , Rajiv Asati (rajiva) wrote:
>
> Like you, I would like to be optimistic about many v4-only apps and
> v4-only devices becoming dual-stack sooner than later.
>
> But knowing that a significant (50%+) of android devices may not support
> IPv6 (just like my brand new Sa
On Apr 7, 2013, at 18:45 , Huasong Zhou wrote:
> We got this modem and router all in one box from Comcast directly. And by the
> way, home use routers don't assign 10.0.0.0 numbers.
>
Some do.
Owen
> Joe
>
> Sent from my iPhone
>
> On Apr 7, 2013, at 9:11 PM, "Rajiv Asati (rajiva)" wrote
On 4/8/13 5:55 PM, Owen DeLong wrote:
>
> On Apr 7, 2013, at 18:45 , Huasong Zhou wrote:
>
>> We got this modem and router all in one box from Comcast directly. And by
>> the way, home use routers don't assign 10.0.0.0 numbers.
>>
>
> Some do.
>
AT&T U-verse used to have 10.0.0.0/8 as an opt
Hi Tom,
The key take-away is that MAP doesn't _necessarily_ require IPv6 prefix to
be constructed in a special way (so as to encode the IPv4 address inside
it).
Please see more inline,
> I think what that screenshot is saying is that after you deploy MAP,
> then if you stop using it the IPv6 a
I agree. Apple does it really well, no doubt about it. This is because
they control both the software and hardware.
Google/Android çan not do it well enough, since the Android OS version
compatibility with the hardware is somewhat dictated by the hardware
manufacturer. This isn't always helpful. :
On Apr 8, 2013, at 20:23 , "Rajiv Asati (rajiva)" wrote:
> I agree. Apple does it really well, no doubt about it. This is because
> they control both the software and hardware.
>
> Google/Android çan not do it well enough, since the Android OS version
> compatibility with the hardware is somewh
On Mon, Apr 8, 2013 at 11:23 PM, Rajiv Asati (rajiva) wrote:
> For ex, there are numerous android apps that are not supported
> on many android devices. :=(
>
I think this is actually up to the developer of the APP not the hardware
nor OS manufacturer.
> I don't doubt that dual-stack home networks will be with us for a long
>time.
> What won't be with us for very long is routing IPv4 across service
>providers.
> It can't. It will become far too expensive to do so. The economics
>aren't going
> to work much past about 5 years, maybe 10 if we're r
58 matches
Mail list logo
