- Test - lists.nanog.org

Broadvoice Cluefull?
by Jay Stewart 20 Sep '06

20 Sep '06

Sorry to send this here, (really, really, sorry), but does anybody know any cluefull techie or CSR types at BroadVoice? I've pretty much tried everything I can to get through to them but after 90 minutes on hold, and after having a working account munged by the CSR to the point where it's no longer working, and being hungup on twice (after 30 minute holds) due to incompetant CSRs, I'm in "homicidal rage" mode about now, and really need to get through to someone who can fix a problem. Thanks in advance. And now back your your regularly scheduled discussion of IP ownerships rights, etc. . . . Jay Stewart Zhonka Broadband P.S. (to all service providing companies): If you're going to have to keep people on hold for 30 minutes or more EACH time they call, please spring a few bucks for some royalty free music or poetry or something (we use Robert Burns read by noted artist John Cairney), but PLEASE, PLEASE don't use an insipid two minute piano loop, ugh. . .

1 0

Cisco Security Advisory: Cisco Guard enables Cross Site Scripting
by Cisco Systems Product Security Incident Response Team 20 Sep '06

20 Sep '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Cisco Security Advisory: Cisco Guard Enables Cross Site Scripting Advisory ID: cisco-sa-20060920-guardxss http://www.cisco.com/warp/public/707/cisco-sa-20060920-guardxss.shtml Revision 1.0 For Public Release 2006 September 20 1600 UTC (GMT) +-------------------------------------------------------------------- Contents ======== Summary Affected Products Details Impact Software Version and Fixes Workarounds Obtaining Fixed Software Exploitation and Public Announcements Status of this Notice: FINAL Distribution Revision History Cisco Security Procedures +--------------------------------------------------------------------- Summary ======= A vulnerability in the Cisco Guard may enable an attacker to send a web browser client to a malicious website with the use of Cross Site Scripting (XSS) when the Guard is providing anti-spoofing services between the web browser client and a webserver. The attacker may exploit this by providing a malicious URL for the web browser client to go to, often in email, followed off of a malicious website, or in an instant message. This issue may occur even if the protected website does not allow XSS. A software upgrade is required to fix this vulnerability. There is a workaround available to mitigate the effects of the vulnerability. This advisory is available at http://www.cisco.com/warp/public/707/cisco-sa-20060920-guardxss.shtml. Affected Products ================= The Cisco Guard is the only affected product. Details are available below. Vulnerable Products +------------------ The following Cisco products are vulnerable. * Cisco Guard Appliance (Software Version 3.X) * Cisco Guard Blade (Software Version 4.X) * Cisco Guard Appliance [Software Version 5.0(3)] * Cisco Guard Appliance [Software Version 5.1(5)] Products Confirmed Not Vulnerable +-------------------------------- No other Cisco products have been found to be vulnerable. There are three ways to determine the software version that your Cisco Guard DDoS mitigation appliance is running. An example of each method is shown here: * Virtual terminal or local serial console connection To determine the software version number through the local serial console use a serial cable and a terminal emulation program to connect to the appliance. Once you are connected, press the Enter key of your terminal and the Guard will present, without even logging in, the version of the software running on the devices: Cisco Guard Version 3.1(0.12) GUARD login: In this example the Cisco Guard is running software version 3.1. For a virtual terminal, the procedure is the same except that no serial cable or terminal emulation program is needed (a standard keyboard and monitor are directly connected to the appliance). * Remote Secure Shell (SSH) connection To obtain the software version number through a SSH session, use a SSH client to log in to the Cisco Guard and issue the show version command-line interface (CLI) command. prompt$ ssh admin(a)guard.example.com admin(a)guard.example.com's password: Last login: Wed Nov 24 22:45:53 on ttyS0 admin@GUARD#show version Copyright (c) 2000-2004 Cisco Systems, Inc. All rights reserved. Software License Agreement [...] Cisco Anomaly Guard Release: 3.1(0.12) Date: 2004/10/27 19:58:14 GUARD uptime is 3 weeks, 3 days, 17 hours, 53 minutes System Serial Number: XXXXXXX In this example, the Cisco Traffic Anomaly Guard is running software version 3.1. * Remote secure web session To obtain the software version that Cisco Guard is running through a secure web interface, open the URL https://IP address of your Guard/ in a web browser, log in, and then click on the About link located on the top right section of the browser window. Details ======= The Cisco Guard DDoS Mitigation Appliance is a distributed denial-of-service (DDoS) protection system. Malicious DOS traffic is identified with a Cisco Detector and diverted to the Guard for attack mitigation. Under normal circumstances, the Guard plays no role in valid traffic; it is specifically designed to deal with large volumes of invalid traffic. Cross Site Scripting (XSS) is an attack where a user follows a link that contains an embedded script. The link often looks valid, and sends the user to a valid site. The recipient website does not contain the link that is sent and sends a meta-refresh back to the user without validating the data it is sent. When receiving the meta-refresh, the web browser interprets the script as an instruction from the website and the script is executed on the user's machine . In this case, when the anti-spoofing feature is enabled, all diverted HTTP traffic is inspected and then a meta-refresh is sent to the client containing the original request. If the original URL contains a script and a specific character sequence, the meta-refresh from the Guard will allow the client machine to execute the malicious script. Several conditions are required to be true in order for the malicious script to be processed: * The client user must follow a URL with a specifically formatted, embedded script to a site protected by the Guard. * The Guard must be running active basic protection, going through basic/redirect protection. * The specially crafted http request must be diverted through the Guard, and processed by the Guard. Only if all of the above conditions are met will the client receive the meta-refresh and process the embedded script. This vulnerability is being tracked by bug ID CSCsf01438. Impact ====== Successful exploitation of the vulnerability may result in malicious executable code being run by an individual user using a web browser. Software Version and Fixes ========================== When considering software upgrades, also consult http://www.cisco.com/go/psirt and any subsequent advisories to determine exposure and a complete upgrade solution. This vulnerability is fixed in version 5.1(6) of the Cisco Anomaly Guard code. In all cases, customers should exercise caution to be certain the devices to be upgraded contain sufficient memory and that current hardware and software configurations will continue to be supported properly by the new release. If the information is not clear, contact the Cisco Technical Assistance Center ("TAC") or your contracted maintenance provider for assistance. Workarounds =========== Changing the basic/redirect protection to basic/safe-reset protects the client from executing the embedded script. Instead of providing a layer seven http meta-refresh to the browser with the malicious URL intact, the Guard provides a layer three TCP-RST to end the connection. This can cause minor compatability issues, as some firewalls do not forward the TCP-RST. However, this method protects users from any XSS attacks until the Guard can be upgraded to a fixed version of code. To turn off basic/redirect and configure basic/safe-reset, please follow the example below. 1. Show the zone. user@GUARD#show zone test ...skipped **** USER FILTERS **** Row Source IP Source Mask Proto DPort Frg Action Rate Burst Units RxRate(pps) 10 * 255.255.255.255 6 80 no basic/redirect user@GUARD#config t user@GUARD-conf#zone test user@GUARD-conf-zone-test# no user-filter 10 2. Configure basic/safe-reset dynamic filter. user@GUARD-conf-zone-test#user-filter 10 basic/safe-reset * 6 80 3. Show that the filter is applied. user@GUARD#show zone test ...skipped **** USER FILTERS **** Row Source IP Source Mask Proto DPort Frg Action Rate Burst Units RxRate(pps) 10 * 255.255.255.255 6 80 no basic/safe-reset For more information, please refer to the configuration guide: http://www.cisco.com/en/US/products/ps5888/products_configuration_guide_cha… Obtaining Fixed Software ======================== Cisco will make free software available to address this vulnerability for affected customers. This advisory will be updated as fixed software becomes available. Prior to deploying software, customers should consult their maintenance provider or check the software for feature set compatibility and known issues specific to their environment. Customers may only install and expect support for the feature sets they have purchased. By installing, downloading, accessing or otherwise using such software upgrades, customers agree to be bound by the terms of Cisco's software license terms found at http://www.cisco.com/public/sw-license-agreement.html, or as otherwise set forth at Cisco.com Downloads at http://www.cisco.com/public/sw-center/sw-usingswc.shtml. Do not contact either "psirt(a)cisco.com" or "security-alert(a)cisco.com" for software upgrades. Customers with Service Contracts +------------------------------- Customers with contracts should obtain upgraded software through their regular update channels. For most customers, this means that upgrades should be obtained through the Software Center on Cisco's worldwide website at http://www.cisco.com/cgi-bin/tablebuild.pl/cisco-ga-crypto for the appliance or http://www.cisco.com/cgi-bin/tablebuild.pl/cisco-agm-crypto for the 7600 module. Customers using Third Party Support Organizations +------------------------------------------------ Customers whose Cisco products are provided or maintained through prior or existing agreement with third-party support organizations such as Cisco Partners, authorized resellers, or service providers should contact that support organization for guidance and assistance with the appropriate course of action in regards to this advisory. The effectiveness of any workaround or fix is dependent on specific customer situations such as product mix, network topology, traffic behavior, and organizational mission. Due to the variety of affected products and releases, customers should consult with their service provider or support organization to ensure any applied workaround or fix is the most appropriate for use in the intended network before it is deployed. Customers without Service Contracts +---------------------------------- Customers who purchase direct from Cisco but who do not hold a Cisco service contract and customers who purchase through third-party vendors but are unsuccessful at obtaining fixed software through their point of sale should get their upgrades by contacting the Cisco Technical Assistance Center (TAC). TAC contacts are as follows. * +1 800 553 2447 (toll free from within North America) * +1 408 526 7209 (toll call from anywhere in the world) * e-mail: tac(a)cisco.com Have your product serial number available and give the URL of this notice as evidence of your entitlement to a free upgrade. Free upgrades for non-contract customers must be requested through the TAC. Refer to http://www.cisco.com/warp/public/687/Directory/DirTAC.shtml for additional TAC contact information, including special localized telephone numbers and instructions and e-mail addresses for use in various languages. Exploitation and Public Announcements ===================================== The Cisco PSIRT is not aware of any public announcements or malicious use of the vulnerability described in this advisory. This vulnerability was reported to Cisco by a customer. Status of this Notice: FINAL ============================ THIS DOCUMENT IS PROVIDED ON AN "AS IS" BASIS AND DOES NOT IMPLY ANY KIND OF GUARANTEE OR WARRANTY, INCLUDING THE WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR USE. YOUR USE OF THE INFORMATION ON THE DOCUMENT OR MATERIALS LINKED FROM THE DOCUMENT IS AT YOUR OWN RISK. CISCO RESERVES THE RIGHT TO CHANGE OR UPDATE THIS DOCUMENT AT ANY TIME. A stand-alone copy or Paraphrase of the text of this document that omits the distribution URL in the following section is an uncontrolled copy, and may lack important information or contain factual errors. Distribution ============ This advisory is posted on Cisco's worldwide website at: http://www.cisco.com/warp/public/707/cisco-sa-20060920-guardxss.shtml In addition to worldwide web posting, a text version of this notice is clear-signed with the Cisco PSIRT PGP key and is posted to the following e-mail and Usenet news recipients. * cust-security-announce(a)cisco.com * first-teams(a)first.org * bugtraq(a)securityfocus.com * vulnwatch(a)vulnwatch.org * cisco(a)spot.colorado.edu * cisco-nsp(a)puck.nether.net * full-disclosure(a)lists.grok.org.uk * comp.dcom.sys.cisco(a)newsgate.cisco.com Future updates of this advisory, if any, will be placed on Cisco's worldwide website, but may or may not be actively announced on mailing lists or newsgroups. Users concerned about this problem are encouraged to check the above URL for any updates. Revision History ================ +-----------------------------------------+ | Revision | | Initial | | 1.0 | 2006-September-20 | public | | | | release. | +-----------------------------------------+ Cisco Security Procedures ========================= Complete information on reporting security vulnerabilities in Cisco products, obtaining assistance with security incidents, and registering to receive security information from Cisco, is available on Cisco's worldwide website at http://www.cisco.com/en/US/products/products_security_vulnerability_policy.… This includes instructions for press inquiries regarding Cisco security notices. All Cisco security advisories are available at http://www.cisco.com/go/psirt. - --------------------------------------------------------------------- All contents are Copyright (C) 1992-2006 Cisco Systems, Inc. All rights reserved. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (SunOS) iD8DBQFFEWqN8NUAbBmDaxQRAqFTAJ9Uufml6jFt/ThwcRkU+L6p/SArKACcDHjb cV8RoF6KJIcd0uZpHa83q10= =kVSm -----END PGP SIGNATURE-----

