Re: Getting rid of the dot
snip Actually, I'd just settle for a badge that wasn't always backwards. While I can't claim that it is 'always' backwards - perhaps a simple(?) solution is to print the identifying information (whatever is decided) on both sides? [Wait - does that double the number of dots :)? Hmmm...] - S
RE: Consensus Call: draft-weil-shared-transition-space-request
I concur that we need to be realistic about this. Having had discussions with operators who are trying to deploy IPv6, the reality is that even if IPv6 were enabled universally tomorrow - a subset of subscribers, subscribers' devices/applications, and content providers will only support IPv4 until key pieces of consumer gear are replaced (many of which do not yet support IPv6, even if replaced). CGN facilitates transition, as the move to IPv6 happens. ISPs have already indicated (a few times) that RFC1918 space is not practical behind the CGN due to the (real) possibility of overlap with customer addressing. Thus, having a shared /10 minimizes the use of public globally assigned addresses and avoids address squatting. - S (as an individual contributor) From: ietf-boun...@ietf.org [mailto:ietf-boun...@ietf.org] On Behalf Of Ida Leung To: ietf@ietf.org; i...@ietf.org Subject: Re: Consensus Call: draft-weil-shared-transition-space-request All, I read a lot of emails today regarding this subject. I would like to express my personal thought on it. I support the allocation of the /10 for this purpose as laid out in draft-weil-shared-transition-space-request In organizations like the one I work for, we have solid IPv6 rollout plans which include the necessity to support some ongoing IPv4 connectivity beyond run out. This is related to the fact that too mach IPv4-Only equipment remains in the network (and still on retail store selves, selling daily just in time for Christmas demand) which cannot be feasibility removed in a short period of time. We have worked tirelessly with vendors to move forward, but reality is king. IPv4 (with address sharing in some form) will need to accompany the IPv6 deployment for a period of time, of which CGN plays a vital role (in the form of CGN and later potential in the form of DS-Lite or the such technologies). To facilitate this functionality, non-RFC1918 space will need to be used such that we can offer a working service to customers. Using a pre-defined allocation helps us and other operators achieve a deterministic approach without the variances of needing to find other, less legitimate space for such purpose. The alternative to the /10 is likely squat space. Worse yet.. Many operators choosing many pools of RIR space which in aggregate will be much greater then a single /10 (with no guidance as to what and how it's used). ...Ida ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
Re: Consensus Call: draft-weil-shared-transition-space-request
I did share what I was smoking - it's called 'reality' :). On a serious note, there aren't many clean (practical) solution that I am aware of as we migrate to IPv6. Given where are, and considering the harm caused by the alternatives of not having a reserved space (inaction - squatting), the proposed option certainly seem better, IMO. To your point, I agree that the perils of misuse exist - and those who do misuse (e.g., customers who use this space incorrectly, in conflict with ISPs) will have themselves to blame (and are probably smart to correct themselves?). Others that can break may break due to this - but, IMHO - would probably adapt more quickly than customer equipment adapting to support IPv6 overnight (which would seriously be nice!)... My $0.02! On Nov 29, 2011, at 9:50 PM, Mark Andrews ma...@isc.org wrote: In message m2sjl644h3.wl%ra...@psg.com, Randy Bush writes: anyone who thinks this will not be used as 1918 space should share what they are smoking. the question is not if, but rather how many milliseconds before it is. that is the operational reality. And what harm to others does that cause? If a ISP is using this and the customer is using this rather than RFC 1918 space then they only have themselves to blame for operational problems it causes. and we should have a betting pool on how long before it is leaked into a measure such as route-views. And users would be advised to filter routes for it the same as they should be filtering routes for other space they are using. and all this is aside from the pnp, skype, ... and other breakage. and, imiho, we can screw ipv4 life support. skype etc. will learn. This does prevent the breakage it just makes it more controlled. What's the bet Skype has a patched released within a week of this being made available? this has become a contest of wills, not a technical discussion. -- Mark Andrews, ISC 1 Seymour St., Dundas Valley, NSW 2117, Australia PHONE: +61 2 9871 4742 INTERNET: ma...@isc.org ___ Ietf mailing list Ietf@ietf.org https://www.ietf.org/mailman/listinfo/ietf
