Re: Question on 7.0.0.0/8
At 06:13 PM 4/15/2007, Jeroen Massar wrote: [EMAIL PROTECTED] wrote: >> We checked with IANA, ARIN, and the US DoD regarding 7.0.0.0/8. We >> were told that this netblock should not see the light of day, > > 10/8 used to be a DoD address block, but it was also used exclusively in > their blacker networks and similar non-connected infrastructure. The > result is that 10/8 was opened up for others to use as well. Could we do > similar with 7/8? What problem would that solve instead of reducing a wee tiny bit the collisions that might occur? Large networks are currently already established and renumbering them from 10.0.0.0/8 to 7.0.0.0/8 would still be renumbering. For those networks it is much better to simply get a block from their RIR and use that and never have collisions. Set up a private allocation registry, and allocate chunks of 7/8 (or some other block that is generally available) to companies for a small annual fee. This would open up space for use in private networks that would then be sufficiently unique to cross-connect, merge or at least provide a bit of landing space for use as border addressing in organizations that are hopelessly over-using 10/8, 192.168/16 and 172.16/12 and need some space that's guaranteed unique for dealing with intercompany private interconnects, mergers or whatever. I recall discussion of approaches with IPv6 to do something more intelligent in doling out private address space in ways that'd help limit conflicts. Why not make use of more DoD space to do something like this in IPv4? Also note that Fastweb in Italy is already using 7.0.0.0/8 inside their network for their customers, who sit behind a NAT. Oh well, so much for using that block for a registry driven allocation system then. Any other blocks that could be used? Greets, Jeroen
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
On Mon, Apr 16, 2007, Perry Lorier wrote: > > configure web proxies, > > once you have DNS you can use the WPAD proxy auto discovery thingamabob. .. and the microsoft extensions to support ipv6 in proxy autoconfiguration files: http://blogs.msdn.com/wndp/articles/IPV6_PAC_Extensions_v0_9.aspx http://blogs.msdn.com/wndp/archive/2006/07/18/IPV6-WPAD-for-WinHttp-and-WinInet.aspx Adrian
RE: Question on 7.0.0.0/8
On Sun, 15 Apr 2007 [EMAIL PROTECTED] wrote: Why doesn't IANA operate a whois server? In fact they do operate whois server at whois.iana.org. However that has domain data for .arpa and .int and not IPv4 whois data which IANA has historically provided using flat file pointer while having RIR maintain specific whois data even for /8 directly listed in IANA file. Exactly because they do not operate ip whois in the flat file "based" on IANA data that for me serves as "root": http://www.completewhois.com/iana-ipv4-addresses.txt for each IANA allocated block the listed whois server is whois.arin.net Why don't they publish a more detailled explanation field in each IANA allocation record so that they can explain the precise status of each block? This question as well as suggestion for IANA to operate "root" ip whois server for /8 bloks should probably be sent to [EMAIL PROTECTED] (but its also possible that IANA people reading this list will respond...) Why doesn't IANA and the RIRs collectively get off their butts and actually make an "authoritative IP address allocation directory" one of their goals? And why don't they do all this with some 21st century technology? A new system based on IRIS protocol (XML based using BEEP as transport) will be in place in the future that will work better as a comprehensive directory. -- William Leibzon Elan Networks [EMAIL PROTECTED]
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
When you can plug your computer in, and automatically (with no clicking) get an IPv6 address, Router Advertisements let you automatically configure as many IPv6 addresses as you feel like. > have something tell you where your DNS assist servers, Microsoft had an old expired draft with some default anycast IPv6 nameserver addresses: fec0:0:0:::1 fec0:0:0:::2 fec0:0:0:::3 -- http://tools.ietf.org/id/draft-ietf-ipv6-dns-discovery-04.txt While this was never accepted by the IETF, I believe windows machines still use these by default if they have no other name servers but do have IPv6 connectivity. This could be a fairly simple defacto standard if network operators start using it. This is an obvious weak link in the chain at this point tho. > configure web proxies, once you have DNS you can use the WPAD proxy auto discovery thingamabob. and solve your dynamic dns problems (as IPv4 set top boxes do today), Updating your forward/reverse dns via DNS Update messages isn't that uncommon today. See: http://www.caida.org/publications/presentations/ietf0112/dns.damage.html where hosts are trying to update the root zone with their new names. So you can get from A to D without requiring DHCPv6.
RE: Question on 7.0.0.0/8
On Sun, 15 Apr 2007 [EMAIL PROTECTED] wrote: > As a result, most people consider William Leibzon and the Bogon project > to be, collectively, the authoritative source for information on whose > IP address that is. ^ If that's the case, all hope has been lost. > That's because William and the Bogon project, act authoritative, and > take some pains to provide comprehensive data. At the same time, IANA > and the RIRs just keep doing the same old thing as their data and > systems slowly rot away. > Why doesn't IANA operate a whois server? Why should they? What will it produce? > Why don't they publish a more detailled explanation field in each IANA > allocation record so that they can explain the precise status of each > block? Why should they? > Why doesn't IANA and the RIRs collectively get off their butts and > actually make an "authoritative IP address allocation directory" one of > their goals? > > And why don't they do all this with some 21st century technology? Why doesn't vwl help by giving ARIN his changelog, if any? -alex
Re: Question on 7.0.0.0/8
> > We checked with IANA, ARIN, and the US DoD regarding 7.0.0.0/8. We > > were told that this netblock should not see the light of day, > > 10/8 used to be a DoD address block, but it was also used exclusively in > their blacker networks and similar non-connected infrastructure. The > result is that 10/8 was opened up for others to use as well. Could we do > similar with 7/8? Or better yet, 11/8 (to make 10/7)? Stephen
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
On Sun, Apr 15, 2007, Iljitsch van Beijnum wrote: > With IPv4, PPP IPCP will negotiate a whole bunch of stuff, including > the addresses of both sides of the link. PPP IP6CP only negotiates a > 32-bit unique token for each side which can then be used to create > link local addresses. I'm pretty sure l2tpns has IPv6 support of some sort. I was planning on trialling it in exactly this setup - LNS services for L2TP-provided PPPoE ADSL. Has anyone here done this and enabled IPv6 negotiation? Has anyone sorted out the issues relating to end-point IPv6 security for home PCs now that NAT is removed? Adrian
RE: Question on 7.0.0.0/8
On Sun, 15 Apr 2007, [EMAIL PROTECTED] wrote: > > 10/8 used to be a DoD address block, but it was also used exclusively in > their blacker networks and similar non-connected infrastructure. Er, no, it was the ARPANET's block. (See the Assigned Numbers RFCs up to 990.) Tony. -- f.a.n.finch <[EMAIL PROTECTED]> http://dotat.at/ FISHER GERMAN BIGHT: SOUTHEAST VEERING SOUTH 3 OR 4, OCCASIONALLY 5. SLIGHT. FAIR. GOOD.
RE: Question on 7.0.0.0/8
> > 10/8 used to be a DoD address block, but it was also used > exclusively in > > their blacker networks and similar non-connected infrastructure. The > > result is that 10/8 was opened up for others to use as > well. Could we do > > similar with 7/8? > > What problem would that solve instead of reducing a wee tiny bit the > collisions that might occur? Large networks are currently already > established and renumbering them from 10.0.0.0/8 to 7.0.0.0/8 would > still be renumbering. Renumbering? Was somebody discussing renumbering? The problem that releasing 7/8 would solve is that IANA could allocate it to an RIR and the RIR could allocate it to customers. Given the finite nature of the IPv4 space, it is a bad thing to lock away address blocks that could be used by others. > Also note that Fastweb in Italy is already using 7.0.0.0/8 > inside their > network for their customers, who sit behind a NAT. And I know a company that has been using 1/8, 2/8, 3/8, 4/8, 5/8, 6/8, 7/8 and 8/8 for many years, also behind NAT or on non-Internet connected networks. But that is not what I am talking about here. In fact, I would like to see a mechanism where large address blocks used primarily in a single geographic area, are made available for reuse in other geographic areas. This would extend the lifetime of IPv4. --Michael Dillon
Re: Question on 7.0.0.0/8
On Apr 15, 2007, at 2:58 PM, <[EMAIL PROTECTED]> wrote: And why don't they do all this with some 21st century technology? Do they have the requisite staff and funding? --- Roland Dobbins <[EMAIL PROTECTED]> // 408.527.6376 voice Words that come from a machine have no soul. -- Duong Van Ngo
Re: Question on 7.0.0.0/8
[EMAIL PROTECTED] wrote: >> We checked with IANA, ARIN, and the US DoD regarding 7.0.0.0/8. We >> were told that this netblock should not see the light of day, > > 10/8 used to be a DoD address block, but it was also used exclusively in > their blacker networks and similar non-connected infrastructure. The > result is that 10/8 was opened up for others to use as well. Could we do > similar with 7/8? What problem would that solve instead of reducing a wee tiny bit the collisions that might occur? Large networks are currently already established and renumbering them from 10.0.0.0/8 to 7.0.0.0/8 would still be renumbering. For those networks it is much better to simply get a block from their RIR and use that and never have collisions. Also note that Fastweb in Italy is already using 7.0.0.0/8 inside their network for their customers, who sit behind a NAT. Greets, Jeroen signature.asc Description: OpenPGP digital signature
RE: Question on 7.0.0.0/8
>Is it just me or does all of this have the odor of >amateur hour around it? Inconsistencies between >the various databases, IANA can't make >http://www.iana.org/assignments/ipv4-address-space >such that it's unambiguously parsable, ARIN backdates >some of the address space it gives out, RIPE used to >register address space under "UK" while that's not a >valid country code (they fixed that last year, though), and so on. Yes, I agree that it seems amateurish. I think that about 10 years ago a lot of people became satisfied with the status quo and the technology of IANA and the RIRs stagnated. The world moved on around them but you still see things like IANA's non-parseable text file and ARIN's SWIP system using text templates in email messages. RIPE is not that far ahead either, although they have made a bit of effort. As a result, most people consider William Leibzon and the Bogon project to be, collectively, the authoritative source for information on whose IP address that is. That's because William and the Bogon project, act authoritative, and take some pains to provide comprehensive data. At the same time, IANA and the RIRs just keep doing the same old thing as their data and systems slowly rot away. Anyone who has ever had to deal with data cleansing in a corporate environment knows what I mean about data rot. Systems similarly degrade when the world around them changes. For instance, in Victorian times a wonderful home cleaning device was invented called a vacuum cleaner. It worked like a modern pool vacuum in that you pumped the handle to produce suction. It was an amazing device that could clean the dust out of rugs without hauling them outside, hanging them up and beating them. In todays world it is a quaint museum piece because electricity is now ubiquitous. But the device still works today as well as it did in Victorian times. That is how systems degrade. Why doesn't IANA operate a whois server? Why don't they publish a more detailled explanation field in each IANA allocation record so that they can explain the precise status of each block? Why doesn't IANA and the RIRs collectively get off their butts and actually make an "authoritative IP address allocation directory" one of their goals? And why don't they do all this with some 21st century technology? --Michael Dillon
RE: Question on 7.0.0.0/8
> We checked with IANA, ARIN, and the US DoD regarding 7.0.0.0/8. We > were told that this netblock should not see the light of day, 10/8 used to be a DoD address block, but it was also used exclusively in their blacker networks and similar non-connected infrastructure. The result is that 10/8 was opened up for others to use as well. Could we do similar with 7/8? --Michael Dillon
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
On 15-apr-2007, at 21:35, Joe Abley wrote: With IPv6, there's of course still manual configuration, but PPP is out because it can't negotiate IPv6 addresses. I've heard you say this a few times now, but I am also told by various people in various places that they have succeeded in getting IPv6 addresses assigned using PPPoE. Colour me confused. Does RFC 2472 have some practical limitations in the real world that I haven't noticed? Or is the problem a simple matter of implementation? With IPv4, PPP IPCP will negotiate a whole bunch of stuff, including the addresses of both sides of the link. PPP IP6CP only negotiates a 32-bit unique token for each side which can then be used to create link local addresses. Two years ago, when I was writing my IPv6 book, I did some testing between an Cisco 2500 and a MacOS 10.4 system to see how IPv6 over PPP behaves, and the result was that it did work, but there was no address assignment from the router to the Mac, not through PPP, because it doesn't support it, and not through router advertisements, for reasons unknown. Probably someone decided that stateless autoconfig on a point to point link didn't make sense. (Note that the pppd in question is common to both the BSD family and Linux.) I have no idea what's different in the PPP over ethernet setup, but it could be many things, such as that the PPP implementations do support stateless autoconfig there, or that it's not actual IPv6 over PPP but rather IPv6 over IPv4 or over bridged ethernet.
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
On 15-Apr-2007, at 06:38, Iljitsch van Beijnum wrote: With IPv6, there's of course still manual configuration, but PPP is out because it can't negotiate IPv6 addresses. I've heard you say this a few times now, but I am also told by various people in various places that they have succeeded in getting IPv6 addresses assigned using PPPoE. Colour me confused. Does RFC 2472 have some practical limitations in the real world that I haven't noticed? Or is the problem a simple matter of implementation? Joe
Re: 1500 does not work: Thoughts on increasing MTUs on the internet
Marshall Eubanks wrote: Dear Pete; The streaming servers that I have dealt with (such as Darwin Streaming Server) do the fragmentation at the application layer. They thus send out lots of packets at or near (in this case) 1450 bytes, but they are not UDP fragments. That's the whole point - many networks will not deliver fragments at all, much less the increased risk of loss when they do. (I use Cox Cable at home, and this network apparently does not forward fragments and also has an apparent MTU of 1480 bytes.) Just looked at a YouTube dump, btw, and almost all of the packets are 1448 bytes. I'm referring to Windows Media and Real. They are the worst offenders, though not too many use them without HTTP. Pete
Re: 1500 does not work: Thoughts on increasing MTUs on the internet
On Apr 15, 2007, at 1:49 AM, Petri Helenius wrote: Marshall Eubanks wrote: I advise people doing streaming to not use MTU's larger than ~1450 for these sorts of reasons. The unfortunate side-effect of that is that most prominent streaming apps (don't know about Youtube though) then send fragmented UDP packets which leads to reassembly overhead and in case of lost packets, a significantly larger lost data than neccessary. Pete Dear Pete; The streaming servers that I have dealt with (such as Darwin Streaming Server) do the fragmentation at the application layer. They thus send out lots of packets at or near (in this case) 1450 bytes, but they are not UDP fragments. That's the whole point - many networks will not deliver fragments at all, much less the increased risk of loss when they do. (I use Cox Cable at home, and this network apparently does not forward fragments and also has an apparent MTU of 1480 bytes.) Just looked at a YouTube dump, btw, and almost all of the packets are 1448 bytes. Regards Marshall Kind regards Peter and Karin Dambier Regards Marshall --Peter and Karin Dambier Cesidian Root - Radice Cesidiana Rimbacher Strasse 16 D-69509 Moerlenbach-Bonsweiher +49(6209)795-816 (Telekom) +49(6252)750-308 (VoIP: sipgate.de) mail: [EMAIL PROTECTED] mail: [EMAIL PROTECTED] http://iason.site.voila.fr/ https://sourceforge.net/projects/iason/ http://www.cesidianroot.com/
Re: DHCPv6, was: Re: IPv6 Finally gets off the ground
On 13-apr-2007, at 21:48, David W. Hankins wrote: A given ISP may or may not directly communicate with end hosts using any form of DHCP, but the current broadband ISP models which are de rigeur would not be salient without DHCPv4 on the end hosts, even if that is only between the set top box and customer. Sure, but that's because with IPv4, there are only three flavors: - manual configuration - PPP - DHCP With IPv6, there's of course still manual configuration, but PPP is out because it can't negotiate IPv6 addresses. New in IPv6 is stateless autoconfiguration, which will give you addresses and default gateways, but (so far) not extra info such as DNS addresses. The situation for DHCP in IPv6 is very different from the one in IPv4: because DHCPv6 was late to the party (IIRC the final RFCs came out around 2003, decent implementations are still not abundant) and we have stateless autoconfig, the focus for DHCPv6 was to provide additional information (those !#$ DNS addresses) and a new trick: prefix delegation. This is a mechanism where routers can lease a prefix from a DHCP server, and then use that prefix in their router advertisements. This is a great tool for provisioning. The DHCPv6 servers and clients that I tested two years ago didn't even support address assignment to hosts. And note that even when hosts do, and a DHCPv6 server is available, these hosts must still listen for router advertisements because DHCPv6 doesn't provide a default gateway address, like DHCP for IPv4 does. What DHCP and PPP did do, was to remove all of that, and make ISP integration of customer premise something that could "just happen" without any handholding or bearded geekery. Fortunately, the IETF got things right the sixth time around (?) by adding the stateless autoconfig to IPv6, so these additional mechanisms aren't necessary. When you can plug your computer in, and automatically (with no clicking) get an IPv6 address, Like I said, this part has never been a problem with IPv6. have something tell you where your DNS assist servers, There will be a router advertisement option to learn DNS servers. Note though, that this is only an issue for hosts that are IPv6-only, which isn't exactly the typical use case today. configure web proxies, ?? and solve your dynamic dns problems Which dynamic DNS problems? It works just fine for me. On the subject of DNS, I think you are going to find that, since IPv6 addresses do not pass the 'phone test', IPv6 customers will have a new emphasis on having their names in DNS. And exactly how often do people type in the address of their own system...? A problem with the DNS and IPv6 is that unlike IPv4, you can't pre- populate the DNS so that each host has a valid DNS name as soon as it receives an address. Manual configuration is problematic for more than the obvious reasons: host may use temporary IPv6 addresses with random lower bits to avoid exposing their MAC address. The only reasonable way to solve this is with dynamic DNS updates. This would be bad except that customers will usually have their own prefix in IPv6 so this should be solvable security-wise.
