Re: SIXXS contact
On Mon, 25 Apr 2011, Andrew Kirch wrote: On 4/25/2011 4:07 AM, Raymond Dijkxhoorn wrote: Hi! would someone at SIXXS please contact me off-list regarding an account issue? Contact The main contact address for SixXS is i...@sixxs.net, which is the sole email address one should use to contact SixXS. Non-English, impolite, clueless, UCE and HTML email gets discarded automatically. The official language used is English, due to archiving issues and the international effort put into SixXS. And you naturally trued that one before sending here, right? Bye, Raymond. Yes, repeatedly. The response was non-existent, or simply unfortunate, so I'm trying other avenues. Echo that. IPv6 bgp peering for distributed looking glass has been down for some 6 months or so now. No responses via any channel. It's sad because distributed looking glass has been very useful. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
RE: Internet Edge Router replacement - IPv6 route table sizeconsiderations
On Thu, 10 Mar 2011, George Bonser wrote: And this is better than just not trying to implement IPv6 stateless auto-configuration on ptp links in the first place how exactly? I don't use autoconfiguration. Static configured IPs, static neighbor entries for these types of links. Man. It must be annoying to change all those static neighbor entries when the interfaces fail, links must be migrated to another line cards or you replace routers. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: quietly....
Semi-OT: You are now what we need you to be. A beaten, resentful people who will have to rebuild, who will have to rely on our.. good graces. Who can be used and.. guided as we wish to guide you. Perfect ground for us to do our work.. Quietly, quietly. Sorry.
Re: IPv6 BGP table size comparisons
On Wed, 22 Dec 2010, Bjoern A. Zeeb wrote: People might say that it would not be helpful at all as we want IPv6 deployed but on the other hand people apply their doings of the last 10 years 1:1 to IPv6 and continue on the same mistakes which will not be helpful either. Indeed... I would really love to see weekly Routing Reports for IPv6 as we have them for legacy IP rather sooner than later. This would provide statistics and might be useful from historical POV, but I fear the operational impact of published IPv4 Routing Table reports is close to zero. (E.g. 'does it help in making people stop advertising unnecessary more-specific routes?'.) I don't expect that to change. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: IPv6 BGP table size comparisons
On Tue, 21 Dec 2010, Jeff Wheeler wrote: http://en.wikipedia.org/wiki/Comparison_of_IPv6_support_by_major_transit_providers 'Maximum Prefix Length' may be an over-simplifying metric. FWIW, we're certainly not a major transit provider, but we do allow /48 in the designated PI ranges but not in the PA ranges. So the question is not necessarily just about the prefix length used because it might vary by the prefix. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: ICMPv6 rate limits breaking PMTUD (and traceroute) [Re: Comcast enables 6to4 relays]
On Wed, 1 Sep 2010, Simon Leinen wrote: Note that the same rate-limit will also cause stars in IPv6 traceroutes through popular routers if the default setting is used. ... Anybody knows which defaults are used by other devices/vendors? I've noticed 6to4 relay rate-limiter blackholes before (e.g. in Your.org relay in AMS, got quickly fixed once I reported it). FWIW, Linux default is 1000pps and BSD has 100pps which is too low for a popular relay. In our relays we've used 1000-3000pps. The majority of ICMPv6's is caused by windows boxes testing the relay's liveness. Depending on the MTU configuration of the relay's tunnel interface (there isn't a BCP on this I think), you will also get more issues if you run the relay at MTU=1280 rather than (say) 1480. But using 1480 may result in an IPv4 blackhole if you source packets from an anycast address and your destination is e.g. behind PPPoE, so... -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: UPDATED - Comcast enables 6to4 relays
On Tue, 31 Aug 2010, John Jason Brzozowski wrote: Enabled two more 6to4 relays this morning. :) Out of curiousity, what is the aggregate Mbps load on the relays? Related question is the platform on which these are run. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: DNS for RFC3180 GLOP reverse zone ?
On Thu, 6 May 2010, James Hess wrote: Now that AS numbers have been extended to 4 bytes in length, and RIRs are even about to stop differentiating between them when allocating AS numbers, or allowing anyone to request and be sure of getting a new 16-bit ASN. Then you may be interested to see this Last Call: http://www.ietf.org/mail-archive/web/mboned/current/msg01021.html (draft-ietf-mboned-ipv4-uni-based-mcast) It seems that it will be impossible for the scheme to be followed in IPv4. A more sensible BCP at this point would be to designate the entire 223/8 to IRRs, like was suggested by the BCP for 64512 -- 65535, since most ASNs are not using GLOP addressing. Uhh. Take away the numbers from those who have already started using them? Are you serious? There were multiple attempts to the private etc. ASN parts of 233/8 to RIRs but these have failed (lack of interest?). The current situation (RFC5771) is that this has been designated as AD-HOC Block III and is assignable from IANA. The curious minds may also want to take a look at: http://tools.ietf.org/html/draft-ietf-mboned-addrarch-06 (Comments welcome, this has been waiting the completion of abovementioned draft.) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: IPv6 enabled carriers?
On Wed, 10 Mar 2010, Chris Grundemann wrote: SixXS maintains a list here: http://www.sixxs.net/faq/connectivity/?faq=ipv6transit. I think that list should also include TeliaSonera. TSIC does offer v6 transit, although their product sheet only mentions IPv4. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
RE: Using /126 for IPv6 router links
On Tue, 26 Jan 2010, Igor Gashinsky wrote: Matt meant reserve/assign a /64 for each PtP link, but only configure the first */127* of the link, as that's the only way to fully mitigate the scanning-type attacks (with a /126, there is still the possibility of ping-pong on a p-t-p interface) w/o using extensive ACLs.. Anyways, that's what worked for us, and, as always, YMMV... That's still relying on the fact that your vendor won't implement subnet-router anycast address and turn it on by default. That would mess up the first address of the link. But I suppose those would be pretty big ifs. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
RE: 2009 Worldwide Infrastructure Security Report available for download.
On Wed, 20 Jan 2010, Stefan Fouant wrote: Completely agree on the disturbing observation of the increase in rate-limiting as a primary mitigation mechanism for dealing with DDoS. I've seen more and more people using this as a mitigation strategy, against my advice. For anyone interested in more information on the topic, and why rate-limiting is akin to cutting your foot off, I highly recommend you take a look at the paper Effectiveness of Rate-Limiting in Mitigating Flooding DoS Attacks presented by Jarmo Molsa at the Third IASTED International conference. Thanks to Arbor for collecting the report and your observations. One thing I found extremely strange is that almost 50% report they use BCP38/Strict uRPF at peering edge, yet only about 33% use it in customer direction. (Figure 13, p20) I wonder if peering edge refers to drop your own addresses or real strict uRPF (or the like)? If not I'm curious if this is for real, and how in earth they're doing it, especially given that in Fig 15 (p22) shows they don't implement BGP prefix filtering. If you can't filter BGP, how could you filter packets? Based on my experience, even if you filter BGP, you may not be able to filter packets except in simple scenarios. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: XO - a Tier 1 or not?
On Tue, 28 Jul 2009, Charles Mills wrote: Is XO Communications a Tier 1 ISP? ... Any help here? Thanks as always. http://en.wikipedia.org/wiki/Tier_1_network -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: NAT64/NAT-PT update in IETF, was: Re: Important New Requirement for IPv4 Requests [re impacting revenue]
On Thu, 23 Apr 2009, Nathan Ward wrote: After trying to participate on mailing lists for about 2 or 3 years, it's pretty hard to get anything done without going to meetings. Just participating in mailing lists is good for keeping up to date, but not so good for getting things changed. That's what I've found, anyway. Might not always be true. If you were to go to meetings, you would realize that it won't help in gettings things changed significantly better than active mailing list participation would... :-/ -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: BGP nexthop-self vs. EIGRP redistribution
On Mon, 16 Mar 2009, Jack Bates wrote: My question is, which is the correct method of implementing this? Should we be redistributing static and connected routes on our borders into IGP, and not using next-hop-self? Or should we not redistribute and use next-hop-self? next-hop-self seems to remain more stable overall. In some scenarios I believe it is even required (just as not using it is required in other scenarios). For your deployment, I'd say you are open to choose either, and next-hop-self would be the more stable of the two. The largest issue with NOT using next-hop-self that I have seen is the effect it has when that IGP route for the next hop disappears. BGP tends to be more graceful about removing routes via iBGP then handling routes locally when they are suddenly unreachable via IGP. On smaller networks (where IGP size is not an issue), I could see some benefit for redistributing connected to IGP and preserving the next-hop for those interfaces which have a backup route through some other interface. I.E: if the connected interface goes down, everyone knows immediately that the nexthop is unusable, and you can start using better working routes immediately, rather than waiting for the routes being BGP WITHDRAWn. Loopback and n-h-s seems to always make sense for those interfaces which are singlehomed to that router (no redundancy) -- otherwise you may want to consider which one is best. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
RE: IPv6 delivery model to end customers
On Sat, 7 Feb 2009, Mikael Abrahamsson wrote: But I wasn't talking (A)DSL. DSL is last century. I am talking VDSL2/ETTH. Security model there is to only have ethernet and IP, no PPP/ATM, no L2TPv3 or PPPoE. Let's skip the terms BRAS/LNS etc. Anything that terminates tunnels is expensive (apart from GRE/IPV6IP which the 7600 seems to do very well, but I don't like tunnels. I like native). Most of the ETTH ports are 10/10, 100/10 or 100/100 (or even higher speeds) and 100/10 costs ~30 USD a month. L2TPv3/PPPoE is not an option. I may be missing something. only have ethernet and IP. Why is plain-ethernet with each subscriber provisioned in a separate router's vlan subinterface insufficient? There is no security issue because each subscriber only sees its own traffic. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Recommendation of Tools
On Wed, 3 Dec 2008, Anders Lindbäck wrote: Mtr is even less usefull then that, in its default mode it does a traceroute and then proceeds to ICMP Ping flood each IP in the list generated by the traceroute, the result is usually completly useless on WAN topologies due to asym-routing, ICMP node protections by carriers and punting etc.. No, it doesn't try pinging the routers in the middle, at least not anymore (I just re-checked with 0.71 and 0.75). I vaguely recall behaviour like that in the past, however, so it's possible that long time ago mtr did behave that way. And using UDP will not really provide better results due to the same thing, and IIRC Cisco from 12.0 has a standard setting of no more then 1 ICMP Unreach per 500ms.. This is true and the point I was getting at, though I believe the bucket is much larger in any recent software release (also in 12.0 series). Actually, 5 years ago, you could see spot Cisco routers in traceroute6 because they dropped the rate-limiter didn't respond to the middle packet and it resulted in a star. The rate-limiter has long since been fixed to be more lenient. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Recommendation of Tools
On Tue, 2 Dec 2008, Antonio Querubin wrote: On Wed, 3 Dec 2008, Pekka Savola wrote: FWIW, Mtr measures latency/delay and loss based on ICMP messages heard back from the routers on path. As a result, in almost all cases, the real hop-by-hop latency of actual end-to-end data packets is better than it can report. mtr has a recently added '-u' option to use UDP instead of ICMP echo requests. But that doesn't change the gist of my message: it's still relying on ICMP ttl exceeded messages sent by the routers on the path to check the delays etc. As such it suffers from basically the same limitations as ICMP probing. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Recommendation of Tools
On Tue, 2 Dec 2008, Andrew Mulholland wrote: On Tue, Dec 2, 2008 at 10:47 PM, Lee, Steven (NSG Malaysia) [EMAIL PROTECTED] wrote: Hi all, do you have any recommended tools that can measure latency/delay hop by hop basis? Preferable the tools can measure the running (live) traffic. mtr ? - http://www.bitwizard.nl/mtr/ FWIW, Mtr measures latency/delay and loss based on ICMP messages heard back from the routers on path. As a result, in almost all cases, the real hop-by-hop latency of actual end-to-end data packets is better than it can report. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: IPv6 routing /48s
On Thu, 20 Nov 2008, Nathan Ward wrote: IPv6 will be used in preference to IPv4 if it is available. If 6to4 is the only IPv6 connectivity then it will be used. See RFC3484. Preference of IPv4 is 10, 6to4 is 30. However, in destination address selection prefer matching scope (comes up when v4 address is rfc1918) and prefer matching label is checked before preference. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: IPv6 routing /48s
On Tue, 18 Nov 2008, Jeroen Massar wrote: Check: http://www.space.net/~gert/RIPE/ipv6-filters.html for a list of suggested filter expressions that cover all of these correctly. Unfortunately, the JunOS version of the strict filter is blocking /32's from APNIC region as well. The offending lines are: route-filter 2001::/16 prefix-length-range /19-/32; ... route-filter 2001:0c00::/23 prefix-length-range /48-/48; This is because Juniper uses longest prefix matching in route filters (maybe this is different in cisco, I don't know): https://www.juniper.net/techpubs/software/junos/junos92/swconfig-policy/how-a-route-list-is-evaluated.html As a result, this will end up rejecting legitimate prefixes such as 2001:c00::/32 because then only /48's are accepted from that range. Unfortunately, I don't know which blocks APNIC has set aside from 2001:0c00::/23 for /48 assignments; based on their web pages, they have policies for at least multihoming, IXs and critical infrastructure. But I couldn't find info which block these are from. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: community real-time BGP hijack notification service
On Sun, 14 Sep 2008, Hank Nussbacher wrote: I have used IAR, PHAS and MyASN and I can say I would not recommend myASN. It is a cumbersome system and very non-intuitive. It is based on an ASN-centric model, whereby each ASN is in its own realm. So if you manage *one* ASN, perhaps this system might work for you. But if you have about 10 ASNs you want to manage, in one central spot, you are out of luck here. Also, you would expect the system to auto-learn what prefixes exist under your ASN and then you would have perhaps check boxes to disable or enable monitoring for specific prefixes. With myASN you have to manually type in each and every prefix you have. The same holds true for the newer http://ripe.net/is/alarms/. They also differentiate between origin and transit ASN. Their summary view doesn't show which prefixes are being monitored. No help or FAQ available yet on the beta alarms system. I think I'll need to chime in here, being a user of myASN. I have not tested other systems. To me it seems to work OK. Manual typing etc. is minimized because you can export and import XML; this is the way I entered our prefix information in the database (though if the prefixes change often, maybe updates would be a chore). The database itself AFAIR does not have any restriction on what it's monitoring when you use the advanced interface -- you can insert any AS-path regexes you want, and that way we're managing prefixes from some ~5-10 ASNs. AFAICS, the ASN in login form is only used for identification purposes and in some shortcuts in the basic interface. I agree that to kickstart monitoring, an auto-learning feature could be used. And that documentation is somewhat sparse :-). I've gotten a couple of alarms which may or may have been bogus. One academic site was purpotedly advertising one of our prefixes duing one day for a couple of 1-2 hour periods. Upon asking they said they had not done anything special, and said that their upstreams wouldn't accept that kind of prefix from them anyway. Not sure if that was true, but I didn't purse this further. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: New Intercage upstream
On Fri, 12 Sep 2008, Paul Wall wrote: This is easy. Hey Cogent (174), AboveNet (6461), and NTT/Verio (2914), Could you guys please be sure you're not routing the following rogue customer prefixes? I think your argument might be more convincing with those NOCs/abuse-desks if you provided or referred to evidence which shows those prefixes don't belong to them. 58.65.238.0/24 58.65.239.0/24 64.28.176.0/20 67.130.99.0/24 67.210.0.0/21 67.210.8.0/22 67.210.13.0/24 67.210.14.0/23 69.1.78.0/24 69.22.162.0/23 69.22.168.0/22 69.22.184.0/22 69.31.64.0/20 69.50.160.0/20 69.50.176.0/20 69.130.99.0/24 69.250.145.0/24 85.255.113.0/24 85.255.114.0/23 85.255.116.0/23 85.255.118.0/24 85.255.119.0/24 85.255.120.0/24 85.255.121.0/24 85.255.122.0/24 93.188.160.0/21 116.50.10.0/24 116.50.11.0/24 195.95.218.0/23 216.255.176.0/20 Thank you, and Drive Slow, Paul Wall On Fri, Sep 12, 2008 at 4:29 AM, [EMAIL PROTECTED] wrote: Looks like they found a new willing partner. AS32335 PACIFICINTERNETEXCHANGE-NET - Pacific Internet Exchange LLC. http://cidr-report.org/cgi-bin/as-report?as=AS27595 http://www.pacificinternetexchange.net/ Marc -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: an effect of ignoring BCP38
On Thu, 11 Sep 2008, Jo Rhett wrote: I've been in, near, or directly in touch with enough big provider NOCs in the last year on various DoS attach research issues, and nearly nobody... that's right NONE of them were using BCP38 consistently. Name the five biggest providers you can think of. They ain't doing it. Now name the five best transit providers you can think of. They ain't doing it either. (note that all of these claimed to be doing so in that survey, but during attack research they admitted that it was only in small deployments) If someone told me (truthfully) that there was 10% BCP38 compliance out there, I'd be surprised given what I have observed. A problem I have with these discussions is that everyone has their own idea what BCP38 implies. Others say their loose-mode uRPF setups are BCP38. Others are using strict uRPF or similar (e.g. acls). Some think that Tier1 transit operators should apply one of the options above to their tier2 customers. Others think it should just be applied at the site-edges. Some don't consider spoofing protection at LAN interface level at all, others call that also BCP38. Etc. Your note above seems to imply that you would expect the five best transit providers you think of to apply BCP38 (strict?) to their customers. Even if the customer is a major ISP? (However, if your argument is about a smallish end-site, I'd agree spoofing protection should be applied there.) FWIW, I've tested what would happen if I were to enable strict-mode (feasible paths) uRPF on an Internet exchange (all peerings). If I recall correctly, the amount of dropped packets would have been in the order of 1%. We decided not to do it. Maybe those five biggest providers you can think of have similar experiences with their biggest customers? Loose mode URPF is seems (IMHO) pretty much waste of time and is confusing the discussion about real spoofing protection. The added protection compared to ACLs that drop private and possibly bogons is not that big and it causes transient losses when the routing tables are changing. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: an effect of ignoring BCP38
On Thu, 11 Sep 2008, Jo Rhett wrote: On Sep 11, 2008, at 10:10 AM, [EMAIL PROTECTED] wrote: By the time you walk our list of upstreams to any of the '5 biggest anything', you've gotten to places where our multihomed status means you can't filter our source address very easily (or more properly, where you can't filter multihomed sources in general). I don't agree with this statement. I hear this a lot, and it's not really true. Being multihomed doesn't mean that your source addresses are likely to be random. (or would be valid if they were) A significant portion of our customers, and *all* of the biggest paying ones, are multihomed. And they might have a lot of different ranges, but we know what the ranges are and filter on those. If you can manage ACLs for these customers, that's fine. But maybe your multihomed customers and '5 biggest anything' customers are different. Maybe your multihomed customer has 5 prefixes. The big ones could have 5000. That's a pretty big ACL to manage. This is where Strict URPF (+feasible paths) helps a lot because in some cases you don't need to manage those ACLs by hand. But this gets broken if the customer advertises more specific routes from another provider, but doesn't advertise these to you -- your route to those more specifics goes through another ISP, and if the site is sourcing packets from those more specifics through you, the strict uRPF would drop them. There are ways to work around this, e.g. by requiring that the customers advertise the more specifics to you as well but mark them so that you don't propagate them, but I suspect this is not feasible in the higher tiers of ISP business. http://tools.ietf.org/html/draft-savola-bcp84-urpf-experiences Section 3 discusses this a bit. FWIW: we use feasible-paths strict uRPF on all customer and LAN interface without exception. Multihomed ones as well, though it's a bit more work. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: Is it time to abandon bogon prefix filters?
On Tue, 19 Aug 2008, Kevin Loch wrote: While you're at it, you also placed the reachable-via rx on all your customer interfaces. If you're paranoid, start with the 'any' rpf and then move to the strict rpf. The strict rpf also helps with routing loops. Be careful not to enable strict rpf on multihomed customers. This includes any bgp customer unless you know for sure they are single homed to you and that will not change. Strict uRPF (feasible paths variant, RFC3704) works just fine with multihomed customers here. But we don't allow TE more specifics either from the customer or from peers, so the longest prefix matching doesn't get messed up. And with certain kind of p2p link numbering, you may need to add a dummy static route. But it works. For more see especially Section 3 of: http://tools.ietf.org/id/draft-savola-bcp84-urpf-experiences-03.txt (comments are also welcome.) -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: route policy (Re: Public shaming list for ISPs announcing other ISPs IP space by mistake)
On Thu, 14 Aug 2008, Brandon Butterworth wrote: Herein is the value, the RIR (RIPE) is also the holder of the policy. With ARIN, this is not the case, there is RADB and a number of other RR's that are out there for varying reasons, some personal and some business. Yes, RIPE rock. Please make it all not suck. Unfortunately, RIPE DB will allow anyone to add any route objects for prefixes that are not under the RIPE management :-(. For example, anyone could add route objects for most of DNS root server prefixes. For those prefixes that are managed by RIPE, it's good. But the above feature dilutes the trustworthiness of RIPE DB slightly... -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
Re: [NANOG] US DoD receives chunked IPv6 /13 (14x /22 but not totally consecutive)
On Fri, 16 May 2008, Colin Alston wrote: On 16/05/2008 20:15 Christopher LILJENSTOLPE wrote: My guess is that they don't want to be tied to only announcing a single /13. Each of those organizations is bigger than a lot of service providers out there... Since when do you have to announce only the same size prefix as your allocation? http://www.arin.net/policy/nrpm.html#six511 reads: c. plan to provide IPv6 connectivity to organizations to which it will assign IPv6 address space, by advertising that connectivity through its single aggregated address allocation; Other regions have, or have had, similar requirements. I'm not a native speaker, but I guess single aggregated address allocation could be read to imply either 1) one superblock [and nothing else], or 2) at least one superblock that covers everything (with no implied statement on the more specifics). Even if the interpretation is the second, the benefit of multiple allocations is that they wouldn't need to route between all the suballocations at least in one location in case someone is building route filters so that it would reject more specifics. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings ___ NANOG mailing list NANOG@nanog.org http://mailman.nanog.org/mailman/listinfo/nanog
Re: IPv6 firewall support
On Fri, 26 Oct 2007, [EMAIL PROTECTED] wrote: ... Juniper SSG (formerly Netscreen) supports IPv6 in ScreenOS 6.0 and up. ... FWIW, there are typically notable differences in v6 feature parity vs v4. So for those folks that are actually using this stuff supports v6 -- check! isn't good enough and may result in some nasty surprises later on. For example, Netscreens cannot presently filter IPv6 in transparent (bridged) mode, only in routed mode. The feature is AFAIK in the roadmap but over a year away. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