1 0

MLMs and RFC2822 filtering
by Travis Hassloch 20 Sep '06

20 Sep '06

-----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Hey, I suspect this is an appropriate forum for discussing mail filtering, since it involves interoperation between sender and receiver. The basic problem is that different MLMs identify remailed mail using different techniques. The net result is that you can't start filtering until you've received at least one email and dissected it. Worse, you can't distinguish it from UBE. Some MLMs have changed their mind multiple times (mailman has done so at least three times). This madness must stop. You may be asking yourself "why don't you just use procmail ^TO?" Well, it can't distinguish between email CC'd to you and sent to you via a mailing list. Also, it can't distinguish between email CC'd to two lists, and it can't recognize email BCC'd to a list. Does anyone care to forward this on to any MLM maintainers they know? How hard would it be to standardize this? - -- The whole point of the Internet is that different kinds of computers can interoperate. Every time you see a web site that only supports certain browsers or operating systems, they clearly don't get it. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.2.2 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFFEJIPPlSPhv5tocwRAoLJAJ9o+OBD2bG3xwm/rdsRxgGYdYLvvgCfR8lS zdEFFw1IUBjeZn/I7/c/oVo= =eAq4 -----END PGP SIGNATURE-----

2 1

Drone Armies C&C Report - 19 Sep 2006
by c2report＠isotf.org 20 Sep '06

