Re: [v6ops] Last Call: draft-ietf-v6ops-mobile-device-profile-04.txt (Internet Protocol Version 6 (IPv6) Profile for 3GPP Mobile Devices) to Informational RFC
Hi, On Wed, Sep 04, 2013 at 06:25:17PM +0900, Lorenzo Colitti wrote: Sure, but the majority are mandatory, and don't forget that some of them are quite large (e.g., implement RFC 6204). Also, I believe it's not the IETF's role to produce vendor requirements documents. The considerations that the IETF deals with are primarily technical, and we want this stuff from our vendors is not a technical issue. *[Med] With all due respect, you are keeping the same argument since the initial call for adoption and you seem ignore we are not in that stage. That?s not fair at all.* I'm just saying it here so that everyone in the community can see it. If it's an IETF document it has to have IETF consensus, and since I feel that the arguments were not properly taken into account in the WG (read: ignored), I think it's important that the community see them before we publish this document. +1 Gert Doering -- NetMaster -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279
Re: [v6ops] 6to4v2 (as in ripv2)?
Hi, On Thu, Jul 28, 2011 at 11:20:18AM -0400, Noel Chiappa wrote: Apple has enough market share to get away with that. IPv6 doesn't. Just how much market share has 6to4, if we exclude those two users? It's amazing how many human life cycles got wasted on this (and that I can't refuse to be sucked into this again). gert -- have you enabled IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] draft-ietf-v6ops-6to4-to-historic
Hi, On Sat, Jul 02, 2011 at 11:11:43PM -0400, Keith Moore wrote: There's clearly a lack of consensus to support it. There's two very vocal persons opposing it and a much larger number of people that support it, but have not the time to write a similarily large amount of e-mails. For me, this is enough for rough consensus. (And I second everything Lorenzo, Randy and Cameron said - there's theoretical possibilities, and real world. 6to4 fails the real-world test. Get over it, instead of attacking people that run real-world networks for the decisions they need to do to keep the networks running in a world without enough IPv4 addresses). Gert Doering -- Operator -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Hi, On Thu, Jun 16, 2011 at 12:15:17PM +0930, Mark Smith wrote: I have a vested interest in anycast 6to4 continuing to exist, This actually brings up a good argument: are you going to pay for us to run our 6to4 relay? not that the cost of it is high, but there is cost to it - to make sure it keeps working, to monitor the system for overload, etc. Our customers don't really need it (because we have native IPv6), we're offering this for free to benefit users on the other side that do not have native IPv6, but insist on not using IPv4. And this also points out why anycasted 6to4 is necessarily(!) less reliable than those other Internet technologies that you have mentioned - because those that run the relays usually have no financial interest in doing so. So if it breaks, it will take longer to notice and even longer to fix than for something that directly affects paying customers. Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Hi, On Wed, Jun 08, 2011 at 04:20:44PM -0700, james woodyatt wrote: Publish it. Publish it now. Let its authors be free to pursue more useful ends than defending it. Well said. +1 Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt(Request to move Connection of IPv6 Domains via IPv4Clouds (6to4) to Historic status) to Informational RFC
Hi, On Thu, Jun 09, 2011 at 11:05:29AM -0400, Keith Moore wrote: The best way to not rat-hole is just to drop the proposed action. One voice doesn't make it consensus to drop. Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-6to4-to-historic-04.txt (Request to move Connection of IPv6 Domains via IPv4 Clouds (6to4) to Historic status) to Informational RFC
Hi, On Mon, Jun 06, 2011 at 07:41:49PM -0400, TJ wrote: On Mon, Jun 6, 2011 at 13:22, Keith Moore mo...@network-heretics.comwrote: I strongly object to the proposed reclassification of these documents as Historic. *snipped lots of great thoughts/comments, solely for brevity* Agreed that this is too harsh, too soon. Fixing the broken implementations is a better idea than trying to break the working ones. And I am not just saying this because I successfully use 6to4 on a fairly common basis ... Do we really need to go through all this again? As long as there is no Internet Overlord that can command people to a) put up relays everywhere and b) ensure that these relays are working, 6to4 as a general mechanism for attachment to the IPv6 Internet is FAIL. If someone wants to use 6to4 to interconnect his machines over an IPv4 infrastructure (=6to4 on both ends), nobody is taking this away. Gert Doering -- NetMaster -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Review of: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-03 *(formal for apps area)*
Hi, On Mon, May 30, 2011 at 08:34:21AM -0700, Dave CROCKER wrote: ACL or V6 DNS ACL or V6 resolver ACL now seem to me quite good labels. They provide useful, direct and precise meaning, while avoiding the various referential and denotational problems of a loaded term like whitelist. I have no idea what a v6 DNS ACL should be, except maybe an ACL that protects which IPv6 clients are allowed to talk to a DNS server. Whitelisting, on the other hand, is the term that Google introduced for this kind of thing and people seem to clearly understand what this is about. You are on my white list of people that I like talking to!. Gert Doering -- Operator -- did you enable IPv6 on something today...? SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [address-policy-wg] Re: Can the RIRs bypass the IETF and do their own thing?
Hi, On Mon, May 14, 2007 at 03:04:19PM -0400, Dean Anderson wrote: [..] ICANN can end the MoU at any time, and find a new technical consultant. The IETF can also end the MoU at any time. But the IETF doesn't have the authority to appoint a new IANA operator. [..] The RIR's can do whatever ICANN and the US Government allow them to do. The IETF _can_ be taken out of the picture if there is cause to do so. Not quite. If ICANN decides we won't listen to IETF anymore, or we try to inforce non-useful politics to the RIRs there is no big reason why the RIRs couldn't just kick ICANN, install the NRO in its place, and change the structure to IETF - NRO - RIRs Remember: the existing mechanism works, because the communities (!!) agree that it's a useful way to handle address distribution. The US DoC might have some say for ARIN, but the rest of the world couldn't care less - and I'm sure that the DoC is well aware of this and won't try to break apart working structures. So this is all sort of academic. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 113403 SpaceNet AGVorstand: Sebastian v. Bomhard Joseph-Dollinger-Bogen 14 Aufsichtsratsvors.: A. Grundner-Culemann D-80807 Muenchen HRB: 136055 (AG Muenchen) Tel: +49 (89) 32356-444USt-IdNr.: DE813185279 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: [EMAIL PROTECTED]: PI addressing in IPv6 advances in ARIN]
Hi, On Sun, Apr 16, 2006 at 06:03:22PM -0400, Bound, Jim wrote: The IETF has NOTHING to say anymore than any other body about any RIR policy. I want it to remain that way. IETF job is a standards body not a deployment body. Things work a lot better if IETF and RIRs work hand-in-hand - that is, IETF makes standards that people can work with, and RIRs use allocation policies that somewhat reflect what the protocol designers had in mind. For IPv6, this isn't a huge success story yet... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 88685 SpaceNet AGMail: [EMAIL PROTECTED] Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 D- 80807 Muenchen Fax : +49-89-32356-234 ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: Stepping down as IETF chair in March - - RE: A personal take on WG's priorities..
Hi, On Fri, Nov 05, 2004 at 04:31:46PM -0500, [EMAIL PROTECTED] wrote: So 40% isn't even *allocated* yet (saying that we're probably burning /8's faster than needed, but only 36% of the available space is actually routed. Sounds to me like we've got more time than 52 months, if we start doing stuff now to increase the usage efficiencies Do we really *want* that? I'd rather go for legacy-free networks. Ditch v4, build proper v6 networks. Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 66629 (65398) SpaceNet AG Mail: [EMAIL PROTECTED] Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299 ___ Ietf mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/ietf
Re: [ipv6-wg@ripe.net] RE: /48 micro allocations for v6 root servers, was: national security
Hi, On Mon, Dec 08, 2003 at 10:01:53PM +0100, Jeroen Massar wrote: There are currently quite some ISP's who filter anything /35. Generally ISP's should be filtering on allocation boundaries. Thus if a certain prefix is allocated as a /32, they should not be accepting anything smaller (/33, /34 etc) There is no commonly agreed-upon best practice for this yet. We do *not* suppress more-specifics from those address blocks, as we think it's a legitimate wish for certain networks to be multihomed, and currently there is no other solution than to go for the pragmatic approach, and just announce a /40 or even /48. I agree that things that are more specific than a /48 should not be out there. [..] the ipv6 global routing table is quite small, but it could grow quite large and when ISP's still don't filter correctly, or better if ISP's don't aggregate it will explode and we will be needing the follow up to BGP soon, which is more work for the IETF :) If every holder of an AS will announce one prefix at maximum (which should be doable by proper aggregation), the v6 BGP table would grow to about 20.000 entries. This is still manageable, although it would kill my good old Cisco 2500 that still has a full v6 BGP table... As for which smoked filled room, this should be a task of the RIRs, thus RIPE's IPv6 WG etc. but it usually takes place when communicating between ISP's. Notice that many ISP's use Gerts list: http://www.space.net/~gert/RIPE/ipv6-filters.html I would applaud a generic /32 that is 'allowed' to being cut up into multiple /48's for the purpose of critical infrastructure. But please, keep it to 1 *documented* /32. That way people will know that they will see more specifics from that prefix and that they should be accepting it too. As you cite my page, you will also know that it does not make a specific recommendation on the subject of filtering things between /35 and /48... Gert Doering -- NetMaster -- Total number of prefixes smaller than registry allocations: 57386 (57785) SpaceNet AG Mail: [EMAIL PROTECTED] Joseph-Dollinger-Bogen 14 Tel : +49-89-32356-0 80807 Muenchen Fax : +49-89-32356-299
