Re: [hybi] Last Call: draft-ietf-hybi-thewebsocketprotocol-10.txt
In your letter dated Fri, 29 Jul 2011 04:38:12 +0200 (MEST) you wrote: Mark Andrews wrote: Martin Rex writes: Mark Andrews wrote: More correctly it is try the first address and if that doesn't connect in a short period (150...250ms) start a second connection to the next address while continuing with the first. If you have more that 2 address you do something similar for the next one Happy eyeballs means that a clients reaction to congestion is to perform an DoS attack, flood the network with additional connection requests and hammer the server with many additional half-open connections that will never actually get used. It is not a DoS attack. The client is almost certainly going to make those connection attempts anyway if the path is congested enough to cause the first connection attempt to fail. The only difference is the application gives up in 30 seconds rather than 60 or 90 seconds by doing the attempts serially. 150...250ms ?! For a satellite link you already have started 3 parallel connects in non-congested(!) situations. just some random IPv4 pings from my office (in germany) _without_congestion_: ping www.asus.com.tw300-380ms ping south-america.pool.ntp.org 280-370ms ping oceania.pool.ntp.org 340-420ms ping www.eff.org160-170ms ping www.ietf79.cn 330-450ms ping www.ietf76.jp 270-370ms So your approach is already hurting the network without congestion! There are two ways to do Happy Eyeballs. A simple immediate solution that works in most cases to use a fixed timeout value. In your case, you would have to increase that value to a bit higher than 400ms. If HE was invented a long time ago, then by now there could have been a parameter in DHCP to let the network control this parameter. The other way of doing HE is make it react to observed connect time. In that case if you are regularly connecting to sites that are more than 400ms away then the parameter will automatically increase to that value. The proposal is currently discussed in v6ops and everybody seems to be happy with it. So a critical voice may help shape the proposal a bit. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: On attending BoFs
2011/7/28 Barry Leiba barryle...@computer.org You're going to ask attendees to self-identify as tourists and leave the room? Today's tourists may well become tomorrow's document editors. ... Let's just assign large enough rooms to BoFs and newly-formed WGs so that the work can start in earnest. I agree. If people are there paying attention, I want them there. Lots of people don't know whether they're going to commit to doing work until the end of the BoF, after they've heard all the stuff about problem statement, work scope, and proposed work items. +1. So far I came only to one IETF meeting. At that time I attended (as a tourist, as you would call it) to a couple of BoF. My motivation for attending was that the BoF title sounded close enough to my interests and I wanted to know something more about it. I could not say if I was willing to be committed in contributing in the next-to-be WG by the title (and maybe a brief abstract) only. Keep also in mind that, although I participate as an individual, I have an employer and I am not entirely free to decide if contributing in some WG or not. (If you are curious: it turned out that one BoF was fairly orthogonal to my interests, while the other one was sufficiently close so that I subscribed to the WG ML and spread the word with few of my colleagues that are more interested in the matter). Riccardo ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re:
In your letter dated Thu, 28 Jul 2011 18:55:04 -0700 you wrote: On Jul 28, 2011 5:28 PM, Martin Rex m...@sap.com wrote: It would be so much easier if hosts on the public internet could use one single IPv6 address that contains both, the IPv6 network prefix and the IPv4 host address, and then let the network figure out whether the connect goes through as IPv4 or IPv6 (for IPv6 clients). In particular, if the remote address is encoded this way. If the host has to chose between an IPv6 or IPv4 destination address then the protocol is fixed. I think that would have been a much better use of thse bits then simply storing the ethernet address there. But anyhow, it should be possible to do that with a destination option with is then inspected by some middle box that makes a routing decision. But that would require a lot of changes to retrofit it in todays operating systems. This is largely (not entirely) achieved with nat64 / dns64. That would require the dns64 box to do destination selection. Possible, but maybe also tricky to keep a dns resolver informed about the current state of the network. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the IESG needs to review everything...
I don't have too much to say on whether the IESG is effective. Our standards production rate and the market uptake of same seems to speak for itself. I also don't have the numbers Dave is looking for either. However, I would like to contribute my own anecdotal experience, involving at least one draft from the person who kicked off this debate (not you Dave or Brian). I reviewed on behalf of the apps-area one of the drafts he wrote and found a serious concern, and reported it. He ignored my review at his peril, and then complained when he got slapped with a DISCUSS. I don't know whether the AD based his DISCUSS on my review or not, but clearly there was, at the very least, a substantial disagreement. What's particular egregious is that here we had a cross-area expert review process that identified a problem that could have been resolved without him wasting IESG time. Instead, we are all incompetent, and don't know what we're talking about, and the process is broken. It has not occurred to this guy that he might have made an error in judgment. In fact he made many. Eliot ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 28/Jul/11 18:34, t.petch wrote: The minor point is that e-mails have just got yet bigger. They are now 100-150% bigger than when first I started following the IETF According to Nielsen's Law, network connection speeds double every 21 months. DKIM is apparently using a quite reasonable fraction of that. But more importantly we have abolished the end-to-end principle. If I am going to benefit from improved security on e-mail, I want to from the originator to me, not some half-way house giving a spurious impression of accuracy. Most users don't want perfect accuracy into the mail system. Not only because of the burden of maintaining keys, but also for concerns about freedom of speech, right to anonymity, possibility to play jokes, and the like. MSA endorsement allows all that, and still delivers some responsibility by leveraging the trust between authors and their mailbox providers. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Jul 28, 2011, at 11:41 PM, Michel Py wrote: IMHO, the only valid stats we can gather are either from a large content provider (which is why Lorenzo's numbers are so interesting) or from a large eyeball ISP. Cisco, Juniper, Apple, the academia, the IETF, etc are NOT valid places to collect data. I think all of the numbers are interesting, but the numbers shouldn't be separated from the conditions under which they were collected. It's reasonable to say Google is now seeing X% 6to4 traffic or My native v6 enterprise network is seeing Y% 6to4 traffic. What's not reasonable is to say that observations under one set of conditions are indicative of the whole network. Even observations made at several points by a large transit carrier might not be indicative of conditions on the other side of the world. It's also dubious to extrapolate from a few data points and call it a long term trend, because we're in a very early phase of v6 deployment (and v4 exhaustion), and there are many factors which could have a large but unpredictable influence on future use of IPv4 vs IPv6. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Jul 29, 2011, at 1:14 AM, Michel Py wrote: Joel Jaeggli wrote: 6rd is global unicast... there's nothing to discriminate it from any other native range. No. there is nothing in the current classification algorithm to discriminate from any other native range. But it's not native, as it has, among other things, the same reliance on IPv4 and the same MTU issues than 6to4 as the core mechanism is based on 6to4 tunneling, or encapsulation, or whatever else you want to call it. Well, maybe. One hopes that if an ISP chooses 6rd as a means to roll out v6 service to its customers, they've considered MTU issues and dealt with them as much as is feasible. It's much easier to do that for TCP traffic than for say UDP. All of these transition mechanisms introduce unpleasant and undesirable corner cases. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 7/28/2011 12:34 PM, t.petch wrote: But more importantly we have abolished the end-to-end principle. If I am going to benefit from improved security on e-mail, I want to from the originator to me, not some half-way house giving a spurious impression of accuracy. The end-to-end principle is often cited as an argument for any mechanism that is not the end-nodes. I'm waiting for the day it is applied to a demand that every user's computer, tablet and smartphone be directly connected to every other one, so that we no longer suffer IP relaying by routers, since their presence violates the end-to-end principle. With respect to DKIM, the problem with your concern is that you appear to misunderstand the function DKIM is performing. Since that's well-documented, I suggest you review how it works and what it means. In case that's too much effort, I suggest you take a look at: The Truth About DKIM http://bbiw.net/presentations/DKIM%20Truth.pdf specifically slide 4. The left hand side includes a short list of common mis-assumptions about DKIM's meaning, along with the one correct one. See whether you know which is the right one. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On Jul 29, 2011, at 6:18 AM, Dave CROCKER wrote: On 7/28/2011 12:34 PM, t.petch wrote: But more importantly we have abolished the end-to-end principle. If I am going to benefit from improved security on e-mail, I want to from the originator to me, not some half-way house giving a spurious impression of accuracy. The end-to-end principle is often cited as an argument for any mechanism that is not the end-nodes. I'm waiting for the day it is applied to a demand that every user's computer, tablet and smartphone be directly connected to every other one, so that we no longer suffer IP relaying by routers, since their presence violates the end-to-end principle. With respect to DKIM, the problem with your concern is that you appear to misunderstand the function DKIM is performing. Since that's well-documented, I suggest you review how it works and what it means. In case that's too much effort, I suggest you take a look at: The Truth About DKIM http://bbiw.net/presentations/DKIM%20Truth.pdf specifically slide 4. The left hand side includes a short list of common mis-assumptions about DKIM's meaning, along with the one correct one. See whether you know which is the right one. DKIM is not my favorite protocol. But it's not like there haven't been several efforts to define e2e authentication for email, including PEM, S/MIME, PGPMIME, and several others whose acronyms I'm too lazy to look up at the moment. Implementations of email clients that support e2e authentication are not hard to find, and some people do use them. But they've never been widely used. I don't blame the DKIM proponents for wanting to try a different deployment model, for a different use case. Keith ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
Michel, Joel Jaeggli wrote: 6rd is global unicast... there's nothing to discriminate it from any other native range. No. there is nothing in the current classification algorithm to discriminate from any other native range. But it's not native, as it has, among other things, the same reliance on IPv4 and the same MTU issues than 6to4 as the core mechanism is based on 6to4 tunneling, or encapsulation, or whatever else you want to call it. the 6rd MTU is under control of a single provider. the transport layer MTU can be set large enough to provide a 1500 byte MTU for IPv6. I presume you are arguing that MPLS (6PE) is not native either? cheers, Ole ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
agree but if you're trying to discriminate it by: This graph shows the daily unique queried reverse addresses by type. you can't. On Jul 29, 2011, at 1:14 AM, Michel Py wrote: Joel Jaeggli wrote: 6rd is global unicast... there's nothing to discriminate it from any other native range. No. there is nothing in the current classification algorithm to discriminate from any other native range. But it's not native, as it has, among other things, the same reliance on IPv4 and the same MTU issues than 6to4 as the core mechanism is based on 6to4 tunneling, or encapsulation, or whatever else you want to call it. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
oh boy... On 7/29/2011 6:36 AM, Keith Moore wrote: The Truth About DKIM http://bbiw.net/presentations/DKIM%20Truth.pdf specifically slide 4. The left hand side includes a short list of common mis-assumptions about DKIM's meaning, along with the one correct one. See whether you know which is the right one. DKIM is not my favorite protocol. But it's not like there haven't been several efforts to define e2e authentication for email, including PEM, S/MIME, PGPMIME, and several others whose acronyms I'm too lazy to look up at Since DKIM's semantic is fundamentally different from PEM, S/MIME and OpenPGP, I don't know why you cited them. For the typically uses of 'authentication' with respect to email, DKIM does not do authentication. Please re-read the preceding sentence 10 times. I really do suggest folks who have comments about DKIM first put some effort understanding what it does and does not do. We've made it easy. There are multiple documents discussion what it is and how to use it. I don't blame the DKIM proponents for wanting to try a different deployment model, for a different use case. DKIM is a different semantic, not just a different implementation. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On 29/07/2011, at 8:03 AM, Joel Jaeggli wrote: agree but if you're trying to discriminate it by: This graph shows the daily unique queried reverse addresses by type. you can't. Very true Joel. I did, for a while, pattern match the 6rd prefix from Free.FR's declared ranges in RIPE whois but it was pointed out to me that dealing with one ISP like this skews things. After all, other ISps also deploy 6rd, and Comcast do some kind of related work. I can put in a 6rd line, if thats what people *want* -G ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the IESG needs to review everything...
On 7/28/2011 7:54 PM, SM wrote: At 04:24 PM 7/28/2011, Brian E Carpenter wrote: Er, no. By definition, it's correct until we update RFC 2026. Quoting the Status of this memo section from RFC 6305, RFC 6308, RFC 6319 and RFC 6331 which are Informational and from the IETF Stream: This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. SM is correctly detecting some problematic inconsistencies in our language. We do not use adequately clear and distinctive language to distinguish between: * IETF consensus used to approve standards/bcp, * IETF consensus used to approve other documents through the IETF * Independent Informational and Experimental submissions that are published /without/ IETF approval. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4 damages the Internet (was Re:
Philip Homburg wrote: I think that would have been a much better use of thse bits then simply storing the ethernet address there. IPv6 address was (when it was SIP) and should be 8B, but extended to be 16B to store ethernet address with wrong reasoning of RFC1715 only to make IPv6 inoperational. At that time, it was 10B+6B, but as I pointed it out that IEEE1394 MAC is 8B long, it became 8B+8B. But anyhow, it should be possible to do that with a destination option with is then inspected by some middle box that makes a routing decision. But that would require a lot of changes to retrofit it in todays operating systems. That's no different from legacy NAT to violate the end to end principle. For example, just as legacy NAT, transport check sum depends on actually used address family and address. Thus, transport check sum must be recalculated by the middle box which changes address family. That would require the dns64 box to do destination selection. Possible, but maybe also tricky to keep a dns resolver informed about the current state of the network. That's guaranteed to be impossible by the end to end argument: The function in question can completely and correctly be implemented only with the knowledge and help of the application standing at the end points of the communication system. Therefore, providing that questioned function as a feature of the communication system itself is not possible. Destination address selection is the function in question and complete and correct implementation by middle boxes is just impossible. The only approach for the address selection function is to do it at the end systems using knowledge and help of the end systems, which requires end systems have knowledge on default free global routing tables. Masataka Ohta ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Why the IESG needs to review everything...
SM s...@resistor.net wrote: At 04:24 PM 7/28/2011, Brian E Carpenter wrote: On 2011-07-28 18:45, SM wrote: At 04:13 PM 7/27/2011, Martin Rex wrote: According to rfc2026: 4.2.2 Informational An Informational specification is published for the general information of the Internet community, and does not represent an Internet community consensus or recommendation. [...] The above is incorrect. Er, no. By definition, it's correct until we update RFC 2026. Quoting the Status of this memo section from RFC 6305, RFC 6308, RFC 6319 and RFC 6331 which are Informational and from the IETF Stream: This document is a product of the Internet Engineering Task Force (IETF). It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). Although it is, by definition, correct until RFC 2026 is updated, RFC 5741 is currently being used for the boilerplate in RFCs. This actually caught me by surprise, but it is accurate. RFC 5741, status Informational, specifies boilerplate for Informational RFCs. The operative text is in Section 3.2.2: The text that follows is stream dependent -- these are suggested initial values and may be updated by stream definition document updates. IETF Stream: This document is a product of the Internet Engineering Task Force (IETF). If there has been an IETF consensus call per IETF process, an additional sentence should be added: It represents the consensus of the IETF community. It has received public review and has been approved for publication by the Internet Engineering Steering Group (IESG). If there has not been such a consensus call, then this simply reads: It has been approved for publication by the Internet Engineering Steering Group (IESG). Frankly, I am not happy with this. An Informational track document has effectively over-ruled RFC 2026, a BCP status document -- and gone on to say that RFC 2026 may be further overruled by stream definition document updates (whatever that may mean). I _much_ prefer the RFC 2026 definition of Informational (and I don't believe they should require extensive IESG scrutiny). (BTW, I wonder to what extent our current repetition of the argument about the IESG filing too many DISCUSSes is in reaction to their scrutiny of Informational track documents.) I don't have time today to research to what extent Informational track RFCs have actually received an IETF consensus call per IETF process. Perhaps somebody else would like to respond on that... -- John Leslie j...@jlc.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4v2 (as in ripv2)?
Le 27 juil. 2011 à 17:29, Michel Py a écrit : ... Fred Baker wrote: Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. Indeed, and it also is a transition mechanism for the very same reasons that 6to4 is. Keith Moore wrote: only if you're confused about the use cases for each. Even if there are different use cases indeed (as you explained it very well yourself) you can't deny that 6rd is 6to4-bis. Oh, yes indeed, on can! (Depending, of course on what you mean with 6to4-bis, but no one can be sure what you mean). - 6to4 delivers native IPv6 prefixes to customer sites, which 6to4 doesn't. - 6to4 has known operational problems, not 6rd. The difference is in who configures/manages it, not how it works; See above. the 6rd code base is a superset of the 6to4. Although it has been convenient to deploy 6rd starting with existing 6to4 code, one can write 6rd code that doesn't work for 6to4. The difference is more a matter of network design than core protocol. It is a matter of clean IPv6 service, transparent to users, vs service for experts who know what they are doing. RD Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-6to4-to-historic (yet again)
Le 27 juil. 2011 à 08:10, Tore Anderson a écrit : * Ronald Bonica After some discussion, the IESG is attempting to determine whether there is IETF consensus to do the following: - add a new section to draft-ietf-v6ops-6to4-to-historic - publish draft-ietf-v6ops-6to4-to-historic as INFORMATIONAL draft-ietf-v6ops-6to4-to-historic will obsolete RFCs 3056 and 3068 and convert their status to HISTORIC. It will also contain a new section describing what it means for RFCs 3056 and 3068 to be classified as HISTORIC. The new section will say that: - 6-to-4 should not be configured by default on any implementation (hosts, cpe routers, other) - vendors will decide whether/when 6-to-4 will be removed from implementations. Likewise, operators will decide whether/when 6-to-4 relays will be removed from their networks. The status of RFCs 3056 and 3068 should not be interpreted as a recommendation to remove 6-to-4 at any particular time. draft-ietf-v6ops-6to4-to-historic will not update RFC 2026. While it clarifies the meaning of HISTORIC in this particular case, it does not set a precedent for any future case. I support this approach. Suggestion to make the two RFC Experimental has been made, and received some support. I haven't seen objections tho this compromise approach. Are there some? RD Best regards, -- Tore Anderson Redpill Linpro AS - http://www.redpill-linpro.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-gundavelli-v6ops-pmipv6-address-reservations-00.txt (Reserved IPv6 Interface Identifier for Proxy Mobile IPv6) to Informational RFC
I do think that pmipv6 has some issues about how it does mag-mn interface. One solution to one issue may be this reserved iid. Is this updating the stds track rfc5453 reserved iids? Does this mean that pmipv6 spec is to be updated? (eg say that its RAs are src'ed with an address formed from this iid?) I think that even though an iid is reserved for mag, the mn must still resolve (ns/na) the addresses ip-mac hence the utility of the uniqueness of a fe80::iid throughout the pmip domain may be questionable. I think it should be stated whether this is for shared links (wifi) or ptp links (3g) this latter doesn't have many problems w/ pmip. Other solutions for this mn-mag pmip problem are possible and implementation exists. Alex Le 29/07/2011 14:14, The IESG a écrit : The IESG has received a request from an individual submitter to consider the following document: - 'Reserved IPv6 Interface Identifier for Proxy Mobile IPv6' draft-gundavelli-v6ops-pmipv6-address-reservations-00.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Proxy Mobile IPv6 [RFC5213] requires all the mobile access gateways to use a fixed link-local and link-layer addresses on any of its access links that it shares with the mobile nodes. This was intended to ensure a mobile node does not detect any change with respect to its layer-3 attachment even after it roams from one mobile access gateway to another. In the absence of any reserved addresses for this use, it requires coordination across vendors and the manual configuration of these addresses on all the mobility elements in a Proxy Mobile IPv6 domain. This document attempts to simplify this operational requirement by making reservation for special addresses that can be used for this purpose. The file can be obtained via http://datatracker.ietf.org/doc/draft-gundavelli-v6ops-pmipv6-address-reservations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-gundavelli-v6ops-pmipv6-address-reservations/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list ietf-annou...@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-housley-two-maturity-levels
I have read version 08 and support this proposal. - Chris --On July 27, 2011 17:46:22 -0400 Jari Arkko jari.ar...@piuha.net wrote: Here's the link: http://tools.ietf.org/html/draft-housley-two-maturity-levels ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Make 6to4 Experimental (was6to4v2 (as in ripv2)?)
+1 IMHO, it does make a lot of sense. (I made a similar comment before reading this one)-. Regards, RD Le 27 juil. 2011 à 18:14, Noel Chiappa a écrit : From: Philip Homburg pch-v6...@u-1.phicoh.com I think it would be quite weird to keep 6to4 at standards track just to prevent some vendors from dropping 6to4 support. There have been suggestions that it might be more appropriate to reclassify it as Experimental, and I think that makes a lot of sense - as you correctly (IMO) point out, due to its issues 6to4 is not really appropriate for standards track (at least, in its current form). Noel ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
Original Message - From: Dave CROCKER d...@dcrocker.net To: ietf@ietf.org Sent: Friday, July 29, 2011 12:18 PM On 7/28/2011 12:34 PM, t.petch wrote: But more importantly we have abolished the end-to-end principle. If I am going to benefit from improved security on e-mail, I want to from the originator to me, not some half-way house giving a spurious impression of accuracy. The end-to-end principle is often cited as an argument for any mechanism that is not the end-nodes. I'm waiting for the day it is applied to a demand that every user's computer, tablet and smartphone be directly connected to every other one, so that we no longer suffer IP relaying by routers, since their presence violates the end-to-end principle. With respect to DKIM, the problem with your concern is that you appear to misunderstand the function DKIM is performing. Since that's well-documented, I suggest you review how it works and what it means. In case that's too much effort, I suggest you take a look at: The Truth About DKIM http://bbiw.net/presentations/DKIM%20Truth.pdf specifically slide 4. The left hand side includes a short list of common mis-assumptions about DKIM's meaning, along with the one correct one. See whether you know which is the right one. Yes, I know enough about DKIM to identify the right one. I think that it is an error for the IETF to add DKIM signatures. They do indeed tell me which intermediary has sent me the mail, but does nothing for the 'spam' that the intermediary accepted in the first place (albeit there being little of that on the IETF managed lists). And has already been pointed out, the mailing list damages any DKIM signature that is already there. I find it interesting that John Levine lists 'DKIM doesn't work with mailing lists' as one of this three myths. I think that that depends on the interpretation of the word 'work'. I would say that DKIM in this context, of a mailing list, gives a spurious impression of increased security that we would be better off without. It functions, but does not work, in that it tells me nothing about the true origin of the communication. Tom Petch d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
Le 28 juil. 2011 à 08:07, Michel Py a écrit : James, If I remember correctly, you mentioned a bit ago that your job required you had native IPv6 at home. Question: Does an ISP providing you IPv6 out of the CPE box (meaning, without any software other than dual-stack on the hosts) qualify as native IPv6 if, behind the scenes, they use a tunnel broker, or 6rd? Facts are AFAIK that: - Tunnel brokers need host cooperation. They can't be used behind the scene by ISP's. - 6rd can indeed be used behind the scene by ISP's, without users making the difference with native IPv6 routing in ISP networks. This has been proven on a large scale over 3.5 years. Regards, RD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: DKIM Signatures now being applied to IETF Email
-Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of t.petch Sent: Friday, July 29, 2011 5:22 AM To: dcroc...@bbiw.net; ietf Subject: Re: DKIM Signatures now being applied to IETF Email It functions, but does not work, in that it tells me nothing about the true origin of the communication. ...but that's not what it's supposed to tell you. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
On Jul 29, 2011, at 9:39 AM, Rémi Després wrote: Le 28 juil. 2011 à 08:07, Michel Py a écrit : James, If I remember correctly, you mentioned a bit ago that your job required you had native IPv6 at home. Question: Does an ISP providing you IPv6 out of the CPE box (meaning, without any software other than dual-stack on the hosts) qualify as native IPv6 if, behind the scenes, they use a tunnel broker, or 6rd? Facts are AFAIK that: - Tunnel brokers need host cooperation. They can't be used behind the scene by ISP's. - 6rd can indeed be used behind the scene by ISP's, without users making the difference with native IPv6 routing in ISP networks. This has been proven on a large scale over 3.5 years. I would suspect that there's nothing that prevents an isp running it's own tunnel broker and a compliant cpe from automating that process in much the same way that 6rd in free required control over the firmware. the business case for doing so seems like an exercise for the reader. Regards, RD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
Le 29 juil. 2011 à 15:51, Joel Jaeggli a écrit : On Jul 29, 2011, at 9:39 AM, Rémi Després wrote: Le 28 juil. 2011 à 08:07, Michel Py a écrit : James, If I remember correctly, you mentioned a bit ago that your job required you had native IPv6 at home. Question: Does an ISP providing you IPv6 out of the CPE box (meaning, without any software other than dual-stack on the hosts) qualify as native IPv6 if, behind the scenes, they use a tunnel broker, or 6rd? Facts are AFAIK that: - Tunnel brokers need host cooperation. They can't be used behind the scene by ISP's. - 6rd can indeed be used behind the scene by ISP's, without users making the difference with native IPv6 routing in ISP networks. This has been proven on a large scale over 3.5 years. I would suspect that there's nothing that prevents an isp running it's own tunnel broker and a compliant cpe from automating that process in much the same way that 6rd in free required control over the firmware. Fair enough, that's a technical possibility. the business case for doing so seems like an exercise for the reader. Exactly, I doubt any ISP would do that, in view of the compared simplicity of 6rd. If that would be used, customers would have native prefixes for which they ignore that ISP-network traversal has bee tunneled. Regards, RD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4v2 (as in ripv2)?
Rémi Després despres.r...@laposte.net wrote: Le 27 juil. 2011 à 17:29, Michel Py a écrit : ... Fred Baker wrote: Actually, I think one could argue pretty effectively that 6rd is 6to4-bis. Indeed, and it also is a transition mechanism for the very same reasons that 6to4 is. Keith Moore wrote: only if you're confused about the use cases for each. Even if there are different use cases indeed (as you explained it very well yourself) you can't deny that 6rd is 6to4-bis. Oh, yes indeed, on can! (Depending, of course on what you mean with 6to4-bis, but no one can be sure what you mean). - 6to4 delivers native IPv6 prefixes to customer sites, which 6to4 doesn't. - 6to4 has known operational problems, not 6rd. In a sense, 6rd has all of the problems that 6to4 does. The difference is that 6to4 is deployed independent of network operators and often without their involvement, and 6rd (when deployed) is deployed by network operators on their own networks. So 6to4 tries to work over networks that might or might not be unsuitable for it, or even hostile to it. By contrast, if an operator's network isn't a good fit for 6rd, they simply don't use it. And presumably an operator choosing to use 6rd won't try to DoS it... Again: there are valid use cases for 6to4. But almost any kind of provider managed service (except one that NATs traffic) is almost certainly better. Keith -- Sent from my Android tablet with K-9 Mail. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-08.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Hi, I generally support this proposal, but have some questions on Section 2.3, Transition to a Standards Track with Two Maturity Levels. I am both an author of several Draft Standards and have chaired working groups that have produced them. Any protocol or service that is currently at the abandoned Draft Standard maturity level will retain that classification, absent explicit actions. Two possible actions are available: (1) A Draft Standard may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. What is the process for this? Is the IESG going to review all Draft Standards. Should authors and/or working groups propose a change of status as defined in the document? Something else? Most draft standards very likely meet most of the requirements listed in the document for Internet Standard. (2) At any time after two years from the approval of this document as a BCP, the IESG may choose to reclassify any Draft Standard document as Proposed Standard. I think this is unfair to the people who have done considerable work to get a document to Draft Standard. I hope that the IESG would only do this after giving a lot of notice to the authors, appropriate working groups, and the IETF community to give them the opportunity to request advancement to Internet Standard. I think this Section of the document needs to provide additional detail on how this should work. Regards, Bob ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
Le 29 juil. 2011 à 14:16, George Michaelson a écrit : On 29/07/2011, at 8:03 AM, Joel Jaeggli wrote: agree but if you're trying to discriminate it by: This graph shows the daily unique queried reverse addresses by type. you can't. Very true Joel. I did, for a while, pattern match the 6rd prefix from Free.FR's declared ranges in RIPE whois but it was pointed out to me that dealing with one ISP like this skews things. After all, other ISps also deploy 6rd, and Comcast do some kind of related work. I can put in a 6rd line, if thats what people *want* I suppose that te proportion of native IPv6 traffic due to Free will quickly decrease as IPv6 gets really deployed by others. (This proportion was reported to still be slightly above 50% a few months ago, but this was before the World IPv6 day and various other events.) Yes, that would be nice to have this proportion for some time. Thanks, RD -G ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
I think that it is an error for the IETF to add DKIM signatures. They do indeed tell me which intermediary has sent me the mail, but does nothing for the 'spam' that the intermediary accepted in the first place (albeit there being little of that on the IETF managed lists). ... It functions, but does not work, in that it tells me nothing about the true origin of the communication. What it does is allow you to assure yourself that the message was, indeed, from an IETF mailing list (well, from an IETF email server), and that it wasn't that someone tried to spoof that. That, in turn, allows you to confidently increase your trust that the message is not spam in proportion to your confidence in the IETF's spam-filtering capabilities. Some of us, at least, find that useful. Some of us might even completely white-list IETF-signed messages. You can make your own choice on that. Barry, DKIM WG chair ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-08.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
Bob: I generally support this proposal, but have some questions on Section 2.3, Transition to a Standards Track with Two Maturity Levels. I am both an author of several Draft Standards and have chaired working groups that have produced them. Any protocol or service that is currently at the abandoned Draft Standard maturity level will retain that classification, absent explicit actions. Two possible actions are available: (1) A Draft Standard may be reclassified as an Internet Standard as soon as the criteria in Section 2.2 are satisfied. What is the process for this? Is the IESG going to review all Draft Standards. Should authors and/or working groups propose a change of status as defined in the document? Something else? Most draft standards very likely meet most of the requirements listed in the document for Internet Standard. Section 2.2 is pretty clear I think. A request to reclassification must be sent to the IESG. ... The request for reclassification is sent to the IESG along with an explanation of how the criteria have been met. The criteria are: (1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience. (2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. (3) There are no unused features in the specification that greatly increase implementation complexity. (4) If patented or otherwise controlled technology is required for implementation, the implementations demonstrate at least two separate and successful uses of the licensing process. (2) At any time after two years from the approval of this document as a BCP, the IESG may choose to reclassify any Draft Standard document as Proposed Standard. I think this is unfair to the people who have done considerable work to get a document to Draft Standard. I hope that the IESG would only do this after giving a lot of notice to the authors, appropriate working groups, and the IETF community to give them the opportunity to request advancement to Internet Standard. This was added after the discussion that Draft Standards could linger for a very long time. Some people said that would not be a problem, and other people said it would be harmful. I conclude that no one knows, so we should include the powers necessary to resolve the problems if they emerge. If they do not emerge, there is no requirement that the IESG do anything. I think this Section of the document needs to provide additional detail on how this should work. I do not think we should add speculation about the potential problems to this document. Russ ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 6to4v2 (as in ripv2)?
Rémi Després wrote: - 6to4 delivers native IPv6 prefixes to customer sites, which 6to4 doesn't. That is playing with words. In that case, any router that delivers native IPv6 to the hosts (by having the tunnel software on the router, not on the hosts) can be called a native solution. This is just flat out WRONG. ANY solution that needs IPv4 to transport IPv6 is NOT native IPv6, and regardless of who states it and their great contributions, it will remain the same. Some please stop calling things what they are not; a native IPv6 solution is one that works when IPv4 has been removed, anything else is called a transition mechanism. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: On attending BoFs
I seem to recall having sometimes seen the chair reserve the front of the seating for people who claim to have read the drafts. d/ On 7/29/2011 12:12 AM, Eric Burger wrote: Just for the record: we want big rooms! On Jul 28, 2011, at 10:01 PM, Scott Brim wrote: And do you really only want people in the room who already know the issues and have decided to be for or against it? If you already have so many of them, you don't need a BOF at all, just take a hum and be done. The main purpose of a BOF is to present. Information to the community so they can decide if the IETF should adopt the work. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
I have updated the graph to include 6rd, based on my understanding that the prefixes of the form 2a01:e3xx: are your 6rd space. There is *other* FreeNet space, which appears to do things, but I sense its not part of the 6rd deployment since the numberforms in the lower /64 appear to be infrastructure assignment, not classic customer space forms. Please let me know if I have this wrong. You will notice that this count places Free/6rd at a far lower relative % of unique DNS than the measures of traffic and sources people discussing here. I think this bears thinking about. http://labs.apnic.net/dns-measurement/ -George ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4v2 (as in ripv2)?
Le 29 juil. 2011 à 18:21, Michel Py a écrit : Rémi Després wrote: - 6to4 delivers native IPv6 prefixes to customer sites, which 6to4 doesn't. That is playing with words. In that case, any router that delivers native IPv6 to the hosts (by having the tunnel software on the router, not on the hosts) can be called a native solution. This is just flat out WRONG. ANY solution that needs IPv4 to transport IPv6 is NOT native IPv6, and regardless of who states it and their great contributions, it will remain the same. Some please stop calling things what they are not; a native IPv6 solution is one that works when IPv4 has been removed, anything else is called a transition mechanism. We have, it seems, a different understanding of the situation. The distinction to be made, and which I make, is between - native addresses vs well-known-prefix addresses (the former start with an ISP allocated prefix, the latter, e.g. those of 6to4 and Teredo, have a routing problem in the Internet backbone) - native IPv6 routing (IPv6-only or dual stack) vs IPv4-only routing 6rd is designed to offer native IPv6 prefixes across IPv4-only routing domains. Regards, RD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-08.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
On 7/29/2011 11:13 AM, Russ Housley wrote: (2) At any time after two years from the approval of this document as a BCP, the IESG may choose to reclassify any Draft Standard document as Proposed Standard. I think this is unfair to the people who have done considerable work to get a document to Draft Standard. I hope that the IESG would only do this after giving a lot of notice to the authors, appropriate working groups, and the IETF community to give them the opportunity to request advancement to Internet Standard. This was added after the discussion that Draft Standards could linger for a very long time. Some people said that would not be a problem, and other people said it would be harmful. I conclude that no one knows, so we should include the powers necessary to resolve the problems if they emerge. If they do not emerge, there is no requirement that the IESG do anything. If a document no longer has anyone watching it, there's a reasonable concern that it no longer has much constituency. In that case, it's better to treat it as immature rather than mature. I think this Section of the document needs to provide additional detail on how this should work. I do not think we should add speculation about the potential problems to this document. +1 d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
On 7/29/2011 11:02 AM, Barry Leiba wrote: What it does is allow you to assure yourself that the message was, indeed, from an IETF mailing list (well, from an IETF email server), and that it wasn't that someone tried to spoof that. That, in turn, allows you to confidently increase your trust that the message is not spam in proportion to your confidence in the IETF's spam-filtering capabilities. Some of us, at least, find that useful. Some of us might even completely white-list IETF-signed messages. You can make your own choice on that. An intermediary that signs messages and has a reputation for carrying spam in its stream will have an appropriate reputation. One that signs messages and has a clean message stream will also have an appropriate reputation. The differences between the two will produce very different disposition at the delivery site. All of which is cleaner and safer than is possible today, except with constrained uses of previous-hop IP(v4) addresses. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 6to4v2 (as in ripv2)?
Rémi Després wrote: 6rd is designed to offer native IPv6 prefixes across IPv4-only routing domains. There is a word for that: oxymoron. In French: oxymore. If it stops working when IPv4 is broken, it is not native. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 6to4v2 (as in ripv2)?
6rd addresses a different problem than 6to4. 6to4 is a global solution, that relies on pretty much every native IPv6 provider deploying 6to4 relays. If these relays were really well deployed and reliable, 6to4 would allow any router with a native IPv4 address to provide IPv6 connectivity to its local users. That is, 6to4 relies on the kindness of strangers and allows uncoordinated deployments by end-users. 6rd is a local solution, that can be used by providers to easily deploy IPv6 tunnels over their existing IPv4 infrastructure. The provider controls the IPv6 prefix, which effectively defines a specific 6rd subnet. The provider also controls the deployment of relays between the 6rd subnet and the native Internet. There is no need to rely on the kindness of strangers. In a sense, 6rd is very similar to a tunnel broker deployment, with a key improvement and an important limitation. The key improvement is the ability for 6rd routers in the same domain to send traffic directly at each other. Local traffic stays local, does not need to be relayed by the tunnel servers or the 6rd relays. The key limitation is that 6rd assumes direct IPv4 connectivity between the participating 6rd routers, i.e. no NAT. 6rd is a very good solution for its intended usage, rapid deployment of IPv6 by IPv4 providers. But 6rd is not a replacement for the global, uncoordinated 6to4 deployment. Hosts that really need this kind of uncoordinated global solution will have to rely on Teredo if they cannot use 6to4. Whether that's a good thing is clearly a matter of debate. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Michel Py Sent: Friday, July 29, 2011 11:38 AM To: Rémi Després Cc: ietf@ietf.org; Keith Moore Subject: RE: 6to4v2 (as in ripv2)? Rémi Després wrote: 6rd is designed to offer native IPv6 prefixes across IPv4-only routing domains. There is a word for that: oxymoron. In French: oxymore. If it stops working when IPv4 is broken, it is not native. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-housley-two-maturity-levels-08.txt (Reducing the Standards Track to Two Maturity Levels) to BCP
At 07:02 PM 7/27/2011, The IESG wrote: The IESG has received a request from an individual submitter to consider the following document: - 'Reducing the Standards Track to Two Maturity Levels' draft-housley-two-maturity-levels-08.txt as a BCP The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the ietf@ietf.org mailing lists by 2011-08-24. Exceptionally, comments may be From Section 2.1: no existing published requirements are relaxed. Are these published requirements BCPs? From Section 2.2: 'This maturity level is a merger of Draft Standard and Standard as specified in RFC 2026 [1]. The chosen name avoids confusion between Draft Standard and Internet-Draft.' Shouldn't that be Internet Standard instead of Standard? The request for reclassification is sent to the IESG along with an explanation of how the criteria have been met. The criteria are: (1) There are at least two independent interoperating implementations with widespread deployment and successful operational experience. (2) There are no errata against the specification that would cause a new implementation to fail to interoperate with deployed ones. (3) There are no unused features in the specification that greatly increase implementation complexity. The document that has been the subject of innumerable messages highlights how difficult it can be to reclassify a RFC. Moreover, it amplified the divide between application folks and operators. The IESG could have used the review clause from RFC 2026 and: (i) requested an implementation report from the people in favor of the proposed standard; and (ii) a statement about deployment to determine whether there are operational issues that have to be addressed. I don't know whether application folks and operators agree that cross-area requires mutual understanding. The creation of interoperable protocol implementations requires clear specifications. Interoperability does not mean that the protocol would not have unintended effects on the network. That is where operational experience comes in. It can serve as valuable input to improve a specification. For what it is worth, there approximately 75 implementation reports have been submitted since 1996. A two-step maturity level folds the two different classes of issues into one. Quoting RFC 5657, which this draft unfortunately does not reference: Moving documents along the standards track can be an important signal to the user and implementor communities, and the process of submitting a standard for advancement can help improve that standard or the quality of implementations that participate. During a discussion on another mailing list, it has been mentioned that such an effort has a cost. Lumping all the issues together can only increase that cost. Strangely, this draft argues for measuring interoperability through widespread deployment of multiple implementations from different code bases. It will be more difficult to remove features once implementations are widely deployed. Keeping the feature fight within the Draft Standard discussion can reduce the level of controversy at the last step. As a side note, it would be less costly if feature evaluation was based on implementations instead of what people would like to keep (only one implementation of a feature). Once a Proposed Standard is published, it is expected that people will go and write code, if they have not done so yet, and evaluate whether their implementation can interoperate with other implementations. I don't see anything in this draft that encourages that. In the RFC 5000 range, there are 7 Internet Standards, 13 Draft Standards and 537 Proposed Standards. One of the arguments for this draft is that it reduces the number of IESG evaluations, and other review cycles, from three to two. Basically, this draft is to adjust the environment so that the IESG can review everything. It does not reduce the barrier of intended proposed standards to the RFC 2026 level. It does not offer any incentive to advance document along the Standards Track. I unfortunately cannot support this draft. Regards, -sm ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: 6to4v2 (as in ripv2)?
In your letter dated Fri, 29 Jul 2011 11:38:16 -0700 you wrote: R?mi Despr?s wrote: 6rd is designed to offer native IPv6 prefixes across IPv4-only routing domains. There is a word for that: oxymoron. In French: oxymore. If it stops working when IPv4 is broken, it is not native. Could you please elaborate why expect the internal IPv4 network of an ISP to break while they are using it for 6rd? It there some sort of built-in self-destruct mechanism somewhere? ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
RE: 6to4v2 (as in ripv2)?
Christian, -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Christian Huitema Sent: Friday, July 29, 2011 12:17 PM To: Michel Py; Rémi Després Cc: ietf@ietf.org; Keith Moore Subject: RE: 6to4v2 (as in ripv2)? 6rd addresses a different problem than 6to4. 6to4 is a global solution, that relies on pretty much every native IPv6 provider deploying 6to4 relays. If these relays were really well deployed and reliable, 6to4 would allow any router with a native IPv4 address to provide IPv6 connectivity to its local users. That is, 6to4 relies on the kindness of strangers and allows uncoordinated deployments by end-users. 6rd is a local solution, that can be used by providers to easily deploy IPv6 tunnels over their existing IPv4 infrastructure. The provider controls the IPv6 prefix, which effectively defines a specific 6rd subnet. The provider also controls the deployment of relays between the 6rd subnet and the native Internet. There is no need to rely on the kindness of strangers. I think this is well said. Another way of saying the same thing is that 6to4 is an inter-site solution while 6rd is an intra-site solution when considering the provider network as a site. With extensions, ISATAP can also satisfy this provider network intra-site requirement (see draft-templin-isupdate) while enabling the desired IPv6 services for end-user sites. Thanks - Fred fred.l.temp...@boeing.com In a sense, 6rd is very similar to a tunnel broker deployment, with a key improvement and an important limitation. The key improvement is the ability for 6rd routers in the same domain to send traffic directly at each other. Local traffic stays local, does not need to be relayed by the tunnel servers or the 6rd relays. The key limitation is that 6rd assumes direct IPv4 connectivity between the participating 6rd routers, i.e. no NAT. 6rd is a very good solution for its intended usage, rapid deployment of IPv6 by IPv4 providers. But 6rd is not a replacement for the global, uncoordinated 6to4 deployment. Hosts that really need this kind of uncoordinated global solution will have to rely on Teredo if they cannot use 6to4. Whether that's a good thing is clearly a matter of debate. -Original Message- From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Michel Py Sent: Friday, July 29, 2011 11:38 AM To: Rémi Després Cc: ietf@ietf.org; Keith Moore Subject: RE: 6to4v2 (as in ripv2)? Rémi Després wrote: 6rd is designed to offer native IPv6 prefixes across IPv4-only routing domains. There is a word for that: oxymoron. In French: oxymore. If it stops working when IPv4 is broken, it is not native. Michel. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
In message 4e3127f1.2030...@unfix.org, Jeroen Massar writes: On 2011-07-28 01:36 , Mark Andrews wrote: [..] Is there *one* tunnel management protocol that they all support or does a cpe vendor have to implement multiple ones to reach them all? I'm pretty sure I know the answer to this question but I'd love to be proved wrong. There is no 'one' solution to the problems that they are solving. As such there tend to be a combo of: - static proto-41 tunnel - 6to4 - 6rd - TSP = dynamic NATted addresses - proto-41 + heartbeat + TIC = dynamic public addresses - AYIYA + TIC = dynamic NATted addresses I was more thinking about commonality with tunnel brokers. 6rd is not a replacement for 6to4 as it requires ISP involment or someone to create a registry of 3rd party 6rd providers along with associated parameters sets similar non anycast 6to4. static proto-41 tunnel is also not a viable replacement as it doesn't handle address reassignment at the CPE end. TSP conveys configurartion information inline with the UDP packets. TIC is solely for configuration information and does not do tunneling but can be used for all proto-41/heartbeat/AYIYA protocols (and for instance AVM chose to only do proto-41 + heartbeat as their devices always have public IPv4 IPs). Teredo is only for a single host thus is not useful for CPEs and thus not included in them. One of the advantages of 6to4 anycast is that it is just needs a check box to turn on and off. Everybody speaks the same thing. Except that it does not work behind a NAT and most people do sit behind a NAT. Next to that those anycasts are even rarer around the world and on top of that it is hard to figure out issues when they are there (although some people have tricks to apparently debug them, the anycast on both IPv4 and IPv6 requires one to contact a lot of folks). The big advantage over a known tunnel endpoint is the known behavior of that endpoint and the simple way of complaining when something is broken. And people fortunately do complain when stuff is broken, unfortunately not always with the proper details though, but I am to blame for not finishing that program up... Another advantage of 6to4 is it doesn't require manual intervention on renumber events. Manual tunnel don't pass muster. I guess you are one of the lucky people to get a public static IPv4 address prefix at home that never renumbers? Guess what, most of the world does not have that luxury, they get 1 dynamic address and for instance in Germany they get a disconnect/force-renumber every 24 hours (according to the ISPs because of 'accounting' reasons...) Do realize that when you have that public IPv4 address, when it changes you are renumbering your 2002:ipv4::/48 prefix everywhere. Fun... (I hope you also like asking 6to4.nro.net everytime to change your reverse) The tunnels above all have ISP-supplied prefixes and tend to be static (I think TSP anonymous tunnels rotate addresses, but the majority just keeps on returning the same static allocation, in the case of SixXS you really get a fixed address, much easier on the PoP side and we can do whois and store it in the relevant RIR registry) Another advantage of 6to4 is you don't have to register. For most of the tunnel brokers you have to register. I guess you also where able to anonymously sign up to your IPv4 ISP!? :) Especially that static IPv4 address must be wonderful to get that way. Note that Freenet6 offers 'anonymous' tunnels, thus that is just a TSP away. Something with the amounts of abuse made us (SixXS) require that we require valid address data. Next to that it is a RIPE requirement to register /48 prefixes. Other Tunnelbrokers just started blocking things like IRC and NNTP because there was too much abuse or traffic We kill off accounts of people when they abuse, google my name and you will find various people who where caught in the act and are quite mad that they can't have funny vhosts on IRC anymore and attract 500mbit DoSses and other such nonsense which are not the goal of providing IPv6. Also, the registration means that people can just type in their username/password (and optionally which tunnel they want to use out of the multiple tunnels they might have) in their CPE and the CPE then uses TIC or TSP to fetch this configuration and set it all up, and it will just work(tm). As a nice example see http://www.sixxs.net/wiki/images/FritzboxHowto.jpg and http://www.sixxs.net/wiki/Fritz!Box_7270 Next to that knowing where the user is and more importantly their endpoint allows one to select a proper PoP for that user close to their endpoint causing low latency and generally high throughput. With anycast you are just hoping that that all will work. Greets, Jeroen -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org
What is Native IPv6
Ole,
Ole Troan wrote:
I presume you are arguing that MPLS (6PE) is not native either?
That's a tough one.
What would make me say it is native is: MPLS is a L2/switching animal,
not a L3/routing one. In theory you can bind any L3 protocol such as
IPv4, IPv6, IPX, Appletalk, etc to it. So the MPLS interface is very
similar in some aspects to a real physical interface such as Ethernet or
HSSI. It reminds me of a frame-relay sub-interface in a past life.
What would make me say it is not native is: you can't remove IPv4 out of
the equation. Frame relay does not even know about which L3 protocols it
transports, while MPLS is kinda going the reverse way in the stack: it
uses L3 packets/datagrams to encapsulate and transport L2 frames.
Here's my take:
- You can have native IPv6 over Ethernet or HDLC or Sonet or any other
L2 technology.
- Saying you have native IPv6 over fiber or copper is incorrect; you
have native IPv6 over GigE over {singlemode|multimode} (*) fiber or you
have IPv6 over Ethernet over GigE over (*) copper (or other examples)
(*) insert the appropriate 802.x standard
- I like the idea of being native requiring the IPv6 to be bound to a L2
interface. The gray area with 6PE is that the interface is logical, not
physical.
- Native IPv6 over a 6to4 or a 6RD or any kind of L3-L3 tunnel is an
oxymoron.
In other words: native IPv6 means:
a) IPv6 has to be bound to a L2 interface.
b) That interface can NOT be a tunnel interface using another L3
protocol such as IPv4.
Up for grabs:
- c1) Is it acceptable to have a structural requirement to use IPv4
(which would mean 6PE is native) or c2) is it a requirement that the
entire infrastructure (in the case of 6RD, the ISP's infrastructure)
supports IPv6 (which would mean that 6PE is not native).
Food for thought:
- If c2) is chosen, I would consider rephrasing a) so it becomes IPv6
has to be bound to a PHYSICAL L2 interface. Rationale: besides 6PE, are
there any other gray area candidates?
- If one is in the business of writing an draft about what is native
IPv6, and if one of the draft's goals is to reach -cough- consensus
-cough-, one may consider forgetting the 6PE classification
altogether. The one part that is not open for grabs with me is
classifying 6RD as native.
Michel.
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 traffic distribution
The Comcast 6rd trial will conclude very soon, so I do not recommend doing anything specific for Comcast 6rd. John = John Jason Brzozowski Comcast Cable e) mailto:john_brzozow...@cable.comcast.com o) 609-377-6594 m) 484-962-0060 w) http://www.comcast6.net = On 7/29/11 8:16 AM, George Michaelson ggm+i...@apnic.net wrote: On 29/07/2011, at 8:03 AM, Joel Jaeggli wrote: agree but if you're trying to discriminate it by: This graph shows the daily unique queried reverse addresses by type. you can't. Very true Joel. I did, for a while, pattern match the 6rd prefix from Free.FR's declared ranges in RIPE whois but it was pointed out to me that dealing with one ISP like this skews things. After all, other ISps also deploy 6rd, and Comcast do some kind of related work. I can put in a 6rd line, if thats what people *want* -G ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: DKIM Signatures now being applied to IETF Email
t.petch wrote: It functions, but does not work, in that it tells me nothing about the true origin of the communication. Yes and No and that the main problem with DKIM, which I see is the lack of 3rd party signal controls or put another way - anyone, middle ware and especially list servers can blindly DKIM resign mail without restrictions. That lack of control has cause originating authoring domains, copyright holders of mail, all benefits of supporting DKIM. The current approach is that original domains no longer have any rights whatsoever to declare they are the only signers allowed to sign mail and any deviation from that expectation should be indication of protocol failure - Reject it! Unfortunately, in order to allow a list server or any 3rd party middleware to exist with DKIM (re)signing features, it needs to ignore any original DKIM domain signing practice or expectations. No domain that wishes exclusive signing operations should be sending their signed mail to a public service forum. We know this, but we don't have the controls to disallow faults or bad guys attempting to create a facsimile of your domain signed mail in public areas or directly to others. Finally, as DKIM was revamped from secured Author-Domain signing protocol to a anyone can signed 3rd party Trust vendor protocol, the problem we face is we don't have consistency with 3rd party trust tables. For DKIM to work, every validators needs a copy of the same trust tables. DKIM is a protocol that requires Batteries in order to work and everyone must use the same batteries. -- Hector Santos, CTO http://www.santronics.com http://santronics.blogspot.com ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Last Call: draft-gundavelli-v6ops-pmipv6-address-reservations-00.txt (Reserved IPv6 Interface Identifier for Proxy Mobile IPv6) to Informational RFC
The IESG has received a request from an individual submitter to consider the following document: - 'Reserved IPv6 Interface Identifier for Proxy Mobile IPv6' draft-gundavelli-v6ops-pmipv6-address-reservations-00.txt as an Informational RFC The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-08-26. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract Proxy Mobile IPv6 [RFC5213] requires all the mobile access gateways to use a fixed link-local and link-layer addresses on any of its access links that it shares with the mobile nodes. This was intended to ensure a mobile node does not detect any change with respect to its layer-3 attachment even after it roams from one mobile access gateway to another. In the absence of any reserved addresses for this use, it requires coordination across vendors and the manual configuration of these addresses on all the mobility elements in a Proxy Mobile IPv6 domain. This document attempts to simplify this operational requirement by making reservation for special addresses that can be used for this purpose. The file can be obtained via http://datatracker.ietf.org/doc/draft-gundavelli-v6ops-pmipv6-address-reservations/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-gundavelli-v6ops-pmipv6-address-reservations/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
Last Call: draft-ietf-krb-wg-clear-text-cred-01.txt (The Unencrypted Form Of Kerberos 5 KRB-CRED Message) to Proposed Standard
The IESG has received a request from the Kerberos WG (krb-wg) to consider the following document: - 'The Unencrypted Form Of Kerberos 5 KRB-CRED Message' draft-ietf-krb-wg-clear-text-cred-01.txt as a Proposed Standard The IESG plans to make a decision in the next few weeks, and solicits final comments on this action. Please send substantive comments to the i...@ietf.org mailing lists by 2011-08-12. Exceptionally, comments may be sent to i...@ietf.org instead. In either case, please retain the beginning of the Subject line to allow automated sorting. Abstract The Kerberos 5 KRB-CRED message is used to transfer Kerberos credentials between applications. When used with a secure transport the unencrypted form of the KRB-CRED message may be desirable. This document describes the unencrypted form of the KRB-CRED message. The file can be obtained via http://datatracker.ietf.org/doc/draft-ietf-krb-wg-clear-text-cred/ IESG discussion can be tracked via http://datatracker.ietf.org/doc/draft-ietf-krb-wg-clear-text-cred/ No IPR declarations have been submitted directly on this I-D. ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6225 on Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information
A new Request for Comments is now available in online RFC libraries. RFC 6225 Title: Dynamic Host Configuration Protocol Options for Coordinate-Based Location Configuration Information Author: J. Polk, M. Linsner, M. Thomson, B. Aboba, Ed. Status: Standards Track Stream: IETF Date: July 2011 Mailbox:jmp...@cisco.com, marc.lins...@cisco.com, martin.thom...@andrew.com, bernard_ab...@hotmail.com Pages: 36 Characters: 77001 Obsoletes: RFC3825 I-D Tag:draft-ietf-geopriv-rfc3825bis-17.txt URL:http://www.rfc-editor.org/rfc/rfc6225.txt This document specifies Dynamic Host Configuration Protocol options (both DHCPv4 and DHCPv6) for the coordinate-based geographic location of the client. The Location Configuration Information (LCI) includes Latitude, Longitude, and Altitude, with resolution or uncertainty indicators for each. Separate parameters indicate the reference datum for each of these values. This document obsoletes RFC 3825. [STANDARDS-TRACK] This document is a product of the Geographic Location/Privacy Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
RFC 6310 on Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping
A new Request for Comments is now available in online RFC libraries. RFC 6310 Title: Pseudowire (PW) Operations, Administration, and Maintenance (OAM) Message Mapping Author: M. Aissaoui, P. Busschbach, L. Martini, M. Morrow, T. Nadeau, Y(J). Stein Status: Standards Track Stream: IETF Date: July 2011 Mailbox:mustapha.aissa...@alcatel-lucent.com, busschb...@alcatel-lucent.com, lmart...@cisco.com, mmor...@cisco.com, thomas.nad...@ca.com, yaako...@rad.com Pages: 40 Characters: 85733 Updates/Obsoletes/SeeAlso: None I-D Tag:draft-ietf-pwe3-oam-msg-map-16.txt URL:http://www.rfc-editor.org/rfc/rfc6310.txt This document specifies the mapping and notification of defect states between a pseudowire (PW) and the Attachment Circuits (ACs) of the end-to-end emulated service. It standardizes the behavior of Provider Edges (PEs) with respect to PW and AC defects. It addresses ATM, Frame Relay, Time Division Multiplexing (TDM), and Synchronous Optical Network / Synchronous Digital Hierarchy (SONET/SDH) PW services, carried over MPLS, MPLS/IP, and Layer 2 Tunneling Protocol version 3/IP (L2TPv3/IP) Packet Switched Networks (PSNs). [STANDARDS-TRACK] This document is a product of the Pseudowire Emulation Edge to Edge Working Group of the IETF. This is now a Proposed Standard Protocol. STANDARDS TRACK: This document specifies an Internet standards track protocol for the Internet community,and requests discussion and suggestions for improvements. Please refer to the current edition of the Internet Official Protocol Standards (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. This announcement is sent to the IETF-Announce and rfc-dist lists. To subscribe or unsubscribe, see http://www.ietf.org/mailman/listinfo/ietf-announce http://mailman.rfc-editor.org/mailman/listinfo/rfc-dist For searching the RFC series, see http://www.rfc-editor.org/rfcsearch.html. For downloading RFCs, see http://www.rfc-editor.org/rfc.html. Requests for special distribution should be addressed to either the author of the RFC in question, or to rfc-edi...@rfc-editor.org. Unless specifically noted otherwise on the RFC itself, all RFCs are for unlimited distribution. The RFC Editor Team Association Management Solutions, LLC ___ IETF-Announce mailing list IETF-Announce@ietf.org https://www.ietf.org/mailman/listinfo/ietf-announce
