Re: Mx204 alternative

[Saku Ytti]

On Sat, 10 Aug 2019 at 00:22, Brandon Martin  wrote:

> Yes, yes they will.  I've seen some distributor pricing and, while not
> officially under NDA, I will not mention it directly.  Suffice to say
> you should demand at least 40-50% off list from your vendor to start with.

You get better price from newegg for CSCO gear.

-- 
  ++ytti

Re: User Unknown (WAS: really amazon?)

[Stephen Satchell]

On 8/9/19 4:03 PM, Matthew Petach wrote:
> ...apparently Amazon has become a public utility
> now?
> 
> I look forward with bemusement to the PUC
> tariff filings for AWS pricing.  ^_^;;

Don't scoff too hard.  How do you think that telephone service became a
utility?  Utilities didn't grow on trees, they became utilities when
some bureaucrats convinced legislators to "promote" successful service
providers to utility status.  Especially when such providers are
providing a service as a monopoly.  Particularly a "natural" monopoly.
AWS has competitors,  but if the number of providers remains small (like
fingers of one hand) the politicians wil step in.

And it wouldn't be the PUC, as Amazon is a company national in scope.
It would be something like the FCC.  Public Utility Commissions are at
the local (usually county) or state level.

Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

[Ronald F. Guilmette]

In message 
Ross Tajvar  wrote:

>First he thought that a /17 got stolen (by creating a company with the same
>name as the original, now-defunct owner), but he then said he was wrong and
>actually it either 1) got transferred against ARIN policy or 2) was made to
>look like it was transferred by altering the whois data.

Yes.  What he said.

Although he left out the imporant detail that the whole thing appears to
be just a smokescreen cover for a large spamming operation, which apparently
targets primarily the Japanese market and which appears to have been ongoing
since at least 2004:

https://yomi.tokyo/agate/toki/bouhan/1103682730/1-/a

Regards,
rfg

Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

[Niels Bakker]

* r...@tristatelogic.com (Ronald F. Guilmette) [Sat 10 Aug 2019, 02:26 CEST]:
As far as I am aware, no RIR makes any effort whatsoever to vet 
changes to WHOIS records, either for IP blocks or ASNs or ORG 
records.


This is hilarious.  You should hear the whining from any EU-based 
operator who has to implement the transfer of RIPE NCC resources in 
a corporate acquisition.


I recently was involved with one of those and the amount of due 
diligence required by the RIPE NCC was pretty intense.  If I were at 
an RIR I'd be insulted by your claim of "no... effort whatsoever".



-- Niels.

Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

[Ross Tajvar]

First he thought that a /17 got stolen (by creating a company with the same
name as the original, now-defunct owner), but he then said he was wrong and
actually it either 1) got transferred against ARIN policy or 2) was made to
look like it was transferred by altering the whois data.

On Fri, Aug 9, 2019, 4:47 PM Töma Gavrichenkov  wrote:

> Peace,
>
> On Thu, Aug 8, 2019 at 10:54 PM Ronald F. Guilmette
>  wrote:
> > Corporate identity theft is a simple ploy which may be used to illicitly
> > obtain valuable IPv4 address space.  Actual use of this fradulent ploy
> > was first described publicly in April, 2008 (https://wapo.st/2YLEhlZ).
>
> nostromo:tmp ximaera$ wc guilmette_combined.mbox
>  2492122   13695 guilmette_combined.mbox
> nostromo:tmp ximaera$
>
> I wish I had enough spare time to read this.
>
> May we have a tl;dr version of this?
>
> --
> Töma
>

Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

[Ronald F. Guilmette]

In message , Brandon Price  wrote:

>
>
> 1) On or about 02-17-2010 HHSI, Inc. (California) transfered the
>registration of the 216.179.128.0/17 block from itself to the
>2009 vintage Delaware entity Azuki, LLC.  If this is what happened,
>then it is likely that the transfer was performed in violation
>of the applicable ARIN trasfer policy that was in force at the time.
>(Azuki, LLC did not simply buy-out HHSI, Inc., lock, stock, and
>barrel in 2010.  California records show that HHSI, Inc. continued
>to be an active California corporation until at least 02/12/2014,
>and probably well beyond that date.)
>
>
>The Arin policy in affect at the time of the transfer would absolutely allow
>this as an 8.2 mergers and acquisitions sale. There is no policy requirement
>for a "lock, stock, and barrel" buy-out as you say.
>
>>From the 2010.1 version published 13 JAN 2010, ref: https://www.arin.net/va=
>ult/policy/archive/nrpm_20100113.pdf
>
>
>"ARIN will consider requests for the transfer of number resources
>in the case of mergers and acquisitions upon receipt of
>evidence that the new entity has acquired the assets which
>had, as of the date of the acquisition or proposed
>reorganization, justified the current entity's use of the number
>resource. Examples of assets that justify use of the number
>resource include, but are not limited to:
>* Existing customer base
>* Qualified hardware inventory"
>
>So they bought the customers and routers that were using that /17. What's
>the big deal?

