Re: Stupid NAT tricks and how to stop them.
Interesting discussion. Keith is hitting all the nails on the head. Phillip seems to suggest that consumers buy NATs out of choice. They don't have any choice. I surveyed my final years students last month. Just four have a static IPv4 allocation for their home network, and only one has more than a /32 for use internally. ISPs just don't give you a choice (unless you are prepared to pay a non-negligible fee). If you deply IPv6 NAT, you may as well stay with IPv4. The first ISPs offering IPv6 are offering /48's here. The allocations to FT etc (they have a /19) are clearly made on the basis of end site /48's. See also http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt We have deployed IPv6 in our enterprise (throughout). We're seeing some early benefits from (student) driven new services. Students are also using transition mechanisms to enable simpler use of applications between homes (rather than battling a NAT out and a NAT in on communication paths). No regrets from deploying, no significant issues either for the existing IPv4 service. And there's more than just address space to take advantage of, like embedded RP for multicast applications. Tim On Tue, Mar 28, 2006 at 12:48:13AM -0500, Keith Moore wrote: In this case the benefit to running NAT on my home network is that it saves me $50 per month in ISP fees, means I have wireless service to the whole house and means that guests can easily connect. one immediate benefit to my running IPv6 on my home network is that I can access any of my machines from anywhere else on the network (via 6to4), as long as I'm not behind a NAT. my home network also has a v4 NAT, so it's not as if they're mutually exclusive. I have never seen a coherent, rational argument as to why the network numbering on my internal network should be the same as the network numbering on the Internet. obviously you've never tried to write a distributed application in a NATted network. and presumably you never tried to do anything with UUCP mail (which had naming conflicts) or a large DECnet (which had address conflicts). the problems are immediately obvious to those of us who have had to deal with those disasters. in brief: one reason is so that apps can have the same view of the network regardless of whether they're hosted on your internal network, or on an external network, or on a combination of the two. it's MUCH simpler if apps don't have to worry about the fact that host A has address A1 from network X and address A2 from network Y. particularly since in a network with scoped addresses, hosts don't really have any way of knowing which network they're on. there are other reasons also: routing, coherent network management, DNS consistency. a network with scoped addressing is like a city where all of the streets have the same name. it becomes pretty difficult to navigate. People will still want to do NAT on IPv6. true. people do all kinds of evil things that break the net. our protocols will only work to the extent that people follow the specifications. when people start breaking things, the protocols and applications start failing. NAT is a good example. in ipv6, we can provide better ways of solving the problems that people think they're solving with NATs. if we fail to do that, or if people insist on using NATs anyway, we're screwed. but that's not a reason to give up without trying. either do something to help or get out of the way. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Today, 90% of the phones in the world are still analog. Including mine, in the capital of California and my buddies' in the heart of Silicon Valley. the (static) statement that 90% of phones are analog seems very wrong to me. according to newest ITU-D estimates, by the end of 2004, there were 1.2 billion land lines, with an average annual growth rate of 5.8% since 1999. this means 18.99 lines per 100 world inhabitants [1]. i ignore how many of these lines are analog, but what is for sure is that the most phones today do not have any lines at all: at the same time, the ITU registered 1.76 billion cellular subscribers, with an annual growth rate of 29% since 1999. This makes up for 27.61 phones per 100 world inhabitants [2]. the vast majority of cellular phones are not analog (GSM+ being the nr 1 technology [3]) and thus probably less than 50% of world phones are analog. i don't know how this relates to the current nat/ipv6/ipv4 discussion, but the argument above could be easily turned into a counter-argument: one could have said that with the original analog phones we were not able to solve the digital divide in the voice service and a new technology has become necessary :-) regards artur [1] http://www.itu.int/ITU-D/ict/statistics/at_glance/main04.pdf [2] http://www.itu.int/ITU-D/ict/statistics/at_glance/cellular04.pdf [3] http://www.gsmworld.com/index.shtml ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 28 mar 2006, at 00.11, Keith Moore wrote: NAT is a done deal. It's well supported at network edges. It solves the addressing issue, which was what the market wanted. It voted for NAT with dollars and time. It is the long term solution - not because it is better, but because it is. NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. It will gradually be replaced by networks that are more-or-less IP based but which only run a small number of applications, poorly, and expensively. ...or you will see an overlay network build on top of NAT+IPv4 that abstracts the shortcomings away - aka what the peer to peer networks are doing. End-to-end addressing... - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Tim Chown wrote: If you deploy IPv6 NAT, you may as well stay with IPv4. Tim, You're the one who convinced me some three years ago that there will be IPv6 NAT no matter what, what's the message here? See also http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt Remember: Users don't read drafts/RFCs. We have deployed IPv6 in our enterprise (throughout). Could you have done it if you did not have the research dollars^H^H^H^H pounds? Artur Hecker wrote: the (static) statement that 90% of phones are analog seems very wrong to me. My bad, I should have said land lines. Hallam-Baker, Phillip wrote: I have never seen a coherent, rational argument as to why the network numbering on my internal network should be the same as the network numbering on the Internet. Phillip, there a few (such as: NAT typically requires hard state, which is a pain to replicate if there is more than one edge router). NAT is not completely evil, but it's far from being clean. Pretending that there are no good reasons against NAT is going to achieve the same as trying to eliminate it: nothing. People will still want to do NAT on IPv6. Yes, and since site-locals have been deprecated they will also hijack an unallocated block of addresses to use as private, same what happened prior to RFC 1597 for the very same reasons (difficult/pricey to get PI). Austin Schutz wrote: ...that opportunity may be to enhance NAT rather than throw it away Austin, this has been tried many times and never went anywhere. As there are no changes in the reasons it has failed in the past I don't see how this could make it this time. Michel Py wrote: A protocol that would be only v4 with more bits in the first place, with routers / NAT boxes that would pad/unpad extra zeroes (also including extra TBD fields). As this would be 100% compatible with v4 this could be deployed without too many headaches. Keith Moore wrote: huh? there is no way to make a protocol that can address more hosts than v4, that is 100% compatible with v4. and there's no good way to divide up the net into v4 enclaves and v6 enclaves because the applications that need v6 addressing don't fit neatly into enclaves. As long as you don't use the extra bits, no problem. IPv4 on one side, IPv4+ on the other; when going from v4 to v4+ add a bunch of zeroes, when going to v4+ to v4 remove a bunch of zeroes. Initially it's a total waste of bits, but silicon is cheap these days. When people will begin to scream bloody murder to use the extended bits (because v4 is getting near exhaustion) the infrastructure could be already in place, and then the pressure will be on software developers to recode their stuff with 128-bit addresses. When that has happened, then we can make use of all these reserved fields for better purposes, and possibly allocate PI to everybody which is another pre-requisite to get rid of NAT. Michel. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
[cc trimmed] On Tue, 2006-03-28 at 01:54 -0800, Michel Py wrote: People will still want to do NAT on IPv6. Yes, and since site-locals have been deprecated they will also hijack an unallocated block of addresses to use as private, same what happened prior to RFC 1597 for the very same reasons (difficult/pricey to get PI). I guess you missed out on: http://www.iana.org/assignments/ipv6-address-space FC00::/7 Unique Local Unicast[RFC4193] You can use that to generate your local prefix and it is much better than site-locals as the chance of collisions is fairly low. And as you know you simply don't want to do a NAT from 10/8 to 10/8 at one point in time when two big companies merge ;) Michel Py wrote: A protocol that would be only v4 with more bits in the first place, with routers / NAT boxes that would pad/unpad extra zeroes (also including extra TBD fields). As this would be 100% compatible with v4 this could be deployed without too many headaches. (I almost got lost in the attribution level here) Then why is IPv6 causing so many headaches? As one can see 6to4 is mostly making up your IPv4+ address from the IPv4 one by doing: 2002 + ipv4 address + padding bytes ;) Ah, of course, one actually need to upgrade most of the internal stuff and upgrade all the applications, convince managers, get money to do it, do training etc... Also for the rest of the thread, overlaying IPv6 over IPv4: RFC4380 Which is more or less a p2p overlay network using IPv6 as the addressing part and thus leveraging a lot of applications already. Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On Mon, Mar 27, 2006 at 11:35:21PM -0500, Keith Moore wrote: now if what you're saying is that we need a standard NAT extension protocol that does that, I might agree. though IMHO the easiest way to do that is to make the NAT boxes speak IPv6. Yes, I am saying we need this or something similar. It seems like the current solution I've seen implemented is something like static port mapping with private ip space behind the NAT for most applications. There's still the limited known ports issue (discussed earlier) among several others which are as yet either unsolved or unimplemented on the global scale. again, this doesn't really solve the problem - it only nibbles off a small corner of it. NATs do harm in several different ways - they take away a uniform address space, they block traffic in arbitrary directions, they hamper appropriate specification of security policies, and these days they often destroy transparency. You have to fix all of those problems and still preserve (improve!) the plug-and-play nature of the NAT. what you end up with is something like a router that does both v4 and v6, autoconfiguring itself in both cases (including getting address blocks from upstream networks), with transparent v6, NAT on v4, a sort of generic IPv4 application socks-like proxy built into the NAT that lets v4-only apps allocate outside addresses/ports, accept connections on them, and also initiate connections from them. This sounds workable. But I really question whether there is an adequate userbase who cares enough about these problems enough to support the development and deployment of the more complex system you suggest. The limitations of NAT you mention make little difference to most of the NAT users I am familiar with. These are typically end users or small organizations. They generally don't know what they are missing, and NAT works adequately well for their purposes. I don't foresee them switching or enhancing unless there is some killer application as yet unsurfaced which demands it and won't work adequately well with a limited amount of bizarre hacks and workarounds. The financial penalty from using non-natted ipv4 space is less of an issue to larger organizations. When address space becomes a more scarce resource globally will they care enough about the limitations above and beyond what bizarre NAT hacks marginally solve to fund ipv6 implementation? Maybe. I haven't seen any evidence of it yet, but maybe some time in the future they will. Austin ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On Tue Mar 28 11:33:27 2006, Austin Schutz wrote: The limitations of NAT you mention make little difference to most of the NAT users I am familiar with. These are typically end users or small organizations. They generally don't know what they are missing, and NAT works adequately well for their purposes. Ah, but there's more. NAT is sold as a firewalling solution, not as a cheap hack to share a single-user DSL. The financial penalty from using non-natted ipv4 space is less of an issue to larger organizations. The first time I saw NAT outside of the hacker-at-home was in a reasonably sized ISP, about ten years ago. Since NAT is sold as a foolproof plug-and-play firewall - the lack of global addressability is promoted as an advantage - then larger organizations do use it. Dave. -- You see things; and you say Why? But I dream things that never were; and I say Why not? - George Bernard Shaw ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
If you can't provide the functionality that the customers want your protocol purity comes down to 'you have to do it our way, oh and by the way we have no interest in listening to you'. which is why some of us wrote draft-ietf-v6ops-nap Brian ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On Mar 28, 2006, at 5:50 AM, Dave Cridland wrote: On Tue Mar 28 11:33:27 2006, Austin Schutz wrote: The limitations of NAT you mention make little difference to most of the NAT users I am familiar with. These are typically end users or small organizations. They generally don't know what they are missing, and NAT works adequately well for their purposes. Ah, but there's more. NAT is sold as a firewalling solution, not as a cheap hack to share a single-user DSL. NAT may be sold as a firewalling solution, but that doesn't make it so. Regards Marshall The financial penalty from using non-natted ipv4 space is less of an issue to larger organizations. The first time I saw NAT outside of the hacker-at-home was in a reasonably sized ISP, about ten years ago. Since NAT is sold as a foolproof plug-and-play firewall - the lack of global addressability is promoted as an advantage - then larger organizations do use it. Dave. -- You see things; and you say Why? But I dream things that never were; and I say Why not? - George Bernard Shaw ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. It will gradually be replaced by networks that are more-or-less IP based but which only run a small number of applications, poorly, and expensively. ...or you will see an overlay network build on top of NAT+IPv4 that abstracts the shortcomings away - aka what the peer to peer networks are doing. End-to-end addressing... the overlay networks depend on having some hosts that aren't behind a NAT to serve as tunnel endpoints for hosts that do. this will become less viable in the future as IPv4 address space gets more and more scarce. also, for the most part, overlay networks do not perform as well as native networks (there are exceptions, as in bittorrent). so they do not abstract (all of) the shortcomings away. OTOH, one transition path away from NATs might be to extend NATs so that they support creation of overlay networks. such devices could also aid v4/v6 coexistence. Keith ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
Hello; On Mar 27, 2006, at 11:13 PM, Anthony G. Atkielski wrote: Keith Moore writes: NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. I hardly think so, but in any case, the solution is pretty simple: give out IP addresses for free, instead of charging an arm and a leg for anything other than a single address. As long as ISPs won't provide multiple addresses, or won't provide them except at unreasonably high prices, NAT will remain. This is connected to IPv6 address assignment policies at your friendly local RIR. I would urge that people who are interested in this issue in the ARIN region join the PPML mailing list and even consider coming the Montreal ARIN meeting next month. There are two proposals coming up, 2005-1 and 2006-4, which would both relax the assignment of PI IPv6 space. Regards Marshall Eubanks ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On Tue, Mar 28, 2006 at 01:54:52AM -0800, Michel Py wrote: Tim Chown wrote: If you deploy IPv6 NAT, you may as well stay with IPv4. You're the one who convinced me some three years ago that there will be IPv6 NAT no matter what, what's the message here? I think there will be IPv6 NAT, because some people will want it. That doesn't mean it's rational to deploy it :) See also http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt Remember: Users don't read drafts/RFCs. And users don't walk into PC World and say 'I'd like a NAT router for my home network please'. They probably ask for a broadband modem, or something that doesn't specify NAT. We have deployed IPv6 in our enterprise (throughout). Could you have done it if you did not have the research dollars^H^H^H^H pounds? While we ironed out many issues with research funding assistance in 6NET, I would say the deployment we have now could be done as part of a natural evolutionary procurement process. The 'cost' is real terms is not that high. We have had to invest time in updating OSS-type elements, but much of the rest comes 'out of the box'. I guess we would have had some training costs as a 'normal' enterprise, but we've helped address that in the academic community by running hands-on IPv6 workshops (just as the Internet2 people do for their community). Phillip, there a few (such as: NAT typically requires hard state, which is a pain to replicate if there is more than one edge router). NAT is not completely evil, but it's far from being clean. Pretending that there are no good reasons against NAT is going to achieve the same as trying to eliminate it: nothing. I note Phillip's extremes of view on IPv6 and DNSSEC. It's interesting to compare how critical these two elements are, and his views on them. Yes, and since site-locals have been deprecated they will also hijack an unallocated block of addresses to use as private, same what happened prior to RFC 1597 for the very same reasons (difficult/pricey to get PI). There are now ULAs, http://www.ietf.org/rfc/rfc4193.txt. When people will begin to scream bloody murder to use the extended bits (because v4 is getting near exhaustion) the infrastructure could be already in place, and then the pressure will be on software developers to recode their stuff with 128-bit addresses. When that has happened, then we can make use of all these reserved fields for better purposes, and possibly allocate PI to everybody which is another pre-requisite to get rid of NAT. And there's always IPv8 ;) -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 28 mar 2006, at 13.46, Keith Moore wrote: NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. It will gradually be replaced by networks that are more-or-less IP based but which only run a small number of applications, poorly, and expensively. ...or you will see an overlay network build on top of NAT+IPv4 that abstracts the shortcomings away - aka what the peer to peer networks are doing. End-to-end addressing... the overlay networks depend on having some hosts that aren't behind a NAT to serve as tunnel endpoints for hosts that do. this will become less viable in the future as IPv4 address space gets more and more scarce. also, for the most part, overlay networks do not perform as well as native networks (there are exceptions, as in bittorrent). so they do not abstract (all of) the shortcomings away. They don't, but they do give the users back some of the benefit's they lost from being behind the NAT. However, that is now transpartent to the user. Uh, I can't buy this VoIP service for some technical reason, but this cool Skype stuff just works The problem is that for the users to get away from the NAT swap, they will need to go down the operators value-added-services-path. OTOH, one transition path away from NATs might be to extend NATs so that they support creation of overlay networks. such devices could also aid v4/v6 coexistence. I think you will see v4+NAT overlaynetworks IPv6-for end to services the providers want to sell (see IPTV and VoIP). Note, that this is end-to-end INSIDE the providers network. There is no incentive (yet) for providers to allow end-to-end on the Internet. - kurtis - ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
From: Scott Leibrand [EMAIL PROTECTED] NAT (plus CIDR) was the short-term solution, Do note that CIDR was intended as a solution to a number of problems, not just consumption of address space - like this one: From: Michel Py [EMAIL PROTECTED] Especially now that the size of the routing table is not a problem anymore. ... Also came memory issues with the global routing table. Some, including me, said it was un-maintainable and would result in the Internet collapsing. Since this old canard has resurfaced again, it's clearly time to drag out some old messages, which I resend every couple of years, and send them around yet again. The executive summary is: The issue with routing table size (and why big ones are Very Bad) is really not the size of the memory needed to hold the table (which is a static thing), but the dynamics - i.e. things like stabilization time after topology changes (and we have real problems there, as all the fancy BGP route-flapping and dampening stuff attests). For more, check out: Date: Sat, 9 Sep 95 17:22:17 -0400 From: [EMAIL PROTECTED] (Noel Chiappa) Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED], [EMAIL PROTECTED] Subject: Routing experts [Apologies for the rather cranky/snide tone in this one - I was pretty stressed out at the time.] Date: Thu, 22 Feb 96 12:44:33 -0500 From: [EMAIL PROTECTED] (Noel Chiappa) Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Last Call: Implications of Various Address Allocation Policies for Internet Routing to BCP Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Date: Thu, 22 Feb 96 12:44:33 -0500 From: [EMAIL PROTECTED] (Noel Chiappa) Message-Id: [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Last Call: Implications of Various Address Allocation Policies for Internet Routing to BCP Cc: [EMAIL PROTECTED], [EMAIL PROTECTED], [EMAIL PROTECTED] Someday I'll get energetic and turn these into a web page on the subject (like my 'Will The Real End-End Principle Please Stand Up?' page). Alas, no time at the moment. No doubt some people, looking at the dates on these, will say see, we've gone ten years without running into the problems you mention, therefore they don't exist. I must admit, I'm fairly amazed we haven't seen worse problems with the routing because of table size. I can only attribute our lack of observed problems to some very careful engineering by the ISP's. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Proposed 2008 - 2010 IETF Meeting dates
On Sat, Mar 25, 2006 at 04:21:31PM +0100, Brian E Carpenter wrote: Ray, I think our goal is to not lose essential participants from the IETF due to clashes. In fact that's why we want to schedule several years out, so as to make it easier for many other organizations to do their scheduling. If we do that, it's each organization's choice whether or not they avoid IETF weeks. (This week, for example, ITU-T NGN chose to schedule two major meetings in other cities.) and how does one define essectial participants? I don't think it's discriminatory to put the NICs and NOGs that don't seem to have a large overlap with IETF participants in the second category. It's just a matter of practicality, given that optimal scheduling is a fundamentally imsoluble problem anyway. I'd be delighted to see growth in African participation in the IETF (the spreadsheet shows two people from Africa pre-registered this week). the same arguments could have been applied to europe 15 years ago... but they were not - --bill Brian Ray Plzak wrote: Why should AfriNIC be considered any less of an RIR than the other APNIC, ARIN, LACNIC, or RIPE NCC(meeting is at RIPE meeting)? Why should AFNOG be considered any less of an operator's forum than NANOG or EOF(meeting is at RIPE meeting)? We are talking about an entire continent. It seems to me in this case that the priority should be equality of treatment based on the function being performed for a region and not any other perceived reason for inequity. Or doesn't the IETF care about the Internet in the developing regions of the world? Ray -Original Message- From: Joel Jaeggli [mailto:[EMAIL PROTECTED] Sent: Saturday, March 25, 2006 1:53 AM To: JORDI PALET MARTINEZ Cc: ietf@ietf.org Subject: Re: Proposed 2008 - 2010 IETF Meeting dates yOn Fri, 24 Mar 2006, JORDI PALET MARTINEZ wrote: Hi Ray, I know is difficult already to manage to avoid clashes, but I think is unfair and discriminatory to have all the RIRs and *NOGs in the MUST NOT list, but AfriNIC, AfNOG and SANOG in the other list. having attended two of three I would simply observe that the overlap between the two communites is a little lower. also. having attended every afnog meeting, it hasn't yet clashed with the ietf. You have to have some priorities. Anticipating for so many years is good enough to allow all those organizations to chat together and make sure the there is not a clash, not just in the exact dates, but allowing a few days in between (if they are hosted in different places of the world) to allow traveling among them, which has not been the case up to now all the time. Regards, Jordi De: Ray Pelletier [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Fri, 24 Mar 2006 09:41:48 -0500 Para: ietf@ietf.org ietf@ietf.org Asunto: Proposed 2008 - 2010 IETF Meeting dates The IETF is proposing dates for its meetings being held 2008 through 2010. Those dates can be found at http://www.ietf.org/meetings/future_meetings0810.html The dates will be evaluated and selected to meet the IETF's standards development objectives, while avoiding conflicts with SDOs and other organizations to the extent possible. Those organizations can be found on the Clash List from the same url. Comments regarding these dates should be addressed to the IAD at [EMAIL PROTECTED] It is anticipated that an official IETF Meeting Calendar for 2008 - 2010 will be formally adopted on April 20, 2006 by the IAOC. Regards Ray Pelletier IAD ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org
Re: Proposed 2008 - 2010 IETF Meeting dates
Mon, Mar 27, 2006 at 10:27:22AM -0500, Scott W Brim wrote: On Mon, Mar 27, 2006 04:18:42PM +0100, Tim Chown allegedly wrote: On Mon, Mar 27, 2006 at 10:38:03AM +0200, Brian E Carpenter wrote: I don't think the analogy holds, for a number of reasons. (As a matter of interest, there were about 6 participants out of 350 with addresses in Europe at the March 1991 IETF meeting, and about 19 out of 530 in March 1993. At that point, scheduling against RIPE would certainly have become a practical problem.) You have to consider the most important clashes; IETF66 clashes with the World Cup Final on July 9th. I hope Canada has good coverage, if not a good football team :) There are plenty of bars in Montreal. bars do not good coverage make. trying to find the olympics on - in real time - during the IceHockey finals, in Perth, was a futile gesture. --bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from hosts to sponsors
On Thu, Mar 23, 2006 at 07:34:00PM -0800, Andy Bierman wrote: Dave Crocker wrote: Michael StJohns wrote: What I think Jordi is saying is that he wants the US sponsors to subsidize the cost of the overseas meetings. At least that's what it works out to be This view can be mapped to a classic model that would have significant benefits for the IETF: A host gets all sorts of marketing leverage out of the role in producing an IETF. There is nothing that requires that the event site management effort be coupled with a particular host's venue. If we moved to a model of having companies provide sponsorship funds, in return for which they get appropriate marketing presence, then we could have meeting venue management move to the sort of predictable and timely basis -- ie, far enough ahead of time -- that has been a concern for many years. Amen! And maybe the meeting fees could actually go down with enough sponsors. An additional room like the terminal room (not out in the open) could be used. Also, the IETF could maintain control of the network if there were multiple sponsors instead of a single host. They would not be allowed to ignore the advice of the NOC team, and let the wireless meltdown right off the bat. d/ Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ah yes, the IETF as a FormulaOne race car. I'll approach CocaCola Visa for branding rights if that would help (esp for those folks denied a 770) --bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: An absolutely fantastic wireless IETF
On Thu, Mar 23, 2006 at 09:58:25PM -0600, Harald Alvestrand wrote: Just wanted to state what's obvious to all of us by now: This time the wireless WORKED, and Just Went On Working. That hasn't happened for a while. THANK YOU! Harald for novel interpretations of WORKED, i'll have to agree with you. In the rooms in Atrium I, we had very strong signal but never a DHCP lease was seen - on the 802.11b network. the whole week. it was reported in the tracker. I am greatful for folks w/ MAC's that had both a and b cards. building an ad-hoc network got others online. --bill ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
From: Anthony G. Atkielski [EMAIL PROTECTED] the solution is pretty simple: give out IP addresses for free, instead of charging an arm and a leg for anything other than a single address. As long as ISPs won't provide multiple addresses, or won't provide them except at unreasonably high prices, NAT will remain. I think there were other very powerful reasons why NAT was (and remains) so popular - to the point where IMO even if ISP's had handed out multiple IP addresses, we'd have seen widespread NAT deployment anyway. (Yes, there's no way to prove that.) One very powerful one, not mentioned at all in the discussion here, is the renumbering issue - i.e. having to change host addresses when you switch ISP's. (And let's *not* get into why this has to happen - asking to take your IP address with you is like asking to take your street address with you when you move so you won't have to re-print your letterhead...) And there's also firewalls - NAT boxes do provide some protection from random probing. (And I'm rather amused to see that now that the low-hanging security protection fruit of email inclusions and firewalls have been plucked, we're seeing a lot more web viruses - a likely development I ranted about some years ago... but I digress.) In general, all of these (including extra addresses) have the attribute that you plug this box in at the edge of the network, and don't have to change anything else. *That* is what really sold NAT. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
From: Keith Moore moore@cs.utk.edu NATs do harm in several different ways It's not just NAT's that are a problem on the fronts you mention, though: they block traffic in arbitrary directions My ISP blocks incoming SMTP and HTTP connections. Has nothing to do with NAT. these days they often destroy transparency. Some ISP's trap outgoing HTTP requests and silently divert them to caches. Again, it's not just NAT that's doing this. NATs started with a simple design, pretended it would work well without doing the analysis, Actually, I think the people who started NAT's (mostly Paul T) understood quite well what the problem were going to be. It's just that NAT was such a simpler/cheaper solution in the short term that it was too attractive. Realistically, the last chance to avoid NAT was when variable-length addresses were removed from IP somewhere in the TCP 2.5 - TCP 3.0 - TCP 3.1 transition (I don't know exactly which stage it was). In other words, a *lggg* time ago. We've just been along for the ride ever since. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Moving from hosts to sponsors
[EMAIL PROTECTED] wrote: ah yes, the IETF as a FormulaOne race car. I'll approach CocaCola Visa for branding rights if that would help (esp for those folks denied a 770) ah yes, the ad absurdem form of argumentation. The reality in having a host is that we already experience quite a bit of marketing from that host. My suggestion was cast in terms of permitting that level to continue, not in permiting every attendee eye-blink to experience a new injection of promotional material. d/ -- Dave Crocker Brandenburg InternetWorking http://bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
From: Hallam-Baker, Phillip [EMAIL PROTECTED] I have never seen a coherent, rational argument as to why the network numbering on my internal network should be the same as the network numbering on the Internet. All I hear is a restatement of the original claim, the 'no you didn't' mode of argument. Your terminology here is a little loose (I don't know exactly what you mean by network numbering), but let me try and say something useful. IP addresses currently serve two completely separate functions: they identify *who* you are talking to, and they identify *where* they are. Unfortunately, because one field is used to two purposes, the constraints on that field are the union of the needs of the two purposes. Let's look at the needs of the where they are function. When packets from your hosts get to the server in, say, Paraguay, they have to have a bit-string in the source field that says these packets came from this place that you now how to get to - in other words, the bit-string has to have a value that the routers in Paraguay recognize, if the return packets are to get back to you. Yes, yes, that bit-string could be added as the packets are leaving your general area - but alas, this contradicts the needs of the *other* usage of that field, which is that they identify who you are talking to. If we change them around, you lose that functionality. What you're seeing, quite simply, is a case where a shared mechanism has ceased to work well as the system scaled up. (This point is discussed in more detail in section 11.2, Shared Mechanisms and System Scale, of my never-completed endpoint spiel, available at: http://users.exis.net/~jnc/tech/endpoints.txt if you wat more about it.) Even if you split the two, however, there'd still be an argument as to why your network number[] on my internal network should be the same as the network numbering on the Internet. You'd still have the same problem, that the where I am field would have to have a value that was meaningful to the router in Paraguay. If that meaningful value was inserted by some router several steps away from you, there are a host of issues that come up: security (what if that router is subverted, etc, etc), complexity, etc, etc. You can also look at the analogy to telephones and street addresses. In both cases, the full form of the name is globally unique - because global uniqueness has all sorts of useful properties. You need only look at personal names to see some of the kind of very painful issues that crop up when they aren't globally unique. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
From: Michel Py [EMAIL PROTECTED] Tim Chown wrote: If you deploy IPv6 NAT, you may as well stay with IPv4. You're the one who convinced me some three years ago that there will be IPv6 NAT no matter what, what's the message here? I think Tim's point is that the only realistic options are: i) IPv4+NAT ii) IPv6 without NAT. The IPv6+NAT option makes little (no?) economic/technical sense - it has all the operational downsides of IPv4+NAT, plus to which you have the cost/hassle of deploying v6. and possibly allocate PI to everybody which is another pre-requisite to get rid of NAT. We aren't *ever* going to give everyone PI space (at least, PI space in whatever namespace the routers use to forward packets), any more than we are going to let them take their street addresses with them when they move. Routing (i.e. path-finding) algorithms simply cannot cope with tracking 10^9 individual destinations (see prior message). Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About cookies and refreshments cost and abuse
... warning, this thread involves geeks trying to understand the real world ... My impression (from inside the hotel in Dallas) was that enough people had travel problems coming into Dallas, which included travel problems returning from dinner in the West End to the hotel on Sunday, that even knowing how many people had signed up for breakfast before the deluge started wouldn't have helped that much. There were people who were staying at the conference hotel who couldn't even get to the conference hotel. I suspect, without knowing, that the adjusted estimates were lagging new arrivals by about one break for most of Monday and Tuesday. Hopefully we won't need an Architectural Research Klub (ARK) in Montreal. I thought the same thing about Jordi's suggestion initially - who would collect the tickets?, but his explanation (no one, just the expectation that people put down a ticket when they pick something up) helped. If this could be tried for the price of five or six spools of admit one tickets at a wholesale store, maybe it's worth doing. .. but suggestions like this can now usefully go to [EMAIL PROTECTED], without setting off cookie discussions on this list... Thanks, Spencer Hi JORDI, --On March 23, 2006 5:32:29 PM -0600 JORDI PALET MARTINEZ [EMAIL PROTECTED] wrote: So my suggestion to be reasonable and fair to all, will be to provide together with our registration pack, a given number of refreshment tickets, enough to cover the average needs. The problem with tickets is who do you get to collect them? Presumably this would have to be hotel staff - at which point the costs will go up as they would likely need to employ more staff to collect tickets in addition to bringing out new trays etc. That would probably lead to having to have fewer refreshment stations and result in longer queues to get those refreshments. Something that might help with at least the estimation process that is currently done, would be to include a breakfast/break sign-up option on the online registration form. The form already asks about attendance at the Sunday reception, so why not extend that to the refreshment breaks? Obviously not everyone registers before hand (what is the percentage BTW?) but this still might be better... -- Cyrus Daboo ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Noel, I think the street address analogy is not close enough - anymore than longitude and latitude numbers or any other description of physical location. The problem with physical location portability is that the location remains even if you're not in it. So someone else might need to describe their own physical location using the same description. Number assignments, however are substantially more portable. It is certainly possible for an IPv6 address pool manager to allocate personalized IPv6 addresses from an IPv6 address pool that they manage and thereby assume responsibility for end-delivery (by any means possible) - thus providing for indefinite address portability. In this sense, this is more analogous to phone number portability or tax identifiers. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, March 28, 2006 10:06 AM -- To: ietf@ietf.org -- Cc: [EMAIL PROTECTED] -- Subject: RE: Stupid NAT tricks and how to stop them. -- -- From: Michel Py [EMAIL PROTECTED] -- -- Tim Chown wrote: -- If you deploy IPv6 NAT, you may as well stay with IPv4. -- -- You're the one who convinced me some three years ago -- that there will -- be IPv6 NAT no matter what, what's the message here? -- -- I think Tim's point is that the only realistic options are: -- -- i) IPv4+NAT -- ii) IPv6 without NAT. -- -- The IPv6+NAT option makes little (no?) economic/technical -- sense - it has all -- the operational downsides of IPv4+NAT, plus to which you -- have the cost/hassle -- of deploying v6. -- -- -- and possibly allocate PI to everybody which is -- another pre-requisite -- to get rid of NAT. -- -- We aren't *ever* going to give everyone PI space (at least, -- PI space in -- whatever namespace the routers use to forward packets), any -- more than we are -- going to let them take their street addresses with them -- when they move. -- -- Routing (i.e. path-finding) algorithms simply cannot cope -- with tracking 10^9 -- individual destinations (see prior message). -- -- Noel -- -- ___ -- Ietf mailing list -- Ietf@ietf.org -- https://www1.ietf.org/mailman/listinfo/ietf -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
From: Kurt Erik Lindqvist [mailto:[EMAIL PROTECTED] NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. It will gradually be replaced by networks that are more-or-less IP based but which only run a small number of applications, poorly, and expensively. ...or you will see an overlay network build on top of NAT+IPv4 that abstracts the shortcomings away - aka what the peer to peer networks are doing. End-to-end addressing... Precisely. Just what is this fetish about keeping the IP address the same as the packet travels? If there is a way for the host to determine that it is behind a NAT and to request external registration of necessary ports the whole process can be made completely transparent to the hosts at each end. smime.p7s Description: S/MIME cryptographic signature ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: About cookies and refreshments cost and abuse
We could also simply tell everyone please take one pastry in the first half of the breakfast hour or one cookie in the first half of the cookie time. I would hope (but maybe this is naive) that if people realize that the food is not infinite they will leave some for their peers. I think issueing tickets would be ridiculous. Taking drinks for non-local consumption is another issue. I have to admit, I like to take a bottle of water to drink in the meeting room. Some hotels put water in the room. Some don't. We do need to have drinking water but it doesn't have to be bottled in most places. The cost of food should not be blown out of proportion. If one counts airfare, hotel, food (lunch dinner), and the value of time at the meeting (don't forget the time preparing for the meeting), IETF attendance is not cheap and the meeting fee is usually a minor part of the total cost unless it is a local meeting. We might try foregoing or limiting the cookies which would probably increase the life expectancy of the attendees but somehow I doubt this will be a popular suggestion. :-) In Paris, we switched to a late dinner which was necessary in Paris but we did this in Dallas. Was this a general decision that I missed? I prefer dinner from 6 - 8 and a night session where the local customs support this. This might also cut down the need for afternoon sugar consumption. Steve Silverman -Original Message- From: Spencer Dawkins [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 10:07 AM To: ietf@ietf.org Subject: Re: About cookies and refreshments cost and abuse ... warning, this thread involves geeks trying to understand the real world ... My impression (from inside the hotel in Dallas) was that enough people had travel problems coming into Dallas, which included travel problems returning from dinner in the West End to the hotel on Sunday, that even knowing how many people had signed up for breakfast before the deluge started wouldn't have helped that much. There were people who were staying at the conference hotel who couldn't even get to the conference hotel. I suspect, without knowing, that the adjusted estimates were lagging new arrivals by about one break for most of Monday and Tuesday. ... I thought the same thing about Jordi's suggestion initially - who would collect the tickets?, but his explanation (no one, just the expectation that people put down a ticket when they pick something up) helped. If this could be tried for the price of five or six spools of admit one tickets at a wholesale store, maybe it's worth doing. .. but suggestions like this can now usefully go to [EMAIL PROTECTED], without setting off cookie discussions on this list... Thanks, Spencer Hi JORDI, --On March 23, 2006 5:32:29 PM -0600 JORDI PALET MARTINEZ [EMAIL PROTECTED] wrote: So my suggestion to be reasonable and fair to all, will be to provide together with our registration pack, a given number of refreshment tickets, enough to cover the average needs. The problem with tickets is who do you get to collect them? Presumably this would have to be hotel staff - at which point the ... ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
On Tue, 2006-03-28 at 08:00 -0800, Hallam-Baker, Phillip wrote: From: Kurt Erik Lindqvist [mailto:[EMAIL PROTECTED] NAT is a dead end. If the Internet does not develop a way to obsolete NAT, the Internet will die. It will gradually be replaced by networks that are more-or-less IP based but which only run a small number of applications, poorly, and expensively. ...or you will see an overlay network build on top of NAT+IPv4 that abstracts the shortcomings away - aka what the peer to peer networks are doing. End-to-end addressing... Precisely. Just what is this fetish about keeping the IP address the same as the packet travels? It certainly doesn't have to be. As long as there is one global identifier which is the same on the other side. A double NAT (thus making sure the packet is 100% identical on the sending and receiving side) with a signalling protocol in between is the solution for this. And there is something already being worked on which does that: shim6. If there is a way for the host to determine that it is behind a NAT and to request external registration of necessary ports the whole process can be made completely transparent to the hosts at each end. You are thinking of UPNP (See http://www.upnp.org or read for instance http://www.microsoft.com/windowsxp/using/setup/expert/crawford_02july22.mspx). Which is already support by Windows for some time and many NAT boxes (ohno I should say 'router' or 'firewall' according to them) vendors also nicely implement it. But it is a kludge and a heavy one as all the applications using it also have to support it and it is not always available and there are not too many applications supporting it, let alone protocols. Next to that, when the well known port on the outside IP is taken it won't work. Just like when there are multiple levels of NAT, or there are no rights to control the UPNP process at all. IPv6 thus gives the advantage over UPNP that: - it is clear and simple to all the applications who they are talking to based on the source/destination IPv6 address - same ideas as IPv4 and no kludges - firewalling can remain the normal firewalling - multiple tools can use the wellknown ports as there are multiple IP's - etc... Other thing you might want to look at is Teredo (RFC4380), which basically implements an p2p overlay network on top of IPv4, but using IPv6 for addressing. (Funny eh that both Teredo and UPNP come out of the MS stables, guess what these guys wanted to solve...) Greets, Jeroen signature.asc Description: This is a digitally signed message part ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About cookies and refreshments cost and abuse
On Tue, Mar 28, 2006 11:16:33AM -0500, Steve Silverman allegedly wrote: In Paris, we switched to a late dinner which was necessary in Paris but we did this in Dallas. Was this a general decision that I missed? I prefer dinner from 6 - 8 and a night session where the local customs support this. This might also cut down the need for afternoon sugar consumption. Oh good, this isn't about cookies anymore. I for one was against using the Paris schedule in Dallas, but I came around quickly, especially with the -- do I have to say it? -- late afternoon cookies. I now think the new schedule is excellent and would like to see it at all future IETFs. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About cookies and refreshments cost and abuse
Fully agree ;-) Regards, Jordi De: Scott W Brim sbrim@cisco.com Responder a: [EMAIL PROTECTED] Fecha: Tue, 28 Mar 2006 11:25:31 -0500 Para: Steve Silverman [EMAIL PROTECTED] CC: ietf@ietf.org ietf@ietf.org Asunto: Re: About cookies and refreshments cost and abuse On Tue, Mar 28, 2006 11:16:33AM -0500, Steve Silverman allegedly wrote: In Paris, we switched to a late dinner which was necessary in Paris but we did this in Dallas. Was this a general decision that I missed? I prefer dinner from 6 - 8 and a night session where the local customs support this. This might also cut down the need for afternoon sugar consumption. Oh good, this isn't about cookies anymore. I for one was against using the Paris schedule in Dallas, but I came around quickly, especially with the -- do I have to say it? -- late afternoon cookies. I now think the new schedule is excellent and would like to see it at all future IETFs. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
On 03/28/06 at 6:11am +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Scott Leibrand writes: NAT (plus CIDR) was the short-term solution, and is realistic as a medium-term solution. In the long term, though, I don't think it will be the only solution. It will be if ISPs continue to charge for extra IP addresses, as they probably always will. They can charge for IPv4 addresses because they're perceived to be scarce. With IPv6 they may be able to charge for allowing me a /48 instead of a /56 or /64, but IMO they won't be able to assign me a /128 by default and charge me if I want a /64. And if someday I want to switch to a new ISP who prefers not to give out IPv4 addresses at all, that'll be fine with me, as long as my ISP provides me IPv4 translation services to reach that portion of the Internet that is still IPv4-only at that point. If your ISP charges you extra for more than one IPv6 address, what will you do? Then I will switch ISPs. ARIN guidelines specifically require ISPs to give out larger blocks when requested. If any ISPs try to be hard-nosed about it and give out /128's anyway, it will be pretty easy to pressure shame them sufficiently that they'll feel it in the marketplace. -Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 03/28/06 at 7:00am +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Keith Moore writes: don't think upgrade; think coexistence. How do IPv4 and IPv6 coexist? Like ASCII and EBCDIC, perhaps? Um, have you heard of dual stack? My Windows XP does it quite transparently (after I enable IPv6 at the command line), and presumably Vista will do IPv4/IPv6 dual stack transparently without any command-line enabling. As an engineer, the right thing to do is to transition away from NAT (along with IPv4), so that eventually it can be discarded. I'm not aware of a smooth transition option; how does it work? OS's (and anything with a TCP/IP stack) starts looking for both IPv4 and IPv6 connectivity at connect time (DHCP for v4, DHCPv6 or RA's for IPv6). If an ISP has enabled IPv6 on their network, the IP stack gets an IPv4 address and one or more IPv6 addresses. When it goes to talk to a host with a v4 address, it uses v4. To talk to a v6 host, it uses v6. If a network wants to stop giving out v4 addresses, they provide v4/v6 translation capabilities of some sort. And NAT is economically driven. Unless ISPs stop charging for extra addresses, it's hear to stay. As I argued in another message, IMO ISPs will not be able to charge extra for an IPv6 /64. That gives you basically as many hosts as your routing/switching gear can handle on a single subnet (as you won't be able to put 2^64 hosts on a single broadcast domain). for some applications, it's simply impractical; for other apps, it's much more expensive (in terms of added infrastructure and support costs) to operate them in the presence of NAT. in either case the market for those apps is greatly reduced, and the apps are more expensive as a result. It might still be cheaper than converting them to IPv6. As long as you already have v6-capable gear, enabling IPv6 shouldn't be significantly more expensive than running v4. IMO it doesn't make sense to try to run v6 on gear that only supports v4, but since pretty much all new gear supports v6 now, folks should be able to gradually turn on v6 as appropriate in their networks. again, this doesn't really solve the problem - it only nibbles off a small corner of it. NATs do harm in several different ways - they take away a uniform address space, they block traffic in arbitrary directions, they hamper appropriate specification of security policies, and these days they often destroy transparency. Agreed, but they reduce the amount of money you must pay to your ISP each month by a factor of ten or more. Your ISP charges you 9 times as much for IPv4 addresses as they do for bandwidth? I'd recommend switching ISPs. All the ones I've seen charge a small premium for additional IP space, but it's never more than about a 50% premium. the reason this looks so complicated compared to NATs is that NATs never really worked all of this stuff out. NATs started with a simple design, pretended it would work well without doing the analysis, and have been trying to fix it with bizarre hacks ever since that have only made the problem worse. People will go to great lengths sometimes to save money. Or to avoid hassle. I have a single IP on my DSL, and run NAT, mainly because it's not worth the hassle to get additional IPv4 space. However, as soon as my ISP starts offering IPv6 with DHCPv6 Prefix Delegation, I'll upgrade my NAT box to something that supports DHCPv6-PD. That might be a linksys/d-link/netgear box, or it might be a PC running Linux. -Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About cookies and refreshments cost and abuse
In Paris, we switched to a late dinner which was necessary in Paris but we did this in Dallas. Was this a general decision that I missed? I prefer dinner from 6 - 8 and a night session where the local customs support this. This might also cut down the need for afternoon sugar consumption. I normally fly in from Europe and strongly prefer the later dinner - not because I like late dinners - but because I prefer to have the sessions before I fall asleep with jet lag. - Stewart ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Proposed 2008 - 2010 IETF Meeting dates
An alternative to coordinating meeting dates with a growing list of peer entities is to simply say that the IETF will meet on the second week of March, July, and November every year. Such a stance would help everyone to schedule. [Note: these weeks are suggestions only, select a permanent variant of your choice.] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
If we are willing to accept arbitrarily long paths to get from point A to point B, there are techniques which allow topologically insensitive packet handling. The Home-Register (aka HLR lookup) is one way. (The routing reserachers have described this topic as stretch 1 routing. There are many non-deployable ideas there. If we really didn't care about path distortion at all, I am sure something deployable could be crafted.) Note however that local number portability is actually a bad analogy. The phone system internally does not work on phone numbers any more (it once did). Your phone number is really more akin to an identity. Phone you call someone, the system does a name lookup (ala DNS) and then gets a routable location. Yours, Joel At 10:48 AM 3/28/2006, Gray, Eric wrote: To: [EMAIL PROTECTED], ietf@ietf.org Subject: RE: Stupid NAT tricks and how to stop them. Noel, I think the street address analogy is not close enough - anymore than longitude and latitude numbers or any other description of physical location. The problem with physical location portability is that the location remains even if you're not in it. So someone else might need to describe their own physical location using the same description. Number assignments, however are substantially more portable. It is certainly possible for an IPv6 address pool manager to allocate personalized IPv6 addresses from an IPv6 address pool that they manage and thereby assume responsibility for end-delivery (by any means possible) - thus providing for indefinite address portability. In this sense, this is more analogous to phone number portability or tax identifiers. -- Eric ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: About cookies and refreshments cost and abuse
Stewart Bryant wrote: In Paris, we switched to a late dinner which was necessary in Paris but we did this in Dallas. Was this a general decision that I missed? I prefer dinner from 6 - 8 and a night session where the local customs support this. This might also cut down the need for afternoon sugar consumption. I normally fly in from Europe and strongly prefer the later dinner - not because I like late dinners - but because I prefer to have the sessions before I fall asleep with jet lag. I heard this comment in Dallas from several people. It works in reverse when I fly to Europe from California. (I'm ready to start WG meeting at 4am :-) I think one's opinion of the new schedule has more to do with whether you had any night sessions to attend that your country of origin. If you go to any night sessions, the old schedule is awful. If not, you don't care so much. - Stewart Andy ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
From: Keith Moore moore@cs.utk.edu NATs do harm in several different ways It's not just NAT's that are a problem on the fronts you mention, though: yes, there are other things that do harm besides NATs. however, that's not a justification for NATs. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Noel, Delivering IP packets _always_ involves a translation service. Usually, more than one, but - assuming we start with IP addresses - there is at least one MAC (or other L2) lookup that must occur before the packets can be delivered. We should be careful not to assert layer dependent statements in a world in which layering is only locally unambiguous. The problem with the road-network analog is that I have no intrinsic requirement to relinquish my network address because I've become mobile. The same thing could - in theory - be said about street addresses, but the current binding/interpretation of street addresses is entrenched in centuries of usage that prevents this from (probably) ever becoming practical. That is not only NOT true in theory for IP(v4/v6) addresses, it is not true in practice. -- Eric -- -Original Message- -- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] -- Sent: Tuesday, March 28, 2006 1:17 PM -- To: ietf@ietf.org -- Cc: [EMAIL PROTECTED] -- Subject: RE: Stupid NAT tricks and how to stop them. -- -- From: Gray, Eric [EMAIL PROTECTED] -- -- I think the street address analogy is not close -- enough - anymore -- than longitude and latitude numbers or any other -- description of -- physical location. -- -- No, it's a very good analogy, because the road network is a -- very good analog -- to the data network. To see how, let's do a though-experiment. -- -- Embed the road-network, not on the surface of a solid -- sphere, but on the -- surface of a flexible hollow spherical surface. Now, -- distort that surface -- arbitrarily. The location (in spatial coordinates) of any -- place on that road -- network has changed totally - but the set of directions -- you'd use to get -- from one point in the road network to another (go down -- road A until you -- meet the junction with B, and turn onto B in the direction -- of C, etc, etc) -- remains unchanged. -- -- What is most important about both the data network, and the -- road network, is -- the *connectivity pattern* - what connects to what. That's -- because packets -- are (usually) constrained to travel down links, and -- vehicles are (usually) -- constrained to travel down roads. -- -- The problem with physical location portability is -- that the location -- remains even if you're not in it. -- -- But the exact same thing is true of a network - Port #0 on -- ISP A's router R -- is the same place in the network (i.e. you use the same -- directions to get to -- it - see above) whether company X or company Y is plugged -- in there - just as -- 126 Main Street is the same building, whether company X or -- company Y is -- housed there. -- -- Number assignments, however are substantially more portable. -- -- Saying that doesn't make it so. You can easily (sic) change -- street names -- too, to make a street name portable. -- -- -- It is certainly possible for an IPv6 address pool -- manager to allocate -- personalized IPv6 addresses from an IPv6 address pool -- that they manage -- and thereby assume responsibility for end-delivery -- -- That's just a translation service from *virtual* addresses -- to real ones - -- those IPv6 addresses aren't the names of locations in the -- network: if the -- pool manager *actually wants to get packets* to those -- entities, it is going -- to have to translate those addresses into the real -- addresses at which -- those entities can be found. -- -- Noel -- ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Proposed 2008 - 2010 IETF Meeting dates
On Tue, 28 Mar 2006, Fleischman, Eric wrote: An alternative to coordinating meeting dates with a growing list of peer entities is to simply say that the IETF will meet on the second week of March, July, and November every year. Such a stance would help everyone to schedule. [Note: these weeks are suggestions only, select a permanent variant of your choice.] proposed meeting dates through 2010 are posted on the meetings page, fixing them in stone reduces leway on negotiating future hotel contracts. There are other unforseen exegiencies that fixing the data in absence of a location create like inconvenient national holidays, that make travel to or from a location infeasible. -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
Scott Leibrand writes: They can charge for IPv4 addresses because they're perceived to be scarce. With IPv6 they may be able to charge for allowing me a /48 instead of a /56 or /64, but IMO they won't be able to assign me a /128 by default and charge me if I want a /64. They will charge you for every address beyond one. Wait and see. BTW, giving out /64s is one reason why the IPv6 address space will be exhausted in barely more time than was required to exhaust the IPv4 address space. Then I will switch ISPs. They will all be doing it. ARIN guidelines specifically require ISPs to give out larger blocks when requested. If any ISPs try to be hard-nosed about it and give out /128's anyway, it will be pretty easy to pressure shame them sufficiently that they'll feel it in the marketplace. How? I haven't been able to pressure or shame my ISP into setting rDNS correctly for my IP address. In fact, nobody at my ISP knows what that means. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
On 03/28/06 at 8:54pm +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Scott Leibrand writes: They can charge for IPv4 addresses because they're perceived to be scarce. With IPv6 they may be able to charge for allowing me a /48 instead of a /56 or /64, but IMO they won't be able to assign me a /128 by default and charge me if I want a /64. They will charge you for every address beyond one. Wait and see. We definitely will have to see how it shapes up in the US. In Japan, where they actually have IPv6 deployed to end users, it looks like most ISPs are giving out /64's to home users, and /48's to business users: http://www.apnic.net/meetings/18/docs/sigs/policy/policy-pres-tomohiro-ipv6-endusers.pdf BTW, giving out /64s is one reason why the IPv6 address space will be exhausted in barely more time than was required to exhaust the IPv4 address space. Then I will switch ISPs. They will all be doing it. I doubt it. There are RFC's (3177) and RIR policies (http://www.arin.net/policy/nrpm.html#six54) that *require* ISPs to allocated a /64 or larger unless it is absolutely known that one and only one device is connecting. ARIN guidelines specifically require ISPs to give out larger blocks when requested. If any ISPs try to be hard-nosed about it and give out /128's anyway, it will be pretty easy to pressure shame them sufficiently that they'll feel it in the marketplace. How? I haven't been able to pressure or shame my ISP into setting rDNS correctly for my IP address. In fact, nobody at my ISP knows what that means. What is correct rdns? Is adsl-066-156-091-129.sip.asm.bellsouth.net correct? -Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
IP addresses currently serve two completely separate functions: they identify *who* you are talking to, and they identify *where* they are. there's a tad more to it than that which is essential: in a non-NATted network, IP addresses identify where a host is in a way that is independent of the location in which they're being evaluated. in a NATted network, at least some IP addresses are location-dependent which removes the ability to hand those addresses to a host in a different part of the network. even if IP had identifiers for hosts that were independent of locators, they wouldn' t be worth very much without a way to map them to locators. and locators are a lot easier to deal with if they're location-independent. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Proposed 2008 - 2010 IETF Meeting dates
I think is clear that we need to fix the meeting dates, and that should be done in advance so we avoid clashes with other events and we can negotiate with hotels and sponsors ahead of time enough to make it cheaper. While I don't agree is to take in consideration national holidays unless they are (almost) *worldwide* ones. Otherwise, taking the national holidays from one or the other country will be discriminatory for the rest. Moreover when we don't know the place we will meet 3-4 years in advance. Otherwise we need to manage at the same time the meeting date and the place for each meeting, which we know is impossible. Regards, Jordi De: Joel Jaeggli [EMAIL PROTECTED] Responder a: [EMAIL PROTECTED] Fecha: Tue, 28 Mar 2006 10:54:14 -0800 (PST) Para: Fleischman, Eric [EMAIL PROTECTED] CC: Carl Malamud [EMAIL PROTECTED], ietf@ietf.org ietf@ietf.org, JORDI PALET MARTINEZ [EMAIL PROTECTED] Asunto: RE: Proposed 2008 - 2010 IETF Meeting dates On Tue, 28 Mar 2006, Fleischman, Eric wrote: An alternative to coordinating meeting dates with a growing list of peer entities is to simply say that the IETF will meet on the second week of March, July, and November every year. Such a stance would help everyone to schedule. [Note: these weeks are suggestions only, select a permanent variant of your choice.] proposed meeting dates through 2010 are posted on the meetings page, fixing them in stone reduces leway on negotiating future hotel contracts. There are other unforseen exegiencies that fixing the data in absence of a location create like inconvenient national holidays, that make travel to or from a location infeasible. -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ** The IPv6 Portal: http://www.ipv6tf.org Barcelona 2005 Global IPv6 Summit Slides available at: http://www.ipv6-es.com This electronic message contains information which may be privileged or confidential. The information is intended to be for the use of the individual(s) named above. If you are not the intended recipient be aware that any disclosure, copying, distribution or use of the contents of this information, including attached files, is prohibited. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 03/28/06 at 9:00pm +0200, Anthony G. Atkielski [EMAIL PROTECTED] wrote: Scott Leibrand writes: Um, have you heard of dual stack? My Windows XP does it quite transparently (after I enable IPv6 at the command line), and presumably Vista will do IPv4/IPv6 dual stack transparently without any command-line enabling. How does your ISP handle this? They could do so (when they implement IPv6) by running dual-stack routers. How much extra does your ISP charge you for IPv6 support? My ISP doesn't yet provide IPv6 support. But at some point they (or another ISP) will. As I argued in another message, IMO ISPs will not be able to charge extra for an IPv6 /64. A /64 is a criminal waste of address space; they _should_ charge extra for that. I don't think you understand exponential math as it applies to IPv6. IPv6 was specifically designed to make this possible. With /48 assignments and an HD ratio of .94, projections indicate a ~500 year lifetime to exhaust the IPv6 address space. That gives you basically as many hosts as your routing/switching gear can handle on a single subnet (as you won't be able to put 2^64 hosts on a single broadcast domain). And even with a million hosts, you'll be wasting fully 99.99945% of the /64. Yep. And since there are about 18,446,744,073,709,600,000 /64's, such wastage is not a problem. IPv6 was *designed* to make sure that address space conservation is *not* required. Do you see why IPv6 address space will soon be exhausted? If you consider hundreds of years soon, then sure. As long as you already have v6-capable gear, enabling IPv6 shouldn't be significantly more expensive than running v4. IMO it doesn't make sense to try to run v6 on gear that only supports v4, but since pretty much all new gear supports v6 now, folks should be able to gradually turn on v6 as appropriate in their networks. When did all applications become capable of handling IPv6? They don't need to be. For the life of any existing applications, IPv4 connectivity will still be available in some fashion. All the ones I've seen charge a small premium for additional IP space, but it's never more than about a 50% premium. Fifty percent is a small premium? No, usually it's a lot less than 50%. More typical is like $5/mo extra for additional IP(s). -Scott ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
Scott Leibrand writes: We definitely will have to see how it shapes up in the US. In Japan, where they actually have IPv6 deployed to end users, it looks like most ISPs are giving out /64's to home users, and /48's to business users: Looks like IPv6 will be exhausted even sooner than I predicted. I doubt it. There are RFC's (3177) and RIR policies (http://www.arin.net/policy/nrpm.html#six54) that *require* ISPs to allocated a /64 or larger unless it is absolutely known that one and only one device is connecting. See above. So if I understand correctly, 99.9% of the IPv6 address space has already been thrown away. Why bother going to IPv6 at all? What is correct rdns? Is adsl-066-156-091-129.sip.asm.bellsouth.net correct? The correct rDNS is the one that matches my domain. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
From: Keith Moore moore@cs.utk.edu even if IP had identifiers for hosts that were independent of locators, they wouldn' t be worth very much without a way to map them to locators. and locators are a lot easier to deal with if they're location-independent. Huh? Did you mean identifiers are a lot easier to deal with if they're location-independent? If that wasn't a typo, and you really meant what you said, the whole *point* of locators is to include location information. A locator [which is] location-independent is an completely oxymoron. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Noel, Please recall that IP addresses are currently serving two semantic functions: Locator and Identity. I interpreted Keith's posting to be speaking of the latter. (e.g., HIP) --Eric -Original Message- From: Noel Chiappa [mailto:[EMAIL PROTECTED] Sent: Tuesday, March 28, 2006 11:45 AM To: ietf@ietf.org Cc: [EMAIL PROTECTED] Subject: Re: Stupid NAT tricks and how to stop them. From: Keith Moore moore@cs.utk.edu even if IP had identifiers for hosts that were independent of locators, they wouldn' t be worth very much without a way to map them to locators. and locators are a lot easier to deal with if they're location-independent. Huh? Did you mean identifiers are a lot easier to deal with if they're location-independent? If that wasn't a typo, and you really meant what you said, the whole *point* of locators is to include location information. A locator [which is] location-independent is an completely oxymoron. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
The other side of the coin is the fact that many devices will effectively require no more than a /128 because of the way they connect up to the network. For example cell phones will be serviced on plans where the subscription fee is per device. it's perfectly reasonable to connect a small network to a cell phone. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
From: Hallam-Baker, Phillip [EMAIL PROTECTED] The other side of the coin is the fact that many devices will effectively require no more than a /128 because of the way they connect up to the network. For example cell phones will be serviced on plans where the subscription fee is per device. Verizon, T-mobile, cingular need no more than one /64 each to service those networks. Uhh... - I thought they actually do (should) give /64 per phone, so that standar IPv6 address configuration works (you get IPv6 link local and global addresses from RA). - phone can use more that one address if you use the phone connection to link your local network to the global internet without NAT, (needs some nasty ND-proxy hacks though..) All Symbian phones have full IPv4/IPv6 dual stack on them already. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
From: Keith Moore moore@cs.utk.edu what I mean is that a locator that means the same thing (refers to the same destination) no matter where you are in the net, is a lot easier to deal with than a locator with a meaning that changes (refers to different destinations) depending on where you are in the net. Oh, I absolutely, completely, totally agree with you on that one! Names which look like they are global, but sometimes aren't, are just asking for trouble. This is doubly true when they don't inherently i) identify when they aren't, and ii) include identification of the binding environment in which they are valid, when they aren't. The complexity and potential confusion inevitably associated with such names means there must be a very good reason for using them in a system design - and offhand, I can't think of a good enough reason to do so. (Before someone says something, NAT is different - they weren't designed in, there.) locators are a lot easier to deal with if they're location-independent Huh? Did you mean identifiers are a lot easier to deal with if they're location-independent? I really was talking about locators, not identifiers. Now that I understand what you actually meant, I'm not freaked out! However, you phrased your point in a way that almost guaranteed confusion! You didn't mean locators are a lot easier to deal with if the name has nothing to do with where the thing it names is, you meant locators are a lot easier to deal with if their meaning (i.e. the thing they are bound to) is the same no matter where you are when you evaluate them. Noel ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 28-mrt-2006, at 11:54, Michel Py wrote: Tim Chown wrote: If you deploy IPv6 NAT, you may as well stay with IPv4. You're the one who convinced me some three years ago that there will be IPv6 NAT no matter what, what's the message here? I've travelled to this strange land where there is IPv6 and it's NATed... Some enterprising souls apparently took it upon themselves to build IPv6 support into a firewalling package that (as so many firewalls do) supports NAT. With the result that if you know how to enable this, you can make it do IPv6 NAT. Simple client-server protocols such as HTTP worked without incident as expected. However, I also tried FTP, which really isn't that bad as NAT-breaking protocols go. It didn't work because the server saw an illegal EPRT request. In IPv4 with NAT that wouldn't have happened because: 1. The FTP client would have used EPSV in order to be NAT-friendly, or 2. The FTP ALG would have intercepted the private address and rewritten it Moral of the story: do IPv6 NAT at your peril. Now of course it's possible to argue all of the stuff that makes IPv4 NAT work to the degree that it does today can also be added to IPv6, and that is true, strictly speaking. But will the vendors bother, and will the customers require it? I don't think so. As Tim said: if you can live with NAT, why not stay with IPv4? That saves you several headaches and it only costs you a few IPv6 nice-to-haves such as stateless autoconf that haven't been able to get people to IPv6 anyway. Artur Hecker wrote: the (static) statement that 90% of phones are analog seems very wrong to me. My bad, I should have said land lines. The interesting thing is that even though ISDN doesn't amount to much in the US and it's mainly used for businesses in Europe, GSM which is the biggest mobile phone technology, uses ISDN Q.9xx signalling, so ISDN was never a waste of time. People will still want to do NAT on IPv6. Not enough to make it work well enough. Yes, and since site-locals have been deprecated they will also hijack an unallocated block of addresses to use as private, You can still use FEC0::/10 even though the special case handling will be removed from future implementations and there are unique site locals for which there is a specific hijacking methodology that minimizes the dreaded ambiguity of private space. Keith Moore wrote: huh? there is no way to make a protocol that can address more hosts than v4, that is 100% compatible with v4. and there's no good way to divide up the net into v4 enclaves and v6 enclaves because the applications that need v6 addressing don't fit neatly into enclaves. As long as you don't use the extra bits, no problem. IPv4 on one side, IPv4+ on the other; when going from v4 to v4+ add a bunch of zeroes, when going to v4+ to v4 remove a bunch of zeroes. Initially it's a total waste of bits, but silicon is cheap these days. When people will begin to scream bloody murder to use the extended bits (because v4 is getting near exhaustion) the infrastructure could be already in place, and then the pressure will be on software developers to recode their stuff with 128-bit addresses. When that has happened, then we can make use of all these reserved fields for better purposes, and possibly allocate PI to everybody which is another pre- requisite to get rid of NAT. The trouble is that if you use IPv4-compatible IPv6 addresses (in the loose sense of the word, not thinking of any RFC) for instance by having the first 96 bits of the IPv6 be zero, you get to translate between v6 and v4 transparently, but you still never get to use addresses that are longer than 32 bits, so the only thing it gains you is simpler IP processing (no header checksum etc) but not more address space. For this, you need a mechanism so that the initiator of the communication knows that the recipient supports longer addresses. That's what we do with records in the DNS today. There are no shortcuts here. BTW, Michel, you said you were about to return from the dark side in true Star Wars fashion. What gives? :-) ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
And there's always IPv8... Wasn't that IPv9 fun? ;) -Thaddeus -Original Message- From: Tim Chown [mailto:[EMAIL PROTECTED] Sent: Dienstag, 28. März 2006 07:09 To: ietf@ietf.org Subject: Re: Stupid NAT tricks and how to stop them. On Tue, Mar 28, 2006 at 01:54:52AM -0800, Michel Py wrote: Tim Chown wrote: If you deploy IPv6 NAT, you may as well stay with IPv4. You're the one who convinced me some three years ago that there will be IPv6 NAT no matter what, what's the message here? I think there will be IPv6 NAT, because some people will want it. That doesn't mean it's rational to deploy it :) See also http://www.ietf.org/internet-drafts/draft-ietf-v6ops-nap-02.txt Remember: Users don't read drafts/RFCs. And users don't walk into PC World and say 'I'd like a NAT router for my home network please'. They probably ask for a broadband modem, or something that doesn't specify NAT. We have deployed IPv6 in our enterprise (throughout). Could you have done it if you did not have the research dollars^H^H^H^H pounds? While we ironed out many issues with research funding assistance in 6NET, I would say the deployment we have now could be done as part of a natural evolutionary procurement process. The 'cost' is real terms is not that high. We have had to invest time in updating OSS-type elements, but much of the rest comes 'out of the box'. I guess we would have had some training costs as a 'normal' enterprise, but we've helped address that in the academic community by running hands-on IPv6 workshops (just as the Internet2 people do for their community). Phillip, there a few (such as: NAT typically requires hard state, which is a pain to replicate if there is more than one edge router). NAT is not completely evil, but it's far from being clean. Pretending that there are no good reasons against NAT is going to achieve the same as trying to eliminate it: nothing. I note Phillip's extremes of view on IPv6 and DNSSEC. It's interesting to compare how critical these two elements are, and his views on them. Yes, and since site-locals have been deprecated they will also hijack an unallocated block of addresses to use as private, same what happened prior to RFC 1597 for the very same reasons (difficult/pricey to get PI). There are now ULAs, http://www.ietf.org/rfc/rfc4193.txt. When people will begin to scream bloody murder to use the extended bits (because v4 is getting near exhaustion) the infrastructure could be already in place, and then the pressure will be on software developers to recode their stuff with 128-bit addresses. When that has happened, then we can make use of all these reserved fields for better purposes, and possibly allocate PI to everybody which is another pre-requisite to get rid of NAT. And there's always IPv8 ;) -- Tim/::1 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
The other side of the coin is the fact that many devices will effectively require no more than a /128 because of the way they connect up to the network. For example cell phones will be serviced on plans where the subscription fee is per device. Verizon, T-mobile, cingular need no more than one /64 each to service those networks. Well I see cell phones as routers for the on body IPv6 bluetooth network. I see cell phones as routers for your laptop. Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stupid NAT tricks and how to stop them.
On 27-mrt-2006, at 23:51, Austin Schutz wrote: Your long term view is irrelevant if you are unable to meet short term challenges. very true. but at the same time, it's not enough to meet short term challenges without providing a path to something that is sustainable in the long term. This is reasonable, but there is no realistic path to ipv6 that the known world can reasonably be expected to follow. Well, if you look at the rate at which the IPv4 address space is being used up, something will have to give at some point. Last year 168 million IPv4 addresses were given out by the RIRs. That's about 4.5% of the 3706 million usable IPv4 addresses, with 60.2% gone as of 2006-01-01 and 1465 million addresses still available. (Give/take a / 8 because of inconsistent IANA/ARIN records.) In the past 10 years, there have been several years where the growth of the growth was less than the year before: 1996199719981999200020012002200320042005 2.7 1.2 1.6 1.2 2.1 2.4 1.9 2.4 3.4 4.5 (The numbers represent the number of addresses used up in that year as a percentage of the 3.7 billion total usable IPv4 addresses.) Those years where the growth was smaller than the year before never happened twice or more in a row. This basically means that unless things take a radical turn, the long- term trend is accelerating growth so that remaining 40% will be gone in less than 9 years. Probably something like 7, as Geoff Huston predicts. When this happens, it will become extremely hard to find IPv4 addresses for new stuff, so many people/devices will have to share a single address through NAT. Today, NAT mostly works because it's not too hard to find someone who isn't NATed to coordinate the communication. With IPv4 depleted that situation will change for any new deployments, so NAT headaches will increase rapidly. (Bittorrent with half the peers behind NAT is no problem. Bittorrent with all the peers behind NAT is suboptimal. Bittorrent with everyone including the tracker behind NAT makes you want to look up the meaning of sneakernet.) At that point, it becomes a no-brainer to add IPv6 to bypass the IPv4 NAT and soon people who still have enough IPv4 space will want to use IPv6 too because that gives them easier access to people who don't have an IPv4 address. At this point ISPs will want to provide IPv6 services too because without that, IPv4-starved ISPs have a very hard time competing with IPv4-rich ISPs. With IPv6 they're still not on an even footing but at least the distance isn't as great. In other words: even though we have significant NAT today, people who need/want an unmolested IPv4 address today can have it without too much trouble. When IPv4 addresses are gone, this will stop being the case and IPv6 will start to look much more appealing. It would also help if by that time all software would work over IPv6. but the ipv6 vs. NAT battle is over in the marketplace. For now. Even with NAT we need a constant supply of fresh IPv4 addresses, which we're not going to have forever. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
On Wed, 29 Mar 2006, Mark Andrews wrote: The other side of the coin is the fact that many devices will effectively require no more than a /128 because of the way they connect up to the network. For example cell phones will be serviced on plans where the subscription fee is per device. Verizon, T-mobile, cingular need no more than one /64 each to service those networks. Well I see cell phones as routers for the on body IPv6 bluetooth network. I find it interesting that our vision is frequently so short-sighted that we can't even envision in the course of an arguement the applications that are possible today let alone the ones that people will want in the future. I see cell phones as routers for your laptop. they are now really... Mark -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf -- -- Joel Jaeggli Unix Consulting [EMAIL PROTECTED] GPG Key Fingerprint: 5C6E 0104 BAF0 40B0 5BD3 C38B F000 35AB B67F 56B2 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
RE: Stupid NAT tricks and how to stop them.
Iljitsch van Beijnum wrote: On 27-mrt-2006, at 23:51, Austin Schutz wrote: Your long term view is irrelevant if you are unable to meet short term challenges. very true. but at the same time, it's not enough to meet short term challenges without providing a path to something that is sustainable in the long term. This is reasonable, but there is no realistic path to ipv6 that the known world can reasonably be expected to follow. Well, if you look at the rate at which the IPv4 address space is being used up, something will have to give at some point. Last year 168 million IPv4 addresses were given out by the RIRs. That's about 4.5% of the 3706 million usable IPv4 addresses, with 60.2% gone as of 2006-01-01 and 1465 million addresses still available. (Give/take a / 8 because of inconsistent IANA/ARIN records.) In the past 10 years, there have been several years where the growth of the growth was less than the year before: 1996 199719981999200020012002200320042005 2.7 1.2 1.6 1.2 2.1 2.4 1.9 2.4 3.4 4.5 (The numbers represent the number of addresses used up in that year as a percentage of the 3.7 billion total usable IPv4 addresses.) Part of the problem here is that the allocation bundles don't map well into nice clean annual buckets. It is the overall trend that matters, not the fact that any given year had a higher or lower growth rate. Those years where the growth was smaller than the year before never happened twice or more in a row. This basically means that unless things take a radical turn, the long- term trend is accelerating growth so that remaining 40% will be gone in less than 9 years. Probably something like 7, as Geoff Huston predicts. While the exact date of exhaustion is impossible to predict, Geoff's 2012 target is presented to placate those in serious denial. The fundamental burn rate has been compound growth since 2000, and there is no reason for it to slow. In fact at the past NANOG meeting John asked if anyone saw reason for ARIN to pursue modifying the policy, and there was dead silence as no organization was willing to slow their business model for 'the global good'. At the same time, arriving at a lifetime anywhere near 2012 for the remaining pool takes dividing it by a constant rate of ~.75 /8's per month (the recent snapshot of cumulative outbound from the RIRs). On the other hand, applying the effective 5 yr+ historical compound consumption rate to the remaining pool shows that IANA runs out in late 2008 (http://www.tndh.net/~tony/ietf/5-yr-projection.pdf) at which point the RIRs collectively having 18 months on hand. Any given RIR may run out sooner or later than mid-2010 depending on their pool size and burn rate. All of this assumes no change in behavior, and the only predictable change at this point is a land grab. When this happens, it will become extremely hard to find IPv4 addresses for new stuff, so many people/devices will have to share a single address through NAT. Today, NAT mostly works because it's not too hard to find someone who isn't NATed to coordinate the communication. With IPv4 depleted that situation will change for any new deployments, so NAT headaches will increase rapidly. (Bittorrent with half the peers behind NAT is no problem. Bittorrent with all the peers behind NAT is suboptimal. Bittorrent with everyone including the tracker behind NAT makes you want to look up the meaning of sneakernet.) At that point, it becomes a no-brainer to add IPv6 to bypass the IPv4 NAT and soon people who still have enough IPv4 space will want to use IPv6 too because that gives them easier access to people who don't have an IPv4 address. At this point ISPs will want to provide IPv6 services too because without that, IPv4-starved ISPs have a very hard time competing with IPv4-rich ISPs. With IPv6 they're still not on an even footing but at least the distance isn't as great. While you are correct, this seems to understate the case. The compound consumption rate of the last 5+ years has been during wide deployment of nat. While many still disbelieve, there really are organizations that have exceeded the capacity set aside in rfc1918 and for business reasons are refusing to deal with multi-layered internal nat. They understand the real cost of this broken technology, and will not go there. In other words: even though we have significant NAT today, people who need/want an unmolested IPv4 address today can have it without too much trouble. When IPv4 addresses are gone, this will stop being the case and IPv6 will start to look much more appealing. It would also help if by that time all software would work over IPv6. Unfortunately this is a case of the application dev community needing a serious wake up call. The unrealistically long lifetime projections for IPv4 don't help in this regard either. but the ipv6 vs. NAT
Re: About cookies and refreshments cost and abuse
pinch of salt I think it interesting that the great minds of the IETF are discussing in depth something that is probably just slightly more important than the outcome of this week's American Idol contest. Oh well, here are my two cents... Cookies seem to be a scarce resource, so why not bring your own darn cookies to the meeting, and you wouldn't have a problem. Seriously, stop by a local grocery store, and plop down $3 and buy whatever kind of cookies make you the most happy. Aggravation avoided. Plop down another $3 and you now have a resource you can use to coerce other people down your path of draft-ness. Need to get a draft approved by your AD? Give him/her a cookie. So if we want to go with the whole ticket route, I say as the IETF, that we go for the whole solution (watch as I open another can of worms)... Badges with barcodes. We get a badge with a barcode. Want a cookie, stand in line, scan the badge. Solves the problem of multiple cookies, just grab everyone's badge. Does it need a human? Nope, just a loud buzzer. Oh, and to give a nod to the TAO of the IETF (I think that's the document) you won't have people standing in front of the cookie table. Move those badge readers to the doors. You then make sure everyone has paid their IETF admittance fee for the meeting. Yep, there are people who use the same badge and just show up. You also eliminate the blue sheets too. No more signing your name, just swipe a badge. You can then use these statistics to see if many people tried to attend the same WG meeting to plan agendas for next year. Do I think cookies are an important problem? Nope. Do I think we should get scanned badges for cookies, and meeting room admittance? Probably not, but I think it would be cool. Do I care when I have dinner? Nope, I either bring my own snack, or I just tough it out like the Internet Nerd Pioneer I one day hope to become. Cheers --Brett /pinch ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
Hallam-Baker, Phillip writes: That is not a real problem. I've lost count of the number of times I've heard _that_. Eight bits, sixteen bits, thirty-two bits, sixty-four bits, and now 128 bits ... they are all good for eternity for at least a few years, and then suddenly they are out of space. It is not practical to manage router tables with greater than 2^64 entries. In fact it is impractical to manage router tables with more than 2^48 entries using technology forseable in the next ten or so years. It will never be possible to put an entire gigabyte of memory into a computer. Processor speeds cannot exceed around 10 MIPS without running into fundamental physical barriers. The maximum transmission speed of a modem can never exceed 2400 bps. The other side of the coin is the fact that many devices will effectively require no more than a /128 because of the way they connect up to the network. For example cell phones will be serviced on plans where the subscription fee is per device. Verizon, T-mobile, cingular need no more than one /64 each to service those networks. No more than 18,446,744,073,709,551,616 addresses each? Well, that's comforting. But I suspect they will run out, anyway, for the same reason that all address spaces run out. Throwing away essentially the entire address space (/64) from the beginning is not a good sign. It just demonstrates that the address space will be exhausted in linear time, not exponential time. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re:StupidNAT tricks and how to stop them.)
Hallam-Baker, Phillip writes: My point was that even if we do run out of /64s at some point the last few remaining /64s can be made to go one heck of a long way. So the address space will ultimately be managed in crisis mode, because it was so badly mismanaged to begin with. Why does that sound familiar. Even if we do eventually exhaust the address space we can fix up the problems easily enough at the internetwork level. Why not just do things right to begin with? ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: StupidNAT tricks and how to stop them.)
Joel Jaeggli writes: I find it interesting that our vision is frequently so short-sighted that we can't even envision in the course of an arguement the applications that are possible today let alone the ones that people will want in the future. And one consequence of this is that we cannot possibly know today how to allocate address for the future, which is another reason why address spaces are exhausted to quickly, no matter how many bits they contain. And this in turn is why IPv6 won't last. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
Mark Andrews writes: Which was why IPv6 when to 128 bits rather than 64 bits. That won't help. It will add perhaps 25% to the lifetime of the address space, no more. 64 bits of address space would have been fine to give everyone all the addresses they would need. 128 bits gives them all the networks they will need. No, it does not. It's only twice as much as 64 bits, and 64 bits is only twice as much as 32. Addressing schemes consistently allocate addresses in a terribly shortsighted way as bit spans, rather than address ranges, so address ranges are consumed much more quickly than they should be. This seems to be one of the most consistent mistakes of computer engineers ever since computers were invented. After all these decades, they still have no clue. ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 vs. Stupid NAT tricks: false dichotomy? (Was: Re: Stupid NAT tricks and how to stop them.)
Thomas Narten writes: This is FUD. Care to back up your assertions with real analysis? Sure. The consistent mistake engineers make in allocating addresses is that they estimate capacity in terms of sequential and consecutive assignment of addresses--but they _assign_ addresses in terms of bit spans within the address itself, which exhausts addresses in an exponential way. They do this in part because they attempt to encode information directly into the address, instead of just using it as a serial identifier. An address of n bits contains 2^n available addresses _only_ if they are assigned serially and consecutively; dividing those bits into any arrangement of smaller fields reduces capacity exponentially. For example, if you have a 16-bit address field, at first it looks as those it has 65,536 addresses. And it does ... if you assign addresses as 0001, 0010, and so on. But if you allocate addresses by dividing those 16 bits into fields, you dramatically reduce the total address space available. If you reserve the first eight bits for a vendor, and the second eight bits for a product, you've cut the address space by 99.6%, not by 50%. You will run out of addresses in record time, and yet you'll never use more than a tiny fraction of the theoretical capacity of the address space. All because you wanted the short-term convenience of encoding information into the address itself. Engineers make this mistake over, and over, and over. I don't know if they are just too stupid to understand the above concepts, or if they are so arrogant that they think they can somehow short-circuit information theory and do the impossible. I tend to vote for arrogance, since I think (and hope) that engineers aren't really that stupid. And further evidence for pure arrogance is that engineers try to allocate address spaces now for a future that they are unable to imagine. They allocate /64 fields out of 128 bits for purposes that they understand now, even though the real need for addresses is likely to be completely different (and unforseeable) by the time addresses actually start to run short. I know I'm wasting my breath; if engineers were that easy to persuade, they would not have made the same mistake over and over for nearly a hundred years. I'm sure others have tried to point out their errors time and again, especially in recent years as more people have caught on to the problem. But they can't be told. They are convinced that it won't happen to them, even though it happened to everyone else. A 128-bit address seems like more than the universe will ever need, and it definitely is ... but only if addresses are assigned serially from the address space, without any information encoded into the address itself. As soon as you reserve any portion of the field in any way, there are multiple exponential reductions in capacity, which can exhaust the address space entirely in a very short time. The mistakes have already been made with IPv6. Someone decided to allocate bit spans out of the address, instantly invalidating the very vast majority of all possible addresses in the address space, and thereby reducing address capacity exponentially. Nobody really knows how addresses will be used 20 years from now, so why do people try to guess and sacrifice the capacity of IPv6 in the process? Don't they ever learn? Is there a safe and conservative way of allocating IPv6 address space? Yes. Set the first 96 bits to zero, and set the remaining 32 to the current IPv4 addresses. When that runs out, set the first 95 bits to zero, set the 96th bit to one, and use the remaining 32 bits for another IPv4 address space. And so on. A space of 128 bits will last for eternity in this way, and most of the space will remain available for any conceivable future addressing scheme, even those we cannot dream of today. In other words, don't allocate bit spans within the address field, allocate address _ranges_ out of the full 128 bits. But I know that won't happen. However, perhaps this message will remain archived somewhere so that I can say I told you so when the address space finally runs out (I'm pretty sure I'll still be around--we all will). ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Protocol Action: 'Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP)' to Proposed Standard
The IESG has approved the following document: - 'Using the NETCONF Protocol over Blocks Extensible Exchange Protocol (BEEP) ' draft-ietf-netconf-beep-10.txt as a Proposed Standard This document is the product of the Network Configuration Working Group. The IESG contact persons are Bert Wijnen and David Kessens. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-netconf-beep-10.txt Technical Summary This document specifies an transport protocol mapping for the NETCONF protocol over the Blocks Extensible Exchange Protocol (BEEP). Working Group Summary The NETCONF Working Group has consensus to publish this document as a Proposed Standard. Protocol Quality It is likely that there are several implementations of this document in various stages of completion at this time. Several major equipment vendors have indicated interest in supporting this document, and some non-commercial implementations are also expected. The WG would like to thank Marshall Rose for his assistance with portions of this document. Bert Wijnen has reviewed this document for the IESG IANA Note -Original Message- From: Andy Bierman [mailto:[EMAIL PROTECTED] Sent: Thursday, March 23, 2006 14:45 To: Bert Wijnen Cc: [EMAIL PROTECTED] Subject: Port request for draft-ietf-netconf-beep-10.txt Hi, Please assign a port number 1024 for the NETCONF protocol over the Blocks Extensible Exchange protocol, as specified in section 4 of this document. thanks, Andy ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'IP over InfiniBand: Connected Mode' to Proposed Standard
The IESG has approved the following document: - 'IP over InfiniBand: Connected Mode ' draft-ietf-ipoib-connected-mode-03.txt as a Proposed Standard This document is the product of the IP over InfiniBand Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-ipoib-connected-mode-03.txt Technical Summary This document describes transmission of IPv4/IPv6 packets and address resolution over the connected modes of InfiniBand. Working Group Summary This document is a work item of the IPOIB WG. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'DHCPv6 Relay Agent Remote ID Option' to Proposed Standard
The IESG has approved the following document: - 'DHCPv6 Relay Agent Remote ID Option ' draft-ietf-dhc-dhcpv6-remoteid-01.txt as a Proposed Standard This document is the product of the Dynamic Host Configuration Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dhc-dhcpv6-remoteid-01.txt Technical Summary This memo defines a new Relay Agent Remote-ID option for the Dynamic Host Configuration Protocol for IPv6 (DHCPv6). This option is the DHCPv6 equivalent for the Dynamic Host Configuration Protocol for IPv4 (DHCPv4) Relay Agent Option's Remote-ID suboption as specified in RFC 3046. Working Group Summary This document is the work of the DHC WG. The WG has consensus to publish this draft as a Proposed Standard. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. Note to RFC Editor In section 3: OLD: This option MAY be added by DHCPv6 relay agents which terminate switched or permanent circuits and have mechanisms to identify the remote host end of the circuit. NEW: This option may be added by DHCPv6 relay agents which terminate ^^^ switched or permanent circuits and have mechanisms to identify the remote host end of the circuit. OLD: The remote-id field MAY be used to encode, for instance: NEW: The remote-id field may be used to encode, for instance: ^^^ OLD: Each vendor MUST assure that the remote-id is unique for their enterprise-number, as the octet sequence of enterprise-number followed by remote-id MUST be globally unique. One way to achieve uniqueness might be to include the relay agent's DUID [1] in the remote-id. NEW: Each vendor must assure that the remote-id is unique for their enterprise-number, as the octet sequence of enterprise-number followed by remote-id must be globally unique. One way to achieve uniqueness might be to include the relay agent's DUID [1] in the remote-id. In Section 4: OLD: DHCPv6 relay agents MAY be configured to include a Remote-ID option in relayed (RELAY-FORW) DHCPv6 messages. NEW: DHCPv6 relay agents may be configured to include a Remote-ID option ^^^ in relayed (RELAY-FORW) DHCPv6 messages. In Section 5: OLD: This option provides additional information to the DHCPv6 server. The DHCPv6 server, if it is configured to support this option, MAY use this information to select parameters specific to particular users, hosts, or subscriber modems. The combined enterprise-number and remote-id SHOULD be considered an opaque value, with policies based on exact string match only; that is, the remote-id field SHOULD NOT be internally parsed by the server. NEW: This option provides additional information to the DHCPv6 server. The DHCPv6 server, if it is configured to support this option, may ^^^ use this information to select parameters specific to particular users, hosts, or subscriber modems. The combined enterprise-number and remote-id SHOULD be considered an opaque value, with policies based on exact string match only; that is, the remote-id field SHOULD NOT be internally parsed by the server. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
Protocol Action: 'The Role of Wildcards in the Domain Name System' to Proposed Standard
The IESG has approved the following document: - 'The Role of Wildcards in the Domain Name System ' draft-ietf-dnsext-wcard-clarify-11.txt as a Proposed Standard This document is the product of the DNS Extensions Working Group. The IESG contact persons are Margaret Wasserman and Mark Townsley. A URL of this Internet-Draft is: http://www.ietf.org/internet-drafts/draft-ietf-dnsext-wcard-clarify-11.txt Technical Summary This is an update to the wildcard definition of RFC 1034. The interaction with wildcards and CNAME is changed, an error condition removed, and the words defining some concepts central to wildcards are changed. The overall goal is not to change wildcards, but to refine the definition of RFC 1034. Working Group Summary This document is a work item of the DNSEXT WG. The WG has consensus to publish this document as a Proposed Standard. Protocol Quality This document was reviewed for the IESG by Margaret Wasserman. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www1.ietf.org/mailman/listinfo/ietf-announce