20 Sep '06

This is a periodic public report from the ISOTF's affiliated group 'DA' (Drone Armies (botnets) research and mitigation mailing list / TISF DA) with the ISOTF affiliated ASreport project (TISF / RatOut). For this report it should be noted that we base our analysis on the data we have accumulated from various sources, which may be incomplete. Any responsible party that wishes to receive reports of botnet command and control servers on their network(s) regularly and directly, feel free to contact us. For purposes of this report we use the following terms open the host completed the TCP handshake closed No activity detected reset issued a RST This month's survey is of 4330 unique, domains (or IPs) with port suspect C&Cs. This list is extracted from the BBL which has a historical base of 11766 reported C&Cs. Of the suspect C&Cs surveyed, 640 reported as Open, 1570 reported as closed, and 684 issued resets to the survey instrument. Of the C&Cs listed by domain name in the our C&C database, 4862 are mitigated. Top 20 ASNes by Total suspect domains mapping to a host in the ASN. These numbers are determined by counting the number of domains which resolve to a host in the ASN. We do not remove duplicates and some of the ASNs reported have many domains mapping to a single IP. Note the Percent_resolved figure is calculated using only the Total and Open counts and does not represent a mitigation effectiveness metric. Percent_ ASN Responsible Party Total Open Resolved 19318 NJIIX-AS-1 - NEW JERSEY INTERN 97 15 85 13301 UNITEDCOLO-AS Autonomous System of 78 25 68 4766 KIXS-AS-KR 62 7 89 16265 LEASEWEB AS 44 33 25 30058 FDCSE FDCservers.net LLC 36 9 75 23522 CIT-FOONET 35 15 57 15083 IIS-129 Infolink Information Servic 35 7 80 33597 InfoRelay Online Systems, Inc. 29 0 100 8560 SCHLUND-AS 27 10 63 174 Cogent Communications 27 17 37 30315 Everyones Internet 26 10 62 7132 SBC Internet Services 26 2 92 25761 STAMIN-2 Staminus Communications 25 14 44 3561 Savvis 25 3 88 13213 UK2NET-AS UK-2 Ltd Autonomous Syste 24 0 100 3269 TELECOM ITALIA 24 13 46 12832 Lycos Europe 24 5 79 9121 TTNet 23 21 9 4314 IIS-64 I-55 INTERNET SERVICES 23 2 91 30407 Velcom.com 23 23 0 Top 20 ASNes by number of active suspect C&Cs. These counts are determined by the number of suspect domains or IPs located within the ASN completed a connection request. Percent_ ASN Responsible Party Total Open Resolved 16265 LEASEWEB AS 44 33 25 13301 UNITEDCOLO-AS Autonomous System of 78 25 68 30407 Velcom.com 23 23 0 9121 TTNet 23 21 9 174 Cogent Communications 27 17 37 23522 CIT-FOONET 35 15 57 19318 NJIIX-AS-1 - NEW JERSEY INTERN 97 15 85 25761 STAMIN-2 Staminus Communications 25 14 44 3269 TELECOM ITALIA 24 13 46 26496 Go Daddy Software, Inc. 11 11 0 8560 SCHLUND-AS 27 10 63 30315 Everyones Internet 26 10 62 30058 FDCSE FDCservers.net LLC 36 9 75 7479 KDDHK-AS-AP KDD HONG KONG LIMITED 8 8 0 9911 CONNECTPLUS-AP Singapore Telecom 9 7 22 15083 IIS-129 Infolink Information Servic 35 7 80 4766 KIXS-AS-KR 62 7 89 9316 DACOM-PUBNETPLUS-AS-KR 11 7 36 12322 PROXAD AS for Proxad ISP 8 6 25 3786 ERX-DACOMNET 13 6 54 Randal Vaughn Gadi Evron Professor ge at linuxbox.org Baylor University Waco, TX (254) 710 4756 randy_vaughn at baylor.edu