Firstly, there is no clear evidence that I am aware of that there are any
"customers" per se in this case.  Spamhaus has, in effect, judged the
entire 216.179.128.0/17 block as being just one big spamming operation,
and I personally have no reason at this instant to take issue with that
judgement.  (Please note also that a generally reliable source informs
me that Spamhaus has had this SBL listing for the entire 216.179.128.0/17
block active and in place since circa 2010-03-02, i.e. a full 9 years now.)

So anyway, in this case we are really only talking about equipment and not
"customers" per se.  If I am wrong about that, please post the evidence.

Second and more to the point, I think that you and I have dramatically
different understandings of the plain meanings of the terms "merger" and
"aquisition".

The evidence indicates that HHSI, Inc. neither merged with nor was aquired
by Azuki, LLC.  Rather, HHSI continued to have, and to actively maintain
its own separate legal existance through at least 2014... several years
*after* the moment in time, on or about 02-17-2010, when the -apparent-
ownership of the 216.179.128.0/17 block (going by the WHOIS records)
somehow magically passed from HHSI, Inc. to Azuki, LLC.

It is not my understanding of mergers and/or aquisitions that the merged
(or acquired) entity continues to have and maintain a separate legal
existance from the other merged (or acquiring) entity following the
merger or acquisition.  You, it seems, may have a different conception.

Theoretically, HHSI, Inc may have been acquired by Azuki, LLC and may have
then become a wholly owned subsidiary of Azuki, LLC.  This would explain
it's continued, simultaneous, and parallel legal existance in the years
2010 through 2014, along with Azuki, LLC.  But even if this rather remote
possibility applied, it would still not serve to explain the apparent
2010 transfer of the 216.179.128.0/17 block from the wholly owned subsidary
to the parent entity.  Why would such a transfer be either necessary or
even desirable?  And how would such a transfer comport with the ARIN
transfer regulations in place at the time?  Those regulations, as you
have quoted them, DO NOT obviously sanction transfers from subsidiaries
to parent entities in cases where both survive as separate legal entities.
And it is not even in the least bit clear that there even was any such
parent/subsididiary relationship between these two corporate entities at
the time of the transfer.

But in answer to your larger question, "What's the big deal?", the answer
is that -all- WHOIS records for -all- IP address blocks adminstered by
-all- RIRs are fundementally unvetted and thus untrustworthy.  This one
case is a clear and blatant example of that fundemental problem with the
way all RIRs are behaving.

As far as I am aware, no RIR makes any effort whatsoever to vet changes
to WHOIS records, either for IP blocks or ASNs or ORG records.  (And this
fact was abundantly evident in the Micfo fraud case, where the man behind
that fiddled the majority of the street address and other contact information
appearing in the public-facing WHOIS records for the blocks assigned to his
various phony baloney shell companies in a now-obvious attempt to mislead
both the public and also anti-abuse investigators.)

Someday soon, because of policies in place at all of the RIRs, you're
going to get some spam, or a hack attempt from a 

Re: User Unknown (WAS: really amazon?)

[Matthew Petach]

On Mon, Aug 5, 2019 at 2:16 AM Scott Christopher  wrote:

>
>
[...]

> It's not about $BIGCORP having lots of corporate lawyers imposing its will
> on the small guys - it's about Amazon's role as a public utility, upon
> which many many many important things depend.
>
> S.C.
>
>
I must have missed the news amidst all the
interest rate changes and tariff tweets...

...apparently Amazon has become a public utility
now?

I look forward with bemusement to the PUC
tariff filings for AWS pricing.  ^_^;;

 Matt

Re: Mx204 alternative

[Aaron]

On 8/9/2019 4:19 PM, Brandon Martin wrote:

On 8/9/19 1:23 PM, Aaron wrote:

We've gotten 5.7M in there with compression.


Out of curiosity, what are you doing that has 5.7M routes in a single 
routing area?  That's a lot of edge routes, tons of VRFs, or something.


They were generated just for testing.



Push them and they will get very aggressive on price.  VERY aggressive. 


Yes, yes they will.  I've seen some distributor pricing and, while not 
officially under NDA, I will not mention it directly.  Suffice to say 
you should demand at least 40-50% off list from your vendor to start 
with.




I don't believe I'm under NDA either but all I'll say is that if you 
push, 40-50% isn't even close to what they'll do.

Re: Mx204 alternative

[Brandon Martin]

On 8/9/19 1:23 PM, Aaron wrote:

We've gotten 5.7M in there with compression.


Out of curiosity, what are you doing that has 5.7M routes in a single 
routing area?  That's a lot of edge routes, tons of VRFs, or something.


Push them and they will get very aggressive on price.  VERY aggressive. 


Yes, yes they will.  I've seen some distributor pricing and, while not 
officially under NDA, I will not mention it directly.  Suffice to say 
you should demand at least 40-50% off list from your vendor to start with.


--
Brandon Martin

Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

[Töma Gavrichenkov]

Peace,

On Thu, Aug 8, 2019 at 10:54 PM Ronald F. Guilmette
 wrote:
