Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Sun, Sep 22, 2013 at 6:59 PM, Paul Wouters p...@cypherpunks.ca wrote: snip Note that decentralising makes you less anonymous. If everyone runs their own jabber service with TLS and OTR, you are less anonymous than today. So decentralising is not a solution on its own for meta-data tracking. When I'm talking about decentralizing of internet I'm talking more about the traffic flow. We are sort of already on the way there with CDN moving much used content close to the user, Microsoft updates are done this way afaik, youtube, think gmail are distributed to. I think this is mostly done due to cost and user-experience reasons. We should go further, end-users should be able to communicate with each other in a direct fasion as possible, preferable not going through central chokepoints at all. Why send a videosession between two neighbours 3000km just because they have different ISP that don't want to exchange local traffic local even they are in the same physical room with their equipment? In a rack next to each other? That is how internet in Norway are mostly done today with a very few exceptions. That means more interconnect between ISPs, more IX'es, and alot more distributed routing... ... but not sure if this is really in the IETF domain at all, is it a technical, economical or political issues that preventing this today? -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Fri, Sep 20, 2013 at 6:54 AM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: I got my arm slightly twisted to produce the attached: a simple concatenation of some of the actionable suggestions made in the discussion of PRISM and Bruce Schneier's call for action. There are one thing I don't see mention in your draft, the discussion that moved from ietf@ and over into lisp@ about encryption by default wherever it's possible. It's one concrete action this NSA/Snowden/Bruce thing has started. -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: [Fwd: I-D Action: draft-carpenter-prismatic-reflections-00.txt]
On Sat, Sep 21, 2013 at 7:24 PM, Stephen Farrell stephen.farr...@cs.tcd.ie wrote: On 09/21/2013 02:42 PM, Roger Jørgensen wrote: snip There are one thing I don't see mention in your draft, the discussion that moved from ietf@ and over into lisp@ about encryption by default wherever it's possible. It's one concrete action this NSA/Snowden/Bruce thing has started. FWIW, I'm also maintaining a list of concrete proposals and relevant I-Ds that I've seen. [1] I've not noticed an I-D on the LISP idea though but let me know if there's one I missed. are no new I-Ds yet no.. :( -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On Sat, Sep 7, 2013 at 5:05 AM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: Scott Brim scott.b...@gmail.com The encapsulation is not much of an obstacle to packet examination. There was actually a proposal a couple of weeks back in the WG to encrypt all traffic on the inter-xTR stage. The win in doing it in the xTRs, of course, is that you don't have to go change all the hosts, application by application: _all_ traffic, of any kind, from that site to any/all other sites which are encryption-enabled, will get a certain degree of confidentiality. Does this count as something the IETF can do reasonably quickly that will help somewhat? :-) One easy fix then would be to have a MUST encrypt traffic between xTRs, and that the encryption used MUST be strong. Are LISP@WG up for the challenge? :-) The userbase and deployment are relative small atm so it's doable to get fast deployment to. -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On Sat, Sep 7, 2013 at 2:20 PM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: From: =?ISO-8859-1?Q?Roger_J=F8rgensen?= rog...@gmail.com The userbase and deployment are relative small atm so it's doable to get fast deployment to. Alas, now that I think about the practicalities I don't think the average router has enough spare computing power to completely encrypt all the traffic. I don't really see that as an issue, it's just a matter of engineering and building the router in a way that they can do it. AFAIK I think most routers have the options of being extended by dedicated encrypt-all-traffic tasks? Probably some changes needed on the software layer to use the extension but that's doable. It is also just the situation right now on the router side. In general should our current technology and processing power be up for the job if needed. Whether or not encrypting just the source+dest addresses, and the sort+dest port (conviently next to each other in one block) is enough to do much good, and if the average router has enough spare crunch to do even that, is a good question. Isn't the payload the important part to protect? the content of the package? -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
decentralization of Internet (was Re: Bruce Schneier's Proposal to dedicate November meeting to saving the Internet from the NSA
On Fri, Sep 6, 2013 at 9:47 AM, Adam Novak interf...@gmail.com wrote: snip One way to frustrate this sort of dragnet surveillance would be to reduce centralization in the Internet's architecture. Right now, the way the Internet works in practice for private individuals, all your traffic goes up one pipe to your ISP. It's trivial to tap, since the tapping can be centralized at the ISP end. excellent idea... any suggestion on how that should be done? Only one I can remember right now are LISP which sort of create a new network on top of our current network, and the EID-block drafts being worked on by some people (including me) tries to address how the IP-space of this new network can be done. But there must be other ways than through LISP-alike way of doing it? The IETF focused on developing protocols (and reserving the necessary network numbers) to facilitate direct network peering between private individuals, it could make it much more expensive to mount large-scale traffic interception attacks. Think there are work being done on the topic? However, how are you going to interconnect all of this private peerings? It sort of imply that everyone need to have their own netblock they can exchange with others. -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: The Friday Report (was Re: Weekly posting summary for ietf@ietf.org)
On 3 Aug 2013 11:14, Ole Jacobsen (ole) o...@cisco.com wrote: It was never a distraction until AB started complaining about it. Been serving a useful purpose for many, many years. Procmail is your friend. +1 for that --- Roger --- Ole J. Jacobsen Editor Publisher http://cisco.com/ipj Sent from my iPhone On Aug 3, 2013, at 9:12, Heasley h...@shrubbery.net wrote: Am Aug 3, 2013 um 9:05 schrieb Abdussalam Baryun abdussalambar...@gmail.com: On 8/3/13, Patrik Fältström p...@frobbit.se wrote: On 3 aug 2013, at 08:46, Abdussalam Baryun abdussalambar...@gmail.com wrote: I prefer if you post at end of Friday (as in the end of working days of 5 in each week). However, in my comment below I will follow the week as done in world calender, start from Sunday (mornings) and ends on Saturday (nights). The day a week starts, and what days are working days in a week, differs between cultures. Many have Sunday-Thursday as working days. Many have Monday as the first day of the week. I suggested to Thomas to submit report in end of Friday (read what i I suggest eliminating the report. As it doesn't measure content quality, one's contribution can't be measured by the email they produce. So, it is only a guage of the distraction they produce. The report itself is a distraction.
Re: Please review draft-housley-rfc2050bis-00.txt
On Mon, Mar 18, 2013 at 5:20 PM, joel jaeggli joe...@bogus.com wrote: On 3/18/13 6:04 AM, Ole Jacobsen wrote: I am wondering if the draft should mention that Local Internet Registries (LIRs) may sometimes take the form of National Internet Registries (NIRs) since this is now a reality in some places? All of the NIRs I've encountered can be construed as LIRs under the terms of the definition of LIR in that region. apnic and lacnic I belive specifically recognize the term. As much as I dislike the entire term NIR I see it exist already on the top/root, to quote from http://www.iana.org/numbers Both IPv4 and IPv6 addresses are generally assigned in a hierarchical manner. Users are assigned IP addresses by Internet service providers (ISPs). ISPs obtain allocations of IP addresses from a local Internet registry (LIR) or National Internet Registry (NIR), or from their appropriate Regional Internet Registry (RIR): I see APNIC are using it (http://www.apnic.net/policy/operational-policies-nirs/text), are anyone else? All I see is just yet another level of administration/control? -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
congestion control? - (was Re: Appointment of a Transport Area Director)
changed the subject ... and added a cc to some that might not follow ietf@ On Sun, Mar 3, 2013 at 1:50 PM, Eggert, Lars l...@netapp.com wrote: On Mar 3, 2013, at 13:37, Eric Burger ebur...@standardstrack.com wrote: There are two other interpretations of this situation, neither of which I think is true, but we should consider the possibility. The first is the TSV is too narrow a field to support an area director and as such should be folded in with another area. The second is if all of the qualified people have moved on and no one is interested in building the expertise the IESG feels is lacking, then industry and academia have voted with their feet: the TSV is irrelevant and should be closed. Since I believe neither is the case, it sounds like the IESG requirements are too tight. I don't believe the requirements are too tight. *Someone* one the IESG needs to understand congestion control. The likely possibility is that many qualified people failed to get sufficient employer support to be able to volunteer. It's at least a 50% time committment. I'll ask a rather basic question and hope someone will answer in an educational way - Why is congestion control so important? And where does it apply? ... :-) -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
On Wed, Nov 21, 2012 at 11:01 PM, Dino Farinacci farina...@gmail.com wrote: Make it an allocation for EIDs and ILNP can use it too. Somehow I hear a voice in the back of my head asking if we're talking about starting to use another big IPv6 block than 2000::/3 for the two above mention usage? 2000::/3 for our current model of Internet with our current style of allocation/assignment of address space to ISP/end users ::/3 for future modells, LISP/EID, ILNP and others? -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
On Tue, Nov 13, 2012 at 3:45 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP EID Block' draft-ietf-lisp-eid-block-03.txt as 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 2012-11-27. 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. I think LISP is an important factor in the future of Internet and I do support the idea of having different IP block for LISP based network. However, I can not support the publication of this document, it has some unclear issues that need good answers first. Anyhow, I see two issues that need to be addressed better 1.) How should the address space be administrated, RIR structure or something else closer to 6bone? I support the suggested idea of discussing this part with the different RIRs to look more into how this are going to work in practice. And as Dino said, No, I am not making any assumptions either way. How allocation gets done is subject to more work. the document should state this. 2.) The interaction between none-LISP and LISP Internet. This problem has two sub-problems within it a.) Why is there a need for a special LISP block. This is partly answered in section 3. Rationale and Intent. Is this the entire reason? start copy'n'paste With the current specifications, if an ITR is sending to all types of destinations (i.e., non-LISP destinations, LISP destinations not in the IPv6 EID Block, and LISP destinations in the IPv6 EID Block) the only way to understand whether or not to encapsulate the traffic is to perform a cache lookup and, in case of cache-miss, send a Map- Request to the mapping system. In the meanwhile, packets can be dropped. end copy'n'paste b.) the routing integration between none-LISP and LISP internet, how are that going to work? The current document isn't clear enough on that as I see it. Are there an assumption that some ISPs will announce the entire LISP space (/16 are mention) for free ? If each and every EID space holder (/32 or similiar) each have to connect to Internet and get their address space routed, then it's nothing different than regular RIR allocated /32's. Address these thing somehow in the document, even just mention that it's subject for other document and I'm happy... :-) -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: [lisp] Last Call: draft-ietf-lisp-eid-block-03.txt (LISP EID Block) to Informational RFC
On Tue, Nov 13, 2012 at 3:45 PM, The IESG iesg-secret...@ietf.org wrote: The IESG has received a request from the Locator/ID Separation Protocol WG (lisp) to consider the following document: - 'LISP EID Block' draft-ietf-lisp-eid-block-03.txt as 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 2012-11-27. 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 This is a direction to IANA to allocate a /16 IPv6 prefix for use with the Locator/ID Separation Protocol (LISP). The prefix will be used for local intra-domain routing and global endpoint identification, by sites deploying LISP as EID (Endpoint IDentifier) addressing space. I have to ask, who can request an netblock from this address space and from where? I might be blind but I couldn't find it mentioned anywhere. -- Roger Jorgensen | ROJO9-RIPE rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: shared address space... a reality!
On Wed, Mar 14, 2012 at 8:47 AM, Måns Nilsson mansa...@besserwisser.org wrote: On Wed, Mar 14, 2012 at 02:22:04AM -0400, Christopher Morrow wrote: NetRange: 100.64.0.0 - 100.127.255.255 CIDR: 100.64.0.0/10 OriginAS: NetName: SHARED-ADDRESS-SPACE-RFCTBD-IANA-RESERVED GOOD. Now I can BOTH keep sticking my head in the sand AND get NEW RFC 1918 space to number my devices! This is really good news for some people, that already have address conflict within RFC1918 and don't want to get public address space :p --- Roger J --- Trailing edge WINS! Congrats, all you people who joined the ietf mailing list to get your VOTE through. You can sign off now and continue non-contributing to the developement of the future. -- /Måns, pissed off. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP'
not replying specific to this mail but to the tons that have arrived lately, are there some confusion out there that it is the amount of votes on ietf@ that make a do/do not on a draft? ... or just me missunderstanding this? anyway, great to see people participate :-) --- Roger J --- On Tue, Feb 14, 2012 at 6:19 PM, Erichsen, Kirk kirk.erich...@twcable.com wrote: I fully support this draft and would like to see it progress to conclusion without further delay. With warm regard, Kirk Erichsen Principle Technology Engineer Time Warner Cable ATG West This E-mail and any of its attachments may contain Time Warner Cable proprietary information, which is privileged, confidential, or subject to copyright belonging to Time Warner Cable. This E-mail is intended solely for the use of the individual or entity to which it is addressed. If you are not the intended recipient of this E-mail, you are hereby notified that any dissemination, distribution, copying, or action taken in relation to the contents of and attachments to this E-mail is strictly prohibited and may be unlawful. If you have received this E-mail in error, please notify the sender immediately and permanently delete the original and any copy of this E-mail and any printout. ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IETF Last Calls and Godwin-like rules
On Thu, Feb 16, 2012 at 3:34 PM, Yoav Nir y...@checkpoint.com wrote: snip I think that an endorsement like I work for Cisco and we intend to implement this in every one of our products is useful. But it's not nearly as useful as this is a terrible idea, and doing this will prevent IPv6 from ever gaining traction. The objections raised in last call are really the point, not the endorsements. Think I've read somewhere that the ground of good engineering (the E in IETF) are being able to argue against your own idea, search and look for flaws in it, and all in the name of testing it to see how it can be made even better, is it good enough? Or simple to consider the bigger picture, can my idea hurt the rest no matter how good it is? There are great and very good ideas out there that isolated are fantastic, but considered in just a bit bigger picture are horrible, they've ruin everything around them. So, when lots of people are all for something without mention or willing to discusse the bad sides... that's scary as I see it. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
Sorry Noel but I choice to reply public to this one. On Mon, Feb 13, 2012 at 10:52 PM, Noel Chiappa j...@mercury.lcs.mit.edu wrote: IPv6 is The Key! If you think denying a CGN block will do anything at all to help IPv6, you're very confused. quote out of context etc... but my change of mind from supporting this draft to not supporting has nothing todo with IPv6 at all. Nothing. It all boils down to RFC1918 space, there are 3 huge network blocks there and double, tripple NAT work, just as well as CGN will (it will break plenty of application either way). * 10.0.0.0/8 ~16mill addresses * 172.16.0.0/12 ~1mill addresses * 192.168.0.0/16 ~65K addresses I can't really see what difference another /10 will make really, especially now that we're in essence out of IPv4 addresses. We're all much better of with some pain (address collision etc) during the transition to IPv6 than to delay it even more. And about your quote, yes we have to change to IPv6, there are at currently no other options at all. Sure there are plenty of not optimal design choice made, stupid things (like we're wasting /64 due to EUI-64) etc etc, but that is an entire other range of subject. Right now, we only have one real choice, move to IPv6. Everything else is moving the pain around. and for those that really really really want to continue to use IPv4, well try to make 240/4 (E-class) usable... there you have an entire /4 instead of /10. 240.0.0.0/4 Reserved for Future Use[RFC1700, page 4] I personally think that reservation should have been lifted years ago. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Tue, Feb 14, 2012 at 5:51 AM, Masataka Ohta mo...@necom830.hpcl.titech.ac.jp wrote: Brian E Carpenter wrote: Sure, that's very common, but these devices are consumer electronics and will get gradually replaced by IPv6-supporting boxes as time goes on. The problem is that IPv6 specification is still broken in several ways to be not operational that existing boxes must be replaced after the specification is fixed. The more serious problem is that IPv6 people in IETF do not admit IPv6 broken, which makes it impossible to fix IPv6. Make a draft, gather your supporters and take that discussion on 6man wg. I'm sure there are people open to consider any arguments on what's wrong/or not. Either way, we're way passed changing any of the important parts of IPv6. That has to be IPv6 v2 WITH backward compability to IPv6 (as we currently know it). -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Mon, Feb 13, 2012 at 9:34 PM, Doug Barton do...@dougbarton.us wrote: On 02/12/2012 13:34, Noel Chiappa wrote: From: Nilsson mansa...@besserwisser.org there _is_ a cost, the cost of not being able to allocate unique address space when there is a more legitimate need than the proposed wasting of an entire /10 to please those who did not do the right thing. On the contrary, denying this block is likely to _accelerate_ usage of what space remains, thereby penalizing the 'other users' whose interests you _claim_ to be protecting. If an ISP can't use a shared block, they'll go ask their RIR for a block - and given that they demonstrably have the need (lots of customers), they will get it. Multiply than by N providers. If the RIRs do not deny these requests there is likely to be a revolt. OTOH that may be a good thing As for your other 2 options: But it is. As I said before, the IETF has precisely two choices: - See CGN deployed using various hacks (e.g. squatting on space) Incredibly unlikely to happen. The ISPs are smart enough to know that this will cause them more headaches than its worth. - See CGN deployed using a block of space allocated for that purpose If the IETF rightly denies this request then the ISPs are going to be forced to use the proper option, 1918 space. Whatever customer support costs they have to bear for the small percentage of customers that actually manage to overlap will rightly be borne by the people who created their own problems. Everyone wins. +1 :-) I did original think it was the lesser evil to support this draft, but I have now changed my mind. Plenty of arguments from so many on so many points that I can't really see any reason anymore to support it. So, no I don't support this draft. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Sat, Feb 11, 2012 at 9:32 AM, Måns Nilsson mansa...@besserwisser.org wrote: On Fri, Feb 10, 2012 at 11:44:42PM -0500, Noel Chiappa wrote: This is only about allocating a chunk of address space. For which there is better use than prolonging bad technical solutions. Address translation has set the state of consumer computing back severely. It might be all nice and proper according to those who desire to keep the power of owning a TV transmitter, a printing press or a transaction broker service. Do keep in mind that the real driver in IP technology is the ability for end-nodes to communicate in a manner they chose without prior coordination with some kind of protocol gateway. NAT and more so CGN explicitly disables this key feature. And this is not what the IETF should be doing. The IETF should seek to maximise the technical capabilities of the Internet protocol suite so that it may continue to enable new uses of the key feature, ie. end-node reachability. Allocating CGN-blessing address space is a clear violation of this. Is that true? And if so, why and how can it be formulated or find support it earlier work? And if it is not true. Why and where do you find support for that view? I ask because you might touch something quite fundamental there... can IETF support something that will break/limit reachability on Internet. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] Last Call: draft-ietf-v6ops-v6-aaaa-whitelisting-implications-08.txt (Considerations for Transitioning Content to IPv6) to Informational RFC
On Thu, Feb 9, 2012 at 10:25 AM, Lorenzo Colitti lore...@google.com wrote: snip It seems to me that approximately 30% of the non-biolerplate text in this draft discusses DNS whitelisting. (And in fact, in its original form the draft entirely on DNS whitelisting - hence the filename. The rest was added later.) Whitelisting is a practice relevant to a few large websites (since nobody else is using it). It so happens that the websites that employ this practice are going to stop using it, all together. Given the cost and implications, I'd say practice is unlikely to be resurrected. So, you decide to tell the whole story, and talk about whitelisting *and* World IPv6 Launch. Or you can decide that whitelisting will soon be irrelevant, and not talk about either whitelisting or World IPv6 Launch. But you can't talk about whitelisting without talking about World IPv6 Launch, because if you do, your document is missing the key piece how do you remove the whitelist, and that's a disservice to its readers. To be more specific, at least section 5.5 (it is unclear how implementers will judge when the network conditions will have changed sufficiently to justify turning off DNS Resolver Whitelisting and/or what the process and timing will be for discontinuing this practice) is now incorrect. It *is* clear, and it's what those implementers are doing as part of World IPv6 Launch. Does that make more sense? Or, the way I read you, you tell us that this entire document isn't relevant anymore. It cover something called whitelisting that were in use for a short periode of time for reason no one in a few year can understand as relevant? -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-14.txt (IANA Reserved IPv4 Prefix for Shared Address Space) to BCP
On Thu, Feb 9, 2012 at 9:40 PM, Ronald Bonica rbon...@juniper.net wrote: SM, At NANOG 54, ARIN reported that they are down to 5.6 /8s. If just four ISPs ask for a /10 for CGN, we burn one of those /8s. Is that really a good idea? It's not about good or bad idea, it should be more about; If they can justify having a /10 each then they should get it. And yes, that will hurt. ... wish people could use more time to move on instead of trying to squeeze even more out of the good old, dry and dead dog called IPv4. With all of that said, giving out this shared address space is a horrible idea, but it just a little bit less horrible than the alternates. And yes it will be abused and be counted as yet another RFC1918 space anyway. I know of plenty of people that will be trilled for this space... woho, no more address collision while they quiet think I hope no one else know about this address space in other word, move on, give out this space, it'll hurt just a little bit less than the other options. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call (Update): draft-weil-shared-transition-space-request
On Dec 5, 2011 7:48 PM, Chris Grundemann cgrundem...@gmail.com wrote: On Sat, Dec 3, 2011 at 15:06, Ronald Bonica rbon...@juniper.net wrote: By contrast, further discussion of the following topics would not help the IESG gauge consensus: snip Agreed. The bottom line here is that if we remove ourselves from the religious/political debate and focus on operational realities - the choice is not a hard one. The allocation of a shared CGN space is the best thing we can do for the Internet, it's users, it's operators, it's vendors, and for IPv6 deployment as well (which is actually redundant). No it might not be a hard choice, but that dont make it a good solution, just a choice of the lesser evil. Btw: If this allocation are made from any of the free available pools, not rfc1918 or 240/4, then lets us also give out a /8 from somewhere in 240/4 and lets see if it really is so d*mn hard to use this space. That might add some value for the future --- Roger J --- ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
On Tue, Nov 29, 2011 at 9:53 PM, Harald Alvestrand har...@alvestrand.no wrote: snip FWIW, given that the IAB has chosen to not uphold the principle of subsidiarity and let this thing be done at the lowest possible level in the decision hierarchy, I hold with the people who argue that allocating this /10 is less harmful than not allocating it. best in this case being synonymous with least bad, not synonymous with good. I read, it is what will hurt the whole less, nothing todo with good or bad idea. Anyway, for what's it's worth. I'm very against the entire idea, but all in all, it's better to give out that one big block than let the chaos loose. but it will probably open a can of worm that will start raining on everyone in 2012 or so -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On Sun, Sep 25, 2011 at 3:42 PM, John C Klensin john-i...@jck.com wrote: snip snip And that helps identify a third risk. How relevant it is depends on one's perspective and understanding of reality but that risk is: 3) People will conclude that these various kludges are actually medium-term solutions and will put resources into them that would have gone into deploying IPv6 instead. As soon as you say folks are going to need to go to the trouble and expense of developing and deploying replacements for a lot of installed-base IPv4 software, the resources involved become significant and there are tradeoffs with other ways in which those resources could be invested. It is quite likely that resources will be used on prolonging IPv4 if there is a way of doing that, like putting this last netblock into use. That just put IPv6 even further off and cause even more trouble down the road. However, if this proposal goes through and that last netblock are assigned to use, how long will it take before anyone ask the following question: Why haven't that last netblock been put to use by the RIR earlier and with that given us more time to prepare for IPv6? -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Last Call: draft-weil-shared-transition-space-request-03.txt (IANA Reserved IPv4 Prefix for Shared Transition Space) to Informational RFC
On Sat, Sep 24, 2011 at 5:24 AM, Ronald Bonica rbon...@juniper.net wrote: Folks, This allocation cannot be made without IETF consensus. Publication on the Independent Stream does not reflect IETF consensus. Therefore, publication on the Independent Stream wouldn't enable the allocation. Sorry, or maybe I'm not really sorry, but I can not see it as a good thing for the internet at whole to allocate the prefix right now. Notice that right now part. Let people try out all of the scenario we have available, we don't need to add yet another part into the huge mess we've already got us into. Are already too many ways to get from v4 to v6 as it is In a few years _when_ we've got IPv6 more into mainstream, I'm quite sure we will see a technical (and only technical) reason for allocating that last remaining piece of IPv4 netblock we've got left. There is already too many burning fire out there right now, we don't need to add more wood (ipv4 addresses or special case usage etc) to it. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Trust membership [Re: IAOC: delegating ex-officio responsibility]
On Tue, Sep 20, 2011 at 11:09 PM, Brian E Carpenter brian.e.carpen...@gmail.com wrote: On 2011-09-21 05:44, Olaf Kolkman wrote: snip The Trust would need to commit to allowing these advisors to join their meetings too. But that can be done in other ways than the Trust Agreement. (so yes, I agree with this line of thought) Obviously this all assumes there is a consensus for changing the I* chairs role ...exactly. I'm far from convinced about that. I think the real need is to figure out how to make the IAOC an Oversight committee rather than it getting involved in executive decisions, and to figure out how to make the IAB an Architecture board instead of getting involved in administrative matters. I'm new to this level of innerworking in the IETF, and a bit more confused after this thread. I did ask what was the core problem sort of and got two excellent answers but none of the convinced me that the draft/proposal at hand are the right answer to an obvious problem. However, Brian's suggestion above looks like a better road ahead since it get closer to the core of the problem, the workload and address that. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IAOC: delegating ex-officio responsibility
On Tue, Jul 26, 2011 at 2:52 PM, Olaf Kolkman o...@nlnetlabs.nl wrote: Dear Colleagues, Based on the discussion I've updated the draft: http://tools.ietf.org/html/draft-kolkman-iasa-ex-officio-membership I still do not understand the basic problem that trigger/cause that propsal. Have been alot of discussion and suggestion and problems but nothing that made me understand why, what is the underlaying cause. (it could be that I'm just slow, we shouldn't rule that out :-) ) -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Conclusions on draft-housley-two-maturity-levels
On Sat, Sep 10, 2011 at 5:47 PM, Dave CROCKER d...@dcrocker.net wrote: On 9/9/2011 10:47 AM, Jari Arkko wrote: It was also very difficult to make a full determination, because a lot of the discussion has been on tangential topics, because in many cases it has been hard to see if a person is on the no objection, absolutely not, or I have these additional ideas camp, and because not all points raised in the discussion got responses. The pattern of failure to make changes to IETF process and structure has involved many people and many years. This means that there is an underlying problem with making change that has nothing to do with particular individuals or particular proposals. Another way of looking at it might be that people in general try to solve everything and make thing perfect... and in that process forget that it really is all of those small steps that matter. One good proposal that address and solve one problem in a good way is one of those small steps. ... and btw, I haven't read this entire proposal all the way through, but if it do address one problem and solve/fix it, then this proposal for sure is a good thing. One of those small steps :-) --- Roger J --- Whatever the details in any one case, there's been an overriding consistency to my eyes: Proposals die from the death of a thousand criticisms. Rather than work to a common proposal, there is always a pattern of decrying a proposal's lack of perfection and a variety of different proposals are put forward, none garnering a base of support. That is, rather than displaying the usual IETF style of seeking compromise to make progress, efforts are killed by individual, rigid idealism. (In terms of project management, I think there also tends to be a failure to develop a core of supporters to provide vigorous aid in making progress, but there have been exceptions that still failed.) In the current case, it's been particularly impressive to see criticisms against the proposal because it does not solve problems it is not trying to solve and because other problems are deemed higher priority. Nevermind whether the proposal does something constructive, let's complain that it doesn't do enough. Before the jointly-authored draft was released, I lobbied to have it contain a longer list of possible justifications, specifically to reduce the danger of relying on everyone's agreeing with any specific justification. We stalled on releasing the document because of this and I finally decided that since the more challenging, normative content had agreement among the authors, we should not hold the document back on this non-normative point. No matter the document's own efforts at justification, there is a basic reality we have a non-functioning standards sequence that ought to embarrass us, and an effort to get it better aligned with reality ought to be intuitively appealing. There's a good argument for simply going to a one-step process; the argument against it is that there might be benefit in the proposed two-step and we will never know if we directly jump to one-step. Personally, I think a low-hurdle step that permits recording the actual success of a protocol is worthwhile and warrants the second step. Folk who put forward a proposal tend to be absolutely certain that it will make everything -- or at least quite a bit -- better. I certainly have held that view for mine and we've been seeing others demonstrating equal certitude about theirs. The problem is that when it comes to organizational change, it's rare that anyone can legitimately be certain of efficacy, nevermind the details of unintended -- and usually deleterious -- consequences. (This well-enough established to be a cliche when teaching organizational behavior and the like.) That's the reason initial changes should be small and simple. It's even more important when the community is not well-aligned. The current draft makes relatively small changes, but includes clarifications that ought to be helpful in both lowering some actual barriers and explaining purpose. While I'm not in the camp that expects this to change working group or Area Director behavior all that much, regarding new Proposed, it might, and that would be nice. More, it provides substantive clarifications for cycling at Proposed and for the criteria to reach Full. I view both of these as significant. The most important requirement in making systemic change is creating momentum for being productive. For interesting systems needing significant change, this is best done by starting with a baby step. Instead, the IETF seems intent on throwing the baby of progress out with the bath water of perfection. d/ -- Dave Crocker Brandenburg InternetWorking bbiw.net ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Roger Jorgensen |
Re: What is Native IPv6
On Sat, Jul 30, 2011 at 4:31 AM, Michel Py
mic...@arneill-py.sacramento.ca.us wrote:
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.
let me try to write all of the above in my own wording to see if I
understand what you mean...
Anything doing translation L3 L3 is not native, that's an easy one.
It mean IPv4 running on top of IPv6, IPv6 running on top of IPv4 is
not native. But this easy way of seeing it only affect IPv4 and IPv6,
not all of the others.
As you said somewhere in there, anything attached to a L2 interface is
L3 and in that respect native as long as the transport from that L2
interface do not require other L3 protocols to work?
(of course it gets hairy when you involve MPLS according to Michel's
text above)
When Jordi says:
However, for what it matters here, 6rd is native after exiting from the
ISP, same as 6to4 is native after exiting from the 6to4 relay.
That fails the first one, it is _translated_ on L3 and is because of
that not native, even if the transportation of the packet after the
translation is 100% native as in not require another L3 protocol to
work.
I guess it all boils down to, are we talking about end to end native,
or the transportation of the L3 protocol being native?
--
Roger Jorgensen |
rog...@gmail.com | - IPv6 is The Key!
http://www.jorgensen.no | ro...@jorgensen.no
___
Ietf mailing list
Ietf@ietf.org
https://www.ietf.org/mailman/listinfo/ietf
Re: [v6ops] 6to4v2 (as in ripv2)?
On Wed, Jul 27, 2011 at 3:07 PM, John Mann (ITS) john.m...@monash.edu wrote: snip [ And that native dual-stack is a replacement for both. ] We want normal users to move past experimental IPv6 towards production IPv6. Exactly, we should focus on doing production IPv6, not wasting our time on something that run on top of something else, whatever it's called (are way too many to choice from already and I will recommend anyone that ask me to never walk down that road, never). So, can we please stop this never ending SPAMMING with regards to 6to4? It is a total waste of time, really Keith, please stop. pretty please stop. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-6to4-to-historic (yet again)
On Mon, Jul 25, 2011 at 4:30 PM, Ronald Bonica rbon...@juniper.net wrote: Folks, 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. Please post your views on this course of action by August 8, 2011. Supported. Guess there are so many against for whatever reason so the consensus part will be hard. The archive have probably all of the arguments. But whatever happen with this one, can we please move on and focus on the one and only important thing, native IPv6. All the other are work around. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Another look at 6to4 (and other IPv6 transition issues)
On Sun, Jul 17, 2011 at 6:59 AM, Doug Barton do...@dougbarton.us wrote: On 07/16/2011 07:02, John C Klensin wrote: --On Friday, July 15, 2011 15:39 -0700 Doug Barton do...@dougbarton.us wrote: snip But, while some people have argued that 6to4 has caused so much damage by being misconfigured that it should, presumably as punishment or to create a public example, be eliminated entirely as an option My perspective, which I've described at length many times now, is not that 6to4 needs to be punished, but that the widespread deployment of IPv6 is being harmed as a result of the negative user experience that it creates for the majority of its users (particularly the unintentional ones) and therefore the network as a whole is better off if it goes away. That do sum it up pretty good. snip Furthermore you have the huge problem that neither end of the 6to4 equation has *any* motivation to fix it. The ISP side can simply block tunnels (or even simpler, ignore the problem). The content side can simply not deploy records. My wild guess is that the ISP will sooner or later stop routing the entire 2002::/16 block... and _yes_ that will hurt bad but it will force a hard error on the whole 6to4 issue. It's so much better with one hard error than lots of possible errors. snip But I don't recall seeing the sort of venom that is directed toward 6to4 being focused on them. Perhaps there weren't enough complaints or you have solid data that 6to4 has caused even more damage. Once again repeating myself ... I have no venom towards 6to4. This isn't a personal attack. And yes, various people and organizations that have vested interests in seeing IPv6 deployed have posted the data about why 6to4 causes way more problems than it solves, and I believe them. I dare to say the content providers want 6to4 gone because it _can_ be pointed at as a risk when enabling IPv6. And I do think the ISP see this as a quite black/white problem _if_ they have to deal with it. Either 6to4 are on and working all the time without them doing much, or it's gone. And this will be my last post on the subject at all, see no point in using more time on it. Lets move on :) -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: draft-ietf-v6ops-6to4-to-historic
Guess I should clearify something, the thing I am considering are to drop all 2002::/16 addresses hard, of course preferable return a correct error messages to. wonder how many find 6to4 usable when ISPs start doing that? Nuclear winter or not may follow. --- Roger J --- On Sun, Jul 3, 2011 at 9:32 PM, Roger Jørgensen rog...@gmail.com wrote: A bit late since this threat will be moderated soon. But I strongly object to this delay of needed action. I guess the other way the problem, which will hurt muchmuch more is maybe to considering a filter of 6to4 on isp level? I will suggest it when we start deploying native ipv6. --- Roger J. --- On Jul 2, 2011 6:39 PM, Ronald Bonica rbon...@juniper.net wrote: Folks, Whereas there has been considerable controversy regarding draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have agreed to the following course of action: - the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-to-historic - The author will introduce a new draft, intended for standards track publication. The new draft will update RFCs 3056 and 3068. It will say that if 6-to-4 is implemented, it must be turned off by default. - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Ron Speaking as OPS Area AD ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: HOMENET working group proposal
On Thu, Jun 30, 2011 at 4:57 AM, Fernando Gont ferna...@gont.com.ar wrote: On 06/29/2011 11:38 PM, Cameron Byrne wrote: The opportunity for restoring e2e is one of the great opportunities of ipv6 This assumes that e2e reachability is a desired property for all networks. A very good point, there are a few network that break e2e on purpose. But I guess this mostly affect enterprises and not the general Internet part, and still I would guess that the network on the inside for those enterprises still use e2e quite heavily so it's still relevant. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re:draft-ietf-v6ops-6to4-to-historic
A bit late since this threat will be moderated soon. But I strongly object to this delay of needed action. I guess the other way the problem, which will hurt muchmuch more is maybe to considering a filter of 6to4 on isp level? I will suggest it when we start deploying native ipv6. --- Roger J. --- On Jul 2, 2011 6:39 PM, Ronald Bonica rbon...@juniper.net wrote: Folks, Whereas there has been considerable controversy regarding draft-ietf-v6ops-6to4-to-historic, the v6ops chairs and document author have agreed to the following course of action: - the V6OPS WG will withdraw its request to publish draft-ietf-v6ops-6to4-to-historic - The author will introduce a new draft, intended for standards track publication. The new draft will update RFCs 3056 and 3068. It will say that if 6-to-4 is implemented, it must be turned off by default. - In order for the new draft to be published, it must achieve both V6OPS WG and IETF consensus If anyone objects to this course of action, please speak up soon. Ron Speaking as OPS Area AD ___ 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: one data point regarding native IPv6 support
On Fri, Jun 10, 2011 at 7:35 AM, Hector Santos hsan...@isdg.net wrote: snip The bottom line: unless I am force to support IPv6, stack or no stack, the investment required isn't going to happen soon. You got an options now, how, when and where you want to go with IPv6, wait a few years until all you communicate with in Asia demand IPv6 connectivity, it's the only way to reach them. and it isn't that hard, just make sure all equipment you buy/invest into now can or have a plan to support IPv6, if you start with it now, or started with it ~2-3 years ago you are pretty much safe. (not all edge equipment are ready at that time but that's another story really) -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ 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
On Thu, Jun 9, 2011 at 5:05 PM, Keith Moore mo...@network-heretics.com wrote: On Jun 9, 2011, at 10:59 AM, Gunter Van de Velde (gvandeve) wrote: Its 'rough' consensus... I don't wanna rat-hole here, but imho send the draft onwards for publication asap please. I'm not even sure it's rough consensus within the v6ops group. Again, haven't read all of the messages, but definitely get the impression that it falls short of consensus. There were quite heavy discussion and in the end, there were a few that was totally against it, the rest supported the document. No point in repeating that entire discussion here really, go back and look at the archive. And just to be clear on procedure: - you need more than rough consensus in v6ops, you need rough community-wide consensus. - the criteria for standards track actions (which this is, despite the document being labeled as Informational) requires both rough consensus and technical soundness. The best way to not rat-hole is just to drop the proposed action. Let's take a few step back and think about what we are trying to achieve here, what is our goal. IPv6 for everyone for any price? A IPv6 only world? A world where both IPv4 and IPv6 work or? I will claim our goal is native IPv6 along IPv4, and in the long run, IPv6 only. We don't need more tunneling of IPv6 over IPv4, that was okay 10years ago, maybe even 5 or 3 years ago. Now it is time to actual do the right thing and say let's do it properly, let's do IPv6 native. ...and stop discussing yesterdays technology. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: [Full-disclosure] IPv6 security myths
On Tue, Oct 26, 2010 at 10:39 PM, Fred Baker f...@cisco.com wrote: snip In the scope of things, wh does having one of out of the many needed tools make IPv6 different than IPv4, especially given that the indicated tool is present in both IPv4 and IPv6 implementations? Scratch-a-my-head. I don't see it. I have a feeling the idea that IPv6 add something to security might be linked back to the IPsec focus real early on in the IPv6 era, like years and years ago. Why it happen or how, I don't really know. -- Roger Jorgensen | rog...@gmail.com | - IPv6 is The Key! http://www.jorgensen.no | ro...@jorgensen.no ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Solutions to the IDN Problems Discussed
sometime its said you shouldn't feed the trolls but right now I think its necessary todo so. Could you please stop posting all of this nonsens on this list? So please take your private problems elsewhere. -- Roger Jorgensen | [EMAIL PROTECTED] | - IPv6 is The Key! ... ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On 9/13/07, Jun-ichiro itojun Hagino [EMAIL PROTECTED] wrote: http://sa.vix.com/~vixie/ula-global.txt has my thoughts on this, which i've appropriated without permission from hinden, huston, and narten and inaccurately failed to remove their names from (since none of them supports the proposal). in fact, nobody in the ietf intelligensia supports the proposal. the showstopped is that this appears to many as an end-run around PI, and the fear is that there's no way to prevent it because, in the end, ULA (whichever flavor it is) leads to IPv6-to-IPv6 NAT. did you read the thread some months ago? There was mention ID and LOC splitting. ULA fits that idea almost perfect. -- Roger Jorgensen | [EMAIL PROTECTED] | - IPv6 is The Key! http://www.jorgensen.no | [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 will never fly: ARIN continues to kill it
On 9/12/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: snip http://sa.vix.com/~vixie/ula-global.txt has my thoughts on this, which i've appropriated without permission from hinden, huston, and narten and inaccurately failed to remove their names from (since none of them supports the proposal). in fact, nobody in the ietf intelligensia supports the proposal. the showstopped is that this appears to many as an end-run around PI, and the fear is that there's no way to prevent it are they still refusing to put it into the queue or do anything? Even after several month? Well let really hope that will change now when/if IPv6-wg change the name to 6man and we can start working again! snip -- Roger Jorgensen | [EMAIL PROTECTED] | - IPv6 is The Key! http://www.jorgensen.no | [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
On 8/29/07, Hallam-Baker, Phillip [EMAIL PROTECTED] wrote: snip I think that we will find that there are 2 sets of user. Most users will never subnet at all and be entirely happy with a /64. just ONE /64 will almost never be enough. The reason are quite simple, almost all types of connection require some sort of link toward the end- site. This link need some sort of link-addresses and you cant get that and the LAN out of the same /64, I'm quite sure that will lead to issues. -- Roger Jorgensen | [EMAIL PROTECTED] | - IPv6 is The Key! http://www.jorgensen.no | [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: DNS as 1980s technology [was Re: The Internet 2.0 box Was: IPv6 addresses really are scarce after all]
On 8/24/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: snip No reason to attack him like you did and I specifically want to address this because mailing lists have a much larger audience than their participants. If such attacks are not answered it creates barriers for new blood to enter into the IETF process. Please don't do this. A wild guess from my side, I think quite some fresh blood are scared of by the path they have to follow to get through with their ideas or thoughts. Not so much the way their questions are answered but it certainly don´t help to be bitched at either:) -- Roger Jorgensen | [EMAIL PROTECTED] | - IPv6 is The Key! http://www.jorgensen.no | [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Internet 2.0 box Was: IPv6 addresses really are scarce after all
On 8/24/07, David Conrad [EMAIL PROTECTED] wrote: snip If you obtain address space from a service provider and you decide to change providers, you have (in most cases) two options: renumber or deploy NAT. It is a simple cost/benefit tradeoff, with the costs impacting software and protocol developers not really a consideration. From the perspective of the network administrator, which is easier? Going through every configuration file, network management program, firewall, router, etc. throughout their entire infrastructure and changing every reference to IP addresses or deploying a new box into the network infrastructure (and I'm not going to go into whether or not that box is deemed to have provide additional security)? Obviously, if you obtain provider independent address space, you don't need to renumber. Unfortunately, this doesn't scale. sound to me that what we need is a new way to - configure hosts - configure routers - configure ACL on routers/firewall/wherever - services (http, mail ) - dns (a bit special, more about it further down) where it is possible to do the change ONE place and get all other fields like the same changed at the same place in all of the above place and other I have forgotten... and at the same place have the changes be done transparent or with as short outages as possible, less than 1minut I would say. In other word. We need to get totaly ride of the manual configuration that has to be done when changing IP addresses, changing domain names etc. NA/RA build into IPv6 has some of this but it just make it possible to configure IP on the host... DNS is one place this could be done, but DNS isn't trustworthy enough yet, and we also have the NAT/RFC1918 ip addresses that make it harder. But without such a automatic system we are forever bound to IP addresses, or hostnames wherever we go. -- Roger Jorgensen | [EMAIL PROTECTED] | - IPv6 is The Key! http://www.jorgensen.no | [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: The Internet 2.0 box Was: IPv6 addresses really are scarce after all
On 8/24/07, Keith Moore [EMAIL PROTECTED] wrote: nice idea, but I'm fairly convinced that it's impractical. there are just too many interfaces, many of them nonstandard and application specific, that need to know about IP addresses. maybe we could come up with a 90% solution, but that 10% is still a bear. I'm back to thinking that we have to find some way to provide PI space to everyone. and I'm not convinced that it doesn't scale to give customers PI space and have PI addresses in IP packets, even though I'm fairly convinced that trying to do routing in terms of customer PI space doesn't scale. ULA-C/G for everone? :) snip -- Roger Jorgensen | [EMAIL PROTECTED] | - IPv6 is The Key! http://www.jorgensen.no | [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
On 8/21/07, Keith Moore [EMAIL PROTECTED] wrote: Roger Jørgensen wrote: I am fully aware of that it will very likely be more than one subnet at some point, that is why the last paragraph was included. Anyway, the important point is that we probably should have two different type of end-users, big and small. no. the important point is that all users need to initially have enough address space that they can attach not just multiple networks, but multiple layers of networks, at that point. trying to define the difference between the two types of end-users is silly. the reason that IPv6 has so many bits in its address space is to allow for expansion at the edges without making addresses variable length. You missed the point in my mail completly. My only point was that we probably need to split the /48 boundry into two, one for big or those who ask for it, they will all get a /48. And the standard that everyone get if they dont ask for a /48. -- Roger Jorgensen | [EMAIL PROTECTED] | - IPv6 is The Key! http://www.jorgensen.no | [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
On Fri, 17 Aug 2007, [EMAIL PROTECTED] wrote: snip LIR's may assign blocks in the range of /48 to /64 to end sites. All assignments made by LIR's should meet a minimum HD-Ratio of .25. * /64 - Site needing only a single subnet. * /60 - Site with 2-3 subnets initially. * /56 - Site with 4-7 subnets initially. * /52 - Site with 8-15 subnets initially. * /48 - Site with 16+ subnets initially. On Sat, 18 Aug 2007, Jeroen Massar wrote: snip * currently, which is why the /56 thing has come up again, which IMHO might be a good idea as a /48 is an awful lot that I won't even use at home, though a /48 for every end-site is fine by me as it currently is too. I would say this entire problem is related to the fact that a /48 is a huge amount of IP addresses and most people have a hard time to understand why everyone, even end-users (your grandmother or any other non-technical users) should get this amount. And at the same time it is expected that most businesses and companys should get the same size. This is just asking for trouble because it is just not-logical at all to have a one size fits all like that. I know the reasons behind the /48 etc but it just going to cause us trouble to keep it like that, we should divide the /48 cateogry of users into two: - people that can get the current /48 as long as they have more than ONE subnet - people that only have ONE subnet, typical home-users (end-users, including your grandmother), they should get a /56 or whatever else bigger than /60 and smaller than /48. Whatever else criteria we are might use should be possible to formulate into one sentence, that simple. -- Roger Jorgensen | [EMAIL PROTECTED] | - IPv6 is The Key! http://www.jorgensen.no | [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: IPv6 addresses really are scarce after all
On 8/20/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote: I know the reasons behind the /48 etc but it just going to cause us trouble to keep it like that, we should divide the /48 cateogry of users into two: - people that can get the current /48 as long as they have more than ONE subnet - people that only have ONE subnet, typical home-users (end-users, including your grandmother), they should get a /56 or whatever else bigger than /60 and smaller than /48. ARIN already has done something like that but the /56 is not for sites with ONE subnet because IPv6 already defines /64 for that. Instead they define /56 as the right size for sites expected to need only a few subnets over the next 5 years. This came about due to requests for a smaller assignment size for consumer customer, i.e. individual homes and apartments. During the discussion it became clear that even if the majority of homes today only have one subnet, this is likely to change as more categories of networkable device become available. I am fully aware of that it will very likely be more than one subnet at some point, that is why the last paragraph was included. Anyway, the important point is that we probably should have two different type of end-users, big and small. Maybe something along what Iljitsch van Beijnum suggested, /60 (or whatever number) by default and /48 to everyone that requested it without question it. -- Roger Jorgensen | [EMAIL PROTECTED] | - IPv6 is The Key! http://www.jorgensen.no | [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
Re: selling IPv4 addresses vs. the POTS number model
On 8/6/07, Arnt Gulbrandsen [EMAIL PROTECTED] wrote: Hallam-Baker, Phillip writes: We cannot afford to indulge in faith based planning here. A question. Is anyone trying to mitigate effects of the End of Time in any other way than by working on IPv6? why bother when IPv6 are ready and can be used? :) use the time wisely and we'll have enough time to prepare. -- Roger Jorgensen | [EMAIL PROTECTED] | - IPv6 is The Key! http://www.jorgensen.no | [EMAIL PROTECTED] ___ Ietf mailing list Ietf@ietf.org https://www1.ietf.org/mailman/listinfo/ietf
