Re: Why IPv6 is a must?
Noel, At 02:36 PM 11/30/2001 -0500, J. Noel Chiappa wrote: ** Most, if not all, of the same people who are refused IPv4 address ** allocations will (or should if we expect not to re-create the swamp) be ** refused allocations of IPv6 addresses. Holy smoke! That's really major. Huh? This really shouldn't (at this late date) be a surprise to anyone. RIRs allocate TLAs (or sub-TLAs) to TLA Registries. TLAs are the only prefixes that are supposed to be in the default free zone routing tables. Ergo... I hadn't realized the registries were trying to guard against routing table bloat as well as address space exhaustion. I'm curious, when did this start, and how was it decided? Ever since the RIRs existed? See goal number 2 of section 1 of ftp://ftp.isi.edu/in-notes/rfc2050.txt or section 2.2.2 of http://www.arin.net/regserv/ipv6/IPv6.txt. As to how it was decided, my guess would be by default. Rgds, -drc
Re: Why IPv6 is a must?
At 12:53 PM 11/29/2001 -0500, Keith Moore wrote: the only benefit that IPv4 has over IPv6 (relative to routing table size) is that IPv4 discourages growth of the Internet. Only? Please. An obvious benefits of v4 over v6 is that it is deployed. Another benefit is the operational experience gained over the years running v4 infrastructures. NAT, despite being the spawn of the devil, at the very least leverages both of these advantages. More realistically, some might consider IPv4 address allocation policies as discouraging the growth of the Internet (I am not among them), but I remain unconvinced IPv6 address allocation policies will be significantly different in the aspects that cause people to be discouraged. Most, if not all, of the same people who are refused IPv4 address allocations will (or should if we expect not to re-create the swamp) be refused allocations of IPv6 addresses. Rgds, -drc
Re: [midcom] WG scope/deliverables
Keith, At 10:44 PM 2/14/2001 -0500, Keith Moore wrote: If end users are required to modify configuration files, you will see NAT so they don't have to. not if the NATs cause more pain than modifying the config files. True. However, a company that produces a NAT that is more painful to use/operate than modifying config files will not likely be in business long. I presume that "technogeeks" includes networking professionals who can't make their B2B applications work reliably over NATs? Given the penetration of NAT, particularly in the business world, I suspect B2B applications that do not work with NAT will not exist too long. Rgds, -drc
Re: [midcom] WG scope/deliverables
Eric, Odd. Every time I renumbered some site (hq.af.mil and sundry other sites sharing similar characteristics), there was neither a NAT prior to, nor subsequent to, the renumbering. If they are already using NAT, it is most likely they wouldn't need your services to renumber, no? Rgds, -drc
Re: [midcom] WG scope/deliverables
Noel, At 01:20 AM 2/15/2001 -0500, J. Noel Chiappa wrote: Why do I have to change street addresses just because I moved? A very good reason your name is separate from your address. Good thing you didn't choose telephone numbers in your rant, huh? In any event, my point (in case you missed it before getting wound up for your rant) was that people find renumbering hard will choose not to renumber given the choice. NAT provides them a choice, like it or not (I personally don't care -- I see NAT as a tool with advantages and disadvantages like any other tool). As long as IPv6 has only one namespace to say *who* you are, as well as *where* you are, your address will change when you change providers. Yes. It astonishes me how many people have been unable to grasp this and assume that magic happens when you go from 32 bits to 128 bits. As the old hackers say, "That's not a bug, that's a feature." The bug is that who and where are not separated, but I suspect you won't argue with that. Rgds, -drc
Re: [midcom] WG scope/deliverables
At 05:53 PM 2/14/2001 -0800, Michael W. Condry wrote: I assume with IPv6 there is no need for NATs. IPv6 does not solve the need to renumber if you change providers (and no, not everyone can be a provider -- IPv6 uses CIDR, just like IPv4). Until that issue is addressed, there will be NATs. Even for v6. Rgds, -drc
Re: [midcom] WG scope/deliverables
Keith, At 10:02 PM 2/14/2001 -0500, Keith Moore wrote: IPv6 does not solve the need to renumber if you change providers (and no, not everyone can be a provider -- IPv6 uses CIDR, just like IPv4). Until that issue is addressed, there will be NATs. Even for v6. I don't think so - first, because IPv6 has more hooks for renumbering than v4 (though more work is needed); If end users are required to modify configuration files, you will see NAT so they don't have to. and second, because a lot of folks will want to use IPv6 precisely because they need to avoid NAT breakage. Technogeeks, perhaps. The vast majority of people on the Internet who are behind NATs most likely don't even know it. Rgds, -drc
Re: Number of Firewall/NAT Users
At 11:52 AM 1/23/2001 +, Jon Crowcroft wrote: o'dell's GSE draft addressed renumbering perfectly. And look how far it got. Rgds, -drc
Re: [Fwd: Re: getting IPv6 space without ARIN (Re: PAT )]
| Please, please, nobody ever pick a prefix at random. For one reason (of several), who's going to delegate you the reverse DNS (ip6.arpa) space to go with it? ?? The discussion was about non-transit provider (what that is) addresses that aren't connected to the (IPv6) Internet. I'm missing something obvious here. Rgds, -drc
Re: getting IPv6 space without ARIN (Re: PAT )
Bertrand, And what DNS server software supports IPv6 address records? See http://www.isc.org/products/BIND/bind9.html (the only server I know of that supports A6, I'd be very happy to hear of another so we can do interop testing). Rgds, -drc
Re: getting IPv6 space without ARIN (Re: PAT )
Daniel, For all the sites in the world who'd LIKE to be able to have an upstream to provide IPv6, but for whom such doesn't exist, and probably won't for a long time, some one or few organizations should look into buying a block of IPv6 space, setting up a few routers which can handle lots of tunnels, and build a virtual IPv6 upstream. I'm sorry if I was unclear. I was speaking of IPv6 network topology when I was saying "upstream provider", regardless of whether that provider is using native IPv6 or tunnels or whatever. The ISP providing the service provider endpoint of the tunnel should allocate space to their customer, even if that customer is getting to them via a tunnel through another ISP. I'm surprised this isn't already on the service menu of those ISPs that have begun deploying IPv6... Rgds, -drc
Re: IPv6: Past mistakes repeated?
For the archives of the historic PIARA discussions, see http://www.apnic.net/wilma-bin/wilma/piara (I think the mailing list is still alive) Rgds, -drc "Steven M. Bellovin" wrote: In message [EMAIL PROTECTED], "J. Noel Chiappa" writes : From: Greg Skinner [EMAIL PROTECTED] There was a similar discussion here about five years ago where some people proposed market models for address allocation and routing. Unfortunately, it's not in the archives. I think it was on CIDRD, actually, no? If anyone has this discussion archived, could they please point me to it? Well, one thing I do have is the draft of: "Suggestions for Market-Based Allocation of IP Address Blocks", by Paul Resnick (then of ATT Research, I don't know where he is now - Paul, you out there?), which I have at: http://ana-3.lcs.mit.edu/~jnc/tech/addr_charging.txt It never turned into an RFC (shame, I thought it was a really well thought out draft), and I don't think it's anywhere else permanent. See http://www.research.att.com/~smb/papers/piara/index.html, by Paul, Yakov Rekhter, and myself. --Steve Bellovin - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand.
Re: IPv6: Past mistakes repeated?
Heh. I know someone who wants to offer a class B at seven figures and for class B's that "sold" for 5 figures. And you say addresses have no value. Ah, nostalgia. It's so nice to revisit old "discussions"... Rgds, -drc Bill Manning wrote: Sigh, Please -NOT- the PIARA again. There is near zero value in the number/address and very real value in the routing slot. Perhaps it is best to simply have ebone route filter on the /16 boundaries to drive home your point. (being cranky this morning) % I would like to see a market develop for IPv4 addresses, along the % lines of the late PIARA work. This would also encourage a % market for routing-table entries, both of which would produce a significant % incentive to dramatically improve upon on-the-fly host-renumbering. % % Sean. % % P.S. by "routing-table entries", I mean of course, not just the % consumption of memory and CPU resources in forwarding packets % in to large numbers of possible destinations, but also the cost % in various resources (bandwidth, CPU, complexity) of acquiring % and propagating information which may lead to routing-table changes. % % -- --bill - This message was passed through [EMAIL PROTECTED], which is a sublist of [EMAIL PROTECTED] Not all messages are passed. Decisions on what to pass are made solely by Harald Alvestrand.
Re: draft-ietf-nat-protocol-complications-02.txt
Keith, even the DNS names for major services may not be well maintained. at one time I did a survey of the reasons for mail bounces for one of my larger mailing lists. You appear to be saying that because historically people screwed up configuring their DNS that it is impossible to rely on the DNS for critical infrastructure. This seems wrong to me. If a properly configured DNS was a fundamental requirement of a working network connection as is assumed by something like 8+8, I think it fairly certain that any misconfigurations would be fixed as quickly as (say) a BGP misconfiguration. Rgds, -drc
Re: draft-ietf-nat-protocol-complications-02.txt
Thomas, This is not true. IPv6's TLA scheme has as its primary goal placing an upper bound on the number of routing prefixes that are needed in the core. ... Contrast that with today's IPv4 where the number of prefixes that need to be maintained in the DFZ in order to have global reachability is more-or-less unbounded, so some prefixes are not reachable from everywhere. As you know, this is not IPv6 magic. The underlying routing technology between v4 and v6, namely CIDR, is identical. The only difference is that _by convention_, the number of routing prefixes in v6 is limited. If we were to create an IPv4 Internet' without the historical baggage of the existing IPv4 Internet, the same conventions could be applied. Thus, traditional multihoming is still quite possible, assuming the various ISPs that need to handle the routes agree to do so. I find it a bit strange that people seem to think the logic / incentives / disincentives that drive multihoming in the v4 Internet will not apply in the v6 Internet. Rgds, -drc
Re: draft-ietf-nat-protocol-complications-02.txt
Keith, a 92.55% reliability rate is not exactly impressive, at least not in a favorable sense. it might be tolerable if a failure of the PTR lookup doesn't cause the application to fail. If people's livelihood depends on something, they're more likely to insure it actually works. Very little depends on PTR records doing anything (with a relatively few exceptions of sites that configure it otherwise). The fact that Bill's getting a 92.55% reliability figure for something that the vast majority of people use to get something other than IP addresses in logfiles is actually surprisingly good. if applications were written to depend on DNS reverse lookups in order to get endpoint identifiers of their peers, they would only work as reliably as DNS, which isn't very good. If it "isn't very good", try using the Internet without it for a bit. In your view, what is it in the DNS protocol(s) that results in a lack of reliability? Rgds, -drc
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
Rick, I hate to add a "me too" but I must. I believe that the RAB minutes would be very useful if they were published. Has any other organization interested in publishing an informational RFC needed to also publish the internal discussions that led to the implementation of their proprietary protocol? I am glad that NSI has published the I-D for their protocol, now does it need to go beyond that and become an RFC, IMHO, no. I-Ds expire. The IETF does not need to publish broken implementations of one companies view of the shared gTLD registration process. Then you were unhappy that (oh, say) Cisco submitted RFC 2281 as an informational RFC (not saying HSRP is "broken", but I'm sure someone would). Having an AD that sat on the RAB promote the I-D and offer no reasoning as to why it *should be* published as an Informational RFC reminds me of the bad taste left by the IAHC and all the processes related. I find this offensive. I was among those who encouraged NSI to publish the RRP as an informational RFC as I felt it would be in the best interests of everybody to have the RRP protocol publically examined and I feel NSI should be commended for documenting their protocol. However, INFORMATIONAL RFCS DO NOT IMPLY ENDORSEMENT. The draft is a representation of an existing, in use proprietary protocol. No further justification should be necessary for documenting it as an informational RFC. Rgds, -drc
Re: Last Call: Registry Registrar Protocol (RRP) Version 1.1.0 to Informational
Ed,
the issue is what
is being presented by NSI to be an informational IETF RFC, not whether
we should commend NSI for doing or not doing anything in their own
benefit. This is yet not the Internet Marketing Study Group.
Nor is it the Internet Inquisition ("No one expects the Internet
Inquistion..."). NSI was under no obligation to publish the RRP. That they
have done so is to the benefit of folks who are interested in this sort of
thing. Requiring anyone who submits a proprietary protocol to the IETF for
publication as an informational RFC to also publish the minutes of internal
discussions that led to the development of that protocol sounds like a really
good way to keep anyone from publishing proprietary protocols.
NSI should be treated no differently than others who publish proprietary
protocols as an informational RFC.
However, to anyone versed in technical work it is clear that if the
references to a work are missing, and if those references actually
*deny* the work being presented, then there is something basically
wrong with the entire process.
You might want to acquaint yourself with the process before declaring it
"wrong".
Note also that the RAB, its meeting Minutes and its Action Points are also
not the result of an NSI private initiative as we know, Conrad, but an
obligation upon NSI by an oversight body and a regulating US agency in a
legal contract.
While it is true, Gerck, that the RRP is a requirement of the Amendment 11, I
do not believe NSI was under any obligation to publish _anything_ outside of a
license agreement with NSI and, in fact, the USG is required "to protect the
confidentiality of such data, software and documentation so delivered".
Rgds,
-drc
Re: IP network address assignments/allocations information?
Brian, DNS doesn't make a choice. If there are multiple addresses, it returns all of them. The host makes the choice. Let me introduce you to today's current crop of DNS-based load balancing "solutions". For example, from http://www.resonate.com/products/global_dispatch/faqs.php3: How does Global Dispatch relate to DNS architectures? Global Dispatch is an authoritative DNS solution- meaning that it integrates into a DNS architecture- but actually replaces existing 'dumb' authoritative DNS capabilities. The Global Dispatch scheduler sits behind an existing authoritative DNS server, such as BIND or Microsoft's DNS server. Global Dispatch resolves a virtual hostname into the IP address of a physical POP. When a client's local DNS server makes an address resolution request for a virtual hostname, Global Dispatch responds with the IP address of the most available physical POP based on latency and load information it receives from agents installed at each POP. Rgds, -drc
Re: To address or NAT to address?
Charlie, DNS is supposed to be a way to resolve domain names into IP addresses. As a hammer is supposed to be a way to pound nails. However, when it is perceived that all you have is a hammer, it is amazing what begins to look like nails. How else would one get an IP(v6) address from a domain name other than by using DNS? Am I missing something here? Yes. The DNS has grown a bit from a simple lookup mechanism. Rgds, -drc
Re: To address or NAT to address?
Steve, I think the point Charlie was making is that IP addresses are precisely the kinds of nails that the DNS was designed to hammer. And I agree. Are you claiming that because the DNS has been used to pound other things, it is no longer any good for hammering (IP address) nails? Not at all. The DNS is (still) a wonderful system for translating IP addresses to names and vice versa. I'm a bit skeptical that the other things the DNS has been pressed into action to do is optimal, but I also see the "nail-ness" of many problems. My point was that suggesting that reliance should not be placed on the DNS has been, is, and most likely will be contrary to what happens in the real world. Rgds, -drc
Re: To address or NAT to address?
Christian, Increasing our reliance on the DNS is definitely not a good idea. Hmmm. This would appear to be the exact opposite of what the IETF has done with IPv6. Rgds, -drc
Re: To address or NAT to address?
Cary, Is this something that you think is an inherent flaw in DNS? Inherent flaw in the DNS: probably not. Inherent flaws in implementations of DNS (including, of course, ISC's BIND) and things in front of the DNS: probably. It is far too easy to do the wrong thing. And if this is true today, just wait -- DNSSEC and IPv6-related RRs create entire new universes of "interesting" configuration options with some _really_ fun interactions. Will this new class of servers be less susceptible to congestion? I am a bit skeptical that congestion is the problem. I suspect misconfiguration (lame servers, bad ACLs, broken firewall rules, etc.) is a more likely cause that results in retransmissions. Rgds, -drc
