last call comments for draft-ietf-6man-stable-privacy-addresses-06
In the process of doing the apps area review, I came across some points that were not related to applications. The basis for these comments is precisely the sentiment that Russ Housley expressed, which is that the specification is done when there is no more to remove. With this document, I wonder if quite a bit could be removed. Specifically, a great deal of discussion goes into the PRF involving DAD counters, etc, when all that is needed is a suitable PRF. The draft in fact says this in Section 3 after an explanation of the inputs. Any PRF that follows the guidelines of RFC 4086 should do fine and not cause interoperability OR security problems. Put simply, you are over-specifying the RID and derive no benefit from doing so. Also, the following text in section 3 Page 7 is contorted: This means that this document does not formally obsolete or deprecate any of the existing algorithms to generate Interface IDs (e.g. such as that specified in [RFC2464]). However, those IPv6 implementations that employ this specification must generate all of their stable addresses as specified in this document. My suggestion is to simplify remove it as it is self-evident. Finally, this algorithm requires that the resultant host portion be 64 bits. Is that necessary? Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06
Hi Fernando, Thanks very much for your response. On 4/22/13 6:06 PM, Fernando Gont wrote: Hi, Eliot, On 04/22/2013 01:20 AM, Eliot Lear wrote: In the process of doing the apps area review, I came across some points that were not related to applications. The basis for these comments is precisely the sentiment that Russ Housley expressed, which is that the specification is done when there is no more to remove. I'd probaby disagree with such statement. One thing is removing tuff from the mechanism or algorithm that you're standardizing, in the hopes of keeping it simple (this one I'd agree with). Another is removing text from specifications, which essentially means that the gut implementing the spec has more to figure out by himself, and hence more chances for failures. Fair point, of course. With this document, I wonder if quite a bit could be removed. Specifically, a great deal of discussion goes into the PRF involving DAD counters, etc, when all that is needed is a suitable PRF. Not sure what you mean...What's thetext that you think could/should be removed? Sorry I wasn't clear: what is the benefit of specifying the algorithm, when simply popping out another PRF will in just about any instance do the job (unless you are reinitializing the PRF with the same seed)? The draft in fact says this in Section 3 after an explanation of the inputs. Any PRF that follows the guidelines of RFC 4086 should do fine and not cause interoperability OR security problems. If you're referring to the text that explains why we're not mandating any specific PRF, that text is there because the issue was raisen in the wg, Ok. So what I gather is that there was a negotiation within the WG and that the algorithm is optional. Ok. From an outside point of view, I didn't need to know that, and the question is what was the value of still specifying the PRF. I think Ran Atkinson answered that. He feels he wants a fully specified algorithm from which to start. Ok. My only response is that I don't understand the need (generating 64 bits that aren't the same shouldn't be that hard), but if the WG really believes there is one, okay. Also, the following text in section 3 Page 7 is contorted: This means that this document does not formally obsolete or deprecate any of the existing algorithms to generate Interface IDs (e.g. such as that specified in [RFC2464]). However, those IPv6 implementations that employ this specification must generate all of their stable addresses as specified in this document. My suggestion is to simplify remove it as it is self-evident. What's the part that is evident? The one about not deprecating existing algorithms? -- Because the other ne certainly isn't: if you're going to use this algorithm for generating addresses *in addition* to those generated by traditional SLAAC, then this document wouldn't mitigate address-scanning attacks. How would an IPv6 implementation employing this specification vary from this specification in a way you or the working group would find objectionable? Also, did you mean MUST? If not, this language is all the more confusing and I don't know what you mean. Finally, this algorithm requires that the resultant host portion be 64 bits. Is that necessary? Well, yes- If the PRF produces a bit string larger than 64 bits, and you say nothing about how you grab the IID, then the algorithm is underspecified. The easier it is for a developer to go through this document and come up with an implementation, the better. The more the open questions, the worse. I think we are underestimating our developers but if the working group feels differently, okay. I asked the above question because it is at least conceivable that at some point host portion != 64 bits and this is the only place in the document where the requirement is stated. Yes, screwing with the 64 bit boundary today is bound to cause all sorts of breakage. I'm not thinking of today but the future. And yes, another argument would be that there isn't enough address space for this to be effectively private. Those are two different issues, but fixing the boundary here reminds me of mistakes we made with IPv4 way back when. In this day and age we're talking about a lot more cleanup later. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: last call comments for draft-ietf-6man-stable-privacy-addresses-06
H Fernando, On 4/22/13 9:23 PM, Fernando Gont wrote: There seems to be a disconnect here: We want an algorithm that, roughly speaking, whenever you connect to the same network, gives you the same address. But such address should be different for each network you connect to. Thank you, and yes there was a disconnect. Indeed now I get it. For some reason I had assumed that you meant for some short period of time, but the algorithm is clearly aimed at longer periods of time (e.g., across reboots). Given that, the inputs the WG has stated seem perfectly reasonable. How would an IPv6 implementation employing this specification vary from this specification in a way you or the working group would find objectionable? If, for the same interface you employ this algorithm *and* the traditional SLAAC algorithm, that's objectionable. Right. With you now. Thanks again... Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Consensus call on adopting: draft-gont-6man-stable-privacy-addresses-01
On 4/18/12 5:43 PM, Fernando Gont wrote: Hi, Eliot, On 04/18/2012 06:37 AM, Eliot Lear wrote: On 04/13/2012 10:09 AM, Eliot Lear wrote: At one point you write that the intent is to replace EUI-64-based addresses (Section 5). Exactly. [Correcting myself] The intent is to have draft-gont-6man-stable-privacy-addresses used instead of the IIDs that embed IEEE identifiers. Yes, I'm looking at the quoted paragraphs (I'm not quite sure from where you're quoting): As noted in [RFC4941], anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier. Therefore, since privacy addresses [RFC4941] do not eliminate the use of fixed identifiers for server-like functions, they only *partially* mitigate the correlation of host activities (see Section 7 for some example attacks that are still possible with privacy addresses). Therefore, it is vital that the privacy And so on. In essence you set up an argument against 4941 but that isn't really your argument for the draft and so I don't really know what it's doing there. It's not an argument against RFc4941, but rather an argument that even with RFC4941, you still need to do something about the IEEE-based IIDs. At the Paris IETF, some folks argued that if you have RFC 4941 in place, you don't need draft-gont-6man-stable-privacy-addresses. Section 7 of draft-gont-6man-stable-privacy-addresses (which should be an Appendix, rather than a section in the main body of the document) illustrates that that's not the case: even if you're employing RFC4941, you're still subject to host-scanning attacks and host tracking. Well, host scanning at least. Host tracking depends on the implementation. It is *not* an argument *against* RFC 4941, since it *is* valuable to have addresses that change over time for outging communications. But perhaps that's not as important as this: I am concerned that adopting this mechanism will make matters worse if this mechanism is being used as an alternative to CGAs, as opposed to EUI-64s.. I don't follow. Could you clarify your concern? You argue that this is an alternative to EUI-64s. Let me correct myself: this is an alternative to IIDs that embed IEEE identifiers: The modified EUI-64 format is a general format, and it does not need to embed IEEE identifiers (for instance, RFC4941 produce Mod-EUI-64 format identifiers, bu clearly do not embed IEEE identifiers). But in practice I am concerned that people will not use this as an alternative to EUI-64s, but instead as an alternative to CGAs, Why? I don't really follow the relationship of draft-gont-6man-stable-privacy-addresses with CGAs. CGAs are used for SEND, and are not even mentioned in this I-D. How do you arrive to the conclusion that people might want to use this instead of CGAs?? As noted in the I-D tihs mechanism is meant to be a replacement for IIDs based on IEEE identifiers. This is orthogonal to RFC4941 and orthogonal to CGAs. I know what you mean. That matters less than how other people make use of the work. Believe me I know. I've got my name on RFC-1918, for crying out loud. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Consensus call on adopting: draft-gont-6man-stable-privacy-addresses-01
Dear Fernando, My apologies for the delayed response: On 4/13/12 2:31 PM, Fernando Gont wrote: hI, Eliot, On 04/13/2012 10:09 AM, Eliot Lear wrote: At one point you write that the intent is to replace EUI-64-based addresses (Section 5). Exactly. But that doesn't seem to jibe with what you write in the intro about RFC-4941. Could you please cite the conflicting text? Yes, I'm looking at the quoted paragraphs (I'm not quite sure from where you're quoting): As noted in [RFC4941], anytime a fixed identifier is used in multiple contexts, it becomes possible to correlate seemingly unrelated activity using this identifier. Therefore, since privacy addresses [RFC4941] do not eliminate the use of fixed identifiers for server-like functions, they only *partially* mitigate the correlation of host activities (see Section 7 for some example attacks that are still possible with privacy addresses). Therefore, it is vital that the privacy And so on. In essence you set up an argument against 4941 but that isn't really your argument for the draft and so I don't really know what it's doing there. But perhaps that's not as important as this: I am concerned that adopting this mechanism will make matters worse if this mechanism is being used as an alternative to CGAs, as opposed to EUI-64s.. I don't follow. Could you clarify your concern? You argue that this is an alternative to EUI-64s. But in practice I am concerned that people will not use this as an alternative to EUI-64s, but instead as an alternative to CGAs, thus improving tracibility (not generally a good thing). Please explain what I'm missing (I'm sure it's a lot). Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: Consensus call on adopting: draft-gont-6man-stable-privacy-addresses-01
A question for the draft author: At one point you write that the intent is to replace EUI-64-based addresses (Section 5). But that doesn't seem to jibe with what you write in the intro about RFC-4941. I am concerned that adopting this mechanism will make matters worse if this mechanism is being used as an alternative to CGAs, as opposed to EUI-64s.. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: [saag] [v6ops] ITU-T SG17 IPv6 security work items liaison
Joe, Liaison A suggestion just on this one point: I'd prefer to see the relevant WGs endorse these as useful ways forward before adding them to this list. It is good for the IETF to provide the ITU's membership an opportunity to comment either formally via the liaison process or informally as individuals before work is finalized, just as we would like that opportunity. So long as we are clear on the status of the work, and the work can reasonably be construed as relevant, it's okay to mention it. Now, how should one apply my advice (which is what this is) to your suggestion? /Liaison Regards, Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: ITU-T SG17 IPv6 security work items liaison
Arturo, On 6/5/11 10:30 PM, Arturo Servin wrote: I do not see why the ITU has to start from zero. There are several (or some at least) very good RFC and I+D documents related to IPv6 security. I think we should recommend them to ITU, it is good that they let us know, it would be better if they use our work as a foundation. There are several specific areas of interest that you can view at https://datatracker.ietf.org/documents/LIAISON/file1228.pdf. The chairman and vice-chairman of the ITU's security area, SG17, are informing us that two of their working groups which the ITU-T calls Questions will be taking on new work relating to IPv6. Let's review the two work items: The first thing to note is that X.ipv6-secguide is targeted to be a deployment guide. We need more of these for IPv6 and we should welcome the ITU-T's involvement. The second document, X.mgv6 is meant to be management guidelines for implementation of IPv6. We provide a fair amount of this sort of guidance in our collective works. Also, the difference between implementation guidance and normative statements can be very narrow. Therefore, this is the area most likely to have overlap. The best way to address that overlap is to communicate effectively through the liaison process, and perhaps to also participate directly in the meetings, when possible. Here the chairman and vice-chairman of SG17 have recognized that the IETF is an important player in the work to be done. While no response has been requested, it would be wise for us to provide the relevant related work so, as you say, the ITU-T doesn't attempt to start from scratch. I hasten to point out that they are by no means starting from scratch, but we should still provide them relevant guidance. So what is relevant guidance? That can take several different forms: 1. Direct participation in the Study Group meetings. Study Group meetings are open to Member States and Sector Members. ISOC is a Sector Member. The IETF on its own is not. 2. Concise and relevant liaison statements. As this work is just beginning, we can point to not only the published RFCs that are relevant, and they include not only RFC 4294 and draft-ietf-6man-node-req-bis (and we can reference this as a work in progress, and in fact invite comment), but also relevant portions of other RFCs, particular their relevant Security Considerations sections. 3. Informal consultations with ITU-T participants. Believe it or not, this is often the most effective way to contribute. At the same time we should invite SG17 to provide us any feedback on our works, especially when they discover any of the following: * A security problem; * An obstacle to deployment; or * An interoperability problem. While this solicitation should not be limited to the ITU-T, that organization has a reach into the developing world that quite frankly we do not, and they may spot issues that relate to certain environments. Hope this helps, Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: draft-dec-dhcpv6-route-option
Woj, Three questions for the group: 1. Is there a practical limit to the number of route entries? 2. Is there a practical need to pad in DHCP? 3. Would it be better to provide a seed address into some sort of routing function so that the information can change without having to monkey with DHCP? Thanks, Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www.ietf.org/mailman/listinfo/ipv6
Re: draft-ietf-ipv6-ula-central-02.txt
Having had my name on RFC 1918, I think understand some of the issues. There is precisely one that I find at all interesting in this proposal, having stated the concern in RFC 1627: * avoiding collisions, and Geoff Huston's math demonstrates the likelihood of that happening But one needn't have reverse lookups delegated in the root to address this concern. I also understand something about the differences between ULA-C and RFC 1918. For one, this space will be unique within the limits of human error. RFC 1918 not being unique meant that providers really had no choice about blocking it, and IANA had no method to insert reverse addresses to a particular site. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
Mark Andrews wrote: I would have thought that router renumbering should be no harder that host renumbering. Essentially all you are changing is the higher (/48 normally) prefix bits. All that is required is a method to distribute the set of prefixes in use with a set of tags (global, deprecated, ula, advertise in RA, etc.). I think there has been hype on both sides of this question. Router renumbering used to be VERY annoying. I've now published several times on the subject and I can say that it's not as hard as it was, but it's not as easy as it could be. Specifically, prefix delegation should do the job for small routers, particularly in the consumer market. Making use of PD in the enterprise is more experimental, I would say, because, as Bill alludes, there are quite a number of knobs to play with. Consider that a typical enterprise router not only has interface addresses and routing subsystems and firewalls, but may also have such fun as VRRP/HSRP configurations, load balancing capabilities, NetFlow/sflow collectors, multicast configuration that has some unicast addresses hidden in it, management configuration (e.g., SNMP, SYSLOG, other), and the like. In my opinion, this means that the router of the future needs to look a little different, and this has implications for other subsystems. Much of this could conceivably be hidden with DNS, but the router itself needs to function not just deterministically but predictably down to the minute in terms of which addresses it is using. DNS isn't very good at that because your TTLs are based on when you query, and are tied to relatively fixed configurations, but it can be used for many things even so. And today you can do that in many portions of the configuration - but not all. It is possible to abstract out much of the configuration EVEN WITHOUT DNS, and modularize those things that will change. And we've done *some* of that at Cisco, but we all could do more. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
Jeroen Massar wrote: Eliot Lear wrote: Mark Andrews wrote: I would have thought that router renumbering should be no harder that host renumbering. Essentially all you are changing is the higher (/48 normally) prefix bits. All that is required is a method to distribute the set of prefixes in use with a set of tags (global, deprecated, ula, advertise in RA, etc.). I think there has been hype on both sides of this question. Router renumbering used to be VERY annoying. I've now published several times on the subject Any links to the papers? There are two that I can point you at, and perhaps the temporal difference would be at least amusing: * Renumbering: Threat or Menace?, Lear, Katinsky, Tharp, et al, Proceedings of the Tenth Systems Administration Conference (LISA96) * Procedures for Renumbering an IPv6 Network Without a Flag Day, Baker, Lear, Droms, RFC 4192, September, 2005. I would also add that Tim Chown has done an extensive amount of work in this space. Indeed, but except for firewalling, it is why I mentioned using a local space (PI) or some other 'globally unique chunk that they can keep'. Certainly we've heard this argument from large enterprise customers. One will then configure all the internal setups (snmp,syslog,sflow/netflow etc) using the forever addresses and won't have to care about those anymore. Sure. Routing internally can also happen using those addresses, though the scary bit is of course when the MTU does change or a Host/Net unreach has to be sent, the router has to pick the correct global address and not the one which is only used inside the network. This really depends on just how scary an enterprise routing configuration is. They can be quite complex depending on both their internal and external connectivity, and each has some implications for the other. There are quite a number of enterprises that make heavy use of BGP internally. But certainly the point of ULAs was to provide some stability in this area. I think LISP (draft-farinacci-lisp-00.txt) has promise here as well, as may Robin's iVIP proposal (see the ram archives for details). In my opinion, this means that the router of the future needs to look a little different, and this has implications for other subsystems. [..goodbits..] Which is indeed why I am thinking that ID/LOC is the way to go. One internal prefix on the local network, and whatever prefix is on the global Internet. Apply ID/LOC when your packets are going somewhere where you can't use your local prefix. If your point is that you should never have to renumber, then that's a lovely way to go. It will still happen, of course, as companies merge and grow. I think IPv6 helps with the latter, but the former is still a challenge simply because topologies change. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Why does everyone see router renumbnering as hard? (was Re: draft-ietf-ipv6-ula-central-02.txt and NAT)
Michael, I totally understand the concern over circular dependencies. They are not to be underestimated. And in a service provider environment I think you must be doubly cautious about them. However, in an enterprise environment it may be appropriate to make certain allowances for certain services, and under certain circumstances. For instance, a load balancer may require DNS to be functioning already in order for it to service requests. Similarly, it may be possible to secondary a zone in order to be able to bring up certain other services, such as NTP. It is *even* possible to retain policy in DNS if one really wants to do so under such circumstances, but one has to at that point consider what your failsafe is. Ultimately, however, the administrative issues of renumbering revolve around an inability to abstract IP address information. In solving that problem, however one performs the dereference from abstract to concrete, one must worry about dependency loops. A configuration server could just as easily be unavailable, for instance, as a name server. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: address selection and DHCPv6
Alain, Ipv6 address will be much more stable than EUI64. But, more importantly, they will be centrally assigned, ie can be propagated to places that maitain ACLs. Just because one receives a DHCP-assigned address doesn't mean one will use it, and so such security is fraught with risks. I'm not say it's impossible, but great caution is needed when going in this direction. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Endianness of IPv6 and payloads
[EMAIL PROTECTED] wrote: [write a draft] How about revving 2460? Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: Prefix Delegation using ICMPv6
Syam Madanapalli wrote: Currently DHCP mechanism works only between routers whereas this new mechanism works for end hosts. The difference between a router and a host is a routing process and a willingness to forward packets, not how it interprets ICMP or whether it can parse DHCP. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: RFC3484 problem: scoping with site-locals/ULAs
David others, If I understand the problem correctly, no matter whether you prefer IPv4 or IPv6 the presumption that is failing us is that if the interface has an A or record associated with it then it is reachable on that address. And yet DNS has no real understanding of reachability except in the crude case of split DNS. Would this be a reasonable assessment or did I blow it? Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: RFC4193 - ULA universal/local bit = 1 or 0
Roger, On Thu, 27 Apr 2006, Soohong Daniel Park wrote: While adopting ULA into the local networks, I am curious how to set universal/local bit of Interface ID. There is no any mention in RFC4193. Which is correct ? 1 or 0 ? 1 is for those assigned to you while 0 are free for any to use last I read up on the subject. By my reading I think you have it backwards. Here is the relevant text: L Set to 1 if the prefix is locally assigned. Set to 0 may be defined in the future. See Section 3.2 for additional information. Today, so far as I know, there is no defined allocation plan or system for one to set that bit to 0. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Multi-homing BOF at NANOG 35
David Conrad wrote: On Oct 15, 2005, at 2:34 AM, Eliot Lear wrote: The IETF cannot legislate prefix lengths, but the argument behind conservation beyond /48 would be utterly silly and demonstrates a revenue opportunity, plain and simple. When multiple /19s and /20s have been allocated and there are rumors of much shorter prefixes which can be justified under the current rules, I'm not so sure discussions about conservation can be classified as utterly silly. Did you see the words beyond /48 somewhere above, David? I'm not saying we should be blowing allocations like /19s and /20s (although I would be interested in data on that and the ). This is a matter of timescale. Prefixes should be expected to change. In fact, SHIM6 should be able to provide equivalent of SCTP's ADD-IP to *devalue* prefix stability. Unfortunately, since applications are aware of IP address structures (both v4 and, sadly, v6), you'll need to rewrite all applications, libraries, and kernels to tolerate changes in those addresses at arbitrary times or face broken connections or misdirected packets. An apparent base assumption in IPv4 was that addresses were stable over a session (be it connection-oriented or connectionless). This assumption permeates every IP stack. Given DNS root server IP addresses retired over 10 years ago still get 30 queries per second, I doubt prefixes can be expected to change by all applications in our lifetimes. This is the purpose of SHIM6. It is not something meant to happen overnight. And it is not something that is meant as a forklift upgrade. And I will be you dollars to doughnuts that those 30q/s are not harming any application that anyone cares about (other than generating unnecessary load). Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Multi-homing BOF at NANOG 35
Hi, Unfortunately, that does not address most of the problems that drive the demand for NAT. The current economic model is: 1) Pay for addresses 2) Pay more for stable addresses 3) Pay much more for portable stable addresses With more address space available, IPv6 may help with (1) if providers play along. But as we have recently seen, customer prefix lengths are already under attack by perfectly reasonable-sounding conservation arguments. A need to conserve always justifies a need to charge. The IETF cannot legislate prefix lengths, but the argument behind conservation beyond /48 would be utterly silly and demonstrates a revenue opportunity, plain and simple. IPv6 does nothing good for (2). In fact it makes the situation worse by making renumbering easier without making it less disruptive. Assuming I understand the protocol correctly, shim6 increases the premium on stable addresses since they will be necessary for its version of PA multi-homing. (Shim6 seems to let you build stable quasi-identifiers on top of two or more stable locators. I would prefer a solution that lets you build stable identifiers on top of one or more unstable locator(s).) This is a matter of timescale. Prefixes should be expected to change. In fact, SHIM6 should be able to provide equivalent of SCTP's ADD-IP to *devalue* prefix stability. IPv6 itself does nothing good for (3). PI allocations may well be available to some set of entities for a while to ease the transition, but that just brings us back to routing table concerns. There is no general PI solution on the horizon, and shim6 may make such a solution less likely to appear. The whole point of SHIM6 from my point of view is quite the opposite by providing a means to advertise access via other prefixes. So could you please justify your above statement? Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 Multi-homing BOF at NANOG 35
Paul, We'll always need PI. The Independence part of PI is what people /really/ want. They don't want multiple-PA (they can do that already relatively easily). If people can not get globally-unique PI addresses they will use private PI space and use address translation. I think enterprise administrators would be happy to go one level deeper under certain circumstances: - there is a selection algorithm that works properly - there is the ability to switch between the two without loss of L4 connections - it can be administered easily - etc. This was the a large part of why Randy Bush asked for draft-ietf-multi6-things-to-think-about.txt. Eliot IETF IPv6 working group mailing list ipv6@ietf.org Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: [rfc2462bis] relationship between M/O flags and relatedprotocols
Christian Huitema wrote: The downside with speculative text is that it creates a weak spot in the RFC. Ask yourself how much of the text will still be valid in 5 years, when have more operation experience. The normative text will probably still be, but there is a high likelihood that the speculative text will be off-base. What will we do then? Rewrite the entire RFC? We update it like anything else. In the end what enterprises will need are a set of predictable behaviors so they know how long transition states will last. So long as you can answer those questions in the draft, life is good. Eliot IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: I-D ACTION:draft-ietf-ipv6-deprecate-site-local-02.txt
Alain, Your proposal below is fine. Brian, what do you think? Eliot Alain Durand wrote: The whole story about deprecating Site Local has led to very complex discussions that a lot of people had difficulties to follow, partly because the issues are complex and partly because of the heat of the debate. As we are coming near to a conclusion to this painful story, I believe we owe implementors and network administrators very clear guidelines on what to do now and confusion in this section of the document is IMHO not acceptable. I think the key is to dissociate in this text what implementors and what network administrator have to do. To the implementors: a) don't implement SL if you are designing a new product b) don't rush removing SL support from your current products, this can be done in future releases. To network administrators: a) don't design new networks using SL b) don't rush redesigning your existing network using SL however, don't expect them to work in the future as new implementations will not support SL. If we explain it this way, maybe we can get rid of the MUST/SHOULD keywords in this section as anyway they are inappropriate as the IETF cannot tell nor enforce what implementors or network administrators do or don't. - Alain. On Dec 5, 2003, at 9:43 AM, Christian Huitema wrote: It would actually be much simpler and less confusing to say only The special behavior of this prefix SHOULD no longer be supported and nothing about existing deployments. This doesn't work operationally, because people use site-locals today. And as we've debated endlessly we don't do flag days anymore. IMHO this text is good enough to ship. I understand Alain's point, the possible confusion about what do in service packs and other types of upgrades, but we went round and round and eventually decided to just leave the text as is. We had a very explicit discussion of this topic during the WG meeting in Minneapolis, and the sense of the room was rather close to Eliot's opinion. In fact, I proposed to change the text to Alain's wording, but Brian Carpenter objected that this would cause more confusion, since we really want to say MUST not use to prevent further usage, and SHOULD does not achieve that. The sense of the room was clearly with Brian. I guess this is one of the cases where the consensus is a bit rough. -- Christian Huitema IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: I-D ACTION:draft-ietf-ipv6-deprecate-site-local-02.txt
Brian E Carpenter wrote: Which software release counts as new is indeed not a question for the IETF, and each implementer will have to make his/her own judgement about exactly when to remove the feature. But I don't think it's wrong to say that they MUST remove it. Sorry- I'm lost in pronouns here. Who MUST remove it? If you're referring to new implementations (for some value of new), I agree. Eliot IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: IPv6 w.g. Last Call on Deprecating Site Local Addresses
Brian, In response to your last call, I'd like to comment on the following sections of the document: Section 2.4 Site is a Vague Concept This section does overstate the case. The last paragraph itself is sufficient cause for concern, regarding the concept as it was envisioned. There is nothing wrong with an administratively scoped boundary, and I would make that more clear. What must be clear is what happens when you have more than one such beastie. Section 4 I agree with Alain. Any text that reads MUST no longer be supported is itself not supportable ;-) The IETF cannot dictate this sort of behavior, and making claims that we can is not helpful. I would simply state that the behavior is deprecated, and that new implementations needn't implement it. Whether they choose to do so is a matter for them. Realistically speaking I would be concerned if my routing vendor released a new piece of software that caused my existing network to stop routing. Thus, the text, However, router implementations SHOULD be configured to prevent routing of this prefix by default, is not quite right. I understand this was not the intent, given what is said about existing deployments, but a router doesn't know from existing versus new deployments. Rather, something like the following: New routing implementations should not support the functionality necessary to implement site-local scoping, and existing implementations should anticipate removing existing support at some point in the future. Eliot ps: you may use any of my words without listing me as an author ;-) IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
Re: why market picked up NATs [Re: Writeups on why RFC1918 is bad?]
DING DING IPv4-0-Meter just went off. Why is this an issue in v6-land, assuming you can get a v6 consumer networking device? Eliot Michel Py wrote: Thomas, Thomas Narten wrote: If you are residential user, try finding a home router that is actually a Real Router. I've come to the unfortunate conclusion that they no longer exist. The $40 router never existed. Get real, there is no way to support Joe Blow configuring a router if it sells for $40. There are dual-ethernet products such as the Netopia R910 ($170) that do what you are looking for. There also are several sub-$100 boxes, none of them I could recommend because the manufacturer will likely tank before the end of the year. And if you want a real firewall you still have to spend a mighty $350 for a SonicWall. I had been living in bliss A too common problem within the IETF. Maybe it would be useful for some people here to actually get out in the real world. Given the current feature/functionaliy/price point reality of home routers, getting them to implement reasonable functionality as an IPv6 router seems like it will be a rather hard sell. :-( It's impossible to deliver because of supportability issues. Technically, the code could be embedded in a $40 box, nobody wants to do that though because it will take $300 to cover support calls. Michel. IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6 IETF IPv6 working group mailing list [EMAIL PROTECTED] Administrative Requests: https://www1.ietf.org/mailman/listinfo/ipv6
