RE: IPv6 Training?
You can also try Command Information [EMAIL PROTECTED] or Sunset Learning https://www.coursemax.com/sunset/CourseSchedule.aspx?CourseID=355ef422-32d3- 4379-a950-2087f6b13bcc -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Lucy Lynch Sent: Thursday, May 31, 2007 11:18 AM To: William F. Maton Sotomayor Cc: Alex Rubenstein; NANOG Subject: Re: IPv6 Training? On Thu, 31 May 2007, William F. Maton Sotomayor wrote: On Thu, 31 May 2007, Alex Rubenstein wrote: Does anyone know of any good IPv6 training resources (classroom, or self-guided)? Looking to send several 1st and 2nd tier guys, for some platform/vendor-agnostic training. Internet2 people have been running workshops on multicast and IPv6 separately. http://ipv6.internet2.edu/ Any clues? Thanks.. -- Alex Rubenstein, AR97, K2AHR, [EMAIL PROTECTED], latency, Al Reuben Net Access Corporation, 800-NET-ME-36, http://www.nac.net wfms
RE: NANOG 40 agenda posted
I agree with John here. I am not going to speak for content providers, but I have heard them raise serious business concerns about the lack of infrastructure deployment. They make their living on responsiveness, and an extended transition with its associated unpredictability without native routing potentially impacts business (ie: so far behind their peers in perceived quality that finances are impacted). This is a grand game of chicken. The ISPs are refusing to move first due to lack of content, and the content providers are refusing to move first due to lack of infrastructure. We are going to hit the end of the IPv4 pool and have a panic driven deployment rather than a well planned one. I just hosted a session with enterprises that are actively deploying IPv6 to start distilling best-practices, and it is clear that something similar is going to have to happen for ISPs. I am not ready to organize something just yet, but if you are interested I will hang around the beer-n-gear. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of John Curran Sent: Tuesday, May 29, 2007 7:20 AM To: Donald Stahl Cc: [EMAIL PROTECTED] Subject: Re: NANOG 40 agenda posted At 9:21 AM -0400 5/29/07, Donald Stahl wrote: At this point, ISP's should make solid plans for supplying customers with both IPv4 and IPv6 connectivity, even if the IPv6 connectivity is solely for their web servers and mail gateway. The priority is not getting customers to use IPv6, it's getting their public-facing servers IPv6 reachable in addition to IPv4. Exactly. So many people seem to be obsessed with getting the end users connected via IPv6 but there is no point in doing so until the content is reachable. The built in tunneling in Windows could be a problem so let's start by using different dns names for IPv6 enabled servers- mail.ipv6.yahoo.com or whatever. Can anyone think of a reason that a separate hostname for IPv6 services might cause problems or otherwise impact normal IPv4 users? There are already folks who have run separate hostnames for IPv6 services, and the fact that we can still exchange email on mailing lists (lots of email ;-) ) means that it doesn't seem to be a problem. The next phase of experimentation which needs some real-world experience is using both IPv4 and IPv6 to reach existing servers, to learn all about the various does and doesn't work scenarios that can be setup with/out IPv6 transit/tunnelling, with IPv4 only and IPv4/IPv6 DNS servers, and the resource record preference rules in various resolver and IP stacks... So, what I'm advocating for is getting servers on both IPv4 and IPv6 asap, and figuring out how to do it safely with the same DNS names. I'm not saying that a good starting step is running IPv6 internal to your own network with separate hostnames, but we all have to move past that pretty quickly. /John
RE: shim6 @ NANOG
Paul Jakma wrote: On Tue, 7 Mar 2006, Iljitsch van Beijnum wrote: Hm, I would rather do this globally but maybe this is the way to go... Geo-aggregation is something that stands its best chance of being implemented locally: While I agree that any aggregation would happen locally, the overall allocation policy for a consistent geo approach needs to be done globally. - the 'players' involved will be fewer - requirements for a workable policy will be easier to work out (and fewer conflicts between requirements) - there may be existing 'arbiter of last resort' (particularly at national levels) to resolve the inevitable conflicts. Ie this may be best done even /below/ the RIR level (though, RIR agreement would be needed). Still though, hard to see it happening without some acceptance by operators. You are mixing issues here. A policy for assigning PI space is what ARIN can deal with. A deployment agreement about aggregating a collection of PI assignments is what operators can deal with. What needs to happen is to define a global mechanism for PI assignments such that it is possible to do aggregations when it becomes necessary. Any of the geo approaches allows aggregation of a high-density pocket without requiring aggregation of all pockets globally. In particular the approach I have been pursuing allows the definition of any aggregate to evolve and track population shifts over time. Tony
protocols that don't meet the need...
A thought I had on the plane last night about the disconnect between the NANOG and IETF community which leaves protocol development to run open-loop. Rather than sit back and complain about the results, why not try to synchronize meeting times. Not necessarily hotels, but within a reasonable distance of each other so the issue about ROI for the trip can be mitigated. This will mean that people who regularly attend both will have overlap issues, but if one meeting every year or two is joint there is an opportunity for those who can't justify the extra trips to at least have some feedback to try and close the loop on protocol design. Tony
RE: protocols that don't meet the need...
I am not going to speak for the IETF, but why would they? Their meetings are already open, and to be globally fair the proposed coordinators would have to attend 3-5 extra meetings a year to cover all the ops groups. Tony -Original Message- From: Eastgard, Tom [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 1:01 PM To: Tony Hain; nanog@merit.edu Subject: RE: protocols that don't meet the need... -Original Message- From: Tony Hain [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 12:35 PM To: nanog@merit.edu Subject: protocols that don't meet the need... A thought I had on the plane last night about the disconnect between the NANOG and IETF community which leaves protocol development to run open-loop. Rather than sit back and complain about the results, why not try to synchronize meeting times. Not necessarily hotels, but within a reasonable distance of each other so the issue about ROI for the trip can be mitigated. This will mean that people who regularly attend both will have overlap issues, but if one meeting every year or two is joint there is an opportunity for those who can't justify the extra trips to at least have some feedback to try and close the loop on protocol design. Would it make sense to ask IETF to provide a focal or coordinate(s?) to NANOG who would host a BOF(s?) on IETF issues --- not to debate, explain or work them but to board the issues and concerns of the operating community? Point being to provide a lightly structured and cost effective mechanism for operators to give feedback without having to attend three more meetings per year? T. Eastgard
RE: protocols that don't meet the need...
I agree that attendance is not required, but it can help some discussions. Given the logistical differences it would be much easier to schedule NANOG into a nearby hotel than to try to move the IETF around. For example this time if NANOG had been a month later it would have been in the same city yet different hotels. I understand that synchronized meetings it not trivial, but it is worth considering. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 14, 2006 1:10 PM To: Tony Hain Cc: nanog@merit.edu Subject: Re: protocols that don't meet the need... On Tue, 14 Feb 2006 12:35:19 PST, Tony Hain said: Rather than sit back and complain about the results, why not try to synchronize meeting times. Not necessarily hotels, but within a reasonable distance of each other so the issue about ROI for the trip can be mitigated. The IETF apparently has some major scheduling problems as it is, because there are very few venues that can handle the number of people that show up *and* have the right mix of large rooms and many smaller break-out rooms. Trying to get it into a hotel opposite a NANOG would just exacerbate the problem. And there's nothing stopping NANOG types from joining an IETF working group and participating via e-mail - there's a large number of people who have contributed to the IETF process and never actually been sighted at an IETF meeting.
RE: Turkey has switched Root-Servers
Tony Li wrote: .com is an abomination, as are the other gTLDs to a lesser extent. .gov, .mil, .edu, .info, and .biz need to be shifted under .us immediately, and everyone under .com, .net, and .org needs to be gradually moved under the appropriate part of the real DNS tree. I can live with .int continuing on, but only because no better solution immediately comes to mind. Actually, I think you've got it backwards. .us and all of the other country-specific TLDs are the last vestiges of nationalism. The Internet is only the second piece of truly global infrastructure. As a key component in the ongoing trend towards a unified global administration, we should do what we can to encourage cooperation and equality across borders, not intensify their differences. In general I agree with you. The primary exception being that if national political interests want to press for local rules about specific strings (like XXX) then those national interests belong in their designated part of the name space. Polluting the global space with nationally inconsistent rules about use will not help. Tony
RE: mh (RE: OMB: IPv6 by June 2008)
Given that shim breaks fundamental assumptions about the stable relationship between the packet header and the application context, there will be many security related issues to be resolved after the shim spec stabilizes. Shim is a 'more than a decade' effort if it ever completes. The disappearance of NAT is not as bad as the FUD that keeps coming up. See: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-01.txt and please send comments if some use of NAT is not covered. As far as alternatives for multi-homing, the IESG has focused on shim and denied a request for a bof in August to discuss interim options. I submitted updates to the ID editor early last month but for some reason they have not popped out yet, but I am always accepting comments on: http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-08.txt http://www.tndh.net/~tony/ietf/draft-hain-ipv6-pi-addr-use-08.txt Like the approach or not, it is straight up existing BGP and existing host stacks. It will never be the highly optimized 400 entry routing table, but it doesn't pretend to be. It does however create PI space that has some hope of aggregating. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Dave Crocker Sent: Friday, July 08, 2005 4:12 AM To: Kuhtz, Christian Cc: Joe Abley; NANOG list Subject: Re: mh (RE: OMB: IPv6 by June 2008) Thanks, I'm fully aware of where shim6 is right now. I'm asking if anyone feels this is headed anywhere useful or if we got anything else we can use to facilitate mh. a shim layer seems like a promising enhancement. ietf-shim6 is taking an approach to a shim layer that will, I suspect, take some time to mature. I'd be surprised if it saw significant deployment anytime within the next 5 years, at the earliest. (a more ascerbic view would probably suggest that it is not even likely to produce a complete specification within that time, with deployment taking another 5 years...) the effort is relying on IPv6 and on the disappearance of NATs, for v6. one might consider these to be critical dependencies that are rather risky. -- d/ Dave Crocker Brandenburg InternetWorking +1.408.246.8253 dcrocker a t ... WE'VE MOVED to: www.bbiw.net
RE: mh (RE: OMB: IPv6 by June 2008)
Mangling the header did not prevent the worms, lack of state did that. A stateful filter that doesn't need to mangle the packet header is frequently called a firewall (yes some firewalls still do, but that is by choice). Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Andre Oppermann Sent: Friday, July 08, 2005 4:42 AM To: Fergie (Paul Ferguson) Cc: [EMAIL PROTECTED]; nanog@merit.edu Subject: Re: mh (RE: OMB: IPv6 by June 2008) Fergie (Paul Ferguson) wrote: I'd have to counter with the assumption that NATs are going away with v6 is a rather risky assumption. Or perhaps I misunderstood your point... There is one thing often overlooked with regard to NAT. That is, it has prevented many network based worms for millions of home users behind NAT devices. Unfortunatly this fact is overlooked all the time. NAT has its downsides but also upsides sometimes. -- Andre
RE: ULA and RIR cost-recovery
Owen DeLong wrote: I have never been a fan of the registered ULAs, and have argued against the IETF's attempts to state specific monetary values or lifetime practice as a directive to the RIRs; but I am equally bothered by the thought that the operator community would feel a need to fight against something that really doesn't impact them. Perhaps it is because in the perception of the operator community, we do not believe it will not impact us. The reality is that once registered ULAs become available, the next and obvious step will be enterprises that receive them demanding that their providers route them. Economic pressure will override IETF ideal, and, operator impact is the obvious result. This argument is basically saying that the RIR membership knows it is forcing allocation policies that are counter to the market demand. The only way ULAs could be considered for grey market PI use is due to lack of any alternative mechanism to meet the real customer requirement for independence. The current problem is that the RIR membership has self-selected to a state where they set policies that ensure the end customer has no alternative except to be locked into their provider's address space. Everyone acknowledges that the demand for PI space is real while simultaneously refusing to seriously deal with it (and the re-architecting of fundamental assumptions about the Internet effort of multi6, while serious, is not a short term solution). My to-do list for the next couple of weeks has an item to ask for a BoF at the next IETF on an interim moderately aggregatible PI approach. I cc'd the Internet ADs since this is as good a time as any to start the process. I have a proposal on the table, but I care more about a real solution than I do about that specific approach. At the same time I continue to get comments like: 'Your geographic addressing proposal (draft-hain-ipv6-pi-addr-07.txt) is very attractive to us (it's pretty much ideal, really)', so it probably makes a good starting point for discussion. Tony
RE: ULA and RIR cost-recovery
Steven M. Bellovin wrote: ... The problem with this scheme is that it's only aggregatable if there's some POP that lots of carriers connect to in the proper geographic areas. What is the carriers' incentive to show up -- peer? -- at such points, rather than following today's practices? It doesn't require POPs per se, but that might be the simplest implementation. It does require some form of peering agreement for a service region which could be implemented with traditional transit arrangements. The incentive question is still open though. One incentive would be the trade-off against a routing swamp, but by itself that is probably not enough. Another incentive might be to stave off the recurring threat that the ITU/Governments could impose worse approaches. If I had an answer to the incentive question it would probably be easier to make progress. Tony
RE: ULA and RIR cost-recovery
Owen DeLong wrote: --On Wednesday, November 24, 2004 11:40 -0800 Tony Hain alh- [EMAIL PROTECTED] wrote: Owen DeLong wrote: I have never been a fan of the registered ULAs, and have argued against the IETF's attempts to state specific monetary values or lifetime practice as a directive to the RIRs; but I am equally bothered by the thought that the operator community would feel a need to fight against something that really doesn't impact them. Perhaps it is because in the perception of the operator community, we do not believe it will not impact us. The reality is that once registered ULAs become available, the next and obvious step will be enterprises that receive them demanding that their providers route them. Economic pressure will override IETF ideal, and, operator impact is the obvious result. This argument is basically saying that the RIR membership knows it is forcing allocation policies that are counter to the market demand. The only way ULAs could be considered for grey market PI use is due to lack of any alternative mechanism to meet the real customer requirement for independence. Well... I'm saying, at least, that I'd rather change the RIR policy and work in an open and consistent manner based on input from the operational community and other stakeholders than have the IETF start setting allocation policy for PI space while pretending that isn't what is happening. If the IETF wants to set such a policy for UGA, then, fine, let's do that. However, pretending that it's not globally routable and trying to use that as an excuse to slide this into position is a fallacy that ignores the real world implications. ULAs are clearly routable over whatever scope people decide to. This was also true of the SiteLocal prefix that ULAs are replacing. The only difference is that ULAs have explicit text to avoid routing ambiguity where SL didn't. I argued against deprecating SL partly on the basis that it had the potential for ambiguity which would be a disincentive for grey-market PI use. I understand and agree with your point about them being a potential problem, but that potential is easily mitigated by providing an economically viable alternative. The current problem is that the RIR membership has self-selected to a state where they set policies that ensure the end customer has no alternative except to be locked into their provider's address space. Everyone acknowledges that the demand for PI space is real while simultaneously refusing to seriously deal with it (and the re-architecting of fundamental assumptions about the Internet effort of multi6, while serious, is not a short term solution). This is absolutely not true. RIPE allocates /24s and smaller. I don't know APNICs current MAU. ARIN will allocate /22s and will probably consider smaller allocations either at the next meeting or the one after that. None of the organizations that are getting long IPv4 allocations will qualify for an IPv6 prefix. There is an implicit concession that it is too late to close the barn door for IPv4, but for IPv6 it is currently locked tight by those that want to maintain control. My to-do list for the next couple of weeks has an item to ask for a BoF at the next IETF on an interim moderately aggregatible PI approach. I cc'd the Internet ADs since this is as good a time as any to start the process. I have a proposal on the table, but I care more about a real solution than I do about that specific approach. At the same time I continue to get comments like: 'Your geographic addressing proposal (draft-hain-ipv6-pi-addr-07.txt) is very attractive to us (it's pretty much ideal, really)', so it probably makes a good starting point for discussion. Agreed. I'd like to see a real solution that allows any organization that wants to multihome to get PI space or have us solve the underlying problems so that address portability becomes irrelevant (better, I think, in the long term). Multi-homing is only one reason for PI space, and people get so hung up on that one that they forget that the simple ability to change providers without massive effort is just as important. As I see it, IP Addresses are currently used for the following purposes: Destination Endpoint Identifier (resolvable by requiring a solid directory service) Source Endpoint Identifier (mostly doesn't matter when this changes) Source Endpoint Authentication (this is bad and we should be using something better that actually identifies the host (or better yet in most cases, user) in a meaningful way) Host authorization (Same issue(s) as previous statement) Portion of Service authorizatoin decisions (again, same issues as previous two) In the early days of the ipng working group, there was hope that v6 would solve these issues. Sadly, after rejecting
RE: ULA and RIR cost-recovery
John Curran wrote: ... If ARIN's members direct it to provide such a service, and provide guidance that the fees should based initial-only and on a cost recovery, I have a lot of faith that it would occur... That does, of course, presume that the operator community actually agrees with the need for ULA's and draft's philosophy on pricing. And that is the basic problem. The primary value of ULAs is with the end site, not the operator community. The IPv6 public prefix allocation policy that only operators get them ensures that the ARIN membership will be heavily weighted against the target audience for the technology. I have never been a fan of the registered ULAs, and have argued against the IETF's attempts to state specific monetary values or lifetime practice as a directive to the RIRs; but I am equally bothered by the thought that the operator community would feel a need to fight against something that really doesn't impact them. Tony
RE: IPV6 renumbering painless?
Owen DeLong wrote: I still think that we should pursue making the design work and not adopt cruft as standards (ULA). ULAs aren't cruft. They serve a purpose. If you don't need them, don't use them and they won't get in your way. ULAs aren't cruft so long as providers do not start exchanging ULA routes in the general routing table. When economics start forcing this issue, then ULAs become a crufty form of PI space. Since I believe the economics will force this issue sooner rather than later, I regard ULAs as cruft whether you agree or not. Your basic argument is that people really want PI space, and as long as the ISPs continue to bias the RIR policies against organized PI space there will be pressure for a grey-market in anything that can be used as PI. A structured and manageable, non-swamp but non-perfect-aggregation approach to PI is described in draft-hain-ipv6-pi-addr-07.txt. Comments welcome. Tony
RE: IPV6 renumbering painless?
First issue is that IPv6 interfaces support both the old new prefixes at the same time, so the provider change case is not as dramatic as people fear based on past IPv4 experience. Second: http://www.ietf.org/internet-drafts/draft-ietf-v6ops-renumbering-procedure-0 1.txt talks about other issues that make renumbering non-trivial. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of [EMAIL PROTECTED] Sent: Thursday, November 11, 2004 8:22 AM To: [EMAIL PROTECTED] Subject: IPV6 renumbering painless? I guess you also want to announce a /64 into the IPv6 BGP tables ? Correct me if I'm wrong, but doesn't IPv6 do away with the need to renumber when switching providers? So if RFC 2462 is right, and you use DNS outside your network and you update that DNS at the moment of switching providers, everything on your network automatically acquires new IPv6 globally routable addresses as soon as the gateway router is connected to the new provider. Seems to me that with a little bit of help from a Change providers tool, this would be virtually painless without the need to own or announce a small globally unique prefix. --Michael Dillon
RE: Important IPv6 Policy Issue -- Your Input Requested
Randy Bush wrote: I see this a lot recently: You are mixing up RfC1918 and NAT. If I have globally unique addresses I can NAT them as well as 10/8. One has nothing to do with the other. Having to NAT RfC1918 addresses to reach the internet, does not imply that I have to have RfC1918 to be able to do NAT. but having 1918, site-loco, whatever, and wanting to reach the internet REQUIRES nat. we'll love it in ipv6; can't let things be too simple, eh? The existence of the address space does not require nat. Being stuck in the mindset where there is only one address on an interface leads people to believe that nat is an automatic result local addresses. Assigning a local prefix for local purposes (like a printer or lightswitch) at the same time as a global prefix for those things that need to reach the Internet does not require nat. Tony
RE: IPV6 renumbering painless?
Daniel Roesen wrote: ... fixed as in now using stateless autoconfig? Fun... change NIC and you need to change DNS. Thanks, but no thanks. Not for non-mobile devices which need to be reachable with sessions initiated from remote (basically: servers). You are allowed to do either / both, or DHCP. If you are talking about a server you want a static value, while it may not make sense to explicitly manage every client. If you don't want to statically configure devices there is always DHCPv6. The point is you can do what you do today, then there are new capabilities for autoconfiguration that can be used when it makes sense to lower operational costs. Tony
RE: Important IPv6 Policy Issue -- Your Input Requested
Ray Plzak wrote: ... This is a valuable discussion but to a large extent the efforts can be considered as a non input into the working group as the discussion is not on their mail list. The IETF works best when people directly contribute to the discussion and consensus building process. I encourage you to move this discussion to the working group mail list and if you are at the IETF to attend the IPv6 Working Group at 9 AM, Thursday morning in the Georgetown room. The session is also multicast. I second Ray's comments about participation here. At the same time as you read and form your opinions, make sure you take off your blinders about how things were done in the good old days. Many current network deployments are work-arounds to the limitations of existing technology. There are opportunities for different configurations going forward that achieve the real goals. To that end, you should also read and comment on: draft-vandevelde-v6ops-nap-00.txt Another point to consider is that most of the people that would be using the ULA space are NOT service providers. As such you should keep in mind that the target user's problem is not the same as most of the membership of this list, so the tools and their use are not the same. While everyone could request space from a provider or Arin for private use, having a clean single well-known bogon filter of FC00/7 makes everyone's life much simpler. Since most of the problems in the operational world are derived from unnecessary complexity, having a simple well understood filter should lead us to a more stable network. Yes we know people leak 1918 today and ULAs don't prevent leaks, but leaks of space that was not intended to be globally routed will be even more common if they are non-contiguous random pieces from each customer. Tony
RE: IPv6/IPv6 threat Comparison Paper available for review
Iljitsch van Beijnum wrote: On 11-mei-04, at 3:13, Darrin Miller wrote: http://www.cisco.com/security_services/ciag/documents/v6-v4-threats.pdf Ok, some comments: ... - Fragmentation You can't drop non-last fragments that are smaller than 1280 bytes as a host may fragment a packet into equal size parts rather than a big and a small part. Testing if you can get away with it makes no sense as new implementations come on the market all the time. If you want to do this you can probably do it at around ~600 bytes for non-last fragments as there is no legitimate need to fragment packets that are already 1280 bytes or smaller, so if this is done anyway it's probably for reasons you don't like. Technically you are correct, but if the firewalls are deployed first those later systems will have to conform to what the network allows. - Smurf I don't think you mention that in IPv6, there are no mechanisms that allow an incoming unicast packet to be turned into a broadcast or multicast packet, and as such, smurf-like attacks are impossible. It can be done on-link by a zombie, but that is not the strict definition of a remote smurf attack. - Tunneling Why only filter outbound tunneling? - Use of multiple addresses You say that RFC 3041 helps against scanning. It doesn't, as hosts also keep their EUI-64 derived addresses. In IPv6 it is required to support having multiple addresses on an interface. There is no requirement for an end system to use the EUI-64 suffix with a global prefix. It is a perfectly reasonable scenario for the system to have a policy that says only use 3041 with global prefixes, and EUI-64 for the FE80:: FC00:: prefixes. The only real issue is how the end system derives a consistent value for anything it registers in DDNS. Even then it can be based on an apparently random set of bits as long as they don't change and create churn in DNS. Tony
RE: Clueless service restrictions (was RE: Anti-spam System Idea)
Dave Crocker wrote: Folks, TH If you insist on restricting the service to a small set of 'approved' TH applications, people will simply encapsulate what they really want to do in TH the approved service and you will lose visibility. A small elaboration: You will make life intolerable for the average user -- ie, the folks not likely to have the skills are working around artificial barriers -- but the non-average user -- ie, including the bad guys -- will encapsulate. The bad guys will know they are encapsulating. Joe-sixpack will just realize that application xyz doesn't work unless he installs the 'Internet-fixer'(R) tool that his buddy told him about. He has no idea what it does, and he doesn't really care as long as the app works. DG The RFC for mail was very well designed. If people simply stuck to the DG orginal RFC (~800 something) and managed more of their own small systems DG then this spam thing just wouldn't be the problem that it has become... DG would it? Well, yes, but no. (I'm finding that a popular response today, because email and spam are so messy.) Email does what it was intended to do pretty well. As with multiaddressing (multihoming and mobility) there is a basic question about the architectural choice for making major changes. I keep wanting the enhancements to stay out of the core. For both areas of work. So, the original Internet mail service does nothing to prevent spoofing or spamming. I think most folks thought that content signing (eg, pgp or s/mime) would be a sufficient solution for authentication and I'd guess we just plain missed the likelihood of spamming. However I still tend to believe that having seen the problem earlier should not necessarily have made the core mail facilities different. In all likelihood, some for of message authentication is needed, possibly along the lines of DomainKeys or Teos. My sense is that the technology for this is quite tractable and requires no changes to the email infrastructure. (On the other hand, we need to pay very close attention to the failure to cross the chasm, for pgp and s/mime.) The oversight is not recognizing the leap from technical space to political space. All the engineering in the world will not solve fundamental political trust issues. At one point in my past, the motto for my group was 'technical solutions to political problems r us', knowing full well there are no technical solutions to political problems. The best the technical side can do is window dress so the politicians can claim victory. I think that the registration oriented authentication mechanisms (spf, rmx, lmap, etc.) can be useful only when the authenticator is the hosting network provider, rather than a message author. SMB In almost all circumstances, authentication is useful for one of two SMB things: authorization or retribution. But who says you need SMB authorization to send email? Authorized by whom? On what criteria? , This certainly goes to a core set of issues. The fact that something is authenticated does not mean it is not spam. On the other hand, authentication is a good thing unto itself. On the other hand, making it a pre-requisite for _all_ email activity is very much a _bad_ thing. I disagree that full authentication is a bad thing. What possible down side is there to being able to track the source of every message? Authenticating mail will help deal with two problems: forgery and accountability. Forgery of the From field is now a major problem. It has always been a major threat. So, finding a tractable way of prevent or detecting forgery is a worthy goal unto itself. It does not solve spam. Rather I think of joe-jobbing and phishing as doing a really spectacular job of market segment development. It has made clear to target customers why they need a solution. Accountability just means that there is a good basis for tracking down problematic sources. That, too, is a good thing. So why not make it mandatory for all messages. Just to be clear I am of the mindset that a new, parallel messaging system is needed. It does not have to be a complete ground up redesign, but requiring a separate MUA port for transport would allow people to opt out of the legacy system at their own pace. Assuming a completely separate system, why not make auth mandatory? Tony d/) -- Dave Crocker dcrocker-at-brandenburg-dot-com Brandenburg InternetWorking www.brandenburg.com Sunnyvale, CA USA tel:+1.408.246.8253
Clueless service restrictions (was RE: Anti-spam System Idea)
Most of the responses to the anti-spam thread, and the comments to Itojun's IAB presentation in Miami about filtering, show that this community has been thoroughly infiltrated and is now as CLUELESS as the PSTN providers, and just as power hungry. The current ISPs have the opportunity to turn the Internet into the PSTN, where customers can have any service they want as long as it uses an audio interface and a rotary dial for signaling. ;) Seriously, filtering is about attempting to prevent the customer from using their target application. Central registration is no better, as its only purpose is exercising power through extortion of additional funds for 'allowing' that application. What people seem to be refusing to hear is the comment Phil Karn made at the mic. If you insist on restricting the service to a small set of 'approved' applications, people will simply encapsulate what they really want to do in the approved service and you will lose visibility. For any who doubt this, revisit how the Internet was deployed and grew despite the limitations of the PSTN interface offerings. The Internet has value because it allows arbitrary interactions where new applications can be developed and fostered. The centrally controlled model would have prevented IM, web, sip applications, etc. from ever being deployed. If there are any operators out there who still understand the value in allowing the next generation of applications to incubate, you need to push back on this tendency to limit the Internet to an 'approved' list of ports and service models. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On Behalf Of Timothy R. McKee Sent: Monday, February 16, 2004 1:19 PM To: 'Petri Helenius' Cc: 'J Bacher'; [EMAIL PROTECTED] Subject: RE: Anti-spam System Idea Personally I don't see where ingress filters that only allow registered SMTP servers to initiate TCP connections on port 25 is irresponsible. Any user sophisticated enough to legitimately require a running SMTP server should also have the sophistication to create a dns entry and register it with his upstream in whatever manner is required. There will never be a painless or easy solution to this problem, only a choice where we select the lesser of all evils. Tim -Original Message- From: Petri Helenius [mailto:[EMAIL PROTECTED] Sent: Monday, February 16, 2004 16:06 To: Timothy R. McKee Cc: 'J Bacher'; [EMAIL PROTECTED] Subject: Re: Anti-spam System Idea Timothy R. McKee wrote: There will *never* be a concerted action by all service providers to filter ingress/egress on abused ports unless there is a legal requirement to do so. Think 'level playing field'... Haven´t it been stated enough times previously that blindly blocking ports is irresponsible? There are ways to similar, if not more accurate results without resorting to shooting everything that moves. Pete
RE: Clueless service restrictions (was RE: Anti-spam System Idea)
Alex Bligh wrote: Steve, --On 17 February 2004 17:28 -0500 Steven M. Bellovin [EMAIL PROTECTED] wrote: In almost all circumstances, authentication is useful for one of two things: authorization or retribution. But who says you need authorization to send email? Authorized by whom? On what criteria? Authorized by the recipient or some delegee thereof, using whatever algorithms and heuristics they chose. But based on data the authenticity of which they can determine without it being trivially forgeable, and without it being mixed up with the transport protocol. IE in much the same way as say PGP, or BGP. Attempts to define official ISPs leads very quickly to the walled garden model -- you have to be part of the club to be able to send mail to its members, but the members themselves have to enforce good behavior by their subscribers. I never said anything about official ISPs. I am attempting to draw an analogy (and note the difference) between SMTP as currently deployed, and the way this same problem has been solved many times for other well known protocols. No it hasn't, and your comparison to BGP is very much about 'official ISPs'. For starters your examples are not anywhere close to the same scale as the SMTP 'problem', and are restricted to 'IN' players. The closest they get is the blatant attempt to restrict SMTP to the privileged club of BGP speakers. We do not have an official BGP authorization repository. Or an official PGP authorization repository. We just have people we chose to trust, and people they in turn chose to trust. Where they specifically form a club and agree to preclude the basement multi-homed site from participating through prefix length filters. This is exactly like the thread comments about preventing consumers from running independent servers by forced filtering and routing through the ISP server. This is not scaled trust; it is a plain and simple power grab. Central censorship is what you are promoting, but you are trying to pass it off as spam control through a provider based transitive trust structure. Either you are clueless about where you are headed, or you think the consumers won't care when you take their rights away. Either way this path is not good news for the future Internet. Tony Take BGP (by which I mean eBGP) as the case in point: It seems to be general held opinion that the one-and-only canonical central repository for routes does not work well. The trust relationship is important, and we expect some transitivity (no pun intended) in the trust relationshipa to apply. And many end-users in the BGP case - i.e. stub networks - chose to outsource their their trust to their upstream; when they don't like how their upstream manages their routes, they move provider. BGP allows me (in commonly deployed form) to run a relatively secure protocol between peers, and deploy (almost) universal end-to-end connectivity for IP packets in a manner that does not necessarily involve end users in needing to know anything about it bar if the routing doesn't work, I move providers; and IP packets do not flow through BGP, they flow in manners prescribed by BGP. Replace BGP by a mail authorization protocol and IP packets by emails in the foregoing; if the statement still holds, we are getting there (without reverting to bangpaths pathalias). Oh, and people keep mentioning settlement and how it might fix everything - people said the same about BGP (i.e. IP peering) - may be, may be not - the market seems to have come up with all sorts of ingenious solutions for BGP. Alex
RE: Clueless service restrictions (was RE: Anti-spam System Idea)
Clearly I misinterpreted your comments; sorry for reading other parts of the thread into your intent. The bottom line is the lack of a -scalable- trust infrastructure. You are arguing here that the technically inclined could select from a list of partial trust options and achieve 'close enough'. While that is true, Joe-sixpack wouldn't bother even if he could figure out how. Whatever trust infrastructure that comes into existence for the mass market has to appear to be seamless, even if it is technically constructed from multiple parts. Steve Bellovin suggested earlier that identity based approaches wouldn't work. While I agree having the identity won't solve the problems by itself, it does provide a key that the rest of the legal system can start to work with. False identities are common in the real world, so their existence in the electronic world is not really any different. I guess I am looking at this from the opposite side the two of you appear to be, rather than requiring authorization to send, irrefutable identity should be used to deny receipt after proven abuse. Tony -Original Message- From: Alex Bligh [mailto:[EMAIL PROTECTED] Sent: Tuesday, February 17, 2004 4:48 PM To: Tony Hain; 'Steven M. Bellovin' Cc: [EMAIL PROTECTED]; Alex Bligh Subject: RE: Clueless service restrictions (was RE: Anti-spam System Idea) --On 17 February 2004 16:19 -0800 Tony Hain [EMAIL PROTECTED] wrote: Where they specifically form a club and agree to preclude the basement multi-homed site from participating through prefix length filters. This is exactly like the thread comments about preventing consumers from running independent servers by forced filtering and routing through the ISP server. This is not scaled trust; it is a plain and simple power grab. Central censorship is what you are promoting, but you are trying to pass it off as spam control through a provider based transitive trust structure. Either you are clueless about where you are headed, or you think the consumers won't care when you take their rights away. Either way this path is not good news for the future Internet. Now there was me thinking that I was in general agreeing with you. I am not promoting any sort of censorship, central or otherwise. I believe you have a perfect right to open a port 25 connection to any server, and I have a perfect right to accept or deny it. And of course vice-versa. What I am saying is that I would like, in determining whether to accept or reject your connection, to know who you are and that you act responsibly, or failing that, to know someone who is prepared to vouch for you; failing that, may be I'll accept your email anyway, may be I won't. I do not care what upstream either you or I have. For the avoidance of doubt, I am not talking about forcing people to send mail through their upstreams, or even suggesting that the graph of any web of trust should follow the BGP topology. Indeed the entire point I made about separating the web of trust's topology from IP addresses etc. was rather to enable end users to CHOOSE how they accept/reject mail in a manner that might have nothing to do with network topology. Personally I would be far more happy accepting mail from someone who'd been vouched for by (say) someone on this list I knew, than vouched for by their quite possibly clueless DSL provider. Of course some people will want to use their ISP, many won't. Just like Joe User can use their upstream's DNS service, but doesn't necessarily need to. Maybe PGP would have been a better analogy as far as the scale bit goes. I think you are assigning motives to the BGP basement-multihoming problems where in general the main motive is not getting return on cost of hardware; however, I don't think the same scale constraints need apply as it is unnecessary to hold a complete table in-core at once. Alex
NTIA/DoC public comment period
As I mentioned yesterday, the DoC is looking for public comment on IPv6. http://www.ntia.doc.gov/reports.html Specifically toward the end they ask: In some instances, government has responded to concerns over potential chicken and egg problems by playing an active role in the introduction of certain products and services, such as FM radio and HDTV. We request comment on how the deployment of IPv6 compares to other standards-based technology transitions and whether IPv6 presents the same or similar concerns that warrant government action. If you have opinions, be sure to send them by March 8. Tony
RE: AOL rejecting mail from IP's w/o reverse DNS ?
[EMAIL PROTECTED] wrote: ... It's not the reverse DNS itself that is meaningful. It is the fact that the SMTP server operator with proper IN PTR records probably has the cooperation of their ISP. This is a broken model. People that are buying high level services should expect those to be delivered correctly, but those who are buying bit transport should not be required to obtain additional services to become fully functional. It is nice to fantasize that the ISP is in control, but time has shown that people will do what it takes to make their service work. If that means pushing the service provider into further irrelevance, they will. Rather than trying to break service for the antonymous network by requiring consent from the cabal, the service providers need to be making it easier and cheaper to get the desired results from their service. Tony
RE: AOL rejecting mail from IP's w/o reverse DNS ?
just me wrote: On Fri, 5 Dec 2003, Petri Helenius wrote: And I refer you to the blocks which are properly registered down to the /29 level and you are saying that if you are a good citizen collateral damage is recommended regardless because antispammers are either lazy or technically incompetent or like their ego boosted by intentional collateral damage? Pete Can you explain to the less hyperbolic among us, why I should be obligated to exchange packets with a provider who hosts abusive customers. Disclaimer: I am not a lawyer. That said, IMHO you are free to do what you want as an individual, but collusion by a group to block a provider (even one with abusive customers) smells a lot like restraint of trade. Tony
RE: IPv6 NAT
Scott McGrath wrote: Agreed NAT's do not create security although many customers believe they do. NAT's _are_ extremely useful in hiding network topologies from casual inspection. This is another bogus argument, and clearly you have not done the math on how long it takes to scan a /64 worth of subnet space. Start by assuming a /16 per second (which is well beyond what I have found as current technology) and see how long 2^48 seconds is. What I usually recommend to those who need NAT is a stateful firewall in front of the NAT. The rationale being the NAT hides the topology and the stateful firewall provides the security boundary. Obscuring the topology provides absolutely no security either. You are not alone, as it is frequently a recommended practice, but obscurity != security no matter how much it is sold as such. Tony
RE: IPv6 NAT
Kuhtz, Christian wrote: ... All hairsplitting aside, given that the term NAT these days is mostly used in a PAT (particularly in a customer connecting to the I) context, what isn't secure about? mangling the header doesn't provide any security, and if you believe it does, do the following exercise: Configure a static NAT entry to map all packets from the public side to a single host on the private side. Show how that mapping provides any more security than what would exist by putting the public address on that host. A stateful filter that is automatically populated by traffic originated from the private side is what is providing 'security'. That function existed in routers long before NAT was specified by the IETF (see RFC1044 for vendor). Tony
RE: Fun new policy at AOL
Matthew Crocker wrote: Shouldn't customers that purchase IP services from an ISP use the ISPs mail server as a smart host for outbound mail? Look carefully at that question and find the logic error. ... In case you missed it, the customer purchased 'IP' service, not 'ISP mail service'. We block outbound port 25 connections on our dialup and DSL pool. We ask our customers that have their own mail servers to configure them to forward through our mail servers. We get SPAM/abuse notifications that way and can kick the customer off the network. We also block inbound port 25 connections unless they are coming from our mail server and require the customer setup their MX record to forward through our mail server. We virus scan all mail coming and going that way. We protect our customers from the network and our network from our customers. We are currently blocking over 3k Sobigs/hour on our mail servers. I would rather have that then all my bandwidth eaten up by Sobig on all of my dialup/DSL connections. Running a walled garden is fine as long as that is what your customers are signing up for. One question though, why aren't you also running a web proxy and NetNanny to protect your customers from the 'bad' content on port 80? What makes port 25 so special? SMTP DNS should be run through the servers provided by the ISP for the exact purpose. There is no valid reason for a dialup customer to go direct to root-servers.net and there is no reason why a dialup user should be sending mail directly to AOL, or any mail server for that matter (besides their host ISP) This line of thinking leads us to a cabal that has complete control over communication. Think about it, a few large organizations allow/encourage abuse, then claim that the only resolution to the abuse is to route all communication through the centrally controlled servers. We end up back in the PTT style monopolies where censorship becomes trivial. Tony
RE: no ip forged-source-address
To reiterate the comment I made during the session yesterday, the places where strict rpf will be most effective are at the very edge interfaces without explicit management (SOHO). This also tends to be the place where there is insufficient clue to turn it on. One hopes that in the nanog community there is sufficient clue to recognize the case where having it on will create a problem and turn it off. This has been a case where money has been talking, and those with enough clue to comment on it are saying they don't want it, while those that really need it are not asking. If the community believes this technique is the best tool for regaining visibility into where attacks are coming from, there are two explicit steps to making it happen. First, demand that all vendors make it the default. Second, be willing to turn it off rather than simply complain that it doesn't work in the ISP network. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:owner-nanog;merit.edu] On Behalf Of [EMAIL PROTECTED] Sent: Wednesday, October 30, 2002 8:21 AM To: [EMAIL PROTECTED] Subject: Re: no ip forged-source-address On Wed, 30 Oct 2002, Daniel Senie wrote: BCP 38 is quite explicit in the need for all networks to do their part. The document is quite effective provided there's cooperation. Doesn't seem to be working. Which interface would you filter on? Customer ingress ports on the ISP side, which I suspect are the majority of ports in ISP networks. Hopefully engineers on the backbone will be clueful enough to turn it off. If we're talking about a router at the customer premesis, the filters should be on the link to the ISP (the customer may well have more subnets internally). At the ISP end, doing the filtering you suggest would not work, since it'd permit only the IP addresses of the link between the customer and user. The routing table of the router should be used to build up a list of prefixes that you should see through the interface. In this way, you could apply it to BGP customers too without having to create filters by hand. Regards, Rich
RE: no ip forged-source-address
Petri Helenius wrote: decides to attack, it would use some neighbor's IP. The subnet I am on is a /24 and there very well may be a few dozen hosts. I could be real sneaky and alter my IP randomly to be any of my neighbors for every packet I send out. This gets a lot sneakier when you got your /64 on the subnet. Specially if people start to build significantly larger subnets by default. Just stop. This nonsense about spoofing is easier because the IPv6 address space is bigger is bogus and wasting everyone's time. When each customer is assigned a unique /48-/64 they are traceable to the accountable entity no matter what low order bits they use. If they are assigned something longer than a /64, they are likely to keep using tunneling technologies like 6to4 until they can dump the provider that is cluelessly hoarding a resource that is not scarce. Tony
RE: Overcoming IPv6 Security Threat
The sad part is that absolutely clueless articles like this one get wider distribution than they deserve, and it takes even more travel and face time to refute the nonsense. In most cases it is hard to tell if the author is really as clueless as the resulting article would lead you to believe, or if they intentionally put in garbage to create an artificial sense of controversy which might lead to even greater distribution. Tony -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Daniel Golding Sent: Thursday, September 12, 2002 10:13 AM To: Jeroen Massar; 'Joe Baptista'; 'NANOG' Subject: RE: Overcoming IPv6 Security Threat This is scarcely the first time that a reporter has taken quotes from NANOG and spliced them together into a news story. Analysts do it too. I guess one of the weaknesses of this kind of forum is that the kooks (Jim Fleming) come off looking as credible as those who have a clue (like Stephen Sprunk or Dave Israel in this case). Now, please pardon me while I write do not talk to reporters on the blackboard, 500 times. - Daniel Golding Jeroen Massar Said.. Joe Baptista wrote: Thanks to everyone who helped out. But you didn't actually read now did you? Oh well you are a reporter nobody can blame you for doing work ;) But to pull some things straight: IPv6, a suite of protocols for the network layer, uses IPv4 gateways to interconnect IPv6 nodes and comes prepackaged with some popular operating systems. Cool, so *NATIVE* IPv6 doesn't exist? Many transitional techniques use intermediate IPv4 hops to connect IPv6 islands, that doesn't mean everything uses it. http://unfix.org/projects/ipv6/IPv6andIPv4.gif IPv6 has suffered bad press over privacy issues. Jim Fleming, the inventor of IPv8, a competing protocol, sees many hazards and privacy flaws in existing IPv6 implementations. Competing? There is yellno such thing as Jim Flemings IPv8/yell There is IPv8* but that is PIP (The P Internet Protocol) which is *NOT* the thing Mr. Fla^Heming is spamming about all the time. * = http://www.iana.org/assignments/version-numbers Maybe Mr. Fleming could write up a draft of his 'standard' sometime? I could start shouting that you are bad and that Man.v2 is much better now does that help anywhere? And one can easily change his/her local EUI so where's the problem there? One also mostly comes from the same /48 so where is the problem. Another obstacle raised by NANOG operators is that there is currently no commercial demand for IPv6 at this time. Which is true in the .US and mostly true in europe, but in Asia there is demand and IPv6 is happening. And that America is lagging behind ah well ;) Next time when you ask things, use them in your articles... Greets, Jeroen
RE: How do you stop outgoing spam?
Rafi Sadowsky wrote: How about using a combination of technical and social measures For example in a Cyber Cafe use passive technical measures to count the total number of outbound SMTP sessions and charge 1$ per Email over an average rate of 2 Emails/minute and 10$ per Email exceeding a rate of 10 per minute So the person who connects after sitting on a plane for 5 hours gets charged extra because the laptop bursts 50 messages ... There is no automated technical approach to a social problem. Public executions would be much more effective than preventing legitimate customers from getting their job done. Tony
RE: Bogus bogon?
Tony Tauber wrote: On Mon, 8 Jul 2002, Rob Thomas wrote: Hi, John. 192.88.99.0/24 which is the 6to4 anycast network. Do we really want to be filtering that prefix? Good question. I'm re-reading RFC 3068 now, and the RFC appears to allow for the advertisement of this prefix into the global table. I'm wondering if this is wise, however. It seems this prefix would best be used internally. What do others think? Thanks, Rob. I believe the idea is that it typically comes from outside one's domain because it's supposed to allow edge islands of IPv6 to find the mainland. If you had a connection to the mainland under your control, you wouldn't need this trick to get there. At least that's my understanding. Tony Close. The prefix should be advertised to the customers of the network which has the interconnect. If those customers are other SPs, the downstream will receive it from outside, and should advertise it to their customers. If a SP chooses to provide the interconnect service, it may still want to receive that prefix from outside as a backup. The point is that it is a well-known prefix that allows end customers to deploy IPv6 even if their direct SP chooses not to support it on their timeframe. It is designed on the assumption that the first hop SP is doing nothing about IPv6 deployment, and that includes not filtering the prefix. It would be wise to continue announcing it even after the SP starts announcing native IPv6 to customers because there will be some islands out there still, and it will be more efficient for the endpoints to directly tunnel over IPv4 than to run it through a central gateway service in each SP. Clearly each origin AS announcing the prefix will want to limit their exposure to their customers, but SPs without an interconnect should not have a problem accepting it. Tony
RE: How do I log on while in flight?
This probably isn't certified for flight use, but: http://www.kvh.com/products/product.asp?id=60 would provide the uplink with usable bandwidth. The downlink requires: http://www.kvh.com/products/product.asp?id=13 for auto tracking. Tony (who is not affiliated in any way with the manufacturer) -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Scott Weeks Sent: Thursday, June 27, 2002 1:11 PM To: [EMAIL PROTECTED] Subject: How do I log on while in flight? I was wondering if any of y'all could give me pointers to services I could use to log into a network during flight on a private airplane. For example a person is in flight cross-country and needs to do a videoconference, send email from his network to interested parties, or any of the normal things we do from the ground. Is this possible or would it interfere with the plane's other systems? scott
RE: IP renumbering timeframe
Marshall Eubanks wrote: On Thu, 30 May 2002 17:52:55 -0700 Tony Hain [EMAIL PROTECTED] wrote: Marshall Eubanks wrote: Since I run a small AS : I like this idea. Since I believe in living dangerously : I also think that a /64 should be reserved in the IPv6 address space, A /64 would have no use in the proposed scheme since it identifies a single subnet. I suspect you really want a /32 set aside since that would provide routable space to allocate /48's to each 16 bit AS. OK and (32 bit) ASN's should be given their own /32 in a GLOP like fashion for IPv6. I don't think the concept scales to 32 bit AS. Why not ? /32 with 32 bit ASN still leaves a /64 for each ASN. See above... What is the point of an ASN if all you are multi-homing is a single subnet? Also, since mechanisms like rfc3041 somewhat rely on a sparse utilization to quickly converge on a usable address, you would never be able to demonstrate the efficiency you need to justify a larger block. Marshall Tony Leo Bicknell wrote: In a message written on Thu, May 30, 2002 at 11:27:49AM -0400, Richard A Steenbergen wrote: I'd be mildly concerned that people would see free IP blocks and start using them even when not necessary. I think allocating them a /24 from this block only when they have demonstrated need, and don't have any other ARIN assigned blocks, would be far more efficient. Since the goal is to reduce paperwork, I'm not sure about 'demonstrated need', but I could definately endorse you get a /24 with your ASN if and only if you have no other registry assigned space assigned to you. I specifically exclude provider allocated space, as I'm assuming the ASN goal is to multihome. -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : [EMAIL PROTECTED] http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html
RE: IP renumbering timeframe
Andy Walden wrote: On Fri, 31 May 2002, Tony Hain wrote: What is the point of an ASN if all you are multi-homing is a single subnet? Tony, I'm missing the correlation between the amount of address space announced and multihoming. (Beyond the prefix being too long and potentially filtered). Care to elaborate? andy The only reason for an ASN is the need to globally announce routing policy due to multihoming. Unless policy changes, this community tends to insist that the prefix length announced via that ASN corresponds to a site, not a single subnet. For IPv6 that means a /48 makes sense as an initial allocation with a new ASN, and a /64 does not. Tony
RE: IP renumbering timeframe
http://www.ietf.org/internet-drafts/draft-ietf-ipngwg-addr-arch-v3-07.tx t is the replacement for 2373 http://www.ripe.net/ipv6/global-ipv6-assign-2002-04-25.html is the replacement for 2374 Yes a /16 would allow for 32 bit ASNs. The prior note was looking for a /32. Tony -Original Message- From: Marshall Eubanks [mailto:[EMAIL PROTECTED]] Sent: Friday, May 31, 2002 3:09 PM To: Tony Hain Cc: Andy Walden; nanog Subject: Re: IP renumbering timeframe This is described in rfc2373 and rfc2374. The 128 bit address space is separated into a /64 for each site and the remaining 64 bits for the MAC address, etc, for interfaces on the site. The public topology is 48 bits, and this is what is supposed to be routable. This would work with a 32 bit ASN based automatic assignment - one /16 could be allocated to this, with 32 bits for the ASN, 16 bits for site assignments and 64 bits for interface assignments. This is _not_ the service model of RFC2374, which envisions 8192 top level routing aggregators (TLA's), with other entities getting their address blocks from one of the TLA blocks. Regards Marshall Tony Hain wrote: Andy Walden wrote: On Fri, 31 May 2002, Tony Hain wrote: What is the point of an ASN if all you are multi-homing is a single subnet? Tony, I'm missing the correlation between the amount of address space announced and multihoming. (Beyond the prefix being too long and potentially filtered). Care to elaborate? andy The only reason for an ASN is the need to globally announce routing policy due to multihoming. Unless policy changes, this community tends to insist that the prefix length announced via that ASN corresponds to a site, not a single subnet. For IPv6 that means a /48 makes sense as an initial allocation with a new ASN, and a /64 does not. Tony -- Regards Marshall Eubanks This e-mail may contain confidential and proprietary information of Multicast Technologies, Inc, subject to Non-Disclosure Agreements T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : [EMAIL PROTECTED] http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html
RE: IP renumbering timeframe
Marshall Eubanks wrote: Since I run a small AS : I like this idea. Since I believe in living dangerously : I also think that a /64 should be reserved in the IPv6 address space, A /64 would have no use in the proposed scheme since it identifies a single subnet. I suspect you really want a /32 set aside since that would provide routable space to allocate /48's to each 16 bit AS. and (32 bit) ASN's should be given their own /32 in a GLOP like fashion for IPv6. I don't think the concept scales to 32 bit AS. Tony Leo Bicknell wrote: In a message written on Thu, May 30, 2002 at 11:27:49AM -0400, Richard A Steenbergen wrote: I'd be mildly concerned that people would see free IP blocks and start using them even when not necessary. I think allocating them a /24 from this block only when they have demonstrated need, and don't have any other ARIN assigned blocks, would be far more efficient. Since the goal is to reduce paperwork, I'm not sure about 'demonstrated need', but I could definately endorse you get a /24 with your ASN if and only if you have no other registry assigned space assigned to you. I specifically exclude provider allocated space, as I'm assuming the ASN goal is to multihome. -- Regards Marshall Eubanks T.M. Eubanks Multicast Technologies, Inc 10301 Democracy Lane, Suite 410 Fairfax, Virginia 22030 Phone : 703-293-9624 Fax : 703-293-9609 e-mail : [EMAIL PROTECTED] http://www.multicasttech.com Test your network for multicast : http://www.multicasttech.com/mt/ Status of Multicast on the Web : http://www.multicasttech.com/status/index.html
RE: references on non-central authority network protocols
This appears to have bounced due to a configuration error on my end... -Original Message- From: Tony Hain [mailto:[EMAIL PROTECTED]] Sent: Monday, April 15, 2002 11:40 AM To: Stephen Sprunk; Scott A Crosby Cc: Patrick Thomas; [EMAIL PROTECTED] Subject: RE: references on non-central authority network protocols Stephen Sprunk wrote: Interesting idea though. Perhaps someone will write an i-d on autonomous numbering for IPv6. RFC 3041 http://www.tml.hut.fi/~pnr/publications/cam2001.pdf Jasper Wallace wrote: Location - either distribute all the addresses evenly over the planet or try to map to population density. (the higher your density of sites, the more accurate your coordinates need to be). you could aggregate addresses by doing something like: 2 hemispheres 36 'triangular' chunks spaced every 10 degrees latitude. then split up in longditudernal stripes. http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-02.txt but i think you'd be better allocation on the basis of population density. How exactly you'd make the social and economic changes to get to a system like this vs, the telcos/isps we have now is probably more trouble than it's worth ;-P http://www.ietf.org/internet-drafts/draft-hain-ipv6-pi-addr-use-02.txt Tony