> Corporate identity theft is a simple ploy which may be used to illicitly
> obtain valuable IPv4 address space.  Actual use of this fradulent ploy
> was first described publicly in April, 2008 (https://wapo.st/2YLEhlZ).

nostromo:tmp ximaera$ wc guilmette_combined.mbox
 2492122   13695 guilmette_combined.mbox
nostromo:tmp ximaera$

I wish I had enough spare time to read this.

May we have a tl;dr version of this?

--
Töma

Re: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

[Ronald F. Guilmette]

Further investigation of this case obliges me to post the following
correction and retraction.

Additional evidence now strongly suggests that the 216.179.128.0/17
IP address block has NOT been "stolen" as I had suggested yesterday.
I simply mis-read the ARIN historical registration ("WhoWas") data
with repect to this block.

In fact, the ARIN historical "WhoWas" registration data for this
block indicates that when the block was first assigned, by ARIN...
which the historical WhoWas records show as occuring on 06-24-2002...
the block was assigned to a Southern California company named HHSI, Inc.

Records available on the California Secretary of State's web site
indicate that this company was first registered with the State of
California 02/11/2002.  Oddly, some seven years would pass after the
registration of this California corporation before any documents
were filed with California which would designate any officers of
the company.  On 03/02/2009 however a filing was made indicating
the President of the company was a gentleman named Koji Ban.
Additional corporate filings in subsequent years indicate that
both Mr. Ban and the company, HHSI, Inc. were located at 20 Arches,
Irvine, CA 92603.

On or about 02-17-2010 the public WHOIS record for the 216.179.128.0/17
block was changed so that instead of designating HHSI, Inc. (California)
as the block's registrant, the WHOIS record for the block would henceforth
say instead that the registrant of the block was the 2009 vintage
Delaware LLC called Azuki, LLC.

Unfortunately, we cannot read too much into this change that was made
to the block's public-facing WHOIS record.  Neither the new WHOIS info
nor even the old WHOIS info can be used to reliably infer who or what
is the legitimate registrant of the block at any point in time.  This
is because ARIN, like all of the other Regional Internet Registries,
allows registrants to put essentially any bovine excrement they desire
into their public-facing WHOIS records.  (And, it should be noted, the
man behind the recent large scale "Micfo" fraud apparently availed
himself of this exact opportunity far subterfuge, in spades.)

Regardless, the available records suggest that there are only two likely
possibilities in this case:

 1) On or about 02-17-2010 HHSI, Inc. (California) transfered the
registration of the 216.179.128.0/17 block from itself to the
2009 vintage Delaware entity Azuki, LLC.  If this is what happened,
then it is likely that the transfer was performed in violation
of the applicable ARIN trasfer policy that was in force at the time.
(Azuki, LLC did not simply buy-out HHSI, Inc., lock, stock, and
barrel in 2010.  California records show that HHSI, Inc. continued
to be an active California corporation until at least 02/12/2014,
and probably well beyond that date.)

 2) Alternatively, on or about 02-17-2010 HHSI, Inc. (California) simply
altered what would henceforth appear in the public-facing WHOIS
record for the the 216.179.128.0/17 block to make it appear... to
everyone except ARIN staff, who knew better... that the block was
now registered to Azuki, LLC in Delaware.

Only ARIN staff can tell us which of these possibilities actually applies.
But due to ARIN's strict adherence to contractual confidentiality with
respect to all of their resource holders, I do not anticipate that ARIN
will actually provide any clarity on this case anytime soon.

To summarize, either the block was transferred in 2010 in violation of
ARIN's own transfer policy or else the information that we have all been
looking at in this block's WHOIS record since 02-17-2010 is and has been
nothing other than a very deliberate and bald-faced lie.  There is no
third option.

Regardless of which of the two possible scenarios applies, it is a dead
certainty that the registration of the 216.179.128.0/17 block was indeed
transferred away from HHSI, Inc. at some point in time, and in a manner that
most probably did not comport with applicable ARIN transfer restrictions
in place at the time.  I say this without fear of contradiction because
the State of California currently lists HHSI, Inc. as "suspended".  Legally
speaking, it no longer exists.  It cannot therefore still be a valid
contractual counterparty, with ARIN, or with respect to the registration
of *any* ARIN-administered resources.

All of this ambiguity, and all of these crooked deception games are enabled
and materially aided and abetted by the disastrous interplay of two
longstanding policies that are and have been in force, for many many years,
both at ARIN an also at all of the other RIRs, namely:

   *)  Excessive anal retentiveness with respect to corporate confidentiality
   which deprives the public at large from even knowing even so much as
   the accurate and correct legal names of resource holders.

   *)  Policies which permit resource holders to place any arbit

Re: MAP-E

[Sander Steffann]

Hi Lee,

> Also but, would that be a Net Neutrality problem, charging less for a service 
> that has arguably worse access to Amazon, Reddit, Twitter, etc.?

