Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 6:29 PM, Randy Bush wrote: There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. >>> >>> excuse me! >> >> Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But >> in my sampling, operators > > benson, > > vendors saying what operators want went *seriously* out of fashion a > couple of years back. we can speak for ourselves, tyvm. I agree completely. I'm responding to what I've heard from operators. Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
>>> There seems to be a position, taken by others on these lists, that >>> IPv6 is the only address family that matters. Interestingly, this >>> position seems to be most pronounced from people not involved in >>> operating production networks. >> >> excuse me! > > Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But > in my sampling, operators benson, vendors saying what operators want went *seriously* out of fashion a couple of years back. we can speak for ourselves, tyvm. randy
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 1:36 PM, Benson Schliesser wrote: > > On Feb 22, 2011, at 3:14 AM, Randy Bush wrote: > >>> There seems to be a position, taken by others on these lists, that >>> IPv6 is the only address family that matters. Interestingly, this >>> position seems to be most pronounced from people not involved in >>> operating production networks. >> >> excuse me! > > Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But in my > sampling, operators with the opinion that 'IPv4 doesn't matter' represent the > minority. Of course, it also depends on how you define "doesn't matter". I > think that ongoing operation matters, especially when "ongoing" means a > continued expectation of both existing and new customers. It's easy to say, > "burn the IPv4 bridge" so we're forced to migrate to IPv6. But it's another > thing to actually do it, when you're competing for customers that want IPv4 > connectivity. > We may be the minority, but, we have a lot more address space and no shortage of IP addresses. How many IPv4 providers can say that? > That said, we're not forced to choose only one: IPv4 vs. IPv6. We should > migrate to IPv6 because it makes sense - IPv4 is going to become more > expensive and painful (to use and support). That doesn't preclude us from > patching IPv4 together long enough to cross the bridge first. > > Thoughts? > Patching the deck chairs does not change the fact that the boat is sinking. I suggest focusing on getting in a life boat. Deck chairs don't float very well. IPv6 is a life boat. NAT444 and other IPv4 preservation hacks are deck chairs. You can rearrange them all you want. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 4:42 PM, Tony Hain wrote: > Seriously, some people will not move until the path they are on is already > burning, which is why they did nothing over the last 5 years despite knowing > that the IANA pool was exhausting much faster than they had wanted to > believe. It took getting within months of exhausting the IANA pool before > the crowd woke up and noticed the path was on fire. Now you want 'just a > little more'... after which it will be 'just a little more'. This won't go on forever. The "price" of IPv4 has been kept artificially low for the past decade, through a RIR-based system of rationing. There was never an immediate incentive to migrate. If we really wanted to motivate people before they reached the precipice, we should have increasingly raised the cost of an IPv4 address. Now, IPv4 exhaustion has effectively raised that cost for us, and people are motivated to migrate to IPv6. But since we didn't force this situation sooner, we now also have to deal with the effects of exhaustion. That's all I'm talking about. IPv4 hacks will not be better or cheaper than IPv6, and they're nothing to fear in terms of IPv6 adoption. Cheers, -Benson
RE: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
Benson Schliesser wrote: > On Feb 22, 2011, at 3:14 AM, Randy Bush wrote: > > >> There seems to be a position, taken by others on these lists, that > >> IPv6 is the only address family that matters. Interestingly, this > >> position seems to be most pronounced from people not involved in > >> operating production networks. > > > > excuse me! > > Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But > in my sampling, operators with the opinion that 'IPv4 doesn't matter' > represent the minority. Of course, it also depends on how you define > "doesn't matter". I think that ongoing operation matters, especially > when "ongoing" means a continued expectation of both existing and new > customers. It's easy to say, "burn the IPv4 bridge" so we're forced to > migrate to IPv6. But it's another thing to actually do it, when you're > competing for customers that want IPv4 connectivity. > > That said, we're not forced to choose only one: IPv4 vs. IPv6. We > should migrate to IPv6 because it makes sense - IPv4 is going to become > more expensive and painful (to use and support). That doesn't preclude > us from patching IPv4 together long enough to cross the bridge first. > > Thoughts? The patching started in 1994 with RFC 1627 how much time is needed??? Seriously, some people will not move until the path they are on is already burning, which is why they did nothing over the last 5 years despite knowing that the IANA pool was exhausting much faster than they had wanted to believe. It took getting within months of exhausting the IANA pool before the crowd woke up and noticed the path was on fire. Now you want 'just a little more'... after which it will be 'just a little more'. Fortunately Randy and a few others took action and demonstrated that 'this is not hard', it just takes some effort. Pouring more effort into hack upon hack is not making progress, it is stalling for the sake of stalling. Consumers don't want IPv4, they want connectivity to their favorite content. Hacks in the network to make that content appear to be available will be expensive to maintain, and irrelevant as soon as the content has realized the mess that has been made between them and their customers. More energy into moving content and apps will result in less energy wasted in deploying short lived hacks. Tony > > Cheers, > -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 3:40 AM, Owen DeLong wrote: >> There seems to be a position, taken by others on these lists, that IPv6 is >> the only address family that matters. Interestingly, this position seems to >> be most pronounced from people not involved in operating production >> networks. But, regardless, if I were to accept this position then I might >> also agree that it doesn't matter whether or not draft-donley-nat444-impacts >> is misleading. >> > I don't think anyone has said that IPv6 is the only address family > that matters. What I think people, myself included, have been saying > is that IPv6 is the only way forward that does not involve many of these > problems. (See my earlier Titanic post). I agree completely: IPv6 is the only way forward that avoids these problems. In fact, an understanding of CGN impacts should be enough motivation for operators and users to start deploying IPv6 immediately. > As to whether or not it matters that people misinterpred draft-donly..., > I'm not sure whether it actually does or not. There is no flavor of NAT > that is particularly desirable. It's a matter of choosing the one that is > least damaging to your environment where least damage may > boil down to a choice between 5% and 3% remaining functionality. I agree with your sentiment, that we should choose the least damaging solutions. Call it the "lesser evil" if you'd like. However, I think your estimates (5% vs 3%) are backwards. CGN-based solutions work for the vast majority of network traffic today - it's the stuff in the margin that breaks, according to all test reports I've seen. > I don't think anyone is saying IPv4 no longer matters. I think we are > saying that effort spent attempting to make the deteriorating IPv4 > situation deteriorate less is both futile and better spent on making > the IPv6 deployment situation better. It's not an exclusive situation - we can roll out IPv6 while continuing to maintain our existing IPv4 connectivity, support new customers with IPv4 needs, etc. As I mentioned before, we have to support the bridge we're crossing (crumbling IPv4 infrastructure) until we're on the other side (fertile IPv6 farmland). >> Of course, we can also rely on an IPv4 address market to avoid NAT in the >> more sensitive situations (i.e. situations with more sensitive users). But >> that's a different conversation. >> > Only if you expect that you can rely on a supply side in such a market. > I am unconvinced that such will be reliable, especially after about 6 > months of trading. This also presumes that more sensitive users can > be defined in terms of what those users are willing (or able) to pay. This is an interesting discussion, because the timeframe is central to everything I've commented above. Considering RIR exhaustion (4-12 months) plus ISP exhaustion (TBD, but let's say anywhere from 1 month to 5+ years after RIR exhaustion), I expect some network providers to struggle with IPv4 address exhaustion before the 3rd quarter of 2011. On the other hand, other network providers will have enough resources to last for years - let's call that "excess supply". By all realistic estimates, any network provider that hasn't deployed IPv6 support into their infrastructure will need anywhere from 3 months to 3 years or more - let's generously say around 18 months to the point where 60% - 80% of hosts have reached IPv6 connectivity. Just considering these facts, I think we can see why some ISPs might be interested in acquiring more addresses through 2012. And those with excess supply might be motivated (financially) by a marketplace to share their resources, to meet this need. Further, let's consider that some network services (such as content / hosting) will need IPv4 connectivity longer than others, in order to reach the long-tail. For this category, I can see why some networks might be interested in acquiring more addresses through 2013 - 2016. Fortunately, on the other side of 2012 prices should decrease because supply goes up (as some people give up IPv4). Thus the market value of an address probably can be represented by a curve peaking in a couple years and then declining to zero a few years after that. Feedback on this would be appreciated - but my current belief is that it's realistic to plan for a couple years of trading rather than "about 6 months". (Side note: If we really wanted people to move to IPv6 before now, we should have instituted increasing prices for RIR-provided addresses. I posit that we just didn't have the collective balls to do this.) Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 3:54 PM, valdis.kletni...@vt.edu wrote: > On Tue, 22 Feb 2011 02:29:23 CST, Benson Schliesser said: >> There seems to be a position, taken by others on these lists, that IPv6 >> is the only address family that matters. Interestingly, this position >> seems to be most pronounced from people not involved in operating >> production networks. > > "most pronounced from people not involved in operating production networks > that are way behind the planning curve for IPv6 deployment". > > There, fixed that for you. My original text remains true, because I tend to hear IPv6-only advocacy from vendors and policy folks more than operators - even more so versus operators of commercial ISP networks. But I take your point, that operators ahead of the IPv6 deployment curve are most likely to stand up with that opinion. Of course, the "network effect" being what it is... Your network being 100% IPv6 doesn't solve the overall problem of reachability. I think your example of 4% traffic from VT is applicable - you will have to worry about IPv4 connectivity, in one form or another, until it diminishes significantly. It's a bit like a tragedy of the commons. Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Tue, 22 Feb 2011 02:29:23 CST, Benson Schliesser said: > There seems to be a position, taken by others on these lists, that IPv6 > is the only address family that matters. Interestingly, this position > seems to be most pronounced from people not involved in operating > production networks. "most pronounced from people not involved in operating production networks that are way behind the planning curve for IPv6 deployment". There, fixed that for you. (Full disclosure - yesterday's MRTG graphs show our border routers averaging 4Gbit/sec of IPv4 traffic and 150 Mbits/sec of IPv6 - so 4% or so of our production off-campus traffic is already IPv6) pgpxDmfB4FE37.pgp Description: PGP signature
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 3:14 AM, Randy Bush wrote: >> There seems to be a position, taken by others on these lists, that >> IPv6 is the only address family that matters. Interestingly, this >> position seems to be most pronounced from people not involved in >> operating production networks. > > excuse me! Hi, Randy. I didn't mean to deny you exist; you apparently do. ;) But in my sampling, operators with the opinion that 'IPv4 doesn't matter' represent the minority. Of course, it also depends on how you define "doesn't matter". I think that ongoing operation matters, especially when "ongoing" means a continued expectation of both existing and new customers. It's easy to say, "burn the IPv4 bridge" so we're forced to migrate to IPv6. But it's another thing to actually do it, when you're competing for customers that want IPv4 connectivity. That said, we're not forced to choose only one: IPv4 vs. IPv6. We should migrate to IPv6 because it makes sense - IPv4 is going to become more expensive and painful (to use and support). That doesn't preclude us from patching IPv4 together long enough to cross the bridge first. Thoughts? Cheers, -Benson
RE: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
> -Original Message- > From: Chris Grundemann [mailto:cgrundem...@gmail.com] > Sent: Monday, February 21, 2011 8:17 PM > To: Dan Wing > Cc: Owen DeLong; Benson Schliesser; NANOG list; ARIN-PPML List > Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 > naysayer...) > > On Mon, Feb 21, 2011 at 19:08, Dan Wing wrote: > > > Its title, filename, abstract, and introduction all say the problems > > are specific to NAT444. Which is untrue. > > I just re-read the filename, abstract and introduction, and I disagree > that any of those say that the problems are specific to NAT444. They > all do state that these problems are present in NAT444, but not that > it's the only technology/scenario/configuration where you might find > them. > > More importantly, I am unsure the point of this argument. My point is that: NAT breaks things, but NAT444 is /not/ the only case where breakage occurs. > Are you > trying to say that the items listed as broken in the draft are not > actually broken? Because in my experience they are. IMHO, the fact > that they are also broken in other (similar) scenarios is not evidence > that they are not broken in this one. On the contrary, this scenario > seems to be evidence to the brokenness in the others (until we get a > chance to test and document them all - are you volunteering? ;). Vendor test results don't carry much value. The authors of draft-donley-nat444-impacts did testing, and I sincerely hope will publish results that split the impacts of access bandwidth starvation from home NAT from CGN from NAT444. -d > Cheers, > ~Chris > > > > -d > > > > > > > > > > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.theIPv6experts.net > www.coisoc.org
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 22, 2011, at 12:29 AM, Benson Schliesser wrote: > > On Feb 21, 2011, at 10:16 PM, Chris Grundemann wrote: > >> On Mon, Feb 21, 2011 at 19:08, Dan Wing wrote: >> >>> Its title, filename, abstract, and introduction all say the problems >>> are specific to NAT444. Which is untrue. >> >> I just re-read the filename, abstract and introduction, and I disagree >> that any of those say that the problems are specific to NAT444. They >> all do state that these problems are present in NAT444, but not that >> it's the only technology/scenario/configuration where you might find >> them. > > Let's at least agree that the text isn't precise. I've had a large number of > conversations in which relatively intelligent people advocated other > (non-NAT444) scenarios involving CGN, built on the premise that NAT444 is > broken and draft-donley-nat444-impacts is evidence. Either the draft is > perfectly clear and all of these people are stupid, or the draft is > misleading (intentionally or unintentionally). > I would point out to them that the fact that their technology choice isn't NAT 444 does not mean that they don't have the same problems, merely that their technology wasn't part of the testing documented in the draft. I think the draft is perfectly clear and that humans, even intelligent humans often have problems with this level of logic. If A is a subset of B, it does not mean that A is not a subset of C. Therefore, a draft that states that technology B has problem A is not and cannot be logically construed as a statement that technology C does not have problem A, no matter how common it is for seemingly intelligent humans to make the mistake of doing so. >> More importantly, I am unsure the point of this argument. Are you >> trying to say that the items listed as broken in the draft are not >> actually broken? Because in my experience they are. IMHO, the fact >> that they are also broken in other (similar) scenarios is not evidence >> that they are not broken in this one. On the contrary, this scenario >> seems to be evidence to the brokenness in the others (until we get a >> chance to test and document them all - are you volunteering? ;). > > There seems to be a position, taken by others on these lists, that IPv6 is > the only address family that matters. Interestingly, this position seems to > be most pronounced from people not involved in operating production networks. > But, regardless, if I were to accept this position then I might also agree > that it doesn't matter whether or not draft-donley-nat444-impacts is > misleading. > I don't think anyone has said that IPv6 is the only address family that matters. What I think people, myself included, have been saying is that IPv6 is the only way forward that does not involve many of these problems. (See my earlier Titanic post). As to whether or not it matters that people misinterpred draft-donly..., I'm not sure whether it actually does or not. There is no flavor of NAT that is particularly desirable. It's a matter of choosing the one that is least damaging to your environment where least damage may boil down to a choice between 5% and 3% remaining functionality. > On the contrary: While I emphatically agree that IPv6 is the path forward, I > don't accept the notion that IPv4 no longer matters. IPv4 is the present-day > Internet, and IPv4 connectivity is demanded by present-day paying customers - > you don't burn the bridge until *after* you've crossed it. Further, given > that IPv4 does matter yet has an exhausted address supply, there exists a > need for IPv4 address sharing technology. Fundamentally, this means that we > need to discuss and engineer the best possible address sharing technology. > It may never be as good as native end-to-end IPv6, but sub-optimal is not the > same thing as "broken" as others have claimed, and sub-optimal might be > acceptable if it's the only alternative. > I don't think anyone is saying IPv4 no longer matters. I think we are saying that effort spent attempting to make the deteriorating IPv4 situation deteriorate less is both futile and better spent on making the IPv6 deployment situation better. > Of course, we can also rely on an IPv4 address market to avoid NAT in the > more sensitive situations (i.e. situations with more sensitive users). But > that's a different conversation. > Only if you expect that you can rely on a supply side in such a market. I am unconvinced that such will be reliable, especially after about 6 months of trading. This also presumes that more sensitive users can be defined in terms of what those users are willing (or able) to pay. Owen (who is very glad he has provider-independent addresses in both families as we approach this iceberg)
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
[ arin cesspool removed from cc: as i can not post there anyway ] > There seems to be a position, taken by others on these lists, that > IPv6 is the only address family that matters. Interestingly, this > position seems to be most pronounced from people not involved in > operating production networks. excuse me! randy
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 21, 2011, at 10:16 PM, Chris Grundemann wrote: > On Mon, Feb 21, 2011 at 19:08, Dan Wing wrote: > >> Its title, filename, abstract, and introduction all say the problems >> are specific to NAT444. Which is untrue. > > I just re-read the filename, abstract and introduction, and I disagree > that any of those say that the problems are specific to NAT444. They > all do state that these problems are present in NAT444, but not that > it's the only technology/scenario/configuration where you might find > them. Let's at least agree that the text isn't precise. I've had a large number of conversations in which relatively intelligent people advocated other (non-NAT444) scenarios involving CGN, built on the premise that NAT444 is broken and draft-donley-nat444-impacts is evidence. Either the draft is perfectly clear and all of these people are stupid, or the draft is misleading (intentionally or unintentionally). > More importantly, I am unsure the point of this argument. Are you > trying to say that the items listed as broken in the draft are not > actually broken? Because in my experience they are. IMHO, the fact > that they are also broken in other (similar) scenarios is not evidence > that they are not broken in this one. On the contrary, this scenario > seems to be evidence to the brokenness in the others (until we get a > chance to test and document them all - are you volunteering? ;). There seems to be a position, taken by others on these lists, that IPv6 is the only address family that matters. Interestingly, this position seems to be most pronounced from people not involved in operating production networks. But, regardless, if I were to accept this position then I might also agree that it doesn't matter whether or not draft-donley-nat444-impacts is misleading. On the contrary: While I emphatically agree that IPv6 is the path forward, I don't accept the notion that IPv4 no longer matters. IPv4 is the present-day Internet, and IPv4 connectivity is demanded by present-day paying customers - you don't burn the bridge until *after* you've crossed it. Further, given that IPv4 does matter yet has an exhausted address supply, there exists a need for IPv4 address sharing technology. Fundamentally, this means that we need to discuss and engineer the best possible address sharing technology. It may never be as good as native end-to-end IPv6, but sub-optimal is not the same thing as "broken" as others have claimed, and sub-optimal might be acceptable if it's the only alternative. Of course, we can also rely on an IPv4 address market to avoid NAT in the more sensitive situations (i.e. situations with more sensitive users). But that's a different conversation. Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Mon, Feb 21, 2011 at 19:08, Dan Wing wrote: > Its title, filename, abstract, and introduction all say the problems > are specific to NAT444. Which is untrue. I just re-read the filename, abstract and introduction, and I disagree that any of those say that the problems are specific to NAT444. They all do state that these problems are present in NAT444, but not that it's the only technology/scenario/configuration where you might find them. More importantly, I am unsure the point of this argument. Are you trying to say that the items listed as broken in the draft are not actually broken? Because in my experience they are. IMHO, the fact that they are also broken in other (similar) scenarios is not evidence that they are not broken in this one. On the contrary, this scenario seems to be evidence to the brokenness in the others (until we get a chance to test and document them all - are you volunteering? ;). Cheers, ~Chris > -d > > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org
RE: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
> >> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 > > That document conflates problems of NAT444 with problems of NAT44 > > with problems of bandwidth starvation with problems of CGN. > > it may require a delicate palate to differentiate the different flavors > of Running out of bandwidth for Netflix is pretty distinct from the flavor of fried gNAT. -d
RE: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
> -Original Message- > From: Owen DeLong [mailto:o...@delong.com] > Sent: Monday, February 21, 2011 12:59 PM > To: Dan Wing > Cc: 'Chris Grundemann'; 'Benson Schliesser'; 'NANOG list'; 'ARIN-PPML > List' > Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 > naysayer...) > > > On Feb 21, 2011, at 12:37 PM, Dan Wing wrote: > > >> -Original Message- > >> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] > On > >> Behalf Of Chris Grundemann > >> Sent: Thursday, February 17, 2011 5:55 PM > >> To: Benson Schliesser > >> Cc: NANOG list; ARIN-PPML List > >> Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 > >> naysayer...) > >> > >> On Thu, Feb 10, 2011 at 14:17, Benson Schliesser > >> wrote: > >> > >>> If you have more experience (not including rumors) that suggests > >> otherwise, I'd very much like to hear about it. I'm open to the > >> possibility that NAT444 breaks stuff - that feels right in my gut - > but > >> I haven't found any valid evidence of this. > >> > >> In case you have not already found this: > >> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 > > > > That document conflates problems of NAT444 with problems of NAT44 > > with problems of bandwidth starvation with problems of CGN. > > > > For details, see my comments at > > http://www.ietf.org/mail-archive/web/behave/current/msg09027.html > > and see Reinaldo Penno's comments at > > http://www.ietf.org/mail-archive/web/behave/current/msg09030.html > > > > -d > > The document describes problems that will exist in NAT444 environments. > It does not state that these problems would be specific to NAT444, but, > NAT444 will cause or exacerbate each of the problems described. To the contrary. Its title, filename, abstract, and introduction all say the problems are specific to NAT444. Which is untrue. > Yes, the problems may have other underlying root causes, but, they > will all be present in a NAT444 environment, even if they were not > present in the same environment prior to deployment of NAT444. > > > Let me put it this way... > > IPv4 has a TITANIC lack of numeric addresses and has been > stretched beyond its limits for some time now. > > IPv6 is a life boat. > > NAT is a seat cushion used for floatation. > > NAT444 (and other NAT-based extensions) are deck chairs. > > Attempting to improve them beyond their current states is > an effort to rearrange the deck chairs. -d
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
>> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 > That document conflates problems of NAT444 with problems of NAT44 > with problems of bandwidth starvation with problems of CGN. it may require a delicate palate to differentiate the different flavors of randy
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 21, 2011, at 12:37 PM, Dan Wing wrote: >> -Original Message- >> From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On >> Behalf Of Chris Grundemann >> Sent: Thursday, February 17, 2011 5:55 PM >> To: Benson Schliesser >> Cc: NANOG list; ARIN-PPML List >> Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 >> naysayer...) >> >> On Thu, Feb 10, 2011 at 14:17, Benson Schliesser >> wrote: >> >>> If you have more experience (not including rumors) that suggests >> otherwise, I'd very much like to hear about it. I'm open to the >> possibility that NAT444 breaks stuff - that feels right in my gut - but >> I haven't found any valid evidence of this. >> >> In case you have not already found this: >> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 > > That document conflates problems of NAT444 with problems of NAT44 > with problems of bandwidth starvation with problems of CGN. > > For details, see my comments at > http://www.ietf.org/mail-archive/web/behave/current/msg09027.html > and see Reinaldo Penno's comments at > http://www.ietf.org/mail-archive/web/behave/current/msg09030.html > > -d > The document describes problems that will exist in NAT444 environments. It does not state that these problems would be specific to NAT444, but, NAT444 will cause or exacerbate each of the problems described. Yes, the problems may have other underlying root causes, but, they will all be present in a NAT444 environment, even if they were not present in the same environment prior to deployment of NAT444. Let me put it this way... IPv4 has a TITANIC lack of numeric addresses and has been stretched beyond its limits for some time now. IPv6 is a life boat. NAT is a seat cushion used for floatation. NAT444 (and other NAT-based extensions) are deck chairs. Attempting to improve them beyond their current states is an effort to rearrange the deck chairs. Owen
RE: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
> -Original Message- > From: arin-ppml-boun...@arin.net [mailto:arin-ppml-boun...@arin.net] On > Behalf Of Chris Grundemann > Sent: Thursday, February 17, 2011 5:55 PM > To: Benson Schliesser > Cc: NANOG list; ARIN-PPML List > Subject: Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 > naysayer...) > > On Thu, Feb 10, 2011 at 14:17, Benson Schliesser > wrote: > > > If you have more experience (not including rumors) that suggests > otherwise, I'd very much like to hear about it. I'm open to the > possibility that NAT444 breaks stuff - that feels right in my gut - but > I haven't found any valid evidence of this. > > In case you have not already found this: > http://tools.ietf.org/html/draft-donley-nat444-impacts-01 That document conflates problems of NAT444 with problems of NAT44 with problems of bandwidth starvation with problems of CGN. For details, see my comments at http://www.ietf.org/mail-archive/web/behave/current/msg09027.html and see Reinaldo Penno's comments at http://www.ietf.org/mail-archive/web/behave/current/msg09030.html -d > Cheers, > ~Chris > > > > > Regardless, I think we can agree that IPv6 is the way to avoid NAT- > related growing pains. We've known this for a long time. > > > > Cheers, > > -Benson > > > > ___ > > PPML > > You are receiving this message because you are subscribed to > > the ARIN Public Policy Mailing List (arin-p...@arin.net). > > Unsubscribe or manage your mailing list subscription at: > > http://lists.arin.net/mailman/listinfo/arin-ppml > > Please contact i...@arin.net if you experience any issues. > > > > > > > > > -- > @ChrisGrundemann > weblog.chrisgrundemann.com > www.burningwiththebush.com > www.theIPv6experts.net > www.coisoc.org > ___ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (arin-p...@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues.
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 20, 2011, at 10:35 PM, Jimmy Hess wrote: > On Fri, Feb 18, 2011 at 2:24 AM, Zed Usser wrote: >> Basic Internet services will work (web browsing, email, Facebook, >> Youtube,...), but: Actually, many facebook and youtube features will also be degraded. >> - Less torrenting >> - Less Netflix watching >> - Less FTP downloads >> - Less video streaming in general (webcams, etc.) >> You might take a hit on online gaming, but what else is there not to love? :) > You're joking, right? I don't think that most customers are going to take kindly to having their internet experience on their computer(s) reduced to what they expect from their cell phone. >> Your sales department / helpdesk might have a bit of hassle of trying to >> undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but >> most of them won't care either way. > > Until some competitor who's not using NAT444 comes along and > advertises that those functions work properly, maybe. > Only for very liberal definitions of the phrase "won't care either way" > > Tolerate != won't care > Most of them != People who won't eventually tell their friends or > tweet about their frustrations > Nah... Just make sure tweeting is one of the things you break along with the rest of the itner-tubes. (joking, of course). > > For those who are connecting to watch Netflix, it is only marginally > less annoying for the user than > removing the "always on" feature of DSL, requiring customers to > manually click an icon to dial in, > and get a busy tone played / "All dialin 'lines are busy'" / "Please > use IPv6 while you wait, > wait 10 minutes and try dialing in again", if there are no global > IPv4 IPs available at the moment > they are trying to connect. > As long as you give them IPv6, their Netflix and Youtube will work. > Some might even strongly prefer that (time limited access and pay > per connected hour) > for periods of access to proper unique IPs over NAT444 brokenness; > You guys are making me very very glad that I: 1. Do not depend on my provider for IPv4 addresses. 2. Have a fully dual-stack environment at home. 3. Do not depend on my residential provider to deliver anything more than the ability to shove GRE across the internet encapsulated in whatever protocol (v4/v6) works at the time. > possibly with a customer choice between NAT444 and "time metered > dynamic unique IP" and reasonably > automatic simple means of switching between IP types on demand. > I encourage my competitors to try this. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Fri, Feb 18, 2011 at 2:24 AM, Zed Usser wrote: > Basic Internet services will work (web browsing, email, Facebook, > Youtube,...), but: > - Less torrenting > - Less Netflix watching > - Less FTP downloads > - Less video streaming in general (webcams, etc.) > You might take a hit on online gaming, but what else is there not to love? :) > Your sales department / helpdesk might have a bit of hassle of trying to > undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but > most of them won't care either way. Until some competitor who's not using NAT444 comes along and advertises that those functions work properly, maybe. Only for very liberal definitions of the phrase "won't care either way" Tolerate != won't care Most of them != People who won't eventually tell their friends or tweet about their frustrations For those who are connecting to watch Netflix, it is only marginally less annoying for the user than removing the "always on" feature of DSL, requiring customers to manually click an icon to dial in, and get a busy tone played / "All dialin 'lines are busy'" / "Please use IPv6 while you wait, wait 10 minutes and try dialing in again", if there are no global IPv4 IPs available at the moment they are trying to connect. Some might even strongly prefer that (time limited access and pay per connected hour) for periods of access to proper unique IPs over NAT444 brokenness; possibly with a customer choice between NAT444 and "time metered dynamic unique IP" and reasonably automatic simple means of switching between IP types on demand. -- -JH
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 20, 2011, at 3:27 AM, Zed Usser wrote: > --- On Sun, 2/20/11, Owen DeLong wrote: >> Oh, I expect CGN/LSN to be connectivity of last resort, no >> question. > Ok, so let's just deploy it and not even try to fix it? Even when it is a > required functionality for IPv6-only hosts to access the IPv4 domain? That'll > go down real well with end-users and really cut down on the operational and > support issues enumerated earlier. > > - Zed > > > Again, I think that it is unfixable and that development efforts are better focused on getting the IPv4 only hosts onto IPv6 as that IS a workable solution to the problem where NAT444 is an awful hack made worse by layering. IPv6 deployment is the only thing that will cut down on the operational and support issues enumerated. Trying to fix NAT444 is like trying to use more gas to get yourself out of the mud in a 2-wheel drive automobile. If you take a limited view, you might think that pushing harder will help, but, in reality, you're just digging a deeper hole. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
--- On Sun, 2/20/11, Owen DeLong wrote: > Oh, I expect CGN/LSN to be connectivity of last resort, no > question. Ok, so let's just deploy it and not even try to fix it? Even when it is a required functionality for IPv6-only hosts to access the IPv4 domain? That'll go down real well with end-users and really cut down on the operational and support issues enumerated earlier. - Zed
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 19, 2011, at 11:31 AM, Zed Usser wrote: > --- On Sun, 2/20/11, Owen DeLong wrote: >>> So, in essence, you are advocating not to >>> interconnect the IPv4-only and IPv6-only domains in any way? >> >> I'm advocating not depending on any such interaction >> working as it's pretty clear that >> the available solution set is fairly broken. > Fair enough. This approach will, however, relegate IPv6-only networks to > second class citizenship status. Access to the "real" Internet will require > IPv4 and IPv6-only will be seen as the inferior choice, to be avoided as best > as you can. Not quite a ringing endorsement for IPv6, in other words. > > This position also assumes that there will be enough IPv4 addresses to go > around for everybody to dual stack. Anybody not so fortunate will simply be > left out in the cold. > > - Zed > > > Oh, I expect CGN/LSN to be connectivity of last resort, no question. However, I don't expect it to work. I don't expect us to be able to resolve the issues with it, and I expect that to fairly rapidly serve as motivation for content providers to adopt IPv6. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
--- On Sun, 2/20/11, Owen DeLong wrote: >> So, in essence, you are advocating not to >> interconnect the IPv4-only and IPv6-only domains in any way? > > I'm advocating not depending on any such interaction > working as it's pretty clear that > the available solution set is fairly broken. Fair enough. This approach will, however, relegate IPv6-only networks to second class citizenship status. Access to the "real" Internet will require IPv4 and IPv6-only will be seen as the inferior choice, to be avoided as best as you can. Not quite a ringing endorsement for IPv6, in other words. This position also assumes that there will be enough IPv4 addresses to go around for everybody to dual stack. Anybody not so fortunate will simply be left out in the cold. - Zed
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 19, 2011, at 12:41 AM, Zed Usser wrote: > --- On Sat, 2/19/11, Owen DeLong wrote: >>> Are you willing to bet that IPv4 address >> exhaustion will not result in IPv6-only hosts before we run >> out of meaningful IPv4-only hosts? >> No, but, I am willing to bet that we will not meaningfully >> make the situation better for those IPv4-only hosts or the IPv6-only >> hosts attempting to reach them by any mechanism more efficient >> than encouraging them to add IPv6 capability, whether or not >> that happens after the fact. > So, in essence, you are advocating not to interconnect the IPv4-only and > IPv6-only domains in any way? > > - Zed > > > > I'm advocating not depending on any such interaction working as it's pretty clear that the available solution set is fairly broken. I'm advocating not expending significant development resources on enhancing that situation when it's pretty clear they are better spent facilitating IPv6 deployment to obviate the need for this level of hackery. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
--- On Sat, 2/19/11, Owen DeLong wrote: > > Are you willing to bet that IPv4 address > exhaustion will not result in IPv6-only hosts before we run > out of meaningful IPv4-only hosts? > No, but, I am willing to bet that we will not meaningfully > make the situation better for those IPv4-only hosts or the IPv6-only > hosts attempting to reach them by any mechanism more efficient > than encouraging them to add IPv6 capability, whether or not > that happens after the fact. So, in essence, you are advocating not to interconnect the IPv4-only and IPv6-only domains in any way? - Zed
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 5:59 PM, Chris Grundemann wrote: > On Fri, Feb 18, 2011 at 16:48, Benson Schliesser > wrote: >> >> I agree that it's an imperfect analogy, so I won't bother defending it. :) >> But my point remains: NAT444 is a deployment scenario, which includes a CGN >> element. Other deployment scenarios that also include a CGN element will >> have the same issues, and perhaps more. And, indeed, a number of >> "transition" (i.e. exhaustion) scenarios include a CGN. Thus it is >> appropriate to focus on the root of the problem (CGN) rather than pointing >> at just one scenario that leverages it. > > That I'll agree with. It seems to me that what's called for is an > expansion of the tests done for the draft in question to include > other, currently in-vogue, CGN/LSN technologies. > That's a serious expansion to the testing matrix. I would rather see those other technologies get their own draft with their own testing matrix as this is far more likely to be achievable. >> So... I agree that CGN is painful, relative to native connectivity and even >> relative to CPE-based NAT44. But I'd like to understand why NAT444 is >> better or worse than other CGN-based scenarios, before I agree with that >> conclusion. > > That wasn't the conclusion I drew, can't speak for others of course. > My conclusion is that CGN/LSN is broken, as evidenced by brokenness in > NAT444. I agree that a comparison of all (or some reasonable subset of > all) LSN technologies would be valuable, especially as folks may begin > to be forced to choose one. For now I stick with the ideal: Avoid if > possible. (Dual-stack early, dual-stack often?) > Agreed. >>> If we get dual v4+v6 connectivity quickly enough, we do not need LSN >>> (including NAT444). >> >> Amen, brother. I guess I'm just pessimistic about the definition of >> "quickly" versus operationally realistic timeframes. > > Fair enough, I still have hope. =) > ~Chris > My thinking is that faced with disconnection after the fact suddenly causing me to choose between restoration by dual stacking vs. restoration by NAT444 (or almost any other form of LSN) leads any sane person to restoration by dual stacking. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Fri, Feb 18, 2011 at 16:48, Benson Schliesser wrote: > > I agree that it's an imperfect analogy, so I won't bother defending it. :) > But my point remains: NAT444 is a deployment scenario, which includes a CGN > element. Other deployment scenarios that also include a CGN element will > have the same issues, and perhaps more. And, indeed, a number of > "transition" (i.e. exhaustion) scenarios include a CGN. Thus it is > appropriate to focus on the root of the problem (CGN) rather than pointing at > just one scenario that leverages it. That I'll agree with. It seems to me that what's called for is an expansion of the tests done for the draft in question to include other, currently in-vogue, CGN/LSN technologies. > So... I agree that CGN is painful, relative to native connectivity and even > relative to CPE-based NAT44. But I'd like to understand why NAT444 is better > or worse than other CGN-based scenarios, before I agree with that conclusion. That wasn't the conclusion I drew, can't speak for others of course. My conclusion is that CGN/LSN is broken, as evidenced by brokenness in NAT444. I agree that a comparison of all (or some reasonable subset of all) LSN technologies would be valuable, especially as folks may begin to be forced to choose one. For now I stick with the ideal: Avoid if possible. (Dual-stack early, dual-stack often?) >> If we get dual v4+v6 connectivity quickly enough, we do not need LSN >> (including NAT444). > > Amen, brother. I guess I'm just pessimistic about the definition of > "quickly" versus operationally realistic timeframes. Fair enough, I still have hope. =) ~Chris > Cheers, > -Benson > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 5:27 PM, Chris Grundemann wrote: > On Fri, Feb 18, 2011 at 16:07, Benson Schliesser > wrote: > >> Broken DNS will result in problems browsing the web. That doesn't make it >> accurate to claim that the web is broken, and it's particularly weak support >> for claims that email would work better. > > I don't think that's a great analogy. NAT444 is CGN, the web is not > DNS. If I say I can chop down a tree with a red ax, can you disprove > that by saying that you can chop it down with any color ax? I agree that it's an imperfect analogy, so I won't bother defending it. :) But my point remains: NAT444 is a deployment scenario, which includes a CGN element. Other deployment scenarios that also include a CGN element will have the same issues, and perhaps more. And, indeed, a number of "transition" (i.e. exhaustion) scenarios include a CGN. Thus it is appropriate to focus on the root of the problem (CGN) rather than pointing at just one scenario that leverages it. So... I agree that CGN is painful, relative to native connectivity and even relative to CPE-based NAT44. But I'd like to understand why NAT444 is better or worse than other CGN-based scenarios, before I agree with that conclusion. > If we get dual v4+v6 connectivity quickly enough, we do not need LSN > (including NAT444). Amen, brother. I guess I'm just pessimistic about the definition of "quickly" versus operationally realistic timeframes. Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Fri, Feb 18, 2011 at 16:07, Benson Schliesser wrote: > Broken DNS will result in problems browsing the web. That doesn't make it > accurate to claim that the web is broken, and it's particularly weak support > for claims that email would work better. I don't think that's a great analogy. NAT444 is CGN, the web is not DNS. If I say I can chop down a tree with a red ax, can you disprove that by saying that you can chop it down with any color ax? > Well, if your user does nothing but send email then perhaps even UUCP would > be good enough. But for the rest of us, until IPv6 penetration reaches all > the content/services we care about, we need dual v4+v6 connectivity. If we get dual v4+v6 connectivity quickly enough, we do not need LSN (including NAT444). Cheers, ~Chris > Cheers, > -Benson > > > > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 4:46 PM, Owen DeLong wrote: > On Feb 18, 2011, at 2:26 PM, Benson Schliesser wrote: >> The document is titled "Assessing the Impact of NAT444 on Network >> Applications" and it claims to discuss NAT444 issues. However, it conflates >> NAT444 with CGN. And it is often used as an explanation for supporting >> alternative technology such as DS-lite, even though DS-lite also leverages >> CGN. This line of reasoning is broken and, as I've stated already, I'm >> waiting for somebody to offer evidence that NAT444 is more problematic than >> CGN. >> > NAT444 is one implementation of CGN and the issues it describes all apply to > NAT444. > > It does not claim that it discusses issues unique to NAT444. It claims that > all of the issues it discusses > apply to NAT444. That claim is accurate. You continue to conflate NAT444 and CGN. I'm not sure I can say anything that hasn't already been said, but perhaps an example will help: Broken DNS will result in problems browsing the web. That doesn't make it accurate to claim that the web is broken, and it's particularly weak support for claims that email would work better. >> Yes. And today's customers enjoy being able to communicate with the IPv4 >> Internet. CGN may be sub-optimal, but it's the lesser of two evils >> (disconnection being the other choice). >> > I remain unconvinced of the accuracy of this statement. Well, if your user does nothing but send email then perhaps even UUCP would be good enough. But for the rest of us, until IPv6 penetration reaches all the content/services we care about, we need dual v4+v6 connectivity. Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 2:26 PM, Benson Schliesser wrote: > > On Feb 18, 2011, at 8:27 AM, Owen DeLong wrote: > >> On Feb 18, 2011, at 12:24 AM, Zed Usser wrote: >>> >>> There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list. >>> >>> "draft-donley-nat444-impacts-01 is somewhat misleading. It claims to >>> analyze NAT444, but it really analyzes what fails when two problems occur: >>> (a) port forwarding isn't configured and (b) UPnP is unavailable or is >>> broken. Several architectures share those two problems: >>> >>> * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) >>> * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) >>> * DS-Lite (which is an LSN / NAPT44 in the carrier's network) >>> * stateful NAT64" >>> >> >> I don't think the draft makes any attempt to claim that the problems are >> unique to NAT444, so, the above, while >> technically accurate isn't particulrarly meaningful. > > The document is titled "Assessing the Impact of NAT444 on Network > Applications" and it claims to discuss NAT444 issues. However, it conflates > NAT444 with CGN. And it is often used as an explanation for supporting > alternative technology such as DS-lite, even though DS-lite also leverages > CGN. This line of reasoning is broken and, as I've stated already, I'm > waiting for somebody to offer evidence that NAT444 is more problematic than > CGN. > NAT444 is one implementation of CGN and the issues it describes all apply to NAT444. It does not claim that it discusses issues unique to NAT444. It claims that all of the issues it discusses apply to NAT444. That claim is accurate. > >>> http://www.ietf.org/mail-archive/web/behave/current/msg09027.html >>> >>> Be that as it may and putting my devil's advocate hat on, aren't the >>> unintended consequences of NAT444 a net win for ISPs? :) >>> >> I guess that depends on whether you like having customers or not. > > Yes. And today's customers enjoy being able to communicate with the IPv4 > Internet. CGN may be sub-optimal, but it's the lesser of two evils > (disconnection being the other choice). > I remain unconvinced of the accuracy of this statement. > Of course, tomorrow morning's customers will enjoy communicating with the > IPv6 Internet even more, so as somebody else already said: deploy IPv6 > alongside any CGN solution. > Absolutely. Also, I think the intent of the draft is to serve as a further heads-up to content and application providers that their customer experience in a NAT-444 environment is going to suck and they need to deploy IPv6. Further, it also serves to provide a guide for help-desks to deal with the consequences of having deployed a NAT444 solution in their network. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 12:50 PM, Zed Usser wrote: > --- On Sat, 2/19/11, Owen DeLong wrote: >> You only need to solve those problems to the >> extent that there are meaningful things still >> trapped in an IPv4-only world. > Are you willing to bet that IPv4 address exhaustion will not result in > IPv6-only hosts before we run out of meaningful IPv4-only hosts? > > - Zed > > > No, but, I am willing to bet that we will not meaningfully make the situation better for those IPv4-only hosts or the IPv6-only hosts attempting to reach them by any mechanism more efficient than encouraging them to add IPv6 capability, whether or not that happens after the fact. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 8:27 AM, Owen DeLong wrote: > On Feb 18, 2011, at 12:24 AM, Zed Usser wrote: >> >> There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list. >> >> "draft-donley-nat444-impacts-01 is somewhat misleading. It claims to >> analyze NAT444, but it really analyzes what fails when two problems occur: >> (a) port forwarding isn't configured and (b) UPnP is unavailable or is >> broken. Several architectures share those two problems: >> >> * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) >> * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) >> * DS-Lite (which is an LSN / NAPT44 in the carrier's network) >> * stateful NAT64" >> > > I don't think the draft makes any attempt to claim that the problems are > unique to NAT444, so, the above, while > technically accurate isn't particulrarly meaningful. The document is titled "Assessing the Impact of NAT444 on Network Applications" and it claims to discuss NAT444 issues. However, it conflates NAT444 with CGN. And it is often used as an explanation for supporting alternative technology such as DS-lite, even though DS-lite also leverages CGN. This line of reasoning is broken and, as I've stated already, I'm waiting for somebody to offer evidence that NAT444 is more problematic than CGN. >> http://www.ietf.org/mail-archive/web/behave/current/msg09027.html >> >> Be that as it may and putting my devil's advocate hat on, aren't the >> unintended consequences of NAT444 a net win for ISPs? :) >> > I guess that depends on whether you like having customers or not. Yes. And today's customers enjoy being able to communicate with the IPv4 Internet. CGN may be sub-optimal, but it's the lesser of two evils (disconnection being the other choice). Of course, tomorrow morning's customers will enjoy communicating with the IPv6 Internet even more, so as somebody else already said: deploy IPv6 alongside any CGN solution. Cheers, -Benson
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
--- On Sat, 2/19/11, Owen DeLong wrote: > You only need to solve those problems to the > extent that there are meaningful things still > trapped in an IPv4-only world. Are you willing to bet that IPv4 address exhaustion will not result in IPv6-only hosts before we run out of meaningful IPv4-only hosts? - Zed
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Fri, Feb 18, 2011 at 10:34 AM, Zed Usser wrote: > Reduce, yes. Remove, no. Without a global cutoff date for the IPv6 > transition, it's not like IPv4 is going to disappear overnight. Furthermore, > without any IPv4/IPv6 translation, the first IPv6 only networks are going to > be awfully lonely. I suspect Google, Microsoft, and others have already figured out a beneficial (to everyone) way to monetize this. If I'm an ISP with working IPv6, and my competitor in a given region is an ISP without IPv6, I'd like to advertise to all the end-users of that ISP whenever they go to a search engine that sells ads. Since these search engine companies have figured out white-listing users into "good IPv6," it's no great leap to suggest that they'll eventually black-list IPv4 users into "bad," and tie that into their advertising system for ISPs to purchase nicely-targeted banners/links. If my ISP is reading this, please tell both your residential and business technical and sales departments to come up with a better answer than "we are not going to support IPv6 because that's only for ISPs that run out of IPv4." Otherwise, I'd bet Google will be more than willing to let your competitors give customers a different answer in the near future! -- Jeff S Wheeler Sr Network Operator / Innovative Network Concepts
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 7:34 AM, Zed Usser wrote: > --- On Fri, 2/18/11, Owen DeLong wrote: > >>> Now correct me if I'm wrong, but isn't some kind of >> NAT/PAT going to be required to join the IPv4 and IPv6 >> domains in all foreseeable futures? If so, aren't we going >> to have to deal with these issues in any case? >>> >> No, we need to move forward with IPv6 on all levels in >> order to reduce the need for these solutions. > Reduce, yes. Remove, no. Without a global cutoff date for the IPv6 > transition, it's not like IPv4 is going to disappear overnight. Furthermore, > without any IPv4/IPv6 translation, the first IPv6 only networks are going to > be awfully lonely. > That depends on the number of IPv4 only networks vs. dual stack networks when that happens. >> Joining the IPv4/IPv6 domains doesn't work out all that >> well and a dependency on doing so is >> broken in a number of ways, many of which are documented in >> the draft. > We agree that IPv4/IPv6 domain interoperability is broken, but it's not like > we can ignore the issue. So, unless I'm very much mistaken, the NAT/PAT > issues are going to have to be dealt with. Or do you propose an alternative > solution? > Dual stacking all the IPv4 networks is the alternative solution. Initially it will be the IPv6 only users that are lonely. Relatively quickly, it will be the IPv4 only networks that are lonely as the bulk of users will, I suspect, become IPv6 preferred relatively quickly once there is no more IPv4 at the RIR level. > Please note that this is not an anti-IPv6 stance. To me it looks like the > problems plaguing NAT444 need to be solved just to make IPv4 and IPv6 > co-exist. Perhaps not the very same problems, but similar NAT/PAT problems in > any case. Please do tell me I'm wrong. Bonus points for explaining why I am > wrong or how the IPv4/IPv6 thing is to be solved without NAT/PAT. > I think that effort spent trying to solve those problems is better spent moving existing IPv4 things forward to dual stack. You only need to solve those problems to the extent that there are meaningful things still trapped in an IPv4-only world. Move them to dual stack and the problem goes away. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
--- On Fri, 2/18/11, Owen DeLong wrote: > > Now correct me if I'm wrong, but isn't some kind of > NAT/PAT going to be required to join the IPv4 and IPv6 > domains in all foreseeable futures? If so, aren't we going > to have to deal with these issues in any case? > > > No, we need to move forward with IPv6 on all levels in > order to reduce the need for these solutions. Reduce, yes. Remove, no. Without a global cutoff date for the IPv6 transition, it's not like IPv4 is going to disappear overnight. Furthermore, without any IPv4/IPv6 translation, the first IPv6 only networks are going to be awfully lonely. > Joining the IPv4/IPv6 domains doesn't work out all that > well and a dependency on doing so is > broken in a number of ways, many of which are documented in > the draft. We agree that IPv4/IPv6 domain interoperability is broken, but it's not like we can ignore the issue. So, unless I'm very much mistaken, the NAT/PAT issues are going to have to be dealt with. Or do you propose an alternative solution? Please note that this is not an anti-IPv6 stance. To me it looks like the problems plaguing NAT444 need to be solved just to make IPv4 and IPv6 co-exist. Perhaps not the very same problems, but similar NAT/PAT problems in any case. Please do tell me I'm wrong. Bonus points for explaining why I am wrong or how the IPv4/IPv6 thing is to be solved without NAT/PAT. - Zed
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 3:33 AM, Andrew Yourtchenko wrote: > On Fri, Feb 18, 2011 at 9:24 AM, Zed Usser wrote: > >> Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be >> required to join the IPv4 and IPv6 >> domains in all foreseeable futures? If so, aren't we going to have to deal >> with these issues in any case? > > I'd compare it with borrowing some money: > > When you make NAT64 to reach from IPv6 to IPv4, you are borrowing the > money to build a new house. > When you make NAT444, you borrow the money to repay the debt you made > by borrowing the previous month. > > Both are borrowing. > > Depending on the circumstances you may need both. > > cheers, > andrew If you are in a circumstance where you need to borrow money this month to repay your debt from last month, then, generally, you are on the fast track to bankruptcy court or a congressional investigation, perhaps both, depending on the size of debt snowball you are able to build. In the first case, you borrow money to leverage equity and there is a reasonable chance that by the time you pay off the loan, the value of what you built exceeds the amount borrowed. In the second case, you end up in a lather-rinse-repeat process where your debt load continues to grow and grow until it overpowers you. It's a good analogy, but, the second form of borrowing is far worse than the first. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Feb 18, 2011, at 12:24 AM, Zed Usser wrote: > On Thu, Feb 10, 2011 at 14:17, Chris Grundemann wrote: > >> In case you have not already found this: >> http://tools.ietf.org/html/draft-donley-nat444-impacts-01 > > There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list. > > "draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze > NAT444, but it really analyzes what fails when two problems occur: (a) port > forwarding isn't configured and (b) UPnP is unavailable or is broken. Several > architectures share those two problems: > > * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) > * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) > * DS-Lite (which is an LSN / NAPT44 in the carrier's network) > * stateful NAT64" > I don't think the draft makes any attempt to claim that the problems are unique to NAT444, so, the above, while technically accurate isn't particulrarly meaningful. > http://www.ietf.org/mail-archive/web/behave/current/msg09027.html > > Be that as it may and putting my devil's advocate hat on, aren't the > unintended consequences of NAT444 a net win for ISPs? :) > I guess that depends on whether you like having customers or not. > Basic Internet services will work (web browsing, email, Facebook, > Youtube,...), but: > - Less torrenting > - Less Netflix watching > - Less FTP downloads > - Less video streaming in general (webcams, etc.) > > You might take a hit on online gaming, but what else is there not to love? :) > + More support phone calls + More unhappy customers + More cancellations + Less revenue + More costs + CALEA joy > Your sales department / helpdesk might have a bit of hassle of trying to > undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but > most of them won't care either way. > An interesting theory. > Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be > required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, > aren't we going to have to deal with these issues in any case? > No, we need to move forward with IPv6 on all levels in order to reduce the need for these solutions. Joining the IPv4/IPv6 domains doesn't work out all that well and a dependency on doing so is broken in a number of ways, many of which are documented in the draft. Owen
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Fri, Feb 18, 2011 at 9:24 AM, Zed Usser wrote: > Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be > required to join the IPv4 and IPv6 > domains in all foreseeable futures? If so, aren't we going to have to deal > with these issues in any case? I'd compare it with borrowing some money: When you make NAT64 to reach from IPv6 to IPv4, you are borrowing the money to build a new house. When you make NAT444, you borrow the money to repay the debt you made by borrowing the previous month. Both are borrowing. Depending on the circumstances you may need both. cheers, andrew
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On 18 feb 2011, at 9:24, Zed Usser wrote: > Basic Internet services will work (web browsing, email, Facebook, > Youtube,...), but: > - Less torrenting > - Less Netflix watching > - Less FTP downloads > - Less video streaming in general (webcams, etc.) You forget: - no IPv6 tunnels Deploying NAT444 without IPv6 is a very bad thing.
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Thu, Feb 10, 2011 at 14:17, Chris Grundemann wrote: > In case you have not already found this: > http://tools.ietf.org/html/draft-donley-nat444-impacts-01 There's a bit of critique on the NAT444 document on the BEHAVE IETF WG list. "draft-donley-nat444-impacts-01 is somewhat misleading. It claims to analyze NAT444, but it really analyzes what fails when two problems occur: (a) port forwarding isn't configured and (b) UPnP is unavailable or is broken. Several architectures share those two problems: * NAT444 (NAPT44 in the home + NAPT44 in the carrier's network) * LSN (NAPT44 in the carrier's network, without a NAPT44 in the home) * DS-Lite (which is an LSN / NAPT44 in the carrier's network) * stateful NAT64" http://www.ietf.org/mail-archive/web/behave/current/msg09027.html Be that as it may and putting my devil's advocate hat on, aren't the unintended consequences of NAT444 a net win for ISPs? :) Basic Internet services will work (web browsing, email, Facebook, Youtube,...), but: - Less torrenting - Less Netflix watching - Less FTP downloads - Less video streaming in general (webcams, etc.) You might take a hit on online gaming, but what else is there not to love? :) Your sales department / helpdesk might have a bit of hassle of trying to undestand / explain this new Intertubes to the suck^H^H^H^Hcustomers, but most of them won't care either way. Now correct me if I'm wrong, but isn't some kind of NAT/PAT going to be required to join the IPv4 and IPv6 domains in all foreseeable futures? If so, aren't we going to have to deal with these issues in any case? - Zed
Re: [arin-ppml] NAT444 rumors (was Re: Looking for an IPv6 naysayer...)
On Thu, Feb 10, 2011 at 14:17, Benson Schliesser wrote: > If you have more experience (not including rumors) that suggests otherwise, > I'd very much like to hear about it. I'm open to the possibility that NAT444 > breaks stuff - that feels right in my gut - but I haven't found any valid > evidence of this. In case you have not already found this: http://tools.ietf.org/html/draft-donley-nat444-impacts-01 Cheers, ~Chris > > Regardless, I think we can agree that IPv6 is the way to avoid NAT-related > growing pains. We've known this for a long time. > > Cheers, > -Benson > > ___ > PPML > You are receiving this message because you are subscribed to > the ARIN Public Policy Mailing List (arin-p...@arin.net). > Unsubscribe or manage your mailing list subscription at: > http://lists.arin.net/mailman/listinfo/arin-ppml > Please contact i...@arin.net if you experience any issues. > -- @ChrisGrundemann weblog.chrisgrundemann.com www.burningwiththebush.com www.theIPv6experts.net www.coisoc.org
