Re: Addressing plan exercise for our IPv6 course
I tend to think a /60 is a reasonable allocation for a residential user. In my home I have two subnets and will in time likely add two more: - general network access - my office (required to be separate by Cisco Information Security policy) - (future) would likely want routable separate bandwidth for A/V at some point - (future) Smart Grid HAN will likely be its own subnet If my wife went to work for a company with an infosec policy like Cisco's, that becomes a fifth subnet. Yes, 16 to choose from seems reasonable. /56 seems appropriate to a small company, /48 for a larger company, and I could see a market for a /52. A company that needs more than a /48 is likely to also be using ULAs for some of its areas, which is an automatic extension, and could always justify another /48 (or one per continent) if it really needed them. Could I do all this within a /64? Of course, with some thought, and by getting the Smart Grid and office prefixes from other sources (Cisco, my utility) and running them over a VPN (which I do anyway). The question is why I should have to. Why four bit boundaries? Because we're using hexadecimal, and each character identifies four bits. It makes tracking numbers simple - no remember to count by N as in IPv4. It's not magic, but to my small mind - and especially for of non-technical residential customers - it seems reasonable. And yes, I think the logic behind a 48 bit MAC address is reasonable too. On Jul 24, 2010, at 7:50 AM, Mark Smith wrote: On Fri, 23 Jul 2010 13:26:43 -0700 Matthew Kaufman matt...@matthew.at wrote: sth...@nethelp.no wrote: It is not about how many devices, it is about how many subnets, because you may want to keep them isolated, for many reasons. It is not just about devices consuming lots of bandwidth, it is also about many small sensors, actuators and so. I have no problems with giving the customer several subnets. /56 is just fine for that. /56? How about /62? That certainly covers several... and if you're really worried they might have too many subnets for that to work, how about /60? I haven't seen any kind of realistic scenarios which require /48 for residential users *and* will actually use lots and lots of subnets - without requiring a similar amount of manual configuration on the part of the customer. So we end up with /56 for residential users. Only because people think that the boundaries need to happen at easy-to-type points given the textual representation. /56 is still overkill for a house. And there's several billion houses in the world to hook up. So you're also strongly against 48 bit Ethernet MAC addresses? Dropping the two bits for group and local addresses, that's 70 368 744 177 664 nodes per LAN. How ridiculous! What were those idiots+ thinking! 48-bit Absolute Internet and Ethernet Host Numbers, by Yogan K. Dalal, Robert S. Printis, *July 1981* http://ethernethistory.typepad.com/papers/HostNumbers.pdf + not actually idiots http://www.ipinc.net/IPv4.GIF
Re: Addressing plan exercise for our IPv6 course
On (2010-07-24 03:50 -0400), valdis.kletni...@vt.edu wrote: Firewall != NAT. The former is still needed in IPv6, the latter is not. And I suspect that most Joe Sixpacks think of that little box they bought as a Maybe you are talking strictly in context of residential DSL, in which case I would agree, NAT is killable, if we don't fsck-up in our DSL offerings. (Provide customer /64 and route /56 to ::c/64, so first /64 is bridged, if customer ever wants to start routing, they just add ::c/64 router to LAN.) However it is quite optimistic to think IPv6 would remove completely need for NAT. Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. This is non-technical problem, enterprises of non-trivial size can't typically even tell without months of research all the devices and software where they've written down the IP addresses. RFC4193 + NAT quite simply is what they know and are comfortable with. It would be hard sell to ask them to design whole IPv6 infra so that they can confidently renumber it in 15min, like you can with RFC4193+NAT. -- ++ytti
Re: Addressing plan exercise for our IPv6 course
On Jul 23, 2010, at 1:26 PM, Matthew Kaufman wrote: sth...@nethelp.no wrote: It is not about how many devices, it is about how many subnets, because you may want to keep them isolated, for many reasons. It is not just about devices consuming lots of bandwidth, it is also about many small sensors, actuators and so. I have no problems with giving the customer several subnets. /56 is just fine for that. /56? How about /62? That certainly covers several... and if you're really worried they might have too many subnets for that to work, how about /60? /60 at a bare minimum since you can do RDNS delegation on /x boundaries where x%4==0. RDNS for a /62 is do-able, but, it requires 4 zone files and 4 sets of parent NS records instead of 1. /62 for 4 customers ends up requiring 16 zone files and 16 sets of parent NS records instead of 4. I haven't seen any kind of realistic scenarios which require /48 for residential users *and* will actually use lots and lots of subnets - without requiring a similar amount of manual configuration on the part of the customer. So we end up with /56 for residential users. Only because people think that the boundaries need to happen at easy-to-type points given the textual representation. /56 is still overkill for a house. And there's several billion houses in the world to hook up. Yes... Overkill is a good thing in IPv6. Even with this level of overkill, fully deploying the current world with a /48 for every house consumes less than 0.1% of the address space. (Apprximately 4x10^9 households on earth getting a /48 each = roughly one /16 which is 1/65,536th of the total address space and 1/8192nd of 2000::/3) What is the harm in doing so? Why not minimize provisioning effort and maximize user flexibility by consuming a very tiny fraction of a plentiful resource which costs virtually nothing? Owen
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 1:29 AM, Saku Ytti wrote: On (2010-07-24 03:50 -0400), valdis.kletni...@vt.edu wrote: Firewall != NAT. The former is still needed in IPv6, the latter is not. And I suspect that most Joe Sixpacks think of that little box they bought as a Maybe you are talking strictly in context of residential DSL, in which case I would agree, NAT is killable, if we don't fsck-up in our DSL offerings. (Provide customer /64 and route /56 to ::c/64, so first /64 is bridged, if customer ever wants to start routing, they just add ::c/64 router to LAN.) However it is quite optimistic to think IPv6 would remove completely need for NAT. Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used. Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? Finally, if you think that non-multihomed end sites need PI, then, put a proposal in to change the RIR policies. RIR policies are not immutable. Each RIR has a bottom-up consensus driven process. If you don't like the policies, it really isn't that hard to get them changed. (I say this as an author of the first successful policy to create IPv6 PI) This is non-technical problem, enterprises of non-trivial size can't typically even tell without months of research all the devices and software where they've written down the IP addresses. Sounds like they haven't written them down very well. RFC4193 + NAT quite simply is what they know and are comfortable with. It would be hard sell to ask them to design whole IPv6 infra so that they can confidently renumber it in 15min, like you can with RFC4193+NAT. Why would you need to renumber in 15 minutes? It's easy enough to do in a week, given the above RA-based process. Owen
Re: Addressing plan exercise for our IPv6 course
On (2010-07-24 02:13 -0700), Owen DeLong wrote: This is non-technical problem, enterprises of non-trivial size can't typically even tell without months of research all the devices and software where they've written down the IP addresses. Sounds like they haven't written them down very well. Exactly, unfortunately this is reality in many enterprises today. And it is optimistic to hope any technical change will fix the situation. It would be excessively easy to renumber IPv4 infrastructure if it was built with that goal, yet it can be multiyear MUSDs gig to integrator. -- ++ytti
Re: Caribbean Network Operators Group Inaugural Meeting in St Maarten August 15th to 20th 2010
André - Nice program. Congratulations and bonne chance! - Lucy On Fri, 23 Jul 2010, André Edwards wrote: Invitation to CARIBNOG 1 -- August 15th – 20th, 2010 Westin Hotel Resort 144 Oyster Pond Road St Maarten -- Dear colleagues, members of the Lacnic community. The Caribbean Network Operators Group (CARIBNOG) has the pleasure of announcing and inviting you to participate in the first Regional CaribNOG meeting, CARIBNOG 1, from August 15th – 20th, 2010. The event will be held at the Westin Hotel and Resort in the beautiful island of St. Maarten during the Inaugural St. Maarten’s ICT Week which is being hosted by the Government of St. Maarten and the Caribbean Telecommunications Union (CTU). The Caribbean Network Operators Group (CaribNOG) is a community of Network Operators dedicated to exchanging technical information and experiences related to the management of IP networks in the Caribbean region. CaribNOG conferences provide a forum for the coordination and dissemination of technical information related to networking technologies, research and operational practices. The meetings are informal, with an emphasis on practical solutions, training and insight relevant to the region. In St. Maarten, expert speakers from the regional and international technical community will be conducting hands-on workshops, in-depth tutorials and presentations on the following topics: · VoIP: VOIP workshop – Deploying secure small and medium Scale VoIP solutions · LINUX: Configuring and Securing LAMP, creating a secure LAMP application, IP Services and Security · ROUTING: Basics; introduction to OSPF, BGP, VoIP and SIP · CSIRT: Developing a Network Security and Incident Response Team. You are welcome to join us in St Maarten for this inaugural meeting. More detailed information on the event and its program, accommodation, registration, and general information will soon be available on CARIBNOG's website: www.caribnog.org Sincerely, Andre Edwards CARIBNOG 1 Program Committee
Proposed Global Policy for Autonomous System Numbers - Final Call for Comments and Background Report
Proposed Global Policy for Autonomous System Numbers - Final Call for
Comments and Background Report
http://www.icann.org/en/announcements/announcement-23jul10-en.htm
-- Forwarded message --
From: IPv3.com ipv3@gmail.com
Date: Sat, Jul 24, 2010 at 7:45 AM
Subject: ASN IANA MLM Leasing Business Out-Dated - Now Automated
To: asn-proposal-2...@icann.org
ASN IANA MLM Leasing Business Out-Dated - Now Automated
Selling or leasing UNIQUE binary values is no longer viable because
.COM owners can derive them FREE
With IPv3 and IPv16 a simple 6-bit Alphabet (Symbol Set) is used for
mapping UNIQUE binary values
64 symbols - 6-bits - {[0-9][A-Z][a-z]-.}
A 5-Letter .COM owner can create a UNIQUE 30-bit ASN for FREE via the
6-bit Alphabet
If upper and lower case symbols are used, several FREE ASNs can be generated
A $6 annual fee for the .COM registration covers all of the costs
needed to generate UNIQUE binary values
The 4-Letter .COM owners can generate several FREE 24-bit prefixes
(called /24s) for IPv* Addressing
ASN IANA MLM Leasing Business Out-Dated - Now Automated
4096 Trending TLD selections are also automated
ICANN and the RIRs can be Dissolved
Re: Addressing plan exercise for our IPv6 course
Owen DeLong wrote: Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. Because, although one of the original goals of IPv6 was for hosts to be easily multihomed at multiple addresses like this, host software (and even some of the required specifications) isn't really isn't there yet, and often the wrong thing happens. Never mind that the timescale for IPv6 deployment, no matter how long it is, will be shorter than the timescale for updating PCI, HIPPA, and SOX audit checklists to remove the requirements around hide internal topology and do not use public addresses on any interface of critical hosts. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? This would *also* require multihoming to actually work properly, only worse as the rules for selecting ULA vs PA routes are usually more right than the rules for selecting one PA vs another PA as an outbound interface, even if your host does multiple default routes properly. Even if all your hosts end up with external connectivity that works, the odds that they can reliably talk to each other is low. Matthew Kaufman
Router/switch vendor recommendations? off-list replies fine
I'm trying to find versatile vendors that can handle a variety of features that meet my needs for several projects. Honestly, the projects aren't that big, but I'd like certain versatility with them, and having trouble finding the right vendors. Perhaps it's just my engineering that is flawed. Suscriber management (both a redundant and non-redundant unit) - PPPoE (4/6) - DHCP (4/6) - IPv6 support for both with reasonable management plans - option 82 (DHCPv6 have an equiv option?) - backend support for DHCP (preferably both radius and DHCP) - q-in-q L3 termination w/ proxy-arp support - LAG for at least 2 Gig-E - line rate L3 speeds - support for OC3 SONET a plus - support for OC3 ATM with RBE type setup a plus - isis (4/6) multi-topology - BGP4 (4/6) NSR a plus L2 Switch (redundant) - LAG (40Gig+ ring) - Line rate - 8100 in 8100 (simple q-in-q) - ability to take untagged traffic on port and arbitrarily provide it double tags (one to send across network, and the inner to drop on a trunk to an aggregation site for customer) Basic q-in-q but customer doesn't have ability to assign vlan on their side. - standard guards for spanning tree, dhcp, IPv6 etc. - rj45 10/100, mm-fx 100, sm-fx 100/1000 CPE switch (for customer who can't terminate fiber or for extending our testing demarc) -1 to 2 rj45 100/1000 -1 to 2 sm-fx 100/1000 -inexpensive, small
Re: Addressing plan exercise for our IPv6 course
On Sat, 2010-07-24 at 08:50 -0700, Matthew Kaufman wrote: Even if all your hosts end up with external connectivity that works, the odds that they can reliably talk to each other is low. I hope I'm not taking the above quote out of context, but why do you think this? How does the fact that interfaces on your host may have more than one public address translate into low odds that they can talk to each other? The only thing I can think of is that if an interface in your network has a public address from only one provider, and another interface in your network has a public address only from another provider, then the connection will go out through one provider and back in from the other, which would be less than optimal. On the other hand, there is no reason to think this would be particularly unreliable, and if such a situation existed it would either indicate a fault or be what you actually wanted. The discussion was in the context of a renumbering exercise. Using the simple method of having a period where both provider ranges are active and allowing the old provider range to time out may result in lost connections; there may also be caching difficulties with some applications. Neither situation is long-lived, and both can be mitigated by careful planning. Is that what you meant? Maybe I've missed your point. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: Addressing plan exercise for our IPv6 course
Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better. Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used. I think that will be a common PI alternative. If people really don't want NAT then we shouldn't provide reasons for it to exist. RFC4193 seems to be the best enterprise plan. They can link to other enterprises and change ISPs easily or multihome. They are not beholden to any ISP or numbering authority. The global table doesn't explode. Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. Enterprises tend to want only one identifier to manage per device and that it be unique and mostly permanent. With several PA and ULA on each device, links to ISPs and other enterprises, the combinations of addresses and paths to manage flows and security over become too hard (if it's not simple it's probably not secure). Every device becomes a router and firewall and the staff who manage those aren't cheap. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? And changing all the ACLs based on the old providers addresses And allowing for all the 5 - 15 year old kit that predates this and won't be upgraded (we have that problem with NT embedded in systems with 10year+ refresh cycle) brandon
Re: IPv4 Exhaustion...
What's crazy is: a) How each org/company seems to be handling these notices themselves. b) How they seem to be filtering down to operations people to sort out. Seems like an opportunity for some lawyers to form a membership association. Agree to some reasonable policy, send them your RIAA (et al, because this kind of thing is growing like kudzu) takedowns, they'll respond or tell you what you should do to satisfy (if anything.) This would let that org develop some leverage with RIAA et al, if we don't hang together we will surely hang separately, RIAA is taking advantage of this, their lawyers know full well how a+b above can be exploited. I sat in an intellectual property constituency meeting at ICANN which was basically me, and 100+ lawyers. Their main topic was takedowns, and how horrible it was that ISPs et al don't just reformat all their disks on receipt of a lawyer letter on nice letterhead, the bastards (i.e., us) start demanding court orders etc, outrageous! expensive! burdensome! I told some quick anecdotes about phony takedown demands (e.g., painful divorce or business partner fights) and my inability/reluctance to accurately judge these things beyond the most obvious. I can't say they weren't receptive, it was a little bit of a WAKE UP AND SMELL THE COFFEE, TAKEDOWNS ARE VALUABLE CONSIDERATIONS! which they understood, and the potential liability aspects for an ISP. Anyhow my take is that takedowns are a growth industry. -- -Barry Shein The World | b...@theworld.com | http://www.TheWorld.com Purveyors to the Trade | Voice: 800-THE-WRLD| Dial-Up: US, PR, Canada Software Tool Die| Public Access Internet | SINCE 1989 *oo*
Re: Caribbean Network Operators Group Inaugural Meeting in St Maarten August 15th to 20th 2010
Thanks for the support everyone. Our hope is for the community to grow as a rich resource. Look out for more updates. Regards, On Sat, Jul 24, 2010 at 8:47 AM, Lucy Lynch lly...@civil-tongue.net wrote: André - Nice program. Congratulations and bonne chance! - Lucy On Fri, 23 Jul 2010, André Edwards wrote: Invitation to CARIBNOG 1 -- August 15th – 20th, 2010 Westin Hotel Resort 144 Oyster Pond Road St Maarten -- Dear colleagues, members of the Lacnic community. The Caribbean Network Operators Group (CARIBNOG) has the pleasure of announcing and inviting you to participate in the first Regional CaribNOG meeting, CARIBNOG 1, from August 15th – 20th, 2010. The event will be held at the Westin Hotel and Resort in the beautiful island of St. Maarten during the Inaugural St. Maarten’s ICT Week which is being hosted by the Government of St. Maarten and the Caribbean Telecommunications Union (CTU). The Caribbean Network Operators Group (CaribNOG) is a community of Network Operators dedicated to exchanging technical information and experiences related to the management of IP networks in the Caribbean region. CaribNOG conferences provide a forum for the coordination and dissemination of technical information related to networking technologies, research and operational practices. The meetings are informal, with an emphasis on practical solutions, training and insight relevant to the region. In St. Maarten, expert speakers from the regional and international technical community will be conducting hands-on workshops, in-depth tutorials and presentations on the following topics: · VoIP: VOIP workshop – Deploying secure small and medium Scale VoIP solutions · LINUX: Configuring and Securing LAMP, creating a secure LAMP application, IP Services and Security · ROUTING: Basics; introduction to OSPF, BGP, VoIP and SIP · CSIRT: Developing a Network Security and Incident Response Team. You are welcome to join us in St Maarten for this inaugural meeting. More detailed information on the event and its program, accommodation, registration, and general information will soon be available on CARIBNOG's website: www.caribnog.org Sincerely, Andre Edwards CARIBNOG 1 Program Committee -- André M Edwards The Caribbean must be one! http://www.integratemenow.com/ http://www.myrx7story.com
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 6:40 PM, Brandon Butterworth wrote: Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. Oh, we have the technology. It's called memory. Speaking from the perspective of a vendor, I'll happily sell it to you. Don't complain to me about the size of the route table, don't complain to me about heat or power requirements, and don't complain to me about convergence intervals. I'll tell you that you designed the bed you wanted to sleep in, and it was all yours.
Re: Addressing plan exercise for our IPv6 course
Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better. Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. Did you mean something like this maybe ?: http://www.sixxs.net/tools/grh/ula/
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 8:50 AM, Matthew Kaufman wrote: Owen DeLong wrote: Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. Because, although one of the original goals of IPv6 was for hosts to be easily multihomed at multiple addresses like this, host software (and even some of the required specifications) isn't really isn't there yet, and often the wrong thing happens. Host software is there, but, it requires some education on how to configure it. You do have to properly set up the rules for which addresses to use for what communication properly. It breaks less if you forego the ULA brokenness, but, some people insist for whatever reason. Never mind that the timescale for IPv6 deployment, no matter how long it is, will be shorter than the timescale for updating PCI, HIPPA, and SOX audit checklists to remove the requirements around hide internal topology and do not use public addresses on any interface of critical hosts. I expect the PCI changes to be out in less than a year. HIPPA and SOX may take closer to two years, maybe even three. I don't expect enterprise-wide adoption of IPv6 to be significant in less than 5 years. The big push for IPv6 right now needs to be on the public-facing services side which doesn't have hidden topology by definition. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? This would *also* require multihoming to actually work properly, only worse as the rules for selecting ULA vs PA routes are usually more right than the rules for selecting one PA vs another PA as an outbound interface, even if your host does multiple default routes properly. Even if all your hosts end up with external connectivity that works, the odds that they can reliably talk to each other is low. Why use rules for selection... Simply have the RAs contain proper priorities for the ones you want to use at any particular moment and change the RA priorities as needed. Owen
Re: Addressing plan exercise for our IPv6 course
Eventually ARIN (or someone else will do it for them) may create a site ... Did you mean something like this maybe ?: http://www.sixxs.net/tools/grh/ula/ Q.E.D. The RFC seeks to avoid a registry so we end up with the potential for many as a result. May as well have had ARIN do it officially in the first place so there'd only be one. brandon
Re: Addressing plan exercise for our IPv6 course
Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. Oh, we have the technology. It's called memory If that were viable then we'd be doing it. Speaking from the perspective of a vendor, I'll happily sell it to you. Don't complain to me about the size of the route table, don't complain to me about heat or power requirements, and don't complain to me about convergence intervals. I'll tell you that you designed the bed you wanted to sleep in, and it was all yours. Indeed, best not listen to vendors brandon
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 9:23 AM, Karl Auer wrote: On Sat, 2010-07-24 at 08:50 -0700, Matthew Kaufman wrote: Even if all your hosts end up with external connectivity that works, the odds that they can reliably talk to each other is low. I hope I'm not taking the above quote out of context, but why do you think this? How does the fact that interfaces on your host may have more than one public address translate into low odds that they can talk to each other? The only thing I can think of is that if an interface in your network has a public address from only one provider, and another interface in your network has a public address only from another provider, then the connection will go out through one provider and back in from the other, which would be less than optimal. On the other hand, there is no reason to think this would be particularly unreliable, and if such a situation existed it would either indicate a fault or be what you actually wanted. I would think even that would be unlikely as the border routers would most likely know routes to both sets of internal addresses and worst case, the packets should hairpin inside the border router rather than being forwarded to the external providers. Ideally, this hairpinning should be designed to occur prior to reaching the firewall, or, the firewall(s) must have rulesets to enable such. However, either solution is easily implemented in most topologies. Owen
Re: Addressing plan exercise for our IPv6 course
On Sat, 2010-07-24 at 10:42 -0700, Owen DeLong wrote: You do have to properly set up the rules for which addresses to use for what communication properly. It breaks less if you forego the ULA brokenness, but, some people insist for whatever reason. What is the ULA brokenness? Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 9:40 AM, Brandon Butterworth wrote: Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better. Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. SIXXS already has such a registry with a pretty low adoption rate. I still fail to see any advantage whatsoever to this approach and I think that the limited number of sites that implement it is unlikely to get continued support from ISVs. I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used. I think that will be a common PI alternative. If people really don't want NAT then we shouldn't provide reasons for it to exist. RFC4193 seems to be the best enterprise plan. They can link to other enterprises and change ISPs easily or multihome. They are not beholden to any ISP or numbering authority. The global table doesn't explode. I agree that easier to get PI addresses is a better alternative. I will support policy initiatives to do that. RFC4193 remains an utterly horrible idea and NATing it to the public internet remains even worse. Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. Enterprises tend to want only one identifier to manage per device and that it be unique and mostly permanent. Right... That identifier is the EUI-64 which is both permanent and unique. The prefix changes when you switch providers, but, that's mostly not particularly horrible since there are tools to make that easier for the bulk of internal hosts. With several PA and ULA on each device, links to ISPs and other enterprises, the combinations of addresses and paths to manage flows and security over become too hard (if it's not simple it's probably not secure). Every device becomes a router and firewall and the staff who manage those aren't cheap. Actually, if you set things up correctly, most of the security stuff to manage is about the same because you hairpin the stuff that doesn't need filtration at a point before it hits the packet filters. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? And changing all the ACLs based on the old providers addresses Mostly this is a pretty straight forward copy-search-replace problem with prefix changes that can be done with the equivalent of an s/x/y/g construct. And allowing for all the 5 - 15 year old kit that predates this and won't be upgraded (we have that problem with NT embedded in systems with 10year+ refresh cycle) That kit won't support IPv6, so, I fail to see the relevance. Any kit that supports IPv6 supports this. Owen
Re: Addressing plan exercise for our IPv6 course
On Sat, 2010-07-24 at 18:49 +0100, Brandon Butterworth wrote: Did you mean something like this maybe ?: http://www.sixxs.net/tools/grh/ula/ Q.E.D. The RFC seeks to avoid a registry so we end up with the potential for many as a result. May as well have had ARIN do it officially in the first place so there'd only be one. The RFC provides for two address ranges in fc00::/7, one for random prefixes (fc00::/8), the other reserved for later management (fd00::/8). Sixxs manages prefixes from within the random one, there is as yet nothing set up to properly manage the other one. Dunno why ARIN should necessarily manage it; or any particular RIR for that matter. The random one allows for swift, bureaucracy-free self-allocation. The more important it is to you that your allocation be unique, the more careful you will be to choose a truly random one. The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. Makes it an interesting question as to whether the managed range is really necessary at all. Regards, K. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Re: Addressing plan exercise for our IPv6 course
The RFC provides for two address ranges in fc00::/7, one for random prefixes (fc00::/8), the other reserved for later management (fd00::/8). Later, in some undefined way. A PI lacking enterprise considering doing v6 this way either waits or decides the available space will do as someone will fix the managment later. Sixxs demonstrated that some will see a need With low take up of v6 it's early to know what they will see important The more important it is to you that your allocation be unique, the more careful you will be to choose a truly random one. So a way to have really unique is reasonable. The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. People still play the lotteries. brandon
Re: Addressing plan exercise for our IPv6 course
Karl Auer wrote: The random one allows for swift, bureaucracy-free self-allocation. The more important it is to you that your allocation be unique, the more careful you will be to choose a truly random one. If it is that important, you'd prefer a managed solution, not a truly random one. The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. Makes it an interesting question as to whether the managed range is really necessary at all. 1) While the chance of conflict is small, it is not non-existent, and when the interaction does occur and a conflict does arise, there may be huge costs involved. Random is fine for small deployments. It is a horrifying prospect for a 500+ subnet network. 2) Managing non-globally routed addressing is easy and doesn't require a lot of overhead. IANA itself could manage it, as it does all other globally unique numbers. First come, first serve. Have a nice day. I enjoy my unique enterprise oid. Why shouldn't I enjoy my own unique non-globally routed address space identifier? There shouldn't be a need for justification of the identifier (or services such as whois), so pawning it off on a RIR seems silly. Jack
33-Bit Addressing via ONE bit or TWO bits ? does NANOG care?
33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? As some people (who understand IPv4) know, there is a SINGLE spare/unused bit in the IPv4 header that can be set to 0 or 1. Some religions require that it be set to 0. Adult content is marked with a 1. That single bit can be viewed as common between the Source and Destination creating a 33rd bit of addressing. Since it is a single bit, it is welded together for both Source and Destination. 0-Normal 1-Evil/Other/Adult/XXX In anticipation of expanding to 33-bit addressing, another bit was deprecated years ago. It can now be used to UNWELD the EVIL bit. That would allow EVIL to be only for the Source. The Destination would have its own EVIL bit. If two bits are used, then the potential to communicate between the previously welded address spaces arises. Some enforcement could still be used in Edge Network Elements to make sure both bits are 0 or both 1. Enforcements are hard to maintain and full 33-bit addressing may emerge. As an aside, NAT was primarily added to improve the .NET Architecture with a Flash Upgrade-able Network Element. It is a shame that IPv6 salesman do not seem to understand Architecture. They continue on the [NAT is Evil] path. NANOG can play an important role in shaping how Address Plans for North America evolve. Since Network Elements are going to be flash upgraded for the new DNS, it is easy to (unweld/change) the 33-bit addressing for .XXX The 33-bit addressing works into the 66-bit Triple-Tagged VLAN addressing with Content Rating. http://en.wikipedia.org/wiki/IEEE_802.1Q The Locator is 33-bits and the ID is 33-bits. Both are UNIQUE. Both fit in the IPv4 foot-print. The three-ring circus architecture emerges. (((Core)Edge)Fringe) does NANOG care? is NANOG now Fringe ?
Re: IPv4 Exhaustion...
On Sat, Jul 24, 2010 at 4:48 AM, Owen DeLong o...@delong.com wrote: Rough translation: LSN + CALEA = Very Interesting Times for ISPs that deploy LSN and are subject to CALEA. why wouldn't you just do the intercept before the LSN? (also, calea and it's ilk knew this was coming, 'your failure to plan...' and all that jazz)
Re: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care?
I am very curious to see how this would play with networks that wouldn't support such a technology. How would you ensure communication between a network that supported 33-Bit addressing and one that doesn't? On 7/24/10 3:26 PM, IPv3.com wrote: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care? As some people (who understand IPv4) know, there is a SINGLE spare/unused bit in the IPv4 header that can be set to 0 or 1. Some religions require that it be set to 0. Adult content is marked with a 1. That single bit can be viewed as common between the Source and Destination creating a 33rd bit of addressing. Since it is a single bit, it is welded together for both Source and Destination. 0-Normal 1-Evil/Other/Adult/XXX In anticipation of expanding to 33-bit addressing, another bit was deprecated years ago. It can now be used to UNWELD the EVIL bit. That would allow EVIL to be only for the Source. The Destination would have its own EVIL bit. If two bits are used, then the potential to communicate between the previously welded address spaces arises. Some enforcement could still be used in Edge Network Elements to make sure both bits are 0 or both 1. Enforcements are hard to maintain and full 33-bit addressing may emerge. As an aside, NAT was primarily added to improve the .NET Architecture with a Flash Upgrade-able Network Element. It is a shame that IPv6 salesman do not seem to understand Architecture. They continue on the [NAT is Evil] path. NANOG can play an important role in shaping how Address Plans for North America evolve. Since Network Elements are going to be flash upgraded for the new DNS, it is easy to (unweld/change) the 33-bit addressing for .XXX The 33-bit addressing works into the 66-bit Triple-Tagged VLAN addressing with Content Rating. http://en.wikipedia.org/wiki/IEEE_802.1Q The Locator is 33-bits and the ID is 33-bits. Both are UNIQUE. Both fit in the IPv4 foot-print. The three-ring circus architecture emerges. (((Core)Edge)Fringe) does NANOG care? is NANOG now Fringe ? -- Steve King Senior Linux Engineer - Advance Internet, Inc. Cisco Certified Network Associate CompTIA Linux+ Certified Professional CompTIA A+ Certified Professional
Re: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care?
On Sat, 2010-07-24 at 15:50 -0400, Steven King wrote: I am very curious to see how this would play with networks that wouldn't support such a technology. How would you ensure communication between a network that supported 33-Bit addressing and one that doesn't? 33-bit is a fucking retarded choice for any addressing scheme as it's neither byte nor nibble-aligned. Infact, the 33rd bit would ensure that an IPv4 header had to have 5 byte addresses. William
Re: 33-Bit Addressing via ONE bit or TWO bits ? does NANOG care?
isn't ipv3@gmail.com jim fleming? http://www.ietf.org/mail-archive/web/ietf/current/msg04279.html (for reference) pls to not be replying to the list when ipv3.com posts to nanog.. -Chris On Sat, Jul 24, 2010 at 4:17 PM, William Pitcock neno...@systeminplace.net wrote: On Sat, 2010-07-24 at 15:50 -0400, Steven King wrote: I am very curious to see how this would play with networks that wouldn't support such a technology. How would you ensure communication between a network that supported 33-Bit addressing and one that doesn't? 33-bit is a fucking retarded choice for any addressing scheme as it's neither byte nor nibble-aligned. Infact, the 33rd bit would ensure that an IPv4 header had to have 5 byte addresses. William
Re: Addressing plan exercise for our IPv6 course
On Sat, 24 Jul 2010 18:49:55 BST, Brandon Butterworth said: The RFC seeks to avoid a registry so we end up with the potential for many as a result. May as well have had ARIN do it officially in the first place so there'd only be one. Given our failure rate with registries of AS numbers, IP address blocks, and routing table entries, and the fact we have no special reason to believe that we'll be able to sprinkle Magic ULA Dust all over it and avoid all the failure modes of registries, we're probably better off just randomly generating them and just hope for no collisions. pgpx25ILrqzKX.pgp Description: PGP signature
Re: IPv4 Exhaustion...
On Sat, 24 Jul 2010 15:40:58 EDT, Christopher Morrow said: why wouldn't you just do the intercept before the LSN? That gets interesting too, when several tens of thousands of users may all be behind the same LSN. Making sure you intercept only the right user's traffic gets a lot more interesting in front of the LSN. Doing it behind the LSN means you can snarf up just the traffic heading to/from one NAT'ed IP, which is hopefully changing not all that often. Doing it in front of the LSN means you need to decide whether to capture the data in real time on a per-flow basis (consider the fun involved in catching a SYN packet outbound - what's your time budget between when the miscreant's packet leaves his host and when you have to catch it on the outbound side of the LSN)... pgpeSDvOvQW7q.pgp Description: PGP signature
Re: IPv4 Exhaustion...
On Sat, Jul 24, 2010 at 4:28 PM, valdis.kletni...@vt.edu wrote: On Sat, 24 Jul 2010 15:40:58 EDT, Christopher Morrow said: why wouldn't you just do the intercept before the LSN? That gets interesting too, when several tens of thousands of users may all be behind the same LSN. Making sure you intercept only the right user's traffic gets a lot more interesting in front of the LSN. Doing it behind the LSN means you can snarf up just the traffic heading to/from one NAT'ed IP, which is hopefully changing not all that often. Doing it in front of the LSN means you need to decide whether to capture the data in real time on a per-flow basis (consider the fun involved in catching a SYN packet outbound - what's your time budget between when the miscreant's packet leaves his host and when you have to catch it on the outbound side of the LSN)... innocent until proven guilty... plus probably a large portion of the calea things aren't for a 'miscreant' anyway but for other reasons. say, i wonder how many actual calea requests have been sent out anyway?? (I know one very large network has yet to get a single one, or so the grape vine tells me.)
North Korea conflict with US and South Korea could spark cyber war
n3td3v Security is monitoring the situation between North Korea, US and South Korea. North Korea has already threatened to use its nuclear arms when the wargames begin Sunday by United States and South Korea, but n3td3v Security predicts North Korea is planning a large scale cyber attack on US interests. We could really see the first cyber war proper here when it all kicks off Sunday between US, S.Korea and the North. n3td3v Security is warning critical infrastructure utility companies to keep an eye on its cyber assets incase NK's cyber command launch any attack. Andrew Wallace http://sites.google.com/site/n3td3v/
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 11:41 AM, Brandon Butterworth wrote: The RFC provides for two address ranges in fc00::/7, one for random prefixes (fc00::/8), the other reserved for later management (fd00::/8). Later, in some undefined way. A PI lacking enterprise considering doing v6 this way either waits or decides the available space will do as someone will fix the managment later. Sixxs demonstrated that some will see a need Or they forego the kludge and go with PA v6 realizing that they can do overlapping PA v6 transitions with relative ease when they switch providers. Of course during that time of overlap, they are technically multi-homed, so, there are other options as well. With low take up of v6 it's early to know what they will see important Yep. Enterprises are really the least of the concerns right now as well. We have about a year, maybe less to try and get public-facing stuff dual-stacked. We have lots of time yet to address the enterprise issues. The more important it is to you that your allocation be unique, the more careful you will be to choose a truly random one. So a way to have really unique is reasonable. I think the simplest approach is simply to multihome and get a PI assignment if you don't want to live with PA. That's the cleanest approach too with the added benefit that you can load-balance and gain some redundancy and other optimizations in the process. The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. People still play the lotteries. My favorite definition of the term Lottery is: Lottery (n): A tax on people who are bad at math. Owen
Re: North Korea conflict with US and South Korea could spark cyber war
I cant check that link out right now, but if what you say is true, this would be very serious. Can anyone confirm this? On 7/24/10, andrew.wallace andrew.wall...@rocketmail.com wrote: n3td3v Security is monitoring the situation between North Korea, US and South Korea. North Korea has already threatened to use its nuclear arms when the wargames begin Sunday by United States and South Korea, but n3td3v Security predicts North Korea is planning a large scale cyber attack on US interests. We could really see the first cyber war proper here when it all kicks off Sunday between US, S.Korea and the North. n3td3v Security is warning critical infrastructure utility companies to keep an eye on its cyber assets incase NK's cyber command launch any attack. Andrew Wallace http://sites.google.com/site/n3td3v/ -- Sent from my mobile device Regards, James. http://www.jamesbensley.co.cc/ There are 10 kinds of people in the world; Those who understand Vigesimal, and J others...?
Re: North Korea conflict with US and South Korea could spark cyber war
James, 1. cyberwar is bullsh*t, always has been, always will be. 2. we are risking a cyberwar (which is, as previously mentioned, bullsh*t) with North Korea which can't even feed itself, let alone buy things like computers, or real internet access. So, yes you can knock out root name servers for a few hours, it has been done by the way, and only people on this list really noticed. The tactical loss of those name servers won't slow down the components of the US military which are now bombing your country. With this point we get to why cyberwar is bullsh*t. Bombs blow stuff up, soldiers shoot and kill people, tanks blow stuff up, big ships with huge cannons blow stuff up. This sort of stuff has to be rebuilt. Launching a crippling internet attack slow down the flow of e-mail, and while this might make our day a bit harder if the blackberry doesn't beep happily every minute and a half, in comparison to bombing, or getting shot, or blown up, or shelled by battleships, e-mail is pretty insignificant. Andrew On 7/24/2010 6:49 PM, James Bensley wrote: I cant check that link out right now, but if what you say is true, this would be very serious. Can anyone confirm this? On 7/24/10, andrew.wallaceandrew.wall...@rocketmail.com wrote: n3td3v Security is monitoring the situation between North Korea, US and South Korea. North Korea has already threatened to use its nuclear arms when the wargames begin Sunday by United States and South Korea, but n3td3v Security predicts North Korea is planning a large scale cyber attack on US interests. We could really see the first cyber war proper here when it all kicks off Sunday between US, S.Korea and the North. n3td3v Security is warning critical infrastructure utility companies to keep an eye on its cyber assets incase NK's cyber command launch any attack. Andrew Wallace http://sites.google.com/site/n3td3v/
Re: North Korea conflict with US and South Korea could spark cyber war
On 7/24/10 3:49 PM, James Bensley jwbens...@gmail.com wrote: I cant check that link out right now, but if what you say is true, this would be very serious. Can anyone confirm this? The North Koreans have historically threatened to go to war whenever the US and South Korea are performing military exercises in the region. I have no idea how the threat of nuclear conflict equates to a cyber attack. Perhaps n3td3v would like to provide something a little more concrete about the origin of their prediction. Mike
Re: North Korea conflict with US and South Korea could spark cyber war
On 7/24/2010 7:44 PM, Ryan Rawdon wrote: Can you provide information to back this up? At first glance glance I am having a hard time believing this is anything but speculation, but would be interested to hear more. That is because n3td3v is a troll. Please do not feed, thx. Andrew
Re: North Korea conflict with US and South Korea could spark cyber war
Maybe we should check snopes.com. Haha. Excuse the spelling/punctuation, this is sent from my mobile device... ChrisFenton On Jul 24, 2010, at 4:46 PM, Ryan Rawdon r...@u13.net wrote: On Sat, 24 Jul 2010 14:22:56 -0700 (PDT), andrew.wallace andrew.wall...@rocketmail.com wrote: n3td3v Security is monitoring the situation between North Korea, US and South Korea. North Korea has already threatened to use its nuclear arms when the wargames begin Sunday by United States and South Korea, but n3td3v Security predicts North Korea is planning a large scale cyber attack on US interests. We could really see the first cyber war proper here when it all kicks off Sunday between US, S.Korea and the North. n3td3v Security is warning critical infrastructure utility companies to keep an eye on its cyber assets incase NK's cyber command launch any attack. Andrew Wallace http://sites.google.com/site/n3td3v/ Can you provide information to back this up? At first glance glance I am having a hard time believing this is anything but speculation, but would be interested to hear more.
Re: Addressing plan exercise for our IPv6 course
On Sat, 2010-07-24 at 14:07 -0500, Jack Bates wrote: The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. Makes it an interesting question as to whether the managed range is really necessary at all. 1) While the chance of conflict is small, it is not non-existent, and when the interaction does occur and a conflict does arise, there may be huge costs involved. Random is fine for small deployments. It is a horrifying prospect for a 500+ subnet network. If two (or four, or ten, or a thousand) ULA prefixes are chosen randomly, the chance that any will conflict with any others is far, far less than the chance that your staff will make a terrible, disastrous mistake that puts you out of commission for weeks. And if you happen to have contingency plans for that, they will do just fine for dealing with a ULA conflict.[1] And of course, to be an actual problem the conflicting prefixes have to be in use by entities whose networks actually interact. Within an administrative domain, uniqueness can be guaranteed anyway. Winning a lottery is *far* more likely[2] than that a randomly chosen prefix from the ULA range will conflict with any other prefix in the same range, randomly chosen or not. Regards, K. [1] A ULA conflict is generally not going to require instant remedial action. People planning interaction at a network level will (one hopes!) do basic stuff like checking what prefixes are in use on the two networks. [2] Depending on the number of players in each game, anything from hundreds of times more likely to millions of times more likely. -- ~~~ Karl Auer (ka...@biplane.com.au) +61-2-64957160 (h) http://www.biplane.com.au/~kauer/ +61-428-957160 (mob) GPG fingerprint: B386 7819 B227 2961 8301 C5A9 2EBC 754B CD97 0156 Old fingerprint: 07F3 1DF9 9D45 8BCD 7DD5 00CE 4A44 6A03 F43A 7DEF signature.asc Description: This is a digitally signed message part
Fwd: Re: North Korea conflict with US and South Korea could spark cyber war
Original Message Subject: Re: North Korea conflict with US and South Korea could spark cyber war Date: Sat, 24 Jul 2010 17:04:23 -0700 (PDT) From: andrew.wallace andrew.wall...@rocketmail.com To: Andrew Kirch trel...@trelane.net Continue to call me a troll in public and I'll be seeking legal advice. - Original Message From: Andrew Kirchtrel...@trelane.net To: nanog@nanog.org Sent: Sun, 25 July, 2010 0:46:28 Subject: Re: North Korea conflict with US and South Korea could spark cyber war That is because n3td3v is a troll. Please do not feed, thx. Andrew QED.
Re: Fwd: Re: North Korea conflict with US and South Korea could spark cyber war
Normally, I wouldn't top post, but in just this one instance... Andrew Wallace, aka n3td3v, and one of the few people to EVER be banned from Full Disclosure, is a troll. Please don't copy his message back when you reply to him, since most of us long ago dropped him in the kill file. Everywhere. Legal advice. Hah. Could this now please end? On 7/24/2010 5:44 PM, Andrew Kirch wrote: Original Message Subject: Re: North Korea conflict with US and South Korea could spark cyber war Date: Sat, 24 Jul 2010 17:04:23 -0700 (PDT) From: andrew.wallace andrew.wall...@rocketmail.com To: Andrew Kirch trel...@trelane.net Continue to call me a troll in public and I'll be seeking legal advice. - Original Message From: Andrew Kirchtrel...@trelane.net To: nanog@nanog.org Sent: Sun, 25 July, 2010 0:46:28 Subject: Re: North Korea conflict with US and South Korea could spark cyber war That is because n3td3v is a troll. Please do not feed, thx. -- Injustice is relatively easy to bear; what stings is justice. H.L. Mencken
Re: North Korea conflict with US and South Korea could spark cyber war
On Sat, 24 Jul 2010, Andrew Kirch wrote: On 7/24/2010 7:44 PM, Ryan Rawdon wrote: Can you provide information to back this up? At first glance glance I am having a hard time believing this is anything but speculation, but would be interested to hear more. That is because n3td3v is a troll. Please do not feed, thx. It does indeed seem to be tool/net.kook day here on NANOG. I didn't check to see if there is supposed to be a full moon tonight. jms
Re: Fwd: Re: North Korea conflict with US and South Korea could spark cyber war
I'd request that anyone with evidence that Andrew Wallace had inappropriate contact with a minor male child in 1999, please contact me off-list. Thanks, and this will be my last response to anything regarding Mr. Wallace publicly as I'll no longer be seeing much of him. Andrew
Re: North Korea conflict with US and South Korea could spark cyber war
On 7/24/2010 2:10 PM, Justin M. Streiner wrote: ... It does indeed seem to be tool/net.kook day here on NANOG. I didn't check to see if there is supposed to be a full moon tonight. jms Close! Full Moon on 25 July 2010 at 9:37 p.m. Eastern Daylight Time.
Re: North Korea conflict with US and South Korea could spark cyber war
On Sun, Jul 25, 2010 at 2:23 AM, Roy r.engehau...@gmail.com wrote: On 7/24/2010 2:10 PM, Justin M. Streiner wrote: ... It does indeed seem to be tool/net.kook day here on NANOG. I didn't check to see if there is supposed to be a full moon tonight. jms Close! Full Moon on 25 July 2010 at 9:37 p.m. Eastern Daylight Time. They should be banned from Nanog, the rules state: Postings that include foul language, character assassination, and lack of respect for other participants are prohibited. http://nanog.org/mailinglist/ Andrew Wallace
Re: Addressing plan exercise for our IPv6 course
On Jul 24, 2010, at 7:52 PM, Brandon Butterworth wrote: Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. Oh, we have the technology. It's called memory If that were viable then we'd be doing it. We are. I'm told that the fully outfitted top-end routers from Cisco and Juniper can handle tens of millions of routes (as long as you're not in a rush to converge and you have lots of cheap power). Of course, the price of said routers is a bit steep, particularly for smaller ISPs and enterprises, so you'll see a shift in the way the Internet works (perhaps not surprisingly, back towards the way telco networks look with a small number of very large companies). Speaking from the perspective of a vendor, I'll happily sell it to you. Don't complain to me about the size of the route table, don't complain to me about heat or power requirements, and don't complain to me about convergence intervals. I'll tell you that you designed the bed you wanted to sleep in, and it was all yours. Indeed, best not listen to vendors As it is best not to listen to doctors that tell you if you continue chain smoking or eating 5000 calories a day, you'll likely regret it. Regards, -drc
Re: Addressing plan exercise for our IPv6 course
On Sat, 24 Jul 2010 10:57:49 -0700 Owen DeLong o...@delong.com wrote: On Jul 24, 2010, at 9:40 AM, Brandon Butterworth wrote: Enterprises of non-trivial size will likely use RFC4193 (and I fear we will notice PRNG returning 0 very often) and then NAT it to provider provided public IP addresses. Eventually ARIN (or someone else will do it for them) may create a site you can register your address and know that it really is unique among participating registrants. Random is fine, unique is better. Such a site would be the seed for when (if) we come up with the tech for everyone to have PI and lose all the restrictions imposed so far. SIXXS already has such a registry with a pretty low adoption rate. And I think that is good news. The fd00::/8 range is not defined as guaranteed globally unique. I'm concerned that the SIXXS registry could imply to those people who have used it, that it is. They may think that because that registry exists, and that they've used it, that address space it now theirs, and nobody else is allowed to use it. Once somebody perceives ownership of something they believe is unique, I think they commonly won't listen to reason about their actual lack of global ownership. fc00::/8 is for guaranteed globally unique ULAs. I still fail to see any advantage whatsoever to this approach and I think that the limited number of sites that implement it is unlikely to get continued support from ISVs. I'm just hoping that we'll at least see 1:1 NAT instead of NAPT being used. I think that will be a common PI alternative. If people really don't want NAT then we shouldn't provide reasons for it to exist. RFC4193 seems to be the best enterprise plan. They can link to other enterprises and change ISPs easily or multihome. They are not beholden to any ISP or numbering authority. The global table doesn't explode. I agree that easier to get PI addresses is a better alternative. I will support policy initiatives to do that. RFC4193 remains an utterly horrible idea and NATing it to the public internet remains even worse. Well I think RFC4193 is a great idea. I don't want my home network addressing to be bound to having a commercial arrangement with an ISP, or having an active Internet connection. I can also use the ULA prefix as a simple designator of trusted verses untrusted traffic sources in firewall rules. I see those advantages equally applicable to enterprise or ISP networks. Then again, I'm happy with the idea of multiple addresses on an interface, and source address selection. They're not much different to those issues in IPv4, such as unnumbered interfaces on routers, designated source addresses for router SNMP traps etc., or source address selection for policy routing. Why on earth would you do that? Why not just put the provider-assigned addresses on the interfaces along side the ULA addresses? Using ULA in that manner is horribly kludgy and utterly unnecessary. Enterprises tend to want only one identifier to manage per device and that it be unique and mostly permanent. That's IPv4 thinking showing though. People fundamentally don't want change when they don't know of or understand the benefits they will gain. ULAs are an overhead, but they also provide benefits that can't be achieved with global address space assigned by an ISP. (I don't accept the PI argument, because it isn't feasible for residential networks). Right... That identifier is the EUI-64 which is both permanent and unique. The prefix changes when you switch providers, but, that's mostly not particularly horrible since there are tools to make that easier for the bulk of internal hosts. With several PA and ULA on each device, links to ISPs and other enterprises, the combinations of addresses and paths to manage flows and security over become too hard (if it's not simple it's probably not secure). Every device becomes a router and firewall and the staff who manage those aren't cheap. Actually, if you set things up correctly, most of the security stuff to manage is about the same because you hairpin the stuff that doesn't need filtration at a point before it hits the packet filters. This is to facilitate easy and cheap way to change provider. Getting PI address is even harder now, as at least RIPE will verify that you are multihomed, while many enterprises don't intent to be, they just need low cost ability to change operator. Why is that easier/cheaper than changing your RAs to the new provider and letting the old provider addresses time out? And changing all the ACLs based on the old providers addresses Mostly this is a pretty straight forward copy-search-replace problem with prefix changes that can be done with the equivalent of an s/x/y/g construct. And allowing for all the 5 - 15 year old kit that predates this and won't be upgraded (we have that problem with NT embedded in systems with
Re: Addressing plan exercise for our IPv6 course
On Sat, 24 Jul 2010 19:41:18 +0100 (BST) Brandon Butterworth bran...@rd.bbc.co.uk wrote: The RFC provides for two address ranges in fc00::/7, one for random prefixes (fc00::/8), the other reserved for later management (fd00::/8). Later, in some undefined way. A PI lacking enterprise considering doing v6 this way either waits or decides the available space will do as someone will fix the managment later. Sixxs demonstrated that some will see a need With low take up of v6 it's early to know what they will see important The more important it is to you that your allocation be unique, the more careful you will be to choose a truly random one. So a way to have really unique is reasonable. The chance that any random prefix will conflict with any chosen prefix is very, very small. The chance that two conflicting prefixes would belong to entities that will ever actually interact is even smaller. People still play the lotteries. And those people, and some others by the looks of it, don't appear to understand statistics and chance ... brandon
Re: Addressing plan exercise for our IPv6 course
On Sat, 24 Jul 2010, Brandon Butterworth wrote: Eventually ARIN (or someone else will do it for them) may create a site ... Did you mean something like this maybe ?: http://www.sixxs.net/tools/grh/ula/ Q.E.D. The RFC seeks to avoid a registry so we end up with the potential for many as a result. May as well have had ARIN do it officially in the first place so there'd only be one. So, back when ULA was first proposed, some of us said (sometimes privately) that there are only 2 rational options: 1. Do it; with a persistent, guaranteed unique, global registry. 2. Don't do it. Option 2 was a non-starter since there was too much critical mass. The logical candidate to operate option 1 was the IANA, and the RIRs were having none of that. (For bonus points, explain how the RIRs continue to exist if everyone can have all of the guaranteed-globally-unique IPv6 space they wanted for free.) So given the overwhelming force pulling at this thing from both directions, you end up somewhere in the middle where no one wants to be. And BTW, the lottery is actually the perfect analogy for ULA, since no matter how astronomical the odds against, eventually someone always wins. Doug -- Improve the effectiveness of your Internet presence with a domain name makeover!http://SupersetSolutions.com/ Computers are useless. They can only give you answers. -- Pablo Picasso