Net neutrality as it is here in Europe usually is satisfied when no 
preferential treatment is given to a limited set of services (Netflix has 
higher priority than Amazon Prime etc). The European regulators don't seem to 
specify things in technical terms but in "Apps" and "Services". As long as you 
don't treat those unfairly you should be fine. When you tell a regulator "yes, 
the new standard works better than the old standard, and we encourage everybody 
to support that new standard (which is a recognised best practice)" then there 
shouldn't be any problem.

Cheers :)
Sander



signature.asc
Description: Message signed with OpenPGP

Re: Mx204 alternative

[Forrest Christian (List Account)]

I'll inject two of my own questions here...

Assuming one can find a used mx204, what is the official juniper licensing
policy?

It looks like I'm going to be replacing our core cisco in the not
too distant future due to running out of fib entries, and am looking at
options.   Am I reading the specs correctly that the mx204 should handle
typical internet routing table growth for the next few years?

On Wed, Aug 7, 2019, 9:47 PM Randy Carpenter  wrote:

> If you don't require redundant routing engines, there is nothing from
> Juniper that will cost less and have the capacity you require. In fact,
> there really aren't any cheaper MX options at all, other than the
> kneecapped MX80 and MX104 variants. MX204 is really a nice box. I only wish
> they had a redundant version.
>
> Is price your only concern with the MX204? You might not need the full
> blown -R or -IR version, so the list price would only be ~$45K.
>
> I'm not too familiar with other vendors, so I'll leave that to others.
>
> thanks,
> -Randy
>
> - On Aug 7, 2019, at 11:02 PM, Mehmet Akcin  wrote:
>
> Greetings,
>
> I am looking for some suggestions on alternatives to mx204.
>
> Any recommendations on something more affordable which can handle full
> routing tables from two providers?
>
> Prefer Juniper but happy to look alternatives.
> Min 6-8 10G ports are required
> 1G support required
>
> Thanks in advance!
>
> Mehmet
> --
> Mehmet
> +1-424-298-1903
>
>

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, SANOG, PacNOG, SAFNOG
TZNOG, MENOG, BJNOG, SDNOG, CMNOG, LACNOG 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 10 Aug, 2019

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

Analysis Summary


BGP routing table entries examined:  767230
Prefixes after maximum aggregation (per Origin AS):  295222
Deaggregation factor:  2.60
Unique aggregates announced (without unneeded subnets):  369331
Total ASes present in the Internet Routing Table: 65109
Prefixes per ASN: 11.78
Origin-only ASes present in the Internet Routing Table:   55990
Origin ASes announcing only one prefix:   23960
Transit ASes present in the Internet Routing Table:9119
Transit-only ASes present in the Internet Routing Table:277
Average AS path length visible in the Internet Routing Table:   4.5
Max AS path length visible:  42
Max AS path prepend of ASN ( 27978)  31
Prefixes from unregistered ASNs in the Routing Table:28
Number of instances of unregistered ASNs:28
Number of 32-bit ASNs allocated by the RIRs:  28163
Number of 32-bit ASNs visible in the Routing Table:   22999
Prefixes from 32-bit ASNs in the Routing Table:  104209
Number of bogon 32-bit ASNs visible in the Routing Table:15
Special use prefixes present in the Routing Table:0
Prefixes being announced from unallocated address space:319
Number of addresses announced to Internet:   2842564736
Equivalent to 169 /8s, 110 /16s and 24 /24s
Percentage of available address space announced:   76.8
Percentage of allocated address space announced:   76.8
Percentage of available address space allocated:  100.0
Percentage of address space in use by end-sites:   99.3
Total number of prefixes smaller than registry allocations:  256682

APNIC Region Analysis Summary
-

Prefixes being announced by APNIC Region ASes:   206978
Total APNIC prefixes after maximum aggregation:   61718
APNIC Deaggregation factor:3.35
Prefixes being announced from the APNIC address blocks:  202028
Unique aggregates announced from the APNIC address blocks:84218
APNIC Region origin ASes present in the Internet Routing Table:9953
APNIC Prefixes per ASN:   20.30
APNIC Region origin ASes announcing only one prefix:   2753
APNIC Region transit ASes present in the Internet Routing Table:   1486
Average APNIC Region AS path length visible:4.6
Max APNIC Region AS path length visible: 29
Number of APNIC region 32-bit ASNs visible in the Routing Table:   4951
Number of APNIC addresses announced to Internet:  771164416
Equivalent to 45 /8s, 247 /16s and 9 /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-141625
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:226878
Total ARIN prefixes after maximum aggregation:   106045
ARIN Deaggregation factor: 2.14
Prefixes being announced from the ARIN address blocks:   225722
Unique aggregates announced from the ARIN address blocks:107208
ARIN Region origin ASes present in the Internet Routing Table:18543
ARIN Prefixes per ASN:12.17
ARIN Region

Re: Mx204 alternative

[Aaron]

I would recommend the SLX9640.  12x 100G and 24x 1G/10G ports. 4 million 
routes in hardware without compression.  We've gotten 5.7M in there with 
compression.  Price point is super good.  Push them and they will get 
very aggressive on price.  VERY aggressive.