2 1

Why is RFC1918 space in public DNS evil?
by Matthew Palmer 18 Sep '06

18 Sep '06

I've been directed to put all of the internal hosts and such into the public DNS zone for a client. My typical policy is to have a subdomain of the zone served internally, and leave only the publically-reachable hosts in the public zone. But this client, having a large number of hosts on RFC1918 space and a VPN for external people to get to it, is pushing against this somewhat. Their reasoning is that there's no guarantee that forwarding DNS down the VPN will work nicely, and it's "overhead". I know the common wisdom is that putting 192.168 addresses in a public zonefile is right up there with kicking babies who have just had their candy stolen, but I'm really struggling to come up with anything more authoritative than "just because, now eat your brussel sprouts". My Google-fu isn't working, and none of the reasons I can come up with myself sound particularly convincing. Can someone give a lucid technical explanation, or a link, that explains it to me so I can explain it to Those In Power? Thanks, - Matt

14 17

Re: IPv6 PI block is announced - update your filters 2620:0000::/23
by Doug Barton 18 Sep '06

18 Sep '06

Gert Doering wrote: > Does the policy really permit /40.../47 assignments? http://www.arin.net/registration/guidelines/ipv6_assignment.html#step2 -- If you're never wrong, you're not trying hard enough

7 6