Aaron


On 8/7/2019 10:33 PM, Brandon Martin wrote:

On 8/7/19 11:02 PM, Mehmet Akcin wrote:

I am looking for some suggestions on alternatives to mx204.

Any recommendations on something more affordable which can handle 
full routing tables from two providers?


Prefer Juniper but happy to look alternatives.
Min 6-8 10G ports are required
1G support required


Extreme (ex Brocade) SLX9540 will do full tables from a couple 
providers in a local edge scenario with their "OptiScale" FIB 
optimization/route caching, but the whole FIB won't fit in hardware.  
Bandwidth is very generous (up to 48x10G + 6x100G), and prices are 
reasonable.  You wouldn't need any of the stupid port licenses, just 
the advanced feature license, so it should be about 25-40% more than 
an MX204 based on public pricing I've seen.  That would get you 24x10G 
+ 24x1G (the rest of the hardware is all there just locked out).


The SLX9650 will supposedly (if marketing and my SEs are to believed) 
do 4M IPv4 in hardware FIB, less if you want IPv6, too but still full 
tables of both with ample room for L2 MACs, next-hops, and MPLS. 
Bandwidth is, well, "Extreme" at I think 24x25G + 12x100G (25G 
breakout capable, all 25G also capable of 1G/10G).  Pricing is 
supposedly "about double" a 9540.


Be advised that the control plane SOFTWARE is NOT as mature as JunOS. 
It's being built up rapidly, but there's still a lot of stuff missing. 
I have not, so far, run into any of the weird glitches that I've seen 
on older Foundry/Brocade products, though, so that's good.  There's 
also no oddball restrictions about port provisioning like the MX204 
has. Control plane HARDWARE is well more than capable with something 
like 16GB (or maybe 32?) of RAM and a Xeon CPU.  There's actually a 
fully supported option for a guest VM for local analytics, SDN, etc. 
in remote scenarios.


If you just want to push packets, they're nice boxes.  If you want 
"high touch" service provider features, I think you may find them 
lacking. They're worth looking at, though, if only because of the 
price/performance ratio.


Arista has some similar boxes with similar caveats in terms of 
infantile software.


MX204 is a very nice pizza box router for service providers.  I'm not 
aware of anything quite like it in terms of having a mature control 
plane.  I like the JunOS config language better than Cisco-style that 
most other folks use.


--

Aaron Wendel
Chief Technical Officer
Wholesale Internet, Inc. (AS 32097)
(816)550-9030
http://www.wholesaleinternet.com

Re: MAP-E

[Lee Howard]

On 8/9/19 1:32 AM, Vincent Bernat wrote:

  ❦  8 août 2019 16:18 -04, Lee Howard :


NAT64. IPv6-only to users. DNS resolver given in provisioning
information is a DNS64 server. When it does a lookup but there's no
, it invents one based on the A record (e.g., 2001:db8:64::). The IPv6 prefix in the invented  is actually a NAT64
translator. Pro: no CPE support required, well understood. Con: No
support for IPv4-only stuff in the prem, breaks DNSSEC.

Is there a known deployment for a medium/large ISP?


Not a fixed/wireline ISP.

The "con" that consumers' game consoles, smart TVs, and IoT things won't 
work is a pretty big "con." I was working with a small ISP that was 
running out of IPv4 addresses, and they kept saying "NAT64." I warned 
them that while NAT64 would solve their runout problem, it would drive a 
lot of unhappy customer calls.


It would be interesting if someone offered a NAT64 service (maybe for a 
reduced price). Buyers could tell consumer electronics companies, "I 
can't use your device without IPv6." But qualifying the customer who 
would do that would be more expensive, I think, than just buying IPv4 
addresses. Also but, would that be a Net Neutrality problem, charging 
less for a service that has arguably worse access to Amazon, Reddit, 
Twitter, etc.?


Lee



Thanks.

RE: MAP-E

[Masanobu Kawashima]

Hi all,

> CPE support is the next big frontier in IPv6 deployment.

That’s why we discussed about the issue with Jordi and other vendors on APNIC 44
almost 2 years ago.
https://conference.apnic.net/44/program/schedule/#/day/6/bof-discussion-with-ipv6-ce-vendors

Following is my presentation at that time.
https://conference.apnic.net/44/assets/files/APCS549/IPv6-support-at-NEC-CEs.pdf

After that, we standardized RFC8585.
So, next step is implemeting transition technologies and deployment.

Please let me know if there’s opportunity to use transition technologies
we have minimum order quantity though, we may discuss about it.

Let’s cross the chasm together. :-)

Regards,
Masanobu


 NEC Platforms, Ltd.
 KAWASHIMA Masanobu
 kawashi...@vx.jp.nec.com
 https://www.necplatforms.co.jp/en/





> -Original Message-

> From: NANOG  On Behalf Of Lee Howard

> Sent: Friday, August 9, 2019 5:18 AM

> To: nanog@nanog.org

> Subject: Re: MAP-E

>

>

> On 8/2/19 11:39 AM, Jay Hanke wrote:

> > Is there a summary presentation someplace laying out the options that

> > are active in the wild with some deployment stats?

>

> I can't think of a public presentation off the top of my head that explains 
> how each major transition technology works,

> and the pros and cons of each. There must be one, but it's hard to cover the 
> major options in an hour.

>

> If you want to know who is using any given transition technology, there's 
> this crowd-sourced list:

>

> https://docs.google.com/spreadsheets/d/1ksOoWOaRdRyjZnjLSikHf4O5L1OUTNOO_7NK9vcVApc/edit#gid=0

>

> Very brief summary of options:

>

> NAT444. Your basic NAT, plus NAT again. You really need to deploy IPv6, too, 
> or all your traffic will go through a

> translator (everything else below assumes native IPv6 is deployed). State 
> information can get expensive. Well understood.

>

> Dual-stack Lite. CPE sends IPv4 traffic through an IPv6 tunnel

> (softwire) to a pre-configured DS-Lite box, which does NAT44. Works fine, 
> deployed at scale (see sheet above), but

> keeping state on lots of

> NAT44 can get expensive at scale.

>

> NAT64. IPv6-only to users. DNS resolver given in provisioning information is 
> a DNS64 server. When it does a lookup

> but there's no , it invents one based on the A record (e.g., 
> 2001:db8:64:: address>). The IPv6 prefix in the invented  is actually a NAT64

> translator. Pro: no CPE support required, well understood. Con: No support 
> for IPv4-only stuff in the prem, breaks

> DNSSEC.

>

> 464xlat. IPv6-only between CE and NAT64. Any IPv4 traffic the CPE receives, 
> it translates to IPv6 and forwards to

> a destination that's the

> NAT64 server, which translates again. Pro: widely deployed at scale on mobile 
> networks. Con: Very little CPE support

> in home routers.

>

> MAP-T, MAP-E. IPv6-only between CE and Border Relay (BR). CPE is provisioned 
> with an IPv4 address and a range of ports.

> It does basic NAT44, but only uses the reserved ports. Then it translates to 
> IPv6

> (MAP-T) or encapsulates in IPv6 (MAP-E) and forwards to the configured Border 
> Relay (BR), which changes it to IPv4.

> Pro: Stateless, very efficient. Con: Very little CPE support in home routers.

>

> Jordi is going to tell me there's plenty of support for 464xlat.

> However, you can't go into any old electronics store in North America and buy 
> a home gateway with support for 464xlat

> or MAP. You can't buy them directly from a vendor, unless you're large enough 
> to request a specific firmware build.

> Yes, you can get support from OpenWRT, but that's probably not how you want 
> your support team spending their time.

>

> CPE support is the next big frontier in IPv6 deployment.

>

> Lee

>

> >

> > On Fri, Aug 2, 2019 at 10:34 AM JORDI PALET MARTINEZ via NANOG

> > mailto:nanog@nanog.org>> wrote:

> >> I understand that, but the inconvenient is the fix allocation of ports per 
> >> client, and not all the clients use

> the same number of ports. Every option has good and bad things.

> >>

> >>

> >>

> >> MAP is less efficient in terms of maximizing the “use” of the existing 
> >> IPv4 addresses.

> >>

> >>

> >>

> >> https://datatracker.ietf.org/doc/draft-lmhp-v6ops-transition-comparis

> >> on/

> >>

> >>

> >>

> >>

> >>

> >> Regards,

> >>

> >> Jordi

> >>

> >> @jordipalet

> >>

> >>

> >>

> >>

> >>

> >>

> >>

> >> El 2/8/19 17:25, "NANOG en nombre de Baldur Norddahl" 
> >>  >> de

> baldur.nordd...@gmail.com>
>  escribió:

> >>

> >>

> >>

> >> Hi Jordi

> >>

> >>

> >>

> >> My alternative to MAP-E is plain old NAT 444 dual stack. I am trying to 
> >> avoid the expense and operative nightmare

> of having to run a redundant NAT server setup with thousands of users. MAP is 
> the onl

Re: BGP router question

[Dennis Lundström]

Data-sheet appear to say the following:

   - Routing entries: 128000

So No. You will not be able to fit a full table.

—Dennis


On Thu, Aug 8, 2019 at 17:39 Art Stephens  wrote:

> Hope this is not too off topic but can any one advise if a Dell S4048-ON
> can support full ebgp routes?
>
> --
> Arthur Stephens
> Senior Network Administrator
> Ptera Inc.
> PO Box 135
> 24001 E Mission Suite 50
> 
> Liberty Lake, WA 99019
> 
>
> 509-927-7837
> ptera.com |
> facebook.com/PteraInc | twitter.com/Ptera
>
>  -
> "This message may contain confidential and/or propriety information, and
> is intended for the person/entity to whom it was originally addressed.
> Any use by others is strictly prohibited. Please note that any views or
> opinions presented in this email are solely those of the author and are not
> intended to represent those of the company."
>