Re: ARIN sucks?
by Hank Nussbacher 18 Sep '06

18 Sep '06

>All our experiences consulting our clients about how to get their AS and >Subnets have been pretty easy and fast. > >First get enought IP from 2 Peer to justify at least a /21; > >Now that you have 2 Peer, request the AS and a Subnet from ARIN; > >Take a day or 2 to prepare the paperwork; > >Submit it in the right sequence to ARIN; > >And LISTEN to your ARIN rep, they know how the procedure must be done and >will help your get it done correctly. > >Simple really. It is indeed simple if you know what needs to be done and what is expected. Even in your case above you mislead people into thinking that one can "request the AS and a Subnet from ARIN". After setting up the various POCs (step #1), step #2 is getting an ORG. Step #3 is requesting the IP space and *not* the ASN. One can't get an ASN from ARIN *until* you have IP space. Once you are authorized by ARIN for the IP space, one has to pay ARIN (step #4). One can pay online via credit card, which for large organizations can sometimes be a problem. In addition, ARIN doesn't accept American Express. Therefore, step #4 might very well involve cutting a check and Fedex'ing it to ARIN and waiting till they process it. Step #5, which can be done in parallel to step #4 is getting the ARIN Registration Service Agreement signed by your legal department. Once again, depending on the size of your organization, this might take anywhere from 1-3 weeks. Step #6 is the ASN request. In order to do that one needs to submit a signed copy of the two contracts one has with their upstreams (to justify the ASN). Once again, these contracts might be buried in legal, need to be found and scanned and sent to ARIN before the ASN request can be processed. Step #7 is paying for the ASN either online or by check (see step #4 above). Those that stated the process to get IP and ASN from ARIN would be a week or so, might be referring to very small organizations (even there I am a bit skeptical). My experience was that IP assignment took about a month and ASN took about a month. Regards, Hank Nussbacher http://www.interall.co.il

5 6

about the spamhaus joe job
by Gadi Evron 17 Sep '06

17 Sep '06

Many abuse desks for numerous ISPs have been getting a fake email message from Steve Linford. Warning against retribution if the spamhaus service is used, with fake information on the court ruling against spamhaus. You can find more information on this Joe Job here: http://www.spamhaus.org/organization/alert-200609161.html Gadi.

1 0

Re: Removal of name
by Christopher X. Candreva 16 Sep '06

16 Sep '06

On Fri, 15 Sep 2006, NAME wrote: > Dear Sirs/Madams, Please remove my name "NAME REMOVED" from this site > below. It is slanderous towards me and it does not involve me. I am no Dr. Phil has a saying: When you find yourself in a hole, stop digging. You do realize you mailed this out to a mailing list with a few thousand people on it, right ? So that you've just reminded everyone who had forgotten about it. In any case, this is an archive of a mailing list, where this discussion originally took place. None of us run it, and there are probably multiple archives of Nanog out there, so you'll never get rid of them all. In fact I'll bet there are people who read your message and are making copies of the page now, just in case the others do come down. > longer involved with telecommunications and I am not associated with Qwest > anymore and it is also slanderous towards Qwest. I would appreciate this > act of kindness. It is gone on too long this is from 2002. This defames my > character from 2002 and it does not properly represent me. Dude, you did it. Be a man and own up to it. Figure out a way in Interviews to show you learned from it, though this post will make it harder. http://www.ibiblio.org/Dave/Dr-Fun/df9601/df960124.jpg > > thanks > > NAME REMOVED > http://www.cctec.com/maillists/nanog/historical/0202/msg00446.html Re: OT: spam from Globix to ARIN POCs > --------------------------------- > > To: Kai Schlichting <kai(a)pac-rim.net> > Subject: Re: OT: spam from Globix to ARIN POCs > From: "Christopher X. Candreva" <chris(a)westnet.com> > Date: Mon, 25 Feb 2002 15:26:36 -0500 (EST) > Cc: nanog(a)merit.org > Delivered-To: nanog-outgoing(a)trapdoor.merit.edu > Delivered-To: nanog(a)trapdoor.merit.edu > Delivered-To: nanog(a)merit.org > In-Reply-To: <426765568.20020225123802(a)conti.nu> > Sender: owner-nanog(a)merit.edu > > --------------------------------- > > On Mon, 25 Feb 2002, Kai Schlichting wrote: > And on another note, that little spamming jerk from Qwest's NYC sales office, > NAME REMOVED, should start finding himself a new job while there is time. > And don't count on collecting unemployment. What, did he spam your users through the whois database, and copy you on it since you are the tech contact ? NAME REMOVED(a)qwest.com went right in the filters. ========================================================== Chris Candreva -- chris(a)westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/ > > --------------------------------- > References: > > OT: spam from Globix to ARIN POCs > From: Kai Schlichting <kai(a)pac-rim.net> > > > --------------------------------- > > Prev: Re: DNS timeline > Next: Re: DNS timeline > Index(es): > Main > Thread > > > > --------------------------------- > Want to be your own boss? Learn how on Yahoo! Small Business. ========================================================== Chris Candreva -- chris(a)westnet.com -- (914) 967-7816 WestNet Internet Services of Westchester http://www.westnet.com/

1 0

Re: IPv6 PI block is announced - update your filters 2620:0000::/23
by Bjoern A. Zeeb 15 Sep '06

15 Sep '06

On Fri, 15 Sep 2006, Gert Doering wrote: Hi, > On Thu, Sep 14, 2006 at 12:05:16AM +0200, Jeroen Massar wrote: >> It's update your IPv6 filters time: >> >> http://www.arin.net/reference/ip_blocks.html >> >> 8<----------------------------------------- >> IPv6 Assignment Blocks CIDR Block >> 2620:0000:/23 >> ----------------------------------------->8 >> Expect blocks in between /40 and /48 there. > > Filter recommendation document updated. Could you also add blocks like 2800::/23 from LACNIC issued Nov 2005 by IANA? > Does the policy really permit /40.../47 assignments? The only thing I found so far is [1] which really only defines the <=48 end. It's talking about _at least_ a /44 reserved for future growth and it says "When possible, [subsequent] assignments will be made from an adjacent address block.". Considering what we see with v4 PI (direct assignments) today and had seen with /8 PA and an undefined ("open") other end in ARIN policy I wouldn't trust any >=40 rule being the maximum for this block. I have so far decided to use (also see [2]): ! + ARIN PI (chose whatever one you think is worse) !ipv6 prefix-list ipv6-ebgp-strict seq 135 deny 2620::/23 le 128 ipv6 prefix-list ipv6-ebgp-strict seq 135 permit 2620::/23 ge 32 le 48 Happy weekend. /bz References: [1] http://www.arin.net/policy/nrpm.html#six582 6.5.8. Direct assignments from ARIN to end-user organizations 6.5.8.2. Initial assignment size 6.5.8.3. Subsequent assignment size [2] http://sources.zabbadoz.net/ipv6/v6-prefix-filter-20060913-public.cfg -- Bjoern A. Zeeb bzeeb at Zabbadoz dot NeT

1 0