RE: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

[Kevin McCormick]

Thought you may find these connections with the 3500 South DuPont Hwy, Dover, 
DE, 19901 address interesting.

https://offshoreleaks.icij.org/nodes/14014038

Thank you,

Kevin McCormick

-Original Message-
From: NANOG  On Behalf Of Ronald F. Guilmette
Sent: Thursday, August 8, 2019 2:54 PM
To: nanog@nanog.org
Subject: Corporate Identity Theft: Azuki, LLC -- AS13389, 216.179.128.0/17

Corporate identity theft is a simple ploy which may be used to illicitly obtain 
valuable IPv4 address space.  Actual use of this fradulent ploy was first 
described publicly in April, 2008 (https://wapo.st/2YLEhlZ).

Quite simply, a party bent on undertaking this ploy may just search the 
publicly available IP block WHOIS records, looking for abandoned and unrouted 
IPv4 address blocks belonging to companies or organizations which no longer 
exist.  Upon finding any such, the thief may simply undertake to formally 
register, with relevant government authorities, a new corporate entity with the 
same or a very similar name as the now defunct entity that is still listed in 
the WHOIS records as the registrant of the coveted IPv4 address block(s).

Note that so-called "legacy" address blocks, i.e. those which were assigned 
prior to the formation of ARIN in early 1997, are especially prized by IPv4 
address thieves because such blocks may be less subject to effective control or 
regulation by Regional Internet Registries.

Publicly available evidence strongly suggests that a corporate identity theft 
has occurred with respect to a former Delaware corporate entity known as Azuki, 
LLC and also with respect to its valuable legacy IPv4 address block, 
216.179.128.0/17.

The corporate search function of the Delaware Secretary of State's web site may 
be used to obtain records relevant to corporate entities registered in Delaware:

https://icis.corp.delaware.gov/Ecorp/EntitySearch/NameSearch.aspx

At present, the Delaware SoS's web site indicates that there are or have been 
two different corporate entities, both named Azuki, LLC, that have been 
registered in the State of Delaware.  The file numbers for these entities are 
2810116 and 4751384.

The former entity was first registered in Delaware on or about 10/20/1997.
It's current operating status cannot be known without paying a fee.  My own 
personal speculation is that it most likely ceased operation well more than a 
decade ago.

The latter entity was registered in Delaware on or about 11/9/2009.

According to the current live ARIN WHOIS record for the 216.179.128.0/17 
address block (NET-216-179-128-0-1), this block was first allocated by ARIN to 
Azuki, LLC on or about 1999-01-07.  Quite obviously, this assignment must have 
been made by ARIN to the original 1997 Azuki, LLC because the one that was 
registered in Delaware in 2009 did not yet exist at that time.

Nontheless the mailing address currently present in the ARIN WHOIS record for 
the 216.179.128.0/17 IPv4 address block, and the one which is also present in 
the ARIN WHOIS record for the 2009 vintage ASN,
AS13389 (Azuki, LLC), i.e. 3500 South DuPont Hwy, Dover, DE, 19901, matches 
exactly with the address given in Delaware corporate records for the particular 
Azuki, LLC that was registered in Delaware in 2009.
(The corporate address that is still on file in Delaware for the original
1997 Azuki, LLC is located in a different Delaware city altogether.)

These evident inconsistancies, by themselves, are strongly indicative of a 
probable case of corporate identity theft.  Additional indicators are however 
also present in this case.

In particular, the contact email address for both the Azuki, LLC ASN
(AS13389) and the Azuki, LLC IPv4 address block (216.179.128.0/17), i.e.
tech_dep (at) azukinet.com, make reference to the azukinet.com domain which 
was, according to the relevant GoDaddy WHOIS record, registered anew on or 
about 2011-05-12, some twelve years -after- the original assignment, by ARIN, 
of the 216.179.128.0/17 block to Azuki, LLC.

The absence of evidence of the contnuous registration of this one and only 
contact domain name since the original 1999 assignment, by ARIN, of the 
216.179.128.0/17 address block also tends to support the theory that this 
valuable address block has been illicitly and perhaps illegally appropriated by 
some party or parties unknown, and specifically via the fradulent ruse of a 
corporate identity theft.  Quite simply, my theory is that following the demise 
of the original Azuki, LLC, sometime in the 2000s, some enterprising crook 
registered the domain name azukinet.com in order to successfully impersonate 
the actual and original Azuki, LLC, specifically when interacting with ARIN 
staff members.  This simple ruse appears to have worked successfully for its 
intended purpose.

Additionally, attempts to call the contact phone number for Azuki, LLC,
(+1-213-304-6809) as currently listed in both the relevant ASN and the relevant 
IP block WHOIS records, during normal

Re: Mx204 alternative

[davey]

One thought could be any of the virtual ones, vmx, nokia vsr, etc on lannerinc 
hardware.

Cheep scalable and has all the interface options 



Sent from my iPhone

> On 9 Aug 2019, at 2:50 am, Tom Hill  wrote:
> 
>> On 08/08/2019 04:02, Mehmet Akcin wrote:
>> 
>> I am looking for some suggestions on alternatives to mx204. 
>> 
>> Any recommendations on something more affordable which can handle full
>> routing tables from two providers?
>> 
>> Prefer Juniper but happy to look alternatives.
>> Min 6-8 10G ports are required
>> 1G support required
> 
> 
> No-one has mentioned it yet, so for completeness big C have the ASR 9901
> (not 9001) with traditional router bits in it.
> 
> A portion of the 10G ports on it are capable of 1/10G.
> 
> Regards,
> 
> -- 
> Tom

Re: MAP-E

[Lee Howard]

On 8/8/19 9:00 PM, Masataka Ohta wrote:

Lee Howard wrote:

MAP-T, MAP-E. IPv6-only between CE and Border Relay (BR). CPE is 
provisioned with an IPv4 address and a range of ports. It does basic 
NAT44, but only uses the reserved ports. Then it translates to IPv6 
(MAP-T) or encapsulates in IPv6 (MAP-E) and forwards to the 
configured Border Relay (BR), which changes it to IPv4. Pro: 
Stateless, very efficient. Con: Very little CPE support in home routers.


So, all we need is NAT44 CPE, which only uses a reserved block of ports,
which is (semi) statically configured by ISP operated gateway.


How would you route from the provider edge?

If CPE A has 192.0.2.15 port 1000-2999

and CPE B has 192.0.2.15 port 3000-4999,

how does your BRAS or CMTS or edge router know whether to forward a 
packet to A or B?


You could do policy routing or similarly do deep packet inspection, but 
you'd need a mechanism to provision that information into the provider 
edge router; you wouldn't manually configure match/set policy for each 
customer.



Pro: Stateless, very efficient, no IPv6 necessary Con: No current
CPE support.

As for protocol, assuming port mapping on UPnP gateway is statically
configured by ISPs not changable from CPE side, GetListOfPortMappings()
of UPnP should be useful for CPEs to know range of ports to be used
by them.


Do CPEs do this now, or is this another feature to ask vendors for?

Lee



    Masataka Ohta

Re: MAP-E

[Brandon Martin]

On 8/8/19 9:00 PM, Masataka Ohta wrote:

As for protocol, assuming port mapping on UPnP gateway is statically
configured by ISPs not changable from CPE side, GetListOfPortMappings()
of UPnP should be useful for CPEs to know range of ports to be used
by them.


There's actually a DHCPv6 option for specifying the port information in 
addition to the transition tech in use.  I had previously inquired to 
NANOG about it, though I don't recall the specifics at this time.


In theory, with that in place, a user could go buy any ol' RG style 
router with support for the proper transition tech and just plug and 
play like they currently do with native dual-stack networks.

--
Brandon Martin

Re: Mx204 alternative

[Radu-Adrian Feurdean]

On Fri, Aug 9, 2019, at 08:13, Saku Ytti wrote:
> On Fri, 9 Aug 2019 at 09:09, Radu-Adrian Feurdean
>  wrote:
> 
> > On Thu, Aug 8, 2019, at 16:51, Tom Hill wrote:
> > > No-one has mentioned it yet, so for completeness big C have the ASR 9901
> >
> > Weren't we talking about "decently priced" ?
> 
> ASR9901 and MX204 being wildly differently priced is market
> inefficiency. It's difficult for me to see, how CSCO could justify the
> premium for any volume order. Either sell at market or lose sale.

The 2 boxes not having exactly the same port count and features(9901 can do - 
or is suppose to be able to do - subscriber stuff - IPoE,PTA,LAC), this 
explains the difference. Add the fact that Cisco has customers that buy "Cisco 
and nothing else".

And not everybody buys "enough" in order to get acceptable volume discounts.

> Also it will never run eXR. I have no information, but I think it's
> reasonable to suspect the OS not being sold may receive decreasing
> amount of NRE. I wouldn't certainly spend my time writing code for
> product I'm not selling.

Agreed. 

Re: BGP router question

[Tore Anderson]

* Art Stephens

> Hope this is not too off topic but can any one advise if a Dell S4048-ON can 
> support full ebgp routes?

As others have mentioned, you won't be able to program them all in the 
forwarding plane, but the control plane can receive them all just fine (it has 
more than enough RAM).

If your use case allows for accepting a default route from your IP transit 
providers along with the full feed, you can easily implement control plane 
policies that ensure that what gets installed to the forwarding plane is only 
the routes to the destinations you care the most about + the default route to 
cover the long tail of traffic to the rest of the world.

You can use the S4048-ON (or any equivalent layer-3 capable data centre switch) 
as a border router this way, at a fraction of what a big C or J router would 
cost you. We started doing this a few years back and we're not regretting it.

https://labs.spotify.com/2016/01/27/sdn-internet-router-part-2/
https://www.redpill-linpro.com/sysadvent/2016/12/09/slimming-routing-table.html

Tore